モニタリングのための「New Relic」導入
菊池宣明氏（以下、菊池）：次はモニタリング、「New Relic」の導入の話をしていこうと思います。
まずそもそもですが、ハッカー飯では監視・モニタリングが一切行われていませんでした。そういった状態から監視を導入しようと至った背景について、まず紹介しようかなと思います。
経緯として、もともとハッカー飯は.NETで動いています。過去に.NETのバージョンを上げる作業を行いました。このタイミングでインフラ側の必要な作業を行わずに作業を終了してしまったために、ハッカー飯にログインができない人というのが発生してしまいました。
本来であれば、こういった障害はユーザーよりも運営側が先に察知して対処する必要があると思いますが、それができておらず、ユーザーからの連絡、実はこの連絡をしたのが僕でしたが、こういった連絡があることによって運営側が障害を認知して対応することが過去に起こりました。
この反省点、振り返りとしては、必要な操作が本番環境で実施されていなかったということと、そもそもハッカー飯が正常稼働しているかどうかを運営サイドが認知できていない問題がありました。
ほかにもいろいろ反省点あるかもしれませんが、よりユーザー体験を向上させるためには何が一番効果的かを考えた時に、デプロイの有無に関わらず、「『ちゃんとサービスが動いていますよね』というのを僕らが認知できていないという状態ってよくないよね」というのを感じていて。
そこをまず改善させるために、モニタリングツールの導入を優先的に実施することにしました。
「CloudWatch」とSaaSのどちらを使うか
最初にまずは「CloudWatch」とSaaSのどちらを使おうか悩みました。CloudWatchはやはり、本当に手軽で簡単に始められるモニタリングツールとしては、ものすごく優秀なものかなと考えています。特になにも設定しなくてもAWSリソースを手早く簡単に確認できるのは、CloudWatchしかできないかなと考えています。
それに対してSaaSの監視ツールの得意分野。別にCloudWatchでもやろうと思えばできると思いますが、SaaSの優位性をあえて言うのであれば、マルチアカウント・マルチクラウド化した時に、SaaSのほうがわりと一元管理はしやすいかなという印象があります。
もちろんCloudWatchでもやろうと思えばできることだと思いますが、将来的にハッカー飯はマルチアカウント・クラウド化することもあると思うので、そういった時にも柔軟に対応できるように、SaaSの監視ツールを採用することにしました。
さまざまなSaaSの監視ツールがあると思いますが、そんな中でもハッカー飯ではNew Relicと呼ばれるSaaS製の監視ツールを導入することにしました。
選定理由としては、New Relicは1ユーザーであればすべての機能を期間制限なく無料利用枠で使用できるためです。現状、インフラを主に見ているのがハッカー飯の中でも僕だけなので、1ユーザーあれば十分かなと考えております。
New Relicの主な機能
New Relicの主な機能としては、Telemetry Data Platform、Full Stack Observability、Alert and Applied Intelligenceの3つの機能で構成されています。
Telemetry Data Platformでは、テレメトリデータの収集・格納を行い、Full Stack Observabilityでは、ここで収集したデータを分析・可視化できます。Alert and Applied Intelligenceでは、閾値ベースのアラート設定などや異常値の検出なども行えます。
もしかすると“テレメトリデータ”はあまり聞き慣れない言葉かもしれません。今回のこの発表では、テレメトリデータは、メトリクス、イベント、ログ、トレースのことを指しています。
もう少し機能について掘り下げると、まずTelemetry Data Platformは、Agentなど、ほかにもありますが、そういったものからテレメトリデータを収集して、テレメトリデータをプラットフォームに送信して格納する場所となっています。
格納したデータをNew Relic上でNRQL（New Relic Query Language）と呼ばれるようなものなどを駆使することによって、このようなダッシュボードを作成することが可能になっています。
さらに、そこで格納したデータを分析する機能として一番有名なのがNew Relic APMと呼ばれるものです。こちらは、アプリケーションのパフォーマンスの計測を行える機能となっています。
例えばトランザクションタイム。Webリクエストの処理に費やす平均時間だったり、あとはスループット。1分間に処理するリクエストの数など、そういったアプリケーションのパフォーマンスがよくわかるものとなっています。
Apdex Scoreについて補足します。
Apdex Scoreは、ユーザー満足度を定量的に表したものとなっています。ちょっと難しいかもしれませんが、レスポンスタイムの閾値をTとした時に、リクエストを以下の3つのようなレベルにまず分類します。
閾値以下のレスポンスタイムのことを「満足レベルのリクエスト」。閾値よりも大きくて4倍の閾値よりも小さいレスポンスタイムのことを「許容可能なレベルのリクエスト」。4倍の閾値よりもレスポンスタイムが大きい場合は「不満足なレベルのリクエスト」と分類してあります。
（スライドを示して）リクエストのレベル分け後、このような式を使ってApdex Scoreを算出しています。全リクエスト数分の満足レベルのリクエスト数、足す、許容可能なレベルのリクエスト数、割る2、となっています。
この式、いわゆる許容可能なレベルのリクエスト、不満足なレベルのリクエスト、いわゆる閾値を超過するリクエストがあればあるほど、全体の値が0に近づいていく。全リクエスト数分の分子がどんどん小さくなっていくので、どんどん0の値に近づいていって、0がユーザーにとって最悪のスコア、1が最高のスコアというふうに定量的に測定できる。これがApdex Scoreというものとなっています。こういったスコアの測定などもNew Relicで行うことが可能となっています。
ほかにも、New Relic Infrastructureという機能で、CPU、メモリ、ディスクなど従来の監視をもちろん観測することもできるし、New Relic Syntheticsという機能を使えば、システムに対して外部から稼働状況を確認すること、いわゆる外形監視と呼ばれるものも可能となっています。
モニターの実行場所の指定が可能なので、例えば東京、シンガポールなどのロケーションを柔軟に選ぶことも可能となっています。
あとは、アラート機能です。こちらは本当にシンプルですが、アラートの設定および通知先を設定できます。通知先としてはEmail、Slack、PagerDutyにも通知できます。
New Relicでハッカー飯が行っていること
New Relicを使って僕らハッカー飯が実際にしていることとしては、まずはユーザーに影響が出そうなものをアラートとして設定しています。特に外形監視、エラー発生率、レスポンスタイムなどは、閾値を超過しているとユーザーに影響が出ると考えているので、このあたりはアラートとして設定をするようにしています。
これ以外のものに関してはどうしているかというと、1週間に1度、メトリクス全体をひととおり確認するようにしています。別のセッションで「メトリクス取得するだけ取って満足しちゃうのはダメだよね」という話があったと思いますが、僕らもそれをなくしていこうと思っていて。
どういった取り組みをしているかというと、アラートが発生していなかったとしても異常が発生していないかを定期的にチェックするようにしています。
確認しているポイントとしては、まずエラーが起きていないか、レスポンスタイムに異常が起きていないか、インフラのリソース使用状況に問題が起きていないか。こういったポイントをメトリクス全体を俯瞰して確認して、定期的に確認することによって、これらがアラートとして上がる前にできるだけ対処することができるのかなと考えています。
定期的なパフォーマンスの観測会でユーザー体験の向上を目指していく
最後にまとめになります。まずLightsailをEC2に移行したことによって、アクセスキーを廃止してIAMロールに置き換えることをしました。もともとRootユーザーで運用が行われていたので、そういったものもやめて、AWS SSOを使ったユーザー管理を行うようにしています。
モニタリングについては、ハッカー飯ではNew Relicを導入していて、サービスが正常に稼働することを運営メンバーが把握できるようにアラートを設定しました。定期的なパフォーマンスの観測会、“定点観測会”と呼ばれるかもしれませんが、そういったことを行うことによって、ユーザー体験の向上を目指していこうかなと思っています。
発表は以上となります。ご清聴いただきありがとうございました。
