オブザーバビリティ 最前線 事例LTから学ぶオブザーバビリティの成熟度

顧客へ迅速な価値提供をしていく中で、信頼性が求められています。 オブザーバビリティという概念が普及し始めているものの、監視との違いを理解し、メトリクスの計測や改善において具体的な取り組みを実践している企業はまだ多くないのが現状です。

今回のイベントでは、オブザーバビリティのステップを
①監視からオブザーバビリティ
②SLMにおける改善
③DevSecOps
と三段階に分けて、成熟度モデルと各ステップにおける実践的な取り組みについて各企業の事例をお話しいただきました。 自社が今どこにいて、次のフェーズは何かがわかり、具体的な取り組みを参考に次にどのようなアクションをすべきかがわかるイベントになっています。

アーカイブはこちら

■パネリスト
New Relic株式会社 伊藤 覚宏さん / @qryuu
Zabbixの日本におけるテクニカルサポート、テクニカルトレーニングの立ち上げを行い、VMwareベースのクラウドサービス開発、AWSテクニカルサポート、クラウドアーキテクトを経て現職。テクニカルサポート、テクニカルトレーニング、運用コンサルを専門領域としてお客様の運用負荷軽減を目指す。得意分野は運用設計、クラウド設計、OSSソフトウェア。

ディップ株式会社 小森谷 良輝さん / @ramiyon_chan
SIerや事業会社を4年経験し、2022年4月にディップ株式会社へ入社。現在は求人サービス「バイトル」開発チームのスクラムマスター。バイトルユーザーサイト開発初の社員エンジニアとして内製化を牽引。

弥生株式会社 牛尾 哲朗さん
ソフトウェアベンダーにてアプリケーション開発を経験したのち、2016年に弥生株式会社へ入社。ML系のテックリードをしばらく担い、現在はYAYOI SMART CONNECTや新サービスなどのテックリードを兼任。ラーメン二郎ガチ勢。

株式会社MIXI 清水 勲さん / @isaoshimizu
SIerで約8年経験後、2011年に株式会社ミクシィ（現MIXI）へ入社。SNS「mixi」のインフラ運用、モンスターストライクのSREを経て、現在は家族アルバム みてねの基盤開発グループマネージャー。 世界中のユーザーが良い体験を得られるよう日々奮闘中。AWS Summit Tokyo、SRE NEXTなどで登壇。New Relic User Group運営。キャンプとビールと音楽があれば生きていける。

株式会社ニューズピックス 安藤 裕紀さん /@integrated1453
SIerのインフラエンジニアとして大企業の技術支援を経験し、2021年10月よりNewsPicksに参画。現在はSREチームのプレイングマネージャーとしてサイト信頼性と開発者体験の向上を牽引している。

オブザーバビリティの成熟度モデルと 監視からオブザーバビリティへ｜New Relic株式会社 伊藤 覚宏

本日はオブザーバビリティというものについてどのようなステップがあるのか、具体的にどのようなアクションが取れるのかを理解いただきたいと思います。まずは監視とオブザーバビリティの違いやどのように変化していくのかについてお話しします。

ITシステムは元々社内向けのシステムからスタートしました。それが少しずつIT自体が価値のあるビジネスへと変化したことにより、社内の人だけではなく、社外の多数のユーザーが使うようになりました。

IT環境にも変化があります。1つの物理サーバーから仮想マシンへ、そして競合との差別化や迅速な価値提供のために、基盤はオンプレ環境からクラウド、コンテナ化へと変化しています。そしてアーキテクチャはモノリシックからマイクロサービスへと変化しました。そうなると、これまでのようにサーバ単位でリソースを見ればいいという状況ではなくシステム全体を見渡す事が必要となってきているということがわかると思います。

なぜ監視だけでは足りないのか。監視とオブザーバビリティの違い

昔からあるシステムモデルとして、ペットモデルとキャトルモデルというものがあります。ペットモデルは1台1台丁寧にメンテナンスをするというもの、キャトルモデルはクラスター化された複数のサーバーを家畜のように群れとして運用するというものです。

現在は、オルガノモデル※1 に変化していると考えています。これは、システム自身が自動復旧をしていくという動きをしており、1個1個の細胞のようなものが自動的に消えて作り直してという形でどんどん変化する中で、その集合体として全体として機能が適切に提供できているかどうかを見なければならないというものです。

監視とは、あるシステムやそのシステムのコンポーネントの振る舞いや出力をチェックしてシステムが安定して稼働していることをずっと見るものでした。しかし、これまで説明した通り、他社に負けないために新機能の追加をしていくと、複雑なコンテナ化、マイクロサービスと監視対象が細かく増えて行ってしまったため、監視だけでは実はシステムを把握することは難しいということがわかってきました。

こうして生まれたのが、オブザーバビリティです。オブザーバビリティではより多くの情報を関連づけて収集するといったようなことを行います。CPUメモリーだけではなくてプロセスや実際のユーザー体験、応答時間、プログラムそのものの処理時間なども測定します。また、エラーメッセージやスタックトレースも集めていきながら、なぜそれがおこったのかという問題の原因を改善していくことがオブザーバビリティによってもたらされる効果になります。

同様に、これまで監視対象ごとにツールも担当者も別れていましたが、オブザーバビリティでは、このアプリケーションからビジネス領域、あるいはセキュリティまで含めてより多くの情報全部の全体像を一つのツールに集めて、それぞれを関連づけて、可視化します。 これが監視とオブザーバビリティとの大きな違いです。

※1 オルガノモデル New Relic 伊藤覚宏 が提唱

オブザーバビリティの成熟度モデル

ステージ0では、まず監視の状態からさらにアプリPMなどを加え、パフォーマンスの計測あるいはエンドユーザーモニタリングを始めます。そこからまず今までの監視のように、どこが遅くなっているのかという通知を見つけてそこに対処していきます。これがステージ1の「受動的な対応」です。

この対応を実現できた次には、サービスレベル目標を定義していき、積極的に異常や壊れている部分、エラーを直すだけではなく、ここが良くなればサービスがよくなるという部分を積極的に直していきましょうというフェーズ2の積極的なフェーズになります。

さらに、今後ユーザーが増えたら悪くなるのではないか、今後こうなったら今のアーキテクチャだと限界が見えているといったところを見つけ出してそこを予測的に対処していくことが求められます。（フェーズ3）

最後に、データドリブンによる経営判断、リリースそのものを決定して付けていくというところがステージ4といったようなところになってきます。

守りから「攻め」の開発へ！New Relicを活用してサービスと共に成長するチームになる｜ディップ株式会社 小森谷 良輝

ディップではガンガン作れる200人体制として内製化を進めています。
今回は、その過程で調査に人的コストがかかってしまったり、監視ツールが浸透していない、エンジニアのパフォーマンスがわからない、といった問題をNew Relicを使って解決したというお話しをします。

New Relicの導入背景と待ち受けていた困難

内製化を進める中で、監視からオブザーバビリティへ移行していくにあたっていくつかリクエストがありました。

• 多角的なシステム全体の見える化
• 担当や領域を限定せずに各エンジニアがシステムを見られるようになること
• 各エンジニアが価値創造に貢献できる主体性が持てるようになること

とはいえ、私の担当するバイトルは20年やっている古いサービスということもあり、言語のバージョンが古くてそのままでは入らなかったり、一部機能が使えなかったり、アラートが次々と上がってきてしまったり、エラーが捕捉できてなくてどうしよう、ログが見づらくてどうしようなど、困りごとが色々ありました。こうした点は、いずれ直面する問題が表出しているだけと結論づけて、見直しを始めました。

New Relic導入の成果

ディップでは、アジャイル開発でスクラムを組んでいるんですが、レトロスペクティブでNew Relicを見る定期点検というのを実施したり、また属人化されている障害対応フローを文書化して、軽い障害の対応ぐらいであれば新卒の方でも任せられる形にしています。

同様に、パフォーマンスチューニングも全員で実施しており、リリース前後にNew Relicを見てパフォーマンスを計測したり、チューニングにおすすめのページを教えてくれるので対応しています。

開発チームのパフォーマンスについては、Googleが提唱しているFour Keys（デプロイ頻度、リードタイム、変更失敗率、復旧時間）の計測を行ってます。またそれらをパフォーマンスのデータと結びつけるということも試みていて、サービスのパフォーマンスのデータと開発チームのパフォーマンスのデータを結びつけることで、開発チームの貢献度を定量的に測ることができないかということを実施しています。

成果としては、最初に挙げた3つのことについて、調査の人的コストは総合的にデータが見えるため調査が早くなり、新しい組織に任せられるほどハードルが低くなりました。監視ツールの浸透については、アラートを整理することで必要なものに移植したり、ツールを見る文化ができて、誰もが使えるようになってきました。 最後に、エンジニアのパフォーマンスというところについてはFour Keysの計測を通じて数値としてパフォーマンスがわかるようになってきました。

問題解決の促進 -New Relicの導入から全社活用までの道のり-｜弥生株式会社 牛尾哲朗

監視からオブザーバビリティまでの、ステップアップについて弊社事例についてお話させていただきます。

弥生株式会社は、弥生会計などの業務ソフトを開発販売している会社です。もしかしたら弥生会計という言葉は聞いたことある方もいらっしゃるかもしれないですが、その他にも、弥生給与や弥生販売といった企業のバックオフィス業務を支援するような業務ソフトを開発しております。 バックオフィス業務を提供してるサービスなので特に月末月初とか、あとは年末調整の時期確定申告時期などによく使われるという特性があり、オブザーバビリティを高める活動というのに力を入れているという背景があります。

監視の時代を経て、New Relicを導入

2015年以前は、いわゆる監視だけを行っていました。
サーバー監視の目的でZabbix、その後は、Mackerelを利用していました。この時代は、サービスの開発チームではなく、運用チームが見ていました。障害発生時などは、運用チームから開発チームに情報の連携はあるものの、開発チームが主体的にサービスの状況を見にいくということはなかったです。

そして、2016年に一部のサービスにNew Relicを導入しました。当時は、まだNew Relicの日本法人も設立されていなかったので、導入と運用を我流で進めました。最初はごく一部のYAYOI SMART CONNECTというサービスで導入しました。認証認可システムや基幹システムには導入していなかったため、API呼び出したときの遅さなどはわかるものの、具体的に認証認可サーバーの方にいつリクエストが届いたのかや、どこの処理に時間がかかっているのかということは、わからず、オブザーバビリティとしては中途半端な状態だったと振り返っています。

全社導入とツールの浸透

その後、2020年に全社利用を開始しました。New Relic社の協力のもと、弥生全体のサービスや、基盤への導入というのを開始いたしました。こうして、先ほどお話しした、APIのときのいつ認証認可のシステムに到達してどこの処理で遅かったのかっていったところがチーム横断的に、効果的にトレーシングできるようになりました。
こうしてようやく成熟度モデルで1の自動的採用や2の積極的な対応の段階に差し掛かりました。

2022年になって、New Relicの利用促進チームの立ち上げを実施しました。New Relic TFC（Technical Field Community）という名前で、New Relic社と弥生のエンジニアの間に立ち入って、New Relicに関する情報の集約と展開を行う役割です。メンバーについては、各製品サービスや基幹システムのチームから1-2名という形をとっています。
活動実績としては、New Relic社と合同でのキックオフの実施、また全開発者向けにNew Relic説明会を実施しました。

監視からオブザーバビリティへに向けた2つの学び

2015年からの監視からオブザーバビリティのステップアップとして得た知見としては、以下2つになります。

1つ目がサービスを導入するだけでは成熟度は進まないため、自社で我流で進めるのではなく、New Relic社のように知見のある方に入っていただき進めていくことが成熟度を高めることに繋がると思います。

2つ目は、関連するサービス全体でオブザーバビリティを高める必要があるということです。
2016年に1つのサービスだけで導入しましたが、一部のトレーシングしかわからず非常に中途半端だったため、例えばAPIの呼び出しなどを行うといった関連するシステムに関しては、段階的にツールやサービスを導入していって、全体としてオブザーバビリティを高めるといった必要があるのではないかなと思っています。

サービスレベル管理 (SLM) とは？ - 計測すべき指標と活用について｜New Relic株式会社 伊藤 覚宏

先ほどご覧いただいたオブザーバビリティの成熟度モデルとして、受動的なオブザーバビリティの段階が終わると、次がSLMをきちんと定義をして積極的に介入する、あるいはエラーバジェットなどを見ていて予測的に対応をするといったようなことが求められるようになってきます。特に、そこに注力する組織としてSRE（サイトリライアビリティエンジニアリング）というものが求められるようになってまいりました。

SREの役割

SREはサービスの可用性やレイテンシー、パフォーマンス、オブザーバビリティで見るような指標をモニタリングをして、さらにキャパシティプランニングや緊急対応あるいは、パフォーマンス性能に責任を追っていくチームになります。 しかし、開発者がどんどん新機能を追加していくサービスについてはシステム変更が加わり、信頼性に対して負の影響を与える形になります。信頼性と機能追加によるビジネス上の競争力確保というのはトレードオフの関係になってしまいます。信頼性を高めればイノベーションが遅れ、イノベーションを優先すれば信頼性が影響を受けるという関係になるわけです。

そこで運用上のバランスをとるSREが、評価できる数値的な信頼性とは何かといったものがサービスレベル目標（SLO）になります。これを定めることにより、優先順位付け、エラーバジェットを使うことによって、今は開発に注力するのか信頼性を高めるのかを判断していきます。

SLO、SLA、SLI

SLOに関するそれぞれの関係性をみていきます。

• SLA（サービスレベルアグリーメント）：サービスの信頼性に関する顧客との取り決め
• SLO（サービスレベル目標）：SLAに抵触する前に、サービスのレベルに関する問題を検知するための閾値
• SLI（サービスレベル指標）：SLOを満たすために計測すべき指標

まず、SLAの定義です。ユーザーがこういうことを期待しているという指標を測定する必要があります。例えば、ユーザー満足度とSLIが比例する応答時間などが一般的で、予測可能なものであることが必要です。
そして、SLIは良い目標を達成しているイベントを、全体のイベント数で割ったものがSLIというものになるわけです。最大の候補としては、可用性や時間、あるいはオートの品質であったり正確性などが入ってきます。

SLIを定めるときの目標値なのですが、高すぎる目標は心を折ってしまって、実際には誰もそのSLIをみなくなってしまいますので、今の数値が悪化しないことというのを最初の目標にすると良いでしょう。今の数値が維持できているのであれば、そこからユーザーが満足するであろう理想的な体にだんだん変えていけばよいのです。

SLIやSLOは一度定義したらそれでOKではなく、実際に自分たちのシステムをみてあるいはユーザーの声をみて適宜変更をしていくということが非常に重要なものとなってきます。

ただし、SLAなどの契約や顧客との関係性にまで影響を及ぼすような指標なため、SLOを決めて観測可能なものにしていくというのは大変です。そこで、New Relicでは、自動的にSLOの値というものを定義することができるというものになっており、先ほどオブザーバビリティのところでご紹介した通り、非常に多くのデータを集めてくることができるわけです。理想的にはいわゆるユーザーの実際に体験してる値も取ることが望ましいというものになりますが、システムの内容とか構成によっては、ユーザーから遠い部分を計測することも可能です。

全世界のユーザー体験の改善にNew Relic Mobileをどのように活用したか｜株式会社MIXI 清水 勲

2014年ぐらいからMIXIという会社でSREをやっています。2018年からは、家族アルバム みてねというサービスのSREとして、今はマネージャーという立場でやらせていただいています。

家族アルバム みてねというサービスについてちょっとどういう製品、サービスかを説明しないとなかなかこの後の話ができないので軽く説明させていただきます。

簡単に言うと、子供の写真を家族、おじいちゃん、おばあちゃんも含めて、共有してコメントをもらったりとか、写真をプリント、メッセージなどの商品展開をしたりしているサービスです。8年前にリリースをしていて、7言語に対応し、175の国と地域で1,500万人を超えるユーザーに利用いただいています。

国ごとに異なるAPIレスポンスタイム

ユーザー数がどんどん増えているのですが、特に海外ユーザーが非常に増えています。ユーザーが増えるにつれ、同時に、海外のユーザーは快適に使えているのかどうか、という疑問が湧いてきます。ユーザーの端末内のアプリの通信状況を知りたいと思うようになりました。
メンバーがいろんな国に入って調査するのもコストが高く、効率も悪い。そこで、New Relicを使って可視化することにしました。
元々2014年くらいからNew RelicのAPMやインフラストラクチャーを使っていましたが、New Relicのラインナップの中に、Mobileというのがあるということで使い始めました。

APIのレスポンスタイムを国ごとに計測した結果がこちらです（上記図を参照）。APIに関しては、アメリカが日本の2倍、ヨーロッパでは、日本の3倍くらい時間がかかっていることがわかりました。

2倍近く改善された効果測定

日本同等の目標値に近づけられるかを考え、みてねというサービスは東京リージョンでサーバーを提供し、APIエンドポイントを提供してきたのですが、1つのアイデアとしてus-east-1にAPIサーバーを立て、稼働させるということを思いつきました。

具体的には、以下の施策を取り組みました。（別途ブログを参考）

• EKSクラスタをus-east-1に構築
• Amazon Aurora Global Databaseを使ってリーダーをus-east-1に追加
• CloudFrontの背後にRoute 53（レイテンシールーティングポリシー）を利用してユーザーから近いALBにルーティングさせる（ALBは各リージョンにある）
• すべてのAPIを対応するのではなく効果の高いAPIを優先して対応

効果がどうだったのかについてもNew Relic Mobileで確認ができます。（上記図を参照）
この赤い線が引いてあるところが施策のタイミングです。徐々に下がっていき、最終的にアメリカは日本に近いぐらいのレスポンスタイムへ、イギリスについては、USと比較すると遅いですが、元々の速さに比べるとかなり改善されました。

この施策をやった中で特に重要なことについてお話ししました。なんとなく遅そう、という状況は変えるべきで、数字で語れるようにすること、そして、改善アイデアも多分やってよくなったよねではなく、実際の効果測定ができることが重要です。まだまだ世界のユーザーの体感というところはまだこれでも課題があるので、第一歩としてはこれで良いのですが、もっとユーザー体験を良くしていけることが必要だと思っています。

New Relic Service LevelsとバーンレートアラートをCDK for Terraformで設定してSLOモニタリングをセルフサービス化した話｜株式会社ニューズピックス 安藤 裕紀

タイトルはとてもHowの部分なのですが、今日はどちらかというと、Why・Whatの話として、SLOモニタリングにどういう課題があったのかというところと、それを解決するためになぜこのHowにつながる技術を選んだのかというというところをお話しします。

SLOモニタリングの課題

NewsPicksにはモバイルとウェブがあるので、ユーザーのタイプ、ユーザーの顧客の階層を分けてSLOを決めて週次でモニタリングしていきました。
例えば、Web のレイテンシーで何かSLO違反が起きたとします。あなたならこの状態からどうしますか。

サイトリライアビリティエンジニアリングの教科書的なエラーバジェットポリシーを見ると、SLO違反していたらチームの開発作業を止めて、復旧させるような作業をしなければならないということになりますが、現実的にはあり得ないです。

ではどうするかを考えたときに、SREには『SREの探求』という本に書いてあるように、フェーズ1~4までフェーズがあり、我々は、支持者・パートナーを目指していきたいと思っています。

Google Cloudのブログにも、SLOを満たしていないからすぐに機能開発をやめてしまう組織はありませんと書かれています。
そこで、関連する開発チームに知らせて、あとでも構わないので、しっかりどういう違反があったのかを集約して、意味のある情報提供をしましょうということです。

例えば、「この前のリリースが原因でページを表示するまでの時間が遅くなっているみたいです」ということを情報を付け加えて補足する。そうすると、エンジニアは「ユーザーのために機能追加したのにユーザー体験が悪くなるところだったのでリカバリしましょう」と納得感を持って信頼性を確保することができる。SREではそのサポートをしていきましょうということです。

我々はどこでSLO違反したのかをNew Relicのダッシュボードから見つけて、調査をし、このエスカレーションを100本ノックしました。

エンドポイントごとのSLOモニタリングの仕組み

ここからサイトリライアビリティエンジニアリングのお話しになります。 これまでやってきた手動で温かみのあるエスカレーションを自動化・セルフサービス化していきます。これがソフトウェアによる信頼性の確保とトイルの削減に繋がります。

前提として、SREがCUJを補足するのは無理だなと思い、APIエンドポイントを開発するチームが一番知っているはずなので、ここは開発チームにみてもらうことにしました。
解決策としては、ポイントごとのSLOをモニタリングする仕組みとして、開発者がリポジトリにconfigをプルリクしたら、CDK for TerraformからNew Relicに反映して、アラートが飛ぶ仕組みを作りました。

一番利点を感じているのが、CDK for TerraformとTypeScriptで部分です。SLOとバーンレートが決まったときにアラートの閾値を決めるためには計算が必要です。
この計算を自動で実施してくれるようなモジュールを作って、New Relicのアラートコンディションに設定するということができます。

最終的に、元々エスカレーション100本ノックで実施していたことが仕組み化され、「モニタリングやってみませんか？」と声をかけやすくなりました。SREチームがサポートしてくれて、このconfigにこういう設定を追加すればダッシュボードが見れるから週次のチームミーティングで確認してください、としてSLOモニタリングが始められるようになりました。

今後は、リクエストベースで可用性・レイテンシーを比較してたのですが、ユーザーの割合ベースで可用性とレイテンシーを確認したいという声があったので、configとNRQLを作っていく予定です。また、開発者が自分でコミットして改善していきたいというサイクルに入ったら、CI/CDも作っていきたいなと思っています。

DevSecOpsへの展開 - 全てのチームの能力を最大限に引き出す｜New Relic株式会社 伊藤 覚宏

最後に、セキュリティにもオブザーバビリティ・New Relicが活用できるというお話しをします。

アプリケーションを開発していて、「脆弱性が発表されました！」ということがあったとします。おそらく、まず自分たちが作っているアプリにその脆弱性が影響するのか、また影響のあるユーザーはだれかなどを調べると思います。

場合によっては、システムを止めるのか、対策体制はどうするのか、アプリケーションを修正するのかなどの決断を誰がどのように下すのかが重要になってきます。これを解決できるのが、New Relic Vulnerability Management、脆弱性管理機能というのになります。

New Relic のAPMを入れていれば、普段からランタイムやミドルウェアなどの構成情報を収集しているので、脆弱性についてどういう緊急度のものが何件、どのアプリケーションに含まれているのかという情報を可視化していくことができます。
現在はアプリケーションが使っているライブラリの部分が対象となっていますが、サードパーティの情報と連携することができるので、広い範囲で脆弱性管理を行うことができるソリューションになっています。

これを使うと、アプリケーションの中の細かいライブラリ情報、バージョン情報などを人が管理するのではなく、自動で管理して、脆弱性に一致するものがあれば警告を発します。セキュリティ部門が実施するのではなく、普段から自分たちが動かしているアプリケーションをみながら、実働環境をリアルタイムに把握していくことができるようになります。

無料サインアップ｜1名分のフルアクセス、100GB/月のデータ保存

ここまでお話ししてきたNew Relicについて、試してみたいという方には無料サインアップをご用意しています。こちらに含まれるのは、1名のフルユーザーアクセスと100GB/月のデータ保存容量です。無料サインアップはこちらからお試し頂けます。

有償契約に移行したあとでも1ユーザー分と100GBまでのデータは無料枠のままですので有効にお使いいただけます。また、New Relicの機能は非常に多岐に渡りますので、自習用に様々なコンテンツを提供するNRU（New Relic University）公開し、エンジニアの皆様をサポートしております。こちらもぜひご覧いただければと思います。