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

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

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

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

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

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

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

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

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

10.
ログの読みやすさ
▌ログ駆け出しのころのログ
▌ログっぽいログ
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."
読みやすいのはこっち？

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

12.
構造ログは読みづらい？
▌生のまま読むと非常につらい
▌加工すれば大丈夫（機械処理万歳！）
{"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-"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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