<h1 id="%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB" data-line="0" class="code-line">
<a class="header-anchor-link" href="#%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB" aria-hidden="true"></a> はじめに</h1>
<p data-line="2" class="code-line">こんにちは、ブルーモ証券株式会社で主にGoのサーバーサイドの実装をしている葛西です。</p>
<p data-line="4" class="code-line">先日、APIの高速化に着手したのですがかなりグダグダになってしまい逆に学びが多かったので他の方が同じ過ちを繰り返さないために、また自分への戒めとしようと思い記事を書きました。</p>
<h1 id="%E8%AA%B2%E9%A1%8C%E3%81%AE%E6%A6%82%E8%A6%81" data-line="6" class="code-line">
<a class="header-anchor-link" href="#%E8%AA%B2%E9%A1%8C%E3%81%AE%E6%A6%82%E8%A6%81" aria-hidden="true"></a> 課題の概要</h1>
<p data-line="8" class="code-line">ブルーモのアプリでは、下記のようにユーザーの資産状況をグラフ表示する機能があり日毎の資産状況をグラフで見ることができます。<br>
以前からこのグラフの描画速度が遅いという課題があったのでバックエンド側でこのグラフの元となる履歴取得APIのパフォーマンス改善をするタスクに取り掛かりました。<br>
目標値は「本番環境でのレスポンス時間の99パーセンタイルを1/5にする」でした。</p>
<p data-line="12" class="code-line">※テスト環境の画面です</p>
<p data-line="14" class="code-line"><img src="https://storage.googleapis.com/zenn-user-upload/88a64356a71e-20250430.png" alt="資産総額グラフ" loading="lazy" class="md-img"></p>
<h1 id="%E5%AE%9F%E9%9A%9B%E3%81%AE%E3%82%BF%E3%82%B9%E3%82%AF%E3%81%AE%E6%B5%81%E3%82%8C" data-line="16" class="code-line">
<a class="header-anchor-link" href="#%E5%AE%9F%E9%9A%9B%E3%81%AE%E3%82%BF%E3%82%B9%E3%82%AF%E3%81%AE%E6%B5%81%E3%82%8C" aria-hidden="true"></a> 実際のタスクの流れ</h1>
<h2 id="n%2B1%E3%81%AE%E8%A7%A3%E6%B6%88" data-line="18" class="code-line">
<a class="header-anchor-link" href="#n%2B1%E3%81%AE%E8%A7%A3%E6%B6%88" aria-hidden="true"></a> N+1の解消</h2>
<p data-line="20" class="code-line">まず私はこのタスクの着手開始時点で履歴取得処理のN+1解消を実施しました。以前から履歴取得処理がN+1になってしまっているのではないかと薄々気づいたのと大体データ取得のボトルネックはDB周りだと思い込んでいたので特に調査もせずそこが原因だとしてその解消を始めました。</p>
<p data-line="22" class="code-line">N+1解消後にテスト環境で履歴データが多いユーザーを対象に計測をしたところ目標値に全く届いておらず、また修正前の計測を行なっていなかったので修正による効果の測定もできませんでした。</p>
<aside class="msg message"><span class="msg-symbol">!</span><div class="msg-content">
<p data-line="25" class="code-line"><strong>教訓1: パフォーマンス改善は計測から始める</strong></p>
<ul data-line="26" class="code-line">
<li data-line="26" class="code-line">改善前と改善後の計測結果を比較することで、効果を正確に評価できる</li>
<li data-line="27" class="code-line">比較をしやすくするためになるべく同じ環境・条件での計測をすること</li>
</ul>
</div></aside>
<h2 id="trace%E3%83%AD%E3%82%B0%E3%81%AE%E8%BF%BD%E5%8A%A0" data-line="30" class="code-line">
<a class="header-anchor-link" href="#trace%E3%83%AD%E3%82%B0%E3%81%AE%E8%BF%BD%E5%8A%A0" aria-hidden="true"></a> Traceログの追加</h2>
<p data-line="32" class="code-line">次にボトルネックを突き止めるために各処理にTraceログを仕込み、それぞれの処理での処理時間を計測することにしました。<br>
ただしTraceログでの計測では各関数の処理時間しか分析できず、メモリ消費量やCPU使用量が計測できずに原因の深掘りができませんでした。</p>
<aside class="msg message"><span class="msg-symbol">!</span><div class="msg-content">
<p data-line="36" class="code-line"><strong>教訓2: 適切な計測ツールを使う</strong></p>
<ul data-line="37" class="code-line">
<li data-line="37" class="code-line">メモリ消費量やCPU使用量も計測できるような計測ツールを使う</li>
</ul>
</div></aside>
<h2 id="trace%E3%83%AD%E3%82%B0%E3%81%AE%E5%88%86%E6%9E%90%E3%81%A8o(n%C2%B2)%E3%81%AE%E8%A7%A3%E6%B6%88" data-line="40" class="code-line">
<a class="header-anchor-link" href="#trace%E3%83%AD%E3%82%B0%E3%81%AE%E5%88%86%E6%9E%90%E3%81%A8o(n%C2%B2)%E3%81%AE%E8%A7%A3%E6%B6%88" aria-hidden="true"></a> Traceログの分析とO(N²)の解消</h2>
<p data-line="42" class="code-line">最初に述べたようにパフォーマンス問題はほとんどDBがボトルネックであるという思い込みがあったのでTraceログを見ている時も当初はDB周りの処理時間ばかり気にしていました。<br>
しかしさらに詳しくTraceログを追っていった結果、ボトルネックとなっていたのはDB処理ではなくアプリケーションロジックでの評価額計算部分だと判明しました。<br>
各銘柄に対して全体に対する評価額の割合を計算する処理があったのですが、その計算のたびに全体の評価額を計算していたため保有銘柄数をNとして計算量のオーダーがO(N²)となっていました。<br>
最終的には全体の評価額の計算をメモ化することによって計算量を削減し、結果として3倍以上レイテンシが改善されました。</p>
<aside class="msg message"><span class="msg-symbol">!</span><div class="msg-content">
<p data-line="48" class="code-line"><strong>教訓3: データ分析をして改善点を洗い出す</strong></p>
<ul data-line="49" class="code-line">
<li data-line="49" class="code-line">問題の原因について先入観を持たず、データからボトルネックを分析して影響が大きい箇所から改善を行う</li>
<li data-line="50" class="code-line">DB以外がボトルネックになることも普通にある</li>
</ul>
</div></aside>
<h2 id="pprof%E3%81%AE%E5%88%86%E6%9E%90%E3%81%A8gc%E3%81%AE%E3%83%81%E3%83%A5%E3%83%BC%E3%83%8B%E3%83%B3%E3%82%B0" data-line="53" class="code-line">
<a class="header-anchor-link" href="#pprof%E3%81%AE%E5%88%86%E6%9E%90%E3%81%A8gc%E3%81%AE%E3%83%81%E3%83%A5%E3%83%BC%E3%83%8B%E3%83%B3%E3%82%B0" aria-hidden="true"></a> pprofの分析とGCのチューニング</h2>
<p data-line="55" class="code-line">O(N²)の解消後にチームメンバーからGoのプロファイリングツールである<a href="https://github.com/google/pprof" target="_blank" rel="nofollow noopener noreferrer">pprof</a>が既に導入されていることを後で教えてもらったので計測と分析を行ったところ、処理時間の約半分がガベージコレクション（GC）に費やされていることがわかりました。<br>
下記がpprofによる計測結果なのですが、大量のデータを処理する過程で頻繁なメモリアロケーションとGCが発生しているようでした(右半分がGCによる処理時間)。</p>
<p data-line="58" class="code-line"><img src="https://storage.googleapis.com/zenn-user-upload/d0673880c7b5-20250502.png" alt="pprof_改善前" loading="lazy" class="md-img"></p>
<p data-line="60" class="code-line">対策としてGCの頻度を減らすためにGo1.19から導入された<code>GOMEMLIMIT</code>環境変数を利用するようにしました。<br>
Go1.18まではGCは使用メモリ量が一定割合以上増えると発生するようになっておりその頻度を<code>GOGC</code>という環境変数で制御していましたが、Go1.19からは<code>GOMEMLIMIT</code>によって上限の使用メモリ量を指定することでGCの発生タイミングを制御できるようになっていたのでこちらを利用しました。<br>
参考：<a href="https://speakerdeck.com/hagatake/go1-dot-19karashi-merugcnotiyuningufang-fa" target="_blank" rel="nofollow noopener noreferrer">Go1.19から始めるGCのチューニング方法</a></p>
<p data-line="64" class="code-line">このチューニングにより、GCの頻度が減少しレイテンシが改善されました(右1/5程度がGCによる処理時間)。<br>
またこのチューニングを行ったことによりAPIのレスポンスだけではなく他のバッチ系の処理も高速化されたため恩恵が大きかったです。</p>
<p data-line="67" class="code-line"><img src="https://storage.googleapis.com/zenn-user-upload/b6b3bf5dbfbb-20250502.png" alt="pprof_改善後" loading="lazy" class="md-img"></p>
<aside class="msg message"><span class="msg-symbol">!</span><div class="msg-content">
<p data-line="70" class="code-line"><strong>教訓4: GCの影響も考慮する</strong></p>
<ul data-line="71" class="code-line">
<li data-line="71" class="code-line">メモリ使用量の多いアプリケーションではGCが大きなオーバーヘッドになり得る</li>
<li data-line="72" class="code-line">Go x Kubernetesの環境では<code>GOMEMLIMIT</code> によるチューニングが効果的</li>
<li data-line="73" class="code-line">Goでのメモリ使用量やCPU処理時間の計測はpprofを使えば良さそう</li>
</ul>
</div></aside>
<h1 id="%E6%9C%80%E7%B5%82%E7%B5%90%E6%9E%9C" data-line="76" class="code-line">
<a class="header-anchor-link" href="#%E6%9C%80%E7%B5%82%E7%B5%90%E6%9E%9C" aria-hidden="true"></a> 最終結果</h1>
<p data-line="78" class="code-line">これらの改善の結果、テスト環境での履歴データが多いユーザーでのパフォーマンスも改善され、目標としていた「本番環境でのレスポンス時間の99パーセンタイルを1/5にする」を達成することができました。</p>
<h1 id="%E6%95%99%E8%A8%93%E3%81%AE%E3%81%BE%E3%81%A8%E3%82%81" data-line="80" class="code-line">
<a class="header-anchor-link" href="#%E6%95%99%E8%A8%93%E3%81%AE%E3%81%BE%E3%81%A8%E3%82%81" aria-hidden="true"></a> 教訓のまとめ</h1>
<p data-line="82" class="code-line">今回のタスクを通じた教訓は以下の通りです。</p>
<ol data-line="84" class="code-line">
<li data-line="84" class="code-line">
<strong>パフォーマンス改善はまず計測から始める</strong>
<ul data-line="85" class="code-line">
<li data-line="85" class="code-line">改善前と改善後の計測結果を比較することで、効果を正確に評価できる</li>
<li data-line="86" class="code-line">比較をしやすくするためになるべく同じ環境・条件での計測をすること</li>
</ul>
</li>
<li data-line="87" class="code-line">
<strong>適切な計測ツールを使用する</strong>
<ul data-line="88" class="code-line">
<li data-line="88" class="code-line">メモリ消費量やCPU使用量も計測できるような計測ツールを使う</li>
</ul>
</li>
<li data-line="89" class="code-line">
<strong>データ分析をして改善点を洗い出す</strong>
<ul data-line="90" class="code-line">
<li data-line="90" class="code-line">問題の原因について先入観を持たず、データからボトルネックを分析して影響が大きい箇所から改善を行う</li>
<li data-line="91" class="code-line">DB以外がボトルネックになることも普通にある</li>
</ul>
</li>
<li data-line="92" class="code-line">
<strong>GCの影響も考慮する</strong>
<ul data-line="93" class="code-line">
<li data-line="93" class="code-line">メモリ使用量の多いアプリケーションではGCが大きなオーバーヘッドになり得る</li>
<li data-line="94" class="code-line">Go x Kubernetesの環境では<code>GOMEMLIMIT</code> によるチューニングが効果的</li>
<li data-line="95" class="code-line">Goでのメモリ使用量やCPU処理時間の計測はpprofを使えば良さそう</li>
</ul>
</li>
</ol>
<p data-line="97" class="code-line">また弊社のようなスタートアップ企業では改善速度の重要度を高く設定しているため、計測が重要だとわかってはいるものの計測の環境が整っていないことを理由として計測をスキップしてしまうことも多々あります。そのような状況に直面した場合は将来のリターンやランニングコストなどを加味した上で計測環境を整えることを検討することも重要だと今回のタスクを通じて感じました。</p>
<h1 id="%E7%B5%82%E3%82%8F%E3%82%8A%E3%81%AB" data-line="99" class="code-line">
<a class="header-anchor-link" href="#%E7%B5%82%E3%82%8F%E3%82%8A%E3%81%AB" aria-hidden="true"></a> 終わりに</h1>
<p data-line="101" class="code-line">今回の高速化タスクでは</p>
<ul data-line="103" class="code-line">
<li data-line="103" class="code-line">計測をしないでとりあえず気になるところを改善する</li>
<li data-line="104" class="code-line">雑な計測する</li>
<li data-line="105" class="code-line">DBがボトルネックだと思い込む</li>
</ul>
<p data-line="107" class="code-line">などの失敗により無駄な時間を割いてしまいましたが目標としていたパフォーマンス改善は実現でき、また結果として失敗からの学びも大きかったです。<br>
今後は今回の学びを活かし生産性向上に繋げるととに、このような日頃のタスクにおける小さい失敗についても学びを共有して知見を貯めることを意識して強いエンジニア組織を作っていきたいと思います。</p>
<h1 id="we-are-hiring!" data-line="110" class="code-line">
<a class="header-anchor-link" href="#we-are-hiring!" aria-hidden="true"></a> We are hiring!</h1>
<p data-line="112" class="code-line">ブルーモでは次世代の金融システムを作る仲間を募集しています！<br>
エンジニア、デザイナー、PdM、事業開発などさまざまポジションで募集をしているので興味がある方は下記の採用ページを覗いてみてください！</p>
<p data-line="115" class="code-line"><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__08d6f62e56316" src="https://embed.zenn.studio/card#zenn-embedded__08d6f62e56316" data-content="https%3A%2F%2Fcareers.bloomo.co.jp%2F" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://careers.bloomo.co.jp/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://careers.bloomo.co.jp/</a></p>


グダグダなパフォーマンス改善からの学び

Discussion