シャーディングされたシステムをAuroraに集約してリソースの消費を削減

リレーショナルデータベースを利用したワークロードで、スケーリングを考えないといけなくなった時に、一般的にスケールアップとスケールアウトと2つの手法が上げられます。一般的にスケールアップの方が簡単に行えます(単純にスペックのいいマシンを購入するなど)。一方スケールアウトは、それぞれ独立したホストで稼働している複数のサーバへ、データベースをシャーディングする必要があり作業が煩雑になります。

難しさにも関わらずスケールアウトとが最近のトレンドとなってきています。コモディティハードウェアとシステムリソースへの要求の増加に伴いワークロードを効率的にシャーディングする必要が出てきました。シャーディングされたシステムの1つの欠点として管理コストがあげられます。もし4つのシャードを持っているとすると、4つのデータベースを管理する必要があります。しかし、たとえそうだとしてもスケールアウトはスケールアップよりコスト効率がいい場面が多かったのです。特にAmazon RDSの様なマネージドデータベースの登場によりリレーショナルデータベースの管理を軽減することが出来るようになったのがその1つの要因です。

しかし、なぜ過去形なのでしょうか? Amazon Auroraの登場によりスケールアップという選択肢が戻ってきたのです。Amazon Auroraは非常にスケールし、MySQL互換のマネージドデータベースサービスです。Auroraは2 vCPU/4 GiBメモリというスペックのインスタンスから、32 vCPU/244 GiBメモリ搭載のインスタンスまでを提供しています。Amazon Auroraは需要に応じてストレージが10 GBから64 TBまで自動的に増加します。また、将来のリードキャパシティの増加に備えて15インスタンスまで低遅延のリードレプリカを3つのアベイラビリティーゾーンに配置することが可能です。この構成の優れている点は、ストレージがリードレプリカ間でシャーディングされている点です。

シャーディングされたシステムを1つのAuroraインスタンスに集約、もしくは少数のシャードに集約しAuroraで稼働させることで多くのコストを節約する事が可能です。これがこのブログポストでお話したいことの全てです。

シャーディングされたシステムをAuroraに集約するために – まずはじめに –

多くのシャーディングされたシステムは標準的な方法で行うことが可能です。データはカスタマーIDなどの特定のキーを元に分割されており、何かしらマッピングを行う機能を用いてシャードに分割されています。この方法には様々な種類があり、1例として参照用のデータを別のシステムか1つのシャードに格納したり、全てのシャードに参照用のデータを配置するなどがあります。どのようにデータを分割しても、シャーディングの複雑さは通常、アプリケーションレイヤーにあり、シャードの統合は比較的容易に行えます。

多分皆さんは今、”利点はわかった。ではどうやってAuroraにデータを移行するのか”という疑問をお持ちかと思います。今回の例では、MySQLを利用して4つのシャードを持つシステムを利用していると仮定したいと思います。また、各シャードは他のシャードが持っているデータを持っていないものとします。また1つのシャードが参照用のデータを持っている前提とします。現在の構成は以下の図の様な構成になっていると思います。mapは各シャードへのアプリケーショントラフィックを表しています。

MySQLを運用しているため、Aurora documentationに記載されている方法を利用を利用可能です。簡単に移行を行うために、まずはじめに参照データのみが格納されているインスタンス1を移行します。しかし、どのシャードを最初に移行するかはそれほど重要ではありません。 移行が完了すると、マッピング機能はインスタンス1ではなくAuroraインスタンスを指します。システムは次の図のようになります。

残りのデータを移行する

この時点で、Auroraが特定のワークロードをどれくらいうまく処理しているか評価し、必要な調整を行う必要があります。設定に問題がなくなれば、他のデータを移行する準備は完了です。では、シャード2をAuroraインスタンスに移行しましょう。しかし、どうやって？

AWS Database Migration Service (AWS DMS)を是非ご活用下さい！AWS DMSはこのようなマイグレーションにも対応するように作られました。シャード2からAuroraインスタンスへデータをコピーするためにDMSをご利用になれます。更に、シャード2にとランアクションを実行しながらこれらの作業が可能です。DMSは初期データのロードが完了すると、それらのトランザクションデータをシャード2から収集しAuroraインスタンスに適用します。DMSは継続的にシャード2からAuroraインスタンスへデータを移行し、シャード2の代わりにAuroraインスタンスの利用を開始させるまで同期させます。シャード2からAuroraインスタンスへ切り替える準備が出来たら、シャード2へのトランザクションを停止し、DMSが最後のトランザクションをAuroraインスタンスへ適用するまで待ち、mapの設定を、シャード2に向いていたトラフィックを直接Auroraインスタンスへ向くように変更します。設定が完了すると、システムは以下のような状態になります。

この時点から、Database Migration Serviceを残り2つのシャードをAuroraインスタンスへ移行するために利用出来ます。最終的にシステムは以下の様になります。

複雑なシャードの扱い方

これでシャーディングされたシステムが1つのAuroraインスタンスへマイグレーションが完了し、コストを削減することが出来ました！しかし、MySQLを利用し、クリーンなシャードを利用しているとう仮定で話をすすめてきました。もしこれらの仮定にそぐわない場合はどうでしょうか？

それでは、シャードがクリーンな状態でない場合を見ていきましょう。例えば、システムが最初に2つのシャードで構成されていたとします。ある時点で、その2つのシャードを4つのシャードに分割したとします。 リシャードィングプロセスの一環として、シャード1と2のコピーを作成してシャード3と4を作成し、マッピング機能を更新しました。 結果は次のようになります。

この図は状況が複雑であるように見えます。 理想的には、このようなリシャードィングの際に、シャードに関係のないデータ、つまりグレーアウトされたデータをパージします。 しかし、必ずしも必要というわけではないし、時には難しいこともあるので、データをそのままにしておく事があります。 この方法では使用されていない冗長なデータを保持する”汚れた”シャードが発生します。 これらのシャードを統合しようとすると、アクティブなデータの行が、削除すべき重複した行と衝突する問題が発生します。

何をすべきか？ シャードの統合を行う前に、利用していない行を削除することができます。 しかし、特にマッピング関数がID値のハッシュ（一般的な方法の1つ）で構成されている場合、利用していない行を特定するのは難しいかもしれません。

諦めないで下さい！ 別のオプションがあるかもしれません。 各シャード内のデータが1つのデータベースに含まれている場合は、DMSを使用して、システムの各シャードをAuroraインスタンス内の単一のMySQLデータベースに統合できます。 次に、既存のマッピング・スキームを使用して、Auroraインスタンス内の適切なデータベースにトランザクションを転送できます。 この例では、Auroraインスタンスは次のようになります。

MySQL以外のデータベースを利用している場合

他の仮定として、データベースエンジンとしてMySQLデータベースを利用をしている前提がありました。もしそうでなければ？ OracleまたはMicrosoft SQL Serverを使用する場合はどうなるでしょうか？ 大丈夫です！ AWS Schema Conversion Tool が役立ちます！

ドキュメントの最初で「AWS Schema Conversion Toolは、ソースデータベースのスキーマとカスタムコードの大部分をターゲットデータベースと互換性のあるフォーマットに自動的に変換することで、異種データベースの移行を容易にします」と述べています。シャーディングされたシステムでは、ストアドプロシージャとトリガを使用してデータベース内に組み込まれた多くのビジネスロジックは、通常すでにアプリケーション側に移動されています。 AWS Schema Conversion Toolで、ソースデータベースとしてサポートされているデータベースエンジンでシャーディングされたシステムを利用している場合、Auroraへの変換と統合が可能かどうかを調べる価値があります。 統合の恩恵を受けるだけでなく、オープンソースプラットフォームへの移行のメリットも得られます。

さらに踏み込んで

さらに詳細に興味がありますか？ AWS Database Migration Service を使用して、シャーディングされたデータベースを1つ以上のAuroraインスタンスに統合する方法を説明する資料をまとめはじめました。 この例では、DMSチームが提供するMySQLサンプルデータベースのシャーディングバージョンを使用しています。 私たちはこのシャーディングされたバージョンをRDSスナップショットとして利用できるようにしました。 スナップショットは公開されているため、こちらの説明に従って試すことが可能です。それぞれ、説明中でmysql-sampledb-master-shard、mysql-sampledb-shard1、mysql-sampledb-shard2と呼ばれていたものです。

— Ed Murray (manager at Amazon Web Services) (翻訳は星野が担当しました。原文はこちら)