Apache Beam で流量制限ができるのか調査

Apache Beam はデータを素早く処理するのに最適だが、処理速度を落とさないといけない場面がたまにある。

Data Engineering Lifecycle でいうところの Serving Step では特にあり得る。例えば、外部の API を叩く場合、Apache Kafka のクラスターが大規模なトラフィックを捌けない場合、あるいは他にも Rate limit がある処理など。

Apache Beam を実際に使っていると、Rate limit を考えなければいけない場面は少なくない。

我々の場合は、Cloud Bigdable (Google のフルマネージド NoSQL データベス) でこう言った場面に遭遇した。

Apache Beam のスループットが大きすぎて Cloud Bigtable への write が詰まってしまった

This is a perfect example of how unchecked high throughput can affect connected systems and break the entire data processing and machine learning pipeline.

BigData の分野では throttle（流量制限）は重要である

この記事では、Apache Beam pipeline でどのように Rate limiting を行うかについて説明する

前提

Apache Beam の runner として基本的には DataflowRunner を使っている

言語は Java を使っている

我々の使っているライブラリはまだ beta である

また、Apache Beam や DoFn などについては理解しているものとする。もしまだ理解していない場合は以下の記事を参考にすると良い

Guava RateLimiter

Google の Guava library を使って実現する

訳注: Guava とは Google が作っている、Java の便利なライブラリたち

DoFn を実装して、pipeline に apply するときに ElementRateLimiter で 10 elements/second の制限を入れる

実際に使っていると 20 element / sec が出ている

ElementRateLimiter の挙動を理解する必要がある

Rate limit は per worker なので、worker が 2 だったら rate limit は 20 element/sec になる

auto scaling を無効にしてもいいのであれば問題はない

Redisson

Guaba の RateLimiter は Single worker なら問題ないが、multi worker だと問題になる。

Redis を使って流量制限をする

比較

Guava RateLimiter を使う場合

ワーカー数が固定の場合

厳密な Rate limiting でなくても OK な場合

Redisson を使う場合

ワーカーが複数あったり、auto-scaling が有効になっている場合

厳密に Rate limit を守りたい場合（外部サービスを利用している場合など）

複数の Apache Beam パイプラインで Rate limit を共有したい場合