Kubernetes、コンテナ技術を活用した開発アジリティー向上にインフラアーキテクトはどう貢献したのか：コンテナベースのCI/CD本番事例大解剖（1）（3/3 ページ）

Kubernetes、コンテナ技術を活用したCI/CD基盤におけるサービス開発について、リクルートの事例を基に解説する連載。初回は、インフラアーキテクトの視点から技術選定の考え方について解説。

[藤原涼馬，リクルートテクノロジーズ]

CI/CD、監視／モニタリングにおけるツール選定

　技術の選定については、最終的にたどり着きたい世界観やその意図を議論することも重要です。その上で要求されるQCD（Quality、Cost、Delivery）のバランスを考え、具体的なロードマップを定めた上で選定を進めます。

「Cloud Native Trail Map」を参考に

　技術面でのロードマップについて考える際、筆者は「Cloud Native Trail Map」（図6）をよく利用しています。本事例では、リリースまでに与えられた期間、メンバーの持っているスキルから判断して、4ステップ目の「4.可観測性と分析（Observability＆Analysis）」の途中まで選定することを、リリースまでのマイルストーンとしました。

図6　Cloud Native Trail Map（「Cloud Native Landscape」から引用）

　この中で「1.コンテナ化（Containerization）」はDockerが、「3.オーケストレーションとアプリケーション定義（Orchestration＆Application Definition）」の大部分についてはKubernetesが担っているので割愛します。

　ここからの解説の中心は主に「2.CI/CD」と「4.可観測性と分析（Observability＆Analysis）」つまり「監視／モニタリング」になります。

CI/CDのツール選定

　CI/CDのツール選定においては候補として3つのツール「Jenkins」「Circle CI」「Concourse CI」を対象としました。

　選定の際には主に下記の3要素に基づいて判断しました。

1. コンテナベースのサービスを前提として安定したCIを提供できる。過去のビルドが、後で実行したビルドプロセスに影響しづらくする（図7）
2. バージョンアップ対応などが容易である
3. CIパイプラインの定義をコードで管理できる（図8）

図7　中間生成物のビルドプロセスへの影響の排除とコンテナ

図8　CIパイプラインのコード管理（パイプラインイメージは一例）

　今回は最終的にConcourse CIを選定しました。他を選定しなかった理由とConcourse CIを選定した理由について説明します。

　まず、Jenkinsです。組織内のノウハウという意味では唯一充足できましたが、上記3要素がいずれも容易には充足できないことがこれまでの利用経験から明らかだったため、採用しませんでした。

　次に、Circle CIです。SaaSモデルもオンプレミスのモデルも選択でき、コンテナベースであり、さらにパイプラインのコード管理も可能です。しかし、開発を開始した当時はバージョン1.x系から2系への移行時期でした。その時点（2017年末から2018年初頭）では、安定性やドキュメンテーション面で懸念があったため、見送りました。現時点で選定し直すとすれば採用の可能性は十分にあると思います。

　最後に、Concourse CIです。検証した結果、コンテナベースかつ、CIパイプラインのコードについても大規模なものまでカバー可能であること、バージョンアップ対応も容易だったことなどが魅力的でした。さらに、小規模な利用から大規模な利用まで、利用規模に合わせたさまざまな展開方法があったり、追加機能を自分で実装することも容易だったりしたことなどもあり、これを採用しました。

監視／モニタリングツールの選定

　監視／モニタリングツールの選定に際しては、前述の要件3「中期的視点でのコストを小さくすること」に注力しました。「Prometheus」と「Datadog」を候補として選定を進めました。

　Datadog自体の利用ノウハウが組織内に多数あったこと、SaaS形式で提供されるため、月額費用さえ支払えば、追加の運用コストがほぼかからない点から採用しました。

図9　PrometheusとDatadogのコストイメージ

　一方Prometheusは、監視に利用するためのサーバも含めて自力で運用する必要があったため、今回の規模のサービスでは運用の負担が大きくなり過ぎると考え、採用を見送りました。

　長期的には将来的にサービスが非常に大きくなり、Datadogの月額費用がPrometheusの運用コストを上回る可能性も大いにあります（図9）。その際は移行も含めて検討する必要があるでしょう。しかし、中期的視点でのベターな選択としてDatadogを選びました。

選定し、実装した結果得られたもの

　今回は筆者の関わったプロジェクトを基に、コンテナ化／Kubernetes対応を行う目的から技術選定までの流れを解説しました。DockerとKubernetesの特性を生かし、結果として、下記のようなメリットが得られました。

• 信頼性の高いCIによるアプリケーションコードの品質向上
• デプロイプロセスの磨き込みを通じたデプロイ品質向上

　信頼性の高いCI環境でテストを高頻度で実行し、その結果を受けてコードを改修することがアプリケーションコードの品質向上につながったと思います。

　また、サービスを構成するコンポーネントをDockerでコンテナイメージ化し、Kubernetesで宣言的なデプロイを実現することで、環境を問わず全く同じかつ単純なプロセスでデプロイできるようになりました。

　しっかりとテストされたコードと、磨き込まれたデプロイ品質によって、エンジニアがデプロイの際に感じる不安を大幅に削減できたと思います。結果として、本番環境への各種リリースが高頻度で行えるようにもなっています。

　現時点では、これらの仕組みがうまく機能しており、ここで得られたノウハウをさらに洗練させて他プロダクトの開発にも積極的に展開しています。一方で、これらの仕組みを安定させるまでには、多くの課題と解決に向けての試行錯誤がありました。これら課題の具体的な内容と、その対応については、次回以降解説します。

筆者紹介

藤原 涼馬

リクルートテクノロジーズ ITエンジニアリング本部 サービスオペレーションエンジニアリング部 プロジェクト基盤グループ所属

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

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