このドキュメントでは、コンテナ ランタイムをサポートする任意の Linux 環境で AlloyDB Omni を実行する準備を行う方法について説明します。
AlloyDB Omni の概要については、AlloyDB Omni の概要をご覧ください。
サイズと容量
サイズと容量は、AlloyDB Omni インスタンスのパフォーマンス、信頼性、費用対効果に直接影響します。既存のデータベースを移行する場合、必要な CPU リソースとメモリリソースは、移行元データベース システムの要件に似ています。
一致する CPU、RAM、ディスク リソースを使用してデプロイを開始し、ソースシステム構成を AlloyDB Omni ベースライン構成として使用することを計画します。AlloyDB Omni インスタンスの十分なテストを行った後で、リソース使用量を削減できる場合があります。
AlloyDB Omni 環境のサイズ設定には、次の手順が含まれます。
ワークロードを定義します。
データ量: AlloyDB Omni に保存するデータの合計量を見積もります。現在のデータと時間の経過に伴う成長予測の両方を考慮します。
トランザクション レート: 読み取り、書き込み、更新、削除を含む 1 秒あたりのトランザクション数（TPS）を決定します。
同時実行: データベースにアクセスする同時実行ユーザー数または接続数を推定します。
パフォーマンス要件: さまざまな種類のクエリとオペレーションで許容される応答時間を定義します。
ハードウェアがサイズ要件をサポートしていることを確認します。
CPU: AlloyDB Omni は、64 コアまでリニアにスケーリングする複数の CPU コアを利用できます。ただし、オープンソースの PostgreSQL では、通常、16 個を超える vCPU を使用するメリットはありません。ワークロードの同時実行と計算ニーズに基づいてコア数を検討します。CPU の世代またはプラットフォームの変更によって得られる可能性のあるメリットを考慮します。
メモリ: データのキャッシュ保存用に AlloyDB Omni の共有バッファに十分な RAM を割り当て、クエリ処理用にワーキング メモリを割り当てます。具体的な要件はワークロードによって異なります。vCPU あたり 8 GB の RAM から始めます。
ストレージ
タイプ: ニーズに応じて、パフォーマンス重視のローカル NVMe ストレージと、スケーラビリティとデータ共有重視の SAN ストレージのどちらかを選択します。
容量: データボリューム、インデックス、ログ先行書き込み（WAL）、バックアップ、将来の増加に十分なストレージを確保します。
IOPS: ワークロードの読み取り/書き込みパターンに基づいて、1 秒あたりの必要な入出力オペレーション（IOPS）を推定します。パブリック クラウドで AlloyDB Omni を実行する場合は、ストレージ タイプのパフォーマンス特性を考慮して、特定の IOPS 目標を達成するためにストレージ容量を増やす必要があるかどうかを判断します。
AlloyDB Omni の実行の前提条件
AlloyDB Omni を実行する前に、次のハードウェアとソフトウェアの要件を満たしていることを確認してください。
ハードウェア要件
| OS/プラットフォーム | ハードウェアの最小要件 | 推奨ハードウェア |
|---|---|---|
| Linux |
|
|
| macOS |
|
|
- データの保存には、専用のソリッド ステート ドライブ（SSD）ストレージ デバイスを使用することをおすすめします。この目的で実機を使用する場合は、ホストマシンに直接接続することをおすすめします。
ソフトウェアの要件
| OS/プラットフォーム | ソフトウェアの最小要件 | 推奨ソフトウェア |
|---|---|---|
| Linux1 |
|
|
| macOS |
|
|
- AlloyDB Omni は、SELinux が存在する場合、ファイル システムへのアクセスなど、コンテナの実行を許可するようにホストで構成されていることを前提としています（または SELinux が許可モードに設定されています）。
サポートされているストレージ タイプ
AlloyDB Omni は、データベース インスタンスのブロック ストレージ ボリュームのファイル システムをサポートしています。小規模な開発システムまたはトライアル システムの場合は、コンテナが実行されているホストのローカル ファイル システムを使用します。エンタープライズ ワークロードの場合は、AlloyDB Omni インスタンス用に予約されたストレージを使用します。データベース ワークロードによって設定された需要に応じて、コンテナごとに 1 つのディスク デバイスを使用するシングルトン構成、または複数のコンテナが同じディスク デバイスから読み取りと書き込みを行う統合構成でストレージ デバイスを構成します。
ローカル NVMe または SAN ストレージ
ローカルの Non-Volatile Memory Express（NVMe）ストレージとストレージ エリア ネットワーク（SAN）ストレージには、それぞれ独自の利点があります。適切なソリューションを選択するには、特定のワークロード要件、予算、将来のスケーラビリティのニーズを考慮する必要があります。
最適なストレージ オプションを決定するには、次の点を考慮してください。
- 絶対的なパフォーマンスを優先する場合は、ローカル NVMe を選択します。
- 大規模な共有ストレージが必要な場合は、SAN を選択します。
- パフォーマンスと共有のバランスを取る必要がある場合は、NVMe over Fabrics を使用する SAN を検討して、アクセスを高速化します。
ローカル NVMe ストレージ
NVMe は、ソリッド ステート ドライブ（SSD）用に設計された高パフォーマンス プロトコルです。高速なデータアクセスが必要なアプリケーションの場合、ローカル NVMe ストレージには次のメリットがあります。
- NVMe SSD は、Peripheral Component Interconnect express（PCIe）バスに直接接続して、高速な読み取りと書き込みを実現します。
- ローカル NVMe ストレージは、最も低いレイテンシを提供します。
- ローカル NVMe ストレージは、最も高いスループットを提供します。
ローカル NVMe ストレージをスケーリングするには、個々のサーバーにドライブを追加する必要があります。ただし、個々のサーバーにドライブを追加すると、ストレージ プールが断片化され、管理が複雑になる可能性があります。ローカル NVMe ストレージは、複数のサーバー間でのデータ共有用に設計されていません。ローカル NVMe ストレージはローカルであるため、サーバー管理者はハードウェアまたはソフトウェアの Redundant Array of Inexpensive Disks（RAID）を使用してディスク障害から保護する必要があります。そうしないと、単一の NVMe デバイスで障害が発生するとデータが失われます。
SAN ストレージ
SAN は、複数のサーバーをストレージ デバイスの共有プール（多くの場合、SSD または一元化された NVMe ストレージ）に接続する専用のストレージ ネットワークです。SAN はローカル NVMe ほど高速ではありませんが、最新の SAN（特に NVMe over Fabric を使用する SAN）は、ほとんどのエンタープライズ ワークロードで優れたパフォーマンスを提供します。
SAN は高度にスケーラブルです。ストレージ容量やパフォーマンスを増やすには、新しいストレージ アレイを追加するか、既存のストレージ アレイをアップグレードします。SAN はストレージ レイヤで冗長性を提供し、ストレージ メディアの障害から保護します。
SAN はデータ共有に優れています。高可用性が求められるエンタープライズ環境では、複数のサーバーが SAN に保存されているデータにアクセスして共有できます。サーバーの障害が発生した場合は、データセンター内の別のサーバーに SAN ストレージを公開して、迅速な復旧を実現できます。