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

Taste of Tech Topics

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

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

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