数万社におよぶ企業がペタバイト規模のデータを Amazon Elastic File System (Amazon EFS) に保存しており、その多くが EFS を使ってコンテナ化したアプリケーションのデータです。Amazon EFS ファイルシステムは、Amazon Elastic Container Service (ECS) と Elastic Kubernetes Service (EKS) の両方で起動したコンテナに接続できます。Amazon EFS はコンテナインフラストラクチャと同様に、データの追加や削除の際に設定が簡単でかつ柔軟なスケーリングが可能な完全マネージド型のサービスであるため、コンテナストレージにうってつけの選択肢です。さらに、ペタバイト級のデータだけでなく、1 秒あたりのギガバイトの総スループットや数千の IOPS にも拡張が可能です。このブログでは、コンテナ化したアプリケーションで EFS を使用するためのベストプラクティスに関する、よくある質問をいくつかご紹介します。
一般に、共有ファイルストレージは、障害に対する回復力が必要な長期にわたって実行するコンテナや、データを相互に共有する必要があるコンテナに適しています。よく目にする例をいくつか挙げましょう。
コンテナデータを永続化する別のオプションとしては、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 を探し、個々の操作のレイテンシーの影響を受けません。
コンテナストレージに 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 メトリクスを出力します。サンプルダッシュボードを公開しています。これには、簡単に開始するためのメトリクスの式とアラームしきい値が含まれています。特に、以下のことに注意してください。
ECS のドキュメントに、ECS で EFS の使用を開始するためのチュートリアルがあります。EKS の場合、開始手順は EFS CSI ドライバー GitHub ページにあります。
このガイダンスが、共有ストレージが必要なコンテナをデプロイしている皆さんのお役に立てるとうれしいです。他にも私が回答できそうな質問があれば、コメントしてください。