Monitoring in the time of Cloud Native — Part 9

クラウドネイティブにおけるモニタリングーPart 9

gavin.zhou

10 min readOct 1, 2019

今回からクラウドネイティブにおけるモニタリングに関しての記事をご紹介していきたいと思います。

とても長い文章になるので、いくつかに分けて投稿していきたいと思います。

今回は商品化される前のテストや実稼働環境でのテストについてです。

Pre-Production Testing

テストは、システムの正確性のベストエフォート(最大限努力した）検証であると同時に、故障モードのベストエフォート (最大限努力した）シミュレーションであることを理解することが重要です。単体テストは、指定された入力セットに対してシステムのビヘイビアをテストするだけです。さらに、テストは非常に制御された（多くの場合、モックされている）環境で行われます。コードをファズする人もごく少数いますが、ランダムに生成された入力のセットに対してコードをテストすることがより効率的な場合もあります。ファジングは、oneserviceへの入力のセットに対して包括的にしかテストできません。エンドツーエンドのテストにより、システムのある程度の全体的なテストが可能になり、 fault injection /カオスエンジニアリングにより、これらの障害に耐えるシステムの能力についてある程度の自信が得られますが、複雑なシステムは複雑な状況で失敗します。故障の原因となる可能性のある最後のすべてのベクトルを予測できるテストはこの世の中にはありません。

これらの欠点にもかかわらず、テストはとても重要なものです。他に何もないとしても、コードをテストすることで、より優れた維持可能なコードを作成できます。さらに重要なことは、多くの分散システムである研究により「エラー処理コードをテストするだけで壊滅的な障害の58％を防ぐことができた」ことが証明されたのです。本番環境でのサービスのビヘイビアを理解することを目的としたツールの復興は、テストを不要なものにするということはありません。

Testing in Production

実稼働環境でのテストは、それほど新しいアイデアではありません。 A / Bテスト、カナリアのデプロイメント、ダークトラフィックテスト（シャドーイングと呼ばれることもある）などの方法論もありました。

ただし、実稼働環境でテストできるようにするには、必要に応じてリリースを停止してロールバックできることが絶対に必要です。これは、実稼働環境でテストしているシステムの動作に関するクイックフィードバックループがある場合にのみ、実稼働環境でテストできることを意味します。また、サービスの主要業績評価指標の変更に注意しています。 HTTPサービスの場合、これはエラー率や主要エンドポイントのレイテンシーなどの属性を意味する場合があります。ユーザー向けサービスの場合、これはユーザーエンゲージメントの変化をも意味する可能性があります。本番環境でのテストとは、本質的に本番環境の変化を積極的に「モニタリング」することを意味します。それでは、次の話に移ります。

Monitoring

モニタリングはなくなったわけではありません。実際、モニタリングは非常に重要であるため、可観測性の範囲内で一番重要なものであるという位置づけがなされています。

実稼働環境でテストするためには、適切で効果的なモニタリングが必要です。障害中心（KPIの変更を積極的にモニタリングする）と人間中心（本番環境でテストするために変更をプッシュした開発者にできるだけ早く警告する）の両方のモニタリングです。

私はこれらを最低限必要なものだと信じているので、より良い言葉を求めて、このティアーIモニタリングと呼ぶことにしました。本番環境で必要になる最小限のサービスです。それがアラートが生じた発生元であり、時系列メトリックがこの目的に最も適していると思います。

しかし、アラートには使用しないが、キャプチャーする可能性のある他のいくつかの情報があります。そのような情報はすべてあまり価値がなく、破棄する必要があると考えられています。しかし、私はこれが、ダッシュボードの形で私に提示するのに必要にであろう情報であると信じています。

この種のティアーIIモニタリングの良い例は、GitLabのこのダッシュボードであり、適切に命名された「フリートの概要」または「実行中のGoプロセスに関する情報を提供するGitLab」です。 GitLabはその透明性で有名であり、実際の会社の本物のライブプロダクションダッシュボードであるため、これらの例を選択しました。これらのダッシュボードの分析は、ブログ投稿のためにおもちゃの例を作成するよりも面白いと思います。

これらのメトリックはグレムリンや存在することさえ知らない問題のデバッグには特に役立ちませんが、そのようなダッシュボードがあるとシステムを鳥瞰図で見ることができます。既知の主要なメトリックが変更によってどのように影響を受けたかについて非常に迅速なフィードバックを提供するため、特にリリース後に非常に貴重だと思います。しかし、アラートをトリガーするほど深刻なものではありませんでした。潜在的なメモリリークのヒープ使用量を測定することは、このようなティアー「 IIモニタリングの良い例です。メモリをリークしているコードをプッシュしたかどうかをものすごく知りたいのですが、それを警告するものだとは考えていません。

Exploration

その次には探求というものがあります。これは、先を見越して考えることができなかった質問に答えるのに役立ちます。これには多くの場合、生のイベントやコンテクストが豊富なログデータのクエリが含まれ、事前に予測できなかった答えを明らかにするのに便利です。

Dynamic Exploration

これまでのアプローチすべての問題点は、システムに関する情報を演繹的に記録する必要があることです。つまり、必要なデータは、そこから有用な情報を引き出す前に生成されるということでを意味しています。

ダイナミックなインストルメント技術は新しいものではありません。ただし、DTraceのような実装は主に「マシン中心」であり、ほとんどがアドレス空間または特定のマシンに限定されたままのイベントを相関させます。最近の学術研究では、これらのアイデアと分散トレースによって開拓されたアイデアの一部が組み合わされ、「システムのあるポイントで任意のメトリックを取得し、システムの他の部分で意味のあるイベンによって選択、フィルタリング、グループ化できるようになり、コンポーネントやマシンの境界を越える場合でも可能になりました」ということです。

提案された Pivot Tracing ペーパーの主なブレークスルーは、 baggage abstractionです。

「Baggage （手荷物）は、スレッド、アプリケーション、およびマシンの境界を横断するときにリクエストとともに伝わるタプルのリクエストごとのコンテナです。タプルはリクエストの実行パスをたどるので、発生前の関係を明示的にキャプチャーします。 Baggage （手荷物）を使用して、Pivot Tracingはリクエストの実行中にその場で発生した結合を効率的に評価します。」

Baggage （手荷物）の伝播というアイデアは、OpenTracingスペックに組み込まれました。これにより、「モバイルアプリからの任意のアプリケーションデータを、ストレージシステムの奥深くまで透過的に送信」できます。これはまだホワイトペーパーで説明しているものとまったく同じではありませんが、真のエンドツーエンドトレーシングと、 visibility を高めるためにトレースデータをダイナミックに強化する機能に一歩近づきました。 Facebookの「Canopy」はさらに、Pivot Tracingペーパーによって開発されたアイデアを取り入れ、Scubaで開発した基礎となるイベントモデルと結合し、データの探索をこれまで以上にダイナミックにします。

https://twitter.com/copyconstruct/status/933371370678886400/

Unknowables

そして遂に、未知の世界に踏み入れようとしています。

知ることもできない、または知る必要もないことのお話をします。アプリケーションとハードウェアのパフォーマンスを完全に把握していても、アプリケーションレイヤーの下にあるアブストラクションのさまざまなエイヤーを完全に可視化することは不可能です。 ARPパケットの損失、BGPアナウンスメントまたは再帰的なBGPルックアップ、OSFPの状態、そして私たちが依存するアブストラクションの他のあらゆる実装の詳細について深く突き詰めて考えないでください。すべての物事を完璧に理解する必要は全くありませんし、分からないことがあって当然なのです。

そして最後に…

Choose your own Observability Adventure

可観測性 ―それ自体は、他のほとんどのものと同じで、特に使いやすものではありません。システムの可観測性から導き出される「価値」は、そのシステムから導き出されるビジネス価値に直結します。

絶対ということではありませんが、多くの企業にとって、適切なアラート戦略と時系列ベースの「モニタリング」を行うことは、おそらくビジネス目標を達成するために絶対的に必要なものです。他の人にとっては、山ほどの種類の問題をデバッグできることが、最もビジネス価値を生み出すために必要なものかもしれません。

可観測性は、それ自体が絶対的なものではありません。

サービスの条件に基づいて、ご自身の目で見て、ご自身に合った可観測性ターゲットを選択するようにしてください。

Orangesys.ioでは、kuberneteの運用、DevOps、監視のお手伝いをさせていただいています。ぜひ私たちにおまかせください。