1TB/dayのログを収集・蓄積する技術

1TB/dayのログを 収集・蓄積する技術 サイボウズ株式会社 クラウド運用チーム 内田公太 2018/03/31 CAMPHOR-

自己紹介 ▌内田公太 @uchan_nos ▌クラウド運用チーム SRE ▌2014年入社／5年目になろうとしている ▌インフラ系のソフトウェア作成  サービスの死活監視システム  ブロックデバイスのリアルタイムバックアップ  ログ収集・解析システム

著書とか http://amzn.asia/4Kvi8gj 執筆 http://amzn.asia/iSc89ok 校正

• http://amzn.asia/iSc89ok
• http://amzn.asia/4Kvi8gj

ログとは ▌航海日誌＝ログ・ブック ▌原義は「丸太」 日本船舶海洋工学会 海洋教育推進委員会 https://www.jasnaoe.or.jp/mecc/fushigi/report/report011.html

• https://www.jasnaoe.or.jp/mecc/fushigi/report/report011.html

IT業界での「ログ」 ▌みなさん、ログ出力してますか？？ ▌アプリケーションのログ ▌アクセスログ ▌DBやファイルシステムのWrite Ahead Log ▌数値メトリクス ▌（ブログ）

この発表の目的 ▌ログ出力の勘所を知る ▌スケーラブルなログ収集基盤アーキテクチャを学ぶ ▌→ログのエキスパートになる！

ログしぐさ ▌ログのフォーマット ▌ログに含めるべき情報 ▌ログを出すタイミング

平文 vs 構造ログ ▌平文：「ロギング」で最も典型的な形式 ▌人間が読みやすい ▌機械処理しにくい 2018-03-31T07:05:26.939624Z localhost a.out debug: " welcome to the CAMPHOR-"

平文 vs 構造ログ
▌構造ログ：プログラマなら夢見る形式
▌機械処理しやすい
{
"topic":"a.out",
"logged_at":"2018-03-31T07:05:26.939624Z",
"severity":"debug",
"utsname":"localhost",
"message":"welcome to the CAMPHOR-"
}

ログの読みやすさ ▌ログ駆け出しのころのログ 読みやすいのはこっち？ Application started. Accepted connection from user aaa. ▌ログっぽいログ 2018-03-23T09:10:26.939624Z localhost my-process info: "Application started." 2018-03-23T09:12:56.036020Z localhost my-process info: "Accepted connection from user aaa."

ログの読みやすさと使いやすさ ▌ログをリアルタイムで読むとき  時刻などない方がすっきり ▌ログを後で調べるとき  時刻やログレベルが無いと辛い ▌自動化を進めるにつれ、後から調査する需要が増える →後者（ログっぽいログ）が圧倒的に使いやすい

構造ログは読みづらい？
▌生のまま読むと非常につらい
{"topic":"a.out","logged_at":"2018-03-31T07:05:26.939624Z","se
verity":"debug","utsname":"localhost","message":"welcome to th
e CAMPHOR-"}

▌加工すれば大丈夫（機械処理万歳！）
2018-03-31T07:05:26.939624Z localhost a.out debug: "welcome to
the CAMPHOR-"

ログに含める情報 ▌後で調査に使うことがある →可能な限り、情報を含めると良い →ログ量が増えすぎると辛いので、バランス大事 ▌ローカル変数の中で、大事なものは値を出しておく

ログを出すべきとき ▌重要なチェックポイント  プロセスの起動と終了  バージョン情報とか、割と役に立つ  ユーザからのリクエストの開始点  ログファイルの切り替え時

ログを出すべきとき ▌時間がかかる処理の前後  ログが更新されないときに場所が分かるように creating index files ... 長時間の処理 index files created.  数分以上時間がかかるなら、時々ログを出すと親切 creating index files ... 1 minutes elapsed. 2 minutes elapsed.

ログを出すべき関数の階層 ▌関数呼び出し階層のどこでログを出すか ▌最下層 handle_user_access →handle_bbs_post →save_file  具体的な処理の値などが最もよく取れる場所  処理のコンテキストは分からないことが多い （ユーザのアクセス起因？定期バッチの関連？） ▌上層  処理のコンテキストは良く分かる  具体的な処理の値などは不明

ログを出すべき関数の階層 ▌handle_user_access  ユーザからのアクセスであること、ユーザ名、APIの種類 ▌save_file  具体的なファイルパス、ファイル内容 handle_user_access →handle_bbs_post →save_file

ログを出すべき関数の階層 ▌理想：コンテキスト情報と、具体的な値が両方欲しい マルチスレッドで困る ▌ナイーブな解決策：2行出す Access from user USER_NAME. Saved to file FILE_PATH, FILE_CONTENT. ▌nginxの解決策：コンテキストを下層に渡す

コンテキストを下層に渡す handle_user_access ▌handle_user_access の中で ctx->log_action = "handling user request"; handle_bbs_post(ctx, …); ▌handle_bbs_post の中で save_file(ctx, …); ctx log_action handle_bbs_post save_file log(ctx, …) ▌save_file の中で log(ctx->log_action, "saved to file …");

ログレベル ▌severityとも ▌チーム全体で定義を合わせると良い ▌↓サイボウズでの定義 名前 Critical Error Warning 値 2 3 4 Info Debug 6 7 意味 errorに該当する問題のうち、特に致命的な問題。 リクエスト処理またはプロセス全体が続行不可能になる問題が発生。 今のところ正常に続行できるが、将来的に問題につながり得る事象が 発生した。将来何か問題があったとき、真っ先に見返してほしいログ。 正常な動作の軌跡。サーバが起動したとかリクエストが来たとか。 関数の出入りの記録や文字列解析の途中結果など、デバッグ用の情報。

cybozu.com を支えるログ基盤 ▌ブログ記事 サイボウズのログ基盤 2018年版 ― Cybozu Inside Out ▌規模感

#customer companies： #accesses / day： Logs / day： 20,000+ 210 millions 800 GB

ログ収集 ▌なぜログを収集するのか  ログが消えないようにしたい →1か所に集めておけば、バックアップしやすい （圧縮してテープに書き出すとか）  ログが分散していると検索しずらい →1か所に集めておけば、grepできる

ログ収集クイズ：皆さんなら、どうやって集める？ Host Host • • • • • 約1000個のホスト 800GB/日 のログ量 ログ発生から数分で回収したい 全ログはgrepで検索したい アクセスログはSQLで検索したい

2016年以前のログ収集 Host Host 収集サーバ Gzip MySQL アクセスログ ssh x 1000+ ▌sshで全ホストからログファイルをコピーしてくる ▌Gzipファイルとして保存する ▌アクセスログはMySQLにINSERTする

2016年以前のログ収集 ボトルネック Host Host 収集サーバ Gzip ssh x 1000+ MySQL アクセスログ SPoF ▌sshで全ホストからログファイルをコピーしてくる ▌Gzipファイルとして保存する ▌アクセスログはMySQLにINSERTする SPoF

2016年以前のログ収集エピソード ▌収集サーバが故障してログ収集が数日止まった →追いつくのに11日かかった ▌MySQLで24時間分のログ集計が13時間かかる ▌開発環境ではVMが多すぎて追い付かない →ほとんどのVMからのログ吸い出しを停止 →VMが次々とDisk Fullに

現在のログ基盤アーキテクチャ

Kafka Cluster (メッセージキュー) Kafka Broker VMとか実機とか Kafka Broker 何らかの プロセス Log files Log Logfiles files logshipper (ログ転送 エージェント) send Kafka Broker Kafka Broker Kafka Broker （ 次 の ペ ー ジ へ 続 く ）

Hadoop Cluster Kafka Cluster (分散基盤) (メッセージキュー) Kafka Broker HDFS poll logarchiver write (ログ保存デーモン) (分散 File System) HBase (分散KVS) read write Kafka Broker poll Kafka Broker Kafka Broker Kafka Broker tailermaid (アクセスログ TSV化デーモン) logkeeper (TSV -> ORC コンバータ) Redash (SQL用UI) Log Log Log Raw write batch query read TSV Hive (SQLエンジン) query Presto (SQLエンジン) write ORC read ORC Log Log Log TSV Log Log Log ORC 30

要件 1/2 ▌ログを保存・閲覧できる  障害発生時の調査（ここ数日のログ）  リソース調整（N 年前からの負荷の変化） ▌ログを集計できる  全ログを日付、ホスト名、トピック名で絞り込める  アクセスログをブラウザからSQLで集計できる  構造ログに対しクエリで絞り込める

要件 2/2 ▌ログ欠損しない（なるべく）  at least onceポリシー ▌大量のログを扱える  現在：800GB/day（非圧縮）  将来：10倍の量には耐えたい ▌ログ収集の経路を冗長化したい ▌ログ収集の遅延を数分以下にしたい

スループット ある時、Kafkaクラスタへの書き込みができなくなった →すぐに回復したので、Kafkaのスループットは申し分ない

新ログ収集基盤の故障 ▌ほとんどのコンポーネントが冗長化されている ▌HDFS：3レプリカ→2台同時死亡までは耐える ▌Kafka：3ブローカ→2台同時死亡までは耐える ▌ZooKeeper：5台クラスタ→2台同時死亡までは耐える

分散システムは難しい 3/12の障害エピソード 1. 「VMのディスクの空き容量が少なくなっている」 というアラートが飛んできて緊急対応開始 2. logshipperが止まっており、ログが回収されてない！ 3. Kafkaの調子が悪く、新規ログ書き込みが出来ないっぽい 4. チームで協力し奮闘、何とかKafkaを復活させる  Kafkaの障害復旧、普段から鍛えてないと厳しい世界  分散システムはバグが絶えない 約5時間の奮闘 →公式文書通りにならないことも良くある

発表まとめ ▌ログしぐさ  平文 vs 構造ログ  ログを出すべきとき  ログを出す関数階層 ▌サイボウズのログ基盤  古いログ基盤  新しいログ基盤