データ ウェアハウスのクラウド移行における課題と対処方法

※この投稿は米国時間 2019 年 9 月 28 日に Google Cloud blog に投稿されたものの抄訳です。

編集部注 : 本稿はデータ ウェアハウスのモダナイゼーションに関する連載の第 2 回目です。第 1 回目はこちらをご覧ください。

前回のブログ投稿では、レガシーなデータ ウェアハウスが限界に達している理由と、企業がデータ ウェアハウスをクラウドに移行している理由について説明しました。お客様からは、クラウドへの移行は苦難の連続だという声をよく聞きますが、それはしっかりとした移行戦略が立てられていないからです。

レガシーな環境からモダンなデータ ウェアハウスへと移行するためには、事前に十分な時間とリソースをかけて準備しなければなりません。移行前にも移行中にも考慮すべきことがたくさんあるため、戦略的なアプローチのもとでプロセスを整理する必要があります。私たち Google Cloud は、データ ウェアハウスを BigQuery に切り替えようとする企業と協力し、あらゆるタイプの組織がクラウドへの移行で成功を収められるよう支援しています。データ ウェアハウスの移行に際してお客様からよく尋ねられることを以下に示します。

• 移行リスクやセキュリティ問題はどうすれば極小化できるのか？

• どれくらいのコストがかかるのか？

• どのようにしてすべてのデータを移行するのか？

• 移行前と同等以上のパフォーマンスがすぐに得られるのか？

移行作業に着手しようとする企業にとってこれらは重要な質問ですが、答えはすでに出ています。順に見ていきましょう。

移行リスクやセキュリティ問題はどうすれば極小化できるのか？

オンプレミスのデータ ウェアハウスは社内にあり、自社で管理できるので、安全だと見なされやすいことがあります。しかし、オンプレミスのデータ ウェアハウスを拡張することが難しい場合は、事業の拡大に合わせてセキュリティを保護することも簡単ではないはずです。

BigQuery にはさまざまなセキュリティ機能が組み込まれています。企業ユーザーにとっては、データへの適切なユーザー アクセスを役割ベースで設定するうえで Cloud Identity and Access Management（Cloud IAM）がカギとなります。SQL のセキュリティ ビューも BigQuery 内で利用できます。また、すべての BigQuery データは保存時や転送時に暗号化されます。さらに顧客管理の暗号鍵（CMEK）を追加すれば、より強力なセキュリティ対策を確立できます。データの漏洩リスクを軽減する VPC Service Controls を使用することで、移行パスの保護も可能になります。

どれくらいのコストがかかるのか？

クラウド データ ウェアハウスのコスト構造は、レガシーなデータ ウェアハウスのそれとは異なります。たとえば Teradata のようなオンプレミス システムでは、ハードウェアの 3 年分の利用料のほかに、システムにアクセスするユーザーのライセンス使用料を支払う場合があります。キャパシティの拡大時には、そのハードウェアの料金以外に追加費用がかかります。

クラウドを使用すると、コストと規模の選択肢が大きく広がります。固定されたコストではなく、データ ウェアハウスから多くの情報を引き出したければそのために料金を支払い、ニーズが下がればそのぶん料金を下げることができます。ただし、クラウド データ ウェアハウスは資本および固定コストの削減または排除に役立ちますが、すべてが同じというわけではありません。シンプルさとコスト削減のレベルがベンダーによって異なるため、各データ ウェアハウスでのパフォーマンス関連の運用コストを確認することが重要です。

BigQuery のようなクラウド データ ウェアハウスの場合、お客様にとっては TCO が、BigQuery への移行時に重要な指標となります（詳しくは ESG のレポートをご覧ください）。Google Cloud の柔軟性はコストの最適化を容易にします。

どのようにしてすべてのデータを移行するのか？

この質問には、ETL ジョブと SAS/BI アプリケーションのワークロードをターゲットのデータ ウェアハウスに移行することと、クエリやストアド プロシージャ、その他の ELT ジョブを移行することの両方が含まれています。

実際のところ、社内のすべてのデータをクラウドに移行することは、移行の初期段階では困難な作業のように思えるかもしれません。ほとんどの企業はサイロ化したデータを多く抱えています。それは、さまざまなチームが何年もかけてセットアップした複数のデータ レイクかもしれないし、重要なアプリケーションを 1 つか 2 つしか扱わない買収を通じて獲得したシステムかもしれません。オンプレミスまたはクラウドのデータ ウェアハウスから BigQuery にデータを移行しようとすると、型システムや表現が一致しないこともあります。

移行を成功させるためには、準備としてワークロードやユース ケースの抽出を行うと効果的です。現在あるユース ケースは何か、それらのユース ケースが大きなワークロードの一部になっているか、個々のユース ケースを支えるデータセット、テーブル、スキーマは何かということを洗い出すのです。ユース ケースは業種や部門によって異なります。たとえば、小売価格を決めるアナリストは、過去の製品価格の変化を分析して将来の価格を計算しようとするでしょう。そのためには、トランザクショナル データベースからデータを取り込み、製品ごとの時系列データに変換してデータ ウェアハウスのテーブルに格納する処理をユース ケースに組み込むことになります。

準備と抽出が終わったら、移行プランを立てるために、レガシー環境の現状を評価する必要があります。これには、ユース ケースの列挙と優先順位の付与、移行するデータとそうでないデータの分類、組織全体でのデータ形式の評価、変換やリライト対象の決定が含まれます。それらが決まったら、データ取り込みとパイプラインの方法を選びます。以上の作業にはテクノロジーと人間の両方が関わります。また、移行が成功したかどうかの判断基準について全社的なコンセンサスを形成しておくことも必要です。

移行前と同等以上のパフォーマンスがすぐに得られるのか？

レガシーなデータ ウェアハウスにスピードという言葉は似合いません。パフォーマンスを上げるためにはキャパシティを犠牲にしなければならないことが多く、ほかのクエリが終了するまで分析に取りかかれないことがよくあります。レポーティングやその他のアナリティクスの処理には数時間から数日かかることがあり、四半期末の売上計算といった大量のデータを扱う大規模なレポートの場合には特に時間がかかります。データ量とユーザー数が急激に増えると、パフォーマンスが低下しはじめ、組織はしばしば破滅的な機能停止に直面します。

一方、BigQuery のようなモダンなクラウド データ ウェアハウスでは、コンピューティングとストレージは分離しており、インフラストラクチャの制約に直面することなく、迅速にスケーリングできます。BigQuery ではお馴染みの SQL インターフェースが使用されているため、ユーザーは数秒でクエリを実行し、得られた知見を共有できます。たとえば Home Depot は、データ ウェアハウスの移行によって 8 時間のワークロードを 5 分に短縮したお客様の例です。

レガシーシステムが定着している場合などは特にそうですが、クラウドへの移行は大変な作業に感じられるかもしれません。しかし、これは単にツールを採用するのではなく、ビジネスを成長させるテクノロジーを取り入れることであり、非常に大きなメリットがあります。ビジネス ニーズが存在することはすでにご存じのはずです。そのニーズの前に立ちふさがるのではなく、成長の道筋をつけるべき時が来ているのです。

- By Ryan McDowell, Strategic Cloud Engineer and Nitin Motgi, Group Product Manager