ApsaraDB for SelectDB:リソース割り当て戦略

リソース管理スキーム

ApsaraDB for SelectDB は、マルチインスタンス、マルチクラスター、ワークロードグループという 3 つのリソース管理および分離スキームに対応しています。

マルチインスタンススキーム

ApsaraDB for SelectDB では、同一アカウント内に複数の独立してデプロイされたインスタンスを作成できます。このスキームは、完全に独立したビジネスシステムに最適です。

インスタンス間でコンピューティングリソースとストレージリソースは物理的に分離されており、各インスタンスは独自の複数のエンドポイントを持ちます。

マルチクラスタースキーム

ApsaraDB for SelectDB は、ストレージとコンピューティングの分離に対応しています。同一インスタンス内に、物理的に分離された複数のコンピュートクラスターを作成できます。各コンピュートクラスターは、ビッグデータシステムのコンピュートグループやコンピュートキューに似た、バックエンド (BE) ノードのグループで構成されます。このスキームは、読み取りトラフィックと書き込みトラフィック、またはオンライントラフィックとオフライントラフィックを分離するのに最適です。

インスタンス内のクラスターは同じデータを共有します。同じエンドポイントを使用して複数のクラスターに接続し、USE @cluster_name コマンドを実行してクラスターを切り替えることができます。詳細については、「複数のコンピュートクラスター」をご参照ください。

ワークロードグループスキーム

ApsaraDB for SelectDB では、ワークロードグループを使用して、ソフトウェアレベルでコンピューティングリソースを分離できます。1 つのクラスターには複数のワークロードグループを設定でき、各ワークロードグループはタスクごとに単一の BE ノードでのコンピューティングとメモリの使用量を制限します。このスキームは、リソースの分離を必要としますが、ある程度のリソースプリエンプションを許容するシナリオに最適です。

コンピューティングリソースはワークロードグループによって論理的に分離されますが、すべてのワークロードグループは同じデータを共有します。ワークロードグループに関連付けられたデータベースアカウントを使用して、異なるグループにアクセスできます。詳細については、「ワークロードグループ」をご参照ください。

スキームの比較

次の表は、3 つのスキームを分離方法と分離レベルの観点から比較したものです。

マルチインスタンススキームは最も強力な分離を実現しますが、ストレージの冗長化やコンピューティング利用率の低下につながる可能性があります。ワークロードグループスキームは、コンピューティングリソースの中程度のプリエンプションを許容し、高い利用率を確保しますが、分離は弱くなります。一般的に、システムが完全に独立している場合はマルチインスタンススキームを使用します。データを共有する必要があるが、コンピューティングリソースを物理的に分離する必要がある場合は、マルチクラスタースキームを使用します。データが共有され、コンピューティングリソースを時々分離する必要がある場合は、ワークロードグループスキームを使用します。

推奨スキーム

マルチインスタンススキーム

次のシナリオでは、マルチインスタンススキームを検討してください。

• 独立したビジネスシステムやチーム間でデータは共有されません。

• ビジネスシステムは重要であるか、機密情報を含んでおり、データ漏洩のリスクを最小限に抑え、相互干渉を防ぐ必要があります。

マルチクラスタースキーム

次のシナリオでは、単一インスタンスのマルチクラスタースキームを検討してください。

• データは共有されますが、コンピューティングリソースは機密度レベルに応じて分離する必要があります。たとえば、オンラインのデータ分析は、オフラインのデータ分析から分離する必要があります。

• データインポートのワークロードをクエリワークロードから分離する必要があります。

• リソース利用率に関する特別な要件がありません。

ワークロードグループスキーム

次のシナリオでは、ワークロードグループスキームを検討してください。

• データは共有され、コンピューティングリソースは物理的な分離を必要としません。各ワークロードには基本リソースを保証する必要がある一方、アイドル状態のリソースはプリエンプションが可能です。

• リソース利用率を最大化する必要がある、またはリソース効率に関する特定の要件があります。