eBay自社製のコンテナオーケストレーションツール、TessMaster登場!
TessMaster
OpenStack Summit Boston 2017では、全部で300を超えるセッションが開催されたという。その多くはOpenStackのコンポーネントに関する最新情報、導入事例、システムを構築する上での注意点などをまとめたものだが、なかにはOpenStackを使いこなすための全く新しいプロジェクトが紹介される場合もある。そのなかから今回は、eBayが公開したTessMasterというKubernetesを巨大な規模でコントロールするオーケストレーションツールを紹介したい。
このセッションでは、eBayのビジネスを支えるインフラストラクチャーの規模の紹介から始まり、「それをいかにして管理運用するか? という問題に対するeBay自身の解答として作られたのがTessMaster」と語ったのはeBayのUday Ruddarraju氏だ。
セッションは、まずeBayの社内クラウドの規模を概観するところから始まった。
eBayの説明によると、同社内のクラウドはリージョンが異なる複数のデータセンターにまたがって展開されているという。その上で稼働するアプリケーションは約4000。これを多いと思うか少ないと思うかは議論の分かれるところだが、多くはコンテナ化されており、それをマニュアルで管理するのは限界があったという。DockerコンテナそしてKubernetesは、OpenStack上のアプリケーション実行環境として非常に人気のあるソフトウェアだが、eBayの規模、つまりマルチリージョンで10万台を超える仮想マシン上に数え切れないぐらいのコンテナが稼働するものを運用管理するのは、非常に困難な問題であることは理解できる。
実際、すでにOpenStackのプロジェクトとして存在するMagnumでは、eBayの必要な機能は達成できなかったと言う。そのため独自に作った管理用のフレームワークがTessMasterというわけだ。会場からも質問があったのだが、「Hashi CorpのTerraformのように構成管理を自動化するツールがすでにあるのに、なぜゼロから開発したのか?」に関しては「宣言的に環境を定義して『今何がどうなっているのか』(What is really is:WIRI)を認識して『今どうあるべきか』(What it should be:WISB)を閉じた運用ループの中で実行したいからだ」と回答していた。
これは手続き的にインフラストラクチャーを定義するのではなく、本来あるべき姿を定義して管理ツールが自動的にそれに近づくように実行する、という発想のものだ。eBayの呼び方では「Fleet Management(艦隊管理)」となっているが、ここで言うFleetとはコンテナが稼働する際のリソース、コンピュートノード、ネットワーク、ストレージを細かい単位で管理する際の対象をそう呼んでいるというものだ。
そのために様々なツールを検証してみた結果、「自分たちで作るしかない」という結論になり、それがTessMasterという構成管理ツールになったという。TessMasterの特徴は、宣言的であり、APIサーバーが常に環境を監視し、モデルを元に環境がどうなっているのか、新しいアプリケーションのためにどうあるべきか、変更が行われたらそれを元に再度監視を行うという完結したループの中で、複数のデータセンターを運用できる点だろう。スライドの最後にある「ハイブリッドクラウドではさらに問題は難しくなる」という辺りに、様々な試行錯誤を体験した雰囲気が漂っている。
セッションでは、いわゆるセルフヒーリングの機能として、すでに稼働しているKubernetesのプロセスを強制終了させても自動的にあるべき姿に復旧する場面をライブデモで見せて、これぞeBayが必要としている運用の自動化だということを垣間見せた。
これは、eBayほどの巨大なインフラストラクチャーであれば当然必要となる自動化への道筋で、パブリッククラウドベンダー以外にも同じようなニーズを持っている企業があるということを認識すべきだろう。
そして以前の記事にも書いたが、筆者は、巨大なインフラストラクチャーを運用した経験のないITベンダーは、商用の管理運用ツールを提供できなくなっていると考えている。
デブサミで垣間見たGoogleのDevOpsの凄さは人的要素の徹底排除にある
このTessMasterのプロジェクトが成功するかどうかは、もちろんeBay自身のコントリビューションも大事だろうが、同じように巨大な環境を運用管理するユーザーの賛同と協力を得られるかどうかににかかっているように思える。「車輪の再発明は良くない」というのはOpenStack Foundationのマーク・コリアー氏のコメントだが、必要に応じて開発を行い、自社で使いこなしてから外部に協力を求めるためにオープンソースソフトウェアとして公開するという流れは、今後も続くだろう。その際に必要となるのは、開発そのものの力よりも外部へのコミュニケーション能力とコミュニティ作りのノウハウかもしれない。
GitHubに設けられたリポジトリにはまだREADME.mdしかない状態だが、これからの発展を注視したい。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- Elastic、Elasticsearchの新機能、Kubernetesの可視化を発表
- 様々な本番環境を支えるOpenStack
- OpenStack Summit Sydneyに見るOpenStackの今そしてこれから
- Open Infrastructure Summitで紹介されたCERNやAdobeの事例
- KubeCon Europe 2024開催。前日に開催されたAIに特化したミニカンファレンスを紹介
- ApacheCon North America 2017:API互換に関する渋いセッションを聴講
- ONSに参加する意図をOpenStack FoundationのJonathan Bryce氏に訊いてみた
- OpenStack Summit 2018 Vancouver開催 リアルな情報交換の場となったイベント
- Red Hat Summit 2017が開催。OpenShiftをコンテナープラットフォームとして強力にプッシュ
- OpenStackDays Tokyo 2017、コンテナへの応用が目立つOpenStackの現状