SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

イベントレポート

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


  • X ポスト
  • このエントリーをはてなブックマークに追加

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を切り出せる点が評価された。

次のページ
AKEの6つの特徴(2)

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
イベントレポート連載記事一覧

もっと読む

この記事の著者

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

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

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/10816 2018/05/15 17:59

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング