ローカル最適化の可能性は非常に限られています。
キャッシュは、単一のコンポーネントまたはサービスの影響力を高めるのに適しています。 しかし、すべての最適化が終わります。 これは、サービスの複数のインスタンスを維持する方法、つまり、アーキテクチャをスケーリングする方法を考える最後の瞬間です。 異なるタイプのノードは、異なる方法でスケーリングできます。 一般的なルールは次のとおりです。コンポーネントがユーザーに近ければ近いほど、スケーリングが容易になります。
スケーリングに取り組む理由はパフォーマンスだけではありません。 システムの可用性の大部分は、各コンポーネントの複数のインスタンスを並行して実行できるかどうかにも依存します。これにより、システムのどの部分の損失にも耐えることができます。 スケーリングの最高の完成度は、システムを柔軟に管理できることです。つまり、トラフィックのリソースの使用を調整することです。
通常、プレゼンテーションレイヤーのスケーリングは簡単です。 これは、Webサーバーまたはサーブレットコンテナー（tomcatまたはjettyなど）で実行されているWebアプリケーションが属するレベルであり、マークアップ（HTML、XML、JSONなど）の生成を担当します。
必要に応じて新しいサーバーを簡単に追加および削除できます-単一のWebサーバーの場合：
- ステートレス、または
- その状態は回復可能です-たとえば、完全にキャッシュで構成されているため、または
- それらの（キャッシュ）状態は特定のユーザーを指し、同じユーザーが常に同じサーバーにアクセスするという保証があります（セッションスティッキ性）。
サービスを実行するレベルであるアプリケーション層を拡張することはより困難です。 しかし、アプリケーション層に移る前に、その背後の層であるデータベースを見てみましょう。
データベース全体のスケーリングに関する悲しい真実は、データベースが機能しないことです。 また、時々、さまざまなデータベースメーカーの代表者が、今回は確かに規模を拡大できることを確信させようとしています。 少しの免責事項：マスター/スレーブでデータベースクラスターやレプリケーションを行う必要がないと言っているわけではありません。 クラスターとレプリカを使用する理由はたくさんありますが、 パフォーマンスはそれらの間ではありません。
これが、アプリケーションがデータベース間で非常に貧弱にスケーリングする主な理由です。データベースの主なタスクは、データ（ACIDおよびその他すべて）を保存することだけです。 彼らにとってデータの読み取りははるかに困難です（「どのように」「なぜ」と叫ぶ前に、なぜlucene / solar / elastic searchのような多くのインデクサーが必要なのでしょうか？） ベースをスケーリングできないため、アプリケーション層をスケーリングする必要があります。 これがうまく機能する理由はたくさんあります。2つ挙げます。
- このレベルでは、ほとんどの論文「アプリケーションとそのデータに関する知識」が収集されます。 アプリケーションが何をどのように行い、どのように使用されるかを知って、スケーリングできます
- データベースレベルで提供されているツールよりもはるかに強力なプログラミング言語ツールを使用して、ここで作業できます。
サービスのスケーリングにはさまざまな戦略があります。
スケーリング戦略。
最初に、サービスの状態（状態）を判断する必要があります。 サービスの1つのインスタンスの状態は、彼だけが知っている情報であり、したがって、他のインスタンスと区別する情報です。
通常、サービスインスタンスは、このサービスの1つのコピーが実行されるJavaVMです。 その状態を決定する情報は通常、キャッシュに入るデータです。 サービスに独自のデータがまったくない場合、サービスはステートレスです。 サービスの負荷を軽減するために、このサービスの複数のインスタンスを実行できます。 一般に、これらのインスタンスにトラフィックを分散するための戦略は、スケーリング戦略です。
最も単純な戦略はラウンドロビンです。 同時に、各クライアントはサービスの各インスタンスと「対話」します。これらのインスタンスは順番に、つまり次々に輪になって使用されます。 この戦略は、サービスがステートレスになり、外部インターフェイス経由で電子メールを送信するなどの簡単なタスクを実行するまで有効です。
スキーム5：ラウンドロビンの原則に従ってサービスコールを分散する
サービスインスタンスに状態がある場合、たとえば、EventChannelまたは別のパブリッシュ/サブスクライバオプションを介して状態の変更を通知することにより、それらを相互に同期する必要があります。
図6：状態同期を使用したラウンドロビン
同時に、各インスタンスは、保存された各オブジェクトに加えたすべての変更を他のインスタンスに通知します。 次に、残りのインスタンスはローカルで同じ操作を繰り返し、プライベート状態を変更します。これにより、すべてのインスタンスでサービスの状態を一貫した（一貫した）状態に維持します。
この戦略は、少ないトラフィックでうまく機能します。 ただし、その増加に伴い、同じオブジェクトを複数のインスタンスで同時に変更する可能性に関して問題が発生します。
これに対処するためにルーティングが使用されます。 この場合、ルーティングとは、コンテキストに応じてサービスインスタンスが選択されることを意味します。 コンテキストは、クライアント、操作、またはデータの場合があります。 データルーティング、 シャーディングは最も強力なルーティングツールです。これは、操作のパラメーター（つまりデータ）に基づいてサービスのターゲットインスタンスを選択するルーティングアルゴリズムを意味します。
理想的には、UserIdなどの単一値パラメーターがあり、これを簡単に数値に変換し、残りで除算できます。 作業インスタンスの数で除算すると、残りはリクエストのターゲットインスタンスを示します。残りが0のすべてのリクエストは最初のインスタンスに進み、残りが1から2番目のインスタンスなどになります。
図7：残りのシャーディング
この戦略には有用な副作用があります。同じユーザーのデータに基づくすべてのリクエストが常に同じインスタンスに分類されるため、データは断片化されます。 これは、より小さなキャッシュ、必要に応じて断片化されたデータベース（つまり、各インスタンスまたはそのグループが独自のデータベースを持っている）、およびその他の最適化スナックを意味します
適切なミドルウェアを使用すると、さらに一歩進んでさまざまな戦略を組み合わせることができます。 たとえば、複数のインスタンスをグループにグループ化して、シャーディングによってクエリを分散し、グループ内の弾力性のためにラウンドロビンを使用できます。 そのような組み合わせた戦略の数は多すぎて（ 別の例 ）、1つの投稿ですべてを説明することはできず、特定の問題に依存します。
特に、1つの操作が異なるコンテキストで2つのデータセットを同時に変更する場合、データを常にセグメント化できるわけではありません。 典型的な例は、ユーザーAからユーザーBへのメッセージの配信で、両方のメールボックスが同時に変更されます。 インスタンス間でデータを分散する（シャーディング）アルゴリズムを見つけることは不可能です。これにより、ユーザーAとBのボックスが同じサービスインスタンスにあることが保証されます。 しかし
図8：プロキシサービス
プロキシサービスインスタンスのタスクは、読み取り要求を処理して、要求をマスターサービスに渡すことなく応答することです。 書き込み操作（ 初期インストールを思い出してください）よりもはるかに多くの読み取りがあり、それらからマスターサービスを排除しているため、私たちは彼の生活を大いに促進します。 通常、読み取り操作は1人の（アクティブな）ユーザーのコンテキストで実行されるため、上記のように「共有」できます。 残りの書き込み操作はプロキシを介してマスターに送られますが、負荷の主要部分がプロキシに残っているという事実により、すでにthey核の送達が大幅に少なくなっています。
エピローグ
このシリーズのフレームワーク（ ここ 、 ここ 、実際はここ）では、適切なアーキテクチャを見つける方法と、それをスケーリングするツールについて説明しました。 建築パラダイムの検索と追跡に費やした時間は、困難な時期に何回も報われる投資であることを読者に納得させたいと思います。 スレーブプロキシ、ラウンドロビンルーティング、またはゼロキャッシュは、新しいポータルで機能し始めて、最初に考えたものではありません。 また、「万が一に備えて」それらを埋め込む必要はありません。それらの使用方法を知って、そのようなツールを使用できるアーキテクチャを用意することが重要です。
すべてのポータルをスケーリングする必要はありませんが、これを迅速に行うことができる必要があるユーザーはスケーリングする必要があります。 テクノロジー（NoSQLなど）のみに依存するということは、ホイールを間違った手に渡すことを意味し、テクノロジーの選択が間違っていることが判明した場合、ほうきでシステムの断片を拾います。
最初から適切なアーキテクチャを選択し、原則とパラダイムを見つけてそれらを順守すれば、常に発生する困難や課題への答えを見つけることができます。
頑張って