| 川俣晶のWindows Azureレボリューション 第2回 Azureと疎結合分散処理 2011/05/26 |
| 3.11震災の問題 |
2011年3月11日の震災で、筆者の部屋も物が散乱してめちゃくちゃになった。しかし、本当の問題は後から発覚した。本棚の位置がずれたのである。しかし、押しても位置を戻せない。重すぎて動かないのである。仕方がないので、本を全て出して本棚の位置を調整してから本を戻した。本さえ出せば人力で動かせる重さなのである。
その際、本のすき間に紛れていたのだろう、買ったことすら忘れていた興味深い本が出てきた。
『オブジェクト指向 ―解説とWOOC'85からの論文―』（鈴木 則久 編、共立出版、1985年12月1日）
「オブジェクト指向」というタイトルからC++やJavaの本だと思うかもしれないが、そのような話はまったく出てこない。当たり前である。C++は生まれるか生まれないかの時期であり、Javaにいたっては生まれてすらいない。取り上げられるわけがない。当然のことである。いまの基準で過去を語りたがる者はけっこう多いが、もちろんそれは誤りである。当時には当時の基準があったのである。
ちなみに、本書ではガベージ・コレクションも取り上げており、マーク＆スイープ法や遅延ガベージ・コレクション（＝参照カウント方式の効率を高めたもので、寿命の短いセルについてのカウントを省く方式）なども説明している。Javaで使用されたガベージ・コレクションに何ら目新しさを感じられないのも当然だ。それはとっくに既知であったわけだからだ。
話を戻そう。では、当時の基準は何か。
Smalltalk-80言語である。Smalltalk-80を中心に、TAO言語などのほかの技術が取り上げらている。本書は、まずSmalltalk-80入門から始まる構成となっている。
では、Smalltalk-80は今時の「オブジェクト指向」、つまりC++やJavaやC#の知識があれば、あらためて勉強するまでもなく分かってしまうのだろうか。
そうではない。
実は、この入門を読み始めるとすぐに今時の言語にはないキーワードが出てくるのである。それが「メッセージ伝達」である。例えば、「1+2」は「1」というオブジェクトに「2」を足せというメッセージを送ることで実現しているが、そのような思考方法は今時の多くのオブジェクト指向言語には存在しない。
| Windowsの問題 |
このようなメッセージ伝達モデルは、C++以降の効率重視のオブジェクト指向言語ではあまり見られないような気がする。いちいちメッセージを送るという仕掛けを媒介するよりも、単なるマシン語の加算に置き換えた方が速いからである。
しかし、「メッセージ伝達モデルを使用したオブジェクト指向」を実現している例が身近にある。それが旧世代のWindowsのウィンドウである。Windowsのウィンドウは言語ではなく、あくまでAPIレベルで実現されたものだ。利用はオブジェクト指向言語ではないC言語が前提になる。しかし、概念としてのクラスを持ち、システムにクラスを登録できる（RegisterClass API）。登録されたクラスはインスタンス化できる（CreateWindow API）。そして、サブクラス化というテクニックも使用できる。ウィンドウはメッセージを送受信する主体であり、ウィンドウ間で自由にメッセージをやりとりする。例えば、「ボタンを押せ（BM_CLICK）」というメッセージがある。初期のWindowsではボタンも一種のウィンドウであるので、このメッセージを受け取ることができる。すると、ボタンは押されたことになるのである。実際に押されていなくてもリモート操作することができる。ちなみにBM_CLICKの「BM」はボタン（Button）のメッセージ（Message）という意味である。
このような「メッセージを前提とする考え方」はいまでは珍しいかもしれないが、Smalltalk時代には珍しくなかったのである。
| Concurrentの問題 |
メッセージを媒介させるとオーバーヘッドが増えてしまうので、媒介させない方式が主流になった。では、メッセージを媒介させるメリットはないのだろうか。実はある。それは何かというと、処理の並列化が容易なのである。『オブジェクト指向 解説とWOOC'85からの論文』でも、「Concurrent Smalltalk」という、並列処理に対応したSmalltalkについての紹介が掲載されている。要するに、メッセージを媒介させることにより、送り手と受け手が同じプロセス空間にある必要がなくなる。さらに、忙しいときはメッセージを一時的にキューにため込むモデルを持つことができる。これはマルチタスク化したWindowsのウィンドウ・システムとも類似性を持つ。
このキューとメッセージというモデルを使えば、非同期並行処理がかなり書きやすくなる。これは、コア数が増えた今時のPCには価値ある特徴だろう。しかし、それだけではない。1マシン上のコア数の問題ではなく、別個のマシンに処理を分散させることも容易になる。要するにネットワーク経由でキューにアクセスでき、そこからメッセージを取得できれば（パフォーマンスの問題を度外視するなら）、いくら遠隔地にあるマシンとも協同で作業に当たることができる。これが疎結合分散処理の世界である。
| Azureの問題 |
さて。そこまで考えたところで、はたとごく最近、キューを媒介にした疎結合分散処理のコードを書いたことを思い出した。まさに歴史は一回りしたようだ。歴史の皮肉である。
では、それはいったい何か。
ずばり、Azure（Windows Azure Platform）である。
Azureにはロールと呼ばれる処理の主体がある。ロール間は通信を行って一緒に仕事をする。ロール間通信の方法はいろいろあるが、最も手軽かつ柔軟なのはキューを媒介にする方法である。例えば、UIを持つWebロールが、何かのリクエストをバックエンドのWorkerロールに出すとしよう。キューを使うということは、リクエストのメッセージをキューに入れるだけでよい。複数実行されているWorkerロールのうち、最初に手のすいたロールがキューからメッセージを取り出して処理してくれる。その際、どのWorkerロールの手がすいているか、いちいち調べる必要もない。手が空いたロールが勝手にキューからメッセージを拾い上げてくれるわけである。
| 疎結合分散処理の問題 |
つまりこういうことだ。
歴史は一回りした。
古い話と奇妙な類似性を示す新しい技術がここにあり、利用されつつある。
問題は、なぜ古い話と似た世界が戻って来たのか、である。
理由は簡単だ。疎結合分散処理を実現するためには、これまで積み重ねてきた技術体系を一度壊し、原点に戻って再出発する必要があるからだ。C++やJavaやC#という比較的新しい言語の上に構築されたノウハウは無効になったので破棄するしかない、とここではあえていっておこう。
では、なぜ疎結合分散処理を実現する必要があるのだろうか。
話は最初の3.11震災に戻る。
この震災で明らかになったことは、電力が不足すると多くのITサービスが止まるということである。しかし、ネット上の情報サービスは場所に依存しないはずである。そして、電力不足は国内の50Hz地域に限られ、それ以外では特に電力不安は起こっていない。関西の在住者は電力に不安がないので、PCの電源を入れてサービスを利用しようとするかもしれない。しかし、停電する地区に設置されたサーバは停止していてサービスを受けられないかもしない。サービスを利用してもらえる可能性があるのに、利用してもらえない。機会損失である。
遠隔地に存在する複数のマシンが協同で作業に当たる疎結合分散処理であれば、このような問題は起きない。停電地域にあるサーバが止まっても、ほかの地域のサーバが稼働していればサービスは継続できる。処理が重くなる可能性はあるが、処理が止まることはない。
なぜAzureを使うのかといえば、このようなメリットを得るためであろう。たとえ本社や自社のデータセンターの電源が落ちてもサービスは継続できるわけである。
| データセンターの問題 |
そのような観点からいえば、データセンターが1カ所だけしかないサービスは不安がある。どれほどバックアップ回線や自家発電設備があると自慢したところで、大津波でデータセンターごと流されれば意味などない。それよりも、コンテナに機材一式を詰めていくつもの場所にデータセンターを分散しているサービスの方が、サバイバビリティがありそうである。しかし、残念ながら現在、クラウドといっても両者のスタイルが混在しているようで、明快にスパッとは割り切れない。だから、筆者はクラウドの専門家と主張する気はないが、「Azureを積極的に使いたい」と宣言するのである。世界各地にデータセンターが存在することが分かっているので、サバイバビリティが高いからである。
| 失敗の問題 |
しかし、疎結合分散処理のコードを書くことは難しい。処理の結果を保証できないからである。
例えば、あるデータがテーブルに存在するからといって、確実に削除できるとは限らない。存在を確認してから削除するまでの間に、ほかのロールが削除してしまうかもしれないからだ。かといって、排他的にロックするわけにもいかない。ロックした後でロックしたロールがダウンしてしまったら、タイムアウトによりロックが解除されるまで、まだ生きているほかのロールは手を出せなくなってしまう。
つまり、疎結合分散処理では、「あるコードは常に成功する」という前提を置くことができない。「失敗するかもしれない」という前提でコードを書く必要がある。それ故に、Azureのコードも難しい。しかし、それは疎結合分散処理が必然的に抱え込んでいる難しさである。Azure固有の難しさではない。
その難しさを回避する方法はある。SQL Azureを使ってしまうのである。それを使えば、昔ながらのSQLプログラミングで対処できる。しかし、追加コストも掛かるし、スケーラビリティも制約されてしまう。やはり理想を追いかけるなら、ハードルの高さを受け入れてAzure固有のストレージに挑戦すべきである。
| まとめ |
- Azureの本質は疎結合分散処理
- 1台落ちてもサービスは落ちない
- 真のクラウドではデータセンターが広域的に分散
- 操作には常に失敗があり得る
- Azureの難しさの本質は、疎結合分散処理の難しさ
|
||||||||||
提供：日本マイクロソフト株式会社
企画：アイティメディア営業企画／
制作：デジタル・アドバンテージ
掲載内容有効期限：2011年7月15日
|
|
マイクロソフトによるWindows Azure 情報
|
|||||||||||
|
|||||||||||
|
＠IT内のWindows Azure 関連情報
|
|||||||||||
|
|||||||||||
|
外部サイトのWindows Azure 関連情報
|
|||
|
|||
