CodeZine(コードジン)

特集ページ一覧

サイバーエージェントがKubernetesで独自に構築! アドテク特化のコンテナ基盤とは?

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2018/05/14 14:00

目次

2016年6月に構築開始、10カ月かけて完成

 AKEの構築が始まったのは2016年6月。「この頃はKubernetes 1.2/1.3の時で、プロダクションで使うにはチャレンジングだった」と青山氏は振り返る。だが青山氏をはじめ、チーム全体で使いたいという希望があり、「実際に触れてソースコード、ネットワークなどについて知識を付けていった」と語る。

 10カ月後の2017年4月に第一弾のAKEをリリース。時間がかかったのは「人員を2人しかさけなかったため」と青山氏。その3カ月後にKubernetes 1.7がリリースされ、OpenStack Cinderのサポートを開始。CNCF(Cloud Native Computing Foundation)からもプロダクションとして使えるとアナウンスされた。

 こうして簡単にKubernetesを使えるようになってきたが、「すべてがいいように進んできたわけではない」と青山氏は言う。というのも同社ではオンプレ上にKubernetesを展開しただけでは、type LoadBalancerが使えなかったり、Ingressがサポートされていなかったりするなど、「GKEを使っている人から見ると、パフォーマンスが出ないなど非常に面倒くさい状況だった」と当時を振り返った。

 2017年9月よりtype LoadBalancerとGKEライクなIngressを活用できるようにしていった。これらの機能を達成したことで、プロダクションとしてリリース。現在は15クラスタ程度で使われていると青山氏は言う。

 AKEに限らず、GKEを使うと、「最初はつらく使うのをやめたいと思った」と振り返る。しかし作り終わった今では、開発力も上がり非常に満足しているという。

 AKEの仕組みは次の通りだ。まずはパッチを当てたKubernetesのバイナリをビルドする。次にKubernetesやDocker、etcdなど必要なコンポーネントを組み込んだOSイメージを用意する。そしてOpenStack Heatを用いて自動構築すると、Kubernetesが立ち上がるといったフローとなっている。スケーリングなどにもHeatの機能を使っているという。

 これで「Kubernetesクラスタの完成」というわけではない。KubernetesやDockerのバージョンや、組み合わせによっては、うまく動かないこともある。そこでCNCFが公式にサポートしているSonobuoyやboshを使ってE2Eテストを実施しているという。

あああ
AKEの構築・リリースの流れ

AKEの6つの特徴(1)

 続いて青山氏はAKEのカギを握る6つの特徴について紹介した。

 第1の特徴はKubernetes&Swarm。「マルチCOE(Container Orchestration Engine)対応である」と青山氏。Docker SwarmはシンプルなCOEなので、なじみやすいが、足りない部分もあるという。一方、Kubernetesはデファクトスタンダードな高機能COEだが、学習コストが高い。同社ではどちらも採用。Docker Swarmはカーネルのリビルドをしてチューニングするなど、そこそこ手をかけているという。

 第2の特徴はOpenStack Integration。OpenStack Keystone(認証を行うコンポーネント)やOpenStack Cinder(アプライアンスストレージと連携して、Dynamic ProvisioningでPersistent Volumeを提供)、OpenStack Designate(CLIなどからの接続時は、クラスタ名を基にした名前を解決)、OpenStack Heat(自動構築ツール)などを活用して構築している。「Heatは扱うには難しく、癖がある。できるだけ使いやすくしている。常時触りたくない」と苦笑いを浮かべた。それなのになぜ、Heatを使ったのか。

 確かにOpenStack MagnumやRancher 2.0、Tectonicなどの選択肢がある。だが、いばらの道を選んだのには理由があるという。というのも、先に挙げた3つのツールにはそれぞれ欠点があるからだ。例えばMagnumにはL3 Networkが必要、開発スピードが遅い、細かな設定が困難といった欠点がある。Rancherはクラウドやオンプレ上に構築できるが、2年前は提供されていなかった。Tectonicは検証時点での知名度が低く、細かい設定が困難だった。つまり「私たちはHeatを選ばざるを得なかったということ。ただ、カスタマイズもできるので、選択して間違ってはいなかったと今でも自信を持って答えられる」と青山氏。

 またベアメタルではなくVMでクラスタを構成している理由についても明かした。「ベアメタルはコンテナを詰めすぎると影響範囲が大きいこと。また物理サーバのコア数に依存したクラスタサイズになること。マルチテナントではネットワークの分離が面倒なこと」という3点を挙げた。一方、VMもオーバーヘッドが大きいなどの欠点はあるが、自由な粒度でNodeを切り出せる点が評価された。


  • LINEで送る
  • このエントリーをはてなブックマークに追加

バックナンバー

連載:イベントレポート

もっと読む

著者プロフィール

  • 中村 仁美(ナカムラ ヒトミ)

     大阪府出身。教育大学卒。大学時代は臨床心理学を専攻。大手化学メーカー、日経BP社、ITに特化したコンテンツサービス&プロモーション会社を経て、2002年、フリーランス編集&ライターとして独立。現在はIT、キャリアというテーマを中心に活動中。IT記者会所属。趣味は読書、ドライブ、城探訪(日本の城)。...

あなたにオススメ

All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5