内部ELBの負荷分散 (Internal ELB) - 雑多なインフラエンジニア日記

自分用にメモ。

複数台あるMySQLスレーブサーバへの参照クエリの負荷分散は
LVS(keepalived+ipvsadm)、HAproxy、またはアプライアンス製品
(BIG-IP/A10/Zeus)などで、構成するのが一般的かと思います。

AWSには言わずと知れたロードバランサー「ELB」があります。
外部(インターネット)からのトラフィックだけでなく、プライ
ベートサブネット(VPC)間のトラフィックも負荷分散できます。
※通称内部ELB。ELB作成時にinternalにチェック

ELBについて分り易い資料

http://aws.typepad.com/aws_japan/2012/06/internal-elastic-load-balancers-in-the-virtual-private-cloud.html
http://www.slideshare.net/AmazonWebServicesJapan/20120521-awsmeisterelbascwpublic
http://understeer.hatenablog.com/entry/2012/02/12/044822

んが、この内部ELB、対RDSに対しては、負荷分散できません。

なので、超個人的オススメ構成は

1. RDSのマスターをそこそこ高いグレード(ラージ、エクストララ

ージあたりでMultiAZ)のモデルを選択する。リードレプリカ無し！

メリットは、内部ELBが不要で、1つのEndPointだけ気にしていれば良い
ので運用が楽。
リソース的に苦しくなったらグレードアップ、プロビジョンドIOPS を
使ってスケールアップ。
デメリットは、くっそ重い更新クエリと参照クエリがバッティングした
ら、システムがスローダウンしがちになるとこ。
データの正規化/スキーマ定義が最悪、そもそもクエリがバグっているなど
アプリエンジニアの品質が悪いシステムだと怖いです。
行き着くとこまで行ったら、リードレプリカ導入を検討しましょう。

2. HAproxy、MySQLProxyを使う。

VPC内部だとマルチキャスト非対応のため、LVSは使えません。
なので複数リードレプリカ構成を選択する場合はHAproxy、MySQLProxyを使用して
Webサーバ側で制御するしか無いです。
使い慣れている人ならいいんですけど、初見で時間がない場合はちょっと辛い
かもです。
世の中の人はこちらでやっているみたいです。時間があれば自分もHAProxy使い
たい。

http://aws.amazon.com/jp/vpc/faqs/
http://www.slideshare.net/wtatsuru/jawsugkyoto2nd
http://blog.suz-lab.com/2012/04/haproxyread-replicards.html

3. ワイルドにEC2上に、自前でMySQLサーバを構築する。。

内部ELBが使えます。各MySQLサーバのリッスンポートに負荷分散する形。
ただ、これはAWSの魅力のひとつであるRDSを捨てることになるので、だいぶ
微妙。唯一いいとこは、OSにログインできるのでオンプレから移行する時には
考慮すべきかも。バックアップ設計やら運用の手間が掛かりますが。。

ということで、めんどくさがりで多少コストをかけれる場合は、1 が良い
でしょう。

内部ELBが複数リードレプリカへの負荷分散ができて、かつ、自動でリードレプ
リカを検知して分散先に組み込んでくれたら、神なんだけどなぁ。
たぶん、AWS思想はDBのリソースが逼迫したら、スケールアップしまくれな感じ
なのかな。。たぶん。

RDSについて補足：
サイト要件によりますが、RDSはMulitiAZが絶対おすすめです。
耐障害性もありますが、そもそも年数回メンテナンスが入るので、SingleAZだと
メンテナンス中はDBが止まりっぱ。
MulitiAZなら、フェイルーバーしてくれるので数分断で済みます。
（フェイルバックは手動です。）

以上です。
　
　