読者です 読者をやめる 読者になる 読者になる

Taste of Tech Topics

Acroquest Technology株式会社のエンジニアが書く技術ブログ

Apache Storm 1.0.0の機能を使ってみる

Java Storm

お久しぶりです@ です。

このブログへの登場はかなり久しぶりです。昨年10月にミャンマーから日本に帰ってきて、今は、IoTやら可視化などに関する仕事をしています

さて、TwitterよりStormが公開されて以降、分散ストリーム処理フレームワークも、FlinkSpark StreamingSamzaBeamGearpumpSensorBee等、さまざまなOSSプロダクトが公開されました。

世はまさに「大ストリーム時代」!?(ワンピース風)

そのような中、4/12にApache Storm から正式メジャーバージョンとなる、1.0.0がリリースされました。このタイミングでどのような機能が盛り込まれるのか、興味を持っていましたが、これまでの課題を解消しつつ、他プロダクトよりも一歩先に行くような内容もリリースされました。

大きな変更点は12個

以下の公式サイトでも公表されていますが、メインとなる変更点は12個のようです。
Storm 1.0.0 released

No タイトル 内容
1 Improved Performance 16倍の処理速度向上と、60%のレイテンシの減少に成功しました。
2 Pacemaker - Heartbeat Server Stormがスケールアップするにつれて生じていたZookeeperのパフォーマンスボトルネックの解消のため、インメモリのKey-Valueストアとして機能するオプションのStormデーモンPacemakerが追加されました。
3 Distributed Cache API Topology毎に共有できるデータストア空間を用意し、Blobで共有データが保持、参照できるようになりました。
4 HA Nimbus Distributed Cache APIの機能を利用することで、高可用性を備えたNimbusが実現可能になりました。
5 Native Streaming Window API Storm Native な Window APIが用意され、いわゆるCEP処理を実装しやすくなりました。
6 State Management - Stateful Bolts with Automatic Checkpointing 自動チェック機構を備えたステートフルなBoltの利用により、状態管理が可能になりました。
7 Automatic Backpressure 上限値、下限値の設定による自動バックプレッシャーが可能になりました。
8 Resource Aware Scheduler Topology毎のリソース(メモリ/CPU)を考慮したタスクスケジューラが実現可能になりました。
9 Dynamic Log Levels Storm UIから動的に出力ログレベルの変更が可能になりました。
10 Tuple Sampling and Debugging Storm UI上でTupleのサンプリングとデバッグが可能になりました。
11 Distributed Log Search Worker毎に分散されてしまうログの検索がStorm UI上で実施可能になりました。
12 Dynamic Worker Profiling WorkerプロセスのプロファイリングがStorm UI上で可能になりました。


今回は上記の変更点の中から、特に面白いだろうと思われる以下の3点を調べてみました。他のものは、なんとなくタイトルから想像できますよね。

  1. Distributed Cache API
  2. Native Streaming Window API
  3. Automatic Backpressure

Distributed Cache APIを使ってみる

前バージョンでは、デプロイしたTopology上で何かファイルのデータなどを使いたい場合、Topologyと一緒にデプロイする必要がありました。そのため、大きなデータをTopology起動後に利用したい場合は、デプロイそのものに時間がかかることがありました。
また、各サーバに共有データを置いたり、データ共有のためにKVSなどのStormとは別のプロダクトを利用するのは、実現したいことに対して重く感じます。
しかし今回のバージョンアップで、Topology上で使いたいファイルを、Stormが持っているデータストアに保持し、Topologyからそのデータを参照することが可能になりました。共有データ保存場所が存在し、そこにデータを配置することでデプロイ時間の削減を可能にした機能です。共有データのサイズが大きければ大きいほど、その恩恵を受けることができます。本家サイトでは「位置情報」や「辞書データ」を保持するとよい、と言われています。

Distributed Cache APIの仕組み

Stormのサイトに素敵な解説図があるので、転載させてもらいます。BlobStoreというインタフェースがあり、このインタフェースを実装したLocalFsBlobStoreとHdfsBlobStoreが提供されています。どちらのStore実装も処理の流れはほぼ同じです。仕組みとしては、Supervisor起動時にBlobStoreのMapを取得し、その後MapにしたがってMap情報(共有データ)を取得する流れのようです。

[LocalFsBlobStore]
f:id:acro-engineer:20160425224701p:plain

[HdfsBlobStore]
f:id:acro-engineer:20160425224721p:plain

使ってみる

早速使ってみます。

  1. 共有データの登録
  2. Topologyの起動

が手順になります。確認のため、Topologyは2つ動作させます。

共有データの登録

README.markdownの登録をします。

# ./bin/storm blobstore create --file README.markdown --acl o::rwa --replication-factor 4 key1

共有用のデータは「storm.local.dir/storm-local/blobs/」に配置されていました。

Topologyの起動

Topologyを2つ起動し、どちらも登録したREADME.markdownをダウンロードすることをログから確認したいと思います。本来はTopologyの中で利用されているところを確認したいのですが、サンプルに適当なものがなかったため、ひとまず起動時に登録した共有データが読み込まれることを確認したいと思います。

# ./bin/storm jar examples/storm-starter/storm-starter-topologies-1.0.0.jar org.apache.storm.starter.clj.word_count test_topo -c topology.blobstore.map='{"key1":{"localname":"blob_file", "uncompress":"false"}}'

test_repoというTopologyを作成し、key1というキーに対して登録したBlobファイルの中身を解凍オプションなしで参照、実行しています。Blobファイルの読み込みに成功すると、以下のようなログが確認できるはずです。

2016-04-23 14:48:05.782 o.a.s.d.supervisor [INFO] Downloading code for storm id test_topo-4-1461390482
2016-04-23 14:48:06.279 o.a.s.d.supervisor [INFO] Successfully downloaded blob resources for storm-id test_topo-4-1461390482
2016-04-23 14:48:06.280 o.a.s.d.supervisor [INFO] Finished downloading code for storm id test_topo-4-1461390482
:
2016-04-23 14:48:06.285 o.a.s.d.supervisor [INFO] Creating symlinks for worker-id: 6d23e0f9-9aa1-43c6-a475-773b0537bdfb storm-id: test_topo-4-1461390482 to its port artifacts directory
2016-04-23 14:48:06.286 o.a.s.d.supervisor [INFO] Creating symlinks for worker-id: 6d23e0f9-9aa1-43c6-a475-773b0537bdfb storm-id: test_topo-4-1461390482 for files(2): ("resources" "blob_file")

同じ操作で別名のTopologyを作成してみてください。上記と同じデータダウンロードが正常に完了するログが確認できるはずです。これでDistributed Cache APIを試すことができました。

Native Streaming Window APIを使ってみる

Stormのネイティブな機能として、スライディングウィンドウが追加されました。どこまでの内容までがStormネイティブとして対応しているのか、サンプルをベースに確認してみたいと思います。まずはメインパートであるSlidingWindowTopology.javaのソースを確認してみます。

    public static void main(String[] args) throws Exception {
        TopologyBuilder builder = new TopologyBuilder();
        builder.setSpout("integer", new RandomIntegerSpout(), 1);
        builder.setBolt("slidingsum", new SlidingWindowSumBolt().withWindow(new Count(30), new Count(10)), 1)
                .shuffleGrouping("integer");
        builder.setBolt("tumblingavg", new TumblingWindowAvgBolt().withTumblingWindow(new Count(3)), 1)
                .shuffleGrouping("slidingsum");
        builder.setBolt("printer", new PrinterBolt(), 1).shuffleGrouping("tumblingavg");
        Config conf = new Config();
        conf.setDebug(true);
        if (args != null && args.length > 0) {
            conf.setNumWorkers(1);
            StormSubmitter.submitTopologyWithProgressBar(args[0], conf, builder.createTopology());
        } else {
            LocalCluster cluster = new LocalCluster();
            cluster.submitTopology("test", conf, builder.createTopology());
            Utils.sleep(40000);
            cluster.killTopology("test");
            cluster.shutdown();
        }
    }

これだけ見ても、以下の3つのBoltが存在します。

  1. SlidingWindowSumBolt
  2. TumblingWindowAvgBolt
  3. PrinterBolt

これらが何をしているのか、またどのように動くのかを確認したいと思います。

[SlidingWindowSumBolt]
とても単純に、受信したTupleの中身を加算していることがわかります。一応ウィンドウから外れたTupleの値は減算するようにも記述されているので、スライディングウィンドウの条件を満たしていることも確認できます。

    @Override
    public void execute(TupleWindow inputWindow) {
            /*
             * The inputWindow gives a view of
             * (a) all the events in the window
             * (b) events that expired since last activation of the window
             * (c) events that newly arrived since last activation of the window
             */
        List<Tuple> tuplesInWindow = inputWindow.get();
        List<Tuple> newTuples = inputWindow.getNew();
        List<Tuple> expiredTuples = inputWindow.getExpired();

        LOG.debug("Events in current window: " + tuplesInWindow.size());
            /*
             * Instead of iterating over all the tuples in the window to compute
             * the sum, the values for the new events are added and old events are
             * subtracted. Similar optimizations might be possible in other
             * windowing computations.
             */
        for (Tuple tuple : newTuples) {
            sum += (int) tuple.getValue(0);
        }
        for (Tuple tuple : expiredTuples) {
            sum -= (int) tuple.getValue(0);
        }
        collector.emit(new Values(sum));
    }

[TumblingWindowAvgBolt]
設定したWindowのサイズで合計値を除算している、シンプルなつくりでした。SlidingWindowTopologyに内包されていますね。「いくつ溜まったら平均値を計算する」という引数には「3」が設定されています。

        @Override
        public void execute(TupleWindow inputWindow) {
            int sum = 0;
            List<Tuple> tuplesInWindow = inputWindow.get();
            LOG.debug("Events in current window: " + tuplesInWindow.size());
            if (tuplesInWindow.size() > 0) {
                /*
                * Since this is a tumbling window calculation,
                * we use all the tuples in the window to compute the avg.
                */
                for (Tuple tuple : tuplesInWindow) {
                    sum += (int) tuple.getValue(0);
                }
                collector.emit(new Values(sum / tuplesInWindow.size()));
            }
        }

[PrinterBolt]
驚くほどシンプルですね。出力するだけ。

  @Override
  public void execute(Tuple tuple, BasicOutputCollector collector) {
    System.out.println(tuple);
  }

まとめると、以下の通りに動くと予想できます。

  1. ランダムに0~999の整数を、合計用のBoltに送付する。
  2. 合計用Boltはデータを受信時、メモリに保持しているSum値に加算していく。
  3. 受信したTuple数が10になったところで、平均計算用Boltに合計値を送付する。
  4. 1~3を、平均計算用Boltの保持Tuple数が3になったら、平均値を計算する。
  5. 1~4を40秒間繰り返す。


これらを基に、動かした際のログを見てみましょう。ソースコードの通り、起動後に40秒で終了するようなので、以下のコマンドを実行してしばらく待ってみます。

# bin/storm jar examples/storm-starter/storm-starter-topologies-1.0.0.jar org.apache.storm.starter.SlidingWindowTopology

[合計用Boltに対する出力ログ]
以下のような感じで合計用Boltにはログが出力されていました。

17562 [Thread-25-slidingsum-executor[4 4]] INFO  o.a.s.d.executor - Processing received message FOR 4 TUPLE: source: integer:2, stream: default, id: {4017617819859316672=-3880300761259985782}, [899, 1461542140369, 1]
17562 [Thread-25-slidingsum-executor[4 4]] INFO  o.a.s.d.executor - Execute done TUPLE source: integer:2, stream: default, id: {4017617819859316672=-3880300761259985782}, [899, 1461542140369, 1] TASK: 4 DELTA: 
17674 [Thread-25-slidingsum-executor[4 4]] INFO  o.a.s.d.executor - Processing received message FOR 4 TUPLE: source: integer:2, stream: default, id: {-2465951973599725012=3371764614267379312}, [888, 1461542140475, 2]
17674 [Thread-25-slidingsum-executor[4 4]] INFO  o.a.s.d.executor - Execute done TUPLE source: integer:2, stream: default, id: {-2465951973599725012=3371764614267379312}, [888, 1461542140475, 2] TASK: 4 DELTA: 

で、10個たまったところで平均計算用Boltに送付しています。

18516 [Thread-25-slidingsum-executor[4 4]] INFO  o.a.s.d.task - Emitting: slidingsum default [6053]
18516 [Thread-25-slidingsum-executor[4 4]] INFO  o.a.s.d.executor - TRANSFERING tuple [dest: 5 tuple: source: slidingsum:4, stream: default, id: {-1356407922762824927=-4912942846543592390, 4017617819859316672=-8950777703384980140, -7679610850762262585=5600559632140381686, -217168626838496871=6670643717321357413, -8433729321932816312=-1512990481045386819, -695350376461229364=-6915299522591467528, -8604773776820158944=2085240823323939478, 4818452273885227082=1055563511177261421, -4383830359476279213=-2430226558792731842, -2465951973599725012=-3111554498250395772}, [6053]]
:
:
19527 [Thread-25-slidingsum-executor[4 4]] INFO  o.a.s.d.task - Emitting: slidingsum default [11182]
19527 [Thread-25-slidingsum-executor[4 4]] INFO  o.a.s.d.executor - TRANSFERING tuple [dest: 5 tuple: source: slidingsum:4, stream: default, id: {4017617819859316672=1956648145851480265, -7679610850762262585=-8990022321548325348, -217168626838496871=8356349476653175499, 6556174365450512594=-2956830898901769282, 4973296703617984132=630324356173502412, -8433729321932816312=7530781138220324522, 8041484834072108391=-1100584463729972475, -695350376461229364=5513770714708145606, -8604773776820158944=-7212706120285088590, -4383830359476279213=5439461521018447939, -1641897178290464600=-510250118691366334, 6730277299577429107=6208397095766677293, -8115189405407159227=1214364586718890587, -1356407922762824927=3843071132908231388, 7588127658633797238=-3035483582895424875, -1600730095770316997=7644364465767360178, -5977653414665598802=6443496393438179244, -4289645355525492039=-7771435519918529374, 4818452273885227082=2145248154554053428, -2465951973599725012=3719500247592761581}, [11182]]
:
:
20536 [Thread-25-slidingsum-executor[4 4]] INFO  o.a.s.d.task - Emitting: slidingsum default [16102]
20536 [Thread-25-slidingsum-executor[4 4]] INFO  o.a.s.d.executor - TRANSFERING tuple [dest: 5 tuple: source: slidingsum:4, stream: default, id: {-217168626838496871=-2098183848111262192, 6694109964234120893=-2919364166006116209, -490688806946141211=-115866302962242997, 6556174365450512594=3417840899423850921, 4973296703617984132=-2075234239029720284, -8433729321932816312=3438734146522000751, -695350376461229364=5479035516364205453, -1356407922762824927=536244103058094589, -8759945507516006916=-7691606294364721504, -1600730095770316997=5198643672682538868, 1928584781574233931=3233801634595403530, 4818452273885227082=3613752122075445564, 4017617819859316672=-5965638492780984127, -7679610850762262585=8746099621132998817, 3628468721856542322=3234989506915660599, 8041484834072108391=2473403470958482418, -8604773776820158944=4291163489101357389, 5275805877791886609=2224008364377626542, -4383830359476279213=-1613810029185700041, -1641897178290464600=-7937957462653577021, 6730277299577429107=-5906850224979170611, -8115189405407159227=-6807612857900762546, -492827708169915833=-3985992390535713144, 7588127658633797238=7922452426043726560, -3771417496478433111=-1133769369307004904, -5977653414665598802=2226449212304201933, -4289645355525492039=8279576780572003648, 2457695339746807997=-943386263403830945, 7278045793299574088=-3628544844039353718, -2465951973599725012=5019064850597613642}, [16102]]

最後に、3個合計Tupleが溜まったところで平均値を計算して出力しています。

20540 [Thread-23-tumblingavg-executor[5 5]] INFO  o.a.s.d.task - Emitting: tumblingavg default [11112]

この後PrinterBoltにデータ送付しているのですが、PrinterBoltは非常にシンプルなので、ここで触れるのは割愛したいと思います。
さて、上記のような感じでスライディングウィンドウも使えました。設定した閾値に伴い指定された動作をしてくれるので、簡単な仕組みであれば、Stormだけで動作させられそうです。
具体的な関数の整備はこれからのようですが、SlidingWindowSumBoltやTumblingWindowAvgBoltを見ればわかるように、「BaseWindowedBoltを実装してexecuteで計算させる」というシンプルでオーソドックスなAPIになっています。EsperWSO2 CEP(Siddhi)といったCEPプロダクトの関数を実装したことがある人なら、難なく実装できると思います。

Automatic Backpressure

個人的に一番気になっているところです。そもそもBackpressureって何ぞや、というところですが。

Backpressureとは何ぞや?

もともとは半二重接続のハブやスイッチで用いられるフロー制御方式の一つです。機器内の通信バッファがあふれてフローが止まってしまう前に、データ送付側に通知を投げて、送ってくるデータを止めたり、量を調整したりする仕組みのことを言います。

なぜBackpressureがStormに必要か?

Stormがリリースされた際にずっと言われていた問題点として、「Spoutの処理性能がBoltの処理性能を上回っている場合、キューに処理が溜まり続けてTopologyが止まってしまう/遅くなってしまう」という考慮すべき点がありました。Storm自体の処理性能は良いのですが、「データストア用のプロダクトに書き込むBoltの性能が上がらず、キューに溜まる」という事象は「Stormあるある」と言ってよいくらい見かけます。
そのため、Stormの環境を構築する際には、SpoutとBoltの処理性能に気を付ける必要があったわけです。

しかし、今回のBackpressure機構を利用すれば、この問題点を緩和させることが可能になります。今回のBackpressureはTopology単位で以下の設定が可能です。

  1. high-watermarkとlow-watermarkの指定が可能。
  2. キュー内のメッセージ量がhigh-watermarkで指定した比率を上回ったら、Backpressure機能が発生し、Spoutの処理を自動的に遅くする。
  3. キュー内のメッセージ量がlow-watermarkで指定した比率を下回ったら、通常のSpoutの処理に戻る。

こちらに検討中のBackpressureの図が載っているのですが、閾値を検知した時点でZookeeperに通知を飛ばし、Spoutの処理を抑えるような制御をするようです。ただし下記の図は検討中なので、ここからおそらく何らかの変更が加わっているとは思います。公式の発表待ちですね。
https://github.com/apache/storm/pull/700

ただし、解決するパターンと解決できないパターンがきちんと言及されています。

  • 解決するケース:Boltの処理が遅い
  • 解決できないケース:外部システムにアクセスするBoltで、外部システムが止まった場合(「遅い」ではなく、そもそも「処理できない」。こういうケースは、HystrixのようなCircuit Breakerが欲しくなりますね、とStormのissueでも話が出ているようです)

Backpressure利用のための設定値

Automatic Backpressureに関する具体的な設定値は以下で指定可能です。

topology.backpressure.enable: true
backpressure.disruptor.high.watermark: 0.9
backpressure.disruptor.low.watermark: 0.4

まとめ

いくつか特徴的なStormの変更点を確認してきましたが、DevOps・運用面にかなり注目が集まっている時代の中で、Stormもついにそちらに目を向け始めたように見えました。ますます便利になっていくので、目が離せません!


ストリーム王に俺はなる!


Acroquest Technologyでは、キャリア採用を行っています。


  • 日頃勉強している成果を、AWSHadoop、Storm、NoSQL、Elasticsearch、SpringBoot、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
  • 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
  • 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
  • OSSの開発に携わりたい。

 
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
 
データ分析で国内に新規市場を生み出す新サービス開発者WANTED! - Acroquest Technology株式会社の新卒・インターンシップ - Wantedlywww.wantedly.com

OpenStack Ironic用のカスタムイメージファイルを作る【導入編】

OpenStack クラウド基盤

こんにちは、こんばんは、miyakeです :-)

先日の4/7(木)に、OpenStackのMitakaが正式リリースされました :-)
去年のカンファレンスで表明された機能がどこまで実現できているかなどなど、気になっているところです ;-) 多分、近いうちにMitakaを調べ始めることになると思います :-)

話変わって、ここ最近、プロジェクトでOpenStackのIronicを使用したベアメタルクラウド環境の開発や構築をやっているのですが、まだまだ発展途上にあるIronicを使って実運用システムの開発を進めていると、未知の問題やソースコードを読まないと解決しない問題などなど、色々な問題にハマっては解決してきました。
その色々ハマった問題のうちの一つである、Ironic用カスタムイメージファイルの生成手順について、今回と次回の二回に分けて書いてみます。

今回は【導入編】として、Ironicの簡単な説明と、ronic用カスタムイメージファイルの基になる、仮想マシンディスクイメージファイルの作成手順とハマりどころについて説明します。
次回は【Ironic用イメージファイル生成編】として、今回作成する仮想ディスクイメージファイルから、Ironic用イメージファイルを生成する手順について説明する予定です :-)

Ironicって?

f:id:acro-engineer:20160409181126p:plain
Ironicは、OpenStackのベアメタル用コンポーネントのプロダクト名称で、OpenStack Kiloから正式に採用されるようになったコンポーネントです。

本家のIronic概要説明 >> Introduction to Ironic

Ironicが使えるようになる前までは、計算リソースとしてVM(仮想マシン)しか扱えなかったOpenStackですが、Ironicを導入することで、ベアメタルサーバ(物理サーバマシン)を計算リソースとして扱えるようになります。
仮想マシンでは性能要求を満たせないケースや、ハードウェアの機能を直接使用したいケースの問題を解決することが可能になります。
※ケースとして通信性能の限界まで使い切りたいNFVとかGPUを使いたい場合などが考えられます。PCIパススルーで解決できるものもありますが、そこまでするなら物理サーバマシンを利用した方が便利なケースが増えてくるだろうな...と思っています。

Kiloから正式に採用されたとはいえ、NovaやKeystoneのAPI仕様のバージョンアップ時期とも重なっていたせいか、APIバージョンのミスマッチなどもあり、Kiloの次のLibertyから何とか使えるようになった...というのが私の認識です。

Libertyからまともに使えるようになったように書いていますが、Liberty時点のNeutronでは仮想マシン用の仮想ネットワーク機能しかできないため、物理サーバマシンのネットワーク制御については、OpenStackだけでは実現できないという大きな課題が残っています。
この課題があるため、Libertyでは仮想マシンと物理サーバマシンを、Neutronで管理するでネットワークセグメント内で通信させることができません。
※仮想ネットワークにかなりの制限を付けたうえで、フレーバーとかを上手く使えば、なんとか共存出来そうな気はしますが...
次のMitakaで対応する...と宣言されていますが、対応Switchが限定されているため、物理サーバマシンのネットワーク制御については、当分の間は自前で実現することになると思っています...多分物理サーバマシン間のネットワーク制御までで、仮想マシンとの接続はできないか、VLANでセグメントを分離する方式にしか対応できないだろうと思います。
※実際うちのプロジェクトでは、OpenFlowスイッチで物理サーバマシンのネットワーク制御を行うコンポーネントを開発して使っています

Ironicで使用するイメージファイルの種類

Ironicでベアメタルサーバを使えるようにするためには、ベアメタルサーバにインストールする、OSを含めたディスクイメージを用意する必要があります。

このディスクイメージには、大きく分けて「デプロイ用イメージ」「インストール用イメージ」の2種類が必要になります。

概要は、以下のページのシーケンス図に説明されています。

CHAPTER 1. INSTALL AND CONFIGURE OPENSTACK BARE METAL PROVISIONING (IRONIC)
https://access.redhat.com/webassets/avalon/d/Red_Hat_Enterprise_Linux_OpenStack_Platform-7-Bare_Metal_Provisioning-en-US/images/PXE_Provisioning.png

ざっくり説明すると、
シーケンスの"Send a DHCP request"~"Sends the deploy kernel and ramdisk"「デプロイ用ディスクイメージ」をPXEBootを使ってベアメタルサーバに転送して実行し、「インストール用ディスクイメージ」をddコマンドでディスクに書き込めるよう、iSCSIで書き込める準備を行います。
準備ができた通知をIronicが受けると、シーケンスのConnects to the iSCSI endpointインストール用ディスクイメージを書き込みに行きます。
このあと再起動を行い、インストールしたイメージでベアメタルサーバが起動します。

そのようなわけで、Ironicで使用するイメージディスクはに、「デプロイ用ディスクイメージ」「インストール用ディスクイメージ」の2種類を作成する必要があります。
今回の記事の対象となる「Ironic用カスタムイメージファイル」は、「インストール用ディスクイメージ」になります。

ちなみにIronicのイメージファイルの考え方は、V2Pが前提になっています。
V2PとはVirtual to Physicalのことで、仮想マシンディスクイメージを物理マシンにデプロイするという意味になります。
VMにだけ対応していたころのOpenStackであれば、V2V(Virtual to Virtual)だけできていればよかったのですが、ベアメタルサーバに対応する必要があるため、このV2Pに対応する必要が出てきました。

※現時点のIronicではP2P(Physical to Physical)ができません。実運用システムでIronicを使用することを考えると、物理マシンイメージのスナップショット取得やスナップショットからの復旧ができないため、いくつかの運用上の制限が出てきます...これもIronicの課題の一つかなぁ...と思っています

今回は、このV2Pに対応したIronic用イメージファイルの基になる、仮想マシンディスクイメージファイルを作成する際の注意点について説明しています。

仮想マシンディスクイメージファイルの生成

前置きが長くなってしまいましたが、Ironic用カスタムイメージファイルの基になる、仮想マシンディスクイメージファイルの生成手順の説明に入ります。
今回の説明では、CentOS7の仮想マシンディスクイメージの作成手順を説明します。
FedoraなどRedHat系であれば、ほぼそのまま応用ができると思います。
Ubuntuなどについては...すみません...この例を参考にして調べてみてください。

KVMを使って仮想マシンディスクイメージファイル生成

それではまず最初に、Ironic用カスタムイメージファイルの基になる仮想マシンディスクイメージファイルを、ISOイメージから生成します。

まずは以下のコマンドを実行して、KVM仮想マシン上でCentOS7のインストーラを起動してOSをインストールします。
なお、OSの細かいインストールの説明などは省いています。また、ある程度KVMを使ったことがあることを前提とした説明になっています...

# qemu-img create -f qcow2 /var/lib/libvirt/images/centos7-custom.qcow2 10G

# virt-install --virt-type kvm --name centos7-custom --ram 1024 \
  --disk /var/lib/libvirt/images/centos7-custom.qcow2 \
  --network network=default \
  --graphics vnc,listen=0.0.0.0 --noautoconsole \
  --os-type=linux --os-variant=rhel7 \
  --location=/var/lib/libvirt/images/CentOS-7-x86_64-DVD-1511.iso

CnetOS7のISOファイルである、CentOS-7-x86_64-DVD-1511.isoはCnetOSのダウンロードページか、ミラーサイトからwgetなどでダウンロードし、/var/lib/libvirt/images/の下に配置してくださ。
virt-install実行後、仮想マシンが正常に起動すると、VNCクライアントから接続してGUIでインストールできるようになります。VNCクライアントには、UltraVNC Viewerなどを使ってください。(VNCクライアントから接続するためのポートNoは、5900から順番に払い出されます)

で、このインストール時に設定するディスク構成が最初のハマりどころになります。

【ハマりどころ その1】

インストーラでディスク構成を決める際、デフォルト構成のままでインストールすると、Ironic用イメージファイル変換に失敗してしまいます。

理由は、Ironic用イメージファイル変換に使用しているdisk-image-createコマンドの制限のためです。

この制限に引っかからないようにするため、ディスク構成は"/"の1パーティションのみとし、ファイルフォーマットはxfsとして生成し、そこにすべてをインストールするようにしてください。swapパーティションを切りたくなるかもしれませんが、swapパーティションもあると変換時に「swapファイルをマウントできません」という警告が出て変換に失敗します。

仮想マシンディスクイメージファイルからIronic用イメージファイルに変換する際、仮想マシンディスクイメージファイルを変換を行っているマシン上のディスクとしてマウントし、必要なファイルの抽出や変更を行っているのですが、デフォルトのLVM構成や、複数パーティションに分割されたイメージファイルをマウントすることができないため、1パーティションのxfsフォーマットのイメージファイルにする必要があります。

仮想マシンディスクイメージファイル固有の設定

OSインストールが完了したのち、ベアメタルサーバで動作させたいサービスのインストール、設定変更などを行って仮想マシンを構築します。

この際、OpenStackで必要となる、仮想マシンイメージ固有のパッケージインストールや設定変更を行います。

cloud-initのインストールと設定

まずはcloud-initのインストールと設定変更を行います。
cloud-initは、VMを生成する際に、VMのホスト名称やssh接続に使用する公開鍵ファイルの配置などを行うためのパッケージです。
OpenStackは、VM上のcloud-initからの要求を受け付け、ホスト名称設定や公開鍵の配置を行っています。

まずはcloud-initのインストール

# yum -y install cloud-init

インストール後、/etc/cloud/cloud.cfg という定義ファイルが生成されます。
通常は設定変更をする必要はないのですが、デフォルトユーザ名称が"centos"となっています。(CentOSの場合)
"centos"のままだと、なんというか違和感があるので、このデフォルトユーザ名称を変更します。
まず、viで/etc/cloud/cloud.cfgを編集します。

...

system_info:
  default_user:
    name: admin  <-- ここをcentosからadminに変更
    lock_passwd: true

...

この例では、元々"centos"となっていたnameを、"admin"に変更しています。
これで、このイメージから生成されたサーバにsshでログインする際、公開鍵を使って、ここで変更したデフォルトユーザ名称でログインすることができるようになります。

GRUB2定義変更

次はGRUB2の設定に、シリアルコンソール接続のための設定を追加します。
これは、仮想マシンに対してKVMのconsoleコマンドで接続したり、OpenStackが仮想マシンの起動時の出力をログに保存する際に使用しています。よって、ベアメタル向けの場合は必要ないと思われますが、念のため....

まず、viで /etc/default/grub に、コンソールの情報を設定します。

GRUB_CMDLINE_LINUX="console=tty0 crashkernel=auto console=ttyS0,115200"
↓
GRUB_CMDLINE_LINUX="vconsole.keymap=jp106 crashkernel=auto vconsole.font=latarchrheb-sun16 console=tty0 console=ttyS0,115200n8r"

GRUB_CMDLINE_LINUXの設定を、上のように変更します。

変更した後、grub2-mkconfigコマンドで、実際のGRUB2定義ファイルを変更します。

# grub2-mkconfig -o /boot/grub2/grub.cfg
zeroconfの無効化

最後に、以下のコマンドを実行してzeroconfを無効化します。

# echo "NOZEROCONF=yes" >> /etc/sysconfig/network

以上で、仮想マシンイメージファイル固有の設定が完了です。
あとは、各自が必要とするパッケージインストールや設定、systemctlでサービスを有効化するなどを行います。

上記が完了したら、shutdownで仮想マシンを終了させます。

Ironic用カスタムイメージ変換前の下準備

KVMで生成した仮想マシンのイメージファイルをIronic用カスタムイメージに変換するため、以下のコマンドを実行して、KVMから切り離すなどの準備を行います。

# virt-sysprep -d centos7-custom
# virsh undefine centos7-custom
# mkdir /root/image
# cp -p /var/lib/libvirt/images/centos7-custom.qcow2 /root/image/.
# cd /root/image

以上で、 仮想マシンディスクイメージファイルの作成は完了です。

次回は、この仮想マシンディスクイメージファイルから、Ironic用カスタムイメージの生成手順について説明します :-)

それではまた~~ :-)

補足事項

  1. Ironicのデプロイの仕組みには、大きく分けて、ddコマンドを使ってディスクイメージを転送するだけの単純なもの(pxe_ipmitool)と、デプロイ先のディスクパーティションをカスタマイズできるAgentを組み込んだもの(agent_ipmitool)の2種類がありますが、今回と次回で説明するイメージファイル作成手順は、ddコマンドでイメージを転送するデプロイ方式向けのイメージファイルの作成方法について説明しています。

Acroquest Technologyでは、キャリア採用を行っています。


  • 日頃勉強している成果を、AWSHadoop、Storm、NoSQL、Elasticsearch、SpringBoot、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
  • 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
  • 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
  • OSSの開発に携わりたい。

 
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
 
データ分析で国内に新規市場を生み出す新サービス開発者WANTED! - Acroquest Technology株式会社の新卒・インターンシップ - Wantedlywww.wantedly.com

Elasticsearchハンズオンセミナー 第2回

Elasticsearch Kibana Logstash

みなさん、こんにちは。

松村です。


3/18(金)にElasticsearchハンズオンの第2回を開催しました。

f:id:acro-engineer:20160318134628j:plain:w480


前回は先輩方が中心に行っていたセミナーですが、
なんと、2週間前に先輩からの突然の無茶ぶりにより、
急遽若手中心のセミナーに変更。


途中、予定していた講師が突然体調不良で、講師の交代が行われるなど、
直前までドタバタだったのですが、
先輩方のフォローもあり、何とか実施することができました。

参加者の皆様からは、

「無料のセミナーとは思えないほど充実した内容だった。」
「初めてElasticsearchに触れたが、非常にわかりやすかった。」

という声をいただくことができ、頑張った甲斐がありました。


今回から、追加した異常検知のデモも好評でしたよ!


というわけで、今回は、司会を行った私(松村)とハンズオンの講師を行った樋口の2人で、
ハンズオンの感想(裏話?)を書きたいと思います。

松村(司会)

いきなり、司会になったときには、焦りました。

社会人相手のセミナーなんて、開いたこともないし、
2週間しか準備期間もなかったわけですから。


さらに今回は、セミナーの内容を見直したり、
異常検知のデモを追加したりと、
前日まで準備が大変でしたが、
好評の声をもらえて、嬉しかった!

最高ですね!
打ち上げのお酒も美味しかったです


参加してくださる皆様の満足を挙げるため、
次のセミナーも頑張ります!

樋口(講師)

一週間前に、突然、講師を交代することになったときには、
どうなるかと思いましたが、
無事、終わることができてよかった!!


前回は受講者として参加したのですが、
学ぶ立場と、教える立場って、こんなに違うものかと。。。
#当たり前ですね(^^;


連日の猛特訓で、先輩がたくさん教えてくれたので、
助かりました♪


Elasticsearchハンズオンでは、Elasticsearchの使い方以外にも、

  • Elasticsearchを使った実事例の紹介
  • Elasticsearchを使ったデモ(今回は異常検知)
  • 最新のElasticsearch情報

f:id:acro-engineer:20160318175306j:plain:w480

など、参加者の皆様に満足していただけるよう、
充実した内容になっているので、
是非参加してください!

どんどん、良いセミナーにしていきますよ!

最後に

ハンズオン後には、Elasticsearchに関する情報交換が盛んに行われました。

Elasticsearchの使い方に対するイメージも参加者によって多種多様であり、
たくさんの質問が飛び交う界になったので、情報共有の場として有意義になったのではないかと思います。

今後も継続的に開催しますので、まだの方は是非、以下からお申し込みください。

www.acroquest.co.jp


Acroquest Technologyでは、キャリア採用を行っています。


  • 日頃勉強している成果を、AWSHadoop、Storm、NoSQL、Elasticsearch、SpringBoot、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
  • 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
  • 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
  • OSSの開発に携わりたい。

 
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
 
データ分析で国内に新規市場を生み出す新サービス開発者WANTED! - Acroquest Technology株式会社の新卒・インターンシップ - Wantedlywww.wantedly.com

Elasticsearchハンズオンを実施しました。 #elastichandson

Elasticsearch Kibana Logstash

こんにちは、fujiiです。

そろそろ花粉の季節ですね。
まだ寒さが残っているにも関わらず、すっかりマスクが手放せなくなってきました。


f:id:acro-engineer:20160307110306j:plain:w480

さて、話は変わりまして、
3/4(金)に、Elasticsearchハンズオンセミナー(無料)を実施しました。


Elasticsearchを触ったことがない人が半分以上参加しましたが、
Elasticsearch、Logstash、Kibanaを利用して、
Kibana上で集めたログデータを可視化し、分析を行ってもらいました。

f:id:acro-engineer:20160304171301j:plain:w480


参加者からは、

「無料で申し訳なくなるくらい素晴らしかったです。周りに宣伝します。」
「予備知識が無い状態で参加しましたが、とても充実で大変勉強になりました。」

というありがたい声もいただき、開催してよかったと思います。


セミナーでは、Elastic Stackを利用した、データ分析の初歩的な説明だけでなく、
Elasticsearchの導入事例の紹介や、最新情報の紹介も行っております。


今後も続けていく予定ですので、興味がある方は、以下からお申込みください。


Elasticsearchハンズオンセミナー| Acroquest Technology Co., Ltd



たくさんのご参加をお待ちしております。


よろしくお願いいたします。

Acroquest Technologyでは、キャリア採用を行っています。


  • 日頃勉強している成果を、AWSHadoop、Storm、NoSQL、Elasticsearch、SpringBoot、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
  • 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
  • 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
  • OSSの開発に携わりたい。

 
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
 
データ分析で国内に新規市場を生み出す新サービス開発者WANTED! - Acroquest Technology株式会社の新卒・インターンシップ - Wantedlywww.wantedly.com

性能改善10事例

Java ENdoSnipe

こんにちは、 @ です。

Acroquestでは、Elastic{ON}のような勉強会やカンファレンスに参加するだけでなく、社内向けの勉強会も開催しています。
新しい技術を調べて「使ってみた」的な発表をしたり、実際に開発の中で得られた知見を発表したり。
各自が得意分野で、様々なテーマで発表し、技術の研鑽を行っています。

私の場合、しばらく性能改善に取り組んでいたため、
その際に解決した問題からいくつか事例をフィードバックし、
性能問題を起こさないよう喚起しました。

www.slideshare.net

スライドでも書きましたが、特に大量に繰り返し実行される処理では、性能を意識した実装をしないと問題になりがちです。
問題があちこちに散らばると性能が大きく劣化し、解決も骨が折れます。
こういう問題は起こさないように、各チームメンバが気を付けて実装する必要があります。

ただ、もし、起きてしまった場合は、ENdoSnipeで解決するのがオススメです^^
www.endosnipe.com


それと、性能問題は解決が難しいケースもあります。
自力で解決できない場合は、JaTSサービスも是非ご利用ください!
jats.acroquest.co.jp

Acroquest Technologyでは、キャリア採用を行っています。


  • 日頃勉強している成果を、AWSHadoop、Storm、NoSQL、Elasticsearch、SpringBoot、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
  • 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
  • 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
  • OSSの開発に携わりたい。

 
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
 
データ分析で国内に新規市場を生み出す新サービス開発者WANTED! - Acroquest Technology株式会社の新卒・インターンシップ - Wantedlywww.wantedly.com

Elastic{ON} 2016レポート いよいよクロージング! #elasticon

Elasticsearch elasticon Kibana Beats

最終日の今日は、朝食もランチも特別なものでした。
会場の外に何台かのバンが来ていて、それぞれのバンで、サンドイッチ、ピザ、ブリトー、ワッフル、ドーナツ、クレープなどを提供されていました。そこから自分で好きなものを(もちろん無料で)頼むのです。
f:id:acro-engineer:20160220190800j:plain:w480


しかも、美味しいんですよね。
というかelstic{ON}で提供される食事はだいたい美味しいんです。

同じサンフランシスコで開催される、僕がよく行くあのJavaイベントとは天と地の開きがありました。

f:id:acro-engineer:20160220190924j:plain:w480


要するに、Elastic{ON}最高です。

How to Build Your Own Kibana Plug-ins

さて、今日参加したセッションの1本は、Kibanaプラグインの作り方。
Kibanaプラグインの開発に使うツールや情報などは、次のURLからアクセスすることができます。

Some resources that are helpful for creating kibana plugins · GitHub



boilerplateはハックを作る時に使えるひな形です。
Kibanaの全画面に対して、ホットキーを設定したり、見た目を少し修正するなどの加工ができます。

こんな感じのindex.jsが提供されています。

export default function (kibana) {
  return new kibana.Plugin({
    uiExports: {
      hacks: [
        'plugins/my_plugin/hack'
      ]
    }
  });
}

どうやらuiExportsのhacksというのが、全画面に対するハックを行うもののようですね。


またgenerator-kibana-pluginは、Yeomanを使ったKibanaプラグインのGeneratorです。
https://github.com/elastic/generator-kibana-plugin

これを使うとSenseやTimelionのような、Kibanaプラットフォームを利用した独自アプリのひな形を生成することができます。

index.jsはこんな雰囲気です。

var exampleRoute = require('./server/routes/example');
module.exports = function (kibana) {
  return new kibana.Plugin({

    name: 'ceroplugin',
    require: ['kibana', 'elasticsearch'],
    uiExports: {
      app: {
        title: 'Ceroplugin',
        description: 'Cero-t's Kibana plugin',
        main: 'plugins/myplugin/app'
      }
    },
// (以下略)

uiExportsのappを使うことで、アプリを作ることができるようです。
Kibanaのプラグインとハックとアプリの区別がよく分からなかったのですが、この辺りを見てようやく分かりました。


なお、Kibanaプラグイン(ハック、アプリ)のフレームワークやテンプレートなどは、今後も変更されやすい点には注意が必要です。
ただ、generator-kibana-pluginは、元々は開発者個人が作ったツールでしたが、
現在はelasticの公式Githubリポジトリに移動され、バージョンも1.0.1となっています。
(セッションを聞いていた時点では1.0.0だったのですが)

そのような状況を見ていると、そろそろプラグイン開発を始めても大丈夫なのかな、という気になりますね。

B-b-b-b-b-beats! How to Build Your Own

Beatsの作り方のセッション。
キャパが30〜40名ぐらいの小さなブースで行われたのですが、立ち見が続出、入れずに諦める人が多数という、大人気セッションでした。
f:id:acro-engineer:20160220191025j:plain:w480

僕自身、Beatsを作ったことがあるということを事前にスピーカーの人と話していたため、「最前列の彼はBeatsを作ったことがあるんだ」など簡単に紹介される嬉しいサプライズもありました。


さて、Beatsの作り方は、基本的にGeneratorを使うのが良いです。
https://github.com/elastic/beat-generator

beat-generatorはcookiecutterというテンプレートツールを使っているので、先にインストールしておく必要があります。
Generatorを起動して、ウィザードに従って名前などを決めれば、設定ファイルやGolangソースのひな形などが生成されます。

以前、beatの作り方をこのブログにも書きましたが、その時にはGeneratorは存在していませんでした。なのでいずれ改めて、作り方の紹介エントリーを書きたいと思います。とっても簡単ですよ。


なおセッション中には、beatの出力先として、Elasticsearch、Logstashに加えて、RedisとKafkaに対応することも紹介されました。この辺りの出力先も、徐々に増えていきそうですね。

そして、クロージングキーノート。

嵐のような3日間は、最後のクロージングキーノートをもって閉幕です。

クロージングキーノートは、elasticのCTOであるShay Banonと、CiscoのCTOであるLew Tuckerのパネルディスカッションや、
会場からの質問に答えるという形で進みました。
f:id:acro-engineer:20160220191149j:plain:w480


OSS企業のあり方や、ビジネスモデルの考え方、またMicroserviceの捉え方などに話は広がりました。
また会場からの質問では、CTOになったけどプログラミングしたくならないかとか、
5年後のElasticsearchの姿はどうなっているのか、など、割と自由奔放な質問が飛びだしていました。
っていうか正味、ちゃんと聞き取れるわけないじゃないですか!!

特にElasticsearchのメインターゲットとなっている「Splunk」に対してどう考えているのかという質問では、
単にSplunk対抗のものを作っているわけではないし、
もし対抗するなら必要なものをリストアップして一つずつ実装していくけど、そのような事はしていないと明言していました。

あくまでも、Elasticsearchを中核として使いやすいものを作るということに注力しているとのことでした。


そんな形でクロージングキーノートも絞まり、いよいよElastic{ON}は閉幕です。
f:id:acro-engineer:20160220191311j:plain:w480


ところで、
Elastic{ON}の来場者の出身地ですが、当然トップの2つはアメリカとカナダ、それを追ってイギリスとドイツ。そして5位はどこでしょう? という質問が投げかけられたのですが・・・もしかして、、、と思ったら、やはり「日本」でした。

昨年はスタッフ以外の来場者が1人もいなかった日本ですが、今年は日本からの来場者がたくさんいます。
もちろんこれは、須田さんをはじめとした日本のelasticスタッフの貢献があってこそだと思います。


Elastic{ON}のサプライズを含むテクニカルな発表や、AMAのような納得度の高いコンテンツ、
また美味しい食事、そして美味しい食事など、とっても良いイベントでした。

僕自身、来年も参加したいと思いますし、またこのブログを読んで一人でも参加したいと思った方がいらっしゃれば、
夜な夜なブログを書いた意義もあったのかなと思います。

elasticの社員、Elastic{ON}のスタッフはじめ、参加者も含めてイベント関わった皆さん、お疲れ様でした&ありがとうございました!!

Stay elastic, see you!

Elastic{ON} 2016レポート AMA = Ask Me Anything! #elasticon

Elasticsearch elasticon

いよいよElastic{ON}も3日目、最終日を迎えました。

今日はライブコーディング中心のプラグイン開発セッションや、
AMA (Ask Me Anything) と呼ばれる自由にQ&Aができるブースで1日を過ごしました。

まずはこのAMAについてレポートしたいと思います。

AMA = Ask Me Anything

もしかすると、AMAこそがElastic{ON}の一番の目玉なのかも知れません。
会場にたくさん来ているelastic社のエンジニアに、直接、様々な質問ができるというブースです。
f:id:acro-engineer:20160220185359p:plain:w575

Elasticスタックのプロダクトやロードマップについて質問するのはもちろんのこと、
最近困っている不具合を目の前で見せて解決を依頼したり、
Elasticsearchを利用した独自プロダクトのアーキテクチャの相談をしたり、
とにかく何でも自由に質問できます。

サブスクリプションを買ったりコンサル費用を払うよりも、
Elastic{ON}で直接聞いたほうが安い(笑)と言われるぐらいにオススメの高いコンテンツのようです。

ここで聞いたことを、簡単に紹介します。

1. Timelionのグラフを、Kibanaダッシュボードに載せられるようになるぞ

Timelionを使い込んでいる皆様方におかれましては、TimelionのグラフをKibanaのダッシュボードに配置できないものかなと思っているかと思います。
その点をKibanaの開発者であるRashid Khan(@)に聞いたところ、「近々対応するつもり、今週もそれを作ってるんだ」と回答してくれました。
わーい。

2. Beatsの設定や管理も、中央集約されるぞ

今回のElastic{ON}の中で、Logstash 5.0になれば、Logstashの設定やステータス情報を個別に扱うのではなく、
Elasticsearchに集約する(そして各Beatsに配信する)ということが明言されていました。

しかしBeatsでは、そのような設定やステータスの中央集約は明言されていませんでした。

その辺りどうなのよと、Beatsの開発者であるMonica Sarbu(@)に聞いたところ、
まだその開発をスタートしてないけど、対応する計画をしているとのことでした。
5.0には間に合わないけど、バージョン5.1ぐらいの時点で提供したいとのことです。
わーい。

3. Kafkaが入った時のアーキテクチャは?

BeatsシリーズからKafkaに出力できるようになることは、以前のエントリーにも書いた通りです。
また、Elasticsearch 5.0のIngest Nodeを使えば、Logstashの加工の機能が必要なくなることも、前に書きました。

現在の構成では、たとえばFilebeatを使って、Kafkaを挟むと次のような形になります。

Filebeat → Logstash(加工) → Kafka(キュー) → Logstash(転送) → Elasticsearch(保存)

これが、BeatsのKafka連携機能と、ElasticsearchのIngest Nodeを使うと、このような構成にできます。

Filebeat → Kafka(キュー) → Logstash(転送) → Elasticsearch(加工、保存)

ただこうなると、Logstashが何のために存在するのか分からなくなるので、削りたくなります。

Filebeat → Kafka(キュー) → Elasticsearch(加工、保存)

こんなことができるのか、Monica Sarbuにぶつけてみました。


まず結論としては、できない。
やはりKafkaからElasticsearchに直接転送するような方法が用意されていないため、転送のためにLogstashを挟むことは必須のようです。

また、ElasticsearchのIngest Nodeで加工することは確かに可能だが、
より細かい制御が必要になる場合は、Logstashを使う必要があるんじゃないかという見解でした。
なるほどですね。

いずれにせよ、この件はしっかりと話ができたので、僕の中でも腑に落ちた感じになりました。


それ以外にも、JMX経由で取った情報をBeatsと連携させるパターンの相談や、
実際に業務上で困っていることなど、ちょっとここでは書けないようなことも色々と質問、相談させてもらいました。

それにしても、いつもは壇上や動画、あるいはツイッターの向こう側にいるエンジニアの方たちと、
マンツーマンでディスカッションできる機会というのは本当に貴重ですよね。

つたない英語でも一生懸命に聞いてくださいますし、とっても捗りました!