こえむの編集後記

コンピュータ スキー そして旅の話を綴ります

ITインフラ プログラミング 催し

最新インフラエンジニア技術勉強会に行ってきました #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 は、もし使うとするならどうやって運用を回そうかと、想像しながら聞いておりました。

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

関連投稿

ITインフラ 催し

SRE NEXT 2024 に参加してきました #srenext

ITインフラ

趣味の #AWS – koemu.com の内側

催し 日記 音楽

初・ピアノの発表会で息子と連弾をしてきたよ #ピティナ

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy