オブザーバビリティを実現するプラットフォーム「New Relic」
オブザーバビリティとは、オライリーの『Observability Enginieering』という書籍によると、「システムのあらゆる状態を説明できる特性」と記されている。そんなオブザーバビリティを実現するためのプラットフォームを提供しているのがNew Relicである。「オブザーバビリティの分野において、New Relicは国内ナンバーワンのシェアを誇る」と高木氏が言うように、New Relicはユーザー体験からインフラまですべてを追跡し、ステークホルダー全員にシステム全体の可観測性を提供する。
New Relicを導入するメリットは、障害対応の時間削減ができることに注目が当たりがち。だが、顧客への提供価値を最大化するために必要な、ベロシティ（作業速度）の向上とリライアビリティ（信頼性）の向上が期待できる体制の構築が可能なのだ。
オブザーバビリティを導入することで、ユーザー視点のモニタリングによるアラートの最適化や原因のボトルネックへのドリルダウンを高速、かつ属人化しない体制ができることで、エンジニアがコア業務に注力できるようになるだけではない。コミュニケーションの効率化も実現する。SLI/SLO運用により、共通指標を元にしたコミュニケーションで開発速度と信頼性を両立するのはもちろん、事業サイドと開発サイドで共通指標を持つことで、顧客への価値提供を最大化できる。これらがオブザーバビリティ導入による開発体験向上における大きなメリットだ。
事業を拡大するため、2つのプロジェクトが進行
具体的にNew Relicを導入するとどんな課題を解決できるのか。その事例として登壇したのが、レバテック開発部の蒲生氏である。レバテックは「日本をIT先進国に」というビジョン、「IT人材と企業を増やし、伸ばし、繋げる」をミッションに掲げ、ITエンジニア・クリエイターのフリーランス、転職、就職、教育のすべてを備える採用プラットフォームを提供している。また最近ではカンファレンススポンサーやテックブログなど、技術広報にも力を入れている。
「レバテックでは、事業をより加速させるため、リアーキテクトプロジェクトの進行とリアーキテクト前の既存システムの運用という2軸のシステム戦略が動いています」と蒲生氏は話す。
2軸でのシステム戦略を進めていくうえで、課題やリスクはどのようなものがあったのか。既存システムの運用課題は2つ。一つはシステムの内部構造が複雑なこと。サービス同士の通信が多く発生し、メトリクスやログだけで通信を追っていくことが難しいほか、レガシーなコードによる認知負荷の高さ、会社に長く属さないと複雑な内部構造がわからないという属人化の問題があった。
もう一つの課題は、サービスの信頼性を計測できないこと。安定稼働が何を指しているのか、開発とビジネスであまり合意が取れていない。計測したとしても、カーディナリティの高いデータが取得できておらず、たとえSLOが下がっても、どのぐらいのユーザーに影響が出ているのかがわかりづらい状態だった。「鳴り響くアラート、オオカミ少年さながらのアラート、機能開発の鈍化、積もり積もった運用作業という形で、課題の影響が表面化してきました」（蒲生氏）
これらは開発体験の悪化を表しており、開発生産性の低下につながる。そこで開発体験を向上させるために、通信状態をコードから追ったり、システムに詳しい人が頑張ってログを分析したり、調査用のログを出す変更をデプロイしたり、重要度高、緊急度低の運用タスクは優先度を下げたりしてきた。そこで通信状態が可視化され、調査しようとする人が調査できる、対応が必要なアラートが鳴る、システムに変更を加えなくても調査ができる、システムの継続運用に必要と判断される運用タスクの優先度を適切につけていく状態を目指すことにした。
リアーキテクトプロジェクトのリスクは大きく3つ。第1に、完遂までのリリース回数が増えること。「デプロイ失敗率が高いまま、開発を継続していくと障害も多く発生してしまう。品質が落ちる回数が増えるので、開発チームへの信頼度が下がり、最悪、プロジェクトがストップしてしまう可能性がありました」（蒲生氏）
第2に、機能やシステムを捨てない限り、システム全体の複雑性は上がっていく一方であること。第3が遅延した時のリスク。既存システムの苦しい運用がその分、継続されてしまうという。
既存システムの運用作業負荷を軽減し、リアーキテクトシステムのデプロイ時の品質を担保する。そのために蒲生氏がアプローチとして選択したのが、オブザーバビリティの採用である。システムの内部構造の可視化と信頼性の計測ができるからだ。
オブザーバビリティツールとして、導入したのがNew Relicである。「New Relicでメトリクス、ログ、トレース、イベントの各テレトリデータを取得、ダッシュボードでわかりやすく表示されるだけではなく、トレース情報から自動でサービスマップを作成してくれます」（蒲生氏）
New Relicを導入したことで、新たな実装なしでシステムの状態が分かるようになっただけではない。「システムに関心のある人が、データを追うことによって自分で調査できるようになるなど、属人性の軽減が図れます。傷害調査にかかる工数も削減でき、暗黙知が形式知化されるので、障害発生の予兆検知、未知の未知への対応がしやすくなることも期待できます」と蒲生氏は見込める効果を紹介する。
信頼性の計測は、SLI/SLOを設定し、New RelicのSLM（サービスレベルマネジメント）という機能を活用することで実現する。「予測モデルの作成が、オブザーバビリティの肝」と蒲生氏。システム内、およびシステムとビジネスの相関性も分かるようになるため、投資の判断がしやすくなるという。
また、カーディナリティの高いデータも取得できるようになる。「SLOを設定しても、どんなユーザーに、どういうときに、どんな影響が出ているのかわからないと、原因分析がしづらいです。なのでカーディナリティの高いデータの取得は、SLOの運用に不可欠です」（蒲生氏）
信頼性の計測が実現することで、「開発とビジネスの指標と相関の強い物を管理できるようになること、また開発者にとってはアラートの精度が向上することが期待できます」と蒲生氏は力強く話す。
これらの結果により、New Relic導入をすることで障害対応時間の減少、オオカミ少年アラートの減少、機能開発により集中できる状態になるという効果が見込める。また運用作業のコントロールができることで、「システムのパフォーマンスがSLOを満たすレベルを維持し続けるために必要な機能開発と、運用作業の優先度づけを適切に行っていけるようになることで、ビジネス層にとっても納得度の高い説明ができるようになるのでは」と蒲生氏は指摘する。
2つのフェーズに分けて、New Relicを導入 進捗の観点と指標
レバテックでの実践例についても蒲生氏は紹介。フェーズを2つにわけてマイルストーンを設定。フェーズ1ではオブザーバビリティの理解やツール移行、アラート禍以前を実施。フェーズ2ではSLOの設定と障害対策改善に取り組んだ。「このマイルストーン作りではオブザーバビリティの成熟度という考え方を参考にしました」と蒲生氏。
フェーズ1の評価の観点は、オブザーバビリティの考え方のインストール、オブザーバビリティのオンボーディング、モニタリンツツールからオブザーバビリティツールへの移行、アラートの最適化。評価指標はオブザーバビリティの理解度、ツールの移行進捗度、クリティカルアラート（重大なお知らせ）の発報数とした。「インストールとツールのオンボーでイングに関しては、勉強会やNew Relicのハンズオン、模擬障害対応などの取り組みを行いました」（蒲生氏）
移行の推進には、New RelicアラートのTerraformライブラリを作成したり、New Relic合宿を行ったり、アラート勉強会を実施したりした。
「現在のところ、ツール導入を当初目標としていたシステムについては無事完了しており、合計30システムに導入しました」（蒲生氏）
アラートもNew Relicに移行済みで、クリティカルアラート発報数は、約1カ月間で約4割削減できた。また、レバテックでは定性面での効果測定も行っており、勉強会アンケートでオブザーバビリティの浸透度、エンゲージメントサーベイでは開発者体験をチェック。勉強会アンケートでは効果は出ていると回答している人は多いものの、エンゲージメントサーベイでは明確にオブザーバビリティ導入による効果はまだ見えてきていないという。
現在はフェーズ2のSLO設定、障害対応の改善に取り組んでいるレバテック。オブザーバビリティ導入による開発生産性を最大化し、開発者体験を向上させるためのチャレンジはこれからも続く。
当講演をもう一度ご覧になりたい方は再放送をチェック！
レバレジーズ様との当事例講演の録画をNew Relicサイトで公開しています。ご視聴はこちらから！
