カミナシでの AWS AppConfig 導入の背景・課題・成果

ツール導入前の課題

AWS AppConfig の導入前は、Feature Flags をソース上にハードコーディングして管理・制御していました。そのため、以下のような課題がありました。

• 適切なタイミングでの機能解放がしづらい。
• 無関係な原因によるデプロイ切り戻しで、機能の公開・非公開状態も道づれで変わってしまう（以降、機能の公開のことを適宜「ロールアウト」と呼びます）。
• 複数箇所の変更が必要な場合に、修正漏れのリスクがある。

弊社で提供している「カミナシ レポート」は、マルチテナント SaaS です。

新機能の開発時は、「開発し切ってから全テナントにロールアウトする」ことは稀で、

1. 開発初期の段階でもデプロイ・レディな状態を保ち、プロダクション環境へのマージ＆デプロイを行う（社内向けテナントには公開することもある）。
2. β版など一定ラインまで開発したら、一部のテナントにロールアウト。
3. タイミングを見計らい、正式に全テナントにロールアウト。

というステップを踏むことがほとんどです。

従来は以下のように 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
    }
}

弊社では、プロダクション環境へのデプロイは通常週２回としており、このタイミングとロールアウトのタイミングを合わせる必要から、適切なタイミングでロールアウトができない事態に度々直面していました。

また、デプロイ起因で障害が発生し、切り戻しを行った場合、ハードコーディングされている設定値も一緒に切り戻ってしまいます。機能の公開状態まで意図せず切り替わってしまうリスクを常に抱えていました。

さらに、弊社「カミナシ レポート」のサービス・リポジトリの構成上、複数箇所で機能の公開・非公開状態を制御する必要があるケースが多く、修正漏れのリスクも抱えていました。

どのような状態を目指していたか

課題に記載した内容の裏返しになりますが、

• デプロイのタイミングに依存せず、適切なタイミングで機能の公開・非公開が切り替えられる。
• 意図せず機能の公開・非公開状態が切り戻らない。
• 公開・非公開時の設定値の修正漏れを心配しなくて良い。

こと目指していました。そのために

• ソースコードの変更・アプリケーションの再起動なしに、任意のタイミングで機能の公開・非公開を切り替えられる。
• 公開・非公開を制御する設定値は、一元管理されている。

を実現する必要がありました。

• Amazon CloudWatch Evidently（類似の機能フラグ管理サービス）
• RDS、DynamoDB、S3などの外部ストレージ（自前でのデータベース管理）
• 環境変数（AWS Systems Manager Parameter Storeなど）

先述の課題をクリアできることはもちろん、実装・運用コストなど妥当な品質を達成するための通り一辺のことはもちろん考慮しました。 一方、Feature Flags の仕組みそのものは、クリティカルなユーザーデータを扱うわけでも、ハイトラフィックをさばく必要があるわけでもなく、決して難しい機能・非機能要件が求められるものではありませんでした。そのため、厳密に要件へのフィットを考えるというよりは「用意された仕組みを素直に使うことができる」ことも念頭においていました。

機能・エコシステムのバランスがよく「用意された仕組みを素直に使うことができる」点です。 具体的には以下の通りです。

• JSONスキーマで Feature Flags のデータ構造の厳密さを一定担保しつつも、弊社のユースケースを満たしうる程度には柔軟に構造化データを定義できる。
• AWS AppConfig agent というサイドカー用のコンテナイメージが提供されており、煩雑なポーリング処理やローカルキャッシュの管理を自前で実装する必要がなかった。

改善したかった課題はどれくらい解決されたか

当初の課題は解消されました。 デプロイのタイミングに依存せずロールアウトできるようになり、また、意図しない公開状態の切り替わり、修正漏れのリスクも解消されました。

どのような成果が得られたか

大きめの機能開発を行う場合は、ほぼ 100% 本 Feature Flags の仕組みを用いています。 定量的な成果は比較計測していないのでわかりませんが、ロールアウト時の調整オーバーヘッドや意図せぬ事態が起きるリスクは低減されていると考えます。

特にありません。 導入自体は、３人で１週間程の作業ボリュームで完了し、非常にスムーズでした。

（AWS AppConfig そのものの話ではなく、かつ、月並みですが）運用全体を見据え、運用ルール等も体系的に整理することが重要です。

例えば弊社の場合、Feature Flags は段階的なロールアウトに使用しており、ロールアウトが無事完了した場合には、機能が全テナントで利用可能となります。最終的には対象機能の公開・非公開を定義・制御するコード一式は不要となります。これらが削除されずに残存するとコードベースのメンテナンス性がじわじわ損なわれますので、忘れずに掃除されるように運用ルール等を整理する必要があります。

安定的に運用できており、利用を継続していくつもりです。