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

Taste of Tech Topics

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

Elastic Stack 5.0.0-alpha5がリリース。そろそろGraphを試してみる #elasticsearch

Elasticsearch Kibana

Pokemon Goトレーナーの @ です。
今月頭にラスベガスのモンテカルロに宿泊したところ、ニャースマンキー、ガーディの巣になっていて、アメを100個以上ためることができました!

そんなPokemon Goとは関係ないですが、Elasticsearch Go の alpha Goがリリースされました! Go! Go! 5! 5!

・・・はい、ちょっと無理ありましたね。知ってます。


Elastic Stack 5.0.0-alpha5の新機能は、Elasticのブログエントリーを参照してください。
https://www.elastic.co/jp/blog/elastic-stack-release-5-0-0-alpha-5

私としては、Beatsのテンプレート読み込み機能の辺りがちょっと注目ポイントでした。


さて、alpha5の話題はこれぐらいにして、今日の主なテーマは「Graph」です。
日本語で「グラフ」と言うと、Kibanaでも作れる棒グラフや折れ線グラフのイメージになりますが、それらは英語圏では「Chart」と呼ばれることが多いです。
一方「Graph」と言えば、点(ノード)を線(エッジ)で繋いで関連を表す図のことになります。日本語だと「グラフ理論のほうのグラフ」と言ったりするやつですね。
言ったりしますよね?

Elasticsearchにも、バージョン2.3と5.0にこの機能が追加されたので、今回は5.0.0-alpha5で試したいと思います。
alpha版のうちは、このGraph機能を制限なく使うことができます。

そもそもGraphって?

ElasticsearchのGraph機能は、データ「関連」を示すものなのですが、そもそも、関連というのはどういう事なのでしょうか?
Elasticsearchの公式サイトにあるGraphは、このような図になっています。

f:id:acro-engineer:20160819114148j:plain:w800
(公式サイトの画像より)


これは好きなアーティストのアンケートを図示したもので、ここではカナダの人が好きなアーティストと、ブラジルの人が好きなアーティストを図示しています。線が太いアーティストほど、出現数が多い(人気が高い)と言えます。また、図中の「metric」や「our lady peace」などは、両方の国の人が好きである、ということが分かります。

これがデータの関連です。ElasticsearchのGraph機能は、このような複数項目の関連を図示できます。この場合は「(アンケートに回答した人の)出身国」と「好きなアーティスト」の関連を示しています。


ところで、図の左のほうにある「mattew good band」と「matthew good」にも線が引かれています。アンケートでは好きなアーティストは複数回答が可能であったため、このように「好きなアーティスト」同士にも関連があるわけです。平たく言えば「このアーティストが好きな人は、このアーティストも好きです」というアレです。
ElasticsearchのGraph機能は、このような単一の項目(配列)の関連も図示できるのです。


データの関連がどういうものか、イメージを掴めたでしょうか?

なお、私はこういうものを見ると「ネットワーク構成の可視化」とか「マイクロサービスの可視化」などしたくなるのですが、少なくとも今のバージョンのGraph機能では、そのような可視化は難しいようです。あくまでもデータの関連を可視化することを主眼とし、多段構成となるノードの関連はあまり目的とされていないようです。


Graph機能を試す環境を作る

それでは実際にGraph機能を利用するための手順を紹介します。


Graph機能を試すには、Elasticsearch、Kibana、X-Packの5.0.0-alpha5をインストールします。
インストール方法は、前回のエントリーを参照してください。
Elastic Stack 5.0.0-alpha4リリース。CSVインポート機能とKibanaのモニタリングがお目見え! #elasticsearch - Taste of Tech Topics

現時点でこの手順に従ってインストールすると、5.0.0-alpha4ではなく、alpha5がインストールされます。


Graph機能は、Kibanaの左メニューにある「Graph」から開くことができます。
f:id:acro-engineer:20160819114757p:plain:w800
こんな感じで、Graphの画面が開きます。

Graph機能を試す

Graphを描画するためには、何らかのデータが必要です。
アクセスログなり、天気データなり、データの種類は特に問いません。

今回は、Big Data Analysis Contestのデータを投入してみました。
The 2nd Big Data Analysis Contest

このサイトから「ナチュラルローソンのお菓子」の売上データをダウンロードすることが可能です(要登録)

ただしデータは正規化されているため、Elasticsearchに投入する際には非正規化したり、少し加工してGraph機能で利用しやすくするような加工を行ないました。本題ではないので、ここでは加工の詳細は割愛します。


さて、データの登録が終わったらGraphの作成に移ります。

まず、左上のボックスからindexを選択します。
次に、1つの項目(配列)内のデータの関連を見たい場合には「Select a field」となっているボックスから、関連を見たい項目を選択します。
そして検索ボックスに * とでも入力して検索ボタンを押せば、グラフが描画されるでしょう。

2つの項目の相関を見たい場合には、Graph画面の右上にあるフラスコのアイコン(Advanced Mode)をクリックします。
次に、「Fields」から関連を見たい項目を選択し、検索ボックスに * など入力して検索ボタンを押します。


ここでは試しに、年齢層と商品名の関連を見てみます。
フラスコをクリックしてAdvanced Modeにして、Fieldsから「segment.keyword」(年齢層)と、「pname.keyword」(商品名)を選びました。
それで検索してみたのですが、、、
f:id:acro-engineer:20160819120108p:plain:w800
あんまり良い感じのGraphになりませんね。


そうなのです、データの内容によっては、これではほとんどGraphが描画されなかったり、ばらばらのグラフが描画されてしまうことがあります。
そのような場合には、右上にあるフラスコの隣のギアのアイコンをクリックして、描画をカスタマイズします。
f:id:acro-engineer:20160819115811p:plain:w800


設定項目は次の通りです。

  • Sample:
    • Graphの描画に用いるデータの数(サンプリング数) この値が2000であれば、データ数が10万あっても、そのうちの2000だけが利用される。
  • Significant links:
    • Graphに描画する対象データをSignificant Searchで抽出するかどうか。これにチェックが入っていると、特徴的なデータでGraphを描画する。チェックを外すことで、特徴がないデータも含めたGraphを描画する。
  • Certainty:
    • データ同士に関連があると判断するための最小出現数。この値が3であれば、データが2個未満の場合は関連なしとみなされる。
  • Diversity field:
    • データの偏りをなくすために、サンプリング対象を制限するためのフィールド。このフィールドと値を選択することで、たとえばアクセスログの「同じセッションIDは10個までしかサンプルに含めない」などができる。
  • Timeout(ms):
    • タイムアウト。この値が5000であれば、5秒以上かかる検索はエラーとなりGraphに追加されない。


この中で、元データの件数が多い場合には「Sample」で対象データを増やしたり、「Diversity field」を上手く使って同件のデータ数を抑制すると、効果があります。
また特徴の抽出よりも全体の概要を掴みたい時には、「Significant links」のチェックを外すことで、全体的な関連が描画されやすくなります。


この設定をカスタマイズしながらGraphを描いてみると、こんな結果が得られました。
f:id:acro-engineer:20160819121828p:plain:w800


えっと、未成年男性(m00_19)にはヨーグルトマシュマロがよく売れていて、50歳以上の女性(w50_)にはチアシードといちじくのクッキーがよく売れていて、20歳から49歳の男女(m20_49、w20_49)には共通してエンゼルパイが売れている・・・なんて。

もちろんここから更なる詳しい調査が必要となりますが、
まずはこのGraph機能を使ってまずインサイト(閃き)を得て、次にそれを裏付けるためにデータを詳細に調査する、という流れが良いのではないかと思います。


alpha版のうちは自由に試せるGraph機能。
ぜひ今のうちに使ってみてください!

Graph Go!

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


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

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

AWS Lambdaの処理性能を言語毎に測ってみた

aws Docker Lambda

こんにちは、@です。

この間AWS Summit Tokyoに参加してきたのですが、皆一様に「AWS Lambda」を、
これからのサーバレスアーキテクチャを支える技術として紹介していましたね。

資料でも言葉でも多分に見聞きしており、軽いゲシュタルト崩壊を起こしている今日この頃、
皆さんはいかがお過ごしでしょうか。

さて、今回はAWS Lambdaです。

AWS Lambdaの処理はJavaやNode.js、Pythonなどの言語で記述することができますが、その性能差がどの程度あるのか?測ってみました。

構成

今回の構成は次の様なシンプルなものにしています。

[計測対象(言語)]

  1. Python
  2. Node.js
  3. Java

[計測対象(カテゴリ)]

  1. 処理速度
  2. 使用メモリ

[Lambdaでの処理内容]

  1. API Gatewayでリクエストを受け付け
  2. Lambda内でDynamoDBから1件データを取り出す
  3. 取り出したデータをログに出力する

図で示すとこんな感じです。

f:id:acro-engineer:20160714104306p:plain

[計測条件]

  1. 次に示すサンプルコードをそれぞれLambdaで定義して実行する。
  2. クライアントにはApache JMeterを利用。
  3. 各言語とも200回計測し、それぞれ100、90、80、50パーセンタイル値、最小値(もっとも速い/軽い)を取る。
  4. メモリは192MB指定。(Javaが192MBでないと動かないので、他も合わせてスペックアップ)

[サンプルコード]

各言語のソースコードは次の通りです。

[Python]

#!/usr/bin/python2.7
# -*- coding:utf-8 -*-
# Python
import boto3
import logging
from boto3.dynamodb.conditions import Key

logger = logging.getLogger()
logger.setLevel(logging.INFO)

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('mytest')

def handle_request(event, context):
    response = table.query(
        KeyConditionExpression=Key('id').eq('test')
    )
    logger.info(response)
    logger.info("SUCCESS")

[Node.js]

// Node.js
var AWS = require('aws-sdk');
var dynamodb = new AWS.DynamoDB();

exports.handler = function(event, context) {
    var params = {
        Key: {id: {"S": "test"}},
        TableName: "mytest"
    };

    dynamodb.getItem(params, function (err, data) {
        if (err) {
            console.log(err);
            context.fail('Failed');
        } else {
            console.log(data);
            context.succeed('Succeeded');
        }
    });
};

[Java]

package jp.co.acroquest.aws.bench;

import com.amazonaws.auth.EnvironmentVariableCredentialsProvider;
import com.amazonaws.regions.Region;
import com.amazonaws.regions.Regions;
import com.amazonaws.services.dynamodbv2.AmazonDynamoDBClient;
import com.amazonaws.services.dynamodbv2.document.DynamoDB;
import com.amazonaws.services.dynamodbv2.document.Item;
import com.amazonaws.services.dynamodbv2.document.Table;
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.LambdaLogger;
import com.amazonaws.services.lambda.runtime.RequestHandler;

public class DynamoDBBench implements RequestHandler<Object, Object> {
	AmazonDynamoDBClient client;
	Table table;
	DynamoDB dynamoDB;

	public DynamoDBBench() {
		client = new AmazonDynamoDBClient(
				new EnvironmentVariableCredentialsProvider());
		client.setRegion(Region.getRegion(Regions.AP_NORTHEAST_1));
		dynamoDB = new DynamoDB(client);
		table = dynamoDB.getTable("mytest");
	}

	public String handleRequest(Object input, Context context) {
		LambdaLogger logger = context.getLogger();
		Item item = table.getItem("id", "test");
		if (item == null) {
			logger.log("Item is null.");
			return "Failure";
		}
		logger.log("Item obtained: " + item);
		return "Success";
	}
}

結果

200回計測した結果の値を取ってみたところ、このようになりました。

[100パーセンタイル(最大)]
f:id:acro-engineer:20160718084625p:plain

[90パーセンタイル]
f:id:acro-engineer:20160718084624p:plain

[80パーセンタイル]
f:id:acro-engineer:20160718084623p:plain

[50パーセンタイル]
f:id:acro-engineer:20160718084622p:plain

[最小]
f:id:acro-engineer:20160718084626p:plain

  • Javaは初回アクセスからしばらくの間、オーバーヘッドが大きいことがわかります。
  • 使用メモリは予想通りJavaが一番大きく、PythonとNode.jsはほぼ同程度の使用率であることがわかります。
  • 実行回数を重ねるごとに、Javaのパフォーマンスが上がっていることがわかります。
  • 処理時間が最小の結果では、Javaが他の言語に追いついていることがわかります。

今回の結果の生データは次のリンクに置いておきました。

taste-of-tech-topics/measure_result.xlsx at master · kojiisd/taste-of-tech-topics · GitHub

Java性能のパフォーマンス向上における確認実験

ちなみに回数を重ねるごとにJavaの性能が大きく上がりはするものの、実行開始時の処理時間がかかっている部分をもう少し詳しく知るために、
AWS Lambda上でフィボナッチ数列を求める計算を簡易的にですが各言語毎に調べてみました。今回は40番目の数値を求める計算をしました。

たった5回の計測でしたが、次の様な平均値が取れました。Javaが他言語に比べてオーバーヘッドなど関係なく圧倒的に早いことがわかります。
Pythonは2分のタイムアウト設定を設けてもタイムアウトしてしまったので、今回はそれ以上は計測していません。

Java Node.js Python
平均処理時間[ms] 4308.3 12387.0 2分以上

個人的には(シンプルな実装なので最適とは言えないが)V8のJavaScriptエンジンを搭載しているNode.jsの3倍もの性能をJavaが出せたのは意外でした。
以上の結果から、今回のDynamoDBにアクセスして値を取得してくる処理に関しては、Javaライブラリの読み込みに時間がかかってしまっており、実行を繰り返す中で最適化がされていったため、初動は遅いが繰り返すたびにJavaの性能が上がってきた、と推測することはできそうです。

今回のフィボナッチ数列計算を試した際のコードは以下になります。

[Java]

package jp.co.acroquest.aws.bench;

import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.LambdaLogger;

public class Fibonacci {
	private static final int INDEX = 40;
	LambdaLogger logger;

	public String handleRequest(Object input, Context context) {
		logger = context.getLogger();
		long calcResult;
		calcResult = calcFib(INDEX);
		logger.log("result: " + calcResult + "\n");
		return "Success";
	}

	public long calcFib(int number) {
		if (number == 1 || number == 2)
			return 1;
		return calcFib(number - 2) + calcFib(number - 1);
	}

}

[Node.js]

exports.handler = (event, context, callback) => {
    var result = calcFib(40);
    context.succeed('result: ' + result)
    context.succeed('Success');
};

function calcFib(num) {
  if(num == 1 || num == 2) {
    return 1;
  }
  return calcFib(num - 1) + calcFib(num - 2);
}

[Python]

import logging
def lambda_handler(event, context):
    result = calcFib(40)
    logging.info('result: ' + result)
    return 'Success'

def calcFib(num):
  if num <= 2:
    return 1
  else :
    return calcFib(num - 1) + calcFib(num - 2)

言語毎の実行ログは以下になります。

[Java]

REPORT RequestId: b0afcdb2-5715-11e6-8d3c-537f664ac4cd	Duration: 4626.36 ms	Billed Duration: 4700 ms Memory Size: 128 MB	Max Memory Used: 34 MB	 
REPORT RequestId: b77533b9-5715-11e6-8d3c-537f664ac4cd	Duration: 4211.39 ms	Billed Duration: 4300 ms Memory Size: 128 MB	Max Memory Used: 34 MB	 
REPORT RequestId: bc0c9611-5715-11e6-8d14-ed04d7d6b375	Duration: 4239.18 ms	Billed Duration: 4300 ms Memory Size: 128 MB	Max Memory Used: 34 MB	 
REPORT RequestId: c2ecb0b3-5715-11e6-ac28-fd403fb9707b	Duration: 4229.15 ms	Billed Duration: 4300 ms Memory Size: 128 MB	Max Memory Used: 34 MB	 
REPORT RequestId: c8944a4a-5715-11e6-b5a7-bb8b3c4b93fe	Duration: 4235.18 ms	Billed Duration: 4300 ms Memory Size: 128 MB	Max Memory Used: 34 MB	

[Node.js]

REPORT RequestId: e3125256-5714-11e6-a4f7-85ff9fd7c6c7	Duration: 12458.36 ms	Billed Duration: 12500 ms Memory Size: 128 MB	Max Memory Used: 16 MB	 
REPORT RequestId: 04db011d-5715-11e6-b7c7-15170a43b8ce	Duration: 12367.85 ms	Billed Duration: 12400 ms Memory Size: 128 MB	Max Memory Used: 16 MB	 
REPORT RequestId: 72e8fccb-5715-11e6-9523-3f458c891180	Duration: 12367.47 ms	Billed Duration: 12400 ms Memory Size: 128 MB	Max Memory Used: 16 MB	 
REPORT RequestId: 7c31b1ac-5715-11e6-8ff0-2d80e2cd4b43	Duration: 12374.82 ms	Billed Duration: 12400 ms Memory Size: 128 MB	Max Memory Used: 16 MB	 
REPORT RequestId: 842b529d-5715-11e6-ad82-7103149e1efd	Duration: 12366.68 ms	Billed Duration: 12400 ms Memory Size: 128 MB	Max Memory Used: 16 MB	

[Python]

REPORT RequestId: 474c2f4b-571a-11e6-8a89-4bca1cc5593f	Duration: 120000.15 ms	Billed Duration: 120000 ms Memory Size: 128 MB	Max Memory Used: 15 MB	 
2016-07-31T12:30:25.971Z 474c2f4b-571a-11e6-8a89-4bca1cc5593f Task timed out after 120.00 seconds

考察

今までの実験を踏まえると、AWS Lambdaで言語を選択する際には、次のようなことを考えるとよいのかと思いました。

  • 継続的にアクセスされず、かつCPUもあまり使わない処理であれば、Pythonが速い。
  • 継続的にアクセスされ、かつCPUをあまり使わない処理であれば、どの言語も大差ない。
  • CPUを大量に使うのであれば、Javaが速い。

実際には上記に加えて書き慣れている言語であるかなど開発者側のスキルなども多分に関係すると思いますが、一旦結果のみから判断しようとすると、こうなるのかな、という感じです。


今回はシーケンシャルかつシングルスレッドで処理されるプログラムで実験をしましたが、複数同時リクエストの場合や、内部で複数スレッドを使って処理をするような場合での性能比較も、どこかで実験してみたいと思います。

それでは!

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


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

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

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アドレス払い出しの仕組みが流用されています。