NEWS ZERO砲、炸裂！そのとき人気Webサービスの裏側で何が起こったか？[PR]

　Webサービスで一旗あげようとしているスタートアップにとっては、自社の商品が首尾よく当たって、利用者が殺到することによるアクセス過多をどうさばくかは、技術力を試される最初の試練だ。

　大手メディアや人気テレビ番組で紹介されて多大なアクセスが一瞬のうちに来る「○○砲」が直撃したときに起こる事象は、実際にそのアクセスを受けた企業にしかわからないデータ。
　実際、「テレビ放送の直撃にどう耐えるか」といったノウハウは、スタートアップ企業のCTOの間でもあまり共有されていなかったりする。

　そこで今回、女性向けの人気ファッションレンタルサービスを手掛け、テレビやメディアでの紹介経験も多い『airCloset』の天沼代表、辻CTOにお声掛けして、根掘り葉掘り聞いてみることにした。対策の指南役には、ITインフラのプロとしてさくらインターネット研究所の鷲北賢所長にご出演願った。

　人気サービスにアクセスが殺到！という傍目にはうれしい悲鳴の裏側で、インフラで何が起こっているのか、その生の声を訊いてみよう。

 

「事前登録2万5000人の『airCloset』サービスイン、直後にサーバーがパンクした」

　ファッションレンタル『airCloset』の天沼聰代表は、待望のサービス開始当日の出来事をこう振り返る。
　スタイリストのコーディネート付きで、好きな洋服が毎月届く。しかも1ヶ月に何回でもレンタルできるという月額制の新業態で、集めた事前登録は2万5000人。サービスインの2015年2月3日に備え、システムには万全の備えをし、いざオープン。
　しかし結果として、ユーザー登録時のトランザクションが想定を上回った負荷となり、システムが耐えられず数時間でサーバーがパンクしてしまった。

　対策のために採った苦渋の選択は、サービス開始を10日間延期すること。問題解決がうまくいき2015年2月14日、無事サービスインまでこぎつけ、現在に至る。
　……と、ここまではサービスイン時にしばしば耳にする普通の苦労劇。

　さて、辻亮佑CTOが延期の裏側で取り組んだのは、10日間の限られた時間で"アプリケーションのプログラムを作り直す"という大掛かりなものだった。再開時のサインアップに耐えられる体制まで持っていって、無事サービスをスタートさせる必要があった。

　結果的には良い状態に改善できたものの、「パンクした」のは具体的に何が引き金だったのだろう。

左から、airClosetの天沼聰代表、辻亮佑CTO、さくらインターネット研究所 鷲北賢所長。

──まず、サービスイン当初、サーバーはどんな構成だったんでしょう。そしてプログラムを作り変える大工事になってしまった根本的な原因は。

辻　まず、当初はフロントのアプリケーションサーバーを複数台立てられる設計じゃなかったというのが大きかったです。サーバーは大手のクラウドサービスを使ってたんですが、ロードバランサーを使っても複数台構成に対応してなかったのでキツかった。最初はアプリに1台、データベースに1台という状態で、スケール（分散）できる状態になっていなかったんです。

──そのためにサービスを10日間で分散型につくりかえたわけですか？それは大作業だ……さくらインターネットの鷲北さん、スタートアップ企業のこういう事例ってよくあるのでしょうか。

鷲北　大前提として、想定を超えてもなお大きくできるようにするには、当初から分散に対応するプログラムでないといけないですよね。最近、スタートアップのサービスでも「当たるかどうかわからないが、当たってしまうと一気に限界突破してしまう」というケースが増えていると感じます。とはいえ、初期のトラブル対応として素晴らしいと思います。

──一気に限界突破してしまう、というのはゲームなどですか？

鷲北　むしろゲームはノウハウがたまっているのである程度は考えて作られているケースが多いんです。これまでになかったような新しいサービスは、システム構築の経験があるなしで対応が変わってきますよね。

──2月14日にソフトウェアをリニューアルされてサービスインして以降、次の大きな山が来たのは？

辻　『めざましテレビ』（2015年2月27日）と『ニュースZERO』（同3月3日）に取り上げられたときですね。このときもドッとアクセスが来ました。いちばん波が大きかったのはニュースZEROです。リリース前に『トレンドランキング』や『サンデージャポン』に取り上げられたこともありました。でも、そのときはただのティザーサイトだったので、耐えられていたんです。

──ちなみにニュースZEROで紹介されたときのアクセスってどうなるんですか？
 

天沼　ぶっちゃけますと、瞬間最大風速で、通常の100倍のアクティブユーザー数でした。

──うわ、そんなに桁が違うんですか。

NEWS ZERO放映時の実際のアクセス解析を元にしたグラフ。放映開始の23時過ぎから急激に立ち上がっているのがわかる。実際には、この通常時100倍のアクセスになるまで1分ほどしかかからなかった。

鷲北　そのアクティブユーザー数は、限界がきてその数になったのか、単純に最大値までさばけたのかどちらでしょう？
 
天沼　サーバー自体の処理速度は遅くなりましたけど、なんとかさばけました。ですので、単純にこの数のお客様がいらっしゃったということだと思います。
結果として、現在に至るまでこれ以外でアクセス増による過負荷になったことはほぼありません。実は別の理由でアプリケーションサーバーは大丈夫でも、裏側のデータベースが耐え切れなかったのが1回ありましたけど、ニュースZEROのときは大丈夫でした。

教訓：「テレビ放映によるアクセス増は1分でMAXに。オートスケールでは対応できない」

──フロントはなんとか耐えたけどDBがダメだった、という例、もうちょっと突っ込んで聞いていいですか。

辻　順番としては、まずairClosetのサイトの入り口でアプリサーバーにCPU負荷がかかり、お客様が登録完了すると今度はDB負荷が上がってきます。表側が落ち着いてくると、今度は裏側（DB）に……という感じで負荷が移動していくイメージです。

鷲北　コンバージョン（ユーザーが登録完了）してるということですよね。サービスにとっては良いことなんですけど、見てるとハラハラしますよね。

天沼　正直、アナリティクスのアクティブユーザー数の増える様子を見ながらヒヤヒヤしていました……。

辻　テレビ放映の経験で気づかされたのは、クラウドサービスの”オートスケール”※は、テレビ放映対策にはまったく使えないってことですね。
　オートスケールは数分間でCPU負荷が上がるのがトリガーになっていて、5分くらいリードタイムがあります。
テレビで放映された場合、最大負荷に達するまで、現実には1分もないんです。ですから、まったく間に合わないんですよ。
※負荷に応じて自動的に仮想サーバーの数を増減して処理能力を高める機能

──1分以内に番組を見たお客さんが押し寄せてくる、と。テレビ独特の動きですね。それでは、テレビ放映があるときは結局どう対応しているんですか。

辻　あらかじめ放映時間を聞いて、事前に仮想サーバーの台数を増やしておくしかないですね。

天沼　事前準備が大事なので、社内コミュニケーションツールで「いつ放映があるのでおよそどれくらいのスケールをするか」をコミュニケーションして用意するようにしてます。

鷲北　テレビ放映って時間は予定どおりに行きます？

辻　キャンセルはありますが時間の変更は基本ありません。だから、あらかじめ時間はわかるんですよ。

天沼　素人質問なんですが、なんとかオートスケールでうまく避けることってできないものなんでしょうか？

鷲北　うーん、仕組み上難しいですよね。オートスケールって、具体的にはアクセス数の監視システムと、サーバーを増やす仕組みのことです。監視は5分単位、1分単位でチェックして、動向を見て判断してます。そこからサーバーを作るとなると、やっぱり短くても3分、通常なら5分ほどかかってしまいますから。

辻　GoogleはGCP（Google Cloud Platform）で高速オートスケールを売りにしてるじゃないですか。あれはどういう仕組みなんですか？

鷲北　何かしらの方法で「跳ねそうだ」という状況を予測し、事前にリソースを追加してしまっているんじゃないかと思います。
で、予測が外れたらそのままにする。ただし、サービスと違ってインフラは用意するのに時間がかかります。サービスの場合不要になったら消せばいいというのはそのとおりなんですが、インフラはちがう。GCPのような柔軟性をインフラで実現するのは難しいところです。

──盛り上がってきましたね（笑）。さくらインターネットさんで「サバ落ち回避策」を相談された場合はどうアドバイスされてます？ 

鷲北　それが、だいたい問題が起きてからご相談が来るケースが多いんですよ。状況としては、大きな波が来たあとに、「いかに防波堤をつくるか」という相談をしている状態です。その時、お客さまに必ず聞いているのは「スケールアウトするようにアプリをつくっていますか？」ということです。

──分散処理でさばけるように設計しておいてくださいよ、と？ 

鷲北　はい。まず複数台のサーバーで対応できるようにしてくださいというのが最初のアドバイスです。クラウドならサーバーのCPUやメモリーを変えるのは簡単です。ただし、アクセスをさばくときは、CPUがいくら強化されても処理できるセッション数に上限があります。セッション数の上限は複数台のサーバーを並べて対処しないと増やせません。

──まさに辻さんがやったことですよね。

鷲北　airClosetさんの例で素晴らしいのは、プログラムのブラッシュアップをわずか10日間で完了できたということです。多くのお客様は、サービスやビジネス開発に注力している場合が多く、インフラは大きくなってから考えようというところも少なくありません。 だから実際に大きな波が来てしまってから「どうしよう？」と考える。
プログラムにしても専任がおらず、場合によっては1ヵ月ほども対処に時間がかかったり、そもそも対応できないというところも多いです。

──後手後手にまわると恐ろしいですね。

鷲北　対処に苦慮して、分散に対応していないプログラムを複数並べて、なんとかアクセスだけは受けようとした例もありました。ただし、それだとDBのアップデートはできないので、ユーザー登録を制限してしまいます。
　機会損失はあるけれど、表向きは落ちてるように見せられない、というわけです。
　スケールする方法を考えていないうちにドカンと当たってしまうとあとあと大変になるという例ですね。

DBサーバー 賢い運用術

──再びサーバーと運営の話に戻ります。airClosetさんは、いざ本格運用を始めたあと、サーバー構成はどうしました？

辻　最初は5台から始めましたが、現在は仮想サーバー1台でもなんとかなるくらいまでパフォーマンス改善を進めました。もっとも本当に1台だけだと何かあったとき困ってしまうので、2台を並べてます。
　一方で、テレビ放映のときは20台以上並べたりもします。最初はアクセスが読めなかったのでガッと上げて安全性を重視して、徐々に落として最適化を図って、この数に落ち着きました。

鷲北　肝心の1台、1ユニットでどれくらいのトランザクションがさばけるかは、サービスがスタートしてデータをさばいてみないとわからないところがあります。アプリとDBにそれぞれどういう負荷があるかは、サービスによって違いますから。
弊社ができるのは基本的にサーバーを増やすだけなんですが、どう増やしたら効果的かはアドバイスをさせてもらっています。

──具体的にはどういったアドバイスなんでしょう？

鷲北　1つはカタログのように静的なコンテンツにアクセスが集まるケースですが、これは数を並べれば解決できます。airClosetさんなら服の写真がそれにあたります。
キャッシュを使ってアクセスをさばいてしまえばDBには負荷がかかりません。やっぱり厄介なのはアプリとDBです。
　小技は色々あって、たとえばカタログに「残りいくつ」と数字が入ってる場合はDBアクセスが発生しますよね。それを「在庫が潤沢なら緑色の文字、少し減ってきたら黄色、在庫僅少の場合は赤」とざっくりした表現にして、静的なコンテンツに逃がしませんかというご提案をしています。

天沼　あー、なるほど！

鷲北　インフラで対応するとなると、並列化しないといけません。アプリを冗長化・並列化できているか。次にDBも並列化できるか。できるとなったら、あとは数を増やすだけのシンプルな話になります。

──でも、クラウドがスケールに対応できて便利とはいえ、特にスタートアップ企業だと青天井でお金を使うわけにはいかないじゃないですか。

鷲北　そのとおりです。増やし続ける一方ではコストもかかってしまいます。
　クラウドを勧める理由はすぐに増やせるからです。スケールアウトする場合は仮想サーバーを勧めますが、性能が良いのは物理サーバーです。弊社ではクラウドと、専用サーバをL2接続して使うことが可能です。DBに一定以上の性能が必要であれば、DBを専用サーバに移行することをオススメしています。

 

「一定規模以上になったら、物理サーバーの方が安い」

辻　性能のお話は納得なんですが、コストってどの程度違うのでしょう？ 

鷲北　クラウドは基本的に物理サーバー上に仮想でのせているものなので、オーバーヘッド（余分な処理）がかかるんです。ですから、同じ性能であれば物理のほうが長期的には安くなる。半年、1年という長いスパンですけどね。1～2ヵ月のスパンならクラウドのほうが圧倒的に安いですが、物理サーバーに転換したほうが性能は向上できます。
　特にDBはディスクアクセスを考えると大きな差があり、物理のほうが向いています。弊社はデータセンター事業者なので、クラウド仮想サーバーをフロント、物理サーバーをバックエンドに置いていて、比較的簡単に物理移行できるようになっているのが特徴です。

辻　物理サーバーをスケールアップする場合ってどうやるんですか？

鷲北　弊社では、ioMemory（※）を搭載した専用サーバーをラインナップしています。DBではディスクI/0が一番利いてくるんですよ。負荷の高いDBではioMemory搭載モデルをおすすめしていますね。
※Fusion ioMemory、PCIeカードによるフラッシュベースの高速ストレージ

天沼　クラウドは性能をおさえて横に広めますけど、性能を高めて縦に伸ばす方向ですか？

辻　DBは横に広げるのがそもそも難しいというのもありますからね。

鷲北　ほかにも、並べる数に違いが出るんですよ。物理だと2～3台で済むところがクラウドだと10～20台。DBで大きくスケールさせるとバックアップやアップデートの問題があって、技術的な困難がどんどん増えてしまう。構成が複雑になると運用コストも増えてしまいますし、物理サーバーを使うほうがトータルでは圧倒的に安いです。

──辻さんはご自身でDBをセットアップして使っているんですか？

辻　はい。基本は某大手クラウドのRDB（リレーショナルデータベース）を使っています。

──RDBだとスケールアウトは？

辻　レプリカはやってくれますね。

天沼　逆に、それ以外は不足しています。

辻　レプリカだとアプリをつくりなおさなきゃいけないんですよ。スケールアップしようとするとどうしてもダウンタイムが出ちゃって。

──今後のサービス成長に対応するための対策は打たれてますか？

辻　システムは今のところ問題ないんですが、今後お客さんが増えたときに備えて、早いうちにつぶしておきたいというのはあります。いまやってる対策としては、キャッシュを入れてDBアクセスを減らすこと。
　DBでもデータによって、RDBではなくNoSQLで出来るものは移行している……という感じです。

airClosetの天沼聰代表。

さくらインターネットがこだわる「物理サーバーの手触り」って？

──ちょっと意地悪な質問ですが（笑）、既に他社サービスを使っているお客さんに対しては、さくらさんはどういう提案をするんでしょう？ 

鷲北　わたしどもがお客さんにうかがうのは「コスト面で困っていることはないですか？」です。特に他者のクラウドサービスをお使いのお客さまは、人気が出るほどサーバーが増えるケースがあるので、トラフィック課金が重い課題になることが多いですよね。

　例えばDBはディスクI/O単位、フロントもネットワーク単位で課金されるため、アクセスが増えるほど高コストになりがちです。弊社の場合、データセンター内のトラフィックは無償です。アウトバウンドも料金に含めているところが多いため、他社に比べると低価格なんですよ。トラフィックは従量課金がなく、サーバー代金だけで使えるんです。
　台数を数えてもらえば事前に見積もってもらえるはずです。他社のクラウドでは刻一刻と変わっているので月末に締めてみないとわからない、というところもあるのですが。

──トラフィックが予測できないと今月いくらかかるかわからない、という話はよく聞きます。

鷲北　そこでお困りの方にはご提案できるんじゃないかと思います。

辻　いまうちの運用の課題はロードバランサーなんです。うちの使っているクラウドだとロードバランサーもスケールしておく必要があるんですけど、事前に申請をしないといけなくて。さくらさんのロードバランサーってどんな感じですか？

鷲北　ロードバランサーをどう実装するかに選択肢があります。たとえば、弊社が提供するコンパネで操作できる機能で充分であれば、そのまま使っていただけます。
　一方、仮想サーバーに自分でロードバランサーのソフトを入れて運用している方もいらっしゃいます。自分で調整できる方が良い、コア数もメモリーもたくさんあるほうが良いとか。ソフトの方も増えていますから、そういうものを導入して運用していらっしゃるパターンですね。

辻　さくらさんが力を入れているというか、こういう売りにしていきたいという方向性はどこなんでしょう。サーバーのフレームワークが売りですか？

鷲北　弊社が重視しているのは「物理サーバーの手触り」ですね。仮想サービス、クラウドの場合、サーバーを『インスタンス』と呼びますが、弊社はインスタンスとは呼びません。
　仮想サーバーは結局のところCPUやメモリー、OSも物理サーバーとなんら違いがありません。インスタンスというと仮想化されて良いこともありますが、モヤモヤっとした感じになります。インフラやネットワーク構成を作るとき、ポリシー（ベース）ルーティングで構成するとき、以前とはちがうノウハウになってしまう。

──物理限界をもとにするわけではなく、ネットワーク管理者定義のポリシーに基づいてルーティングしていると。そうなると、アプリやサービスの設計に差が出そうですね。

鷲北　最近のエンジニアはクラウド世代なので、ポリシールーティングしかわからないというエンジニアもいます。しかしわれわれは、物理の味をそのまま生かしていきたい。サーバーをつないでネットワークをつくるときも、あえてスイッチをつくってもらって、NICとスイッチングポートを繋ぐ。そういう操作感をコントロールパネルから提供させてもらっているんですね。
　結果、ネットワークには2～3レイヤーにフロントエンドがあって……という昔ながらのインフラ設計をクラウドで再現できる。物理サーバーとのネットワークがある、物理サーバーのネットワークとクラウド上のネットワークを容易につなげられる。それを重視したサービスづくりをしているんです。

──物理サーバー風に設計するから、クラウドとのハイブリッド運用もしやすいと？ 

鷲北　たとえばソフトのアプライアンスが増えているという話がありますよね。ロードバランサーやセキュリティー製品が増え、ソフトウェアだけリリースされている。クラウドサーバーにソフトをインストールしてくれれば、仮想サーバーをファイアウォールにする、ということもできます。
　サーバーとして動作することを重視しているので、アプライアンスもちゃんと動くんですよ。仮想サーバーにどんどんアプライアンスも対応しているので、従来のようなインフラを仮想サーバーでちゃんと動かせるようになるというわけです。

さくらインターネット公式サイトのハブリッド接続解説ページ。こういった運用が簡単にできるのはデータセンター事業者ならでは。

──他社では運用費に使えるクーポンを配ったり、スタートアップの優遇策を出していますが、さくらインターネットも何かそうしたキャンペーンはやってらっしゃるんでしょうか？

鷲北　クラウドサービスによっては、VC経由だと50万円ぶんの利用料などの料金でやっていますが、うちは「期間」にしています。3ヵ月とか1年とか。そこが違いですね。ガッツリ使えば相当お得なはずですよ。

＊

　人気サービスにアクセスが殺到したとき、その舞台裏で何が起こるのか？
　いかがだったでしょうか。「自分たちはこんな体験をした」「こうやってスタート時の障害を乗り越えた」といった事例をお持ちのスタートアップ企業の皆さん、出演希望の場合はぜひ編集部までご一報ください。

　それでは最後に、対談の要点をまとめておきましょう。

■対談の要点まとめ
・サービスのシステムは最初から分散処理できるように作っておくべし
・テレビ放映からのアクセスは通常の増加曲線とはまったく違う。放映1分で最大値まで達する
・立ち上げ直後のサービスの場合、アクセス数は一瞬で通常時の100倍に達することもある
・クラウドサービスの"オートスケール"はテレビ放映の負荷対策には無力
・サービスが一定規模に達したら、物理サーバーの方が安価に運用できる。ハイブリッド運用という選択肢もある

取材協力：さくらインターネット

●関連リンク
さくらインターネット公式サイト
airCloset公式サイト