Amazon Aurora への移行 – お客様自身が語るサクセスストーリー

今回は、AWS のお客様である Safe Software によって記述されたゲストポストを紹介します。同社は Amazon Aurora のアーリーアダプターで、有用な経験をシェアしています。

–
Jeff

Safe Software はデータ移動のビジネスに携わっているので、先端のデータベーステクノロジーをサポートするように常に心がけています。この理念の当然の結果として、Amazon Aurora にも興味を抱きました。

AWS と Aurora のパワーを顧客のために活用するだけでなく、当社の内部プロセスを改善するという観点からも、この新しいテクノロジーを評価しました。Aurora のベータバージョンがリリースされたときに、当社のシステムを Aurora に移行することをすぐに考えました。この決定は、価値あるものであることが証明されました。Aurora に移行することによって、生産性が向上しただけでなく、年間のシステムコストが 40% も削減されました。

すでに移行は終了しているので、この経験から得たヒントや洞察を、Aurora への移行を検討している人たちとシェアしたいと思います。移行作業の詳細について説明したいのですが、実際にはボタンをクリックするだけで終了してしまったので、多くを書くことはできません。その代わりに、私たちが最初に試したこと、準備に使った方法、Aurora での運用を開始した後でシステムをさらに最適化した方法について、シェアしようと思います。

クラウドを必要とした理由
当社では、当社の空間データ変換テクノロジー FME の高い品質を維持するために、厳しい自動化テストスイートを実行します。このプラットフォームは、365 を超えるデータフォーマットと制限のない変換をサポートするので、自動化された日々のテストは、15,000 のテストを、4 つのオペレーティングシステムと 3 つの製品で、24 時間 365 日実行、というようにとても厳しいものになっています。

問題は、システムの健全性を維持するための、ハードウェアのプロビジョニングを継続できないことです。1 秒という応答想定時間を維持できなくなった、などとは思わないでください。

当社の内部プロダクションデータベースは、きわめてトラフィックの多いシステムで、140 を超えるテーブルに 1 億行にも達するデータが格納されています。このデータベースは、内部のイントラネットとレポート処理のフレームワークと同様に、ビルドシステムとテストシステム用の主要な運用リポジトリであり、150 台に及ぶサーバーファームをサポートしています。100 人を超えるユーザーが、このシステムを頼りにしています。

Aurora の前に試したこと
私たちは当初、すべてを RDS 上の MySQL に移行しようと考えましたが、負荷を管理するために、リードレプリカをかなり大きなインスタンス上で実行する必要があることに気付きました。それでも、ほとんどのクエリ用に処理できる接続数の運用上限を引き上げようと悪戦苦闘しました。必要な応答時間を達成しようともがきました。しかし、このソリューションは、すぐにコストが倍に膨れ上がりました。

多くの時間を MySQL の習熟に費やしましたが、新しいシステムのすべてを再び学習しなければならないということは苦痛を伴いました。このような経験から、アプライアンスのように扱える何かがあれば、事態ははるかによくなることに気付きました。

フェイルセーフな準備と移行
Aurora が MySQL 経験を活かせると聞き、試す価値があると考えました。失うものが何もないことを確認するために、プロダクションシステムを既存の形態で稼働させながら、Aurora をテストすることに決めました。

パフォーマンスのより高いシステムに移行することの利点の 1 つは、数年前に戻ってシステムを再評価する良い機会を得られることです。この移行時には、いくつかのハウスキーピング処理を実行しました。データベースについて、インデックス、テーブル構造、および多くのその他のリレーショナルデータベースに関する側面を見直しました。また、ロジックをさらに簡素化するために、複数のスキーマを組み合わせて、わずか 2 つにすることができました。

Aurora への実際の移行作業自体は、簡単に終了しました。Amazon のコントロールパネルで、ボタンクリックによる移行を選択しました。移行はバッググラウンドで実行され、結果として、MySQL で実行されていたものが、Aurora 内にコピーとして作成されました。きわめて簡単でした!

カットオーバーを管理することは、スケジュールの面でかなり大きなことであり、運用に影響を及ぼさないようにしながら、データの最新のスナップショットをキャプチャする必要があります。私たちは同期がずれることを心配しました。つまり、移行が終了したときに、読み込みレプリカが古いデータのままになり、使うことができなくなるのではないかという心配がありました。プロダクションシステムを稼働させながら移行するのに数時間がかかり、この間にデータが変化する可能性があることがわかっていました。

移行をライブシステムで、そのシステムを稼働させながら深夜に行うことを選択しました。当社独自の FME 製品を活用して、移行時に揮発性テーブルで発生する変更をキャプチャし (総データの 2～3%)、ポーティングしました。

ビルドとリリースのチームは、移行を自分自身で管理でき、IT 部門が関与したのは、ID とアクセスの管理を構成することと、すべての準備が整ったことが確認された後でのネットワーク上の DNS の変更だけでした。

最初にいくつかのサンプルを使用してサニティチェックを行いましたが、私たちはアーリーアダプターだったので、手探り状態での試行が続きました。ただし、必要に場合には、古いシステムにロールバックできることを確信していました。

移行後の最適化
移行後にすべてのプロセスを徹底的にテストしました。最初の 2 日間の監視において、困惑するような出来事がいくつかありました。運用時に CPU 負荷が散発的に重くなり、Aurora がスローダウンすることがありました。このような現象は、以前の MySQL の運用時には検知されませんでした。

私たちはスローダウンを追跡して、深くネストされている SELECT を使用する非効率なクエリを見つけました。これらは簡単には修正できませんでした。これらの問題は、いくつかの単純なスキーマ変更を実施して解決し、複雑性の高い関係については、自社の製品である FME を使用して、事前に封じ込めることができました。重要なヒント – スキーマ設計は引き続き重要。

移行以来、その他の問題は発生せず、これらのクエリやインデックスのチューニングは、結果的にメリットをもたらしました。運用に関しては、これまで使ってきた慣れ親しんだインターフェイスを使用して、エンタープライズスケールで行っています。

ほとんどすべての運用に関して、Aurora はこれまでのシステムより高速であることが証明されており、はるかに高いレベルのスケーラビリティを提供しています。現在、比較的中規模のセットアップを実行しています。これは、拡張できることがわかっているからできることですが、こうすることで、年間約 8,000 USD を節約しています (コストが 60% 減少)。実際、Aurora を使うことでパフォーマンスは 2 倍になっていますが、コストは昨年よりも少なくなっています。また、年間運用向けにインスタンスをリザーブすることで、さらに 2,000 USD を節約しています。

運用管理はきわめて重要な要件ですので、バックアップやデータベース障害について心配しなくて済むのは、とても心休まることです。また、マネージド型データベースは、多くの頭痛の種も取り除いてくれました。このパフォーマンスを自分たちだけで達成しようとした場合、ハードウェアと人的資源に多大な投資が必要だったと思います。

Aurora を使用することで、当社の FME 製品ビルドを作成する作業がより良く、高速になり、テスト結果を迅速に入手できるようになりました。このことは、究極的には、これまでになく高いレベルの品質の製品を提供できるようになったことを意味します。

– Iain McCarthy、Product Release Manager、Safe Software Inc.