翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

[Storage (ストレージ)]

概要

短期または長期でデータを保存する必要があるアプリケーションを実行するシナリオがあります。このようなユースケースでは、ポッドによってボリュームを定義およびマウントして、コンテナが異なるストレージメカニズムを利用できるようにします。Kubernetes は、エフェメラルストレージと永続ストレージのさまざまなタイプのボリュームをサポートしています。ストレージの選択は、アプリケーションの要件に大きく依存します。各アプローチにはコストへの影響があり、以下に説明するプラクティスは、EKS 環境で何らかの形式のストレージを必要とするワークロードのコスト効率を実現するのに役立ちます。

エフェメラルボリューム

エフェメラルボリュームは、一時的なローカルボリュームを必要とするが、再起動後にデータを保持する必要がないアプリケーション用です。これには、スクラッチスペース、キャッシュ、設定データやシークレットなどの読み取り専用入力データの要件が含まれます。Kubernetes エフェメラルボリュームの詳細については、こちらを参照してください。ほとんどのエフェメラルボリューム (例: emptyDir、configMap、downwardAPI、シークレット、ホストパス) は、ローカルにアタッチされた書き込み可能デバイス (通常はルートディスク) または RAM によってバックアップされるため、最もコスト効率が高くパフォーマンスの高いホストボリュームを選択することが重要です。

EBS ボリュームの使用

ホストルートボリュームとして gp3 から開始することをお勧めします。これは Amazon EBS が提供する最新の汎用 SSD ボリュームであり、gp2 ボリュームと比較して GB あたり低価格 (最大 20%) を提供します。

Amazon EC2 インスタンスストアの使用

Amazon EC2 インスタンスストアは、EC2 インスタンスに一時的なブロックレベルのストレージを提供します。EC2 インスタンスストアが提供するストレージは、ホストに物理的にアタッチされたディスクからアクセスできます。Amazon EBS とは異なり、インスタンスストアボリュームはインスタンスの起動時にのみアタッチでき、これらのボリュームはインスタンスの存続期間中にのみ存在します。他のインスタンスにデタッチおよび再アタッチすることはできません。Amazon EC2 インスタンスストアの詳細については、こちらを参照してください。インスタンスストアボリュームには追加料金はかかりません。これにより、EBS ボリュームが大きい一般的な EC2 インスタンスよりもコスト効率が高くなります (インスタンスストアボリューム）。

Kubernetes でローカルストアボリュームを使用するには、Amazon EC2 ユーザーデータを使用してディスクをパーティション化、設定、フォーマットし、ポッド仕様でボリュームを HostPath としてマウントできるようにする必要があります。または、Local Persistent Volume Static Provisioner を活用して、ローカルストレージ管理を簡素化することもできます。Local Persistent Volume 静的プロビジョナーを使用すると、標準の Kubernetes PersistentVolumeClaim (PVC) インターフェイスを介してローカルインスタンスストアボリュームにアクセスできます。さらに、ノードアフィニティ情報を含む PersistentVolumes (PVs) をプロビジョニングして、Pod を正しいノードにスケジュールします。Kubernetes PersistentVolumes を使用していますが、EC2 インスタンスストアボリュームは本質的にエフェメラルです。エフェメラルディスクに書き込まれたデータは、インスタンスの存続期間中にのみ使用できます。インスタンスが終了すると、 もデータになります。詳細については、このブログを参照してください。

Amazon EC2 インスタンスストアボリュームを使用する場合、合計 IOPS 制限はホストと共有され、ポッドを特定のホストにバインドすることに注意してください。Amazon EC2 インスタンスストアボリュームを採用する前に、ワークロードの要件を徹底的に確認する必要があります。

永続ボリューム

Kubernetes は通常、実行中のステートレスアプリケーションに関連付けられます。ただし、1 つのリクエストから次のリクエストまで永続的なデータや情報を保持する必要があるマイクロサービスを実行するシナリオがあります。データベースは、このようなユースケースの一般的な例です。ただし、ポッドとその中のコンテナまたはプロセスは、本質的にエフェメラルです。Pod の存続期間を超えてデータを保持するには、PVs を使用して、Pod から独立した特定の場所にあるストレージへのアクセスを定義できます。PVs に関連するコストは、使用されているストレージのタイプとアプリケーションによる消費方法に大きく依存します。

Amazon EKS の Kubernetes PVs をサポートするストレージオプションには、さまざまなタイプがあります。以下に説明するストレージオプションは、Amazon EBS、Amazon EFS、Amazon FSx for Lustre、Amazon FSx for NetApp ONTAP です。

Amazon Elastic Block Store (EBS) ボリューム

Amazon EBS ボリュームは、Kubernetes PVs として使用して、ブロックレベルのストレージボリュームを提供できます。これらは、ランダムな読み取りと書き込みに依存するデータベースや、長時間の継続的な読み取りと書き込みを実行するスループットを多用するアプリケーションに適しています。Amazon Elastic Block Store Container Storage Interface (CSI) ドライバーを使用すると、Amazon EKS クラスターは永続的ボリュームの Amazon EBS ボリュームのライフサイクルを管理できます。Container Storage Interface は、Kubernetes とストレージシステム間のインタラクションを有効にし、容易にします。CSI ドライバーを EKS クラスターにデプロイすると、永続ボリューム (PVs)、永続ボリュームクレーム (PVCs)、ストレージクラス (SCs) などのネイティブ Kubernetes ストレージリソースを介してその機能にアクセスできます。このリンクでは、Amazon EBS ボリュームを Amazon EBS CSI ドライバーとやり取りする方法の実例を示します。

適切なボリュームの選択

価格とパフォーマンスの適切なバランスを実現するため、最新世代のブロックストレージ (gp3) を使用することをお勧めします。また、追加のブロックストレージ容量をプロビジョニングすることなく、ボリュームサイズに関係なくボリューム IOPS とスループットをスケールすることもできます。現在 gp2 ボリュームを使用している場合は、gp3 ボリュームへの移行を強くお勧めします。ブログ記事「Amazon EKS クラスターを gp2 から gp3 EBS ボリュームに移行する」では、アプリケーションのダウンタイムを必要とする CSI ボリュームスナップショット機能を使用して、バックアップと復元を使用して Amazon EKS クラスターの gp3 上の gp2 から移行する方法について説明します。

Amazon EBS では、ボリュームサイズ、IOPS、スループットなどのボリューム特性をオンラインで変更できます。この機能を使用すると、このブログで説明されているように、EBS CSI ドライバー v1.19.0 以降を必要とする PVC 注釈を使用するか、ここで説明されている VolumeAttributesClass API を使用して Amazon EKS v1.31 および EBS CSI ドライバー 1.35 から始めることで、アプリケーションのダウンタイムなしで gp3 上の gp2 から移行できます。

1 つの gp3 ボリュームがサポートできる以上のパフォーマンスとボリュームを必要とするアプリケーションがある場合は、io2 ブロックエクスプレスの使用を検討する必要があります。このタイプのストレージは、SAP HANA や低レイテンシー要件の他の大規模なデータベースなど、最大、最も I/O 負荷の高いミッションクリティカルなデプロイに最適です。インスタンスの EBS パフォーマンスはインスタンスのパフォーマンス制限によって制限されるため、すべてのインスタンスが io2 Block Express ボリュームをサポートしているわけではありません。このドキュメントでは、サポートされているインスタンスタイプやその他の考慮事項を確認できます。

単一の gp3 ボリュームは、最大 16,000 IOPS、最大スループット 1,000 MiB/秒、最大 16TiB をサポートできます。最大 256,000 IOPS、4,000 MiB/秒、スループット、64TiB を提供する最新世代のプロビジョンド IOPS SSD ボリューム。

これらのオプションのうち、ストレージのパフォーマンスとコストをアプリケーションのニーズに最も合わせる必要があります。

時間の経過に伴うモニタリングと最適化

アプリケーションのベースラインパフォーマンスを理解し、選択したボリュームを監視して、それが要件/期待を満たしているかどうか、または過剰にプロビジョニングされているかどうかを確認することが重要です (プロビジョニングされた IOPS が完全に活用されていないシナリオなど）。

最初から大量のボリュームを割り当てる代わりに、データを蓄積するにつれてボリュームのサイズを徐々に増やすことができます。Amazon Elastic Block Store CSI ドライバー (aws-ebs-csi-driver) のボリュームサイズ変更機能を使用して、ボリュームのサイズを動的に変更できます。EBS ボリュームサイズは増やすことしかできないことに注意してください。

ダングリング EBS ボリュームを特定して削除するには、AWS の信頼されたアドバイザーのコスト最適化カテゴリを使用できます。この機能は、アタッチされていないボリュームや、一定期間の書き込みアクティビティが非常に少ないボリュームを特定するのに役立ちます。ライブ Kubernetes クラスターをスキャンし、デプロイされたリソースと設定に関する潜在的な問題をレポートする、Popeye と呼ばれるクラウドネイティブのオープンソースの読み取り専用ツールがあります。たとえば、未使用の PVs と PVCs をスキャンして、それらがバインドされているかどうか、またはボリュームマウントエラーがあるかどうかを確認できます。

モニタリングの詳細については、EKS コスト最適化オブザーバビリティガイドを参照してください。

考慮すべきもう 1 つのオプションは、AWS Compute Optimizer Amazon EBS ボリュームのレコメンデーションです。このツールは、最適なボリューム設定と必要な適切なパフォーマンスレベルを自動的に特定します。例えば、過去 14 日間の最大使用率に基づいて、プロビジョニングされた IOPS、ボリュームサイズ、EBS ボリュームのタイプに関する最適な設定に使用できます。また、レコメンデーションから得られる月間コスト削減の可能性も定量化します。詳細については、このブログを参照してください。

バックアップの保持ポリシー

point-in-timeスナップショットを作成することで、Amazon EBS ボリュームのデータをバックアップできます。Amazon EBS CSI ドライバーはボリュームスナップショットをサポートします。ここで説明するステップを使用して、スナップショットを作成し、EBS PV を復元する方法について説明しますhttps://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/examples/kubernetes/snapshot/README.md。

後続のスナップショットは増分バックアップです。つまり、最新のスナップショットの後に変更されたデバイスのブロックのみが保存されます。これにより、スナップショットを作成するのに要する時間が最小限に抑えられ、データを複製しないことで、ストレージコストが節約されます。ただし、適切な保持ポリシーなしで古い EBS スナップショットの数を増やすと、大規模な運用時に予期しないコストが発生する可能性があります。AWS API を使用して Amazon EBS ボリュームを直接バックアップする場合は、Amazon Elastic Block Store (EBS) スナップショットと EBS-backed Amazon マシンイメージ (AMIs) 用の自動化されたポリシーベースのライフサイクル管理ソリューションを提供する Amazon Data Lifecycle Manager (DLM) を活用できます。コンソールを使用すると、EBS スナップショットと AMIs。

Kubernetes 環境では、Velero というオープンソースツールを使用して EBS 永続ボリュームをバックアップできます。バックアップの有効期限が切れるようにジョブをスケジュールするときに TTL フラグを設定できます。以下は、例として Velero からのガイドです。

Amazon Elastic File System (EFS)

Amazon Elastic File System (EFS) は、サーバーレスで完全に伸縮自在なファイルシステムです。標準のファイルシステムインターフェイスとファイルシステムのセマンティクスを使用してファイルデータを共有し、幅広いワークロードやアプリケーションに対応します。ワークロードやアプリケーションの例としては、Wordpress や Drupal、JIRA や Git などの開発者ツール、Jupyter などの共有ノートブックシステム、ホームディレクトリなどがあります。

Amazon EFS の主な利点の 1 つは、複数のノードと複数のアベイラビリティーゾーンにまたがる複数のコンテナにマウントできることです。もう 1 つの利点は、使用したストレージに対してのみ料金を支払うことです。EFS ファイルシステムは、ファイルを追加および削除すると自動的に拡張および縮小されるため、容量計画が不要になります。

Kubernetes で Amazon EFS を使用するには、Amazon Elastic File System Container Storage Interface (CSI) ドライバー、aws-efs-csi-driver を使用する必要があります。現在、ドライバーはアクセスポイントを動的に作成できます。ただし、Amazon EFS ファイルシステムを最初にプロビジョニングし、Kubernetes ストレージクラスパラメータへの入力として提供する必要があります。

適切な EFS ストレージクラスの選択

Amazon EFS には 4 つのストレージクラスがあります。

2 つの標準ストレージクラス：

2 つの 1 ゾーンストレージクラス：

低頻度アクセス (IA) ストレージクラスは、毎日アクセスされないファイルに対してコスト最適化されています。Amazon EFS ライフサイクル管理を使用すると、ライフサイクルポリシーの期間 (7、14、30、60、または 90 日間) アクセスされなかったファイルを IA ストレージクラスに移動できます。これにより、EFS 標準ストレージクラスと EFS 1 ゾーンストレージクラスと比較して、ストレージコストがそれぞれ最大 92% EFS 削減されます。

EFS Intelligent-Tiering を使用すると、ライフサイクル管理はファイルシステムのアクセスパターンを監視し、ファイルを最適なストレージクラスに自動的に移動します。

Amazon FSx for Lustre

Lustre は、最大数百 GB/秒のスループットとオペレーションごとのミリ秒未満のレイテンシーを必要とするワークロードで一般的に使用される高性能の並列ファイルシステムです。これは、機械学習トレーニング、財務モデリング、HPC、ビデオ処理などのシナリオに使用されます。Amazon FSx for Lustre は、スケーラビリティとパフォーマンスを備えたフルマネージド共有ストレージを提供し、Amazon S3 とシームレスに統合されています。

Amazon EKS の FSx for Lustre CSI ドライバーまたは AWS のセルフマネージド Kubernetes クラスターを使用して、FSx for Lustre でバックアップされた Kubernetes 永続ストレージボリュームを使用できます。詳細と例については、Amazon EKS ドキュメントを参照してください。

Amazon S3 へのリンク

Amazon S3 に存在する耐久性の高い長期データリポジトリを FSx for Lustre ファイルシステムにリンクすることをお勧めします。リンクされると、大きなデータセットは必要に応じて Amazon S3 から FSx for Lustre ファイルシステムに遅延ロードされます。分析と結果を S3 に戻し、Lustre ファイルシステムを削除することもできます。

適切なデプロイとストレージオプションの選択

FSx for Lustre にはさまざまなデプロイオプションがあります。最初のオプションはスクラッチと呼ばれ、データはレプリケートされません。2 番目のオプションは永続と呼ばれ、名前が示すように、データは保持されます。

最初のオプション (スクラッチ) を使用して、一時的な短期データ処理のコストを削減できます。永続デプロイオプションは、AWS アベイラビリティーゾーン内のデータを自動的にレプリケートする長期ストレージ用に設計されています。また、SSD ストレージと HDD ストレージの両方をサポートしています。

必要なデプロイタイプは、FSx for lustre ファイルシステムの Kubernetes StorageClass のパラメータで設定できます。サンプルテンプレートを提供するリンクを次に示します。

データ圧縮を有効にする

また、「LZ4」をデータ圧縮タイプとして指定することで、ファイルシステムでデータ圧縮を有効にすることもできます。有効にすると、新しく書き込まれたすべてのファイルは、ディスクに書き込まれる前に FSx for Lustre で自動的に圧縮され、読み取り時に解凍されます。LZ4 データ圧縮アルゴリズムは可逆であるため、元のデータは圧縮されたデータから完全に再構築できます。

データ圧縮タイプは、FSx for lustre ファイルシステムの Kubernetes StorageClass のパラメータで LZ4 として設定できます。値がデフォルトで NONE に設定されている場合、圧縮は無効になります。このリンクにはサンプルテンプレートが用意されています。

Amazon FSx for NetApp ONTAP

Amazon FSx for NetApp ONTAP は、NetApp の ONTAP ファイルシステム上に構築されたフルマネージド共有ストレージです。FSx for ONTAP は、AWS またはオンプレミスで実行されている Linux、Windows、macOS コンピューティングインスタンスから幅広くアクセスできる、機能豊富で高速、柔軟な共有ファイルストレージを提供します。

Amazon FSx for NetApp ONTAP は、1/プライマリ階層と 2/キャパシティプール階層の 2 つのストレージ階層をサポートしています。

プライマリ階層は、アクティブでレイテンシーの影響を受けやすいデータ用のプロビジョニングされた高性能 SSD ベースの階層です。完全に伸縮自在なキャパシティプール階層は、アクセス頻度の低いデータに対してコスト最適化されており、データが階層化されると自動的にスケールされ、事実上無制限のペタバイトの容量を提供します。キャパシティープールストレージでデータ圧縮と重複排除を有効にして、データが消費するストレージ容量をさらに削減できます。NetApp のポリシーベースのネイティブ FabricPool 機能は、データアクセスパターンを継続的にモニタリングし、ストレージ層間で双方向にデータを自動的に転送して、パフォーマンスとコストを最適化します。

NetApp の Astra Trident は、CSI ドライバーを使用して動的ストレージオーケストレーションを提供します。これにより、Amazon EKS クラスターは、Amazon FSx for NetApp ONTAP ファイルシステムによってバックアップされた永続ボリューム PVs のライフサイクルを管理できます。開始するには、Astra Trident ドキュメントの「Amazon FSx for NetApp ONTAP で Astra Trident を使用」を参照してください。

その他の考慮事項

コンテナイメージのサイズを最小限に抑える

コンテナがデプロイされると、コンテナイメージは複数のレイヤーとしてホストにキャッシュされます。イメージのサイズを減らすことで、ホストに必要なストレージの量を減らすことができます。

最初からスクラッチイメージやディストリビューションコンテナイメージ (アプリケーションとそのランタイム依存関係のみを含む) などのスラムダウンされたベースイメージを使用することで、攻撃領域の削減やイメージのプル時間の短縮など、その他の補助的な利点に加えて、ストレージコストを削減できます。

また、最小限のイメージを作成する簡単で安全な方法を提供する Slim.ai などのオープンソースツールの使用も検討する必要があります。

パッケージ、ツール、アプリケーションの依存関係、ライブラリの複数のレイヤーは、コンテナイメージサイズを簡単に肥大化できます。マルチステージビルドを使用すると、あるステージから別のステージにアーティファクトを選択的にコピーでき、最終イメージから不要なものをすべて除外できます。イメージ構築のベストプラクティスについては、こちらを参照してください。

もう 1 つの考慮事項は、キャッシュされたイメージを保持する期間です。一定量のディスクが使用されているときに、古いイメージをイメージキャッシュからクリーンアップできます。これにより、ホストのオペレーションに十分なスペースを確保できます。デフォルトでは、kubelet は未使用のイメージのガベージコレクションを 5 分ごとに、未使用のコンテナのガベージコレクションを 1 分ごとに実行します。

未使用のコンテナとイメージガベージコレクションのオプションを設定するには、設定ファイルを使用して kubelet を調整し、KubeletConfigurationリソースタイプを使用してガベージコレクションに関連するパラメータを変更します。

詳細については、Kubernetes ドキュメントを参照してください。