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

Kubernetesの設計思想に共感して、1,000台規模のインフラ刷新プロジェクトに採用したサイボウズが、独自のインフラ、自社開発のOSSツールで挑戦するNoOpsな未来について聞きました。

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

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

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

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

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

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

2

池添 明宏(いけぞえ・あきひろ)3zoetrope
サイボウズ株式会社 運用本部 サービス運用部(写真中央)。2016年に中途入社し、アプリケーション開発者の立場からインフラの構築に関わる。現在はNecoプロジェクトの中心メンバーとして、サーバーのプロビジョニングやKubernetesクラスタ運用を自動化する仕組みの開発を行っている。
天野 光隆(あまの・みつたか)4mitsutaka
サイボウズ株式会社 運用本部 サービス運用部(写真左)。2017年に中途入社し、現cybozu.comのインフラ担当を経て、翌年Necoプロジェクトに参加。2018年は全てのKubeCon + CloudNativeConに参加し、Kubernetesの最新動向を社内に共有した。
鶴田 貴大(つるだ・たかひろ)5dulltz
サイボウズ株式会社 運用本部 サービス運用部(写真右)。2017年、新卒入社。ログ基盤を刷新するプロジェクトに参加したのち、インフラ刷新プロジェクトNecoに携わる。

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

7

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

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

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

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

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

参考 パブリッククラウドにおけるストレージのコストについては、DropboxがAWSから独自インフラに移行したケースがある。
8DropboxがAWSを捨てて独自のインフラとネットワークを構築した理由

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

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

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

9

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

エンジニアHubに会員登録すると
続きをお読みいただけます(無料)。
登録のメリット
  • すべての過去記事を読める
  • 過去のウェビナー動画を
    視聴できる
  • 企業やエージェントから
    スカウトが届く