こんにちは、大和総研CCoEの光原です。
大和総研ではクラウドを通じてお客様に価値を提供すべく、2021年度よりパブリッククラウドの推進組織（CCoE: Cloud Center of Excellence）を設置し、クラウド活用を推進しています。
本記事は、前回大和総研のホームページコラム欄にて紹介したAWSにおけるマイクロサービスで実装したWebサービスの継続的デプロイ（概要編）の連載第2回（全3回）です。第1回では、Blue-Greenデプロイを実現するための構成として、マイクロサービスで実装されたWebサービスを例に、全体概要について解説しました。
今回は、バックエンドアプリの継続的デプロイ構成について解説していきます。
継続的デプロイを組織で運用する際によくある課題
バックエンドアプリの構成は第1回で紹介した通りです。
第1回でも書いていますが、すでにオンプレミス環境で構築されたサービスを保守運用している企業は、多くの場合に以下が前提となります。
- アプリ、インフラ、運用が別組織、別権限である
- 本番相当の環境に対してのデプロイでは、デプロイ前に運用担当の承認が必要である
そのため、クラウドサービスを利用した新たなサービスを運用するにあたり、下のような課題が発生することがあります。
- アプリ／インフラごとにリソース管理されているため、Webサービス全体の構成を把握することが難しい
- アプリケーション担当からインフラ担当へ連携するフロー（その逆も）を改善したいが、どのように行えばよいかイメージできない
- 開発環境／テスト環境／ステージング環境（以下STG環境）／本番環境など、複数の環境を持っており、それぞれの環境の構成状況を管理することが難しい
- 本番相当の環境の変更は運用担当者による承認を条件とする必要があるが、どのように承認プロセスを組み込めばよいのか分からない
これらの課題解決には、アプリ／インフラ／運用などの複数の組織を巻き込んでデプロイプロセスの改善を合意して進めていくことが必要です。企業によっては、解決するために労力のかかる課題ですが、クラウドサービス利用による俊敏性向上の利点を充分に生かすためには、どれも解決が必要なものです。最終的に目指す形を組織で認識共有したうえで、まずは、小さな案件から少しずつ取り組んでいくことも有効でしょう。
よくある課題を解決するためのデプロイの構成を考えるうえで、下記が考慮すべきポイントとしてあげられます。
これらのポイントについて、それぞれリンク先の節で詳しく解説しています。
- リソースを一元管理する （「リポジトリ管理」参照）
- 開発担当とインフラ担当のリソースについてリポジトリを分けることで管理対象を明確化する （「リポジトリ管理」参照）
- デプロイパイプラインは各ワークロードの存在するアカウント側で実行する （「デプロイ」参照）
- 運用担当の承認が必須である環境（今回はSTG環境）は、デプロイパイプラインに承認ステージを設ける （「デプロイ」参照）
構成例とポイント
バックエンドの継続的デプロイ構成の一例をあげると、「図1.バックエンドの継続的デプロイ構成」のようになります。
出所：大和総研作成
次に、継続的デプロイを構成する要素とポイントについて解説します。
リポジトリ管理
リポジトリ管理の構成ポイントは以下2点です。
- リソースを一元管理する（この例では開発アカウントで一元管理している例です）
- アプリケーション担当とインフラ担当でリポジトリを分けてそれぞれ適切なブランチ戦略を適用する
デプロイ対象の環境は複数環境存在していますが、リソースは1ヵ所で管理できた方が望ましいため、今回は開発用アカウントにリポジトリを配置する構成としました。
リポジトリはアプリケーション担当とインフラ担当で明確に管理を分けるため、それぞれのリソースを別のリポジトリで管理する方針としています。アプリケーションリポジトリは、更新サイクルを重視しmainブランチ上で更新していく前提（git-flow など）としています。一方で、インフラリポジトリはワークロード環境（DEV／STG／PRD）ごとにブランチを分けて管理していく前提（GitLab Flow など）です。このように、リソースごとに適切なブランチ戦略を選択できることも、リポジトリを分ける利点です。
ビルド
ビルドは、アプリケーションリポジトリのmainブランチが更新されたタイミングでCIパイプラインを起動させます。アプリケーションをビルドして開発環境用のECRにコンテナイメージを格納するところまでをCIパイプラインで実行します。コンテナイメージには、どのタイミングで作成されたイメージなのか区別するためにCommitIDをタグとして付与しておきます。
実際には、CIパイプラインでリグレッションテストや静的コード解析なども行いますが、ここでは割愛しています。
コンテナイメージのレプリケーション
デプロイ対象の環境にコンテナイメージを持っていく方法として、今回はECRのクロスアカウントレプリケーションを利用する方法としました。ECRには、イメージがpushされたときに別アカウントのECRにレプリケーションする機能があります。レプリケーションのルールとしてプレフィックスを用いてフィルタすることも可能なので、レプリケーション対象のECRリポジトリを限定することも可能です。一方で、即時にレプリケーションが完了するわけではないことに注意が必要です。
デプロイ
今回は、ワークロード環境へデプロイする際に運用担当の承認が必要となるケースを想定しているため、デプロイパイプライン内のデプロイ処理の前段に手動承認のステージを設定しています。
デプロイを実行しているCodePipelineはデプロイ先環境で実行させることにしており、開発用アカウント側に強い権限を持たせないようにしています。
Blue-Greenデプロイ実現方法での考慮ポイント
AWSでは、ロードバランサー（ELB）を使ってルーティングしているコンテナアプリケーションの場合は、Blue-GreenデプロイメントをCodeDeployを用いて実現することができます。デプロイのイメージは図2のように、前段のELBで新アプリケーション側にトラフィックを計画的に送信することで行われます。
出所：大和総研作成
一方で、AppMeshを利用してルーティングを実現している場合は、CodeDeployを用いてBlue-Greenデプロイはできません（2023年8月時点）。そのため、Blue-Greenデプロイを実行するためには作りこみが必要となります。一つの方法として、仮想ルータの重みを変更する方法が考えられます。
出所：大和総研作成
通常、AppMeshを利用することで、サービス間の通信制御、サーキットブレーカーによるリトライや遮断制御、可観測性向上が見込めるため、今回の構成例でも利用を前提としています。
特に、マイクロサービスアーキテクチャを採用しており、サービス同士が複雑に関連し合っているようなケースでは、AppMeshの利用が有効です。
一方で、AppMeshを利用しており、前段にELBを挟まない構成である場合には、Blue-Greenデプロイの実現ために段階的にルート情報を更新するなど、デプロイ実現方法が複雑になることを考慮しておく必要があります。
おわりに
今回は、バックエンドアプリの継続的デプロイについて構成例を用いて解説しました。
構成例にあるようなリポジトリ構成にすることで、アプリケーション担当とインフラ担当のリソースを分けて管理することができます。
デプロイのパイプラインは、デプロイ先の環境で実行するようにして開発環境の権限を限定させ、運用者の承認ステージもデプロイ先環境側に設けることができます。
既存の組織を踏襲しながら、クラウドサービスの利点である俊敏性を生かすためのデプロイ方法の１つの例として参考になれば幸いです。
次回は、CloudFront+S3で構成されたフロントエンドのBlue-Greenデプロイについて解説する予定です。
大和総研では、金融機関や事業会社のお客様へクラウドを導入・運用してきた実績を活かし、お客様のクラウドインフラの構築・移行などをサポートします。ご要望・ご不明点などがありましたら、ITソリューションサービスサイトよりお問い合わせください。
今回利用したAWSサービス
AWS CodeCommit
プライベートにソースを管理できるマネージドサービスです。CodeCommitは、プライベートGitリポジトリをホストしており、Gitの標準機能がサポートされています。
AWS CodeCommit（プライベート Git リポジトリでのコードの保存）| AWS
AWS CodePipeline
アプリケーションをデプロイするために必要なステップを自動化できるマネージドサービスです。CodePipelineを利用することで、アプリケーションソースの取得、ビルド、テスト、デプロイなどの一連の処理を自動化することができます。
AWS CodePipeline（継続的デリバリーを使用したソフトウェアのリリース）| AWS
AWS CodeBuild
アプリケーションをビルドする環境をマネージドで提供するサービスです。CodePipelineのビルドステージやテストステージのアクションとしてCodeBuildを追加することができます。
AWS CodeBuild（継続的スケーリングによるコードのビルドとテスト）| AWS
Amazon ECR
Dockerコンテナレジストリーサービスです。S3と同様に高い耐久性、可用性を持ち、ECSやCodeBuildなどの他のAWSサービスとの連携も可能です。
Amazon ECR（Docker イメージの保存と取得）| AWS
AWS Fargate
サーバーレスでコンテナを実行するワークロード環境です。Fargateを利用することで、コンテナワークロードのインスタンスを管理することなくコンテナを実行することができます。
AWS Fargate（サーバーやクラスターの管理が不要なコンテナの使用）| AWS
AWS App Mesh
サービス間の通信制御と可観測性の向上を実現するサービスメッシュを提供するマネージドサービスです。App MeshはVirtual Gateway（仮想ゲートウェイ）、Virtual Service（仮想サービス）、Virtual Router（仮想ルータ）、Virtual Node（仮想ノード）のコンポーネントから構成されます。App Meshにより、コンテナ間のルーティング制御、サーキットブレーカー機能、サービス間通信の暗号化、メトリクスやロギングなどの可観測性向上の機能を利用することができます。
AWS App Mesh（マイクロサービスをモニタリングおよびコントロールする）| AWS
関連する事例
プロジェクト事例：海外拠点とのデータ連携システムをAWS サーバーレスを活用して構築
スミセイ情報システム株式会社様 | 保険業界のデジタル戦略をサポートする「DXプラットフォーム（通称：insNext）」をクラウドネイティブなアーキテクチャで構築
