こんにちは。インフラエンジニアの永井(shnagai)です。
サービスで使っているDBをRDS for MySQLからAuroraへ移行するプロジェクトを進めていて、 色々と知見が溜まってきたので、これまでAWS SAの方に聞いたりwebで調べたことについてざっとまとめてみました。
アーキテクチャ
リーダエンドポイントによる負荷分散と共有ストレージモデルのメリットが大きい
- リードレプリカアクセスにLB機能がある
- リーダエンドポイントによって、ヘルスチェック&ラウンドロビンで読み取りアクセスに負荷分散
- レプリカ0の場合は、writerにアクセスがいく
- アプリケーション側のエンドポイントとしては、リーダエンドポイントを指すことでr53では出来なかったヘルスチェック機能付き負荷分散可能(パブリックアクセス許可しないとr53からのヘルスチェックは使えない。。) & HA Proxyやライブラリで行っているLB機能をAWSに任せられる
- RDS for MySQLだと、Multi-AZ構成で無駄になっていたスタンバイインスタンスがリードレプリカとして使える
- 共有ストレージモデルなので、レプリカの遅延とほぼ無縁(3AZ 6つのストレージに非同期書込)
- MySQL5.6互換なので移行にあたりアプリケーションの改修は不要(まだ検証中だが今の所何もなさそう)
- Auroraインスタンスを束ねるクラスタという概念があるので、クラスタ内のノードの状態について管理する必要がない
運用面
ほぼDBA的な仕事が不要になったり、運用の為の細かい作り込みから開放
- ストレージ、キャッシュ、DBエンジンが分離されているから再起動が早い
- DBエンジンの再起動のみなので、Aurora再起動は1分以内で
- 再起動後のあたため(キャッシュ作り)が不要
- 暗号化もオプション一つで可能
- SQLによるフェイルオ−バーテスト（カオスエンジニアリング出来る！！）
- ALTER SYSTEM CRASH [{INSTANCE | DISPATCHER | NODE}]
- 1分でfail over (リードレプリカありのケース)
- 監査要件で必要とされがちな、AuditLogを有効にした際のパフォーマンス劣化が少ない
- RDS for MySQLだと1/3ほどになるという話もあったのでサービスで使うインスタンスには使いづらかった
- ゼロダウンタイムパッチ(ZDP)
- ダウンタイムゼロでのパッチ適用
- セッション切断しないのアプリケーションエラーは起きず、5秒ほどのスループット低下のみ
- DBクローン機能で、本番相当のテストが簡単に出来る
- バックトラック機能で瞬時に特定時点へのロールバック
- オペミスしたら瞬時戻すみたいなケースが出来る(もちろん使わないのがベストですがw)
- ストレージが自動拡張するので、ディスク容量の管理不要(ディスクフルだ。。。からおさらば)
- コストも下げれる
- RDSと比べると2,3割高いが、multiAZ構成をはがせるのでその部分でうまくやればコスト削減見込める
- モニタリングの強化
- select単位のレイテンシやスループット取れたりCloudWatchで取れるメトリクスがだいぶ増えてる
- 拡張モニタリングで1s単位でモニタリング出来る
パフォーマンス面
CPUをMySQLよりがっつり使ってスループットを上げるチューニングをしているみたい
ココらへんは、実際に本番の切替を行ってから詳しく見てみる
- 独自エンジンなので、パフォーマンスアップの為のチューンが諸々あるらしい
- 独自Cache, Faster index build, Fast DDL
- 並列度を上げるためのチューンをかなりしてそう??
- 数%から数10% Disk/IO 性能が高いらしい
- MySQLと比較すると、統計情報が変わる可能性がある
全体を通じてだいぶ枯れてきている印象で、更新履歴見てもここ2016,2017年で様々なパッチがあたり問題なく運用出来るレベルになっていそうな印象を受けました。
Amazon Aurora MySQL 1.1 のデータベースエンジンの更新 - Amazon Aurora
来月には、実際のAurora移行プロセスについて書こうと思います。
コネヒトではサービスの信頼性向上をミッションに幅広い領域をカバーしながらエンジニアリングの力でサービスをよりよくしていけるエンジニアを募集しています。 少しでも興味もたれた方は、是非気軽にオフィスに遊びにきていただけるとうれしいです。
