背景・目的
最近、腐敗防止層（Anti-corruption layer）という言葉を知ったので、整理します。
下記を参考にまとめます。
まとめ
| 特徴 | 説明 |
|---|---|
| 腐敗防止層 | Anti-corruption layerという。異なるシステム間でデータモデルの違いを吸収する仲介層を指す 変換リスクとビジネスの中断を軽減する |
| 導入する理由 | モノリシックアプリからマイクロサービスに移行すると、新しく移行されたサービスのドメインモデルセマンティクスが変更される可能性がある |
| 適用対象 | 既存のモノリシックアプリがマイクロサービスに移行された関数と通信する必要がある |
| 問題点と考慮事項 | 下記のような点を考慮する ・チーム依存関係 ・運用オーバーヘッド ・単一障害点 ・技術的負債 ・レイテンシー ・スケーリングのボトルネック ・サービス固有の実装または共有実装 |
概要
Intent
アンチ破損レイヤー (ACL) パターンは、ドメインモデルのセマンティクスをあるシステムから別のシステムに変換する仲介レイヤーとして機能します。アップストリームの境界コンテキスト (モノリス) のモデルを、アップストリームチームによって確立された通信契約を消費する前に、ダウンストリームの境界コンテキスト (マイクロサービス) に適したモデルに変換します。このパターンは、ダウンストリームの境界コンテキストにコアサブドメインが含まれている場合、またはアップストリームモデルが変更不可能なレガシーシステムである場合に適用できます。また、呼び出しをターゲットシステムに透過的にリダイレクトする必要がある場合に発信者への変更を防ぐことで、変換リスクとビジネスの中断を軽減します。
- 異なるシステム間でデータモデルの違いを吸収する仲介層を指す
- 古いシステム（モノリス）のモデル → 新しいシステム（マイクロサービス）のモデルに変換する
- ダウンストリームの境界コンテキストにコアサブドメインが含まれている場合、またはアップストリームモデルが変更不可能なレガシーシステムである場合に適用できる
- 呼び出しをターゲットシステムに透過的にリダイレクトする場合、発信者への変更を防ぐ
- 変換リスクとビジネスの中断を軽減する
導入する理由
移行プロセス中にモノリシックアプリケーションをマイクロサービスに移行すると、新しく移行されたサービスのドメインモデルセマンティクスが変更される可能性があります。これらのマイクロサービスを呼び出すためにモノリス内の機能が必要な場合は、呼び出し元のサービスを変更することなく、移行されたサービスに呼び出しをルーティングする必要があります。ACL パターンを使用すると、モノリスは、呼び出しを新しいセマンティクスに変換するアダプターまたはファサードレイヤーとして機能することで、マイクロサービスを透過的に呼び出すことができます。
- モノリシックアプリからマイクロサービスに移行すると、新しく移行されたサービスのドメインモデルセマンティクスが変更される可能性がある
- マイクロサービスを呼び出すためにモノリス内の機能が必要な場合、呼び出し元のサービスを変更することなく
- 移行されたサービスに呼び出しをルーティングする必要がある
- ACLパターンを利用し、モノリスは、呼び出しを新しいセマンティクスに変換するアダプターor ファサードレイヤーとして機能する
適用対象
次の場合は、このパターンの使用を検討してください。
- 既存のモノリシックアプリケーションは、マイクロサービスに移行された関数と通信する必要があり、移行されたサービスドメインモデルとセマンティクスは元の機能とは異なります。
- 2 つのシステムには異なるセマンティクスがあり、データを交換する必要がありますが、一方のシステムを他のシステムと互換性があるように変更することは実用的ではありません。
- 迅速かつシンプルなアプローチを使用して、影響を最小限に抑えながら、あるシステムを別のシステムに適応させたいと考えています。
- アプリケーションが外部システムと通信しています。
下記の場合に適用を検討する
- 既存のモノリシックアプリがマイクロサービスに移行された関数と通信する必要がある
- 2つのシステムには異なるセマンティクスがある。データを交換する必要があるが、一方のシステムを他のシステムと互換性があるように変更することは実用的でない
- 迅速かつシンプルなアプローチを使用して、影響を最小限に抑えながら、あるシステムを別のシステムに適応させたい
- アプリケーションが外部システムと通信する
問題点と考慮事項
- チーム依存関係： システム内のさまざまなサービスが異なるチームによって所有されている場合、移行されたサービスの新しいドメインモデルセマンティクスは、呼び出し元のシステムの変更につながる可能性があります。ただし、チームは他の優先順位を持っている可能性があるため、調整された方法でこれらの変更を行うことができない場合があります。ACL は呼び出し元を切り離し、呼び出しを新しいサービスのセマンティクスと一致するように変換するため、呼び出し元が現在のシステムに変更を加える必要がなくなります。
- チーム依存関係
- 変更すると呼び出し元のシステムの変更につながる可能性がある
- ただし、チームは他の優先事項を持っている（可能性あり）、調整された方法では変更できない場合あり
- ACLは呼び出し元を切り離し、呼び出しを新しいサービスのセマンティクスと一致するように変換する。これにより呼び出し元が現在のシステムに変更を加える必要がなくなる
- 運用オーバーヘッド： ACL パターンでは、運用と保守にさらなる労力が必要です。この作業には、ACL をモニタリングおよびアラートツール、リリースプロセス、継続的インテグレーションおよび継続的デリバリー (CI/CD) プロセスと統合することが含まれます。
- 運用のオーバーヘッドがある
- ACLパターンは運用と保守にさらに労力がかかる
- ACLをモニタリング、およびアラートツール、リリースプロセス、CI/CDプロセスと統合すること
- 単一障害点： ACL で障害が発生すると、ターゲットサービスに到達できず、アプリケーションの問題が発生する可能性があります。この問題を軽減するには、再試行機能とサーキットブレーカーを構築する必要があります。これらのオプションの詳細については、バックオフパターンとサーキットブレーカーパターンによる再試行を参照してください。 サーキットブレーカーパターン適切なアラートとログ記録を設定すると、平均解決時間 (MTTR) が向上します。
- SPOFになる
- ACLで障害が発生すると、ターゲットサービスには到達できずに、アプリの問題が発生する可能性あり
- 上記の問題を軽減するために、リトライとサーキットブレーカーを構築する必要がある
- サーキットブレーカーパターンの適切なアラートとログ記録によりMTTRが向上する
- 技術的負債： 移行またはモダナイゼーション戦略の一環として、ACL が一時的または暫定的なソリューションか、長期的なソリューションかを検討してください。中間ソリューションの場合は、ACL を技術的負債として記録し、すべての依存発信者が移行された後に廃止する必要があります。
- 技術的負債
- 移行、またはモダナイぜーション戦略の一環として、ACLが一時的または暫定的なソリューションか、長期的ソリューションかを検討する
- 中間ソリューションの場合、ACLを技術的負債として記録し、すべて移行後に廃止する必要がある
- レイテンシー： 追加のレイヤーでは、あるインターフェイスから別のインターフェイスへのリクエストの変換によりレイテンシーが発生する可能性があります。ACL を本番環境にデプロイする前に、応答時間に敏感なアプリケーションでパフォーマンス耐性を定義してテストすることをお勧めします。
- レイテンシー
- 追加のレイヤーでは、あるI/Fから別のI/Fへのリクエスト変換によりレイテンシーが発生する可能性あり
- パフォーマンステストを推奨
- スケーリングのボトルネック： サービスがピーク負荷までスケールできる高負荷のアプリケーションでは、ACL がボトルネックになり、スケーリングの問題が発生する可能性があります。ターゲットサービスがオンデマンドでスケールする場合は、それに応じてスケールするように ACL を設計する必要があります。
- スケーリングのボトルネック
- サービスがピーク負荷までスケールできる高負荷アプリでは、ACLがボトルネックになりスケーリングの問題が発生する可能性あり
- ターゲットサービスがオンデマンドでスケールする場合、それに応じてスケールするようにACLを設計する必要がある
- サービス固有の実装または共有実装： ACL を共有オブジェクトとして設計して、呼び出しを複数のサービスまたはサービス固有のクラスに変換およびリダイレクトできます。ACL の実装タイプを決定するときは、レイテンシー、スケーリング、障害耐性を考慮してください。
- サービス固有の実装または共有実装
- ACLを共有オブジェクトとして設計し、呼び出しを複数のサービスまたはサービス固有のクラスに変換、リダイレクトできる。（どっちか選べる）
- これらを選ぶとき、レイテンシー、スケーリング、障害耐性を考慮すること
実装
ACL は、モノリシックアプリケーション内に、移行されるサービスに固有のクラスとして、または独立したサービスとして実装できます。ACL は、すべての依存サービスがマイクロサービスアーキテクチャに移行された後に廃止する必要があります。
- ACLは、下記のパターンで実装が可能。しかしいずれもすべての依存サービスがマイクロサービスに以降された後に廃止する必要がある
- モノリシックアプリ内
- 移行されるサービスに固有
- 独立
高レベルのアーキテクチャ
次のアーキテクチャ例では、モノリシックアプリケーションには、ユーザーサービス、カートサービス、アカウントサービスの 3 つのサービスがあります。カートサービスはユーザーサービスに依存し、アプリケーションはモノリシックリレーショナルデータベースを使用します。
※出典：Anti-corruption layer pattern
- 3つのサービスがある
- カートサービスはユーザサービスに依存する
- アプリケーションはモノリシックRDBを使用する
次のアーキテクチャでは、ユーザーサービスは新しいマイクロサービスに移行されています。カートサービスはユーザーサービスを呼び出しますが、実装はモノリス内で利用できなくなりました。 また、新しく移行されたサービスのインターフェイスが、モノリシックアプリケーション内にあった以前のインターフェイスと一致しない可能性もあります。
※出典：Anti-corruption layer pattern
- ユーザーサービスは、新しいマイクロサービスに移行されている
- カートサービスは、ユーザサービスを呼び出す。これによりモノリス内で利用できなくなった
- 新しく移行されたサービスのI/Fがモノリシックアプリ内にあった以前のI/Fと一致しない可能性がある
※出典：Anti-corruption layer pattern
- カートサービスが新しく移行されたユーザサービスを直接呼び出す場合、カートサービスの変更とモノリシックアプリケーションの徹底的なテストが必要になる
- これにより、変換リスクとビジネスの中断が増加する可能性がある
- 目標は、モノリシックアプリの既存の機能への変更を最小限に抑えること
- この場合、古いユーザーサービスと新しく移行されたユーザサービスの間にACLを導入する（ことを推奨）
- ACLはアダプター、ファサードとして機能する
AWS サービスを使用した実装
AWSを利用したACLを実装する方法。
- マイクロサービスは、ASP.NETから移行され、AWS Lambdaとしてデプロイされる
- Lambdaの呼び出しは、API Gatewayを介してルーティングされる
- ACLはモノリスにデプロイされ、呼び出しを翻訳してユーザマイクロサービスのセマンティクスに適応する
考察
今回は、腐敗防止層（Anti-corruption layer）について整理しました。次回はサーキットブレーカーパターンをまとめたいと思います。
参考