Auroraのローンチ記念イベントに登壇しました

Amazon RDS

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ウィスキー、シガー、パイプをこよなく愛する大栗です。
11/10にAmazon RDS for Aurora 東京ローンチ記念セミナーが開催されたのですが、私もイベント内で発表してきたので内容をご紹介します。

Amazon RDS for Aurora 東京ローンチ記念セミナー

re:Invent 2015で発表されましたが、Auroraが東京に上陸したことを記念してAWSJ様主催でイベントを開催され、各社のAuroraの情報について発表されました。私はクラスメソッドでのAurora移行事例とAuroraを活用した新しいCDP提案を話させて頂きました。

Aurora移行事例

このサイトであるDevelopers.ioの移行事例と某SNSサイトでのAurora移行検証について、ご紹介しました。 なお、Developers.ioのAurora移行の詳細は 【Aurora】とあるWebサイトのDBをAmazon Auroraに移行してみた をご参照下さい。

新しいCloud Design Pattern

Auroraの高速なフェイルオーバーを活用することで、オンラインのDBのスケールアップ/スケールダウンを可能にしてコストを下げる「DB Scheduled Scale Up」を提案しました。

AWSクラウドデザインパターンの流儀で書いていきます。

解決したい課題

DBは性能向上をScale Upで行うためオンラインでは切替えが難しいのでピーク時の負荷に合わせたサイジングを行う。常時ピーク性能のスペックを使用するので高コストになりがちである。

クラウドでの解決/パターンの説明

RDS for AuroraとMariaDB Connector/Jを組み合わせると、マスタからレプリカへのフェイルオーバーを高速(1〜2秒)に行うことが可能になる。サイズの異なるレプリカを作成し、フェイルオーバーを行う事で処理に影響が少なく切り替えることができる。

実装

AWS Lambdaにはcronのように時刻指定で実行する機能がある。この機能を利用して、AWSのAPIを発行して処理を実行する。

  1. Auroraのレプリカ作成
  2. DB接続情報の更新(マスタとレプリカ)
  3. Auroraのフェイルオーバー
  4. DB接続情報の更新(新しいマスタ)
  5. 古いAuroraインスタンスを削除

構造

利点

  • トラフィック量/処理量の増大予定時刻に合わせて自動的にRDSインスタンスのスペックを大きくすることができる。
  • トラフィック量/処理量が多くないときにはRDSインスタンスを小さくできるのでコスト削減につながる

注意

  • AWS Lambdaの指定する時間はUTC時間となる。
  • Auroraのフェイルオーバー先を指定できないため、レプリカを使用する場合は実装が難しい。
  • 高速なフェイルオーバーに対応しているドライバはJDBCであるためJava以外では実装できない。

まとめ

Auroraは以下の様な利点があります。MySQL互換のDBを使用するときには一番初めにAuroraの利用を検討してはいかがでしょうか?

  • Single-AZでも十分な対障害性。
  • エンタープライズDBだけでなくOSS DBと比較して低価格の場合も。
  • 高速なフェイルオーバーでダウンタイムを極小化。MariaDB Connector/Jで更に 高速に。