すずけんメモ

技術メモです

re:InventでのLogglyの分散ストリーム処理環境に関するセッションが面白かったのでまとめておく

aws

さきほど帰国。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...

http://www.slideshare.net/AmazonWebServices/infrastructure-at-scale-apache-kafka-twitter-storm-elastic-search-arc303-aws-reinvent-2013

Logglyについては、

  • log management as a service
  • 2010年からawsつかってる
  • お客さんがreal timeにログをおくってくるので、near real-timeにindexingしてる

とのこと。以下セッションを聴きながらツイートした内容。

所感

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用に流すことで同様の検証を行うためにこのパターンを利用することもできるだろう。