はじめに
AWS Summit2024のAWS コンテナサービスから考える安全なアプリケーションデリバリー(AWS-34)を受講しました。その内容を元に、現在私が携わっているプロダクトでどのように活用できるかを考えます。
担当プロダクト
現在私が携わっているのは社内の営業向けに求人広告の作成を手助けするプロダクトです。
今年の夏にリリースしたばかりで、プロダクトとしてはまだ0→1のフェーズであり、一部の営業さんに使って貰いながらニーズを検証し、日々機能の追加や修正を行なっています。そのため開発チームも小さく、実際にコーディングを行なっているのは私を含め２名です。
フロントエンドにNuxt.jsを使用しており、ECSにデプロイしているため本セッションの内容を今後の開発にどのように活用できるか考えたいと思います
Note：担当プロダクト
- 社内向け
- 0→1フェーズ
- 小さく作って検証
- 小さな開発チーム
安全なアプリケーションデリバリーとは
ずばり、「障害などが発生した際の影響を最小限に抑えるデリバリー」のこと。
Note：背景
コードレビューや検証環境での結合試験を入念に行なってもバグが混入してしまう可能性はある。
→ リスクを0にすることは出来ない
安全なデリバリーが行えると何が良いか?
→ 安心してデリバリー頻度を上げることが出来る
≒ 機能追加・改修のスピードを上げることが出来る
線形デプロイ / Canaryデプロイ
安全なアプリケーションデリバリーを行うための代表的な手法として、線形デプロイとCanaryデプロイがあります。
これらは図の通り、ALBなどを利用して、段階的に新バージョンのアプリケーションを公開していく手法です。現行バージョンへのトラフィックを減らしつつ、新バージョンへのトラフィックを増やしていくことで、新バージョンを利用するユーザーを増やしていき、最終的に完全に移行します。
新バージョンで障害が発生した場合は、自動ロールバックを行い全てのトラフィックを現行バージョンへ戻します。（自動ロールバックについては本記事では紹介しないので、詳しく知りたい方はセッションを受講してみてください。）
線形デプロイ
線形デプロイは名前の通り、予め設定した比率で少しづつ新バージョンへのトラフィックを増やしていきます。比率は10%ずつなどの数値をロードバランサーに設定可能で、慎重さをより重視する場合はこの線形デプロイが適していると言えます。
Canaryデプロイ
Canaryデプロイは少しずつではなく、一気に新バージョンへ切り替えます。初めに10%などの少数トラフィックに対してのみ新バージョンを公開し、問題がなければ段階を踏まずに100%に新バージョンを公開します。線形デプロイよりも簡易で、線形デプロイと比較して工数も少なく済みます。
0→1プロダクトにはどちらが良いか？
0→1プロダクトにはCanaryデプロイが適しているでしょう。一部のトラフィックで新バージョンの動作を確認しつつも、工程が少ないことでスピードも担保できます。まだユーザーが少ない0→1プロダクトや社内向けプロダクトなど、障害発生の影響の小さいものに適していると言えます。
対する線形デプロイは慎重に動作確認を行いながらバージョンを切り替えていきます。そのため、既にある程度の数のアクティブユーザーがいる成熟したプロダクトや商用プロダクトなど、障害が発生した場合の影響が大きいものに適していると言えます。
機能フラグ
機能フラグはアプリケーションコード内に、リクエストに対する新機能へのアクセスを制御する条件式を予め記述しておき、アクセス制御（機能フラグ）のON・OFFをクラウド側の設定で行うものです。
線形/Canaryデプロイではトラフィックの割合を操作出来るだけだったのに対し、機能をフラグを使えばユーザーの属性を見て、特定のユーザーにのみ新機能を公開できます。例えばユーザーのIDやメールアドレスなどを用いて特定のユーザーのみに新機能へのアクセスを許可します。
ただデメリットとしては、新機能へのアクセス制御の条件式をアプリケーションコードに記述する必要があり、コードの見通しが悪くなるだけでなく、後から条件式の削除を行う必要があるので保守性も下がってしまいます。
0→1プロダクトでの使い道
0→1のプロダクトでは、一部ユーザーに対する新機能のフィジビリなどに利用することが出来るかもしれません。匿名ではない登録ユーザーが多いプロダクトの方が属性でユーザーを選別し易いため、特に社内向けプロダクトには向いていると思います。
私が担当している営業向けプロダクトでも、例えば〜営業部１課にだけやインサイドセールス課の営業さんにだけなど、特定の属性にだけユーザーを絞ってフィジビリを行い、新機能の効果検証等を行うことが出来るでしょう。
まとめ
ここまで『AWS コンテナサービスから考える安全なアプリケーションデリバリー(AWS-34)』を受講して得た知識をもとに、それを私の担当する社内向け0→1プロダクトでどのように活用できるかを考えてきました。まとめとしては以下のようになります。
「社内向け0→1プロダクト」の安全なデプロイ手法
Canaryデプロイが最適
→ トラフィック制御による段階的なデリバリーで安全性を担保しつつも少ない工程でスピーディーなデプロイ
「社内向け0→1プロダクト」の効果的な機能検証の手法
機能フラグが便利
→ ユーザーの属性を見て特定の人にだけ新機能を公開できるため、現プロダクトを動かしながら新機能のフィジビリなどを並行して行うことが出来る
参考
AWS Summit2024のAWS コンテナサービスから考える安全なアプリケーションデリバリー(AWS-34)での受講内容を元に記事を作成しております。また記事内のスライドは全てこちらからの引用になります。