テクノロジー移行戦略に関する完全なガイド: (パート 3 – データベース移行)

公開: 2020-12-25

新しいアパートを購入するシナリオを想像してみてください。全員が入居するために満員で、慎重にプロセスを計画しました。あなたはすべて新しい家に引っ越す準備ができていますが、突然、問題があることに気づきます。家具や工芸品があなたの新しいアパートにうまく収まりません。

すべての家具を捨てて、ゼロから始めなければならないとしたら、どう思いますか? この類推をさらに進めて、新しいアパートを新しいデータベース、家具をデータと考えてください。ビジネスにとってデータは家具よりもはるかに重要であると確信しているため、移行を計画している間はデータのすべてを保持する必要があります。

テクノロジー移行シリーズの続きとして、このブログでは、データベース移行 (DBM) の基本、データベース移行を実行する際に理解し、考慮し、注意すべきことを明らかにします。

データベースの移行が必要な理由と時期は?

前回のアプリケーション移行ブログのフォローアップとして、今日の記事はデータベース移行 (スキーマ移行とも呼ばれます) を中心に扱っています。別。

基本的に、データベースの移行の必要性は、ビジネス要件に固有のものである場合もあれば、さまざまな規制当局によって制定された最新の複数の規制ポリシーを満たすためである場合もあります。 DBM が必要となる明確な状況はありませんが、これが避けられないいくつかの状況を以下に示します。

一般的な理由は、古いシステムを、ビジネス要件と最新のデータニーズを満たすシステムに移行することです。ビッグデータの時代には、新しい最新のストレージ技術が必要になっています。
特定の規制当局は、データが特定の地域にのみとどまるよう義務付けています。したがって、分散データを 1 つの場所に移行する必要があります。
一部の企業は、オンプレミスデータベースをクラウドデータベースに移行することを好みます。これにより、通常、データをサポートするために必要なインフラストラクチャと専門知識のリソースが節約され、システムが高速化されます。
新しいプラットフォームに移行することで、包括的なデータの整合性が確保されます。ストレージとメディアのコストが削減されるため、ROI が大幅に向上します。
現代の多くの企業は、すべてのデータを 1 か所に保管したいと考えています。このようにして、会社のすべての部門がデータにアクセスできます。

データベースシステムを新しいプラットフォームに移行することで、日常業務に発生する混乱が軽減されます。これは、新しいデータベースプラットフォームの選択が賢明であれば、最小限の手作業で行うことができます。

データベースの種類

データベースの移行に進む前に、まずさまざまな種類のデータベースを見てみましょう。

リレーショナルデータベース– リレーショナルデータベースは、データベース業界の主力製品として知られています。これらのデータベースは、一連のテーブルによって分類されます。テーブルは行と列で構成され、行にはデータインスタンスが含まれ、列には特定のカテゴリのデータエントリが含まれます。 SQL – 構造化照会言語は、リレーショナルデータベースの標準プログラミングインターフェイスです。
分散データベース– 名前が示すように、データは組織のさまざまなサイトに分散されます。通信リンクは、サイトを相互に接続するために使用されます。これにより、分散データベースに簡単にアクセスできます。
オブジェクト指向データベース– このタイプのデータベースは、リレーショナルデータベースとオブジェクト指向プログラミングの属性を結合します。 C++ や Java で作成されたさまざまなアイテムはリレーショナルデータベースに格納できますが、オブジェクト指向データベースの方が適しています。
NoSQL データベース – NoSQL データベースは、複数の仮想サーバーに格納された大規模な非構造化データを効率的に分析できます。対照的に、リレーショナルデータベースは一部のビッグデータパフォーマンスを効率的に処理できません。 NoSQL データベースは、このようなケースを簡単に管理でき、大量の分散データセットに使用されます。
クラウドデータベース– クラウドデータベースは、従量課金制の柔軟な仮想環境です。ユーザーは、要件に合った帯域幅とストレージ容量に対してのみ料金を支払う必要があります。
グラフデータベース –簡単に言えば、グラフはノードとエッジの集合です。グラフデータベースにはエンティティを表すノードが含まれ、エッジはそれらのエンティティ間の関係を表します。これは NoSQL データベースの一種であり、グラフ理論を使用して関係をマップ、保存、およびクエリします。
集中型データベース– このタイプのデータベースでは、データは単一の集中型の場所に保存されます。データベースには、基本的に、ユーザーがリモートの場所からも DB にアクセスできるようにするアプリケーションプロシージャが含まれています。

データベース移行のアプローチ

あるデータベースプラットフォームから別のデータベースプラットフォームへのデータの移行は、非常に重要な作業になる場合があります。移行が LIVE 環境で計画されている場合、移行は細心の注意を払って行う必要があります。データ移行を進める前に、都合のよい移行時間を選択する必要があります。稼働中のシステムでは、データが新しいデータベースに転送されるときにダウンタイムが発生することがよくあります。
データベースの移行には、主に次の 2 つの方法があります。

ビッグバンデータ移行:

このアプローチでは、限られた時間枠内でデータベース全体を一度に移行することを選択します。ビッグバンデータの移行はそれほど複雑ではないように見えますが、実際の Web サイトには十分なダウンタイムが必要です。さらに、このアプローチでは、移行がいつでも失敗した場合に備えて、移行プロセスの完全なロールバックを実現するのは容易ではない可能性があります。

トリクルデータ移行

このアプローチでは、移行プロセスを小さなチャンクまたはフェーズに分割する必要があります。移行に対するアジャイルアプローチのように、1 つのフェーズで障害が発生した場合は、そのフェーズのみをロールバックしてプロセスを繰り返す必要があります。ただし、Trickle データの移行には非常に時間がかかるため、プロジェクトのコストが増加する可能性があります。

さまざまな種類の移行

リレーショナル DB からリレーショナル DB

このアプローチは、最も単純な移行です。この種の移行を非常に効率的に実行し、ほぼ 100% の効果を発揮するツールは数多くあります。

リレーショナル DB から非リレーショナル DB へ、およびその逆

この移行は、前述の移行に比べてより困難です。リレーショナル DB と非リレーショナル DB は根本的に異なるため、それらの移行は 100% 効率的ではない場合があります。本質的に、非リレーショナル DB への移行は、データベースのスケーラビリティを保証する ACID プロパティ (アトミック、一貫性、分離、耐久性) を犠牲にすることを意味します。
ただし、リレーショナル DB から非リレーショナル DB へのデータベースの移行をサポートする無料のツールが複数あります。ただし、これらのツールはシステムのスキーマ構造をサポートしておらず、ほとんどがシステム要件に適応するには硬すぎるように見えるため、これらのツールを使用することは広く推奨されていません。

このタイプの移行でレンダリングできる基本的な変換のヒントがいくつかありますが、これを考慮することができます (簡単にするために、MySQL をリレーショナルデータベースとして、MongoDB を非リレーショナルデータベースとして考えてみましょう)。

convert-mysql-string-data-type-to-string-in-mongodb

MySQL の String データ型を MongoDB の String に変換します。これには、char、varchar、blob、text などが含まれる場合があります。
MySQL Numeric データ型を MongoDB の Number に変換します。これには、int、float、decimal、double などが含まれる場合があります。
MySQL の Date データ型を MongoDB の Date に変換します。これには、日付、年、タイムスタンプなどが含まれる場合があります。
MySQL Bool および Boolean データ型を MongoDB の Boolean に変換します。
他の場合も同様に評価できます。

ハイブリッドモデルでの移行

ハイブリッドモデル設計は、各システムの欠点を軽減しながら、2 つの一般的なデータベースモデルを 1 つのフレームワークに統合します。たとえば、データ集約型のイニシアチブ用の非リレーショナル DB と組み合わせて、要求の少ない操作用にリレーショナル DB を活用できるハイブリッドアプローチをいつでも採用できます。

データバックアップ

実行前に移行戦略を計画することで、スムーズな移行プロセスを確保できます。そうは言っても、常にプラン B を用意する必要があります。移行の実行中にデータが失われたり、データが破損したりする最悪のシナリオを想定します。再試行する前に、データを元の状態に復元する準備ができている必要があります。これが、DBM (データベース移行) 中にデータのバックアップが非常に重要なステップである理由です。では、安全なデータバックアップを確保するためにどのようなオプションが存在するのか、詳しく見ていきましょう。

クラウドバックアップ

移行イニシアチブを保護するための最も効率的で安全な方法の 1 つは、クラウドストレージへのバックアップを実行することです。基本的に、データをクラウドストレージにバックアップすると、ファイルはオフサイトに保存されます。これにより、問題を引き起こす可能性のあるローカルハードウェアの脆弱性が排除されます。では、なぜクラウドバックアップを使用するのでしょうか。

クラウドバックアップは、使用した分だけ支払う必要があるため、手頃な価格です。
エンドツーエンドの暗号化を提供するため、クラウドバックアップは安全です。
簡単なディザスタリカバリとデータリストアが可能
堅牢なクラウドバックアップオプションには、システムイメージ全体のバックアップが含まれます。したがって、OS を再インストールする必要はありません。コンピュータとサーバーは、最後に機能していたバージョンに復元されます。

ファイル共有ソフトウェア

Dropbox のようなソフトウェアスイートは、ユーザーのニーズを満たすために成長しています。 Dropbox は、必要に応じて復元できるファイルのバージョンを保持しています。クラウドバックアップと同様に、このオプションは手頃な価格であり、ファイルはオフサイトに保存されます。その利点は何ですか？

ファイルは、任意の場所の任意のシステムに復元できます。
無料でコラボレーションをサポートします。
安全性が高い (クラウドストレージは転送中のファイルを暗号化します)
オフライン作業機能

ただし、欠点は、復元が自動化されていないことです。データを保存するには、データをファイル共有ディレクトリ構造にコピー & ペーストする必要があります。ファイルは、定義された構造内に存在する必要があります。そうでない場合、ファイルはバックアップされません。ファイルが共有フォルダまたはディレクトリにある場合、それらのファイルをバックアップするには、おそらくより多くの帯域幅が必要になります。

一般的に言えば、フラッシュドライブや外付けハードドライブへのバックアップなど、バックアップ用に利用できるメディアは他にもあります。ただし、これらのオプションは、クラウドバックアップやファイル共有ソフトウェアと比較して完全に安全ではないため、お勧めできません。たとえば、ハードドライブに物理的な損傷があると、データが失われる可能性があります。さらに、ランサムウェア攻撃やクリプトウイルスの影響を受けやすく、脆弱です。

データの安全性を確保するにはどうすればよいですか?

データ移行を実行するときは、機密データが侵害または改ざんされていないことを確認する必要があります。移行に失敗すると、2020 年にここで挙げた例のように、より大きな結果を招き、データ漏洩やデータ損失につながる可能性があります。

残念ながら、データ漏洩はクライアントの評判を傷つけ、ビジネスや顧客の損失につながる可能性があります。または場合によっては、法的措置を引き起こす可能性があります。このような結果をすべて回避するには、移行戦略を念頭に置いて、事前にセキュリティ計画を策定する必要があります。

まず、信頼性が高く安全なサーバーアクセスとデータアクセスが優先リストに含まれている必要があります。
データ転送に必要なアクセス許可の数を増やします。大規模な組織では、セキュリティ部門がサーバーへのアクセスを制限し、関連するサーバー間のデータ移行を定義します。
より多くの関係者が関与すると、データは高いリスクにさらされます。そのため、ポータブルストレージデバイスや電子メールを介して当事者間で転送することは避けてください。このような場合、データは簡単に侵害される可能性があります。
データの安全なアクセス、保存、および検索を確実に行うには、暗号化と復号化を常に実践する必要があります。ハイブリッド暗号化アルゴリズムを使用して、最大限のデータセキュリティを確保できます。しかし、これはすべての人に推奨されるわけではありません。移行に失敗すると、データが乱雑になり、データの破損や損失につながる可能性があります。

安全な移行を確保するために、基本的なツールの使用は避けてください。原始的なツールを使用すると、システムが弱まり、ハッカーがアクセスできる抜け穴が残る可能性があります。機能固有のデータ移行用の堅牢なツールを採用する必要があります。

データ移行プロセス

データ移行は基本的に複数フェーズのプロセスです。データの損失を回避し、安全なデータベース移行を確保するには、次の手順に従う必要があります。

評価:

ビジネス要件分析を収集し、DBM で達成する必要がある主要な目標を定義します。
スコープを定義する
大規模なデータプロファイリングを実施します。
- ソースデータ、データ形式を確認し、スキーマ構造、コンテンツ、およびデータインスタンス間の関係を確認します。
宛先システムを理解する
利害関係者を特定する
活動全体の予算を立てる

データバックアップ

移行するデータが安全にバックアップされていることを確認してください。クラウドバックアップを使用することをお勧めします。
宛先がクリーンで、データハッキングから保護されていることを確認します。

リソースの可用性:

移行に利用できる時間と、移行先システムのダウンタイム。
採用した人材が適切なスキルセットを持っていることを確認してください。
適切なツールとスクリプトを特定します。

データ移行の実行:

移行プロセスには、データを移動するためのスクリプト、ETL ツール、またはその他の同等のツールが含まれる場合があります。
移行時に、データを変換し、データ型を正規化し、最後に考えられるエラーをチェックします。

テストとチューニング:

チームとクライアントチームは、すべてのデータが正しく移行されていることを非常に確認する必要があります。
したがって、データが正しく移動されているかどうか、データが完全であるかどうかを確認し、欠損値がないことを確認してください。
また、データが有効で、NULL 値が含まれていないことを確認してください。
データの不一致がある場合は、データのロールバックが必要であり、プロセス全体を再起動する必要があります。

監査

新しいデータベースが稼働したら、システムをセットアップしてデータを監査できます。これにより、データベース移行の正確さが保証され、不完全で不正確なデータに注意が向けられます。

データベースの移行に伴う潜在的なリスク

データベースの移行は非常に複雑な手順であり、リスクと不確実性が伴います。これらは、適切な計画と実行によって常に克服できます。発生する可能性のあるリスクは次のとおりです。

期限切れのソースシステム:ここでは、データソースが期限切れ、冗長、廃止、または些細な場合があります。
異種のデータベースアーキテクチャ:このシナリオでは、ソースデータベースが複数の場所に配置されている可能性があり、それらは互いにまったく異なるアーキテクチャを持っている可能性がありますが、宛先データベースではすべてが同期されている必要があります。
ダウンタイムの延長:計画された移行が予想よりも長くかかる場合があり、これによりシステムのダウンタイムが延長されます。これは、エンドクライアントにビジネス上の損失をもたらす可能性があり、受け入れられない場合があります。
潜在的なデータ損失:テスト段階ですべてのデータ損失を特定できるわけではありません。システムが十分なトラフィックを取得すると、一部のデータ損失インスタンスが最終的に特定される場合があります。

リアルタイムデータベースからの移行:トランザクションの多い Web サイトでは、データベースの移行は常に困難です。これは、データの更新が常に行われているためです。ライブデータとリアルタイムデータを移行することはできません。移行を行うにはダウンタイムが必要です。

最後に

データベースの移行に関するサードパーティの専門家からのガイダンスをいつでも求めることができます。私たちはクレオールスタジオであり、データベースの移行を専門としています. テクノロジー移行シリーズの 4 回目となる最後のブログをお見逃しなく。