Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

クラウドサービスの成長とログ基盤の進化

1,020 views

Published on

Battle Conference U30のスライドです

Published in: Technology
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

クラウドサービスの成長とログ基盤の進化

  1. 1. クラウドサービスの成長と ログ基盤の進化 Battle Conference U30, 2018-04-21 @ueokande Cybozu, Inc.
  2. 2. Vim Vixen $ whois 上岡 真也 @ueokande サイボウズ株式会社2016年新卒入社 業務では、ミドルウェアからインフラ周りまで プライベートは、WebExtensionsとかいろいろ 2
  3. 3. ログ、活用してますか
  4. 4. 製品の改善・マーケティング アクセスログからユーザーの行動を解析して、 製品の導線を改善 このお客さん、お試し中にいろいろ試している。 サポートしてみよう! 4
  5. 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. 6. ログ基盤の2つの目的 ログの分析 製品改善や、マーケティング・営業に利用 障害調査 ログの収集 閲覧・解析するために、全てのホストを1箇所に集約 ディスクを圧迫するので、収集されたログをホストから削除
  7. 7. サイボウズのインフラの規模感 自社製データセンター ホスト数(実機 + VM): 1200程度 リクエスト数 : 2.0億/day ログ量 : 20億行/day, 800GB/day(毎秒平均 23,000行くらい) 7
  8. 8. サイボウズのログ基盤 ~ 2016年
  9. 9. サイボウズのログ基盤 | ~2016年 収集ノード 転送デーモン (cron) Application Host SSH MySQL MySQL 本番環境 社内環境 全ホストからSSHで ログを転送 アクセスログは定期的に 社内環境に転送 古いログは テープに永続化 9
  10. 10. 分析基盤の課題 | 使えるログが範囲が限定的 ログの利用者は、いろんなログを解析したい! 他のログと組合せて利用できない MySQLからは古いログが削除 テープには永続化されてるが、取り出すのは、時間と手間がかかる 実質アクセスできるのは直近数カ月分のみ 😣 10
  11. 11. 分析基盤の課題 | とにかく遅い! 1台のMySQLを、SRE・開発者・プロダクトマネージャーが共有 1日のレコード数はおよそ2億件 簡単なクエリでも数時間かかる 「アクセスログにクエリを実行した。明日の朝には終わってるだろう。」 11
  12. 12. 収集基盤の課題 単一ノードがSSHでログを集める SSHの転送路が限界ギリギリ 😣 サービスの成長に合わせてスケールできない 😣 転送経路が単一障害点で、停止するとログ転送全体が影響 😣 12
  13. 13. 💪 ログ基盤プロジェクト発足 💪 SRE・サービス開発者が便利に使えるよう、横断的に活動 ログフォーマットの仕様の決定 サービス開発者も自由に利用できる仕組みづくり プロダクトマネージャーも巻き込んで、 開発外の人たちの要件も取り入れ 13
  14. 14. 新しいログの基盤の要件 到達保証: ログを取りこぼすことなく、途中の経路でもデータロスしない 長期保存: 最低10年間ログを保存 高スケーラビリティ: サービスの成長に追従して、ログ基盤もスケール ユーザビリティ向上: grepではなく、横断的に検索・解析 リアルタイム性: ログが出力されて数分以内には、閲覧・解析可能 14
  15. 15. サイボウズのログ基盤 2018年
  16. 16. サイボウズのログ基盤 | 2018年 Kafka Cluster Hadoop Cluster Elasticsearch Cluster Application 転送デーモン Host hbase clientBroker Broker Broker Broker 出力されたログは Kafkaに転送 分散メッセージキュー アクセスログは Prestoで解析 Elasticsearchで 検索・解析 Hadoopに永続化 16
  17. 17. 2018年の分析基盤 ログをHadoopクラスタに永続化、 古いログを使った解析の対象に 複数ノードと列指向のデータで高速な解析 Web UIを提供して、営業・マーケティング も利用できる解析基盤 17
  18. 18. 2018年の収集基盤 転送路に分散メッセージングシステムを導入 冗長化された経路で、高信頼な転送路 😃 ログ量にあわせたスケールや、ログサービスの追加が容易 😃 現ログ量の数倍は許容できるスループット 18
  19. 19. 新しいログの基盤の要件 高スケーラビリティ -> 転送路のノード数を追加してスケールできる ユーザビリティ向上 -> Web UIを使った分析 リアルタイム性 -> 出力されて2-3分後にはログが利用可能 19
  20. 20. まとめ サービスの成長にあわせて、ログ基盤も新しくする必要があった ログ基盤プロジェクトが発足 Kafka + Hadoopで、スケーラブル・高信頼・高可用性なシステムを実現 マーケティング・営業の方にも使えるプラットフォーム 20

×