📑

NewRelicを使って2日間の作業で年間1000万円のコスト削減に成功した話

2023/06/19に公開

https://www.youtube.com/live/sOe1EKqhEB4?feature=share

はじめに

弊社では、システムのオブザーバビリティを高めるために、NewRelicを導入し、インフラ・DB・アプリの内部状況の可視化に取り組んでいます。
本記事では、オブザーバビリティの向上から課題の解決に至るまでの一例を紹介します。

オブザーバビリティに対する課題感

ユーザ様やシステム利用者からの問い合わせでシステムの問題を発見し、その問題の解決のために開発者がシステムの状況や仕様をログやソースコードなどから特定し、改善を行っていました。
これでは、システムの問題の発見が受動的になってしまう場合があったため、問題の解決が後手に回ってしまい、ユーザ満足度の低下につながる要因となり得ます。
また、開発者の経験や勘が必要で、誰でも気軽にできるものではありませんでした。

NewRelicを導入することで、オブザーバビリティを強化できました。
ダッシュボード機能を活用することで、インフラ・DB・アプリの内部状況をシームレスに観測できるようになり、問題発見を先んじて行えるようになりました。
また、ある一定の知見を持つ開発者であれば誰でもシステムの内部状況の観測が可能となりました。
ダッシュボードの一例

パフォ会

弊社では「パフォ会」という活動を週次で実施しています。
NewRelicのダッシュボードなどを使いシステムの状況を確認する会で、インフラメンバーに限らず、有志の開発者が集まって活動しています。
ユーザ影響のありそうな問題や定常時とは異なる振る舞い、定常的な挙動ではあるが改善の余地がある振る舞いなどの原因を特定することを目標としています。

DBへの負荷が高まっていることへの気づきは、このパフォ会でのものです。

DBの負荷が高くなっていることへの気づき

これは全AuroraインスタンスのDB Loadを表したグラフです。
DB Loadの遷移を表したグラフ
(全てのAuroraインスタンス)

Amazon Auroraを使用しており、vCPU数の設定は8です。
DB負荷を適切な範囲に留めるために、vCPU数の設定を超えないようにしたいのですが、グラフをみるとvCPU数が超えてしまっているところが何箇所かあります。
また、vCPU数の範囲内ではあるものの、定期的に山ができているところがあります。
これらのことから、DB負荷が高くなっていることに気づきました。

次に、グラフをドリルダウンし、定期的にできているこの山について詳しく見ていきます。
これは、特定のAuroraインスタンスでの7時間のDB Loadを表したグラフです。
ここから、毎時40分ごろにDB Loadの山ができていることがわかりました。
7時間分のDB Loadを表したグラフ
(特定のAuroraインスタンスのみ)

APMで課題を深掘り

ここからは、課題となっている処理の根本原因を探るために、APMを見ていきます。
Transactionsで確認できるグラフの中から、毎時40分ごろに山ができている処理を探し、課題となっている処理を見つけられました。

これは、テーブルに対する処理にかかる時間の内訳を表したグラフです。
問題となっている処理にかかった時間の内訳

グラフをみると、毎時40分ごろに特定のテーブルに対するSELECTの処理に長い時間をかけてしまっていることがわかりました。

さらに見ていくと、問題となっている処理時間の80%以上がテーブルに対するSELECTの処理時間で占められていることがわかりました。
テーブルに対する処理にかかる時間の内訳

この表の下にあるTransaction tracesTransactionTrace Detailsで問題となっている処理を深ぼっていくと、ボトルネックとなっているクエリ文とEXPLAINの結果を確認できました。
対象のクエリのEXPLAIN結果

ここまでの調査で、どの処理がボトルネックであるかがわかりました。

効果測定

ここまでの調査を元にクエリ文を改修し、どのような改善効果があったのかを見ていきます。

DB Load

リリース前後のDB Loadの遷移
左のグラフはリリース前のDB Loadの遷移です。
定期的な山とvCPU数の設定を超えてしまっている箇所がありました。
リリース後は、右のグラフで確認できるように、定期的な山が消えてvCPU数が設定を下回るようになりました。

このことから、DBへの負荷を適切な範囲で留めることができたことが確認できました。

SELECTの処理時間

リリース前後のSELECTにかかる処理時間の遷移
リリース後にテーブルに対するSELECTの処理時間も大幅に削減できました。

AuroraのI/O課金量

さいごに、AuroraのI/O課金量がどうなったかを見ていきます。

  • リリース前のコスト: 約800(ドル/1日)
  • リリース後のコスト: 約600(ドル/1日)

削減コストは年間約73000ドル。
1ドル130円で換算すると日本円にして年間約1000万円の削減に成功しました。

さいごに

本記事では、オブザーバビリティの向上から課題の解決に至るまでの一例として、DB負荷が高まっていることの発見と改善活動、その結果をご紹介しました。

NewRelicを導入したことで、課題を能動的に発見し改善活動に繋げられるようになりました。
また、インフラやDBの気づきからAPMの活用に繋げることで、アプリケーションの改善がスムーズになりました。
そして、改善活動の結果、DB負荷を大きく軽減し、AuroraのI/O課金のコストを大幅に削減できました。

NE株式会社の開発ブログ

Discussion