6つの最新のソフトウェアアーキテクチャ設計パターン

こんにちは、Habr！TanmayDeshpandeによる記事「ソフトウェアプロフェッショナル向けの現代のアーキテクチャ設計パターン」の翻訳を紹介します。





多くの最新のアプリケーションは、企業全体、場合によってはインターネット全体で構築する必要があります。各アプリケーションは、スケーラビリティ、可用性、セキュリティ、信頼性、および復元力の要件を満たす必要があります。



この記事では、上記の機能を簡単に実現できるいくつかの設計パターンを紹介します。各パターン、クラウドでのこのパターンの使用方法、使用する場合と使用しない場合について説明します。

これらのパターンのいくつかはそれほど新しいものではありませんが、今日のインターネットクラウドの世界では非常に役立ちます。



この記事で説明するパターンのリストは次のとおりです。

1. サーキットブレーカー
2. コマンドとクエリの責任の分離（CQRS）
3. イベントソーシング
4. サイドカー
5. フロントエンドのバックエンド
6. ストラングラー

それでは始めましょう。

1.サーキットブレーカー

分散システムは、障害を念頭に置いて設計する必要があります。今日、世界にはマイクロサービスがあり、これらのサービスは主に他のリモートサービスに依存しています。これらのリモートサービスは、ネットワーク、アプリケーションのダウンロードなどのさまざまな理由で時間内に応答しない場合があります。ほとんどの場合、再試行を実装することで問題を解決できるはずです。



ただし、サービスの劣化やサービス自体の完全な障害などの深刻な問題が発生する場合があります。このような場合、再試行を続けるのは意味がありません。この場合、回路ブレーカーモデルが役立ちます。







上の図は、回路ブレーカー回路の実装を示しています。サービス1は、サービス2の呼び出しに再試行ではなく継続的な障害/タイムアウトがあることに気付いた場合、サービス1はサービス2への呼び出しを切断し、障害が発生した場合に応答を返します。



以下のような人気のあるオープンソースのライブラリがありますNetflixのHystrix

またはReselience4J非常に簡単にこのパターンを実装するために使用することができます。



APIゲートウェイまたはEnvoyの ようなプロキシを使用している場合、これはプロキシレベル自体で実現できます。注意：





チェーンが開いているときに十分なログと警告を実装して、この間に受信した要求を追跡し、運用チームがこれを認識していることが非常に重要です。



ハーフサーキットブレーカーを実装して、障害のあるサービスの顧客にサービスを提供し続けることもできます。



このパターンをいつ使用するか

• サービスが別のリモートサービスに依存している場合、および一部のシナリオでは、失敗する可能性があります。
• サービスに非常に強い依存関係がある場合（マスターデータサービスなど）。

このパターンを使用しない場合

• ローカルの依存関係を処理する場合、回路ブレーカーによってオーバーヘッドが発生する可能性があります。

2. Command and Query Responsibility Segregation (CQRS) ( (CQRS))

CQRSは、最新のデータウェアハウスアプリケーションにとって非常に便利なモデルです。これは、データストア内の読み取り（クエリ）操作と書き込み/更新（コマンド）操作を分離するという原則に基づいています。



MySQL / PostgreSQLなどのデータベースにデータを保存する必要があるアプリケーションを構築しているとしましょう。ご存知のとおり、ストレージにデータを書き込む場合、操作は検証、モデリング、永続化などのいくつかの段階を経る必要があるため、通常の書き込み/更新操作は単純な読み取り操作よりも時間がかかります。



同じデータストアを使用して読み取り操作と書き込み操作を同時に大規模に実行すると、パフォーマンスの問題が発生する可能性があります。

このような場合、CQRSテンプレートが役立ちます。 CQRSパターンは、読み取り操作と書き込み操作に異なるデータモデルを使用することを提案しています。一部のバリエーションでは、これらのモデルに個別のデータストアを使用することも提案しています。







注：最近のほとんどのPaaSデータベースに は、データストアの読み取り可能なレプリカ（Google Cloud SQL、Azure SQL DB、Amazon RDS

など）を作成する機能があり、データの複製をはるかに簡単に実現できます。

ローカルデータベースを扱っている場合、多くのエンタープライズデータベースもこの機能を提供します。



注：最近の一部の人々は、MongoDBやElasticsearchなどの高速でパフォーマンスの高いNoSQLデータベースとして読み取り可能なレプリカを実装することも好みます。



このパターンをいつ使用するか

• 大量の読み取りと書き込みが予想されるアプリケーションのスケーリングを検討している場合
• 読み取り操作と書き込み操作を別々に設定する場合。
• 読み取りが実際に近いか、最終的には順次である場合。

このパターンを使用しない場合

• 一度に大量の読み取りと書き込みを期待しない通常のCRUDアプリケーションを構築している場合。

3.イベントソーシング

イベントソースは、一連のドメインイベントがログとして保存され、集約されたログビューがアプリケーションの現在の状態を示す興味深い設計パターンです。



このパターンは、データストレージのロックを行う余裕がなく、監査とイベント履歴を維持する必要があるシステム（ホテル、会議、座席などのアプリケーションなど）で一般的に使用されます。







ユーザーが予約または予約をキャンセルすることが期待されるホテルの部屋の予約システムを考えます。ここでは、予約とキャンセルを一連のイベントとして保存する必要があります。利用可能な部屋は、イベントログを確認することにより、各予約の前に要約で表示されます。



注意：ほとんどのクラウドサービスプロバイダーは、Google Pub / Sub、Azure Service Bus、AWS SQSなどのメッセージングサービスをサポートしています。これらのサービスを強力な一貫性のあるデータストアと組み合わせて、このスキームを実装できます。



このパターンを使用する場合

• 通常のCRUD操作が要件を満たすのに十分でない場合
• 通常、バス、電車、会議、映画館などの座席予約システムに適しています。-またはカートトランザクション、支払いなどのアクティビティで構成されるeコマースシステムの場合。
• アプリケーションの現在および過去の状態を作成するために、強力な監査とイベントの再生が必要な場合。

このパターンを使用しない場合

• 通常のCRUD操作でユーザーのニーズを満たすのに十分な場合。

4.サイドカー（サイドカーデザインパターン）

サイドカーパターンは、マイクロサービスの出現で人気を博しました。このスキームでは、アプリケーションコンポーネントは別のプロセスまたはコンテナにデプロイされます。これは、抽象化とカプセル化を実現するのに役立ちます。



Envoy Proxyは、最も人気のあるサイドカープロキシサーバーの1つであり、広く使用されています。サイドマシンを使用して、ネットワーキング、可観測性、セキュリティなどの一般的な機能を分離することにより、アプリケーションの主な機能を分離するのに役立ちます。







このタイプのサイドカーは、抽象的なL4 / L7タイプの通信に役立ちます。Envoy Proxiesなどのサイドカーは、相互TLSを実装することで、より高いセキュリティを実現するのにも役立ちます。

これをサービスグリッドと組み合わせて使用​​すると、異なるマイクロサービス間の接続性とセキュリティを向上させることができます。これについては、前回の記事で詳しく読むことができます。



このパターンをいつ使用するか

• 製品ポートフォリオで多数の異種マイクロサービスを扱っている場合。
• 新しい時代の相互運用性とセキュリティの課題を処理できない傾向があるレガシーアプリケーションを扱う場合。

このパターンを使用しない場合

• 相互に通信する必要のある限られた数のサービスを扱っている場合。
• サイドホイールチェアの展開が不経済または操作に不便である可能性がある小さなアプリケーション

5.バックエンドフォーフロント（BFF）

通常の製品開発サイクルでは、バックエンドエンジニアがデータウェアハウスと対話するサービスの作成を担当し、フロントエンドエンジニアがユーザーインターフェイスの作成を担当します。最近のアプリは、モバイルとデスクトップの両方を念頭に置いて構築する必要があります。



モバイルデバイスとデスクトップデバイスのギャップはハードウェアの観点から近づいていますが、接続と使用はモバイルデバイスにとって依然として課題です。



このようなシナリオでは、BFFテンプレートが非常に便利になります。ここでは、特定のフロントエンドの内部サービスを構築/構成する必要があります。







モバイルクライアントのパフォーマンスを最適化するために、軽量でページ分割された応答で応答する別個のバックエンドサービスを構築することをお勧めします。

このパターンを使用してさまざまなサービスを集約し、バックエンドとフロントエンド間のデータ通信を減らすこともできます。



注：最近、APIゲートウェイを使用している場合、BFFパターンはゲートウェイ自体に簡単に実装でき、個別のサービスを提供する必要はありません。



このパターンをいつ使用するか

• デスクトップやモバイルクライアントなど、さまざまなクライアントに製品/サービスを提供したい場合。
• 特定のタイプの顧客向けに応答を最適化したい場合。
• モバイルクライアントとさまざまなサービス間のチャットを減らしたい場合。

• , .
• , .

6. Strangler ( )

アプリケーションの最新化に向かっている組織で働いている場合は、Stranglerデザインパターンが必須です。Stranglerパターンは、レガシーアプリケーションと新しいアプリケーションの上にファサードオーバーレイを構築することを提唱し、消費者が物事を客観的に見ることができるようにします。







このパターンは、アプリケーションの古い部分と新しい部分の間の移行アクティビティからクライアントを分離します。



注：一般的なIT組織では、あるERPシステムから別のERPシステムに移行する場合、このタイプのスキーマは非常に役立ちます。ゲートウェイAPIを使用している場合は、プロキシゲートウェイ自体にこれを実装する方が簡単です。



移行の最後にアドイン（ファサード）を保持するか、削除するかを決定する必要があります。



このパターンをいつ使用するか

• ERP移行など、複雑で依存度の高いアプリケーションを移行またはアップグレードする場合

このパターンを使用しない場合

• 移行が簡単で、直接交換するのが最善のオプションである場合。