[論文レビュー] Circuit Breakers, Discovery, and API Gateways in Microservices

Fabrizio Montesi, Janine Weber|arXiv (Cornell University)|Sep 19, 2016

Software System Performance and Reliability参考文献 12被引用数 44

ひとこと要約

本論文は、Jolie（ネイティブなマイクロサービスプログラミング言語）における、3つのコアなマイクロサービスパターン—リトライ、サービスディスカバリ、APIゲートウェイ—の体系的分析を提示する。これにより、クライアント側以外の場所にリトライを適用するという新たな知見が得られ、進化するAPIに適応可能なパラメトリックな再利用性の重要性が強調され、コンポジショナルでパターンベースの設計がマイクロサービスアーキテクチャにおけるシステムのレジリエンスと柔軟性を高めることを提唱する。

ABSTRACT

We review some of the most widely used patterns for the programming of microservices: circuit breaker, service discovery, and API gateway. By systematically analysing different deployment strategies for these patterns, we reach new insight especially for the application of circuit breakers. We also evaluate the applicability of Jolie, a language for the programming of microservices, for these patterns and report on other standard frameworks offering similar solutions. Finally, considerations for future developments are presented.

研究の動機と目的

• 主なマイクロサービスパターン（リトライ、サービスディスカバリ、APIゲートウェイ）の展開戦略を分析・比較すること。
• リトライがクライアント側以外の場所に効果的に適用可能である方法を調査し、システム全体のレジリエンスとフェイルセーフティを向上させること。
• Jolieがこれらのパターンを実装するのに適しているかを評価し、特にパラメトリシティと再利用性に焦点を当てる。
• 既存のサービスコーディネーションの形式的モデルにおけるギャップを特定し、今後のこれらのパターンとの統合に向けた方向性を提案すること。
• 開発者がより信頼性が高くスケーラブルなマイクロサービスシステムを構築できるよう、これらのパターンを統一的かつ原則的（principled）に概説すること。

提案手法

• 3状態モデル（クローズド、オープン、ハーフオープン）を用いて、リトライのステートマシン動作を体系的に分析する。
• ターゲットサービスインターフェースに対してパラメトリックであるJolieベースのリトライプロトタイプを提案し、展開場所を問わず透明に再利用可能であることを実現する。
• クライアント側とサーバー側のサービスディスカバリ戦略を評価し、Eureka（クライアントベース）とAWS ELB（サーバー基地）のアプローチを対比する。
• APIゲートウェイがJolieの再利用可能なコンポーネントからどのように構成できるかを示し、セキュリティ、監視、トラフィック管理のためのリトライとロードバランシングを統合する。
• Jolieのネイティブなサービスコンポジションおよびインターフェース定義機能を活用して、型セーフでモジュラーな方法でパターンを実装・検証する。
• 現在の形式的コーディネーションモデルにおける制限を特定し、タイムアウト、障害、動的バインディング、パラメトリック動作をサポートするための拡張を提案する。

実験結果

リサーチクエスチョン

• RQ1 リトライをクライアント側以外の通信チェーンの任意の地点に透明に展開することで、マイクロサービス全体のレジリエンスをどのように向上させられるか？
• RQ2 スケーラビリティ、フェイルセーフティ、パフォーマンスの観点から、クライアント側とサーバー側のサービスディスカバリのトレードオフは何か？
• RQ3 APIゲートウェイをモジュラーで再利用可能なコンポーネントからどのように構成できるか？これにより動的API管理とクロスカットする関心事（cross-cutting concerns）をどのようにサポートできるか？
• RQ4 既存の形式的コーディネーションモデルは、リトライ、サービスディスカバリ、APIゲートウェイの実装をどの程度サポートできるか？
• RQ5 インターフェースのパラメトリシティは、進化するマイクロサービスシステムにおけるリトライのようなパターンの長期的保守性と再利用性をどのように実現するか？

主な発見

• リトライは、クライアント側に限らず、通信チェーンの任意の地点に透明に配置可能であり、連鎖的障害に対する広範な保護を提供する。
• Jolieベースのリトライプロトタイプはインターフェースのパラメトリシティをサポートしており、インターフェースが進化してもサービス間で再利用可能である。Hystrixとは異なり、新しい操作を追加するたびに再実装を必要としない。
• クライアント側ディスカバリ（例：Eureka）はクライアント側キャッシュのおかげでよりレジリエントであるが、サーバー側ディスカバリ（例：AWS ELB）は高負荷下でボトルネックとなる可能性がある。
• Jolieで構築されたAPIゲートウェイは、リトライやロードバランサなどのモジュラーなコンポーネントから構成可能であり、責任の分離と拡張性を実現する。
• 既存の形式的コーディネーションモデルは、タイムアウト、障害、動的バインディングといったキーパターンの機能をネイティブにサポートしていないため、強化されたモデルの必要性が示唆される。
• リトライ、サービスディスカバリ、APIゲートウェイを統合した単一の形式的モデルの構築は、依然として未解決の課題であり、プロセス計算やコンポーネントベースのシステムにおける現在のフレームワークに拡張が必要である。