BioErrorLog Tech Blog

試行錯誤の記録

高制御なデプロイパイプラインのアーキテクチャ事例 | AWSクラウドアーキテクチャ

高い制御が可能なデプロイパイプラインのアーキテクチャを、事例から学びます。


はじめに

おはよう。@bioerrorlogです。

先日、AWSから上の動画が投稿されました。

ヘルスケア企業のNextGenで利用されている、高い制御の求められるビルド・デプロイパイプラインのアーキテクチャが解説されています。

今回はこの動画のアーキテクチャを改めて自分で書き下し、デプロイパイプラインのアーキテクチャを学んでいきます。


アーキテクチャ

f:id:BioErrorLog:20200215191814p:plain

CodePipelineからCloudFormationを介して各環境をデプロイするパイプラインのアーキテクチャです。


開発者は、アプリケーションコード・インフラストラクチャーコード (CloudFormationコード) をCodeCommitにプッシュしていきます。

CodeCommitの特定のブランチの更新をトリガーにCodePipelineが起動し、CloudFormationにコードがプッシュされます。


ここで、CloudFormationに与えられる権限はIAMロールによって定義されています。

NextGenでは患者情報など重要機密情報も扱うため、このIAMロールによってCloudFormationのデプロイ権限範囲が厳密に定められていることが重要なポイントだそうです。

このIAMロールによるデプロイ前の制御に加え、ConfigルールやGuardDutyによってデプロイ後のコンプライアンスも継続的にモニタリングされています。


CloudFormationからは、アプリやインフラの全て(ネットワーク・データベース・コンピュート(Lambdaなど)・エッジコンポーネント)がデプロイされています。
デプロイ先も、開発環境/テスト環境/本番環境の全てに繰り返しデプロイされます。

CloudFormationにインポート/エクスポートする値は、Secrets ManagerとSystems Manager Parameter Storeでまとめて管理されています。


重要なポイントは、各リソースがそれぞれ独立のCodePipeline/CloudFormationスタックによってデプロイされていることです。

もともとは全てのリソースが一つのCloudFormationスタックによってデプロイされていたそうですが、この場合ある一か所の変更であっても全てのスタックリソースが更新処理を実行することになってしまいます。
CloudFrontの一時停止なども引き起こされてサービスが停止してしまうため、現在はリソース毎に別々のCloudFormationスタックとして管理し、互いのデプロイが干渉し合わないように、デプロイ範囲の権限が厳密に管理されているそうです。


このパイプラインのデプロイにかかる時間としては、Lambdaなどコンピュートリソースでは数分、エッジコンポーネントではもう少し長く、データベースでは(種類にもよりますが)30~45分ほど。

それらに比べてCodeCommitからCloudFormationまでの流れは、問題にならないほど短いとのことです。


おわりに

NextGenの事例から、高い制御の求められるデプロイパイプラインのアーキテクチャを学びました。

リソース毎にCloudFormationスタックを分けることや、IAMロールによるCloudFormation権限の制御が重要であることなど、いろいろと勉強になりました。

余談ですが、"Highly Regulated"をどう日本語に訳したものか、いまいちよく分かりませんでした(高制御...?)。


関連記事

www.bioerrorlog.work


参考

NextGen Healthcare: Build and Deployment Pipelines in the Highly Regulated Healthcare Sector - Youtube