はじめに

AWSにてデプロイのリスクを緩和するにあたり「Well-Architected Framework 運用上の優秀性」への考慮は大変重要です。 今回は、AWS Summit Japan「Amazon ECSから考える安全なアプリケーションデリバリー」をベースに、デプロイのリスクを緩和する方法をご紹介いたします。

目次

• 安全なアプリケーションデリバリーとは
• 線形デプロイ/Canaryデプロイ
• 機能フラグ(Feature Flag)
• 自動ロールバックの必要性
• まとめ

安全なアプリケーションデリバリーとは

AWSの定義する「安全なアプリケーションデリバリー」とは意図しない障害が発生した際の影響範囲を最小限にすることです。 残念ながら、システムを運用する上で、意図しない障害が発生する可能性をゼロにすることはできません。 だからこそ「いかに影響範囲を最小限にするか？！」に着目すべきなのだと思います。

いかに影響範囲を最小限にするか？

AWSはこの課題を解決するためにデリバリーによる新機能の公開を少数のユーザから段階的に行う手法を推奨しています。

新機能を段階的に公開する手法

1. 線形デプロイ/Canaryデプロイ
2. 機能フラグ(Feature Flag)

それでは、それぞれの手法を詳しく見ていきたいと思います。

1. 線形デプロイ/Canaryデプロイ

線形デプロイおよびCanaryデプロイとは、ユーザからのトラフィックの一部分のみを新バージョンのアプリケーションへアクセス許可する手法です。

線形とCanaryの違い

線形デプロイ
線形デプロイとは、デリバリーされた新機能にアクセス許可するトラフィックの比率を10% → 20% → 30%...と線形的に増やし、正常性確認を慎重に行う手法です。

Canaryデプロイ
Canaryデプロイとは、デリバリーされた新機能にアクセス許可するトラフィックの比率を10%程度の少数に定め、その小規模なトラフィックに対して正常性が確認でき次第、全てのトラフィックを新機能にアクセス許可する慎重かつ大胆な手法です。

線形/CanaryデプロイのAmazon ECSでの実践

それでは、線形デプロイ/CanaryデプロイのAmazon ECSでの実践について詳しく見ていきたいと思います。

必要となるAWSのリソース

• AWS ALB
  → ユーザからのトラフィックの一部を新バージョンのアプリケーションにルーティングさせる役割
  
• Amazon ECS
  → 現バージョンで稼働させているアプリケーションはそのまま稼働させつつ新バージョンのアプリケーションも追加で稼働させる役割
  
• AWS CodeDeploy
  → 線形デプロイ/Canaryデプロイの司令塔
  → AWS ALBにおけるトラフィックの比率管理およびAmazon ECSにおけるサーバの並行稼働を実現する役割
  

フロー

1. 新バージョンのアプリケーションをデプロイ
   → AWS CodeDeployがAmazon ECSに自動でデプロイ
   
2. ユーザからのトラフィックの一部を新バージョンのアプリケーションにルーティング
   → AWS CodeDeployがAWS ALBのトラフィックの比率を自動で変更
   
3. 全てのユーザからのトラフィックを新バージョンのアプリケーションにルーティング
   → AWS CodeDeployがAWS ALBのトラフィックの比率を自動で変更
   
4. 現バージョンのアプリケーションを停止
   → AWS CodeDeployがAmazon ECSを自動で停止
   

上記のようなフローで、線形デプロイ/CanaryデプロイをAmazon ECSにて実践することができます。

ALBの仕組み

AWS ALBはターゲットグループと重み(トラフィックの比率)を設定することができます。
例えば、現バージョンのターゲットグループに80%の重みを、新バージョンのターゲットグループに20%の重みを設定します。 そうすることで、ユーザからのトラフィックの一部分のみを新バージョンのアプリケーションへアクセス許可することが可能です。 しかしながら、その設定だけではユーザの割り当て先が毎回バラバラになってしまう課題が残ります。
そこで登場するのが、AWS ALBの機能の内の1つであるスティッキーセッションです。

スティッキーセッション
セッションが有効な間、クライアントとサーバーを常に一対一で接続させる役割

スティッキーセッションを利用することで、ユーザの割り当て先を固定し、線形/CanaryデプロイのAmazon ECSでの実践を可能にします。

2. 機能フラグ(Feature Flag)

機能フラグ(Feature Flag)とは、特定の属性を持つユーザからのトラフィックのみに対して新バージョンのアプリケーションへアクセス許可する手法です。 具体的には、アプリケーションコードに「機能フラグがONの場合にのみ実行されるロジック」を組み込み、機能フラグのON/OFFによりアプリケーションの振る舞いを切り替えます。

補足 : フラグ(Flag)とは、ONかOFFのどちらの状態かを判断するために使用する変数です。

アプリケーションコードに組み込むロジック

ユーザからのトラフィックの情報に含まれるuserID(Flag)が、機能フラグ(FlagGroup)に含まれている場合にのみ、新機能へのルーティングがONになります。 これにより、ユーザID単位での新機能へのON/OFFを制御することが可能になります。

機能フラグ(Feature Flag)のAmazon ECSでの実践

それでは、機能フラグ(Feature Flag)のAmazon ECSでの実践について詳しく見ていきたいと思います。

必要となるAWSのリソース

• AWS AppConfig
  → 機能フラグを管理する役割
  → アプリケーションコードに組み込むロジックの保存や配布を簡素化する役割
  
• Amazon ECS
  → 機能フラグを定期的に取得するためのサイドカーコンテナ(AppConfigエージェント)を稼働させる役割
  
• AppConfigエージェント(サイドカーコンテナ)
  → アプリケーションの代わりに機能フラグを定期的に取得する役割
  → アプリケーションが直接的にAWS AppConfigを叩く必要がなくなり、アプリケーションコードをよりシンプルに書くことが可能
  

フロー

1. 新機能を含むアプリケーションコードを本番環境にデプロイ
   → AWS AppConfigに保存されている機能フラグはOFFの状態
   
2. 新機能を公開したい一部のユーザに対して機能フラグをONに変更
   → AWS AppConfigに保存されている機能フラグの値を更新
   
3. 機能フラグがアプリケーションに反映され一部のユーザに新機能が公開
   → AppConfigエージェント(サイドカーコンテナ)が非同期で機能フラグの値を取得しアプリケーションに反映
   
4. 全てのユーザに対して機能フラグをONに変更し、全体のユーザに新機能が公開
   

上記のようなフローで、機能フラグをAmazon ECSにて実践することができます。

自動ロールバックの必要性

ここまで、線形/Canaryデプロイと機能フラグについて見てきましたが、ここで自動ロールバックについて考えます。 線形/Canaryデプロイや機能フラグによる新機能の段階的公開では、問題が確認されたタイミングでロールバックを実施する必要があります。 もし、ロールバック作業が手動である場合、せっかく確保できた時間リソースを無駄にしてしまうことになります。

そこで登場するのが自動ロールバックです。

自動ロールバックのAmazon ECSでの実践

それでは、自動ロールバックのAmazon ECSでの実践について見ていきたいと思います。

必要となるAWSのリソース

• Amazon CloudWatch
  → AWS CodeDeployとAWS AppConfigと連携しALARM状態を伝達する役割
  
• Amazon ECS
  → 新バージョンのアプリケーションからメトリクスを発行する役割
  
• AWS CodeDeploy & AWS AppConfig
  → AWS CloudWatchのALARM状態時に自動でロールバックをする役割
  

フロー

1. 常時発行されるメトリクスに対してしきい値を設定
   → Amazon ECSから常時発行されるメトリクスに対してAmazon CloudWatchアラームを作成
   
2. しきい値を超えた場合のみ旧アプリケーションへの自動ロールバックを実行
   → AWS CodeDeploy & AWS AppConfigがAmazon CloudWatchのALARM状態を検知し自動ロールバックを実行
   

補足 : Amazon CloudWatchのデフォルト機能だけでは自動ロールバックをすることはできません。そのため、上記のようなアラームの作成が必要とされます。

上記のようなフローで、自動ロールバックをAmazon ECSにて実践することができます。

まとめ

ここまで「Amazon ECSから考える安全なアプリケーションデリバリー」について見てきました。 デプロイのリスクを緩和する方法のイメージは湧きましたでしょうか？

AWS CodeDeployやAWS App Configなど、マネージドなリソースを利用することで時間リソースを確保するだけではなく、オペレーションミスなどによるインシデントを未然に防ぐことができます。 AWSにおいて、アプリケーションのデリバリー頻度を上げつつ、そのデリバリーを安全に行いたい想いを持つエンジニアの方々には、ぜひ利用を試みていただきたいです！ ご精読いただき、ありがとうございました。