オブザーバビリティの活用に、開発者が重要な理由を事例から探る
オブザーバビリティの活用において、開発者が重要な役割を果たすということは実際の活用事例からもわかる。
最初に岡田氏が挙げたのは、ある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の基本的なデータが見えるだけでも品質向上に役立つが、メトリクスを活用してアプリケーション分析することで、サイト改善検討につながる洞察を見つけられる可能性があるという。岡田氏は「オブザーバビリティは旧来型のアプリケーションにも有効に活用できるので、気軽に始めていただければと思います」と話す。
このようにオブザーバビリティを活用するには、データの発生源であるシステム自体を把握している開発者は非常に重要な役割を担う。だがそこから運用を考えたり、運用の視点で必要なデータを捉えたりする、運用担当者の役割も非常に重要であることは間違いない。
「オブザーバビリティはどちらかの力だけで成功するものではありません。最も重要なのは、開発者と運用担当者が連携すること。両者がシステムをよくするという共通の目的の下、意見を出し合って連携することで、オブザーバビリティの真の活用がなされると思います。まずは触ってさまざまなデータを送り、見える化してください。システムの動きが見えればきっと開発者も楽しくなるはず。そして品質向上に役立ててください」
最後にこう語り、岡田氏はセッションを締めくくった。
