AWS でデプロイの自動化を実現するベストプラクティスをグラレコで解説

2020-05-11
AWS グラレコ解説

Author : 伊藤 ジャッジ向子

本連載では、様々な AWS サービスをグラフィックレコーディングで紹介する awsgeek.com を、日本語に翻訳し、図の解説をしていきます。

※ awsgeek.com は Amazon Web Services, Inc. プリンシパル・テクニカル・エバンジェリスト、ジェリー・ハーグローブが運営しているサイトです。

デベロッパーの皆さんがアプリケーションのコードを書いた後は、そのアプリケーションをユーザーが使えるようにするためにデプロイされているかと思います。最後にデプロイした時のことを覚えてらっしゃいますか?最後のデプロイと、その前のデプロイと、比べてみて、大きく違いますか、もしくはほぼ同じでしょうか ?

もし現在、人の手で行っているデプロイがあれば、それを自動化するタスクの小さな一歩を踏んでみませんか。

デプロイ全体を自動化しようとすると、そのタスクはとてつもなく大変に感じられるかもしれません。しかし、一度に全て自動化するのではなく、小さなタスクを一つ一つ自動化のパイプラインに当てはめていけば、最終的には全体の自動化が可能となります。

今回の記事では次の 3 つのポイントから、デプロイの自動化でご利用いただける AWS のサービスについてお話しします。

1. リリースの自動化では、リリースを自動化して効率的にアプリケーションをユーザーに届けたい ! という願いから生まれた、デプロイの自動化 (CI/CD: Continuous Integration/Continuous Delivery) のお話をします。

2. 安全なデプロイでは自動化において不測の事態が起こった際に、人の手を使わずに対処できる環境を作成するサービスについてのお話をします。

3. 繰り返し可能なインフラの変更では手順をコード化して、多くある設定を効率的に一括管理するサービスについてのお話をします。

【注記】
CI/CD の実用例は多く想定できますが、今回の記事の例ではアプリケーションがカプセル化されたイメージとしてビルドされることを想定して、特にコンテナを利用した CI/CD に注目しています。そのため記事内では AWS のコンテナサービスについて言及しています。しかし CI/CD の考え方はコンテナ化しているかどうかにかかわらず適用できる考え方です。コンテナ技術の話や、コンテナサービス使用するにあたっての注意すべき点や、実際にアプリケーションをコンテナ化する為の手順ならびにアプリケーションの条件は、残念ながら今回の記事では紙面の都合で割愛しています。また、デプロイプロセスのオーケストレーションに使えるツールは多々ありますが、今回は AWS CodePipeline の例でお話ししています。

1.リリースの自動化

実は、Amazon においても非常に頻繁にデプロイを行なっています。年間 1.9 億回ものデプロイを行なっており、1 秒あたり 6 回ものデプロイを行なっている計算になります。もちろん人の手ではできない量ですので、デプロイは自動化されています。

図が典型的なパイプラインです。大まかに 3 つのステップに分かれています。(※図ではテスト環境とプロダクション環境で分かれています)

1) ソースのコーディング&設定
2) イメージをビルド
3) テスト環境 (Preprod) プロダクション環境 (Prod) へデプロイ

上記の各ステップにデプロイを自動化の余地があります。一つ一つ見てみましょう。

1) ソースのコーディング & 設定

デベロッパーの皆さんが実際にアプリケーションのコードを書くステージです。デプロイの自動化のためには、この段階で自動化ツールをトリガーできるソースを選択します。例として AWS CodePipeline では、GitHub のブランチ、AWS CodeCommitAmazon S3 バケットのレポジトリの変更、または Docker のタグを使用して Amazon ECR レポジトリからベースイメージの変更を使用することができます。

Amazon ECR は、フルマネージド型の Docker コンテナレジストリで、コンテナサービス Amazon ECS と完全に統合されているため Amazon ECS のレポジトリとして簡単に使用できるサービスです。

2) イメージの Build

各機能やサービスを小さな固まりごとカプセル化して、コンテナイメージをビルドすることで信頼性の高い CI/CD プロセスを形成できます。

ビルドツールには AWS CodeBuild が利用可能です。AWS CodeBuild はフルマネージドサービスで、利用時間に応じて分単位で課金されますので費用に無駄がありません。特に AWS CodeBuild で管理される Docker イメージでは AWS CLI が使用できるため、コマンドラインで Amazon ECR へ手動でプッシュする運用を行なっていた場合、簡単にコード化できます。 

もし、さらにカスタマイズされたビルド手順を実行する必要があれば、ビルド仕様 (buildspec) ファイルで設定します。
 

3) テスト環境 (Preprod) プロダクション環境 (Prod) へデプロイ

デプロイの自動化は組織ごと、アプリケーションごとに固有の既存のプロセスに沿った形で構築する必要があります。そのため、自動化のプロセスは柔軟性を常に考慮に入れるべきです。 AWS CodeDeploy は、多種多様なサービスへのデプロイを自動化するフルマネージドサービスです。 GitHub ActionsJenkinsfile など様々なツール、設定を Amazon ECSとの連携に使用できるよう考慮されています。
※参考情報 : 上記の図内の Spinnaker の AWS 環境で使用については、英語ではありますが AWS Open Source Blog (英語) に紹介されています

2. 安全なデプロイ

安定的な運用は最優先に考慮されなければいけません。万が一、デプロイ中に不測の事態が起こり、担当者が手動で介入する必要が生じた場合、人の手が介入したことによりエラーが発生すれば、デプロイは中断されてしまいます。

また不測の事態に担当者が対応するプロセスでは、対応が遅れたり、あるいは担当者の作業を待っている間にデプロイが自動的に進んでしまい、被害が大きくなってしまうこともあります。

AWS CodeDeploy では不測の事態で人の手を使わないように設定できます。「万が一」の際には自動的にロールバックできるよう、Lambda 関数による検証が実行されるよう設定可能です。

同じ理由で、ロールバックも素早く行わなければなりません。自動化されていれば人間が命令するより早くロールバックもできます。

さて、デプロイが正常終了したように見えた後も、「デプロイ成功 !」を宣言して次のデプロイにとりかかる前にしばらく時間を置きましょう。30 分でも 24 時間でも、新しいコードが十分な実行パスをひと通り実行される時間を設けます。

上記のような詳細な設定は AWS CodeDeploy の AppSpec ファイルに設定します。AppSpec ファイルの Lifecycle hook で Lambda 関数 (フック関数) による検証結果によりロールバックをトリガーしたり、デプロイ後状況監視の待ち時間を設定できます。

また、デプロイは小さな環境から始めて、徐々に大きな環境に適用することをお勧めします。何かが起こっても、小さな範囲の火消しは大きな環境に渡った火消しよりも簡単だからです。

安全なデプロイを行うためには、上記のどの段階で警告が上がっても、すぐにロールバックできるように設定しましょう。

安全なデプロイを自動化に組み込むため、AWS CodeDeploy を使用したデプロイでは、Application Load Balancer (ALB) を使用して図のように Prod (青) のグループと、Test (緑) のグループの 2 つに分けてデプロイを設定できます (blue/green デプロイメント)。何か問題があったらすぐに ALB が経路を変更します。この運用で、デプロイが原因で問題が起こった際のダウンタイムの短縮ができます。

何度かデプロイしているうちにイメージタグ上書きされてしまい、どのイメージがデプロイされたかわからなくなり困った、といった問題を避けるためには Amazon ECR でのイミュータブルなタグの機能をお使いください。

また、よりセキュアなコンテナイメージを build するためには、Amazon ECR のコンテナイメージスキャン機能でビルドしたコンテナイメージで既知の脆弱性をスキャンすることもできます。

3. 繰り返し可能な、インフラの変更

1) Infrastructure as Code

前項で、buildspec ファイル、AppSpec ファイルでの設定についてお話ししました。しかし、これ以外にも例えば Amazon ECS のサービスで必要なタスク数など、イメージに関連する設定は多くあります。イメージ以外にも、それを取り巻く環境にはロードバランサーや DNS またはロードバランサーの TLS の設定、ヘルスチェックのパスなど多くの設定があります。

もし、設定の小さな間違い、たとえば Test と Production でヘルスチェックのパスが違った、などのミスが発生した場合、折角 Amazon CloudWatch で自動化されたプロセスを監視していても、誤検知や過度に頻繁な検知が起こってしまい、誰もアラームを信用しなくなります。そうなると自動化されたデプロイプロセスに対する信頼性も落ちてしまいます。

このような自動化されたデプロイの環境やイメージの、設定ミスを避けるため、コード化されたインフラストラクチャ (Infrastructure as code) が自動化されたデプロイでは重要になります。コード化された手順は、自動化ツールの一部として最初から取り込んでおきます。

コード化には、例えば Amazon CloudFormation を使用します。同じ Amazon CloudFormation テンプレートを複数のデプロイに使えば、上記の例ようなヘルスチェックのパス等の設定を一元的に管理できます。

2) AWS CDK

しかし CloudFormation のテンプレートファイルも、長くなれば設定も大変になります。そこでお勧めしたいのは、AWS Cloud Development Kit (AWS CDK) です。

AWS CDK はリソースタイプごとの動作設定を指定できますし、ベストプラクティスに沿ったコードを作成する助けになります。たとえばもし Amazon ECR のイメージを Amazon ECS 上にデプロイしたい場合は、Amazon ECS に必要な IAM ポリシーを作成します。またデプロイに必要なネットワーク環境を整えるため Amazon VPC を作成し、その動作に必要な属性を指定したかどうかの検証をユーザーに促します。本記事の最後に、コンテナ向けサービスコンピューティングエンジンの AWS Fargate のタスクを定義するコードの例を載せています。AWS CDK CLI は AWS CDK を制御するツールです。Amazon CloudFormation テンプレートを生成したり、他のテンプレートにデプロイしたりできます。AWS CDK はビルド手順の中で実行することも可能で、AWS CodeBuild の buildspec ファイルの中に直接設定することができます。

3) AWS Fargate

最後に図のタイトルには登場したにもかかわらず、図中には登場しなかった AWS Fargate について補足をします。AWS Fargate は、Amazon ECS と Amazon EKS 双方が利用できるサーバーレスコンピューティングエンジンです。サーバーレスのため Amazon ECS、Amazon EKSでやらなければいけなかったインスタンスの管理が必要なくなり、タスクやポッドの指定のみで利用できます。そのため、ワークロードの分離がしやすいため、多くの CI/CD の運用で便利にお使いいただけます。

最後に、全体の図を見てみましょう。

デプロイの自動化には様々なツールやスタイルがあります。今回ご紹介した内容はそのごく一部です。本記事の内容は AWS re:Invent 2019 で紹介された Amazon のデプロイで実行している自動化を例にベストプラクティスを紹介したものです。セッションは英語のみですが YouTube でも紹介されていますのでご参照ください。

もしデプロイの自動化をお考えでしたら、今回ご紹介いたしましたサービスや機能にご興味を持っていただければ幸いです。


付録:AWS CDK の一例 (YouTube 動画より)

const cluster = new ecs.cluster(this, 'cluster')
const taskDef = new ecs.FargetTaskDefinition(this, "MyTaskDefinition", {
    memoryLimitMiB:512,
    cpu:256
});
taskDef.addContainer("AppContainer",{
    image:ecs.ContainerImage.fromRegistory("amazon/amazon-ecs-sample"),
});
new ecs.FargateService(this, "FargateService",{
    cluster,
    taskDefinition: taskDef
});

AWS グラレコ解説のその他の記事はこちら

選択
  • 選択
  • 今話題のブロックチェーンをAWSで実現する仕組みをグラレコで解説 »
  • サーバーレスって何が便利なの ? AWS でサーバーレスを構築するためのサービスをグラレコで解説 »
  • 機械学習のワークフローってどうなっているの ? AWS の機械学習サービスをグラレコで解説 »
  • 外部から AWS のバックエンドサービス利用を実現する仕組みをグラレコで解説 »
  • AWS でデプロイの自動化を実現するベストプラクティスをグラレコで解説 »
  • コンテナを使ってモノリスを分割する方法をグラレコで解説 »
  • クラウドへ移行する理由とそのステップをグラレコで解説 »
  • Windows ワークロードをクラウドへ移行するためのベストプラクティスをグラレコで解説 »
  • サーバーレスのイベントバスって何 ? Amazon EventBridge をグラレコで解説 »
  • サーバーレスで SaaS を構築する方法をグラレコで解説 »
  • 「あなたへのおすすめ」はどう生成するの ? Amazon Personalize で簡単に実現する方法をグラレコで解説 »
  • クラウド設計・運用のベストプラクティス集「AWS Well-Architectedフレームワーク」をグラレコで解説 »
  • 特定の顧客セグメントにメッセージ送信。「Amazon Pinpoint」の仕組みをグラレコで解説 »
  • アプリにユーザー認証機能を簡単に追加できる「Amazon Cognito」をグラレコで解説 »
  • わずか数分で WordPress サイトを構築できる「Amazon Lightsail」をグラレコで解説 »
  • 異なるアプリケーション同士の疎結合を実現。「Amazon SQS」をグラレコで解説 »
  • Web アプリを高速に開発できる「AWS Amplify」をグラレコで解説 »
  • 機械学習の知識ゼロでもテキストデータを分析。Amazon Comprehend をグラレコで解説 »
  • ビジネスデータをまとめて可視化 & 分析。Amazon QuickSight をグラレコで解説
  • 人工衛星の地上局を 1 分単位で利用。AWS Ground Station をグラレコで解説
  • カオスエンジニアリングで本当にカオスにならないための進め方をグラレコで解説
  • GraphQL API を簡単に作成 & 運用。AWS AppSync をグラレコで解説
  • IoT 環境を必要な機能を選択するだけで構築。AWS IoT をグラレコで解説
  • 高い可用性と耐久性のオブジェクトストレージ。Amazon S3 をグラレコで解説
  • サーバーレスでイベント駆動型アプリケーションを実現。AWS Lambda をグラレコで解説
  • データサイエンス教育の強い味方。Amazon SageMaker Studio Lab をグラレコで解説
  • 高速で柔軟な NoSQL データベースサービス。Amazon DynamoDB をグラレコで解説
  • リレーショナルデータベースを簡単・迅速に実現。Amazon RDS をグラレコで解説
  • アプリのワークフローを視覚的に構成。 AWS Step Functions をグラレコで解説
  • データ保護に使う暗号化キーを一元管理。AWS KMS をグラレコで解説
  • アプリケーションへのトラフィックを効率的に負荷分散。Application Load Balancer をグラレコで解説
  • AWS で簡単にコンテナアプリケーションを構築 ! Amazon ECS をグラレコで解説
  • 大規模データセットも簡単クエリ! Amazon Athena をグラレコで解説
  • キャッシュ機能でアプリの高速化を実現 ! Amazon ElastiCache をグラレコで解説
  • 使い慣れたプログラミング言語でクラウド環境を構築 ! AWS CDK をグラレコで解説
  • ストリーミングデータを簡単にキャプチャ、処理、保存 ! Amazon Kinesis Data Streams をグラレコで解説
  • AWS で始める機械学習はじめの一歩 ! AWS の主要な AI/ML サービスをグラレコで解説
  • リレーショナルデータベースをサーバーレス化 ! Amazon Aurora Serverless をグラレコで解説
  • ML 駆動の検索エンジンで企業の情報管理を革新! Amazon Kendra をグラレコで解説
  • オンプレミス、エッジ、どこでも楽々コンテナ管理 ! Amazon EKS Anywhere をグラレコで解説
  • 生成 AI アプリケーション開発をもっと身近に、簡単に ! Amazon Bedrock をグラレコで解説
  • わずか数クリックで多様な脅威を監視しクラウドを保護 ! 脅威検出サービス Amazon GuardDuty をグラレコで解説
  • データの改ざん耐性と変更履歴の検証可能性を実現 ! 台帳データベース Amazon QLDB をグラレコで解説
  • 生成 AI x クラウドがもたらす次世代のイノベーション ! AWS Summit Japan Day 1 基調講演をグラレコで解説
  • ビジネス向け生成 AI アシスタント Amazon Q Business をグラレコで解説
  • 生成 AI コーディングアシスタント Amazon Q Developer をグラレコで解説
  • フロントエンドとバックエンドを統合開発 ! フルスタック TypeScript 開発環境 AWS Amplify Gen 2 をグラレコで解説

builders.flash メールメンバーへ登録することで
AWS のベストプラクティスを毎月無料でお試しいただけます

筆者紹介

伊藤 ジャッジ向子(さきこ)
アマゾン ウェブ サービス ジャパン合同会社
テクニカルライター。

2016 年にアマゾン ウェブ サービス ジャパン合同会社テクニカルサポート部入社。AWS Snowball 等のストレージ系サービスのサポート、ならびに IoT サービスをメインにサポートを行い、2019 年より現職。
趣味はインドアでは小さなセンサーと Raspberry Pi でおもちゃを作ること。アウトドアでは犬を連れてのハイキングとキャンプ。

AWS を無料でお試しいただけます

AWS 無料利用枠の詳細はこちら ≫
5 ステップでアカウント作成できます
無料サインアップ ≫
ご不明な点がおありですか?
日本担当チームへ相談する