Battle Conference U30のスライドです

1. クラウドサービスの成長と
ログ基盤の進化
Battle Conference U30, 2018-04-21
@ueokande
Cybozu, Inc.

2. Vim Vixen
$ whois
上岡 真也 @ueokande
サイボウズ株式会社2016年新卒入社
業務では、ミドルウェアからインフラ周りまで
プライベートは、WebExtensionsとかいろいろ
2

3. ログ、活用してますか

4. 製品の改善・マーケティング
アクセスログからユーザーの行動を解析して、
製品の導線を改善
このお客さん、お試し中にいろいろ試している。
サポートしてみよう！
4

5. 2017-11-14T04:01:43.489Z INFO [VerifiableProperties] Verifying properties
2017-11-14T04:01:43.489Z INFO [VerifiableProperties] Property client.id is over
2017-11-14T04:01:43.489Z INFO [VerifiableProperties] Property metadata.broker.l
2017-11-14T04:01:43.489Z INFO [VerifiableProperties] Property request.timeout.m
2017-11-14T04:01:43.490Z WARN [ConsumerFetcherManager$LeaderFinderThread] [gray
kafka.common.KafkaException: fetching topic metadata for topics [Set(landsat.dev
at kafka.client.ClientUtils$.fetchTopicMetadata(ClientUtils.scala:73) ~[gray
at kafka.client.ClientUtils$.fetchTopicMetadata(ClientUtils.scala:94) ~[gray
at kafka.consumer.ConsumerFetcherManager$LeaderFinderThread.doWork(ConsumerF
at kafka.utils.ShutdownableThread.run(ShutdownableThread.scala:63) [graylog.
障害対応
急にサービスが重たくなった 😭
メトリクスやログから、エラーや遅延の
時系列変化を見る
cybozu.comは自社データセンターで、
カーネルのバグや機材故障もよくある
5

6. ログ基盤の2つの目的
ログの分析
製品改善や、マーケティング・営業に利用
障害調査
ログの収集
閲覧・解析するために、全てのホストを1箇所に集約
ディスクを圧迫するので、収集されたログをホストから削除

7. サイボウズのインフラの規模感
自社製データセンター
ホスト数（実機 + VM）: 1200程度
リクエスト数 : 2.0億/day
ログ量 : 20億行/day, 800GB/day（毎秒平均 23,000行くらい）
7

8. サイボウズのログ基盤
～ 2016年

9. サイボウズのログ基盤 | ～2016年
収集ノード
転送デーモン
(cron)
Application
Host
SSH
MySQL MySQL
本番環境 社内環境
全ホストからSSHで
ログを転送
アクセスログは定期的に
社内環境に転送
古いログは
テープに永続化
9

10. 分析基盤の課題 | 使えるログが範囲が限定的
ログの利用者は、いろんなログを解析したい！
他のログと組合せて利用できない
MySQLからは古いログが削除
テープには永続化されてるが、取り出すのは、時間と手間がかかる
実質アクセスできるのは直近数カ月分のみ 😣
10

11. 分析基盤の課題 | とにかく遅い！
1台のMySQLを、SRE・開発者・プロダクトマネージャーが共有
1日のレコード数はおよそ2億件
簡単なクエリでも数時間かかる
「アクセスログにクエリを実行した。明日の朝には終わってるだろう。」
11

12. 収集基盤の課題
単一ノードがSSHでログを集める
SSHの転送路が限界ギリギリ 😣
サービスの成長に合わせてスケールできない 😣
転送経路が単一障害点で、停止するとログ転送全体が影響 😣
12

13. 💪 ログ基盤プロジェクト発足 💪
SRE・サービス開発者が便利に使えるよう、横断的に活動
ログフォーマットの仕様の決定
サービス開発者も自由に利用できる仕組みづくり
プロダクトマネージャーも巻き込んで、 開発外の人たちの要件も取り入れ
13

14. 新しいログの基盤の要件
到達保証: ログを取りこぼすことなく、途中の経路でもデータロスしない
長期保存: 最低10年間ログを保存
高スケーラビリティ: サービスの成長に追従して、ログ基盤もスケール
ユーザビリティ向上: grepではなく、横断的に検索・解析
リアルタイム性: ログが出力されて数分以内には、閲覧・解析可能
14

15. サイボウズのログ基盤
2018年

16. サイボウズのログ基盤 | 2018年
Kafka Cluster Hadoop Cluster
Elasticsearch Cluster
Application
転送デーモン
Host
hbase clientBroker
Broker
Broker
Broker
出力されたログは
Kafkaに転送
分散メッセージキュー
アクセスログは
Prestoで解析
Elasticsearchで
検索・解析
Hadoopに永続化
16

17. 2018年の分析基盤
ログをHadoopクラスタに永続化、
古いログを使った解析の対象に
複数ノードと列指向のデータで高速な解析
Web UIを提供して、営業・マーケティング
も利用できる解析基盤
17

18. 2018年の収集基盤
転送路に分散メッセージングシステムを導入
冗長化された経路で、高信頼な転送路 😃
ログ量にあわせたスケールや、ログサービスの追加が容易 😃
現ログ量の数倍は許容できるスループット
18

19. 新しいログの基盤の要件
高スケーラビリティ -> 転送路のノード数を追加してスケールできる
ユーザビリティ向上 -> Web UIを使った分析
リアルタイム性 -> 出力されて2-3分後にはログが利用可能
19

20. まとめ
サービスの成長にあわせて、ログ基盤も新しくする必要があった
ログ基盤プロジェクトが発足
Kafka + Hadoopで、スケーラブル・高信頼・高可用性なシステムを実現
マーケティング・営業の方にも使えるプラットフォーム
20