Google Cloudについて学び直すメモ

ぱんだ

以下で入門したけどもう一回ちゃんと学び直す。

ぱんだ

イントロ

Google Cloudでは

組織
フォルダ
プロジェクト
リソース

の構成で成り立ってる。個人アカウントの場合は「組織なし」になる。フォルダはあってもなくてもいいけどプロジェクトをグループ化するときに便利。プロジェクトはプロジェクト。リソースはCompute Engineのようなリソース。

設計などで使うアイコンは以下の公式で用意されている。

https://cloud.google.com/icons?hl=ja

ていうかブラウザで設計図書けるようになってるし、そこからterraformのコード作成できるようになってるんだけど。すご

無料トライアルとは別に以下のリンク記載のリソースは無料で使用できる。

ぱんだ

ComputeEngine

無料枠

最低料金は月額で700円くらい
スペックに応じて価格はピンキリ
インスタンス起動時間で秒単位の課金
確約利用や継続利用割引などいろいろ割引がある

ssh

リソース作成をしたオーナーアカウントであれば普通にサッシュボードからsshすることができる。
参照権限しかないアカウントでsshするのに余計な鍵管理などすることなくsshできるOS Loginという仕組みがある。これはIAMのロールにCompute OSログインとサービスアカウントユーザーのロールを追加しプロジェクトまたはsshしたいインスタンスのメタデータにenable-oslogin: trueを設定することでsshできるようになる。

永続ディスク

HDD, SSDなどがあり、これらはある程度冗長構成をとっていて分散して管理される。ローカルSSDなんてものもありインスタンスと物理的に繋がってるのでパフォーマンスがいいが冗長構成をとっていないので耐久性とか可用性とかそういうものを犠牲にすることになる。

データをどこに保存するかをストレージオプションとして選択できる。

ゾーン永続ディスク　迷ったらこれ。同じゾーンにネットワークで繋がってる。
リージョン永続ディスク　２つのゾーンにまたがる。コストは２倍。
ローカルSSD 前述したようにパフォーマンスと可用性、耐久性がトレードオフ。
Cloud Storage
Filestore 高い。

これらのストレージのスナップショットもとることができ、手動でもできるしスケジュールして自動でもできる。このスナップショットをもとに別のインスタンスを新たに作成なんかもできる。

可用性ポリシー

VMプロビジョニングモデルをスポットにするとプリエンプティブルVMを7割引くらいで使える。ただし、Google Cloud側でリソースが不足したときにインスタンスが停止することがあるため途中で落ちても大丈夫なバッチ処理とかCIサーバーとかなら利用できるかもしれない。

2週間に一回程度でVMが稼働しているサーバーのメンテナンスが実行される。このときにVMインスタンスを修了させずに、稼働したままで他のホストに移行させることができる。この設定は推奨

自動再起動設定なんかもある。

ロール

VMインスタンスが他のGoogle Cloudリソースにアクセスする際にサービスアカウントが使用される。デフォルトだと編集権限を持ったCompute Engine default service accountが割り当てられる。

インスタンステンプレートとインスタンスグループ

VMインスタンスの雛形をテンプレートとして作成することで、いつでもそのインスタンスを作成することができる。

インスタンスグループは複数のインスタンスをグループ化しておくことができる。
これはロードバランサーの背後に置かれることが多い。

ぱんだ

IAM

３つの基本概念

プリンシパル(サービスアカウントなど。ユーザー)
ロール(リソース操作権限)
ポリシー(プリンシパル + ロールの集合)

プリンシパル

サービスアカウント
Googleアカウント
Googleグループ
Google Workspaceアカウント
Google Identityアカウント
認証済みのGoogle アカウント全て
全てのアカウント

ロール

基本ロールオーナー、編集者など。何千もの権限が付与されるので本番での使用は推奨されない。
事前定義ロール　事前にリソースごとなどで定義されたロール。本番使用推奨。
カスタムロール　事前定義ロールで要件を満たせない場合に作成可能。

###　ポリシー

ポリシーの実態は以下のようなJSON。

{
  "role": "roles/editor",
  "members": [
    "serviceAccount:200636842901@cloudservices.gserviceaccount.com",
    "serviceAccount:200636842901-compute@developer.gserviceaccount.com"
  ]
}

ポリシーアナライザーという機能でどのプリンシパルでどのような権限を持っているといったクエリを発行することでポリシーを検索することができる。

ポリシーには継承という概念があり組織->フォルダ->プロジェクト->リソースという階層構造にたいして上位のレイヤーに付与されたポリシーはその下の全てのレイヤーで有効となる。

IAMのAPIの整合性でポリシーの読み込みは結果整合性に基づき古い結果を返すことがある。書き込みに関しては逐次整合性に基づき時系列順に実行される。

ぱんだ

Cloud Billing

請求の基本概念。今までに出てきた組織の上にドメインという概念がある。これはGoogle Workspaceのようなものが紐づいている。実際の課金情報はドメインの外で管理されその課金情報を課金アカウントに紐づける。この課金アカウントはドメイン内部に存在する。課金アカウントをプロジェクトと紐づけることでリソースの利用ができる。

プロジェクトやリソースにはラベルをつけることができ、課金情報のフィルタリングに使用することもできる。

アクセス制御

請求関係のアクセス制御として以下の６つの権限がある。Billingに関する権限はIAMによって実現するが設定場所はIAMではなくBillingの画面。プロジェクト支払い管理者のみIAMから設定できる。

請求先アカウント作成者　請求先アカウントを作成
請求先アカウント管理者　作成はできない。支払い方法の管理や請求書のエクスポートなど
請求先アカウントユーザー　プロジェクトを請求先アカウントにリンク
請求先アカウント閲覧者　費用情報の閲覧
請求先アカウントの費用管理者　費用情報を表示、エクスポート
プロジェクト支払い管理者　プロジェクトと請求先アカウントにリンクや解除

###　予算とアラート

予算を決めて請求管理者にメールで通知
Cloud Monitalingを使用して最大5人までメールで通知
Cloud Pub/Sub, Cloud Functions, Billing APIを使用することで予算のトリガーに対してリソースを削除したりなどの操作も可能

基本的に予算を越えたからといってリソースが停止、削除されることはない。

ぱんだ

Deployment Manager

Google Cloud のIaCを実現するための仕組み
AWSのCloud Formationみたいなもの
Yamlファイルでリソースを定義する
テンプレートをJinjaまたはPythonで記述できる
実際の現場ではTerraformが使われる方が多いだろう

ぱんだ

オペレーションスイート

SRE業務で使用されるようなモニタリング、メトリクス収集、ログ、通知などの機能群。

Cloud Monitor
Cloud Logging
Error Reporting
Cloud Debugger
Cloud Trace
Cloud Profiler

ぱんだ

VPC

defaultというネットワークが構築済み
ネットワーク内のサブネット間通信は可能
ネットワークを跨いでの通信はできない
VPCピアリングを使えばネットワークを跨いでの通信も可能
Google CloudのVPCはグローバルリソースなので、各サブネットはリージョンに配置される。
AWSはリージョン単位でVPCが配置される。以下のリンクがわかりやすい

サブネットはipアドレスの範囲
CIDR方式で定義することが多い
VPC内のリソースに外部からアクセスするにはファイヤーウォールの設定で適切にポートに穴をあけたりしないといけない

ぱんだ

Cloud Storage

マネージドなストレージサービス。

データの保存場所は単一リージョンやマルチリージョンから選べる。（冗長構成がとれる）
eleven nineの耐久性
ストレージクラスがStandard、Nearline, Coldline, Archiveの４種類ある
アクセスする機会が少ないほどコストが安くできる
アクセス制御はIAMとは別にACL(Access Control List)がある
オブジェクトのバージョン管理も可能
ライフサイクル管理

gsutil

Cloud StorageにアクセスするためのCLIツール(Python製)。

ぱんだ

BigQuery

サーバーレスのデータウェアハウス。分析基盤として人気のあるプロダクト。10Gのストレージと1Tのクエリが無料枠としてある。

ダッシュボードからテーブルの作成やクエリの実行は可能
クエリ実行で発生するデータ処理量が課金対象になるためdryrun機能がある
bqというコマンドラインツールもあるしプログラムから実行もできる

ぱんだ

GKE(Google Kubernetes Engine)

コンソールぽちぽちで構築できるようにもなっている
さらにk8sのワーカーノードの管理も完全にサーバーレスにしたAuto Pilotモードもあり、マニフェストもノードのことも考えずにクラスターを構築できるようになってる
Auto Pilotモードではなくスタンダードモードで構築した場合、ワーカーノードはCompute Engineとなる
AWSのEC2とfargateみたいなものと理解
当然、kubectlを使い向き先をGoogle Cloudにすればマニフェストファイルを元にクラスターを構築することができる

ぱんだ

Cloud Identity

IDaaS
Google Cloudの組織登録をするにはGoogle WorkspaceかCloud Identityを紐づける必要がある
実際はスプレッドシートのようなGoogleアプリの利用もしたいと思うのでGoogle Workspaceで社員のユーザー管理をするんじゃないだろうか
どちらにせよ組織のドメインが必要

ぱんだ

GAE(Google App Engine)

以下の記事がわかりやすい

Google CloudのPaaS。Cloud Runと類似しているけどGAEは言語ランタイムを提供するためwebアプリケーションのデプロイに適している。Cloud Runはコンテナランタイムを提供するためGAEよりも柔軟な利用ができる。

また、GAEはバージョン管理が可能でトラフィックを細かく調整できる。そのため、新バージョンをリリースしたときに段階的にトラフィックを流したり、バグがあったときにバージョンを戻したりといったことがかなり容易に実現できる。

デプロイはgcloud app deployというコマンドのみで可能だが、このコマンドはソースコードのアップロード、ビルド、コンテナイメージの作成といった多くの処理が裏側で実行されている。

GAEには標準モードとフレキシブルモードの２つのモードがあり、フレキシブルモードはDockerイメージからアプリケーションをデプロイできる。

ぱんだ

Cloud Functions

Google CloudのFaaS。GAEがアプリケーションレベルでデプロイするのに対して、Cloud Functionsは関数単位でデプロイする。

CloudFunctionsは執筆時点で第一世代と第二世代があり、第二世代は以下のような特徴がある。

最大実行時間が9分から60分に大幅増加
Cloud Runをベースに利用
インスタンスごとに最大1000のリクエストを同時処理できる
トラフィックが増加したときは自動的にインスタンスの数を増やし、負荷を分散する

ぱんだ

Cloud Run

サーバーレスのコンテナランタイム。

利用できるコンテナレジストリはContainer Registry、Artifact Registory
Artifact Registoryが推奨でOSやソースコード、言語パッケージなどアーティファクトを総合的に管理できる
Docker Hubは使えない
コンテナイメージならなんでもよさそうだけどCloud Buildを使用してソースコードからイメージを作成しデプロイする
自動スケーリングの設定でインスタンス数をある程度柔軟に設定可能
最適起動数を0にすればリクエストがないときはインスタンス起動数を０にしてコスト節約ができる
最大と最低起動数をあわせれば固定数起動することができる
Cloud Buildによるビルドはリポジトリ内のDcoerkfileと.cloudbuild.yamlをもとに実行される

GAEが長らく使用されていてそこから生まれたCloud Run。GAEとCloud RunはGAEがソースコードだけでなくコンテナイメージからもデプロイできるようになっているので同じような用途で使用できるがCloud Runの方がより柔軟な感じはする。素人目だと正直どっちでもいい気がしなくもないけどCloud Runの方が注目されているし、後発として考えて作られてる気がするので個人的にはCloud Runで作ると思う。

このスクラップは2024/02/01にクローズされました