オブザーバビリティとは何か？
「本セッションのゴールは、開発者の皆さまにオブザーバビリティを『こんな風に使えるんだ』『自分のプロジェクトでも使ってみたい』など、自分ごととして捉えてもらうことです」
日本ユニシスの岡田氏はこのように述べ、セッションは始まった。
オブザーバビリティは昨今「SpringOne」の基調講演や「VMworld」など、さまざまなイベントで語られるようになっている。さらに今年3月にはオブザーバビリティにフォーカスした単独イベント「Observability Conference 2022 by CloudNative Days」が開催されるなど、開発系イベントでも非常に注目を集めている。
とは言え「オブザーバビリティとは何か」と改めて聞かれると、端的に答えるのは難しい。オブザーバビリティというキーワードで検索すると「『メトリクス』『トレーシング』『ログ』といった3本柱で構成される」との説明が出てくる。また画像検索を行うと、グラフやログ検索などの画面がヒットする。
このような状況から、開発者の多くはオブザーバビリティを運用担当者だけが活用する領域だと思いがちだ。だが岡田氏は「オブザーバビリティは旧来型のモニタリングとは異なり、開発者がいるからこそ、より活用できる領域」と言い切る。
なぜそう言い切れるのか。オブザーバビリティを日本語にすると「可観測性」となる。可観測性と日本語にしてもよくわからないため「『観測』という言葉にフォーカスして考えていきます」と岡田氏。
観測とは「観察し測定すること」である。例えば果物を栽培する際に、人は日照時間や気温などを測定する。この場合の観測目的は明快で「果物の品質向上」にある。「システムに当てはめても同じことが言えそうですよね」と岡田氏は参加者に呼びかける。
「オブザーバビリティは、果物の観測と同様にシステムを観察し、詳しく理解することで品質を向上するためのものだと考えています」
この観察の際に重要になるのが、データである。先の果物の例では、品質向上につなげるために日照時間や気温という生産対象特有のデータを取得し、分析する。システムにおいても同様で、そのシステムを表す特有のデータを取得して、特有の分析をする必要がある。ではそのシステムの品質向上につながる特有のデータとは何か。「それを把握しているのがシステムを作った人、開発者です」と岡田氏は力強く語る。
では、オブザーバビリティで何を観測すべきなのか。岡田氏は「CPUやメモリが思い浮かぶかもしれません。それらも正解ですが、オブザーバビリティのすべてではないのです。答えは『何でも』。オブザーバビリティはどのようなデータも事前定義なく観測することができます。ここが旧来型モニタリングとの大きな違いです」と解説する。
旧来型モニタリングは監視対象のサーバーが決まっており、決められた対象にエージェントを導入し、CPUやメモリなどの決められたデータを収集、監視していた。だがビジネススピードが加速している現在、従来のようなモノリスのシステムではなく、機能ごとに分解されたマイクロサービスでシステムを構築することが増えている。このマイクロサービス時代においては、どのようなデータも事前定義なく送ることができ、観測できることが必要だ。そしてこの「どのようなデータも事前定義なく送ることができ、観測できること」が、開発者にとっても大きな意味を持つのである。
オブザーバビリティの活用に、開発者が重要な理由を事例から探る
オブザーバビリティの活用において、開発者が重要な役割を果たすということは実際の活用事例からもわかる。
最初に岡田氏が挙げたのは、あるIoTサービスの事例だ。デバイスから送信されたデータをMicrosoft Azureの「IoT Hub」が受け、さらにテーブルストレージと監視処理用のキューに転送するファンクション、監視キューからデータを取り出し閾値監視するファンクションがあるというシステムを構築し、サービスを実現した。
IoTサービスのデバイスは日夜増減する一方、プロジェクトはスモールスタートだったため、少人数で運用していた。そこで、デバイス増減に対するスケール対応を人力で行う必要がないように、FaaSをフル活用しシステムを構成したという。だが、ある日お客さまから「いくつかのデバイスデータがなかなか画面に表示されない」という問い合わせがきてしまった。
「ここでオブザーバビリティが活用されていない場合を考えてみます」と岡田氏。IoT Hubから得られる有用そうなデータのひとつが、メッセージの取得数である。それを見ると、デバイスが送ってくるデータの件数に対して、問い合わせの数が少ないということはわかった。だが、ファンクション側にはエラーが来ておらず、また異常終了の履歴もなく、例外のログもなかったという。ファンクションの処理の遅延も考えられるものの、全デバイスではなく特定デバイスだけの遅延であるためそれも違う。
このような状態で障害解析をするにはどうすればよいのか。「ここで出番となるのが、オブザーバビリティです」と岡田氏。オブザーバビリティは先述の通り、どのようなデータも事前定義なく送ることができ、観測できる。具体的には以下のような内容だ。
- ファンクションが起動した際の情報
- プロパティを基にした毎回の処理で扱うメッセージ数
- 各メッセージのエンキューからデキューまでの遅延時間
- 処理の多重度というメトリクス
- 共通プロパティ（処理したインスタンス名・送信元デバイスID・パーティションの情報）
つまり、アプリケーションが内部で知り得るデータすべてを送っているということだ。そのおかげで障害発生時にそれらのデータを多角的に分析し、対応に活かすことができた。
では、オブザーバビリティを使ってどのように障害解析ができたのか。具体的には以下の情報を確認することで、システムのどこに問題があったのかを把握したという。
- デバイスごとのIoT Hubのデキュー遅延時間
- IoT Hubのパーティションごとのデキュー遅延時間
- 送信したデータのパーティションとデバイスIDの関連
- パーティションごとのメッセージ数
- ホストごとの処理多重度
「このIoTサービスの事例では、IoT HubとFunctionsで大量処理することに限界があるとわかったので、並列に処理できるサービスで検討し直すことにしました」と岡田氏は振り返る。
最終的には各メッセージを取り出し、それにロックをかけ正常に処理されれば削除、失敗したら戻すという並列処理に適したサービスに構築し直した。特定のデバイスのみデータの到達が遅延するという障害を解決できたのである。
「障害発生時にオブザーバビリティが収集した、アプリケーションで得られるすべてのデータをさまざまな視点で分析することで、正しい姿に修正することができました。Azureの持つメトリクスやFunctionsのプログラムから出力されるテキストログだけでは、こうした分析は難しかったと思います」
なお同サービスには後日談がある。問題を修正し稼働を開始した直後、「全デバイスのデータが画面に表示されない」とお客さまから問い合わせがあった。Functionsがまったく動いていないため、日本マイクロソフトに問い合わせたところ、Functionsのシステムドライブの容量不足が原因だった。このようなFaaSを使っているケースでもオブザーバビリティは非常に役立つ。メトリクスとして自由にデータを送れるため、FaaSに異常がないか、死活監視に用いることができるのだ。
最後の事例はSpring Boot製のモノリスアプリケーションへの適用である。製品として活用したのはVMwareが提供する「Tanzu Observability」。「Tanzu Observabilityは聞きなじみはないかもしれませんが、私は気に入って使っています」と岡田氏は紹介する。Tanzu Observabilityは元Googleのエンジニアが開発したオブザーバビリティのSaaSサービス「Wavefront」をVMwareが買収し、名称変更したサービスだ。
オブザーバビリティは「Prometheus＋Elasticsearch＋Jaeger」というOSSの組み合わせや「Azure Monitor＋Log Analytics＋Application Insights」などの組み合わせでも実現できる。だが、岡田氏がTanzu Observabilityを気に入っているのには理由がある。
第一がSaaSであるため、Prometheusのようにサーバーを準備する必要がないこと。第二にSpringとの親和性が高いこと。そのため既存のSpring Boot製アプリケーションの依存関係にSpring SleuthとWavefrontの依存関係を含めるだけで、リクエストレートやJVM（Java仮想マシン）のヒープやガベージコレクション、スレッドの数などの基本的な情報が見えるようになる。第三は太っ腹であること。フリーアカウントの用意も不要で「起動すると内部で勝手にフリーの環境を整備し、そこにデータを流し始め、環境へのリンクをログで案内してくれる。非常に手軽に扱えます」と岡田氏。
Javaの基本的なデータが見えるだけでも品質向上に役立つが、メトリクスを活用してアプリケーション分析することで、サイト改善検討につながる洞察を見つけられる可能性があるという。岡田氏は「オブザーバビリティは旧来型のアプリケーションにも有効に活用できるので、気軽に始めていただければと思います」と話す。
このようにオブザーバビリティを活用するには、データの発生源であるシステム自体を把握している開発者は非常に重要な役割を担う。だがそこから運用を考えたり、運用の視点で必要なデータを捉えたりする、運用担当者の役割も非常に重要であることは間違いない。
「オブザーバビリティはどちらかの力だけで成功するものではありません。最も重要なのは、開発者と運用担当者が連携すること。両者がシステムをよくするという共通の目的の下、意見を出し合って連携することで、オブザーバビリティの真の活用がなされると思います。まずは触ってさまざまなデータを送り、見える化してください。システムの動きが見えればきっと開発者も楽しくなるはず。そして品質向上に役立ててください」
最後にこう語り、岡田氏はセッションを締めくくった。
