ビジネスの拡大にフィットするスケーリングを考える
2013年7月、買収によりIBMクラウドに追加されたクラウドコンピューティングサービス「SoftLayer」（ソフトレイヤー）。2014年1月現在、そのIaaSプラットフォームは10万余りのサーバーを擁し、2万2000社以上のユーザー、2000万以上のドメインが使用している。規模が優位性となるクラウド市場にあって、IBMによる買収はSoftLayerにとって事業拡大の大きな機会となるだろう。
ジャクソン氏はSoftLayerについて、他のサービスとは「APIの捉え方とその根幹となる哲学が違う」と言い切る。特徴的なのは、公開しているAPIの範囲が広いことだろう。SoftLayerのモデル（下図）の中央にあるSoftLayer APIでは、ユーザーアプリケーション向けに一般APIを提供する。さらに、SoftLayer自身が使用するAPIまで公開しており、ユーザーのビジネスや統合に利用できるようになっている。
さて、近年のソフトウェアのスケーリングについて、ジャクソン氏は「自分が関わるようになった9年間でも大きく様変わりした」と語る。ビジネスの捉え方、アプリケーションの作られ方、そしてインフラの上でどのようにアプリケーションが活用されるのか、全てが変わってきたというわけだ。その潮流に最も影響を与えたのが「クラウドへの変化」だ。
かつて、システムはトップダウン的なアプローチで作られてきた。つまり、ユーザーからの要件を受け、サーバーやファイアウォールを構築したり、コストに合わせてスケールダウンを行ったりしていた。ジャクソン氏はその様子を「高速道路のレーン」になぞらえて、「必要量の見積もりが重要だが難しい。予測できない出来事が起きれば限界が来てしまう」と評する。
そこで、ジャクソン氏は「カンガルーを考えて」という。「カンガルーはカンガルーでしかないと思いがち。しかし『ティラノサウルスとシカを掛け合わせれば、カンガルーになる』と考えれば、全く新しい見方ができる。そして、今後はそうした見方ができるようになる」（ジャクソン氏）
この発想の転換を、従来のトップダウンアプローチによるシステム構築に適用するとどうなるのか。ジャクソン氏は、決してトップダウンアプローチに問題があるわけではないとした上で、「適材適所での対応が不可欠」と語る。
エンタープライズアプリケーションは条件が明確であり、コスト抑制が課題となる。一方、インターネットスケールアプリケーションはユーザーも使われ方も不確定で"カオス”であり、サーバーの過剰な負荷がむしろ”成功の証”にもなる。スケールアップはパフォーマンスを高め、より多くのユーザーに対応するために行う。
たとえば、メディアミックスブログサービスを提供するtumblrは、ユーザーの自由度が高く、動画などのコンテンツを自由に作成しシェアできる点が魅力のサービスだ。しかし、どのコンテンツの人気が出るのかは予測できない。そこでtumblrでは、コンテンツやブロガーの人気動向に合わせて変化できるよう、プラットフォームを柔軟に設計している。ユーザーに快適なブログサービスを提供できている理由はここにある。
また、ゲーム開発スタジオとして急成長したOMGPOPは、ゲーム「Draw Something」が大ヒットし、2012年にはZyngaに買収された。この急成長を支え、意欲的なユーザーを獲得できたのも、やはり適切なスケールアップが可能だったからと、ジャクソン氏は分析する。
クラウドアプリケーションもシンプルが鉄則
ここからジャクソン氏は、Drupal（PHP言語で記述されたフレームワークの1つ）で自作したコンテンツマネジメントシステム（以下、CMS）を例に説明を進めた。このCMSは、動画ファイルを適した形式に変換して公開するというもので、ジャクソン氏は携帯電話で撮影した会場の動画をその場でアップし公開してみせた。
従来、このようなシステムの構築には、Webサーバーやトランスコーディングサーバーなどのほか、SANのような大型ストレージが必要であった。ただし、これでは構築に大きなコストが掛かってしまう。一方、ジャクソン氏の自作CMSは、アプリケーションなどが入ったバーチャルマシンを中心にサードパーティ製のサービスやプロダクトと連携することで、個人でも開発・公開できている。「インターネットスケールアプリケーションを開発する上で、もっとも重要なことは『全てを自分で作らないこと』」（ジャクソン氏）。セキュリティーや拡張性、信頼性の確保においても、自らのサービスに合致したサービスやプロダクトを選んで連携させればよいのだ。
また、その際のキーワードは「Simplicity（シンプルであること）」であると、ジャクソン氏は強調する。人はどうしても複雑に考えてしまう。しかし、先述の「カンガルー」のように、要素と本質を突き詰めて考えれば、パターンが見えてくる。また、コンポーネントとステップに分け、さらにそれを突きつめて単純化すると本質が見えてくる。
さらに、ジャクソン氏はお気に入りの言葉「システムがシンプルでまったくバグがないとわかるか、あまりに複雑でバグが見えないか」を引き合いに、シンプルさの重要性を強調する。シンプルであればバグも予見できるというわけだ。
また、アプリケーションのキーワードとして、ジャクソン氏は「Stateless（ステートレス）」と「Asynchronous（非同期）」を挙げる。Statelessはクライアントとサーバーとのやり取り（セッション）の状態を維持しないことを指す。Asynchronousは、あるジョブやプロセスを始めるときに、他のジョブやプロセスの完了を待たなくてもよいという状態である。
ジャクソン氏の自作CMSでは、独立した4つのブロックでプロセスが稼働しており、それらは互いに「処理のタイミングをはかる必要」も「同じサーバー上で動かす必要」もない。
処理は、ワーカー（Worker）がメッセージキュー（Message）を受け取り、いずれかのプロセスと作業した後、メッセージキューを削除するという形で進められる。バグやサーバーの問題があれば、メッセージキューはそのまま返す。そして、ワーカーはまた次のメッセージキューを受け取り、プロセスとの作業を開始する。こうした流れのため、あるプロセスで発生した問題が他に及ばず、堅牢性も高い。たとえば、動画ファイルの変換プロセスが途中で止まっても、問題があったところから再度やりなおすことができる。
ここまで説明した後で、ジャクソン氏は自作CMSのデモンストレーションを再開。今度は、いくつかのジョブが待ちになっている状態で画面中のボタンを押すと、新しいワーカーを誕生させるというものである。新しいワーカーはやはりメッセージキューを取り出し、変換が必要なものがあればDrupal Nodeを作ってトランスコードキューに送る。すると1つのジョブが入ったことがわかる。
こうしたアプリケーションの作成において重要なのは、「どこにどのくらいのメッセージキューができているのかを見ておくことだ」とジャクソン氏はいう。そして、停滞しているところがあれば、そこに新しいキューを追加する。そうしておけば、各々のワーカーがプロセスの一部を担い、1箇所に長い時間をかけるのを避けることができる。チェックジョブキューの方は、単にトランスコードのジョブを見て完了を確認し、確認できなければメッセージをキューに戻して1分待って再試行する。
アプリケーションの分解、コンポーネントの収容、そして「カンガルー」的な発想などを踏まえてスケーリングしてみると、デザインにおいての強みが見えてくる。たとえば、ワーカープロセスは、別々でも種類が異なるマシンでも実行できる。アプリケーションの一部がデータベース用とすれば、ハイパーバイザーなしのベアメタル系サーバー、それもシェアされていない環境が適切だ。また、仮想マシンでのWebサーバーはハードディスクにあまり依存しない、というように「適材適所」が肝心というわけだ。
適材適所に配置できれば、ワーカーごとに最適な環境で実行し、さらには分析を行って稼働率や負荷を鑑みて、部分部分をスケーリングすればよい。あらゆる技術に対応し、スケーリングの在り方も選択できる。その際には、メモリーを増やしプロセッサを加える「バーティカル」という方向と、ノードを増やす、ロードバランサーを入れるといった「ホリゾンタル」という方向で考える。
「POD」を組んで柔軟な拡張を実現し、トラブルに備える
さて次の課題は、「どのようにこれらを組み合わせていくか」だ。これまでバラバラなコンポーネントをワーカーに落とし込み、その適材適所も明確化し、スケールの手法も「ホリゾンタル」か「バーティカル」か判断する。
それが完了したら「POD（Portable Organizational Deployment）」を組む。それが1000人に対応するPODなら、ある日2万5000人に達する可能性があれば25のPODが必要と予測できる。そして次のステップが「グローバル展開」だ。日本なら日本のユーザー数分だけというように、地域ごとにPODを用意しておけばよい。
また、こうした流れの中で「ボトルネック」を意識することは重要だが、全て解消する必要はない。ただし、それがどこにあって、ビジネスにどのくらい影響を与えているかは、知っておくべきだという。さらに「どんなシステムなのか」「どのくらい影響があるのか」などと照らしあわせ、どう対応すべきか判断を行う。中にはスケーリングせずともよいものだってあるはずなのだ。
そしてもう1つ、「失敗は起きるのだ」と心がける必要がある。どんなハードも故障や劣化はある。その対応策には、不測の事態には自動的にオフになり、また復旧する「DR（Disaster Recovery）」と、災害時でも繋がり続ける「冗長性」や「高可用性環境の構築」が考えられる。当然ながら、後者の方が高コストとなる。
しかし、そのレベルも、たとえば問題が生じた時にアップロードはできなくなってもサイトはダウンせず、過去のスレッドは読めるという環境も選べるということだ。もちろんフェイルオーバーや冗長性を担保することも悪くはない。しかし、それが本当に必要かどうかを見極める必要がある。
最後に再びジャクソン氏は「システムの本質をあらゆる方面から新しい見方で考えるために、『カンガルー』を思い出してほしい」と語り、「シンプルに、非同期に、そして常にそのジョブに最も適切なツールを使おう。そしてそのシステムの本質をしっかりと理解して、常に失敗に備えてほしい」とセッションをまとめた。
日本アイ・ビー・エム株式会社
〒103-8510 東京都中央区日本橋箱崎町19-21
TEL: 0120-300-426（平日9時30分～17時30分）
URL: http://www.ibm.com/cloud-computing/jp/ja/softlayer.html
