マイクロサービスアーキテクチャ内で見られる共通パターン
この文章は機械翻訳によって提供されています。原文は英語であり、OpenAIによって翻訳されました。
目次
- 概要
- クライアントからマイクロサービスへの直接通信
- APIゲートウェイパターン
- ゲートウェイオフローディング
- フロントエンド向けバックエンド（BFF）
- Kuroco API管理
概要
マイクロサービスは、アプリケーションを複数のサービスコンポーネントに分割するアプリケーションアーキテクチャの一種であり、すべての部分が結びついて依存関係を共有する従来のモノリシックアーキテクチャとは対照的です。
マイクロサービスは、他のマイクロサービスと独立して機能する細粒度のエンドポイントを公開します。目標は、各サービスをより簡単に構築およびメンテナンスし、依存関係を減らし、マイクロサービスの速度とスケーラビリティを向上させることです。アプリケーションが複雑になるにつれて、多くのバンドルされたマイクロサービスとの通信は問題を引き起こす可能性があります。以下で詳しく説明します。
クライアントからマイクロサービスへの直接通信
最も基本的なパターンは、クライアントからマイクロサービスへの直接通信アーキテクチャです。このパターンでは、クライアントアプリケーションがマイクロサービスに直接リクエストを行います。
大規模なサーバーサイドアプリケーションは通常、クライアントから適切なバックエンドマイクロサービスへのリクエストを管理するために負荷分散が必要なクラスターとして組織化されます。アプリケーションが成長するにつれて、使用するマイクロサービスの数が数十になる場合、これは管理が困難になる可能性があります。
したがって、大規模なアプリケーションでは、バックエンドマイクロサービスへのリクエストの数を最小限に抑えることが重要です。なぜなら、これによりレイテンシが増加し、フロントエンドのパフォーマンスが低下する可能性があるからです。代わりに、必要なデータが集約されたときに、サーバーサイドでレスポンスをバンドルしてフロントエンドに提供するべきです。
直接クライアントからマイクロサービスへの通信パターンのもう一つの主要な問題は、認証、データの変換、動的リクエストのディスパッチなどの機能の処理です。
- 各マイクロサービスごとに認証が必要な場合、これは大規模な開発オーバーヘッドと繰り返しコードを作成し、スケールできない難しい管理が生じます。
- インターネットクライアントが直接消費するためには適していないプロトコルを使用している場合、まずHTTP/HTTPSに変換する必要があり、これも多くの開発オーバーヘッドを要する場合があります。
- モバイルアプリとWebブラウザなど、異なるフロントエンドの特定のニーズを満たすためにAPIマイクロサービスをバンドルすること
APIゲートウェイパターン
上記のパターンでは、クライアントアプリケーションは時間の経過とともに多くのマイクロサービスエンドポイントに結びついてしまいます。アプリケーションが構造を変更したり新しいマイクロサービスを導入したりすると、多くのエンドポイントを処理することは非常に困難になります。
- 結合：マイクロサービスは互いに独立していますが、クライアントアプリケーションはしばしば内部マイクロサービスに直接参照を行うため、内部マイクロサービスがリファクタリングされると破壊的な変更が発生する可能性があります。
- レイテンシ：クライアントアプリケーションのビューのいずれかが複数のサービスへの多数の呼び出しを必要とする場合、ネットワークが遅くなり、レイテンシが大幅に増加する可能性があります。集約は、これに対する最も明らかな解決策です。
- セキュリティ：マイクロサービスはデフォルトで一般公開されているため、クライアントアプリケーションが直接使用しない内部マイクロサービスよりも攻撃面が広くなります。
- 認証：一般公開されている各マイクロサービスは、認証やSSLなどのクロスカットの関心事を処理する必要があります。これにより、各マイクロサービスごとに開発オーバーヘッドと繰り返しコードが発生し、統合できる可能性があります。
上記の問題に対する最も広く使用されている解決策は、APIゲートウェイです。
APIゲートウェイ
APIゲートウェイパターンは、クライアントアプリケーションのニーズを最優先に考えることに関連しています。APIゲートウェイは、クライアントアプリケーションとマイクロサービスの間に位置し、リバースプロキシとして機能し、クライアントからのリクエストをサービスにルーティングします。また、認証、SSL終了、キャッシングなどの機能も処理できます。
APIゲートウェイは、リバースプロキシまたはゲートウェイルーティングなどのさまざまな機能を提供できます。ゲートウェイは、クライアントアプリケーションに対して単一のエンドポイントまたはURLを提供し、リクエストをグループ化された内部マイクロサービスのエンドポイントに内部的にマッピングします。このルーティング機能により、クライアントアプリケーションとマイクロサービスの結合が緩和されます。また、モノリシックAPIのモダナイズ時にも便利です。モノリシックAPIとクライアントアプリケーションの間にAPIゲートウェイを配置し、将来的にはモノリシックAPIを複数のマイクロサービスに分割するまで、新しいAPIを新しいマイクロサービスとして追加できます。
APIゲートウェイのおかげで、クライアントアプリケーションは使用されているAPIが内部マイクロサービスとして実装されているのか、モノリシックAPIとして実装されているのかを気にする必要はありません。さらに重要なのは、モノリシックAPIをマイクロサービスに進化させ、リファクタリングする際に、APIゲートウェイのルーティングにより、クライアントアプリケーションにURIの変更が影響を与えないことです。
リクエストの集約
ゲートウェイパターンの一環として、複数のクライアントリクエスト（通常はHTTPリクエスト）を複数の内部マイクロサービスに対する単一のクライアントリクエストに集約することができます。 このパターンは、クライアントのページ/画面が複数のマイクロサービスから情報を必要とする場合に特に便利です。 このアプローチでは、クライアントアプリケーションはAPIゲートウェイに単一のリクエストを送信し、APIゲートウェイは複数の内部マイクロサービスに対して複数のリクエストをディスパッチし、その結果をまとめてクライアントアプリケーションに送り返します。
このデザインパターンの主な利点と目標は、クライアントアプリケーションとバックエンドAPIの間のやり取りを減少させることであり、特にモバイルアプリやJavaScriptからのSPAアプリからのリクエストなどのリモートアプリケーションにとって重要です。 通常のWebアプリはサーバー環境でリクエストを実行するため、リモートクライアントアプリケーションよりもはるかに低い遅延があるため、このパターンはそれほど重要ではありません。
使用するAPIゲートウェイによっては、この集約を実行できるかもしれません。 ただし、多くの場合、APIゲートウェイの範囲内で集約マイクロサービスを作成する方が柔軟性があります。
ゲートウェイのオフロード
APIゲートウェイが提供する機能によっては、各マイクロサービスからゲートウェイに機能をオフロードでき、各マイクロサービスの実装を簡素化できます。
このアプローチは、以下の機能など、すべての内部マイクロサービスで正しく実装するのが複雑な専門の機能に適しています：
- 認証および承認
- サービスディスカバリ統合
- レスポンスキャッシュ
- レート制限とスロットリング
- ロードバランシング
- ロギング、トレーシング、相関
- ヘッダー、クエリ文字列、およびクレームの変換
フロントエンド用バックエンド（BFF）
APIゲートウェイパターンと同様に、フロントエンド用バックエンド（BFF）パターンは複数のゲートウェイを使用し、それぞれが特定のフロントエンドチャネルに専用のものです。 たとえば、ネイティブモバイルアプリのフロントエンドと伝統的なデスクトップブラウザWebアプリは、それぞれ統合するためのAPIゲートウェイを持ち、それが必要なデータを適切な形式で集約し提供します。
このパターンについての詳細は、この記事を参照してください。
Kuroco API Management
Kurocoのバックエンドは、組み込みのトラッキングとアナリティクスを備えたAPIゲートウェイ機能を提供しています。
Kurocoは、APIのログ記録、セキュリティ、メータリングを可能にし、これらの洞察を通じて企業がAPIの使用状況とパフォーマンスを理解するのに役立ちます。 これにより、ほぼリアルタイムのアナリティクスレポートを表示し、ビジネスに影響を与える可能性のあるトレンドを特定することができます。 さらに、リクエストとレスポンスのアクティビティに関するログを表示して、オンラインおよびオフラインでの分析が可能です。
今すぐ無料で試してみるか、質問がある場合はカスタマーサポートチームにお問い合わせしてください！