しんどくないSLI/SLOプラクティスをNew Relicで？

Dec 12, 2023 · o11y observability SLI/SLO SRE New Relic ·

Share on:

はじめに

こんにちは、情報システム部 SRE 橋本です。

今回はQiitaのNew Relic Advent Calendar 2023の14日めの記事として書きました。

担当しているシステムでサービス監視やSLI/SLOを用いて、どのようにしてサービスの健全性を知るのか？というのを考えていく中でNew Relicが課題解決に繋がるかもしれないと思い、直近でチームで評価を行いました。

この記事では、どのような課題感を持っていたのかというのと、その課題感に対して当該プロダクトがどう刺さったのかを簡単にお話したいと思います。

サービスとその信頼性

BtoBやBtoCなどで違いはあると思いますが、サービスがあり（中央）、サービスの提供者（下）、サービスを利用するお客様などの利用者（上）という3つの関係性で整理できます。

この関係性の中で、我々は利用者が正常にサービスを利用できているかを知りたいという欲求があります。

伝統的な監視

そこで自分たちのシステムに対して監視を行うことになります。PrometheusやZabbix、Sensu、Munin、Cacti、Nagios、MRTG、etc…といろんなツールがありますが、メトリクスを取得してグラフ化したりゲージやカウンターの値をもとに監視やパフォーマンス計測をしたりします。また、ログもどこかに集約したり、もしくはサーバに直接入ってエラーが発生したら確認したりします。

しかし、これら伝統的な監視だけで正しくサービス適用が出来ているかを判断することは実は難しいのです。CPU使用率が高ければ、エラーが少し出たらお客様が本当に困るのでしょうか？

困っているかもしれないし、困っていないかもしれません。これだけでは分からないのです。

夜中にアラートで起こされたエンジニアにとって、「誰も困っていないかもしれないからアラート対応しません」 とは言い切れないのです。 スパイクして落ち着いた形跡が分かるメトリクスのグラフを貼ってログをチャットでシェアして 「静観します」 とだけ書いて再び眠りについた経験があるのではないでしょうか。

また、大きな障害が万が一発生した場合、エラーが出ているがどれだけの深刻度合いなのかが即時に判断できず、エスカレーションをどこまで行うべきか迷ったことがあるかもしれません。

Site Reliability Engineering

そこで細かなメトリクスやログを用いた監視ではなく、SLI/SLOを用いたプラクティスでサービスの正常性を測ろうという話が出てきます。

SLI/SLOと、利用者がどのようにサービスを利用しているかを現す ユーザー・ジャーニー（User Journey） を関連付けて考えることでサービスの正常性を計測することが、SRE（Site Reliability Engineering）のプラクティスの一つであると捉えています。

しかし、このSLI/SLOの仕組みを作る取り組みは一筋縄ではいきません。大変なのです。

監視の仕組みを作り、グラフを作り、新しい仕組みができれば追加し、メトリクスを集計するエージェントを入れ、ログのフォワーダーを仕込んで、集約する仕組み（アグリゲーター）の設定をして、サービスの負荷が高まると監視やログを集約する仕組みが詰まり、スケールさせて負荷対策をして、ダッシュボードを作っていたら一週間の時間がいつの間にか溶けており、気がついたらコストの問題や、そもそも活用されていないという根本課題が出てきて最初の仕組みづくりに戻る…

そして、これらの監視の仕組みをもとにSLIをUJ（User Journey）を分析して定め集計し、それもダッシュボードにして運用しながら妥当性を見極めつつBizと会話をしてSLOを決めて、それに従って運用をする…

最後の運用までたどり着けるイメージが湧きません。

システムが初期段階から徐々に成長していくのであれば徐々に成長させていけるかもしれません。また、すでに大きなSLI/SLOを取り扱う仕組みがあり、それらに乗っかる形であればもちろん問題ないかと思います。

しかしながら、まったく白紙の状態から、比較的大きなシステムに対してSREのプラクティスを適用するのは上記の大変さを乗り越える必要があり、とてもコストがかかってしまうものであると考えています。作れたとしても維持するコストや継続的・組織的に担保するのも多くの場合困難を伴うものと思われます。

大事なのはサービスが正常かを知ることであり、知るための仕組みを作り・維持することではないのですが、 “知るための仕組み"そのものが重量級 なものになりがちであるが故に目的と手段が交叉してしまいがちであろうと思います。自身の過去の苦い経験でもありますし、今現在も進行形の課題でもあります。

“運用のための運用"にならないために

我々の環境ではシステムに対する 可観測性（オブザーバビリティ） を確保するためにGoogle Cloudのプロダクトや独自に開発された集計の仕組みを利用しています。

Google Cloudのこれらは、比較的簡単に使い始めることが出来て、且つ、安価でもあるので（一部工夫が必要ですが）とても使いやすいプロダクトが揃っていると思います。

しかし、先に述べた仕組みづくりや維持の負担がシステム規模に比して大きくなってきており、 “運用のための運用” になってきてしまっている状況が見えつつありました。

また、最後の “SLI/SLOの運用"というゴールまでが長くなりそう に思われました。

少し前置きが長くなりましたが、以上までを背景としてNew RelicをPoCしてみました。

導入ポイント

我々の環境はGKE/コンテナ環境のフロントエンドと、VMで構成されるデータストアサーバがあります。

コンテナ向けやGKE、VM等へのインフラ基盤、記載はしていませんがクラウド連携などを導入時に行っています。これらAgentに関しては他製品もそうですが特にコンテナ環境への導入は容易ですね。

入れたらスグSLIダッシュボードが出来上がる

個人的に刺さったのはSLIダッシュボードが簡単にできることでした。

マイクロサービスの各コンテナにAPMを導入する際にAppNameを添えて起動するのですが、その名前でグループ化されて自動的にRequestの正常性やLatencyの集計が行われます。

また数字で全体を眺めるダッシュボード化も簡単に行えます。これで一目でサービスの健全性を把握しやすくなるのですが、ここまでの労力はほぼAPM Agentを入れるところまでです。

APMだから色々ガバって持ってきてくれている

ここまでカンタンに出来たので、次はそのあとの運用イメージです（PoCまで実施しただけなので、まだ実際に運用していないので想像を交えた話になります）

先のSLIダッシュボードでサービスの異常に気づきます。何かのSLIの数値が99.9%を下回ってPagerが発生することになります。

上の画像はErrors Inboxと呼ばれる画面です。Google CloudでのError Reportingと同じようなものだと思っています。SLIの数値が悪化しているということは、このErrors Inboxにも何かのエラーが検知されているものと思われます。直近のエラーレートの増加などを見つつエラーの中身を追跡する導線になると思われます。

このErrors Inboxから該当エラーに飛ぶと上の画像のように、発生しているエラーのログやStackTraceを確認することが出来ます（画像は公式のものを使用しています）

また、APMによりトレースが行われているため、どの部分の処理なのか（トランザクション）を見たり、該当処理におけるデータベースへのクエリを確認することをシームレスに行うことができます。

APMだからこそ わかることだとPoCの後になれば理解できますが、ここまでカンタンに様々なことを追跡可能になることに驚きました。また、現在では複数のツールに分かれて入っていたり、取得するためにはそもそもデバッグログを仕込む必要があったりする部分も何も考えなくても既に一箇所に集まっている状態になります。これがとても強力で魅力的に映ります。

ツールや仕組みが複雑であると、しばしば追跡が職人芸になり問題対応が属人化することがあります。

上記に示したような仕組みであれば、カンタンにWebページでドリルダウンして誰でも追跡できる点が非常に大きな恩恵であると感じます。ただ、New Relicの画面遷移やメニューが多岐に渡るので覚えるまでに少し時間がかかるかもしれません。そこはご愛嬌ですね。

トレースの部分はもう少し触れておきたいところもあったり、その他のトピックスもありますが長くなってしまうのでここまでとしておきます。他にも統合的なツールとしてカンタンに強力な可観測性をもたらしてくれる手応えをPoCを通じて理解することが出来ました。