分散アプリケーションの構成要素。 ゼロ近似

世界は静止していません。 進歩は新たな技術的課題を生み出します。 変化する要件に応じて、情報システムのアーキテクチャも進化する必要があります。 今日は、イベント駆動型アーキテクチャ、同時実行性、同時実行性、非同期性、そして Erlang でこれらすべてを問題なく使用する方法について説明します。

導入

設計されたシステムの規模とその要件に応じて、私たち開発者はシステム内で情報を交換する方法を選択します。 ほとんどの場合、サービスの対話を整理するには、RabbitMQ や Kafka などに基づくブローカーを使用したスキームが有効なオプションとなります。 ただし、イベントの流れ、SLA、システムの制御レベルによっては、既成のメッセージングが適さない場合もあります。 もちろん、ZeroMQ や nanomsg を使用するなど、トランスポート層とクラスターの形成を担当することで、システムを少し複雑にすることもできます。 ただし、システムが標準 Erlang クラスターの十分なスループットと機能を備えている場合、追加のエンティティを導入する問題には詳細な調査と経済的正当性が必要です。

リアクティブ分散アプリケーションのトピックは非常に広範囲に及びます。 記事の形式を維持するために、今日の議論の主題は Erlang/Elixir 上に構築された同種の環境のみです。 Erlang/OTP エコシステムを使用すると、最小限の労力でリアクティブ アーキテクチャを実装できます。 しかし、いずれの場合でも、メッセージング層が必要になります。

理論的根拠

設計は、目標と制約を定義することから始まります。 主な目標は、開発のための開発領域ではありません。 私たちは、さまざまなレベルの最新のアプリケーションを作成、そして最も重要なことに開発できる、安全でスケーラブルなツールを入手する必要があります。小規模なユーザーにサービスを提供する単一サーバーのアプリケーションから始めて、後に最大 50 のクラスターに発展させることができます。 -60 ノード、クラスター フェデレーションで終了。 したがって、主な目標は、最終システムの開発コストと所有コストを削減して利益を最大化することです。

最終的なシステムの 4 つの主な要件を強調しましょう。

• Сイベント指向。
  システムは常にイベントのフローを通過し、必要なアクションを実行する準備ができています。
• Мスケーラビリティ。
  個々のブロックは垂直方向と水平方向の両方にスケーリングできます。 システム全体が無限に水平方向に成長できる必要があります。
• О耐障害性。
  すべてのレベルとすべてのサービスは、障害から自動的に回復できる必要があります。
• Г保証された応答時間。
  時間は貴重なので、ユーザーはあまり長く待ちすぎてはいけません。

「できる小さなエンジン」についての古いおとぎ話を覚えていますか? 設計されたシステムがプロトタイプ段階を正常に終了し、進歩するためには、その基盤が最小要件を満たしている必要があります。 スモッグ.

インフラストラクチャ ツールおよびすべてのサービスの基盤としてのメッセージングには、プログラマにとっての使いやすさというもう XNUMX つのポイントが追加されます。

イベント指向

アプリケーションが単一サーバーからクラスターに成長するには、そのアーキテクチャが疎結合をサポートしている必要があります。 非同期モデルはこの要件を満たします。 この場合、送信者と受信者はメッセージの情報負荷に気を配り、システム内の送信やルーティングについては心配しません。

スケーラビリティ

スケーラビリティとシステム効率は隣り合わせです。 アプリケーション コンポーネントは、利用可能なすべてのリソースを利用できる必要があります。 容量をより効率的に利用でき、処理方法がより最適化されるほど、設備に費やす費用が削減されます。

Erlang は単一マシン内で競争の激しい環境を作り出します。 同時実行性と並列性のバランスは、Erlang VM で使用できるオペレーティング システム スレッドの数と、これらのスレッドを利用するスケジューラの数を選択することで設定できます。
Erlang プロセスは状態を共有せず、ノンブロッキング モードで動作します。 これにより、従来のブロッキングベースのアプリケーションに比べて、比較的低いレイテンシと高いスループットが実現します。 Erlang のスケジューラは CPU と IO の公平な割り当てを保証し、ブロッキングがないため、アプリケーションはピーク負荷や障害時でも応答できます。

クラスターレベルでは、廃棄の問題も存在します。 クラスター内のすべてのマシンに均等な負荷がかかり、ネットワークが過負荷にならないことが重要です。 状況を想像してみましょう。ユーザー トラフィックは受信バランサー (haproxy、nginx など) に到達し、利用可能なバックエンドのセット間で処理リクエストを可能な限り均等に分散します。 アプリケーション インフラストラクチャ内では、必要なインターフェイスを実装するサービスは最後のマイルにすぎず、最初のリクエストに応答するために他の多くのサービスをリクエストする必要があります。 内部リクエストにはルーティングとバランシングも必要です。
データ フローを効果的に管理するには、メッセージングがルーティングと負荷分散を管理するインターフェイスを開発者に提供する必要があります。 このおかげで、開発者はマイクロサービス パターン (アグリゲーター、プロキシ、チェーン、ブランチなど) を使用して、標準的な問題とめったに発生しない問題の両方を解決できるようになります。

ビジネスの観点から見ると、スケーラビリティはリスク管理ツールの XNUMX つです。 主なことは、機器を最適に使用して顧客の要求を満たすことです。

• 進化により装備の威力が上昇した場合。 ソフトウェアが不完全なためにアイドル状態になることはありません。 Erlang は垂直方向に適切に拡張でき、常にすべての CPU コアと利用可能なメモリを利用できます。
• クラウド環境では、現在または予測される負荷に応じて機器の台数を管理し、SLAを保証します。

耐障害性

「失敗は許されない」と「失敗は必ずある」という XNUMX つの公理を考えてみましょう。 ビジネスにとって、ソフトウェアの障害は金銭の損失、さらに悪いことに評判の損失を意味します。 起こり得る損失とフォールト トレラント ソフトウェアの開発コストとのバランスを考慮すると、妥協点が見つかることがよくあります。

短期的には、フォールト トレランスを組み込んだアーキテクチャにより、既製のクラスタリング ソリューションを購入するコストが節約されます。 高価ですし、バグもあります。
長期的には、フォールト トレラント アーキテクチャは、開発のすべての段階で何倍もの利益をもたらします。
コード ベース内のメッセージングにより、開発段階でシステム内のコンポーネントの相互作用を詳細に検討できます。 これにより、すべての重要なコンポーネントが障害を処理し、結果として生じるシステムは障害後に自動的に正常に戻る方法を設計上認識しているため、障害への対応と管理のタスクが簡素化されます。

応答性

障害に関係なく、アプリケーションはリクエストに応答し、SLA を満たす必要があります。 現実には、人々は待ちたくないので、企業はそれに応じて適応する必要があります。 応答性の高いアプリケーションがますます増加すると予想されます。
応答性の高いアプリケーションは、ほぼリアルタイムで動作します。 Erlang VM はソフト リアルタイム モードで動作します。 株式取引、医療、産業機器制御などの一部の分野では、ハード リアルタイム モードが重要です。
レスポンシブ システムは UX を向上させ、ビジネスに利益をもたらします。

予備結果

この記事を計画するにあたり、メッセージング ブローカーを作成し、それに基づいて複雑なシステムを構築した私の経験を共有したいと思いました。 しかし、理論的および動機付けの部分は非常に広範囲にわたることが判明しました。
記事の後半では、交換ポイントの実装の微妙な違い、メッセージング パターン、およびその応用について説明します。
XNUMX 番目の部分では、サービスの編成、ルーティング、バランスに関する一般的な問題について検討します。 システムのスケーラビリティと耐障害性の実際的な側面について話しましょう。

最初の部分の終わり

フォト @ルカブラボ.

出所： habr.com