관련링크

 こんにちは、

WhaTap Labsのテクニカルライターである、 Sunnyです。

皆さんは「톺아보다(ドッパボダ)」という韓国語を聞いたことがありますか？ 「톺아보다(ドッパボダ」というのは、’くまなくさぐり調べる’という意味のハングルの韓国語です。

このポストではObservabilityについてくまなくさぐり調べてみましょう。 Observabilityとは何なのか、Monitoringとどう違うのか、なぜ必要なのかについてご説明します。

Observabilityとは何ですか？

ソフトウェアシステムでのObservabilityについて説明する前に、まず単語の由来を学びましょう。「Observability」という概念を初めて導入したのはエンジニアである、Rudolf E. Kálmánです**。**RudolfはObservabilityを以下のように定義しました。

Rudolfがobservabilityという概念を利用したのは、エンジニアリングでのcontrol theoryを説明するためでした。ソフトウェアシステムでのobservabilityはどういう意味でしょう？

現代のソフトウェアシステムでは、observabilityは単にデータ型や入力を意味するものではありません。私たちが管理する複雑なシステムとどのようにやり取りし、理解しようとしているのかについてです。

MonitoringとObservabilityはどう違いますか？

Monitoringでは、何が問題という基準がすでに確立されています。 モニタリングシステムは、メトリクスを収集し、合計を求め、分析します。このプロセスは、事前に定義された問題のパターンを検出します。これをリアルタイムでダッシュボードで見ることも、必要に応じて警告通知を受け取ることもできます。

時には経験豊富なエンジニアの直感に依存することがあります。経験してきたパターンと知識に基づいてデバッギングをします。問題が検出されたら、以前に知られていた問題と同様のパターンまたは類似性があるかどうかを比較します。

モニタリングでよく使用される静的ダッシュボードは、通常、各サービスごとにデータを収集して表示します。この方法は、エンジニアがシステムのいくつかの側面を理解するときに便利です。つまり、ダッシュボードは、もともとメトリックスの組み合わせと注目すべきトレンドフローを概略的に示すように設計されています。ただし、新しい問題をデバッグするときは、ダッシュボードに制限がある可能性があります。

しかし、システムでどのような問題が発生しているのかわからない場合はどうなりますか？ 英語でこの状況をUnknown Unknownsと呼びます。現代の分散システムアーキテクチャでは、問題の状況を解決する難易度がはるかに高いです。1つの新しいリクエストは複数のサービスを経て、複数のネットワークを介して移動することもあります。誰もどんな問題が起こるのか予測できません。一度も経験してみなかった状況に直面することもあります。

Observabilityでは、隠された問題を見つけることが重要です。これを行うには、ログ、メトリクス、イベント、トレースなどのさまざまな情報をまとめて集めなければなりません。その情報の文脈と関連性を把握できるはずです。このようにシステムを一目で把握する能力を備えたときに可視性(visibility)が確保されたと言います。

Observabilityがなぜ必要なのですか?

メトリクスとモニタリングだけでは十分ではありませんか？ はい、結論から申し上げますと、十分ではありません。複雑さが増した現代のシステムでは、従来のモニタリングには対応に限界があります。現代のシステムは、以前よりはるかに高度化され、細かく分割されています。ソフトウェア開発者は、既存のモニタリングだけでは現代の複雑なシステムを完全に理解することはできません。

Observabilityが必要な理由を理解するには、ITシステムがどのように変化しているのかを概説する流れを知る必要があります。10年前だけでも、ユーザー数が今ほど多くはありませんでした。システムとプラットフォームが何千万ものユーザーだけをサポートできるのに十分でした。今ではユーザー数が指数関数的に増えています。数百万から数十億人に達する。 たとえば、Amazonショッピングモールを考えてみましょう。AmazonのWebサイトは、米国内の消費者だけでなく、直球を望む世界中の人々がアクセスしています。割引があるシーズンの場合、トラフィックが爆発的に増加する可能性があります。Netflixも同様のケースです。人気のシーズンのドラマが放映されると、従来のシステムではその規模を余裕ができませんでした。

結論的に余裕がなければならないトランザクション、ユーザー数が過去とは比較できないほど増加したのです。このように変化する規模を余儀なくするには、新しいシステムを導入しなければなりませんでした。この時登場したのがまさにクラウドです。クラウドでは、必要なコンピューティングリソース(サーバー、データベースなど)を必要に応じて使用するのに十分なだけ借りることができます。 変化する需要にもっと柔軟に対応できます。

しかし、クラウドに移動するのは簡単ではありませんでした。1つの大きなアプリケーション(Monolithic Architecture)を丸ごとクラウドに入れると、管理するのがとても難しかったのです。結局、クラウドに移行するために、そのような大きなアプリケーションを小さく分割して作り始めました。それがMSA(Microservice Architecture)です。

レガシーメインフレームアプリケーションは、巨大で複雑な統一された(monitoring)システムで、多数のプログラムで構成されています。各プログラムはお互いへの依存度が非常に高いです。したがって、1つのプログラムで発生したバグを修正するために、プログラム全体をテストする必要があります。

マイクロサービスアーキテクチャ(Microservice Architecture)とは、1つの大きなアプリケーションを複数の小さなサービスユニットに分割したアーキテクチャのことです。各マイクロサービスは相互通信、変更、および組み合わせが可能です。これにより、サービス全体が構成されます。

多くのアーキテクチャがメインフレームからマイクロサービスに移行しました。サービスはますます小さくなり、管理するサービスの数ははるかに増えました。問題はここから始まります。単一のトランザクションが入っているとしましょう。このトランザクションを処理するには、複数のサービスを経ます。トランザクションが処理されるための一連のプロセスを表示できるはずです。そうしてこそ問題が生じたとき、どこから間違っているのか、何を改善すべきかを把握できるからです。

結局のところ、新しいマイクロサービスの複雑さを管理するには、可視性(visibility)が必要です。潜在的な危険因子がどこにあるかを迅速に検出し、リアルタイムで対応する必要があります。クラウド、マイクロサービスなど、ITシステムは非常に急速に変化しています。従来のツールでは、爆発する流入量と速度に追いつくことはできません。マイクロサービスアーキテクチャでも可視性を確保したのがObservabilityです。