ZOZOテクノロジーズ SRE部の川崎（@yokawasa）です。ZOZOTOWNのアーキテクチャをマイクロサービスで再設計してリプレイス化を推進するチームに所属しております。

本記事では、このZOZOTOWNのマイクロサービスプロジェクトで実践している継続的インテグレーション/継続的デリバリー（以下、CI/CD）についてご紹介します。

はじめに

まずはじめに、本記事に登場する中心的なキーワードであるCI/CDと、Infrastructure as Code（以下、IaC）について簡単に説明します。

IaCとは、インフラ構成をコード化して、そのプロビジョニングを自動化する手法です。コード化されたファイルはコードリポジトリで管理することが多く、また、IaCを実現するためのツールやサービスの利用が不可欠になります。

CI/CDは、その名の通り、CI（継続的インテグレーション）とCD（継続的デリバリー）の組み合わせです。CIはコードの変更を起点にコードの静的分析、ビルド、テスト、成果物の生成などの実行を自動化する手法です。一方、CDはCIで検証・テストされたコードや成果物を目的の環境に自動でデプロイする手法です。IaCと同様に、CI/CDを実現するためのツールやサービスの利用が不可欠です。

CI/CDの導入は組織全体のパフォーマンス向上のため

CI/CDを導入する目的として、運用負荷の軽減や、自動化されたテストやデリバリによる品質の向上などが一般的に言われていることかと思います。もちろんこれらはCI/CDを導入する理由の1つではありますが、あまり強いものではありません。我々が考えるCI/CDを導入する真の目的は組織全体のパフォーマンス向上です。

CI/CDを導入することで、本来人間が行う必要のない作業は自動化され、結果的に空いた時間で本質的な作業に取り組むことができます。たとえば、開発者であればアプリ開発、SREであればサイトの信頼性向上といった本質的な作業に時間を割くことができます。これらのことはメンバーのモチベーション向上と、組織全体の生産性向上につながるものと考えています。

また、CI/CDパイプラインに落とし込むためには、作業の手順化とIaC化が必要になります。IaC化の恩恵は非常に大きく、変更履歴が管理できるようになり、属人的になりがちな運用・開発業務を非属人化しスケールさせることができるようになります。結果、組織全体のパフォーマンス向上が期待できます。

CI/CDを起点としたサービス環境の構築・更新

本プロジェクトにおいて、CI/CDはサービス環境の構築・更新の起点となる、非常に重要なプロセスであると捉えています。CI/CDの基本方針は以下の通りです。

可能な限りサービス環境の構成はIaC化する
サービス環境の構築・更新はCI/CDパイプラインから行うことを基本とする
もちろんIaC化、CI/CD化が技術的難しい、もしくはコスト的に見合わない場合は例外的にやらないものの、手動実行のための手順の文書化を徹底する

継続的な更新ループ

CI/CDを中心としたサービス環境の更新ループの基本的な流れを紹介します。

先述の通り、CI/CDを起点としたサービス環境の構築・更新を基本方針としています。これをコード作成・変更から、CI/CDパイプラインからのサービス環境へのデプロイ、監視や試験結果によるフィードバックを元にさらにコード更新されるまでの一連のループを表したのが次の図です。

開発・検証、ステージング、本番環境など、ネットワークやKubernetesクラスタレベルで分離された複数環境を用意
GitHubでPull Request（以下、PR）を投げたら、自動的にテストを実行
PR上でレビューが完了するとソースコードがmasterブランチへマージされ、CI/CD経由で開発・検証とステージング環境に自動デプロイ
リリースはreleaseブランチ管理で、releaseブランチにPRを投げてレビュアーによる承認、ソースコードのマージを経て、CI/CD経由で本番環境に自動デプロイ
サービス環境は常に自動監視され、異常が検知されると関係者にアラート通知
ステージング環境で結合試験、負荷試験を実施し、本番想定の環境で機能要件・非機能要件の確認実施

この更新ループのゴールは、局所的ではなく全体として機能するよう継続的にアップデートできることです。そのため、開発・検証環境やステージング環境など、分離された環境でのアプリやインフラの変更点による影響の洗い出しはとても重要なプロセスになります。

また、上述の通り、デプロイ前のチェック機構として必ずレビュープロセスを通るようになっています。以下、レビュープロセスのポイントとフロー図になります。

PRにおいてマージ前に必ずレビュープロセスを通るように、ブランチの保護機能でレビュー必須を有効化している
ソースコードの品質のみならず運用的な観点でコードの変更点による運用プロセスへの影響もレビューする
必要に応じて関連文書も含めてレビューする

CI/CDパイプラインの紹介

マイクロサービスプロジェクトで導入しているCI/CDパイプラインを簡単に紹介します。

CI/CDを起点として構築・更新しているインフラやプラットフォームサービスのパイプラインをインフラCI/CDとして、またコンテナーアプリのパイプラインをアプリCI/CDとして紹介します。

なお、本プロジェクトではクラウド基盤にAWSを採用しており、アプリはコンテナーベース、コンテナーアプリの基盤プラットフォームにはマネージドKubernetesサービスであるEKSを採用しています。

また、AWS外のサービスでは、APMにDatadog、障害通知にPagerDutyを採用しています。CI/CDパイプラインは、インフラ・アプリ共にGitHub Actionsを活用して構築しています。

インフラCI/CD

ネットワークやストレージを始め、IAM、監視、ログ解析サービスなどAWSで利用しているほぼすべてのリソースをAWS CloudFormation（以下、CFn）を活用してIaCを実施しています。CFnが対応しているリソースをCFnテンプレートに落とし、これをGitHubでコード管理します。CI/CDパイプラインで、CFnのChange Setの仕組みを使ってリソースの変更点を検証し、サービス環境にデプロイします。

また、コンテナーアプリはEKSにデプロイします。アプリのデプロイに必要なKubernetesリソースはすべてKubernetes YAMLファイルに落とし、これをGitHubでコード管理します。CI/CDパイプラインでYAMLの差分チェックを行い、EKSにデプロイします。

さらに、AWS外のDatadogやPagerDutyなどの利用サービスについても、Terraformを活用してIaCを実施します。これらの構成定義をTerraform構成ファイルに落として、GitHubでコード管理します。CI/CDパイプラインでterraform plan/applyコマンドを実行しサービス環境にデプロイします。

各CI/CDの利用IaCツールとパイプラインの内容を表したものが下図です。

アプリCI/CD

先述の通り、EKSにデプロイするためのコンテナーアプリをビルド、静的分析して最終的にECR（AWSのマネージドコンテナーレジストリサービス）にPUSHするところまでをCI/CDで行います。構築するコンテナーの構成をDockerfileに記述し、インフラCI/CDと同様にアプリのコードを含めてGitHubでコード管理します。

なお、ここでは内容については紹介しませんが、データ生成用の定期実行ジョブやDBのマイグレーション処理についてもCI/CDで実行している例もあります。

以上、簡単ではありましたが、CI/CDパイプラインの活用事例を紹介しました。

DevとOpsの責任分界点

DevとOpsは弊社組織でいうと、開発者（Dev）と運用管理を行うSRE（Ops）になります。マイクロサービスプロジェクトにおいては、その名の通り、開発者は基盤となるアプリケーションの開発を、SREはマイクロサービスの信頼性を向上させるための運用・開発作業を主に行います。

ただし、DevとOpsの間に責任分界点が明確に分けられているかと言えばそうではありません。基本的な精神としてソフトウェアをスピーディかつ安定的にデリバリすることが中心にあり、そのためには双方が協力し、それぞれのドメインを越えることは多々あります。つまり分界点は良い意味であいまいです。

たとえば、アプリケーションコードにSREが手を入れることもありますし、アプリのCI/CDパイプラインをSREが作成することもあります。また、開発者がKubernetes YAMLファイルに手を入れることもあります。

まとめ

本記事ではZOZOTOWNのマイクロサービスプロジェクトで実践しているCI/CDについてご紹介しました。徹底したIaC化とCI/CDを起点としたサービス更新の取り組みがご理解いただけたのではないでしょうか。

なお、今回のトピックはCI/CDでしたが、マイクロサービスプロジェクトにおいては数多くのおもしろい技術的取り組みやチャレンジがあります。これらについては他のメンバーがどこかで共有してくれるはずですのでご期待いただければと思います。

登壇資料や関連サイト

著者のボスにあたる、そのっつさんがInfra Study Meetup#1にて、リモートワークとIaCやCI/CDとの相性の良さについて発表しました。その時のスライドがこちらです。

docs.google.com

ZOZOテクノロジーズは、技術書典応援祭にて、有志で制作した技術同人誌【ZOZO TECH BOOK VOL.1】の頒布を行いました。著者は同誌において「第3章　速習GitHub Actions 〜明日からの充実GitHub自動化ライフのための凝縮ポイント〜」というタイトルで、GitHub Actionsについての記事を執筆しました。現在も引き続きBOOTHにて頒布中ですのでご覧いただけたら幸いです。 zozotechnologies.booth.pm

さらに、関連イベントとして、4/28と4/30の二日間、頒布をしている ZOZO TECH BOOK VOL.1 の解説会をオンラインで実施しました。著者は、そこで同記事に関する解説を行いました。そこでの発表スライドもよろしかったらご参照ください。