Monitoring in the time of Cloud Native — Part 2

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

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

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

今回はモニタリングと可観測性についてです。

Monitoring

「モニタリング」と検索すると、以下の2つの結果が表示されます。

―一定期間、あることの進捗状況を観察したり確認したりすること、体系的なレビューをし続けること

―定期的にモニタリングをし続けること

私にとって「モニタリング」とは、本質的に不具合と同じくヒューマンセントリック（人間主体の）なものという意味を含むものです。それでは、これについてもっとお話ししましょう。なぜかというと、このテーマがこの記事の基盤になっているからです。

過去には、自分たちのアプリケーションを最初にテストしてきました。QAサイクルがこれをフォローしています。それから、自分たちのコードをリリースし、それを「モニタリング」することでフォローしてきました。ものすごく偶然にフォローされていました。

公平な目で見ると、みんながこのようにソフトウェアのライフサイクルを管理しているとは思いません。でも、それはしばしば「古い方法」と考えられているものに対して良い模倣になります。

私たちはある事象が正しく動いているかを期待して、その事象を「モニタリング」します。さらに悪いことには、非常に具体的な方法で何かに障害が出ることを予想し、この特定の障害をモニタリングしたいと考えました。「明確で予測可能な障害」中心のモニタリングアプローチは、障害モードの数が増加し、要害になる可能性も増えるという問題になってきます。障害が当たり前の時代に生きているとよく耳にします。 「 SRE book 」には次のように記載されています。

「ただし、特定のポイントを過ぎると、サービスの（そして、そのユーザーの）信頼性の向上率が悪化することが判明しています。真楽精を極めて高く上げるためにはコストがかかります。新しい機能を早く開発するために安定限界を最大にしたり、ユーザーに早く商品を配布できるようにすると、コストがものすごくかかるようになり、搭載できる機能の数が減ることになります 」

障害を受け入れるモデルにオプトインするには、障害が発生した場合に適切に動作するようにサービスを設計する必要があります。言い換えると、これはハード、明示的な障害モードを部分的で、暗黙的、ソフトの障害モードに変えるということです。リトライ、タイムアウト、障害のモード、回路の遮断やレート制限のような正常な劣化メカニズムが処理する障害モード。結果として起こる一貫性、もしくは多層のティア―になったキャッシュのようなメカニズムを伴う緩和された一貫性の保証のために容認された障害モード。サービスを完全に停止する可能性のある負荷が増加した場合に、負荷制限によって意図的にトリガーすることもできる障害モード。これにより、劣化状態で動作します。

しかし、これらは全て、全体的な複雑さが増すという代償を伴います。そしてバイヤーは深く後悔し、システムを簡単に推論することができなくなります。

そうなることで、「モニタリング」においての第二の特徴、つまり人間中心のものでるという特徴が見えてきます。何かを「モニタリング」することにした理由は、何かが正常に動作しないはずだということを知っていたからです。そして、誤作動が起きた場合、重大な結果を招くことになります。本当にあまりよくない結果を招きます。それはできるだけ早く改善されるべきです。人道的な介入が必要となる改善が必要です。

全てのものを自動化することが万全の策だと私は思っていません。しかし、Kubernetesのようなプラットフォームの出現で、これまでの人的および障害中心のモニタリングツールが「モニタリング」に役立った問題はすでに解決されました。ヘルスチェック。ロードバランス、ローテーションの中から不備のあるサービスを取り除くこと、無料で提供されているプラットフォームの特徴です。それらが重要な４大要素です。

従来のモニタリングが自動化されてしまっているため責任がなくなり、「モニタリング」は人間中心ではなくなるか、近いうちに人間中心でなくなるでしょう。これらのプラットフォームはいずれも、サービスを実際に障害に耐えるようにはできませんが、正しく使用すると、ハード障害の数を減らせることができ、エンジニアとして、システムが示す可能性のある微妙で曖昧で予測不可能な動作に対処することができます。 壊滅的ではないが以前よりもはるかに多くの種類の障害です。

それでは質問です。どのようにそのようなシステムに対してモニタリング設計をすればよいのでしょうか。

それは、システムに対するモニタリングの設計というよりも、そのシステム自体の設計をどうするかという問題です。

「モニタリング」は、この新しい世界においてでさえも、人間中心と同時にハードの障害であるべきです。「モニタリング」の目的は変わっていません。その領域が大幅に縮小したとしても、今私たちが直面している課題は、依然として人間中心の「モニタリング」の部分を特定し、最小化することです。 現在、障害ドメイン全体のごく一部のみが、ハードで緊急に人間が実行可能な種類のものになるようにシステムを設計する必要があります。

しかし、パラドックスが存在します。「ハードの、予測可能な」障害モードの数を最小限にすることは、どのみちそのシステムそのものを全体的にシンプルになることではありません。言い換えれば、インフラストラクチャーの管理がより自動化され、人間がそれほど介入しなくてもよくなりにつれ、アプリケーションのライフサイクル管理はより難しくなるのです。暗黙的な障害モードと全体的な複雑さが劇的に増える代わりに、ハード障害モードの数が縮小するため、すべての障害を明示的に「モニタリング」することは不可能になりますし、言うまでもなく、それは全く必要のないことです。

Observability

私の意見では、可観測性はプロダクトの中でどのようにシステムが動いているかを理解できるようになることだと考えています。もし「モニタリング」が全体的なヘルスシステムの報告に最適なのであれば、「可観測性」は、その反対にリッチなコンテキストとともにシステムの動作に関する非常に緻密なインサイトを提供することを目的としており、暗黙的な障害モードの可視性とデバッグに必要な情報のオンザフライの生成に最適です。 障害のモニタリングがモニタリングされているため、これらの障害を事前に予測できる必要があります。モニタリングとは障害に目を光らせて見ておくことです。それらの障害を積極的に予測できるようにしてくれます。observableなシステムは、それ自身の十分なデータをエクスポーズしてくれるもので、情報を生成し（まだ決まっていない質問に対して答えを見つける）、簡単にその情報にアクセスできるようになります。

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