AWS AppConfig で低リスク・低ストレスなロールアウトを実現した話 / A story about low-risk, low-stress rollouts with AWS AppConfig

by 株式会社カミナシ

Slide 1

Slide 1 text

AWS AppConfig で低リスク・低ストレスなロールアウトを実現した話  株式会社カミナシソフトウェアエンジニア　　　　　　　　佐藤丈生

Slide 2

Slide 2 text

自己紹介株式会社カミナシソフトウェアエンジニア佐藤丈生(Tomoki Sato) 経歴) 　パッケージソフト開発（Java, 普通のJS 中心）　　→ 2022/12 株式会社カミナシ　カミナシでは、React / React Native (iOS) / Golang / AWS

Slide 3

Slide 3 text

はじめに会社 & プロダクトについて

Slide 4

Slide 4 text

会社 & プロダクト紹介日常はITに溢れているのに、仕事場は紙ばかりで非効率。今日も作業現場で働く人たちは、十分に才覚を発揮できていない。そんな3,900万人の埋もれたエネルギーを、私たちが解き放つ。誰もが享受するべき当たり前を、すべての現場の人たちに届けたい。効率的な作業、見事な成果、腕のなる仕事、豊かな人生。これらはきっとつながっているから。ノンデスクワーカーの才能を解き放つ Mission

Slide 5

Slide 5 text

会社 & プロダクト紹介誰でも正しい手順で作業を実行カミナシは、モバイルアプリを使って、現場業務のムダを自動化するサービスです。現場ＤＸプラットフォーム「カミナシ」管理者の代わりに作業をチェックデータから自動で集計・報告書を作成改善活動をサポート

Slide 6

Slide 6 text

会社 & プロダクト紹介

Slide 7

Slide 7 text

会社 & プロダクト紹介

Slide 8

Slide 8 text

はじめにここから本題

Slide 9

Slide 9 text

セッション対象者 ➢ 実例を通じて、AWS AppConﬁg で Feature Flags を実装するイメージを持ちたい方 ➢ Feature Flags を用いた低リスク・低ストレスなサービスのロールアウトを実現したい方 ➢ AWS AppConﬁg の特徴やその使い所（使用例）について知りたい方セッション対象者とゴール

Slide 10

Slide 10 text

ゴール ➢ 今後 Feature Flags などの仕組みを設計するときに AWS AppConfig を設計の選択肢の１つにできること話すこと ➢ Feature Flags の概要や、必要とされる理由 ➢ AWS AppConfig ならではの特徴や、その利用イメージ話さないこと ➢ Feature Flags に関する網羅的な説明 ➢ AWS AppConfig の詳細な仕様や、使用する際の具体的な手順セッション対象者とゴール

Slide 11

Slide 11 text

アジェンダ 1. Feature Flags はなぜ必要か？ a. デプロイとロールアウトの分離の重要性 b. Feature Flags とは？ c. カミナシにとっての Feature Flags 2. AWS AppConfig で Feature Flags の仕組みを整備した話 a. AWS AppConfig とは？ b. カミナシでの AWS AppConfig 利用例 3. Feature Flags の仕組みを運用してみての学び a. よかったこと b. 今後の課題

Slide 12

Slide 12 text

アジェンダ 1. Feature Flags はなぜ必要か？ a. デプロイとロールアウトの分離の重要性 b. Feature Flags とは？ c. カミナシにとっての Feature Flags 2. AWS AppConﬁg で Feature Flags の仕組みを整備した話 3. Feature Flags の仕組みを運用してみての学び

Slide 13

Slide 13 text

Slide 14

Slide 14 text

デプロイとロールアウトの分離の重要性デプロイとロールアウトの分離とは？デプロイ ➢ 運用環境のソフトウェアのバージョンを変え、稼働させること ➢ 例）コンテナイメージをビルドし、ECR に push。それを元に、ECS タスクを(再)起動するロールアウト ➢ 機能を、利用者の一部 or 全体に利用可能にすること ➢ 例）新規開発した機能Xを、ユーザーが利用可能な状態にすること

Slide 15

Slide 15 text

デプロイとロールアウトの分離の重要性デプロイとロールアウトの分離とは？ 💡本セッションでは、デプロイとの区別を明確にするために、「機能を、利用者の一部 or 全体に利用可能にすること」という意味合い対して、「リリース」ではなく「ロールアウト」という言葉を使用します。

Slide 16

Slide 16 text

デプロイとロールアウトの分離の重要性デプロイとロールアウトの分離とは？ ➢ デプロイとロールアウトが分離していない状態 ○ 例）コンテナイメージをビルドし ECR に push。それを元に、ECS タスクを(再) 起動すると、新規開発した機能Xを、ユーザーが利用可能になる ➢ デプロイとロールアウトが分離した状態 ○ 例）コンテナイメージをビルドし ECR に push。それを元に、ECS タスクを(再) 起動しても、新規開発した機能Xは、ユーザーには公開されない ○ 例）コンテナイメージのビルド〜 ECS タスクの(再)起動を行わなくても、機能X の、公開・非公開状態が切り替えられる

Slide 17

Slide 17 text

デプロイとロールアウトの分離の重要性なぜ、デプロイとロールアウトの分離が重要なのか？開発視点 (開発効率・作業負荷軽減・安定運用） ➢ CD(継続的デリバリー)、継続的デプロイメントに、事実上不可欠であるため ➢ ロールアウト時のリスクを低減させるためビジネス視点（ビジネス上の施策・戦略） ➢ 開発を妨げずに、適切なタイミングでロールアウトできるようにするため

Slide 18

Slide 18 text

デプロイとロールアウトの分離の重要性なぜ、デプロイとロールアウトの分離が重要なのか？ 👀開発視点 (開発効率・作業負荷軽減・安定運用） ➢ CD(継続的デリバリー)、継続的デプロイメントに、事実上不可欠であるため ○ コード変更を一日複数回メインブランチにマージしたい！ ○ 高頻度でプロダクション環境にデプロイしたい！ ○ その一方で、ある程度の期間を要する機能追加・変更は発生しうる... ➢ ロールアウト時のリスクを低減させるため ○ ロールアウト後に、トラブルが起きたら、即座にその機能をオフにしたい！

Slide 19

Slide 19 text

デプロイとロールアウトの分離の重要性なぜ、デプロイとロールアウトの分離が重要なのか？ 👀ビジネス視点（ビジネス上の施策・戦略） ➢ 開発を妨げずに、適切なタイミングでロールアウトできるようにするため ○ 開発チームがデプロイしたいタイミングと、ビジネス上、機能をユーザーに公開したいタイミングは異なる ■ 例：ユーザーへの公開は、マーケティングキャンペーンと連動させたい

Slide 20

Slide 20 text

アジェンダ 1. Feature Flagsはなぜ必要か？ a. デプロイとロールアウトの分離の重要性 b. Feature Flags とは？ c. カミナシにとっての Feature Flags 2. AWS AppConﬁg で Feature Flags の仕組みを整備した話 3. Feature Flags の仕組みを運用してみての学び

Slide 21

Slide 21 text

Feature Flags とは？ ➢ コードを修正せずに、システムの振る舞いを変える技術（参考: https://martinfowler.com/articles/feature-toggles.html)

Slide 22

Slide 22 text

Feature Flags とは？ ➢ コード上の特定の箇所を、条件に応じて ON or OFF にできるイメージ

Slide 23

Slide 23 text

Feature Flags とは？ロールアウトされた状態ロールアウトされていない状態

Slide 24

Slide 24 text

Feature Flags とは？ Feature Flags でデプロイとロールアウトの分離を実現できるさらにこんなこともできる......🎉 例：ユーザーの属性に応じて、機能の利用可否を切り替える ➢ 開発視点では、ロールアウト時のリスクをさらに低減できる ○ カナリアリリース ➢ ビジネス視点では、完全なロールアウトの前に、検証プロセスを回せる ○ A / B テスト ○ β リリース＊一般的に「カナリアロールアウト」や「β ロールアウト」のような言い方はしないと感じたのでここでは「リリース」という言葉を使っています

Slide 25

Slide 25 text

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)

Slide 26

Slide 26 text

アジェンダ 1. Feature Flagsはなぜ必要か？ a. デプロイとロールアウトの分離の重要性 b. Feature Flags とは？ c. カミナシにとっての Feature Flags 2. AWS AppConﬁg で Feature Flags の仕組みを整備した話 3. Feature Flags の仕組みを運用してみての学び

Slide 27

Slide 27 text

カミナシにとっての Feature Flags Feature Flags のメリットを感じていること ➢ ステークホルダーへの影響などを考慮しながら、ロールアウトのタイミングを調整できる ○ フィールドワーカーの中には、Saas やアプリなどツールに不慣れな方も多い ➢ 一部のお客様へのβ版提供により、機能をブラッシュアップできる ○ 別環境を構築せずに、プロダクション環境を使用 ○ 本番データで、質の高いβテスト（データ壊れないよう注意だが...) ➢ 開発に数週間・数ヶ月かかるような機能も、メインブランチにマージ & プロダクションへデプロイできる ○ 開発の効率や、エンジニアの作業負荷の軽減

Slide 28

Slide 28 text

カミナシにとっての Feature Flags Feature Flags のメリットを感じていること (Pick up) ➢ プロダクション環境・実業務のデータで、β版を試していただく ● β版環境・お試しデータは、 ■ お客様が業務がイメージしづらい・実業務での使用はほぼ不可 ● プロダクション環境・実業務データは、 ■ お客様が実業務をイメージしやすい・実業務で使用可の場合も ■ （もちろん実業務データに悪影響がでないよう注意 & 期待値調整必須） →　フィードバックがたくさん🎉 →　Feature Flags で一部ユーザーのみに柔軟にロールアウトできるおかげ

Slide 29

Slide 29 text

「1. Feature Flagsはなぜ必要か？」まとめ ➢ 開発・ビジネスの両方の視点で、デプロイとロールアウトの分離は重要 ➢ Feature Flags により、デプロイとロールアウトの分離が実現できる ➢ カミナシでは、開発・ビジネス両面で、Feature Flags のメリットを享受している

Slide 30

Slide 30 text

次章以降の説明のための補足 (参考：https://martinfowler.com/articles/feature-toggles.html） Toggle Configuration （機能ONにするユーザーの属性値）

Slide 31

Slide 31 text

アジェンダ 1. Feature Flagsはなぜ必要か？ 2. AWS AppConfig で Feature Flags の仕組みを整備した話 a. AWS AppConfig とは？ b. カミナシでの AppConfig 利用例 3. Feature Flags の仕組みを運用してみての学び

Slide 32

Slide 32 text

Slide 33

Slide 33 text

AWS AppConfig とは？全体イメージ AWS AppConfig を使用することにより、「アプリケーションの設定」を作成・管理し、素早く「デプロイ」できます（引用元：https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html 佐藤意訳）

Slide 34

Slide 34 text

AWS AppConﬁg とは？全体イメージ

Slide 35

Slide 35 text

AWS AppConﬁg とは？全体イメージ ● 「アプリケーションの設定」を作成・更新し、「デプロイ」（開始）する ○ 「アプリケーションの設定」：　Feature Flags の文脈では、Toggle Conﬁguration ● アプリケーションは、「デプロイ」された「アプリケーションの設定」を参照する ○ 「デプロイ」：　「アプリケーションの設定」を、アプリケーションが参照できる状態にすること

Slide 36

Slide 36 text

AWS AppConﬁg とは？全体イメージ ➢ Feature Flags の文脈：Toggle Conﬁguration が「アプリケーションの設定」に相当する Toggle Configuration （機能ONにするユーザーの属性値）

Slide 37

Slide 37 text

AWS AppConﬁg とは？「デプロイ」(deployment) について

Slide 38

Slide 38 text

AWS AppConﬁg とは？「デプロイ」(deployment) について ● イメージ：　ローリングアップデートのようなことができる ○ Deployment strategy によって変更の反映をコントロールできる ■ 例えば、複数のアプリケーションに、徐々に新しい設定を参照させる、ことができる ○ Deployment time + Bake time 内であれば、ロールバックが可能 ■ トラブル時にロールバック ■ システムメトリクスなどを観ながら、慎重にロールアウト

Slide 39

Slide 39 text

AWS AppConfig とは？ AWS AppConfig を使うと何が嬉しいの？ ● 👀「アプリケーションの設定」を更新する時のバリデーション ○ JSON スキーマ・AWS Lambda ● 「アプリケーションの設定」の変更をアプリケーションに迅速に反映 ○ 「アプリケーションの設定」がAWS AppConfigにより一元管理 ● デプロイ・再起動なしで「アプリケーションの設定」の更新を反映 ● 👀Deployment Strategy により、設定変更の反映のされ方をコントール ○ トラブル時にロールバック ○ システムメトリクスなどを観ながら、慎重にロールアウト

Slide 40

Slide 40 text

補足　典型的なアプリケーションからの参照方法 AWS AppConﬁg とは？

Slide 41

Slide 41 text

AWS AppConfig とは？補足　典型的なアプリケーションからの参照方法 ● イメージ： Local Cacheを参照する。Local Cache 更新はバックグラウンドスレッド ● バックグラウンドスレッド ○ StartConfigurationSession（＊API)：　セッション開始 ○ GetLatestConfiguration（＊API)：　ポーリング ○ 「アプリケーションの設定」に変更があれば、Local Cache を更新する ● アプリケーション ○ 設定を参照する箇所では、Local Cache を参照する＊API：AWS AppConfig のAPI

Slide 42

Slide 42 text

アジェンダ 1. Feature Flagsはなぜ必要か？ 2. AWS AppConfig で Feature Flags の仕組みを整備した話 a. AWS AppConfig とは？ b. カミナシでの AWS AppConfig 利用例 3. Feature Flags の仕組みを運用してみての学び

Slide 43

Slide 43 text

カミナシでの AWS AppConﬁg 利用例弊社でどのように AWS AppConﬁg を利用したのかについて、より詳細は、弊社テックブログもご確認ください。 →　https://kaminashi-developer.hatenablog.jp/entry/2023/07/31/122831

Slide 44

Slide 44 text

カミナシでの AWS AppConﬁg 利用例誰でも正しい手順で作業を実行カミナシは、モバイルアプリを使って、現場業務のムダを自動化するサービスです。 (再掲)現場ＤＸプラットフォーム「カミナシ」管理者の代わりに作業をチェックデータから自動で集計・報告書を作成改善活動をサポート Web 管理者向け画面（React (SPA)) Mobile 記録者向け画面（React Native)

Slide 45

Slide 45 text

カミナシでの AWS AppConﬁg 利用例カミナシのアーキテクチャ概要

Slide 46

Slide 46 text

カミナシでの AWS AppConﬁg 利用例カミナシのアーキテクチャ概要 ● ブラウザからアクセスする「Web」アプリケーション(React。SPA) ● 「Mobile」アプリケーション（React Native。iOSネイティブアプリ） ● フロントエンドからアクセスされる「API Server」 ● API サーバーは、AWS Fargate 上のコンテナで稼働する Go lang アプリケーション

Slide 47

Slide 47 text

カミナシでの AWS AppConﬁg 利用例 AWS AppConﬁg 利用前の状態・課題

Slide 48

Slide 48 text

カミナシでの AWS AppConfig 利用例 AWS AppConfig 利用前の状態・課題 ● ソースコード上に Toggle Configuration をハードコーディング ● 課題 ○ ロールアウトのために、デプロイが必要 ○ 一元管理が難しい　→　認知コスト・ロールアウト時の修正漏れ

Slide 49

Slide 49 text

カミナシでの AWS AppConﬁg 利用例再掲（Toggle Conﬁguration)

Slide 50

Slide 50 text

カミナシでの AWS AppConﬁg 利用例アーキテクチャ（アプリケーション周り全体）

Slide 51

Slide 51 text

カミナシでの 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」にアクセス

Slide 52

Slide 52 text

アーキテクチャ（アプリケーション周りフロントエンド） ● 各コンポーネントでは、カスタムフックを用いて、機能の利用可否を判定 ○ API コールのタイミングを意識したくない ○ コンポーネントのレンダリング毎に API コールされるのを避けたい ○ → Front End は Front End で Local Cache を管理 ● TanStack Query のキャッシュ機構を用いて実装カミナシでの AWS AppConﬁg 利用例

Slide 53

Slide 53 text

カミナシでの AWS AppConﬁg 利用例 AWS AppConﬁgの設定を IaC で管理する

Slide 54

Slide 54 text

カミナシでの AWS AppConfig 利用例 AWS AppConfigの設定を IaC で管理する ● Toggle Configurationは Terrafrom で定義し、Github Repository で管理 ○ Toggle Configuration の変更履歴を残し、レビューのプロセスを通したい ○ ロールアウト、ロールバックしたい時は、PR を出す ● Terraform Cloud 上で、Plan実行 → Apply により、「デプロイ」開始 ○ main ブランチへのマージがトリガー ● Deployment time、Bake time ともに 0 のため、即時に全コンテナに反映

Slide 55

Slide 55 text

カミナシでの AWS AppConfig 利用例他の選択肢について Toggle Configuration をどこに格納するか？ ● RDS、DynamoDB、S3など何かしらの外部ストレージ ○ AWS AppConfig に比べ自由度が高いが、そのぶん設計・実装・管理が難しい ● Amazon CloudWatch Evidently を利用する ○ 自由度、エコシステムなどが、AWS AppConfig の方がふさわしかった ● 環境変数（AWS Systems Manager Parameter Storeなど） ○ タスク再起動が必要。構造化データを持たせる辛み

Slide 56

Slide 56 text

カミナシでの AWS AppConfig 利用例他の選択肢について Front End からどうやって AWS AppConfig の設定を取得するか？ ● Amazon Congito を活用し、Front End から直接 AWS AppConfig の API にアクセスする ○ API サーバーにエンドポイントを定義する方が、（現状では）シンプルかつ、実装・運用しやすい

Slide 57

Slide 57 text

カミナシでの AWS AppConfig 利用例活かせている AWS AppConfig の良さ ● ✅「アプリケーションの設定」を更新する時のバリデーション ○ ✅ JSON スキーマ・AWS Lambda ● ✅「アプリケーションの設定」の変更をアプリケーションに迅速に反映 ○ ✅「アプリケーションの設定」がAWS AppConfigにより一元管理 ● ✅ デプロイ・再起動なしで「アプリケーションの設定」の更新を反映 ● 🔴 Deployment Strategy により、設定変更の反映のされ方をコントール ○ トラブル時にロールバック ○ システムメトリクスなどを観ながら、慎重にロールアウト＊AWS AppConfig の良さを全て活かしきれているわけではない

Slide 58

Slide 58 text

「2. AWS AppConfig で Feature Flags の仕組みを整備した話」まとめ ➢ AWS AppConfig 使うことにより、 ○ 設定の更新時、バリデーションによりエラーを低減 ○ 設定を一元管理 ○ 設定の更新時にアプリケーションの停止も不要 ○ Deployment Strategy により、設定更新の反映のされ方をコントロール ➢ カミナシでは、AWS AppConfig を利用した仕組みを整備し、以下を実現 ○ Toggle Configuration の一元管理 ○ デプロイに依存しないロールアウト

Slide 59

Slide 59 text

アジェンダ 1. Feature Flagsはなぜ必要か？ 2. AWS AppConﬁg で Feature Flags の仕組みを整備した話 3. Feature Flags の仕組みを運用してみての学び a. よかったこと b. 今後の課題

Slide 60

Slide 60 text

Slide 61

Slide 61 text

よかったこと導入しやすさ ● ３-4 人で、１スプリント（１week) 程度の作業ボリュームで導入できた ● いい感じのエコシステムが揃っていた ○ AWS AppConﬁg agent ■ Local Cache の管理などを実装しなくてよかった ○ Terraform Cloud ○ TanStack Query ■ （AWS AppConﬁg とは直接関係ないが、Local Cache 管理の点で便利だったため、記載）

Slide 62

Slide 62 text

よかったこと導入した効果（効果を感じている点） ● Toggle Conﬁguration が一元管理されている ○ 認知コストが下がった ○ ロールアウト時の修正漏れ防止 ● ロールアウトのスケジュールが柔軟に設定できるようになった ○ （現状は、毎週火・木に定期デプロイ） ○ このタイミングとロールアウトのタイミングを合わせる必要が無くなった

Slide 63

Slide 63 text

Slide 64

Slide 64 text

➢ Feature Flags のよさを活かし、よりデプロイの頻度を上げる ➢ AWS AppConﬁg のよさを活かし、サービスの変化・成長に適応する ➢ Feature Flags の濫用を防ぎ、技術負債を作らない仕組み今後の課題

Slide 65

Slide 65 text

Feature Flags のよさを活かし、よりデプロイの頻度を上げるデプロイとロールアウトの分離が加速したので、デプロイの頻度を上げたい！ ● Feature Flags 以外の整備も必要 ○ 派生元ブランチにマージ後の、手動の動作検証がブロッカー ● コードが複雑化している部分では、Feature Flags自体を定義しづらい。 ○ Feature Flags の仕組みがあっても制御しづらい ○ 要リファクタリング今後の課題

Slide 66

Slide 66 text

今後の課題 AWS AppConfig のよさを活かし、サービスの変化・成長に適応する Deployment strategy について ● 現状は、即座に全コンテナに設定が反映 ○ Deployment time、Bake time が 0 min. ● Deployment strategy を見直したら、ロールバック時の Toggle Configuration の値の管理方法も再考 ○ Github Repository 上の値と、AWS AppConfig 上の値が乖離するため

Slide 67

Slide 67 text

今後の課題 AWS AppConﬁg のよさを活かし、サービスの変化・成長に適応するバリデーションについて ● 現状では、JSON スキーマによるバリデーションで十分 ● AWS Lambda によるバリデーションも検討？ ○ 複雑または、不備があった際に業務影響が大きな Toggle Conﬁguration を使用したいケースがあれば...

Slide 68

Slide 68 text

今後の課題 Feature Flags の濫用を防ぎ、技術負債を作らない仕組み ● Feature Flags を定義しすぎない・長い期間使わない仕組み ○ 定義する数・期間に制限を設ける

Slide 69

Slide 69 text

「3. Feature Flags の仕組みを運用してみての学び」まとめ ➢ AWS AppConfig を利用した Feature Flags の仕組みはエコシステムが充実しており、妥当な期間で導入できた！ ➢ 導入前目的としていた、Toggle Configuration の一元管理やデプロイに依存しないロールアウトは実現できた！ ➢ 一方で、Feature Flags の利点や、AWS AppConfig の長所は今後もっと生かす余地がある！

Slide 70

Slide 70 text

おわり We are hiring !! カミナシ Entrance book エンジニア

Slide 71

Slide 71 text

おわりご清聴ありがとうございました！

Slide 72

Slide 72 text

Further reading Feature 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-flags CI/CD 関係 - https://semaphoreci.com/blog/2017/07/27/what-is-the-difference-between-continuous-integration-conti nuous-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