Developers Boost 2019 B6「CloudNativeな監視とは？」を聞いたので復習がてら内容を書きだしてみます。

CloudNativeな監視とは？

そもそもCloudNativeとは？

「CNCF Cloud Native Definition v1.0」を参照。
雑にまとめるとクラウド上で実行されるアプリケーションまで、基盤であるクラウドに最適化すること。発表はアプリケーションのなかでも特にマイクロサービスの監視に焦点をあてたものでした。

マイクロサービスとは？従来のオペレーションとの違いは？

従来のWeb3層モデル（ユーザ←WebーApp→DB）で障害があった場合、まずはWeb、次にApp、その次にDB…という風に上位層からコンポーネントの調査をすることが可能です。

しかし、小さなサービスを連携させてひとつのサービスを作るマイクロサービスの場合、上位層から順番に調査するのは非現実的です。
なぜならコンポーネントの量が多く、中身の内容はどれも違うから。
例:ツイッターの分散システム

障害があったら調べなくちゃいけない。でも量が多すぎて従来の方法では確認しきれない。
こんな時に役に立つのが、可観測性Observabilityという考え方です。

可観測性Observability？

ざっくり言うと、様々なシステムやアプリケーションを観測することという意味です。
（ただし、人によって定義が違うことがあるので注意。）

想定できない障害に対するアプローチ Monitoring
サービスを理解し改善すること Analytics
この２つを目的としています。

ところで、なぜ目的が２つあるのでしょうか？
Monitoringだけではいけないのでしょうか？

Monitoringだけではいけない理由

従来のMonitoringでは「想定された障害」に対してアラートを出すなどの対策を取るものでした。
しかし、分散システムではどのような障害が起こるかは予測不可能。しかも障害が起こってもなぜ障害が発生したのかのデバッグができません。

つまり、分散システムのMonitoringに求められるのは、
システム全てコンポーネントに対して
「事前に予測できる障害」「事前に予測できない障害」の両方を観測しておき、後からデバッグできるようにすることです。

それを可能にするのが「可観測性 Observability」！

可観測性 Observabilityにおけるテスト Testing

忘れてはいけないのは可観測性 Observabilityにはテスト Testingも含まれるということ。特に、サービスの正常性を知るため・リリース後に品質を向上させるために実施するという意味合いが強いです。
例:アップデートによる品質劣化の検知

可観測性 Observabilityを実現するツール

可観測性 Observabilityを実現したいときに使用されうるツールには、例えば下記があります。

これらの共通点はTelemetryなツールであるということ。

Telemetryとは？

https://businessnetwork.jp/Detail/tabid/65/artid/6206/Default.aspx
https://www.netone.co.jp/report/column/column1/20171129.html
などが分かりやすかったです。
超雑に言うと、デバイス側は収集したデータを定期的に送信し、データの購読側は取得したデータをもとに分析などを行う、この一連の流れのこと。
Telemetryは可観測性Observabilityを可能にするための手段になります。ただし、Telemetryなツールの導入＝可観測性Observabilityの実現ではないことは頭に入れておく必要があります。

Telemetryには下記の３要素が含まれています。

Metrics：サービスを定量的に数値として計測すること
- 統計的に集計が行えることです。予測やアラート機能を実現します。ただし、個々のメトリクスだけ見ても何も分からないことが多いです。
- 上記ツールだと、Prometheusが該当。
Logging：コンポーネントに対するイベントを記録すること
- Loggingがあると、事象を人間が容易に把握できるようになります。実装が容易なのも強み。
- ログの形式はプレーンテキスト・構造体（json）・バイナリなどです。
- 注意点は、ストレージの設計やLogLevelの設計などは事前に考えておかないといけないこと。加えて複数コンポーネントに関して横断的な検索をするのは不得意です。
- 上記ツールだと、Grafana Lokiが該当。
Tracing：リクエストに対するイベントを記録すること
- リクエストのライフサイクルを横断的に見ます。
- ユーザのリクエストに紐づいており、コンポーネント間の通信遅延時間（レイテンシ）の記録に向いてます。
- ただし、インフラ側とソフトウェア側の両方にアプローチが必要で、ソフトウェア側に負荷がかかることに注意が必要。
- 上記ツールだと、Jaegerが該当します。

現状だとMetrics・Logging・Tracingの全てを連携するための方法は確立されていません。時間を軸として、Metrics・Logging・Tracingで取得した情報をそれぞれ確認していく必要があります。

Analytics

ここまでが「想定できない障害に対するアプローチ Monitoring」の話。
可観測性 Observabilityを構成するもう一つの要素には「サービスを理解し改善すること Analytics」を忘れてはいけません。
例えば、Monitoringで得られた情報を分析し、ビジネスに活かすことなどがAnalyticsの範囲です。
監視システム全体を観点とし、分析することが該当するのですが、この観点に関してはまだまだ研究の余地ありとのことでした。

０からはじめる監視

監視経験０の人が監視を始めるなら下記の３点を試してみるといいそうです。

社内の監視が強い人の真似をする
MeetUpなどで強い人とコンタクトを取る
本を読む
やっぱり周りから刺激を受け続けることがモチベーションアップにもなるしおすすめとのこと。

Developers Boost 2019 B6 備忘録