Oracle Cloud Infrastructure Blog(翻訳)

Oracle Resource Managerによる高度なTerraformスタック・ロジック (2023/11/01) https://blogs.oracle.com/cloud-infrastructure/post/adv-terraform-stack-logic-oracle-resource-manager 投稿者： Zachary Smith | Principal Solution Architect このブログ投稿では、 Oracle Resource Manager スタックを使用してTerraformコードに高度なロジックを作成する方法を示します。このブログの例は、 Data Lakehouseのクイック・スタート・スタック と、 Oracle Container Engine for Kubernetes (OKE)のApache Airflowのクイック・スタート・スタック です。 Resource Managerスタック・スキーマ Oracle Resource Manager は、Infrastructure as Code (IaC)モデルを介してリソースをインストール、構成および管理するのに役立つTerraformスタック・サポートを提供する、無償のフルマネージドOracle Cloud Infrastructure (OCI)サービスです。Oracle Resource Managerスタックについて最初に理解する必要があるのは、基礎となるTerraformコードに スキーマ・オーバーレイ を使用することです。このスキーマでは、Oracle Cloudコンソール・インタフェースを使用して変数選択を抽象化できます。また、このスキーマでは、OCI内の非常に強力な 動的統合 もサポートされており、テナンシ内の使用可能な値のリストを公開する合理化されたメカニズムが提供されます。次に例を示します。 Region selection Compartment ID Core image selection Compute shape selection VCN selection Subnet selection Availability domain selection Fault doma

Oracle Machine Learning for R 2.0がOracle Databaseで利用可能に (2023/11/01) https://blogs.oracle.com/machinelearning/post/oml4r-2-now-available-for-oracle-database 投稿者： Mark Hornick | Senior Director, Data Science and Machine Learning Oracle Database 19cおよび21cでのOracle Machine Learning for R 2.0の一般提供をお知らせします。昨年、Oracle Autonomous DatabaseのOML4R 2.0を発表しました。このリリースでは、ユーザーは同じスタンドアロンのOML4Rクライアント・パッケージを使用して、Oracle Database、Oracle Database Cloud ServiceおよびOracle Autonomous Databaseに接続できるようになりました。OML4R 2.0では、Rを介して公開されるネイティブ・データベース内アルゴリズムのセットが拡張され、ニューラル・ネットワーク、ランダム・フォレスト、指数平滑法モデルおよびXGBoostが含まれます。XGBoostは21c以降で使用できます。 Oracle Machine Learning for R(OML4R)は、データベースをハイパフォーマンス・コンピューティング環境として活用して、使い慣れたR構文およびセマンティクスを使用しながら、データを迅速かつ大規模に探索、変換および分析します。データベース内の並列化された機械学習アルゴリズムは、適切に統合されたRインタフェースを介して公開されます。 データ・サイエンティストやその他のRユーザーは、フラット・ファイルで管理するのではなく、ユーザー定義のR関数とRオブジェクトをデータベースに直接格納および管理することもできます。これらの機能により、データ・サイエンティストからアプリケーション開発者へのデータ・サイエンス・ワーク製品の便利な受渡しが可能になり、データ・サイエンス・チーム間のコラボレーションが促進されます。このリリースのOML4Rでは、R 4.0.5に基づく

Oracle RACによるメンテナンスのためのドレインとアプリケーション・コンティニュイティの仕組み (2023/11/01) https://database-heartbeat.com/2023/11/01/draining-ac-rac/ はじめに Oracle RACは、Oracle Databaseのスケーラビリティと高可用性を提供します。1つのサーバー(RACノード)に障害が発生した場合、またはメンテナンスのためにオフラインになった場合でも、追加のノードを介してデータベースにアクセスできます。ただし、メンテナンスの開始時に、データの読取りまたは変更に関係なく、一部の作業を実行しているクライアント・セッションはどうなりますか。この作業は中断され、ドレインを実装してアプリケーション・コンティニュイティまたは透過的アプリケーション・コンティニュイティを有効にしないかぎり、エンドユーザーまたはアプリケーションによって再度実行する必要があります。 環境 2ノードのOracle RACを例に挙げて、高速アプリケーション通知(FAN)、ドレインおよびアプリケーション・コンティニュイティによってメンテナンス・イベントがエンドユーザーに透過的になる方法を理解しましょう。アプリケーションは、30個のセッションを保持するように構成された接続プールを使用しています。 通常の操作 通常の操作中は、両方のRACノードが起動し、アプリケーションを実行しています。ロード・バランシング戦略によっては、セッションの数が両方のノード間で異なるか、均等に分散される場合があります。次の図をよりよく視覚化するために、ノード2のノード1および20のセッションに10のセッションがあるとします。 セッションは、アイドル状態(接続されているが何もしていない)またはアクティブ状態(リクエストの途中)にできます。リクエストは、データの読取り(SELECT)または操作(INSERT、DELETE、UPDATE)が可能です。 ドレインによるサービスの停止 ある時点で、システムのメンテナンスが必要になります。2ノードRACがあるため、メンテナンスはローリング方式で、1つのノードを順番に(ほとんどの場合)実行できます。メンテナンスは、たとえば、オペレーティング・システム、Grid Infrastructureまたはデ

Oracle Autonomous Databaseとクラウド間のDatabricksとの接続方法 (2023/10/31) https://blogs.oracle.com/datawarehousing/post/how-oracle-autonomous-database-connects-with-databricks-across-clouds 投稿者： Alexey Filanovskiy | Product Manager 以前は、顧客は1つの処理システムを選択し、すべてのデータをそこに置く必要がありました。これは、データベースまたはHadoopディストリビューションです。これらのプラットフォームを連携させるのは難しいことであり、データをある場所から別の場所にコピーすることは、情報を共有する通常の方法でした。このアプローチには、古いデータ、不要なストレージとCPUの使用、稼働を維持するための余分な作業、ミスの可能性など、多くの問題がありました。 デルタ共有により、プラットフォーム統合の新たな可能性が明らかに Oracle ADBは、適切に管理されたデータベースのクラウドベースの形式です。30年以上にわたる集中的な開発が印象的な結果をもたらしたため、Oracle Databaseがどれほど堅牢で強力であるかを強調する必要はありません。そのクラウド製品により、Oracleは多数の最先端の機能を組み込んでおり、今日の主要なクラウド・データベース・ソリューションの1つとなっています。2013年に設立されたDatabricksは、Sparkおよび機械学習タスクに人気のあるプラットフォームです。興味深いことに、この2つのプラットフォームは別々のクラウドで運用できます。ただし、 Delta Sharing は、各プラットフォームがクラウド間で他のプラットフォームのデータにアクセスできるようにします。Web UIを使用して、より明確な視覚的な説明を行うことで、これが例でどのように機能するかを説明します。 シナリオ: Oracle ADBがDatabricksによって共有されるデータにアクセス プロセスは非常に簡単です。 ステップ1.Databricksによって共有が作成され、Oracleにメタデータが提供されます。データをコピーする必要はありません。メタデータのスワ

CMiC、OCI File Storageサービス・レプリケーションにより、次世代構築ERPのディザスタ・リカバリを最適化 (2023/10/31) https://blogs.oracle.com/cloud-infrastructure/post/cmic-disaster-recovery-erp-oci-fss-replication 投稿者： Aboo Valappil | Technical Product Manager このブログは、CMiCと共同で開発されました。著者は、コンテンツ・マーケティング、PRおよびソーシャル・メディア担当シニア・マネージャ、Farhana Ahmad氏(CMiC)、およびIT担当ディレクタ、Vince Di Piazza氏(CMiC)に感謝したいと考えています。 CMiC は、 次世代の建設エンタープライズ・リソース・プランニング(ERP) の主要なプロバイダです。建設業界向けに設計された、統合された革新的なソフトウェア・ソリューションは、建設ソフトウェア分野における強力な足場を確保するのに役立っています。ソリューション・オファリングの観点から、主な製品カテゴリは 財務 および プロジェクト管理 です。これらのソリューションは、建設企業が単一のデータベースPlatformTMからすべての財務、プロジェクト、リソース、およびコンテンツアセットを計画および管理することで、生産性を最適化し、リスクを最小限に抑え、成長を促進する方法を変革します。 CMiCは、Oracle Cloud Infrastructure(OCI)と提携し、Platform-as-a-Service(PaaS)製品として、建設ERPソフトウェアCONSTRUCTのエンタープライズ・バージョンを実行します。OCIのInfrastructure-as-a-Service (IaaS)リソース(コンピュート、ストレージ、データベースなど)は、これらの要件を満たすようにプロビジョニングされています。永続ストレージ・レイヤーでは、CMiCプラットフォームは OCI File Storage 、 OCI Object Storage および Block Storage を使用します。 ディザスタ・リカバリの目標と課題 CMiCのお客様は、ビジネスクリティカルなサー

Kasten K10によるOracle Container Engine for Kubernetesのデータ保護のサポートを発表 (2023/10/31) https://blogs.oracle.com/cloud-infrastructure/post/kasten-k10-support-data-protection-oci-oke 投稿者： Ramesh Venkat | Principal Product Manager Rishi Johari | Principal Product Manager エンタープライズ・ソフトウェア開発におけるKubernetesの導入により、アプリケーションのデプロイ、パッチ適用、拡張が迅速化され、カスタマー・エクスペリエンスと市場投入までの時間が改善されました。GARTNER®によると、「2027年までに、グローバル組織の90%以上が本番環境でコンテナ化されたアプリケーションを実行することになり、2021年には40%未満から大幅に増加します」(GARTNER、 How to Run Containers and Kubernetes in Production 、Arun Chandrasekaran、2022年9月1日)。GARTNERは、GARTNER、 Inc.および/または米国とその他の国におけるその関連会社の登録商標およびサービス・マークであり、本書では許可を得て使用しています。All rights reserved. しかし、Kubernetesを使用して本番グレードのコンテナ化されたワークロードを実行する組織が増えるにつれ、2日目にはKubernetesクラスタのアプリケーション保護を確保するという課題が生じます。これらの課題には、災害への備え、ランサムウェア攻撃や偶発的な本番データの削除からアプリケーションを保護することが含まれます。Oracle Container Engine for Kubernetes (OKE)はマネージドKubernetesサービスであり、デフォルトでは、OKEを介して作成されるすべてのKubernetesクラスタのコントロール・プレーン・コンポーネントは高可用性であり、コントロール・プレーンの障害発生時に信頼性を提供します。また、OKEは、KubernetesをOr

OCI Stack Monitoring Enterprise Editionによる充実した監視 (2023/10/31) https://blogs.oracle.com/observability/post/enriched-stack-monitoring-enterprise-edition 投稿者： Aaron Rimel | Principal Product Manager, Observability and Management Stack Monitoring Enterprise Editionをご紹介します。 スタック・モニタリング は、Oracle E-Business Suiteなどのアプリケーションの検出と監視、およびOracle WebLogic Server、Oracle Database、ホストなどの基礎となるテクノロジ・スタック・コンポーネントをサポートするOracle Cloud Infrastructure (OCI)サービスです。Enterprise Editionでは、Stack Monitoringは、環境に固有の条件を監視するためのカスタム・メトリックの作成、機械学習を使用したパフォーマンスの異常の識別、Stack Monitoringの組込み機能以外の他のリソースへの監視の可視性の拡張など、一連の高度な監視機能を導入しています。これらの拡張性機能により、他のソリューションやサービスからリソースをインポートして、モニタリングを統合し、アプリケーション・トポロジを充実させることができます。 スタック・モニタリング・メトリック拡張による固有の要件の監視 メトリック拡張 は、スタック・モニタリングによって提供される即時利用可能なメトリック・セットを拡張して、一意のIT環境を監視するときに必要なユースケースを満たします。メトリック拡張は、単一のリソースまたはコンパートメント内のすべてのリソースでメトリック拡張を作成、テスト、公開および有効化する機能を提供します。 Stack Monitoring Enterprise Editionでのメトリック拡張の作成 スタック・モニタリングでOracle Databaseを監視するDBAは、バックアップされていないデータファイルを追跡し、過去3日以内にバックアップが発生していない場合

OCI Full Stack Disaster Recovery の新機能の概要 (2023/10/31) https://blogs.oracle.com/maa/post/new-features-oci-full-stack-disaster-recovery 投稿者： Suraj Ramesh | Principal Product Manager OCI Full Stack Disaster Recovery(Full Stack DR) は、インフラストラクチャ、データベース、アプリケーションなど、フルスタック・クラウド・アプリケーションのすべてのレイヤーに対して、完全に自動化された包括的なディザスタ・リカバリ・オーケストレーション・ソリューションを提供します。Full Stack DRを使用すると、OCIリージョン全体または同じリージョン内の複数の可用性ドメインにわたってフル・スタック・アプリケーションをリカバリできます。 ここでは、Full Stack DRサービスの DR保護グループ の一部にできる、現在使用可能な DR計画 および メンバー を簡単にまとめます。 DR計画タイプ: スイッチオーバー フェイルオーバー メンバー: Compute (仮想マシンおよび専用仮想マシン・ホスト) Oracle Base Database Service Oracle Exadata Database Service on Dedicated Infrastructure Oracle Autonomous Database Serverless ボリューム・グループ DR保護グループのメンバーに基づいて、Full Stack DRは、スタンバイDR保護グループ・リージョンでDR計画を作成しながら、 組込みグループ を自動的に生成します。要件に応じて、ユーザー定義の計画グループおよびステップを使用してDR計画をさらにカスタマイズできます。 最近ロールアウトしたエキサイティングな新機能をFull Stack DRサービスと共有できてうれしいです。 1.DRドリル・プラン: DRドリルを実行することは、顧客が本番スタックを中断することなく、ビジネス継続性の構成と計画を行使および検証できる重要なDRサービス機能です。 DRドリル・プランでは、テストおよび検証の