re:InventでのLogglyの分散ストリーム処理環境に関するセッションが面白かったのでまとめておく
さきほど帰国。parse.comのメモに引き続き、re:InventでのLogglyのセッションについてもまとめておく。
- 【追記 2013/11/20 9:20】スライドがupされていたので貼っておきます。
要約すると、
- お客さんから大量に送られてくるログをリアルタイムに捌くためのシステム
- 最初の設計ではSolrCloudを利用していた
- 第二世代ではElasticsearchを利用。システム全体としてElasticな環境に。
- 基本環境はKafka + Stormな構成
セッションの情報は以下のとおり。
ARC303 - Unmeltable Infrastructure at Scale: Using Apache Kafka, Twitter Storm, and Elastic Search on AWS
This is a technical architect's case study of how Loggly has employed the latest social-media-scale technologies as the backbone ingestion processing for our multi-tenant, geo-distributed, and real-time log management system. This presentation describes design details of how we built a second-generation system fully leveraging AWS services including Amazon Route 53 DNS with heartbeat and latency-based routing, multi-region VPCs, Elastic Load Balancing, Amazon Relational Database Service, and a number of pro-active and re-active approaches to scaling computational and indexing capacity.
The talk includes lessons learned in our first generation release, validated by thousands of customers; speed bumps and the mistakes we made along the way; various data models and architectures previously considered; and success at scale: speeds, feeds, and an unmeltable log processing engine.
Philip O'Toole - Senior Architect and Lead Developer, Loggly Jim Nisbet - CTO and VP of Engineering, Loggly
https://portal.reinvent.awsevents.com/connect/sessionDetail.ww?SESSION_ID=1246
発表スライド
Infrastructure at Scale: Apache Kafka, Twitter Storm & Elastic Sear...
Infrastructure at Scale: Apache Kafka, Twitter Storm & Elastic Search (ARC303) | AWS re:Invent 2013 from Amazon Web Services
Logglyについては、
- log management as a service
- 2010年からawsつかってる
- お客さんがreal timeにログをおくってくるので、near real-timeにindexingしてる
とのこと。以下セッションを聴きながらツイートした内容。
13:30から"ARC303 - Unmeltable Infrastructure at Scale: Using Apache Kafka, Twitter Storm, and Elastic Search on AWS"を聞く予定です
— Kenta Suzuki (@suzu_v) 2013, 11月 15Logglyのセッション、logのvolumeとself-inflicted painのグラフがプレゼンされていてみていてあるある感満載
— Kenta Suzuki (@suzu_v) 2013, 11月 15$ sudo rm -rf /var/log/apache2 という怖いコマンドが書かれているスライド
— Kenta Suzuki (@suzu_v) 2013, 11月 15Sumo Logic, Loggly, New Relic, DataDogといろいろなmonitoringサービスの話を聞けるなかなか珍しいカンファレンスだよなぁとふと思った
— Kenta Suzuki (@suzu_v) 2013, 11月 15初期のLoggly。Solr cloudを利用。数1000のシャード。queueにZeroMQ。EC2インスタンスのストレージを利用。10 - 100k events / secの様々お客さんが1000アカウントくらい。ログのtrafficはよくバーストする。
— Kenta Suzuki (@suzu_v) 2013, 11月 15学んだこと。indexingが最も厳しい。solrの問題で一時的に手動でre-indexingしなければいけなかったりした。また、複数のindexingの戦略が必要だった。10epsと100000+epsのユーザにはことなるindexの戦略が必要。
— Kenta Suzuki (@suzu_v) 2013, 11月 15かつ、low volumeなユーザについてリッチ過ぎるシステムになってしまっていた。
— Kenta Suzuki (@suzu_v) 2013, 11月 15Apache Kafkaの利用。分散pub-sub型のメッセージングシステム。persistentなメッセージングが可能であり、高いスループットが可能。ZooKeeperをcluster管理に利用。queueとtopicによるセマンティクスをサポート。
— Kenta Suzuki (@suzu_v) 2013, 11月 15Kafkaでマシン並べたら50台で400000msg/secくらいカジュアルにさばけるようになったぜ、という話
— Kenta Suzuki (@suzu_v) 2013, 11月 15Stormについて。Spout, Boltの説明をされてる。さっきKinesisの説明聞いたので既視感が。Kinesis ApplicationがBoltみたいなものかさっきのところでいくと。
— Kenta Suzuki (@suzu_v) 2013, 11月 15KinesisだとこのZookeeperによる管理とかSupervisorの部分がAWSが持ってくれるということになるっぽい
— Kenta Suzuki (@suzu_v) 2013, 11月 15Elastic Search in Action。管理が簡単。動的にノードを追加削除できる。attributeをnodeやindiceに持たせることができる。また、indiceは自動的に最適なnodeに異動する。indiceはsharding可能。またバルクインサートをサポート。
— Kenta Suzuki (@suzu_v) 2013, 11月 15Loggly第二世代。常にログを受け入れられるように。logを失わないように。全てのログをクリティカルなものであると扱うようにした。また、完全にElastic(True Elasticity)な設計にした。
— Kenta Suzuki (@suzu_v) 2013, 11月 15Apache Kafkaをmessage queueingに。顧客がqueueのlocationをtrackできるようにした。
— Kenta Suzuki (@suzu_v) 2013, 11月 15StormをEvent processingに利用。Stormを"pull"システムとして利用。average loadによってプロビジョニングするようにしている。Kafkaからqueueを入力。このプロビジョニングがAWSとマッチした。workerが動的に増減できる。
— Kenta Suzuki (@suzu_v) 2013, 11月 15Eventの収集は+100ks/sec, TCP/UDP及びHTTPをサポート。3つのazのcollectorに転送。KafkaのBrokerにこれを渡す。broker nodeにはEBSのパーティションが割り当てられている。この設計は非常にロバストで使い勝手が良い。
— Kenta Suzuki (@suzu_v) 2013, 11月 15logglyのログコレクタはC++のマルチスレッド実装。Boostを利用。それぞれのコレクタは250k+ のイベントをm2.2xlargeで処理することが可能。
— Kenta Suzuki (@suzu_v) 2013, 11月 15ステージングとプロダクション環境について。Kafkaのbrokerのebsの一部のpartitionをstagingのためのデータのprocessingに利用。
— Kenta Suzuki (@suzu_v) 2013, 11月 15Loggly, collector: c1.xlarge。Kafka: m2.2xlarge、ディスクのバッファでキャッシュ。ebs: 4K PIOPs EBS。storm supervisor: c1.xlarge。nimbusとzookeeperはm1.xlarge
— Kenta Suzuki (@suzu_v) 2013, 11月 15いくつかの失敗について。collectorのフロントにelbを置いていた。しかし、elbは514(syslog)ポートをforwardしてくれない。またUDPをサポートしない。また、burst時にelbのパフォーマンスの限界に達してしまった。
— Kenta Suzuki (@suzu_v) 2013, 11月 15Route 53 DNSラウンドロビンを使ったのは良かった。basicな方法。AWSのhealth checkの仕組みを上手く利用することが出来た。また、ラウンドロビンはAZやregionをまたがってもうまく動作した。
— Kenta Suzuki (@suzu_v) 2013, 11月 15最初のプラン。cassandraを利用する予定だった。writeが早いのもあっている。利用するならDataStaxのサポートを利用しようと思っていた。しかし、Cassandraはメッセージキューのためにはデザインされていない。
— Kenta Suzuki (@suzu_v) 2013, 11月 15総括として、良かったことはAWSのサービスをレバを効かせて使えたこと。multi-region, az。PIOPS。Route 53のDNSによるlatencyの解決。Stormのリソースを簡単に増減させられたこと。そしてKafka, Storm, ESを採用したこと。
— Kenta Suzuki (@suzu_v) 2013, 11月 15興味深いセッションだった。
— Kenta Suzuki (@suzu_v) 2013, 11月 15所感
Kafkaによるmessage queueingをベースとしたdistributed stream processingの設計を聴けたのはよかった。ちょうどこの前のセッションがAmazon Kinesisだったので、それと比較して聴くことが出来た。Solr CloudとElasticsearchのそれぞれにおけるindexingの戦略についてはあまり僕自身は詳しくないのでそのあたりはもう少し調べたいところ。KafkaについてはZooKeeperによるクラスタの管理をしてはいるものの、先日のparse.comの例のようにprovisioning周りを便利に作っておかないと面倒そうな印象。kafkaから流れてきたqueueを処理するバックエンドのworkerを動的にコントロールできるのはAWSを利用した場合のメリットであると触れられていて、これはKinesis Applicationでも同様のことが言える。システム全体としてフロントのログ収集からstream processing, そしてElasticsearchをバックエンドに置くことで全体としてのelasticityを担保しているところがスマートな設計であるように感じた。
また細かい話だけれど、staging環境のために、production環境のKafka brokerのEBSのあるパーティションのみ流しこむようにしているのは興味深かった。こういうKafkaのバックエンドworkerで処理するためのプログラムというのは本番のデータで検証するのが一番なのだけれど、なかなか検証環境を作るのが面倒だったりする。例えば、Amazon Kinesisでも特定partitionをstaging用に流すことで同様の検証を行うためにこのパターンを利用することもできるだろう。
