パフォーマンスを向上させた話

About

この記事は LITALICO Engineers Advent Calendar 2021 2つ目 5日目の記事です。

株式会社LITALICOでSREグループのマネージャをしております、 tjinjinです。今日で連続投稿は打ち止めです。

今回はパフォーマンスを向上させた話を書きます

変更前後

CPU使用率

レイテンシ

今回の対応でCPU使用率の定価とレイテンシの改善（山がなくなった）ができました。個別のAPIで見ていくと数倍程度のレイテンシ向上をできたものもあります。

何をしたのか

今回具体的には下記の対応を実施しました。

• BFFからのコンテナ間通信時の非同期処理のバグ解消
• OPcacheの導入
• APIのレスポンスの圧縮 & Cloudfront周りの設定を適正化

それぞれどのようなことをしたのか個別に書いていきます。

どのように調査したか

BFFからのコンテナ間通信時の非同期処理のバグ解消

まず遅い、という状況を明らかにするためdatadogを使っていくつかの画面に絞ってどのくらい遅いのか？を調査しました（RUM/APMなどが入ってなかったためログベースで確認）

全体的に遅かったのですが、特にBFFからのレスポンスが遅い状況でした。そこでBFFの処理の確認をしました。

上記のようにユーザからのリクエストに応じて必要な情報を各アプリケーションから集める処理をしています。

アプリケーションコード確認すると非同期で各アプリケーションを呼び出すような書き方になっていましたが、ログ見ると毎回同じ順番でコンテナを呼び出しておりました。

調査を進めていくとhttpのclientとして使っているguzzleの書き方が悪かったことがわかりました。内容としては下記のブログを参考にしました。

guzzleのClientを複数作るとasyncでも直列処理になる - takekoshi's blog

変更前後で下記のくらいの速度向上ができました。

API	変更前	guzzle修正
A	1.86s	1.66s
B	603ms	507ms
C	3.50s	2.99s

OPcacheの導入

phpのパフォーマンス向上に効果があると聞いたことがあったので、即座に試しました。もっと速く入れておけばと反省しております。。。

OPcacheの概要に関してはこちらの記事を参考にさせていただきました。 Zend OPcacheの速さの秘密を探る

API	変更前	guzzle修正	guzzle修正 + OPcache導入
A	1.86s	1.66s	1.10s
B	603ms	507ms	118.09ms
C	3.50s	2.99s	2.10s

APIのレスポンスの圧縮 & Cloudfront周りの設定を適正化

ここまで簡単にできそうなAPIの高速化を対応したので、次にlighthouseなどを使ってブラウザからの状態を確認しました。その中で以下の問題に気付きました。

• APIのレスポンスが圧縮されておらずかなり大きいレスポンスを返していた
• Cloudfrontからjsなどを配信しているが、http1.1になっていた

まずAPIレスポンスを確認しました。APIはOpenresty + phpfpmの構成になっていたため、Openrestyの設定を見直しました。

Cloudfrontの配信方法の見直しも行い最終的な結果は下記となりました。

API	変更前	guzzle修正	guzzle修正 + OPcache導入	guzzle修正 + OPcache導入 + レスポンスをgzip化
A	1.86s	1.66s	1.10s	588ms
B	603ms	507ms	118.09ms	108.43ms
C	3.50s	2.99s	2.10s	1.88s

まとめ

今回インフラ観点でのパフォーマンス向上の施策を実施していきました。アプリケーション側で直すべきところはまだあるので、引き続きやっていきます！

明日は @tatsuya-fujii-LITALICO のTypeScriptの話です！入門してCDK書きたい！