最新インフラエンジニア技術勉強会に行ってきました #dli_infra

最新インフラエンジニア技術勉強会に行ってきました #dli_infra

昨夜、ドリコムさんで行われた「最新インフラエンジニア技術勉強会 〜Fluentd, Elasticsearch,Chefの実践実例〜」に足を運んできました。

タイトルにもありますように、Chef, モニタリング, Fluentd, そして elasticsearch が使われている現場の情報を伺える機会となりました。

それでは、いつものようにノートをアップしておきます。

概要

19:30-20:00     ひらしー    ドリコムのInfrastructure as Code
20:00-20:30     mickey  Winning the metrics battle
20:30-21:00     外山 寛  Fluentd プラグイン開発講座
21:00-21:30     yoshi_ken   MySQLと組み合わせて始める全文検索エンジン「elasticsearch」
21:30-  懇親会

ドリコムのInfrastructure as Code

ひらしーさん @y05_net(ドリコム)

  • 規模
    • 1億PV以上
    • 100万DAU以上
    • オンプレ300台
    • クラウド1,000台
      • 30〜50台の規模で拡大中
    • インフラ担当 3人
  • Chef運用
    • Chefサーバ立ててる
      • 以前はこれだった
      • 100台越えた当たりだけでCouchDBがボトルネックに(10系のころ)
      • 定期的収束がうまく行かなかった
    • Chef Solo構成もある
      • プロビジョニングにあたってChefサーバはいらないという判断
  • 開発フロー
    • CI環境構築済み
      • GitLab + Jenkins(VirtualBox CLI) + Foodcritic (lint) + serverspec (test)
    • 本番反映
      • Rundeck (SSH経由で一括実行) + serverspec
      • Zabbix APIで対象ホスト一覧を取得
  • コードのメンテナンス
    • 3つの○○ Driven Infrastructrure
      • Issue Driven
      • Pull Request
      • マサカリ (ツッコミ・議論)
  • serverspec
    • テストシナリオの切り替えにYAMLを取り扱えるラッパを書いている模様 (どこでもやってるんだな)
  • Chefサーバ
    • 有効活用できている事例をあまり聞かないんだが… (確かにな)
  • Rundeck
    • 便利すぎるのだが無名 (僕も今日知った)
    • アプリのデプロイで使うCapistranoと被らなくてよい
    • 履歴も管理できるそうだ
  • パラメータチューニング
    • ifで分岐は辛い。失敗するし、障害が出てしまうこともあった。
    • 設定ファイルのみ更新。Rundeck で一括実行。
    • 設定ファイルのバージョン管理は実はあまりしていない。
    • サーバ増やす際は、サーバコピーで対応。
      • ってことは、Chefは初期構築のみでやってるって感じだろうか。

Winning the metrics battle

mickeyさん @mickey1982 (ドリコム)

  • Graphiteと戯れているゼイ!
  • 1,300台を越えたあたりで、パフォーマンスモニタリングで工夫が必要になってきた。
  • 工夫をしなかった事による失敗
    • Cactiで自動追加できない (わかるわかる)
    • CactiではDC間でつなぐのにエラい大変 (わかるわかる)
    • Cactiはスケールしない (わかるわかる)
  • 要求
    • 自動追加
    • 自動でレンダリング
    • 中央集約の方法
    • スケールアウトによって支えられる台数を増やせる
  • 検討結果
    • 比較
      • Munin: 見た目が好みでなくて却下
      • Ganguria: 同上
    • 習熟の難易度が低いもの
    • やっぱない。開発した!
  • Mine
    • ドリコム自作モニタリングシステム
    • CactiっぽいView
    • Ruby 2.0
    • Backbone.js Padrino
    • Graphite (メトリクス保存・レンダリング部分)
      • URL API
        • ビューをAPIで管理 関数を適用する
        • ファイルフォーマットも柔軟に対応
      • Push型
        • CactiはPull型 サーバ側がスケールしない
        • デーはUDPでサーバに投げつけている データロストは多少許容している
        • Chefでエージェントを送り込んでいる
      • Collectd
        • 動作軽い・機能充分
        • Collectdを踏み台に立たせて暗号化して集計側のCollectdに投げる
        • Collectdは冗長化済み
    • アーキテクチャ概要
      • モニタリング
        • 極端に低い・高い負荷のサーバを見つける → 対策の糸口にする
        • 5分間隔
        • 1年保存
      • 受信・保存
        • Collectdのデータはハッシュベースでシャーディングしている
        • CollectdのノードはDRBDで冗長化
      • 表示
        • Mine側で、情報を持っているGraphiteのノードを探して表示。
        • データの再利用もしやすい。
  • Cactiの辛い所
    • APIがない
    • グルーピングして統計処理できない
    • RRDだ
    • スケールしない
    • (わかります。わかります。)

Fluentd プラグイン開発講座

外山 寛さん @toyama0919(イプロス)

  • スライド: fluentdプラグイン講座
  • 先端ツールの領域から、進んだ感ある。運用ツールとして普及してきた。
  • 使っているプラグイン
    • RedShift
    • Elasticsearch
    • mysql-replicator
    • leftronic
    • その他10個くらい
  • 自作プラグイン
    • mysql-bulk
    • split
    • incremental
    • file-sprintf
    • backlog (エラー通知) (未公開)
    • sedue (未公開)
    • qiita (未公開)
  • 自作の理由
    • 公開されているものが無い。
    • 用途が微妙に違う。
    • 簡単。
    • Rubyでいきやすい。
    • 企画担当者からの無茶振りに対処。
  • プラグイン分類
    • Buffer Output
      • チャンクのキューを維持
      • インターバルの指定可能 (デフォルト 1分)
      • 真の意味でのリアルタイムではない
      • 再送機能あり (ここポイント)
      • 事例: elasticsearch, redshift, growthforecast
      • 用途: ディティールが外部要因、失敗できない、まとめて実行したい、等。向こう側が落ちてたら?を考える。
    • Output
      • 即時送信
      • 再送機能無し
      • ほぼリアルタイム処理可能
      • 事例: rewrite-tag-filter, etc…
      • 用途: 信頼性重視しない、自分自身がディティールを保持している場合、次のプラグインへの中継ぎ、等。
    • Input
      • 外部からの入力を定義できる
      • WebAPI等を入力する時はStreamingっぽい実装をする必要あり
      • あくまでポーリング。Event drivenではない。
      • 事例: mysql, dstat, etc…
    • Time Slice Output
    • Multi Output
  • 開発プロセス (自分なりの、という前置きあり。)
    • localのfluentdで開発→push→td-agentで動作確認→使う
    • 実装するメソッド: initialize, configure, emit, write, run
    • gemにするの面倒
      • 無理にせんでもいいで
    • td-agentでテスト
      • Ruby, gemのバージョンがずれる
      • td-agentにあわせれば問題ないだろう
  • 質疑
    • フォーマットエラーは、スルーしている。
    • 単体テストは、人によってバラバラ。 (ベストプラクティスあるのかな)
  • 参考情報

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

yoshi_kenさん (リブセンス)

  • elasticsearchを使った検索システムを手軽にはじめたい時に、どうするか。
  • Yamabiko
    • 削除検知ができる 数十万行でも対処可能
      • SQLの結果を同期するためMySQLの本体に手を入れなくても良い
      • BinLog APIを使う場合はMySQL本体に手を入れる必要がある
    • 差分検知が遅い (行のハッシュ検知が遅い)
  • elasticsearch_mysql_importer
    • 都度再同期
      • 差分検知の遅さをこれで解消
    • Bulk APIでドカンと流し込み直している
      • これの方が結果としてパフォーマンスが出るらしい
    • 使い方
      • 実装無しにMySQLのレコードを流して検索したい
      • 実際は、Blue-Green Deplyomentの要領で、elasticsearchのサーバを切り替えながら使う。
    • (この後は、主にプロダクトの利用法。)
    • ネスト構造化
      • 正規化したデータを要領よくまとめあげるために使う(のだと思う)
  • 使ってね!

感想

Chefは私も仕事で使っているのですが、実際に使っていると起こる問題について、どのように回されているのかを伺う事ができ、非常に参考になりました。

モニタリングは、どのようにスケールさせて行くのかの事例の一つを伺う事ができました。その中で、台数が増えてきた時の戦略の立て方を学ぶ事ができました。

Fluentdは、ITインフラを支える点でも、もっと活用する方法があるのでは、と考えさせられました。使い切れてないなと反省しております。

elasticsearch は、もし使うとするならどうやって運用を回そうかと、想像しながら聞いておりました。

講演者・幹事の皆様、どうもありがとうございました。そして、会場を提供いただいたドリコムさん、お世話になりました。

LINEで送る
Pocket