Amazon Web Services ブログ

MySQLデータベースをAuroraへ移行する方法をマスターする

By Nathaniel Kangpan, SVP Technology & Data Services, Kepler Group

私は過去12ヶ月の間に(a)クラウドベースのインフラストラクチャを使うことに踏み出していない、もしくはその様なチームがいない(b)2018年のロードマップにクラウドを使うことが乗っていないクライアントに会っていません。ハードウェアからクラウドへ移行した場合のTotal Cost of Ownership(TCO)の節約は無視できません。

しかし、所有しているハードウェアからAWSのようなクラウドベースのインフラストラクチャに移行する際には、本当に何を期待するべきですか？ Amazon EC2などの仮想サーバー上にソリューションを複製するだけでいいですか、Amazon RDSのようなマネージドサービスを増やすべきででしょうか？

Kepler Groupでは、インフラストラクチャの95％以上が2014年後半からAWS上で稼働しています。過去数年にわたり、多くのお客様に機転となる時に何を期待しているかをアドバイスしました。私達はマーケティングデータベース管理サービスを提供しています。クライアントとの最も一般的な議論の1つは、リレーショナルデータベースをAWSに移行する際に抱えるメリットと課題を理解する助けとなることです。

 

Global Fortune 100の例

私たちは通常、Global Fortune 100クライアントのために完成した代表的なプロジェクトを中心に、データベースクラウドの移行に関する会話行っています。この特定のクライアントにとって、私たちは最初に、データセンターのハードウェア上にMySQLデータベースを構築しました。その後、MySQLを実行しているEC2インスタンスに移行し、最終的にAmazon Aurora MySQLに移行をしました。クライアントのユースケースと基本的なデータスキーマは、この間にあまり変化しませんでした。そのため、私たちはソリューションの管理がますます効率化されるようになるにつれ、同じMySQLデータベースを複数のフレームワークで実行することの長所と短所について多くのことを学びました。

今回の対象のデータベースは、マーケティングおよびセールスカスタマーリレーションシップマネジメント(CRM)データベースでした。一連の電子メールおよびセールスチームベースのマーケティングキャンペーンで、レポートおよび分析ユースケースのために複数のサードパーティソースにデータを継続的に集約しました。私たちのチームは、データベースの管理に加え、マネージドサービスとしてレポートと分析の提供を担当する主なユーザーです。

このプロジェクトは、スコープと予算の面で一般的に管理していた物の小規模なものでした。クライアントのニーズを満たすことに加えて、次の点に細心の注意を払う必要がありました:

  • データベースメンテナンスの負荷を低く抑える
  • インフラストラクチャコストの制限
  • 信頼性の高いバックアップおよびリカバリプロセスを確保する

前述のように、データベース用に3つの異なるインフラストラクチャソリューションを使い、各バージョンのメリットと課題についてかなりのことを学びました:

  • v1.0：オンプレミスハードウェア上のLinuxでMySQLを実行する
  • v2.0：Amazon EC2上のLinuxでMySQLを実行する
  • v3.0：MySQLと互換性を持つAmazon Aurora

次の移行の概要では、各バージョンへの移行の決定と、その過程で得た利点と課題について説明します。

 

Version 1.0: オンプレミスハードウェア上のLinuxでMySQLを実行する

2013年後半にこのクライアントとの関係を開始したとき、クラウドベースのサービスを検討し始めましたが、私たちのインフラストラクチャは、データセンターを基盤とするハードウェアソリューションでした。クライアントサービスや厳しい締め切りで働いている多くの人が理解できるように、理想的な長期的なソリューションを最初から構築するのではなく、迅速に稼働させることを優先する必要がありました。私たちは、オンプレミスハードウェア上のLinuxとMySQLの組み合わせから開始することにしました。これは、このプロジェクトで作業しているエンジニアが最も慣れている構成だったからです。

利点

この初期のアプローチの唯一のメリットは、エンジニアがハードウェア+ Linux + MySQLの構成でよく作業していたことです。必要な開発フレームワーク、データ転送メカニズムなどはすべてかなり理解されており、大きな技術的驚きは期待できませんでした。これにより、限られたAWS経験を持つクラウドベースのソリューションに飛び込むのとは対象的に、納期と予算に対するリスクを最小限に抑えながら顧客の設定した期限を迎えることができるという自信が得られました。

チャレンジ

しかし、ハードウェア環境で解決策を維持することには、かなりの数の問題がありました。AWSへの移行を後で行うまでは、これらの非効率性を十分に理解していませんでした。具体的には、クラウドと比較してハードウェアソリューションでは次のような課題に直面しました:

  • かなり高いサーバーとデータベースのメンテナンスとアップグレードの運用負荷
  • 時間の経過とともに増加するデータ量に対応する、シームレスではない垂直スケーリングプロセス
  • スナップショットを復元する必要があるときはいつでも、より多くの手動リカバリプロセスを必要とするカスタムバックアッププロセスを実装する必要性
  • ハードウェアに障害が発生する可能性のリスク

現在、成熟したクラウドベースのソリューションと比較して、ハードウェアベースのソリューションの欠点はかなりよく理解されていますが、2014年初頭ではあまり理解されていませんでした。

 

Version 2.0: Amazon EC2上のLinuxでMySQLを実行する

2014年中頃までに、私たちは、指数関数的に増加するデータ取り込みと複数のクライアントの分析ユースケースによって、データセンター全体を大幅に拡張する必要がありました。AWSのコスト計算を使用して、クラウドをハードウェアソリューションと比較してベンチマークを行い、簡単なTCO分析を実施しました。ハードウェアインフラストラクチャを継続的に拡張するのではなく、AWSへの大規模な移行を行うことで、大幅かつ迅速な節約を実現できることがわかりました。

エンジニアリングチームの長い議論の後、物理的なデータセンターソリューションとクラウドプラットフォームの両方をコスト効率よくサポートできないと結論づけました。クラウドに移行するならば、すべてのサービス​を移行する必要がありました。

私たちは一度に行わなければならない変更の数を制限する必要がありました。そこでAuroraのようなマネージドデータベースソリューションに直接飛び込むのではなく、データセンターで実行していたものと同じバージョンのMySQLを実行するLinuxベースのOSを使用して、現在のクライアントのMySQLデータベースをEC2インスタンスに移行しました。

利点

この移行により、すぐに2つのメリットが実現出来ました:

  • まず、ハードウェアベースのデータセンターと比較して、インフラストラクチャのコストが大幅に下がりました。これは、コロケーション費用、追加のハードウェア費用、および実行中のハードウェアに付属するその他すべてのコストを考慮した後です
  • 第2に、ますます増大する第三者のデータソースに対応するためにソリューションを垂直方向に拡張することは、本当にシームレスになりました。物理的にデータセンターに行ったり、ハードウェアを追加したり、新しいサーバーを設置・プロビジョニングする必要がなくなりました。いくつかのコマンドを入力するだけで、瞬間的に10〜100GBを拡張することが出来ます。

Amazon EC2には、この特定のクライアントのための移行からは得られませんでしたが、他にも利点があります。 公平にするために、これは私たちのユースケースにはあまり必要とされないものでした。たとえば、複数のアベイラビリティゾーンを持つことで得られる追加の冗長性を必ずしも必要としませんでした。AWSをあまりご存知出ない方のために説明すると、AWSのリージョンには複数のアベイラビリティゾーンがあり、各アベイラビリティゾーンは別々の施設で構成されています。万が一1つのアベイラビリティゾーンに障害が発生した場合は、別のアベイラビリティゾーンに迅速にサービスを展開できます。しかし、今回のユースケースでは、99.99％の稼働率と可用性を備えたソリューションは必要ありませんでした。 私たちが構築していたソリューションの主なユーザーはわずか2〜3人でした。レポート分析は、オンデマンドである必要はなく、24〜48時間のウィンドウ内でアドホックに完了することができました。

チャレンジ

このソリューションでは、次の2つの大きなチャレンジがありました:

  • ソリューションオンボーディング: クラウドサービスへの最初の大きな移行であったため、多くの1回限りの学習曲線の問題がありました。今ではエンジニアリングチームの誰もが、従来のハードウェアスタックよりも、サーバーの調達、ネットワークの管理、AWSによるデータのバックアップなどの作業を大幅に簡単に行うことに同意しました。しかし、これらのことをシームレスに行う方法を学ぶためには、まだ少し経験がが必要でした。経験豊かなAWSのエンジニアやコンサルタントの助けを借りずに学びながら行いました
  • サーバーとデータベースのメンテナンス: Amazon EC2のセットアップでは、サーバーにパッチを当てて、手動でデータベースのアップグレードを実行して、クライアントと操作手順およびサービスレベル契約に沿った状態を維持する必要がありました。コンピューティングとストレージのリソースを追加する以外に、データベースの保守に費やした時間は、以前に実行したハードウェアベースのソリューションと大きく異なりませんでした

 

Version 3.0: Aurora

2015年の残りの期間で、クライアントのために多数の新しいデータパートナーを導入しました。特に、私たちにあまり綺麗になっていないデータを送信して、データの品質チェックを何とする義務がありました。サードパーティのデータプロバイダを扱う多くの人が経験していると思いますが、ベンダーは以前に問題を処理していた方法を上書きする新しい例外を導入することに堪能でした。これにより、クライアント用に構築したデータベース内で整合性の問題が発生することがありました。これは、処理前のポイントから手動でリストアする必要があります。そのため、私たちは、バックアップとポイントインタイムのスナップショットプロセスを維持することよりもはるかに多くの時間を費やしていました。

EC2インスタンスでMySQLを実行することは、既存のチームがクラウドサービスのコア機能がどのように機能しているかを理解する上で非常に重要な出発点でした。しかし、2016年の初めには、AWSインフラストラクチャーへの一歩を踏み出し、この特定のデータベースをAmazon Auroraに移行する時が来たと考えました。更新、アップグレード、バックアップ/リストアプロセスなど、メンテナンスのための組み込み機能を利用できます。

利点

Auroraへの直接的な移行が必要でした。Auroraへの移行は、当社のソリューションを維持する上で残った非効率性の大半を取り除きました。エンジニアとDevOpsチームは、ポイントインタイムリストア処理の手動コンポーネントから大幅に解放されました。エンジニアが一般的なAWSスタックに精通しており、データが既にAmazon S3に保存されていたため、Amazon EC2ソリューションからAuroraへの移行はかなりシームレスでした。

私たちが始めたハードウェアベースのソリューションと比較して、Auroraは私たちに次のことをもたらしました:

  • インフラコストの大幅な削減: 設備投資(Capex)のリソースコストは現在50-60％削減出来ました
  • 劇的に削減されたメンテナンス: 私たちは、このシステムをサポートするために日々のデータベース管理リソースの約80％を削減でき、チームが顧客のために製品価値を構築することに注力出来るようになりました
  • 増大するデータのニーズに対応するためのシームレスな垂直スケーリング: 数時間または数日ではなく、数分で容量を追加できるようになりました
  • ターンキーバックアップとリストアプロセス: これは、エラーが発生しやすい、時間のかかるカスタムプロセスではなく、AWS Management Consoleで数回クリックするだけで完了するようになりました

Auroraは、私たちの特定のクライアントのユースケースに対して効果的に動作します。これは、小規模なレポーティングと分析プロジェクト用にMySQLを実行するリレーショナルデータベースを構築する必要があるときは、今では標準のソリューションです。

チャレンジ

では、欠点は何でしょうか?  2016年中頃に初めて移行を完了したとき、サーバーと使用状況ログに定期的にアクセスする方法は不明確でした。ログに定期的にアクセスするには、定期的にAWS Lambdaのようなカスタムジョブを設定して実行する必要がありました。これは、MySQLがAWSリソースのクラウド監視サービスであるAmazon CloudWatchに直接データを送信することを可能にした最近のアップデートで部分的に対処されています。しかし、Amazon Redshiftのようなアナリティック・データベース製品には、ログ・アクセスが組み込まれているようです。

このユースケースではAuroraはうまく機能しましたが、すべての問題を解決出来るソリューションはないことを覚えておくことが重要です。我々は、アドバンテージが、ソリューション開発と継続的なメンテナンスのコストを上回るかどうかが不明確な多くのケースでAuroraの仕様を検討しました。たとえば、マルチリージョンのサポートと何千もの同時書き込みを必要とする消費者向けソリューションをサポートするには、SSDストレージ・オプションを使用して構築されたソリューションをカスタマイズし、複数のインスタンスを作成したり、シャーディングしたりする必要があります。これには多大な手間がかかり、継続的なメンテナンスが複雑になる可能性があります。

ここでの非効率性の仮定は部分的な情報に基づいた意見です。AWSはAmazon Aurora Multi-Masterという機能を発表しました。この機能はこの種のユースケースに適しています。

 

私達はハードウェアももう使いません

クライアント向けにこのソリューションのバージョン1.0を初めて完成してから4年が経過しています。最初にデータベースをAWSに移行してから3年が経過しています。それ以来、Amazon RedshiftからAmazon DynamoDBからAuroraまで、提供されているほとんどすべてのサービスとフレームワークで、数多くのAWSに関するデータベース関連プロジェクトを様々なクライアントに向けて完了しました。

最初のいくつかのプロジェクトでクラウドに移行する初期の学習の後、私はクライアントの技術チームの中でAWSの最大の主張者の1人になりました。Auroraのようなマネージド・ソリューションでは、単なるコスト削減以上のメリットがあります。当社のエンジニアおよびDevOpsチームは、メンテナンス、アップグレード、およびリカバリプロセスの時間を60〜80％削減し、クリエイティブな時間に当てています。

 

翻訳は星野が担当しました。原文はこちら。