CM re:Growth 2014 TOKYOでAuroraの話をしてきた #cmdevio

ウィスキー、シガー、パイプをこよなく愛する大栗です。 昨日弊社AWSチームで開催したre:Growth 2014 TokyoでAuroraについて話してきました。

Aurora？

先日のre:Invent 2014で発表された新しいクラウドネイティブなRDBMSです。MySQL 5.6と互換があるので、移行が容易です。

絶対安全データは消えない！

3カ所のDCに計6重化でて保存しており、継続的にS3へバックアップしているので耐久性はS3と同様に99.999999999%になっています。既存RDSのMulti-AZはEBSの2重化なので、耐久性のレベルが異なります。

ストレージ不足？何それ？

Auroraの目玉の一つと言える機能です。Auroraはストレージ容量が自動で増加します。既存RDSでも手動であればストレージ容量を増加できますが、移行中の性能低下や切替え時のサービス瞬断が発生してしまいます。 Auroraの場合は、ユーザーはストレージ容量の増加を意識せずに行われ、サービスの瞬断も無い様です。

運用テストも任せろ！

障害を発生させる！

Auroraには通常のDBには存在しないユニークな機能があります。それは障害を「人為的に」起こせると言う事です。Auroraにログインして以下の様なSQLを実行するとログインしているインスタンスでインスタンス障害をシミュレートして再起動が発生します。

[SQL]ALTER SYSTEM CRASH INSTANCE;[/SQL]

他にはAuroraのディスク障害やネットワーク障害もシミュレートできる様です。 ドキュメントには"ALTER SYSTEM CRASH"文や"ALTER SYSTEM SIMULATE"文の記載がまだ無いので詳細は不明ですがAZ単位のネットワーク障害のシミュレートまで行える様です。これで運用テストで障害時の動作確認もできる様になりました。

 フェイルオーバーの仕組みは？

Auroraは起動しているインスタンスがMasterだけの場合は同じ名前(Endpoint)で再起動するだけなのですが、Read Replicaがある場合はRead Replicaにフェイルオーバーします。元々起動しているRead Replicaへフェイルオーバーするため高速にサービスを再開できます。ドキュメントにも障害発生から60秒以内に復旧する事もあると書かれています。

AuroraにはクラスタのEndpointとインスタンスのEndpointの2つがあります。クラスタのEndpointがwriter(Masterの事です)を指しており、インスタンスのEndpointが各々のインスタンスを個別にアクセスします。インスタンスの障害が発生した場合は、クラスタのEndpointが別のインスタンスに切り替わる事でフェイルオーバーします。データはキャッシュも含めて共有されているので切替え時間が短くなっていると思われます。

さいごに

AuroraはPreviewでfeedbackを受け付けている。正式リリースに向けて更なる進化がある事を期待しましょう！