このページの本文へ

前へ 1 2 次へ

サイボウズのCTOがクラウド基盤の裏側をここまで語った!

cybozu.comの生みの親が自作クラウド派になった理由

2013年09月24日 10時00分更新

文● 大谷イビサ/TECH.ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

サーバー群は「サービスセット」で小分け

 cybozu.comの特徴は、やはりビジネスアプリケーションを安全に使うためのスペックを確実に満たしている点だ。稼働率に関しては、目標の99.9%に対し、全ユーザーの平均で99.99%以上を達成(定期メンテナンスをのぞく)。また、サイボウズ自体がすべてをコントロールできるよう、データセンターは国内に設置しており、大規模ユーザーには専用機材を用意する。データ保護に関しては、ユーザーが個別にリストアすることを前提に設計しており、余裕を持った過去14日分のバックアップを保持。人手を介した有償オプションになるが、「管理者が誤ってユーザーを消してしまうといった場合でも、確実にリストアできる」(山本氏)環境を提供している。堅牢性の高いクラウド環境を実現すべく、cybozu.comにはさまざまな工夫が施されているわけだ。

バックアップはユーザーが個別に行なえるよう設計

 サーバー群は大規模な障害を避けるため、論理的に「サービスセット」として区分けられている。1つのサービスセットは平均6台からのサーバーで構成されており、最大1万ユーザーほど収容できる。あるドメインのサービスは、1つのサービスセットに依存しているため、他のサービスセットで反省する障害に影響されない。

サーバー群は6台程度のサービスセットに小分け

 キャパシティの増強に関しても、「有料のビジネスクラウドなので、既存ドメインのアクセスが急激に増えることはまずない。半年前くらいからテスト運用や交渉があって、契約に至るので、いきなり増設しなければならないという事態には陥らない」(山本氏)とのことで、サービスセット単位で徐々に増やせば問題ないという。なお、ドメインに関しては、任意のJavaScriptの実行を許すサブドメイン方式を採用し、他社のシステムに影響を与えないようになっている。

 一方、クラウドでキモになるストレージは、RAID6を組んだ汎用サーバーを「Square」と呼ばれる自社製システムで管理している。ホストのボリュームはソフトウェアRAIDにより複数のストレージにミラーリングされ、さらにバックアップストレージにスナップショットがとられる。バックアップはフルバックアップをとらず、毎日差分バックアップをとり続けるインクリメンタルフォーエバー方式の「TBS」を採用し、6TiBの差分バックアップが3時間ほどで終了するという。「普段はありあまっているCPUのすべてを使って、非常に遅いけど、圧縮率の高いLZMA圧縮方式でバックアップデータを圧縮。この圧縮データを遠隔のデータセンターに自動転送している」(山本氏)という。

SquareとTBSの概要。DRBDのトラブルを避けた結果、こうした構成になったという

 障害対応に関しては、自動障害回復システムである「月読」を導入している。cybozu.comにおける障害の最大の要因は仮想マシンとなるホストの故障だ。「原因の一番はHDDだが、2番目はマザーボード、3番目はメモリ」(山本氏)。そのため、ホストが障害を起こした場合は、障害を検出し、稼働している仮想マシンを予備のホストに移動させ、仮想マシン上で動作すべきプログラムを起動させるといった手順を踏む必要がある。従来は、これを人手で行なっていたため、30分以上の時間がかかり、稼働率を下げる要因となっていた。この障害復旧をまさに自動で行なうのが、月読になる。

 月読は各ホストのエージェントとして動作しており、プログラムが自律的に監視と情報交換を行なう。他社のクラウド障害を元に、ネットワークの分断や連鎖的なサーバーのダウン、誤検出などにも配慮された優れたシステムだが、「非同期な処理をがんばってPythonでやってしまったので、ソースが複雑で読みにくい。Goで書けば、もっとシンプルで性能もよかったという忸怩たる思いがある」(山本氏)とのことで、公開は予定していないという。

OSSは注意して使う必要がある

 cybozu.comでユニークなのは、自社開発のツールが多いという点だ。これまで紹介してきた構成要素の共通管理システム「Slash」や自動障害復旧システム「月読」、分散ファイルシステムの「yrmcds」、仮想マシンの自動バックアップ機能を持つKVM管理システム「FLVM」、ストレージの総合管理システム「Square」、ボリュームバックアップツール「TBS」などのほか、クラスタ管理やモニタリングツールまで自社開発を行なっており、内製化率はきわめて高いと言える。「構成情報を一元管理するSlashのような仕組みがあるので、さまざまなツールを手軽に、安価に作れる。Chefなどでは構成情報をマッピングする必要があり、かえって現実的ではなかった」(山本氏)。

 OSSに関しては、山本氏曰く「一部実績のあるものだけを使っている」とのこと。サーバーOSとしてパッチ管理の容易なUbuntu 12.04、ハイパーバイザーとしてKVM+QEMU、データ管理にMySQLなどのほか、開発言語、ストレージ周り、モニタリングなどでもいくつかのOSSを活用している。ただし、「採用ポリシーは保守的」(山本氏)で、長年の安定稼働実績がないと使わない。これは過去、実績の少ないOSSをロードバランサーで使用した結果、トラブルが発生した経験からだ。

UbuntuやKVMなど活用しているOSS

 こうしたポリシーで採用したOSSでもそのままでは使わないという。Ubuntuなどに関しても、まずはステージング環境で更新を評価して、問題ないことを確認してから手動で更新するといった“石橋叩く方針”で運用している。安定性で一日の長のあるRed Hatではなく、Ubuntuを採用したのも、最終的にはパッチの更新のしやすさを重視したからだという。

 現在使っているツールの一部も、安定動作に問題があるため、自社開発に切り替えている途中。たとえば、Zabbixはあくまでグラフ化ツールとして使うのみで、重要な監視は自社製のツールで行なっている。レプリケーションに関しても、現在はDRBDを使っているが、将来的にはLinuxカーネルの拡張として開発している「WalB」を用いる予定だ。山本氏はOSSの利用について「一般論として、多くのユーザーが携わるOSSは機能過多で、それにともなって品質が低くなるものもある。そのため注意して使う必要がある。特に運用部分はコストがかかっても、自社で作った方がよいと判断した」と語る。

 最近の山本氏の悩みの種は、インターネット回線が細い中国での利用。現状は物理的な回線強化がないことを見越して、CDNの導入で乗り切っているとのこと。その他、WebSocket対応や脱KVMも大きなテーマとなっており、今回テーマに入らなかったセキュリティの話題も含め、定期的にブログで情報発信しているという。

■関連サイト

前へ 1 2 次へ

カテゴリートップへ