スケーリングは簡単です

B2Cポータルは、主に拡張が期待されています。 残念ながら、スケーリングはテクノロジーの問題として頻繁に宣言されます。流行のテクノロジーを選択するだけで、すべての問題が解決します。 これがそうではないという事実は、ごく最近では、すでに実動モード（稼働中のシステム上）で発生する可能性があります。
技術的なメイスを振る代わりに、よく考え抜かれたアーキテクチャを使用して、アクセスしやすくスケーラブルなポータルを開発し、データモデルを意識的に放棄する方法について説明します。 最初の部分では、一般的な概念について説明し、可能なシナリオとその解決策を説明します。

パート1 理論

むかしむかし、インターネットの始まりの暗い時代、つまり過去の終わりのどこか、つまりこの千年の初めに、適切なアーキテクチャを選択するという問題は、多くの場合、適切なデータベースを選択することになりました。 スタートアップのディレクターが開発者に新しいポータルを構築するよう依頼したとき、チームは主にOracle Enterprise Editionを購入するか、標準ライセンスを不要にするかについて議論しました。 高度なコンパニオンは、 t 、 Versant、またはその他のオブジェクト指向データベースを実験しました 。 その後、データモデルが作成されました。これはほとんどの場合データベースモデルであり、これをすべて質問する前に、システムは実際に何をすべきか、どのようにすればよいのでしょうか。

今日、ソフトウェア分野での興味深い発展の10年後、OracleまたはInformixを選択する代わりに、 Mongo 、 Hadoop 、 ElasticSearchのいずれを採用するかについて議論していることを除いて、すべてが非常によく似ています。 間違いなく、これらは優れた非常に有用な技術です。 ただし、テクノロジーの選択は、アーキテクチャの選択より優先されるべきではありません！ 言い換えれば、テクノロジーは、それがどれほど高度であっても、そのフレームワーク内で特定のタスクを実行し、アーキテクチャを提供する必要があります。 これらのタスクは、アーキテクチャとシステム要件によって決定される必要があります。

ソフトウェア開発の溝によく見られるテクノロジーファーストのアプローチは、技術的に不十分なガイドにとって非常に魅力的です。私はいつも投資家を無視します：彼らは私がすべての最もファッショナブルな技術を使ったと言っています、それはそれが私のせいではないことを意味します！」
私は反対のアプローチを支持します： Architecture First 。 これは、問題が主にアーキテクチャ的に解決されることを意味し、技術はアーキテクチャを実装する方法にすぎません。 したがって、テクノロジーはソリューションの一部にすぎず、このソリューションのコンテキストで特定のメリットがもたらされる場合に限ります。

以下に例を示します。

長年、人々はリレーショナルDBMSの助けを借りてポータル構築のすべての問題を解決しようとしましたが、 スキーマ （DBスキーム）が非常に複雑になるとすぐに、これらのポータルをスケーリングするすべての試みはちりばめられました。 この災害の結果、RDBMSの相続人の世代が登場しました-NoSQL DBMS（NoSQLデータベースが根本的に新しいものであるか、古いアイデアの単なる蘇生であるかは関係ありません）。 もう1つ興味深いのは、NoSQL DBMSの成功は、SQL DBMSの主要な問題であるJoinsを認識しており、単にそれらをサポートしていないという事実に基づいています。 ただし、Joinなしで実行できるようにアーキテクチャを構築する場合、つまり、 意識的にそれらを破棄する場合 、古き良きSQLデータベースは問題なくスケーリングされます。

アーキテクチャ-それは何ですか？

柔軟性 （スケーラビリティ）、 スケーラビリティ （スケーラビリティ）、 管理性 （制御性）などの標準要件をサポートする適切なアーキテクチャを見つける方法について話す前に、実際にアーキテクチャとは何かを決定する必要があります。 ここでは意見が異なります。 一部の人は、アーキテクチャをシステム要件の記述の非常に抽象的な形式、一種の要件分析と考えています。 その他は、パッケージを配布するクラスのようなものです。 このページでは、ソフトウェアアーキテクチャのさまざまな定義を幅広く選択できます 。
私は次のように最も成功していると考えています：

アーキテクチャ（ソフトウェア）は、コンポーネント、これらのコンポーネントの可視プロパティ、およびそれらの間の関係から構成されるシステムの構造です。

つまり、アーキテクチャはシステムのコンポーネントとそれらの間の通信を処理します。 この定義はコンポーネントの概念に基づいていますが、コンポーネントとは何ですか？
コンポーネントは、さまざまな基準、特にビジネスプロセスまたはデータに対する責任によって判断するアーキテクチャ思考のコンポーネントです。
個別のコンポーネントは、共通のタスクを実行するエンティティ（クラス/オブジェクトなど）のセットです。 たとえば、MessagingServiceは、メッセージの送信を担当し、いくつかのクラス（MessagingServiceインターフェース自体を含む）で構成されるコンポーネントです。
コンポーネントのサイズは可能な限り小さくする必要がありますが、問題を解決するには十分です（メッセージング-メッセージの送受信）。

B2Cポータルに戻ると、アーキテクチャの観点から、プロパティの共通点に注目します。

• 読み取り操作と書き込み操作の比率が高い：リーダーの数は、書き込みを行うユーザーの9〜10倍になる可能性があります。
• 明確に区別可能な機能-たとえば、内部メッセージングまたはプロファイル。
• ポータルトラフィックは、時刻、週、または年に基づいて複数の通常の負荷を作成するスパイクの影響を受けます。
• ポータルは常に急速に変化しています。 これは、コード、コンテンツ、およびデータに適用されます。

一般的なアーキテクチャの原則

このようなポータルを構築するための最も一般的なアーキテクチャの1つは、サービス指向（SOA）です。 最近、その評判はWebServicesの人気の影響を受けてきました。WebServicesは、SOAとほとんど共通点のないアーキテクチャですが、よく混同されます。 SOAは、WebServicesよりもはるかに古く、成熟したアーキテクチャであるため、正しく使用すると、多くのスケーリングの問題に対するソリューションを提供します。

アーキテクチャの観点から見ると、SOAのコンポーネントはサービスとクライアントであり、各コンポーネントは両方同時に存在できます。 コンポーネントの外部から見えるプロパティは、それが公開するインターフェースです。 コンポーネント間の関係については、次の2つのタイプがあります。

• 直接通信または同期通信はメソッド呼び出しです。つまり、クライアントはサービスにアクセスします。
• 間接通信または非同期通信は、特定のリスナーがあるかどうかを心配することなく、コンポーネントが「全世界に秘密に」公開する状態変化（イベント）に関するアラートです。

直接通信は、タクシーやピザの注文サービスへの電話に似ています。間接通信は、誰かが読んだかどうかに関係なく表示されるストックボードのティッカーに匹敵します。 リスニングデータのようなインタビューされたメソッドは、アーキテクチャの観点からのインターフェース、つまりコンポーネントとの通信手段です。

骨髄への隔離（データベースへ）

SOAの基本的かつ最も有用な原則の1つ：コンポーネントを相互に分離します。 とりわけ、これは各コンポーネントがそのデータの絶対所有者であることを意味します。 少なくとも、またはそれ以上に、所有者に自分で変更を行うように頼むことなく、それらを変更する権利は誰にもありません。
サービス指向アーキテクチャには多くのオタクがいますが、その主な利点はグローバルデータモデルの欠如です。 特定の各コンポーネントのインターフェースは、それについて「外部」で知られているすべてです。 彼の内面の生活は純粋に個人的な問題であり、誰にも知られていません。 この原則には支持者だけでなく、1つの（3階建ての）SQLクエリを使用して複雑な調査を実施することが非常に便利です。 はい、確かに、DBMSレベルでのさまざまなサービスのデータ間の接続は、調査、統計分析、およびデータマイニング （ データマイニング 、詳細、またはデータマイニング ）において何らかの利点がある可能性があります。 しかし、これらの関係は職場環境に存在しなければならないとはどこで言われているのでしょうか？ 誰かが分析のためにデータを必要とする場合、だれも定期的に作業システムから分析システムにデータを転送することを気にしません。 しかし、作業システム自体は、これらの「内臓」で汚染されるべきではありません-バラストは、敏nimで速い「フェラーリ」から活発で遅い「パサート」を作ります。

システムアーキテクチャの観点からのグローバルデータモデルの自主的な放棄とは、次のことを意味します。

• データモデルはサービスモデルに置き換えられます。 この単語が左右に使用されていない場合、 エンタープライズモデルと呼ばれる可能性があります。 サービスモデルは、システム内のサービス、それらが管理するアーティファクト、およびこれらのアーティファクト間の関係で構成されます。
• 各サービスと各コンポーネントは、永続性を自由に選択できます。 適切に構造化されたデータを管理するサービスは、それをSQLデータベースに書き込むことができます。 Blob サービスは 、写真であれ大きなテキストであれ、より適切な永続化メソッドを使用できます。
• サービスの負荷はシステム内で異なります。 2層（2層）データベース指向システムでは、負荷の増加は常にシステム全体に及びます。 SOAでは、負荷が増大したサービスを簡単に識別できます。これにより、最適化またはスケーリングによって、この場所でサービスを処理できるようになります。

SOAのメリットを十分に活用するには、サービスを正しく「切り刻む」必要があります。 大規模で巨大なサービスは、多くの場合「アプリケーション内のアプリケーション」に変わり、それ自体が私たちが克服しようとしていた問題を起こしやすくなります。 サービスを細かく切断しすぎると、オーバーヘッド通信が発生し、ルートでのすべてのスケーリングが停止します。 適切なサービスサイズを見つける方法

これを行う最も簡単な方法は、次の2つのソフトウェア開発パラダイムを遵守することです： 責任による設計とレイヤー分離 。 後者の助けを借りて、サービスの責任の基本的な境界-サービス（ビジネスロジックなど）とそうでないもの（プレゼンテーションロジックなど）を決定することができます。 Design by Responsibilityは、サービスを垂直にカットし、主題や機能の専門化（メッセージング、検索など）によってサービスを分類するのに役立ちます。


図1：適切なサービスの切断

サービスを正しく識別した後、サービスが相互に「通信」する方法について考える必要があります。


図2：許可された（緑）および禁止された（赤）通信パス

グローバルデータモデルを回避する方法

レイヤーの一般的に受け入れられているモデルは垂直です。 上部はプレゼンテーション層で、下部は永続的です。 したがって、開発者は通常、永続性から始めてグローバルデータモデルを作成します。 実際、SOAでは、 途中から開始する必要があります。


スキーム3：レイヤー間の依存関係

したがって、特定の永続性がそれぞれサービスのニーズを満たし、それだけである実際のサービスモデルを作成できます。 これは、スケーリングに必要な厳密な分離につながります。


図4：永続性の分離

絶対に従う必要があるもう1つのパラダイムは、KISS（Keep it Simple、Stupid）です。 ソフトウェアアーキテクチャに関して、KISSは、絶対に必要なコンポーネントのみをアーキテクチャの一部にする必要があることを意味します。 直接的に有益ではないもの、流行の技術に関連するものはすべて除外する必要があります。 つまり、サポートのコストを正当化するテクノロジーのみが、最終的なソリューションを導入する権利に値します。

良いアーキテクチャには多くの歯車があります

しかし、ようやく、サービスの設計と作成が行われたときが来ました。今度は、実際のユーザーの本当の負荷の下で、胸に胸を張るときです。 起動する前に、特定のコンポーネントがどのような負荷に耐えられるかわからないことがよくあります。 もちろん、現実的なストレステストを行うのは良いことです。 問題は、良いテストを書くために、ユーザーの実際の行動を知る必要があり、ユーザーの実際の行動を見つけるために、開始する必要があるということです。

それにもかかわらず、動作モードで起動した後にチューニングを行うことはまったく怖くないです。なぜなら、私たちは皆、時期尚早な最適化とは何かをよく覚えているからです。 時間のボトルネックを認識し、このコンポーネントが完全に過負荷になるまで応答するために、各コンポーネントを監視することが重要です（こんにちはMoSKito ！）。 このようなボトルネックを知っているため、さまざまな対応能力があります。 次のパートで、キャッシュとルーティングの2つについて説明します 。