こんにちは、SREグループの三橋です。
今回はNew Relic x OpenTelemetryを使ってサービスの健康状態がわかるダッシュボードを作ったのでそのお話をします。
※ 主にWhyにフォーカスしており、New RelicやOpenTelemetryなどの技術的な部分についての説明は記載していないのでご注意ください。
想定する読者
- New Relicの活用事例についてご興味をお持ちの方
- New Relic x OpenTelemetry にご興味をお持ちの方
- Yappliの裏側についてご興味をお持ちの方
背景
Yappliはマルチテナント構成をとっており、2024年7月30日現在845のアプリが同じプラットフォーム上で稼働しています(参考: ヤプリ、アプリ開発プラットフォーム「Yappli」のアプリが累計2億ダウンロード突破)。またYappliが提供する機能の中にはクライアント企業様が保有するサーバーと連携する機能もあります。この関係から主に障害対応周りで以下の対応に時間がかかっていました。
- 障害発生時にYappliで起きている障害なのかクライアント企業様の管理するサーバーで起きている障害なのかの調査
- どの機能で障害が起きているのかの調査
- どの程度の大きさの障害なのかの調査
企業の競争力を維持するためにも継続的なデプロイは欠かせませんが、変更頻度が高い分、障害やインシデントが発生する可能性も高くなります。そのため、いかに素早く障害を検知し、いかに素早く対応できるかが重要です。 そこでサービスの健康状態を即座に把握できる仕組みを作ることにしました。
New Relicでの可視化
弊社ではオブザーバビリティツールとして主にNew Relicを使用しています。New Relicにはダッシュボードを提供する機能があるため、これを使って誰でも即座にどこでどのような障害が発生しているかわかるようにできるのではないかと考えました。
ただし、New RelicのAPMエージェントが送るデータではYappliの機能単位で分析をすることはできないため監視の仕組みを考える必要がありました。
Synthetic Monitoringの課題
New RelicにはSynthetic Monitoringという外形監視を行う仕組みがあります。Synthetic Monitoringは他のNew Relicの機能とは異なり、監視頻度に応じた従量課金が発生します(参考: New Relic Usage plan)。これまではこの機能を使っていくつかのYappliのエンドポイントの監視を行っていましたが、監視対象を増やすと料金も増えるため常にコストを意識する必要がありました。
Yappliには数十以上の機能があり、クライアント企業様によって利用する機能も異なります。オブザーバビリティを高めるためにも、すべての機能のエンドポイントを監視する必要があります。また、将来期に機能拡張があった際もコストを意識することなく監視対象を増やしていけるようにするため、自前で外形監視の仕組みを作ることにしました。
外形監視の仕組み
最終的に作成した外形監視の仕組みの構成図は以下の通りです。
監視対象のアプリ
Yappliではポイントカードやスタンプカード、ログイン機能など様々な機能を提供しているためクライアント企業様によって利用するAPIが異なります。また特定クライアントのアプリを監視していたとしていてもクライアント企業様によるコンテンツの更新により監視していたコンテンツがなくなってしまうこともあります。そのため今回の監視ではYappliの機能すべてをモリモリに載せたモバイルアプリを構築し、それらのコンテンツを取得するAPIを監視することにしました。
Goを使う
SREグループでは、このような仕組みを作る際に、メンバーが使い慣れているshellやpythonを使用することが多いです。しかし、今回の外形監視の仕組みはSLI/SLOやオブザーバビリティ向上にも役立つものであり、SREプラクティスの一環です。SREはロールではなくプラクティスであるため、このような仕組みをSREグループだけの持ち物にしてはいけないと考えています。そこで、将来的なSREプラクティスの普及と効果的な運用のために、サーバーサイドメンバーに馴染みのあるGoを採用しました。
私もGoの経験はほとんどなかったのですが、サーバーサイドメンバーにレビューしてもらいながら実装することで、新たな気づきが得られただけでなく、非常に良い刺激となりました。また、SRE文化を醸成する上でも他チームと連携しながら新たな挑戦をしていくことが重要だと改めて感じました。
OpenTelemetryを使う
メトリクスを計装する方法はいくかありますが下記の理由からOpenTelemetryを採用しました。
- メトリクスに様々な属性(今回の場合はYaapliの機能名)を付与できるようにDimensional metricsを使いたい
- OpenTelemetryは今後のオブザーバビリティの業界標準になっていくと想定される
OpenTelemetry Collectorは使わなくても大丈夫でしたが、現在は使うことが主流となっているようなのでCollectorを介してNew Relicに送信するようにしました。これによりバックエンドがNew Relicでなくなった場合も設定ファイルを書き換えるだけでそのまま動かすことができます。単独で動かすメリットは今回のケースではあまりなかったのでサイドカーとして動かしています。
作成したダッシュボード
今回作成した外形監視の仕組みとAPMのデータを合わせて最終的に以下のようなダッシュボードを構築しました。
Yappliで障害が発生しているかがわかるダッシュボード
AWS Health Dashboardのようなイメージです。障害が発生するとその機能の部分が赤色になってくれます。
自前の監視対象アプリを見ているため、Yappliで障害が発生している場合すぐに気づくことができます。
障害の大きさがわかるダッシュボード
こちらはNRQL魔術を使って作成したもので、どれくらいのアプリに影響が出ているかを直感的に把握することができます。
どのアプリで障害が起きていそうかがわかるダッシュボード
こちらはアクセス数やレイテインシー、エラー率などが高いアプリの上位10件を表示してくれるダッシュボードです。クライアント企業様が行う施策等によってアクセス数が跳ねるとここに現れます。その際に何か障害が発生していないかなどを把握することができます。
どの処理で障害が起きていそうかわかるダッシュボード
こちらは先ほどのダッシュボードと似ていますが任意のアプリに絞って、どの処理で障害が発生していそうかがわかるダッシュボードです。Template variablesというNew Relicダッシュボードの機能を使っているため任意のアプリを選ぶことができ、動的に表示内容が変わるようになっています。
まとめ
New Relic x OpenTelemetryを使ってサービスの健康状態が一目でわかるダッシュボードを作成しました。これにより、エンジニア以外のメンバーでも障害の一次切り分けが可能となり、組織全体の生産性向上に寄与できると期待しています。
