オンプレミス環境からAWSへの移行する際のファイルの扱い方について
目次
はじめに
こんにちはi-Vinci髙橋です。
多くの会社がオンプレミスからクラウド環境に移行していると思います。
弊社でもクラウド環境への移行を行う仕事をさせていただいていますが、どのようなシステムでも共通してぶつかる壁があると思います。
その中の一つとしてファイルの扱いをどうしていくかについて記事にしたいと思います。
一口にファイルと言っても種類が多く全てのパターンに言及することも難しいため下記の3種類について記載します。
- アプリケーションの設定ファイル
- アプリケーションのログファイル
- アプリケーションに関連する静的ファイル
3つ目の静的ファイルがかなりざっくりしていますが、ここではAWSでの一般的な静的ファイルの扱いについて記載します。
上記の説明にあたってアプリケーションの実行環境として次の3種類に分けて説明します。
- AWS Lambda
- Amazon ECS + Fargate
- Amazon EC2
実際の実行環境の組み合わせとしてはもっと存在しますが、ある程度よく使われている組み合わせに絞ります。
※体感です
1. AWS Lambda のファイル管理
設定ファイルの管理
まずは、Lambdaとして実装していくアプリケーションの設定についてです。
環境変数
Lambdaの環境変数は、アプリケーションの実行に必要な設定、特に動的に変更されることがない設定項目に適しています。
Lambdaが呼び出すAPIのエンドポイントやアプリケーションの固有の設定などですね。
LambdaへのDeploy時に設定を行います。Deploy後もマネジメントコンソールなどから更新が可能です。
基本的にハードコーディングを行わない設定はこちらに切り出していくとよいと思います。
ただし、開発環境やステージング環境、本番環境など環境ごとに変更したい設定は後述しますが少し工夫が必要です。
AWS Systems Manager Parameter Store
Parameter Storeは、機密性が高くないが、頻繁に変更される可能性のある設定や、複数のLambda関数間で共有される設定情報に適しています。
データベースの接続文字列や、動的に変更が必要なアプリケーションの設定値が挙げられます。
Parameter Storeは、バージョン管理とアクセス制御が可能です。また、設定値を階層的に管理することができます。
階層的に管理というのは下記のようなイメージです。
- /dev/app1/parameter1
- /dev/app1/parameter2
- /staging/app1/parameter1
- /staging/app1/parameter2
環境変数の説明の際に開発環境やステージング環境、本番環境など環境ごとに変更したい設定は後述しますと記載しましたが、Parameter Storeの利用が一つの答えです。
例えばLambdaのDeployにAWS SAMやAWS CDK、AWS CloudFormationなどを利用している場合はBuild時にParameter Storeから値を取得してLambdaの環境変数に設定することも可能です。
また、実装するアプリケーションの中でParameter Storeから取得してくるようにすることもよいと思います。
Build時に取得する場合はParameter Store側で値の変更があった際に再Buildが必要なため、頻繁に変更される場合はアプリケーション内で取得する方がよいでしょう。
ただし（Parameter Storeに限らずですが）サービスのクォータに気を付ける必要があります。
あまりに頻繁に複数のLambdaで呼び出す場合は最大スループットに達してしまい、スロットリングのエラーが発生してしまうかもしれません。
このあたりについては設定の更新頻度やどの程度のLambdaに呼び出されるか等のバランスを見て決定していくとよいと思います。
AWS Secrets Manager
データベースのパスワードやAPIキーなどの機密情報は、AWS Secrets Managerに保存することもよいと思います。
Parameter Storeとよく比較されるSecret Managerですが、どちらを採用するべきかについてはパスワードを自動更新させるか否かだと考えています。
以前はParameter Store側のクォータ制限が厳しかったことで暗号化して管理する設定についてはSecret Managerを検討することが多かったですが、現在はParameter StoreでAWSに申請せずに上限を上げることが可能なため、基本的にはParameter Storeで管理する前提で検討していくのがよいでしょう。
※上限を上げることで料金がかかるので利用料について問題ないか検討は必要です
ログファイル
続いてはアプリケーションのログの管理についてです。
オンプレミス環境ではOSのファイルシステムにログファイルを出力して、日付やサイズでローテーションしていることも多いと思いますが、Lambdaにおいては別の考え方をしていく必要があります。
Amazon CloudWatch Logs
AWSでアプリケーションのログと言えばCloudWatchです。
Lambdaで出力したログについてはCloudWatchに連携されるため、設計時に考慮することはCloudWatchのロググループについてくらいです。
アプリケーションとしては一般的なコンテナ上のアプリケーションと同様でstdoutにログを出力するように実装を行えばログの出力が可能になっています。
またシステムによってはAWSだけではなくAPMサービスを利用する場合もあると思います。
詳細な使用方法は各サービスで異なる部分なので言及しませんが、ほとんどのAPMサービスはCloudWatchにログを出力できていればログを拾っていくことはすぐに可能になると思います。
静的ファイル
最後に静的ファイルです。
静的ファイルの種類によって選択肢が変わってくるものもありますが、ここでは代表的な2つのサービスを挙げます。
これらのサービスを利用すればほとんどの場合は要件に沿ったシステムを構築することが可能なはずです。
Amazon S3
AWSで静的ファイルを管理する場合は、Amazon S3を利用することが多いかと思います。
ほとんどの場合においてはS3の利用で問題ないです。
LambdaにおいてはS3か後述するEFSの2択になります。
S3とEFSの違いについてですが、こちらはオブジェクトストレージかファイルストレージの違いになります。
大きな違いとしてはS3はhttp(s)でアクセスする必要があるのに対し、EFSの場合はNFSとしてマウントすることができます。
アプリケーションからすればOSのファイルシステムとして認識できるEFSの方がオンプレミスからの移行は簡単になります。
その他の点では料金体系やファイルの整合性に関する仕組みが違うため、Lambdaにマウントさせる必要がない場合はこれらの観点で検討するとよいと思います。
Amazon EFS
S3の項目で記載してしまいましたが、EFSの特徴としてファイルシステムとしてマウントすることが可能となっています。
この仕組みのおかげで常に最新のファイルを参照することが可能になったり、複数のLambdaでのファイル共有をファイルシステムで行うことが可能となっています。
Lambdaにマウントさせる必要がある場合はEFSの利用が必須なため、S3と比較して利用を検討しましょう。
2. Amazon ECS + Fargate のファイル管理
設定ファイルの管理
続いてはコンテナの実行環境の一つであるECS + Fargateです。
Lambdaと変わらない部分もあるため、Lambdaと同様の点については省略していきます。
環境変数
ECSには実行するタスクの定義が必要になります。
そのタスク定義内に環境変数を定義することができ、コンテナ起動時に環境変数が読み込まれます。
起動時に読み込まれる関係で環境変数の内容を変更した際にはコンテナの再起動が必要です。
どのような設定を扱うべきかについてはLambdaと特に変わりはありません。
そのため、こちらもParameter Storeなどと連携していくことがよいです。
環境変数に設定する値はParameter StoreやS3と連携することが可能です。
AWS Systems Manager Parameter Store / AWS Secrets Manager
Lambdaと同様です。
環境ごとに変更される設定や、機密情報などはこちらで管理して適宜環境変数に読み込ませましょう。
Amazon S3
コンテナの起動時に環境変数に展開される値をS3のファイルから取得することが可能です。
S3の任意のバケットに~.envファイルを配置し、そのファイルを取得できます。
.envファイルにはkey=value形式で値を設定します。
ログファイル
Amazon CloudWatch Logs
こちらもLambdaと同様です。
コンテナアプリケーションなので、stdoutにログを出力して指定したCloudWatchのロググループにログを連携できます。
コンテナでのログ管理は直接コンテナ上にログを出力したり、サイドカーコンテナでログを出力したりなどの方式があります。
ここでは割愛しますが、作成するシステムの特性に合わせた設計を行い管理を行っていきたいですね。
静的ファイル
静的ファイルについても基本的にLambdaと同様です。
S3やEFSを必要に応じて選択していきましょう。
3. EC2のファイル管理
続いては一番オンプレミス環境のサーバーに近い存在であるEC2です。
オンプレミス環境と同じような使用感で使っていけるものの、クラウド環境ならではの考慮が必要になってきます。
設定ファイルの管理
インスタンスストア / EBSボリューム
EC2インスタンスでは、インスタンスストアまたはEBSボリュームを利用して設定ファイルを直接管理できます。
OS上ではファイルシステムとして使用することが可能です。
EC2上で稼働させるアプリケーション本体や設定ファイルをオンプレミス環境と同様に管理することができます。
ただしインスタンスストアは揮発性であるためEC2インスタンスの停止、終了などの操作でデータが消失します。EBSについては永続的に管理可能です。
EC2で気を付けたいのは各サーバーの管理の考え方をクラウドに合わせないといけない点です。
オンプレミス環境では一度作成したサーバーは稼働し続けられるように設計していきますが、クラウドにおいては使用感が近いEC2でもサーバーは無くなるものとして管理していく必要があります。
よくペットと家畜に例えられる違いですが、EC2では永続化可能なEBSを使用していても動的に変化していくファイルの管理は切り離していくことが重要です。
例えばEC2の冗長化などでAutoscalingを利用することが多いですが、Autoscalingが起動するEC2は事前に指定したAMIを基に作成されます。
このAMIはEBSのスナップショットを含んでいるため、AMIを作成した時点のデータでEC2が起動されます。
そのため、EC2の稼働中にEBS上のデータが更新されていくと、Autoscalingで起動したEC2は更新されたデータを持っていない状態になります。
簡単にデグレが発生してしまいますね。
なので日々変化していくようなデータについてはLambdaやECSと同様にサーバー外で管理していきましょう。
AWS Systems Manager Parameter Store / AWS Secrets Manager
このあたりの使用感についてはLambdaやECSと同様です。
EC2では環境変数に展開していくというよりは、EC2上で稼働するアプリケーションで適宜読み込んでいくことになります。
ログファイル
設定ファイルの管理で記載しましたが、動的に変化していくデータはサーバーに含めない方針が基本になります。
オンプレミス環境ではファイルに出力していたログなども同様で、CloudWatchに連携していきましょう。
EC2においてはCloudWatch AgentがAWSより提供されているので、ファイルに出力したログやWindowsのEventログなども連携することが可能です。
静的ファイル
静的ファイルについてもLambdaやECSと基本的には同様です。S3やEFSで管理するとよいと思います。
ただ日々動的に変化していくものでなければEBSに直接配置する選択肢も取れます。
EBSに配置する場合は、配置後にAMIを再取得しAutoscalingに設定している起動テンプレートのAMIを更新することを忘れずに行いましょう。
おわりに
簡単にファイルの扱い方を記載してきました。
AWSにおいては稼働させるサーバーやファイルの管理場所についてもまだ選択肢がありますが、ここで記載したことが中心になってくると思います。
ここで記載したもの以外では
- 作成するシステムによってはオンプレミス環境のファイルサーバーとの連携
- CloudWatchにログを出力せずにAPMサービスに連携
- Webで配信するファイルのキャッシュサーバーとしてCloudFrontを使用
などなど...
要件によって適切な選択肢は変わってきます。
単純にオンプレミス環境の構成をAWSに持ってきただけではクラウドの恩恵を享受できない部分も多いため、予算と相談しながらAWSに合わせた構成に徐々にでも変更していきたいですね。
以上オンプレミス環境からAWSへの移行する際のファイルの扱い方についてでした。