HOME > 技術ブログ > 月別アーカイブ: 2021年5月

月別アーカイブ: 2021年5月

SCSK様と協業による「Google Cloud向け移行支援サービス」の提供開始

05/25/2021 Y.N

2021年5月24日に、SCSK様との協業による「Google Cloud向け移行支援サービス～お客様のデジタルトランスフォーメーション推進をサポート～」に関するプレス・リリースを発表しました。

記事はこちらからご覧頂けます。

https://www.scsk.jp/news/2021/topics/20210524i.html

SCSK様と協業による「Google Cloud向け移行支援サービス」の提供開始

【GCP】BigQueryを利用した迅速かつ安価なデータ分析基盤の構築検証

05/21/2021 T.W

はじめに

皆さん、こんにちは。クラウド基盤技術部のT.W.です。

弊社ではGoogle Cloud Platform (以下、GCP)を使ったシステム提案/開発に注力しており、各種イベントやGCPサービスを展開しております。

技術ブログでもGCP関連のネタを随時公開していきますので、是非ご活用下さい。

やりたいこと

GCP内に閉じた環境で迅速なデータ分析基盤構築と安価に構築できるデータ分析基盤の構築

検証で採用するGCPコンポーネント

GCP BigQuery(データウエアハウス)
GCP Cloud Data Fusion(ETL/抽出・変換・格納)
GCP Cloud Storage(データストレージ)
GCP Compute Engine(仮想マシン)
GCP Cloud SQL (データベース MySQL)

構成図

構成図の説明

まず初めに、今回の検証におけるデータの一連の流れを軽く説明します。

今回は、検証に利用するデータをデータカタログサイトから取得して、MySQLのデータベースに格納し、これをデータソースとして検証を実施します。

具体的には、データソースからSQLで必要なデータのみを抽出して、CSV形式でCloud Storageに格納し、このデータを取得、解析、加工して、BigQueryに投入します。

BigQueryに格納しているデータを如何に見える化・可視化するかは、Google社が提供する無料のBIツール「データポータル」を利用します。

最終的に、データポータルで作成したグラフなどの分析情報を分析依頼者に共有して完了とします。

事前準備

検証データ取得

https://www.data.go.jp/data/dataset/meti_20141009_0022

機能検証の段階では、なかなか本番システムのマスタデータを使用するのは難しいと思います。
そこで今回は、日本政府が二次利用が可能な公共データの案内・横断的検索を目的で公開しているオープンデータを利用します。

検証データをDBへ格納

検証で利用するCSV形式のデータを如何にMySQLのデータベースに投入するかは、いろいろやり方があると思います。

長年利用され続けてきたほとんどのRDBMSと一部のNoSQLに対応し、データベース統合開発環境として利用されている、JetBrains社のDataGripを今回は利用して、CSVデータをDBに投入します。
https://www.jetbrains.com/ja-jp/datagrip/

一般的なやり方ですと、テーブルの作成、データ型の指定、場合によっては、エラーハンドリングなどの煩雑なオペレーションを行わないといけないのに対し、DataGripを利用するとほぼ全自動でやってくれる利点があります。

DataGripから対象データベースに接続したら、事前に入手したCSVデータファイルをDataGrip画面の対象データベースにドラッグアンドドロップするだけで、テーブル定義、データ型の定義などが瞬時に作成されます。もちろん、細かい要件に応じて、微調整も行えます。

データ分析基盤構築

GCP Cloud Storageバケット作成

次はGCP Cloud Storageのバケットを作成します。
細かいところを無視して、バケットの名前のみ入力して作成します。

BigQuery テーブル作成

次はBigQueryテーブルを作成します。
自動生成されたカラム名とデータ型が問題ないか確認して、テーブルを作成します。

GCP Cloud Compute Engine

ここでは定期的にデータベースからデータを抽出することを想定してGCP Compute Engineを使用しますが、Cloud Functionでも対応できると思います。MySQLクライアントから、以下のSQL文でデータを抽出し、CSVデータとして一時的にローカルに保存します。

CSVファイルをCloud Storageへアップロードするには、以下のコマンドで実現します。
# gsuitl cp <CSVデータファイル名> gs://<バケット名>/<パス>

該当ファイルがCloud Storageにアップロードされたことを確認します。

GCP Cloud Data Fusion (ETLツール)

次はGCP Cloud Data Fusionの環境を構築します。
GCP Cloud Data Fusionを簡単で説明しますと、GUI環境でコードを意識せずに ETL / ELT パイプラインが作成できるサービスです。

実態はビックデータ解析・分析として有名はApache Sparkなので、GUIのあるApache Sparkサービスとも言えるでしょう。

作成が完了するまでは数分かかります。完了したら「インスタンスを表示」をクリックします。

「Wrangler」をクリックします。

事前にCloud StorageへアップロードしたCSVをクリックします。

最初はテキストファイルとして認識されていますが、以下のように数回クリックすることで簡単にCSVファイルとして認識させることができます。

今回の検証では利用しない機能ですが、以下のように機密情報などは簡単にマスキングすることもできます。

ほかにも、データ加工する機能、計算、変換、フォーマット変更などいろいろあるので、ぜひ触って見てください。CSV認識、カラム削除、データ型変換など合計25ステップのデータトランスフォーメーションが提供されています。

さて、Wranglerの右側にSink機能のBigQueryを追加して、加工したデータの出力先をBigQueryに指定します。あわせて、BigQueryのプロパティの出力先のプロジェクトID、データセット名とテーブル名を入力して保存し、デプロイます。

検証なので、クラスターのCPU、メモリ、ノート数などのサイジングはすべてデフォルトのままで実行します。ここで最重要かつ行わなければいけないことは、エラーが発生しないように祈ることです。笑

さて、Status箇所で「Succeeded」が確認できました。

GCP BigQueryにデータが入っているかどうかを確認します。

BigQueryにデータが確認できたら、データの見える化、可視化に移ります。

データポータル(BIツール)

データポータルは、Google社が提供する無料のBIツールです。Googleアカウント同士であれば、簡単にユーザ間で結果を共有することができます。

データポータルのメインページはテンプレートがたくさんありますが、今回は空のレポートを指定します。

https://datastudio.google.com/

データの接続先として、BigQueryを選択します。

プロジェクト、データセット、テーブルを指定します。

対象テーブルを指定すると、以下のような画面が表示されます。

グラフやチャートのタイプを選択するなど数回のクリックと、数分待つことで、以下のような綺麗なダッシュボードになります。

最後、完成した可視化できたデータを依頼者へ共有して完了となります。

検証は以上となります。

気を付けるべき点

1. BigQueryのデフォルト課金はオンデマンド課金のため、対策をせずに大量・不必要なクエリを実行すると、恐ろしい金額で請求される場合がある
2. GCP Cloud Data Fusionで文字列を数字に変換する際、Integer型へ変換失敗した場合はLong型を検討する
3. 現時点では、GCP Cloud Data Fusionのユーザ・インタフェースは英語しかない
4. GCP BigQueryとCloud Data Fusionのテーブルは日本語のカラム名に対応していない
　→ 早い段階でカラムを英語へ変換したほうが楽ですね。

今後について

今後については、以下の3点をブログで公開予定です。

1. ソースとなるデータベースをAWSのRDSと連携
2. AWS Lambda・GCP Cloud Functionsでデータを抽出して、CloudStorageにアップロードする部分を自動化
3. マルチクラウド環境で、如何に効率よく、かつ、セキュアなデータ連携を実現できるか、を考察

今後も是非、弊社の技術ブログを見守ってください！

まとめ

最後までお読みいただきありがとうございます。
このように、小規模から大規模なデータセットを簡単かつ迅速に安価なデータ分析基盤を作成できました。蓄積したデータを有効に活用できていないなと感じている方、ぜひお試しください！！！

【GCP】BigQueryを利用した迅速かつ安価なデータ分析基盤の構築検証

【GCP】CloudBuildを利用して、仮想マシンをGCEインスタンスに移行してみた

05/13/2021 R.A

はじめに

皆さん、こんにちは。入社2年目のクラウド基盤技術部のR.Aです。

弊社では昨年からGoogle Cloud Platform (以下、GCP)を使ったシステム提案/開発に注力しており、各種イベントやGCPサービスを展開しております。
技術ブログでもGCP関連のネタを随時公開していきますので、是非ご活用下さい。

今回はvSphere環境上の仮想マシンをGoogle Compute Engine (以下、GCE)インスタンスに移行する方法を説明します。

移行にあたり、GCPのサービスの一つであるCloud Buildを利用して、仮想ディスク（VMDKファイル）からGCEインスタンスとして起動できるイメージを作成します。

また、移行前の仮想マシンと移行した後のGCEインスタンスの変化しているOS設定を確認します。

そもそもCloud Buildって？

サーバーレスCI/CD (Continuous Integration / Continuous Delivery)プラットフォームで、特にCIである継続的インテグレーションを容易に実行できるGCPのサービスです。

ビルド構成ファイルなどに基づき、DockerイメージのビルドやPython、Javaなどのプログラミング言語で書かれたアプリケーションのビルド・テスト・デプロイに加え、ビルドの自動化やアーティファクト（成果物）の保存ができます。

今回の仮想ディスク（VMDKファイル）からGCEインスタンスとして起動できるイメージを作成する際には、ビルド構成ファイルなどの作成は必要なくGUI操作でポチポチするとGCE用のイメージが作成できます。

Cloud Buildについて詳しく知りたい方はGoogle公式サイトをご覧ください。
https://cloud.google.com/build

環境情報

vSphere環境（移行元）

移行対象の仮想マシンがあるvSphere環境情報です。

・ESXi 6.5

・vCenter 6.7

GCP環境（移行先）

仮想マシンの移行先であるGCP環境情報です。

Virtual Private Cloud（以下、VPC）、サブネット、ファイアウォールルールが既に作成してあるプロジェクトに移行します。

※赤枠で囲われているサービスを今回作成します。

移行対象仮想マシン情報

移行対象の仮想マシン情報です。

・CentOS 7.9

- ハードディスク1つ

- ネットワークアダプタ1つ

・動作確認用ミドルウェア

- Apache/2.4.6

前提条件

・移行対象の仮想マシンのVMDKファイルをダウンロードしていること

・移行対象先のプロジェクトやVPC、サブネット、ファイアウォールルールは事前に作成していること

・移行対象先のプロジェクトにアクセスできるIAMユーザーを有していること

・そのIAMユーザーにオーナー権限が付与されていること

大まかな仮想マシンの移行手順

以下の手順で、vSphere環境上の仮想マシンをGCP環境へ移行します。

１．VMDKファイルをGoogle Cloud Storage (以下、GCS)へアップロード

２．Cloud Buildを利用して、VMDKファイルからイメージの作成

３．作成したイメージからGCEインスタンスの作成

４．GCEインスタンスの動作確認

1. VMDKファイルをGCSへアップロード

このフェーズでは、VMDKファイルをアップロードするGCSバケットを作成しアップロードします。

ナビゲーションメニュー > [Cloud Storage] - [ブラウザ]を選択します。

画面上部にある[バケットを作成]を押下します。

ナビゲーションに従い、必要情報を入力し[作成]を押下します。下記は今回の入力・選択理由です。

名前 : 任意の名前を入力します。

ロケーションタイプ : 可用性は必要ないため、"Region"を選択します。

ストレージクラス : すぐにアクセスするため、"Standard"を選択します。

アクセス制御 : ACLでのアクセス管理は行わないため、"均一"を選択します。

バケットが作成されると自動的に作成したバケットに遷移します。

[ファイルをアップロード]を押下し、ダウンロード済みのVMDKファイルを選択します。

VMDKファイルがアップロードされたことを確認します。

2. Cloud Buildを利用して、VMDKファイルからイメージの作成

このフェーズでは、Cloud Buildを利用してGCEインスタンスのイメージ作成を行います。

ナビゲーションメニュー > [Compute Engine] - [イメージ]を選択します。

画面上部にある[イメージを作成]を押下すると、イメージ作成画面に遷移します。

必要情報を入力します。下記は今回の入力・選択理由です。

名前 : 任意の名前を入力します。

ソース : "仮想ディスク（VMDK、VHD）"を選択します。

Cloud Storageファイル : 参照からアップロードしたVMDKファイルを選択します。

仮想ディスクのオペレーティングシステム : 移行対象の仮想マシンのOSを選択します。

ゲストパッケージをインストールする : チェックを入れます。

[作成]を押下すると、 [Compute Engine] - [イメージ] > [イメージインポートの履歴]タブの画面に遷移します。

初めて実行する際には、、、

ソース : "仮想ディスク（VMDK、VHD）"を選択した際に、Cloud Build APIを有効化していないと以下の写真のポップアップが出てきます。

[Cloud Build APIを有効にする]を押下しAPIを有効化します。

Cloud Build APIを有効にすると、Cloud Buildサービスアカウントが自動的にプロジェクトに作成されます。

このCloud Buildサービスアカウントに以下のロールが必要なため、APIの有効化と同様に[付与]を押下しロールの付与を実施します。

・compute.admin（Conmpute 管理者）

・iam.serviceAccountUser（サービスアカウントユーザー）

API有効化とロール付与の確認

ポップアップが消えた時点でCloud Build APIの有効化とサービスアカウントにロール付与の実行は終了していますが、不安な方は以下の方法でそれぞれ確認してください。

　・Cloud Build APIが有効化されたか確認するには、以下のページにアクセスします。

　　ナビゲーションメニュー > [APIとサービス] - [ライブラリ] > "Cloud Build"と検索し、

　　検索結果の[Cloud Build API]を押下する。

　・Cloud Buildサービスアカウントにロールが付与されたか確認するには、以下のページにアクセスします。

　　ナビゲーションメニュー > [IAMと管理] - [IAM] > フィルタに"Cloud Build"を入力する。

少し本題からずれたため、説明を[イメージインポートの履歴]タブの画面に遷移した後に戻します。

画面遷移後、[Cloud Build ID]を押下すると、イメージインポートの詳細からCloud Buildのログを確認できます。

写真の[7a8fc911-5015-4c9c-a73d-487c5d08e79b]の部分を押下します。

もちろん、Cloud Buildの画面（ナビゲーションメニュー > [Cloud Build] - [履歴] ）からも、同等のログを確認できます。

[イメージインポートの履歴]タブの画面に戻り、緑アイコンに変わるとイメージが正常に作成された合図です。

念のためイメージが作成されたことを[イメージ]タブの画面に移動し確認します。

3. 作成したイメージからGCEインスタンスの作成

このフェーズでは、作成したイメージでインスタンスを作成します。

ナビゲーションメニュー > [Compute Engine] - [VMインスタンス]を選択します。

画面上部にある[インスタンスを作成]を押下し、必要情報を入力します。

設定項目が多いため重要部分のみ入力・選択理由を記載します。

左ペインが[新規VMインスタンス]になっていることを確認してください。

仮想マシン名には、任意の名前を入力します。

ブートディスクをカスタムイメージに変更するため、[変更]を押下します。

[カスタムイメージ]タブに移動し、[イメージ]のプルダウンから作成したイメージを選択します。

※作成したイメージがプルダウンに表示されない場合は、1つ上の[表示するイメージの取得元]を確認してください。

Apacheの動作確認を行うため、[ファイアウォール] - [HTTTPトラフィックを許可する]にチェックを入れます。

[ネットワーキング] > [ネットワークインターフェース]から、VPCやサブネットを変更できます。

Apacheの動作確認を行うため、外部IPを付与（[なし]以外を選択）します。

[作成]を押下し、 [Conmpute Engine] - [VMインスタンス] > [インスタンス]タブの画面に遷移します。

インスタンスが作成されるまで待ちます。

4. GCEインスタンスの動作確認

このフェーズでは、作成したインスタンスが起動すること、ミドルウェアが起動することを確認します。

インスタンスが起動すると、緑アイコンに変わります。

今回はTeraTermを使用して、外部IP宛てにSSHログインします。

※移行前にログインできていたユーザーとパスワードを使用します。

Apacheが無事動作していることをWebブラウザから確認できました。

仮想マシン（移行前）とGCEインスタンス（移行後）の変化

移行する前と移行した後で変化している部分をざっと確認しました。

rpmパッケージ

以下が移行後に追加されたrpmパッケージです。

移行後に削除されているrpmパッケージは確認できませんでした。

boost-regex-1.53.0-28.el7.x86_64

google-cloud-sdk-340.0.0-1.x86_64

google-compute-engine-20210204.00-g1.el7.noarch

google-compute-engine-oslogin-20210429.00-g1.el7.x86_64

google-guest-agent-20210223.01-g1.el7.x86_64

google-osconfig-agent-20210429.3-g1.el7.x86_64

gpg-pubkey-3e1ba8d5-558ab6a8

gpg-pubkey-836f4beb-5fc97e5e

nvme-cli-1.8.1-3.el7.x86_64

ユーザーとグループ

追加されているユーザーは確認できませんでしたが、以下のグループが追加されていました。

・/etc/group

google-sudoers:x:1000:

hostsファイル

下から2行分追加されています。コメントアウトは自動で記載してありました。

・/etc/hosts

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4

::1 localhost localhost.localdomain localhost6 localhost6.localdomain6

192.168.100.2 migration-test-01.c.certain-math-279406.internal migration-test-01 # Added by Google

169.254.169.254 metadata.google.internal # Added by Google

名前解決と時刻同期設定

DNSサーバーと検索ドメインは、どちらも書き換えられていました。

・/etc/resolv.conf

# Generated by NetworkManager

search c.certain-math-279406.internal google.internal

nameserver 169.254.169.254

時刻同期設定は/etc/chrony.confを確認しましたが、変更されていませんでした。

ネットワーク

ネットワークは、移行前と移行後のコマンドの出力結果を比較して確認します。

移行前

・ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo