Zenn
Closed15

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

Google Cloud
ぱんだぱんだ

イントロ

Google Cloudでは

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

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

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

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

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

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

https://cloud.google.com/free/docs/free-cloud-features?hl=ja#free-tier-usage-limits

ぱんだぱんだ

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が配置される。以下のリンクがわかりやすい

https://iselegant.hatenablog.com/entry/google-cloud-load-balancer

  • サブネットは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にすればマニフェストファイルを元にクラスターを構築することができる
ぱんだぱんだ

GAE(Google App Engine)

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

https://dev.classmethod.jp/articles/gae-webapp/

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をもとに実行される

https://cloud.google.com/appengine/migration-center/run/compare-gae-with-run?hl=ja

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

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