web-dev-qa-db-ja.com

マイクロサービスアーキテクチャで大量のデータを交換するのに最適なオプションはどれですか。

私が取り組んでいるアプリケーションでは、Microsoft Wordドキュメント（doc、ppt、xls）、pdfなどのさまざまな独自のドキュメント形式からテキストコンテンツを抽出する必要があります。

独自形式のドキュメントを入力として受け取り、抽出したテキストを出力として返すマイクロサービスを実装する予定です。

このソリューションでは、リクエストごとに大量のデータ（1 MBから100 MBのオーダー）を交換するマイクロサービスが必要です。マイクロセリブは1秒あたり1000リクエストにスケーリングできるはずです。

このソリューションへのW.r.tは理解したいです

  • マイクロサービスアーキテクチャ上でこのレートでデータを転送しても問題ありませんか？
  • REST APIを使用してデータを転送する計画。それは良いオプションですか？
restmicroservicesaws
6
user2586432

最初に考慮すべきいくつかの重要な側面があります。

ストリーミング

100 MBのファイルがサービスAによって受信され、サービスBに転送するとします。サービスBは、サービスCを使用して独自フォーマットの実際の解析を行います。

間違ったアプローチは、サービスAとBが基礎となるサービスのみにファイルの送信を開始することですafterクライアントからファイルを完全に受信します：

enter image description here

代わりに、startファイルを受信するとすぐに、基盤となるサービスにストリームする必要があります。

enter image description here

これは、100 MBを転送するのにかかる時間を3回待つのではなく、1回だけ待つだけでなく、レイテンシを待機することを意味します...

待ち時間

一方、待ち時間は避けられません。すべての中間サービスは、ファイルの転送を開始する前に、基になるサービスへのHTTP/HTTPS接続を開く必要があります。

マイクロサービスが同じデータセンターにある場合、レイテンシは数ミリ秒の問題である可能性があります。サービスが異なるデータセンターでホストされている場合、遅延が大きくなる可能性があります。仲介者の数が多い場合、これは問題になる可能性があり、小さな要求にも影響します。

可能なDOS

ストリーミング手法を使用する場合は、DOS攻撃の可能性に身をさらさないようにしてください。リスクは、クライアントがファイルを送信している限り、仲介者がHTTP接続を維持することです。 DOS攻撃は、サービスが処理できる接続を使い果たすために、非常に低速で多くのファイルを送信することで構成されます。

7
Arseni Mourzenko

あなたへの私の提案は、非常にシンプルで進化するものから始めることです。まず、AWS Lambda + API Gatewayを試してください。非常にシンプルな開始、リージョンごとの最大1000の同時実行の自動スケーリング。より多くの同時実行が必要になる場合は、マルチリージョン負荷分散について考えることができます。または、リクエストを開いて割り当てを増やしてみてください。問題は価格です。高価になる可能性があります。同じドキュメントを使用する場合は、結果をキャッシュすることを検討してください。

より複雑なアーチ：

  1. ドキュメントをs3にアップロードします。 （アップロードが完了した後にのみ、ドキュメントの名前でLambdaを呼び出します）
  2. Lambdaを呼び出して、s3のドキュメントを分析します。 （後、ドキュメントを削除し、ドキュメントのハッシュを結果にキャッシュに保存します）
  3. 結果を返します。

これは、さまざまな観点から見たより賢明なアーキテクチャです。

  • S3アップロードの複数のクライアントに非常に適しています。
  • レイテンシLambda <-> S3がはるかに良い
  • 開発が簡単
  • 価格
1
yuriy polonskiy