Oracle Cloud Infrastructureサービスおよびプラットフォームのレジリエンスと継続的な可用性に関するFAQ

免責事項: 以下は、オラクルの一般的な製品の方向性の概要です。情報提供のみを目的としており、いかなる契約にも組み込むことはできません。これは、何らかの資料、コード、または機能を提供することを約束するものではなく、購入を決定する際の根拠にするべきではありません。オラクル製品について説明されている機能の開発、リリース、時期、価格は変更される可能性があり、Oracle Corporationの単独の裁量により決定されます。

このFAQは、オラクルがコア・インフラストラクチャ・サービスおよびホスティング・プラットフォームでどのように耐障害性と継続的な可用性を実現しているかについてのよくある質問に回答しています。次のような理由から、これらの回答は、Oracle Cloudのお客様が対象となります。

  • Oracleのホスティング・プラットフォームとサービスを評価する際に、お客様のデュー・デリジェンスの実施を支援します。
  • 回答の多くは、クラウド規模のあらゆるシステムの基本的な課題やソリューションについて説明しているため、お客様がクラウドに構築しようとしているシステムのアーキテクチャと設計がわかります。

Oracle Cloud Infrastructure Services and Platformの回復性と継続性のFAQ

すべて開く すべて閉じる
  • Oracleでは、クリティカル・サービス、継続的に使用可能なサービス、単一ロケーション・サービスなど、様々なサービス・クラスを区別していますか。

    オラクルでは、このような区別はしていません。かわりに、依存性レベル、アベイラビリティ・スコープおよびデータ・プレーンとコントロール・プレーンでサービスを分類しています。これらのカテゴリは、アベイラビリティ、耐久性、パフォーマンス、および利便性の間で、様々な有用なトレードオフを提供するように設計されています。

    依存性レベル

    アーキテクチャ・ブロック図では、これらのレベルがレイヤーまたは層とみなされる場合があります。各レイヤーが依存するのは、その下のレイヤーのみです。

    下から順に、次のとおりです。

    • コア・サービス: これらのサービスは、Oracle Cloud Infrastructureの基盤を形成します。これには、アイデンティティおよびアクセス管理(IAM)、キー管理、ネットワーキング、コンピュート、ブロック・ボリューム、オブジェクト・ストレージ、テレメトリおよびいくつかの共有内部サービスがあります。これらは、依存関係を最小限に抑えるように設計されています。(依存関係の詳細は、このドキュメントの後半を参照してください)。
    • IaaS: このレイヤーは、よりインフラレベルの機能をコアの上に構築します。このレイヤーのサービスには、File Storage、DatabaseおよびContainer Engine for Kubernetesがあります。
    • SaaS: このレイヤーは、リッチなSoftware as a Serviceであり、下位レイヤーに基づいて構築されます。

    可用性スコープ

    サービスに対する可用性と耐久性の目標を達成するため、各サービスには、次のいずれかのアベイラビリティ・スコープが選択されています。

    • 可用性ドメイン・ローカル: 可用性ドメインごとに、サービスの1つの独立したインスタンスが含まれます。このサービスが、同じアベイラビリティ・ドメイン内のレプリカ間で同期レプリケーションを行うことで、格納されたデータの耐久性を高めています(詳細は、このドキュメントの後半のフォルト・ドメインの項を参照してください)。これらのサービスでは、各サービスの特性に応じて、アベイラビリティ・ドメイン内の1/3以上のインフラの停止に耐えることができます。可用性ドメイン・ローカル・サービスは、可用性ドメイン内の2種類の論理データ・センター(障害分離とパフォーマンス分離の論理グループ)を使用することで、このレベルのフォルト・トレランスに合せることができます。詳細は、このドキュメントを参照してください。また、これらのサービスは、アベイラビリティ・ドメインが他のどのアベイラビリティ・ドメインとも通信できない場合でも、通常として機能できます。そのため、他のアベイラビリティ・ドメインの損失や、リージョン内のワイド・エリア・ネットワークの完全な障害には耐えられます。
    • 複数のアベイラビリティ・ドメイン・リージョン: 複数のアベイラビリティ・ドメインがある各リージョンにはサービスの1つの独立したインスタンスが含まれており、そのリージョン内の各アベイラビリティ・ドメインにコンポーネントが置されています。これらのサービスでは、同じリージョン内の複数のアベイラビリティ・ドメインと同期レプリケーションを行うことで、非常に高い耐久性を実現しています。これらのサービスは、リージョン内の1つのアベイラビリティ・ドメインの停止または通信不能を許容できます。
    • 可用性ドメインが1つのリージョン: リージョンの可用性ドメインが1つのみの場合、リージョナル・サービスの観測可能な特性は、前述した可用性ドメイン・ローカルのサービスの特性と一致します。可用性ドメイン・ローカル・サービスと単一可用性ドメイン・リージョナル・サービスの違いが関係するようになったのは、1つ以上のアベイラビリティ・ドメインを追加して単一可用性ドメイン・リージョンが拡張されている場合のみです。この場合、各リージョン別サービスは、新しい可用性ドメインを適切に使用するために自動的に拡張されますが、サービスのインスタンスは1つのままです。たとえば、追加のアベイラビリティ・ドメインを使用して既存データの耐久性を向上させるため、Object Storageデータ・プレーンが拡張されます。一方、アベイラビリティ・ドメインのローカル・サービスでは、新しいアベイラビリティ・ドメインのそれぞれが、各アベイラビリティ・ドメインのローカル・サービスの独立した専用のインスタンスを受信します。
    • リージョン間の分散: Oracle Cloud Infrastructureの基本原則は、各リージョンの運用が他のリージョンからできるかぎり独立していることです。可能なかぎりという条件が表しているのは、リージョンでは、少なくともインフラの一部(たとえば、リージョン間のバックボーン・ネットワーク)を共有せねばならないという事実です。それ以外の場合は、透過的な高可用性やフェイルオーバーなど、同時に複数のリージョンに影響する問題を引き起こす可能性がある密結合メカニズムをリージョン間に構築しません。かわりに、リージョン間にサービスを分散する2つのメカニズムを冗長なカップリングで提供します。
      • 障害時リカバリ(DR): お客様がDR特性を持つシステムを構築できるようにすることは、クラウドにおけるオラクルのアプローチと投資の基礎です。いくつかのコア・サービスは、すでにDRメカニズムを提供しています。たとえば、Block Volumesリージョン間のバックアップやObject Storageリージョン間のコピーなどです。オラクルのすべてのサービスでDR機能は、ロードマップにおける優先度が高い項目になっています。
      • インターリージョン・サブスクリプション: 現在のところ、IAMデータに対するリージョン間サブスクリプションのみを提供しています。概念的には、IAMデータにはグローバル・スコープがあります。お客様は、一連のリージョンをサブスクライブ(オプトイン)でき、オラクルは関連するIAMデータとその後の更新を指定されたリージョンに自動的にレプリケートします。密結合を避けるため、レプリケーションは非同期で、最終的には一貫性が確保されます。お客様は、ノミネートする「ホーム」リージョン内のIAMデータを変更します。現在のホーム・リージョンがなんらかの理由により利用できなくなっていった場合、別のリージョンをノミネートできます。

    コントロール・プレーンとデータ・プレーン

    サービスのデータ・プレーンは、データ処理インタフェースおよびコンポーネントのコレクションで、アプリケーションで使用することを目的としたサービスの機能を実装します。たとえば、仮想クラウド・ネットワーク(VCN)のデータ・プレーンには、ネットワーク・パケット処理システム、仮想化ルーター、ゲートウェイが含まれ、Block Volumesのデータ・プレーンには、iSCSIプロトコルの実装とボリューム・データ向けのレプリケートされたストレージ・システムが含まれます。

    サービスのコントロール・プレーンは、次のタスクを担当するAPIおよびコンポーネントのセットです。

    • リソースをプロビジョニング、再構成、スケール・アップ/ダウンまたは終了する、カスタマ・リクエストの処理
    • 大規模フリートの迅速で安全な自動パッチ適用の実行
    • 失敗したリソース、低下リソースまたは構成ミッド・リソースの検出
    • 自動修復の実行、またはサポート要員の呼出し
    • 他のコントロール・プレーンとのコラボレーション(コンピュート、VCN、ブロック・ストレージはLaunchInstanceの間に結合されます)
    • 未使用容量の管理
    • 新しい装置が到着する際や、物理的な修理およびメンテナンスなどにおける人間との調整
    • 操作の可視化と管理を実現
  • Oracleは、どのようにしてサービスの回復性と継続的な可用性を確保していますか。

  • 複数の可用性ドメインを含むOracleリージョンでは、すべてのクリティカル・サービスが可用性ドメイン間に分散されますか。

  • Oracleとその顧客は、単一の論理データ・センターに依存するクリティカルなサービスを避けるためにどのようにしますか。

  • Oracleでは、重要なサービスを一時的に使用できずにメンテナンス・アクティビティをどのように行いますか。

  • サーバーレス・プラットフォーム・サービスは、複数の論理データ・センターにデプロイされ、高可用性を実現していますか。

  • 耐障害性がデフォルト構成ではない場合、顧客には複数の論理データ・センター・デプロイ(たとえば、複数の可用性ドメインからなる構成またはリージョン間構成)の選択肢が提供されますか。

  • Oracleは、様々なインフラストラクチャ・サービスとプラットフォーム・サービス間の内部依存関係によって発生するアプリケーションの相関する障害をどのように回避するのですか。

  • リージョンのAPIエンドポイントを含む、リージョン内のOracle Cloud Infrastructureサービスは、グローバル・コントロール・プレーン関数から分離されている場合に操作を続けますか。

  • リージョンの制御プレーン機能から分離した場合、論理データ・センター内のOracle Cloud Infrastructureサービスは引き続き機能しますか。

  • Oracle Cloud Infrastructureリージョンには、高可用性のための冗長インターネット接続がありますか。