Help us understand the problem. What is going on with this article?

リアルタイム処理エンジンGearpumpって?

More than 3 years have passed since last update.

こんにちは、最近Gearpumpという面白そうなプロダクトを教えてもらったので、それについて調べてみようと思います。

参照:
http://www.gearpump.io/
http://conferences.oreilly.com/strata/big-data-conference-sg-2015/public/schedule/detail/45109

Gearpumpとは?

Intel発のOSSでリアルタイムなビッグデータストリーム処理エンジンです。
構造としてはDAG構成を持ったグラフをベースとし、それを実行するためのエンジンとなります。

類似の類似のプロダクトにはどのようなものがあるか?

具体的にGearpumpがビッグデータのプロダクト群の何に対応づけられるかというと、下記の図のとおりとなります。
Gearpump01.png

レイヤとしては実際に処理を実行するためのエンジン部、その中でもストリーム処理を行うプロダクトになります。

ストリーム処理系のプロダクトとしては下記のようにプロダクトが公開されてきています。
実際にはActiveMQやKafkaはデータを流す基盤プロダクトなので微妙に立ち位置は違いますが、過去Yahoo S4、Storm、Spark Streaming等が公開されてきたものの流れを汲むプロダクトという位置づけとなりそうです。

Gearpump02.png

どのような特徴を持っているか?

サイトを見るに、下記のような特徴を持っているようです。

  • 高性能
  • 低レイテンシ
  • メッセージの処理信頼性設定可能(At least once / exactly once)
  • 高拡張性
  • 動的DAG
  • Storm互換
  • Samoa互換
  • 広範なIoT接続容易性
  • 高レベル、低レベルの両方のAPIを提供

大部分はこういったストリーム処理基盤でよく謳われる項目なのですが、中でも目を引くのがexactly onceをストリーム処理基盤で可能という所です。
これまでStorm等ではexactly onceは実現できず、相応に実現したSpark Streamingは中身の実態はバッチ処理、という事情もあります。
ですので、モデルとして1メッセージずつ処理するリアルタイム/ストリーム処理基盤系でexactly onceを達成したプロダクトを私は知らなかったので、実際どういうものかは興味がわきました。

具体的にどのくらい性能が出るのか?

ページのトップを見る限り、4nodeのクラスタで100バイトのサイズを持ったメッセージを毎秒1100万件17msのレイテンシで処理したとあります。
Gearpump03.png

尚、実際にどのような処理を行ったかというと、100バイトのランダムのメッセージを生成し、それを下流に流すというのみの、主にネットワーク帯域をどこまで活用可能かを確認するためのテストのようです。
処理量は少ないですが、メッセージの送信についてはStormのデフォルトであるShuffle Groupingがベースとなっているため、ネットワーク的な効率は悪い構成。
これが妥当かどうかはちょっと悩みどころですが、単にスループット、ネットワーク的な性能を試すという意味ではそれなりに有効なようには見えます。

デフォルト設定なのであれば、下記の構成となるようです。
- 階層は2階層(メッセージを生成するモジュール>メッセージを下流に流すモジュール)
- メッセージを下流のどのモジュールに流すかはラウンドロビン(StormでのShuffleGrouping)

参照:
https://github.com/intel-hadoop/storm-benchmark/blob/master/src/main/java/storm/benchmark/benchmarks/SOL.java

どのくらい使いやすそうなの?管理しやすそうなの?

この手の処理エンジンを使う時に必須となるのが管理をするための画面ですね。
GearpumpはStormのような初期のプロダクトのUIとは違い、直観的に中身がそれなりに見えるダッシュボードを有しているようです。

dashboard.gif

どのような技術要素で構成されて、どのような運用が出来そう?

基本的にAkkaのActorをベースとしたアーキテクチャとなっているようです。

actor_hierarchy.png

Akka Streamsのように下記のような記述でモジュールの連鎖を組むことも可能な模様。

image

そのため、実装言語もJavaとScalaを用いた構成となっており、JVM系エンジニアとしては非常に都合がいい言語構成となっています。

また、YARN上で実行する構成、自前でクラスタ管理する構成の両方を提供し、実行基盤も確保しやすくなっています。

図2.png

あとはMasterの多重化によってプロセスが落ちた、ノードが落ちた、というケースの障害に対しては単一障害点は除去している模様。
まぁ、この手の分散処理基盤の単一障害点ないよ、はあまり信頼が置けないと言えば置けないのですが。
図1.png

まとめ

上記のとおり、Gearpumpのサイトや発表資料をざっと見て概要的な部分を漁ってみました。
次回ぐらいにもう少し詳細な情報を資料から読み解いてみて、その次位から実際に動かしてみましょうか・・・

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away