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) へデプロイ

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

img_awsgeek-ci-cd_01

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

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

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

img_awsgeek-ci-cd_02

2) イメージの Build

img_awsgeek-ci-cd_03

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

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

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

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

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

2. 安全なデプロイ

img_awsgeek-ci-cd_05
img_awsgeek-ci-cd_06
img_awsgeek-ci-cd_07

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

1) Infrastructure as Code

img_awsgeek-ci-cd_08

2) AWS CDK

img_awsgeek-ci-cd_09

3) AWS Fargate

img_awsgeek-ci-cd_10

デプロイの自動化には様々なツールやスタイルがあります。今回ご紹介した内容はそのごく一部です。本記事の内容は 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
});
photo_ito_judge

筆者紹介

伊藤 ジャッジ向子(さきこ)

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

AWS のベストプラクティスを毎月無料でお試しいただけます

さらに最新記事・デベロッパー向けイベントを検索

下記の項目で絞り込む
絞り込みを解除 ≫
フィルタ
フィルタ
1

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

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