本連載では、サービスの開発、提供のアジリティ向上の一助となることを目的として、企業における「Kubernetes」の活用について解説する。今回は、リクルートテクノロジーズにおいて筆者が取り組んだ事例を基に、コンテナ仮想化技術を本番環境で利用する際の取り組み、成果と課題、「なぜ最終的にKubernetesを活用する決断に至ったか」を説明する。
昨今、コンテナオーケストレーションツール「Kubernetes」に注目が集まっています。本連載「先行事例に学ぶKubernetes企業活用の現実」では、サービスの開発、提供のアジリティー向上の一助となることを目的として、企業におけるKubernetesの活用について数回にわたり解説します。
前回は、DockerのおさらいとKubernetesの概要、起源、現状を説明しました。今回はリクルートテクノロジーズにおいて筆者が取り組んだ事例を基に、コンテナ仮想化技術を本番環境で利用する際の取り組み、成果と課題について説明します。また「なぜ最終的にKubernetesを活用する決断に至ったか」を述べます。
筆者の取り組みをまとめると3つのフェーズに分けることができます。
最初から大規模に適用するのではなく、規模や「社内外のどちらに提供するか」といった中で段階を設けて検討と適用を進めています。
本フェーズ以前の取り組みとして開発環境での適用については、過去の取り組みとして実施済みであり、成果が上がっていました(参考:Dockerを活用したリクルートグループ開発基盤の構築)。
ここで得られたメリットを生かしつつ、「どのようにして本番環境でもコンテナ仮想化技術を活用するか」の観点で取り組みを進めました。
本フェーズの目的は2つです。
前者については文字通りの内容です。後者については少し補足します。
これまでリクルートグループでは、「どのサービスでも一定の品質を担保する」ことを目的として利用する技術スタックを標準化していましたが、「サービスごとの特性に、より適した技術スタックを採用したい」という要求は年々高まっていました。そこで本フェーズでは、目的に「技術スタックの多様化に伴う、ビルド、デプロイ運用の複雑化を緩和、削減する」ことを含めました。
ごく小規模かつ、コンテナ仮想化技術の本番環境への初適用ということで「Docker知見者の不足」「低コスト運用の確立」という課題がありました。これらへの対策として、表1に挙げる形で対応しました。
課題 | 詳細 | 対策 |
---|---|---|
Docker知見者の不足 | そもそものDockerの知見を持つ人が不足している | 知見の不足を補うツール、仕組みを準備する |
低コスト運用の確立 | ごく小規模なシステムなので、運用にかかる人手と計算リソースを最小化する | ・運用の手間が少ない技術を選定する ・計算リソースの消費が少ない仕組みを利用する |
Dockerの知見を持つメンバーの不足に対しては、知見の不足を補助しつつ、「必要な操作を実施できる」ことを目的として表2に挙げるツールを導入して対応しました。
ツール名 | 用途 | 期待した成果 |
---|---|---|
Rancher | コンテナ操作用のGUI提供 | 開発、運用メンバーがDockerのコマンドを実行することなく、コンテナを操作できるようにする |
Jenkins | CI/CD(継続的インテグレーション/継続的デプロイ)の提供 | 開発、運用メンバーがDockerのコマンドを実行することなく、ビルドおよびデプロイを実行できる |
ツール選定においては、「認証の仕組みなどを備えていること」「導入、学習コストが低く保てること」などを中心に据えて行いました。
ここでは、小規模システムで必要となることの多い「必要となる計算リソースの最小化」「運用にかかる人的コストの最小化」という2点の課題についての対応を中心にオーケストレーションツールを選定しました。
構築対象のシステムはオンプレミスでの運用前提だったため、Kubernetesでは当時は2つの課題を共に充足できませんでした。そこで、両者を充足できそうな「Docker Swarm mode」を採用しました。
ビルド、デプロイの複雑化への対応として、Dockerfileによるビルドのコード化、Docker Swarm modeによるデプロイの単純化に加えて、それらの一連の流れをJenkins上でパイプライン化することで複雑さを隠蔽(いんぺい)できました。
結果として、開発メンバーはビルド、デプロイの複雑さを意識することなく開発を進めることができました。特に、リリース直前の追い込み時期には、「テスト版のリリース→ユーザーテスト→フィードバック」のサイクルを高頻度で回すことができ、サービスの品質向上につなげられました。
また、コンテナオーケストレーションツールを利用することで可用性などの非機能要件についても充足できました。
第1フェーズの残課題は、主にデプロイ周りです。本フェーズでは、Docker Swarm modeのコマンドをJenkinsのパイプライン上で繰り返し実行することでCDを実現しました。つまり、手続き型のデプロイを実施していました。
手続き型でデプロイを記述する場合、システム規模の拡大に伴って生じる問題点として以下の2つが挙げられます。
よって、大きな規模のシステムでは、図1に示すように、手続き型ではなく宣言型でデプロイを記述した方がよいことが分かりました。
第1フェーズでの取り組みの結果、コンテナオーケストレーションツールを用いることで本番環境においてもコンテナ仮想化のメリットを享受できることが確認できました。
そこで、大規模なシステムにおいても同様の効果が得られることを期待して社内向けの大規模システム構築にコンテナ仮想化を適用することにしました。
第1フェーズで挙がったデプロイに関する課題に対しては、宣言型のデプロイを記述することで対応しました。本フェーズでは「Rancher」(とオーケストレーションツールには「Cattle」)を採用しました。Rancherを採用したのは以下に挙げる3つの理由によるものです。
ここに挙げたRancherだけではなく、Jenkinsも含めたCI/CDの仕組みを提供することで大規模開発における取り組みを推進しました。
Rancherを用いてシステム全体の定義を宣言的に記述できたこと、個別のコンポーネントをGUI経由でアップグレードできたことから、あまりコンテナ仮想化に詳しくない開発メンバーでもデプロイ作業を実施できるなど、大規模環境でも十分なメリットを享受できることを確認できました。
特に個別コンポーネントを短時間でアップグレードできることから効率的にテストを実施でき、品質の改善に大きく貢献しました。
第1フェーズ、第2フェーズ共に、コンテナ仮想化とコンテナオーケストレーションツールを活用することで、以下のようなメリットが得られることが分かりました。
ここまでの取り組みを見ると、Kubernetesを活用しなくても十分な成果が上がっているように見えます。にもかかわらず、なぜKubernetesに取り組むことを決断したのかについては第3フェーズで説明します。
Kubernetes活用に取り組むの理由については、前回の記事から振り返ってみます。Kuberenetesの活用を勧める理由は、特に以下の2点に起因します。
AWS(Amazon Web Services)やMicrosoft Azure、GCP(Google Cloud Platform)などの主要パブリッククラウドサービスにおいてKubernetesマネージドサービスが提供されるようになったこと、さらに競合するツールを持っていた陣営も相次いでCNCFのメンバーになったことから、「Kubernetesがコンテナオーケストレーションツールのデファクトスタンダードである」という状況が生まれています。
このような状況下では、次に挙げることがKubernetesに期待できます。
2017年まではKubernetesについて学習するための環境を確保するだけで手間がかかる状態でしたが、現時点(2018年3月)では、Kubernetesが統合されたDocker(Mac版/Windows版)をローカル端末で利用できるようになりました。
その結果、今後はKubernetesについて学習し、活用できるだけの知識を持ったエンジニアは増加すると思われます。
Kubernetesの活用にたどり着くまでに、複数のフェーズを経て対応しました。段階を踏んで、それぞれで現れる課題を1つ1つ解決することで、自信を持って次のフェーズへと取り組むことができました。
Kubernetesに限らず、複雑な仕組みの活用に取り組む際には一気呵成(かせい)に取り組むだけではなく、今回のように「長期的に段階を踏んで徐々に取り組めるだけの地力を蓄える」方法もあるということも頭の隅に置いていただけると幸いです。
次回は、「Kubernetesをなぜ活用するのか」について技術的な面からもう少し掘り下げて説明するとともに、Kubernetesを活用する上でのノウハウについて、開発プロセスの観点も含めて説明します。
リクルートテクノロジーズ ITエンジニアリング本部 サイトリライアビリティエンジニアリング部 インフラストラクチャエンジニアリンググループ所属
ユーザー系SIerでのR&D業務を経て2016年から現職。前職ではシステムの性能分析系技術の研究開発に従事。現在は主に、リクルートグループにおけるコンテナ仮想化をベースとしたシステムの設計・構築・運用に従事。
コンテナ管理ツール「Rancher」のコミュニティー(Rancher JP)のコアメンバーも務める。
Copyright © ITmedia, Inc. All Rights Reserved.