XAP（でたらめアーキテクチャバスト）

昨日、私が初めて地元の微妙さを知らずにHabrに関する記事を書いた。



修正済み！ 今では普通の言葉で、ユーモアを持って！



ブラックフライデーは、 コールのアメリカのインターネットデパートにとって真のブラックであることが判明しました。 クリスマスセールの日に、すべてのサーバーは銅の盆地で覆われていました。 その日に稼いだ年収の通常20％は、とんでもない些細なことであることが判明しました。これはすべて、ボリバルがそのような負荷に耐えられなかったためです。



Tomcat + WebLogic + DBの従来のアーキテクチャは完全に台無しにされています！ システム管理者は無駄に床を駆け回り、大手プログラマーはパニックで大騒ぎし、建築家は髪の残りを引き裂きました...ボトルの首はすべての潜在的な顧客がそれを絞ることができず、短期間で拡張するには十分ではありませんでした。 ボトルは性交を破った。 そして長い間、彼女の破片が負った傷は出血していました...

3層アーキテクチャの問題

-息子、それは動作します-触れないでください！

-お父さん、それは動作しません、それはブレーキをかけます!!!



皆さんは古いことをよく知っていますが、常に親切な3レベルのアーキテクチャーではありません。









このソリューションを分析することにより、いくつかの明らかな問題を簡単に特定できます。

管理の難しさ

すべてのレベルに異なるクラスタリングモデルがあります。 そのようなシステムを管理するには、それらすべての知識と経験が必要です。 これには以下が含まれます。

• 高コスト：企業は、すべてのコンポーネントの個別のライセンスを購入し、各レベルをインストールして維持するために専門家を雇わなければなりません。 さらに、一部のコンポーネントのクラスタリングは必ずしも単純ではなく、多くの場合、経験豊富な専門家でさえ予期せぬ困難に満ちています。
• 制御の難しさ：実際の稼働中のシステムのこのような多数のコンポーネントの追跡と監視には、再度追加のリソースが必要です。 ほとんどの場合、そのような目的のために追加のソフトウェアアプリケーションを購入する必要があります。
• 問題の特定と解決の難しさ：システムに障害が発生した場合、何がどのレベルで発生したかを判断することは困難です
• ソフトウェアの実装の難しさ：モジュール間の統合と構成は、追加のコスト源にもなります。 すべてのモジュールを相互に正しく「通信」するには、通常、ある程度の時間と追加のリソースが必要です。

静的リソースバインディング

ハードドライブやサーバー名など。 そのようなアプリケーションは本質的に非常に動的であるため、クラウドにそのようなアプリケーションをインストールするときに問題が発生します。

性能

ほとんどすべての要求は、システムの3つのレベルすべてを通過し、レベル間およびレベル内の多くのネットワークジャンプを含む可能性があり、これは平均応答時間に影響します。 さらに、遅かれ早かれ、データをディスクにフラッシュする必要があります。 ネットワークおよびディスクI / Oはスケーラビリティを大幅に制限し、再びシステムのブレーキングにつながります。



その結果、3層アーキテクチャは予測どおりにスケーリングできません。 システムの負荷を増加させると、データを処理するためにより多くのリソースが必要になりますが、愚かな鉄を追加してもこの問題は解決しません。 さらに、多くの場合、レベルの1つ（データベースサーバーなど）にリソースを追加すると、役立つだけでなく、クラスターノード間の同期のオーバーヘッドにより、システム全体のレイテンシが増加し、スループットが低下します。

キャッシュとデータグリッドが問題を解決しない理由

遅延とスケーラビリティの問題を解決するために、通常、リレーショナルデータベースの前にインメモリデータグリッドを配置します。 間違いなく、これは正しい方向へのステップであり、システムを部分的にオフロードし、主にキャッシングに適しています。 ほとんどのデータグリッドでは、一意のIDのみを使用してデータを取得する能力が制限されていることに注意してください。 このソリューションは個々のケースに適用できますが、次の理由から依然として理想的ではありません。

• 追加のライセンスが必要な別のレイヤーが追加されます。 他のすべてと同様に、誤動作が発生した場合、新しいレベルを統合、構成、監視、および削除する必要があります。 したがって、これにより、このアーキテクチャの管理の全体的な複雑さと、インストール、サポート、およびメンテナンスのコストが増加します。
• 前述のように、このようなソリューションは、読み取り操作が多いシステムに役立ちます。 ただし、書き込み操作が多いシステムではまったく役に立ちません。 さらに、キャッシュが存在する場合、キャッシュとデータベース間の同期に追加のコストが発生します。

実世界の例

オンライン販売のためのコールの実際の多層システムアーキテクチャを検討してください。





このシステムのどの部分もボトルネックの役割を果たすことができることはすぐに明らかです。 明らかに、「狭い」場所以外の場所にリソースを追加しても、システムのブレーキを取り除くのに役立ちません。



KohlのWebLogicの場合、ApacheとOracleデータベースは50台の物理サーバーを使用して素晴らしい仕事をしました。 30,000人の同時接続ユーザーが、すべてのリクエストに対する回答を定期的に受け取りました。 たとえば、企業が毎秒特定の一定数のトランザクションを処理する必要があり、システムの要件に急激な変更がなければ、今後も機能し続けます。



ただし、2009年の同じ「ブラックフライデー」（ブラックフライデー、何百万人ものアメリカ人が店に急行し、小売業者が1日で年間収益の20パーセント、時には30パーセントを稼ぐ）は、システムが500,000の負荷に対応することを要求しました同時にユーザー。 3レベルのアーキテクチャでは、このような打撃に対応できませんでした...



結果は数千万ドルの損失です。 したがって、質問：

古いヒーローを変える時ですか？

そのため、最新のプラットフォームの主要な要件を策定します。

• データ操作は高速でなければなりません
• 抽象化のレイヤー間の分離はパフォーマンスに影響しないはずです
• 新しいリソースを追加すると、生産性が直線的に（またはほぼ直線的に）向上するはずであり、制限に左右されません。
• 外交は柔軟かつシンプルでなければなりません。
• システムは「殺せない」必要があり、潜在的な問題を事前に警告する必要があります。

10年前に新しいXAPプラットフォーム（eXtreme Application Platform）の開発を開始したGigaspacesのエンジニアは、これらの要件をほぼガイドしました。

それは彼らがすべて来た方法です

• すべてのデータはディスクではなくRAMに保存されます。 どちらかといえば、RAMは今日では非常に安価であり、Oracle Databaseでさえ、最も単純なサポートでも
• アプリケーションロジックは同じデータコンテナにあります。 もちろん、大学の教師やその他の古典建築の愛好家はこれを好まないかもしれません。 別のハブロフスク市民は、そのようなソリューションがデータとロジックの不健全な混合に寄与すると判断することさえあります。 しかし、経験から、実際の職人を止めることができる層はないことが示されており、適切なスキルがあれば、あらゆる種類の「アーキテクチャ」でビネグレットを作ることができます。
• すべてのデータは無制限の数のパーティションに分割され、各パーティションは別々のマシンに配置できます。
• 外交は宣言的に記述されています！ 「すべてのデータを100,500個に分割し、各ピースに2つのバックアップを作成し、1つのデータセンターに外交バックアップを作成せず、卒業証書に146％以上ロードされたマシンを使用しないでください」
• 特別なディスパッチャは、一度に複数の場所にデータを書き込み、障害が発生した場合、リクエストを他のマシンに自動的にリダイレクトします。 これと並行して、クラスター内のノード数の不足、システム障害、マシンの輻輳など、潜在的な問題をすべて通知する便利な監視システムがあります。

そして、ここにビデオがあります

コールは灰から立ち上がった

2009年の危機の後、コールは古いアーキテクチャ全体をXAPに置き換えました。 その結果、Googleによると、今日のサイトはページ配信速度の面で世界で最初のサイトの1つです。





今日、コールだけがXAPプラットフォームを使用しているわけではありません。 現在の顧客リストには、スイスの大手銀行（ UBSなど ）、ニューヨーク証券取引所、 アバイア 、その他数百社が含まれています。

エピローグ

誰かが言うだろう：「そして、私はマルチレベルのアーキテクチャを使用し、非常に満足しています！」そして非常によく。 しかし、データの量が指数関数的に増加している世界に住んでいるので、今日、インメモリコンピューティングプラットフォームが必要ない場合でも、少なくともそれらの存在とそれらがもたらす利点について知る必要があることを理解する必要があります。 近い将来、アプリケーションで処理されるデータ量の要件が増加する可能性があります。もちろん、インメモリコンピューティングプラットフォームが役立つ可能性があります。もちろん、使用が単純に必要な膨大なデータでリアルタイムに動作するアプリケーションは言うまでもありません。

追記

31日土曜日にJUGに来てください。XAPについて、その作品のよりカラフルでライブのショーでお話しします。



そして、ここにビデオがあります：