AWSコンテナサービスから考える安全なアプリケーションデリバリー

こんにちは。皆さんはアプリケーションのデリバリーを安全に行えていますか？最近はビジネスシーンの変化が激しく、ソフトウェア製品のアップデートや新機能のリリースなど、開発スピードが求められるケースが増えてきました。しかし、開発スピードを重視するあまり、セキュリティリスクへの対策がおろそかになっては本末転倒です。

本記事では、AWSのコンテナサービスであるAmazon ECSを用いて、アプリケーションのデリバリーを安全に行うための方法論と、具体的な実装方法について解説していきます。

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

まず、安全なアプリケーションデリバリーとは何でしょうか？アプリケーションデリバリーとは、開発したアプリケーションをユーザーが利用できるように、本番環境に配置し、公開するプロセス全体を指します。しかし、このプロセスにおいては、バグの混入や予期せぬ障害が発生するリスクが常に付きまといます。

もちろん、コードレビューや検証環境でのテストなど、事前にリスクを最小限に抑える努力は必要です。しかし、それでも完全にリスクを排除することはできません。

安全なアプリケーションデリバリーとは、障害などの意図しない状況が発生した場合の影響範囲を最小限に抑え、ユーザーへの影響を最小限に抑えることを目指す取り組みと言えます。

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

安全なアプリケーションデリバリーを実現するために、新機能を段階的に公開する方法は、主に以下の2つがあります。

• 線形デプロイ／カナリーデプロイ：ユーザーからのトラフィックの一部を新しいバージョンのアプリケーションにルーティングする方法です。
• 機能フラグ（Feature Flag）：特定の属性を持つユーザーに対してのみ、新しいバージョンの機能を有効にする方法です。
• 自動ロールバック: デプロイに失敗した場合に自動的に以前のバージョンに戻す方法です。

これらの方法はどちらも、トラフィックをコントロールすることで新機能を段階的に公開するという点では共通していますが、トラフィックの移行パターンが異なります。

デプロイ方法	説明
線形デプロイ（Linear Deploy）	新バージョンにアクセスするトラフィックの比率を線形に増やしていく方法
カナリーデプロイ（Canary Deploy）	少数のトラフィックを新バージョンにルーティングし、問題がないことを確認した後に、残りのトラフィックを一括で新バージョンに移行する方法

線形デプロイ／カナリーデプロイ

線形デプロイとカナリーデプロイは、アプリケーションの前段にロードバランサーなどを配置し、トラフィックを制御することで、新機能を段階的に公開する方法です。

例として、スポーツの実況サービスを構築するケースを考えてみましょう。このサービスでは、ユーザーがインターネットを経由してアクセスし、ELB (Application Load Balancer) を通じてアプリケーションにリクエストを送信します。

線形デプロイ

線形デプロイでは、新バージョンへのトラフィックの比率を段階的に増加させていきます。例えば、10%ずつトラフィックを新バージョンに移行していく場合、次のような流れになります。

1. 新バージョンのアプリケーションをデプロイします。
2. ELBの設定で、新バージョンにルーティングするトラフィックの比率を0%から10%に設定します。
3. 新バージョンで問題がないことを確認したら、20%、30%、…と10%刻みで比率を増加させていきます。
4. 最終的に、100%のトラフィックを新バージョンにルーティングします。

カナリーデプロイ

カナリーデプロイでは、少数のトラフィックを新バージョンにルーティングし、動作確認を行い問題がないことを確認してから、残りのトラフィックを一括で新バージョンに移行します。

1. 新バージョンのアプリケーションをデプロイします。
2. ELBの設定で、新バージョンにルーティングするトラフィックの比率を10%に設定します。
3. 新バージョンで問題がないことを確認したら、残りの90%のトラフィックを一括で新バージョンにルーティングします。

線形デプロイとカナリーデプロイは、ワークロードに応じて使い分けることができます。慎重に状況を見ながらデプロイしたい場合は線形デプロイ、ある程度のスピードを重視したい場合はカナリーデプロイを選択するといった形です。

Amazon ECSにおける線形デプロイ/カナリーデプロイ

Amazon ECSでは、ELB (Elastic Load Balancing) と連携することで、線形デプロイやカナリーデプロイを実現することができます。ELBは、1つのリスナーに対して、複数のターゲットグループ（アプリケーションの塊）を設定することができます。

ELBは、それぞれのターゲットグループに重み付けをして、リスナーが受けたリクエストを振り分けることができます。例えば、既存バージョンのアプリケーションに80、新バージョンに20といった重みを設定することができます。

また、ELBでは、ターゲットグループレベルのスティッキーセッション（振り分けの維持）を設定することができます。例えば、スティッキーセッションの維持時間中に新バージョンのターゲットグループにルーティングされたユーザーは、その時間中は新バージョンにルーティングされ続けるという振り分けの維持も設定できます。

機能フラグ（Feature Flag）

機能フラグは、ユーザーからのリクエストに含まれる特定の属性（例えばユーザーIDなど）に基づいて、新機能を段階的に公開する方法です。

例えば、電子書籍の販売サービスにおいて、新機能を段階的に公開したい場合、次のような流れになります。

1. 開発チームは、新機能のロジックをアプリケーションコードに含めますが、機能フラグはOFFの状態にして本番環境にデプロイします。
2. 新機能を有効にしたいユーザーのグループを、機能フラグのフラググループというフラグで設定します。
3. 新機能を有効にしたいユーザーからのリクエストに対して、アプリケーションは、外部の機能フラグを参照し、ONになっている場合は新機能のロジックを実行します。

このように、機能フラグを利用することで、アプリケーションコードを書き換えることなく、機能のON/OFFを切り替えることができます。

Amazon ECSにおける機能フラグの実装

Amazon ECSで機能フラグを利用するには、アプリケーションの外部で機能フラグを管理するためのコンポーネントが必要です。

本記事では、AWS AppConfigを利用して機能フラグを管理する方法を紹介します。AWS AppConfigは、機能フラグの保存や取得を簡単に行うことができます。

また、AWS AppConfigでは、アプリケーションからAWS AppConfigのAPIを直接叩いて値を取得する必要はなく、アプリケーションの代わりにAppconfig Agentというコンテナ化されたエージェントが値の取得を行ってくれます。

Amazon ECSでは、このAppconfig Agentをサイドカーコンテナとして追加することで、簡単に機能フラグの利用環境をセットアップすることができます。

自動ロールバック

新機能を段階的に公開する際には、問題が発生した場合に備えて、ロールバックを自動化する仕組みも重要です。

例えば、バージョン2のアプリケーションをデプロイしたものの問題があり、バージョン1にロールバックしたとしましょう。しかし、バージョン2では書き込みをJSON形式で行うように変更されていたため、バージョン1のアプリケーションでは、JSONファイルを読み込むことができず、問題が発生する可能性があります。

このように、ロールバックの前後で破壊的な変更を含まないようにすることが重要です。

Amazon ECSにおける自動ロールバック

Amazon ECSでは、AWS CodeDeployと連携することで、自動ロールバックを組み込むことができます。

AWS CodeDeployでは、デプロイ戦略として、2フェーズデプロイと呼ばれる段階的なデプロイを定義することができます。

このデプロイ戦略では、ロールバックのトリガーとして、どのCloudWatchアラームを使うのかという設定ができます。

例えば、新バージョンのアプリケーションの信頼性を測るメトリクスをAmazon CloudWatchに発行しておき、そのターゲットとなるCloudWatchアラームも作成しておきます。新バージョンで問題が発生し、メトリクスにその状況が反映され、CloudWatchアラームがアラーム状態になった場合に自動でロールバックするように設定できます。

まとめ

本記事では、AWSコンテナサービスから考える安全なアプリケーションデリバリーというテーマで解説を行いました。特に、Amazon ECSで安全にアプリケーションをデプロイするための具体的な方法として、以下の3つのアプローチを紹介しました。

• 線形デプロイ/カナリーデプロイ: トラフィックを段階的に新バージョンに移行する方法
• 機能フラグ: 特定の条件を満たすユーザーにのみ新機能を公開する方法
• 自動ロールバック: デプロイに失敗した場合に自動的に以前のバージョンに戻す方法

これらのアプローチを組み合わせることで、より安全で信頼性の高いアプリケーションデリバリーを実現できます。

安全なアプリケーションデリバリーは、開発スピードを重視する現代において非常に重要です。本記事の内容が、皆様のアプリケーションデリバリープロセスを改善する一助となれば幸いです。

AWSモダナイズ・スモールスタート開発支援、基幹業務システムのUI.UX刷新はお気軽にお問い合わせください。