判ったつもりのserfメモ

仕事で数10台のサーバをどうたらしなければならなくなりました。今更何を言ってるのかと「その筋」の人から言われそうですが、別に小生はインフラで売ってるわけじゃなくてプログラマですから。

PHPなんかのプログラムを、その数10台がWEBサーバだとすると、サンハイと入れ替えなければならない。手動でrsyncとかあり得ません。となると、とりあえずexpectで頑張ってもらってましたが、流石に数10台に何回もとなると、待ってる時間が惜しい。もっと早く終わってくれた方が有難い。

expect自身をforkするとか色々手はあるわけですが、tclsh標準でforkは無いっぽいので、どうせ作らなきゃならんなら他の選択肢を使うかと。。

もちろん有りました。

https://github.com/hashicorp/serf

serf自身は、農奴って意味らしい。ノード？まさかね。

難しい言い方をすると

• サービスディスカバリに使える
• オーケストレーション（組織化、らしい）に使える
• イベントプロパゲーション
• 大雑把な人はメッセージングツールと呼ぶ

要するに前述のサンハイを手伝ってくれるプログラムってことらしい。それ以上でも以下でも無さそう。本業は分散ノード間のメッセージ転送ですが、それだけで終わっちゃ困る。ついでに何か処理してよと。

• 特定のホストを持たず、7946ポートでノード間で通信しあう。
• 一個のノードでイベント発行すると、全ノードに分散配信してくれる
• オーケストラに例えれば指揮
• 受け取った「イベント」に対して、そのノードが何をするかは、serf.conf で先に定義しておく必要がある。
• オーケストラに例えればそのパート楽譜

特定のホスト＝指揮者？を持たないので、オーケストラ＋指揮に例えるのは適切ではないかも知れません。結果は似てますが、実際には指揮者は人間で、指揮の伝搬は演奏者間の伝言ゲームなので、手段は大きく違う。

ただ昨今の風潮で、単一故障点を持たないというのは重要。その上で、人間が操作をするための入り口ノードを固定して運用する、というのはアリでしょう。

結果的に、このシステムは、デプロイ用というよりは、インフラ構成の変化に対して、何かの定義ファイル類を動的に変える時に良さそうですね。

• muninの監視ノードを、マスタに追加するとか
• MongoDB replicasetsの
• ノード追加で、WEBサーバからの接続定義を書き換えるとか
• ノード停止で、（replicasetsクライアントの切り替え判定を待たずに）WEBサーバ側の接続定義のprimary順序を入れ替えるとか

これらすべてが「ホスト○○を△△用に追加したよー」というイベントの発行だけで「ヨロシクやってくれる」わけです。素晴らしい。何か変える度に定義ファイル書き換えてcommitしてテストしてデプロイしなおしとか頭悪いな思ってたんですよ。

もちろん「ヨロシクやってくれる」様にserf.conf自身をメンテナンスしなきゃならないし、それは小生自身の仕事だったりするわけですが、それは先に仕込んでおく話。いざ事が起こったら、「ヨロシクやってくれる」有様を眺めてニヤリと笑う。とイイネ。