おい、ハブル！

コロナウイルスによる現在の状況を考慮して、多くのインターネット サービスの負荷が増加し始めています。 例えば、 英国の小売店チェーンの XNUMX つは、オンライン注文サイトを停止しました。容量が足りなかったので。 また、より強力な機器を追加するだけでサーバーを高速化できるとは限りませんが、クライアントのリクエストは処理される必要があります (そうしないと、リクエストは競合他社に送られてしまいます)。

この記事では、高速でフォールト トレラントなサービスを作成できる一般的なプラクティスについて簡単に説明します。 ただし、考えられる開発スキームの中から、現時点で実現可能なもののみを選択しました。 使いやすい。 項目ごとに、既製のライブラリがあるか、クラウド プラットフォームを使用して問題を解決する機会があります。

水平スケーリング

最もシンプルで最もよく知られているポイント。 従来、最も一般的な XNUMX つの負荷分散スキームは、水平スケーリングと垂直スケーリングです。 最初の場合 サービスを並行して実行できるようにすることで、サービス間の負荷を分散します。 2番目の より強力なサーバーを注文するか、コードを最適化します。

たとえば、抽象的なクラウド ファイル ストレージ、つまり OwnCloud や OneDrive などの類似物を取り上げます。

このような回路の標準的な図を以下に示しますが、これはシステムの複雑さを示しているだけです。 結局のところ、何らかの方法でサービスを同期する必要があります。 ユーザーがタブレットからファイルを保存し、それを電話から表示したい場合はどうなりますか?

アプローチの違い: 垂直スケーリングではノードの能力を高める準備ができており、水平スケーリングでは負荷を分散するために新しいノードを追加する準備ができています。

CQRS

コマンドクエリの責任の分離 これは、異なるクライアントが異なるサービスに接続できるだけでなく、同じイベント ストリームを受信できるようにするため、かなり重要なパターンです。 単純なアプリケーションの場合、その利点はそれほど明らかではありませんが、ビジーなサービスにとっては非常に重要です (そして簡単です)。 その本質は、受信データ フローと送信データ フローが交差すべきではないということです。 つまり、リクエストを送信して応答を期待することはできず、サービス A にリクエストを送信しても、サービス B から応答を受け取ります。

このアプローチの最初の利点は、長いリクエストの実行中に (広い意味での) 接続を切断できることです。 たとえば、ほぼ標準的なシーケンスを考えてみましょう。

1. クライアントはサーバーにリクエストを送信しました。
2. サーバーの処理時間が長くなりました。
3. サーバーはクライアントに結果を返しました。

ポイント 2 で接続が切断された (またはネットワークが再接続された、またはユーザーが別のページに移動して接続が切断された) と想像してみましょう。 この場合、サーバーが正確に何が処理されたかに関する情報をユーザーに応答して送信することは困難になります。 CQRS を使用する場合、シーケンスは少し異なります。

1. クライアントは更新をサブスクライブしました。
2. クライアントはサーバーにリクエストを送信しました。
3. サーバーは「リクエストが受け入れられました」と応答しました。
4. サーバーはポイント「1」からのチャネルを通じて結果を返しました。

ご覧のとおり、このスキームはもう少し複雑です。 さらに、ここには直感的なリクエストとレスポンスのアプローチが欠けています。 ただし、ご覧のとおり、リクエストの処理中に接続が切断されてもエラーは発生しません。 さらに、実際にユーザーが複数のデバイス (携帯電話とタブレットなど) からサービスに接続している場合、両方のデバイスに応答が届くことを確認できます。

興味深いことに、受信メッセージを処理するコードは、クライアント自体の影響を受けたイベントと、他のクライアントからのイベントを含む他のイベントの両方で同じ (100% ではない) になります。

ただし、実際には、一方向フローを関数型スタイル (RX などを使用して) で処理できるという事実により、追加のボーナスが得られます。 そして、本質的にアプリケーションを完全にリアクティブに、また機能的なアプローチを使用して作成できるため、これはすでに大きな利点です。 ファット プログラムの場合、これにより開発リソースとサポート リソースが大幅に節約されます。

このアプローチを水平スケーリングと組み合わせると、ボーナスとして、あるサーバーにリクエストを送信し、別のサーバーから応答を受信できるようになります。 したがって、クライアントは自分にとって都合のよいサービスを選択でき、内部のシステムは引き続きイベントを正しく処理できます。

イベントソーシング

ご存知のとおり、分散システムの主な特徴の XNUMX つは、共通の時間や共通のクリティカル セクションが存在しないことです。 XNUMX つのプロセスについては、(同じミューテックス上で) 同期を実行できます。その際、他の誰もこのコードを実行していないことが保証されます。 ただし、これは分散システムにとって危険です。オーバーヘッドが必要になり、スケーリングの美しさもすべて損なわれてしまいます。すべてのコンポーネントが依然として XNUMX つのコンポーネントを待機することになります。

ここから重要な事実がわかります。高速分散システムは同期できない、なぜならパフォーマンスが低下するからです。 一方で、コンポーネント間には一定の一貫性が必要になることがよくあります。 このために、次のアプローチを使用できます 最終的な一貫性、最後の更新から一定期間 (「最終的に」) データの変更がない場合、すべてのクエリが最後に更新された値を返すことが保証されます。

従来のデータベースでは非常に頻繁に使用されることを理解することが重要です。 強い一貫性ここで、各ノードは同じ情報を持っています (これは、XNUMX 番目のサーバーが応答した後でのみトランザクションが確立されたとみなされる場合によく実現されます)。 ここでは分離レベルにより多少の緩和が見られますが、一般的な考え方は同じであり、完全に調和された世界で暮らすことができます。

ただし、元のタスクに戻りましょう。 システムの一部を構築できる場合 最終的な一貫性そうすると、次の図を構築できます。

このアプローチの重要な特徴:

• 受信リクエストはそれぞれ XNUMX つのキューに入れられます。
• リクエストの処理中に、サービスはタスクを他のキューに配置することもあります。
• 各受信イベントには識別子があります (重複排除に必要です)。
• キューは思想的には「追加のみ」のスキームに従って機能します。 要素を削除したり、再配置したりすることはできません。
• キューは FIFO スキームに従って動作します (トートロジーでごめんなさい)。 並列実行を行う必要がある場合は、ある段階でオブジェクトを別のキューに移動する必要があります。

私たちはオンライン ファイル ストレージの場合を検討していることを思い出させてください。 この場合、システムは次のようになります。

図内のサービスは必ずしも別のサーバーを意味するわけではないことが重要です。 プロセスさえも同じかもしれません。 もう XNUMX つ重要なことは、イデオロギー的に、これらのものは水平スケーリングを簡単に適用できる方法で分離されているということです。

XNUMX 人のユーザーの場合、図は次のようになります (異なるユーザー向けのサービスは異なる色で示されます)。

このような組み合わせによるボーナス:

• 情報処理サービスは分離されています。 列も区切られています。 システムのスループットを向上させる必要がある場合は、より多くのサーバーでより多くのサービスを起動するだけです。
• ユーザーから情報を受け取った場合、データが完全に保存されるまで待つ必要はありません。 逆に、「わかりました」と答えてから、徐々に作業を開始するだけです。 同時に、新しいオブジェクトの追加はすぐに行われ、ユーザーはサイクル全体の完全なパスを待つ必要がないため、キューによってピークが平滑化されます。
• 例として、同一のファイルをマージしようとする重複排除サービスを追加しました。 1% のケースで長時間動作しても、クライアントはほとんどそれに気づきません (上記を参照)。これは大きな利点です。XNUMX% の速度と信頼性が要求されなくなったためです。

ただし、欠点はすぐにわかります。

• 私たちのシステムは厳密な一貫性を失いました。 これは、たとえば、異なるサービスにサブスクライブした場合、理論的には異なる状態を取得できることを意味します (サービスの XNUMX つが内部キューから通知を受信する時間がない可能性があるため)。 別の結果として、システムには共通時間がなくなりました。 つまり、サーバー間のクロックが同期していない可能性があるため (さらに、XNUMX つのサーバーで同じ時間が理想郷であるため)、たとえば、単純に到着時間だけですべてのイベントを並べ替えることは不可能です。
• (データベースの場合のように) 単純にロールバックできるイベントはなくなりました。 代わりに、新しいイベントを追加する必要があります- 補償イベント、これにより、最後の状態が必要な状態に変更されます。 同様の分野の例として、履歴を書き換えないと (これは場合によっては悪いことです)、git でコミットをロールバックすることはできませんが、特別なロールバックを行うことはできます。 ロールバックコミット、基本的に古い状態を返すだけです。 ただし、誤ったコミットとロールバックは両方とも履歴に残ります。
• データ スキーマはリリースごとに変更される可能性がありますが、古いイベントは新しい標準に更新できなくなります (イベントは原則的に変更できないため)。

ご覧のとおり、イベント ソーシングは CQRS とうまく連携します。 さらに、データ フローを分離せずに、効率的で便利なキューを備えたシステムを実装すること自体がすでに困難です。キューのプラスの効果全体を無効にする同期ポイントを追加する必要があるからです。 両方のアプローチを同時に適用するには、プログラム コードを若干調整する必要があります。 今回の場合、ファイルをサーバーに送信したときの応答は「ok」のみで、これは「ファイルを追加する操作が保存された」ことを意味するだけです。 形式的には、これはデータがすでに他のデバイスで利用可能であることを意味するものではありません (たとえば、重複排除サービスがインデックスを再構築できるなど)。 ただし、しばらくすると、クライアントは「ファイル X が保存されました」という形式の通知を受け取ります。

結果として：

• ファイル送信ステータスの数は増加しています。従来の「ファイル送信済み」の代わりに、「ファイルがサーバー上のキューに追加されました」と「ファイルがストレージに保存されました」という XNUMX つのステータスが表示されます。 後者は、他のデバイスがすでにファイルの受信を開始できることを意味します (キューが異なる速度で動作するという事実に合わせて調整されています)。
• 提出情報がさまざまなチャネルを介して送信されるようになったという事実により、ファイルの処理ステータスを受信するためのソリューションを考え出す必要があります。 この結果、従来のリクエスト/レスポンスとは異なり、ファイルの処理中にクライアントを再起動できますが、この処理自体のステータスは正しいものになります。 さらに、このアイテムは基本的に箱から出してすぐに機能します。 その結果、私たちは失敗に対してより寛容になりました。

シャーディング

上で説明したように、イベント ソーシング システムには厳密な一貫性が欠けています。 これは、複数のストレージを同期せずに使用できることを意味します。 私たちの問題にアプローチすると、次のことが可能になります。

• ファイルを種類ごとに分けます。 たとえば、写真/ビデオをデコードして、より効率的な形式を選択できます。
• 国ごとにアカウントを分けます。 多くの法律により、これが必要となる場合がありますが、このアーキテクチャ スキームはそのような機会を自動的に提供します。

あるストレージから別のストレージにデータを転送したい場合、標準的な手段ではもはや十分ではありません。 残念ながら、この場合はキューを停止し、移行を実行してから開始する必要があります。 一般的なケースでは、データを「オンザフライ」で転送することはできませんが、イベント キューが完全に保存されており、以前のストレージ状態のスナップショットがある場合は、次のようにイベントを再生できます。

• イベント ソースでは、各イベントに独自の識別子 (理想的には、減少しない) があります。 これは、最後に処理された要素の ID であるフィールドをストレージに追加できることを意味します。
• すべてのイベントを複数の独立したストレージで処理できるように、キューを複製します (XNUMX つ目はデータがすでに保存されているストレージで、XNUMX つ目は新規ですがまだ空です)。 もちろん、XNUMX 番目のキューはまだ処理されていません。
• XNUMX 番目のキューを起動します (つまり、イベントの再生を開始します)。
• 新しいキューが比較的空の場合 (つまり、要素の追加と取得の間の平均時間差が許容範囲内である場合)、リーダーを新しいストレージに切り替え始めることができます。

ご覧のとおり、私たちのシステムには厳密な一貫性がありませんでしたし、現在も保っていません。 存在するのは結果的な一貫性だけです。つまり、イベントが同じ順序で処理される (ただし、遅延は異なる可能性があります) という保証があります。 そしてこれを利用すると、システムを停止することなく比較的簡単に地球の裏側へデータを転送することができます。

したがって、ファイルのオンライン ストレージに関する例を続けると、このようなアーキテクチャによってすでに多くの利点が得られます。

• 動的な方法でオブジェクトをユーザーの近くに移動できます。 これにより、サービスの品質を向上させることができます。
• 当社は一部のデータを企業内に保管する場合があります。 たとえば、エンタープライズ ユーザーは、(データ漏洩を避けるために) 管理されたデータ センターにデータを保存することを要求することがよくあります。 シャーディングを通じてこれを簡単にサポートできます。 また、顧客が互換性のあるクラウドを使用している場合、このタスクはさらに簡単になります (たとえば、 Azure のセルフホスト型).
• そして最も重要なことは、これを行う必要がないということです。 結局のところ、最初は (すぐに作業を開始するために) すべてのアカウントに XNUMX つのストレージがあれば十分満足するでしょう。 そして、このシステムの最大の特徴は、拡張可能でありながら、初期段階では非常にシンプルであるということです。 XNUMX 万もの独立したキューなどを処理するコードをすぐに記述する必要はありません。 必要に応じて、これは将来的に実行される可能性があります。

静的コンテンツのホスティング

この点は非常に明白に思えるかもしれませんが、多かれ少なかれ標準でロードされるアプリケーションには依然として必要です。 その本質は単純です。すべての静的コンテンツは、アプリケーションが配置されているのと同じサーバーからではなく、このタスク専用の特別なサーバーから配布されます。 その結果、これらの操作がより高速に実行されます (条件付き nginx は Java サーバーよりも高速かつ低コストでファイルを提供します)。 さらに CDN アーキテクチャ (コンテンツ配信ネットワーク) により、ファイルをエンド ユーザーの近くに配置できるようになり、サービスの操作の利便性にプラスの効果が得られます。

静的コンテンツの最も単純かつ標準的な例は、Web サイトのスクリプトと画像のセットです。 これらを使用するとすべてが簡単です。それらは事前に知られており、アーカイブは CDN サーバーにアップロードされ、そこからエンド ユーザーに配布されます。

ただし、実際には、静的コンテンツの場合は、ラムダ アーキテクチャに似たアプローチを使用できます。 タスク (オンライン ファイル ストレージ) に戻りましょう。このタスクでは、ユーザーにファイルを配布する必要があります。 最も簡単な解決策は、ユーザーのリクエストごとに必要なチェック (承認など) をすべて実行し、ストレージからファイルを直接ダウンロードするサービスを作成することです。 このアプローチの主な欠点は、静的コンテンツ (特定のリビジョンを持つファイルは実際には静的コンテンツです) が、ビジネス ロジックを含む同じサーバーによって配布されることです。 代わりに、次の図を作成できます。

• サーバーはダウンロード URL を提供します。 これは、file_id + key の形式にすることができます。key は、今後 XNUMX 時間リソースにアクセスする権利を与えるミニデジタル署名です。
• このファイルは、次のオプションを備えた単純な nginx によって配布されます。
  • コンテンツのキャッシュ。 このサービスは別のサーバーに配置できるため、最新のダウンロード ファイルをすべてディスクに保存できる機能を将来に備えて残しておきます。
  • 接続作成時のキーの確認
• オプション: ストリーミング コンテンツ処理。 たとえば、サービス内のすべてのファイルを圧縮する場合、このモジュールで直接解凍を行うことができます。 結果として、IO 操作は必要な場所で実行されます。 Java のアーカイバは大量の追加メモリを簡単に割り当てますが、ビジネス ロジックを含むサービスを Rust/C++ 条件文に書き直すことも効果的ではない可能性があります。 私たちの場合、さまざまなプロセス (またはサービス) が使用されているため、ビジネス ロジックと IO 操作を非常に効果的に分離できます。

このスキームは静的コンテンツの配布とはあまり似ていません (静的パッケージ全体をどこかにアップロードするわけではないため) が、実際には、このアプローチはまさに不変データの配布に関係しています。 さらに、このスキームは、コンテンツが単に静的ではなく、不変で削除不可能なブロック (追加は可能ですが) のセットとして表すことができる他のケースにも一般化できます。

別の例として (強化のために): Jenkins/TeamCity を使用したことがある場合は、両方のソリューションが Java で書かれていることをご存知でしょう。 どちらも、ビルド オーケストレーションとコンテンツ管理の両方を処理する Java プロセスです。 特に、どちらも「サーバーからファイル/フォルダーを転送する」などのタスクがあります。 例として、アーティファクトの発行、ソース コードの転送 (エージェントがコードをリポジトリから直接ダウンロードせず、サーバーがダウンロードする場合)、ログへのアクセスがあります。 これらすべてのタスクは IO 負荷が異なります。 つまり、複雑なビジネス ロジックを担当するサーバーは、同時にそれ自体を介して大規模なデータ フローを効果的にプッシュできなければならないことがわかります。 そして最も興味深いのは、そのような操作をまったく同じスキームに従って同じ nginx に委任できることです (データ キーをリクエストに追加する必要がある点を除く)。

ただし、システムに戻ると、同様の図が表示されます。

ご覧のとおり、システムは根本的により複雑になりました。 これは、ファイルをローカルに保存する単なるミニプロセスではありません。 今、必要とされているのは、最も単純なサポートや API のバージョン管理などではありません。 したがって、すべての図を作成した後、拡張性にコストに見合う価値があるかどうかを詳細に評価することが最善です。 ただし、システムを拡張できるようにしたい場合 (さらに多くのユーザーを操作できるようにするなど)、同様のソリューションを選択する必要があります。 しかし、その結果、システムはアーキテクチャ的に負荷の増加に対応できるようになりました (ほぼすべてのコンポーネントをクローンして水平方向のスケーリングを行うことができます)。 システムを停止せずにアップデートできます（一部の操作が若干遅くなります）。

冒頭で述べたように、現在、多くのインターネット サービスの負荷が増加し始めています。 そして、それらの一部は単に正しく動作しなくなり始めました。 実際、ビジネスが利益を生むはずだったまさにその瞬間に、システムは失敗しました。 つまり、配送を延期するのではなく、顧客に「今後数か月間配送を計画してください」と提案するのではなく、システムは単に「競合他社に行くように」と指示したのです。 実際、これは生産性が低いことの代償であり、利益が最も高まるはずのときに損失が発生することになります。

まとめ

これらのアプローチはすべて以前から知られていました。 同じ VK は、画像を表示するために静的コンテンツ ホスティングのアイデアを長い間使用してきました。 多くのオンライン ゲームでは、シャーディング スキームを使用して、プレーヤーを地域に分割したり、ゲームの場所を分離したりしています (世界自体が XNUMX つの場合)。 イベント ソーシングのアプローチは電子メールで積極的に使用されています。 データが常に受信されるほとんどの取引アプリケーションは、受信したデータをフィルターできるようにするために、実際には CQRS アプローチに基づいて構築されています。 水平スケーリングは、かなり長い間多くのサービスで使用されてきました。

ただし、最も重要なことは、これらのパターンはすべて、最新のアプリケーションに非常に簡単に適用できるようになったということです (もちろん、適切であれば)。 クラウドはシャーディングと水平スケーリングをすぐに提供します。これは、異なるデータセンターに異なる専用サーバーを自分で注文するよりもはるかに簡単です。 RX などのライブラリの開発のおかげで、CQRS ははるかに簡単になりました。 10 年ほど前には、これをサポートできる Web サイトはほとんどありませんでした。 イベント ソーシングは、Apache Kafka を備えた既製のコンテナーのおかげで、セットアップが非常に簡単です。 10年前ならこれは革新だっただろうが、今では当たり前のことだ。 静的コンテンツ ホスティングも同様です。より便利なテクノロジ (詳細なドキュメントと回答の大規模なデータベースがあるという事実を含む) のおかげで、このアプローチはさらにシンプルになりました。

その結果、多くのかなり複雑なアーキテクチャ パターンの実装がはるかに簡単になりました。これは、事前に詳しく検討した方がよいことを意味します。 XNUMX 年前のアプリケーションで、実装と運用のコストが高かったために上記のソリューションの XNUMX つが放棄された場合でも、新しいアプリケーションで、またはリファクタリング後に、すでにアーキテクチャ的に拡張可能なサービスを作成できます (パフォーマンスの点で)、クライアントからの新しい要求 (個人データのローカライズなど) にすぐに対応できます。

そして最も重要なことは、単純なアプリケーションを使用している場合は、これらのアプローチを使用しないでください。 確かにそれらは美しくて興味深いものですが、ピーク時の訪問者数が 100 人であるサイトの場合は、多くの場合、古典的なモノリス (少なくとも外側は、内側のすべてをモジュールに分割できるなど) で対応できます。

出所： habr.com