はじめに

#

現在のプロジェクトでは、アプリケーションの設定管理を以下のように行っている。

• 実装コード内にconfigファイルを配置
• 環境変数で環境（dev/stg/prod等）を切り替え、対応するconfigを読み込む

この方式で感じている不便さ：

• 設定を変えるたびにデプロイが必要
• 設定変更のレビュー・マージ・デプロイのリードタイムが長い
• Feature Flagのような動的な切り替えがやりづらい
• 環境ごとの設定差分の管理が煩雑

そこで、AWS AppConfigを使えばこのあたりが改善できるのではないかと考え、調べて試してみることにした。

今回作成したコードは以下のリポジトリに置いている。 https://github.com/kiitosu/appconfig-trial

AWS AppConfigとは

#

• AWS Systems Managerの一機能
• アプリケーションの設定を外部化し、デプロイなしで動的に変更できるサービス
• バリデーション、段階的デプロイ、ロールバックの仕組みが組み込まれている

Feature Flag / 動的設定管理の業界動向

#

AppConfigは「Feature Flag / 動的設定管理」という領域に属するサービス。この領域には以下のようなプレイヤーがいる。

AppConfigの立ち位置は「AWSに寄せている人向けの安価でシンプルな選択肢」。

また、OpenFeatureというベンダー中立な標準仕様も出てきており、特定サービスへのロックインを避ける動きもある。

既存方式との比較

#

IaCとの付き合い方

#

AppConfigのインフラ（アプリケーション・環境・設定プロファイルの定義）はIaCで管理できる。しかし設定値そのものはConsole / CLI / APIで動的に変更するのが前提の設計。

「コード = 実態」というIaCの思想と矛盾するように見えるが、これはAppConfig固有の問題ではなく、Feature Flag / 動的設定管理という領域全体の設計思想。LaunchDarklyなど他のサービスも、設定値はダッシュボードから変えるのが前提になっている。

やってみる

#

設定の取得方法

#

ECSからAppConfigの設定を取得する方法は主に2つある（Lambda ExtensionもあるがこれはLambda専用）。

Agentのほうが圧倒的に楽で、AWSも推奨している。SDK直接を選ぶ理由があるとすれば「サイドカーを増やしたくない」くらい。

AppConfig Agentの仕組みとしては、Agent自体は事前に設定を知っているわけではない。アプリからリクエストが来たときに初めてAppConfigのAPIを呼んで設定を取得し、キャッシュする。以降はキャッシュから返しつつ、バックグラウンドでポーリングして最新の設定を取得する。つまりAgentはAppConfig APIとアプリの間に入るキャッシュ付きプロキシとして動作する。

構成

#

今回はECS (Fargate) + AppConfig Agent（サイドカー）構成で試す。

• ECSタスク内にAppConfig Agentをサイドカーコンテナとして配置
• アプリケーションコンテナからlocalhost経由でAgentに設定を取得しにいく
• Agentが設定のキャッシュ・ポーリングを担当するため、アプリ側の実装はシンプルになる

AppConfigのリソース構成は以下の通り：

Application: my-app
├── Environment: api-service     → APIサーバー用の設定
│   └── ConfigurationProfile: api-config
└── Environment: batch-service   → バッチ処理用の設定
    └── ConfigurationProfile: batch-config

Environmentは同一アプリケーション内で設定の配布先を分ける単位。今回は2つのECSサービス（api-service、batch-service）に対してそれぞれ異なる設定を配布し、独立して動的に変更できることを検証する。

CDKによるインフラ定義

#

CDK（TypeScript）で構築した。AppConfigのL2 Constructがaws-cdk-lib/aws-appconfigにstableとして含まれているため、シンプルに書ける。

AppConfigリソース：

// アプリケーション
const application = new appconfig.Application(this, "MyApp", {
  applicationName: "my-app",
});

// 設定の配布先を分ける
const apiServiceEnv = new appconfig.Environment(this, "ApiServiceEnv", {
  application,
  environmentName: "api-service",
});

const batchServiceEnv = new appconfig.Environment(this, "BatchServiceEnv", {
  application,
  environmentName: "batch-service",
});

// デプロイ戦略（即時反映）
const deploymentStrategy = new appconfig.DeploymentStrategy(this, "Immediate", {
  rolloutStrategy: appconfig.RolloutStrategy.linear({
    growthFactor: 100,
    deploymentDuration: Duration.minutes(0),
    finalBakeTime: Duration.minutes(0),
  }),
});

// 設定データ（初期値。デプロイ後はConsoleから動的に変更できる）
new appconfig.HostedConfiguration(this, "ApiServiceConfig", {
  application,
  name: "api-config",  // 同一Application内で一意
  deployTo: [apiServiceEnv],
  content: appconfig.ConfigurationContent.fromInlineJson(
    JSON.stringify({
      apiEndpoint: "https://api.example.com",
      timeout: 30,
      featureX: false,
    })
  ),
  deploymentStrategy,
});

HostedConfigurationではname（設定プロファイル名）を明示的に指定する必要がある。指定しないと自動生成された名前になり、アプリ側の取得URLと一致しなくなる。また、同一Application内でプロファイル名は一意でなければならない。

ECSタスク定義（api-service）：

const apiTaskDef = new ecs.FargateTaskDefinition(this, "ApiTaskDef", {
  memoryLimitMiB: 512,
  cpu: 256,
  runtimePlatform: {
    cpuArchitecture: ecs.CpuArchitecture.ARM64,
    operatingSystemFamily: ecs.OperatingSystemFamily.LINUX,
  },
});

// AppConfigへのアクセス権限
apiTaskDef.taskRole.addToPrincipalPolicy(
  new iam.PolicyStatement({
    actions: [
      "appconfig:StartConfigurationSession",
      "appconfig:GetLatestConfiguration",
    ],
    resources: ["*"],
  })
);

// アプリコンテナ
apiTaskDef.addContainer("app", {
  image: ecs.ContainerImage.fromAsset(path.join(__dirname, "../app")),
  portMappings: [{ containerPort: 3000 }],
  // AppConfig Agentへの問い合わせURLを環境変数で指定
  environment: {
    APPCONFIG_APP: "my-app",
    APPCONFIG_ENV: "api-service",
    APPCONFIG_CONFIG: "api-config",
  },
});

// AppConfig Agent（サイドカー）
apiTaskDef.addContainer("appconfig-agent", {
  image: ecs.ContainerImage.fromRegistry(
    "public.ecr.aws/aws-appconfig/aws-appconfig-agent:2.x"
  ),
  portMappings: [{ containerPort: 2772 }],
});

Apple SiliconのMacでビルドする場合、runtimePlatformでARM64を指定しないとFargate上でexec format errorになるので注意。

アプリケーション側の実装

#

アプリはExpressで、環境変数をもとにAppConfig Agentへの取得URLを組み立てる。

import express from "express";

const appName = process.env.APPCONFIG_APP ?? "my-app";
const envName = process.env.APPCONFIG_ENV ?? "dev";
const configName = process.env.APPCONFIG_CONFIG ?? "my-config";

const app = express();

app.get("/", async (_req, res) => {
  const response = await fetch(
    `http://localhost:2772/applications/${appName}/environments/${envName}/configurations/${configName}`
  );
  const config = await response.json();
  res.json({ message: "Config from AppConfig", config });
});

app.listen(3000, () => console.log("Listening on port 3000"));

取得URLのフォーマットは：

http://localhost:2772/applications/{アプリ名}/environments/{環境名}/configurations/{プロファイル名}

今回はリクエストのたびにAgentに問い合わせる実装にしたが、本番ではアプリ起動時や一定間隔で取得してメモリに保持するのが一般的。

設定を変更してみる

#

1. npx cdk deploy でインフラと初期設定をデプロイ
2. ECS Execでコンテナに入り、設定値が取得できることを確認
3. AWSコンソールから設定値を変更してデプロイ
4. 再度コンテナ内からアクセスし、アプリをデプロイし直さずに設定が変わっていることを確認

以下、コンソールでの操作手順をスクリーンショットで紹介する。

AppConfigダッシュボード

#

CDKでデプロイしたアプリケーションmy-appが表示されている。

アプリケーションを選択

#

my-appの中にbatch-configとapi-configの2つのConfiguration Profileがある。今回はapi-configの設定を変更する。

現在の設定を確認し、新しいバージョンを作成

#

Version 1の設定（timeout: 30）を確認し、「Create version」から新しいバージョンを作成する。

設定値を変更

#

JSON形式で設定を編集できる。ここではtimeoutを30→60に変更した。

デプロイを開始

#

デプロイ先の環境（api-service）、ホストされた設定バージョン（2）、デプロイ戦略を選択して「デプロイを開始」。

変更後の設定を確認

#

Version 2としてtimeout: 60の設定がデプロイされた。

ECS Execで動作確認

#

まず設定変更前の値を確認する。

$ aws ecs list-tasks --cluster appconfig-trial --service-name api-service
{
    "taskArns": [
        "arn:aws:ecs:ap-northeast-1:xxxxxxxxxxxx:task/appconfig-trial/4e468c5cc027..."
    ]
}

$ aws ecs execute-command --cluster appconfig-trial --task <タスクARN> --container app --interactive --command "/bin/sh"

Starting session with SessionId: ecs-execute-command-xxxxx
# curl http://localhost:3000/
/bin/sh: 1: curl: not found
# node -e "fetch('http://localhost:3000/').then(r=>r.json()).then(console.log)"
{
  message: 'Config from AppConfig',
  config: {
    apiEndpoint: 'https://api.example.com',
    timeout: 30,
    featureX: false
  }
}

node:22-slimにはcurlが入っていないので、node -eで代用した。timeout: 30が返ってきており、CDKで設定した初期値が取得できている。

この後、上記のコンソール操作でtimeoutを60に変更してデプロイし、再度同じコマンドを実行すると、アプリのデプロイなしでtimeoutが60に変わっていることを確認できた。

これでAppConfigによる動的設定変更が実際に動くことを確認できた。

ハマったポイント

#

• ConfigurationProfile名の衝突: 同一Application内で2つのHostedConfigurationに同じnameを付けるとデプロイが失敗する
• exec format error: Apple SiliconでビルドしたDockerイメージをFargateで動かすにはruntimePlatformでARM64を指定する必要がある
• ECS Exec: enableExecuteCommand: trueをサービスに追加し、タスクを再起動しないと有効にならない
• curlが入っていない: node:22-slimにはcurlがないので、node -e "fetch(...)" で代用した

自分たちのユースケースに合うか

#

実際に調べて試してみて気づいたのは、自分たちの設定は環境ごとのURL接続先など静的な設定が中心だということ。

AppConfigの主要なメリットを現状のユースケースに照らすと：

AppConfigの価値が出るのは：

• 運用中に頻繁に変える設定がある（Feature Flag、レート制限値、メンテナンスモード切替など）
• 変更のたびにデプロイを回すのがつらい

逆に静的な設定であれば、現在の方式（configファイル + 環境変数）やParameter Storeでも十分対応できる。

最後に

#

AppConfigは動的な設定管理のためのサービスであり、「設定を頻繁に変える」「デプロイなしで即座に反映したい」というユースケースで真価を発揮する。

一方、自分たちのように静的な設定が中心の場合は、現状のconfigファイル + 環境変数の方式で十分対応できる。導入の手間やIaCとの整合性を考えると、今すぐ移行するメリットは薄い。

導入を検討すべきタイミング:

• Feature Flagの需要が出てきたとき
• 設定変更のたびにデプロイを回すのがボトルネックになったとき
• メンテナンスモード切替など、運用中に即座に切り替えたい設定が増えたとき

「何でもAppConfigにする」のではなく、設定の性質（静的か動的か、変更頻度はどうか）に応じて使い分けることが大事だと感じた。