ハッカー飯に New Relic を導入して実践した3つのこと 菊池 宣明

セッションの概要 New Relic をハッカー飯に導入して僕らが実際にやってきた3つのことを共有します。 これから New Relic を導入するけど何から始めれば良いのか分からない…という方の参 考になれば幸いです。

自己紹介 菊池 宣明 ● 本業は X-Tech 5 で SRE 業務やってます ● 今年から副業でハッカー飯の開発メンバーとしてジョインしました 趣味 ● ゲーム（スマブラ、Fortnite） 好きな AWS サービス ● AWS サポート @kikulabo

技術や知識でアイデアを形にする人々(=ハッカー)が、 ご飯を囲むような気軽さで、語り合い、教え合い、繋がれるオンラインプラットフォーム

No content

No content

ハッカー飯の特徴

● イントロダクション ○ 監視導入の背景 ○ 何故 New Relic を選んだのか ● New Relic 導入して実践した3つのこと ○ ①監視の設定 ○ ②New Relic Flex を使った KPI 分析 ○ ③パフォーマンス観測会 ● まとめ/今後の展望 本日お話しする内容

イントロダクション 〜監視導入の背景および New Relic の選定理由〜

ユーザが連絡することで運営側が障害を認知 監視導入の背景 ① ② ③ ④ .NET 5 から .NET 6 へ バージョンを上げるぞ！ インフラ側の必要な作業を行わずに作業を終了 ハッカー飯にログイン出来ない人が発生 ハッカー飯運営

● ハッカー飯では監視ツールとして New Relic を選定 ○ 選定理由①: １ユーザであれば全ての機能を期間制限なく無料利用枠で使用できるため ■ 月間100GBまでのデータ容量であれば無料なのでお手軽に始められる ○ 選定理由②: ホスト単位での課金が発生しないため ■ 監視するホストの台数が増えても料金が変化しないので安心して利用できる ○ 選定理由③: NRUG といったコミュニティが存在し中の人との距離感が近い（と感じたから） ■ 知見やハマりポイントの共有を行う場が提供されている（他のサービスだとあまり無いかも） New Relic を選んだ理由

● Agent に関して ○ EC2 の t3.nano に New Relic Agent をインストールしたところメモリ不足でインストールに失敗 ■ 小さいインスタンスサイズで検証する時は注意が必要かも ○ New Relic に送る必要が無いログ（デバッグログ等）はドロップフィルタールールで制御する ■ ログの転送量に応じてコストが発生するので制限をかけておく ● インテグレーション機能に関して ○ メトリクスの取得に API コール料金が発生することがあるので初めのうちは利用料金を定期的に確認しておく ■ ※ New Relic に限った話では無いです ○ 例えば AWS の場合、 インテグレーション機能を使用すると GetMetricData API という項目の課金額が上昇する New Relic 導入に関する注意点

New Relic 導入して実践したこと 〜ハッカー飯での事例〜

● まず始めに New Relic Synthetics を導入してサービスの死活監視を実施 ○ 監視導入の背景にもある通りこれまで運営側が障害認知する術が無かったため一番初めに実施 ○ New Relic Synthetics には様々な種類のモニターが存在し用途に応じて使い分けることが可能 ■ Pingモニター ● URLの死活監視に利用可能。最も単純なモニタータイプ。 ■ ScriptBrowser ● WEB サービスのログイン確認などユーザー操作をシミュレートした監視 ■ APITest ● http-request モジュールを使用しエンドポイントへの HTTP 呼び出しを行い API サービスを監視 etc... 実践内容①: 監視の設定 ~外型監視編~

● その他ユーザに影響が出そうなものをアラートとして設定 ○ ゴールデンシグナルに基づいて監視するメトリクスを一旦選定 ■ メモリ使用率、エラー発生率、レスポンスタイム等を監視 ● 初めのうちは閾値の設定等難しく感じるかもしれないが、pre-built alerts 機能を使用すると簡単に作成できる 実践内容①: 監視の設定 ~ゴールデンシグナル~ ゴールデンシグナルに関して: https://sre.google/sre-book/monitoring-distributed-systems/

実践内容②: New Relic Flex を使った KPI 分析 ● イベントや企画等の効果を定量的に計測するためにハッカー飯では以下の項目を一旦 KPI として設定 ○ 登録ユーザ数 ○ イイねリクエスト数 ○ マッチング数 ● New Relic Flex 定期的に DB にクエリを投げデータを取得しグラフ化を実施

New Relic Flex について ● New Relic Flex とは？ ○ New Relic の標準機能では取得できない独自のデータ等をメトリクスとして取得できる機能 ■ New Relic Infrastructure エージェント導入後、以下のような YAML ファイルを作成する integrations: - name: nri-flex interval: 3h ←メトリクスを取得する間隔 timeout: 5s config: name: NriFlexHackermeshiDb apis: - name: NriFlexHackermeshiDbUsersRegistered commands: - run: echo -n "RegisteredUsers " && sqlite3 ***.db 'select ~~~' ←定期実行するコマンド split: horizontal split_by: \s+ row_start: 1 set_header: [RegisteredUsers, Count] New Relic Flex に関する記事: https://newrelic.com/jp/blog/how-to-relic/how-to-use-new-relic-flex

実践内容③: パフォーマンス観測会 ● 1週間に一度メトリクス全体を一通り確認 ○ アラートが発生していなくとも異常が発生していないかを確認するため ■ 確認ポイント ● エラーが起きていないか ● レスポンスタイムに異常が起きていないか ● インフラのリソース使用状況に問題が起きていないか ○ 定期的にメトリクスを確認することで上記のような異常がアラートして検知される前に出来るだけ対処する ○ また、定常状態のメトリクスのパターンを把握しておくことで、トラブルシューティングが行いやすくなる

New Relic CodeStream を使ったエラー調査 ● New Relic CodeStream 機能を表示するとエラー詳細画面から該当箇所に簡単に遷移することが出来る ○ VS Code に CodeStream の拡張機能をインストールすることが利用可能 ○ New Relic 上で検知したエラー画面上に表示される「Open in IDE」ボタンをクリックすると移動できる 画像引用元: https://newrelic.com/jp/blog/how-to-relic/happy-debugging-with-codestream

● New Relic 導入の話 ○ コスト面およびコミュニティの盛り上がり的な側面から New Relic 導入を決断 ● New Relic 導入して実践した3つのこと ○ ①監視の設定 ■ 外型監視およびゴールデンシグナルに基づいた監視を実施 ○ ②New Relic Flex を使った KPI 分析 ■ New Relic Flex を用いて登録ユーザ数等をモニタリング ○ ③パフォーマンス観測会 ■ 定期的にメトリクスを確認し潜在的な問題がないか観察 ● 今後の展望 ○ ダッシュボードの内容を充実化して知りたい情報の全てを1画面に収められるようにする ○ SLI、SLO を選定を行い、パフォーマンスが悪いところは改善しユーザ体験の向上を目指す ご清聴ありがとうございました！ まとめ/今後の展望