この記事は公開されてから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を発行して処理を実行する。
- Auroraのレプリカ作成
- DB接続情報の更新（マスタとレプリカ）
- Auroraのフェイルオーバー
- DB接続情報の更新（新しいマスタ）
- 古いAuroraインスタンスを削除
構造
利点
- トラフィック量/処理量の増大予定時刻に合わせて自動的にRDSインスタンスのスペックを大きくすることができる。
- トラフィック量/処理量が多くないときにはRDSインスタンスを小さくできるのでコスト削減につながる
注意
- AWS Lambdaの指定する時間はUTC時間となる。
- Auroraのフェイルオーバー先を指定できないため、レプリカを使用する場合は実装が難しい。
- 高速なフェイルオーバーに対応しているドライバはJDBCであるためJava以外では実装できない。
まとめ
Auroraは以下の様な利点があります。MySQL互換のDBを使用するときには一番初めにAuroraの利用を検討してはいかがでしょうか？
- Single-AZでも十分な対障害性。
- エンタープライズDBだけでなくOSS DBと比較して低価格の場合も。
- 高速なフェイルオーバーでダウンタイムを極小化。MariaDB Connector/Jで更に 高速に。
5
