「AWS AppConfig」で「Feature Flags」の仕組みを整備　ロールアウトを低リスクで実施可能にした、カミナシの実装

AWS AppConfigはどのようなサービスか

佐藤丈生氏：では、いよいよ第2章の「AWS AppConfig」でFeature Flagsの仕組みを整備したお話に入っていきたいと思います。

（スライドを示して）まずは「AWS AppConfigとは？」というところで、全体的なイメージとして、非常に簡易的な図を見てもらっています。

ものすごく直感的にイメージをしてもらうためにお話しすると、AWS AppConfigとは、設定ファイルの中身のようなデータを保存しておいて、それをアプリケーションから参照できるようにするようなサービスとイメージしてもらえればいいかなと思います。

ここで1点注意事項があるんですが、先ほどお話しした設定ファイルの中身のような設定データ、設定値をAWS AppConfigに保存しただけでは、アプリケーションから参照できるようにならないんですね。

（スライドを示して）じゃあアプリケーションから参照できるようにするためにはなにをすればいいのかというと、スライドの赤い線のデプロイというオペレーションが必要になります。

ここでいうデプロイですが、ちょっとややこしいんですが、先ほど紹介したデプロイとロールアウトの分離と言った時のデプロイとはまた別の概念で、AWS AppConfigにおけるデプロイ、ないしデプロイメントという概念になるので、ご了承ください。

ちなみにFeature Flagsにおいて、Feature Flagsの仕組みを実現する上でAWS AppConfigにどんなデータを格納するのかという話ですが、先ほども見てもらったように、機能のオン・オフを切り替えるためのユーザーの属性値のようなデータを格納していくイメージになります。

AWS AppConfigにおけるデプロイ

続いて、先ほど少し頭出しをしたAWS AppConfigにおけるデプロイがなんなのかについて、もう少し詳しく見ていきたいと思います。

先ほどもお話ししましたが、AWS AppConfigに保存した設定値をアプリケーションのほうから参照できるようにするためにやる必要のある、オペレーションです。

非常にざっくりとしたイメージで言うなら、ローリングアップデートみたいなことができるようにするためのものとイメージしてもらうことができます。

どういうことなのかと言うと、例えばコンテナが10個ぐらいあるとします。AWS AppConfig上の設定データが更新された時に、そのコンテナ10台に即時にその変更を反映することもできるわけなんですね。ただ、そうではなくて、例えば100分くらい時間をかけて、徐々に徐々に10台のコンテナに変更を反映させていくなんてことも設定次第ではできるわけです。

これをFeature Flagsの文脈で言うならば、時間をかけて、徐々に徐々にロールアウトしていっているというようなイメージを持つことができると思います。

さらに特徴的なのが、このデプロイメント、Deployment timeという尺を設けているんですが、徐々に徐々にロールアウトしている最中、設定の変更を反映している最中であれば、ロールバックできるんです。なので、システムのメトリックとかをロールアウト中に監視して、なにか怪しい挙動を示したら、それに応じてロールバックするなんてこともできるわけです。

ちなみに、徐々に徐々にロールアウトしていくとか、一気に設定の変更を反映するとか、こういったデプロイの仕方に関する設定のことをDeployment strategyといいます。

AWS AppConfigを使うとうれしい2つのこと

以上までの話を踏まえて、AWS AppConfigを使うとなにがうれしいのかに関して整理していこうと思います。4つ列挙しているんですが、ここから2つお話ししたいと思います。

1つが、AWS AppConfigで設定を保存したり更新したりする時に、バリデーションをかけられるというのが1つの大きな特徴かなと思います。設定値のフォーマットとかが間違っている時に、それを事前にバリデーションで検知できるみたいなことができるようになっています。

もう1つが先ほども紹介したDeployment strategyの話で、ローリングアップデートのようなことができたり、ロールアウト中になにかあった時にロールバックしたりができるのも、AWS AppConfigの大きな特徴かなと感じています。

我々が実装するアプリケーションの側からAWS AppConfigのデータを参照したい時に、どんな実装になるのかも補足的に説明しておきたいなと思います。

なにかアプリケーション上の処理から設定値を参照したい時に、参照したくなる度、AWS AppConfigのAPIコールを直接するモデルではないんです。

どういうものなのかというと、典型的にはバックグラウンドスレッドとかを立てて、そのバックグラウンドスレッド上でAWS AppConfigに対してポーリングをかけます。AWS AppConfigに対するアクセスの結果、設定の変更を検知したら、ローカルキャッシュを更新して、アプリケーションの設定を参照したい側、この図でいうと黒いやつなんですけど……。あっ、すみません。黒いやつが2つありますね。ちょっと大きい黒いほうです。

この大きい黒いやつがアプリケーションの処理のイメージなんですが、この設定を参照したい時にはローカルキャッシュを参照するといったモデルが、典型的なアプリケーション側の実装方法としてイメージされています。

アプリケーション側のアーキテクチャにおけるAWS AppConfigの利用例

では、弊社カミナシにおけるAWS AppConfigの利用例というかたちで紹介していきたいと思います。

こちらで紹介している内容は、弊社のテックブログにも詳しく紹介しているものなので、興味のある方はこちらも見ていただければと思います。このセッションではかなり要点をかいつまんで説明するかたちになります。

まず弊社のアプリケーションのアーキテクチャですが、まずフロントエンドとして、ブラウザ向けのReactのSPAと、タブレット向けのネイティブアプリ。大きく2つのフロントエンドがあります。

この2つのフロントエンドがAPIサーバーにアクセスしているような構造です。ちなみにAPIサーバーはAWS Fargate上で稼働しているコンテナになります。

AWS AppConfigを利用する前にどんな状態だったのかについて話します。どういう状態であったのかというと、Feature Flagsの仕組み自体を持っていなかったというか、作っていなかったということではないんですが。（スライドを示して）この図に「Hard Coding！」と書いているんですが、ソースコード上にToggle Configurationをハードコーディングしているような状態でした。

Toggle Configurationというのはスライドの赤枠のデータで、Feature Flagsでいうならば、要はAWS AppConfigに本来は保存するようなデータのことですね。

それをソースコード上にハードコーディングするような、簡易的な実装を行っていました。ハードコーディングされているので、当然ながらロールアウトしようと思うとデプロイが必要です。

さらに、ソースコード上にハードコーディングされている関係で、リポジトリごとに定義しなきゃいけないかたちになってしまうので、なにが制御されているのか把握するのに認知コストがかかったり、ロールアウト時に修正漏れのリスクがあったり、そういった課題を抱えていました。

そういったものを、AWS AppConfigを利用するかたちで仕組みを整備し直したというかたちになります。

（スライドを示して）整備した後の構成を紹介すると、ざっくりこういった感じの図になります。ポイントを2つほどピックアップして話したいなと思います。

まず1つ目がConfiguration ProfileというリソースのtypeにFeature Flagというタイプを選んだという話です。「これは何ぞや？」という話なんですが、要するにAWS AppConfig上に格納する設定値のフォーマットのことだと考えてください。

typeにFeature Flagを選ぶと、一定のフォーマットがある程度定まっていて、それを使うことがある種強制されるんですね。

なので、もうちょっと違う見方をすると、例えばTerraformとかで設定を更新したいとなって更新した時に、自動的に一定のJSONスキーマによるバリデーションがかかってくれるというものなんですね。これが1つ目のポイントになります。

2つ目のポイントがAWS AppConfig agentです。

こちらが図の真ん中らへんに書かれているもので、AWS AppConfigへのアクセスを一手に引き受けてくれるものになります。

これがなにかというと、AWSが提供しているサイドカーコンテナイメージです。先ほど紹介したAWS AppConfigへのポーリングとかローカルキャッシュの管理という、煩雑になってしまいがちな部分を担ってくれるサイドカーコンテナイメージというかたちになります。こちらも1つポイントかなと思っています。

インフラのコード化におけるAWS AppConfigの利用例

以上がアプリケーション側のアーキテクチャというか設計の話になるんですが、インフラのコード化という観点でも1つ話したいと思います。

インフラのコード化の部分に関しては、Toggle ConfigurationをTerraformで定義してGitHubリポジトリで管理しているという話です。

Toggle Configurationは何度か出ているんですが、Feature Flagsの文脈ではAWS AppConfigに格納する設定値とかのことですね。ロールアウトする時に編集するようなデータのことです。これをTerraformで定義して、GitHubリポジトリで管理しています。

なぜそうしているのかというと、こういった設定値を変える時であっても、ちゃんと変更履歴を残して、レビューのプロセスを通したかったからというのが理由となります。

なので、当然ながらロールアウトしていきたい、ロールアウトする、例えば対象を増やす時にはプルリクエストを出す必要があるし、ロールアウトしたものをいったん切り戻す場合でも、プルリクエストを出していく必要があったりします。

あと1点補足ですが、先ほどDeployment strategyで「ローリングアップデートみたいなことができますよ」みたいな話をしたと思うんですが、現状弊社ではローリングアップデート的なことはしておらず、設定を変更すると、一度に全コンテナに反映されるような、そういった作りにしています。

（スライドを示して）こちら弊社の現在の利用方法で、AWS AppConfigの特徴のどこが活かせているかに関してチェックをつけてみたものになります。

例えばこれが設定値を保存する時のバリデーションとか、一元管理とか、言ってしまえばベーシックな部分に関してはけっこうAWS AppConfigの良さを活用できているのではないかなと思います。

先ほども触れていたとおり、Deployment strategyによってローリングアップデートをしていくみたいな、もしロールアウト中にトラブルが起きたらロールバックをするとか、そういったことに関しては、まだ取り組めていないというようなイメージになります。

では2章のまとめを行いたいと思います。まずはAWS AppConfigの特徴ということで、主に設定を更新する時にAWS AppConfig側でバリデーションをかけてくれるということがあって、それでエラーを低減できるというような趣旨の話とか、Deployment strategyによって、なにか設定を更新した時にローリングアップデートみたいなことができたりといったことを話しました。

次に、弊社カミナシでAWS AppConfigを利用した仕組みを整備して、ある程度AWS AppConfigのうまみは活かせたのかな、みたいなお話をしました。

Feature Flagsの仕組みを運用してみての所感

では、最後。今回Feature Flagsの仕組みを運用してみての学びというか、所感のようなことをお話しできればと思います。

まずは良かったことで、運用という単語を出しておきながらぜんぜん運用じゃない話になっちゃうんですが、こちらも触れておきたくて。まず所感として、すごく導入しやすかったなと感じています。

どういうことかというと、先ほど紹介したAWS AppConfig agentのような、実装がすごく煩雑になってしまいがちな部分を引き受けてくれるような、良い感じのエコシステムがそろっていたので、けっこう手頃な作業ボリュームで実現できたのかなという感想を持っています。

続いて、導入した効果について話していきたいと思います。こちらの効果ですが、留意してほしいのが、Feature Flagsを使った効果じゃなくて、ハードコーディングなどのような簡易的なFeature Flagsの仕組みをAWS AppConfigを使った、ある程度しっかりと設計した仕組みにしたことによって感じた効果といった意味合いになります。

こちらのお話しをしていくと、Toggle Configurationが一元管理されているというところで。何度か出てきているんですが、Toggle Configurationは、Feature Flagsでいうと、AWS AppConfigに格納しておく設定値とかのことですね。

これが一元管理されているので、なにが制御されているのかを把握する上での認知コストが下がったり、ロールアウト時に一元管理されているので、仕組み上、修正漏れみたいなことは非常に起きづらくなっております。

さらに、ロールアウトがデプロイに依存しなくなったので、ロールアウトのスケジュールがすごく柔軟に設定できるようになったなという効果も感じています。

今後の課題

今後の課題に触れていきます。すみません、ちょっと時間が押してきちゃったので、3つある今後の課題のうち、1個だけピックアップしてお話ししますね。興味ある方は後からスライドを見てもらえるとうれしいです。

「Feature Flagsの濫用を防ぎ、技術負債を作らない仕組み」と題しているんですが、別に今弊社でFeature Flagsが濫用されまくって困っているという話ではなくて、「サービスが成長したり組織が大きくなってくると、こういうところもちょっとケアしていかなきゃいけないかな」というニュアンスで書いています。

Feature Flagsを必要以上に定義していろいろな機能を制御しちゃったり、定義したままずっと放置しちゃったりをしすぎると、それが技術負債となって生産性をかえって下げちゃうというようなことに陥りかねないので、一定の規制とか制限は必要かなと考えているところです。