データベースをクラウドに移行するためのベストプラクティス

クラウド コンピューティング業界の専門家は、オンプレミスではごくわずかな量の未使用データが、企業のクラウド プラットフォーム導入予算に重大な影響を及ぼす可能性があると指摘しています。

[[329282]]

デジタル変革により多くの企業が前例のない量のデータに直面しています。多くの人は、データ量の増加と分析要件の複雑化に直面しても IT パフォーマンスを確保するには、Microsoft Azure または AWS クラウド プラットフォームから SQL Server データベースを実行するのが最善の方法だと考えています。しかし、一部の人にとっては、クラウド プラットフォームに切り替えることで、よりコスト効率の高い作業が可能になることが最初の希望です。重要な理由の 1 つは、データ資産が新しいクラウド コンピューティング環境向けに事前に最適化されていないことであると考えられます。したがって、移行は十分な準備を行った後にのみ行う必要があります。

クラウドへの移行は、新しい家に引っ越すようなものです。家の中にあるすべてのアイテムを確認すると、自分が持っていることすら知らなかったものが見つかる可能性が高くなります。必然的に生じる疑問は、「家の中のすべてのアイテムは新しい家に関係しているのだろうか？」ということです。それとも、乱雑なものを徹底的に片付ける時期なのでしょうか?

このアプローチは、SQL Server データベースをクラウド プラットフォームに移行する場合にも適用できます。クラウド コンピューティング環境のルールはオンプレミス環境のルールとは異なるため、移行をスムーズに進めるには、データベースを適切にクリーンアップする必要があります。これを行うには、データベース管理者 (DBA) はまず、すべてのデータベースが接続されたアプリケーションとどのように対話するかの概要を把握する必要があります。これにより、データセット内の不要な乱雑さをクリーンアップし、必要に応じてコードを変更できるようになりました。したがって、移行する前に、評価フェーズとレビューフェーズで構成される 2 段階のプロセスを実行する必要があります。

評価フェーズ: 移行のためのデータの選択

クラウド移行が失敗する最も一般的な理由の 1 つは、コストが高いことです。多くの場合、これは新しいクラウド コンピューティング課金モデルがまだ十分に検討されていないことに起因します。未使用データの量（オンプレミスの運用では無視できるほど小さい）は、CPU、ストレージ、IOP によって価格が決まるクラウドでは予算に大きな負担をかける可能性があります。代わりに、事前に徹底的な評価を完了することで、新しい環境を可能な限り効率的に使用できるようになります。これを行うには、すべてのインベントリ データ レコードを識別し、クリーンアップ、アーカイブ、移行の 3 つのカテゴリに順番に割り当てる必要があります。

クリーニング

大量のジャンク データや役に立たなくなったデータ セットは、クラウド移行前にクレンジングするのに適しています。このカテゴリのデータには、過去に作成されたデータが含まれますが、データの品質が低い可能性があり、法的な理由でのみ保存する必要があります。法律で定められた期限を過ぎた場合は削除されることがあります。個人データの場合、GDPR 規制やその他のデータ保護規制に照らしてデータインベントリも考慮する必要があります。

アーカイブ

調査中に、データベースが逆の状況に遭遇する可能性もあります。つまり、一部のデータ セットは古くなっていますが、その品質は現在および将来の傾向分析に適しています。引き続きデータを読み取り専用モードで使用することをお勧めします。たとえば、Microsoft Azure への移行を計画している場合は、SQL Stretch Database を使用して、データを比較的低コストのストレージ層に簡単に移動できます。そこでは、データは読み取り専用モードで利用可能であり、ビジネス インテリジェンス操作、人工知能または機械学習機能の適用、予測分析の作成のために必要に応じて取得できます。

移住する

削除およびアーカイブする必要があるデータが決定されると、移行に適したデータの量が自動的に形成されます。このデータはオンプレミスの運用システムから取得されますが、クラウドベースの運用システムに直接転送できるわけではありません。移行後にレポートが意味をなさなくなったというユーザーからの苦情を防ぐために、次のステップでは、このデータに対して徹底的な品質チェックを実行しました。

チェックフェーズ: データベース品質チェック

移行プロセス中はアプリケーションとデータベースに変更を加えてはならないため、信頼性の高いパフォーマンスを妨げる機能はすべて排除する必要があります。アプリケーション レベルとデータベース レベル間のスムーズなやり取りを保証するために、追加の品質チェックを実行する必要があります。したがって、以下の点に注意する必要があります。

• テーブル、ビュー、トリガー、ストアド プロシージャ、ユーザー定義関数 (UDF) などのオブジェクトに対する一貫した命名標準。
• テーブルに含まれる値のいずれも 32 文字を超えていない場合は、CHAR(500) などのサイズが大きすぎる列を使用しないでください。
• GUID (グローバル一意識別子) はクラスター化インデックスとして使用されません。これは、拡張されていない小さなテーブルに対してのみ機能します。また、GUID をクラスター化された主キーとして使用していないかどうかも確認する必要があります。これにより、多くのパフォーマンスの問題が発生する可能性があるためです。
• NVARCHAR(MAX) など、最大サイズが定義されたデータ型はありません。
• 暗黙的な変換は、重大なコード問題を引き起こす可能性があるため、行われません。特に、オブジェクト リレーショナル マッピング (ORM) ツールを使用する場合、デフォルトで GUID をクラスタリング インデックスとして使用することが多いため、変換の問題が発生する可能性が高くなります。

さらに、クエリ タイムアウトのエンコードを再度確認する必要があります。オンプレミス環境で特定のクエリによってすでにサーバー タイムアウトが発生している場合、クラウドではこれらのタイムアウトが増加します。これを回避するには、クエリ タイムアウトと比較してクラウド プラットフォームでの回復力が高くなるようにコードを変更し、関連するクエリをそれに応じて最適化する必要があります。

もう 1 つの必要なタスクですが、場合によっては面倒な作業になる可能性があるのは、一時テーブルの作成など、よく使用される機能の評価とテストです。これらの機能はコードのロジックを改善するためによく使用されますが、パフォーマンスにプラスの影響を与えるのはそのうちのほんの一部です。クラウドで予期せぬ事態を回避するには、最も一般的に使用されるデータベース機能のテストを行うのが最善です。

しっかりとしたドキュメントがクラウドへの移行を助けます

全体として、クラウド プラットフォームに参入するには、データ カタログに基づいて包括的なドキュメントを作成するだけで済みます。移行後にアプリケーションとユーザーがすでに移行されていることが発覚しないようにするには、次の手順を実行して、ディレクトリに記録されたデータにアクセスするアプリケーションを記録する必要があります。

データベースにとっては、引っ越しの際に長い間忘れていたアイテムを扱わなければならないのと同じように、これは少し不快に思えるかもしれません。ドキュメント作成プロセスを簡素化するには、データ ソースの詳細な概要を自動的に作成できる適切な管理ツールを使用する必要があります。このようにして、クラウド コンピューティング サービスのスムーズな移行と効果的な使用のための適切な条件を作成できます。