IBM Developer Japan Webサイトは2021年3月15日をもって終了となり、日本語コンテンツの一部は、オープンソースとして、提供予定です。 URLはこちら

LogDNAによる可観測性(Observability)の説明

アプリケーションが複雑化する中、この混乱状態からどのように新しい洞察を引き出し、役立てていますか?可観測性は単なるバズワードでしょうか、それとも考慮に値するものでしょうか?

IBM CloudチームのSai Vennamです。本日は特別ゲストをお招きしています。こんにちは LogDNAのデベロッパー・アドボケイト、Laura Santamariaです。

補足しておきますと、LogDNAはIBM Cloudにおける可観測性の領域で重要な役割を果たしています。では、本日は可観測性についてお話しします。

alt

[可観測性(Observability)の定義]

可観測性とはシステムの特性です。ユーザーがシステムの内部状態を把握し、動作を監視して、問題解決に必要な情報を得るのに役立ちます。

alt

[可観測性の3つの要素]

まずは私の得意分野であるロギング。その次がメトリックです。これは収集されるあらゆるデータのさまざまな分析指標です。最後がモニタリングです。モニタリングではシステムを詳しく調べて、その稼働状態から新しい洞察を取得します。

alt

[インフラストラクチャー]

では例を挙げて説明していきましょう。左下に描かれているのは本日取り上げるインフラストラクチャーです。これはパブリック・クラウドです。どのクラウドでも同じです。そしてユーザーのオンプレミス。こちらは何らかのユーザー・データとしましょう。おそらくはタブレットか携帯電話です。

alt

[ペルソナ]

これらすべてのインフラストラクチャーは、データを作成、出力しています。ここで注目したいのは、それらのデータを消費するペルソナ(想定ユーザー)です。開発者、運用者、セキュリティー担当者のペルソナがあります。ここで着信するデータの量は膨大です。そこで、それぞれのユーザー・ペルソナが理解しやすいように、データを絞り込みたいと思います。

alt

[ロギングの3つのレベル]

まずは開発者からです。開発者はどのようなことに関心がありますか?ここで少し補足しておきたいと思います。ロギングが発生するすべてのレベルを説明しましょう。3つのレベルについて考える必要があります。

オペレーティング・システム、Kubernetesまたはその他のプラットフォーム。ここではKubernetesを使いましょう。私も気に入っています。最後がアプリケーションです。

alt

オペレーティング・システムとKubernetesは有益なログを送信します。ユーザーは多くのデータをそのまま使用したり、独自のデータを追加したりできます。しかしアプリケーションには多少の時間を費やす必要があります。

[ペルソナ: 開発者]

開発者は適切なイベント・ストリームを作成する必要がありますが、ガーベッジイン・ガーベッジアウト方式が前提となります。つまりアプリケーションで正しいデータを出力するには、正しいデータを入力する必要があります。そうすることで有益なログを取得できます。

alt

プラットフォームはKubernetesやオペレーティング・システムの優秀な開発者によってインスツルメントされています。しかしアプリケーションのインスツルメンテーションについては、ユーザー側の開発者次第ということですね。

alt

例えばここにオペレーティング・システムがあり、その上でKubernetesが動作していて、Kubernetesで動作するアプリケーションがあります。

alt

これらすべてがそれぞれデータを送信しています。したがって3つの異なるレベルのデータがあり、そのすべてが発信されて、情報を必要としている開発者に届きます。

alt

アグリゲーター

なるほど、すべてのデータがこの中心エリアに向かっているようですね。そうです。これがアグリゲーターの機能です。アグリゲーターはすべてのデータを取り込み、ユーザーが利用できるよう1カ所にまとめます。

alt

しかし開発者はすべての着信情報に関心があるわけではありません。開発者が関心のあるデータだけを抽出するにはどうしますか?先に触れたように、おそらく開発者は特定のアプリケーションをインスツルメントしているでしょう。それをどのように抽出しますか?

多くの場合、アグリゲーターはフィルターを備えています。例えば開発者がデバッグに関するデータや情報だけを求めている場合フィルターによって、開発者はダッシュボードまたはその他の方法で、データにアクセスし必要な情報だけを調べることができます。

alt

これが可観測性ソリューションの中核です。アグリゲーターはデータを収集するだけでなく、データを外部化して、公開する必要があります。それによって開発者はデータにアクセスし、新しい洞察を得ることができます。パズルのこの部分は解決しましたね。

alt

[ペルソナ: 運用者]

では運用者はどのようなことに関心がありますか?どのような運用チームがあって、システムからどのような情報を得ようとしていますか?

運用チームはシステムの性能低下、ポッドのフォールオーバーの状態、データベースがフルになっていないか、システムの修復方法などの情報を求めています。運用チームはこうしたさまざまなシステムからデータを入手し、フィルタリングして別のダッシュボードやインターフェースに出力し、必要なデータだけを入手します。

alt

運用チームは細かいアプリケーション・レベルのログにあまり関心がないかもしれませんが、Kubernetesに対してはCPUの使用量や、水平ポッド・オートスケーラーを構成して制限超過を防止すべきかといった情報を求めます。

[ペルソナ: セキュリティーチーム]

それでは最後にセキュリティー・チームについて考えていきましょう。おそらく彼らにも専用のダッシュボードが作成されています。セキュリティー・チームは、一般的にサード・パーティーのツールを使用しています。

alt

彼らは脅威IDや顧客IDを識別し、特定された潜在的脅威を詳細に分析する必要があります。その情報をアグリゲーターに入力すると、チームは問題点を確認して理解し、個々のセキュリティー・アナリストに必要な情報を正確に判別できます。

ここで気になる点があります。必要な情報は必ずしもシステムの問題点だけではありません。多くの場合、セキュリティー・アドバイザーは今起こっていることや、その次に起こることを知る必要があります。一日中座ってログを観察しているわけにはいきません。そのとおりです。

[モニタリング]

ここで役に立つのがモニタリングで、双方向で行われます。アラートを自動化して送信し、チームが関心を持っている特定の情報や、確認する必要がある特定のイベントを各グループに通知します。

alt

例えばシステムに対して想定外のアクセスが行われていたとしましょう。システムは人間よりもずっと早くそれを検知します。それこそがアラートの役目です。運用チームがユーザーと同時にサービスの低下に気付くようでは困ります。彼らは事前に検知しなければなりません。

優れた可観測性ソリューションには、データを外部化するだけでなく、学習する機能も必要です。開発チームはSlackが非常に使いやすいと感じているので、チャットボットを作成して、特殊な例外が発生した場合にそれを把握できるようにしています。

alt

運用チームはメッセージ・システムなどを使用して、夜間に障害が発生した場合にアラートを受け取り、ただちに調査を開始できるようにしています。

alt

最後にセキュリティー・チームですが、先に触れたように大抵は、サード・パーティーのツールかカスタム・ダッシュボードを使用します。セキュリティー・チームはカスタム・アラートを設定し、いつ障害が発生するかを正確に知ることができます。

alt

実はこれが新たな常識です。複数のクラウドがあり、オンプレミス・システムがあり、ユーザーから直接データが送られてきます。あなたは何が起こっているかを理解できなければなりません。それこそが可観測性です。

alt

可観測性の概要をご覧いただきありがとうございました。

無料のIBM Cloudアカウントに登録すれば、費用をかけずにいつでもクラウドで作業を開始できます。