コードレビュー自動化、障害注入／分散トレーシング、マルチクラウドIaC――コンテナベースのCI/CDがもたらす新たな開発者体験とは：コンテナベースのCI/CD本番事例大解剖（終）（2/2 ページ）

[藤原涼馬, 小松凌也，リクルートテクノロジーズ]

アジリティの向上

　アジリティの向上という観点ではこれまでの取り組みとして、「アプリケーションコードの作成から本番デプロイまでのリードタイムをどうやって短くするか」に注力してきました。

　また、最も更新頻度が高くデプロイされることの多いアプリケーションコードの、デプロイまでのプロセスを効率的かつシンプルにしました。これにより、同コードの作成からデプロイまでのリードタイムを削減し、事業運営における仮説検証のサイクルを短期間で回す、各種不具合の修正デプロイを容易に実施できる基盤を作り上げました。

　さらに、アジリティを向上させるにはDocker、Kubernetesの活用にとどまらず、Infrastructure as Code（IaC）のスコープを広げていくことが必要になってきます。システムの動作環境全体のコード化に本格的に取り組むことを通じ、本番相当の環境をオンデマンドで払い出せるようにすることで、DX（Developer eXperience：開発者体験）と開発アジリティのさらなる向上を図ろうとしています。

マルチクラウドIaCの推進

　パブリッククラウド上でのサービス開発を進める上では、DockerとKubernetsを中心としたコンテナ技術に加えて、Amazon Web Services（AWS）やGCPなどのクラウドプロバイダーが提供するマネージドサービスを活用することがアジリティを高く保つための鍵となります。

　例えば、「Amazon ElastiCache」「Google Cloud Memorystore」はスケールするハイパフォーマンスのインメモリデータベースを提供します。よく利用される「Amazon S3」「Google Cloud Storage」のようなオブジェクトストレージをはじめ、メール送受信サービスの「Amazon SES」、スケーラブルな権威DNSを利用できる「Amazon Route 53」「Google Cloud DNS」など多種多様なサービスが各クラウドプロバイダーによって提供されています。これらの活用がインフラの構築、運用にかかる人的コストの大きな削減につながります。

　各クラウドプロバイダーは、利用可能なサービスごとに詳細な機能要件を定義するためのグラフィカルな入力インタフェース（GUI）をユーザーに提供しています。GUIを利用すれば、プログラミングに精通していないユーザーであっても、簡単にサービスを利用できます。その一方で、構築に際してその設定値や構築手順を正確にドキュメントに残すことなどが必要になります。

　GUIを使う場合、開発環境を追加でもうワンセット構築したいといった場合に同じ手順を手動で何度も繰り返す必要が生じます。このようなトイル（※）を削減するためには、IaC化が必要不可欠です。

※自動化できるにもかかわらず、手作業で行う運用作業

　IaCとは、物理／仮想サーバ、コンテナ、クラウドリソースのようなインフラの構成をコードで定義することにより、コードベースでのインフラ管理を可能にするという概念です。

　AWSやGCPなどのクラウドリソースに対しIaCのツールを適用することで、GUIを人間が操作することで発生するヒューマンエラーや、環境追加で発生するリードタイムを削減することも可能になります。また、コード自体が設計と構成を表すドキュメントにも成り得ます。このように、IaCのツールの導入による恩恵は多岐にわたるといえます（図6）。

図6　クラウドインフラ＋IaCのイメージ

　さて、ここまでDockerやKubernetesなどと同様にパブリッククラウドの環境構成をコードで管理できること、それによるメリットを説明しました。

　しかし、単一のサービスで複数のクラウドプロバイダーを利用する場合、環境構成をどのようにしてIaCの世界に落とし込むのか――そこは少し難しい問題です。例えば、「AWS CloudFormation」が管理対象とするのはAWSのリソースのみです。マルチクラウド環境でこのAWS CloudFormationのような機能を利用する場合は、GCPのリソースを管理するために別のツールを併用したり、手作業で構築したりする必要があります。

　HashiCorpが提供するコードソフトウェアツール「Terraform」は、AWSやGCPを含む約90ものプラットフォームに対応しています。Terraformが優れているのは、宣言的なリソース定義によるストレスフリーのクラウドリソースの構成管理ができる点だけではありません。リソースタイプとそのインタフェースさえ用意されていれば、「背後に存在するクラウドプロバイダーや、そのサービスがどのようになっているのか」をあまり気にすることなく、複数のクラウドプロバイダーに対するリソースの操作ができます。例えば、次のような一連の手続きを行います。

1. AWSのマネジメントコンソールを開く
2. AWSでリソースを作成
3. 作成したリソースのエンドポイントをコピー
4. GCPのマネジメントコンソールを開く
5. GCPでリソースを作成
6. AWSで作成したリソースのエンドポイントをペースト

　こうした手続きをソースコードに落とし込んで、IaCの世界で管理することを可能にしてくれます（図7）。

図7　マルチクラウドIaCのイメージ

Terraformを使ったマルチクラウドIaCのサンプル

　ここでは、TerraformでAmazon SESとGoogle Cloud DNSを用いたマルチクラウドのDNSレコードを認証する例を紹介します。使用するTerraformのリソースタイプは、次の4種類のみです。

• aws_ses_domain_identity
• aws_ses_domain_dkim
• google_dns_managed_zone
• google_dns_record_set

　これらは分かりやすくするために、それぞれ「aws」「gcp」というモジュールに分割して管理することにします。ディレクトリツリー構造は図8のようになります。

project
├── config.tf
├── main.tf
├── provider.tf
├── variables.tf
└── modules
   ├── aws
   │   ├── aws_ses.tf
   │   └── variables.tf
   └── gcp
       ├── gcp_cloud_dns.tf
       └── variables.tf

図8　ディレクトリツリー

　AWSとGCPを併用するため、「project/provider.tf」には複数のproviderの定義が混在することになります。

　ここで1つ注意が必要です。2019年10月現在Amazon SESがサポートしているリージョンは、送受信機能ともに「us-east-1」「us-west-1」「us-west-2」の3つのみとなっています。そのため、AWSのproviderを「ap-northeast-1」「us-east-1」でそれぞれエイリアスとして定義して使わなければなりません。Amazon SESでのメール送信を有効にするためには、有効にしたいAmazon SESドメインを管理可能な権威DNSサーバのゾーンに、認証情報を含むレコード（TXT、MX、CNAME）を登録する必要があります（図9）。

図9　アーキテクチャ図

　一般的には、Amazon SESの認証には同じAWSのフルマネージド権威DNSであるAmazon Route 53を使うと思いますが、Google Cloud DNSで認証する場合であっても特別な設定などを入れる必要はなく、resourceのparameterに渡す認証情報の形式に気を付けさえすれば容易に認証できます。

図10　SES認証のイメージ

　リソースの依存関係もTerraformが解決してくれるため、「terraform apply」コマンドでこのレシピを適用するとGoogle Cloud DNSで認証されたAmazon SESのメール送信機能を利用できるようになります。

　機能改修や拡張が進むにつれて、より多種多様なクラウドリソースを利用するようになり、環境の構成はより複雑さを増していきます。このような状況に対応していくには、IaCを適用して管理を高度化していくしかありません。

　Terraformを用いたマルチクラウドIaCによるソリューションは、複雑化するクラウドインフラを開発、運用する上で、アジリティを落とさないための重要な要素となるでしょう。

IaCの範囲拡大によるアジリティの向上

　さて、ここまでマルチクラウド環境におけるIaCについてTerraformを活用したサンプルも含めて解説しました。

　最後に、Docker、KubernetesとコンテナベースのCI、そしてTerraformを使って実現したい世界観について解説します。

図11　これまでのIaC化範囲とこれからのIaC化範囲

　Docker、Kubernetes、コンテナベースのCIで実現できていたのは、図11左側の範囲まででした。具体的には、アプリケーションとパブリッククラウドの提供するマネージドサービスをつなぎ、アプリケーションデプロイのリードタイムを短縮することでした。

　今後はTerraformを組み合わせることで、アプリケーションのデプロイのリードタイム短縮だけではなく、本番と同様の構成を持った環境を効率的に払い出し、さらに開発者体験を向上させることで、効率的なサービス開発の実現を目指したいと思います（図11右側）。

　これにより、コード化によってCI/CDのパイプラインに乗せることができるようになります。IaC化されたコードをパイプラインに乗せ、コードと実環境の差分を調べられるようにすることで、インフラ構成変更時のリスクなども確実に洗い出せるようになることでしょう。

まとめ

　これまでの連載では3回にわたり、技術選定、アプリケーションエンジニア視点での各種課題への取り組み、インフラ／運用エンジニア視点での各種課題への取り組みについて解説してきました。

　今回の内容はCI/CD、コンテナやKubernetesから外れたように感じられた部分もあったかもしれません。しかし、このような大胆な取り組みについて現実的に考えられるようになったのは、コンテナ技術の活用により、アプリケーションのビルド、テスト、デプロイの品質が劇的に向上したことに起因します。

　確かに現時点では、技術的に大変な部分があることも事実です。とはいえ、高いアジリティに基づいて仮説検証サイクルを高速で回すということに重点を置くサービスの場合は、間違いなくプラスに働いていると実感しています。

　本連載を最後まで読んでいただいた皆さんも、サービス開発のアジリティと開発者体験を向上させるためにチャレンジしてみてはいかがでしょうか。連載にお付き合いいただきありがとうございました。

筆者紹介

藤原 涼馬

リクルートテクノロジーズ ITエンジニアリング本部 プロダクティビティエンジニアリング部 クラウドアーキテクトグループ所属

ユーザー系SIerでのR＆D業務を経て2016年から現職。前職ではシステムの性能分析系技術の研究開発に従事。現在は主に、リクルートグループにおけるコンテナ仮想化をベースとしたシステムの設計・構築・運用に従事。

コンテナ管理ツール「Rancher」のコミュニティー（Rancher JP）のコアメンバーも務める。

小松 凌也

リクルートテクノロジーズ ITエンジニアリング本部 プロダクティビティエンジニアリング部 クラウドアーキテクトグループ所属

2018年新卒入社。パブリッククラウドやInfrastructure as Code（IaC）絡みの技術を主に扱い、リクルートグループの新規プロダクトにおけるインフラ開発やエンハンス、既存プロダクトのインフラ運用などに従事。IaCの考えを積極的に取り入れた高汎用インフラの開発と普及を目指している。