2018.08.20

[和訳] コンテナオーケストレーション環境向けの積極的な運用方法: Docker EEによるモニタリングとロギング戦略 #docker

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

本稿は Proactive Ops for Container Orchestration Environments: Monitoring and Logging Strategies with Docker Enterprise (2018/08/14) の和訳です。

ここ10年ほどのマイクロサービスおよび高いスケーラビリティを持ったシステムの人気の高まりは、アプリケーション全体に複雑さをもたらしました。こういったアプリケーションは今や、多くの可動部と潜在的故障モードを含みつつも重度にネットワークで分散しています。

このアーキテクチャの進化はモニタリング要件に変化をもたらし、ビジネスや内外部のエンドユーザに支障が出る前に、システムの問題をよりうまく特定・デバッグ・解決するための、拡張性と洞察性に富んだツールと実践的手段の必要性を生みました。

私は先日行われたDockerConサンフランシスコ2018において、Docker EEの機能について講演しました。Docker EEは、ダウンタイムを引き起こす前に問題をトリアージし修正するためのキーメトリクスおよびベストプラクティスとともに、コンテナプラットフォーム環境を、運用者がより簡単にモニタリングできる機能などを備えています。

講演はこちらでご覧いただけます:

モニタリング方法論

もっともよく知られている初期のモニタリング技術は、Netflix社のBrendan Gregg氏によるUSEメソッドです。USE (Utilization, Saturation and Errors)メソッドは、モニタリングすべきリソースを特定するものです。特定するリソースには、利用状況（Utilization; サービスを提供するために費やした時間）、飽和状態（Saturation; 費やしたがサービスを提供できなかったリソースの程度）、エラー（Errors; エラーとなったイベントの数）があります。この方法はハードウェアやノード中心のメトリクスには適していましたが、ネットワークベースのアプリケーション向けには異なる方法が必要でした。

よりネットワーク重視のクラウドネイティブなアプリ向けにもっとも一般的なモデルは、「4 Golden Signals（4大シグナル）」です。つまりGoogle SRE ハンドブックで述べられている、レイテンシ（Latency; 待ち時間）、トラフィック（Traffic; 通信）、エラー（Error）、サチュレーション（Saturation; 飽和状態）の4つのシグナルです。これらのモニタリングメソッドは、アプリケーションおよびプラットフォームレベルにおいて有用ですが、複雑なケースや失敗となるパターンをトリアージするための詳細情報には不足しています。

アプリケーションとプラットフォームのオブザーバビリティ（可観測性）

オブザーバビリティは、単純なメトリクスの一歩先の段階をいくものです。システムの出力をレビューすることで、システムの状態をいかに的確に推察できるかの指標となります。オブザーバビリティは、システムの状態の全体像を描くためのモニタリング、（イベントの）ロギング、トレース、アラートを含みます。アプリケーションを「観測可能な状態」にするためには、アプリケーションに計器を取り付けることが重要になります。これにより重要な情報を取り出し、分析することが可能となります。ここ数年、この領域のツールはルネサンス期を迎えています。DataDogをはじめ、InstanaやPrometheus、そしてSumo Logicなど多数のツールがこの領域における先進的な機能に増えつつあるニーズを満たしています。

Docker EEにおけるオブサーバビリティ

Docker EEコンテナプラットフォームは多くの内蔵機能により、より簡単なモニタリングとメトリクスの基準の設定が可能です。なかでも真に役立つ機能は、ヘルスチェックと、Docker Engineのメトリクスおよびログです:

ヘルスチェック

ヘルスチェックはDockerfileの仕様に組み込まれている機能で、ユーザが自身のアプリケーションに対してモニタリングのチェック項目を記述できるものです。この情報はDocker Engineを通じて報告され、Docker EEのWeb管理者UIを通して閲覧することができます。Docker EEは、ヘルスチェックをパスできないワークロードを自動で再スケジューリングします。

Docker Engineのメトリクス

Docker Engine、すなわちDocker EEは、Prometheusフォーマットのメトリクスデータを発行するエンドポイントを公開しており、モニタリングツールに容易に統合できます。ビルドに関するデータをはじめ、Swarmのステータス（クラスタリーダーがダウンしている場合や定足数の損失などを検知するため）、ネットワーク作成などのデーモンイベントなど、その他多くを含む何百もの個別のメトリクスが使用可能となっています。