はじめに

この記事は弥生 Advent Calendar 2025 の 6 日目の記事です。

こんにちは、弥生でバックエンドエンジニアをしている kazu です。

本記事では、「サービスのメンテナンス中に 503 エラーを返す仕組みを検討する中で、
AppConfig と AppConfig Agent を活用してほぼリアルタイム反映とコスト削減を実現した事例」を紹介します。

AppConfigは一般的に「Feature Flag」用途で知られていますが、今回はそれとは少し異なり、
「メンテナンス情報のリアルタイム反映」という目的で活用しました。

また、後半では検討して見えてきた「AppConfig を導入しやすいケース」と「注意が必要なケース」との違いや、そこから得られた学びについても合わせて紹介します。

はじめに
背景
Before構成：S3＋Redis
AppConfig＋Agent 導入の背景
After構成：AppConfig＋AppConfig Agent
新構成のポイント
Before vs. After
AppConfig を「導入しやすいケース」と「注意が必要なケース」
設定ファイル例
おわりに
参考リンク

背景

弥生では、社内でサービス共通の「メンテナンス情報登録システム」があります。
登録された情報を取得し、メンテナンス期間中は 503 エラーを返す仕組みを各サービスで構築しています。

その中で、「できるだけ素早くメンテナンス開始・終了時刻を反映したい」、「インフラコストを抑えたい」という要求があり、今回紹介する構成を検討しました。

Before構成：S3＋Redis

初期検討では、他サービスで既に導入されていた以下のような構成を想定していました。

EventBridge で起動した Lambda がメンテナンス情報を取得し、S3 に保存
S3 のデータをRedis にキャッシュ（キャッシュ時間 10 分）
アプリ（ECS）は Redis を参照してメンテナンス中かを判定

一見シンプルですが、運用を想定すると次の課題がありました。

課題 1：タイムラグの発生
Redis のキャッシュ更新が 10 分間隔のため、設定変更から反映まで最大 10 分の遅延が発生し、
メンテナンス開始・終了時にタイムラグが生じてしまう。
課題 2：固定コストの発生
ElastiCache（Redis）は常時稼働が必要で、小規模なサービスでも一定のコストが発生する。

AppConfig＋Agent 導入の背景

これらの課題を解決するために、AppConfig＋Agent を導入しました。

AWS AppConfigとは
アプリケーション設定を安全かつ柔軟にデプロイできるマネージドサービスです。
環境・プロファイル単位で設定を管理し、即時反映・段階的ロールアウト・ロールバックも可能です。
AWS AppConfig Agentとは
ECS タスクや開発環境で、AppConfig から設定情報をポーリングし、ローカルキャッシュとしてアプリケーションに提供するサイドカーです。
アプリは localhost:2772 にリクエストを送るだけで、Agent がキャッシュした最新設定を取得できます。

これらの組み合わせにより、Lambda が AppConfig の設定を更新し、
Agent が AppConfig をポーリングすることで、定期的に設定をローカルキャッシュに反映します。

なお、AppConfig の設定が更新された際には、新しいバージョンをデプロイする必要がありますが、デプロイ戦略に “AllAtOnce” を選ぶことで、設定をほぼリアルタイムに反映できます。

After構成：AppConfig＋AppConfig Agent

従来の S3＋Redis 構成を、AppConfig＋AppConfig Agent に置き換えました。

EventBridge で起動した Lambda がメンテナンス情報を取得し、AppConfig にデプロイ
Agent が AppConfig からメンテナンス情報を定期取得し、ローカルキャッシュを更新
アプリ（ECS）は localhost:2772 経由で最新設定を取得し、メンテナンス中かを判定

新構成のポイント

サイドカー構成による安定動作
本番環境では、ECS タスクに AppConfig Agent をサイドカーとして常駐させ、同一タスク内通信（localhost）でリアルタイムに設定を取得できます。
ポーリングでの自動反映
Agent は AppConfig の更新をポーリングで検知し、自動的にキャッシュを更新。アプリ側は常にローカルキャッシュを参照するだけで最新情報を取得できます。
インフラ構成の簡素化
Redis を廃止し、AppConfig の仕組みを利用することで、管理コストを削減できました。

Before vs. After

項目	Before（S3＋Redis）	After（AppConfig＋Agent）	効果
反映速度	キャッシュTTL分の遅延（Before 設定では 10 分）	数秒〜数十秒程度（ポーリング間隔に依存）	遅延ほぼゼロ
運用負荷	Redisの管理・監視が必要キャッシュ更新ロジックの実装も必要	AppConfig に設定を集約し、Agent が自動反映	大幅に軽減
月間コスト	合計：$18.29 内訳：・ElastiCache: $18.25 ・S3: $0.025 ・EventBridge+Lambda: $0.01	合計：$0.013 内訳：・AppConfig: $0.0032 ・EventBridge+Lambda: $0.01	約 99% 削減

※ 今回のコスト試算はまだ本番運用前のため、Amazon Q を使用し、以下の前提条件で計算しています：

EventBridge：15 分間隔で実行（2,880 回/月）
設定変更頻度：週 1 回（4 回/月）
ECS タスク数：1 台
ElastiCache インスタンス：cache.t4g.micro を想定

AppConfig を「導入しやすいケース」と「注意が必要なケース」

今回のように「メンテナンスフラグや日時」といったシンプルな設定であれば、AppConfig＋Agent は相性が良いと思います。

一方で、DB のマイグレーションを伴う設定変更や、設定バージョンによってアプリの挙動やデータ構造が大きく変わるケースでは注意が必要です。AppConfig Agent はポーリングで設定を取得するため、タスクごとに反映のタイミングが少しずつズレてしまいます。その結果、「新設定で動いているタスク」と「旧設定で動いているタスク」が一時的に混在し、DB の整合性が崩れるなどのリスクがあります。

そのため、「状態やデータ構造を変えるような重い変更」には使わず、メンテナンス情報やフラグなど、

多少の反映タイムラグやタスク間のズレが許容できる設定
読み取り専用で、DB 構造には影響しない設定

を中心に AppConfig を使うのが安全だと感じました。今回はこの条件に当てはまっていたため、問題なく導入できました。

設定ファイル例

AppConfig では、設定データを JSON などの汎用フォーマットで管理できます。今回は、メンテナンス情報を次のような JSON 形式で定義しています。

ローカル開発環境では、この設定を /Application/Local/Maintenance.json に配置しています。

{
  "application": {
    "isMaintenance": true,
    "windows": [
      {
        "startDateTime": "2025-12-06T22:00:00+09:00",
        "endDateTime":   "2025-12-06T23:00:00+09:00"
      }
    ]
  }
}

本番環境（ECS）では、Agent が AppConfig からこの設定を取得し、タスク内で localhost:2772のエンドポイントを提供します。
アプリケーション側では、次のように Agent にリクエストして最新設定を取得、現在時刻と比較し、 503 を返すか判断します。

curl "http://localhost:2772/applications/{AppName}/environments/{EnvName}/configurations/{ProfileName}"

おわりに

今回の検討を通じて、AppConfig は単なる「設定管理ツール」にとどまらず、ほぼリアルタイムで設定を共有できる基盤としても活用できることを学びました。

Redis などのキャッシュサーバーを立てるほどではなく、運用コストを抑えつつ、できるだけリアルタイムに設定を反映したい場合には、ぜひ AWS AppConfig の活用をご検討ください。

参考リンク

AWS AppConfig 公式ドキュメント

弥生では一緒に働く仲間を募集しています。
www.yayoi-kk.co.jp
弥生のエンジニアに関するnote記事もご覧ください。
note.yayoi-kk.co.jp

弥生開発者ブログ

AWS AppConfigを使ってメンテナンス情報をリアルタイム反映する仕組みを作った話