カテゴリー: aws

はじめに

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

やりたいこと

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

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

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

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

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

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

対応

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

HAproxyのインストール

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

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

yum install -y gcc
cd /usr/local/src/
wget http://www.haproxy.org/download/1.8/src/haproxy-1.8.8.tar.gz
pwd
tar xvfz haproxy-1.8.8.tar.gz
ls -ltr
cd haproxy-1.8.8
make TARGET=generic
make install

HAproxyの設定

設定は以下の通り

$ cat /etc/haproxy/haproxy.cfg 
global
    log         tsukada01 local2

    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4096
    user        haproxy
    group       haproxy
    daemon
    stats socket /var/lib/haproxy/stats
    stats maxconn 1
    stats timeout 120s

resolvers awsvpc
    nameserver vpc 172.20.0.2:53

defaults
    mode        tcp
    log         global
    retries     3
    timeout     connect 10s
    timeout     client 1m
    timeout     server 1m
    timeout     check 10s
    maxconn     512

listen mysql
    bind tsukada01:3306
    mode tcp
    option mysql-check user haproxy_check

    balance roundrobin

    option          log-health-checks

    server read01 dbserver01:3306 check port 3306 resolvers awsvpc inter 2000 fall 3
    server read02 dbserver02:3306 check port 3306 resolvers awsvpc inter 2000 fall 3

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

$ cat /etc/haproxy/haproxy.cfg
global
    log         tsukada02 local2

    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4096
    user        haproxy
    group       haproxy
    daemon
    stats socket /var/lib/haproxy/stats
    stats maxconn 1
    stats timeout 120s

resolvers awsvpc
    nameserver vpc 172.20.0.2:53

defaults
    mode        tcp
    log         global
    retries     3
    timeout     connect 10s
    timeout     client 1m
    timeout     server 1m
    timeout     check 10s
    maxconn     512

listen mysql
    bind tsukada02:3306
    mode tcp
    option mysql-check user haproxy_check

    balance roundrobin

    option          log-health-checks

    server read01 dbserver01:3306 check port 3306 resolvers awsvpc inter 2000 fall 3
    server read02 dbserver02:3306 check port 3306 resolvers awsvpc inter 2000 fall 3

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

これで

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

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

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

ALBでバランシング

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

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

振り返って見て思うこと

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

はじめに

内部通信で使うサーバやMacBookのアドレスはOSに付いているip addrなどのコマンドでわかるけど、残念ながらグローバルIPはOSを確認するコマンドはOSに付いていない。外部サービスに問い合わせ、自分のIPを聞くのが一般的だ

自分のIPを確認する

ブラウザで確認する場合

https://www.cman.jp/network/support/go_access.cgi へアクセスすると、接続しているマシンのIPアドレスがわかる。他の拠点のスタッフにIPアドレスを確認するのによく使う。

CUIで確認する場合

$ curl -s httpbin.org/ip 
{
  "origin": "123.12.1.11"
}

IPのみを取り出したい場合はjqコマンドを使うとIPのみ取り出せる。

$ curl -s httpbin.org/ip | jq -r .origin
123.12.1.11