クラウドアプリケーションもシンプルが鉄則
ここからジャクソン氏は、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
