1. サイボウズのサービスを
支えるログ基盤
ゼロからの刷新とこれから
Cybozu Meetup #6, 2017-07-25
@ueokande
Cybozu Inc.

2. $ whois
上岡 真也
2016年サイボウズ入社
アプリケーション基盤チーム
GitHub/Twitter: @ueokande

3. 目次
cybozu.comのこれまでのログ基盤
ログ基盤のゼロからの刷新
新しいログ基盤のこれから

4. cybozu.comの
これまでのログ基盤

5. cybozu.com

6. cybozu.comとは
2011年にスタートした、企業向けクラウドサービス
契約社数 20,000社以上
ユーザ数70万人以上
リクエスト数1.7億/day

7. cybozu.comを支えるインフラ
自社製データセンター
ホスト数（実機 + VM）: 1200程度
ログ量 20億 行/day, 800 GB/day
（毎秒平均 23,000行 くらい）

8. なぜログが重要か
ログはWebサービスの健康状態を示す
障害対応の手がかり
サービスの改善に役立てる
性能検証
ユーザの行動をビジネスに利用する

9. これまでのcybozu.comのログ基盤
1. ログを毎分ローテート
2. ローテートされたログをtarに固める
3. SSHでtarをストレージサーバーに転送
4. 転送が完了したログをホストから削除

10. そろそろ限界...
ログの増加にシステムが追いつかない
スケールしたいけどできない
転送システムがSPOF
転送ホストが止まると、全体のログ転送が停止する
ログを活用できていない
可視化・解析できていない、開発者以外が利用できていない

11. ちくちょう。
刷新だ！
Trying to crawl here by Donnie Ray Jones | https://www.flickr.com/photos/donnieray/32890584381/

12. ログ基盤のゼロからの刷新

13. 新ログ基盤の要件
① at least once
ログを取りこぼすことなく集める
② 信頼性
どこかで障害が発生しても、全体の転送が止まらない
③ ログを活用できる
ログを活用できるサービスを容易に導入できる

14. 新ログ基盤アーキテクチャ
出力されたログは
Kafkaに転送
必要なサービスが
Kafkaからログを取り出す

15. Apache Kafkaとは
pub/sub型の分散メッセージングシステム
LinkedInが開発してOSS化した
Twitter、Netflix、LINEなどの採用実績

16. Apache Kafkaを使う理由
分散メッセージングサービス
データはレプリケーションされるので、急にノードが死んでも大丈夫
ノードを追加することで容易にスケールできる
pull型consumerのpub/subシステム
データを購読する側が任意のタイミングでデータを読みだす
入力側・出力側が粗結合になり、それぞれ独自のタイミングで読み書きできる

17. 各ホストからKafkaへの転送
ログファイルの更新を監視してKafkaに送る
ローテートされて転送が完了したログはディ
スクから削除

18. Kafka clusterから各サービス
HBase
ログをHadoop上に長期保存する
Hive + Presto
ユーザの動向をクエリで検索・解析する
Graylog
ログの検索、監視

19. At least once
システム全体で、ログを取りこぼすことなく配送
どこかのホストが突然の死を遂げても、ログのデータロスが発生しない
ログの重複は許す（≠ exactly once）

20. At least once | Kafkaへのログ転送
初めはFluentdでKafkaへ転送してたが、
at least onceを満たすことが難しいと判明
転送エージェントをGoで実装
状態はatomicに更新
ローテート後もしばらく監視

21. At least once | Kafkaからの転送
HiveやHBaseへの経路は冗長構成
HDFS上のファイル操作もatomicに更新する必
要がある

22. 信頼性とログの活用
信頼性
Kafka/Hadoopのノードが死んでも全体の転送は止まらない
ラックの電源が落ちても大丈夫なように、同クラスタのノードはラックを分離
ログの活用
用途に応じて、様々なサービスを追加できた
新たなサービスを追加するのに、他の箇所に影響しない

23. 新ログ基盤の要件
at least once
→ 電源断してもデータロスが起こらないように設計
信頼性
→ 冗長性をもたせたクラスタ構成とラック設計
ログを活用できる
→ Kafkを使うことで容易にサービスを追加できる

24. 苦労話 | 長いログの対応
Kafkaのレコード長には上限がある
MySQLのスローログでは1行が10MBを超えるケースもある
Kafkaのレコードに、断片化されたログかのフラグを付与
Kafkaからログを取り出す時、再び結合するのが少し大変

25. 苦労話 | 転送遅延
ある日、Kafkaからの転送が大きく遅延した
本番環境と同じ環境を開発環境に構成してたた
め、早期に気付けた
Kafkaのパラメータチューニングして解決

26. 苦労話 | journaldに悩まされる
アプリケーションのログをjournaldに集める計画もあった
社内でjournaldを導入してみたらいろいろ問題が
長いログの行が勝手に分割される
Disk Full時にjournaldが死亡する
結局ファイル最強だった

27. 新しいログ基盤のこれから

28. これからやっていきたいこと
より良い製品づくりに役立てる
ユーザデータを可視化・解析して製品改善に役立てる
必要なログやデータを組合せて、障害調査を加速させる
開発者以外も広く利用できる環境
エンジニア以外もログを利用できる環境の用意
ユーザへのサポートやマーケティングを効率化させる

29. まとめ
サイボウズのログ基盤が新しくなりました
Kafka導入で「at least once」「信頼性」「ログを活用できる仕組み」を実現
これからもログをどんどん活かして、より良い製品づくりに役立てます