[> Home](https://github.com/oreilly-japan/communicationpatterns-jp) | [>特典コンテンツ](https://github.com/oreilly-japan/communicationpatterns-jp/blob/master/freebies.md) # ADR-044 イベント駆動型分散アーキテクチャの使用 ## ステータス 決定済み、2023-10-04 [ADR-031 サーバーレス関数の使用](https://link-to-superseded-ADR)を置き換える ## コンテキスト Polyglot Mediaシステムは現在、主にサーバーレス関数からなる分散システムである。モノリシックから分散型サーバーレスアーキテクチャへ移行したのは、ライブシステムの応答性の問題や、機能とバグ修正がコード化され本番環境にデプロイされるまでの長いリードタイムに対処するためだった。 しかし、サーバーレスアーキテクチャでは、応答性やメンテナンス性の問題が必要なレベルで解決されず、機能が他の多くの機能と強く結びついている。 応答性と市場投入までの時間の問題を解決する方法を見つける必要がある。 ## 評価基準 [ADR-032 アーキテクチャ特性の選択](https://link-to-ADR-002) を参照 - _応答性_：顧客はシステムの応答性に不満を感じており、これに対処する必要がある。これは最も重要な基準とされている。 - _メンテナンス性_：サーバーレス関数により、バグ修正や新機能の市場投入までの時間は改善されたが、必要なレベルには達していない。 - _デプロイ容易性_：メンテナンス性とともに、デプロイ容易性もバグ修正や新機能の市場投入までの時間を改善するために重要だ。 - _スケーラビリティ_：顧客からの応答性に関する苦情の多くはピーク時に集中しているため、システムはユーザーの最大ピーク数を影響を与えずに処理できる必要がある。 ## 選択肢 ### 1. マイクロサービス | 基準 | スコア | 根拠 | | --------------- | ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 応答性 | ★★★☆☆ 3/5 | [本質的に高パフォーマンスではない](https://link-to-reference-info)が、ボトルネックでの最適化（例：スケーリング）が可能 | | メンテナンス性 | ★★★☆☆ 3/5 | 依存関係が問題になる可能性があり、多くのデータストアを管理する必要がある | | デプロイ容易性 | ★★★★★ 5/5 | 変更があった部分のみをデプロイ | | スケーラビリティ | ★★★★★ 5/5 | サービスごとのスケールが可能 | | | **合計:** 16/20 | **その他のトレードオフ** | | | | - データを [サービスごとに1つのデータストア](https://link-to-reference-info)に分割する必要がある<br/>- 構築コストが高くなる傾向がある <br/>- 複雑でワークフローの作成が難しい | ### 2. サービスベース | 基準 | スコア | 根拠 | | --------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------------ | | 応答性 | ★★★☆☆ 3/5 | [本質的に高パフォーマンスではない](https://link-to-reference-info)が、ボトルネックでの最適化（例：スケーリング）が可能 | | メンテナンス性 | ★★★★☆ 4/5 | マイクロサービスよりも少ないデータストアで管理可能 | | デプロイ容易性 | ★★★★☆ 4/5 | 変更があった部分のみをデプロイ、共有データストアの変更が他サービスに影響を与えないよう確認が必要 | | スケーラビリティ | ★★★☆☆ 3/5 | 個別のサービスはスケール可能だが、[キャッシング](https://link-to-reference-info)を使用しない限り共有データストアのスケールは難しい | | | **合計:** 14/20 | **その他のトレードオフ** | | | | - 比較的複雑でワークフローの作成が難しい <br/>- マイクロサービスほど進化しやすくない | ### 3. イベント駆動 | 基準 | スコア | 根拠 | | --------------- | ---------------- | ---------------------------------------------------------------------------------------------------------------------------- | | 応答性 | ★★★★★ 5/5 | 一般的に [fire-and-forget](https://link-to-reference-info)であり、イベント処理はスケールや最適化が可能 | | メンテナンス性 | ★★★★☆ 4/5 | イベント処理とともにサービスやデータストアの管理が必要、イベントによりサービスが分離され各チームで管理可能になる | | デプロイ容易性 | ★★★☆☆ 3/5 | イベント処理のデプロイと変更も含めて管理が必要 | | スケーラビリティ | ★★★★★ 5/5 | サービスとメッセージ処理の両方をスケール可能 | | | **合計:** 17/20 | **その他のトレードオフ** | | | | - [その他のトレードオフ](https://link-to-reference-info) | ## 決定 意思決定基準に対する総合スコアおよび、最も重要な基準である応答性においてオプション1および2のスコアが低かったことから、イベント駆動型アーキテクチャを採用する。 ## 影響 ### ポジティブな影響 - 現行のサーバーレス機能よりも、全体的な応答性、メンテナンス性、スケーラビリティが向上する。 - 待機中のイベントを処理するために、サービスの追加インスタンスを起動することでイベント処理のスケーラビリティが向上する。 - サービス内での処理において、サービスの追加インスタンスを起動することでスケーラビリティが向上し、サービス内での処理ニーズに対応できる。 ### ネガティブな影響 - チームまたは個人が新しいスキルや技術（イベントキューなど）を学ぶ必要が出てくるかもしれない。 - イベント管理（キューなど）は、開発とデプロイメントがさらに複雑になる。 - 統合テストおよびDevOpsを全面的に見直す必要が生じる。 ## 協議 - _ヴラッド_：マイクロサービスもサービスベースも [本質的に高パフォーマンスではない](https://link-to-reference-info)ため、私たちが望むほど応答性を高めることはできないでしょう。 - _ニッキ_：私はイベント駆動型アーキテクチャの経験があり、キューを使用していました。キューの長さを監視し、必要に応じてサービスの追加インスタンスを起動して長いキューを処理していました。 - _リビー_：キューとチャネルを使ってイベント処理の優先順位をつけることができます。例えば [救急車パターン](https://link-to-reference-info)が使えます。 - _マーク_：応答性は顧客の苦情に対応するため、最優先事項であるべきです。 - _リビー_：完全なマイクロサービスの場合、サービス間でデータストアを共有しない必要があります。データをこのように分割するには、かなりの労力が必要でしょう。 ライセンス：[CC BY 4.0 (Jacqui Read / jacquiread.com)](https://creativecommons.org/licenses/by/4.0/)でライセンスされた[ADR-044 Use an Event-Driven Distributed Architecture](https://communicationpatternsbook.com/assets/ADR-example-decision-making.html)を翻訳したものです。 [> Home](https://github.com/oreilly-japan/communicationpatterns-jp) | [>特典コンテンツ](https://github.com/oreilly-japan/communicationpatterns-jp/blob/master/freebies.md)