コンテナを丸裸にする方法（モニタリング、ロギング、デバッグ）と関連ツールの紹介 #reinvent #CON320

今回のre:Invent2017でも、コンテナ関連について、かなり重要な新サービスやアップデートが多数発表されましたね。

• 【速報】AWSのマネージドKubernetesサービス、Elastic Container Service for Kubernetes(EKS)が発表されました！ #reinvent ｜ Developers.IO

• 【速報】新サービスAWS Fargateが発表されました！！ #reinvent ｜ Developers.IO

そんななか、改めてコンテナの中身のログを取得してデバッグするための手法について解説したセッションに参加したので、その内容をご報告いたします。

CON320 - Monitoring, Logging, and Debugging for Containerized Services

セッション概要はこちら。

As containers become more embedded in the platform tools, debug tools, traces and logs become increasingly important. Nare Hayrapetyan, Senior Software Engineer and Calvin French-Owen, Senior Technical Officer for Segment will discuss the principals of monitoring and debugging containers and the tools Segment has implemented and built for logging, alerting, metric collection, and debugging of containerized services running on Amazon ECS.

意識しておかないと、とかくブラックボックスになりがちなコンテナや、そのバックにあるインスタンス状態のモニタリング、ロギング、デバッグ手法について、その基本的な考え方と、SEGMENT社のオープンソースツールの利用方法の紹介が多数あり、初めて聞くツールも多数あったので、非常に勉強になりました。

　__
（祭） ∧ ∧
　Y　 ( ﾟДﾟ)
　Φ[_ｿ__ｙ_l〉     Containerﾀﾞ ﾜｯｼｮｲ
　　　 |_|＿|
　　　 し'´Ｊ

ほな、いってみよ。

イントロダクション

コンテナにはモニタリング、デバッグ、そしてロギングが重要

マイクロサービスは、とかくモニタリングとデバッグが難しく、また、以下のような多数のコンポーネントから成り立っている。

• ロードバランサー
• インスタンス
• クラスター
• タスク

また、コンテナ事態も一時的な存在であり、全てのパーツについて透明性が求められる。

マイクロサービスは、常に以下の点について、答えることが必要となる。

• 顧客はサービスに対しアクセスが可能なのか？
• もし駄目なら、いったい何が駄目なのか？
• エラーの兆候はあるか？その発生頻度は？

取得すべきキーメトリクス

そんな状態を把握するために、以下のメトリクスを常に把握しておく必要がある。

• インフラ部分
  • CPU
  • メモリー
  • ロードバランサー
  • ディスク使用量
• アプリケーション
  • エラー発生率
  • アクセスボリューム
  • 応答速度

Amazon CloudWatchを利用したモニタリング

Amazon CloudWatchを利用すると、ECSのメトリクスを全て、Amazon CloudWatchに転送することが可能。エージェントバージョンを1.4.0以上のものを使い、CPUやメモリの空き容量、利用量を送信できる。

こちら、がAmazon CloudWatchを利用したモニタリングのサンプルだ。

ECSは、1分置きにメトリクスを転送する。高解像度モードをOnにすると、5秒間隔での取得が可能となる。ディスク使用量はカスタムメトリクスを利用していただく。

カスタムメトリクスによるモニタリングの例だ。

Datadogによる、モニタリングの例だ。イカスね。

Sysdigによる、モニタリングの例だ。これもやるね。

ロギングの話

ロギングする場合、まず最初にログをロギングフレームワークに送信する必要がある。幸いなことに、ECSは複数のログドライバーに対応しており、それは、タスク定義の中で設定することが可能だ。

現在、対応しているログドライバーは以下の通り。

• awslogs
• fluentd
• gelf
• joumald
• json-file
• splunk
• syslog

awslogsを利用すれば、このようにログをCloudWatch Logsで参照可能、

Amazon CloudWatchによるアラームの話

どうやって、エラーを検知するのか。

CloudWatchにおいては、Logs Metric Filterを利用してのアラート設定が可能。下記のようなフィルターパターンを設定することができる。

{$.errorCode = "AccessDenied"}

タスクが失敗した時のデバッグ手法

新しいデプロイ時、サービスがタスクの起動に失敗したばあい、タスクは、PENDING状態になり、消え去る。

このようにタスクのステータスが表示されている。

インスタンス自身のログ

インスタンス内、ecsエージェントやDockerデーモンのログもCloudWatchで集約する。この場合、ClooudWatch Logsエージェントをセットアップしておく。

ログの分析

集約したログは、10億行を超える場合もある。其の中から、パターンや兆候を抜き出し、検索し分析するためのツールが必要となる。

ログ分析のアーキテクチャ例。CloudWatch Logsに集約した後、いろんな利用法が考えられる。

• ログの蓄積　→　Amazon S3
• ログのストリーム取得　→　Amazon Kinesis
• ログからのアプリケーション起動　→　AWS Lambda
• ログの検索　→　Amazon Elasticsearch Service

このように、AWS Lambda、Amazon Elasticsearch Serviceなどへのストリーミング処理も可能となっている。

セッションまとめ

• ログを分析するのは非常に重要な観点である
• あらゆる階層でログをモニタリングせよ
• ログに対してアラームを設定し異常にそなえよ
• ツールを利用して、あらゆる異常を検知し可視化せよ

SEGMENT社ツールの紹介

ここで、SEGMENT社を紹介する。

Analytics API and Customer Data Platform · Segment

• 一月あたり1400億のイベントを検知
• ピークでは1秒あたり1億6000万
• 1万6000のコンテナ
• 350にわたるECSを稼働

非常に大きなスケールで使われているツールだ。みんなも、是非この機会に試してみて欲しい。

デバッグ状況を構築するには、以下の3ステップを踏む

1. メンタルモデルの構築
2. 詳細な調査
3. クラウドへの実装

1.メンタルモデルの構築

メンタルモデルの構築とは、以下のことを明らかにしていくことだ。

• どのようにすれば、それがシステムにフィットするのか？
• このサービスはどのように設定されているのか？
• 観察すること以外のことがあるのか？

まずは、仕様を把握する

こちらのツールを見てくれたまえ。

segmentio/specs: Peer into your ECS clusters

$ docker run segment/specs

Specsを利用することで、以下を明らかにすることができる。

• どれだけのサービスがクラスター内で動作しているか
• サービスの稼働状況の把握
• Dockerイメージへのタグ付け
• 一番多く稼働しているイベント

terraformを利用し、設定方法の確認に進む。

これは、terraform ECS サービスの例だ。

このように可視化が可能。Amazon CloudWatchと、Datadogを利用。

2.詳細な調査

ステータスの把握には、CloudWatchを利用する。

ログ収集のアーキテクチャは、こういう想定だ。Dockerで収集したjournaldをecs-logsに転送し、そこから各種ログ分析ツールに流し込む。

しかし、この構造では、journaldに対しての書き込みが単一障害点となりボトルネックとなりうる。

其の場合、このようにrate-limiting-log-proxyを利用することで、jounaldへの書き込みを負荷分散させることができる。

サイトはこちらだ。是非、このツールも活用して欲しい。

segmentio/rate-limiting-log-proxy: A syslog-compatible log proxy that limits based on syslog tag

その他、ECSのログ周辺で利用できるツールはこれだ。是非、この機会にこれらのツールの活用も検討してほしい

• segmentio/ecs-logs: Log forwarder for services ran by ecs-agent.

• segmentio/ecs-logs-go: Set of Go packages to integrate the ecs-logs format with other logging packages.

• segmentio/ecs-logs-js: Logger formatting messages compatible with ecs-logs

• segmentio/rate-limiting-log-proxy: A syslog-compatible log proxy that limits based on syslog tag

• segmentio/cwlogs: CLI tool for reading logs from Cloudwatch Logs

追跡においては、BCCが有用だ。

BCCとは、BPFコンパイラーコレクションで、追加のカーネルモジュールや実装は必要としない。優秀なツールだ。

iovisor/bcc: BCC - Tools for BPF-based Linux IO analysis, networking, monitoring, and more

利用例はこのような感じだ。

Pprof-serverを紹介する。

segmentio/pprof-server: Web server exposing performance profiles of Go services.

go性のツールで、Webサーバーのヒートマップやメモリーダンプ、プロファイルなどをビジュアライズ化して提供してくれる。

どうだい、便利そうだろう？負荷状況をビジュアライズ化して追うことができるのは、非常に便利だ。

利用方法例を紹介する。runコマンド時に、consulとして利用することが可能だ。

濱田まとめ「コンテナのロギングに有用なツールが多数紹介されたセッション」

主に、ECSにおけるロギングの一般的な戦略と、それに関連して、SEGMENT社のオープンソースツールを活用した、具体的なロギング戦略が話されているセッションでした。オープンソースで気軽に試せるツールが多数紹介されていたので、これらのなかから、コンテナのロギングに一つでも利用できそうなツールが見つかれば良いですね。

それでは、今日はこのへんで。濱田でした。