この記事は秋の技術特集 2024の 17 記事目です。

はじめに

Musubi AI 在庫管理で DevOps エンジニアをしている kacky です。

Web アプリケーションの開発において、設定値の管理は避けて通れない課題です。データベース接続情報や機能フラグなど、アプリケーションの挙動を左右する重要な情報を安全かつ効率的に扱う必要があります。

AWS では、設定値の保存に利用できるサービスがいくつか存在します。本稿では、特に S3, AppConfig, Parameter Store の 3 つに焦点を当て、それぞれのメリット・デメリットを比較し、最適な設計を選択するための決定法を紹介します。

なぜ設定値の保存先を検討する必要があるのか？

設定値をアプリケーションのコード内に直接記述してしまうと、環境ごとに設定を変更する際にコードを修正する必要が生じ、運用ミスやセキュリティリスクの増加に繋がります。また、設定値の変更に伴い、アプリケーションの再構築が必要になる場合もあります。

この問題は、モダンなアプリケーション開発のベストプラクティス集として有名な Twelve-Factor App でも言及されており、「設定をコードから厳密に分離すること」が強く推奨されています。

Twelve-Factor App - III. 設定

Twelve-Factor は 設定をコードから厳密に分離すること を要求する。設定はデプロイごとに大きく異なるが、コードはそうではない。

AWS ではアプリケーションコードから分離して設定値を管理できるサービスを提供しており、これらを活用することで、Twelve-Factor App の原則に則り、より安全で効率的な開発・運用が可能になります。

データ保護

AWS の S3, AppConfig, Parameter Store の 3 つのサービスはすべて、データ保護のために AWS マネージドキーや AWS Key Management Service (KMS) を使用して暗号化することが可能です。これにより、保存される設定値が不正アクセスから保護され、セキュリティが強化されます。どの方法を利用するかはセキュリティ要件に応じて選択してください。

S3: S3 バケットに保存されるデータは、サーバーサイド暗号化 (SSE) をサポートしており、AWS マネージドキー (SSE-S3) または KMS キー (SSE-KMS) を使用して暗号化できます。
AppConfig: AppConfig で管理される設定値はデフォルトで AWS マネージドキーで暗号化されており、オプションで KMS キーを使用して暗号化できます。
Parameter Store: Parameter Store では、SecureString を利用することでパラメータの値を AWS マネージドキーまたは KMS キーを使用して暗号化できます。

サービス比較

S3, AppConfig, Parameter Storeそれぞれのメリット、デメリットをまとめると以下のようになります

サービス	メリット	デメリット	適用例
S3	- 大容量データの保存が可能 - 低コスト	- 設定値の取得・更新にコードが必要 - 設定の読み込みに時間がかかる	- MB を超える大容量の設定、sqlite などの利用
AppConfig	- 設定値の検証・段階的なデプロイが可能 - 設定変更の履歴管理が容易 - 設定変更をアプリケーションに動的に反映可能 - AppConfig Lambda extension の活用により Lambda 利用時に API 呼び出しを削減してコストとパフォーマンスが向上する	- 保存できるデータ容量は 4MB まで	- 稼働中に設定値の更新が必要なアプリケーション - 設定値の変更を安全にデプロイしたい場合
Parameter Store	- 階層構造で設定値を管理できる - 標準スループットでは無料枠内で利用可能	- 標準スループットでは 1 秒あたり 40 トランザクション(TPS)の制限がある	- 更新頻度が低い設定値(url や env 等)

コンテナ実行環境における選択

AWS では、コンテナ化されたアプリケーションを実行する基盤として、 Amazon ECS (Elastic Container Service) や AWS Lambda などが提供されています。これらのサービスを利用する際、設定値の保存先として、以下のような基準で選択できます。

設定ファイルのサイズ

1MB*1 を超える場合: S3 を利用します。S3 は大容量データの保存に適しています。
1MB 以下の場合: AppConfig または Parameter Store を利用します。アプリケーションの要件に合わせて選択します。

アプリケーション実行基盤

Lambda: AppConfig を利用します。Parameter Store は 40TPS の制限があるため、Lambda のように大量のコンテナが起動、終了を繰り返すケースには適しません。
ECS: AppConfig または Parameter Store を利用します。アプリケーションの要件に合わせて選択します。

設定値の更新時にアプリケーションの再起動してもよいか:

再起動を避けたい場合: AppConfig が適しています。アプリケーションの実行中に設定値を変更できるため、ダウンタイムを最小限に抑えられます。
再起動してもよい場合: Parameter Store が適しています。Parameter Store はアプリケーションの起動時に読み込む必要がある設定値を安全かつ低コストに保存するのに適しています。

流れを図にまとめるとこのようになります。

graph TD
    A[設定ファイルのサイズ] -->|1MB を超える| B[S3]
    A -->|1MB 以下| C[アプリケーション実行基盤]

    C -->|Lambda| D[AppConfig]
    C -->|ECS| E[更新時にアプリケーションを再起動してもよいか]

    E -->|再起動を避けたい| D[AppConfig]
    E -->|再起動してもよい| F[Parameter Store]