概要
みなさんこちらの絵は何に見えるでしょうか。
カントリーマアムの断面にも見えますよね? おしい!! これは New Relic 上に残された API サーバのレスポンスタイムです。
弊社サービスは簡単に図で表すと、AWS に配置された以下のような構成となっています。
(図の EC2 のところは一部 ECS に置き換わっているのですが、とりあえず雰囲気が伝われば。)
今回、問題になったのは 上記図における API のところです。
なんだかレスポンスが遅くなったぞという話があがってきました。
API サーバですので、インターネットからの1リクエストに対して、ウェブサーバから何回か API サーバへリクエストがいくわけですから
API に対する 1 リクエストのレスポンスが 300ms だとしても、
ユーザのブラウザ側への応答時点で、5〜10秒のレスポンスになりますので、もうサービスとして致命的になってきます。
そこでどれだけこのカントリーマアム、、、もとい、New Relic のグラフからサクッと原因を突き止め、改善したかを共有します。
調査
まずあからさまにグラフの盛り上がっている箇所にマウスオーバーすると、Memcached と表示されます。
さらに、Transactions 一覧に重かったリクエストの代表選手がいるので、上位のものをクリックします。
クリックすると、Throughput うちデータベースへのリクエストが表示されました
Memcached get が1秒近くかかっている。これはなんだ。。。
ウェブサーバが セッションや API応答結果を保存するために Memcached 使う想定はあったが、API サーバから Memcached を呼ばれている想定はなかった。
その上で、セキュリティグループで不要なポートや接続元を整備していました。検証が不十分だったということが反省点ではあるものの、
New Relic を使うことで一瞬で原因の特定ができました。
APIサーバで Memcached を使う処理を無効化することで、問題は難なく収束しました。(ウェブサーバでキャッシュしているものを、API サーバでも同じデータをキャッシュするような処理になっていたため無効化した)