1,000台規模のインフラ刷新！ Kubernetesを採用したサイボウズが語る「NoOps」な未来

── Necoはいままでと同様に実機でのインフラ構築とはいえ、既存のモノリシックなインフラとは大きく異なる“スケールと自動化”を前提にしたアーキテクチャで、サービスの実装もかなり大変なのでは……と想像するのですが、実際に着手してみていかがでしょうか。

池添　大変です(笑)。とくに技術的にハードルが高いのが、マイクロサービス化への取り組みですね。先ほども触れたように、サイボウズのアプリはクラウドを前提にしていないものも多いので、コンポーネント化しにくいという難しさがあります。コンポーネント化があまりに難しい場合は、アプリケーション自体の改修を先に進める必要があります。

　現時点では、Kubernetesを導入して、リソース管理とアプリケーションデプロイメントの基盤とするところまではほぼ出来上がっていて、次は技術的なバランスを考慮しながらKubernetes上で動くアプリケーションのマイクロサービス化を進めていく段階に入っています。ただ、その“技術的なバランス”を取るのはなかなか大変です。

── 例えば、どういった点でしょうか。

鶴田　マイクロサービスに関連するオープンソースプロジェクトの動きはすごく速くて、しかも数が多いんです。監視プロジェクトやロードバランサー、ネットワークの経路を判断するサービスメッシュ、それにコンテナを動かすランタイムの数も多い。それらの中から適切なタイミングで適切な技術を評価するのは、エンジニアとしてはかなりハードな作業ですね。いろいろな意味で「長い道のりになりそうだな」と思うこともよくあります。

── いろいろと技術的なハードルがあるようですが、逆に、サイボウズならではのインフラ構築において工夫している点があれば教えてください。

池添　大規模なオンプレミス環境におけるサーバのライフサイクル管理をAPIで実現する「Sabakan」というツールを開発し、オープンソースで提供しています。

GitHub - cybozu-go/sabakan: A versatile network boot server for large data centers

　また、「CKE（Cybozu Container Engine）」というKubernetesクラスタを構築・メンテナンスするツールを開発しました。Sabakanと同様に、CKEもオープンソースとして提供しています。

GitHub - cybozu-go/cke: A kubernetes cluster manager

天野　SabakanとCKEを連携させることで、購入したサーバ機材をデータセンターに設置して電源を投入するだけで、自動的にOSやソフトウェアがセットアップされ、Kubernetesクラスタのノードに追加されます。あるKubernetesノードが壊れた場合は、そのノード上で動作しているアプリケーションを退避させ、ノードをクラスタから切り離すところまで自動化しています。大規模であればあるほど、こうしたツールがもたらす運用の効率化のメリットは大きいですね。

池添　新しいcybozu.comの大きなテーマは「継続的デリバリ」です。それは顧客に対して提供するアプリケーションに限った話ではなく、インフラ自体も継続的にデリバリしていくことが目標です。SabakanやCKEなどの自動化ツールはそのチャレンジをサポートしてくれる存在であり、だからこそオープンソースとして公開してツール自体のアップデートも図っているのです。

── お話を伺っていると、そうした細やかなアップデートが新しいcybozu.comを支えているのだと感じます。ただ、Necoはサイボウズにとっても今までチャレンジしたことがない要素が多いプロジェクトで、想定外のトラブルに遭遇することも少なくないと想像するのですが、そうした場合はどのように対応しているのでしょうか。

池添　それはもう、「“想定外”をたくさん想定する」しかないですね(笑)。確かに思いもよらない事態に遭遇することはありますが、その解決策をひとつひとつ積み重ねていって、我々のインフラのあるべき姿をアップデートしていくしかないんじゃないかと。

鶴田　想定外のことは必ず起こります。だから人的な運用を完全にゼロにすることは難しいかもしれません。それでも「運用の人的オペレーションを最小限に抑え続ける」ことが、Necoの目指すNoOpsだと思っています。

Kubernetesの設計思想にインスパイアされたNeco

── 質問がすこし戻りますが、今回のインフラ刷新でKubernetesを選んだ理由についてお聞かせいただけるでしょうか。Kubernetesがコンテナオーケストレーションのデファクトスタンダードであり、サイボウズのサービスがマイクロサービス化へとシフトしていくことを考えれば、NecoでKubernetesを採用するのは当然のようにも思えますが、もしほかに理由があればぜひお聞かせください。

池添　まず挙げられるのが、KubernetesはGoogleが開発したオーケストレーションツールであり、すでにGoogle内での大規模本番運用の実績があった点が大きいです。Googleが開発し、実際に本番環境で使っているというだけでも大きな信頼に値すると思います。

　もうひとつの理由は、Kubernetesの設計思想に対して非常に共感できる部分が多いことが挙げられます。Kubernetesは「現在の状態と望む状態（あるべき状態）の間にある差分を意識してアップデートを重ねていく」という思想が息づいています。我々もこの思想を、例えば、CKEの開発などにも適用しており、Neco自体もこの考えに大きくインスパイアされています。

── つまり、Kubernetesの設計思想が、Necoのゴールと非常に近しいという感じでしょうか。

池添　そうです。Kubernetesがほかのコンテナオーケストレーションツールと最も大きく違ったのは、すべてのコンポーネントがAPIを中心にしてプラガブルに構成され、いわゆる“手続き型”ではなく“宣言型”のアプローチを取っている点だと思います。ネットワークもストレージもプラグインでつながる、このアプローチが高く評価されたのではないのでしょうか。

　逆に、Dockerなどは一世代前のDevOpsで主流だった“手続き型”の思想を踏襲しているので、コマンドを叩いて、Ansibleのようなツールを起動して……といったオペレーションになりがちなので。

── DevOpsの世界もアップデートされているんですね。

天野　DevOpsは文化ですが、当然ながら文化も変わっていきます。いまの話に出てきたように、従来のDevOpsの考え方にとらわれていると、宣言型のアプローチは理解しにくい部分が多いと思います。そう考えるとKubernetesはうまくDevOpsの文化の変わり目に適応したといえるかもしれません。

鶴田　ただ、エンジニアとしては、Kubernetesの四半期に一度のアップデートにキャッチアップしていくのはかなり大変です。バージョンが上がってすぐはリリースノートに書かれていないところでつまずくこともしょっちゅうで、各コンポーネントのパラメータの値なども試行錯誤しながら変更しています。もっともそれを追っていく能力こそが、現在のインフラエンジニアには強く要求されている部分でもありますが。

── 逆に、Kubernetesには向いていないワークロードもあると思うのですが。

池添　もちろん、Kubernetesで何でも管理できるかというと、決してそういうわけでもなくて、例えば、これからNecoで本格的に着手するデータベースの管理などは、あまり向いているとはいえません。データベースやストレージはこれから作業が本格化する部分ですが、まだ多くの難関が待ち構えていそうです(笑)。

ビジネスとして大切にしている部分は細部まで自分たちで

── Necoはオンプレで構築するという選択をされたわけですが、サイボウズさんとしてパブリッククラウドを使用しないというわけではありませんよね。今回の開発に関してはどのあたりに基準があったのでしょうか。

池添　もちろん、サイボウズでは一部のサービスでパブリッククラウドを利用しています。ではその境目、クラウドを利用するか自前でやるかの境目はどこにあるかというと、「顧客に対して最終的にサイボウズが責任を追わなければならない部分は自前でやる」ということに尽きます。

　ストレージに関しても同じですね。最初にお話ししたようにコストの問題もありますが、顧客のデータのようにサイボウズがビジネスとして大切にしている部分はやはり、インフラがどんなに刷新されても自分たちで守り続けていくと思っています。

{$image_13}

取材・執筆：五味明子