Azure Kubernetes Service (AKS) の Azure Storage に関する考慮事項

  • [アーティクル]

特定のアプリケーション ワークロードを実行するために、組織または企業は適切な Azure Kubernetes Service (AKS) プラットフォーム レベルの機能を設計する必要があります。 これらのワークロードのストレージ要件は、おそらく異なるでしょう。 アプリケーションに適したストレージ ソリューションを選択する際には、パフォーマンス、可用性、回復性、セキュリティ、およびコストなど、複数の考慮事項をふまえる必要があります。 この記事の目的は、ワークロードに適した 1 つのオプション、またはオプションの組み合わせを選択できるようにガイドすることです。

Kubernetes では、ステートレス ワークロードとステートフル ワークロードの両方を実行できます。 ステートフル ワークロードでは、多くの場合、状態を保存するためのストレージ ソリューションが必要です。 AKS では、マネージド データベース、ディスク (またはブロック)、ファイルと BLOB (またはオブジェクト) ストレージなど、ネイティブ ストレージ用の複数の統合オプションがサポートされています。 これらの各オプションごとに提供される SKU、サイズ、およびパフォーマンス特性はさまざまです。 適切なオプションを選択するためには、慎重な検討が必要です。

この記事では、「適切なストレージ サービスを選択する」および「設計上の考慮事項」で考慮する必要がある要因とオプションについて説明します。 また、「設計上の推奨事項」で具体的な推奨事項を説明しています。

適切なストレージ サービスを選択する

最初のデプロイに適した SKU とサイズを選択するには、いくつかの評価と、場合によっては概念実証またはテスト環境が必要です。 以下は、AKS 用ストレージを使い始める際に役立つ、大まかなガイドラインをまとめたものです。

  • 構造化データ. プラットフォーム上で利用可能なマネージド データベース (たとえば、Azure SQL) に保存される、アプリケーションの構造化データについては、マネージド データベースを使用することをお勧めします。

  • 非構造化データ. 写真、ビデオ、テキスト ドキュメントなどの非構造化データには、BLOB ストレージを使用します。 BLOB は、ネットワーク ファイル システム (NFS) 経由でファイルとしてマウントされる BLOB を使用するか、BlobFuse を使用して仮想ファイル システムとしてアクセスすることで利用可能です。 また、アプリケーションから BLOB ストレージに直接読み書きすることもできます。

  • 共有アプリケーション データ。 高パフォーマンスを必要とする共有アプリケーション データの場合は、Azure NetApp Files または premium レベルの Azure Files を使用します。 限定的なパフォーマンスしか必要としない共有構成データには、Azure Files の standard レベルを使用します。

  • アプリケーションとストレージの要求に必要な帯域幅。 アプリケーション要求とストレージ要求の両方を処理するのに十分なネットワーク帯域幅がノードにあることを確認します。 ストレージのトラフィックは、転送用のプロトコルがサーバー メッセージ ブロック (SMB) であっても NFS であっても、ネットワーク スタックを経由します。

  • 低遅延、高 IOPS。 アプリケーションのメッセージング アプリケーション用に一貫した低遅延が必要で、Kubernetes 上で独自のデータベースを実行するために高い 1 秒あたりの必要な入出力 (I/O) 操作 (IOPS) と高いスループットを必要とする場合は、ストレージにディスクを使用します。 最高のパフォーマンスを得るには、Azure Premium SSD、Azure Premium SSD v2、または Azure Ultra Disk Storage の利用を検討してください。

設計上の考慮事項

以下は、AKS のストレージを設計する際の考慮事項です。 AKS 環境のどこにストレージが必要かを検討し、それぞれの要件に最適なソリューションを決定してください。

オペレーティング システム (OS) ディスク

オペレーティング システム (OS) ディスクの場合は、次の要因を考慮してください。

  • OS のエフェメラル ディスク。 Azure の各仮想マシン (VM) には、その OS 用のディスクが必要です。 Kubernetes ノードはエフェメラルであるため、サポートされている VM サイズでは、AKS にはデフォルトでエフェメラル 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) の Container Storage Interface (CSI) ドライバー」を参照してください。

ファイルベースのソリューション

ポッド間でファイル システムを共有する必要があるかどうかを検討します。 共有ファイル システムは、Kubernetes クラスター内の複数のポッドによって読み取られ、共有されるアプリケーションおよび構成データに最適です。 ファイル ストレージは、NFS または SMB/Common Internet File System (CIFS) を介して共有ファイル システムを公開します。 Azure には、Azure Files と Azure NetApp Files という、ファイル ベースのストレージ用のソリューションが 2 つあります。

Azure Files

Azure Files の場合は、次のオプションを検討してください。

  • 静的または動的に作成されたファイル共有。 AKS の外部で作成された静的ファイル共有を使用するか、AKS に動的にファイル共有を作成させるかを検討します。 詳細については、次を参照してください。

  • Standard または Premium のパフォーマンス。 Standard パフォーマンスで十分か、または Azure Files の Premium パフォーマンスが必要かどうかを評価します。

  • SMB/CIFS または NFS。 Azure Files にアクセスするには、ワークロードで既定のプロトコル (SMB/CIFS) に API を使用する必要があるかどうか、またはワークロードで NFS サポートが必要かどうかを評価します。

  • アクセス用のネットワーク モデル。 直接パブリック IP アドレス、サービス エンドポイント、またはプライベート リンクを介したアクセスなど、Azure Files へのアクセスに使用するネットワーク モデルを検討してください。

Azure NetApp Files

Azure NetApp Files の場合は、次のオプションを検討してください。

BLOB ストレージ

アプリケーションで格納する必要がある非構造化データの量について検討します。 Azure Blob Storage には、HTTP API または SDK を介してアクセスできます。 BLOB ストレージをファイル システムとしてコンテナーまたはポッドにマウントすることは、ログ ファイル、画像、ドキュメント、ストリーミング メディア、ディザスターリカバリー データなど、大量の非構造化データを含むアプリケーション ワークロードに最適です。

  • データの冗長性。 どのデータ冗長性がアプリケーションに適しているかを検討します。 詳細については、「Azure Storage の冗長性」を参照してください。 データの冗長性は、ストレージ アカウントのレベルで選択します。

  • パフォーマンス レベル。 アプリケーションに必要な BLOB ストレージのパフォーマンス レベルを検討します。 詳細については、BLOB データのホット、クール、アーカイブ アクセス層に関するページを参照してください。

  • アクセスの認証方法。 アプリケーションから Blob Storage へのアクセスに使用する認証方法 (ストレージ キー、SAS、または Microsoft Entra ID) を検討します。 詳細については、「Azure Storage でデータへのアクセスを承認する」を参照してください。

  • BLOB ストレージを抽象化するための API。 どの API を使用するかを検討します。 通常、BLOB ストレージにアクセスするアプリケーションでは、SDK のいずれかにある、Kubernetes クラスターから BLOB ストレージとの対話を抽象化するアプリケーションの API を使用します。 さまざまなプログラミング言語のライブラリの詳細については、「Azure Blob Storage の概要」を参照してください。

  • 静的または動的に作成された BLOB ストレージ。 AKS の外部で作成された静的 BLOB ストレージ コンテナーを使用するか、AKS で動的に BLOB ストレージ コンテナーを作成させｒるかを検討します。 詳細については、次を参照してください。

  • ストレージにアクセスするためのドライバー。 アプリケーションから BLOB ストレージへのアクセスに使用する方法を検討します。 ファイル システムとしてアクセスする場合は、Kubernetes の BLOB CSI ドライバーを使用できます。 このドライバーを使用すると、NFSv3 プロトコルまたはヒューズ ドライバーを介して BLOB ストレージにアクセスできます。

その他のストレージ ソリューション

アプリケーションでこの記事に記載されていないものが必要な場合は、他の種類のストレージを検討してください。 Azure には、Kubernetes と統合できる複数の特殊なストレージ ソリューションがあります。 この記事ではカバーされていませんが、次の一覧から考えられる解決策をご確認ください。

  • Azure HPC Cache。 ハイパフォーマンス コンピューティング (HPC) タスク用に、HPC Cache を使用してデータへのアクセスを高速化できます。 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 ディスク

Azure ディスクの場合は、次の設計オプションをお勧めします。

  • Premium または Ultra Disk を使用する。 ほとんどの場合、適切なパフォーマンスを確保するために Premium ディスクまたは Ultra ディスクをお勧めします。 詳細については、Azure Blob 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 Files

Azure NetApp Files の場合、次の設計オプションをお勧めします。

  • アプリケーションの要件に基づいて、パフォーマンス レベルを選びます。 Azure NetApp Files には、さまざまなパフォーマンス クラスを提供する 3 つのパフォーマンス レベルが用意されています。 詳細については、「Azure NetApp Files のパフォーマンスに関する考慮事項」を参照してください。

  • AKS クラスターと同じ Azure リージョンに、容量プールを作成します。 詳しくは、「Azure NetApp Files 用の容量プールを作成する」をご覧ください。

  • 容量プールには、自動 QoS の種類を使います。

  • ネットワークを計画する。 ネットワークの設計には、次の 2 つのオプションがあります。

    1. AKS と Azure NetApp Files に同じ VNet を使う場合は、Azure NetApp Files に専用のサブネットを作成し、Microsoft.NetApp/Volumes にそのサブネットをデリゲートします。
    2. 異なる VNet を使う場合は、それらの間に VNet ピアリングを確立します。

BLOB ストレージ

BLOB ストレージの場合は、次の設計オプションをお勧めします。

  • ストレージとのインターフェイスに SDK を使用する。 BLOB ストレージとのインターフェイスには、アプリケーションレベルの SDK を使用することをお勧めします。

  • ストレージとのインターフェイスに NFS CSI を使用する。 BLOB ストレージとのインターフェイスにアプリケーションレベルの SDK を使用できない場合は、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 のデプロイ、サービス、ラベル、ポッド、または名前空間にコスト割り当ての範囲を設定する方法について説明します。

Kubecost を使用したコスト ガバナンス