この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
こんにちは、崔です。
セッションDAT381：How Verizon moves critical databases to Amazon RDS with zero downtime に参加しましたので、そのレポートをお届けします。
セッション概要
Learn how Verizon is moving mission-critical databases from on premises to Amazon RDS. Verizon’s workloads, including VZW.com, demand high availability, data consistency, and low latency at all times to service millions of customers every day. In this session, Verizon engineers share how they achieved a zero-downtime migration to AWS by setting up a multi-region active-active architecture and ensuring data synchronization across on-premises and cloud environments during the transition phase. They dive deep into the specific features and tools used and share the challenges and lessons learned during the migration process.
VerizonがミッションクリティカルなデータベースをオンプレミスからAmazon RDSに移行する方法をご覧ください。 VZW.comを含むVerizonのワークロードは、毎日何百万人もの顧客にサービスを提供するために、常に高可用性、データの一貫性、低遅延を要求しています。 このセッションでは、Verizonのエンジニアが、マルチリージョンアクティブ/アクティブアーキテクチャをセットアップし、移行フェーズ中にオンプレミス環境とクラウド環境全体でデータ同期を確保することにより、AWSへのゼロダウンタイム移行を実現した方法を共有します。 彼らは、使用される特定の機能とツールを深く掘り下げ、移行プロセス中に学んだ課題と教訓を共有します。
スピーカー
- Sandeep Kariro - Solutions Architect - AWS, Amazon Web Services
- Sandeep Varma Alluri - Senior DB Engineer, Verizon Wireless
- Srinivas Sodagam - Senior Member Technical Staff-Sys Engineering, Verizon Wireless
セッションメモ
Verizon's journey to AWS
System/application types
既存のアプリケーションを3種類に分類しました。
ミッションクリティカルなアプリケーションとビジネスクリティカルなアプリケーションとそれ以外です。
- ミッションクリティカルなアプリケーション
- データセンター内で高可用性を確保することが求められる
- DBレイヤー、アプリレイヤー、NWレイヤー、複数のDC間でアクティブに利用可能
- RTOは15分以内
- ビジネスクリティカルなアプリケーション
- 内部ビジネス機能をサポートするアプリケーション
- Active-Passiveなアベイラビリティ
- RTOは4時間以内
System architecture(Mission-critical)
- Multiple data centers
- 3つのデータセンターがオンプレミスにあり、3つのデータセンターすべてで同じアプリケーションが実行
- お客様のリクエストの発信元に基づいて、3つのサイトで実行中のアプリケーションを積極的にサポートできるように、最も近いデータセンターにトラフィックをリダイレクト
- 必要なのは、マルチマスターデータベースを持つ
- つまり、すべてのサイトでデータベースを読み取りおよび書き込みができること
System architecture(Business-critical)
- Single(active) data centers
- アクティブサイトにルーティング
- 一方向のデータ同期
Cloud migration(Approach)
- Mission-critical
- リフト＆シフト
- 商用データベースをRDSかEC2に移行
- 最終的にはAurora PostgreSQLへ
- Business-critical
- リファクタリング
- Aurora PostgreSQLへ
Cloud security Requirements
- 保存されているデータはすべてkmsキーを有効にする必要がある
- ロードバランサーからEC2へのすべてのトラフィックを暗号化する必要がある
- データベース上のアプリケーション間のトラフィックはSSL対応
- クレジットカードのデータをトークン化
- AMIはVerisonのセキュリティ標準に則ったAMIでなければならない
- AMIはライフサイクルポリシーに乗っ取る
Cloud migration Key databse requirements
- 24時間365日稼働
- マルチAZによる自動フェイルオーバー
- リージョン毎の高可用性
- オンプレミスのデータセンターとAWSリージョンの高可用性
- ニアリアルタイムなデータ同期
Cloud migration Data copy - checklist
データコピーのチェックリスト
- 移行前に不要なデータを削除
- レプリケートされるデータの監査
- ETLの標準化
- データベースの分散
Amazon RDS
- Multi-AZによる高可用性
- インスタンスサイズをスケールアップ
- ストレージのパフォーマンスも必要に応じてスケール
- 自動バックアップ
- 自動フェイルオーバー
- 自動アップグレード
Cloud migration(build state) Mission-critical N+1
- オンプレミスからのデータコピー
- 時間ベースに基づくデータエクスポート
- マルチスレッドによるDMSによるデータコピー
- ETLツールによるデータコピー
HUB architecture High availability
- プライマリーRDSインスタンスと同じAZにプライマリーEC2を置く
- スタンバイRDSインスタンスと同じAZにパイロットライトEC2インスタンスを置く
- EFSをマウント
- レプリケーションソフトウェアをEFSに配置
- DNSで向き先を制御
Performance and resiliency testing
- 性能テストは複数回実行
- テスト結果をモニタリング、分析
- RDSとEC2のインスタンスサイズを調整
- IOPSの微調整とEFSのスケール
- AZ障害のテスト
Database and replication monitoring
- RDSのイベント
- CloudWatchのモニタリング
- カスタム監視スクリプトの作成
- アプリケーションの性能モニタリングの実施
Lessons learned/technical challenges
RDS
- ストレージのリサイズ
- 性能テストをベースとしたインスタンスサイズとIOPSの調整
- RDSフェイルオーバー後のクライアント接続の再開
問題
- JVMオプションを有効にすると、自動マイナーバージョンアップが強制
- 個別パッチの適用
Future enterprise requirements
- モニタリングの強化
- パフォーマンスインサイトの強化
- パッチ更新
- 適用するか選択する
- フェイルオーバー前に通知
- クロスリージョンレプリカ
- カスタムSSL認証
Key takeaways
- 一つのサイズが全てに適合しないことを知ること
- それぞれのオンプレミスのアーキテクチャに依存する
- 複数のドライランの実施
- 性能テストの計測
- 複数のレイヤーでの計測
- セキュリティが最も重要
- 継続的なプロセス
まとめ
まず、AWSへ移行を行う中で、移行対象のアプリケーションを要件によって分類し、その分類によって、移行方式を選定していた。
また、AWSのサービスが各機能を提供しているが、それらをしっかりと理解し、正しく利用することでセキュリティやモニタリングを担保していた。
さらに、性能テストや障害テストはしっかりと実施し、そのテスト結果に基づいて、インスタンスサイズやIOPSを選定したとのことでした。
最後のスライドにもありましたが、一つのサイズが全てに適合しない、それぞれのシステムに依存する、また、複数のドライランの実施や性能テストでの計測といったとことが、移行の基本であるということに立ち返ることを忘れてはいけないと感じることができました。
6
