Google Cloud書き散らし

Google Cloudについて勉強する中で得た知見をアウトプットも兼ねて書き散らしていきます。
覗いてもいいですがまだまだ勉強中のため中身の正確性は保証しません。

VPCネットワークとVMインスタンスについて
VPC(Virtual Private Cloud)ネットワークとはプライベートクラウドとしてクラウドのリソースやサービスを単一の組織用として構築できるテナント環境のこと
Google CloudのVPCネットワークには「default」という名前のネットワークが標準で用意されている
defaultネットワークにはサブネット、ルート、ファイアウォールルールが標準で用意されている
VMインスタンスの作成にはVPCネットワークが必要で、VPCネットワークが無い状態だと作成することができない
標準で用意されているファイアウォールルールについて
ファイアウォールルール「~~icmp」では同じVPCネットワーク内のVMインスタンスに対して外部IPでのicmp接続を許可している（icmpはpingで使用するプロトコル）
ファイアウォールルール「~~custom」では同じVPCネットワーク内のVMインスタンスに対して内部IPでのicmp接続を許可している
ファイアウォールルール「~~ssh」では同じVPCネットワーク内のVMインスタンスに対してSSH接続を許可している

sasami

 Cloud Storagehttps://cloud.google.com/storage/docs/introduction?hl=ja
概要

様々なデータ、ファイルをオブジェクトとして管理するためのストレージサービス。

最大の特徴はすべてのファイル１つ１つへのアクセスをURLで行えることで、これによりWebテクノロジーとの親和性が高いこと。（BLOBの保存に使用されることが多い。）
バケットについて

Cloud Storageのすべてのデータは「バケット」と呼ばれるものの中に格納され、バケットはグローバルで一意になるように名前を付け、どのロケーションに保存されるかを指定する。保存先ロケーションはレイテンシが最小になるように使用先を考えて指定するのがおすすめ。

バケットはフォルダ、ディレクトリとは異なり、入れ子にすることはできない。

既存バケットは名前変更ができない。変更したいときは別途新しいバケットを作成して中身のファイルを移動させる必要がある。
バージョニング

バケットの「バージョニング」を有効にすることで特定のオブジェクトに加えた変更が追跡可能になる。バージョニングが有効になっていると過去バージョンの一覧が見れたり、古いバージョンの復元ができるので基本は有効にしておくのがよさそう。
セキュリティ

格納するオブジェクトには機密情報、個人情報が含まれる場合もあるはずなので適切に権限を設定することが重要。IAMロールが適用できるほか、アクセス制御リスト（ACL）が使用でき各ユーザに最適な権限を付与できる。
お金

ストレージなので保存している間もお金がかかる。月に１GB単位でロケーションによって発生する料金が変わってくる。保存にかかる料金削減としてはオブジェクトのライフサイクルポリシーを使用することが推奨されている。何日で削除するかってやつ。

また、オブジェクトへのデータの読み書きにも料金が発生し、すべてのリクエスト、特定のストレージクラスへのアクセス、マルチリージョンでの保存のためのレプリケーション、AutoClassってやつ、に対して料金が発生するとのこと。
ストレージクラス

保存するオブジェクトのアクセス頻度によって料金が変わるストレージの種類がある。

いかがその種類。カッコ内が目安のアクセス頻度。
Standard Storage（頻繁）
Nearline Storage（月１）
Coldline Storage（四半期）
Archive Storage（年）

これはあくまでアクセス頻度による違いであって、無制限ストレージであることやアクセス元のロケーションは問わないこと、ローレイテンシ、高耐久性、ツールやAPIなどの使い勝手はすべて同じとなっている。

また、AutoClassという機能を有効化するとオブジェクトごとのアクセス頻度によって適切なクラスに自動的にオブジェクトを移行してくれるようになる。
アクセス方法

CLIかGLIでアクセスできる。CLIの場合はgcloud storageコマンドで操作でき、GLIの場合はブラウザでドラッグ&ドロップでデータを保存できる。

何TBとかあるバカデカオブジェクトはStorage Transfer Serviceというのでコスパよく転送できるのでこれがおすすめ。ほかのクラウドからも転送や、バッチ転送にもにも対応しているとのことなので何かと便利。

Transfer Applianceというのもあって、簡単に言うとGoogle Cloud用デカSSDを受け取ってデータぶち込んでGoogleに返すとCloud Storageに挙げてくれるサービス。ネット経由だと時間がかかりすぎる場合のデータ移行とかにつかうっぽい。

データ移行に絞っていうと、BigQueryやCloud SQLと連携してインポート/エクスポートができたり各Google Cloudサービスのログ保管やバックアップにも使用できたりする。

sasami

 Cloud SQLhttps://cloud.google.com/sql/docs/introduction?hl=ja
概要

MySQL、PostgreSQL、 SQL ServerなどのRDBの フルマネージドサービス。

つまり、いろんな種類のRDBを管理系（バージョンアップとかバックアップとか）をGoogle Cloudでやってくれる上で使えるサービス。
スケーリング

最大プロセッサコア128個、 RAM 864GB、ストレージ64TBにスケーリング可能
バックアップ

バックアップ7回分が標準で料金に含まれている
暗号化

テーブルにデータがあるとき、一時ファイルにあるとき、バックアップにある時に暗号化されて保存される。
Auth Proxy

許可されたIPアドレスやSSLを構成しなくても安全にCloud SQLにアクセスできる仕組み

ローカルクライアントを使用してローカル環境から接続する

sasami

 Spannerhttps://cloud.google.com/spanner/docs?hl=ja
概要

KVSをルーツとするRDBMSを備えたフルマネージドデータベースシステム。

主にスケーラビリティ（拡張性）に優れており小規模から始めて、徐々に大きくしていく（大きくなっていくかもしれない）場合に選択されるデータベースサービス。

もともとKVSのデータベースから始まったサービスだったこともあり、リレーションもなくSQLではなくミューテーションAPIでのアクセスだけだったのが、今では普通にRDBとして使用することもできるようになっており、SQLでのデータ操作など一般的なRDBに備わっている機能は大体使える。
余談

あまり解説にでてこず知られていないっぽい？が、「１秒あたり多数の入出力オペレーションを必要とするもの」もSpannerを選定する理由の一つになるそうな。

ということはマスタテーブルよりもトランザクションテーブルでの活用が向いているということかなぁ

sasami

 FireStorehttps://cloud.google.com/firestore/native/docs/overview?hl=ja
概要

NoSQLのサーバーレスデータベースでクライアントサイドからの接続可能なサービス。

オフラインでも使用可能とのこと。
ドキュメント指向データモデル

特徴的なのはこのモデル。RDBのテーブル、行、カラムとは違って、ドキュメントという単位にKV方式でデータが蓄積される。そのドキュメントを束ねるのがコレクションという概念でコレクションはドキュメントに含めて入れ子にすることが出来る。
データ同期

同じデータベースに接続しているほかのクライアントとデータの同期が可能。オフラインでも使用可能なのはこのため。オフラインの間でもクエリが実行でき、オンラインに戻った時に同期されてデータベースに反映されるそうな。

sasami

 Bigtablehttps://cloud.google.com/bigtable/docs/overview?hl=ja
概要

NoSQLで使用可能なビッグデータデータベースサービス。

GmailやGoogleマップなどのGoogleのいろんなサービスで実際に使用されているらしい。

主にデータ分析などの場面で使用されているようで、大量なデータがリアルタイムに移動する、変化することが多いプロダクトの場合に選定されるとのこと。
列指向性データベース（カラムナデータベース）

列からの高速な読み込みに特化するため、相互に関連する列は列ファミリーとしてグループ化したり、行と列の交差部分には複数のデータを格納することが出来るようにしている。

sasami

 Kubernetes(GKE)https://cloud.google.com/kubernetes-engine/docs/concepts/kubernetes-engine-overview?hl=ja
概要

コンテナ化されたワークロードとサービスを 管理するオープンソースプラットフォーム。

もともとGoogleが開発したシステムで、現在はオープンソース化しGoogle CloudではGoogle Kubernetes Engine（GKE）として提供されている。

Dockerみたいなもの。
構成

ポッド（Pod）と呼ばれるコンテナの集合が作成、デプロイ可能な最小単位になる。

それを使ってコンテナをノード（node）と呼ばれる演算インスタンスつまりマシンにデプロイし使用します。ノードは複数作成でき、ノードを束ねるのがクラスタ（Cluster）になる。
接続

KubernetesはPodが作成されると固定IPアドレスを持つServiceを作成し、コントローラがクラスタ外からアクセスできるようにこのServiceにパブリックIPアドレスを持つ外部ロードバランサを追加する。

このIPアドレスに到達したクライアントはすべてServiceの背後にあるPodにルーティングされる仕組みになっている。
スケーリング

kubectl scaleコマンドで自動スケーリングを使用することが出来る。

たとえばCPU使用率がしきい値に達するとPod数を増やすように指定したりとか。
宣言的（Declarative）API

適時コマンドを実行してシステムの状態を変更していくのを命令的（Imperative）というのに対し、Kubernetesは宣言的（Declarative）な機能がある。

構成ファイルに記載した構成をAPIで登録してデプロイされてハイ終わりではなく、Controller（Reconciliation Loop）という機能が常に監視（Observe）しており何か問題があってノードがクラッシュした！（Diff）なんてときは構成ファイルに記載されている構成に自動的に戻してくれる機能（Act）がある。

そういった障害対策だけでなく、アプリの更新なんかの時も命令的にコマンドで更新するのではなく、構成ファイルを更新、反映することでそれに従ってKubernetes自身が１つずつ安全に更新をかけていってくれるという使い方もできる。
GKE

GKEではKubernetesのノード１つひとつがCompute Engineインスタンスとして稼働する。

さらにそれを束ねるクラスタをGoogleCloud側で管理してくれるので楽ちんだとのこと。

そのうえでノード内の細かいところまで見てほしい場合は Autopilotモード、細かいところはユーザが管理したいならStandardモードにしておくとよい。

sasami

 Cloud Runhttps://cloud.google.com/run/docs/overview/what-is-cloud-run?hl=ja
概要

コンテナとしてビルドできるようにしたアプリをGoogleCloud上で動作させることのできるサービス。

ユーザはアプリだけ作ればよいのでそれを乗っけるサーバのことは全部Googleにおまかせできる。Pub/Subイベント経由でもトリガーできる。

しかしアプリのトリガーが対応しているものに限られるなど多少の制限はあり。

実際に使用した分にだけ課金されるのでアイドル状態ならお金かからない。

（でもビルドしたコンテナイメージが保存されていると課金される場合があるらしい。なぜ。）
デプロイ

コンテナベースのワークフローでもコードベースでも可能。

コードからコンテナイメージをできる状態になっていればCloudRunのほうでビルドしてデプロイしてくれる。しかも言語には制限がないみたい。

sasami

 Alloy DBhttps://cloud.google.com/alloydb/docs/overview?hl=ja
概要

GoogleCloud基盤を活用した100% PostgreSQL 互換データベース
Spanner並みのスケーリングが可能なPostgreデータベース

SpannerやBigtableと同じように、データベースのコンピューティングとストレージを分離することで高いスケーラビリティを実現し読み取りと書き込みの両方で高いパフォーマンスを維持しながらデータベースを拡張できる
Auth Proxy

Cloud SQLと同じように専用プロキシがあり安全に接続できる

sasami

 BigQueryhttps://cloud.google.com/bigquery/docs/introduction?hl=ja
概要

さまざまなデータ分析のためのデータの保存、管理から分析までを一手に担うフルマネージドAI対応プラットフォーム

データは構造データも非構造データもどちらも使用でき、地理空間分析やML：機械学習にも対応する

sasami

 MemoryStorehttps://cloud.google.com/memorystore/docs/redis/memorystore-for-redis-overview?hl=ja
概要

Redis、Memcachedに対応したフルマネージドのインメモリデータベース。

VPCネットワークとプライベートIPを使用し、インターネットから保護されているだけでなくデータ保護のためIAM認証と統合されている。

またCloudMonitoringでインスタンスをモニタリングでき、アラートを上げることができる。

sasami

 IAM認証https://cloud.google.com/iam/docs/overview?hl=ja
概要

だれがどのリソースに対してどのようなアクセス権トロールを持つかを定義してGoogleCloudの様々な製品のアクセス制御をおこなうことが出来る機能
プリンシパル

「だれが」に該当する用語。

タイプとして、
Googleアカウント

開発者、管理者、運営者などのGoogleCloudとやり取りするその他のユーザーを指す
サービスアカウント

アプリケーションやコンピューティングワークロード用のアカウントを指す

複数のアプリケーションなどをまとめたコンポーネントを表すためにも使用できる
Google グループ

Googleアカウントとサービスアカウントを複数まとめて定義できるハコ

グループに関連付けられた固有のメールアドレスがある

複数のアカウントにまとめて権限を付与するのに使用する

ログイン認証情報を持たずIDが確立していない（これでログインして作業とかするものではないということかな）
Google Workspace アカウント

Googleアカウント用の仮想グループ。用途はGoogleグループと同じだがこちらはGoogle Workspace上のアプリケーションと連携が取れたりする？
Cloud Identify domain

こちらもGoogleアカウント用かそうグループ。こっちはGoogle WorkSpaceへのアクセスはできない。用途はGoogleグループと同じ。
対象のリソース

Google Cloudプロジェクト、Compute Engineインスタンス、Cloud Storageバケット、Artifact Registryリポジトリなどがある
権限による許可される操作

何のリソースにどういう権限が割り当てられているかを表すときには、

[サービス].[リソース].[動詞]の形で表される。

<例>pubsub.subscriptions.consume, storage.objects.list, compute.disktypes.list
ロール

権限の集合。ユーザにロールを付与するとそのロールに含まれるすべての権限が付与される。

Googleアカウント個別に付与することもできるし、Googleグループなどに対してまとめて複数ユーザにロールを付与することもできる。

ロールにはタイプが３つある。
基本ロール（Basic）
事前定義されたロール
カスタムロール

基本ロールには「閲覧者」「編集者」「管理者」くらいのざっくりとしたロールが用意されている。

ざっくりすぎるので基本ロールは原則本番環境では使用しないことが推奨されている。

事前定義されたロールにはGoogle側で設定した特定のリソースへの細かいアクセスが定義されたロールが用意されている。特殊な権限が必要にならない限りはこちらで済ませる。

カスタムロールはユーザによって定義されるもので、前述の2つにはない権限が必要な場合にさくせいするもの。たとえば、事前定義されたロールがちょっと厳しすぎるなーとかのときにやや広げた権限をカスタムロールとして作成する。

sasami

サービスアカウントはユーザが直接認証に関与しないようにOAuth トークンなどを設定してアプリケーションがAPIを呼び出すために使用したりする

sasami

サービスアカウントは、RSA 秘密キーと公開キーのペアを使用して認証する。
秘密鍵はJSON形式でダウンロードできるが＝パスワードになるので取扱には注意。

sasami

ダウンロードできる秘密鍵は原則仕様せずほかの方法で認証することが推奨されている。
ダウンロードした鍵を悪意あるユーザに使用されることで情報漏洩のリスク、悪意あるユーザの権限昇格のリスク、悪意あるユーザの身元詐称のリスクなどがある。

sasami

Google Cloud API認証

アプリの実行場所の違い
- GoogleCloud上でアプリが動作しているorする予定の場合
  ローカルでの開発（GoogleCloud予定）はgcloud auth application-default loginコマンドでアプリがユーザ認証を使用できるようにする。
  すでにGoogleCloud上で動いていればComputeインスタンスなどに直接サービスアカウントを紐づける。
  Google Kubernetes Engine上でアプリが動いている場合は、Workload Identityを使用する。
  GKEクラスタ内のワークロードがIAM認証のサービスアカウントになりすまして（いいのか）認証する。
- ほかのクラウドやオンプレミスサービスの場合
  そもそもGoogleCloudですらないところで動いているor動くことを予定している場合はフェデレーション（Workload Identity Federation）という機能が使えるかどうかを確認する。
  ほかのクラウドや、オンプレミスのサービスで何かしらIDトークンが発行できるようになっていればGoogleCloudのアクセストークンと交換できる。
  交換したアクセストークンでサービスアカウントを必要とせずに権限とかを偽装できる（言い方）。
  フェデレーション機能が使用できない場合はGoogleCloud上でサービスアカウントから秘密鍵をDLしてきて厳重保管しながら使用する。
ADC（Application Default Credentials）
GoogleCloud上の様々なリソースにアクセスするためにGoogleCloudの認証ライブラリが使用する資格情報の検索手法のこと。
ローカルでもCloudに乗せてからでも同じコードで動作する。
1. GOOGLE_APPLICATION_CREDENTIALS環境変数が設定されていればその値に設定されたパスにあるサービスアカウントファイルを取得
2. サービスアカウントファイルを使用してサービスアカウントを検索、使用して認証する
3. 環境変数が設定されていなければgcloudコマンドで以前認証したユーザ情報を検索、あればサービスアカウントを探しに行って以下同文。
サービスごと特定のリソースに別々のサービスアカウントを設定できるのでまずはアクセスしようとしているリソースに紐づいたサービスアカウントを検索します。リソースに紐づけがない場合は、そのリソースが属するサービスのデフォルトサービスアカウントを検索。それでも見つからない場合はエラーになります。
gcloud auth application-default loginコマンドを実行したときにADCが探してきた”てい”でADC用の格納場所に認証用のJSONファイルが作成される。これが実際に認証ライブラリが認証するときに使用されている。

sasami

その他の認証

OAuth 2.0 プロトコル
Identity-Aware Proxy (IAP)
Firebase Authentication
Identity Platform

sasami

 Secret Managerhttps://cloud.google.com/secret-manager/docs/overview?hl=ja
概要

パスワードやAPIキーなどの機密情報を安全に管理するための機能を提供する管理サービス。
シークレット

機密情報は「シークレット」という形式のデータに変換されて管理される。

シークレットは実際にはコレクションで機密情報本体に加えて、ラベル、アノテーション、権限を含む。

機密情報本体は「シークレットバージョン」というシークレットに含まれる要素として管理され、たとえばパスワードなら最初にAAAとつけてBBBとつけた場合、

■シークレット「パスワード」

　→メタデータ、シークレットバージョン１「AAA」

　→メタデータ、シークレットバージョン２「BBB」

という感じで保存される。
権限の管理

保存したシークレットの権限の管理にはIAMが使用される。

sasami

 事前トレーニング済みの学習モデルアプリにのせるためのAIとして用意された事前トレーニング済みの学習モデルが提供されている。
Vision API

画像検出のためのAI
Speech-to-Text API、Text-to-Speech API

音声からテキストに、テキストから音声にするためのAI
Cloud Translation API

爆速翻訳AI
Cloud Natural Language API

エンティティ分析（既知の固有名詞や人名などを抽出してその情報を取得する）のためのAI
Video Intelligence API

ビデオからエンティティ分析ができるAI
AutoML系

上記のモデルのうち独自にトレーニングできるエディション
また、TensorFlow、PyTorch、Vertex AI などのフレームワークを使用して独自のカスタムMLを作成できる。