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.

サイボウズのサービスを支えるログ基盤

36,427 views

Published on

Cybozu Meetup #6 大規模サービスを支える名脇役たちでの発表
https://cybozu.connpass.com/event/61329/

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. サイボウズのサービスを 支えるログ基盤 ゼロからの刷新とこれから Cybozu Meetup #6, 2017-07-25 @ueokande Cybozu Inc.
  2. 2. $ whois 上岡 真也 2016年サイボウズ入社 アプリケーション基盤チーム GitHub/Twitter: @ueokande
  3. 3. 目次 cybozu.comのこれまでのログ基盤 ログ基盤のゼロからの刷新 新しいログ基盤のこれから
  4. 4. cybozu.comの これまでのログ基盤
  5. 5. cybozu.com
  6. 6. cybozu.comとは 2011年にスタートした、企業向けクラウドサービス 契約社数 20,000社以上 ユーザ数70万人以上 リクエスト数1.7億/day
  7. 7. cybozu.comを支えるインフラ 自社製データセンター ホスト数(実機 + VM): 1200程度 ログ量 20億 行/day, 800 GB/day (毎秒平均 23,000行 くらい)
  8. 8. なぜログが重要か ログはWebサービスの健康状態を示す 障害対応の手がかり サービスの改善に役立てる 性能検証 ユーザの行動をビジネスに利用する
  9. 9. これまでのcybozu.comのログ基盤 1. ログを毎分ローテート 2. ローテートされたログをtarに固める 3. SSHでtarをストレージサーバーに転送 4. 転送が完了したログをホストから削除
  10. 10. そろそろ限界... ログの増加にシステムが追いつかない スケールしたいけどできない 転送システムがSPOF 転送ホストが止まると、全体のログ転送が停止する ログを活用できていない 可視化・解析できていない、開発者以外が利用できていない
  11. 11. ちくちょう。 刷新だ! Trying to crawl here by Donnie Ray Jones | https://www.flickr.com/photos/donnieray/32890584381/
  12. 12. ログ基盤のゼロからの刷新
  13. 13. 新ログ基盤の要件 ① at least once ログを取りこぼすことなく集める ② 信頼性 どこかで障害が発生しても、全体の転送が止まらない ③ ログを活用できる ログを活用できるサービスを容易に導入できる
  14. 14. 新ログ基盤アーキテクチャ 出力されたログは Kafkaに転送 必要なサービスが Kafkaからログを取り出す
  15. 15. Apache Kafkaとは pub/sub型の分散メッセージングシステム LinkedInが開発してOSS化した Twitter、Netflix、LINEなどの採用実績
  16. 16. Apache Kafkaを使う理由 分散メッセージングサービス データはレプリケーションされるので、急にノードが死んでも大丈夫 ノードを追加することで容易にスケールできる pull型consumerのpub/subシステム データを購読する側が任意のタイミングでデータを読みだす 入力側・出力側が粗結合になり、それぞれ独自のタイミングで読み書きできる
  17. 17. 各ホストからKafkaへの転送 ログファイルの更新を監視してKafkaに送る ローテートされて転送が完了したログはディ スクから削除
  18. 18. Kafka clusterから各サービス HBase ログをHadoop上に長期保存する Hive + Presto ユーザの動向をクエリで検索・解析する Graylog ログの検索、監視
  19. 19. At least once システム全体で、ログを取りこぼすことなく配送 どこかのホストが突然の死を遂げても、ログのデータロスが発生しない ログの重複は許す(≠ exactly once)
  20. 20. At least once | Kafkaへのログ転送 初めはFluentdでKafkaへ転送してたが、 at least onceを満たすことが難しいと判明 転送エージェントをGoで実装 状態はatomicに更新 ローテート後もしばらく監視
  21. 21. At least once | Kafkaからの転送 HiveやHBaseへの経路は冗長構成 HDFS上のファイル操作もatomicに更新する必 要がある
  22. 22. 信頼性とログの活用 信頼性 Kafka/Hadoopのノードが死んでも全体の転送は止まらない ラックの電源が落ちても大丈夫なように、同クラスタのノードはラックを分離 ログの活用 用途に応じて、様々なサービスを追加できた 新たなサービスを追加するのに、他の箇所に影響しない
  23. 23. 新ログ基盤の要件 at least once → 電源断してもデータロスが起こらないように設計 信頼性 → 冗長性をもたせたクラスタ構成とラック設計 ログを活用できる → Kafkを使うことで容易にサービスを追加できる
  24. 24. 苦労話 | 長いログの対応 Kafkaのレコード長には上限がある MySQLのスローログでは1行が10MBを超えるケースもある Kafkaのレコードに、断片化されたログかのフラグを付与 Kafkaからログを取り出す時、再び結合するのが少し大変
  25. 25. 苦労話 | 転送遅延 ある日、Kafkaからの転送が大きく遅延した 本番環境と同じ環境を開発環境に構成してたた め、早期に気付けた Kafkaのパラメータチューニングして解決
  26. 26. 苦労話 | journaldに悩まされる アプリケーションのログをjournaldに集める計画もあった 社内でjournaldを導入してみたらいろいろ問題が 長いログの行が勝手に分割される Disk Full時にjournaldが死亡する 結局ファイル最強だった
  27. 27. 新しいログ基盤のこれから
  28. 28. これからやっていきたいこと より良い製品づくりに役立てる ユーザデータを可視化・解析して製品改善に役立てる 必要なログやデータを組合せて、障害調査を加速させる 開発者以外も広く利用できる環境 エンジニア以外もログを利用できる環境の用意 ユーザへのサポートやマーケティングを効率化させる
  29. 29. まとめ サイボウズのログ基盤が新しくなりました Kafka導入で「at least once」「信頼性」「ログを活用できる仕組み」を実現 これからもログをどんどん活かして、より良い製品づくりに役立てます

×