BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース トゥルーリニアスケーラビリティに新たなるパターンとミドルウェアアーキテクチャーは必要か?

トゥルーリニアスケーラビリティに新たなるパターンとミドルウェアアーキテクチャーは必要か?

ブックマーク
リニアにスケーラブルなアプリケーションを構築する際に新しいパターンとミドルウェアアーキテクチャーは必要になってくるのだろうか。GigaSpacesのCTOのNati Shalomは、段階的なアプローチ用にデザインされたミドルウェアは真のリニアスケーラビリティアーキテクチャーには使用できないと信じている。その代わりに彼は分割、またスケールアウトされたモデルをサポートする自己完結型ユニットに基づいた新しいミドルウェアスタックを提案している。Shalomが新たなミドルウェアスタックを提案する一方、マイクロソフトのPat Hellandは数年前自身が呼ぶところ、半無限のスケーラブルシステムにて使用される新たなる処理的パターンと形態を提案している。

Nati Shalomは同期しているデータを保持するためだけに各段階でたくさんのステートやメッセージングピンポンを引き合わせるので、この段階的なアプローチに(メッセージング、データ、ビジネスプロセッシング)に未来はないと主張している。また彼は仕事量のリニアな増加を可能にさせるために、多大なる数のCPUを加える必要性をもたらしつつ、段階的アプローチは非ノンリニアスケーラビリティをもたらすであろうと論じている。

それに代わりNatiは同じアドレススペースにメッセージング、データ、プロセッシングを保ったまま、一つのプロセッシングユニットの中にこれらが一緒に置かれるという、異なるアーキテクチュアルアプローチを提案している。プロセッシングユニット間でシェアされないアーキテクチャを結合することにより、プロセッシングのニーズが増加した場合にも機械を追加することによって、リニアなスケーラブルソリューションが可能になる。このモデルはもちろんステートレスアプリケーションには大変適しているが、ステートフルアプリケーションに関しては事は複雑化してくる。Natiは以前に2つの基本的なルールを提示するのと共にステートフルアプリケーションの測り方について論じている。

  1. まず同じデータソースの競合を減少させればならない。
  2. アプリケーションの中の多様なユニットか間で依存性をなくす必要がある。 リニアスケーラビリティは各単位が自己完結型でまた他のユニットと何も共有していない場合においてのみ可能になる。

これらがスケーラビリティの基本的なルールである。しかしステートフル環境でこの2つのルールを達成する通常のパターンは区切られている。
例:一つ一つのユニットがアプリケーションデータの特定のサブセットを処理させたままアプリケーションを個々の作業ユニットに分割する。そして単純にプロセッシングユニットを加えることにより測ることが可能になる。

もしデータがこれらの隣接したアプリケーションデータのサブセット内で分割可能であれば、ここのユニットがサブセットのデータを保持したままアプリケーションを単体のプロセッシングユニットにスケールアウトすることができる。このやり方が分割可能でな典型的なデータはウェブアプリケーションのセッションインフォメーションであろう。しかしこの分割モデルはたくさんのアプリケーションプロセスが同じシェアードデータにアクセス、及びアップデートする必要のある場合には機能しない。 Shalomはこれに関して”このようなケースではデータはリモートパーティションを通して参照することができる。
例:ビジネスロジックとメッセージングは一つの同じプロセッシングユニットに共存する。この方法であればレイテンシと同じ費用でスケーリングができる。

しかしもしシェアードデータが膨大だった場合には?一つの解決策としては同じ種類のデータを異なるデータストアパーティションに区分することだ。しかしこの方法には二つの問題点が浮上する。

  • 凝集である。中心化されていないデータソース上でのクエリの実行のしかた(例:たくさんのデータストアパーティション上における一つのクエリ)
  • 分子分散処理の使用 VS 分子分散処理の不使用 。分配分散処理はうまくスケーリングが行われないので他の解決策ソリューションが必要となる。 

Shalomはこの集合問題に関して解決策を述べている。

クエリを平行化すると個々のクエリがそれぞれのパーティションに反して作動する。そうすることによって自分の要求を完全に平行化するためにそれぞれのパーティション内のCPUとメモリキャパシティを利用することになる。クエリを提示しているクライアントはパーティションの物理的な分離を察することなく、まるで一つ大きな違いのある巨大なデータに反して作動しているようかのように集合された結果を得るだろう。こうすればもっと早くなるだろう。

細かい分散処理問題の解決策を見つけるために、私達はこの問題をAmazonに所属しニュース上でで"分配分散処理を超えて:Apostateの主張”を主張したPat Helland氏を訪ねた。ニュース上で彼はラージスケールシステム内では基本的にクロスシステム処理を使用すべきではないことを結論としている 。

スケーラブルシステムを構築する際に使用されているコンセプトとアブストラクト用用語の欠如に関してHellandはこう定義している。

-エンティティはその実体内で自動的に更新される可能性のある名前つきのデータの集合体であるがエンティティが交差して自動更新されることは絶対にない

- アクティビティは単一性エンティティとのメッセージングを行うために使用されるエンティティ内のステートの集合体から成る

決断にいたるまでのワークフローはエンティティ内でのアクティビティ内の機能において長年にわたり論議されてきた。
それは半永久スケーリングのように驚異的なワークフローの超微粒子の性質なのです。

これによってHellandは同じトランザクション内で二つのエンティティは更新されないことを意味している。代わりに彼は”トランザクショナルシリアライザビリティの複数分離スコープ”と想定しているが、後にHellandは紙面上でこのスコープはエンティティと定義している。 マルチプルエンティティの更新はこの定義の基では単一分子トランザクション内では成されないが、エンティティ間でpeer to peerスタイルを用いてメッセージングを通して行われなければならない。このメッセージングは単独でのカンバセーショナルステートマネージメントの必要性をもたらし、またHellandはそれぞれのエンティティパートナーのステートマネージメントをアクティビティーと定義している。

たくさんの商品を含んだ一つ注文の処理をすることを考えてみてください。商品一つ一つの製品管理が分離されたアクティビティといえるだろう。 一つの注文がエンティティ、また倉庫の人々に用意されたそれぞれの商品が分離されたエンティティとなる。
トランザクションはこれらのエンティティを交差して想定されない。

この注文内でそれぞれの在庫が別々に処理されるのだ。メッセージングプロトコルは別々に管理されなくてはならない。注文そのものに含まれている在庫ごとのデータはアクティビティである。そのように名付けられてはいないがこのパターンは良くラージスケールアプリケーションにて見受けられる。

これによってもたらされるエンティティとメッセージング間での分散処理性のトランザクショナルアトミシティの欠如が、果てはビジネス理論に潜在する新たなる問題を引き起こすのだ。冪等(べきとう)性の処理可能なメッセージの再試行とプロセス。また、エンティティ間における非同期メッセージングの必要性は細顆粒のワークフローの施行を強制させる。またそれは下記に示されているキャンセレイションまたコンファームを含む試験的な動作を含んでいる。

Nati Shalomによって紹介されたこのアーキテクチャーは最近バージョン6が発表されたGigaSpacesのプラットフォームにて施行されている。Pat Hellandの記事は時代を問わず貴重なものであり、是非全文を読んで欲しい。

この記事に星をつける

おすすめ度
スタイル

BT