Kubernetes活用に至るまで――リクルートテクノロジーズがコンテナを大規模システムの本番環境へ適用した事例：先行事例に学ぶKubernetes企業活用の現実（2）

本連載では、サービスの開発、提供のアジリティ向上の一助となることを目的として、企業における「Kubernetes」の活用について解説する。今回は、リクルートテクノロジーズにおいて筆者が取り組んだ事例を基に、コンテナ仮想化技術を本番環境で利用する際の取り組み、成果と課題、「なぜ最終的にKubernetesを活用する決断に至ったか」を説明する。

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

コンテナ仮想化技術を本番環境で利用する際の3つのフェーズ

　昨今、コンテナオーケストレーションツール「Kubernetes」に注目が集まっています。本連載「先行事例に学ぶKubernetes企業活用の現実」では、サービスの開発、提供のアジリティー向上の一助となることを目的として、企業におけるKubernetesの活用について数回にわたり解説します。

　前回は、DockerのおさらいとKubernetesの概要、起源、現状を説明しました。今回はリクルートテクノロジーズにおいて筆者が取り組んだ事例を基に、コンテナ仮想化技術を本番環境で利用する際の取り組み、成果と課題について説明します。また「なぜ最終的にKubernetesを活用する決断に至ったか」を述べます。

　筆者の取り組みをまとめると3つのフェーズに分けることができます。

1. 小規模システムにおける本番環境への適用
2. 社内向け大規模システムにおける本番環境への適用
3. 社外向け中規模システムにおけるKubernetes活用への取り組み

　最初から大規模に適用するのではなく、規模や「社内外のどちらに提供するか」といった中で段階を設けて検討と適用を進めています。

【第1フェーズ】小規模システムにおける本番環境への適用

　本フェーズ以前の取り組みとして開発環境での適用については、過去の取り組みとして実施済みであり、成果が上がっていました（参考：Dockerを活用したリクルートグループ開発基盤の構築）。

　ここで得られたメリットを生かしつつ、「どのようにして本番環境でもコンテナ仮想化技術を活用するか」の観点で取り組みを進めました。

目的

　本フェーズの目的は2つです。

1. コンテナオーケストレーションツールを用いたコンテナ仮想化技術の本番適用
2. 「新しい技術スタックの導入によるビルド、デプロイの負担増」の低減

　前者については文字通りの内容です。後者については少し補足します。

　これまでリクルートグループでは、「どのサービスでも一定の品質を担保する」ことを目的として利用する技術スタックを標準化していましたが、「サービスごとの特性に、より適した技術スタックを採用したい」という要求は年々高まっていました。そこで本フェーズでは、目的に「技術スタックの多様化に伴う、ビルド、デプロイ運用の複雑化を緩和、削減する」ことを含めました。

検討事項と対策

　ごく小規模かつ、コンテナ仮想化技術の本番環境への初適用ということで「Docker知見者の不足」「低コスト運用の確立」という課題がありました。これらへの対策として、表1に挙げる形で対応しました。

表1　【第1フェーズ】の検討事項と対策

課題	詳細	対策
Docker知見者の不足	そもそものDockerの知見を持つ人が不足している	知見の不足を補うツール、仕組みを準備する
低コスト運用の確立	ごく小規模なシステムなので、運用にかかる人手と計算リソースを最小化する	・運用の手間が少ない技術を選定する ・計算リソースの消費が少ない仕組みを利用する

Docker知見者の不足

　Dockerの知見を持つメンバーの不足に対しては、知見の不足を補助しつつ、「必要な操作を実施できる」ことを目的として表2に挙げるツールを導入して対応しました。

表2　Docker知見者の不足への対応策

ツール名	用途	期待した成果
Rancher	コンテナ操作用のGUI提供	開発、運用メンバーがDockerのコマンドを実行することなく、コンテナを操作できるようにする
Jenkins	CI/CD（継続的インテグレーション／継続的デプロイ）の提供	開発、運用メンバーがDockerのコマンドを実行することなく、ビルドおよびデプロイを実行できる

　ツール選定においては、「認証の仕組みなどを備えていること」「導入、学習コストが低く保てること」などを中心に据えて行いました。

低コスト運用の確立

　ここでは、小規模システムで必要となることの多い「必要となる計算リソースの最小化」「運用にかかる人的コストの最小化」という2点の課題についての対応を中心にオーケストレーションツールを選定しました。

　構築対象のシステムはオンプレミスでの運用前提だったため、Kubernetesでは当時は2つの課題を共に充足できませんでした。そこで、両者を充足できそうな「Docker Swarm mode」を採用しました。

第1フェーズの成果

　ビルド、デプロイの複雑化への対応として、Dockerfileによるビルドのコード化、Docker Swarm modeによるデプロイの単純化に加えて、それらの一連の流れをJenkins上でパイプライン化することで複雑さを隠蔽（いんぺい）できました。

　結果として、開発メンバーはビルド、デプロイの複雑さを意識することなく開発を進めることができました。特に、リリース直前の追い込み時期には、「テスト版のリリース→ユーザーテスト→フィードバック」のサイクルを高頻度で回すことができ、サービスの品質向上につなげられました。

　また、コンテナオーケストレーションツールを利用することで可用性などの非機能要件についても充足できました。

第1フェーズの残課題

　第1フェーズの残課題は、主にデプロイ周りです。本フェーズでは、Docker Swarm modeのコマンドをJenkinsのパイプライン上で繰り返し実行することでCDを実現しました。つまり、手続き型のデプロイを実施していました。

　手続き型でデプロイを記述する場合、システム規模の拡大に伴って生じる問題点として以下の2つが挙げられます。

1. 手続き型ではシステム規模（≒コンポーネント数）とステップ数が比例する傾向にある
2. 個々のステップと最終的なシステム構成の対応関係が見通しづらくなる。

　よって、大きな規模のシステムでは、図1に示すように、手続き型ではなく宣言型でデプロイを記述した方がよいことが分かりました。

図1　手続き型のデプロイ定義と宣言型のデプロイ定義（補足：2018年時点ではdocker-composeとDocker Swarm modeの連携が強化された結果、Docker Swarm modeにおいてもデプロイを宣言的に記述することが可能になっています）

【第2フェーズ】社内向け大規模システムにおける本番環境への適用

　第1フェーズでの取り組みの結果、コンテナオーケストレーションツールを用いることで本番環境においてもコンテナ仮想化のメリットを享受できることが確認できました。

　そこで、大規模なシステムにおいても同様の効果が得られることを期待して社内向けの大規模システム構築にコンテナ仮想化を適用することにしました。

過去の取り組みでの課題と対応

　第1フェーズで挙がったデプロイに関する課題に対しては、宣言型のデプロイを記述することで対応しました。本フェーズでは「Rancher」（とオーケストレーションツールには「Cattle」）を採用しました。Rancherを採用したのは以下に挙げる3つの理由によるものです。

1. docker-composeファイル（とRancher独自のrancher-composeファイル）を用いて宣言的にデプロイ設定を記述できる
2. RancherのGUIからシステムを構成するコンポーネントごとに個別アップグレードできる
3. Rancher自体の環境構築がKubernetes単体よりも容易

　ここに挙げたRancherだけではなく、Jenkinsも含めたCI/CDの仕組みを提供することで大規模開発における取り組みを推進しました。

第2フェーズの成果

　Rancherを用いてシステム全体の定義を宣言的に記述できたこと、個別のコンポーネントをGUI経由でアップグレードできたことから、あまりコンテナ仮想化に詳しくない開発メンバーでもデプロイ作業を実施できるなど、大規模環境でも十分なメリットを享受できることを確認できました。

　特に個別コンポーネントを短時間でアップグレードできることから効率的にテストを実施でき、品質の改善に大きく貢献しました。

ここまでのまとめ

　第1フェーズ、第2フェーズ共に、コンテナ仮想化とコンテナオーケストレーションツールを活用することで、以下のようなメリットが得られることが分かりました。

1. 複雑な構成のシステムにおけるビルド、デプロイの容易化
   →ビルド、デプロイ作業の属人性を低減できる
2. 小まめなリリースによる品質改善のスピードの向上
   →ビルド、リリースの属人性が低下した結果、品質の改善にもつなげられる

　ここまでの取り組みを見ると、Kubernetesを活用しなくても十分な成果が上がっているように見えます。にもかかわらず、なぜKubernetesに取り組むことを決断したのかについては第3フェーズで説明します。

【第3フェーズ】Kubernetes活用への取り組み

　Kubernetes活用に取り組むの理由については、前回の記事から振り返ってみます。Kuberenetesの活用を勧める理由は、特に以下の2点に起因します。

1. Kubernetesのコンテナオーケストレーションにおけるデファクトスタンダード化
2. DockerへのKubernetesの統合

Kubernetesのコンテナオーケストレーションにおけるデファクトスタンダード化

　AWS（Amazon Web Services）やMicrosoft Azure、GCP（Google Cloud Platform）などの主要パブリッククラウドサービスにおいてKubernetesマネージドサービスが提供されるようになったこと、さらに競合するツールを持っていた陣営も相次いでCNCFのメンバーになったことから、「Kubernetesがコンテナオーケストレーションツールのデファクトスタンダードである」という状況が生まれています。

　このような状況下では、次に挙げることがKubernetesに期待できます。

1. デファクトスタンダードとして機能面、品質面で継続的な発展が見込める
2. マネージドサービスの活用による運用コストの低減が期待できる
3. 環境を問わず、オーケストレーションレイヤーを含めて可搬性を確保できる（ただし、コンテナ外のPaaSに起因して可搬性が毀損（きそん）される可能性は存在する）

DockerへのKubernetesの統合

　2017年まではKubernetesについて学習するための環境を確保するだけで手間がかかる状態でしたが、現時点（2018年3月）では、Kubernetesが統合されたDocker（Mac版/Windows版）をローカル端末で利用できるようになりました。

　その結果、今後はKubernetesについて学習し、活用できるだけの知識を持ったエンジニアは増加すると思われます。

次回は、Kubernetesを活用する上でのノウハウなどについて

　Kubernetesの活用にたどり着くまでに、複数のフェーズを経て対応しました。段階を踏んで、それぞれで現れる課題を1つ1つ解決することで、自信を持って次のフェーズへと取り組むことができました。

　Kubernetesに限らず、複雑な仕組みの活用に取り組む際には一気呵成（かせい）に取り組むだけではなく、今回のように「長期的に段階を踏んで徐々に取り組めるだけの地力を蓄える」方法もあるということも頭の隅に置いていただけると幸いです。

　次回は、「Kubernetesをなぜ活用するのか」について技術的な面からもう少し掘り下げて説明するとともに、Kubernetesを活用する上でのノウハウについて、開発プロセスの観点も含めて説明します。

筆者紹介

藤原 涼馬

リクルートテクノロジーズ ITエンジニアリング本部 サイトリライアビリティエンジニアリング部 インフラストラクチャエンジニアリンググループ所属

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

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