New Relicを活用したSREの最初のステップ

New Relic Advent Calendar 2024、シリーズ4 12/6(金)の記事となります。

本記事では、2024年11月19日に開催されたNew Relic User Group 沖縄支部 Vol.3で登壇した際の内容を記事にして、よりわかりやすくお伝えできればと思います。

スライド資料はこちら（SpeakerDeck）

対象となる方

• SREってなに？という⽅
• SRE初学者の⽅
• SREをこれから始める⽅、始めたばかりの⽅

もちろん

• SREをすでに実践されている⽅

も⼤歓迎です。この記事がSRE入門のきっかけになれば幸いです。

記事の内容は、あまり複雑であったり難解な表現はなるべく避けてお伝えできるようにしたいと思います。New Relic初心者の方もご安心ください。

SREとは

2024年10⽉にオライリー・ジャパンより出版された「SREをはじめよう」で、

SREとは、

組織がシステム、サービス、製品において適切なレベルの信頼性を持続的に達成できるよう⽀援することを⽬的とした⼯学分野

と表現しています。

この一文を私なりに3つに分解してみました。

1. SREは、システム、サービス、製品（プロダクト）のためのものである
2. SREは、適切なレベルの信頼性が必要である
3. SREは、持続的に信頼性を達成できるように⽀援することを目的とした工学分野である

ということで、

• みなさんが関わっているシステム、サービス、プロダクトの適切なレベルの信頼性とはどのくらいなのか？
• それを持続的に達成できるように⽀援するためはなにをすればよいのか？

ということを考えていきます。

適切な信頼性レベルの設定

ビジネスとして成り⽴つ信頼性レベルはどのくらいだろうか？

⾔い換えれば、ユーザーの満⾜度を維持できるレベルとはどのくらいか？をまず考えます。

信頼性レベルは⾼ければ⾼いほど良いってものではありません。

100%の信頼性レベルは⾮現実的で、バグや障害は起こり得るものという前提があります。過度な⽬標設定だと、様々な機能開発や構成変更などができなくなってしまいます。

ビジネスサイドも含めて⼀緒に⽬指すべき信頼性レベルはどの程度かを決める（会話する）ことが大事です。

最初からきっちりとレベルを決められない場合はざっくりでもよいと思います（そういったケースのほうが多い気がします）。

現状⼤きな問題が起きてないのであれば、今と同レベルという考え⽅でもよいので、まずはとにかく前に進めてみて、レベルに課題を感じたらその時に⽬標を修正していければ良いと思います。

まずは現状の信頼性レベルを知る（計測する）ところから始めましょう

信頼性をどうやって知るのか？

ユーザー体験に影響する箇所において、

• どのくらいエラーが出ているのか、その原因となりうる箇所はどこか
• どのくらいスループットが出ているのか
• どのくらいのレスポンスタイムで返せているのか

を把握することがまず第⼀歩となります。

その⽅法として

• メトリクスを収集、集計する
• ログを収集、集計する

というのが挙げられます。

信頼性を計測するために必要な情報を収集‧記録し集計する

信頼性の計測⽅法いろいろ（個別サービス・ツール利⽤）

信頼性の計測方法は各種クラウドではさまざまなサービスが用意されています。また、オープンソースのツールも充実しています。その中でも代表的なものをいくつか挙げてみます。

メトリクス

• CloudWatch
• Cloud Monitoring
• Prometheus
• Grafana

ログ

• CloudWatch Logs
• Cloud Logging
• Fluentd/Fluent Bit → Data Firehose → S3/OpenSearch Service/Athena
• Fluentd/Fluent Bit/Promtail → Grafana Loki → S3
• BigQuery

このほかにもいろいろあるでしょう。

信頼性の計測⽅法いろいろ（オブザーバビリティSaaS利⽤）

各社から便利なオブザーバビリティ製品が提供されています。以下はその代表的な例です。

• New Relic
• Datadog
• Dynatrace
• AppDynamics
• Sentry
• Splunk Observability Cloud
• Mackerel
• Grafana Cloud
• Elastic Observability

ほかにもいろいろあるかもしれません。

製品によって得意とする領域や対応する言語、フレームワーク、価格体系が異なるので注意が必要です。

SaaSはメトリクス、ログ含め様々な情報を⼀元的に収集‧集計できるというメリットがあります

New RelicはSREにどう役に⽴つ？

New Relicの基本機能

New Relicには多くの機能がありますが、最低限これだけ覚えておくと良いと思うものを挙げてみます。

• APM（Application Performance Monitoring）
  • サーバーアプリのパフォーマンスモニタリング
• Infrastructure
  • サーバー、コンテナ、データベース、Kubernetesのモニタリング
• Mobile
  • モバイルアプリのパフォーマンス、クラッシュのモニタリング
• Browser
  • Webサイトのパフォーマンスモニタリング
• Log Management
  • ログの⼀元化、検索、可視化、アラート

あらゆるアプリケーション・インフラの状態を⼀元的に収集し、検索、可視化できます

New Relic APMでオブザーバビリティの第⼀歩

特にサーバーアプリケーションの状態を知ることがオブザーバビリティの第⼀歩です。

なぜかというと、サーバーアプリケーションの状態を知るために、サーバー1台ずつにSSHしてログをgrep‧‧‧なんて⾯倒なことはしたくありませんよね？（私も過去多くの経験があります...）

これには、ただ⾯倒だけでなく、欲しい情報を探す難しさ、⾒逃してしまうといった課題があります（人間の能力に寄った属人化や職人化が起きるのが想像できます）。

APMを導⼊することですべてのサーバーで動作しているアプリケーションの状態を知ることができるようになります（いちいちSSHはしなくていいということですね）

New Relic APMはGo、Java、.NET、Node.js、PHP、Python、Rubyに対応しています。（ExperimentalとしてElixirも対応している様⼦）

APM導⼊⼿順は公式ドキュメントを参照: APMによるアプリのパフォーマンス改善

オブザーバビリティと信頼性

オブザーバビリティを確保することによって何が変わるのかというと、

アプリケーションの状態が

「なんとなく良さそう...」「たまになんかおかしい...」

から、スピーディーに状況が把握できることによって、

「このレスポンスタイム値なら⼤丈夫だ」「このエラー今⽇xx回出てるから直そう」

に変わります。

オブザーバビリティによって現在の信頼性を持続的に把握できます
必要に応じて改善のアクションにつなげられます（これぞSRE）

まとめ

いま扱っているシステムの信頼性がどの程度なのかを知ることがSREの第⼀歩です。

信頼性を測るためにはオブザーバビリティは⽋かせません

オブザーバビリティツールは世の中に数多くあります。なにを選ぶかは要件（機能やコストなど）に合わせて。

APMの導⼊は第⼀歩⽬としてオススメです

中規模〜⼤規模なサービスだとデータ量（コスト増）に注意が必要です

その他のSREのプラクティスはいろいろあるが...

SREのプラクティスは他にもインシデントレスポンス、ポストモーテム、トイルなどがありますが、まずは「⽬指すべき信頼性レベルを決める、今の状況を知る」ためのオブザーバビリティを整えておきましょう

New Relicのノウハウは世の中に増加中！

特にQiitaのアドベントカレンダーには多くのTipsが溢れているのでぜひご覧ください！