こんにちは、大和総研CCoEの光原です。
大和総研ではクラウドを通じてお客様に価値を提供すべく、2021年度よりパブリッククラウドの推進組織（CCoE: Cloud Center of Excellence）を設置し、クラウド活用を推進しています。
本記事は、AWSにおけるマイクロサービスで実装したWebサービスの継続的デプロイ（概要編）の連載第3回（全3回）です。第1回では、Blue-Greenデプロイを実現するための構成として、マイクロサービスで実装されたWebサービスを例に、全体概要について解説しました。第2回では、バックエンドアプリの継続的デプロイの構成について紹介しています。 今回は、連載の最終回としてフロントエンドの継続的デプロイ構成について解説していきます。
構成例とポイント
第2回で解説したバックエンドの継続的デプロイの検討と同様に、フロントエンドの継続的デプロイについて検討していきます。フロントエンドの構成は、第1回で紹介したCloudFront+S3の構成としています。 考慮ポイントとしては、バックエンドと同じく、以下の点となります。
- リソースは開発用アカウントで一元管理する
- デプロイパイプラインは各ワークロードの存在するアカウントで実行する
- 開発担当とインフラ担当のリソースについてリポジトリを分けることで、管理対象を明確化する
- 運用担当の承認が必須である環境（今回はSTG環境）は、デプロイパイプラインに承認ステージを設ける
まずは、構成図についてまとめると図のようになります。
それでは、各構成要素について解説していきます。
リポジトリ管理
リポジトリ管理や運用の複雑化を避けるために、リポジトリ管理とビルドの流れはバックエンドと同じ構成としています。第2回で紹介した通り、管理する主体がアプリケーション担当なのか、インフラ担当なのかでリポジトリを分け、それぞれのリポジトリに適切なブランチ戦略を選択しています。今回の例では、アプリケーションリソースはMainブランチ上で更新し、インフラリソースはワークロード環境（DEV／STG／PRD）ごとにブランチを分けて管理しています。
ビルド
アプリケーションリポジトリのMainブランチが更新されたタイミングで、起動するAWS CodePipeline（以下、CodePipeline）の処理でビルドします。ビルド実行で作成されたコンテンツはAmazon S3（以下、S3）に格納し、S3のクロスアカウントのレプリケーションを利用して、各ワークロード環境へコピーする方式としています。バックエンドのビルド実行では、作成されたコンテナイメージをクロスリージョンでレプリケーションする方式としていたので、フロントエンドもその方式に合わせています。
デプロイ
デプロイパイプラインは、デプロイ前に運用担当の手動承認ステージを設定しています。 手動承認後に実行されるデプロイ処理には、Amazon CloudFront(以下、CloudFront)のContinuous deployment（継続的デプロイ）を利用しています。Continuous deploymentのイメージは下のようになります。AWSの公式ドキュメントもご参照ください。
Stagingディストリビューション
Continuous deploymentでは、Stagingタイプのディストリビューションを準備して、トラフィックをTraffic configurationに従い振り分けることで、Blue-Greenを実現できるサービスです。StagingディストリビューションのオリジンパスをCIパイプラインで作成したS3上のコンテンツに向くように設定します。上のイメージでは、既存のコンテンツを”/v1.0”とし、新しいコンテンツを”/v1.1”としています。
継続デプロイポリシー（Traffic configuration）
継続デプロイポリシーではWeight-basedとHeader-basedの2種が選択できます。Weight-basedを指定した場合は、指定した割合のリクエストがStagingディストリビューションに割り振られる動きとなります。Header-basedを指定した場合は、指定したヘッダーがあるリクエストだけがStagingディストリビューションに割り振られます。Header-basedポリシーを利用することで、リリース前に指定したヘッダーを付与すれば新しいバージョンのコンテンツの動作検証ができます。また、こちらの設定は、有効/無効も設定できるので、デプロイ開始のタイミングでこの設定を有効化することができます。
昇格（Promote）
新しいコンテンツの稼働確認後はPromoteを実行して、Stagingディストリビューションの内容を本番の設定に反映します。上のイメージでは、Primaryのディストリビューションのオリジンパスが”/v1.1”に変更される動きとなります。その後、キャッシュをクリアすることでフロントエンドのデプロイが完了となります。
Continuous deploymentを利用しない場合は、切り替えをDNSレコードの更新やCloudFrontのオリジンパスの変更などで対応することになりますが、Continuous deploymentを利用すれば、比較的簡単に切り替えを行うことができます。
おわりに
今回はフロントエンドの継続的デプロイについて、アプリケーションのパイプラインで行うビルドの内容と、インフラリソースのパイプラインで行うデプロイ処理を例に説明しました。特にデプロイ処理については、CloudFrontのContinuous deploymentを利用することで切り替え前のテストが指定したヘッダーを付与することで可能であり、切り替えの手間も少ないというメリットがあることを紹介しました。
AWSにおけるマイクロサービスで実装したWebサービスの継続的デプロイをテーマに、3回にわたり構成例を使って説明してきましたが、みなさまの継続的デプロイの導入おいて、今回の記事が参考になれば幸いです。
大和総研では、金融機関や事業会社のお客様へクラウドを導入・運用してきた実績を活かし、お客様のクラウドインフラの構築・移行などをサポートします。ご要望・ご不明点などがありましたら、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 CloudFront
高速コンテンツ伝送ネットワーク(CDN)サービスです。CloudFrontでサービスを提供しているコンテンツをユーザがリクエストすると、リクエストはエッジロケーションにルーティングされ、これにより低遅延で配信がされます。
Amazon CloudFront（グローバルなコンテンツ配信ネットワーク）| AWS
Amazon S3
データを格納し管理できるオブジェクトストレージサービスです。拡張性、可用性に優れており、アクセス制御やデータ暗号化により高いセキュリティ機能も有しています。
Amazon S3（拡張性と耐久性を兼ね揃えたクラウドストレージ）｜AWS
関連記事
プロジェクト事例：海外拠点とのデータ連携システムをAWS サーバーレスを活用して構築 | 大和総研
保険業界のデジタル戦略をサポートする「DXプラットフォーム（通称：insNext）」をクラウドネイティブなアーキテクチャで構築 | 大和総研
