2014-08-31

YAPC::Asia Tokyo 2014 行ってきました。

yapc

YAPC::Asia

YAPC::Asiaとは、YetAnotherPerlConferenceの略らしい。
@miyagawaさんのpodcast rebuild.fmでこのお祭りがあることを知って、
Perlオンリーではないとのこともあり参加してみました。

全体的な感想

Perlさわったことない人でも全然参加すべき！お祭り感楽しい！
わからない人にもわかりやすく説明してくれるしトークもうまいし、さすが熟練発表者さま。
はじめてmiyagawaさんとnaoyaさんを生で見れたので感激（ミーハー）
１年目、２年目のような人がガンガンLTしてた。すげぇかっこいい。負けてられん。
かき氷すすめすぎ！！たくさん食べた！！
こういうお祭りはやっぱりモチベーションあがる！

でもキャパ超え過ぎ！床座り見、立ち見疲れた。。。
質問系の時間がなさ過ぎて。。。もうちょい。こう。なんか。

ともあれ、皆様ありがとうございました！！

徒然なるままに・・・

こういうお祭りにうちの会社の人はどのくらい参加するのだろう。
親会社含めてとんがっている人は、ごくわずかなのかなぁ。
外にアピールしてる人が少なくてアンテナに引っかからないのかなぁ。
ジャンルがちょっと違うからひっかからないのかなぁ。

でもまぁとんがってればいいって訳ではない。

今回、YAPCに行くまでは、ほかの会社がよく見えた。
自分たちでサービスをつくってユーザ体験思考でモノづくりをしたり、
最新技術をガンガン取り入れていったり、本当にうらやましい。
やる気に満ちあふれた人ばかりだし。職業プログラマはいなそうな。
なんでうちの会社でそうじゃないのか、そうできないのか。

でもちょっと領域が違うのか、と感じた。
どこも素敵なサービスを提供しているけども、
うちの会社が相手にするところとはちょっと領域が違う。

うちの会社でしかできないことがあって、その領域をもっとよくすると、
なんかこう、基盤をよくすることができるのかな？


正直技術がすごい好きって分けでもない、元々職業プログラマだった訳で。
そんな人がわりかし多い、うちの会社をなんとかどうこう少しでも変えられたら楽しくないか？
というのが最近のモチベーション。

以下、メモ

インフラエンジニアは死んだ（狭義）

memo

Lineの中の人。
プログラミングスキルのないインフラエンジニアは死ぬのか？
自称○○エンジニア→自分のやるべきこと、使命的な
目の前にある問題を解決するために必要ならば書く・読む
まず解決すべき問題は何なのか？を考える
過去の自分は他人！
同じ悩みを共有できる仲間、刺激を与えられる仲間。

one's impression

意識高い系！！みんながみんなこんな意識高ければ苦労しないぜ。
懇親会でちょっとお話しさせてもらったけど、LINEさんには意識低い系はいないらしい。
意識高い系だらけばかりっていうのも大変とのこと。そうねぇ。
でも職業プログラマばかりも大変よ。

最近のウェブサービスの検索機能やその先の話

memo

はてなの　@yanbe さん

期間指定ができる検索
お気に入り（フォローしているユーザのブックマーク）から検索→ノイズが少ない
サブドメインをお横断して検索
Presso　モバイルアプリ

検索ミドルウェアの歴史
2007 MySQL Like検索
2008 サービス規模を増やしたい。１１００万エントリ、３３００万ブックマーク
2008 Sedue 導入
2009 関連エントリ機能　あるページに関連するページ
     MySQL + Senna　スケールしない
2012 Sedue -> Solr
2013 秋 Elasticsearch検討

親子ドキュメント、わかりやすいクエリ
JSON APIがモダンでいいよね
Aggregation API で　ブクマカウント

マッピングの更新は同じ構成のマシンを用意して、ブルーグリーンデプロイメント！！

one's impression

Elasticsearchは自分も使って運用しているので興味あり。
MySQL + Sennaとかちょっと懐かしかった。使用しているものはそこまでかわらないんだなぁ。

懇親会でもうちょい詳しくきいた。
どうやら「しぇいばのん」とあったらしい！！
バージョン的には0.90系からで、いまは１０台,SSD、シャード数６、レプリカ２で運用していると。
データストアがMySQL?で検索エンジンとしてElasticsearch。うんうん。
kibanaも使っているらしく２週間分のデータを保持して利用している。
aggregationsマジおすすめって言われた。

開発合宿！！！！

memo

yasuhiro_onishi はてな　チーフエンジニア　サービス開発本部長
はてなブックマークは開発合宿でつくられた
３日間の合宿でつくって、持ってかえっていきなりβリリース。はやい

Pros
お祭り感！非日常感！

Cons
飲み過ぎる

企画とテーマ決めが大変
幹事、宿、食事、旅のしおり

宿選び
優先、無線LAN
１日中作業できるか？
会議室、プロジェクタ
持ち込みとか

無線LAN HUB ,電源タップとかとか

one's impression

開発合宿楽しそー！！！とあらためて感じることができた。
うちの会社でもやりたいが、これをやるためのお金とかはでないんだろうなぁ。。。
自腹でやってみたい人集めてやるとかになってしまいそうじゃ。
おすすめの宿をいくつか聞きたかったけど質問が多くて聞けんかった。

懇親会

初めての懇親会。あんまり記憶がないよ。頑張って話しかけたよ。でも何話していいかわからないよ。

面白法人カヤックの方　２人
Chefで自動構築、オートスケールはやってない

pixivは小文字の人

pixiv は phpらしい。rubyは性能面であきらめた
４５０台で運用していて、スケールアウトは簡単にしないで
なるべくリソースを使い切るということをいわれるらしい。すごいぞなもし。
ログはS3で運用。

突然ITインフラを任された人のための監視設計入門

memo

ハートビーツ　Yuichiro SAITO

なんで監視するのか
いち早く障害発生を確認できるようにする
復旧にいち早く取りかかれるようにする

なにを監視
死活監視
動いているかどうか

メトリクス監視
閾値の範囲内かどうか

外形・デーモン・リソース・サーバ
ps を眺める。

閾値
非機能要求から決める
平常値の２・３倍
ntp/smtp
誤報が出ないように見直す、誤報慣れをしない

連絡体制
責任分担を決める
Nagiosはconfigでの操作しかしない。
Zabbixはmysqlのバックアップでやってるところもある。

one's impression

うちもちゃんとやれることはやっているではないか！よかよか、と再認識。
Zabbixの設定をどう構成管理したらいいかでちょっと質問させてもらった。
mysqldumpでって言うのはちょっと無理あるか。。。も。。。
設定変更したものを構成管理ができるか？って観点でOSSを選ぶのも大事なことなのか。な。

Google BigQuery で DWH 構築

memo

Naoya Ito さん

120億レコード５秒
ログ解析。DatawareHouse.。

SQLを分散処理。
スキーマレスではない。
すべてフルスキャン、インデックスとかない。
MPP Query Engine : Presto Impala GoogleEngine


アクセスログの保存、調査　S３より安い
アプリケーションログの解析
ABテストの優位さ判定

one's impression

BigQueryってなにもの？っってレベルで参加した（Rebuildでファンになったっていうのもありつつ）
やはり説明がうまいなー。資料も見やすくてわかりやすいなー。

S3よりやすくて解析もできるなんて、うちのログも突っ込んでみればよくね？と思ってしまった・・・。
他社サービスを使うことに非常に障壁があるうちの会社だけど、今の流れならば乗っかれる気がする・・・！！

いくつか自分が見なおしたい資料

メモメモメモメモメモメモ

完成されたシステムなどない。

memo

なんかスピリチュアルな感じのトークだった。
めちゃめちゃ壇上をうろうろするなぁと感じて「kenjiskywalker」さんって言う名前を見て納得していた。
理想論で語られていたので、それはそうやねぇ。と思って聞いていた。
もうちょい現実路線でどう試行錯誤しているのか的なことが聞けたらよかったな。
トーク後のtagomorisさんからの質問で「現実はどうなんだ！」っていうのが面白かった。

ランチセッション

memo

DeNA　@yosuke_furukawa
QuizNow Node.jsユーザグループ代表

思いつきを意識する
その場ののりは大事　モバミ

自分のスペシャリティをシェアする
ios1 serversside2 front1 design1

勉強会スタイルでよいサイクルをまわそう

gitによるツール開発

memo

motemen　はてなの人
mackerel

gitのテクい話
ghq 
git help -a

DeNA自動化

memo

モバゲプラットフォーム開発をやってきた
デプロイ自動化、その背景

安全工学
システムをいかに安全に運用し続けるか
早く安全に届ける

問題が早めに発見されるシステムはいいシステム
巨大なコンテナ->意味のある小さなサービスに分割　マイクロサービス的な

自動化できる条件
ソースコードのバージョン管理
ユニットテスト、受け入れテスト
自動テスト、CI
データベースバージョン管理
環境を問わない簡易なデプロイツール
　開発と本番でなるべく差異をなくす

デプロイメントパイプライン
Jenkinsをつかっている -> ビルドパイプライン
　ユニットテスト -> ビルド -> デプロイ -> 結合テスト
zeroデプロイ

テストケースの時間、依存関係、並列化・高速化

WHERE狙いのキー、ORDER BY狙いのキー

memo

yoku0825さん

みんなExplainしてるー？
kuso-query As A Code

table scan とらんぷの一番上からしたまで
ちゃんと狙っていけ

ウェッブエンジニアのローレベルプログラミング

memo

立ち見
OSとか人がつくったものから解き放たれて自然界を相手にするここちよさ！
トークがすごい楽しそうでいい雰囲気だった

How's startup life? - working as CTO in Japan

memo

スタートアップって何？ファイナンシャル、エンジニア、デザイナー。
Ansible pythonを意識しないところがいい
chef ruby臭がつよい
Rethink the risk
ベンチャーは先端技術とか面白いことができる

Mobile Application Development for Perl Mongers

memo

[ninjinkun x gfx]

mvvm angularとか
Reactive Programming reactiveCocoa
Fablic -> Elasticsearch

Bots ios ci

2014-08-24

インデックスに割り当てられるシャードをノード毎にいい感じしたい

Elasticsearch

total_shards_per_node

仮にノードが４台のクラスタで、プライマリ１０シャード、レプリカ１の場合は

curl -XPUT localhost:9200/test/_settings -d '{
    "index.routing.allocation.total_shards_per_node" : 5
}'

こんな感じにすると１つのインデックスにシャードが５個割り当てられていい感じになる。
特定のインデックスがでっかくなるのでバランシングしたい！ってときにはいいのではないか？

2014-08-24

DevOpsを考える

devops agile

開発から運用へ

今まではアプリ開発のメンバとしてずっとやってきたのだけど
いろいろとあってインフラ開発・運用のリーダとして仕事をすることになった。

上司からはDevOpsを求められている。

運用の現場

運用に入って正直驚いた。

チケットは１行「作業完了」といって解決にしているし、
リポジトリにコミットせずに、なぜか部の共有ディレクトリにファイルをあげている。
そこには「XXXX_201407XX.txt」なんて対比されているファイルもある。
と思えば、リポジトリにはチケットの作業ログがあげられている。
特にレビューも作業結果も確認せずにクローズされているチケット。

ただ、運用メンバに加わることで見えてくることもあった。

「人のせい」にしないで「プロセスのせい」にして、ちゃんとした振り返りを作業後に行っている。Good
複数のプロジェクトの運用を行っているため、コンテキストスイッチが多くなかなかつらい。
実工数分しか発注されていないため、そもそも運用改善をする時間が取れない。
「何のために」をちゃんと教わっていなそう

現場を見て、DevOpsに悩む

個人的な理想 DevOps。
運用と開発をがっちゃんこした一つのチームにして運用も開発もみんなができるようになって。

なんてことが本当にできるのか？

やはり「運用」としての人材としてきてもらっている人にいきなりコード書けは敷居が高すぎるし運用メンバには負担でしかないのではないか？
DevOpsと言いはじめたとき、運用メンバも開発やるのか・・・勉強しなきゃって不安があるという噂を聞いた。

開発メンバは開発効率が下がるだーなんだーいって、運用をやりたくないことしか伝わらない。

そもそもプロセスが全く違うしどうやって一つのチームとしてまとめるんだろう？

数週間頭が痛いのが続いた。
正直会社にも行きたくねーってなった。（あ、これは普段通りかもw）

上司、開発リーダからの助言

運用にコードを書けとは言わない。もっと他にもやることがあるだろう。
DevOpsだからといって一つのチームでということではない。
いろいろなDevOpsの体系があるんだから焦らずに、中長期的に見据えていこう。

DevOpsについて学ぶ

固まっていた思考がだいぶほぐれた気がした。
というかそもそもDevOpsについて勉強していなかった。
勝手にそういうもんだと思い込んでいた。

DevOpsはキーワードは知っていたけど、勉強していなかったのでほんとうに「にわか」ダッタと思う。
いまでも「にわか」だけど前よりはましになっただろう。

今日、その辺りの資料をいろいろと読んでみた。

そもそも開発は変更を加えたいと運用は安定かどうさせたいというミッションの違いがあることから対立がおきている。
そこでビジネスゴールという共通の目標をたてて、同じ方向を向き、クリアするためにどうするか。
なんかアジャイルを勉強していたときに聞いた話だった。

結局は、

素早く、お客さんに黄金体験（ゴールドエクスペリエンス）を提供する

あくまでこれが大前提であることがわかった気がする。

アジャイルと同じでDevOpsに形はない。チームにあった自分たちのやり方を考えるんだ。

自分はよく手段を目的にしてしまうことがあるので、「何のために」を先に考えることが必要。
さて、今後どうしていくか。

2014-08-10

情報収集のもと。

ict antena from Akira Otsuka

2014-08-10

Zabbix 2.2アップデート

zabbix

Zabbix 2.2アップデート

利用者へのメリット

パフォーマンスが改善されている
キャッシュの拡張、データベースアクセスの最適化、および処理アルゴリズムの改善等大小様々な改良によって 2.0に比べて 2～5倍全体的にパフォーマンスが向上している。
グラフ処理性能や監視設定の変更操作のWebインターフェース、ログファイルの監視といった監視自体の性能も向上している。
無効ホストの過去データ参照
監視を無効にしている環境の過去データが参照可能となった。
これまでは対象環境の電源がオフの場合、監視を無効にする必要があったためリソースを後で確認することができなかったが
対象環境を停止している状態でも、性能負荷試験実施などの過去リソースを見ることができるようになる。
Web監視の改善
Webコンテンツの再利用（前リクエストのレスポンスの一部を後続ステップで再利用）ができる。
また、リトライ回数の指定やweb監視時に個別のＨＴＴＰプロキシの指定ができるようになる。

運用者へのメリット

VMware監視
VMwareハイパーバイザーとVMのリソース監視ができるようになる。
これまでもZabbixエージェントを入れることで監視可能であったが、
仮想環境特有の監視内容などをハイパーバイザーから取得するようになった
（現時点で利用の必要性はないかもしれない）
バージョンアップが容易
データべースの自動アップグレードがサポートされており、アップグレード時の時間も短縮されている。
Zabbixプロキシの自己監視
Zabbixプロキシの内部チェックがサポートされ、動作状況やリソース使用状況を見ることができるようになる。
イベント関連の改善
不明トリガー、取得不可アイテムの障害通知がおこなえるようになる。
監視が正しく行えなかったとき（監視対象のログが消失した等）に障害通知を行うことが可能となる。
バグフィックス
- セキュリティ問題の修正
  - 認証・権限の問題
  - SQLインジェクションの問題
- メモリーリーク問題の修正
- クラッシュする問題の修正
  - キュー計算時にZabbixServerがクラッシュする可能性がある[ZBX-8060]
  - Zabbixサーバーから正しくないレスポンスを受信した場合にZabbix senderがクラッシュする[ZBX-5741]
- 監視問題の修正
  - サーバ起動中・ネットワーク問題・によるZabbixProxy からのデータ消失の修正[ZBX-6526/ZBX-6249]
  - Zabbix senderでファイルからデータを送信した場合の問題を修正[ZBX-5732]
  - proxy からのデータ取得が不正な場合がある[ZBX-7133]
  - ログサイズと更新日が保存されない問題の修正[ZBX-6929]
- ログ出力の改善
  - エージェントがサーバー/プロキシへの接続に失敗した場合にワーニングログを出力するように修正[ZBXNEXT-1056]
- WebGUI改善
  - IEでの操作時の非表示問題改善(ホストグループ)

Zabbix 2.2の新機能とZabbixオフィシャルサービスの紹介
http://www.slideshare.net/KodaiTerashima/20130802-osc2013-kyoto

「Zabbix 2.2は最も優れ、安定したリリース」、開発者が語る
http://www.atmarkit.co.jp/ait/articles/1311/22/news150.html

気になったバグフィックスりすと

セキュリティ問題の修正
- [ZBX-7703] fixed being able to switch users without proper credentials when using HTTP authentication
- [ZBX-7693] fixed admin user being able to update media for other users; reference CVE-2014-1685
- [ZBX-7091] fixed SQL injection vulnerabilities in page filtering
- [ZBX-7091] fixed SQL inection vulnerabilities dashboard favourite managing fixed trying to change the status of a deleted trigger or trigger prototype changes the status of all trigger and prototypes
メモリーリーク問題の修正
- [ZBX-5988] fixed memory leak in functions evaluate_LOGEVENTID()
- [ZBX-6819] fixed memory leak in snmp trapper regular expression processing
- [ZBX-3878] fixed memory leaks in slide shows
- [ZBX-8006] fixed memory leak in proxy when handling ssh, telnet and database monitor items
ZabbixServer/ZabbixAgentがクラッシュする問題の修正
- [ZBX-8336] fixed server crash with value cache is working in low memory mode
- [ZBX-7836] fixed possible crash when a value older than the last item value was added to the value cache
- [ZBX-8060] fixed server crash when calculating queue
- [ZBX-5741] Zabbixサーバーから正しくないレスポンスを受信した場合にZabbix senderがクラッシュする問題を修正
ログ出力の改善
- [ZBXNEXT-1056] アクティブエージェントがサーバー/プロキシへの接続に失敗した場合にワーニングログを出力するように修正
監視問題修正
- [ZBX-5732] Zabbix senderでファイルからデータを送信した場合の問題を修正
- [ZBX-6526] fixed possible data uploading issues duing server startup or network problems 　　　　　　　proxy からのデータ消失の修正
- [ZBX-7133] fixed processing of zabbix[host,*,available] item; fixed proxy's hosts availability data on server 　　　　　　proxy からのデータ取得が不正な場合がある
- [ZBX-6929] fixed updating of lastlogsize and mtime in the proxy's database
- [ZBX-6249] fixed data loss in proxy "Data sender" process caused by unfinished transactions[ZBX-6129]
- [ZBX-6835] fixed bug when agent/proxy connection error could have resulted in a wrong warning about message size
- [ZBXNEXT-166] fixed proxy not storing items with text value type
- [ZBX-7968] fixed bug when proxy stopped sending history data if it had more than 1000 unmonitored item values in history table
- [ZBX-8202] fixed queue calculation for unavailable hosts which are monitored through a proxy
IEでの操作時の非表示問題改善(ホストグループ)

2014-08-03

Ansible入門

ansible

社内勉強会向けの資料を書いてみたので公開します。
基本は公式サイトのドキュメントを参考にぺたぺたしています。

Ansible入門 from Akira Otsuka

2014-07-15

第5回elasticsearch勉強会にいってきました

Elasticsearch

静岡からの参戦。しかし遠いなぁ、定時即でぎりぎり。もう少し近ければいいのに。例のごとく道に迷いながら時間ギリギリでたどり着きました。

Elasticsearchトレーニングに参加している先輩２人と合流してお勉強会スタート。

@yusukeさん、同時翻訳ありがとうございました！！

もう英語力がなさすぎてちんぷんかんぷん。基本的に同時翻訳をごりごりメモらせていただきました。ちゃんとまとめきれていない、個人めも程度です。ごめんちゃい。

タイムテーブル１

Honza Kral / @honzakral　さん Elasticsearchのpythonクライアント作っている人とのこと。なかなか渋い色のElasticsearchTシャツを着ていた。

1.0の新機能であるaggreagationについて。

このスライド、後で読む

aggreagationはネストできるfacetらしい。
aggreagationの中にさらにaggreagationを記述できる。
デモでは１つのクエリでドキュメントのヒット数、トップコメント、コメンタのスコアなどを取得できた。
キーのstringがとれるようになった(?)

あとpythonクライアントの話。クエリとかフィルターがメソッドチェーンで簡単にかけるらすぃ。けどpython使ってなかったのでふむふむ、とした感じ。んー、でも簡単なツールならこっち使った方が簡単かも。

aggreagationは結構目玉機能な感じ。必要なときに必要なものしか調べない（悪い癖）からこういうのについていけていない。。。ちょっとさわってみて、今度まとめてみたいと思う。

タイムテーブル2

Igor Motov / @imotov　さん Elasticsearchの開発者。snapshotとか作っているらしい。基本的なところからluceneや内部の動きについて。

※追記資料が上がっております。

file descriptors 32k -> 64k この辺りの設定とか重要
言葉の意識合わせ
- nodeはJVMのプレセス単位
- 複数あるとお互いが認識し合ってクラスタをくむ
- indexが生成されるとshard(luceneのインデックス)にして保管される
  ドキュメントIDのハッシュ値をもとにどこにルーティングするを決める
  shardをまとめてindexとして管理する
master node
- nodeがクラスタとして構成されるとmasterノードが決定される
  クラスタのステートはノードのリストやアドレスなど、インデックスのメタデータ、
  シャードのルーティングテーブルなどで構成される
cluster state
クラスタ構成中のみ存在する情報（永続化されていないという意味？？いや永続化されている？？？）
data
- データはproximity(近さ)によっていろんなレベルで保管される
- elasticsearch.ymlや--path.data on command lineでデータディレクトリを指定できる
- １つのdataディレクトリを複数のノードで共有することも可能
  data_dir内のサブディレクトリにノード別に保管しているので (data/elasticsearch/nodes/0　みたいな感じで確かにべつものになる。)
- state
  デフォルトでesはjsonフォーマットで保管している
  ymlファイル見るとformatとしてのjsonが指定されている（なんと、気づいてなかった） →んー、ローカルのやつはとてもjsonではない。設定もどこで指定するか見当たらない。。。
- node.lockというファイルがあり、競合がおこらないようになっている
- クラスタの_stateというディレクトリにはメタデータが保管されている
  （cluster setting apiのやつとかだっけ？）
- インデックス内のstateにはaliases mapping setting など　インデックスのメタデータ
  0 / 1 / 2 インデックスがシャードとして保管されている。
  ここにもstate(メタデータ)　これはシャードメタデータ
transaction log
- データ操作するとまずluceneのバッファに送られ、バッファをフラッシュするタイミングでluceneのインデックス二反映される（MySQLのbin-logみたいな操作ログかな？）
- これは時間がかかるのでいくらか、ためてから定期的に実行する（refreshのことか？）
- transaction logにはアクションを時系列に記録していく
- デフォルトでは５秒毎に反映される
- transaction log がいっぱいになるとluceneセグメントに反映される
- 落ちた場合はtransaction logを確認して復旧する
lucene segments
- every 30min 200mb or 500 operation
lucene indexについて
- lucene indexにはいろんな情報が格納されている
  転置インデックスの説明、わかりやすい。
- セグメント化されている例えばフィールドデータとしてドキュメント１にどんなトークン格納されているか、 doc2にどんなトークンが格納されているかといった情報
stored fields
- デフォルトで格納している
内部の動き
- クラスタの状態を確認しシャードがどのノードにあるか確認する
- シャード１つないで何が行われているか
  シャード内では各セグメントをなめていきます。１つずつ。
  １つのセグメント内では転置インデックスを確認してdistributedはdoc1にあることがわかる。
  つづいて日付でソート field dataより
- top 10 document correct for each shard -> grobal top 10 doucment
  masterがマージしている。
- シャード内ではノードで指定したドキュメントが格納されているセグメントから
  ドキュメントのテキストをひっぱってきてノードがシャードからかえってくる情報をマージしてレスポンスを返す。

QA time

フェーズを２つに分けてる理由は？

ドキュメントIDを割り出し（クエリフェーズ？）、フェーズ２で詳細情報を取得すると(fetchフェーズ？)
stored filedの情報が必要ない場合、フェーズ２はいらないんじゃないか？

シャードが返すidはドキュメントのidではなくてセグメントのidと位置。クエリフェーズで実行した場合luceneのidをかえす（内部的にはluceneの転置インデックスから内部のidをかえす）パフォーマンスが早いのでこのタイミングでフィールドは見に行かない先にトップ１０ドキュメントを洗い出してよりコストの高い処理をフェーズ２で行うユーザが指定したdoc id を全シャードで調べて返すと重いよ countだけつかうならばsearch-typeでフェーズ２をスキップできるよ

transaction log

検索パフォーマンスには影響しない（transaction log） fsyncはディスクに書き込まれていることを確認/ensureする作業そしてfsyncされた情報からセグメントを生成する esのrefreshを行うと発生する→transaction log の書き込みつまりtransaction logを生成したタイミングでは検索できない

apacheのアクセスログ解析に使っている人、多分Elasticsearchに入れたらログ消してもいいかな？的な？

jsonドキュメントをesに渡したらデフォルトではjsonまるまるesに格納されている esにすべての情報が格納されているという前提でよいか

多くのユーザーはデータリソースを別に持っていて簡単に再ビルドできるようにしているプライマリにはまだ使わないでほしい。別のとこにデータのこしておいて。

なぜクラスタstateの情報をnodeのレベルで持っているの？

クラスタは論理的なあつまりで、ノードの集合に名前が付けられたものクラスタはつまりノードが動いている間しか存在しないクラスタが消えた場合ノードでも動けるように個別に持っている

Shay Banon登場

なんでFDを設定する必要がある？

luceneインデックスは複数のセグメントで構成されているどんどんたくさんのインデックスを作っていくと、セグメントができまくって１つ１つのセグメントを検索する必要が出てくるたくさんセグメントができるとあるタイミングでマージする必要がでてくる効率的に検索するための最適なセグメント数がある

インデックスは複数のシャードで構成されていて、シャードは複数のセグメントで構成されていてセグメントは複数のファイルで構成されている。ので。FDの設定が大事。内部通信用にも使ったりするしね。

kibana

aggreagtionはkibanaのため。facetでは十分な情報がとれなかった kibana4が作られている。そっちをお楽しみに。１つのhistogramに異なるフィールドを出すこともできるようになる！！！これは期待！！

なんでesをつくったか

すげー暇だったからw icookという奥さんのためのレシピ検索を作りはじめたのがきっかけ。検索ボックスが１つあって何でもそこから検索できるような。そこからいろいろなものを使ってみたけどイマイチしっくりこない感じでー。

スナップショット機能を使っていて、現状２０００スナップショットあるんだけど性能でない！

POSTがめちゃくちゃ遅い。数が大杉？

スナップショットはインクリメンタル。過去分をみて保存できていないものを保存する仕組みなので、過去のスナップショット数が多くなると遅くなる。

定期的にあたらしくつくったほうがいいのか？

想定していない使い方かもしれないけど、それが必要があってやっているなら教えてください。なおしますよ。

relevanceあたりのドキュメントがちょっとわかりにくいかも？

まず、ドキュメンテーションは現在頑張ってます。無料のebookがあるので読んでみてください。 MVELからgroovyベースに移行している

githubにも情報があるよ。日本O'Reilly本でるらすぃ。

今後のビジョン

aggregationは今後に向けて、アナリティクスのプラットフォームとして躍進するのに重要な機能ツイートが何百万もあって検索した場合ヒットが多すぎて一つ一つ追うのは無理。 aggregationがあれば検索結果から全体を俯瞰できる。次のバージョンではaggregationがよりメモリ利用効率の高い形で実現できる。さらにfiled-collapsionも実装予定（？）

resiliency?にも投資している luceneはハッシュの確認とかしないからデータの破損とか検出しづらい。まずluceneにチェックサム検証機能を実装した、既にマージされている。次のesではチェックサムを様々なステージで確認する。シャードのマイグレーションとか。スプリットブレインとか。より分散デプロイメントが安定するはず。

ペタバイトデータを持っている人が再インデキシングするとすごい時間がかかってしまうけど改善したい。

esのデベロッパはイノベーションに費やす時間を十分設けている俺すごいの考えちゃった！なんてデベロッパがいればよしやれー見たいな風土にしている