私は、ノルウェーのオスロで開催されたJavaZoneの期間中、John Daviesと会って情報交換しました。私たちの出会いは、Johnがロンドンの銀行産業にいたころの体験について話すことから始まりました。業務アプリケーション開発者に求められているスケーラビリティは、おそらく1秒間に1,000トランザクションというところでしょう。しかし、これらの銀行が直面しているのは10,000トランザクション/秒というものでした。しかも、秒あたりで処理しなければならないトランザクションの数は着々と増加しています。 (銀行の) フロントオフィスの成功は、市場に存在する多くの競合状態に勝ち抜き、銀行がITのリニューアルに莫大な投資を積極的に行うかどうかにかかっていたのです。
こうした投資はしばしば銀行において流行になったとともに、私たちのITインフラストラクチャにおける未来像をうかがわせました。現在、銀行は利益獲得のための戦いを続けながら、グリッドテクノロジーに対する多大な投資を行っています。ここでは、我々が今どこにいてどこに向かおうとしているのかを、John Daviesが簡潔に、間断なく述べています。難しい話は抜きにして、ここではJohn DaviesがJavaグリッドと、なぜわれわれにそれが必要なのかが書かれています!
25MHzのCompaqでCプログラミングをしていたのが、はるか昔に思えます。その当時では、それが一番速いマシンでしたし、数ヵ月後に33MHz バージョンが登場した時は、猛烈な速さだったものです。PDP-11や4MHzの8080、私が最初に使ったZ80に比べても、これより速いものなんて誰が必要とするんでしょう？
当時我々は最先端で、競合に対する数秒のアドバンテージを銀行に与え、かなりの利益を得ていました。これが、株式市場の開始における"ビッグバン"の日々です。ネットワークは、一つのマシンとほかのマシンの間で行った更新の差異が見えるほどに遅くて、何の意味もありませんでした。これがトレーダーの間でネットワークリングマシン間の接続の開始が待ち遠しいという議論になり、我々が以前使用していたRS-232 "ネットワーク"上で進められました。
それからの数年と言うもの、私が従事した最初のシステムと競合する、他のディーリングルームシステムをアップグレードする度に、お金をもらい続けました。速くするたびに、です。(速くすることができたのは) ムーアの法則のおかげばかりではなく、高パフォーマンスなトレーディングシステムを設計するにはどのようにすれば良いか、また何をすべきでないかを学んでもいたのです。C++とObjective Cはどちらも偉大な言語ですが、トレーディングフロアにおいてはC++はObjective Cに勝利を収めました。興味深いことにその理由は、C++はハックすることが可能ですが、Objective Cはあまりにオブジェクト指向過ぎて遅かったからなのです。競争の重圧は大きく、我々はWindows NT4のベータ版を実際のディーリングルームに導入したりもしましたが、そのおかげで90年代後半にWindows NTがリリースされたとき、経歴として非常に役立ちました。
その1年か2年後にJavaがリリースされ、最初はWeb上で絵を動かすことのできる目新しい言語でした。数年後にはJavaが製品で使用されるのを見かけるようになり、その後のJavaに関する話は御承知の通りです。
90年代後半では、(10BaseT上で) 数百ミリ秒以上かかるような処理はほとんど見かけませんでしたし、ほとんどの場所では依然として10BaseTを使用していたにもかかわらず、より速いディーリングルームでは100BaseTか、それより速いものに切り替えていました。競争のプレッシャーは依然として存在し、市場がよりグローバル化するに従ってどんどん強くなっていきました。吸収合併を行った銀行は、システムの進化を後退させるための再投資を行う必要があったため、平均よりも遅いシステムになりました。平均よりも遅いシステムになったため、システムを進化させるために再投資を行う必要がありました。そのサイクルは大体3から7年でした。いくつかの銀行は他よりもリスクを負い、さらにシステムを進化させたため、サイクルはより長くなりました。他の銀行はより保守的で、技術を受け入れる前に、勇敢な他の銀行によってテストされるのを待っていました。この、先駆者と後発者というパターンはJ2EEにおいて非常に顕著でした。"思想的なリーダー"は、90年代の終わりごろからEJBと戯れていました。こうした先駆者のうちの一部はエキスパートになり、 EJBの限界に打ち勝つための新しい道を見つけ始めました。あなたも、Rod JohnsonやCedric Buest、Tyler Jewell、Robin Roosと言った人々の名前はご存じでしょう。こうした人々は、90年代からEJBを扱おうと試み、数年後にはそれを主題にした書籍を執筆しました。この後、SpringやHibernate、JDO、そしてほかの多くの興味深い代替テクノロジーが登場したのです。一方Sunは、彼らのベイビーを何とか生かしておこうと試みており、EJBは未だにサポートされ続けています。
そしてグリッドです。私たちとグリッドはどこにいるのでしょう？アセンブラ、C、C++、Java、J2EE、そして現在グリッドです。先進的な銀行では、彼らのJ2EE資産の多くを捨て、2000年代半ばの早い時期にグリッドに移行しています。現在、銀行の大多数が、何らかの計算やデータをグリッドで走らせています。私は、グリッドが使われているのがごくわずかであることは知っていますが、それ (グリッド) に投資していない銀行を知りません。多くのテクノロジーと同様、グリッドはとても分類の緩やかな技術です。いくつかシステムはそうした緩やかな分類の中に埋没していますが、他のシステムはクラスタリングや分散ESBグループと言った、より良い分類の中に属しているようです。
GridをWikipediaで見て見ると、単純な答えはどこにもありません。その始まりは..."グリッドコンピューティングは、分散コンピューティングにおける用語で、いくつかの意味を持っている" そして、たくさんの意味について記されています。SETI@homeのようなものは技術的にはグリッドですが、私がここで示そうとしているグリッドとは違います。"私の"グリッドは、一つ、もしくは少数のローカルサブネットの中にある、サーバやブレードのネットワークのことです。技術的には、2もしくは3台のマシン (クラスタとして知られています) から数千台までの全てを指します。グリッドを分散コンピューティング、同様に並列コンピューティングだと述べるのは簡単ですが、しかしそこには分散処理のより大きな原理が存在しています。
グリッドの人気が出始めた理由として面白いのが、ムーアの法則に対する横向きの動きだということです。以前は、ムーアの法則のグラフに従ってクロックスピードやバス幅が単純に変化しました。以前は、私たちが書いたforループは、24ヵ月ごとに大体2倍、20年で1000倍の速度で動作するようになることが期待されていました。この数年、この小さなforループの速度は変わっていません。現在、発生する熱が大きな問題となり、クロックスピードはピークに達しています。我々はすでに3-4GHzあたりで壁にぶち当たり、マルチコアへの移行が続けられています。今日では、一つ目のforループを遅くすることなしに、三つか四つのforループを同時に動かすことができると言う違いがあるのです。
マルチコアは代償を伴い、我々は最終的に並行性と向き合う必要がありますが、多くのプログラマーは今までのところ、幸運にも無視することができていました。並列性はJavaプログラムだけの問題ではありません。我々が現在使用しているオフィスアプリケーションのほとんどは、同じマシンにある別のコアを使用するよう、大きく設計を変更する必要があります。あなたのアプリケーションをどのように並列化するかを、オペレーティングシステムが推測してくれるはずだと単純に放っておくことはできません。そして、80年代、90年代、そして2000年代のアプリケーションのうちで、こうした考えを考慮に入れて書かれたものはごく少数です。プログラマの作業は増え、お金も増えれば、我々は全員ハッピーですが。
最近数年にわたって、そして興味深いことに、まさに数週間前アーキテクチャとコードをレビューするよう頼まれました。もっとも最近レビューを行ったものは非常に典型的で、モジュール化された設計を取っており、キューを使用して、良く疎結合になっていました。このケースでは、複数のJVMが一つ、もしくは複数のマシン上で動作し、キューメカニズムを通じて繋がっていると仮定しており、紙の上では悪いアイデアではなかったのですが、実際の動作はまるでバカのようでした。モジュールに対する単一の呼び出し全てがネットワーク上でシリアライズ/デシリアライズされ、多くのケースでローカルホスト (への呼び出し) であるにもかかわらずローカルコールに対する最適化が行われていませんでした。これは初期のEJBプログラマが経験した問題で、同じマシンで動作しているにもかかわらず全ての呼び出しがリモートインターフェースを介して行われました。たとえば、ステートレスセッションビーンからエンティティビーンの呼び出しです。Sunは、ローカルインターフェースを生み出すことで"パッチを当て"ました。リモート呼び出しの問題は解決しましたが、それはプログラマがデプロイメントのトポロジについて指示しなくてはならないということを意味しました。パフォーマンスの観点から見ると効果がありましたが、設計と言う観点から見ると、素晴らしい解決策とは言えませんでした。Springは、ロケーションの抽象化についてもう少しエレガントな解決策を提案しています。クラスローダーを見ただけで、処理がローカルで行われるべきか、それともリモートかを決定することができました。
グリッドが成熟してきたおかげで、こうした初期の問題の多くはすでに整理されています。現在、近代的なグリッドフレームワークはロケーションを抽象化するインターフェースを提供し、プログラマは単一のVMで動くかのような単純なプログラムを行うことができます。Javaの世界では、 GigaSpaces、Tangosol (現在はOracle)、Gemstone、Terracottaなどの、いくつかのキーとなるベンダが目立っており、いくつかの新しいグリッドフレームワークが登場していますが、銀行業界でこれらを見たことはまだありません。誰にも多くのチャンスがありますが、グリッドからお金を得ているように見えるのは、上のリストに挙げた会社だけです。完結に言うと、私はこれらのベンダの得意分野を以下のように位置づけています。GigaSpaceは、マスター/ワーカパターンのベストな実装です。Tangosolは、ベストなデータキャッシングを提供します。Gemstoneは、ネイティブのCで書かれたものでは最も成熟しています。そしてTerracottaは、オープンソースの良い選択肢です。
まあ、この記事が投稿されたらすぐにそれぞれのプレイヤーたちが、全てのプロダクトの中でも自分たちの物がベストであり、他のものは単なる出来そこないだ、とコメントするであろうことは分かっています。それぞれが競合相手に勝る部分での例を見つけ出すことができるでしょうし、他のアーキテクチャの穴をデモすることもできるでしょう。しかし、もしあなたが現在抱えている問題に対して、今適切なツールを選んだとしても、最終的には全ての製品が上手く動いてくれることでしょう。
それぞれに違いがある理由は、内部にアクセスするために彼らが選択したAPIにあります。GigaSpacesはJiniの一部で、J2EEよりも古いものであるJavaSpacesを起源としています。従ってコアのインターフェースはSunのJavaSpaces APIであり、信じられないほど単純です。APIはプログラマに対してread、write、take、そしてnotify (通知を受ける) 事を許しています。これは、データが主要なサービスインターフェースとして設計されている場合は、良く動作します。もし私がサービスとしてJava APIを設計しているなら、(多少の変更は必要ですが) これがそのサービスインターフェースになるでしょう。一つのアプリケーションとほかのアプリケーションが対話するには、オブジェクト (メソッドを持たないインターフェースであるEntryを実装する必要があります) が"Space"に書き込まれます。"Space"はコンテナで、オブジェクトの受取人はオプショナルな通知の後、読み取りや取得を行います。これはポイント間でトランザクショナルに動作することができ、パブリッシュ/サブスクライブアーキテクチャ内で動作します。
TangosolのCoherenceは、最近Oracleに買収されましたが、J2EE初期のキャッシュのニーズに合わせて成長しました。そのAPIは単純なHashmapで、全てのJavaプログラマが知っているAPIです。Coherenceはオブジェクトの保存と検索については素晴らしいものです。マップは二つのアプリケーションが同じマップを共有することによってトランザクショナルな対話を行うことができ、片方がオブジェクトをマップに保存すると、他はそれを取り出します。Publish/subscribeモデルは"最新の値"におけるかなり興味深い機能を持っており、通常のpub/subメッセージングベンダーのものよりはいくらか (機能が) 不足しています。
Gemstoneは、もともとはオブジェクト指向データベースでしたが、前の2つの例と同様一つのアプリケーションが(インメモリの)データベースにオブジェクトを書きこむと、他のアプリケーションがそれを読むことができます。
恐らくあなたは、パターンにお気づきでしょう。オブジェクトはコンテナに書き込まれます。あるものはローカル、あるものはリモートですが、どちらのケースでもコンテナは分散され、そのメカニズムはAPIを通して我々の目からは隠されています。そしてこれこそがJavaグリッド、つまり分散コンテナなのです。
普通だったら、これで終わりです。私としては、(この記事のタイトルである) 質問に答えられたと思います。しかし、グリッドの利用によって現れつつある、いくつかの興味深いトレンドを指摘しておきたいと思います。一つ目は、ディスクよりもメモリを利用することです。昔の平均的なトレーディングでは、より効率良くデータを扱えるはずにもかかわらず、ディスクへの書き込みを必要としました。例えば我々はXMLを使用していません。我々は依然としてディスクの読み取り、書き込み、消去を必要としているからです。アドレス可能なメモリは、プロセッサのアドレス制限に束縛されます。16ビットは64kしかアドレスできません。32ビットだと4Gです。しかし、64ビットは1,800万テラバイトをアドレス可能です。その最たるものはZFSで、Sunの新しいファイルシステムは128ビットを使用しますが、その理由は、あなたが「いつか」必要とする、と言うものです。莫大な量のメモリをアドレス可能になり、分散フレームワークがローカルとリモートのストレージを隠ぺいできるおかげで、現在我々は、数百GBのRAMが利用でき、レプリケートできると期待した設計を、真剣に行うことができます。そして、長期間のデータ保存以外の理由で、我々がディスクに触れる必要がそもそもあるのでしょうか。現在のトレンドは、日常の作業にはメモリを使用し、ディスクはアーカイブを行うための場所とみなすことです。面白いのは、このトレンドは自己永続的であり、このテクノロジーは使用すればするほどより必要性を感じることなどです。
二つ目のトレンドは恐らく、グリッドと言うよりは世界的な動きですが、グリッドと分散メモリの利用が拍車をかけています。これはリレーショナルデータベース中心とは対照的に、メモリ内でのオブジェクトや階層構造の利用が増大しているというものです。その理由は、メモリ内に保存されたデータの依存関係が、ディスク上では損なわれることがあり、数秒もしくは数分、数時間にわたってデータを保存するには、結局のところハッシュマップやJavaSpaceが最も良い方法だということです。データの元の形を保ったまま、普通は保存しておける (恐らくオブジェクトかXML) のに、なぜこれをリレーショナル構造にマップし直さなくてはならないのでしょう。検索クエリについても心配ありません。スレッド数の増加が意味するのは、クエリを分散させることができると言うことです。恐らくGemStoneが最初ですが、私は自分が正しいことを確信しています。結果として、グリッドは複雑なORMレイヤーの必要性を置き換えることで、設計を劇的に単純化します。グリッドは、我々のビジネス上の問題を解決するだけではなく、time-to -marketを短縮し、保守性を向上させます。
賢いベンダは、グリッドの文化に合わせたプログラミングを現在行っています。単純でスレッドセーフ、自身に機能を含み、振舞いが定義されたPOJOを使用しています。私たちはこれらがオブジェクトだということを知っています。我々がCPUサイクルをぎりぎりまで得ようと努力するのと同様に、CPUのダイレクトメモリとほぼ同様の物を作ろうとしています。分散処理は避けられませんが、CPUのメモリキャッシュが動作する方法と同様にネットワーク利用を最小限に最適化し、CPUテクノロジーの利点とメモリ価格の絶え間なく続く下落は、私たちにとって願ったりかなったりです。あなたがどう定義しようと、グリッドはすでにここにあります。今日の問題の多くを解決すると言うだけでなく、ビジネス人やアナリストが大好きなService Oriented Archetecture (SOA) を実現可能な実装でもあるのです。
著者について
JohnはC24のCTO/共同設立者であり、IONAの技術ディレクターでもあります。2000年に設立されたC24はその1年後に、金融サービスのメッセージング標準に関する革新的なJavaバインディングテクノロジーによって、市場に衝撃を与えました。Integration Objects (IO) は、FpML (検証ルールを含む) からSWIFTまで、ほとんど全ての金融サービスメッセージング標準に関して、Javaコードを生成することができます。これは市場においてユニークなニッチであり、先進的なミドルウェアやメッセージング、アプリケーションサーバベンダとOEM契約が結ばれました。現在最も大きな顧客は、そのコードを通じて50億ドル以上の株取引を実現し、最も早いプロセスは1秒間に数千のメッセージを処理しています。
C24-IOが幅広く採用されたことにより、世界中の多くの先進的な金融機関の内部に対する、独自の視点をJohnは得ることができました。Johnは、多くの場合コンサルタントとして、20年近くも銀行が行う投資に関わり、25年以上もITに関わっています。彼はJavaとJ2EEに関するいくつかの共著を持ち、Learning Treeの分散Javaコースの教材を執筆しており、Javaと銀行業界でグリッド、Jini、JavaSpacesをいつも講演しています。John は数年にわたり、たとえばJPMorganのような銀行内で、テクニカルアーキテクト部長のように、非常に高いポジションを複数兼任しています。