こんにちは。KDDIアイレットMSPの岡本です。今回は、Google資格の記事となります！
この記事では、Google Cloud の資格取得に向けて学習される皆さんに、
こちらは公式に試験で対応するよとされているサービスの中から個人の主観により要注意なサービスとその概念をお伝えします。概念的な部分が参考になれば幸いです。

試験を受ける前に持つべきマインド

Google Data Engineer/Cloud Database Engineer では主に、データの取り扱いやデータベースの関わりを試します。
この試験に限らず、実業務のトラブルシューティングでもGoogle試験を受ける際にも以下のマインドをまずは持っておきましょう。

・〇〇できないと警告があるとき、まずは権限が必要十分かを確認する
・データが遅延している、送られていない、といった現象でかつインフラ原因か確認する際はまずはメトリクスをチェックする
・構成は必要最小限か？費用や手間のかかる構成は後々の工数発生になる恐れがある

Data Engineerとは？

正式名称：Professional Data Engineer
試験時間は2時間、問題数は50問、試験費用は税別で200ドルになります。
オンラインもしくはテストセンターでの受験が可能で、試験は日本語、英語のいずれかで受験可能です。
類似資格にAssociate Data Practitionerという試験が存在します。

試験時間 2時間
問題数 50問
試験費用 200ドル（税別）
有効期限 2年
公式ページ Follow the learning path
模擬問題（公式） 問題

Cloud Database Engineerとは？

正式名称：Professional Cloud Database Engineer
試験時間2時間、問題数は50問、試験費用は200ドル（税別）です。
オンラインもしくはテストセンターでの受験が可能で、試験は英語、日本語で受験可能です。
関連資格にMachine Learning Engineerが存在します。
こちらの紹介はまたいずれどこかで。受験予約はこちらから。

試験時間 2時間
問題数 50問
試験費用 200ドル
有効期限 2年
公式ページ Follow the learning path
模擬問題（公式） 問題

Professional Cloud Database Engineer/Professional Data Engineerの重要サービスは？

公式が出すと謳うサービスのうち、セレクトした重要サービスとその概念をいくつかご紹介します

データ処理・パイプライン系

── データ処理（ストリーミング / バッチ / オーケストレーション） ──
Google Cloudサービス AWS相当 Azure相当 Oracle Cloud相当 Google Cloudの特徴
Pub/Sub SNS と SQS / Kinesis Azure Service Bus / Event Hubs OCI Streaming（Kafka互換） ・グローバルデフォルト・フルマネージド
・メッセージ順序保証に追加設定必要
Dataflow AWS Glue / Kinesis Analytics Azure Data Factory / Stream Analytics OCI Data Flow / Oracle Data Integration ・ Batch/Streaming 統一モデル（Apache Beam）
・起動レイテンシが高め
Dataproc EMR HDInsight / Azure Databricks OCI Data Flow（managed Spark/Hadoop） ・ 既存 Spark/Hadoop をそのまま移行可
・クラスタ管理コストは Dataflow より高
Cloud Composer Amazon MWAA Azure Managed Airflow（プレビュー） Oracle Data Integration ※Airflow直接管理サービスなし ・フルマネージド Airflow
・料金が高め・起動まで時間がかかる

Pub/Sub

Pub/Subは、非同期のメッセージイベント取り込みサービスです。
AWSのSQSやSNSに近い能力があり、配信の順序を維持してイベントデータをストリーミングできます。
また、ストリーミング分析やデータベースとの橋渡し役（パイプライン）も担うことが可能です。
メリットは、多くのワークフローに並列で処理を依頼するとき、１対他通信を簡単にできるためワークを効率的に 分散します。
デメリットは、非同期通信なので100ミリ秒程度の遅延があるため、準リアルタイムであることです。
類似のApache Kafka と PulsaやApache ActiveMQ 、 RabbitMQと比較すると、Apache Kafka と Pulsarと同じくオートスケーリング機能があり、Apache ActiveMQ 、 RabbitMQのようにデッドレター キューやフィルタリングに対応します。

利用例としては、以下が挙がります。

・ログイベントをデータベースに集約
・システムイベントをデータベースに集約
・ユーザーイベントをデータベースに集約
・ インタラクション イベントをデータベースに集約
・複数のタスクをワーカーへの負荷が偏らないように負荷分散し並列処理を支援

Dataflow

AWS的に置き換えるなら一番近いのはAWS Glue、Amazon Managed Service for Apache FlinkにあたるサービスがDataflow。個人的にはGlueに近いニュアンスの意識があります。
いわゆる、データをストリーミングしながらリアルタイムに変換（バッチ処理）を行うツールです。
Google Cloud 上での、Apache Beam 実行環境を提供しております。
Apache Beamとはバッチ処理とストリーミング処理を得意とするオープンソースで、処理を実行する場所をRunnerで宛先指定ができます。
Apache Beam のコンセプトが「Write once, run anywhere」（一度書けばどこででも）ということから、OS依存がありません。ETL変換やストリーミング処理的でデータベースとやり取りするだけでなく、Vertex AIでの利用も可能です。
サーバーレスで、オートスケーリングにも対応しています。
気になるお値段はこちらが最新になります！

Dataproc

Dataprocは、マネージドなHadoop/Spark環境です。AWSで一番近いのはAmazon EMRです。バッチETL処理が主な用途ですが、Apache FlinkやSpark Streamingも動作するため、準リアルタイムなストリーミング処理にも対応できます。既存のHadoop処理をそのまま移行したい場合にも利用できます。

Managed Service for Apache Airflow（Cloud Composer）

引用：Cloud Composer 環境のアーキテクチャ 

複数ジョブで依存関係のある定期バッチを整理するツールがManaged Service for Apache Airflow（Cloud Composer）になります。
マネージドで依存関係を指定されたバケットにDAGファイル（py記述）を追加するだけで依存関係を理解し、バッチを実施するように指揮してくれます。また、Airflow Worker(s)は、キューから仕事を受け取り、タスクを実際に実行する実行者の役割を果たします。node_countの設定を調整することでAirflow Workerを増減できます。

メリット デメリット
マネージドかつクラウド、オンプレミス両方のジョブを管理できる 複雑なジョブでなければ過剰構成
管理、モニタリングが簡単 環境自体を管理する工数が発生
オープンソース

 ストレージ・データウェアハウス系

── データストレージ（DWH / RDBMS / NoSQL） ──
Google Cloudサービス AWS相当 Azure相当 Oracle Cloud相当 Google Cloudの特徴
BigQuery Athena Azure Synapse Analytics Oracle Autonomous Data Warehouse (ADW) ・ サーバーレス・列指向で爆速スキャン
・高頻度小クエリはコスト高
Cloud SQL RDS Azure DB for MySQL / PG / SQL Server Oracle MySQL HeatWave / Autonomous Database ・ 標準的マネージド DB
・グローバル分散不可（→ Spanner 検討）
Cloud Spanner Aurora Cosmos DB（強整合）/ SQL Hyperscale Oracle Autonomous Database（Globally Distributed） ・唯一の外部整合グローバル RDBMS
・料金高め・SQL に制限あり
AlloyDB Aurora PostgreSQL Azure DB for PG Flexible Server Oracle MySQL HeatWave ・PG 互換で OLTP/OLAP 混在・AI Column Engine
・Cloud SQL等の老舗サービスと比較し、運用ノウハウの蓄積が発展途上
Memorystore ElastiCache Azure Cache for Redis OCI Cache（Redis互換） ・フルマネージド Redis / Valkey
・標準Redisとの互換性が高く、独自拡張を抑えたシンプルな仕様
Bigtable DynamoDB / Cassandra on EC2 Cosmos DB（Cassandra API） Oracle NoSQL Database Cloud ・超大規模時系列・IoT に最適
・小規模では割高・スキャン非効率
Firestore DynamoDB / DocumentDB Cosmos DB（Core API） Oracle NoSQL Database Cloud（JSON doc対応） ・リアルタイムリスナー・モバイル統合
・複雑クエリ・集計は苦手

BigQuery

BigQueryは、AWSでいうところのAthenaに近い機能があります。
サーバーレスでクラスタ管理が不要な点やスキャン量で課金が決まる点です。
ただし、データを内部管理できるところはBigQueryならではでしょう。BigQueryはさらに、BigQuery AI を使用してデータを AIにシームレス接続し予測推論にも活用できます。
また、Knowledge Catalog （Dataplex）も併用することで、データがどこから来てどう加工されたか追跡が可能になります。また、他のデータベースからデータを移動させずクエリするfederated queryにも対応しております。

Cloud SQL

Cloud SQLは、標準リレーショナルデータベースです。使えるSQLタイプは、PostgreSQL、MySQL、SQL Server。
可用性99.99%を誇ります。バックアップ、レプリケーション、パッチ適用、暗号化、ストレージ容量の追加をすべて自動化する部分が特徴となります。これはインスタンスにデータベースを構築することに比べて運用工数が０に近い点がメリットです。また、オンプレミスやクラウドのインスタンス上DBから移行し利用することも可能です。

利用のメリット・デメリット

メリット デメリット
運用工数が自前サーバに比べ小さい リージョン障害の際のフェイルオーバー構成としては機能しない。（グローバル分散はしない）
高速トランザクションには向かない

Cloud Spanner

Cloud Spannerはフルマネージドリレーショナルデータベースです。
特徴はなんと言っても３つのゾーンにかけてインスタンスをホストすること。強整合性と高可用性とスケーラビリティを提供します。

利用のメリット・デメリット

メリット デメリット
最大 99.999% の可用性 単一リージョンなら過剰構成
リレーショナルデータベースでスケーラビリティあり

AlloyDB

AlloyDBは、PostgreSQLとの互換性100%のデータベースです。標準的なPostgreSQLに対応できるデータベースの場合、ストレージ部分はデータベースインスタンスに紐づいています。AlloyDBの場合は、データベースインスタンス部分とストレージ部分を分けて構成しているため、それぞれのスケーリングが可能です。ストレージ部分がデータベース部分と分離していることで、スケールアウトやインの際、ストレージ部分をプロビジョニング・プロビジョニング解除を行う必要がありません。
つまり、一般的な PostgreSQL のセットアップのスケーリングで必要となる一度拡張すると縮小が難しいというリスクがありません。また、高度なI/O管理とキャッシュ機能のおかげで、高速なトランザクション クエリが可能です。耐障害性に関してもマルチAZ対応、バックアップやレプリケーションの自動化と手厚めです。
利用のメリット・デメリット

メリット デメリット
PostgreSQLとの互換性100%であること ミリ秒単位など時間制約や強整合を必要としない場合過剰
データベースサーバ部分とストレージ部分を分けての拡張可能

また、主な機能としてデータベースの使用パターンに基づいてデータスキーマを最適化するインデックス アドバイザーやワークロードの形に則してバキューム関連のパラメータを自動調整する機能があります。
AlloyDBはプライマリインスタンスと読み取りプール インスタンスの２種類があり、プライマリインスタンスのノードをアクティブ・パッシブで構成することで可用性を高めます。読み取りプール インスタンスは、リードレプリカと同じ概念で読み取り専用のインスタンスを作成することでプライマリインスタンスへの読み取り負荷を下げる狙いがあります。
AlloyDB の概要

Bigtable

BigtableはNoSQLデータベースで、リアルタイムで大量データを収集・集約管理することに優れたサービスです。AWSでいうとAmazon DynamoDBやApache Cassandra（マネージド構成）に近い位置付けです。NoSQL型ですがBigtableの真骨頂は超大規模データの集約管理にあり、その点でRedshiftに近い用途感があります。
特徴は、ダウンタイムなしでクラスタをオートスケーリングできること。データ構造はKey-Value型（ワイドカラム）です。実務で気にするべきはホットスポットを発生させないようにする工夫でしょうか。複数ノードへの書き込み分散が可能ですが、キーが偏ると一部ノードに過集中が起きスケーリングが無意味になります。書き込みキーをユニークにすることが肝要です。BigQueryやDataflowとの連携もシームレスです。
利用のメリット・デメリット

メリット デメリット
リアルタイムで大量データを収集分析 ホットスポット対策が必要
オートスケーリング可能

Firestore

スマホアプリなどと相性のいいデータ管理といえば、Firestore。
肝となるのはNativeモードとDatastoreモードです。
ざっくり説明するとNativeモードはフロント側で利用するのに向いた高速で強整合性なデータベースです。
リアルタイム同期の強整合を持つデータベースでオフラインにも対応していることからアプリ系と相性がいいのが特徴です。
DatastoreモードはNativeモードでは制限されていたトランザクションなどの制限がなくスケール向けなのが特徴です。最新の内容は公式情報のこちらからご確認ください。

ガバナンス・セキュリティ・移行系

── ガバナンス・変換・移行 ──
Google Cloudサービス AWS相当 Azure相当 Oracle Cloud相当 Google Cloudの特徴
Dataform Glue DataBrew  Fabric Dataflows Oracle SQL Developer Web / Data Transforms ・ BQ 直結・GitOps 対応
・BQ 専用（他 DB に使えない）
Dataplex Amazon DataZone/ Glue Catalog Microsoft Purview Oracle Data Catalog / Enterprise Metadata Management ・データメッシュ・自動品質チェック
・設定の複雑さ・学習コスト高
DMS AWS DMS Azure Database Migration Service Oracle GoldenGate / Zero Downtime Migration (ZDM) ・異種 DB 間スキーマ変換も対応
・複雑な移行は Datastream と組み合わせ必要
KMS AWS KMS Azure Key Vault Oracle Vault（OCI Vault） ・CMEK 対応・HSM あり（Cloud HSM）
・鍵のインポート制限あり

DMS

オンプレミスからデータベースをクラウドに移行するとなった時、気になるのはダウンタイムです。
ダウンタイムを最小限に抑えるサービスが「Database Migration Service」（DMS）です。
DMSの特徴はなんといってもGoogleのSQL対応しているマネージドサービスへの移行がダウンタイム最小でできること。OracleのデータベースをCloud SQLに載せ替える場合、ストアドプロシージャなど一部を変えなくてはいけませんが、変換をスムーズに行ってくれる特徴があります。

Cloud KMS


データを安全に保管するには、暗号化というのはAWSだけでなくGoogleでも鉄板ネタです。
Cloud KMSは、クラウド上の暗号化キーの作成、破壊、更新を一元管理します。
GoogleではCloud KMSに含まれるものに以下があります。
CMEKはいわゆる顧客作成のGoogle管理しているキー。カスタマーキーになります。
Cloud HSMは暗号化キーを作ったり、管理する入れ物のこと。ハードウェアセキュリティモジュールのサービスと一般的には称されます。
暗号化キーはストレージやデータベースの暗号化といった、機密性を高めるために利用され、ストレージの暗号化にはGoogle管理の暗号化キー（デフォルトの保存データの暗号化）が用いられます。
特に、Cloud EKMは、保護レベルは高いですがGoogleで暗号化キーを管理しないためキーローテーションの際注意が必要です。具体的には、以前の鍵バージョンで保護されたデータは再暗号化されません。

利用のメリット・デメリット

メリット デメリット
データの暗号化の担保 暗号キーをどのように設定するかによってコストと管理工数が発生する

鍵のローテーション

Dataform

DataformはBigQuery専用パイプライン管理とTransformツールです。
従来、BigQueryではSQLも組み合わせてデータ変換する場合ネイティブなツールはなく、クエリを独自に定義し管理が必要でした。
BigQueryはデータの追跡やクエリは得意ですが、今までどこを変更したかを確認して変更していないところから新たにクエリする、依存関係を気にした上でクエリを行うといった、変更履歴や依存関係は苦手です。
Dataformは、どの順序でクエリするのか、どこからクエリするのかと言った指示（ワークフローコード）をSQLにリアルタイムで変換しBigQueryへ渡すことができます。
メリットは効率的なデータ変換とパイプライン管理で開発スピードアップが狙えることです。また、Dataformそのものの利用料金も無料である点も魅力的です。
デメリットは、Google独自で依存的であること（ベンダーロックイン）でしょうか。

メリット デメリット
効率的なデータ変換とパイプライン管理で開発スピードアップが狙える ベンダーロックイン

参考：コンパイルを構成する

Dataplex

データカタログが用語として一番近いでしょうか。現在は、Knowledge Catalogに名称が変更されてしまいました。役目としては、いろいろなデータベースなどに格納されたメタデータをカタログ化します。
さらに、どこをどう変更したのか（リネージ検出、プロファイリング、追跡）とビジネス用語集の役割も果たします。
AWSでは、Amazon DataZoneが類似サービスとして挙がります。
使用のメリットは、組織全体のデータがどこに何があり誰が変更したか一元管理しやすいことです。
デメリットは、利用コストやGoogle独自で依存的であること（ベンダーロックイン）でしょうか。

終わりに

いかがだったでしょうか？考え方のコツが掴めていたら幸いです。
なお、AWSやGoogle試験を受けつつ監視業務を行う実生活で共通した思いとしては以下の印象があります。

・まずはどのリソースが問題か特定するためモニタリングした様子をチェック
・〇〇できない時はまず権限がついているかをチェック。AWSもGoogleも最小権限を意識しているぞ
・データやリソースや権限はまとめて管理できるように整理し構成すべし。どこに何があるかとっちらかりにくいぞ
・変更する時はちょっとずつ本番お試しできること。元の体制に巻き戻せる設定はCI/CDやMLどっちでも重要だ。

最後に、弊社KDDIアイレットでは、cloudpackというサービスでGoogle Cloud やAWS、OCI の移行、構築、設計、運用、請求代行などをサポートしております！最近リリースしたgaipackもお見逃しなく♪