NLB + Fluentd の構成でファイルディスクリプタが枯渇する謎の現象を解消した話 - Repro Tech Blog
Repro インフラチーム (SRE + 分析基盤) の伊豆です。今回は、Repro のデータ収集基盤で私たちが遭遇した問題を紹介したいと思います。 具体的には、AWS Network Load Balancer(NLB) + Fluentd の構成でファイルディスクリプタが枯渇する謎の現象に遭遇したので、その問題の調査記録と解決策を共有します。また、この問題を解消するにあたり Fluentd に PR を送ったのでそれの紹介もします。 https://github.com/fluent/fluentd/pull/2352 データ収集基盤の構成 Repro のデータ収集基盤はFlunetd High Availability Configをもとに構成され、大まかに次のようになっています。 SDK からアップロードされたデータは、転送用 Fluentd(log forwarders)を経由し
AWS Network Load Balancerの内部LBはクライアントとターゲットが同一IPアドレスのトラフィックを扱うことができない | DevelopersIO
ども、大瀧です。 内部NLB(Network Load Balancer)でFluentd Aggregatorの負荷分散構成を組んでいたところ、タイトルの制約に気がついたので共有します。 どういう制約? 図で示すと以下になります。 NLBのターゲットグループがインスタンス単位で登録するタイプの場合、NLBはトラフィックの送信元IPアドレスをクライアントIPアドレスのままターゲットに転送します。そうするとターゲットからの戻りのトラフィックの宛先IPアドレスがターゲット自身に向き、行きと戻りで経路がちぐはぐになってしまうわけです。 こんな構成にすることあるの?と思われるかもしれませんが、ECSタスク(Dockerコンテナ)のログをNLB経由でFluentd Aggregatorに送るというケースだと十分ありえるわけです。 で、本ケースについてはドキュメントに記載があり、さらに回避方法も案内さ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
