広がるクラウドリフト市場と課題
クラウドインフラ市場は高い成長率を維持し、年々拡大を続けています。オンプレミスやプライベートクラウドでこれまで動かしてきたシステムをAmazon Web Services（以下、AWS）やGoogle Cloud、Microsoft Azure（以下、Azure）などのパブリッククラウドに移行する「クラウドリフト」もそれに伴い引き続き高い需要があります。一般的にクラウドリフトは以下のような目的でおこなわれます。
- 弾力性の向上
スケールアウト、スケールインが容易なクラウドの特性を活用し、変化する業務量に合わせて柔軟にリソースを確保する - TCO（Total Cost of Ownership：総コスト）の削減
ハードウェア費用を削減し、運用を効率化することでTCOを削減する
しかしながら、既存のシステムを変更することなくそのままクラウドに移行しただけでは、これらのメリットを十分に享受することはできません。
- 既存のシステムのアプリケーションが実行数（インスタンス数）の増減を想定した作りになっておらず、スケールアウト・スケールインによるクラウドの弾力性をいかすことができない
- データベースなどのミドルウェアが商用プロダクトに依存しており、クラウドに移行した際にライセンス費用が高額のまま残り、期待したTCO削減につながらない
これらの課題に思い当たる方も多いのではないでしょうか。
どちらの課題も重要ですが、前者のアプリケーションの対応はクラウドリフト後に徐々にクラウドネイティブな形に進化させていくアプローチがよくとられます。それに対して後者のミドルウェアについては、クラウドリフト段階で対応を計画しておかないと、クラウドリフトによりむしろTCOが増加してしまうことにもつながりかねません。本稿では後者のデータベースの移行、「DBマイグレーション」に焦点を当てていきます。
DBマイグレーションの課題とNTT DATAのアプローチ
DBマイグレーションはクラウドリフトの対応事項の中でも、特に重点的な検討が必要になります。その理由は、データベース、そしてデータはシステムの根幹であり、データベースを変更することによる影響範囲が広いためです。DBマイグレーションを伴うクラウドリフトでは、以下のような検討が必要になります。
- クラウドに移行してもシステム要件は満たせるのか
- 移行先のRDBMS（リレーショナル・データベース管理システム）をマネージドサービス含めて何に変更するか
- クラウドリフトやデータベースの変更に伴いアプリケーションはどの程度変更が必要になるのか
- スキーマ変換、データ移行をどのように進めるか
- 移行先のアーキテクチャーをどのように構築するか
- 全てを自分たちで管理するわけではないマネージドサービスをどのように運用設計するか
これらのほかにもさまざまな検討事項があり、一つひとつ実現性を含めて確認しながら、移行後の運用開始までのプロセスを整備していかなければなりません。
NTT DATAでは、DBマイグレーションに必要なプロセスやクラウド基盤の標準設計をオファリングとして整備しており、アプリケーションも含めお客さまのシステムに合わせたクラウドリフトのご提案が可能です。
図1：NTT DATAのDBマイグレーションのオファリング例
新規データベースサービスの動向
クラウドリフトした先の環境、つまり各クラウドベンダが提供するデータベースのマネージドサービスも日々進化しています。例えば、AWSはこの1年近くの間にAmazon Aurora Limitless Database（Limitless Database）、Amazon Aurora DSQL、Oracle Database@AWSなど、複数の新しいマネージドサービスを発表しました。Google CloudもCloud Spannerに加え、AlloyDBのような高いパフォーマンスを示すサービスを提供しています。
これらに共通するのは、特定のユースケースに特化したサービスであることです。
例えばLimitless Databaseは既存のAmazon Auroraよりも高いスケール性能を示し、これまでであれば書き込みの限界性能に達していたような大量トランザクション、大量データの処理を可能にする仕組みとして紹介されています。
少し内部に踏み込んで解説すると、Limitless Databaseは以下のようなアーキテクチャーを採用しています。
図2：Limitless Databaseのアーキテクチャー（引用元：https://aws.amazon.com/jp/blogs/news/join-the-preview-amazon-aurora-limitless-database/）
- Distributed Transaction Router（DTR）
図2ではTransaction Routersと記載されている、クライアントからのリクエストを受け付け処理するノード。後述のDASにクエリを振り分けて、最終結果を集約してクライアントにレスポンスを返却する。 - Data Access Shard（DAS）
図2ではShardsと記載されている、実データにアクセスして、参照や書き込みなどクエリを処理するノード
複数のDTRがクライアントからのクエリを受け付け、実データ処理はDASで分散処理する二層構造のアーキテクチャーを取ることによって、これまで以上の高トランザクションのリクエストをさばけ、高い書き込み性能を発揮できるとされています。
分散の核となるのが「シャーディング」と呼ばれる仕組みです。DASには特定のキーを元にデータが分散され、同じキー値を持つエントリーは同じDASに配置されます。
例えば、ECサイトを例に考えてみると、会員テーブルと注文テーブルという二つのテーブルがある場合に、どちらも会員IDという列を持つでしょう。この時、同じ会員IDを持つ会員テーブルと注文テーブルのエントリーは同じDASに配置されます。ECサイトでは、「ある会員の過去の注文履歴を抽出する」のように会員IDを元に処理するデータアクセスのパターンが多くあります。会員IDをキーとして関連するデータはひとつのDASに集約されているため、単一ノードで高速に処理できます。この仕組みによりLimitless Databaseは、分散処理によるスケール性能とパフォーマンスを両立可能です。
では、すべての既存RDBMSは今後Limitless Databaseに乗り換えていけばよいのでしょうか？その答えはNoです。
Limitless Databaseは高いスケール性能を示しますが、二層構造で処理をする仕組み上、単一のクエリ処理自体はどうしても既存のデータベースサービスに比べてパフォーマンスが劣ります。加えて、単一DASノードで処理ができず複数のDASノードに処理がまたがる場合は、さらにパフォーマンスに影響が出ます。
先ほどのECサイトの例において、「会員によらず特定の期間の注文一覧を取得したい」という場合、注文データは各DASに分散されて配置されているので、それぞれのDASから必要な情報を取得して、集約するという処理が必要になります。分析処理などデータをまとめて取得するような用途にはLimitless Databaseは向いていないのです。
このようにLimitless Databaseをはじめとするユースケース特化のサービスは、合致する利用用途では高いパフォーマンスを発揮しますが、そうでない場合にはかえって性能が劣化する可能性もあります。NTT DATAはこれまでの実績や知見をもとに、システムにあわせた最適な移行後の構成をご提案することが可能です。
まとめ
本稿では、クラウドリフトやDBマイグレーションの課題とNTT DATAのアプローチについてご紹介しました。クラウドリフトは単一のやり方があるわけではなく、成功させるためには取り巻く環境や利用しているシステム、今後の見通しをもとに最適な方法で進めることが重要です。
NTT DATAは本稿でご紹介したDBマイグレーションだけでなく、もちろんアプリケーションの移行や移行後の維持運用も含め、業界を問わず多くのクラウドリフトの実績があります。クラウドへのシステム移行にお悩みの方がいらっしゃいましたらNTT DATAにご相談ください。
クラウドについてはこちら：
https://www.nttdata.com/jp/ja/services/cloud/