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

本稿は 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のステータス（クラスタリーダーがダウンしている場合や定足数の損失などを検知するため）、ネットワーク作成などのデーモンイベントなど、その他多くを含む何百もの個別のメトリクスが使用可能となっています。

ロギング

Docker EEは数多くのさまざまなロギングドライバのサポートを内蔵しています。それはログをアグリゲータに出力した後、より簡単な問い合わせを可能とするメタデータと共にタグ付けするサービスなどを含みます。

Docker社におけるDockerのオブザーバビリティ

Docker社では、インフラチームがクラウドでDocker HubとDocker Storeを実行しています。このプラットフォームでは、隔週ごとの集計で10億回以上のイメージのプルを含む、驚くほどの通信数があります。私たちの本番環境全体のうち、いくつかのステータスは次のようになります。

これらはすべてDocker EEプラットフォームで実行でき、本記事でその概要をご紹介した前述のツールおよび技術の多くを活用しているものです。

あなたのコンテナ運用の合理化において、Docker EEがいかにお役に立てるかについて、もっと学ぶ:

• Docker EEについてもっと学ぶ
• 無料でDocker EEを試す
• ヘルスチェック、 Docker Engineメトリクス、ロギングドライバについてもっと学ぶ