このドキュメントでは、Config Controller の使用をシャーディングする方法についての推奨事項を示します。シャーディングとは、Config Controller で管理されている Google Cloud リソースを複数の名前空間、クラスタ、プロジェクトに分割するプロセスです。
シャーディングには次のような利点があります。
- 変更の影響を軽減する: 1 つのシャードが機能を停止しても、他のシャードは影響を受けません。
- セキュリティ管理を支援する: 各シャードに専用の IAM と RBAC 構成を設定できます。1 つのシャードを侵害する悪意のある攻撃者は、他のシャードにアクセスできません。1 つのシャードの構成ミスが他のシャードに影響することはありません。
- スケーラビリティの向上: 単一シャードでは、マネージド オブジェクトの数や API 割り当てなどのスケーラビリティのボトルネックが発生する可能性があります。複数のシャードを使用すると、Config Controller の使用の全体的なスケーラビリティが向上します。
Config Controller でシャーディングを使用する
シャーディングを実装する方法はいくつかあります。最適なアプローチは、お客様固有のニーズと要件によって異なります。
シャーディング モデル
シャーディング モデルには、主に次の 2 つがあります。
- 事業部門またはアプリケーション チームによる処理: このモデルは通常、Config Controller が異なるチームによって使用される場合に使用します。このモデルでは、各チームに独自のシャードが存在します。
- 環境による処理: このモデルは通常、Config Controller が異なる環境で使用される場合に使用します。たとえば、開発環境、QA 環境、本番環境それぞれに 1 つのにシャードがあるとします。
シャード間の参照の必要性を最小限に抑える
Config Controller の使用をシャーディングする場合は、シャード間の参照を最小限に抑える必要があります。シャード間の参照は、構成を複雑にし、管理を困難にする可能性があります。詳細については、インスタンス間のリソース参照をご覧ください。
シャーディング メカニズム
主なシャーディング メカニズムには次の 3 つがあります。
- 名前空間による処理: 追加の名前空間を作成し、それらの名前空間のリソースを管理するように Config Connector を構成できます。
- Config Controller インスタンスによる処理: 1 つの Google Cloud プロジェクト内に複数の Config Controller インスタンスを作成できます。
- プロジェクトによる処理: 複数の Google Cloud プロジェクト内に複数の Config Controller インスタンスを作成できます。このメカニズムは、1 つのプロジェクトで割り当てのボトルネックが発生した場合に、API の割り当ての問題に対処するのに有効です。詳細については、複数のプロジェクトにリソースを分割するをご覧ください。
シャーディングを実装する際の注意点
Config Controller の使用にシャーディングを実装する際には、発生する可能性のある注意すべき問題がいくつかあります。これらの問題を軽減する計画を立ててください。
インスタンス間のリソース参照
Config Controller をシャーディングする際の課題の一つは、インスタンス間でのリソース参照の処理です。たとえば、プラットフォーム チームが 1 つのインスタンスでプロジェクトを作成し、アプリチームが他のインスタンスでそれらのプロジェクトを参照するリソースを作成することが考えられます。これにより、次のような問題が発生する可能性があります。
- 複雑性の増大: クラスタ間でリソース参照を管理すると、構成が複雑になり、管理が困難になる可能性があります。
- リスクの増大: あるシャードでリソースが削除されても、他のシャードにあるリソースによって引き続き参照される可能性があります。これにより、予期しない動作やデータ損失が生じる可能性があります。
- パフォーマンスの低下: クラスタ間のリソース参照により、構成変更のレイテンシが増大する可能性があります。
相互参照の課題を回避するには、いくつかの方法があります。
- シャード間の参照が不要な方法でシャーディングする。これは、環境またはチームでシャーディングすることで実現できます。
- 外部参照を使用する。つまり、参照されているオブジェクトは実際には Config Controller によって管理されていません。オブジェクトが頻繁に変更されない場合は、この方法が適しています。
- すべてのシャードで同じオブジェクトを利用可能にする。これはより複雑な方法ですが、オブジェクトが頻繁に変更される場合は最適な方法です。オブジェクトは、異なるシャードにあるオブジェクト間の調整による競合を回避するために、同じ信頼できる情報源を共有する必要があります。これらのオブジェクトの競合防止ポリシーを
noneに設定する必要があります。
いずれかを選択する前に、各アプローチの長所と短所を慎重に検討することが重要です。
API 割り当て
シャーディングを行うと、API の割り当てが増加する可能性があります。この点に留意して、計画を立ててください。API 割り当て上限の管理に関するベスト プラクティスについては、API 割り当て上限を管理するをご覧ください。
次のステップ
- Config Controller のスケーラビリティの詳細を確認する。