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

Taste of Tech Topics

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

Elastic Stack 5.0.0-alpha4リリース。CSVインポート機能とKibanaのモニタリングがお目見え! #elasticsearch

Elasticsearch Kibana

最近めっきり暑くなりましたが、皆さんいかがお過ごしでしょうか。
なにげに日傘男子の @ です。


さて、先日、Elastic Stack 5.0.0-alpha4がリリースされました。
なかなか良いペースでalphaもバージョンが上がっていて、この調子ならβ版のリリースも近いんじゃないのかなと思います。

さて、今日はそのalpha-4の新機能を紹介します。

Elastic Stack 5.0.0-alpha4の新機能

まず簡単にalpha4の主な新機能を紹介します。

https://www.elastic.co/jp/blog/elastic-stack-release-5-0-0-alpha-4

  • ElasticsearchのJavaクライアントに、HTTP/REST(9200番ポートのほう)対応版が追加されました。
  • KibanaでCSVファイルのインポートができるようになりました。
  • Kibanaのモニタリングができるようになりました。
  • Logstashから取れるメトリック情報の種類が増えました。

という感じです。
このうちKibanaの新機能である「CSVインポート」と「モニタリング」を試してみます。

1. Elastic/Kibanaのインストール

前回のエントリーとほとんど同じですが、ElasticsearchとKibanaのインストール手順を紹介します。
BeatsとLogstashは使わないので、インストール手順は省略します。

今回もサーバはAWSAmazon Linux 2016.03、インスタンスサイズはt2.smallを使っています。


まずJava8(OpenJDK)とdstatをインストールします。

sudo yum update -y
sudo yum remove -y java-1.7.0-openjdk
sudo yum install -y java-1.8.0-openjdk-devel
sudo yum install -y java-1.8.0-openjdk-debuginfo --enablerepo=*debug*
sudo yum install -y dstat

この辺は僕の好みで入れているのでスキップしても構いません。


yumでインストールするため、RPMの公開鍵をインポートして、リポジトリの定義を作成します。

sudo rpm --import https://packages.elastic.co/GPG-KEY-elasticsearch
sudo vi /etc/yum.repos.d/elastic.repo

elastic.repo

[elasticsearch-5.x]
name=Elasticsearch repository for 5.x packages
baseurl=https://packages.elastic.co/elasticsearch/5.x/centos
gpgcheck=1
gpgkey=https://packages.elastic.co/GPG-KEY-elasticsearch
enabled=1

[kibana-5.x]
name=Kibana repository for 5.x packages
baseurl=http://packages.elastic.co/kibana/5.0.0-alpha/centos
gpgcheck=1
gpgkey=http://packages.elastic.co/GPG-KEY-elasticsearch
enabled=1

[logstash-5.x]
name=Logstash repository for 5.x packages
baseurl=http://packages.elastic.co/logstash/5.0/centos
gpgcheck=1
gpgkey=http://packages.elastic.co/GPG-KEY-elasticsearch
enabled=1

勢いあまってLogstashの設定までしてしまっています。なおBeats 5.0系のリポジトリは、まだ用意されてなさそうです。


yumコマンドでElaticsearchとKibanaをインストールし、自動起動の設定をして、起動します。

sudo yum install -y elasticsearch
sudo yum install -y kibana

sudo chkconfig --add elasticsearch
sudo chkconfig --add kibana

sudo service elasticsearch start
sudo service kibana start

これでインストールは完了です。
ブラウザで http://(サーバのアドレス):5601/ にアクセスして、Kibanaの画面が出たら成功です。


画面遷移時に「Index Patterns: Please specify a default index pattern」というエラーメッセージが出るので、とりあえず「.kibana」をデフォルトindexにすることで警告はなくなります。
f:id:acro-engineer:20160603192241p:plain:w800


ところでKibana 5.0.0-alpha4では、なぜかログが /var/log/kibana に出力されなくなっています。

たぶんこのチケットで、
https://github.com/elastic/kibana/issues/7590

パッチもすでにマージ済みなので、
https://github.com/elastic/kibana/pull/7593/files

次のバージョンでは直るんじゃないかと思います。


これでElasticsearchとKibanaのセットアップは完了です。

2. CSVインポート機能を試す

CSVインポート機能はElasticsearchとKibanaさえセットアップすれば、特に追加のプラグインなどを入れずに利用することができます。
今回は、横浜市の5年間の気象データをCSV形式にしたものをインポートしたいと思います。

気象データは、気象庁のサイトからダウンロードしました。
http://www.data.jma.go.jp/obd/stats/etrn/index.php

ただ利用にあたり少し加工したので、加工後のCSVファイルもこちらに置いておきました。せろ忍者。
http://www.cero.ninja/t3blog/weather.csv


ではCSVインポート機能を試してみましょう。Kibanaの左メニューから「Management」を選択します。
f:id:acro-engineer:20160712104535p:plain:w800
Connect Dataに「Upload CSV」というメニューがあるため、これを選択します。

そうすると、CSVのアップロード画面が開きます。
f:id:acro-engineer:20160712104622p:plain:w800
ここでCSVファイルをドラッグ&ドロップします。

それだけでサッとCSVの中身が認識されました。
f:id:acro-engineer:20160712104643p:plain:w800


なおここでアップロードするCSVファイルですが、1行目が見出しになっていること、また日付はyyyy-MM-dd形式となっている必要があるようです。たとえばこんな感じ。

year-month-day,rain,max_temperature,min_temperature,daylight_hours,snow_depth,snow_ammount
2011-05-12,20.5,16.2,14.1,0.0,0,0
2011-05-13,0,24.0,16.1,5.4,0,0
2011-05-14,0,25.3,15.5,11.1,0,0

恐らくもう少し先のバージョンでは、Ingest Nodeの加工機能と連携して、CSVを加工するような機能も提供されるのではと思いますが、今のところは先にCSVファイルを修正しておく必要があります。


さて、CSVファイルが上手く読み込めたら「Next」を押して次の画面へ。
ここではindex名の指定や、それぞれのフィールドの型を選択します。
f:id:acro-engineer:20160712105630p:plain:w800
今回は日付を利用したtime-basedのデータで、日付以外のデータは全て数値なので、このまま読み込みます。

「SAVE」を押して読み込みを行ない、数秒待つと読み込みが成功したメッセージが表示されました。
f:id:acro-engineer:20160712105751p:plain:w800
1828行のCSVデータが読み込まれたようです。


discoverでindexを開き、期間を「Last 5 years」を指定すればデータが投入されたことを確認できます。
f:id:acro-engineer:20160712105859p:plain:w800
※若干、表示範囲とデータの範囲がズレているので件数が1766件(投入は1828件)になっていますが、まぁまぁ気になさらず。


もちろん、投入したデータを使ってグラフを作ることもできます。
f:id:acro-engineer:20160712110419p:plain:w800
簡単でしょう?


このCSVインポート機能のおかげで、Logstashの設定を書くことなく、データ投入を試せるようになりました。
これはちょっとElasticsearchを活用する人が増えそうな新機能じゃないですか?

3. X-Packの導入

次にKibanaのモニタリングを試してみます。
モニタリングを行なうためには、X-Packというプラグインセットをインストールする必要があります。
本来X-Packは商用ライセンスを購入しなくては使えないプラグインなのですが、alpha版である現在では自由に使うことができます。


X-Packをインストールする前に、Elasticsearch/Kibanaを止めておきます。

sudo service kibana stop
sudo service elasticsearch stop


elasticsearch-pluginコマンドで、ElasticsearchにX-Packプラグインをインストールします。

cd /usr/share/elasticsearch/
sudo bin/elasticsearch-plugin install x-pack

途中で一回質問が出ますが、力強く「y」を押して頂いて差し支えありません。


続いて、kibana-pluginコマンドでKibanaにX-Packプラグインをインストールします。
不安になるぐらいインストールに時間が掛かりますが、数分ぐらい待てばインストールが完了します。

cd /usr/share/kibana
sudo bin/kibana-plugin install x-pack

これでX-Packのインストールは完了しました。
以前は(というか現在は)MarvelやらShieldやらをアチコチにインストールしなくてはいけなかったのが、このインストールだけで済むのは楽ですね。

サービスを起動しましょう。

sudo service elasticsearch start
sudo service kibana start

そしてKibanaにアクセスすると・・・認証画面が表示されました。
これはSecurity(旧Shield)のプラグインが効いているためです。
f:id:acro-engineer:20160712112341p:plain:w800
特に何もアカウントを変更してない場合、ユーザー名「elastic」で、パスワード「changeme」でログインができます。

ログイン後すると、左メニューの項目が増えていたり、左下にユーザボタンやログアウトボタンが増えていることが分かります。
新機能のモニタリングを試すには、増えたメニューから「Monitoring」を選択します。
f:id:acro-engineer:20160712112635p:plain:w800
Monitoringの画面に、Elasticsearchだけでなく、Kibanaも出ています。

ここで右側のKibanaの「Instances: 1」のリンクをクリックすると、詳細なデータが確認できます。
f:id:acro-engineer:20160712113223p:plain:w800
ロードアベレージやメモリ消費量、リクエスト数などの基本的なリソース情報がグラフで確認できました。これでKibanaで異常が起きる前に予兆を掴んだり、あるいは問題が起きた時に(情報はElasticsearchに残っているため)後から問題をトレースすることもできるでしょう。

いずれは、ここにLogstashやBeatsシリーズも並ぶことになるでしょうね!

まとめ

  • Elasticsearch 5.0.0-alpha4は今すぐ試せるぞ。βもそう遠くない?
  • CSVインポート機能のおかげで設定レスでElasticsearchへのデータ投入ができるようになりました。
  • Kibanaをモニタリングできるようになりました。LogstashとBeatsも所望する!


次はGraphなんかを試してみたいですね。
それでは皆さん、日焼けなどしすぎないように、See you!

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


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

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

Trema Day #9でLTしてきました :-)

SDN OpenFlow

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

先日(7/2)に行われたTrema Day #9で、LTしてきました。
trema.connpass.com
Trema Dayは、SDNやOpenFlowなど、ネットワーク周りの濃い人たちが集まる勉強会だったりします。
そんなTrema Dayで、最近のプロジェクトの中で、ハードウェアOpenFlowスイッチを使った際にハマった事例をLTで話してきました。

www.slideshare.net

スライドでは、ハードウェアスイッチ固有の仕組みによるOpenFlow1.3の仕様とのギャップなど、実際に使ってみて初めて分かる問題点について書いています。

今回のTrema Dayでは、Tremaを使った物理ネットワークの自動試験の取り組みや、CPUコアの配置まで考慮したLagopusの使い方など、かなり濃い内容のものばかりでした :-)
また機会があれば、Trema Dayに参加してみようと思います。

それでは :-)

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


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

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

Elastic Stack 5.0 alpha 3で、いよいよ登場Metricbeat! #elasticsearch

Elasticsearch Kibana Logstash Beats

Hello world, @ です。

突然ですが、SpringOneのスピーカーになることが決まりました!
SpringOneは、毎年行われるSpring界隈で最大のイベントです。今年8月にラスベガスで開催されます。
springoneplatform.io

発表内容は、Elasticsearchを用いたSpring Bootアプリケーション(というかマイクロサービス)の可視化です。
Schedule: Let's Visualize Your Spring Boot Applications - SpringOne Platform

どういう内容になるか、ご期待ください! 要するに、まだちゃんと考えていません!


さて、そんな前振りをしつつ、今日はElastic Stack 5.0のalpha版のお話です。
Elasticsearch / Kibana / Logstash / BeatsのElasticスタックは、次のリリース時にバージョンが「5.0」で統一されます。
先日、そのalpha 3がリリースされたため、これをインストールして試してみます。

Elastic Stack 5.0 alphaの特徴

これまでこのブログでは、Elastic Stack 5.0 alphaについて話題にしてこなかったため(更新サボっててすみません!)、簡単に各バージョンの見どころを書いておきます。

alpha 1

https://www.elastic.co/jp/blog/elastic-stack-release-5-0-0-alpha-1

  • 5.0 alpha 最初のリリース。
  • ElasticsearchのIngest Node(Logstashのfilterのような文字列加工機能)が使えるようになりました。
  • Kibanaが新しいデザインになりました。
  • Logstashのメトリクス情報を取得できるようになりました。
  • Beatsから直接Kafkaに出力できるようになりました。
alpha 2

https://www.elastic.co/jp/blog/elastic-stack-release-5-0-0-alpha-2

  • ElasticsearchとLogstashがIPv6アドレスを扱えるようになりました。
  • Kibanaにsenseが標準搭載されました。
alpha 3

https://www.elastic.co/jp/blog/elastic-stack-release-5-0-0-alpha-3

  • Beatsシリーズに「Metricbeat」が追加されました。
  • Kibana + X-Packに、ユーザ管理画面が追加されました。
  • Logstashにプラグインジェネレータが搭載されました。


という感じです。
基本的には、alpha版はお試しという位置づけなので、最新のものを使っていれば良いと思います。

1. 前準備

それでは、インストールを行ないましょう。
今回はAWSで、Amazon Linux 2016.03のt2.smallで試しました。

まずは前準備として、Java8(OpenJDK)とdstatをインストールします。
この辺りは僕の好みなのでスキップしても構いませんが、Javaで問題があった時に解析できるようにopenjdk-develとopenjdk-debuginfoを入れることと、リソースの確認ツールとしてdstatを入れることを、いつもやっています。

sudo yum update -y
sudo yum remove -y java-1.7.0-openjdk
sudo yum install -y java-1.8.0-openjdk-devel
sudo yum install -y java-1.8.0-openjdk-debuginfo --enablerepo=*debug*
sudo yum install -y dstat

これで準備は完了です。

2. ElasticsearchとKibanaをyumでインストール

Amazon LinuxCentOS/RHEL)にElasticスタックをインストールする方法は3つあります。

  1. アーカイブをダウンロードして解凍する
  2. rpmをダウンロードしてインストールする
  3. yumコマンドでインストールする

運用のしやすさを考えれば2か3がよく、特に3のyumでインストールをしておけば、アップデートの際にもyum updateで済むので、今回はそれでインストールします。

まずはRPMの公開鍵のインポートと、リポジトリの定義作成です。

sudo rpm --import https://packages.elastic.co/GPG-KEY-elasticsearch
sudo vi /etc/yum.repos.d/elastic.repo

elastic.repo

[elasticsearch-5.x]
name=Elasticsearch repository for 5.x packages
baseurl=https://packages.elastic.co/elasticsearch/5.x/centos
gpgcheck=1
gpgkey=https://packages.elastic.co/GPG-KEY-elasticsearch
enabled=1

[kibana-5.x]
name=Kibana repository for 5.x packages
baseurl=http://packages.elastic.co/kibana/5.0.0-alpha/centos
gpgcheck=1
gpgkey=http://packages.elastic.co/GPG-KEY-elasticsearch
enabled=1

[logstash-5.x]
name=Logstash repository for 5.x packages
baseurl=http://packages.elastic.co/logstash/5.0/centos
gpgcheck=1
gpgkey=http://packages.elastic.co/GPG-KEY-elasticsearch
enabled=1

なおBeatsだけは5.0系のリポジトリが見つからなかったため、yumインストールを諦めました。

ElaticsearchとKibanaをインストールして、自動起動の設定をしておきます。

sudo yum install -y elasticsearch
sudo yum install -y kibana

sudo chkconfig --add elasticsearch
sudo chkconfig --add kibana

ちなみにElasticsearch 5.0 alpha 2では、依存モジュールの問題で、Amazon Linux上でyumインストールしようとすると失敗する問題がありましたが、alpha 3では修正されています。

インストールが終わったら、ElasticsearchとKibanaのサービスを立ち上げます。

sudo service elasticsearch start
sudo service kibana start

このあとブラウザで http://(サーバのアドレス):5601/ にアクセスして、Kibanaの画面が出たら成功です。
f:id:acro-engineer:20160603190541p:plain:w800
雰囲気がちょっと変わりましたね!


ちなみに、ここで他の画面を表示しようとすると「Index Patterns: Please specify a default index pattern」というエラーメッセージが表示されます。デフォルトのindexが指定されていないというエラーです。
何のためのエラーなのか、僕もいまひとつ理解していないのですが(←ちゃんとしろ!)とりあえずサイズの小さい「.kibana」をデフォルトindexにすることにしています。
f:id:acro-engineer:20160603192241p:plain:w800
これで設定しておけば、エラーは起きなくなります。

3. Beatsを使ってリソース情報を可視化

続いて、Beatsをセットアップをします。
Beatsの5.0 alpha 3では目玉機能として、Metricbeatが追加されました。
www.elastic.co

MetricbeatはApache、nginx、MySQL、Redisなどのサーバ状態を収集してElasticsearchに転送するものです。それに伴ってTopbeatが廃止され、Topbeat相当の機能がMetricbeatに移植されました。


今回は、このMetricbeatとPacketbeatをインストールして、リソース情報を可視化します。
先にも書きましたがBeatsはyumでインストールできないため、rpmパッケージをダウンロードしてインストールします。

curl -L -O https://download.elastic.co/beats/metricbeat/metricbeat-5.0.0-alpha3-x86_64.rpm
sudo rpm -vi metricbeat-5.0.0-alpha3-x86_64.rpm
sudo chkconfig --add metricbeat

curl -L -O https://download.elastic.co/beats/packetbeat/packetbeat-5.0.0-alpha3-x86_64.rpm
sudo rpm -vi packetbeat-5.0.0-alpha3-x86_64.rpm
sudo chkconfig --add packetbeat

まずはMetricbeatでTopbeat相当の情報だけを取得するようにします。
デフォルトの設定のままでも動作するのですが、せっかくなので標準でOFFにされている情報も取得するようにします。

sudo vi /etc/metricbeat/metricbeat.yml

metricbeat.ymlの -core と -diskio と -fsstat がコメントアウトされているので、それぞれアンコメントします。

metricbeatのサービスを起動します。

sudo service metricbeat start

これでElasticsearchに情報が流れ始めます。

Elasticsearchに正しく情報が入っているかどうかはElasticsearchの /_cat/indices にアクセスして確認します。

curl localhost:9200/_cat/indices

次のようにMetricbeatのindexができていれば、Elasticsearchへの転送は成功です。

yellow open metricbeat-2016.06.03 5 1 89 0 19.2kb 19.2kb
yellow open .kibana 1 1 2 0 3.8kb 3.8kb


またElastic Stack 5.0から、Beatsのダッシュボードを作成するためのスクリプトが、各Beatsのkibanaフォルダに置かれるようになりました。rpmでインストールした場合は /usr/share/(Beats名)/ がインストールフォルダとなります。ここにある import_dashboards.sh を実行すると、ダッシュボードが作成できます。
これを使って、Metricbeatのダッシュボードを作成しましょう。

cd /usr/share/metricbeat/kibana
sudo ./import_dashboards.sh

これでMetricbeatのダッシュボードが、Kibanaに作成されました。
Kibanaにアクセスして、左メニューからダッシュボードを開き、上部のメニューの「Open」から「Metricbeat System Statistics」を開くと、収集した情報が表示されます。
f:id:acro-engineer:20160603192721p:plain:w800
こんな感じのダッシュボードが数分でできるのは、本当にお手軽でいいですよね。


ついでに、Packetbeatも同じように設定しておきましょう。Packetbeatはネットワークインタフェースに流れるパケットをキャプチャして、アクセスを解析するツールです。ApacheやnginxなどのHTTPや、MySQLPostgreSQL、MongoDBなどのパケットに対応しています。

このPacketbeatを使って、ElasticsearchとKibanaに対するHTTPアクセスを収集します。
設定ファイルを書き換えて、HTTPに使うポート番号を指定します。

sudo vi /etc/packetbeat/packetbeat.yml

packetbeat.yml

packetbeat.protocols.http:
  ports: [5601, 9200]

5601と9200が、それぞれKibanaとElasticsearchのHTTP待ち受けポート番号です。


Packetbeatのサービスを起動して、またダッシュボードもMetricbeatと同じように作成しておきます。

sudo service packetbeat start

cd /usr/share/packetbeat/kibana
sudo ./import_dashboards.sh

これでPacketbeatのダッシュボードができました。
「Packetbeat HTTP」というダッシュボードを開くと、HTTPアクセス記録を確認できます。
f:id:acro-engineer:20160603193916p:plain:w800
特にアクセスログ解析をしたわけでもなく、パケットに流れる情報だけでこのようなダッシュボードを作れるのは、ホント便利ですね。

4. Logstashでログ情報の収集

せっかくなので、Logstash 5.0 alphaも試してみましょう。Logstashを使ってKibanaのアクセスログを収集します。

インストールはyumコマンドで行ないます。

sudo yum install -y logstash

Logstashは5.0 alpha 3から /etc/init/logstash.conf に自動起動設定が置かれるため、chkconfigを行なわなくとも自動起動されるようになります。

設定ファイルを修正して、Kibanaのログファイル(JSON形式)を読み込んで、Elasticsearchに転送するようにします。

sudo vi /etc/logstash/conf.d/kibana.conf

kibana.conf

input {
  file {
    codec => "json"
    path => "/var/log/kibana/kibana.stdout"
    start_position => "beginning"
    sincedb_path => "/var/log/logstash/since_kibana"
  }
}

output {
  elasticsearch {
    index => "kibana_access-%{+YYYY.MM.dd}"
    document_type => "%{type}"
  }
}

書式などはこれまでと変わっていません。

serviceコマンドではなく、initctlコマンドを用いてLogstashを起動します。

sudo initctl start logstash

こういう仕組み(Upstart)を知らなかったので、若干、戸惑いました。

LogstashからElasticsearchに正しく情報が入っていることを、index一覧を見て確認します。

curl localhost:9200/_cat/indices

次のようにkibana_access-yyyy.MM.ddというファイルが出来ていれば成功です。

yellow open .kibana 1 1 100 1 166.6kb 166.6kb
yellow open packetbeat-2016.06.03 5 1 20384 0 7.2mb 7.2mb
yellow open metricbeat-2016.06.03 5 1 20126 0 5.9mb 5.9mb
yellow open kibana_access-2016.06.03 5 1 324 0 496.9kb 496.9kb

あとはKibana上でindex定義をしたり、ダッシュボードを作成すれば良いのですが、手順は割愛します。

まとめ

  • Elasticスタック 5.0 alphaも、yumでインストールできます。
  • Beats 5.0 alpha 3でMetricbeatが追加され、Topbeatはなくなりました。
  • 各Beatsのフォルダ内にある「kibana」フォルダのスクリプトを使ってダッシュボードが作れます。
  • Logstash 5.0 alpha 3はUpstartで起動するため、若干、起動の仕方が変わりました。


紹介しきれなかった5.0の新機能や、X-Packなんかは、また改めて紹介したいと思います。

それではまた、
See you!

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


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

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

Java Day Tokyoでマイクロサービスとかの話をしてきました #JavaDayTokyo

Java Microservices

Hello world, タニモトです!
っていうと、誰か分からない感じになりますが @ です!

なんだか怒濤のようにJavaな日々が過ぎていきました。
5/21(土)のJJUG CCCではイベントスタッフをこなしながら、後輩たちによるElasticsearchハンズオンを見守り、とにかく忙しくしていたら1日が過ぎ去っていきました。CCCの参加者は800人越えですってよ😳

そして、5/24(火)のJava Day Tokyoでは、自分自身の発表と、また英語でインタビューを受けるという貴重な機会をいただき、こちらも準備でバタバタしていたら、あっという間にイベントが終わっていました!😷
Java Day Tokyoは、1300人を越える参加があったそうです!

これらのイベントに参加してくださった皆様、ありがとうございます。
日本のJavaコミュニティが少しでも盛り上がるよう力を尽くしている中で、このような大きなイベントが運営されたこと自体、JJUG幹事の一人として嬉しく思っています。・・・ぐらいの真面目なコメントも、たまにはしないとね😆

NightHackingの英語インタビューで好き放題!

さて、Java Day Tokyoでは、2つ、お話してきました。

一つ目が、NightHackingの英語インタビューです。
NightHackingは、Oracle社のStephen Chinさんが中心になって世界中のJavaコミュニティやJavaイベントを巡り、現地のJavaエンジニアにインタビューをするというものです。今回のJava Day Tokyoのタイミングでも、何組かのインタビューが行われました。

昨年に引き続き、僕もインタビューの機会を得たので、好きなことを好きなだけ話してきました。
www.youtube.com

なんかもうプレビューからしてアレですが、BABYMETALと、格ゲーのマクロと、マイクロサービスについて話しました。
好きなことを好きなだけにも程があるって感じですね!

マイクロサービス開発の追体験をしてもらいたい!

もう一つは、マイクロサービスについてのセッションです。
今回は、マイクロサービスについて、とにかく「僕自身がやったこと」を中心にお話をしました。
speakerdeck.com

マイクロサービスに関する情報って、理論的なものや概念的なもの、あるいは原理主義的な説明や、教科書的な説明が多い印象で、なかなか実際的なところが話されていないように感じています。
また、世の中で謳われているマイクロサービスの構成要素についても、組織にフィットするよう取捨選択やカスタマイズなども行うべきですが、やはりその辺りもあまり情報はありません。

そんな状況でしたので、僕自身が辿ったマイクロサービス開発の経験を、皆さんにも追体験して頂ければと思って話しました。

もし可能だったら、セッション後にマイクロサービスについてのディスカッションなどできれば良かったかも知れませんね。また別の機会に、どこかでやりましょう!

商用障害!?

ところで、セッション中に「商用障害」という言葉を使ったのですが、終わったあとに知人から「あれはどういう意味だったの?」という質問を受けました。どうやらこれ、一般用語ではなかったみたいですね。

商用環境で起きる障害だから、商用障害・・・なんですが、そもそも商用環境という言葉すら、一般用語でない様子。

圧倒的に「本番環境」という言葉が一般的なようです。
商用環境というのは、どうもテレコム系でよく使われる用語のようですね・・・?


なんて、いずれにせよ、何かと学びの多い数日間でした。
次は半年後、JJUG CCC Fallでお待ちしています!

f:id:acro-engineer:20160526011929j:plain:w640

それではまた、
See you!

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


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

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

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

クラウド基盤 OpenStack

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

GWはどのように過ごされたでしょうか?
私は1年ぶりに自転車で、鎌倉までポタリング(往復で70kmぐらい)してました :-)

今回は、前回のOpenStack Ironic用のカスタムイメージファイルを作る【導入編】 - Taste of Tech Topicsの続き、Ironic用イメージファイルの生成手順について説明します。

イメージファイル作成ツールのインストール

まずはイメージファイル作成ツールを、以下のコマンドを実行してインストールします。

# pip install diskimage-builder

このDiskimage-builderは、OpenStackのVM用イメージファイルなどのディスクイメージを生成するツールです。
このツールには、Ironicイメージを生成するための機能も含まれていて、今回はこのDiskimage-builderを使います。

デプロイ用イメージファイルの生成

次に、以下のコマンドを実行してデプロイ用イメージファイルを生成します。

# mkdir /root/image
# cd /root/image
# ramdisk-image-create ubuntu deploy-ironic -o deploy-image

ここでは、デプロイ用イメージファイルの基になるOSイメージとしてUbuntuを指定しています。
デプロイ用イメージファイルは、初期のデプロイ処理を行うためのイメージでしかないため、仮想マシンイメージファイルのOSと合わせる必要はありません。

※この例では前回の例と同様に"/root/image"の下でイメージファイル作成を行っています。あくまでも今回の説明用に作っているだけなので、実際には適当に作業領域を作ってください。

ramdisk-image-create を実行した後、"/root/image"の下に以下の2つのファイルが生成されます。

deploy-image.kernel
deploy-image.initramfs

deploy-image.kernelは、デプロイ処理の際に使用するカーネルイメージファイルで、deploy-image.initramfsは、デプロイ処理のブートイメージで、インストールするための準備と、準備完了をIronicに通知する処理を行うイメージファイルになります。
この2ファイルがPXEBootによって物理サーバマシンに読み込まれることで、カスタムイメージファイルをインストールするための準備を行います。*1

Ironic用イメージファイルに変換

ここから、disk-image-createコマンドを使って、前回作成したオリジナルの仮想マシンのイメージファイル(/var/lib/libvirt/images/centos7-custom.qcow2)からIronic用イメージファイルに変換する手順の説明になります..

が、ここでいきなりハマりどころが...

【ハマりどころ】

disk-image-createは引数で変換元イメージファイルを設定できない

変換元イメージファイルを指定する方法を示すマニュアルやそれらしい資料が見つからなかったので、仕方ないのでソースを読みました... :-(
disk-image-createは、elementsという単位で機能を追加する仕組みをもっているのですが、このelementsに定義を引数で渡す手段がないようで、環境変数でカスタマイズしたい定義を渡すようになっていました...(というより、そうせざるをえない構造な気がする)

で、オリジナルの仮想マシンイメージファイルからIronic用イメージファイルに変換する場合、環境変数"DIB_LOCAL_IMAGE" に、変換元になるイメージファイルをフルパスで指定します。

# export DIB_LOCAL_IMAGE=/root/image/centos7-custom.qcow2

ちなみに、DIB_LOCAL_IMAGEを設定しないでdisk-image-createコマンドを実行すると、変換元のイメージファイルは、CentOSやFerora、Ubuntuが公開しているクラウドイメージファイル(仮想マシン用イメージファイル)からダウンロードしてきます。

あぁ~~ これでオリジナルイメージができると思って実行したところ、変換に失敗...
蓋を開けてみると、disk-image-createは作業用ディスク領域にtmpfs(RAMディスク)を使っていて、変換対象のイメージサイズが大きいため容量不足でエラーになっていました...
※元々VM程度のディスクイメージサイズのファイルしか作ることを想定していなかったのでしょう...

調べた結果、環境変数 "DIB_NO_TMPFS"に 1 を設定することで、/tmp 配下を作業領域にするようになることがわかりました。

【注意】
環境によっては、"/"パーティションのディスクサイズが小さい(50Gbyteとか)ため、/tmp の容量不足でエラーになることがあります。
よって、"/"パーティションのディスクサイズについては、"/home"を減らして、"/"の容量を増やすなどの対処が必要になることがあります...

最終的に、以下のコマンドを実行することでIronic用イメージファイルに変換することができるようになります。

# export DIB_LOCAL_IMAGE=/root/image/centos7-custom.qcow2
# export DIB_NO_TMPFS=1

# disk-image-create centos7 baremetal dhcp-all-interfaces grub2 -o centos7-custom-image -a amd64

disk-image-create の -o で指定している"centos7-custom-image"の名称で、Ironic用イメージファイルが生成されます。

上記コマンドを実行すると、オリジナルの仮想マシンイメージファイルをマウントしたり、必要なパッケージをインストールしたりという処理を実行する経過が表示され、20分後ぐらいに、以下の3つのイメージファイルが生成されます。

centos7-custom-image.vmlinuz
centos7-custom-image.initrd
centos7-custom-image.qcow2

centos7-custom-image.vmlinuzカーネルのイメージファイル、centos7-custom-image.initrdはブート時に実行されるinitrdのイメージファイル、centos7-custom-image.qcow2はディスクイメージファイルになります。
デプロイされると、centos7-custom-image.qcow2のディスクイメージが、デプロイ先の物理サーバマシンのディスクに、ddコマンドによって書き込まれます。
centos7-custom-image.vmlinuzcentos7-custom-image.initrdは、PXEBootによって物理サーバマシンに送り込まれて実行されます。

以上で、 Ironic用カスタムイメージファイルの生成は完了です。
生成した上記イメージファイルや、デプロイ用イメージファイルはGlanceに登録して、NovaからIronic経由でベアメタルノードのデプロイ時に、使用するイメージとして指定することになります。

4月の25~29にOpenStack Summit Austinが開催されて、次のバージョンはNeutonに決まりました。
AT&T(とMirantis)の事例が注目されていたようで、NFVへのOpenStack適用が進むようです :-)

補足事項

  1. 今回の手順で作成したイメージファイルでAHCIモードのサーバマシンにデプロイを行った場合、デプロイに失敗します。これは、今回の手順で作成したイメージの/boot配下のinitrd用ファイルがAHCI対応していないことが原因です。このためAHCI対応のサーバマシンに対してデプロイを行うと、ブート時のinitrdでディスクデバイスが認識できずに失敗します。これに対応するためには、Ironic用イメージファイル生成時に生成されたinitrdイメージファイルをマウントして、AHCI対応のためのカーネルドライバのインストールなどを行う必要があります。

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


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

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

*1:このPXEBootのために使用するDHCPサービスには、Neutronのサブネット管理の持つ、ネットワークのIPアドレス払い出しの仕組みが流用されています。

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