[レポート] Integration patterns for distributed systems #API315 #AWSreInvent

セッションの概要

Today's applications are interconnected: they expose APIs, publish events, call third-party services, and externalize states. They must therefore address the fundamental challenges of distributed systems, such as out-of-order delivery, retries, idempotence, and partial failures. To address these challenges, architects must carefully evaluate integration options while considering how to manage complex system interactions. In this session, learn about common design trade-offs for distributed systems and how to navigate them with design patterns, illustrated by examples.

( 機械翻訳 )
今日のアプリケーションは相互接続されています。API を公開し、イベントを発行し、サードパーティのサービスを呼び出し、状態を外部化します。そのため、順序が乱れた配信、リトライ、冪等性、部分的な障害といった分散システムの根本的な課題に対処する必要があります。これらの課題に対処するため、アーキテクトは複雑なシステム間の相互作用をどのように管理するかを考慮しながら、統合オプションを慎重に評価する必要があります。このセッションでは、分散システムにおける一般的な設計のトレードオフと、実例で説明されるデザインパターンを用いてそれらをどのように乗り越えるかについて学びます。

• Type: Breakout session
• Level: 300 – Advanced
• Features: Lecture-style
• Topic: Application Integration
• Area of Interest: Event-Driven Architecture, Serverless
• Role: Developer / Engineer, IT Executive, Solution / Systems Architect
• Services: Amazon EventBridge, Amazon Simple Notification Service (Amazon SNS), Amazon Simple Queue Service (Amazon SQS)

システムの統合

現代のシステムは異なるアプリケーション同士の接続が当たり前となっています。
例えば 2 つのシステムを接続しようとしたとき、私たちはあらゆることを考慮しなければなりません。
データフォーマットはどうするか、同期か非同期か、エラー時のリトライはどうするか、など分散システム特有の課題が存在します。

「すべてのアーキテクチャ決定にはトレードオフが存在する」という前提のもと、以下の 4 つの柱を中心に設計パターンが紹介されました。

この中から、最初の原則である Coupling and its dimensions について詳しくレポートにしてみようと思います。

Coupling and its dimensions

セッションでは、結合を構成する要素として 4 つの次元が定義されました。イメージしやすい例として、同期的な API で説明されました。

• Location (場所)
  • Booking サービスは、Payment サービスの場所 (IP アドレスや DNS 名) を知っている必要がある
• Format (形式)
  • Payment サービスが決定した通信形式 (JSON、gRPC、XML など) に、Booking サービス側が合わせる必要がある
• Temporal (時間)
  • 可用性 (Availability): Payment サービスがダウンしていると、Booking サービスも機能しない
  • 処理時間 (Processing): Payment サービスの処理が終わるまで、Booking サービスは待機する必要がある
• Domain
  • Booking サービスは、「支払いを行う」という Payment サービスのドメイン知識を理解しておく必要がある

ここの概念、とても重要なので理解した上で次に進みましょう。

非同期 API にする場合

レスポンスを待たずに 202 Accepted だけを返す場合、処理時間の結合は解消されます。

しかし、相手がダウンしていたら受け付けられないため、可用性の結合 (Temporal) は残ります。もちろん Location や Format もそのままです。

メッセージキューを導入する場合

キューを間に挟むと、ガラッと変わります。

• Temporal: 相手がダウンしていてもメッセージを送れるため、可用性の結合が解消される
• Location / Format: 背後にあるサービスの場所や形式を知る必要はなくなるが、キューの場所と形式に結合することになる

しかし、Domain の結合は全く解決していません。
なぜなら、「支払い」というメッセージを送る場合、送信側は依然として受信側が何をするかを知っており、具体的に相手に指示を出す必要があるからです。

Pub/Sub を導入する場合

ここで Domain 結合の逆転が発生します。

送信側は受信側を考慮せずに「予約の完了」というイベントだけを送信します。受信側は「予約イベント」を自ら Subscribe します。

Pub/Sub パターンを使うことで、送信側は受信側のドメイン知識から解放されます。これが疎結合の正体の一つであると説明されました。

その他にも

その他の柱においても、Push vs Pull の比較をされていたり、

マルチテナント構成における Noisy Neighbor 問題への解決策の 1 つとしてシャッフルシャーディングが紹介されていたり、

学びと気付きの多すぎるセッションとなりました。

おわりに

いろいろなアーキテクチャパターンが存在するものの、万病に効く特効薬はない、ということを改めて実感しました。
と同時に、結合を完全になくすことを目標にしてアーキテクチャを考えるのではなく、プロデューサー側とコンシューマー側のどちらに結合を寄せるかなどを検討していくことが重要です。