はじめに
表題の件、実は100%解消していないため不完全燃焼な感じの記事となっておりますのでご了承ください。
（もし完全解決したら記事をUpdateする予定）
サーバ構成
| ロール | バージョン | インスタンスタイプ | 台数 |
|---|---|---|---|
| Consul Server | 0.5.2 | t2.midium | 3 |
| Consul Agent | 0.5.2 | ごちゃまぜ。t2.microが多いかも | (秘密..結構大きいと思う) |
現象について
日に１、２回ほどこんなログが出力される。
どこか（不確定）のノードが一時的にFailし、すぐにJoinし直す。
現象としては 以前 に書いたのと似てはいるが、頻度が低い。たまに起こる程度。
2015/11/30 06:09:25 [INFO] memberlist: Marking hogenode as failed, suspect timeout reached
2015/11/30 06:09:25 [INFO] serf: EventMemberFailed: hogenode xxx.xxx.xxx.xxx
2015/11/30 06:09:25 [INFO] consul: member 'hogenode' failed, marking health critical
2015/11/30 06:09:27 [INFO] serf: EventMemberJoin: hogenode xxx.xxx.xxx.xxx
2015/11/30 06:09:27 [INFO] consul: member 'hogenode' joined, marking health alive
今のところ、うちではクリティカルな使い方をしていないのでそれほど問題になっていないが、
nginxコンフィグやデータストアのエンドポイントをConsul Templateなどで適用している場合に困るかもしれない1し、そもそもスッキリしない。
対応
いくつかissueなどを眺めてみて、出来る限りConsulの負荷をかけないように設定しなおしてみることにした。
基本的には こちら の情報を参考にしてみる。
決め手となる感じではなさそうだが、やらないよりはやったほうが良さそうだし。
- Consul本体
- ConsulのGOMAXPROCS>=2 にする
- TTLを設定する
- ネットワーク性能の良いインスタンス(M4など)に移行する
- MTUの調整？
- Consul Template
- max-staleの値を設定する(0.11.0以前のバージョンを利用している場合は特に注意)
実際に行ったのは Consul本体の 1.2. と、Consul Templateの max-stale 対応。
結果
それなりに改善し、頻度は減ったように見える…が、 0になったわけではない 。
ちなみに、効果があったかなーと思うのは GOMAXPROCSとConsul Templateの設定ではないかなと思っている。
考察
０にならないのは何故なのか考えてみる。2
わりとヘビーな使い方してる
このクラスタは結構な数を管理しているが、
追加／削除が数十台レベルで／日常的に／しかも頻繁に行われる環境である、ということ。
より負荷がかかっているのかもしれない。
クラスタ内にt2.microがたくさんいる
クラスタ内にt2.microが半数近くいるのが原因説。
ネットワーク性能がかなり低いので、クラスタ全体的のパフォーマンスに影響を与えているのではないか。
特定のサーバがなんらかの原因でネットワーク過負荷になっていたのかも
以前別エントリにも書いているが、どれか一つのサーバ・ネットワークが劣化すると全体的に不安定になる事案が発生していた。
もしかしたらFailしている時間帯に、特定サーバのネットワークが重くなったりしているのかもしれない3
あとがき
調査にまとまった時間が取れず、中途半端な結果に終わってしまいました。
手が空いたらもう少し詳細に追いたいなーと思っています。
全然関係ない話
Consul Template、久々に見たらファンクションすごい増えててびっくりした。別記事で書きたい