はじめに
AWSやGCPやAzureなどには、オートスケーリング機能というものがあり、サーバーを増やすと自動的にロードバランサーのメンバーに追加してくれる機能が提供されています。
しかしながら、nginx にはオートスケーリングの機能がありません。
この方法を考えてみます。
方法
パターン① NGINX PLUS
これが本命です。
nginx の有料版「NGINX Plus」には WebAPI が提供されており、この API を使用してメンバーの追加・削除を行うことができます。
ドキュメントを読む限り使用方法も簡単で、HTTP のリクエストを送信するだけで使用できます。
curl -X POST -d '{ \
"server": "10.0.0.1:8089", \
"weight": 4, \
"max_conns": 0, \
"max_fails": 0, \
"fail_timeout": "10s", \
"slow_start": "10s", \
"backup": true, \
"down": true \
}' -s 'http://127.0.0.1/api/9/http/upstreams/appservers/servers'
詳細は以下参照。
しかし、問題は価格です。
NGINX Plus は現在公開されていませんが、古い情報によると約 1350ドル/年 のため、年間20万円ほどの料金となります。高い!
現在は、F5 Networks に買収されたため、価格は AWS のマーケットプレイスによると約 3500ドル/年のため、年間50万円ほどが現在の価格のようです。さらに高い!
安く購入する方法もあるのかもしれませんが、どちらにしてもまぁまぁ高いです。
オートスケーリングを使用するような大規模サービスであれば価格としては妥当かもしれませんが、私のような個人で使っている人には厳しいものがあります。
パターン② DNSを使用する方法
次点の候補です。
NGINX には、DNS で IP アドレスを取得する機能があり、これを使用して分散先を自動的に適用することができるようです。
つまり、サーバーが増えたらDNSに追加し、サーバーが減ったらDNSから削除することで、オートスケーリングを実現できる、というものです。
location / {
resolver 172.43.1.2 valid=10s;
set $backend https://demo-app.com$uri$is_args$args;
proxy_pass $backend;
include proxy_params;
}
デメリットは、DNS サーバーの維持管理が必要な点と、DNS への反映部分は別途実装する必要があります。
特に前者は重要で、DNS サーバーがダウンすると通信の分配が行えなくなる可能性があります。
AWS の Route53 など、高可用性+API機能を持った DNS サービスと組み合わせるといいと思います。
パターン③ 自作
APIを自作するという方法もあると思います。
しかし、Githubを調べてみた限り、同様のことをやっている方は居なかったので、あまりメジャーではないようです。
パターン④ アプライアンスLBの仮想版
NGINX ではなくなりますが、ロードバランサーが必要な場合は、F5 Networks や A10 Networks のロードバランサーの仮想マシン向けエディションを使用する方法もあります。
どちらも API 機能が標準で実装されていたはずです。
お値段も NGINX Plus とそれほど差はありません。F5に至ってはNGINX Plus より安いくらいです。通信量の制限はありますが。
F5 Networks BIG-IP Virtual Edition 200Mbps $2964/年
A10 Networks vThunder 100Mbps $5466/年
結論
結論として、私は手動のままにしておこうと思います。
今のところサーバー台数は10台ほどのため、年間50万円もかけられないためです。
ただ、さらにサーバーが増えるようであれば NGINX Plus の購入も検討しようと思います。
Active Health Check も便利ですしね。
いずれにしてもスケールの変更判定は自作する必要(Zabbixの機能でできそうでしたが)がありそうですし、この辺はオンプレの面倒なところです。
Kubernetes が流行る理由も分かります。
コメント