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

 (engineering.ab180.co)
17 ポイント 投稿者 toughrogrammer 2021-11-11 | 2件のコメント | WhatsAppで共有

Kafkaのconsumer groupとpartition数の関係、そしてそれによって生じるauto scalingの難しさを解決するために、新しいアーキテクチャを導入した事例です。

  • AirbridgeサービスとWorkloadの紹介

  • 既存アーキテクチャの問題点

  • 新しいアーキテクチャの提案

    • 案1: Spark streamingのようなdriver, executor model

    • 案2: Kafka consumerとapplication serverのdecouple model

  • 案2を選択した理由

  • Kafka consumerとapplication serverのdecouple modelアーキテクチャ

  • 新しいアーキテクチャにおける考慮事項

  • 経験した難しさ

  • 新アーキテクチャ適用後の結果

  • 今後さらに試してみるべきこと

関連記事

2件のコメント

 
lamanus 2021-11-11

わあ…私もecsを使っていますが、ここまで深く考えたことはなかったので、いいですね。
 
lamanus 2021-11-11

envoyを使っていて、AZ間トラフィックを減らすためのリクエストは保留状態だったようですね。

https://github.com/aws/aws-app-mesh-roadmap/issues/94