こんにちは。アプリケーション基盤チームの @ueokande です。 今日は、サイボウズの新しくなったログ基盤についてお話しします。
サイボウズのログ基盤の進化
リプレイス前のログ基盤
サイボウズのログ基盤はサービスの成長に合わせて、常に進化し続けてます。 そんななか2017年の夏に大きなリプレイス作業がありました。
以前のログ基盤は、ログを収集するホストがあり、各ホストからログを収集してました。 しかしログの転送システムが単一障害点であったり、スケーラビリティに欠けるのでサービスの成長に追いつかず、性能的にも限界に達してました。 また以前のログ基盤では、ログの解析がしにくく、ログはあるけどビジネスに役立てにくい状況でした。
そのため今後のサービスの成長や、より安定したログ基盤を運用できるように、ゼロから刷新することにしました。 またログ基盤刷新と同時に、サイボウズの社員がより簡単にログを検索・解析できるような仕組みの導入も目指しました。
サイボウズのログ基盤で求められてること
ログは、Webアプリケーションの健康状態・利用状況を表すのに欠かせないもので、障害対応や製品開発などに役立てることができます。 サイボウズのクラウドサービスは、独自のデータセンターで稼働しているため、Webアプリケーションの状態だけでなく、物理機材のログも日々監視しています。
VMと物理機材を合わせると1000を超えるホストがサービスを提供しており、ログの量は1日800GBにも上ります。 これらのログを活用するために、全てのホストからログを収集、保存、そして解析できるログ基盤が必要になります。 サイボウズのログ基盤の要件は、次のようなものがあります。
- 到達保証: ログを取りこぼすことなく、途中の経路でもデータロスしないこと
- 長期保存: 最低10年間ログを保存できること
- 高スループット: サービス成長に追従して、ログ基盤もスケールできること
- ユーザビリティの向上: grepで検索するのではなく、検索・解析できるプラットフォームがあること
ログ基盤の全貌
2018年現在のログ基盤の全体図は以下のようになります。
ログ基盤ではログを一時的に保存する場所として、分散メッセージングシステムであるApache Kafkaを採用しました。 ログを永続化する保存先には、Apache Hadoopをバックエンドに持つApache HBaseを採用しています。
アクセスログはHadoopクラスタに保存され、PrestoとRedashを使ってHive上のデータを解析できるようにしました。 全てのログのうち直近のログは、Elasticsearchをバックエンドに持つGraylogで、検索・解析ができます。 それ以外の古いログは、HBaseに問い合わせることで、CLIからログを閲覧できます。
それではそれぞれのコンポーネントについて、より深く見ていきたいと思います。
各ホストからKafkaへの転送
各ホストからKafkaへ転送するログは、ファイルのログとjournaldのログです。 転送デーモンは、ファイル・journaldを監視して、新たな書き込みがあったデータをKafkaに転送します。 そして転送が完了した古いログは、ディスクを圧迫しないよう削除します。 転送デーモンがログの送信から古いログの削除を行うので、ログを欠損することなく確実にKafkaに送信できます。
また、出力されるログをほぼそのままの形式でKafkaに記録し、ログの加工処理は後段のサービスに任せます。 ログは行ごとに分割してKafkaに送信しますが、ログの1行あたりの長さはアプリケーション依存なので予測できません。 開発環境でしたが、1行数百MBものログに遭遇することもありました。 なので転送デーモンは、ログを一定の長さ毎に分割してKafkaに記録します。 このとき分割されたログだという状態を付与して、Kafkaに保存します。 ほかにもホスト名やタイムスタンプなどの情報を付与します。
Kafkaクラスタ
クラスタの中心に、分散メッセージングシステムのApache Kafkaを採用しました。 Apache Kafkaは高い信頼性とスループット、そしてat-least-onceを容易に実現できるため、我々の要件と非常に相性が良かったです。 そしてApache Kafkaクラスタの存在で、メンテナンスや仕様の変更に強いシステムも実現できました。
Kafkaでは耐障害性と可用性を考え、レプリカ数3、mininum in-sync replicaを2にしています。 そして確実にKafkaにデータが書き込まれることを保証するため、書き込み側は全てのin-sync replicaの書き込みを待つよう設定します。
HBaseによる長期ログの保存
Kafkaに一時的に貯められたログは、最終的にHadoopクラスタに永続化されます。 Hadoopは高信頼で高いスケーラビリティのある分散ファイルシステムを構築できます。
小さなログファイルを直接HDFSに保存すると、パフォーマンスの問題があります。 またテキストファイルは検索の利便性に欠けるため、ログはHDFSをバックエンドに持つApache HBaseに記録します。 HBaseはGoogleのBigtableを元に作られており、大量データを高速に処理できます。
HBaseには「トピック名」「ホスト名」「タイムスタンプ」をキーとしてログを記録しています。 この設計で、ユーザーが見たいログに高速にアクセスできます。 直接HBase Shellを叩くのは辛いので、ユーザーにはCLIのクライアントツールを提供しました。
Hive、Presto、Redashによるアクセスログ解析基盤
アクセスログは、ログの中でも需要が高いログです。 アクセスログを検索・解析することで、製品改善に役立てたり、販売促進につなげることができます。
Kafkaに保存されたアクセスログは、Hiveから読めるようにHDFS上に保存します。 そしてパワフルにログの検索や解析をできるよう、Prestoを採用しました。 また開発の人以外の社内の人向けに、Redashを採用してWeb UIからクエリを叩けるようにしました。
ユーザーフレンドリーなWeb UIを提供することで、開発側の人間だけでなく、 営業やマーケティングの人たちもアクセスログをビジネスとして活用できるようになりました。 例えばダッシュボードでA/Bテストの結果を可視化したり、アラートを設定してパフォーマンスの劣化を検知できるようになりました。 以下のグラフは、ある日のサイボウズLiveの1日のアクセス数の例です。
Elasticsearch、Graylog によるログの検索・解析基盤
HBase上から全てのログを閲覧できますが、HBaseは全文検索に不向きです。 またデータセンターにログインする必要があるため、気軽にログを見ることができません。 そこでWeb UIから容易にログを検索するために、Elasticsearchをバックエンドに持つGraylogを採用しました。 全文検索はとても高速なので、ユーザーは複数のホストや時刻をまたがった検索なども容易にできます。
Elasticsearchクラスタは高速に検索・解析がしたいので、NVMe機材上に構築しました。 毎日800GBものログが生成されるので、全てのログを格納できるElasticsearchクラスタを構築するのはコスト的に見合いません。 なので直近のログをElasticsearchに保存するようにしてます。
またGraylogを採用したもうひとつの理由は、詳細な権限設定ができるためです。 社内では、お客さんのデータをマスクしたログと、お客さんのデータを含む生のログを出力してます。 Graylogではロールベースで権限を設定できるため、たとえばお客さんのデータを見る権限が無い人には、マスクされたログしか見れないという運用が可能になりました。
最後に
以上で、2018年現在のログ基盤の全貌となっています。 現在は本番環境で元気に安定稼働しており、日々の業務に役立っています。 とはいえ全てが順調に行くはずもなく、開発初期は分散システムの謎の挙動に悩まされたりしました。 しかし本番環境に導入する前に、長期間ステージング環境で動作させ、問題の早期発見につながりました。
サイボウズではログ基盤の構築や運用に興味のあるエンジニアを募集しています。 この取り組みに興味がある、協力したいという方はご連絡ください！
