誰が、いつ、何をリリースしたか？ アプリリリースに自信を持って臨むためのオブザーバビリティとは

1. アプリケーションを「自信を持ってリリースする」

クラウドネイティブなアーキテクチャが主流になった今、私たちはアプリケーションを以前よりも頻繁に、かつ小さな単位でリリースするようになりました。

これは開発サイクルを加速させ、各チームが自律的に機能開発・デプロイを行えるという点で大きなメリットがあります。ただ一方で、「いつ、どのチームが、どのアプリケーションに対して、どんな修正を行ったのか」というのを把握するのは非常に難しくなります。

たとえば、ある日突然サービスのエラー率が上がったとしましょう。すぐに「直前に行われたアプリのリリースが原因かも」と仮説を立てることはできますが、それを証明するには相応の手間とナレッジが必要です。ログをあさり、関係者にヒアリングをし、コードリポジトリやCI/CDツールを確認し……。これでは、せっかくの高速開発・運用の足を引っ張ってしまいます。

あるいは、あなたが担当しているアプリケーションで何かの問題が起きたとして、もしかすると、その原因が他のチームのコードプッシュによるものかもしれません。だとしたら、そうと理解できるまで果たしてどれだけの時間を調査に費やす必要があるでしょうか。想像もしたくないのではないでしょうか。

2. リリースと同時に「見える化」する

こういったアプリケーションのリリースという作業は、例えばコードレポジトリのリリースページで公開されていたり、何らかのシステム管理サービス上で開始と完了が管理されたりします。ただ、その作業と、実際のシステムの状態・変化というものを相関付けることは時に難しかったりします。

こういった難しさに対してSplunk Observability Cloudでは、アプリケーションリリースなどの任意のカスタムイベントをチャート上に表示し、システムの状態と相関付けて可視化することが可能です。

サービスの健全性を可視化するダッシュボード上にこういったリリースイベントを表示することを通じて、

• いつ、どのバージョンのアプリがリリースされたかを、ダッシュボード上に明示
• リリース前後でリクエスト数、レイテンシ、エラー率に変化があったかを一目で比較

さらには、問題が発生した際には当然「どんな変更が行われたのか」「どんなコードが問題を起こしているのか」といった調査が必要になることがあります。単純に可視化するだけではなく、こういった問題調査に必要となるような情報もこのカスタムイベントに含めておくことで、周辺サービスへの動的なリンクを生成することもできます。

これにより、「このバージョンのリリースが原因かも？」という仮説を、ほんの数クリックで検証することができるはずです。

3. もしも新バージョンでエラーが出たら

例を見てみましょう。

あるアプリケーションが動いています。マイクロサービス化されたアプリケーションによって成り立つサービスで、一つ一つの丸・四角などのオブジェクトがアプリケーションやデータベースなどを表しています。ざっと見た感じ、大きな問題は起きていなさそうというのは分かるはずです。

そして、あなたはproduct-catalogというサービスを担当しているとします。サービスの健全性をモニターするダッシュボードでは、特にエラーも記録されず、普段と同じように動いています。

さて、この日、あなたが少し席を離れている間に、あなたのチームのメンバーがアプリケーションへの修正リリースを行ったようです。

知らなくても大丈夫です。このダッシュボード上には、アプリケーションのリリースイベントが記録され、チャート上にそのリリースタイミングがマッピングされています（青い菱形とライン）。さらには各チャートも、アプリケーションのバージョン別にリクエストレート等が表示されるようになっていますね。どうやら、青いラインが引かれているタイミングで、これまで動いていた2.0.1というバージョンから進んで、2.1.8というバージョンのアプリケーションがリリースされたようです。

どんな修正リリースが行われたのでしょうか。先ほどのイベント発生を示すマーカーをクリックすると、リリースイベントが表示されており、そこにはGitHubのリリースページへのリンクが設定されています（青枠）。これをクリックすると、リリースページに記載された修正内容を知ることができます。リリースノートを見ると、将来リリース予定の機能を、実際には動かないように制御した形で追加したようですね。

そのリリースからまもなく、エラー率が徐々に上がり、アラートが発報されました。Splunk Observability Cloudのダッシュボードでは、そのアラートがリリースイベントと同じようにチャート上に表示されます。チャート自体も赤く変化して、問題が生じていることを教えてくれます。
※もちろん、アラートを検出したら普段皆さんがよく見ているであろうコミュニケーションツールやインシデント管理ツールに対して通知を上げることもできます。

このことから、新しいバージョンのアプリケーション2.1.8をリリースした直後からエラー率が上昇したようだということは想像に難くないはずです。

冒頭に開いていたサービスマップを改めて開いてみても、エラーを複数のアプリケーションで記録しています。

これを裏付けるために、先ほど検出されたアラートからAPM Troubleshootingというページをクリックしてみましょう。

product-catalogサービスのService Centric Viewというページで概況を確認しつつ、Tag Spotlightというページを開いてみましょう。service.versionという属性に関するチャートをオーバーレイすると、見事に新しいバージョンのアプリケーションでのみエラーが記録されていることを確認できます。
※ 黄色の枠で囲まれている部分がservice.version = 2.0.1に対するリクエスト、オレンジの枠で囲まれている部分がservice.version = 2.1.8に対するリクエストです。エラーが記録されているのは、service.version = 2.1.8に対するリクエストのみです。

では、この新しいバージョンのアプリケーションで実行されていた処理をトレースから追いかけてみましょう。当該時間帯に記録されているトレースを一つ選んで、ウォーターフォールを表示すると、確かにエラーを記録しています。

エラーになったスパンを開いて、その属性を眺めてみると、エラーメッセージを確認できます。

リリースページを通じて、無効化した状態で追加したはずの機能がどうやら有効になってしまっていて、結果的にエラーが生じる設定になっていることが示唆されています。必要であれば、画面右下の“Logs”というリンクをクリックして、このトレースに関連するログを参照することも可能です。

今回の例では「本来無効にしていたはずの機能フラグが有効になっていたことが原因でエラーが発生していた」と判明しました。

では、どんなコードが含まれていたんでしょう。このproduct-catalogサービスのコードレポジトリへのリンクもここから辿ることができたりします。
※今回の例ではコードレポジトリへのリンクにしていますが、実はここのリンクは動的に設定することができます。後述で仕組みを紹介するので、柔軟に工夫してみましょう。

ここまで分かれば、復旧のためにロールバックするだけです。旧バージョンを再リリースすると、そのイベントもダッシュボードに可視化され、グラフ上のメトリクスも徐々に改善していきます。そして一定時間後には、アラートも自動的に解消されました。

こうした一連の変化を可視化し、必要に応じて調査を柔軟に行うことができるというのは、開発者にも運用者にも大きな安心感を与えてくれるはずです。

「何かあってもすぐ戻せる」「根拠を持って判断できる」――これが、システムの信頼性とスピードの両立において、欠かせない視点だと実感しています。

4. 技術的な仕掛け：シンプルだけど強力な2つの工夫と1つの原則

このような可視化やリンク機能は、実は驚くほどシンプルな仕掛けで実現できます。

リリースイベントの登録

アプリケーションのリリースタイミングを記録するには、特定の形式のPOSTリクエストをSplunk Observability Cloudに送るだけで完了します。APIリクエストに関するガイドはこちらを参照してください。

以下のようなデータをPOSTリクエストに含めて送信することで、アプリケーションリリースというイベントと、それに関する付帯情報をSplunk Observability Cloudに登録することができます。

[
    {
        "category": "USER_DEFINED",
        "eventType": "Application Release",
        "dimensions": {
            "deployment.environment": "${ENVIRONMENT}",
            "service.name": "${SERVICE}",
            "service.version": "${VERSION}"
        },
        "timestamp": ${TIMESTAMP},
        "properties": {
            "release.git": "${GIT_REPO}/releases/tag/${VERSION}"
        }
    }
]

例を見ても分かる通り、

• 環境名
• サービス名
• バージョン番号
• リリース実行時刻
• 任意のリンク（GitHubのリリースノートなど）

といった情報を含むリクエストを送信することでカスタムイベントを登録します。CI/CDの中に組み込むのも簡単なはずです。ダッシュボード上では、Event Overlayオプションでこのリリースイベントを登録するように設定しておくだけです。

Global Data Link：コンテキストを外部サービスまで拡張

もう一つ便利なのが、Global Data Linkです。これは、トレースやメトリクスに含まれる属性（たとえばサービス名やバージョン番号）を使って、外部URLへのリンクを動的に生成する機能です。

この例では、service.nameという属性に入る値を、Githubのレポジトリ・ディレクトリのURLに組み込んでいます。これによって、上で見た今回の例では、product-catalogサービスに関連するスパンからproduct-catalogサービスのソースコードレポジトリまでジャンプすることができたのです。

ポイントは、Splunk Observability CloudやSplunk製品に限定されない外部サービスに対するリンクを生成することができるという点です。システムの開発・運用にはさまざまなサービスを利用しているはずです。それらをいくつもブラウザで開いておいて、何度も画面を切り替えて、目でデータを突き合わせて…というのは経験したことがある方も多いでしょう。Global Data Linkを使えば、調査において必要となるコンテキストをSplunk Observability Cloudの外部にまで拡張し、調査やデバッグに必要な情報まですぐに辿り着けるようになるのです。

OpenTelemetryセマンティック規約への準拠

ダッシュボード上でバージョンごとのチャートが生成されたり、Tag Spotlightで属性に基づいた傾向を確認したと思います。これらは、トレースやメトリクスに含まれる属性に基づいてチャートを集計するオプションを設定していることで実現しています。

どんな属性であれテレメトリーデータに付与され、かつ、Splunk Observability Cloudで集計ができるようにオプション指定していればよいのですが、例えばアプリケーションごとに異なる属性名を使用してしまうと、このオプションは有効に機能しなくなってしまいます。

その点、SplunkはOpenTelemetryに完全準拠しているオブザーバビリティソリューションです。そして、OpenTelemetryにおいては、セマンティック規約というものを定め、これらの属性として何を一般的に利用するのが推奨かを定めています。セマンティック規約は、テレメトリーデータに付与する属性に関するガイドラインを提供するものなので、これに準拠するようにしておけば、自ずとオブザーバビリティソリューションを使いこなしやすくなっていきます。

5. おわりに

Splunk Observability Cloudを使えば、アプリケーションのリリースといった人が行った変更作業などをテレメトリーデータと相関付けていくことができます。これは、システムが出力するテレメトリーデータだけに閉じたオブザーバビリティをさらに拡張して、より開発者や運用者が自信を持ってサービスを開発・運用していくことを可能にし、ひいてはサービスを利用するユーザにとっても安心してそのサービスを使うことができるという状態を作り出すことにつながります。

クラウド時代の「自信あるリリース」のために必要なこうした仕組みづくりをSplunk Observability Cloudでやってみましょう！

Splunk Observability Cloudは14日間のフリートライアルを提供しておりますので、こちらから是非お試しください。また、トライアルにさきがけたコンサルティングや相談なども、Splunkのエキスパートまでお気軽にお問い合わせください。