こんにちはマネージドサービス部 大城です。
2023年12月に販売された「New Relic実践入門 第2版 オブザーバビリティの基礎と実現」を読んだので読書感想文を書きます。
今回の本は第2版となっており、第1版のときに書かれた弊社のブログもありますので貼っておきます。
『New Relic 実践入門 監視からオブザーバビリティへの変革』を読んでみた - サーバーワークスエンジニアブログ
誰におすすめか
New Relicを活用したいインフラエンジニアはもちろん、アプリケーション開発に携わるエンジニア、駆け出しエンジニアにもおすすめです。
近年、マイクロサービス、SaaS、FaaSの組み合わせでシステムが複雑化している状態です。問題が発生すると「開発した担当者」や「システムに詳しい職人」を頼りがちです。オブザーバビリティを実現することで、あまりシステムに詳しくないエンジニアでも、問題が発生している箇所が把握しやすくなります。New Relicを使うことで「こんなことが出来るんだ」というのが分かる本です。
本書の構成
ざっくり下のような流れで構成されています
第１部 New Relicを知る
オブザーバビリティの重要性の説明が最初にあります。従来の監視との違い、New Relicの全体像が書かれています。
第２部 New Relicを始める
New Relicの機能単位で「なぜ必要なのか」とセットアップの方法が書かれています。
第３部 New Relic活用レシピ
実装パターンがケースごとに具体的に書かれています。
感想
私が読んでいて個人的に刺さったワードと感想を書いていきます
オブザーバビリティの民主化
(p15から引用)
従来、データを意味のある情報として活用するためには熟達したエンジニアのスキルや経験が必要でしたが、それはある種の属人性であり、誰もがデータを使って効率的に問題解決できるとは限りませんでした。 そこでNew Relicはオブザーバビリティの民主化を掲げ、すべてのエンジニアが専属のスキルや経験がなくとも、意味のある情報として分析でき、業務に活用できる形で提供しています。
私は業務で使うNew Relicアカウントとは別に、個人でNew Relicアカウントを持っています。月100GBまでなら無料で使えるのでおすすめです。
AWSの個人アカウントを業務アカウントとは別でエンジニアが持っているように、New Relicアカウントも個人で作っても良いと思っています。（New Relicがオブザーバビリティの民主化を掲げているので）
「スキルや経験がなくても分析できる」という点を私の体験から一つ紹介します。
私の個人アカウントのAPMの画面です。PHP環境にAPMを入れて負荷をかけています。特に設定のカスタマイズはしておらず、APMを入れたデフォルトの状態です。この画面から下のことが「なんとなく」分かります。
- 前半は20ms以内でレスポンスを返せている
- 後半のグラフが赤くなっていてやばそう
- 後半のレスポンスが40msを超えており最終的に260msまで悪化している
- 最終的にApdex（ユーザー満足度）が「0」になっている
- スループットが後半50以下に悪化している
これだけのことが１画面で把握できます。
New Relicを入れる前、運用畑１０年以上おじさんの私はこれらをどのように分析していたかというと
サーバーからログを収集し、grep awk wcコマンドなどを駆使して分析を行っていました。数GBのアクセスログに対してコマンドを実行するとgrepが返ってこなくて辛かった思い出があります。
その他、OSSを駆使して Fluentd+OpenSearch+Grafana などを使う方法もあります。昔使っていたこともありますが、サービスがスケールして Index が膨大になると OutOfMemory が発生し運用が大変だった記憶があります。
New Relicにメトリクスを連携するだけで、これらが数クリックで出来るようになっています。便利な世の中になったと感じます。
インフラ監視・フロントエンド監視
(p74から引用)
これまで、New Relic APMによって、アプリケーションで発生している問題の検知や原因の特定が迅速に行えることを説明してきました。その問題がインフラで発生しているのか、それともフロントエンドに起因するものなのかを把握することで、より正確に問題を補足し、適切な優先順位で的確な対策を講じることができます。
サービスをインフラ、フロントエンド、バックエンドすべて１チームで見ている場合はあまり課題にならないのですが、大きいサービスほどレイヤー毎にチーム分けされることもあります。
障害が発生した場合、各チーム間でのコミュニケーションの問題がどうしても発生すると思います。最悪の場合だと問題の押し付け合いに発展することもあります。
私は昔からインフラエンジニアをしてきましたが「最終的にインフラをスペックアップすれば良いでしょ」というケースに何回か遭遇してきました。暫定対応だったつもりがずっと大きなサーバーが常時起動されている状態で、コストが勿体ないと思っていました。
APMに加え、New Relic Browser、New Relic Infrastructureを入れることで一気通貫でシステムを把握しやすくなります。
インフラ、フロントエンド、バックエンドどこに問題があるのかNew Relicの画面を見ながらディスカッションし「本質的なボトルネックはどこにあるか？」をワイワイみんなで話すことが出来ると思っています。
Applied Intelligence（AI）
(p149から引用)
対応しきれないほど多すぎるアラートは大きく２つの問題を引き起こします ・大量のアラートによる過負荷 ・アラートの誤認や見逃し
Applied Intelligence（AI）を利用することで、Splunk、Prometheus、Grafana、Amazon CloudWatchなどのデータをREST APIを使ってNew Relicに統合することでアラート疲れを軽減する方法が書かれています。
この機能は私も触ったことがないので今度試してみようと思います。
SREを実践する
(p241から引用)
ユーザーの期待に応え、デジタルビジネスに貢献していくSREを実践するためには、オブザーバビリティの実装が必要不可欠です。そのために、New Relicで何を計測し可視化するのか、SREを実践するエンジニアのために New Relicの活用方法を解説します。
有名な本ですが、SREについては下を合わせて読むと知識が補完されるので良いと思います。
New Relic APMをインストールすると重要な指標 ゴールデンシグナル のグラフがAPM > Summary 画面に表示されます。
はじめの一歩としてまずはAPMを入れることでSREを実践する近道になると思います。
カオスエンジニアリングとは
(p241から引用)
実験することによってシステムが持つレジリエンスを測定し、改善につなげる手法の１つがカオスエンジニアリングです。
刺激的で強いことが書かれています。簡単に言うと「本番環境で障害発生を実験してみよう」という内容です。
- APサーバー１台のCPUを高騰させてみる
- データベースをフェイルオーバーさせてみる
そんなこと出来るのかと思ってしまいますが、New Relicで定常状態を見える化しておくことで、APサーバー１台ダメなってもApdex（ユーザー満足度）が低下しなければOKだよね。ということになります。
APサーバー１台がOKだったら、次は勇気を持ってデータベースをフェイルオーバーさせてみよう、サービスレベル上許容されていればOKということになります。
おもしろそう。ビジネス側が許すのであれば将来的にやってみたいなと思いました。
最後に
ここまで読んでいただきありがとうございます。紹介した内容は一部となります。他にも参考になる情報が多くあるので気になる方は読んでみてください。
大城 慶明 (記事一覧)
マネージドサービス部
2022年10月サーバーワークスに入社、沖縄からリモート勤務。AWSを勉強中。沖縄では大城が多いので「よっさん」と呼ばれています。AWS14冠。NRUG沖縄支部運営。X @yo_ohshiro
