ホーム
お役立ち
Google Service
オンプレミスから Google Cloud （GCP）のデータ分析基盤へ効率的にデータ移行を行う方法とは？

オンプレミスから Google Cloud （GCP）のデータ分析基盤へ効率的にデータ移行を行う方法とは？

BigQuery
Cloud
Cloud Composer
データマイグレーション
データ移行

公開年月日: 2022.06.09

更新年月日: 2024.09.26

オンプレミスから Google Cloud （GCP）のデータ分析基盤へ効率的にデータ移行を行う方法とは？

昨今、データ活用の重要性が大きな注目を集めており、自社が保有するデータを管理・分析する企業が増えています。データ分析のプラットフォームとして Google Cloud （GCP）を導入するケースは多いですが、実際にデータを活用するためには、越えなければならない様々なハードルが存在します。

データ活用のプロセスは、データの収集や加工、分析など多岐にわたりますが、今回は「データの収集」に焦点を当て、オンプレミス環境からデータ分析基盤となる Google Cloud （GCP）へのデータ移行について、重要なポイントなどをわかりやすくご説明します。

Google Cloud （GCP）によるデータ活用の課題

最近サービスを開始したスタートアップ企業であれば、初めからデータがクラウド上に存在するかもしれません。しかし、多くの企業はそうではなく、自社のデータをオンプレミス上に保管しているケースが一般的となっています。

クラウド環境から Google Cloud （GCP）へのデータ移行は比較的手間なく実現できますが、オンプレミス環境から Google Cloud （GCP）へのデータ移行は容易ではなく、この点がネックとなり、データ活用を諦めてしまう企業は一定数存在します。

そのため、オンプレミス環境から Google Cloud （GCP）へスムーズにデータ移行することが、 Google Cloud （GCP）によるデータ活用の第一歩だと言えるでしょう。このデータ移行の成否が、最終的なデータ活用や自社の DX の結果を大きく左右するため、必ず押さえておきたいポイントになります。

それでは、具体的にどのような点を意識して、どのような形でデータ移行を進めていけば良いのでしょうか？
次章以降で詳しくご説明します。

オンプレミス環境から Google Cloud （GCP）の分析基盤へデータ移行する際の3つのポイント

オンプレミス環境から Google Cloud （GCP）へデータ移行する際、データの移行先は Google Cloud Storage （GCS）を用いるのがベストプラクティスである、とされています。 GCS は Google が提供しているオブジェクトストレージであり、 Google Cloud （GCP）に内包されているサービスの一つです。

そこで今回は、オンプレミス環境から GCS へデータ移行する、という前提に立ち、意識すべき3つのポイントをご紹介します。

ネットワーク

1つ目のポイントはネットワークです。通常、オンプレミス環境と GCS は離れた場所にあるため、両者を繋ぐネットワークが必要になります。自社のセキュリティ要件などをクリアしつつ、スムーズなデータ移行を実現するためのネットワーク構築が求められます。

データ転送ツールとインストール場所

2つ目のポイントはデータ転送ツールとインストール場所です。データを移行するためにどのツールを使うのか、そのツールをどこにインストールするのか、などを決める必要があります。例えば、「オンプレミスから GCS にデータを送る」または「 GCS 側からオンプレミスにデータを取りに行く」という2つのパターンが考えられます。

データパイプライン管理

3つ目のポイントはデータパイプライン管理です。データ移行は一過性のものではなく、継続的に行ってこそ真の価値を発揮します。いつまでも古いデータで分析を行っていては、最新のトレンドや顧客ニーズを正しく把握することはできません。そのため、全体のデータパイプラインを適切に管理することが重要になります。

このように、オンプレミス環境から GCS へデータを移行する際は、前述した3つのポイントを押さえておく必要があります。しかし、これらを検討する上では様々な選択肢が存在するため、どれを選べば良いのか迷ってしまうケースもあると思います。

そこで、次章以降では、3つのポイントそれぞれについて、どのような選択肢があるのかを詳しく解説します。自社に最適なデータ移行を実現するためのヒントにしていただければ幸いです。

ネットワークにおける選択肢

ネットワークにおける選択肢は大きく分けて「パブリック接続」と「プライベート接続」の2つがあります。以下、順番に見ていきましょう。

パブリック接続

パブリック接続は、インターネットを経由してオンプレミスから GCS へデータを移行する方法です。コストを抑えながら手軽にデータ移行を行える点が大きなメリットになります。

インターネット経由で GCS へデータ移行する際のポイントとしては、オンプレミス側のプロキシサーバーで GCS のドメイン許可をあらかじめ行っておくことです。具体的なドメインとしては「 accounts.google.com 」や「 googleapis.com 」などが挙げられます。

一般的なプロキシサーバーでは、限られた通信しか通さないようになっているため、事前にドメイン許可を行うことでスムーズなデータ移行を実現できます。また、インターネットはセキュリティ面で不安を覚える方が多いですが、 GCS への通信は HTTPS の暗号化通信になるため、一定のセキュリティを担保した状態でデータを移行することが可能です。

プライベート接続

プライベート接続はインターネットを使わず、プライベートな通信を経由して GCS へデータを移行する方法です。代表的なものとしては VPN や Partner Interconnect 、 Dedicated Interconnect などが挙げられます。

VPN とは Virtual Private Network の略であり、インターネットの回線上に仮想的なプライベートネットワークを構築する技術です。インターネット経由で通信を行う場合と比較して、セキュリティを大きく強化することができます。

Partner Interconnect と Dedicated Interconnect は、どちらも物理的な専用線です。 Partner Interconnect は Google のパートナー企業に専用線の敷設を依頼するものであり、 Dedicated Interconnect はユーザー企業が自社で専用線を敷設するものです。

これらを使う上で注意しておきたいポイントは、 GCS の通信は Google の API 経由でデータのやり取りを行うため、 VPN や Interconnect を使っていても、インターネット経由での通信になってしまう、という点です。

ここからは、 VPN や Interconnect でセキュアに GCS へアクセスするための選択肢を2つご紹介します。

プロキシを利用する方法

1つ目の選択肢はプロキシを利用する方法です。 VPN や Interconnect は VPC （ Virtual Private Cloud ：仮想プライベートクラウド）への経路を確立するためのものであるため、 VPC 上にプロキシサーバーを構築することで、 VPC 内のプロキシサーバーを経由して、インターネットを通らずに GCS へ通信することが可能になります。

この方法では、設定が必要となるポイントが少なく、ネットワーク全体に大きな影響を与えないため、小規模でテストを行いたい場合などに有効な選択肢になります。

DNS やルーティング設定を行う方法

2つ目の選択肢は DNS やルーティング設定を行う方法です。 DNS やルーティングに対して追加設定を行うことで、インターネットを通らずに GCS へ通信するための環境を構築します。この方法では、ネットワークレベルで大規模な設定を行うため、オンプレミス環境の通信を一括で変更できます。

また、 Google Cloud （GCP）側のプロキシサーバーが不要になる点もメリットの一つです。大規模なネットワークに対して設定を行う場合には、有効な選択肢になると言えるでしょう。

さらに詳しく知りたい方は以下の記事がオススメです。

【トップゲート主催】Google Cloud ハイブリッドクラウドセミナー体験レポート

データ転送ツールとインストール場所における選択肢

次に、データ転送ツールとイントール場所について見ていきましょう。データ転送に使われるツールは多岐にわたりますが、ツールごとに特徴が異なるため、自社に最適なものを選ぶことが大切です。

データ転送ツールを大きく分けると、以下の3種類に分類されます。

主にデータソース側で使われるツール
主に Google Cloud （GCP）側で使われるツール
どちらでも使われるツール

以下、それぞれのツールについて具体的にご説明します。

主にデータソース側で使われるツール

データソース側で使われるデータ転送ツールとしては fluentd が挙げられます。 OSS （ Open Source Software ：オープンソースソフトウェア）のログ転送ツールであり、ストリーミングでログを持ってくるときにオススメです。

主に Google Cloud （GCP）側で使われるツール

Google Cloud （GCP）側で使われるデータ転送ツールとしては Cloud Dataflow や Cloud Data Fusion が挙げられます。 Cloud Dataflow は Apache Beam のマネージドな実行エンジンであり、 Cloud Data Fusion はノンコーディングでの ETL 処理やパイプライン管理が可能なツールとなっています。

Cloud Dataflow に関心のある方は以下の記事がオススメです。

Google の ETL サービス「 Dataflow 」とは？概要、特徴、できること、料金体系まで徹底解説！

Cloud Data Fusion に関心のある方は以下の記事がオススメです。

Google のデータ統合サービス「 Cloud Data Fusion 」とは？機能、特徴、料金体系、できることまで徹底解説！

どちらでも使われるツール

データソース側と Google Cloud （GCP）側のどちらでも使われるデータ転送ツールとしては gsutil や embulk などが挙げられます。 gsutil は GCS 用の CLI ツールであり、 embulk は OSS のバッチ転送ツールです。 CLI （ Command Line Interface ）とは、ソフトウェアがユーザーに対して情報提示を行う方式の一つであり、すべてのやり取りがテキストで行われる、という特徴を持っています。

gsutil は簡単に扱えるため最初に検討されることが多く、 embulk はデータの取得元が多岐にわたる場合にオススメのツールとなっています。この他、 Google Cloud （GCP）のライブラリがデータ転送に利用されるケースもあります。

gsutil を使う場合のポイント

ここまで、様々なデータ転送ツールをご紹介しましたが、今回は多くのケースで頻繁に利用される gsutil について詳しく解説します。

gsutil でデータ転送を行う場合のポイントとして、マルチスレッドの活用が挙げられます。これは、複数ファイルを並行転送するための機能であり、複数のデータを同時に転送できるため、多くのデータを扱う場合でも効率的にデータ移行を行うことが可能です。

また、一つのファイル容量が大きい場合は、並列複合アップロードが効果を発揮します。これは、膨大なファイルを複数のコンポーネントに分割し、それぞれを並列的にアップロードできる機能です。これにより、大容量ファイルを扱う場合でも、スムーズなデータ移行を実現できます。

このように、 gsutil を活用する上では、各機能を駆使することでデータ移行の作業効率を高めることができます。 gsutil は利用機会の多いツールなので、ぜひ覚えておいてください。

データパイプライン管理における選択肢

最後に、データパイプライン管理ですが、具体的なツールの選択肢に入る前に、重要なポイントを一つご紹介します。それは「データ連携の始まりと終わりを理解する」ということです。

例えば、以下のような内容が挙げられます。

どこまでのジョブが終われば利用者に価値を提供できるのか？
エラーハンドルやリトライをすべき境界線はどこか？
プロジェクトのスコープに囚われすぎていないか？

このような点を念頭に置き、組織全体で本質的なデータ連携を検討することが大切です。手段が目的にならないよう、具体的なデータパイプライン管理を構築する前に、一度立ち止まって考えてみてください。

それでは、データパイプライン管理に使えるツールをいくつかご紹介します。

Google Cloud （GCP）のサービス

データパイプライン管理に利用できる Google Cloud （GCP）のサービスとしては Cloud Composer や Cloud Data Fusion が挙げられます。 Cloud Composer は Apache Airflow のマネージドサービスで汎用性が高く、 Cloud Data Fusion はノンコーディングでパイプラインを組むことができます。

Cloud Composer に関しては、後ほど詳しくご紹介します。

Airflow 以外の OSS ツール

Google Cloud （GCP）のサービスを使わない場合は Airflow 以外の OSS ツールを利用することもあります。例えば、 Digdag や Luigi などが代表的なツールであり、これらは OSS として提供されているため、誰でも簡単に利用できる点が大きなメリットです。

プロプライエタリツール

オンプレミス環境の中で従来から利用しているプロプライエタリツールでデータパイプラインを管理する、という選択肢もあります。例えば、環境全体における Google Cloud （GCP）の利用割合が少ない場合は、プロプライエタリツールで全体管理をした方が効率的なケースも存在するため、実際に多くの企業がこの方式を採用しています。

Cloud Composer とは？

ここで、利用頻度が高い Cloud Composer について簡単にご説明します。

Cloud Composer は Google Cloud （GCP）で提供されているワークフロー構築サービスです。 Google 公式サイトでは、 Cloud Composer を「ワークフローオーケストレーションサービス」と表現しています。オーケストレーションとは、システムやサービスにおける設定や運用管理の自動化を指す言葉です。

Cloud Composer を活用することで、 Google Cloud （GCP）上にワークフローを作成し、デプロイすることができます。デプロイとは、構築したサービスなどをサーバー上に展開・配置して、利用可能な状態にすることです。

また、 Cloud Composer は「 Apache Airflow 」のオープンソースプロジェクトをベースに構築されており、「 Python 」のプログラミング言語を使用して運用されています。 Apache Airflow は Python で実装されている Job 管理ツールであり、直感的でわかりやすい操作性が特徴です。

つまり、Cloud Composer を使えば、 Apache Airflow をベースとした操作性の高いワークフローを Google Cloud （GCP）の環境に構築し、デプロイや運用管理までを一気通貫で実現できるということです。

Cloud Composer に関心のある方は以下の記事がオススメです。

Google のワークフロー構築サービス「 Cloud Composer 」とは？概要、特徴、料金体系、できることまで徹底解説！

想定ユースケースごとのサンプルアーキテクチャ

最後に、想定ユースケースごとのサンプルアーキテクチャをご紹介します。よくあるシーンを3つ想定し、どのようなアーキテクチャが考えられるのか、それぞれのパターンごとに解説します。

ケース1.BigQuery で自社データを分析したい

このケースでは、以下の3つが前提条件となっています。

BigQuery で初めて自社データを分析する
NFS などに置いてあるログファイルを転送したい
テストなので環境構築は最小限にしたい

これらの条件を前述した選択肢と照らし合わせて考えてみます。

まず、テストなので一度データ移行できれば良く、ジョブ管理までは考える必要がありません。また、ツールの指定がないため、簡単に扱うことができる gsutil を採用し、インターネット上の HTTPS でポリシー上の問題がないかどうかを念のため確認します。

上記を踏まえると、非常にシンプルなアーキテクチャとなります。オンプレミス環境にあるデータを gsutil の gsutil cp というコピーコマンドで GCS に送ります。このとき、通信は HTTPS で暗号化されています。その後、 GCS に移行されたデータを bq load コマンドで BigQuery に転送すれば完了です。

ケース2.BigQuery で自社データを分析したい（プライベート接続必須）

このケースでは、以下の4つが前提条件となっています。

BigQuery で初めて自社データを分析する
NFS などに置いてあるログファイルを転送したい
テストなので環境構築は最小限にしたい
必須でプライベート接続をしたい

基本的にはケース1と同じ内容ですが、プライベート接続が要件として追加されています。この場合、アーキテクチャはどのように変わるのでしょうか？

ケース1では高いセキュリティが求められなかったため、インターネットによる通信を採用しましたが、今回はプライベート接続が必須となります。そのため、ネットワークの部分は VPN とプロキシを使った構成とし、セキュリティを強化します。

この場合、オンプレミス環境でプロキシ設定を行なった上で gsutil cp でデータを VPN 経由で GCS に送ります。そして、 Google Cloud （GCP）側にもプロキシサーバーを構築し、そのプロキシサーバーを通して GCS にデータを送り、 BigQuery へ流していく構成となります。

ケース3.履歴テーブルを BigQuery に1日1回同期したい

このケースは実践的な内容であり、以下の3つが前提条件となっています。

オンプレミス DB の履歴テーブルを BigQuery に1日1回同期したい
DB サーバーへのツールインストールは許可されなかったが JDBC 接続は可能
セキュリティ観点からインターネット経由は避けたい

まず、履歴テーブルは日々増えるものであり、1日1回の同期を行うため、ジョブ管理が求められます。また、 JDBC 接続が可能なツールを選ぶ必要があり、プライベート接続経由で DB へアクセスする仕組みを構築しなければなりません。

この場合、 Cloud Composer を活用したアーキテクチャが考えられます。 Cloud Composer でエラーハンドリングやジョブ管理は実現できますし、 JDBC 用の Operator を使うことで、オンプレミス側のデータベースからデータを取得することが可能になります。なお、インターネット経由を避けるため、ネットワーク部分は VPN または Interconnect 経由でのプライベート接続になります。