Monitoring in the time of Cloud Native — Part 7

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

gavin.zhou

7 min readSep 24, 2019

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

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

今回はリログの生成、処理、保存、分析の問題を軽減するのに役立つとであろうアプローチについてです。

Best practices

前述のログの特性を考えると、ロギングのベストプラクティスに関する話は本質的にトレードオフを体現しています。ログの生成、処理、保存、分析の問題を軽減するのに役立つとであろうアプローチがいくつかあります。

Quotas

関心のあるすべてをログに記録して処理とストレージのペナルティを支払うか、忠実度を犠牲にしているが重要なデータにアクセスできるようにすることを選択してログを記録します。ロギングに関するほとんどの話はログレベルを中心にしていますが、サービスが生成できるログデータの「量」に制限が課されていることはほとんどありません。 Logstashとそれに関係するものにはログの取り込みを調整するプラグインがありますが、これらのフィルターのほとんどは「キー」と特定のしきい値に基づいており、イベントの生成後に調整が行われます。

もしロギングが内部のサービスとして提供されたら、（これが当てはまる企業が多い場合）、割り当てと優先順位を使用してサービスイアーを確立することが最初のステップになります。要求またはサービスに直面しているユーザーには最優先されますが、インフラストラクチャータスクやバックグラウンドジョブ、または制限された遅延を許容できるものは優先度が低くなります。

Dynamic Sampling

割り当ての有無にかかわらず、ログをダイナミックにサンプリングできることが重要になります。そのため、ログ生成の速度をその場で調整して、ログ転送、処理、およびストレージシステムの負担を軽減できます。 EC2でのログ記録をオフにすることで50％の増加が見られたとのことです。

「必要に応じてロギングを動的に増減する能力の必要性を強く感じました。ただし、常に本格的なログ記録を実行しないと、最終的にはシステムが有効になった状態で実行することに対処できなくなるので注意が必要です。」

Logging is a Stream Processing Problem

データはアプリケーションパフォーマンスやデバッグのためだけに使用されるのではありません。すべての分析データのソースも形成します。このデータは多くの場合、ビジネスインテリジェンスの観点から非常に有用であり、通常、企業はより良い製品決定を下すためにこのデータを理解する必要な技術と人員の両方に喜んで経費を使います。

ここで興味深いのは、ビジネスで回答したい質問とデバッグ中に回答したい質問がとても似ているということです例えば、ビジネスにとって重要な質問は次のとおりです。

「ユーザーがこの記事を閲覧した合計100回未満の外れ値の国にフィルターをかけます。」

一方、デバッグの観点からは、質問は次のようになります。

「100件を超えるデータベースクエリを実行した、外れ値ページの読み込みにフィルターをかけます。

または、読み込みに10秒以上かかったインドネシアからのページ読み込みのみを表示します。」

これらは技術的な観点からは類似したクエリではありませんが、これらの種類の分析を実行したり、これらの似た同じ種類のクエリに応答するために必要なインフラストラクチャーはほぼ同じです。

「ユーザーAは製品Xを表示しました」

このデータにいくつかの追加情報を追加すると、観測可能性の目的に適したものになります。

「ユーザーAは製品Xを表示し、ページの読み込みに0.5秒かかった

キャッシュから画像が提供されなかった製品XをユーザーAが表示した

ユーザーAは、製品Xを表示し、API呼び出しの応答時間が300ミリ秒であったレビューZを読んだ」

これらの両方のクエリは、イベントによって可能になります。イベントは、基本的に構造化された（オプションで入力された）キーと値のペアです。ビジネス情報とリクエストの「ライフタイム」に関する情報（タイマー、期間など）を組み合わせることにより、分析ツールを観測可能性の目的に再利用することができます。

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

これについて考えると、ログ処理はOnline Analytics Processing（OLAP）の請求書にきちんと収まります。 OLAPシステムから得られる情報は、デバッグやパフォーマンス分析、またはシステムのエッジでの異常検出のために得られる情報と比べてそれほど異なる点はありません。ほとんどの分析パイプラインは、イベントバスとしてKafkaを使用します。豊富なイベントデータをKafkaに送信すると、Confluentの優れた皆さんのKSQL（Kafka用ストリーミングSQLエンジン）を使用して、ストリームをリアルタイムで検索できます。

「KSQL は、集約、結合、ウィンドウ化、セッション化など、さまざまな強力なストリーム処理操作をサポートしています。 Kafkaログは、ストリーミングデータのコアストレージアブストラクションであり、オフラインデータウェアハウスに入った同じデータをストリーム処理に使用できるようにします。それ以外のすべては、さまざまなデータベース、検索インデックス、または社内の他のデータ提供システムなど、ログのストリーミングマテリアライズドビューです。これらの派生ビューの作成に必要なすべてのデータ強化とETLは、KSQLを使用してストリーミング形式で実行できるようになりました。モニタリング、セキュリティ、異常および脅威の検出、分析、および障害への対応は、手遅れではなくリアルタイムで実行できます。Kafkaのすべてのデータであるシンプルで使い慣れたSQLインターフェイスであるKSQLを使用して、ほぼ誰でも使用できます。」

既存のストリーム処理インフラストラクチャーを再利用するときは、とにかく追加のタイミングや、可観測性の使用事例に必要なその他のメタデータを使用して、Kafkaに入るビジネスイベントを充実させるとよいでしょう。このパターンを利用すれば、このデータがKafkaログから定期的に期限切れになるという利点も出てきます。デバッグに必要なほとんどのイベントデータは、通常ETLジョブによって評価および保持されるビジネス中心の情報とは異なり、イベントが生成された後の比較的短い期間にのみ価値があります。もちろん、Kafkaがすでに組織の不可欠な部分であるときに最も意味があります。リアルタイムのログ分析のためだけにスタックにKafkaを導入するのは、特にJVMの運用に関する専門知識のない非JVMショップでは、ちょっとやり過ぎです。

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