Amazon Web Services ブログ

RDS Classic から Aurora MySQL へのミッションクリティカルな SaaS プロダクションワークロードの移行

Sumo Logic は、AWS スタックが成熟し始めた頃とほぼ同じ時期に創業しました。同社は当初、試行とテストが行われたインフラストラクチャを選択しましたが、同時に最先端のインフラストラクチャ、つまり Amazon RDS for MySQL インスタンスも選択しました。

けれども、時が経つにつれ、その選択で開発者のかなりの時間が取られるようになりました。開発者は、MySQL バージョンのアップグレード、データベース接続の増加によるインスタンスのスケーリング、顧客からのデータと需要の増大に伴うストレージのスケーリングに時間を使いました。

つまり、顧客に見えるダウンタイムを持つことと、古いバージョンの MySQL を長期間使用し続けることとの間に絶え間ない葛藤がありました。当社は、成長するにつれて見込まれる将来のワークロードに対する、より手を加えず、堅牢で柔軟なソリューションを必要としていました。

当社について

Sumo Logic は、安全なクラウドネイティブのマシンデータ分析プラットフォームです。アプリケーションのライフサイクルおよびスタック全体にわたって、構造化データ、半構造化データ、および非構造化データからリアルタイムの継続的なインテリジェンスを提供します。

世界中の 2,000 人以上の顧客が最新のアプリケーションとクラウドインフラストラクチャを構築、実行、および保護するための分析と洞察を求め、Sumo Logic を当てにしています。Sumo Logic を利用すると、マルチテナントサービスモデルの優位性を得て、継続的なイノベーションへの移行を加速し、競争上の優位性、ビジネス上の価値、および成長を促進することができます。

Amazon Aurora に移行した理由

Amazon Aurora へ移行することで、Amazon が提供する従来の RDS の実装を超えるいくつかの利点がもたらされました。

  • 完全マネージド: Aurora インスタンスとクラスターは、Amazon RDS によって完全に管理されています。この管理機能により、最小限のダウンタイムでスケーリング、ストレージの追加、アップグレードやパッチの適用を行うことができます。ほとんどの場合、これらはクライアントの中断を招くことなく行われます。これは、Sumo Logic の非常に高い成長率と規模をサポートしているインフラストラクチャチームにとって大きなメリットです。
  • 高可用性と耐久性: 従来の MySQL に関する最大の懸念の 1 つは、メンテナンス、ネットワークパーティション、またはサービスの喪失に伴う、顧客に見える停止時間でした。Aurora はこれらの点ではるかに高い回復力をもたらします。
  • 互換性: Aurora のカギを握る機能は MySQL との互換性です。つまり、クライアントでコードを変更する必要はありませんでした。導入するとすぐにうまくいきました。
  • デフォルトの VPC: より優れたデータベースシステムへの移行に加えて、さらなる分離、セキュリティ、およびプライベートネットワークとして機能するための能力のために Amazon VPC にも移行しました。デフォルトで VPC にある Aurora インスタンスにより、当社の非 VPC Amazon EC2 インスタンスを VPC に移行する際にさらに利点が得られました。

検討した課題と移行アプローチ

Sumo Logic は毎日数百ペタバイトのデータを処理しています。顧客が自分たちの同様の問題に対処するために使用するソリューションが当社のサービスであることを考えると、何か中断、遅延、またはダウンタイムが発生した場合は桁違いに悪化し、決定的にクリティカルになります。世界中の 8 以上の AWS リージョンで、各データベースで毎秒何千ものデータベース操作を実行し、数テラバイトのストレージをホストしています。毎日何百何千というユーザーが Sumo のサービスにログインしているのです。

VPC

当社のアプリケーションをホストしていた EC2-Classic ネットワークプラットフォームで実行されている EC2 インスタンス (非 VPC) を VPC に移行するには、まずすべてのデータベースを VPC に移行する必要がありました。これは、VPC 中の EC2 インスタンスから VPC にないデータベースにアクセスする場合は、公衆インターネット経由でアクセスする必要があるためです。つまり、この移行により、VPC をインターネットに開放することになりました。この場合、EC2 インスタンスと RDS インスタンスの両方がユーザーアクセス用の独自のセキュリティグループによって保護されていても、これはセキュリティ上の懸念事項でした。

このプロセスの背景については、RDS のドキュメントの「VPC 中の DB インスタンスにアクセスするためのシナリオ」を参照してください。

ダウンタイム

Amazon が RDS インスタンス用に提供するプッシュボタン移行では、移行を実行した時に約 5〜10 分のダウンタイムが発生しました。メンテナンス期間があっても、システムは常に稼働しているため、ダウンタイムを最小限に抑える、または停止させないことを目指していました。当社は毎日に何百ペタバイトものデータを取り込み、毎秒数千ものデータベース操作を実行しています。したがって、どのようなダウンタイムでも、全体的に問題が発生します。

当社は次の 2 つのことを望んでいました:

  1. データベースの移行自体は瞬時に行われることが保証されること。
  2. 切り替えの実行中にデータベース書き込みを管理する方法を制御すること。

リードレプリカ

RDS DB インスタンスのリードレプリカを作成することはできますが、VPC の境界を越えて作成することはできません。つまり、リードレプリカが VPC 内にもあるようにするには、インスタンスが VPC 内にある必要があります。

上記の困難を緩和するために考えられる選択肢について、AWS のテクニカルアカウントマネージャーと何度か話し合いました。このプロセス全体を通じて、彼らは優れた情報とサポートを提供してくれました。彼らは RDS MySQL データベースを VPC に移行することについて詳述した AWS ホワイトペーパーを提供してくれました。けれども、これは前述の困難があったため、当社にうまく当てはまるユースケースではありませんでした。

同じ頃、当社はデータベースを Aurora に移行することを計画し始めました。VPC への移行と Aurora への移行を別々に行った場合、6 か月以上かかる試算でした。主にロールアウトに時間がかかることと、デプロイあたりの停止時間を最小限にする必要があったことにより、開発にも多大な時間がかかったことでしょう。代わりに、EC2-Classic ネットワーキングプラットフォーム上の RDS DB インスタンスから Aurora に直接移行することで、単一の移行作業で両方の目的を達成し、3 か月のコストと労力を節約できました。

最後に、Aurora リードレプリカを使用して Aurora 移行パスを利用することを選択しました。

計画

分散システムの文字通りすべての部分に影響を与えることになるタスクを実行するときは、考慮事項がいくつかあります。さまざまなアップグレードサイクル、期待、作業量、およびサービス中断への影響がある中、複数のチーム (インフラストラクチャ、取り込み、検索、セキュリティ、分析、顧客の成功など) と協力して作業する場合、計画が非常に重要です。データベースは当社のサービスのすべての業務の中心であるため、すべてのチームが同様に影響を受け、社内または顧客とコミュニケーションを行う必要がありました。

計画の一環として、データベース、モジュール、サービス、およびチーム間の依存関係を考慮する必要があります。可能であれば、ターンアラウンドタイムを短縮するために、ほとんど互いに独立している移行をグループ化することを試みる必要があります。

以下は、当社が使用し、すべてのチームと共有したロールアウト計画の一例です。

VPC で RDS DB インスタンスを Aurora に移行した方法

RDS インスタンスをまず VPC に移行するのではなく、直接 Aurora に移行すると、Aurora と VPC の両方が一度に得られました。

Amazon Aurora は、この目的のために優れた移行パス、Aurora リードレプリカを提供してくれます。これらのレプリカは、VPC の境界を越えて使用するように設計されており、VPC 内にデータのレプリケーションコピーを直接提供してくれました。このようにして、既存の RDS インスタンスを VPC に移行するという複雑なプロセスをスキップしました。代わりに、それらを Aurora に直接移行したため、デフォルトで VPC が提供されました。プロセスの詳しい手順については、AWS ニュースブログの記事「RDS MySQL DB インスタンスから Amazon Aurora リードレプリカを作成する」を参照してください。

移行: Aurora リードレプリカの作成

最初のステップは、データベースごとに Aurora リードレプリカを作成することでした。これらを作成すると次のいくつかのことが行われます。

  • データベースのスナップショットが作成されます。
  • このスナップショットを Aurora のリードレプリカに移行します。
  • スナップショット移行後、Amazon RDS は RDS MySQL データベースと Aurora リードレプリカの間でレプリケーションを開始します。

これはすべてバックグラウンドで行われ、マスターデータベースの運用に最小限のオーバーヘッドがあります。これは、Amazon CloudWatch メトリクスモニタリングからわかるように、メモリと CPU の使用率の最大 5〜10 ％の増加にすぎません。ただし、スナップショットが移行すると、バイナリログレプリケーションは、マスターデータベースにも同様に有害なパフォーマンスの影響を与える可能性があるため、上記の使用量の増加を考慮すると、CPU、メモリやデータベース接続のアラートしきい値に近いすべての DB インスタンスをサイズアップする必要がありました。

このプロセスは通常、データベースあたり 4〜6 時間かかります。すべての AWS リージョンにかけて約 100 のデータベースインスタンスに何百ものデータベースが含まれることを考慮すると、このステップをできるだけ早く開始することが重要でした。また実際の切り替えを開始するずっと前に終了する必要もありました。ありがたいことに、このプロセスはマスターインスタンスへの負荷がいくらか増加したことを除けばほとんど害はありませんでした(これを見越して、以前はより高いプロビジョニングを行っていました)。

すべての Aurora レプリカがマスターデータベースに対して作成され、それらがすべてレプリケートされると、移行する番です。

切り替えの時間!

切り替えプロセスでは、次の手順を実行しました。

  1. 移行前にすべてのデータベース接続を書き留めました。移行後もこれらはほぼ同じになるはずです。つまり、以前とほぼ同じ数のサービスとプロセスがデータベースと通信するはずです。これは単なる健全性テストであり、大きな点で何も問題がないことを確認するためのものです。
  2. すべての内部 Sumo Logic データベースアラートを適切にルーティングまたはミュートしました。
  3. データベースと通信するすべてのサービスを停止しました。これは次のいくつかのことを確保するためでした。
  • 移行中に古いデータベースにデータが書き込まれないようにすること。
  • 社内のカスタムキューからデータが取得されないようにすること。このようにして、少しキューをバックアップして、データが失われないようにすることができます。
  • 当社のユースケースでは、Sumo Logic をストリーミングサービスの逆のサービスと見なすことができることを考えると、書き込みを完全に停止しなければ、すべてのシステムのダウンタイムをゼロに近くすることはほぼ不可能です。主に、レプリカからマスターへの実際の切り替えが瞬間的であることを確認する必要がありました。そして実際にそうなりました。当社は、切り替えが完了した後、キューを使用して当社のサービスを通してデータを再生することによって残りのデータを制御しました。
  1. 古いデータベースに、新しいデータベースにまだレプリケートされていないデータがないようにするためにレプリケーションステータスを確認しました。これは、レプリカラグの値が 0 であることを確認することに加えて、「Show slave status」オプションを使用して確認できます。
  2. 古いデータベース接続数が確実にゼロになるようにしました。これにより、これらの古いデータベースとやり取りする取り残されたサービスが存在しなくなりました。
  3. コンソールの [アクション] で [リードレプリカのプロモート] を選択して、Aurora リードレプリカをマスターになるようにプロモートしました。

移行後

移行後、次の手順に従いました。

  1. 新しい Aurora クラスターの適切なバックアップを有効にしました。
  2. 新しい Aurora インスタンスを指すようにサービスレジストリを更新し、停止したサービスを元に戻した後、それらが Aurora インスタンスに接続するようにしました。
  3. すべてのサービスをオンラインに戻しました。

これで 移行は完了です!

移行ヘルスチェックメトリクス

切り替え中に監視する最も重要なメトリックの 1 つは「ログインの失敗」です。

このメトリクスは、1 つ以上のサービスが新しいマスターインスタンスに接続できていないことを示します。

監視対象の他のメトリクスには、次のものがあります。

  • Aurora レプリカラグ – Aurora レプリカが RDS DB インスタンスと同期しており、切り替えを実行しても安全であるようにします。
  • CPU 使用率 – 何千ものプロセス/スレッドが突然 (再) 接続されると、CPU 使用率が定常状態の動作よりはるかに高くなることがあります。
  • DB 接続 – 接続の前後の数に大きな不一致がある場合、体系的な問題があることを示している可能性があります。
  • 選択レイテンシー – CPU 使用率と同様に、以前に停止したすべてのプロセスを突然接続すると、選択クエリが遅くなり、システム全体の問題が発生する可能性があります。

(自社のユースケースに基づいて監視したいと思うメトリクスが他にも多くあるかもしれません)

ツーリングとオートメーション

当社は、移行するために約 100 のインスタンス上に何百ものデータベースを持ち、それぞれにテラバイトのデータが含まれていました。この規模のプロセスを手動で行うと、次のような人的ミスが発生する可能性があります。

  • 誤ったインスタンスタイプ
  • 誤ったストレージサイズ
  • インスタンスが見つからない
  • バックアップが見つからない
  • セキュリティ設定が見つからない
  • パラメータ設定が見つからない
  • SLA で義務付けられているアップグレードウィンドウが見つからない
  • 複数のリージョンにまたがる特定のデータベースのための特別な設定

2 つのデータベースを移行する間のプロセスから偏差を排除したいと思いました。

以下は、当社が自動化/追加したツールの非網羅的なリストです (これらは、将来の移行を考慮して、当社のユースケースのために特別に開発した社内ツールです)。

  • データベース接続の検証
  • レプリカラグの検証
  • Aurora レプリカの作成
  • マスターへのレプリカのプロモーション
  • 新しいインスタンスを指すようにサービスレジストリを切り替える
  • データベース固有のアラートの処理
  • インスタンスタイプのスケーリング

結論

すべてのデータベースを移行するには、移行前の手順も含めて約 3〜4 か月かかった一方、システムはすべて正常に稼働していました。

この間ずっと、AWS のテクニカルアカウントマネージャー (TAM) と Aurora チームから大きな助けを得ました。当社は彼らと何度か意見を交わして、彼らは当社を助けるためにいつもそこにいてくれ、実行可能な戦略について綿密に話し合いました。TAM はまた、クラシック (個々の AWS アカウント)、マネージド (管理者マネージド)、VPC のみ、およびハイブリッド (クラシックと VPC) を含むさまざまなタイプの設定とアカウントに対して、プレッシャーテストと仮移行を何度も行ってくれました。

この移行の間、AWS Cloudwatch と当社の Sumo Logic プラットフォームを使用した内部モニタリングの両方で、モニタリングと KPI に大きく依存していました (切り替えのセクションで述べたとおり)。

当社は Sumo Logic を社内で使用して独自のサービスとインフラストラクチャを監視しているため、サービスごとの Sumo Logic ダッシュボードの膨大なコレクションがあり、当社の待機エンジニアが、ログインの失敗、データベース接続の移行前後の比較、選択的なスループット、レイテンシー、サービスの安定性、測定可能な顧客のダウンタイム、検索、インデックスの作成、Sumo Logic へのペタバイト単位のデータのストリーミングへの影響など、移行中に発生した問題を迅速に診断およびトリアージできました。

以下のおかげで、顧客の観点から見たダウンタイムをゼロにして、内部に数百のデータベースを含む約 100 のデータベースインスタンスを移行することができました。

  • a.) データベースと通信するサービスを短時間停止し、キューイング、データのキャッシュ、および DynamoDB や S3 などの他の AWS のサービスの助けを借りて、内部のダウンタイムをいつどのように発生させるかを制御したこと。
  • b.) レプリカインスタンスからマスターへの実際の切り替えがほぼ瞬時に行われるように、Amazon Aurora の移行に関する知識と保証があったこと。

プロダクションのアップグレード、急増、ダウンタイム、そして最も重要なこととして、未知の問題、バグおよびプロダクションファイアなどを考慮した詳細な計画のおかげで、すべてのチームが常に計画を把握しておくのに役立ちました。

この移行により、古いハードウェアやシステムから最新の RDS プラットフォームに移行することが可能になりましたが、そうする間、テクノロジーだけでなくプロセスや将来の移行の点でもシステムをより堅牢で将来性のあるものにすることができました。

その他の便利なリンクと参考文献

 

著者について

Aditya Kelkar は、Sumo Logic のバックエンドエンジニアで、データおよびインフラストラクチャチームに所属し、次世代の機能の設計と開発に取り組んでいます。Aditya はまた、Sumo Logic が、コンテナ、マイクロサービス、大規模分散システムなどの最新の業界標準や動向に合わせて最新かつ堅牢でスケーラブルなインフラストラクチャを備えているようにすることに取り組んでいます。余暇には、木工や犬と遊ぶことを楽しんでいます。