エンジニアHubPowered by エン転職

若手Webエンジニアのための情報メディア

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

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

OGP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

関連記事

取材・執筆:五味明子