私たちは最も目の肥えた好みのために販売を続けていますが、私たちの創造的な検索の別のテーマであるイベント駆動型アーキテクチャ（EDA）に注意を向けます。カットの下には、この革新的なパラダイムがWebアプリケーションの開発にどのように役立つかについての美しいフローチャートとストーリーがあります。
この記事では、最新のWeb開発におけるイノベーションを推進するいくつかの課題について説明します。次に、サーバーアーキテクチャを再定義することでこれらの問題に対処する、イベント駆動型アーキテクチャ（EDA）について詳しく説明します。
Webアプリケーションは、静的HTMLコンテンツがサーバーから提供されていた時代から長い道のりを歩んできました。今日、Webアプリケーションははるかに複雑になり、さまざまなフレームワーク、データセンター、およびテクノロジを使用しています。ここ数年で、IT市場の発展を決定する2つの傾向が見られます。
- アプリケーションをクラウドに転送する;
- マイクロサービスアーキテクチャの実装。
これらのアイデアは、ソフトウェアが今日どのように設計および構築されているかを大きく左右します。今日、私たちはもはやアプリケーションではなく、プラットフォームを構築していると言えます。アプリケーションが共有コンピューティングスペースを占有しなくなりました。代わりに、REST APIやリモートプロシージャコール（RPC）などの軽量通信プロトコルを使用して相互に情報を交換する必要があります。このモデルは、Facebook、Netflix、Uberなどの優れた製品につながりました。
この記事では、最新のWeb開発におけるイノベーションを推進するいくつかの課題について説明します。次に、イベント駆動型アーキテクチャ（EDA）について詳しく説明し、サーバーアーキテクチャを再定義することでこれらの課題に対処します。
現代のウェブの現在の問題
すべてのWebテクノロジーは、スムーズに実行されるように設計された、最新のマルチユーザー非同期アプリケーションが満たさなければならない課題に対処する必要があります。
可用性
現在、私たちは1つのアプリケーションではなく、数十または数百もの関連サービスを使用しており、それぞれが24時間年中無休で問題を解決する必要があります。これはどのように達成できますか？ほとんどの場合、サービスは複数のインスタンスに水平方向にスケーリングされ、複数のデータセンターに分散して、高い可用性を確保できます。この特定のサービスに対するすべての要求はルーティングされ、すべてのインスタンスに均等に分散されます。一部の展開ツールは自己修復機能を提供するため、1つのインスタンスに障害が発生した場合、その代わりに別のインスタンスが作成されます。
スケーラビリティ
スケーラビリティは、多くの点で可用性に似ています。アクセシビリティの本質は、サービスの少なくとも1つのインスタンスが稼働し、着信要求を処理する準備ができていることを確認することです。次に、スケーラビリティは主にパフォーマンスに関連しています。アプリケーションが過負荷になると、そのアプリケーションの新しいインスタンスが作成され、リクエスト数の増加に対応します。ただし、特にステートフルアプリケーションの場合、アプリケーションを垂直方向にスケーリングすることは簡単な作業ではありません。
真実の1つの源
マイクロサービスが登場する前は、これはかなり単純な作業でした。すべてのデータは1つの場所にあり、原則として、それは1つまたは別のリレーショナルデータベースでした。ただし、複数のサービスがデータベースを共有している場合、スキーマの変更やパフォーマンスの問題に関する異なるチーム間の依存関係などの問題が発生する可能性があります。通常、この問題は、サービスごとに独自のデータベースを割り当てることで解決されました。分散された真実のソースは、クリーンなアーキテクチャを維持するのに非常に役立ちますが、そのような状況では、分散トランザクションと複数のデータベースをサポートする複雑さに対処する必要があります。
同期性
典型的な要求-応答シナリオでは、クライアントはサーバーが応答するのを待ちます。応答を受信するまで、または指定された遅延が期限切れになるまで、すべてのアクションをブロックします。この動作を採用し、システム全体で実行されるコールチェーンを使用してマイクロサービスアーキテクチャに実装すると、いわゆる「マイクロサービス地獄」に簡単に陥ることがあります。それはすべて、1つのサービスを呼び出すことから始まります。それを「サービスA」と呼びましょう。しかし、その後、サービスAはサービスBを呼び出す必要があり、楽しみが始まります。この動作の問題は次のとおりです。サービス自体がブロックされたリソースに関連付けられている場合（たとえば、スレッドがハングしている場合）、遅延は指数関数的に大きくなります。サービスごとに500ミリ秒の遅延を許可し、チェーンに5つのサービス呼び出しがある場合、最初のサービスには2500ミリ秒（2.5秒）の遅延が必要であり、最後のサービスには500ミリ秒の遅延が必要です。
現代のウェブの課題
イベント駆動型アーキテクチャの概要
イベント駆動型アーキテクチャ（EDA）は、イベントの生成、検出、消費、およびそれらへの応答を容易にするソフトウェアアーキテクチャパラダイムです。
従来の3層アプリケーションでは、システムのコアはデータベースです。EDAでは、焦点はイベントとそれらがシステムをどのように流れるかに移ります。この焦点のシフトにより、アプリケーションの設計方法を完全に変更し、前述の問題を解決することができます。
これがEDAでどのように行われるかを正確に確認する前に、「イベント」とは何かを見てみましょう。イベントは、アプリケーションの状態の通知または変更を開始するアクションです。ライトがオン（通知）、サーモスタットが暖房システムをオフ（通知）、ユーザーが住所を変更（状態の変更）、友人の1人が電話番号を変更（状態の変更）しました。これらはすべてイベントですが、イベント駆動型ソリューションに追加する必要があるのはまだ事実ではありません。ビジネス関連のイベントのみがアーキテクチャに追加されると想定されています。 「ユーザーが注文する」というイベントはビジネスの観点から重要ですが、「ユーザーが注文したピザやランチを食べる」というイベントは重要ではありません。
いくつかのイベントについて考えると、それらがビジネスにとって重要であることがすぐに明らかになるものもあれば、そうでないものもあります。特に他のイベントに応じて発生するものについて。 「イベントアサルト」と呼ばれる手法は、システムを通過するイベントを識別するために使用されます。アプリケーション開発の参加者（プログラマーからビジネスロジック開発者、主題の専門家まで）が招集され、すべてのビジネスプロセスを共同でマッピングし、特定のイベントとして提示します。このようなマップの準備ができたら、作業の結果は、アプリケーションを開発するときに満たす必要のある要件の形式で作成されます。
イベントアサルト方式で記述された予約申請例
関心のあるイベントを特定し、それらを特定する方法を決定したら、このパラダイムが上記の典型的な問題をどのように解決できるかを見てみましょう。
イベントの流れは一方向です：プロデューサーからコンシューマーへ。この状況をREST呼び出しと比較してください。イベントプロデューサーは原則としてコンシューマーからの応答を期待しませんが、REST呼び出しの場合は常に応答があります。応答がないということは、何か他のことが起こるまでコードの実行をブロックする必要がないことを意味します。この場合、イベントは本質的に非同期になり、遅延で行き詰まるリスクを完全に排除します。
イベントはアクションの結果として発生するため、ターゲットシステムはありません。サービスAがサービスBでイベントをトリガーするとは言えません。ただし、サービスBはサービスAによって生成されたイベントに関心があると言えます。
確かに、このシステムには他の「利害関係者」、たとえばサービスCまたはDが存在する可能性があります。特定のシステムで開始されたイベントがすべてに到達することを確認するにはどうすればよいですか。「興味のある」サービス？通常、このようなシステムはメッセージブローカーを使用して解決されます。ブローカーは、イベントエミッター（イベントを生成したアプリケーション）とイベントコンシューマーの間の仲介役として機能する単なるアプリケーションです。したがって、アクセシビリティの問題に対処しながら、アプリケーションを互いにきちんと切り離すことができます。、この投稿で前述しました。アプリケーションが現在利用できない場合、オンラインに戻ると、イベントの消費と処理が開始され、利用できない期間中に発生したすべてのイベントが補われます。
データウェアハウスはどうですか？イベントをデータベースに保存できますか、それともデータベースの代わりに何か他のものが必要ですか？確かに、イベントはデータベースに保存できますが、この場合、イベントの「イベント」の本質は失われます。イベントが発生すると、それを修正することはできなくなります。したがって、イベントは本質的に不変です。次に、データベースは変更可能です。データベースにデータを入力した後、変更することができます。
イベントログにイベントを保存することをお勧めします。イベントログは一元化されたものにすぎませんデータウェアハウス。各イベントは、変更不可能な一連のレコード、いわゆる「ログ」として記録されます。ログは、新しいイベントがリストの最後に追加されるログと比較できます。すべてのログイベントを最初から現在まで再生することで、いつでも最新の状態を再現できます。
したがって、スケーラビリティを除くすべての問題をカバーしました。イベント駆動型サービスは、常に複数のインスタンスに展開されるように設計されています。状態自体はイベントログに保存されるため、サービス自体はステートレスになり、対象のサービスを外科的に正確にスケーリングできます。
この原則の唯一の例外は、具体化されたビューを作成するように設計されたサービスです。..。本質的に、マテリアライズドビューは、特定の時点でのイベントログを説明する状態です。このアプローチは、データのクエリを容易にするために使用されます。スケーリングの問題に戻ると、マテリアライズドビューは、テーブルのような形をしたイベントの単なる集約ビューです。しかし、これらのテーブルはどこに保存しますか？ほとんどの場合、このような集計はメモリ内に表示されますが、同時に、サービスは自動的にステートフルなサービスに変わります。迅速で簡単な解決策は、マテリアライズドビューを作成するすべてのサービスにローカルデータベースを提供することです。このようにして、状態はデータベースに保存され、サービスはステートレスで実行されます。
イベント駆動型アーキテクチャは15年以上前から存在していますが、最近深刻な人気を得たばかりであり、これは偶然ではありません。ほとんどの企業は、激しい需要を伴う「デジタル変革」の段階を経ています。これらの要件は複雑であるため、エンジニアはソフトウェア設計への新しいアプローチを習得する必要があります。これは、特に、サービスの相互結合を弱め、サービスの保守コストを削減することを意味します。EDAは、これらの問題に対する1つの可能な解決策ですが、それだけではありません。また、すべての問題が解決されることを期待するのではなく、EDAに切り替えるだけです。一部の機能では、堅牢な旧式のREST APIが必要な場合や、データベースに情報を保存する必要がある場合があります。自分に最適なものを選択して、適切に設計してください。