カミナシでの AWS AppConfig 導入の背景・課題・成果
株式会社カミナシ / Tomoki Sato
メンバー / フルスタックエンジニア・プロダクトエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
| 利用機能 | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|---|
AWS AppConfig(Feature flags) | 11名〜50名 | 2023年6月 | B to B |
| 利用機能 | AWS AppConfig(Feature flags) |
|---|---|
| ツールの利用規模 | 11名〜50名 |
| ツールの利用開始時期 | 2023年6月 |
| 事業形態 | B to B |
アーキテクチャ

アーキテクチャの意図・工夫
(前提)弊社「カミナシ レポート」のバックエンド(API サーバーなど)は、AWS Fargate 上で稼働しています。 (参考:カミナシが EC2 から AWS Fargate に移行した当時の背景と現在の活用状況 )
- ECSタスク上に AWS AppConfig agent をサイドカーコンテナとして配置し、AWS AppConfig へのポーリング・キャッシュ管理などの責務をオフロードすることで各コンテナの責務をシンプルに保っています。また、AWS AppConfig agent が停止してもアプリケーション全体が停止しないように、ECSタスク定義にて同コンテナの essential を false にしています。
- フロントエンドからは、既存 API サーバーに追加したエンドポイント(GET /enabledFeatures)経由で Feature Flags を取得する構成とし、AWS AppConfig にアクセスするための IAM クレデンシャル管理もバックエンドに一元化しています。
- AWS AppConfig のリソース定義・Feature Feature Flags の設定値は、アプリケーションインフラとは別のリポジトリにて Terraform(IaC)管理しています。インフラと切り離して構成管理できるようにしています。
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
AWS AppConfig の導入前は、Feature Flags をソース上にハードコーディングして管理・制御していました。そのため、以下のような課題がありました。
- 適切なタイミングでの機能解放がしづらい。
- 無関係な原因によるデプロイ切り戻しで、機能の公開・非公開状態も道づれで変わってしまう(以降、機能の公開のことを適宜「ロールアウト」と呼びます)。
- 複数箇所の変更が必要な場合に、修正漏れのリスクがある。
弊社で提供している「カミナシ レポート」は、マルチテナント SaaS です。
新機能の開発時は、「開発し切ってから全テナントにロールアウトする」ことは稀で、
- 開発初期の段階でもデプロイ・レディな状態を保ち、プロダクション環境へのマージ&デプロイを行う(社内向けテナントには公開することもある)。
- β版など一定ラインまで開発したら、一部のテナントにロールアウト。
- タイミングを見計らい、正式に全テナントにロールアウト。
というステップを踏むことがほとんどです。
従来は以下のように Feature Flags をフロントエンド・バックエンドそれぞれで、ハードコーディングして管理していたため、先ほど述べたような課題に直面していました。
// 機能Xを開放したいテナントのIDs
const tenantIds = [
123,
124,
125
]
const isFeatureXEnabled = (tenantId: number) => tenantIds.includes(targetTenantId)
const doSomething = () => {
....
if (isFeatureXEnabled(tenantId)) {
// doSomething with FeatureX
} else {
// doSomething without FeatureX
}
}
弊社では、プロダクション環境へのデプロイは通常週2回としており、このタイミングとロールアウトのタイミングを合わせる必要から、適切なタイミングでロールアウトができない事態に度々直面していました。
また、デプロイ起因で障害が発生し、切り戻しを行った場合、ハードコーディングされている設定値も一緒に切り戻ってしまいます。機能の公開状態まで意図せず切り替わってしまうリスクを常に抱えていました。
さらに、弊社「カミナシ レポート」のサービス・リポジトリの構成上、複数箇所で機能の公開・非公開状態を制御する必要があるケースが多く、修正漏れのリスクも抱えていました。
どのような状態を目指していたか
課題に記載した内容の裏返しになりますが、
- デプロイのタイミングに依存せず、適切なタイミングで機能の公開・非公開が切り替えられる。
- 意図せず機能の公開・非公開状態が切り戻らない。
- 公開・非公開時の設定値の修正漏れを心配しなくて良い。
こと目指していました。そのために
- ソースコードの変更・アプリケーションの再起動なしに、任意のタイミングで機能の公開・非公開を切り替えられる。
- 公開・非公開を制御する設定値は、一元管理されている。
を実現する必要がありました。
比較検討したサービス
- Amazon CloudWatch Evidently(類似の機能フラグ管理サービス)
- RDS、DynamoDB、S3などの外部ストレージ(自前でのデータベース管理)
- 環境変数(AWS Systems Manager Parameter Storeなど)
比較した軸
先述の課題をクリアできることはもちろん、実装・運用コストなど妥当な品質を達成するための通り一辺のことはもちろん考慮しました。 一方、Feature Flags の仕組みそのものは、クリティカルなユーザーデータを扱うわけでも、ハイトラフィックをさばく必要があるわけでもなく、決して難しい機能・非機能要件が求められるものではありませんでした。そのため、厳密に要件へのフィットを考えるというよりは「用意された仕組みを素直に使うことができる」ことも念頭においていました。
選定理由
機能・エコシステムのバランスがよく「用意された仕組みを素直に使うことができる」点です。 具体的には以下の通りです。
- JSONスキーマで Feature Flags のデータ構造の厳密さを一定担保しつつも、弊社のユースケースを満たしうる程度には柔軟に構造化データを定義できる。
- AWS AppConfig agent というサイドカー用のコンテナイメージが提供されており、煩雑なポーリング処理やローカルキャッシュの管理を自前で実装する必要がなかった。
導入の成果
改善したかった課題はどれくらい解決されたか
当初の課題は解消されました。 デプロイのタイミングに依存せずロールアウトできるようになり、また、意図しない公開状態の切り替わり、修正漏れのリスクも解消されました。
どのような成果が得られたか
大きめの機能開発を行う場合は、ほぼ 100% 本 Feature Flags の仕組みを用いています。 定量的な成果は比較計測していないのでわかりませんが、ロールアウト時の調整オーバーヘッドや意図せぬ事態が起きるリスクは低減されていると考えます。
導入時の苦労・悩み
特にありません。 導入自体は、3人で1週間程の作業ボリュームで完了し、非常にスムーズでした。
導入に向けた社内への説明
上長・チームへの説明
Design Doc を執筆し、マネジャー含むチームのメンバー間で認識を揃えました。 (弊社では新機能実装などの大きめの開発をするとき、満たすべき要件や技術的なトレードオフなどを論じた Design Doc を作成し、ステークホルダー間の認識を揃えています)
活用方法
大きめの機能開発を行う場合は、ほぼ 100% 本 Feature Flags の仕組みを用いてロールアウトをしています。
また、役割を終えた Feature Flags の定義を忘れずに削除し、コードベースをクリーンに保つため、運用定例(Service Review)という場で、不要な Feature Flags が無いかの確認を定期的に行っています。
よく使う機能
アプリケーション構成はアーキテクチャ図に記載した通りです。 補足:AWS AppConfig では設定値を格納する方法として「FreeForm Configuration」と「Feature Flags」が選べます。現状「FreeForm Configuration」ほどの自由度は不要のため「Feature Flags」を選択しています。
ツールの良い点
「選定理由」の内容と被りますが、十分な機能が手頃に利用できている実感があります。
「数値の配列」などJSONスキーマを明示して、Feature Flags のデータを定義できるため、設定の一貫性や整合性を保ちやすい。(スキーマに違反する場合、設定更新時にエラーになる)
AWS AppConfig agent が用意されており、コンテナ環境では特に、実装・メンテナンスコストを低く抑えることが可能。
ツールの課題点
シンプルな使い方をしていることもあり、AppConfig そのものの課題を感じることはほぼありません。
AppConfig そのものの課題とは言えないかもしれませんが、以下参考までに、IaC との相性面で「かゆいところに手が届かない」と感じる点をご紹介します。
アーキテクチャ図の通り、弊社では Terraform を用いて Feature Flags の内容も管理しています。Terraform を用いて変更を行うときは通常 plan を実行し変更内容(diff)を確認してから apply します。この plan の際に Feature Flags の内容の diff までは判明しません(設定値全体が「Known after apply」となります)。すなわち plan の段階では「Feature Flags の内容になんらかの変更がある」ことはわかるものの「具体的にどの機能のどの tenant の公開状態が変わるのか?」までは、わからないということになります。 このあたりの正しさは、プルリクエストのコードレビューなどで担保する必要があります。
ツールを検討されている方へ
(AWS AppConfig そのものの話ではなく、かつ、月並みですが)運用全体を見据え、運用ルール等も体系的に整理することが重要です。
例えば弊社の場合、Feature Flags は段階的なロールアウトに使用しており、ロールアウトが無事完了した場合には、機能が全テナントで利用可能となります。最終的には対象機能の公開・非公開を定義・制御するコード一式は不要となります。これらが削除されずに残存するとコードベースのメンテナンス性がじわじわ損なわれますので、忘れずに掃除されるように運用ルール等を整理する必要があります。
今後の展望
安定的に運用できており、利用を継続していくつもりです。
株式会社カミナシ / Tomoki Sato
メンバー / フルスタックエンジニア・プロダクトエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
株式会社カミナシ / Tomoki Sato
メンバー / フルスタックエンジニア・プロダクトエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法


