サービス制限の管理

テナンシのサービス制限とコンパートメント割当てについて理解、監視および管理します。 サービス制限は、テナンシで使用できるリソースを制限するリソース割当てです。これらはテナンシの作成時に確立されますが、リクエストに応じて変更できます。コンパートメント割当て制限は、管理者が高いレベルの柔軟性を備えた特定のコンパートメントにリソースを割り当てることができるポリシーです。
サービス制限は、次の目的で使用されます。
  • ユーザーが事前定義済のリソース量のみを使用できるようにすることで、消費量とコストの未計画の急増から保護します。
  • ワークロードの実行に必要なリソースをOracleに通知して、それらのリソースを常に使用できるようにします。

テナンシのデフォルト・サービス制限の理解

エンタープライズ・アーキテクト、クラウド・アーキテクト、クラウド・オペレーション・マネージャー

通常、テナンシに関連付けられたサービス制限は、Oracle Cloud Infrastructure (OCI)にサインアップするときに確立されます。

Oracle営業担当に制限を設定していない場合、またはOracle Storeを介してサインアップした場合は、テナンシのデフォルト制限またはトライアル制限が設定されます。OCIコンソールまたはAPIを使用して、サービス制限を表示します。

サービス制限は、次の目的で使用されます。
  • ユーザーが事前定義済のリソース量のみを使用できるようにすることで、消費量とコストの未計画の急増から保護します。
  • ワークロードの実行に必要なリソースをOracleに通知して、それらのリソースを常に使用できるようにします。
サービス制限に関係なく、実際に使用したリソースに対してのみ課金されます。

OCIはリージョンおよび可用性ドメインでホストされます。リージョンはローカライズされた地理的領域で、可用性ドメインは1つのリージョン内の1つ以上のデータ・センターです。各リソースには、定義された制限とスコープがあります。サービス制限の範囲は、リージョナル、可用性ドメインまたはリソース固有です。場合によっては、スコープはサービスによって定義されます。たとえば、仮想クラウド・ネットワークごとに許可されるNAT Gatewayリソースは1つのみです。

テナンシのサービス制限を確認するには、次のベスト・プラクティスに従います:

  1. アプリケーション、レイテンシおよびディザスタ・リカバリの要件に基づいて、Oracle Cloud Infrastructureリージョンを選択します。
  2. アプリケーションに必要なサービスを特定します。

要件を確認するには、アプリケーション・アーキテクチャ、インフラストラクチャ・コードまたはオンプレミス・デプロイメントを確認し、次のベスト・プラクティスに従います。

  1. 必要なサービスのデフォルトの制限および範囲を確認します。たとえば、アベイラビリティ・ドメインごと、リージョンごと、またはテナントごとです。サービスによっては制限が追加されることもあります。
  2. 増加が必要なデフォルトのサービス制限を識別します。
  3. ピーク負荷時にアプリケーションを実行するために必要な容量を理解し、アベイラビリティ・ドメインに障害が発生した場合の自己回復性を制限できることを確認してください。

サービス制限の監視および管理

クラウド・アーキテクト、クラウド・オペレーション・マネージャー

Oracle Cloud Infrastructureサービスの使用をアプリケーションに基づいて定期的に評価する必要があります。成長と拡張の余地を残して、アプリケーションの日常的な使用によって誤ってサービス制限を超えないようにしてください。使用状況を追跡し、成長を監視します。

  • OCIコンソールまたはサービス制限APIを使用して、テナンシの現在のリソース使用率およびサービス制限の合計を取得します。たとえば、アベイラビリティ・ドメイン当たりに使用しているコンピュート・インスタンスの数、およびそのアベイラビリティ・ドメインとリージョンで拡張する必要がある領域などです。

  • 必要に応じて、リソースのサービス制限の増減をリクエストします。レコードを保持し、要求を追跡します。確認を受信したら、OCIコンソールまたはサービス制限APIに移動して、サービス制限が増加(または減少)したことを確認します。

コンパートメント割当ての設定

クラウド・アーキテクト、クラウド・オペレーション・マネージャー

管理者は、ポリシー・ステートメントを使用してコンパートメント割当てを作成します。コンパートメント割当ては、各クラウド・コンパートメント内でリソースを消費する方法を制御します。管理者は、ポリシー・ステートメントを使用してコンパートメント割当てを作成します。
  1. コンパートメント構造に基づいて、各コンパートメントのサービスおよびその割当て要件を識別します。親コンパートメント・レベルで設定された割当て制限。そのコンパートメントとそのすべての子に対するリソースの使用を制限します。親コンパートメントの割当て制限を設定する場合は、子コンパートメントの使用状況を必ず含めてください。
  2. コンパートメント割当てのスコープを可用性ドメイン、リージョナルまたはグローバルとして識別します。
  3. コンパートメント割当て制限ポリシー・ステートメントを作成します。可用性ドメイン(AD)のスコープを持つ割当てを設定する場合、ポリシーで特定のADを指定しないかぎり、その割当ては各ADに割り当てられます。リージョンの割当てが各リージョンに適用されます。

固定サービス制限に注意してください

クラウド・アーキテクト、クラウド・オペレーション・マネージャー

一部のリソースには、変更できない固定のサービス制限があることに注意してください。

アプリケーションに影響を与える可能性のあるものを特定し、アーキテクチャを適切に調整します。たとえば、1つのサブネットに最大5つのセキュリティ・リストをアタッチできます。この制限を克服するために、セキュリティ・リストに加えてネットワーク・セキュリティ・グループを使用するようにアーキテクチャを調整できます。

サービス制限でのフェイルオーバー使用量の考慮

クラウド・アーキテクト、クラウド・オペレーション・マネージャー

フェイルオーバーに対応するために、現在のサービス制限と最大使用率の間の十分なギャップを考慮してください。

リソースに障害が発生しても、正常に終了するまで制限に対してカウントされる場合があります。障害が発生したリソースが終了する前に、制限がすべての障害が発生したリソースと交換の重複をカバーしていることを確認してください。このギャップを計算するときは、可用性ドメインの障害を考慮する必要があります。

  1. 信頼性と可用性のシナリオと、それに対応するのに十分なアーキテクチャの自己回復性を理解します。
  2. ブルー/グリーン、ロールオーバー、カナリアなどのデプロイメント・パターンを把握します。
  3. フェイルオーバーのサービス制限に適切なバッファがあります。
  4. 将来の成長と拡大のための適切な余地を残してください。

さらに学ぶ