cloudpack の かっぱこと 川原 洋平（@inokara）です。

各種情報

講師

発表資料

関連資料

以下、関連する資料ですので当日の資料ではありませんのでご了承下さい。

当日の資料が公開されましたら追加します。

Serf と Consul について

@zembutsu さん

いきなりでもデモ

  • バイナリ一個で動く！（他のオーケストレーションツールとは一線を画す）
  • 速攻でクラスタが構築される
  • serf members
  • serf event
  • 寝ていても大丈夫w

この先生きのこるには…（前置き）

  • 一年前の業務知識ですら通用するかどうかわからない
  • Software Design に寄稿
  • 現在の農業情報化ソリューションは高価
  • 農業生産情報をオープンに
  • まず、目の前の業務を自動化

Docker 入門（前置き）

  • まずは触ってみよう
  • Docker = エコシステム
  • Docker は使えない？（クラウドが台頭してきた頃と同じ）
  • Docker と ドラ◯もんと色合い似てない？

オーケストレーションツール？

  • 自動化（オーケストレーション、機械化、システム化）
  • 指揮者
  • 楽（楽しい = 楽）
  • Apache Mesos などなど…
  • Serf と Consul は中でも「シンプル」
  • なんでもやってくれる夢のツールではない
  • 一斉に何かをやってくれるツール

Serf 基本編

  • 軽量なオーケストレーションツール
  • 全ノードで秒単位でイベント同期
  • メンバー一覧とイベントの発生を管理
  • 障害検知、フェールオーバー
  • 簡単軽量（バイナリ一個、ロールのタグ機能）
  • サービス検出とオーケストレーションツール

Serf の三つの特徴

  • メンバ管理
  • 障害検知
  • カスタムイベント
メンバ管理
  • ゴシッププロトコル
  • マスターサーバーが不要
  • クラスタ参加、離脱を管理
  • タグ機能（タグ毎にイベントを発生出来る）
  • A => serf join => B が応答
  • A が B を認識（メンバージョイン）
  • C は A or B のどちらでも serf join を投げれる
  • C => serf join => A
  • B は A が C とメンバーになったことを認識する
障害検知
  • B が突然の死 => A が検知 => C にも伝播してクラスタ全体に伝播
  • B が切り離される（一台でも B がダメと検知したら…）
  • 但し、NIC が二つあったりしたらフラッピングが発生する可能性はある
同期イベント
  • serf event
  • 100 ノードでもすぐに伝播する

適用例、他のツールとの比較

  • Zookeeper と機能が類似

Serf の使い方

  • serf member
  • serf join（マルチキャスト環境は -discover=xxxx コマンドを使えば join 先の指定は不要）
  • serf event

イベントハンドラ

  • イベントに応じてコマンドを実行する

設定ファイル

  • json ファイルにて指定可能

Serf のまとめ

  • 簡単軽量、オーケストレーションツール
  • serf と consul を使えば仕事が楽になりますよ

Consul

  • サービス検出（Consul エージェントがサービス一覧を作ってくれる）
  • 障害検知
  • マルチデータセンター（おまけ）
  • キーバリューストア（おまけ）
サービス検出
  • api や mysql という service 名で定義
  • 検出は consul ノードで自動的に開始
  • HTTP API 又は DNS で結果を返す
  • 各種監視ツールとの連携
その他
  • KVS
  • DNS のロードバランサ機能
  • Blocking Query
  • Consul 0.4 からイベントハンドラ機能

Zabbix の運用自動化

  • Serf へのメンバージョインをトリガーに Zabbix の監視対象を追加する
  • Zabbix API を利用する

全体的なまとめ

  • Serf と Consul は軽量シンプルツール
  • 敷居が低い（軽量バイナリ）
  • API を使ってツールを結びつけ自動化を支援する
  • オーケストレーション技術の部屋（Google Group）

About Consul

@ijin さん

自己紹介

トラブルシューターズ

Consul とは

  • HASHICORP
  • HTTP API と DNS で操作出来る分散クラスタ
  • 簡単に Service を登録して自動でクラスタ上で検出可能
  • DNS や HTTP で操作
  • ヘルスチェック機能、死んだノードへのリクエスト迂回
  • マルチデータセンター
  • キーバリュー（動的な設定情報置場）
  • ロングポーリング

テクノロジー

  • Raft / FSM
  • Serf（Gossip Protocol）
  • Sessions（Chuby）
  • TLS / なんちゃらテスト…（忘れた）

アーキテクチャ

  • agent
  • server モードの集合 = peer set
  • client モード
  • server はリーダーでなければリーダー server に対して forwarding する

一貫性

  • CAP Theorem
  • Raft の consensus protocol
  • リーダーノードから他の server にレプリケーション
  • quorum に該当する台数 server に書き込みが出来たら commit
  • default : Mostly Stongly Consistent
  • read : quorum に達するノードの数に問い合わせを行う
  • stale : リーダー以外の server が情報を返却可能
  • https://speakerdeck.com/ijin/about-consul?slide=15
  • JEPSEN Testing を使って保証している
  • server は3 台から 5 台からお薦め

Consul Agent

HTTP API
  • HTTP API
  • kv（KVS にデータを登録、取得、パラメータ raw）
  • agent（agent への問い合わせ）
  • catalog
  • health（自身のノードへのサービス監視 / Exit Code 0 or 1 or other）
  • Clocking Query（Long Polling を使った監視）
DNS Client
  • DNS(bar.node.consul / tag.hoge.service.consul)
  • DNS Caching（Stale Reads / TTL）
Use case
  • Internal DNS
  • インベントリマネジメント
  • フェールオーバー
demo

ベンチマーク

  • 当初 TTL が無かった
  • v0.3.0 からかなりパフォーマンスが向上（GET は 5 倍程度向上、PUT は 4 倍、レスポンスタイムは 6 〜 7 倍）
  • 一貫性レベルに関しては多少差がある

Consul-API

  • Go のライブラリ

感想

  • 今まで Serf や Consul に対してはふわっとした認識しかなかったが一貫性に関する挙動やどんな場面で使うのか等がイメージ出来ました
  • あと、ハンズオンとかあるとさらにイメージをつかめるのでは…
  • Serf や Consul と同じような機能を提供する他のツールとの比較等があるとより Serf や Consul について理解を深められるような気がしました
  • 最後になりますが…講師の @zembutsu さん @ijin さん、ハートビーツさん有難うございました！