JD.comはいかにしてOpenStackからKubernetesに移行したか

中国最大のEコマース企業のひとつであるJD.comは先頃、従来使用していたOpenStack管理のIaaSを、Kubernetesを採用したアプリケーションコンテナベースのインフラストラクチャへと発展させた、自らの経験について公開した。自社開発のネットワーク用コンポーネントを含む今回の変更により、リソース利用率が30%向上している。

JD.comのデプロイメントインフラストラクチャにおけるアプリケーションコンテナの採用は、物理的な機器(2004～2014)とオペレーティングシステム(OS)コンテナ(2014～2016)という、２つのフェーズで実施された。最初のフェーズでは、ベアメタルマシンを手作業によって管理していた。このセットアップで直面した問題は、立ち上げ(go-live)時間の長さ(アプリケーションの割り当てからオンラインまで約1週間)、アイソレーションの欠如、リソース利用率、硬直的なスケジュールといったものだった。機器の故障がアプリのマイグレーションにつながり、対処に数時間を必要としていた。自動スケール機能はなく、ログ収集や自動デプロイメント、コンパイル、パッケージング、リソース監視といった一般的なタスクのために、技術チームが内製ツールを開発するような状況だった。

インフラストラクチャの第２段階ではコンテナが採用された。使用したのはOSコンテナで、既存のアプリケーションとデプロイメントアーキテクチャをそのままコンテナに移し替える形だった。つまりコンテナは、それまでの物理的マシンの単なる小型高速バージョンであって、コンテナの思想が本格的に導入された訳ではなかったのだ。

そうではあっても、コンテナの採用によって、第２フェーズで実現された時間やリソースの面でのアドバンテージは少なくなかった。コンテナ層としてはOpenStackが、コンテナ管理にはnova Dockerドライバが使用された。コンテナプラットフォームとしてはDockerを採用した上で、いくつかの新機能を追加した。すべてのアプリケーションがコンテナに移行したことにより、必要なコンピューティングリソースは１週間から数分に短縮された。アプリケーションの平均展開密度と物理的マシンの使用率は３倍に増加した。デプロイを行なうための統合APIも開発され、社内的にJDOS(JD Datacenter Operating System) 1.0と呼ばれた。

OpenStackベースのセットアップでは、単一のクラスタに4,000～10,000の計算ノードが接続されていた。2016年11月時点で、JD.comにはおよそ150,000のコンテナが運用されていた。これによって同社では、サイトが実施した２回のプロモーション中に発生した大量のトラフィックを処理することができた。その内の１回である2016年11月には、約3,000万件の成約が確認されている。

コンテナへの移行は技術チームにとって、第２フェーズ以降においてデプロイメント単位としてコンテナを使用するように、デプロイメントアーキテクチャを変更するための道を開くものだった。チームはこれをJDOS 2.0と呼んだ。このアプローチの焦点は単にインフラ管理だけでなく、アプリケーションを意識したコンテナの管理にある。設計上はシステムとアプリケーションという、２つの抽象化が用意された。“システム”は複数の“アプリケーション”からなり、個々のアプリケーションには同じサービスを提供するいくつかのポッド(Pod)がある、という構成だ。ここでのシステムは、Kubernetesのネームスペースに対応する。

デプロイメントパイプラインを構成するコンポーネントに加えて、DevOpsのツールもコンテナ化されていて、Kubernetsの管理するプラットフォームにデプロイされる。これにはGitlab、Jenkins、Logstash、Harbor、Elasticsearch、Prometheusなどが含まれている。デプロイメントプロセスはソースコードとDockerfileで構成されていて、リポジトリにプッシュされてJenkinsでビルドされる。Jenkinsはマスタ-スレーブモードに設定されていて、アプリケーションの構築とパッケージングを行なうスレーブノードと、コンテナイメージを構築する同様のノードがある。生成したイメージの保存には、オープンソースのDockerレジストリであるHarborを使用する。

イメージ提供 : http://blog.kubernetes.io/2017/02/inside-jd-com-shift-to-kubernetes-from-openstack.html

KubeletとOpenStackのNeutronを統合するためにJD.comでは、Caneという名の、CNI(Container Networking Interface)ベースのソリューションを独自に開発した。Kubernetesがロードバランサの生成や削除、あるいは変更を行なうと、CaneがNeutronロードバランシング・アズ・ア・サービス(LBaaS)にそれを通知する。Cane内部のHadesというコンポーネントが、内部DNS解決サービスをPodに提供する。