はやさがたりない。

へっぽこぷろぐらまのメモログ

elasticsearch 勉強会 第6回

Elasticsearch

Aggregationあれこれ

  • Facetはdeprecated。2.X系でなくなるらしい
  • Group by color : Bucket
    検索結果のドキュメントを分類
  • Count(color) : Metric
    Bucket内のドキュメントのデータをもとに計算
    ドキュメント数、平均値や最大値など
  • shard毎にAggsして、最終的にノードがマージする
    検索と同じ仕組み、クエリフェーズで実行
  • post_filterはAggsの影響を受けない
  • filterr aggsはAggsのみに影響して、検索結果には影響しない
  • Bucket
    • terms Facetの代わり、結果は近似値
      shard毎で最初に足切りされている。shard_sizeを使うとチューニングできる
    • significant terms
      異常検知、レコメンドなどに利用？
    • keydクエリ
      結果にkeyをつけて名前がわかりすくできる
  • Metric
    • stats はmin/max/avg/sum
    • cardinality SQLのDistinct
      近似値(HyperLogLog++) 最大40,000まで指定可能
      precision_threshold あげるとメモリを消費する
    • persentiles パーセンタイル
      compressionでメモリ使用量を調整可能
    • top-hits ★ $expand ?! グルーピングされた検索結果（Filed Collapsing）に検索できる
      Bucket内のドキュメントを結果として出力
      メモリを食うらしい。
    • scripted metrics 1.4.0で導入予定

秒間3万の広告配信ログをElasticsearchでリアルタイム集計してきた戦いの記録

  • ディスプレイ広告配信DSP Smalgo
  • 広告主 -> DSP -> アドネットワーク/SSP -> ユーザ
  • impression / click / conversion それぞれでログを出しており
    FluentdでElasticsearchに入れる
  • mark 行動履歴もログに落とし込んでElasticsearchに入れる
  fluentd 10node -> ELB -> | Elasticsearch coordinate Node  (write)   2node r3.large
  kibana         -> ELB -> | Elasticsearch Data Node        (read)    2node r3.large
                           | Elasticsearch searchNode                28node
                           |     12shard 1replica r3.xlarge / 1GB SSD
  • kibanaはエグイクエリを発行するので使いすぎると負荷が上がるｗ
  • 柔軟だがインデックスとドキュメントの設計は大事
  • 1日1.5TB (primary & replica)
  • データドライブのEBSをSSDに変更して高速化
  • 検索処理のキャッシュ化（ElastiCache）
  • バージョンアップの話はうちでも使えそう
  • indexingのパフォーマンスアップ -> johtaniさんのブログ

Elasticsearch日本語スキーマレス環境構築と、ついでに多言語対応

  • dynamic templates & index templates を駆使する
  • dynamic templates
    • 最初にマッチしたtemplatesが使われる
  • index templates
    • nodeの再起動は必要なく、新規で作成したインデックスのみに適用される
    • _analyzer path langage
      -> 多言語対応の部分は後で見たい

elasticsearchソースコード読みはじめてみた

非常に勇気をもらえた。
おらでもソースを読めそうだ！？

  • クエリを受けて結果を返す部分から読むのがベター と言われたものたどりつくのも大変！
  • ノード起動から導入した時のお話

reroute APIを使用してシャードの配置を制御する (LT)

  • 複数シャード移動のはまりどころ
    自動再配置に注意！自動再配置を抑止するべし。
  • Bonsai is cool !!
  • shardの移動でRemoteTransportExceptionが頻発
    （shardが多すぎる？）

タグを振って配置することもできる(whereness?)

検索のダウンタイム0でバックアップからIndexをリストアする方法 (LT)

  • snapshot & resotre api
  • 無停止でバックアップできる！
  • リストアにはIndexをいったん削除 or closeする必要がある！無停止できない！
  • index alias & restore api rename_replacement field
  • リストア実行後にAliasの削除！ → include_aliases : false

サーバ・インフラエンジニア養成読本　ログ収集～可視化編　勉強会

Elasticsearch fluentd kibana

最近、行ってきたブログばかり。。。
もうちょいがんばりたい。。。

サービス改善はログデータ解析から

すずけんさん @suzu_v adingo

  • 分析はコアだ
  • データの分析はチームで作るもの
    そして、データを活かせるようにするエンジニアが必要
  • 収集、変換、保存、分析、表示、運用
  • 「ログ分析は後にして機能追加をしましょう」ありがち
  • とりあえずやってると何とかなる
    可視化してから考えよう
  • チームとして「データを活かそう」というスタンスにならないと進まない

Fluentd

よしけんさん @yoshi_ken y-ken リブセンス

  • 再送処理など、ネットワーク周りの例外は任せられる
  • Rubyを用いたプラグイン記述のハードルは低い
  • ログ収集コストの最小化
    時差もなくなる
  • tailプラグインはファイルのローテーションにも対応
  • レイテンシの改善、帯域バーストの緩和
  • ファイルやDBといった複数データストアへの保存も可能
  • QoS レベル At Most One
  • 変更のないシンプルな処理のみを担うといい
  • 各ノードは単一責任がいい
    • 転送元ノード
    • 集約ノード（Aggregator）
    • Processor
    • Watcher
  • シングル構成や複数構成も組める
  • 固い運用には向き不向きがある

Elasticsearchもうちょっと入門

@johtaniさん

  • サジェストもあるんだ
  • クラスタの監視もできる？
  • Logstash １回 Redisにため込む！？
  • aggregation
    • 階層的な集計、グループ化
    • 動的な集計、グループ化
    • Bucket　ドキュメントのある値ごとに結果をグルーピング
      男性、女性など
    • Metric　ドキュメントの持つ値を集計
      ツイートの文字数の平均、最大値最小値とか　

Kibana

みちいしゅんすけさん @harukasan pixiv

  • 17回/1日 デプロイ
  • グロースチーム
    • サービスのグロースのためになんでもやる人たち
  • 可視化も継続的デリバリーの手段の一つ
  • fluent-plugin-elasticsearch作者
  • 3割くらいが使っている
    • クエリ：ログを検索
    • フィルタ：すべてのクエリに適用
    • パネル：どう表示するか
  • Dashboard
    見たい数値が1画面に収まっている
    1つのデータに対して複数の面から分析する
    毎日・毎週継続して変化をみることができる
  • タグ deployとかイベントを

  • Trends 1週間前との傾向

  • つくってから「Share」で一時URL
    ミーティングなどで見るようにする

  • GoogleBigQueryを間にかましてデータ量を絞る

パネルディスカッション

  • サーバ/インフラエンジニア？

    • 趣味でいれた
    • ログエンジニアがいた

  • ログ解析

  • 前はGoogleAnalyticsとか、体系化された方法があったわけではないと。

    • GrowthForecastとか
    • DataWareHouse / BI (たぶろー)
      • EFK は DataWareHouseのモダン版

  • データどうしてる？

    • ため込んだやつ消してます or 閉じてしまう
    • 生データはS3
    • 直近版と長期版2段階構成が定番

  • A・Bテストしてたら数値しか見なくなった
    直感というか感覚も大事。数値は一つの指標

  • Elasticsearch使うならmemoryはつめ！

  • 認証方法

    • LDAP認証
    • メソッドをふさぐ
    • @typesterさん Googleアカウントでできる認証Proxyを作ったのでそれを使うのもあり

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

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

Elasticsearch

total_shards_per_node

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

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

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

DevOpsを考える

devops agile

開発から運用へ

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

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

運用の現場

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

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

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

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

現場を見て、DevOpsに悩む

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

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

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

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

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

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

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

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

DevOpsについて学ぶ

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

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

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

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

結局は、

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

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

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

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