Amazon Web Services ブログ
コンテナストレージに Amazon EFS を使用するためのベストプラクティス
数万社におよぶ企業がペタバイト規模のデータを Amazon Elastic File System (Amazon EFS) に保存しており、その多くが EFS を使ってコンテナ化したアプリケーションのデータです。Amazon EFS ファイルシステムは、Amazon Elastic Container Service (ECS) と Elastic Kubernetes Service (EKS) の両方で起動したコンテナに接続できます。Amazon EFS はコンテナインフラストラクチャと同様に、データの追加や削除の際に設定が簡単でかつ柔軟なスケーリングが可能な完全マネージド型のサービスであるため、コンテナストレージにうってつけの選択肢です。さらに、ペタバイト級のデータだけでなく、1 秒あたりのギガバイトの総スループットや数千の IOPS にも拡張が可能です。このブログでは、コンテナ化したアプリケーションで EFS を使用するためのベストプラクティスに関する、よくある質問をいくつかご紹介します。
コンテナには共有ストレージが必要ですか?
一般に、共有ファイルストレージは、障害に対する回復力が必要な長期にわたって実行するコンテナや、データを相互に共有する必要があるコンテナに適しています。よく目にする例をいくつか挙げましょう。
- WordPress や Drupal などのコンテンツ管理アプリケーションは、パフォーマンスと冗長性を確保するために複数のインスタンスにスケールアウトしたり、複数のインスタンス間でアップロード、プラグイン、テンプレートを共有することで利点を享受します。
- JIRA、Artifactory、Git などの開発者ツールでは高可用性を実現するためインスタンス間でデータを共有します。これは、永続性のために複数の AWS アベイラビリティゾーンに保持されているコードとアーティファクトを使って行われます。
- MXNet や Tensorflow のような機械学習フレームワークは、ファイルシステムインターフェイスを介してデータにアクセスする必要があります。永続的な共有ストレージを使用すると、複数のユーザーとジョブを同じデータセットで並行して実行できます。
- Jupyter や Jupyterhub などの共有ノートブックシステムには、ノートブックやユーザーワークスペース用の耐久性のあるストレージが必要です。共有ストレージを使用すれば、データサイエンティストの間で簡単に共同作業が行うことができます。
コンテナデータを永続化する別のオプションとしては、Amazon Elastic Block Storage (EBS) があります。これは MySQL、あるいは Kafka や Cassandra のような分散システムのデータベースなど、他のコンテナとデータを共有する必要がない場合に適していることがよくあります。
新しいファイルシステムを作成する、あるいは既存のファイルシステムを使用する必要がありますか?
たいていの場合、データを共有または保持する必要のある新しいアプリケーションごとに、新しいファイルシステムを作成することができます。こうすれば、1 つの場所でアプリケーションのすべてのデータを保護および管理できるためです。これには 2 つの例外があります。1 つ目はアプリケーションに必要なデータを含むファイルシステムが既に存在する場合で、新しいファイルシステムを作成する代わりに、その既存のファイルシステムをコンテナに接続するだけ済みます。2 つ目はコンテナが共有データの読み込みだけを必要とする場合で、ECS と EKS の両方でファイルシステムを読み込み専用としてマウントします。
ファイルシステムを共有するもう 1 つの理由に、規模があります。作成する各ファイルシステムは少なくとも 1 つのマウントターゲットをプロビジョニングし、Amazon Virtual Private Cloud (VPC) ごとに最大 400 個のマウントターゲットを作成できます。VPC に 400 個以上のアプリケーションがあり、それぞれが独自の共有ファイルストレージを必要とする場合、1 つのファイルシステムを複数の使用ディレクトリにパーティション分割します。アプリケーションが 400 個未満の場合でも、ファイルシステムのスループットは保存されているデータの総量に基づいているため、複数のコンテナ間でファイルシステムを共有する方が管理が簡単で、バーストモードのファイルシステムの総スループットが高くなる場合があります。これを行うには、ファイルシステムを作成したら、/myapplication1 や /myapplication2 などの一意のアプリケーションごとにディレクトリを作成します。ファイルシステムをコンテナにマウントする際にソースディレクトリを /myapplication1 として指定すると、コンテナはその場所にルートされ、他のアプリケーションのデータを表示できなくなります。セキュリティの観点から、アプリケーションを起動する管理者が信頼できる場合には、このソリューションは最適に機能します。管理者はデータを含むディレクトリのみに各アプリケーションをスコーピングする責任があるためです。
マウントターゲットはいくつ必要ですか?
ECS と EKS はどちらも、複数のアベイラビリティーゾーンでコンテナを起動します。アプリケーションがどこで起動されても EFS にアクセスできるようにするには、現在お住まいのリージョンのあらゆるアベイラビリティーゾーンに EFS マウントターゲットを作成することをお勧めします。EFS コンソールを使用してファイルシステムを作成する場合、これはデフォルトで行われます。ファイルシステムに追加のマウントターゲットを作成するのに、新たな追加料金は発生しません。
DNS の名前を使用してファイルシステムにコンテナを設定し、file-system-id.efs.aws-region.amazonaws.com の形式にすることをお勧めします。この DNS 名を使用すると、ルックアップはアプリケーションと同じアベイラビリティゾーンのマウントターゲットに自動的に解決するため、ネットワークのコストとパフォーマンスが最適化されます。ECS や EKS など、EFS とネイティブに統合するサービスとフレームワークでは、これを自動的に行います。
データを暗号化できますか?
転送中の EFS データと保存中のデータのどちらも暗号化できます。AWS または顧客のいづれかが管理するカスタマーマスターキー (CMK) を使って、ファイルシステムを作成するときに、保存データの暗号化を有効にすることができます。転送中のデータの暗号化は、接続ごとに設定されます。転送中のデータを暗号化するには、まず、使用しているコンテナホストに EFS マウントヘルパーがインストールされていることを確認し、「-o tls」オプションでマウントするように設定します。
どのパフォーマンスモードを選択すればいいですか?
EFS ファイルシステムには、汎用と最大 I/O の 2 つのパフォーマンスモードがあります。通常、汎用パフォーマンスモードは、コンテンツ管理システム、開発者ツール、データサイエンスノートブックなど、操作ごとのレイテンシーを短縮することから恩恵を受ける対話型アプリケーションに最も適しています。最大 I/O パフォーマンスモードのファイルシステムは、数百または数千のコンテナから並列操作を実行する分析や機械学習トレーニング、またはその他のワークロードに最適です。可能な限り最高の集約スループットと IOPS を探し、個々の操作のレイテンシーの影響を受けません。
Provisioned Throughput を使用する必要がありますか?
コンテナストレージに EFS を使用しているお客様は、エンドユーザーに一貫したサービスを受けていただくため、たいていは Provisioned Throughput を有効にしています。Bursting Throughput ファイルシステムのスループットは保存されているデータの量に基づくために、新しくプロビジョニングしたアプリケーションに対するスループットが十分に出ない場合があります。これを調整するには、エンドユーザーが必要とする正確なスループットで Provisioned Throughput を設定します。たとえば通常は、Jenkins ファイルシステムには 50~150 MiB/s の Provisioned Throughput で設定し、Nexus または Artifactory リポジトリファイルシステムには 512~1024 MiB/s で設定しています。
Provisioned Throughput の料金設定の良い点は、保存しているデータの量を考慮して、Bursting Throughput で受信したベースラインレートを超えるスループットの量に対してのみ支払うことができること、さらに、保存するデータ量がプロビジョニングしたものよりも高いスループットとなった場合には、2 つのうち高いスループットが提供される点です。たとえば、50 MiB/s の Provisioned Throughput でファイルシステムに Jenkins コンテナをプロビジョニングした場合、合計ストレージが 1 TiB に近づくにつれてスループットに対する支払いが徐々に少なくなります。Provisioned Throughput の支払いがなくなった後は、許可されたスループットはスライド制で保存した TiB あたり50 MiB/s に基づいて支払いが行われます。ストレージが 1 TiB を下回ってもスループットは 50 MiB/s 以下にはならないため、エンドユーザーは一貫したサービスを享受できます。
低頻度アクセスを使用してコストを削減できますか?
もちろんです。EFS 低頻度アクセス (IA) ストレージクラスは、EFS にデータを保存する料金を最大 92% 下げることができます。これを活用するには、ファイルシステムで Lifecycle Management を設定し、読み書きされていないファイルが IA に移行するまでの期間を指定します。この期間は最短で 14 日間、最長で 90 日間です。たとえば、Nexus や Artifactory などのアーティファクトリポジトリは、通常、最新のビルドアーティファクトのみ頻繁にアクセスされるため、データの 80% 以上を IA に移行できます。その結果、米国東部 (バージニア北部) (us-east-1) リージョンの料金に基づいた GB 月あたり 0.08 USD の混合コストが発生します。
データをバックアップできますか?
AWS Backup を使用すれば、コンテナ化したアプリケーションのファイルシステムすべてのデータを簡単にバックアップできます。開始するには、AWS Backup コンソールにアクセスしてバックアップ計画を設定した後、「K:Backup、V:DailyBackup」などのタグでリソースを割り当てるようにバックアップ計画を設定します。次に、コンテナのファイルシステムを作成するときに、「K:Backup、V:DailyBackup」のタグを追加します。AWS Backup はファイルシステムを自動的に検出し、設定したバックアップポリシーに従ってバックアップを開始します。データを誤って削除しバックアップから復元する必要がある場合は、既存のファイルシステムのディレクトリまたは新しいファイルシステムのいずれかにバックアップを復元するよう AWS Backup に指示できます。
何かをモニタリングする必要がありますか?
EFS はファイルシステムのモニタリングに役立つ CloudWatch メトリクスを出力します。サンプルダッシュボードを公開しています。これには、簡単に開始するためのメトリクスの式とアラームしきい値が含まれています。特に、以下のことに注意してください。
- スループット使用率: これは、計算またはプロビジョニングした利用可能な合計スループットと比較して、アプリケーションが使用しているスループット間の関係を示したものです。これにより、Provisioned Throughput を有効にすべきか、それともアプリケーションのために設定した量を調整すべきかが分かります。
- IOPS 使用率: 汎用パフォーマンスモードのファイルシステムがある場合、最大 7,000 の集約 IOPS を稼働できます。このメトリクスは、この制限の割合としての稼働中の IOPS 数を示します。使用率が 100% に達した場合は、データを複数のファイルシステムに分割するか、IOPS 制限のない最大 I/O ファイルシステムを使用することを検討する必要があります。
- バーストクレジットバランス: ファイルシステムが Bursting Throughput モードの場合、バーストクレジットバランスによって稼働可能なスループットの量が決まります。クレジットをバーストすると、ストレージの TiB あたり最大 100 MiB/s、または 100 MiB/s のいずれか高い方まで稼働できるようになります。バーストクレジットを使い果たすと、ストレージの TiB あたり 50 MiB/s を稼働します。結果的にアプリケーションのパフォーマンスが変化する可能性があるため、不足している場合には通知が来るよう、バーストクレジットバランスにアラームを設定する必要があります。バーストクレジットを使い果たしそうなときは、Provisioned Throughput を有効にして、スループットがアプリケーションに対して一貫した値を保つようにすることができます。
どのように開始したらよいですか?
ECS のドキュメントに、ECS で EFS の使用を開始するためのチュートリアルがあります。EKS の場合、開始手順は EFS CSI ドライバー GitHub ページにあります。
他にも何かご質問はありますか?
このガイダンスが、共有ストレージが必要なコンテナをデプロイしている皆さんのお役に立てるとうれしいです。他にも私が回答できそうな質問があれば、コメントしてください。