リアクティブマニフェスト

近年、アプリケーションの要件は大幅に変更されました。 数十台のサーバー、数秒での応答時間、数時間続くオフラインメンテナンス、ギガバイトのデータ-これらはほんの数年前の大規模なアプリケーションでした。 今日、アプリケーションは、単純な携帯電話から数千のプロセッサーのクラスターまで、完全に動作します。 ユーザーは、ミリ秒の応答時間と100％の稼働時間を期待していますが、データはペタバイトにまで成長しています。



当初、このニッチはGoogleやTwitterなどの大規模な革新的なインターネット企業に占有されていましたが、このようなアプリケーション要件は業界の多くの分野で出現し始めました。 金融および通信会社は、新しい要件を満たすために新しい慣行を導入した最初の企業でしたが、現在は残りの企業が撤回されています。



新しい要件には新しいテクノロジーが必要です。 以前の決定は、管理対象サーバーとコンテナに焦点を合わせていました。 スケーリングは、クーラーサーバーの購入とマルチスレッドの使用により達成されました。 新しいサーバーを追加するには、複雑で非効率的で高価な専用ソリューションを使用する必要がありました。



ただし、進歩は止まりません。 変化する要件を満たすために、アプリケーションアーキテクチャが進化しました。 このアーキテクチャに基づいて開発されたアプリケーションは、 リアクティブアプリケーションと呼ばれます 。 このアーキテクチャにより、プログラマーはイベント指向、スケーラブル、フォールトトレラントで応答性の高いアプリケーションを作成できます。これは、スケーラブルでフォールトトレラントなスタックに基づいて良好な応答時間を提供し、マルチコアおよびクラウドアーキテクチャに簡単に展開できるリアルタイムアプリケーションです。 これらの機能は、反応性にとって重要です。

リアクティブアプリケーション

Merriam Websterディクショナリは、リアクティブを「外部イベントに応答する準備ができている」と定義します。これは、コンポーネントが常にアクティブであり、常にメッセージを受信する準備ができていることを意味します。 この定義は、リアクティブアプリケーションの本質を明らかにし、次のようなシステムに焦点を当てています。

• イベントに反応する
  
  イベントオリエンテーションとは、次の性質を意味します
• 増加した負荷に対応する
  
  スケーラビリティに焦点を当て、公共リソースへの競争的アクセスを最小限に抑えます。
• 失敗に対応する
  
  フェイルセーフシステムは、すべてのレベルで回復する機能を備えて構築されています。
• ユーザーに応答する
  
  負荷に依存しない応答時間の保証

これらの特性はそれぞれ、リアクティブアプリケーションにとって不可欠です。 それらはすべて互いに依存していますが、標準のマルチレベルアーキテクチャの層としてではありません。 それどころか、テクノロジースタック全体に適用可能なプロパティについて説明しています。







次に、これら4つの特性のそれぞれを詳しく調べ、それらが互いにどのように関係しているかを確認します。

イベントオリエンテーション

なぜこれが重要なのか

非同期モデルを使用するアプリケーションは、純粋な同期呼び出しに基づくアプリケーションよりもはるかに少ない接続を提供します。 送信者と受信者は、イベントがシステム内でどのように配信されるかの詳細を見なくても実装できます。これにより、インターフェースは伝送の内容に集中できます。 これにより、実装の拡張、変更、および保守が容易になり、柔軟性が向上し、サポートのコストが削減されます。



非同期相互作用の受信者はメッセージを受信するまで非アクティブであるため、この方法ではリソースを効率的に使用でき、多くの受信者が同じハードウェアストリームで作業できるようになります。 したがって、非ブロッキングアプリケーションは、ブロッキング同期および通信プリミティブに基づく従来のアプリケーションよりもレイテンシが低く 、 スループットが高い場合があります 。 これにより、トランザクションコストが削減され、プロセッサリソースの使用率が向上し、エンドユーザーの満足度が向上します。

主要な構成要素

イベント指向のアプリケーションでは、コンポーネントはメッセージを送受信することで相互作用します -事実を説明する個別の情報です。 これらのメッセージは、非同期および非ブロッキングモードで送受信されます。 イベント指向システムは、 pullやpollよりもモデルをプッシュする傾向があります。 つまり 絶えずデータを要求または待機してリソースを浪費するのではなく、データが利用可能になったときにデータをコンシューマにプッシュします。

• 非同期メッセージングとは、その性質上、アプリケーションに高度な競争があり、マルチコアアーキテクチャを変更することなく動作できることを意味します。 任意のCPUコアが任意のメッセージを処理できるため、並列化機能が向上します。
• ノンブロッキングとは、障害やピーク負荷の状態でも、アプリケーションが常に応答するように動作し続ける能力を意味します。 これを行うには、CPU、メモリ、ネットワークなど、応答性を確保するために必要なすべてのリソースを独占しないでください。 これにより、待ち時間が短くなり、帯域幅が広がり、 スケーラビリティが向上します。

従来のサーバーアーキテクチャは、単一のスレッドでパブリックな可変状態とブロッキング操作を使用します。 これにより、システムのスケーリングが難しくなります。 パブリックな可変状態には同期が必要です。これにより、複雑さと非決定性が追加され、コードの理解と保守が難しくなります。 スレッドをスリープモードに切り替えると、限られたリソースが消費され、目覚めは高価です。



イベントの生成とその処理を分離することで、プラットフォームがフロー間の同期とイベントのディスパッチの詳細を処理できるようにします。一方で、より高いレベルの抽象化とビジネスロジックに専念します。 スレッドやロックなどの低レベルのプリミティブを掘り下げる代わりに、イベントの送信元と送信元、コンポーネントの相互作用方法について考えます。



イベント指向システムは、コンポーネントとサブシステム間の接続性が不十分です。 このような接続は、後で説明するように、スケーラビリティとフォールトトレランスに必要な条件の1つです。 コンポーネント間の複雑で強力な依存関係がなければ、システムを拡張するには最小限の労力しか必要ありません。



アプリケーションに高いパフォーマンスと優れたスケーラビリティが必要な場合、ボトルネックが発生する可能性のある場所を予測することは困難です。 したがって、ソリューション全体が非同期で非ブロッキングであることが非常に重要です。 これは、典型的なアプリケーションでは、アーキテクチャが完全にイベント指向であり、グラフィカルインターフェイス（ブラウザー、RESTなど）を介したユーザーリクエストから始まり、Webレイヤーでリクエストを処理し、サービス、キャッシュ、データベースで終わることを意味します。 これらのレイヤーの少なくとも1つがこの要件を満たしていない場合-データベースでブロッククエリを作成し、パブリックな可変状態を使用し、高価な同期操作を呼び出す-スタック全体が消滅し、ユーザーは遅延の増加とスケーラビリティの低下のために苦しみます。



アプリケーションは、上から下にリアクティブでなければなりません。



チェーン内の弱いリンクを排除する必要性は、アムダールの法則によってよく説明されています。



並列化によるプログラムの高速化は、プログラムのシーケンシャル部分に制限されます。 たとえば、計算量の95％を並列化できる場合、使用されるプロセッサの数に関係なく、理論上の最大加速度は20を超えることはできません。

拡張性

なぜこれが重要なのか

スケーラブルという言葉は、Merriam Webster辞書で「簡単に拡張または近代化できる」と定義されています。 スケーラブルなアプリケーションは、スケールアップすることができます。 これは、アプリケーションの弾力性、つまりシステムが要求に応じて伸縮（ノードの追加または削除）できるようにするプロパティを提供することで実現されます。 さらに、このアーキテクチャにより、アプリケーションを再設計または再作成する必要なく、拡張または縮小（より多くのプロセッサまたはより少ないプロセッサに展開）することができます。 弾力性により、クラウドで機能するためのコストが最小限に抑えられますが、実際に使用した分に対してのみ支払いが行われます。



スケーラビリティはリスクの管理にも役立ちます。機器が少なすぎると顧客の不満や損失につながり、多すぎると（スタッフとともに）非アクティブになり、不要なコストが発生します。 別のスケーラブルなアプリケーションは、機器が利用可能な場合の状況のリスクを低減しますが、アプリケーションはそれを使用できません：今後10年間で、数千ではないにしても数百のハードウェアスレッドを備えたプロセッサがあり、その潜在的な使用には顕微鏡レベルでのスケーラビリティが必要になります。

主要な構成要素

非同期メッセージングに基づくイベントベースのシステムは、スケーラビリティの基礎です。 コンポーネントとサブシステムの弱い接続性と場所の独立性により、同じセマンティクスで同じソフトウェアモデル内にとどまりながら、多くのノードにシステムを展開できます。 新しいノードが追加されると、システムのスループットが増加します。 実装に関しては、クラスターまたはデータセンター内のより多くのコアまたはより多くのノードにシステムを展開しても違いはありません。 アプリケーショントポロジは、システムの負荷を監視する構成の問題および/または適応ランタイムアルゴリズムになります。 これは、 場所の透過性と呼ばれるものです。



透明な分散コンピューティング、分散オブジェクト、またはRPC通信を発明することではなく、その目標はすでに試みられており、このアイデアは失敗したことを理解することが重要です。 代わりに、非同期メッセージメカニズムを介してソフトウェアモデルで直接表現することにより、ネットワークを採用する必要があります 。 真のスケーラビリティは、当然、分散コンピューティングとノード間の相互作用に依存します。つまり、本質的に信頼性の低いネットワークをバイパスします。 したがって、プログラムモデルで例外的な状況の制限、トレードオフ、シナリオを明示的に考慮することは、物事を「単純化」しようとする漏れやすい抽象化のスクリーンの背後に隠すのではなく重要です。 その結果、コンセンサスに到達するメカニズムや信頼性の高いメッセージングインターフェイスなど、分散環境で発生する可能性のある典型的な問題を解決するためのビルディングブロックを含むソフトウェアツールを提供することも同様に重要です。

耐障害性

なぜこれが重要なのか

アプリケーション障害は、ビジネスに発生する可能性のある最も有害なものの1つです。 通常、これはサービスが単に停止し、利益の流れにギャップを残すという事実につながります。 長い目で見れば、これは顧客の不満や評判の低下につながり、ビジネスをさらに深刻に傷つける可能性があります。 驚くべきことに、アプリケーションの復元力の要件は、一般的に無視されるか、アドホック技術者によって対処されます。 これは、多くの場合、不正確で粗雑なツールを使用して、誤った詳細レベルで問題に対処することを意味します。 一般的な解決策は、クラッシュリカバリでアプリケーションサーバークラスタリングを使用することです。 残念ながら、このような既製のソリューションは非常に高価であり、さらに危険です。クラスター全体を潜在的に「カスケード」する可能性があります。 その理由は、小さなコンポーネントの相互作用のレベルで詳細に解決する必要がありますが、障害管理の問題は非常に小さなスケールのマップで解決されているためです。



リアクティブアプリケーションでは、フォールトトレランスは後で使用できるようになりませんが、最初からアーキテクチャの一部です。 プログラムモデルのファーストクラスオブジェクトとしての障害に対する態度は、それらに対応し、それらを管理するタスクを容易にします。これにより、アプリケーションは障害に耐えられ、システムは動作中に自身を「修復」および「修復」できます。 問題は間違ったレベルで解決されないため、例外的な状況を処理する従来の方法ではこれを達成できません。例外が発生した場所ですぐに処理するか、アプリケーション全体の回復手順を開始します。

主要な構成要素

障害を管理するには、障害を他の正常なコンポーネントに拡散しないように隔離し、障害が発生する可能性のあるコンテキスト外の安全な場所から監視する方法が必要です。 思い浮かぶ1つの方法は、システムのコンパートメントを分割する隔壁で、コンパートメントの1つがフラッディング（失敗）した場合に、他のコンパートメントに影響しないようにすることです。 これにより、連鎖障害の古典的な問題が回避され、問題を個別に解決できます。







スケーラビリティを提供するイベント駆動型モデルは、フォールトトレランスの問題を解決するために必要なプリミティブも提供します。 イベント駆動型モデルの弱い接続性により、完全に分離されたコンポーネントが提供されます。障害は必要な詳細とともにメッセージにカプセル化され、他のコンポーネントに転送されます。



このアプローチにより、次のようなシステムが作成されます。

• エラー処理とは別に、ビジネスロジックはクリーンなままです。
• 障害は明示的にモデル化されるため、区分化、監視、制御、および構成は宣言的に定義されます。
• システムはそれ自体を「修復」し、自動的に回復できます。

何よりも、コンパートメントが、問題が適切なアクションを実行するのに十分なパワーを持つレベルにまで上昇する大企業のように、階層的な方法で編成されている場合。



このモデルの威力は、純粋にイベント指向であるということです。リアクティブコンポーネントと非同期イベントに基づいているため、 ロケーションの透過性があります。 実際には、これは、そのセマンティクスがローカルサーバーで動作するか、分散環境で動作するかに依存しないことを意味します。

応答性

なぜこれが重要なのか

応答性は、Merriam-Webster辞書で「迅速に応答する、または適切に応答する」と定義されています。 以下では、この一般的な意味でこの単語を使用し、 レスポンシブWebデザインとCSS メディアクエリおよび進歩的な改善を混同しないことに注意してください。



レスポンシブアプリケーションはリアルタイムアプリケーションであり、魅力的で機能が豊富で、共有を提供します。 応答性と双方向性により、顧客とのオープンで継続的な対話が維持されます。 これにより、クライアントの生産性が向上し、問題を解決してタスクを完了するための一貫性と即応性がいつでも得られます。 そのような例の1つに、リアルタイムの共同編集をサポートするGoogleドキュメントがあります。これにより、ユーザーは互いの編集を直接見ることができます。



アプリケーションは、障害が発生した場合でも、タイムリーにイベントに応答する必要があります。 アプリケーションが妥当な時間内に応答しない場合（レイテンシーとも呼ばれます）、実際には利用できないため、 フォールトトレラントとは見なされません。



武器や医薬品に関連するアプリケーションなど、一部のアプリケーションの厳しいリアルタイムフレームワーク内にとどまらないことは、完全なシステム障害に相当します。 すべてのアプリケーションにこのような厳しい要件があるわけではありません。 多くのアプリケーションは、一時的な要件を満たせなくなるとすぐに役に立たなくなります。たとえば、取引操作を実行するアプリケーションは、時間通りに応答する時間がなければ現在のトランザクションを失う可能性があります。



オンライン小売店などのより一般的なアプリケーションは、応答時間が長くなると収益を失います。 ユーザーはレスポンシブアプリケーションとより集中的にやり取りし、大量の購入につながります。

主要な構成要素

リアクティブアプリケーションは、監視可能なモデル、イベントフロー、および状態クライアントを使用します。



観察されたモデルにより、他のシステムは状態が変化したときにイベントを受信できます。 これにより、ユーザーとシステム間のリアルタイム通信が提供されます。 たとえば、複数のユーザーが同じモデルで同時に作業している場合、変更をリアクティブに同期することができ、モデルをロックする必要がなくなります。



イベントのストリームは、このような関係が構築される基本的な抽象概念を形成します。 それらをリアクティブに保つことにより、ブロックを回避し、変換と通信が非同期でブロックされないようにします。



負荷に関係なく、イベントへの応答時間がO（1）または少なくともO（log n）を超えないようにするために、リアクティブアプリケーションはアルゴリズムの順序を知っている必要があります。 スケーリング係数が含まれる場合がありますが、顧客、セッション、製品または取引の数に依存するべきではありません。



遅延を負荷プロファイルに依存しないようにするための戦略を次に示します。

• 爆発的なトラフィックの場合、リアクティブアプリケーションは、基になるリソースの詳細を理解して考慮しながらバッチ処理を使用して、I / Oや競合データ交換などの高価な操作のコストを償却する必要があります。
• キューは、フローの強度を考慮して制限する必要があります。応答時間のこれらの要件を持つキューの長さは、 リトルの法則に従って決定する必要があります。
• システムは常に監視状態にあり、十分な安全マージンが必要です。
• 障害が発生すると、 サーキットブレーカーがアクティブになり、バックアップ処理戦略が開始されます。

例として、リッチクライアント（ブラウザ、モバイルアプリケーション）を備えたレスポンシブWebアプリケーションを考えて、ユーザーに高品質のインタラクションエクスペリエンスを提供します。 このアプリケーションはロジックを実行し、クライアント側で状態を保存します。このモデルでは、データがリアルタイムで変更されたときに、観察されたモデルがユーザーインターフェイスを更新するメカニズムを提供します。 WebSocketやサーバー送信イベントなどの技術により、ユーザーインターフェイスはイベントのフローに直接接続できるため、システム全体がイベント指向になり、バックエンドレイヤーからクライアントで終わります。 これにより、リアクティブアプリケーションは、非同期および非ブロッキングデータ転送を通じてイベントをブラウザおよびモバイルアプリケーションにプッシュし、スケーラビリティとフォールトトレランスを維持できます。



ここで、反応性の4つの「クジラ」であるイベント指向 、 スケーラビリティ 、 フォールトトレランス、および応答性が相互に接続され、単一の全体を形成する方法が明らかになります。

おわりに

リアクティブアプリケーションは、ソフトウェアシステムの開発における現代の問題を解決するためのバランスの取れたアプローチです。 これらは、 イベント指向およびメッセージング指向のフレームワーク上に構築され、 スケーラビリティと復元力のためのツールを提供します。 さらに、リッチでレスポンシブなユーザーインタラクションインターフェイスをサポートしています。 数が急速に増加しているシステムは、近い将来このマニフェストに従うと予想されます。

マニフェストの下で購読する