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

• 1,000台規模のインフラをKubernetesで刷新する
• なぜパブリッククラウドではなく独自インフラなのか
• インフラ自体を継続的デリバリするためツールをOSSで
• Kubernetesの設計思想にインスパイアされたNeco
• ビジネスとして大切にしている部分は細部まで自分たちで

主力製品の「サイボウズ Office」「Garoon」「kintone」などを、2011年からクラウドサービス cybozu.com として提供してきたサイボウズ。これらのサービスのために同社が自前で構築したインフラ基盤は、国内のデータセンターで運用されています。

クラウドビジネスが成長するに従って、当然ながらインフラにもスケールが要求されるようになります。オンプレミスでモノリシックなアーキテクチャでは、そのニーズに応えることが徐々に難しくなってきました。また、1,000台近いサーバをほぼ手動で管理するコストも大きく、運用者の負荷も上がる一方だったといいます。

スケールし、運用の自動化を実現するインフラをゼロベースで作り直し、ビジネスサイドのニーズに迅速に応えたい。こうした理由から、サイボウズではインフラ刷新プロジェクト「Neco」をスタートしました。

Necoはツラくないクラウド基盤を作ってます、という話をしてきました - Cybozu Inside Out

このインタビューでは、現在Necoに専業で関わっている3名のエンジニアに、同プロジェクトで大きく導入するKubernetesについて、そしてその先にある「NoOps」について聞きました。

1,000台規模のインフラをKubernetesで刷新する

── Necoは、cybozu.comのインフラ基盤をゼロベースで刷新するプロジェクトとお聞きしています。プロジェクトの概要をお話しいただけるでしょうか。

池添　Necoは、2018年1月にスタートした3年計画のインフラ刷新プロジェクトです。プロジェクトに関わっているメンバーは9名で、全員、専業です。プロジェクトのゴールとして掲げているのは「スケーラビリティの向上」と「運用コストの大幅な削減」の2つです。

　運用コストの削減に関しては、Kubernetesの導入によるリソース管理と自動化を実施することで、運用管理者の負荷を減らすようにしています。刷新前と同様に、パブリッククラウドなどは利用せずに実機で環境を構築しています。

── cybozu.comのインフラ規模を教えていただけますか。

天野　2018年時点のインフラ規模でいえば、サーバ台数は約1,000台、ホスト数（実機＋VM）は1,500以上になります。扱っているデータ量は約800Tバイト、1日あたりのリクエスト数は2億を超えます。ちなみに契約ユーザ数は100万人以上、契約社数は2万5000社以上です。

── 確かにそれほどの規模のインフラ刷新となると、3年もの時間が必要になるのもうなずけます。現在はスタートして2年目になると思うのですが、それぞれの年におけるゴールなどは決められているのでしょうか。

池添　ざっくりいうと、こんな流れで進めています。

• 2018年: 物理機材の管理の容易化 … 機材管理の容易化、コンテナ基盤の構築
• 2019年: データベースおよび検索エンジン … MySQLおよびElasticsearchクラスタの構築
• 2020年: 分散オブジェクトストレージクラスタ … Cephクラスタの構築

　今年（2019年）はデータベース周りの作業が中心になる予定なんですが、実際にはきっちりと作業を分けているわけではなく、昨年の作業でまだ残っているところを片付けつつ、データベースにも手を付けながら、さらにストレージに関しても少しずつ始めている、という感じで進めています。

鶴田　Necoのユニークな点をもうひとつ挙げておくと、ほとんどのプロジェクトをオープンソース化してGitHubで公開していることがあります。外部に公開することで、コードやドキュメントの品質向上を担保でき、継続的な改善につながるというメリットがありますが、自社の事情を特殊化し過ぎないという点でも効果があると思っています。

GitHub - cybozu-go/neco: Data center construction tools

なぜパブリッククラウドではなく独自インフラなのか

── プロジェクトの詳細を伺う前に、なぜ再び自前で刷新する道を選ばれたのか、その理由をお聞かせいただけますか。インフラの運用管理を楽にすることが大きな狙いなら、パブリッククラウドという選択もあったかと思うのですが。

池添　パブリッククラウドを選ばなかった大きな理由のひとつは、cybozu.comで提供しているアプリケーションサービスのいくつかが、20年以上前のアーキテクチャをベースにしていることにあります。例えば、もともとパッケージ製品として開発していたGaroonなどは、クラウドに向かない仕様になっています。とくにAWSのようなモダンなパブリッククラウドは、アプリケーションの構造的にもかなり難しいと判断しました。

　また、サイボウズのアプリは、クラウドネイティブな最近のアプリと違って急激にアクセスが上下する、いわゆる“スパイク”や“バースト”が起こることがほとんどないんですね。リソースの使われ方がほぼ予測できるので、パブリッククラウドのメリットである“柔軟なリソース追加”といった機能が必要ないということもあります。

　もうひとつはコストの問題です。先ほど、cybozu.com上で扱っているデータ量は約800Tバイトとありましたが、今後はもっと増えていきます。この規模のデータをパブリッククラウドのストレージサービスに預けるとなると、かなりのコストになります。クラウドで一番コストがかかる部分はストレージだと言われていますから。

── つまり、cybozu.com上で展開するアプリケーションのアーキテクチャとユースケースが、パブリッククラウドとマッチしない部分が大きいこと。それに加えてストレージコストも考えると、パブリッククラウドではなく、実機で自前で構築するという選択になったというわけですね。

池添　うーん、単純な「パブリッククラウドか、実機か」という二者択一をしたわけではないですね。Necoプロジェクトを開始したとき、インフラチームには「このままではcybozu.comは破綻してしまう、近い将来にスケールが限界を迎える」という強い危機感がありました。

　だからといって、パブリッククラウドに載せ替えればすべて解決するという問題ではなく、サイボウズ自体がパッケージビジネスからクラウドビジネスにシフトしていくのであれば、そのビジネスを提供する基盤はどうあるべきなのか。それをさまざまな視点から検討した結果、Necoにたどり着いたと思っていただければ。

インフラ自体を継続的デリバリするためツールをOSSで