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

ウィスキー、シガー、パイプをこよなく愛する大栗です。 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で更に 高速に。