140523最新インフラエンジニア技術勉強会

ドリコムのInfrastructure as Code

chef soloで収束している
他社でもChef-serverで有効な事例をあまり知らない

３つの *** Driven Infrastracture

  • Issue Driven
  • Pullreq Driven
  • マサカリDriven
    • コミットに容赦無いコメントを投げ込んでいく
    • 意識の高いモヒカンが四方八方からツッコミを加える
    • （気になっただけです）という圧力

テスト駆動インフラ

  1. serverspecで作業項目を記載
  2. GitLabでコードレビュー
  3. 開発環境で実行・テスト

  4. 本番環境で実行・テスト 基本はRunDeck
    serverspecはあまり強くないので

  5. 早く：Chef、CIツール、serverspec

  6. 正確に：PDCA
    P: Chef,serverspecコードレビュー
    D: Chef,Rundeck実行
    C: sererspec実行
    A: コード修正

Rundeck

リモートサーバのオペレーション管理が便利すぎるのに無名
すでにImmutable Infrastructureを実現して必要がないのかも？

Q&A

  • chefからこぼれる緊急修正はどういうフロー？

    • if文で限定的にやるのはどんどん苦しくなる、条件分岐に失敗するときもよくあった、特にchef-serverはきつい
    • Rundeckでshを動かせるので、それが通るようにテストを修正する
    • chef+sh(<-Rundeck)

  • ラピックがすべての作業を履歴・実行者管理している

  • サーバーコピー、chef、Rundeckの３つで適材適所な感じ

ドリコムにおけるWinning the metrics battle

Graphiteと戯れたり、インフラ改善施策とか

サーバー状態の収集と閲覧を簡単にできるようになるのは重要、しかし1300台を超えると工夫が必要

工夫をしなかったがための失敗について

  • Cactiに自動でグラフが作られない
  • Proxyや情報を暗号化する機能がなくてCactiが乱立した
  • スケールアップできない

このままだと破綻する！->

  • サーバ（モニタ対象）が自動で追加される
  • グラフが自動でレンダリングされる
  • 情報を中央に集めるのに必要な機能
  • スケールアウトができる

Munin, Gangria: 先輩「グラフが好みじゃない」で却下

  • 普段使いなので習熟度が低いものが欲しい、しかしいいものがなかった

→作った
↓

Mine

地雷を探すシステム

Ruby + Padrino + Backbone.js
Graphite : グラフ描画、メトリクス保存、URL API、プッシュ型

URL API

target=averageSeries(hoge-web-*.nginx.response=) ←関数
平均、移動平均、などなど、形式もSVG、PNG、json、CSVで返せる

プッシュ型

プル型→収集したいサーバーに取りに行く、手動で登録する（並列で取る）のは数百台で限界

プッシュ型→監視サーバーにそれぞれが送りつける 多少失われても困らないのでUDPで投げる

管理用サーバーをchefで構築するだけでノードが増やせる！

Collectd

Graphiteへ情報をプッシュするミドルウェア
軽くて、機能的に十分

Cactiとの違い

APIがない、グループできない、RRDなので画像しかない、プル型

今後

複数サーバーをサマライズしたり 100台の平均レスポンスを出す→見るグラフを最小化する 異常値がわかりやすいように →最大値・平均値・最小値をプロット →頑張りすぎ、サボりすぎを見やすくする

アーキテクチャ

複数データセンターのサーバー→各Collectd→暗号化して中央のCollectd→復号化→carbon(Graphite)→Mine

collectdは冗長化済み

carbonは暗号を受信したらハッシュで分割、データセットへ

データを書き込み→DRBDで同期、grapdite-webを叩いて見れる状態に 中央のcollectd→grapdite-webまでも冗長化済み

表示

UserがMineを見て、g-webにリクエスト、複数サーバーから探索

まとめ

1300台を5分間隔で取得 プッシュ型、手動では限界がある、Graphiteに蓄積するのはよさげ

Q&A

  • 5分間隔で１年分は保存されている
  • 100台だとほとんどかからない

Fruentd プラグイン開発

外山寛さん　株イプロス

運用ツールとして認識されつつあるFruentd プラグインを自分で作れれば威力が倍増します

elasticsearch勉強会もやってます

DevOps向けFluentd勉強会も

iprosで使ってるプラグイン、用語解説、開発プロセス

公開されているプア溜飲だけではやはり実現できないことが多い ビジネスロジックに依存した大規模なものも、プラグインなら

使っているプラグイン

  • redshift
  • elasticsearch
  • mysql-replicator
  • leftronic などなど

作ったもの

未公開

  • sedue
  • qiita
  • backlog

作る理由

  • ない
  • 微妙に使い方が違う、パラメータで吸収されない
  • 簡単に作れる、rubyでかける

用語解説

chunk

  • データの塊(recordがたくさん)
  • プラグインならHash型
  • このrecordをいろいろ操作するのがプラグインづくりのメイン

種類

  • buffer output
  • output
  • input
  • time slice output
  • multi output
buffer output
  • チャンクのキューを維持する
  • インターバルの指定
    • 真の意味でのリアルタイムではない
  • 送信失敗時の再送機能
  • 代表作
    • elasticsearch
    • growthforecast
使うとき

外部要因に依存する場合 失敗が許されない通信 逐次じゃなく、一括でやりたいとき

  • elasticsearch
    • 落ちていたら？
  • td
    • treasuredataで障害があったら？
  • redshift
    • awsで障害があったら？

→再送してくれる

output
  • 即時送信
  • 失敗時の再送機能はない
  • 真のリアルタイム、に近い

自分自身が処理のディテールを持っている時 信頼性を特に重要視しない データを加工して次のプラグインに渡すときとか

  • 代表作
    • rewrite-tag-filter
    • parser
input
  • 外部からの入力を定義
  • WEBAPIなどを入力にするとき、streamingっぽくするときには自力で実装する必要がある、APIの実装に依存
  • あくまでポーリング、イベントドリブンではない

  • twitterならstreaming apiに対応してるけど、qiitaは非対応→差分などは自力で

  • 使い道

  • WEBAPIのポーリング

  • DB、外部サービスのポーリング

  • 代表作

開発プロセス

ここからは想像だけで作ったベストプラクティスです

  • ローカルfluentdで開発
  • git push
  • td-agentで動作確認
  • gem push

fluentd -p xxxxxxで読み込んで開発 -cで設定ファイルを指定

  • 以下のメソッドを定義
    initialize Libraryの読み込み
    configure
    emit, wiret, run 実処理、ここがキモ

コールバックの処理をどんどん書いていく
buffer_outputのときはchunk(配列)で飛んでくる

パラメータの定義
データ型：string, bool, time, integer V1ではhashとarray、環境変数も使える模様

ここまでやって大体githubにpush

、gem push大変、そもそも社内でつかうから公開したくない →プラグインフォルダに.rbをコピーして再起動

.rb１つで作れます

必ずしもgemにする必要はありません、無理なくはじめましょう

td-agentテスト

fluentdを直接使ってる人は少ない印象
逆にfluentd使ってtd-agent使ってない人いる？→会場ではゼロ
rubyやfluentdのバージョンがズレる時がある 逆にtd-agentに合わせてやる travis-ciなどでバージョン横断ユニットテストを実行

リアルな話、プラグイン作り始めたら無茶ぶりにも耐えられるようになってきました

あんまり効率的じゃない結末、がなくなってきた

Q&A

  • エラー処理は？
    フォーマットのエラー処理はスルー、V1ではエラーを流せるっぽい
  • 単体テストのやり方は？
    人によってバラバラみたい

MySQLと組み合わせて始める全文検索エンジン"elasticsearch"

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

elasticsearch歴１年未満

こんな悩みありません？

  • MySQLを使っている、モダンな検索機能がほしい
  • ファセット検察
  • サジェスト機能
  • 位置情報検索
  • ネスト構造
  • RESTful API
  • 検索漏れの少ない日本語全文検索
  • Kuromoji

最近('14 2月)1.0が出ました、アツいです
そろそろSolrを追い抜かしそうな勢い

弊社でも検証が始まった段階です

MySQLとのデータ連携
Solrよりモダンである一方、互換性は作りこみの余地ありなので

今回のテーマ

  • 実データで連携検索したい
    • スモールスタートしたい 既存の更新系処理に触りたくない メインはMySQL、検索のみにelastic RDS for MySQLにも応用できる、手離れの良い構成にしたい

異種RDB間の同期

作りました
↓

Yamabiko

y-ken/yamabiko

CentOS6向けrpm配布中

削除検知ができる PKeyキャプ判定で実現、数上万行でも動くけどちょっと重たいです

  • BinaryLogではなくSQL結果で同期する理由
    • JOINなしでやるNoSQL概念に対応させるため
    • 非正規化VIEWテーブルを作ることを想定している

新たな課題

差分検知が遅い問題 各行のハッシュ比較が重い

→作りました
↓

elasticsearch_mysql_importer

MySQLデータ→elasticsearch の手間を最小化するツール
Yamabiko同様、ドキュメントのネスト化が可能

y-ken/elasticsearch_mysql_importer ただいま公開
(ライブrake release)

利用例

  • 実装なしにMySQLレコードを流し込んで検索へ
  • １レコードに複数紐づく属性情報をネスト構造で検索したい
  • 非リアルタイム更新なWebサービスでの利用
    • 求人、賃貸、グルメ、商品情報、口コミ
  • 都度インデックスを作り直す、１００万行程度想定

Groove Incrementっぽい構成
利用サーバをデプロイごとに切り替える、blue-green deployment手法

git clone...
cd elastic...
bundle install --path ven...

vim example.rb

curl -s _XPOST localhost:9200/_bulk --data-binary@request.json

ユニークキーを指定、出力先パス指定、

ネスト構造化の仕組み

  • skills
  • member-skill
  • members のパターン

jsonの"skills": 以下にネスト構造で
プリペアドクエリ設定を使って、tmpテーブルを作っている SELECT skill_name, skill_url FROM tmp_member_skill WHERE member_id = ${member_id} AS skills

あまり複雑なことをせずにネスト構造を実現しました

まとめ

  • elasticsearchが本格的に使えるプロダクトへ成長した
  • elasticsearch_mysql_importerで手軽に始められる
  • elasticsearchの国内トレーニングや日本語書籍もあります
    　　core elasticsearch on jul 14 in tokyo @赤坂
    　　「Elasticsearch on Server」