Kubernetes と Firebase の接続リセットの問題のデバッグ（前半）

今回の記事は長いので前半と後半に分けてお送りします。

今回は前半です。

Kubernetes、Firebase、Cloud NATネットワークなどに関する記事です。

Background — ECONNRESET

Leveregeでは、大規模なIoTアプリケーションを構築・管理するためのIoTプラットフォームを提供しています。アセットトラッキングからリモートモニタリング(遠隔監視）まで、何百万ものセンサーが毎日当社のプラットフォームと通信しています。Leverege IoTプラットフォームは、Google Kubernetes Engine（GKE）上で動作するマイクロサービスで構成されており、データ処理にはFirebase、TimescaleDB、BigQueryを組み合わせて使用しています。特にFirebaseを使用して、デバイスのリアルタイム情報や状態情報を保存しています。

当社のネットワークの問題は、自動車のユースケースが大幅に拡大し始めたことに伴い発生し、API サーバー上で接続のリセットやタイムアウトが起きるようになりました。最初は、接続の問題はトラフィックが多い時にしか発生しなかったので、サーバーのパフォーマンスの問題を疑っていました。しかし、サーバーをより多くのレプリカに拡張し、リクエストを処理するためにより多くの子プロセスを実行した後も、ECONNRESET は継続していました。

トラフィックを生産負荷の 5 倍にする負荷テスト（ロードテスト）を実行したところ、リセットがより頻繁に発生し、ある時点でサーバは新しいメッセージを処理できなくなってしまいました。というのも リトライのためにスローバックされたキュー内の未認識メッセージは、新鮮なデータの数を上回るようになったからです。この問題を緩和するためにデッドレターキューを実装する代わりに、私たちは根本的なネットワークの問題を修正することにしました。

Debugging Kubernetes Networking

最初に試したのは、単純にノードプールに大きなマシンを選択することでした。コスト削減という理由から、API サーバーは以前は GKE 上の n1-standard-2 のプリエンプティブルなマシンで動作していました。下のグラフにあるように、n1-standard-4 の TCP スループットは n1-standard-2 の約 2…