Google Cloud の Cloud SQL/Spanner/Dataproc の基礎

## 要約
本記事では、Google Cloud の主なデータベースサービスとそれぞれの基礎知識、ベストプラクティスをまとめます。

---

## 目次
- [Cloud SQL](#cloud-sql)
  - [高可用性と耐障害性の違い](#高可用性と耐障害性の違い)
  - [プライマリインスタンスとスタンバイインスタンス](#プライマリインスタンスとスタンバイインスタンス)
  - [フェイルオーバー](#フェイルオーバー)
  - [注意点](#注意点)
  - [リードレプリカ](#リードレプリカ)
  - [バックアップ](#バックアップ)
  - [トランザクションログ](#トランザクションログ)
  - [スナップショットとポイントインタイムリカバリの違い](#スナップショットとポイントインタイムリカバリの違い)
  - [Cloud SQL Auth Proxy](#cloud-sql-auth-proxy)
  - [Query Insights](#query-insights)
  - [予算超過の理由](#予算超過の理由)
- [Cloud Spanner](#cloud-spanner)
  - [インターリーブ](#インターリーブ)
- [Dataproc](#dataproc)
  - [YARN](#yarn)
  - [GCSではなくHDFSを使う場合](#gcsではなくhdfsを使う場合)
  - [最適化のために](#最適化のために)
  - [ベストプラクティス](#ベストプラクティス)
  - [コンピューティング](#コンピューティング)
  - [正規化と非正規化](#正規化と非正規化)
  - [サイロ化](#サイロ化)

---

## Cloud SQL

### 高可用性と耐障害性の違い

|                | 耐障害性                             | 高可用性                                 |
|----------------|----------------------------------|---------------------------------------|
| 環境             | サービス中断は発生しないが、コストが高い   | 最小限のサービス中断が発生する                    |
| テクノロジー       | 特殊ハードウェアを使用してハードウェア障害を検出し、予備のハードウェアに切り替える | ソフトウェアと業界標準のハードウェアを組み合わせる |
| ダウンタイム対策   | ハードウェア障害に対応できるが、ソフトウェア障害に対応できない | 障害発生時に必須のサービスを迅速に復元する              |
| ダウンタイムの長さ | 長時間のダウンタイムを許容するが、サービスは提供され続ける     | 短時間のダウンタイムを許容し、素早く復元する               |
| コスト            | 非常に高い                             | 一部の中断を許容しながらコストを抑える                 |
| 応用範囲          | タイム・クリティカルでないアプリケーション                | タイム・クリティカルなアプリケーション                   |

出典: [IBM: 高可用性と耐障害性の違い](https://www.ibm.com/docs/ja/powerha-aix/7.2?topic=aix-high-availability-versus-fault-tolerance)

### プライマリインスタンスとスタンバイインスタンス

プライマリインスタンスに障害が発生した際にスタンバイインスタンスにフェイルオーバーさせる仕組みを「高可用性構成」といいます。

### フェイルオーバー

Cloud SQL インスタンスが存在する zone またはインスタンス自体が利用できなくなった際に、同じ region の別 zone に存在する Cloud SQL インスタンスに対してトラフィックを流すように切り換えます。

### 注意点

HA 構成を有効化するとインスタンスが 2 台稼働するため、インスタンスの CPU ・メモリ・ストレージ料金が 2 倍かかります。

### リードレプリカ

リードレプリカは Cloud SQL インスタンスのコピーであり、読み取りリクエストを負荷分散する目的で利用します。プライマリインスタンスのデータが更新されると、ニアリアルタイムで非同期レプリケーションされます。

#### 非同期レプリケーション
- 最初のサーバーのディスク上にあるコミット済みのデータが障害発生時に失われる可能性があります。

#### 同期レプリケーション
- 最初のサーバーのディスク上にあるコミット済みのデータがすべて 2 番目のサーバーのディスク上にもあります。

以下の図解が目的の違いを分かりやすく示しています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/431477/f4b17d3c-d818-a79e-5184-9867fda089b3.png)

### バックアップ
- オンデマンドバックアップと自動バックアップがあります。

### トランザクションログ
- トランザクションログを用いてポイントインタイムリカバリが可能です。

### スナップショットとポイントインタイムリカバリの違い
- **スナップショットの復元**: 特定のスナップショット時点のサーバーを起動。
- **ポイントインタイムリカバリ (PITR)**: 任意の時点のサーバーを別インスタンスとして作成。
  - 元のインスタンスを巻き戻すのではなく、別インスタンスとして作成されます。
  - SQL Server では利用不可です。

### Cloud SQL Auth Proxy
- SSL/TLS 通信を自動的に暗号化
- Public IP でも承認済みネットワークの追加不要 (IAM で接続元を承認)
- IAM データベース認証が可能 (PostgreSQL のみ)

### Query Insights
- DB のクエリパフォーマンスを確認できる (PostgreSQL のみ対応)
- 有効化すると 7 日分の情報が保存

確認できること:
- DB 全体の負荷状況
- クエリごとの負荷状況
- 高負荷クエリの実行計画・所要時間

### 予算超過の理由
- 過剰にプロビジョニングされたリソース
- アイドル状態のリソース
- 確約利用割引
  - 1年または3年間の継続利用により大幅な割引料金が適用

[コスト最適化の公式ブログ](https://cloud.google.com/blog/ja/products/databases/reduce-cloud-sql-costs-with-optimizations-by-active-assist)

---

## Cloud Spanner

### インターリーブ

Cloud Spanner では、下記のように親子関係を持つテーブル (インターリーブ) を作成可能です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/431477/374751eb-9b55-b02b-f03b-07b7e449d4ac.png)

---

## Dataproc

### YARN

YARN（Yet Another Resource Negotiator）は、Apache Hadoop のリソース管理フレームワークです。Dataproc は YARN を使用し、複数のワークロードを効率的に管理します。

### GCSではなくHDFSを使う場合
- メタデータ更新が頻繁
- ファイルサイズが小さい
- ディレクトリのリネーム操作が多い
- append 操作が多い
- 数ミリsecのレイテンシも許容できない

ただし、永続化には GCS を推奨します。中間データなどにのみ HDFS を利用すると良いです。

### 最適化のために
- Hadoop/Spark 実行はスタンドアロンスクリプト化し、クラスタ外部からジョブとして実行
- 永続化は GCS を利用し、コンピューティングとストレージを分離
- クラスタリソースは破棄可能にし、プリエンプティブル VM や自動スケーリングを活用

### ベストプラクティス
- [Dataproc ベストプラクティス](https://cloud.google.com/blog/ja/topics/developers-practitioners/dataproc-best-practices-guide)
- [自動スケーリング設定](https://cloud.google.com/dataproc/docs/concepts/configuring-clusters/autoscaling?hl=ja)
- クラスタプールやラベルの活用

### コンピューティング
#### プリエンプティブル VM（PVM）
- セカンダリ ワーカーのみに PVM を使用 (最大 30% 未満)
- アプリケーションマスターは PVM でないワーカーのみで起動

### 正規化と非正規化
- 正規化: データの冗長性を抑え、一貫性を保持

### サイロ化
- 部門ごとの孤立により、情報連携が進まない状況