雑文発散

追記
過去の日記

2015-06-02 [長年日記]

[Elasticsearch] 第10回 Elasticsearch 勉強会へ参加してきた昨日の話

昨日、第10回elasticsearch勉強会 へ参加してきた。

えっ、日記なのに今日の話じゃなくて昨日の話を書くのはどうなの!?という思いもあるけど、昨日は別の話題で、ちょっと長めの日記を書いてしまっていたので、日を分けてしまおうという考え。まぁ、なんだ、ネタ切れ防止だ。

ちなみに少なくとも2014年1月1日から今日まで、途切れなく毎日この Web 日記を書いている。ただ、気負い過ぎるとツラくなるので「ネタが無い場合にはヒトコトで良し!」という方針でやっているので、わりと気楽だ。

まぁ、そんな話は置いておいて、勉強会の感想など。

Elastic{ON}の報告と商用プラグインの紹介

【資料はまだアップされてないかも】

Elasticsearch およびその周辺にまつわる初の単独カンファレンスであるところの elastic{ON} の紹介など。このときに Elasticsearch から Elastic へ社名を変更した。

また、Elasticsearch を AWS 上で構築して商用サービスをやっている Found 社の買収についてもこの時に発表されたらしい。Found 社のサービスは、ES のバージョンアップとかもマネジメントコンソール的な画面からポチポチやっていけるらしい。

Elasticsearch は最初の構築が簡単なので導入時はいいんだけど、いざ運用に入るといろいろな問題が発生しそうな予感はある(まだ体験していない)。こういう「サービス開発の本筋ではないところ」を運用してくれるサービスはこれからも増えていくんだろうな。

elastic{ON} の講演のサマリでは、名だたる企業が ES を使っている様子が伺えた。Microsoft は msn や Azure Search などで利用。Yelp は Solr から ES へ乗り換え。GitHub の検索も ES だし、Wikimedia でも利用されているとか。あとは企業ではないけど NASA では、宇宙にある機器からのデータを ES にブチ込んでいるんだとか。「宇宙」って聞くだけで盛り上がる人種には、ES と関わっているだけで嬉しくなる話だ。

Facebook でも社内で使っているとか。(社内?)ハッカソンで使ってみて、いいね!ということになったらしく、内部システムで利用しているとか。

それから Elastic 社の有償プラグインである Marvel、Shield、Watcher についての紹介。

Marvel は ES のクラスタやノードの状態(ヒープサイズ、ディスクサイズなど)の監視に利用でき、その取得データを Kibana 上で閲覧するもののようだ。またクエリを投げる UI もあり、そこでは Elasticsearch API のサジェスト機能や JSON の構文チェック機能などがあるとか。

Shield は ES をよりセキュアにするためのもので、誰でもアクセスできちゃう割とオープンな仕様の ES のユーザー認証・認可などが行えるようになる。また ES のクラスタ内での通信も SSL 化できるそうだ。あと、重要なデータを入れた場合に必要になってくる監査ログの取得・閲覧機能もあるそうだ。

Watcher は、まだベータ版で、クエリによる監視・通知サービス。定期的にクエリを投げて「システムとしては正常かどうしているが、データに異常値が見つかった」などの検知に使えるみたいだ。この検出をトリガーとして、メール送信やら Slack などへのチャットへ投げたりできるとか。

企業内に入れていくなら、このあたりのプラグインは欲しくなるね。うまいところを付いている商売だと思う。

Aamazon Web Service で実現するelasticsearchの大規模運用

【資料はまだアップされてないかも】

自社サービスでの Elasticsearch の利用内容と AWS Auto Scaling での利用事例の紹介だった。

パブリック DMP として、現在約4億件のデータを ES に蓄積・検索をしているそうだ。提携している各メディアからの来訪者情報、閲覧履歴やネットリサーチからのアンケート情報などを絡めたセグメントを広告配信ツールへ提供してエンドユーザーの趣味嗜好などに合わせた広告配信を実現するためのサービスの一角を担っている。

全て AWS 上に構築し、クラスタがひとつで Type もひとつというシンプルな構成。そこにノードが 86 台あるそうだ。86 台の内訳は、マスタ(データは持たない)が3台で、データ(マスタ機能は持たない)が80台、検索を受け付ける ES が2台にインデクサ(index を作成する役割)が1台。さらにこのフロントに ELB が置かれている。インデクサ以外は Auto Scaling の対象になっているそうだ。

この構成に決める前に、負荷試験などを行なってみたそうで、ノード数 == シャード数の状態では100台くらいまで性能向上が見られたが200台くらいで検索のパフォーマンス劣化を見つけ、シャードとノードの比率が 1 を超える(例えばシャード 10 に対しノード 8 とかの状態?)だと、パフォーマンス劣化が見られるなどを発見したそうだ。

インスタンスの性能については、SSD の性能重視で選択し、c3 ファミリーに。コストパフォーマンスを考えて xlarge にしているそうだ。

Auto Scaling は、100台単位のクラスタを数人で回すために必要だったとのこと。運用コストを減らす対策。その一方でスケールアウトしやすくなったというメリットも出たそうだ。

Auto Scaling って、急な負荷のときの対策というイメージが強かったんだけど、一定数の規模のクラスタを運用し続けるという使い方もあるんだね。そこが分かってなくて、勉強会の最中にはあまりピンと来ていなかった。よく見たら AWS のドキュメントにも「必要な数の Amazon EC2 インスタンスを確実に実行するための助けとして、Auto Scaling を使用することができます」と書いてあったわ。

「一定数の規模のクラスタの維持」の話だということでリカバリの話もあった。コケたサーバとか、ライフサイクルにより入れ替わったサーバを復帰させるときのリカバリ処理を速くする TIPS。indices.recovery.max_bytes_per_sec をデフォルトの 40mb から 500mb にしているとか。こういった設定などで、CPU 4 コア、データ量 40GB のノードが10分程度でサービスインできるそう。

これが速いのか遅いのか、ちょっとまだオレの感覚にはないなぁ。。。

ELB のヘルスチェックは、検索受付用サーバ以外にも実行しているそうだ。これはリカバリしたノードで、ごくたまに ES がうまく立ち上がらない場合があるからだそうだ。9200 ポートを叩いて返事があるかどうかでチェックしてるそう。

Q&A コーナーでは、検索用ノードを分けた理由についての質問が興味深かった。もともとマスタノードで検索をしていたが、激しい検索で GC が発生してマスタノードがコケたからだそうだ。「激しいクエリ」がどのくらいなのかは分からないけど、そういう可能性があるという良いノウハウを聞けた。

Spark in small or middle scale data processing with Elasticsearch

【資料はまだアップされてないかも】

ビズリーチ社での利用事例。Scala で Elasticsearch を叩いているそうだ。Scala の知識が無かったので、そのメリットについてはあまり分からなかったけど、サービス構築までの裏話が聞けて面白かった。

サービス開発は1年くらいかけたのだけど、その間に何回か作りなおしたりしていたそう。当初は AWS の CloudSearch を使っていたそうなのだが、今回のサービスは「検索」そのものに重きを置いているので、そのキモの部分をブラックボックスである CloudSearch に任せてしまうことへのリスクを考え、ES にしたとのこと。ES なら自分たちで手を入れることが可能なのもプラスポイントになったそう。

当初のアーキテクチャでは、クロールしてきたデータを入れる ES と、そのデータを元にして検索用データを投入する ES を分けていた。そこをふたつに分けていくことにより、それぞれのサービス開発のライフサイクルの違いを吸収。別々にデプロイしやすくしたそうだ。

データ量の増加と作業の反復などを踏まえて、Apache Spark を導入して分散処理ができるようにしたそうだ。ただ、初期には map のタスク数 == シャード数にしてしまい、タスクが分割されないというミスも。また、Spark で大量に書き込みを行ったら、シャードが壊れてしまう事故も発生したので、設定値の一部を低くして書込しすぎないようにしたんだとか。

現在ではアーキテクチャの一部を変更して、Spark Streaming を導入しているそうだ。クロールしたデータは ES へ入れるのではなく S3 へ登録、Spark Streaming で S3 を監視し、新しいファイルがあれば処理を開始するというスタイルになっているとか。

Elasticsearchのサジェスト機能を使った話

サジェスト機能の話もさることながら、先日の Testing Casual Talks #2 のときに引き続き、Gatling の名前が出てきた。負荷試験には Gatling がいいのかもなー。

Elasticsearchで作る形態素解析サーバ

形態素解析のいろいろな準備が面倒なので、Elasticsearch の API を使って、形態素解析 API サーバを作っちゃおうという話。ちょうどこの辺について興味があったので、似たようなことを試してみたい。

開発効率UP! Elasticsearch Client Tool 作ってみた

Sublime Text 3 の拡張(プラグイン?)で Elasticsearch にクエリを投げたり結果をみたりするヤツだそうだ。Emacs にも es-mode があるので試してみたい。

あと、Hello! Elasticsearch. のなかの人だったとは。いろいろ勉強させてもらってます。

変わり種プラグインの作り方

【資料はまだアップされてないかも】

Elasticsearch のプラグインは簡単に作れるよ、いろんな部分で作れるよ、という話。フック出来る箇所がたくさん良いされているそうだ。

アプリケーション側で行われている処理を ES のプラグイン化してしまえば、ES 本体のクラスタ機能により、処理が分散でき、スケールするという考えが面白かった。そういう発想は無かった。

全体を通して

いろいろな方面の話があって面白い回だった。実況ツイートという名のメモを書いていたけど、自分の知識の範囲外の単語も出てきて、なかなか大変だったけど、勉強になった。まさに勉強会。

開催ありがとうございました。


2015-06-01 [長年日記]

[Karma] Karma でブラウザのプロファイルを切り替えて使う方法

PHP カンファレンス関西2015で「PHPer だからこそ知っておきたい、JavaScript のテストを複数ブラウザで自動実行する話」を発表した時に頂いた質問で、「プロファイルを指定したブラウザを使いたい場合はどうするのか?」という内容のものがあった。

以前調べているときに、どこかでそれに似た話を見かけたような気がしたので「なにかでできると思います」という超あいまいな返事をしてしまったので、ちょっと調べてみることにした。ちなみにその質問者の方は「自分でやったときにはうまくいかなかった」とおっしゃっていたので、どうなることやら。。。

プロファイル切り替えといえば、先陣を切ったのが Firefox だという認識があるので、Firefox で試す。独自プロファイルの作り方や指定の仕方なんかは、Mozilla の「プロファイルの管理」だとか「コマンドラインオプション」あたりを読めば分かると思うので、ここでは省略する。

で、今のところの結論を言うと「プロファイルを指定した Firefox を Karma で利用する」には、次のステップを実行すれば良いことがわかった。ただし、「今のところ」と言っているのは、まだ良くわかってないところがあるため。むしろ、知っていたら誰か教えて欲しい。

  1. Karma 用の Firefox プロファイルを作る
  2. 「1 のプロファイルを指定した Firefox」を起動するシェルスクリプトを作る
  3. karma-script-launcher をインストールする
  4. karma.conf.js の browsers 配列に 2 で作ったシェルスクリプトを指定する

1 は、先程も言ったように説明は省略。今回は「karma」という名前のプロファイルを作成した。

2 は、だいたいこんな感じ。karma-firefox.sh というファイル名にしてみた。あ、ちなみに環境は OS X である。この記述でとりあえずは動くようなのだが、ちょっとまだ不明点がある。それは Firefox に渡している URL のid=11111111 のところ。

#!/bin/sh

FIREFOX='/Applications/Firefox.app/Contents/MacOS/firefox'
PROFILE='karma'

$FIREFOX -p $PROFILE 'http://localhost:9876/?id=11111111'

この id は、karma.conf.js 内の browsers 配列に渡すブラウザごとに違った id 値を割り振るようなのだけど、それを動的に割り当てる方法が分からない。karma-script-launcher 以外で立ち上げたブラウザ(例えば karma-chrome-launcher で立ち上げた Chrome)の URL 欄をよく見ると、毎回違った id が割り振られているので、Karma が起動時に動的に割り当てていそう。それをシェルスクリプトへ渡せればいいんだけど。

ただ、今のところ固定値にしておいても、他のブラウザと被らなければ大丈夫そうな気配ではある。

3 は、npm コマンドでインストールするだけ。

% npm install karma-script-launcher --save-dev
  1. はこのような記述になる。
// karma.conf.js
// [snip]
browsers: [
  '/path/to/karma-firefox.sh'
],
// [snip]

あるいは、--browsers オプションを利用して、次のようにしても起動できた。ちなみにシェルスクリプトの path はフルパスじゃないとダメみたい。

% ./node_modules/karma/bin/karma start --browsers '/path/to/karma-firefox.sh'

完璧な回答にはなってないけど、「プロファイルを指定したブラウザ」での実行はこんな感じなのではないだろうか。

発表のあと、質問して頂いた方とお話できなかった(他の方とのお話が長引いた)ので、お名前とか伺えなかたので、この回答が何かで届くといいなと思いつつ書いてみた。質問の意図が違ってたら申し訳ない。


2015-05-31 [長年日記]

[] 大阪ぶらぶら、もしくは、ユニークポータルハック

宿泊先である「イルクオーレなんば」を朝9:30頃に出た。ちなみにこのホテルのシャワー、ちょっと強めにしたら、シャワーヘッドが固定具から外れかけるほどの水圧になった。もうちょっと強かったら、そのまま外れてヘッドが暴れまくりそうな勢いだった。今まで泊まったホテルの中では、最高クラスの水圧だった。自宅のシャワーもこのくらい強くなるといいのに。。。

特別にどこかへ行く予定も無かったのだけど、Google Maps を眺めていたら日本橋が近くにあるし、そこら辺をブラつくか、とそちら方面へ歩いて行った。Ingress のマップを眺めながら。

日本橋は、、、まだほとんどの店がシャッターが降りたまま。まだ開店前の時間帯だったようだ。この時点でもうだいぶ暑くて汗だく。前日の懇親会やら二次会やらで、がぶがぶ飲んでいたのも効いているような気がした。

そんなこんなで通天閣。実に n 年ぶり、、、というか思い出せない。と思ったけど、検索したら、この日記に書いてあった。前回来たのは、2002年6月2日だった。

大阪ぶらぶら2015

新世界はさすがに開いている店もチラホラあったけど、まだ本格的な時間帯じゃなかった様子で、こちらもシャッターが閉まっているお店が多かった。

そのまま天王寺公園の方へ歩いて行き、大阪市立美術館の前まで行った。面白そうなことをやっていれば入ってもいいかな〜と思っていたんだけど、いまの展示はあまり興味がないものだったのでスルー。そして天王寺駅/阿倍野橋駅方向へ向かって、あべのハルカスへ。

大阪ぶらぶら2015

この辺で既に疲れてしまったので、ビル内にあった「丸福珈琲店」へ。なんとなく名前を聞いたことがあったような気がしたので、入ってみることにした。

まだモーニングセットが注文できる時間帯だったけど、甘いものが欲しかったのでケーキセットを注文。超定番のチーズケーキとホットコーヒーで。

大阪ぶらぶら2015

出てきたコーヒーを飲んだら、なにこれめちゃうま。濃い目のコーヒーが好きなオレにはぴったりの味。濃厚なのでチビチビ飲みながら、ケーキを食べると、これは至福。このお店、東京にもないのかなーと思って、いま店舗一覧を見たら、何店舗かは東京にある。

そのひとつが羽田空港店。第1ターミナルの到着ロビーにあるそうで、たぶん、そこで見た記憶が「なんとなく名前を聞いたことがあった」ということなんだろう。

その他には秋葉原のヨドバシの中にも入っているらしい。こっちの方が行動範囲に近いかなぁ。最近はほとんど秋葉原へ行かなくなっちゃったけど。。。

あとはあべの橋周辺をウロウロ。この旅行中に Amazon が Kindle 本の 50% ポイント還元セールなんかをやっていたので、そういえば漫画版の「アベノ橋魔法☆商店街」も安くなっているかな?と思って見てみたけど、そもそも Kindle 版が出ていないというオチであった。

そんなこんなで、ちょっと早めに伊丹空港へ行き、ラウンジで日記などを書いていた。

羽田へのフライト便が JAL SKY Wi-Fi に対応している機体だった。特にネットに繋ぎたいモチベーションは無かったのだけど、どのくらい速度が出るものなのか?という点は気になったので、試しに接続してみた。モバイル・30分プラン400円で。

大阪ぶらぶら

回線速度は iOS の「RBB TODAY SPEED TEST」を使った。普段からインストールしていた訳ではなく、このアプリも JAL SKY Wi-Fi 経由でインストールした。

実行してみた結果はこんな感じ。何度か試したけど、だいたい似たような数字だった。

大阪ぶらぶら

メール送信とか非同期かつテキストベースの通信なら良さそうだけど、いまどきのサービスを利用しようとするとストレスが溜まっちゃいそう。この結果をすぐにシェアしたくて、機上から Facebook へ画像付きでメッセージを送信したりしたんだけど、ずっと通信中のマークがくるくる回っていて、なかなかアップできなかった。ネット廃人(死後か)といえども、機上でのネット利用は、まだあまり現実的ではない気がするな。

ただ、「高速移動中の飛行機の中から人工衛星経由でネットワークに繋がる」というシチュエーションは、なんだかカッコイイよ。更なる快適さを目指して、関係各位にはがんばって頂きたい。

そうして到着した羽田空港で、本日2度目の丸福珈琲店でコーヒーを飲んで締めた大阪トリップだった。

大阪ぶらぶら

丸福、美味しいよ、丸福。


2015-05-30 [長年日記]

[PHP] PHPカンファレンス関西2015で「PHPer だからこそ知っておきたい、JavaScript のテストを複数ブラウザで自動実行する話」を発表してきた

PHPカンファレンス関西2015で「〜 PHPer だからこそ知っておきたい〜 JavaScript のテストを複数ブラウザで自動実行する話」を発表してきた。

このタイトルは「この書き方なら公募セッションの審査に通るだろ?」というところを狙って付けた若干釣りタイトル気味なもの。そうしたら、まんまと(以下略)

有料イベントで発表するということ

PHP カンファレンス関西は、今年から参加チケットが有料になった。その経緯については「勉強会(カンファレンス)を有料にするということ」が詳しいのだが、これはスタッフ側から見た感覚。

有料だった価値があったかどうかの参加者からの感覚は、これから幾つか出てくるだろうから、ここでは発表者の立場として「有料イベントで発表すること」について思ったことを書いてみようと思う。

まず準備段階。主に発表用の資料作り。オレは資料作成に時間をかけるタイプなので、だいぶ前から作り始めた。最初はいつものつもりで作っていたんだけど、ある時に「そういえば、これ、有料イベントだったわ」と意識してしまったら、「本当にこれでいいのかな?」という不安が少し芽生えた。

まぁ、無料イベントでの発表でもそういう気持ちは多かれ少なかれあるものだけど、お金を払って来てくれた人の前で話すとなると、いつもよりしっかりやらないとなぁという気持ちになった。

いったん資料ができたところで通しで見てみたら、「この発表で言いたいことってなんだっけ?」と疑問に思う構成だったので、もうちょっと手直し。結局最後の「まとめ」で無理やり言いたいことを追加した感じになってしまった。

そんなこんなで最終的に落ち着いたのが当日の朝。大阪へ早めに到着したので、カンファレンス会場近くのスタバにて完成した。

昨年の PHP カンファレンス2014では、資料は作ったものの、発表の練習をしなかったので、だいぶグダグダな発表になってしまった記憶があった。なので、今回はリベンジしたかったし、何より有料イベントなので(以下略)。

前日の夜、未完成状態でちょっと発表練習をした。当日の朝にスタバで完成した最終稿については、そのスタバでストップウォッチを見ながら小声で練習をした。時間が足りないかな?と思ったけど、割とキッチリと30分以内に収まった。

PHPカンファレンス関西2015

そして、本番もだいたい同じくらいのペースで話すことができ、質問の時間も取ることができた。

最後に「タイトルと内容が(釣りじゃなくて)釣り合っていたと思った人はどのくらいいますか?」と聞いたら、何人か手を挙げてくれたので、まぁ、そこそこは価値のある発表をできたんじゃないかな(自画自賛)。

ということで、「有料イベントで発表者側に特別な何かがあったか?」というと、「適度なプレッシャーがあって結果的に良かった」というところかな。

人前で発表したのはひさびさだったけど、こういうのは刺激になって良いなぁ。また機会があればアウトプットしていこう。


2015-05-29 [長年日記]

[] プロダクトオーナーとスクラムマスターと開発チーム

なぜか、いま全部の立場をやってるんだよね(笑)

もはや「スクラム」とは言えない「なんだこれ」状態になっているけど、まぁ、プロジェクトは回っているし、先には進んでいるので、いまの変態ステータスでも良いのだろう、きっと。目的はプロダクトを先へ進めることで、スクラムの形を保つことではない。

スプリントのレビューとか計画とかあると、つい司会進行もしちゃうので、ヘタをすると独裁的になりかねないので注意しているつもりではある。

まー、ぼちぼちやっていこう。