Lagのないリアルタイムデータパイプラインのためのアーキテクチャ改善記

<p>Kafkaのconsumer groupとpartition数の関係、そしてそれによって生じるauto scalingの難しさを解決するために、新しいアーキテクチャを導入した事例です。<br /> <br /> - AirbridgeサービスとWorkloadの紹介<br /> - 既存アーキテクチャの問題点<br /> - 新しいアーキテクチャの提案<br /> - 案1: Spark streamingのようなdriver, executor model<br /> - 案2: Kafka consumerとapplication serverのdecouple model<br /> - 案2を選択した理由<br /> - Kafka consumerとapplication serverのdecouple modelアーキテクチャ<br /> - 新しいアーキテクチャにおける考慮事項<br /> - 経験した難しさ<br /> - 新アーキテクチャ適用後の結果<br /> - 今後さらに試してみるべきこと</p>

[lamanus]

<p>わあ…私もecsを使っていますが、ここまで深く考えたことはなかったので、いいですね。</p>

[lamanus]

<p>envoyを使っていて、AZ間トラフィックを減らすためのリクエストは保留状態だったようですね。<br /> <br /> https://github.com/aws/aws-app-mesh-roadmap/issues/94</p>;