2023/09/02 AWS Startup Day 2023 https://aws-startup-community.connpass.com/event/289498/
AWS AppConfig で低リスク・低ストレスなロールアウトを実現した話
佐藤 丈生 Software Engineer
AWS AppConfig で低リスク・低ストレスなロールアウトを実現した話 株式会社カミナシソフトウェアエンジニア 佐藤 丈生
View Slide
自己紹介株式会社カミナシソフトウェアエンジニア佐藤 丈生(Tomoki Sato)経歴) パッケージソフト開発（Java, 普通のJS 中心） → 2022/12 株式会社カミナシ カミナシでは、React / React Native (iOS) / Golang / AWS
はじめに会社 & プロダクトについて
会社 & プロダクト紹介日常はITに溢れているのに、仕事場は紙ばかりで非効率。今日も作業現場で働く人たちは、十分に才覚を発揮できていない。そんな3,900万人の埋もれたエネルギーを、私たちが解き放つ。誰もが享受するべき当たり前を、すべての現場の人たちに届けたい。効率的な作業、見事な成果、腕のなる仕事、豊かな人生。これらはきっとつながっているから。ノンデスクワーカーの才能を解き放つMission
会社 & プロダクト紹介誰でも正しい手順で作業を実行カミナシは、モバイルアプリを使って、現場業務のムダを自動化するサービスです。現場ＤＸプラットフォーム「カミナシ」管理者の代わりに作業をチェックデータから自動で集計・報告書を作成改善活動をサポート
会社 & プロダクト紹介
はじめにここから本題
セッション対象者➢ 実例を通じて、AWS AppConfig で Feature Flags を実装するイメージを持ちたい方➢ Feature Flags を用いた低リスク・低ストレスなサービスのロールアウトを実現したい方➢ AWS AppConfig の特徴やその使い所（使用例）について知りたい方セッション対象者とゴール
ゴール➢ 今後 Feature Flags などの仕組みを設計するときに AWS AppConfig を設計の選択肢の１つにできること話すこと➢ Feature Flags の概要や、必要とされる理由➢ AWS AppConfig ならではの特徴や、その利用イメージ話さないこと➢ Feature Flags に関する網羅的な説明➢ AWS AppConfig の詳細な仕様や、使用する際の具体的な手順セッション対象者とゴール
アジェンダ1. Feature Flags はなぜ必要か？a. デプロイとロールアウトの分離の重要性b. Feature Flags とは？c. カミナシにとっての Feature Flags2. AWS AppConfig で Feature Flags の仕組みを整備した話a. AWS AppConfig とは？b. カミナシでの AWS AppConfig 利用例3. Feature Flags の仕組みを運用してみての学びa. よかったことb. 今後の課題
アジェンダ1. Feature Flags はなぜ必要か？a. デプロイとロールアウトの分離の重要性b. Feature Flags とは？c. カミナシにとっての Feature Flags2. AWS AppConfig で Feature Flags の仕組みを整備した話3. Feature Flags の仕組みを運用してみての学び
デプロイとロールアウトの分離の重要性デプロイとロールアウトの分離とは？デプロイ➢ 運用環境のソフトウェアのバージョンを変え、稼働させること➢ 例） コンテナイメージをビルドし、ECR に push。それを元に、ECS タスクを(再)起動するロールアウト➢ 機能を、利用者の一部 or 全体に利用可能にすること➢ 例） 新規開発した機能Xを、ユーザーが利用可能な状態にすること
デプロイとロールアウトの分離の重要性デプロイとロールアウトの分離とは？💡本セッションでは、デプロイとの区別を明確にするために、「機能を、利用者の一部 or 全体に利用可能にすること」という意味合い対して、「リリース」ではなく「ロールアウト」という言葉を使用します。
デプロイとロールアウトの分離の重要性デプロイとロールアウトの分離とは？➢ デプロイとロールアウトが分離していない状態○ 例）コンテナイメージをビルドし ECR に push。それを元に、ECS タスクを(再)起動すると、新規開発した機能Xを、ユーザーが利用可能になる➢ デプロイとロールアウトが分離した状態○ 例）コンテナイメージをビルドし ECR に push。それを元に、ECS タスクを(再)起動しても、新規開発した機能Xは、ユーザーには公開されない○ 例）コンテナイメージのビルド 〜 ECS タスクの(再)起動を行わなくても、機能Xの、公開・非公開状態が切り替えられる
デプロイとロールアウトの分離の重要性なぜ、デプロイとロールアウトの分離が重要なのか？開発視点 (開発効率・作業負荷軽減・安定運用）➢ CD(継続的デリバリー)、継続的デプロイメントに、事実上不可欠であるため➢ ロールアウト時のリスクを低減させるためビジネス視点（ビジネス上の施策・戦略）➢ 開発を妨げずに、適切なタイミングでロールアウトできるようにするため
デプロイとロールアウトの分離の重要性なぜ、デプロイとロールアウトの分離が重要なのか？👀開発視点 (開発効率・作業負荷軽減・安定運用）➢ CD(継続的デリバリー)、継続的デプロイメントに、事実上不可欠であるため○ コード変更を一日複数回メインブランチにマージしたい！○ 高頻度でプロダクション環境にデプロイしたい！○ その一方で、ある程度の期間を要する機能追加・変更は発生しうる...➢ ロールアウト時のリスクを低減させるため○ ロールアウト後に、トラブルが起きたら、即座にその機能をオフにしたい！
デプロイとロールアウトの分離の重要性なぜ、デプロイとロールアウトの分離が重要なのか？👀ビジネス視点（ビジネス上の施策・戦略）➢ 開発を妨げずに、適切なタイミングでロールアウトできるようにするため○ 開発チームがデプロイしたいタイミングと、ビジネス上、機能をユーザーに公開したいタイミングは異なる■ 例：ユーザーへの公開は、マーケティングキャンペーンと連動させたい
アジェンダ1. Feature Flagsはなぜ必要か？a. デプロイとロールアウトの分離の重要性b. Feature Flags とは？c. カミナシにとっての Feature Flags2. AWS AppConfig で Feature Flags の仕組みを整備した話3. Feature Flags の仕組みを運用してみての学び
Feature Flags とは？➢ コードを修正せずに、システムの振る舞いを変える技術（参考: https://martinfowler.com/articles/feature-toggles.html)
Feature Flags とは？➢ コード上の特定の箇所を、条件に応じて ON or OFF にできるイメージ
Feature Flags とは？ロールアウトされた状態ロールアウトされていない状態
Feature Flags とは？Feature Flags でデプロイとロールアウトの分離を実現できるさらにこんなこともできる......🎉例：ユーザーの属性に応じて、機能の利用可否を切り替える➢ 開発視点では、ロールアウト時のリスクをさらに低減できる○ カナリアリリース➢ ビジネス視点では、完全なロールアウトの前に、検証プロセスを回せる○ A / B テスト○ β リリース＊一般的に「カナリアロールアウト」や「β ロールアウト」のような言い方はしないと感じたのでここでは「リリース」という言葉を使っています
Feature Flags とは？Feature Flags の種類について補足- Release Toggles- Experiment Toggles- Ops Toggles- Permission Toggles- …..💡本セッションでは、新しい機能を追加するときに、柔軟にロールアウトしていくために利用するFeature Flags を念頭においています。上記では、Release Toggles や Experiment Toggles が近いイメージです。（参考： https://martinfowler.com/articles/feature-toggles.html)
カミナシにとっての Feature FlagsFeature Flags のメリットを感じていること➢ ステークホルダーへの影響などを考慮しながら、ロールアウトのタイミングを調整できる○ フィールドワーカーの中には、Saas やアプリなどツールに不慣れな方も多い➢ 一部のお客様へのβ版提供により、機能をブラッシュアップできる○ 別環境を構築せずに、プロダクション環境を使用○ 本番データで、質の高いβテスト（データ壊れないよう注意だが...)➢ 開発に数週間・数ヶ月かかるような機能も、メインブランチにマージ & プロダクションへデプロイできる○ 開発の効率や、エンジニアの作業負荷の軽減
カミナシにとっての Feature FlagsFeature Flags のメリットを感じていること (Pick up)➢ プロダクション環境・実業務のデータで、β版を試していただく● β版環境・お試しデータは、■ お客様が業務がイメージしづらい・実業務での使用はほぼ不可● プロダクション環境・実業務データは、■ お客様が実業務をイメージしやすい・実業務で使用可の場合も■ （もちろん実業務データに悪影響がでないよう注意 & 期待値調整必須）→ フィードバックがたくさん🎉→ Feature Flags で一部ユーザーのみに柔軟にロールアウトできるおかげ
「1. Feature Flagsはなぜ必要か？」まとめ➢ 開発・ビジネスの両方の視点で、デプロイとロールアウトの分離は重要➢ Feature Flags により、デプロイとロールアウトの分離が実現できる➢ カミナシでは、開発・ビジネス両面で、Feature Flags のメリットを享受している
次章以降の説明のための補足(参考：https://martinfowler.com/articles/feature-toggles.html）Toggle Configuration（機能ONにするユーザーの属性値）
アジェンダ1. Feature Flagsはなぜ必要か？2. AWS AppConfig で Feature Flags の仕組みを整備した話a. AWS AppConfig とは？b. カミナシでの AppConfig 利用例3. Feature Flags の仕組みを運用してみての学び
AWS AppConfig とは？全体イメージAWS AppConfig を使用することにより、「アプリケーションの設定」を作成・管理し、素早く「デプロイ」できます（引用元：https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html 佐藤意訳）
AWS AppConfig とは？全体イメージ
AWS AppConfig とは？全体イメージ● 「アプリケーションの設定」を作成・更新し、「デプロイ」（開始）する○ 「アプリケーションの設定」： Feature Flags の文脈では、ToggleConfiguration● アプリケーションは、「デプロイ」された 「アプリケーションの設定」を参照する○ 「デプロイ」： 「アプリケーションの設定」 を、アプリケーションが参照できる状態にすること
AWS AppConfig とは？全体イメージ➢ Feature Flags の文脈：Toggle Configuration が「アプリケーションの設定」に相当するToggle Configuration（機能ONにするユーザーの属性値）
AWS AppConfig とは？「デプロイ」(deployment) について
AWS AppConfig とは？「デプロイ」(deployment) について● イメージ： ローリングアップデートのようなことができる○ Deployment strategy によって変更の反映をコントロールできる■ 例えば、複数のアプリケーションに、徐々に新しい設定を参照させる、ことができる○ Deployment time + Bake time 内であれば、ロールバックが可能■ トラブル時にロールバック■ システムメトリクスなどを観ながら、慎重にロールアウト
AWS AppConfig とは？AWS AppConfig を使うと何が嬉しいの？● 👀「アプリケーションの設定」を更新する時のバリデーション○ JSON スキーマ・AWS Lambda● 「アプリケーションの設定」の変更をアプリケーションに迅速に反映○ 「アプリケーションの設定」がAWS AppConfigにより一元管理● デプロイ・再起動なしで「アプリケーションの設定」の更新を反映● 👀Deployment Strategy により、設定変更の反映のされ方をコントール○ トラブル時にロールバック○ システムメトリクスなどを観ながら、慎重にロールアウト
補足 典型的なアプリケーションからの参照方法AWS AppConfig とは？
AWS AppConfig とは？補足 典型的なアプリケーションからの参照方法● イメージ：Local Cacheを参照する。Local Cache 更新はバックグラウンドスレッド● バックグラウンドスレッド○ StartConfigurationSession（＊API)： セッション開始○ GetLatestConfiguration（＊API)： ポーリング○ 「アプリケーションの設定」に変更があれば、Local Cache を更新する● アプリケーション○ 設定を参照する箇所では、Local Cache を参照する＊API：AWS AppConfig のAPI
アジェンダ1. Feature Flagsはなぜ必要か？2. AWS AppConfig で Feature Flags の仕組みを整備した話a. AWS AppConfig とは？b. カミナシでの AWS AppConfig 利用例3. Feature Flags の仕組みを運用してみての学び
カミナシでの AWS AppConfig 利用例弊社でどのように AWS AppConfig を利用したのかについて、より詳細は、弊社テックブログもご確認ください。→ https://kaminashi-developer.hatenablog.jp/entry/2023/07/31/122831
カミナシでの AWS AppConfig 利用例誰でも正しい手順で作業を実行カミナシは、モバイルアプリを使って、現場業務のムダを自動化するサービスです。(再掲)現場ＤＸプラットフォーム「カミナシ」管理者の代わりに作業をチェックデータから自動で集計・報告書を作成改善活動をサポートWeb 管理者向け画面（React (SPA))Mobile 記録者向け画面（React Native)
カミナシでの AWS AppConfig 利用例カミナシのアーキテクチャ概要
カミナシでの AWS AppConfig 利用例カミナシのアーキテクチャ概要● ブラウザからアクセスする「Web」アプリケーション(React。SPA)● 「Mobile」アプリケーション（React Native。iOSネイティブアプリ）● フロントエンドからアクセスされる「API Server」● API サーバーは、AWS Fargate 上のコンテナで稼働する Go lang アプリケーション
カミナシでの AWS AppConfig 利用例AWS AppConfig 利用前の状態・課題
カミナシでの AWS AppConfig 利用例AWS AppConfig 利用前の状態・課題● ソースコード上に Toggle Configuration をハードコーディング● 課題○ ロールアウトのために、デプロイが必要○ 一元管理が難しい → 認知コスト・ロールアウト時の修正漏れ
カミナシでの AWS AppConfig 利用例再掲（Toggle Configuration)
カミナシでの AWS AppConfig 利用例アーキテクチャ（アプリケーション周り 全体）
カミナシでの AWS AppConfig 利用例アーキテクチャ（アプリケーション周り 全体）● Toggle Configuration を AWS AppConfig で管理○ Configuration Profile の type == Feature Flag○ （JSON スキーマによるバリデーション）● AWS AppConfig へのアクセスは、AWS AppConfig agent が担う○ AWS が提供するサイドカーコンテナイメージ○ https://gallery.ecr.aws/aws-appconfig/aws-appconfig-agent● アプリケーションは、AWS AppConfig agent にアクセス● Front End は、「GET /enabledFeatures」にアクセス
アーキテクチャ（アプリケーション周り フロントエンド）● 各コンポーネントでは、カスタムフックを用いて、機能の利用可否を判定○ API コールのタイミングを意識したくない○ コンポーネントのレンダリング毎に API コールされるのを避けたい○ → Front End は Front End で Local Cache を管理● TanStack Query のキャッシュ機構を用いて実装カミナシでの AWS AppConfig 利用例
カミナシでの AWS AppConfig 利用例AWS AppConfigの設定を IaC で管理する
カミナシでの AWS AppConfig 利用例AWS AppConfigの設定を IaC で管理する● Toggle Configurationは Terrafrom で定義し、Github Repository で管理○ Toggle Configuration の変更履歴を残し、レビューのプロセスを通したい○ ロールアウト、ロールバックしたい時は、PR を出す● Terraform Cloud 上で、Plan実行 → Apply により、「デプロイ」開始○ main ブランチへのマージがトリガー● Deployment time、Bake time ともに 0 のため、即時に全コンテナに反映
カミナシでの AWS AppConfig 利用例他の選択肢についてToggle Configuration をどこに格納するか？● RDS、DynamoDB、S3など何かしらの外部ストレージ○ AWS AppConfig に比べ自由度が高いが、そのぶん設計・実装・管理が難しい● Amazon CloudWatch Evidently を利用する○ 自由度、エコシステムなどが、AWS AppConfig の方がふさわしかった● 環境変数（AWS Systems Manager Parameter Storeなど）○ タスク再起動が必要。構造化データを持たせる辛み
カミナシでの AWS AppConfig 利用例他の選択肢についてFront End からどうやって AWS AppConfig の設定を取得するか？● Amazon Congito を活用し、Front End から直接 AWS AppConfig の API にアクセスする○ API サーバーにエンドポイントを定義する方が、（現状では）シンプルかつ、実装・運用しやすい
カミナシでの AWS AppConfig 利用例活かせている AWS AppConfig の良さ● ✅「アプリケーションの設定」を更新する時のバリデーション○ ✅ JSON スキーマ・AWS Lambda● ✅「アプリケーションの設定」の変更をアプリケーションに迅速に反映○ ✅「アプリケーションの設定」がAWS AppConfigにより一元管理● ✅ デプロイ・再起動なしで「アプリケーションの設定」の更新を反映● 🔴 Deployment Strategy により、設定変更の反映のされ方をコントール○ トラブル時にロールバック○ システムメトリクスなどを観ながら、慎重にロールアウト＊AWS AppConfig の良さを全て活かしきれているわけではない
「2. AWS AppConfig で Feature Flags の仕組みを整備した話」まとめ➢ AWS AppConfig 使うことにより、○ 設定の更新時、バリデーションによりエラーを低減○ 設定を一元管理○ 設定の更新時にアプリケーションの停止も不要○ Deployment Strategy により、設定更新の反映のされ方をコントロール➢ カミナシでは、AWS AppConfig を利用した仕組みを整備し、以下を実現○ Toggle Configuration の一元管理○ デプロイに依存しないロールアウト
アジェンダ1. Feature Flagsはなぜ必要か？2. AWS AppConfig で Feature Flags の仕組みを整備した話3. Feature Flags の仕組みを運用してみての学びa. よかったことb. 今後の課題
よかったこと導入しやすさ● ３-4 人で、１スプリント（１week) 程度の作業ボリュームで導入できた● いい感じのエコシステムが揃っていた○ AWS AppConfig agent■ Local Cache の管理などを実装しなくてよかった○ Terraform Cloud○ TanStack Query■ （AWS AppConfig とは直接関係ないが、Local Cache 管理の点で便利だったため、記載）
よかったこと導入した効果（効果を感じている点）● Toggle Configuration が一元管理されている○ 認知コストが下がった○ ロールアウト時の修正漏れ防止● ロールアウトのスケジュールが柔軟に設定できるようになった○ （現状は、毎週火・木に定期デプロイ）○ このタイミングとロールアウトのタイミングを合わせる必要が無くなった
➢ Feature Flags のよさを活かし、よりデプロイの頻度を上げる➢ AWS AppConfig のよさを活かし、サービスの変化・成長に適応する➢ Feature Flags の濫用を防ぎ、技術負債を作らない仕組み今後の課題
Feature Flags のよさを活かし、よりデプロイの頻度を上げるデプロイとロールアウトの分離が加速したので、デプロイの頻度を上げたい！● Feature Flags 以外の整備も必要○ 派生元ブランチにマージ後の、手動の動作検証がブロッカー● コードが複雑化している部分では、Feature Flags自体を定義しづらい。○ Feature Flags の仕組みがあっても制御しづらい○ 要リファクタリング今後の課題
今後の課題AWS AppConfig のよさを活かし、サービスの変化・成長に適応するDeployment strategy について● 現状は、即座に全コンテナに設定が反映○ Deployment time、Bake time が 0 min.● Deployment strategy を見直したら、ロールバック時の ToggleConfiguration の値の管理方法も再考○ Github Repository 上の値と、AWS AppConfig 上の値が乖離するため
今後の課題AWS AppConfig のよさを活かし、サービスの変化・成長に適応するバリデーションについて● 現状では、JSON スキーマによるバリデーションで十分● AWS Lambda によるバリデーションも検討？○ 複雑または、不備があった際に業務影響が大きな Toggle Configurationを使用したいケースがあれば...
今後の課題Feature Flags の濫用を防ぎ、技術負債を作らない仕組み● Feature Flags を定義しすぎない・長い期間使わない仕組み○ 定義する数・期間に制限を設ける
「3. Feature Flags の仕組みを運用してみての学び」まとめ➢ AWS AppConfig を利用した Feature Flags の仕組みはエコシステムが充実しており、妥当な期間で導入できた！➢ 導入前目的としていた、Toggle Configuration の一元管理やデプロイに依存しないロールアウトは実現できた！➢ 一方で、Feature Flags の利点や、AWS AppConfig の長所は今後もっと生かす余地がある！
おわりWe are hiring !!カミナシ Entrance book エンジニア
おわりご清聴ありがとうございました！
Further readingFeature Flags 関係- https://martinfowler.com/articles/feature-toggles.html- https://semaphoreci.com/blog/feature-flags- https://codezine.jp/article/detail/14114- https://www.harness.io/blog/what-are-feature-flagsCI/CD 関係- https://semaphoreci.com/blog/2017/07/27/what-is-the-difference-between-continuous-integration-continuous-deployment-and-continuous-delivery.html- https://trunkbaseddevelopment.com/AWS AppConfig 関係- https://kaminashi-developer.hatenablog.jp/entry/2023/07/31/122831- https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html
kaminashi
orgachem
you
muziyoshiz
s2terminal
yoshiitaka
oracle4engineer
simosako
sat
yuya4
sorami
karamem0
leveragestech
paulrobertlloyd
mongodb
notwaldorf
matthewcrist
gr2m
chriscoyier
eileencodes
jensimmons
aleyda
marcduiker
jnunemaker
ufuk