ISUCON13 に New Relic を導入して挑んできた

New Relic Advent Calendar 2023 に投稿した記事です。

こんいす〜!今年も ISUCON に参加してきました!コンテスト中に New Relic を使ってみたので導入してみた感想とか苦労したことを書いてみます。

ISUCON とは

ISUCON は「Iikanjini Speed Up Contest(いい感じに スピードアップ コンテスト)」の略で、お題となるWebサービスを決められたルールの中で高速化を図るチューニングコンテストです。

今年のお題は「ISUPipe」というライブ配信サービスの高速化がテーマになっており、 ISUPipe の投げ銭機能により、送金・寄付された金額がスコアになるといったものでした。

チーム情報

チーム名: あしたから本気出す

言語: Pyhton

最終スコア: 6,885

事前に準備したこと

去年初参加した ISUCON12 では New Relic の導入がうまくいかず 2 時間半ぐらいかかったので、今年は色んな過去問を解き New Relic の導入パターンを学んでおきました。

インフラエージェントはコマンド一発でインストールが可能なのですが、 APM に関してはアプリケーションがコンテナ上で動いているのか pyenv で動いているのかによって微妙に導入方法が変わってくるので、本番で New Relic を使おうという人は事前に導入方法を確認しておくと良いと思います。

ISUCON13 Python の環境で APM を導入する方法

今年は virtualenv 上で動いていたので、最終的には以下のような手順で APM を導入することが出来ました。

1.仮想環境をアクティベート

. .local/share/virtualenvs/python-RZQ_zDKY/bin/activate

2.仮想環境上で newrelic ライブラリをインストール

pip install newrelic

3.newrelic.ini を作成

4.isupipe-python.service を以下のように変更

[Unit]
Description=isupipe-python
After=syslog.target
After=mysql.service
Requires=mysql.service

[Service]
WorkingDirectory=/home/isucon/webapp/python
EnvironmentFile=/home/isucon/env.sh
# Environment を追加★
Environment=NEW_RELIC_CONFIG_FILE=/home/isucon/newrelic.ini

User=isucon
Group=isucon
# ExecStart を変更★
# ExecStart=/home/isucon/.x pipenv run python app.py
ExecStart=/home/isucon/.x pipenv run /home/isucon/.local/share/virtualenvs/python-RZQ_zDKY/bin/newrelic-admin run-program python app.py
ExecStop=/bin/kill -s QUIT $MAINPID

Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

苦労した点

という感じにさらっと書きましたが実際には本番で New Relic の導入に手こずりました。

pipenv が使われてそうだったので pipenv install newrelic を実行してインストールしたものの newrelic-admin が見つからないといったエラーが出てしまいました。

その後色々考えたところ手順1で書いたような仮想環境をアクティベートした後に newrelic をインストールしたところ上手くいきました。

あとは Environment に記述した内容が最初絶対パスになっていなかったため newrelic.ini が見つからないというエラーも出てしまい、なんやかんやあって今年は APM の導入に 1 時間ぐらいかかってしまいました。

導入に時間かかっては元も子もないので来年ももし New Relic を導入するならもっと早く APM を入れられるようになりたい…!

New Relic を使って分析してみた

ベンチマーカーを回して負荷を確認した所 mysql の使用率が高いことは分かっていました。

New Relic の Database の結果を見ると MySQL users select の時間が掛かっていることが分かりました。

Transactions のページで Throughput 順にソートすると get_icon_handler が多く叩かれていることが判明しました。

コードを読んでみると users テーブルから ユーザの ID を取得した後に icons テーブルからユーザ ID に紐付く画像のバイナリーデータを取得していました。

そこで DB に登録されたバイナリーデータを参照するのではなく、ディスク上に保存された画像ファイルを参照するようにすれば users テーブル(と icons テーブル)が叩かれずに済むので負荷が減るのではと考えました。

上記のような修正を行った結果 Most time consuming における users テーブルのランキングを下げることができ、スコアを上昇させることが出来ました!

感想

今年もなんやかんや導入に手こずってしまいましたが去年よりは早く APM を使える状態に出来て良かったなと思いました。

ISUCON ではしばしばアクセスログの分析には alp 、スロークエリログの分析には pt-query-digest 等が用いられることが多いですが、これは CLI を使って分析する手法なので New Relic よりもこっちの方が手軽に導入することが出来ます。

一方 New Relic はベンチーマーカーを回した結果を GUI 上で可視化することが出来るのでアプリケーション全体を俯瞰して見やすいというのが強みなのかなと考えています。

とは言ったものの今メトリクスを見返してみるともっと他に優先するべき変更点等があったなという気もしていて、まだまだ観察力が足りないなと痛感しました。

今年も ISUCON を楽しんで参加することが出来ました。運営の皆様本当にありがとうございます。

また来年も参加したいと考えているので、次こそは1万点を目標に頑張っていきたいと思います。

New Relic の無料プランを約 1 年間ほど使ってみた感想

はじめましての方ははじめまして、そうでない方はこんにちは。どうも菊池宣明(@kikulabo)です。

New Relic Advent Calendar 2022 というものに参加したので New Relic に関するブログを1 本書きました。

このブログを通して少しでも役立つ情報を提供できたら幸いです。


前置き

友人と一緒に開発をしたサービスに New Relic を導入して約 1 年間ほど経過しました。

このサービスはまだ収益が出ているものでは無いため、コストの観点から New Relic の無料プランの範囲内で利用しています( New Relic さん本当にごめんなさい)。

この記事では実際に無料プランを 1 年間使ってみてどうだったか、注意するべき点は何かについて書いていきます。

New Relic 料金体系について

まず、無料プランの話の前に現在の New Relic の料金体系について簡単に説明します。

<参考記事>

newrelic.com

2022 年 12 月時点では取り込まれたデータ量とコア/フルプラットフォームユーザ数に応じて料金が変わってくるモデルになっています。

New Relic の料金モデルは他のサービスと比べると特徴的であり、一般的なモニタリングサービスとの相違点を以下にまとめました。

  • 一般的な SaaS 系のモニタリングサービス
    • 監視エージェントの導入台数分だけ課金が発生
    • 例えばスケールアウト等でインスタンスの台数が増えるとその分課金が追加で発生する
    • サービスを利用するユーザ数が増えても請求金額は変わらない
  • New Relic
    • コア/フルプラットフォームユーザ数単位での課金形式
    • 監視対象のホストがいくつ増えても課金額は変わらない
    • 無料で追加できるベーシックユーザというものも存在するが機能が限られておりダッシュボードとログの確認程度しか出来ない

このような違いがあるのでモニタリングツールを選ぶ際は、どんな権限を持ったユーザをどれくらい発行する必要があるのか、監視対象のホストがどれくらい存在するのかを考慮してみると良いのかなと考えています。

New Relic の無料プランに含まれている内容

1 名分の無料フルプラットフォームユーザーと取り込みデータ量が 1 カ月当たり 100 GB までが無料プランの範囲内です。

フルプラットフォームユーザというのは名前の通り New Relic の全ての機能を利用できる権限を持ったユーザのことを指します。

僕たちが開発しているサービスで現状 New Relic 周りの設定をしているのは僕 1 人だけなので、今のところ 1 ユーザに制限されていても特に問題を感じたことはありませんでした。

また、 データ取り込み量に関しても 1 カ月で約 30 GB 程度しか発生していないため、僕たちが作っているサービスでは問題無くクリアしています。

New Relic を導入してみた所感

そもそもモニタリングって必要なの?という所から、とあるインシデントをきっかけに New Relic の導入を行い信頼性向上を目指した結果、チーム内で以下のような変化が起きました。

過去を振り返り分析してから行動するようになった

メトリクスの計測と比較を行えるようになったので何かしらのイベントを新規に開催する際に、過去のデータを参考にして負荷に耐えられるかどうかを事前に判断し行動できるようになりました。

また、僕たちはちょっと特殊な使い方もしているのですが、 New Relic Flex を使って登録ユーザ数やマッチング数等といったデータをメトリクスとして取得し、ダッシュボード上に表示させ KPI 分析を行うようにしています。

ダッシュボードにまとめてしまえばベーシックユーザでも閲覧することが出来るので、週に 1 回メトリクスを一通り確認し、結果を考察、次に僕らがやるべきことを考え行動するといった流れをチーム内に浸透させることが出来ました(この流れを癖付けるまでに半年以上かかりました)。

エラーの検知および改善を行うきっかけを作れた

これまでエラーは全て Slack に通知するといったことをやっていたので、以下のような問題が発生してました。

  • 重要なエラーかどうかがぱっと見分からない
  • 定期的に出ているエラーなのかどうかの分析がし辛い
  • エラー発生箇所の特定が難しい

こういった課題に対して New Relic の APM を使用することで、どんなエラーが、いつどれくらい発生しているかを可視化することができ、またエラー発生箇所の特定も容易になりました。

影響が小さいエラーに関しては定期的に確認を行うようにしており、実際にこの機能のおかげでバグを検知し直すこともできました。

無料プランを使用する際に気をつけなければいけないこと

無料プランの範囲内で使う際に気をつけないといけないポイントとして、個人的には Synthetic チェックの回数制限を注意する必要があるのかなと考えています。

フルプラットフォームユーザであれば New Relic Synthetic のモニターを作成することは出来るもののチェック回数に制限があるため、無料利用枠だとメトリクスの取得頻度をそこそこ延ばさないとモニターを作成することが出来ません。

一方、 New Relic Synthetic のうち Ping モニターに関してはチェック数を消費しないため、要件が合うならこちらを利用する分には問題無いのかなと思います。

※ New Relic Synthetics の Ping モニター は ICMP Ping ではなく、 HTTP クライアントとして WEB ページの HTML ソースを取得するものです。

<参考記事>

newrelic.com

僕たちのサービスでは New Relic Synthetics を使わずに自前の監視ツールを使用してチェックを行うようにしています。


実は Advent Calendar 用に投稿しようと思ってたネタが他の人と被ってしまい急遽内容を変更して記事を投稿しました(言い訳)。

最後まで読んで頂きありがとうございました。

Daily Note 2022-10-10

この記事は僕が Slack にメモした内容を日次で自動的に記事として投稿したものです。

2022-10-10 08:23:25

【初心者】Amazon ElastiCache for Redis を使ってみる - Qiita

qiita.com

2022-10-10 21:19:30

[アップデート]AWS BackupがAmazon Auroraに対応しました | DevelopersIO

dev.classmethod.jp