https://tech.mirrativ.stream/entry/2022/08/03/114918

インフラ・ストリーミングチームの id:udzura （@udzura）です。今回は、Goミドルウェアのメモリリークを見つけて解決する際に、どのようなプロセスを踏んでいったかを解説します。

ミラティブでは、Webアプリケーションのみならず、ミドルウェアに相当する部分についても必要なものは内製しています。その中の一つに、社内で「Radisha」と呼んでいる各種集計とキャッシュなどを行うためのミドルウェアがあります。Radishaは以下のような特徴を備えています。

• GET、SET、SETEXなど基本的なRedis互換のコマンドを実装している。そのため、既存のRedisクライアントライブラリから操作が可能である。
• ランキング集計、一定時間内のアクセス集計などが行えるよう、Redis にない独自のコマンドを実装している。
• 高い可用性を志向しており、オンメモリのデータは Raft を用いてレプリケーションされる。

ちなみにRadishaという名前は特徴である**Redis + Raft + HA(High Availability)**から付けられました。

このミドルウェア自体のアーキテクチャなど、詳細な解説は、別の記事に譲ることとします（お楽しみに！）。今回はメモリリークの解決にテーマを絞ります。

なお、今回の記事執筆にあたり、確認や検証を行った環境は以下となります。

Goのバージョン

• Go 1.17.10

OS

• Flatcar Container Linux 2605.9.0 x86_64 / Kernel 5.4.81-flatcar
• Ubuntu 20.04.1 aarch64 / Kernel 5.8.0-63-generic （最後のtraceの検証のみ）

検証中に発生したメモリリーク

このRadishaを検証環境で動作させて、ある程度負荷を掛けつつ挙動を確認していたところ、以下のような問題が発生しました。

• 時間経過とともに、プロセスのResident Set Size（RSS）が肥大化してしまう
  • アクセスが少ない状態でも、数日の間にRSSが2GBを超過し、減る様子が見られない
• メモリの肥大化に伴ってなのか、SETなどの書き込み系コマンドのリクエストが時々遅くなってしまう
  • 通常数msで完了するところが、数百ms〜数秒かかることがある

メモリリークが発生し、それがリクエストの遅延につながっているのではないかと考えました。そしてログを仕込んだり、色々と検証しているうちに、どうやら長時間書き込みのリクエスト（SET、DELなど）が行われると徐々に肥大していくようだということが分かりました。