HAproxyでHR構成を組む on AWS

はじめに

DBサーバへ接続する際、readレプリカを複数台作ることが一般的だが、readレプリカに対してバランシングはインフラの設計ポイントとなる。auroraであれば自動でreadレプリカを作ってくれるのでその考慮は要らないがレガシーなシステムを運用している場合それは使えない。今回はAWSで組むこととする。

やりたいこと

多くのプログラムはそうであろう構成。

プログラムは更新用(write)と参照用(read)で接続先を変え、
データベースはMasterとSlaveでレプリケーションをしている。

Slaveは今後増える可能性もあるのに加え、Slaveが1台ダウンしてもサービスが稼働できるようにするには、クラスタリング構成をする必要がある。

クラスタリングソフトの検討

名前考察
keepalived名前解決不可能。また、ググっても実績なし
HAProxyAmazon linuxでyumでのversionが古い(1.5.2)。v1.6の resolvers オプションを使ってVPCのnameserverを参照するようにし、A Recordの変更に追従させる事が可能だが、ソースからのinstallになってしまう
MySQL Routerアルファ版 本番利用 非推奨
Consul by HashiCorpググっても出ない
ProxySQLAmazonLinux非対応

keppalivedはAWSでは難しいようだ。

今回はHA proxyで実現することにした。

対応

Amazon linuxの上にHAproxyを使いクラスタリングを実現する。

 

HAproxyのインストール

amazon linuxの場合、yumでinstallしようとすると、versionが古い。

そのため、sourceでインストールすることにした

HAproxyの設定

設定は以下の通り

もう片方のサーバは今の通りに設定した

ほとんど同じように見えるので差分をまとめると、以下のような違いだ

これで

  • tsukada001の3306ポート
  • tsukada002の3306ポート

    に接続すると、dbserver01,dbserver02へラウンドロビンで接続されるようになった

しかし、これでは当然tsukada001、tsukada002自体で障害が起きる可能性もある。

ALBでバランシング

tsukada001:3306、tsukada002:3306をALBに登録しラウンドロビンで登録した。

これによりALBのエンドポイントが払い出され、それを各プログラムが参照するような形にして可用性を担保した。

振り返って見て思うこと

レガシーなDBでこの構成を組もうとすると、できないことはないが、登場人物がやたら多い。一番なのはauroraなどに移行し、本当に必要なことのみに集中できれば最高だ。

 

 

Facebook Comments