シナリオ: 小さいサイズ (それぞれ平均 50 バイト) の一連のレコード (10k、おそらくそれ以上) を処理する必要があります。パフォーマンスを向上させるには、処理を並行して行うか、その他の方法で行う必要があります (処理するレコードがたくさんあることを思い出してください)。また、処理自体は非常に単純な作業です (AWS Lambda を使用する理由の 1 つです)。単純ですが、一部の処理は他の処理の前後に終了する可能性があるため、これらのレコードが互いに独立しており、処理の順序は問題にならないもう 1 つの理由です。
これまでのところ、Step Functions は進むべき道のようです。
Step Functions を使用すると、次のグラフを作成できます。
RecordsRetrieval を 1 つのタスクとして定義できます。その後、これらのレコードは、タスク ProcessRecords-Task-1、ProcessRecords-Task-2、および ProcessRecords-Task-3 によって並行して処理されます。見た目からして、元気でダンディでしょ？違う！
最初の問題：動的スケーリング処理するレコードの量を考慮して、これらのタスクの動的スケーリング（たとえば、10、100、5k、または10k）が必要な場合は、jsonを動的に構築する必要がありますそれを達成します（非常にエレガントなソリューションではありませんが、うまくいくかもしれません）。タスクの数には限界があると確信しているので、それに頼ることはできません。スケーリングの重労働が私ではなくインフラストラクチャによって処理されると、はるかに良いでしょう。
いずれにせよ、GetAddress、GetPhoneNumber、GetWhatever などの明確に定義された一連の並列タスクについては、すばらしいことです。魔法のように動作します！
2 番目の問題: ペイロード ディスパッチ RecordsRetrieval タスクの後、これらのレコードのそれぞれを個別に処理する必要があります。Step Functions では、それを達成する方法がわかりませんでした。RecordsRetrieval タスクがそのペイロード (この場合はこれらのレコード) を渡すと、すべての並列タスクが同じペイロードを処理します。
繰り返しますが、最初の問題で述べたように、明確に定義された並列タスクのセットには完全に適合します。
結論 おそらく、AWS Step Functions は私のシナリオのソリューションではないと思います。これは私の知識の要約ですので、何か見逃した場合は遠慮なくコメントしてください。
私は多くの理由 (スケーラビリティ、サーバーレス、シンプルさなど) からマイクロサービス アプローチを検討しています。
これらのレコードを取得して、1 つずつ別のラムダに送信できることはわかっていますが、これもあまり洗練されたソリューションではありません。
また、これはバッチ ジョブであり、AWS には Batch サービスがあることも知っています。私がやろうとしているのは、AWS Batch/EC2 に依存せずにマイクロサービス アプローチを維持することです。
それについてどう思いますか。お気軽にコメントください。任意の提案をいただければ幸いです。