このページの本文へ

前へ 1 2 次へ

インストールの自動化や新規申し込み、バックアップ時間の短縮など

成長痛解消に内製が効く?サイボウズがお手製カイゼンを披露

2015年06月17日 17時30分更新

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

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

6月17日、サイボウズは3回目となる技術説明会を開催し、cybozu.comを支えるインフラについて説明した。「大規模化にともなう痛み」をテーマにしたセッションでは、インストールの自動化、新規申し込みやバックアップ/レプリケーションなどの高速化などの取り組みを披露した。

アクセス増・データ量拡大にともなう成長の痛み

 冒頭登壇したのはサイボウズ 運用本部 サービス運用部 副部長の萩原利士成氏。萩原氏は、クラウドインフラに特化した開発部隊である「Hazamaチーム」は所属。アプリケーションと物理インフラのまさに狭間で、自動デプロイやリハーサル、モニタリング、ミドルウェア開発などを手がけているという。萩原氏は自前のクラウドインフラで提供されているcybozu.comのアーキテクチャと現状に関する説明からスタートする。

サイボウズ 運用本部 サービス運用部 副部長 萩原 利士成氏

 cybozu.comは、アプリケーション、DB、ストレージで構成された「サービスセット」を組み合わせたアーキテクチャとなっている。サービスセットはDoSなどに耐性がある独立した単位で構成され、リクエストはロードバランサーで各サービスセットに振り分けられる。サービスセットには、複数の顧客をホストすることもあるので、アーキテクチャレベルでデータを分離し、サービスセット内に同居できるようになっている。

複数のサービスセットで構成されるcybozu.comのアーキテクチャ

 さて、2011年11月に稼働を開始し、6月で3年7ヶ月を経たcybozu.comは、現在18億/月のアクセス数に膨れあがり、98TiBのデータ量を抱えるに至っている。2箇所のデータセンターで運用されている本番サーバーはVM・実機あわせて1000台、開発系も100台単位になっている。2年間でサービス規模が2倍以上に拡大したことで、まさに成長痛を抱えている状態だ。「システムの規模が増えながら、システムの高度化が遅れている現状がある。このギャップを成長の痛みと呼んでいる」と萩原氏は吐露。ドメインやデータが増えると読み込みに時間がかかり、サーバー台数が増えるとOSのインストールの時間もかかるという課題が顕著に出てきているという。

cybozu.comの成長痛によるさまざまな課題

 こうした痛んだ部分・痛みそうな部分をいかに発見し、既存技術の改良やときにコストをかけて解決していくかが今回の大きなテーマ。具体的な例として萩原氏が説明したのが、OS自動インストールだ。

 現在、cybozu.comは3世代8種類のサーバーが存在しており、世代にRAIDの設定が異なる。さらに12のロールがあり、運用チームの時間を知らぬうちに大量に消費していたという。サーバーの種類や納品時の設定が異なり、大きな待ち時間が発生。「数百台もの再インストール作業。ときには心が折れる作業だった」という。

 これに対しては、自動セットアップツールを導入した。PXEサーバーとマネジメントサーバーを組み合わせることで、BIOSやRAIDの設定変更、OSのインストール、ロールごとのセットアップを自動実行させることに成功した。

nginx+Luaスクリプトで申し込み時間を10分を10秒に

 続いてHazamaチームでインフラ開発をしている野島裕輔氏が紹介したのが、nginxを改造し、10分かかっていた新規申し込み時間を10秒にまで短縮した話だ。

サイボウズ 野島裕輔氏

 現在、cybozu.comは新規の申し込みを行なうと、自動的に環境を構築してくれる。このフローにはデータベースの初期化とロードバランサーに振り分け先を登録する作業が必要になるが、総ドメインが増えてきたことで必要な時間が増加。「昨年は3分が5分にまで延び、申し込みが現実的な時間で終わらなくなる危険性があった」(野島氏)という。

 これに対して、まず行なったのがデータベースの初期化とロードバランサーの登録を高速化だ。前者に関しては、申込時に作成していたデータベースの作成と初期化を申し込み前に行なう「在庫方式」を採用。後者のロードバランサーに関しては、振り分け先追加のたびに再起動を要するApacheの仕様に起因しているため、大量のVirutalHostの設定ファイルや証明書の読み込みの無駄を排除し、起動の高速化を試みた。設定ファイル読み込みの内部ループの最適化、OpenSSL内部の重複チェックのハッシュ化、証明書ロード回数の削減などを実施した結果、10分かかっていた申し込みが2分まで短縮できたという。

データベースの初期化を申し込み前に行なう「在庫方式」

 しかし、「減りはしたけど、2分でも遅い。しかもドメイン数が増えると遅くなるのは変わっていない」(野島氏)のも事実。そこで、抜本的にアーキテクチャを見直し、新しいロードバランサーを設計することになった。

 Apache時代はドメインごとにVirtualHostを用意し、起動時にこれら数万の設定ファイルをすべて読み込んでいた。これをリクエスト駆動型に変え、リクエストが来るたびに必要な設定のみ読み込むようにする。また、新規の申し込みが来た場合は、プロビジョニングサーバーに申し込み情報を登録しておくと、ロードバランサーが設定ファイルを取得し、再起動なしで振り分けまで行なえる。こうした設計を実現すべく、いろいろな案の中から、導入決定されたのがイベント駆動型の高性能HTTPサーバーである「nginx」とリクエスト処理をカスタマイズできる「Luaモジュール」だ。

新ロードバランサーでは再起動も不要になる

 まずnginxはApacheやIISに代わるWebサーバーとしてグローバルで高い実績を持つため問題ない。ある調査だと、アクセス数上位1000サイトのうち、4割をnginxを採用しているという。nginx+LuaではApacheのVirutalHostに相当するモノを1つだけ用意し、Luaスクリプトの中でドメイン固有の設定をロード。ロードされた設定に従ってリクエストに認証し、サービスセットに割り振っている。この結果、4分以上かかっていたドメイン登録が1~2秒で完了するようになった。その他、証明書の動的ロードをできるように、TLSのハンドシェイク部分にパッチを当てたり、DoS対策用の独自モジュールを開発し、機能面も拡充。申し込みが来てから、新しい環境を10秒以内に構築できるようになったという。

(次ページ、1日1回だったバックアップを高速化するWaLB)


 

前へ 1 2 次へ

カテゴリートップへ

  • 角川アスキー総合研究所
  • アスキーカード