NTT DATA

DATA INSIGHT

NTTデータの「知見」と「先見」を社会へ届けるメディア

絞り込み検索
キーワードで探す
カテゴリで探す
サービスで探す
業種で探す
トピックで探す
キーワードで探す
カテゴリで探す
サービスで探す
業種で探す
トピックで探す
2021年5月17日技術ブログ

データベース移行で「攻める」ビジネスを

システム特性に応じた適切なDB製品選択ができているだろうか。
その際には汎用RDBMSだけでなくNoSQLやビッグデータ向けといったさまざまなDBを目的に合わせて選択するのが重要だ。ここではビジネスを成長させる鍵でもあるデータベース製品の移行とその課題を考える。

データベース移行でビジネスを成長させる

例えば自社のECサイトのレスポンス性能がどうも遅い、と思っているシステム管理者がいたとします。
ECサイトの性能を悪化させているのはレコメンド機能だということがわかっていました。しかしレコメンド機能は売り上げ増に寄与していることもわかっており、半年後に予定しているシステム更改では、さらなるレコメンド機能の拡充をしたいと考えていたところでした。
そんなとき、彼はGoogleによるこんな調査結果を目にしました。

表示速度が1秒から3秒に落ちると、直帰率は32%上昇する
表示速度が1秒から5秒に落ちると、直帰率は90%上昇する
表示速度が1秒から6秒に落ちると、直帰率は106%上昇する
表示速度が1秒から10秒に落ちると、直帰率は123%上昇する

出典:Daniel An、Google モバイル部門のグローバルプロダクトリーダーによる記事
“New Industry Benchmarks for Mobile Page Speed – Accelerated Mobile Pages Project”(※)

このままでは頑張ってレコメンドの機能拡充をしても、レスポンス性能低下によりサイトを訪れる人が激減してしまう、ということに気付きシステム管理者は悩みました。

これを解決する方法としてレコメンド機能について、データベースを従来のRDBMSから、業務目的に合ったグラフDBに移行して切り出す案があります。

レコメンド機能をグラフDBに移行してサイトの魅力を向上

(参考)グラフDB

データを従来のRDBMSのような「表」ではなく、ノード・プロパティ・エッジによる「グラフ」で格納するタイプのデータベース。関係をたどる検索が非常に速いという特徴がある。

グラフDBのデータ構造例

レコメンド業務にマッチしたグラフDBに機能を移行することで、パフォーマンス改善や充実した機能追加が可能となり、さらなるビジネスの拡大が狙えるでしょう。
性能や機能の限界点を上げ、自社サービスが生き残るためには、システム特性に合わせて適切なデータベースへ移行することが解決になることがあります。
適切なデータベース製品の選択はコストダウンだけでなく、ユーザ体験を向上させるなど、ビジネスを拡大する鍵でもあります。データベース製品を変えることによるコストダウンやビジネス成長というメリットが移行コストをペイするならば、データベース変更を「攻め」の判断として決断すべきではないでしょうか。

しかしそれがわかっていても、データベース製品を後から変更することはアプリケーションや基盤の大きな変更を伴うため、なかなか難しいものです。
ここでは、データベース移行における課題は何か?どう乗り越えていくか?を解説します。

(※)出典:Daniel An、Google モバイル部門のグローバルプロダクトリーダーによる記事
“New Industry Benchmarks for Mobile Page Speed – Accelerated Mobile Pages Project”

https://amphtml.wordpress.com/2017/02/28/new-industry-benchmarks-for-mobile-page-speed/

データベース移行を乗り越える

データベース製品の移行では「移行の実現性の判定」「アプリケーション資産の移行」「DBデータの移行」「DB基盤の再設計」が課題となります。

データベース製品移行における課題

移行の実現性の判定プロジェクト後半でノックアウトファクターが見つかる事態は最悪です。
プロジェクト開始前に、想定している機能・非機能が、移行後のDBで実現可能なのかを見極める必要があります。
また、移行にかかる工数(コスト)を正しく見積もることも重要なポイントです。
アプリケーション資産の移行現行アプリケーション資産を移行後のDBでそのまま動作させたい場合でも、アプリケーションの書き換えと動作テストが必要になります。
これは、データベースごとにSQLの方言や、使用可能な関数・機能に違いがあるためです。また、一見正しく移行できたように見えても、特定値や異常値を入力とした際の動作が変わることも多く、入念なテストが必要で、決して簡単ではありません。
DBデータの移行テーブル定義や各種オブジェクト定義は、移行後のDBアーキテクチャに合わせて変更が必要になります。また、データ自体の移行も必要で、短時間での移行切り替えを実現するための移行方式の工夫や、文字化け等を防ぐ移行設計が重要です。
DB基盤の再設計現行システムの非機能要件(可用性、信頼性、セキュリティ、性能…)を下げないような実現方式を設計する必要があります。 移行前後のDB間で同様方式が取れない場合も多く、その場合は代替方式を設計する必要が生じます。

こういったDB移行の課題をどう乗り越えれば良いのでしょうか。 これらの課題はDB移行のリスクであり、リスクが顕在化しないような対処をプロアクティブに実施するプロジェクト計画が重要となります。下記のようなリスク回避のためのタスクを実施する計画を盛り込みます。

データベース移行の課題を乗り越えるためのタスク

DB移行の課題を正しく認識し、必要なタスク実施を計画することで、データベース移行が実現できます。
データベース移行の案件を数多くこなしていくことでノウハウが蓄積し、移行のスピード感も上がっていきます。これは全体的なシステムアジリティの向上をもたらし、ビジネスの変化への追従速度を上げることができるでしょう。

- NTTデータは、「これから」を描き、その実現に向け進み続けます -
お問い合わせ