AWSにおけるCI/CDのテクノロジースタック

はじめに

この記事はDevOps on AWS大全の一部です。
DevOps on AWS大全の一覧はこちら。

この記事ではAWSでCICDを実現する際に利用するテクノロジースタックを整理しています。

具体的には以下3点をまとめた上で、AWSにおけるCICDのテクノロジースタックを紹介します。

• CICDとは
• AWSで構築したシステムにCICDを導入しないと何が大変なのか
• AWSで構築したシステムにCICDを導入すると何がうれしいのか

AWSの区分でいう「Level 200：トピックの入門知識を持っていることを前提に、ベストプラクティス、サービス機能を解説するレベル」の内容です。

この記事を読んでほしい人

• CICDに興味はあるがCICDとは何かを説明できるようになりたい人
• CICDを導入することと何がうれしいかを説明できるようになりたい人
• AWSにおけるCICDに関連するサービスをを学びたい人
• AWS Certified DevOps Engineer Professionalを目指している方

CI/CDとは

以下にCI/CDの概略図を記載します。
これを見てなにをやっているかわかる人はこのセクションを飛ばして大丈夫です。

CIとは

CI(Continuous Integration)を一言でいうと「ソースコードを書いたら、すぐにテストし、出力結果をもとにすぐに修正する、というサイクルを高速回転させること」です。

具体化すると以下手順を高速で回して行くことがCI、となります。

1. 開発者はソースコードを修正したらすぐにコードリポジトリにプッシュ
2. コードリポジトリにプッシュされたことを契機にビルド&テストを実行
3. ビルドとテストの結果を開発者にフィードバック

このサイクルを可能な限り早く回すためにはリポジトリへのプッシュを契機に、人手を介さずでビルドとテストを実行する必要があるため、CIを導入するためにはイベントドリブンで自動ビルドと自動テストできる仕組みを構築することが必須です。

なお、この手順を図式化すると以下になります。

ではCIを導入するどうしてうれしいのでしょうか。
答えは「ビルドとテストを自動で実行」できるので「早期のバグ発見が可能」になり、「開発者が楽をできる」から、です。

現場で導入するときには必ず、これまでのやり方にこだわる人が出てきます。
しかし、CIを導入し開発の効率化を実感できれば最後は喜んでもらえるので自信をもって進めましょう。

CDとは

CD(Continuous Delivery)を一言でいうと「自動で頻繁に本番環境へリリースを行うこと」です。

具体的には四半期に一度まとめてリリースするのではなく、リリースをしたいときには毎日でもリリースをする、というのがCDです。

毎日という頻度でリリースをするためには、リリースが自動化されていないと実現不可能なのでCDを導入する際には、自動デプロイメントできる仕組みを構築することが必須です。

なお、この概念を図式化すると以下になります。

ではCDを導入するどうしてうれしいのでしょうか。
答えは「デプロイメントを自動化」できるので「リリース時の人為的ミスが少なくなり」になり、「開発者が楽をできる」から、です。

実際には変化の激しい時代、可能な限り早くサービス改修をしたいというビジネスサイドの要望を満たす側面もありますがCI同様、開発者も楽になるので自信をもって進めましょう。

AWSで構築したシステムにCICDがない場合の悲劇

ここまでCI/CDについて説明と導入するメリットを記載してきました。
ここからはCI/CDを導入しない場合=AWSのベストプラクティスから外れた場合にどういう負荷が開発者にかかるかをまとめます。

複雑な手順を要するリリース

AWSでシステムを構築していても、Excelで作った手順書に従って何十もの画面遷移やコマンド打鍵を一つもミスなく実施することで初めてリリース完了する、というプロジェクトは多いのではないでしょうか。

ロールバックできないデプロイ

手順が複雑ということはロールバックも極めて難しいデプロイになっているということです。
ミスなく終わることを祈ってリリースしてヒヤリハットを何とかくぐり抜けている、というプロジェクトに思い当たりがあるのではないでしょうか。

再現不可能なインフラ変更

AWSで大規模システムを構築している場合IaC(Infrastructure as code)を実践しているプロジェクトが多いと思います。
そういったプロジェクトにこそ問いたいのですが、そのインフラは本当にいつでもどこでも再現可能でしょうか。

アカウントにつき一度しか行わない操作に限ってコード化しておらず、本番環境で作業もれしてしまう、というのはよくある話です。

開発初期からCI/CDを意識して、いつでもどこでもどんな時でも同じインフラを構築できるコードを作ることがAWSのベストプラクティスです。

AWSで構築したシステムにCI/CDを導入することで得られる幸せ

得られる幸せは基本的に先ほど書いた悲劇の裏返しですが、CI/CDの導入に抵抗を感じる人を説得するためにも導入することでどう幸せになるかをまとめます。

リリースの自動化

リリースが自動化されることで手順はいつも同じでマネジメントコンソールにてボタンを押すだけでリリースが完了する、という世界を作ることができます。
手順はいつも同じで動作させるパイプライン名だけ変数にすればよい、となればリリースのたびに膨大な手順を作る不毛な作業からも解放され幸せは二倍です。

安全なデプロイ

CI/CDをベストプラクティスに沿って実装すると、ビルドやデプロイに失敗したときには自動でロールバックすることが可能になります。
Blue/Greenデプロイやカナリヤリリースを手軽に行えるのでリリース時の心理的負荷がかなり軽減されます。

繰り返し可能なインフラ変更

インフラの設定をすべてコード化することで、いつでもどこでもどんな時でも同じインフラを構築できるようになります。
大規模開発だと、開発用の環境をいくつも並列で構築することはよくある話です。
CI/CDができるインフラのコードは自然と繰り返し可能なインフラ変更を満たすことができるので急な開発環境の追加構築も簡単に完了することが可能になります。

AWSにおけるCICDのテクノロジースタック

ここまで、CI/CDとはなにか、AWSで構築したシステムにCI/CDは何をもたらすかを整理しました。

これらを踏まえて、AWSにおけるCICDのテクノロジースタックの全体をおさえましょう。
今回は全体を示すにとどめ、個別の説明は次回から順番に行います。

• Codeシリーズ
  • パイプライン
    • CodePipline
  • コードリポジトリ
    • CodeCommit
  • ビルドサーバ
    • CodeBuild
  • デプロイメントサーバ
    • CodeDeploy
  • アーティファクト管理
    • CodeArtifact
  • コードレビュー
    • CodeGuru
• 特定の構成の構築簡易化
  • Amplify
  • ElasticBeanstalk
• IaC
  • CloudFormation
• AMI構築の自動化
  • EC2 Image Builder

テクノロジースタック全体図

羅列されてもわかりにくいと思うのでCI/CDの図に整理すると以下になります。

まとめ

今回は以下3点をまとめた上で、AWSにおけるCICDのテクノロジースタックを紹介しました。

• CICDとは
• AWSで構築したシステムにCICDを導入しないと何が大変なのか
• AWSで構築したシステムにCICDを導入すると何がうれしいのか

次回はAWSにおけるパイプラインのベストプラクティスパターン整理を解説していきます。

続きはこちら