サービス制限の管理

テナンシのサービス制限およびコンパートメント割当てを理解、監視および管理します。 サービス制限は、テナンシで使用できるリソースを制限するリソース割当てです。これらはテナンシの作成時に確立されますが、リクエストに応じて変更できます。コンパートメント割当て制限は、管理者が特定のコンパートメントに高い柔軟性でリソースを割り当てることができるようにするポリシーです。

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

エンタープライズ・アーキテクト、クラウド・アーキテクト、インフラストラクチャ・リーダー

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

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

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

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

1. アプリケーション、レイテンシおよび障害時リカバリの要件に基づいて、Oracle Cloud Infrastructureリージョンを識別します。
2. アプリケーションに必要なサービスを特定します。

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

1. 必要なサービスのデフォルトの制限およびスコープを確認します。たとえば、可用性ドメインごと、リージョンごと、テナントごとなどです。サービスによっては制限が追加されることがあります。
2. 増加が必要なデフォルトのサービス制限を特定します。
3. ピーク負荷時にアプリケーションを実行するために必要な容量を把握し、可用性ドメインに障害が発生した場合にリジリエンシが許可されるように制限します。

サービス制限は、次の目的で使用されます。

• テナンシが目的のリソースのみを使用できるようにすることで、予期しない消費から自分自身を保護できます。
• ワークロードの実行に必要なリソースをOracleに通知して、それらのリソースが常に使用可能になるようにします。

サービス制限に関係なく、実際に使用するリソースに対してのみ課金されます。

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

クラウド・アーキテクト、インフラストラクチャ・リーダー

アプリケーションに基づいてOracle Cloud Infrastructureサービスの使用を評価します。拡張の余地を残しておきます。現在の使用状況を追跡し、成長を監視します。

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

• 必要に応じて、リソースのサービス制限の引上げをリクエストします。レコードを保持し、リクエストを追跡します。確認を受信したら、OCIコンソールまたはサービス制限APIに移動して、サービス制限を検証します。

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

クラウド・アーキテクト、インフラストラクチャ・リーダー

管理者は、ポリシー・ステートメントを使用してコンパートメント割当て制限を作成します。割当て制限は、クラウド・コンパートメントでのリソースの使用方法を制御します。

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

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

クラウド・アーキテクト、インフラストラクチャ・リーダー

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

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

サービス制限におけるファクタのフェイルオーバーの使用

クラウド・アーキテクト、インフラストラクチャ・リーダー

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

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

1. 信頼性と可用性のシナリオ、およびそのシナリオに対応するのに十分な耐性をアーキテクチャに持たせる方法を理解します。通常、可用性の形式は「9秒の数」です。
2. ブルー/グリーン、ロールオーバー、キャナリなどのデプロイメント・パターンを理解します。
3. フェイルオーバーのサービス制限に適切なバッファがあること。
4. 将来の拡張に備えて適切な余地を残しておきます。

さらに学ぶ

• リージョンおよび可用性ドメイン

• サービス制限、割当て制限および使用状況の表示

• サービスの制限API

• コンパートメント割当て