LoginSignup
5
3

More than 5 years have passed since last update.

AWSの自分用メモ4 (Aurora_Part.2)

Last updated at Posted at 2016-03-21

前回Auroraの特徴についてまとめましたが、その後さらにいぢくり、さらにいぢくり倒し、
何点かわかったことについて追加/補足していきます。
前回はAuroraの仕様についての話がメインでしたが、今回はAuroraの使い方についてが主になります。

ClusterEndpoint

この子には騙されました。(勝手に勘違いしただけなのですが…)
最初私はこれは"WriterとReaderをまとめたインスタンス郡の名前"と思っており、
ELBのように負荷分散とかをやってくれるものだと思っていました。

ですが実はそうではなく、これは"ReaderにFailoverしてもその新しいWriterを常に追いかけてくれる名前"でした。
要するに"Writerを指し続けるDNS"だそうで、複数の向き先を指定して~などやらずとも
これ一つ指定しておけば100%Writerに向かってくれるというものだそうです。

「じゃあ逆にReader達を指し続けてくれるものは?」というと、残念ながらありません。
大きいシステムだと『Writerは書き込み専用で、読み込みは全てReader達にへ』なんて用途は少なくないはずですので、
それこそReaderだけを指し続け、おまけにELBのように負荷分散までやってくれる!みたいなものが、
すぐに出てきてくれるのでは!と、勝手に思っております。

MariaDB Connecter/J

公表されている『Failover完了までの時間』というのが、
このClusterEndpointが新しいWriterに切り替わるまでの時間のようです。
要するに1分未満です。

これまでのMySQLに比べれば十分早いです。
ただ用途によっては『1分間書き込み不可』というのは結構な痛手だったりします。
「どうにかならないかしら・・・」

安心してください、早くなりますよ

JDBCを使って、より早くする方法が、このMariaDB Connecter/Jです。
こいつを使ってやることで超高速のfailoverができるのです。
設定にもよりますが、その時間、なんと1~2秒!!! (検証済み)

さすがに驚きました。設定時に注意するのは以下です。

  • parameterはauroraを設定する
  • ClusterEndpointは使用せずに、Writer/ReaderのEndpointをカンマ区切りで指定
  • オプションのconnectTimeout適切に設定する
    • ここで結構はまりました・・・

あと、これは2016/2末時点での制限ですが、
『この高速failoverと負荷分散(loadbalance)の両立はできません!』
つまり『書き込みはWriterに高速failoverする設定にして、読み込みはWriterとReaderで分散するように』みたいな事は現状ではできません。
どちらかを諦めるか、読み書きで設定を分けるかの対応になってしまいます。
うむぅ・・おしい。。

ただこれもきっとすぐに何とかしてると、勝手に思ってます。

AuroraのCloudFormation

Auroraの場合、既存のRDSと異なるのはClusterが必要な部分です。
そのため、DBClusterParameterGroupDBClusterを作成する必要があります。
また、Clusterを指定した場合、DBInstanceの方で指定できないものが幾つかあります。
指定すると怒られます。

  • AllocatedStorage
  • CharacterSetName
  • DBSecurityGroups
  • SourceDBInstanceIdentifier
  • StorageType
  • MultiAZ
  • PreferredBackupWindow
  • PreferredMaintenanceWindow
  • StorageEncrypted

これはParamterGroupがDBCluasterとDBInstanceに分かれたのと理由は同じで、
『DB構成全体で管理する設定』と『DB一台ずつ個別で持つ設定』が異なるためになります。

まとめ

failoverが1~2秒でできるのは正直感動ものです。
更に、failover先のレプリカの選択は、これまではレプリカの中からそのときの状況で自動選択されてたものを、最近では設定できるようになったそうです。(まだ試してませんが)
Auroraのレプリカはストレージ料金がかからない分、Multi-AZよりも低コストですし、
読み書きどちらもDB負荷が高い場合などにはfailover先の控えとして1台、余分にレプリカを建てておくことにも抵抗が少なくなります。
高速failoverと合わせて、冗長化のメリットが飛躍的に向上しているようです。
今後改善して欲しいところもちょこちょこありますが、まだまだ進化途中といった感じですし、今後に期待も高まりますね!

5
3
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
3