AWS クラウドへの移行時にデータベースコストを削減して可用性を向上させる

ログとクリックストリームのデータを保存するためにデータベーステーブルを使用するアプリケーションがあるとしましょう。開発タスクと管理タスクを容易にするためにリレーショナルデータベースにデータを保存するかもしれません。アプリケーションをカットオーバーすると、初めのうちはこのデータベースも管理可能ですが、データベースは毎週何百ギガバイトにも成長します。データの保存と取得だけでも、リレーショナルデータベースインスタンスの IOPS と CPU の 20 パーセントが消費されています。さらに、アプリケーションはトランザクションデータに加えて、データベーステーブルに XML ドキュメント、JSON ドキュメント、およびバイナリドキュメントも保存しています。履歴データも毎月増加し続けています。従来のオンプレミスデータベースのライセンスコストとインフラストラクチャコストは増えつづけ、データベースのスケーリングが大きな課題になっています。このような場合には何ができるでしょうか?

このブログ記事では、AWS クラウドに移行するときにデータベースコストを削減し、可用性を向上させる戦略について説明します。

データストアのタイプ

リレーショナルデータベース管理システム (RDBMS) は、ほとんどのトランザクション処理システムの中核を成しています。RDBMS にすべてのデータを保存することによって、以下が起こる可能性があります。

• パフォーマンス問題の原因になる。大規模なテーブルには、データのクエリにより長い時間が必要です。特定のテーブル一連における大量の読み取り/書き込みトラフィックは、データベースでの他のクエリの速度を低下させます。
• 総所有コスト (TCO) を増大させる。より多くの読み取り/書き込みトラフィックに対応するには、より多くのコンピューティングキャパシティーとストレージ容量を追加することによってデータベースを垂直にスケールする必要があります。これは季節的なトラフィックの増加に対処するためのものかもしれまんせんが、アプリケーショントラフィックへの対応に高額な先行投資を行わなければなりません。また、データベースサーバーをスケールダウンすることはできません。これも TCO を増加させます。

AWS に移行すると、アプリケーションはリレーショナルデータベースのストレージだけを使用するのではなく、そのデータを専用のデータストアに保存することができます。アプリケーションが使用するデータストアは、そのアクセスパターンに応じて異なります。これは、データがどのような規模で増加することを見込んでいるか、およびデータにどれだけ迅速にアクセスする必要があるかにも依存します。以下の表は、これらのデータストアのタイプと用途、および各タイプの例を示すものです。

これらのデータストアをデータ処理アーキテクチャで使用して、アプリケーションのパフォーマンスと可用性を向上させ、コストを削減します。この記事では、以下の AWS のサービスを使用することによって、従来の高容量オンプレミスデータベースの TCO を最小限に抑える方法を説明します。

• DynamoDB
• Amazon S3
• Amazon Relational Database Service (Amazon RDS)

以下の図は、DynamoDB および Amazon S3 などの複数のデータストアへの大規模なリレーショナルデータベースのリファクタリングを示しています。

このアプローチは、2 つの理由から、Amazon RDS または Amazon EC2 上のデータベースエンジンへのデータベースの移行 (Oracle から PostgreSQL への移行など) とは異なります。

第一に、多くの人が商用データベースエンジンを使用するアプリケーションを構築します。これらのアプリケーションは、リレーショナルデータベースエンジンに固有の機能を使用するかもしれません。このエンジンは、オープンソースのデータベースエンジンになく、大幅な改変が必要かもしれません。エンドステートのアーキテクチャにフットプリントが小さい同一のリレーショナルデータベースエンジンを保持することが、より迅速なクラウドへの移動に役立ちます。こうすることによって、アプリケーションまたはデータベースレイヤーで必要となる変更の量も最小限に抑えられます。類似するデータベース間での移行は、コードとデータベースオブジェクトがネイティブのデータベース移行ツール、または AWS Database Migration Service (DMS) を使用して移行されることから、常に最も簡単な方法です。

第二に、このアプローチでは、Amazon S3 と Amazon DynamoDB に移行できるデータベースの一部を特定することが推奨されています。これは、先ほどの図からもわかります。このアプローチは、ログ、クリックストリームデータ、ラージオブジェクトなどで急速に増加するデータによって引き起こされるパフォーマンス問題と TCO 問題の対処に役立ちます。

この記事の残りの部分では、このアプローチを次の 3 つのセクションに分けて検討します。

1. Amazon EC2 または Amazon RDS へのリレーショナルデータベースのサブセットの移動。
2. リレーショナルデータベースから Amazon S3 へのラージオブジェクトの移動。
3. DynamoDB などの NoSQL データストアへのリレーショナルデータベースのサブセットの移動。

Amazon EC2 または Amazon RDS へのデータのサブセットの移動

このアプローチの最も簡単な箇所は、データベースで変更したくない部分の特定です。データベースのこの部分は、Amazon RDS にある同一のデータベースエンジンに移行する、または Amazon EC2 にある自己管理型データベースで実行することができます。

Amazon RDS は、クラウドでのリレーショナルデータベースのセットアップ、運用、およびスケーリングを容易にするマネージドサービスです。Amazon RDS は、インフラストラクチャのキャパシティーのプロビジョニングからデータベースソフトウェアのインストールまで、リレーショナルデータベースのセットアップに関与する作業を自動で実行します。Amazon RDS は、バックアップの実行、およびデータベースを動作させるソフトウェアへのパッチ適用といった一般的な管理タスクも処理します。マルチ AZ 配置では、Amazon RDS が自動フェイルオーバーを使って複数のアベイラビリティーゾーン全体への同期データレプリケーションを管理します。データベースを Amazon RDS に移行させることによって、TCO を節約して運用のオーバーヘッドを削減し、リレーショナルデータベースのためにより優れたレベルの可用性と信頼性を実現できます。

データベースのどの部分を変更せずに残しておくかを判断するには、以下の質問を検討してください。

• データセットにあるデータの大半は、単一の行として頻繁に読み取りおよび書き込みが行われるトランザクションデータ、または多数の小規模バッチのどちらですか?
• このデータの処理と保存には、データベースオプションなどのデータベース固有の機能が使用されますか?
• 変更することが困難なこのデータセットにはプロシージャコードが記述されていますか? 例えば、Oracle データベースにある何百万行もの PL/SQL コードなどです。
• 変更することが困難なこのデータセットにはアプリケーションとユーザーインターフェイスコードが記述されていますか?
• アプリケーションは、このデータに対して複雑な SQL クエリを発行し、複数のテーブルからのデータを連結しますか?
• データベーススキーマにあるテーブルとエンティティの定義 (列の数、データタイプなど) は、アプリケーションが進化しても固定されたままですか? データの保存中、データモデル内の異なるテーブル全体に制約を適用したいですか?

リレーショナルデータベースのサブセットに関する前述の質問のすべて、またはそれらのほとんどに「はい」と回答した場合、そのサブセットは Amazon RDS または Amazon EC2 にあるリレーショナルデータベースへの移行に適しています。特定したデータのサブセットは変更されず、これはデータベースの大半、例えばその 50～60 パーセントにすることができます。このデータサブセットのサイズを判断するには、データベース管理者または開発者がデータベースのデータディクショナリをクエリして、Amazon RDS または Amazon EC2 に移行されるデータのサイズを把握することができます。

データの移行には、データベースエンジンのネイティブツール、AWS DMS、AWS Schema Conversion Tool、またはサードパーティーツールを使用できます。AWS DMS は、同種間および異種間のデータベース移行をサポートします。データベースのフルロード移行、一回限りの移行、または継続的な移行もサポートされ、アプリケーションダウンタイムの短縮に役立ちます。ネイティブツールと AWS DMS を使用した商用データベースソリューションの AWS への移行方法に関する詳細については、「AWS Database Migration Service のベストプラクティス」を参照してください。

リレーショナルデータベースから Amazon S3 へのラージオブジェクトの移動

多くのお客様が、キャラクタラージオブジェクト (CLOB) とバイナリラージオブジェクト (BLOB) をリレーショナルデータベーステーブルに保存するアプリケーションを設計しています。ほとんどのリレーショナルデータベースソリューションがこれらのデータタイプを許容し、ラージオブジェクト (LOB) を保存してそれらにアクセスする手段を提供するため、これはごく自然なことです。

データベースでの CLOB と BLOB の保存には、以下のメリットがあります。

• ポイントインタイム整合性。データベースを特定の時間に復元すると、すべてのデータとオブジェクトが以前と同じ状態に戻ります。
• アクセスの容易さ。
• セキュリティとアクセスのコントロール。

アプリケーションが 1 秒あたりギガバイト単位でこれらの LOB を生成している場合、リレーショナルデータベースでのこのデータの保存と処理は、ネットワークスループット、ディスク I/O、CPU、およびメモリを大量に消費する可能性があります。ラージオブジェクトを保存および取得する間における秒単位のトランザクション遅延を許容できるアプリケーションについては、このデータを Amazon S3 にオフロードすることでパフォーマンスと可用性を改善できます。Amazon S3 は、拡張性と信頼性に優れた高速で低価格のデータストレージインフラストラクチャへのアクセスを提供します。Amazon S3 は拡張性が高いため、パフォーマンスや信頼性を損なうことなく、小規模なアプリケーションから始め、希望に応じて成長させることができます。

LOB のポイントインタイム整合性を達成するには、リレーショナルデータベースにおけるトランザクションと共に、変更されたオブジェクトのバージョン ID を Amazon S3 に保存するようにアプリケーションロジックを変更する必要があります。アプリケーションにおけるこの変更は、TCO の削減とアプリケーション全体におけるパフォーマンスの向上に比べると、取るに足らないものです。

Amazon S3 への履歴データの移動

大規模データベースの多くには、頻繁に読み取られないのにストレージと CPU サイクルを消費する履歴データが含まれています。このデータは、例えばコンプライアンスおよび規制面での目的のために保持する必要があるかもしれません。このデータをリレーショナルデータベースで保持する代わりに、リレーショナルデータベースのデータから特定期間のアーカイブファイルを作成して、それを Amazon S3 または Amazon S3 Glacier にオフロードすることができます。

アプリケーションがこれらのアーカイブファイル内のデータにアクセスしなければならないときは、Amazon S3 Select または Amazon S3 Glacier Select などの Amazon S3 機能を使用できます。このアプローチは、1 年間に 99.999999999% の耐久性 (長期間のデータ保護) と 99.99% の可用性 (システム稼働時間) を提供しながら、データのストレージと取得のコストを大幅に削減できます。

DynamoDB などの NoSQL データストアへのデータのサブセットの移動

戦略全体の最後の部分として、リレーショナルデータベースからのデータのサブセットの保存に DynamoDB を検討してください。Amazon DynamoDB は、キー/値構造とドキュメントデータ構造をサポートする完全マネージド型の NoSQL データベースです。DynamoDB では、分散型データベースの運用とスケーリングにおける管理上の負担から解放されるため、ハードウェアのプロビジョニング、セットアップと設定、レプリケーション、ソフトウェアのパッチ適用、またはクラスタースケーリングについて心配する必要がなくなります。

DynamoDB などの NoSQL データストアに保存できるデータを特定するには、以下の要因を考慮してください。

• データは頻繁に、または高速度で書き込まれますか?
• 個々のレコードには、スキーマ設計の一部として決定できない可変数のフィールドと属性がありますか?
• データは、スキーマ内の他のテーブルとは無関係に書き込まれますか?
• データを結果整合として読み取ることができますか? 結果整合性とは、読み取り用に即時には利用できない可能性があっても、その後数秒間で読み取り用に利用できるようになるデータベースにデータが書き込まれる場合のことです。
• リレーショナルデータベーステーブルは、シンプルなクエリでクエリできる JSON ドキュメントとアプリケーションを保存していますか?
• ACID トランザクションをサポートするデータストアが必要ですか?
• グローバルなユーザーベースに低遅延でサービスを提供するために、データベーステーブルをグローバル (つまり、複数の AWS リージョン全体) にレプリケートする必要がありますか?

リレーショナルデータベースのサブセットに関する前述の質問のすべて、またはそれらのほとんどに「はい」と回答した場合、データのそのサブネットは Amazon DynamoDB などの NoSQL データストアへの移行に適しています。

前述の考慮事項に加えて、以下のようなデータは NoSQL データストアに移動させないでください。

• アプリケーションのユーザーインターフェイスのために多数のテーブルから集約される。
• オンライン分析処理 (OLAP) のソースとして多用される。
• BLOB データタイプとして扱われている。
• サイズが単独で 400 KB を超えるレコードがある。
• アプリケーションレイヤーでの大幅な変更が必要になる。

データストアの状態を理解することは、どのデータを NoSQL データストアに移動させて、どのデータをリレーショナルデータベースで保存し続けるべきかを判断するために役立ちます。関連データを NoSQL データストアに移動させることを決定した後は、DynamoDB 内のデータモデルの設計が将来のデータ増加に対するパフォーマンスの鍵となります。DynamoDB は、テーブル内のデータを異なる物理サーバー上の複数のパーティション全体に分散します。このデータは、DynamoDB にあるテーブルのプライマリキー (パーティションキー) のハッシュ値に基づいて分散されます。パーティションキーは、データの読み取り/書き込みパターンに応じて、DynamoDB がデータをパーティション全体に均等に分散できるようにするものを選択するようにしてください。こうすることによって、テーブルの読み取り/書き込みスループットが向上します。DynamoDB での正しいパーティションキーの選択に関する詳細については、Choosing the Right DynamoDB Partition Key を参照してください。

DynamoDB テーブルの設計が完了したら、AWS DMS を使ってリレーショナルデータベースから DynamoDB にデータを移行できます。詳細については、AWS Database Migration Service and Amazon DynamoDB: What You Need to Know を参照してください。

このセクションの初めでお話ししたメリットに加えて、データのサブセットをリレーショナルデータベースから DynamoDB に移行することにより、テーブル用にプロビジョニングした読み取り/書き込みキャパシティーに対する料金だけを支払い、大幅なコスト削減を達成できます。また、DynamoDB オンデマンドを使用できるようにもなりました。これは、キャパシティーを計画することなく、DynamoDB テーブルで毎秒何千件ものリクエストに対応することを可能にします。詳細については、Amazon DynamoDB 料金を参照してください。

まとめ

このブログ記事では、データベースを AWS に移行するときに、モノリシックデータベースを専用のデータストアに分割することについて読んでいただきました。データのために正しいデータストアを特定することによって、ライセンスおよびインフラストラクチャのコストの大幅な削減はもちろん、可用性の向上も実現できます。

このブログ投稿に関するコメントは、以下のコメントセクションからお送りください。この記事にあるソリューションの実装に関するご質問がおありの場合にも、このコメントセクションをお使いいただけます。

著者について

Ejaz Sayyed は、アマゾン ウェブ サービス、グローバルシステムインテグレーターチームのパートナーソリューションアーキテクトです。Ejaz が主に取り組んでいる分野には、AWS のデータベースサービス、および AWS でのデータベースとデータウェアハウスの移行が含まれます。

Karthik Thirugnanasambandam は、アマゾン ウェブ サービスのパートナーソリューションアーキテクトで、AWS クラウド導入において大手グローバルシステムインテグレーターと共に仕事をしています。Karthik は DevOps とサーバーレスの熱烈な支持者です。仕事以外では、読書と家族との時間を楽しんでいます。