この記事では、Azure Kubernetes Service (AKS) ワークロードに最も効果的なストレージ オプションを選択して実装する方法について説明します。 適切なストレージ ソリューションを選択することは、Kubernetes 環境で最適なアプリケーション パフォーマンス、信頼性、およびコスト効率を実現するために不可欠です。
Azure Kubernetes Service では、ステートレスワークロードとステートフル ワークロードの両方がサポートされています。 ステートフル アプリケーションをデプロイする場合は、アプリケーションの状態を維持するための適切なストレージ ソリューションが必要です。 AKS は、マネージド データベース、ディスク (ブロック ストレージ)、ファイル、BLOB (オブジェクト) ストレージなど、複数のネイティブ ストレージ オプションと統合されます。 各オプションは、さまざまなワークロード要件に対応するために、さまざまなパフォーマンス特性、可用性の保証、コスト構造を提供します。
適切なストレージ サービスを選択する
AKS ワークロードに適したストレージ ソリューションを選択すると、パフォーマンス、信頼性、コスト効率に影響します。 次のガイドラインを使用して、データ要件に基づいて適切なストレージ サービスを選択します。
| データの種類 | 推奨されるストレージ サービス | このサービスを使用する場合 |
|---|---|---|
| 構造化データ | マネージド データベース (Azure SQL、 Azure Database for MySQL、 Azure Database for PostgreSQL、 Azure Cosmos DB) | 基になるインフラストラクチャを管理せずに、組み込みの高可用性、自動バックアップ、スケーラビリティを必要とするリレーショナル データまたは NoSQL データの場合 |
| 非構造化データ | Azure Blob Storage | SDK、NFS プロトコル、BlobFuse を介した HTTP/REST ベースのアクセスが必要なメディア ファイル、ドキュメント、ログなどの大量のオブジェクト データの場合 |
| 共有ファイル データ (高パフォーマンス) | Azure NetApp Files または Azure Files Premium | サブミリ秒の待機時間 (Azure NetApp Files) または一貫した 1 桁ミリ秒の待機時間 (Azure Files Premium) 要件を持つ共有ファイル アクセスの場合 |
| 共有構成データ | Azure Files Standard | 構成ファイル、共有アプリケーションの状態、および中程度のパフォーマンス要件を持つその他のデータの場合 |
| データベースワークロードとトランザクションワークロード | Azure Managed Disks (Premium SSD、Premium SSD v2、Ultra Disk) | 特定の IOPS とスループットを保証する専用の高パフォーマンス ブロック ストレージを必要とするステートフル アプリケーションの場合 |
| エフェメラル、一時データ | エフェメラル ディスク | ポッドまたはノードの再起動の間に保持する必要がない一時的なデータの場合 |
最終的なストレージの決定を行う前に、現実的なワークロードを使用した概念実証テストを通じてパフォーマンス要件を評価します。 AKS 内のすべてのストレージ トラフィックはネットワーク経由で移動するため、アプリケーショントラフィックとストレージ トラフィックの両方を処理するのに十分なネットワーク帯域幅がノードにあることを確認してください。
設計に関する考慮事項
次の考慮事項は、AKS 用のストレージを設計する場合です。 AKS 環境でストレージが必要な場所を検討し、各要件に最適なソリューションを決定します。
オペレーティング システム (OS) ディスク
オペレーティング システム (OS) ディスクの場合は、次の要因を考慮してください。
OS の一時的ディスク。 Azure 内の各仮想マシン (VM) には、その OS 用のディスクが必要です。 Kubernetes ノードはエフェメラルであるため、AKS では、サポートされている VM サイズでエフェメラル OS ディスクが既定で使用されます。 エフェメラル OS ディスクの詳細については、「エフェメラル OS」を参照してください。
OS 用のマネージド ディスク。 ワークロードで必要な場合は、代わりに AKS クラスター内のノードに通常のマネージド ディスクを使用できます。 これにより、OS ドライブ上の永続的なデータを必要とするワークロードがサポートされます。 永続ストレージのオプションの詳細については、「 Azure Kubernetes Service (AKS) のアプリケーションのストレージ オプション」を参照してください。
マネージド ディスクのサイズ変更。 OS ディスクとしてマネージド ディスクを選択する場合は、OS、Kubernetes システム、およびワークロードの要件をサポートするようにサイズを設定してください。 オプションと相違点の詳細については、「 Azure マネージド ディスクの種類」を参照してください。
アプリケーション データ
一部のワークロードでは、アプリケーション データを格納するために一貫性のあるデータ ストアが必要です。 アプリケーションでデータベースが必要な場合は、次のオプションを含む Azure のマネージド データベースを調べてみてください。
AKS のストレージ ソリューション
マネージド データベースがアプリケーションのニーズを満たしていない場合は、AKS で使用できる別のストレージ オプションを使用して一貫性のあるデータを格納することを検討してください。 オプションには、ディスク ベースのソリューション、エフェメラル ディスク、ファイルベースのソリューション、BLOB ストレージ、およびこの記事で取り上げられていないその他のオプションが含まれます。
ディスク ベースのソリューション
ディスク (ブロック ストレージ) は、未加工のブロック ベースのデバイスに直接データを格納するのに最適です。 ディスク ベースのストレージは、Kubernetes クラスターがホストするデータベースのデータを格納するのに最適です。 Azure では、マネージド ディスクはブロックベースのストレージを取得するためのソリューションです。
静的または動的に作成されたディスク ストレージ。 AKSの外部で作成した静的ディスクを使用するか、ポッドが必要に応じてAKSが動的に作成するディスクストレージを使用する必要があります。 動的に作成されたストレージは、動的に削除することもできます。 詳細については、以下を参照してください。
冗長性とパフォーマンス。 ワークロードに必要なストレージの冗長性とパフォーマンスを考慮してください。 詳細については、以下を参照してください。
共有ディスク。 共有ディスクが必要かどうかを検討します。 オプションの詳細については、「 Azure マネージド ディスクの共有」を参照してください。
ディスクとスループットのノードのサイズ。 Kubernetes ノードのサイズを検討します。 ディスクの数と合計スループット要件の両方をサポートするのに十分な大きさである必要があります。 サイズと特性の詳細については、「 Azure の仮想マシンのサイズ」を参照してください。
ディスク サイズと必要なパフォーマンス。 マネージド ディスクのサイズがワークロードのパフォーマンス要件に適しているかどうかを検討します。 Standard HDD、Standard SSD、Premium SSD v1 のディスク サイズが増えると、パフォーマンスが向上します。 マネージド ディスクの詳細については、「 Azure マネージド ディスクの種類」を参照してください。
エフェメラル ディスク ソリューション
アプリケーションで非永続的な一時ストレージが必要か、ストレージ 最適化 VM で高パフォーマンスドライブを使用する場所を検討してください。 エフェメラル ボリュームに接続するには、Kubernetes の emptyDir オプション または CSI エフェメラル ローカル ボリュームのドライバーを使用できます。 スクラッチ領域などの一時的なデータには emptyDir をお勧めします。 ストレージ最適化 VM シリーズのストレージでは、一時的なローカル ボリュームで CSI を使用することをお勧めします。 CSI ドライバーの詳細については、 Azure Kubernetes Service (AKS) 上のコンテナー ストレージ インターフェイス (CSI) ドライバーに関するページを参照してください。
Azure コンテナー ストレージ
Azure Container Storage は、コンテナー用にネイティブに構築されたクラウドベースのボリューム管理、デプロイ、オーケストレーション サービスです。 Azure ディスク、エフェメラル ディスク、または Azure Elastic SAN を使用して、ReadWriteOnce モードでブロックベースのストレージを使用する予定の場合、Azure Container Storage には CSI ドライバーを直接使用するよりも優れた利点があります。
- 価格パフォーマンスの向上: 1 つのディスクを複数の PV で共有して、オーバープロビジョニングを削減し、コストを削減します。
- より高いPVスケール:CSIドライバで64 PVの制限を超えるノードあたり最大75PVをサポートします。
- レプリケーションを使用したローカル NVMe: 一時的なディスクのミリ秒未満の待機時間と回復性を有効にします。Cassandra などの組み込みのレプリケーションを使用するワークロードに最適です。
- プロビジョニングとスケーリングの高速化: バッチ操作では、シリアル CSI ドライバー操作と比較して、ボリュームのプロビジョニングとスケーリングが高速化されます。
詳細については、「Azure Container Storage とは」を参照してください。
ファイルベースのソリューション
ポッドで共有ファイル システムへのアクセスが必要かどうかを確認します。 Kubernetes クラスター内の複数のポッドが読み取って共有する必要があるアプリケーションと構成データには、共有ファイル システムを使用します。 ファイル ストレージは、NFS または SMB/Common Internet File System (CIFS) プロトコルを介して共有ファイル システムを提供します。 Azure には、ファイル ベースのストレージ用の 2 つのソリューション (Azure Files と Azure NetApp Files) が用意されています。
Azure Files
Azure Files の場合は、次のオプションを検討してください。
静的または動的に作成されたファイル共有。 AKS の外部で作成する静的ファイル共有、または AKS がユーザーに代わって動的に作成するファイル共有を使用することを検討してください。 詳細については、以下を参照してください。
Standard または Premium のパフォーマンス。 標準パフォーマンスで十分かどうか、または Azure Files の Premium パフォーマンスが必要かどうかを評価します。
SMB/CIFS または NFS。 Azure Files にアクセスするには、ワークロードで既定のプロトコルである SMB/CIFS 用の API を使用する必要があるか、またはワークロードで NFS サポートが必要かを評価します。
アクセス用のネットワーク モデル。 Azure Files へのアクセスに使用するネットワーク モデル (直接パブリック IP アドレス、サービス エンドポイント、またはプライベート リンクを介したアクセス) を検討してください。
Azure NetApp ファイルズ
Azure NetApp Files の場合は、次のオプションを検討してください。
静的または動的に生成された Azure NetApp Files の共有。 AKS の外部で作成する静的な Azure NetApp Files 共有を使用するか、AKS が Astra Control を介して動的に作成するファイル共有を使用することを検討してください。 詳細については、以下を参照してください。
パフォーマンスを評価します。 ワークロードに必要なパフォーマンス レベルを評価します。 詳細については、「Azure NetApp Files のパフォーマンスに関する考慮事項」を参照してください。
ネットワークを計画します。 Azure NetApp Files のネットワークに関する推奨事項について説明します。 詳細については、「Azure NetApp Files のネットワーク計画のガイドライン」を参照してください。
ブロブストレージ
アプリケーションで格納する必要がある非構造化データの量を考慮してください。 Azure Blob Storage には、HTTP API または SDK を介してアクセスできます。 BLOB ストレージをファイル システムとしてコンテナーまたはポッドにマウントすることは、ログ ファイル、イメージ、ドキュメント、ストリーミング メディア、ディザスター リカバリー データなど、大量の非構造化データを含むアプリケーション ワークロードに最適です。
データの冗長性。 アプリケーションに適したデータ冗長性を検討します。 詳細については、「Azure Storage の冗長性」を参照してください。 データの冗長性は、ストレージ アカウントのレベルで選択されます。
パフォーマンス レベル。 アプリケーションで必要な BLOB ストレージのパフォーマンスレベルを検討します。 詳細については、「 BLOB データのホット、クール、アーカイブアクセス層」を参照してください。
アクセスの認証方法。 BLOB ストレージへのアクセスにアプリケーションで使用する認証方法 (ストレージ キー、SAS、または Microsoft Entra ID) を検討します。 詳細については、「Azure Storage でデータへのアクセスを承認する」を参照してください。
BLOB ストレージを抽象化する API。 使用する API を検討します。 通常、BLOB ストレージにアクセスするアプリケーションは、いずれかの SDK を介してアプリケーション内の API を使用します。これにより、Kubernetes クラスターから BLOB ストレージとの対話が抽象化されます。 さまざまなプログラミング言語のライブラリの詳細については、「 Azure Blob Storage の概要」を参照してください。
静的または動的に作成された BLOB ストレージ。 AKS の外部で作成する静的 BLOB ストレージ コンテナー、または AKS がユーザーに代わって動的に作成する BLOB ストレージ コンテナーの使用を検討してください。 詳細については、以下を参照してください。
記憶域にアクセスするためのドライバー。 アプリケーションが BLOB ストレージにアクセスする方法を検討します。 ファイル システムとしてアクセスするには、Kubernetes の BLOB CSI ドライバー を使用できます。 このドライバーを使用すると、 NFSv3 プロトコル または ヒューズ ドライバーを介して BLOB ストレージにアクセスできます。
その他のストレージ ソリューション
Azure には、Kubernetes と統合できる複数の特殊なストレージ ソリューションがあります。 この記事では、これらの特殊なストレージ ソリューションについては説明しませんが、次の一覧で考えられる解決策を示します。
Azure HPC キャッシュ。 HPC Cache を使用すると、ハイ パフォーマンス コンピューティング (HPC) タスクのためにデータへのアクセスを高速化できます。 Azure HPC Cache で Azure 内のファイルをキャッシュすることで、クラウド コンピューティングのスケーラビリティを既存のワークフローでも実現します。 詳細については、「 Azure HPC Cache と Azure Kubernetes Service の統合」を参照してください。
Azure Data Lake Storage Gen2。 Data Lake Storage Gen2 は、Hadoop や Spark などのビッグ データ ワークロード用に最適化された特殊な種類の BLOB ストレージです。 詳細については、「Azure Data Lake Storage Gen2の概要」を参照してください。
設計に関する推奨事項
このセクションでは、Azure のお客様に有効な推奨事項を示します。
Azure Private Link を使用します。 セキュリティのために、Azure Private Link をサポートするすべてのストレージ ソリューションに使用することをお勧めします。 Azure Private Link を使用すると、Azure Storage や SQL Database などの Azure サービスや、仮想ネットワーク内のプライベート エンドポイント経由で Azure でホストされるサービスにアクセスできます。 詳細については、「Azure Private Link とは」を参照してください。
OS にはエフェメラル ディスクを使用します。 OS ディスクの場合は、エフェメラル ディスクを使用することをお勧めします。 この機能を利用するには、適切なサイズの一時ディスクを持つ VM サイズを選択します。 詳細については、 Azure VM のエフェメラル OS ディスクに関するページを参照してください。
マネージド データベースを使用します。 アプリケーション データの場合は、マネージド データベースを使用することをお勧めします。 データベース オプションの一覧については、「 Azure 上のデータベースの種類」を参照してください。
次のセクションでは、Azure ディスク、Azure Files、BLOB ストレージに関するその他の推奨事項について説明します。
Azure Container Storage を使用する
次のセクションには、AKS で Azure Container Storage を使用するための推奨事項が含まれています。
Azure Container Storage の要件
- AKS クラスターの前提条件: ノード プールに少なくとも 3 つの仮想マシンを含む AKS クラスターをデプロイします。それぞれに少なくとも 4 つの vCPU があります。
- アクセス モードの制限事項: Azure Container Storage では ReadWriteOnce アクセス モードのみがサポートされます。 ReadWriteMany アクセスを必要とするワークロードの場合は、代わりに Azure Files を使用してください。 アクセス モードの詳細については、 Kubernetes のドキュメントを参照してください。
適切な Azure Container Storage の種類を選択する
Azure ディスク: 階層 1 と、MySQL、MongoDB、PostgreSQL などの汎用データベースに使用します。 UltraSSD_LRSまたはPremiumV2_LRS ディスクを使用する場合は、 IOPSReadWrite パラメーターと MBpsReadWrite パラメーターを使用して、ストレージ プール定義でパフォーマンス パラメーター (IOPS とスループット) を直接指定します。 この方法により、Azure Container Storage によって、パフォーマンスニーズに最適なディスク リソースがプロビジョニングされます。
Azure エフェメラル ディスク: データ持続性の要件がない、または組み込みのアプリケーション レベルのデータ レプリケーション (Cassandra など) を使用して、超低待機時間 (サブミリ秒) を必要とするアプリケーションに最適です。 エフェメラル ディスク上のデータは、VM の再起動によって保持されません。 NVMe を使用する Azure Container Storage では、単一ノードの障害に対する回復性のためにボリューム レプリケーションがサポートされていますが、すべてのレプリカが同時に再起動するとデータが失われます。 特定のワークロードに対してこのリスクを慎重に評価します。 NVMe は、 ストレージ最適化 L ファミリ VM SKU で使用できます。
Azure Container Storage の回復性を構成する
Azure Container Storage を使用して回復性を設計する場合は、高可用性のために次のいずれかの方法を選択します。
| 回復性のアプローチ | 説明 | 適しているケース: |
|---|---|---|
| ゾーン冗長ストレージ (ZRS) | ゾーンの障害から保護するために、2 つ以上の可用性ゾーン間でデータを自動的にレプリケートします。 | アプリケーション レベルのレプリケーションなしでゾーン レベルの障害からの自動データ保護を必要とするワークロード。 |
| マルチゾーン記憶域プール | 可用性ゾーン間でストレージ容量を均等に分散し、各ゾーンが独自の個別のストレージ リソースを維持します。 | 既に独自のデータ冗長性を管理しているアプリケーション レベルのレプリケーション (Cassandra など) を使用するワークロード。 |
注
ZRS とマルチゾーン の両方の記憶域プールは、異なるメカニズムを通じて同様の目的を果たすので、同時に使用することはできません。 選択した方法に関係なく、バックアップとディザスター リカバリー戦略の一部として通常の ボリューム スナップショット を実装します。
Azure ディスク
Azure ディスクの場合は、次の設計オプションをお勧めします。
Premium ディスクまたは Ultra ディスクを使用します。 ほとんどの場合、適切なパフォーマンスを確保するために、Premium ディスクまたは Ultra ディスクをお勧めします。 詳細については、「 Azure Disk Storage」を参照してください。
ディスクとスループットのノードのサイズを設定します。 Kubernetes ノードのサイズは、ディスクの数と合計スループットの量をサポートするのに十分な大きさにすることをお勧めします。 サイズと特性の詳細については、「 Azure の仮想マシンのサイズ」を参照してください。
永続ボリュームのスナップショットを作成します。 Azure Disks CSI ドライバーを使用して、永続ボリュームのスナップショットを取得してデータをバックアップするか、ボリュームを以前の状態に復元します。 詳細については、「 ボリューム スナップショット」を参照してください。
ディスク間でのディスク ストライピングを回避します。 Kubernetes の複数のディスク間でストライピングを行わないようにすることをお勧めします。
PV/PVC を使用します。 Kubernetes で PV と PVC を使用して、必要に応じてディスクを動的に作成することをお勧めします。 永続ストレージの詳細については、「 Azure Kubernetes Service (AKS) のアプリケーションのストレージ オプション」を参照してください。
Azure Files
Azure Files の場合は、次の設計オプションをお勧めします。
[Premium] を選択します。 パフォーマンスが重要な場合は、Premium レベルを使用することをお勧めします。
専用ストレージ アカウントを作成します。 ファイル共有用の専用ストレージ アカウントを提供することをお勧めします。
静的または動的に作成されたファイル共有を選択します。 AKS でファイル共有を作成するか、Kubernetes の外部で静的に作成するかを慎重に検討することをお勧めします。 動的に作成されたストレージは、動的に削除することもできます。 AKS でファイル共有を動的に作成する方法の詳細については、「 Azure Files で永続ボリュームを動的に作成して使用する」を参照してください。
Azure NetApp ファイルズ
Azure NetApp Files の場合は、次の設計オプションをお勧めします。
アプリケーションの要件に基づいてパフォーマンスレベルを選択します。 Azure NetApp Files には、さまざまなクラスのパフォーマンスを提供する 3 つのパフォーマンス レベルが用意されています。 詳細については、「Azure NetApp Files のパフォーマンスに関する考慮事項」を参照してください。
AKS クラスターと同じ Azure リージョンに容量プールを作成します。 詳細については、「 Azure NetApp Files の容量プールを作成する」を参照してください。
容量プールには自動 QoS タイプを使用します。
ネットワークを計画します。 ネットワーク設計には、次の 2 つのオプションがあります。
- AKS と Azure NetApp Files に同じ仮想ネットワークを使用する場合は、Azure NetApp Files 用の専用サブネットを作成し、 そのサブネットを Microsoft.NetApp/Volumes に委任します。
- 異なる VNet を使用する場合は、それらの間に仮想ネットワーク ピアリングを確立します。
ブロブストレージ
BLOB ストレージの場合は、次の設計オプションをお勧めします。
SDK を使用してストレージとインターフェイスします。 アプリケーション レベルの SDK を使用して BLOB ストレージとインターフェイスすることをお勧めします。
ストレージとインターフェイスするには、NFS で CSI を使用します。 アプリケーション レベルの SDK を使用して BLOB ストレージとインターフェイスできない場合は、BLOB CSI ドライバーで NFS v3 オプションを使用することをお勧めします。 詳細については、「 Azure Blob Storage Container Storage Interface (CSI) ドライバーの使用」を参照してください。
アクセスには Microsoft Entra ID を使用します。 Blob Storage へのアクセスを承認するには、Microsoft Entra ID を使用することをお勧めします。 共有ストレージ アカウント キーの使用は避けてください。 詳しくは、Microsoft Entra ID を使用した BLOB へのアクセスの認可に関する記事をご覧ください。
レベルを調整します。 アクセス頻度の低いデータをより低いアクセス層に移動するには、ライフサイクル管理ポリシーを使用することをお勧めします。 詳細については、「 BLOB データのホット、クール、アーカイブアクセス層」を参照してください。
次のステップ
Kubecost を使用して、AKS のデプロイ、サービス、ラベル、ポッド、または名前空間にコスト割り当てのスコープを設定する方法について説明します。