マネージドインスタンスグループ (MIG)

• 以下3種類
  • アンマネージドインスタンスグループ
    • アンマネージドインスタンスグループはCloud Load Balancingの配下に単にVMをぶら下げるためのインスタンスグループ。
    • オートスケーリングやオートヒーリングは利用不可。
    • 単一ゾーンでのみVMをグルーピングする。
  • ステートレスマネージドインスタンスグループ
    • オートスケーリングやオートヒーリングを利用可能。
  • ステートフルマネージドインスタンスグループ
    • オートスケーリングは利用不可。
    • オートヒーリングを利用可能。
• インスタンステンプレートの更新 ( Instance Group Updater が組み込まれたもの)
  • PROACTIVE (先行型)
    • 既存の稼働中のVMにも適応する場合
  • OPPORTUNISTIC (追従型)
    • 既存の稼働中のVMには適応を保留し、インスタンスが終了したものにだけアップデートを行う。

https://qiita.com/pict3/items/079a0c15b354f5986a28

• インスタンステンプレート
  • インスタンスの設定を保存したテンプレート。
• オートスケール
  • カスタムイメージからインスタンステンプレートを作成し、インスタンステンプレートを基にオートスケールを指定したマネージドインスタンスグループを作成する。

https://blog.g-gen.co.jp/entry/compute-engine-explained-advanced

https://dev.classmethod.jp/articles/gcpforexam-blog3/

Bare Metal Solution

Regional Extentionと呼ばれる拡張されたリージョンで専用のベアメタルインスタンスを提供。
ライセンスはBYOL(Bring Your OWN LICENCE)。

GCEのネットワークの話

VPCネットワーク

• NICに対してIPアドレスを付与する。
  • 内部IP
    • プライマリIP : 必須。サブネットから与えられる。
      • エフェメラル
      • 静的
    • セカンダリIP : VM上のコンテナ運用で利用。各コンテナはセカンダリIPからIPを払い出される。
  • 外部IP : グローバルID。任意。

BIOIPも可能。
VMは最大8つのNICを持てる。ネットワークアプライアンス(FW)などをインスタンスにインストールして利用する場合に入口NWと出口NWで分けるためにそれぞれNICが必要。

Google Virtual NIC (gVNIC)

// TODO

GCEのバックアップの話

• スナップショット
  • ディスク単位で取得
  • 増分バックアップ
  • マルチリージョン or 特定のリージョンに保存可能

Migration for Compute Engine

VMware vSphere、EC2、Virtual machine (Azure)からGoogle CloudのGCEにサーバ移行するツール。
移行元にセットアップするMigrate Connectorがデータを継続的にGoogle Cloudへ転送する。
ダウンタイムを最小限にしながらサーバ移行できる。

• 移行ランブック
  • 移行するVMの構成を定義したCSV

https://sight-r.sts-inc.co.jp/google_cloud_article/gce-migration-part5/

Sole Tenancy Instance (GCE)

• ライセンス持ち込み(BYOL)シナリオ等でポリシーゆえに共有インスタンスを使えない場合に物理サーバを貸し切りにする。
  • Windows Serverとか。

Google Cloud Directory Sync (GCDS)

Cloud Identityの機能。
Microsoft Active DirectoryやLDAPサーバで登録されているユーザやグループをGoogle WorkSpacesやCloud Identityのユーザやグループに同期するツール。Linux版、Windows版と提供されている。
ユーザー認証の仕組みを提供するものではない。 認証を一元化する場合、既存のIDプロバイダとSAML2.0経由でフェデレートする。

https://qiita.com/pict3/items/dbffe6cc3cec4b2b4d7b

GCDS では Cloud Identity 側にディレクトリが同期されるため、最終的には、Google Cloud の ID を使いログインするという点です。
それに比べてWorkforce Identity Federation では一連のプロセスにおいて Cloud Identity が使われることがありません。

https://zenn.dev/google_cloud_jp/articles/3f06bac31aa013

• Workforce Identity Federation
  • Google Cloud リソースにアクセスできるようになるのは"ユーザ"
• Workload Identity Federation
  • Google Cloud リソースにアクセスできるようになるのは"(外部のクラウドやk8sで稼働する)アプリケーション"

これとは別でPassword Syncというのもある。 // TODO

Cloud Dataprep

• 内部的にはCloud Dataflow(とBigQuery?)が動くETLツール。それ故Dataflowのコンソールからも確認可能。
• Dataprepはpreparationの頭文字と考えられる。preparationは不定型なスキーマの生データを収集/加工し分析に利用できる状態にすること。
• GUI操作が提供され、データを確認しながら処理できる。→ AWS Glue Studio相当？
• データソースにはGCSやBigQueryなど種々指定できる。オンプレもでるとかできないとか // TODO 要確認

Cloud Dataproc

• HadoopやApatch Sparkのクラスタを作成し、クラスタ上でジョブを実行する。AWS EMR相当。
• ジョブ実行にあたり必要なインスタンスはユーザ側で作成する必要がある。
  • その点DataflowではマネージドなETLサービスゆえに、インスタンスのオートスケールにより自動調整されるため考慮不要。
  • ワーカーインスタンスとしてオンデマンドインスタンス以外にスポットインスタンスを利用可能。
• HDFSではなくGCSにデータを永続化可能。
  • ストレージとコンピュートリソースが分離できるため
  • それゆえサーバの常時起動不要でクラスタを使用する時のみ コンピューティングリソースを起動しオートスケールすることが可能。
• 既存リソースとしてHadoopやSparkの資産をリフト&シフトするならDataprocだが、そうでないならDataflowが推奨。

https://cyberagent.ai/blog/tech/gcp/1424/
https://mukiudo.dev/post/gcp/0002-etl-on-gcp/

Data Fusion

GUIベース(Data Fusion Studio)で簡単にETL環境を構築できる。
スケジュール実行やパイプラインのテンプレート化、エクスポートにも対応。
こちらはDataprocの上で動く。

https://qiita.com/tomoyanamekawa/items/e45317bada702159add0
https://mukiudo.dev/post/gcp/0002-etl-on-gcp/

まとめるとこんなイメージ。

• Dataflow 系はバッチ処理とストリーミング処理に対応し、特に ストリーミング処理に強い 。
• Dataproc 系はバッチ処理と インタラクティブなSQLクエリに有用 だが、ストリーミング処理に弱い。

Cloud VPN

• IPsecを利用したインターネットVPNでオンプレミスネットワークとVPCを接続する。
• 帯域幅は上下合計で3Gbpsが上限。一般的に10Gbps以下の帯域幅でよいなら専用線は不要でVPNで十分。
• VPNの終端であるVPNゲートウェイで暗号化/復号が行われる。
• 以下2種類提供。
  • HA VPN (高可用性 VPN)
    • SLA 99.99% (内部的にトンネルが2つ)
    • BGP(動的)のみサポート
  • Classic VPN
    • SLA 99.9% (内部的にトンネルが1つ)
    • 基本、静的ルーティングのみサポート(動的も一部条件下でのみサポートあり)
  • 比較表あり
• HA Cloud VPNでは、HA Cloud VPNとオンプレミスVPNゲートウェイの間に2本のトンネルが構成されており、一方がダウンしても接続が可能な冗長構成がとられている。一方でClassic Cloud VPNはトンネルによる冗長化がされず可用性が低い。
• VPNゲートウェイはリージョナルリソースであるため複数リージョンに接続する倍はそれぞれのリージョンにVPNゲートウェイを設置する必要がある。
• VPC間やVPC-オンプレ間でプライベートIPアドレス範囲が重複している場合、VPCピアは使えない(前者の場合)ので、VPNで解決する。
  • そもそも何でアドレス範囲が共通していると通信できあにのか？
    • VPC内のルータは自身と同じアドレスレンジの通信はローカルネットワーク宛のものと解釈するためVPC外に出ることができない。
• VPNではSNAT(sourceNAT)、DNAT(destinationNAT)により実際のIPアドレスをマスクして通信できるためIPアドレスのコンフリクトを機にしなくていい。

▲引用元: https://blog.g-gen.co.jp/entry/vpn-base

• ピアVPNゲートウェイ
  • オンプレやほかのクラウドプロバイダがホストするVPNゲートウェイ
• Cloud VPN ゲートウェイ
  • Google Cloud で稼働する仮想 VPN ゲートウェイ
  • リージョナルリソース。→ 冗長性を確保する場合、複数リージョンに展開し、それぞれピアVPN GWと1つ以上のトンネルを有する構成を取る。

Cloud Interconnect

AWS DX相当。

• インターネットを介さずGoogleの専用線を用いるため高速。
• Dedicated InterconnectとPartner Interconnectの2種類が存在。

Dedicated Interconnect

• Google指定のコロケーション施設(PoPが設置されている施設)内の相互接続ロケーションにおいて設置されたGoogle peering edgeとユーザのオンプレミスネットワークを直接光ファイバーケーブルで接続する。
• 10Gbpsまたは100Gbpsから帯域幅を選べる。

Partner Interconnect

• Googleのパートナーのサービスプロバイダを介して接続する。相互接続ロケーションにおいてGoogle peering edgeとService provider peering edgeが接続されており、ユーザのオンプレミスネットワークとService provider peering edgeを繋ぐことで専用線接続できる。
• 帯域幅は50Mbps〜10Gbpsの範囲で柔軟に選ぶことができる。

用語

メトロ(大都市圏)

コロケーション施設のある都市。

エッジアベイラビリティドメイン

• 各メトロにはエッジアベイラビリティドメインが2つ以上存在する。
• エッジアベイラビリティドメインは冗長性確保が目的であり、Googleの定期メンテナンスにて片方が停止していても片方が稼働している状態となる。
• この単位はゾーンとは異なる。

相互接続ロケーション

• ロケーション施設内でGoogleのネットワークと接続するポイント。
• いくつかの相互接続ロケーションは低レイテンシーが保証されており、コロケーション施設からVMまで5ミリ秒未満のアクセスが可能。

VLANアタッチメント

• ユーザ側のルータと接続先のVPC内のCloud Router間で、仮想的なインターフェースであるVLANアタッチメントを介したBGP接続を行う。
• Interconnectの契約単位。VPCの接続毎に1契約および帯域指定が必要となる。

ダイレクトピア

• GoogleWorkspacesやGoogle Cloudリソースへ高速なアクセスを提供する。
• Google Cloudアクセスが必須ではないため Google Workspacesの利用がメイン。
• インターネットASを運営している様な大規模な企業が対象であり、インターネット上のピアリングであることからGoogle Cloudのリソースとしては現れない。

キャリアピアリング

• インターネットASを自社で用意できないが同様の要件がある場合に、サービスプロバイダを介してピアリングを行うもの。
• 同じく Google Workspacesの利用がメイン。

https://atbex.attokyo.co.jp/blog/detail/37/
https://sdpf.ntt.com/services/docs/fic/tutorials/HowToConnectGoogle/index.html
https://www.topgate.co.jp/blog/google-service/9154
https://zenn.dev/persona/articles/8e6c6903c73ef0

Cloud NAT

• 戻りの通信は透過するが外部からの直接の内部IPしか持たないインスタンスへのアクセスはできない。AWS NAT GW相当。
• 内部IPしか持たないインスタンスにインターネットからアクセスできるようにするには？
  • → CLBを配置して前面に置くか、外部IPを付与するしかない。
• Cloud Routerにも設定が必要。

Cloud Router

VPC内において、サブネット間でルーティングの自動化を行う。
BGPを使用してルーティング情報を更新しIPトラフィックのルートを自動的に切り替える。
NATやInterconnect、VPN利用時には必要になる。
当然接続する環境間でIPアドレスの重複はしてはいけない。

Network Intelligence Center

ネットワークの可視性向上やトラブルシュートのツール群。
対応したGoogle Cloudリソース間の通信の到達性をテストできる。

• Firewall Insights
  • ファイアウォールの運用や効率を可視化しトラブルシュートや最適化に利用するツール。
  • 緩すぎるルールに対するサジェストや、無駄なルール(シャドウルール)の削除の推奨などを表示。(裏では Recommender API が利用されている。)
  • ファイアウォールルールロギングを有効にする必要がある。
• ネットワークアナライザ
  • VPC ネットワークの構成ミスや最適でない構成を検出する

https://blog.g-gen.co.jp/entry/network-intelligence-center-explained

CaaS

• PaaSに比べてマネージドな範囲は減る。
• コンテナのランタイムなどversionによって挙動が変わりうる部分をイメージとして固めることで移植性を高めることができる。
• Google CloudではCloud RunとGoogle Kubernetes Engineがこれに該当。

Cloud Run

CaaS。App Engine(PaaS)と似ているがあくまでコンテナの実行環境。
KnativeのServingがバックエンドを支えている。 // TODO Knative調査
GKEの場合はクラスタを作ってその上にコンテナをデプロイしていくが、Cloud Runでは実行環境は提供されているのでコンテナを稼働させる間だけ課金される。

• 作成したアプリケーションをbuildしイメージを作成後、Artifact Regsitryにアップロードし、Cloud Runがそれを取得して実行する。
• 同時実行性
  • 一般的なFaaSでは1インスタンスで1つしか処理できない。
  • 複数の処理を1インスタンスで実行できる。 リソース消費が効率化しコスト削減につながったり、コールドスタートを回避可能になる。
• リクエストがなければインスタンスは0。
  • コールドスタートを回避したい場合は最小インスタンス数を指定してWarm状態にすることも可能。
• 新しいリビジョンとしてアプリケーションをデプロイし、リビジョン間で任意の割合でトラフィックを分けテストするといったことが可能。

コンポーネント

Service

// TODO

Revision

上書きではなくバージョンが保持される。GAE同様。

CPUを常に割り当て

• リクエスト処理中のみCPUが割り当てられるため、非同期で処理させようとするとCPUを永続させる必要がある。

トラフィック制御

Blue/GreenなどGAE同様に制御可能。

アクセス制御

関数の呼び出し

IAM認証

認証には以下選択可能。

• 未承認の呼び出しを許可 Allow unauthenticated invocations
  • 一般公開する用途など
• 認証が必要 Required Authentication
  • IAMアクセス制御される。
  • Authorizationヘッダを入れないとアクセスできなくなる。

Ingress設定

特定IPに絞りたいなどの場合にはLoadBarancerを前段に立ててCloud Armorで制御が必要。
その上でCloudRunのIngressの設定として内部トラフィックとCloud Load Balancingからのトラフィックのみを許可することが必要。
← LBからのアクセスに絞らないとCloud Runを直叩きされるとアクセスできてしまうため。

関数から外部へのアクセス

サービスアカウント

Service単位でサービスアカウントを設定可能。

Egress設定

Cloud RunはVPC外のリソースであるためVPC内リソース(Memorystoreなど)に直接アクセスができない。
→ サーバレスVPCアクセスを設定することでVPCリソースにアクセスできる様になる。

サーバレスVPCコネクタを設定し、全てのトラフィックをVPCコネクタ経由に設定することも可能
→ IP固定したい場合(外部のSaaSを叩く必要がある場合かつ特定の登録済みIPからのみアクセスが許可されている様な場合)に全てのトラフィックをサーバレスVPCコネクタでVPCに渡し、固定IPを当てたCloud NAT経由でコールする方法が取られる。

IAP連携

Cloud Identity Aware Proxy(IAP)と連携することでアプリケーションはそのままに認証認可の仕組みを加えることができる。
AppEngineと異なり Cloud Runの前段にLoad Balancingを設定し、そこにIAPを当てる必要がある。
サーバレスNEG(Network Endpoint Group)を構成する必要がある。

サーバレスNEG(Network Endpoint Group)

Cloud RunやGAE、Cloud Functions、 API Gatewayのようなサーバレスリソースへのロードバランシングをする差異のエンドポイントのこと。
https://book.st-hakky.com/hakky/about-google-cloud-serverless-neg/

セキュリティ

VPC サービスコントロール境界に含めることができる。

App Engine vs Cloud Run

一般的なケースではどちらでも利用可能。
今後はCloud Runの開発に注力されていく。

Cloud Functions

FaaS。 Lambda相当。

• イベント駆動
  • 何かしらのイベントをトリガしてサーバレスな関数を実行する。
  • トリガとしてPub/Subからリクエストを受けるなど設定することが可能。

2nd GenではバックエンドはCloud Runが動いている。

• Cloud Functionsを作成するとCloud Runのコンソールから確認可能。
• 長時間の処理にも対応できる : 60min
• CLoud Run同様にリビジョン管理可能
• トリガはEventarcをサポとし、より多くのトリガを設定可能。
• 関数タイプ
  • HTTP関数
    • 同期実行
    • At-most-once
  • イベント実行
    • 非同期実行
    • At-least-once
    • 冪等性のある実装を。

CPUのみ指定可能。メモリはそこから自動的に決まる。

認証

Cloud Run同様。

• 関数を実行するURLを認証なしで直叩きできるかどうか
  • Allow unauthenticated invocations → 一般公開する用途で利用。
  • Required Authentication → AuthorizationヘッダにIDトークンを持ってないと拒否される。

Cloud RunとCloud Functionsの使い分け
→ 内部的には同じなので機能面で差はなくなる。
→ イベント駆動や小規模ではCloud Functions

Cloud SQL (PostgreDQL / MySQL / SQL Server)

• RDB。AWS RDS相当。
• SQL ServerのAlwaysOnを再現しようとすると本来Windowsサーバのクラスタリングを構成する必要があるがワンクリックで利用可能。
• プライマリインスタンスとスタンバイインスタンス(=フェイルオーバーレプリカとも呼ばれてる？)を異なるゾーンに作成することで耐障害性を提供。
• ストレージの自動拡張 を有効にすることで当初用意したストレージ容量の上限に近づいた差異には自動で拡張することが可能。
• HA構成
  • 内部的にはGCEとリージョン永続ディスクで構成されている。そのため複数ゾーンにまたがってプライマリ/スタンバイを用意できる。
  • HA構成は準同期レプリケーション(リアルタイムなデータレプリケーション) ←→ リードレプリカは非同期レプリケーション
  • HA構成はデータロスト時の復元用途ではない(完全な復元は保証されない)。 // TODO ？
• リードレプリカ
  • 任意ゾーンに作成可能。
  • リードレプリカは非同期レプリケーション
  • 負荷分散や可用性の向上が目的。
• CloudSQL Auth Proxy
  • IAMによる認証を用意に実現する //あとでハンズオン
• バックアップ
  • 増分バックアップ
  • 自動バックアップ
    • 定期的なスナップショット取得。
    • day単位。デフォルト7で365日分まで保持。それ移行はエクスポートする。
  • 保存先はマルチリージョンも選択可能。
• ポイントインタイムリカバリ
  • 最大7日の任意時点にリカバリ可能。
• メンテナンス
  • HWメンテはLiveMigrationのためダウンタイムなし
  • OSなどSWメンテはメンテはダウンタイムあり。
    • メンテナンスウィンドウを指定しておく。
• Query Insights
  • DB負荷やクエリ性能を可視化、クエリのボトルネックなどを探すのに有用
• Database Migration Service
  • 他社クラウドやオンプレからの移行をサポート
• バイナリログ(どちらかというとMySQLの機能)
  • MySQLのトランザクションログ機能。DB障害時にログから直前の状態まで復元することができる。

AlloyDB (PostgreDQL)

• コンピュート環境とストレージ層を分離。
• AWS Aurora相当？

Cloud Spanner

• RDBに属する。
• RDBの持つ特性であるSQLによるアクセスと整合性を維持しつつ、NoSQLのように可用性と水平スケーリングを可能にしている。
• RPO RTOを0とするクリティカルなワークロードでは有用。というかこれしかない。
• 自動バックアップをサポートしていないのでCLoud Schedulerなどと組み合わせて対応する必要がある // 要確認
• トランザクション型のワークロードに有用。大量のテレメトリを解析するような分析型ワークロードではBigQueryなどを選択する。

*1 : active-active構成が取れること。RDBでは一方をスタンバイとし非同期にコピーするため利用することはできない。

• リージョン/マルチリージョンを指定して構成するノード数を指定するだけで立ち上がる。
• 自動でシャーディングし、クエリをルーティングする。シャードの増減にダウンタイムを伴わない。
• パフォーマンスのための設計
  • スキーマ設計として、ホットスポットを回避する。プライマリキーの連番などはNG。(=アーキテクチャとしてはNoSQLに近いため)
  • インターリーブ(親子関係)を定義することでシャードが分かれて保存されデータアクセス時に複数シャードにアクセスし結合する手間がなくなる。

Cloud Bigtable

• Apatch HBase APIでアクセス可能なNoSQL(KVM型/ワイドカラム型)
• クイックストリーム分析や時系列データに最適。
• 数百PBクラスまでシームレスにスケール可能であり、秒間数千万件のリクエストを裁くことができることから、IoTデータや金融取引、株価データなどの低レイテンシー高スループットを要求されるシステムに利用される。
  • 同じNoSQLであるDatastore(おそらくFirestoreも同様)では高トランザクションに対応できない。
• 特にIoTセンサーデータや機械学習基盤など大量の列数を持つ場合に有用。(=ワイドカラム型の特性)
• 高いリアルタイム性を要求されるケースで有用。
  • 大量のリアルタイムデータの取り扱い がポイント。大量のログデータ分析などは向かず、BigQueryを利用。
• テーブルにデータが書き込まれると3台以上のサーバに自動でレプリケートされるため耐障害性が高い。
• マルチリージョンまたはマルチゾーンでのレプリケーションが可能。
• ただし、レプリケーションによりreadスループットは向上するが、writeスループットは低下する。
• NoSQLのスキーマ設計のアプローチに従い、ホットスポットを回避すべくRowKeyを適切に選択する必要がある。

Cloud Firestore

• NoSQL(ドキュメントストア型)であるが、ACIDトランザクションやSQLライクなクエリを提供している。AWSのDynamoDB相当(どちらかというとDatastoreと近そう、ネイティブモードは…？)。
  • キーによりエンティティを一意に識別する。DyanmoDBのイメージ。
  • 複数のエンティティを取得する場合、個々に取得するより一括取得を行う方が効率的。
• Firebaseとの親和性が高いためモバイルのバックエンドに使われる。
• オフライン利用
  • オフライン時にデータにアクセスでき、のちにオンラインになった際に同期される
• ネイティブモードとDatastoreモードを提供。
  • Cloud FirestoreはFirebaseのFirebase Realtime DBの後継サービス。
  • AppEngine由来のDataStoreから機能拡張したもの。
  • 故に今後はネイティブモードの利用が推奨。
  • 1つのプロジェクトではどちらかしか選択できない様になっているのはそういう背景もあるものと推察。
• モバイルとのリアルタイム同期をサポート。
• Cloud KMSを利用することで暗号化可能。

• リアルタイムアップデート : データストア側の更新をアプリケーション側にリアルタイムに反映させる。
• index情報を更新したい場合はgcloud datastore create-indexesとすることでほかと同様に扱える
  。

*: 注釈

アプリが使用している Firestore データのコピーがキャッシュに保存されるため、デバイスがオフラインであっても、アプリはデータにアクセスできます。
https://cloud.google.com/firestore/docs/manage-data/enable-offline?hl=ja#:~:text=Firestore はオフライン データの,データにアクセスできます。

アクセス制御

モバイルクライアント/Webクライアントライブラリ

Firebase AuthenticationとFirebaseセキュリティルールを使用してサーバレスな認証認可を実施できる。

サーバクライアントライブラリ

IAMベースのアクセス制御。ただし反映されるまでに5min程度のラグがある。

他

Datastoreで１エンティティ毎Getするのは非効率で、一括で取得することが推奨されているようです。
Stackdriverトレースでも複数回Getしているものは、一括で処理するようにアドバイスされます。

https://qiita.com/hanenao/items/b25bc3ec274380f8633a

用途としてもDanamoDB的で、アプリケーションのセッション情報などはDataStoreに逃し、インスタンスがスケールインしてもセッションを永続できるようにする用途がある。

Google Cloud Storage (GCS)

• AWS S3相当。
• リージョン/デュアルリージョン/マルチリージョンを選択可能。

ランダムプレフィックス

• パフォーマンスを改善する。
• AWS S3ではこの制約は無くなったはず。Google Cloudでは今はどうなのか？

ストレージタイプ

• Standard
  • 短期間のストレージや頻繁にアクセスされるデータに最適
• Nearline
  • アクセスが 1 か月に 1 回未満のバックアップとデータに最適
• Coldline
  • データへのアクセスが四半期に 1 回未満の場合に最適。
  • ただし、バックアップやアーカイブプロセス用にデータを完全に保持する場合、Archiveストレージのほうがストレージ費用が最も安くなる。
• Archive
  • アクセス頻度が年 1 回に満たないデータの長期デジタル保存。
  • コールドデータストレージ、DR用途。
    もしくはAutoclassを指定することでアクセス頻度に基づいてストレージクラスを最適化してくれる。 (S3 Interigent IA的な位置付け？)
    なお、各ストレージタイプでアクセスする時間は同じ。

バージョニング

AWS同様

リクエスト元による支払い

AWS同様 → リクエスタ支払い

アクセス制御の方法

• IAMによるバケットレベルの制御
• ACLによるオブジェクトレベルの制御
  なお、ACLによる制御は一般的なユースケースでは不要。例としてはIAMでアクセス管理できないユーザからのアクセスが想定される場合など。

バケット内の個々のオブジェクトへのアクセスをカスタマイズする必要がある場合。IAM 権限を付与できるのはバケットレベル以上ですが、ACL は個々のオブジェクトに設定できます。

署名付きURL

XML APIエンドポイントをGCSアクセスする場合のみ利用可能。 // TODO Hostingで使えないよという意味？

サービスアカウントの力を借りて指定期間だけアクセス可能なURLを発行する。
→ サービスアカウントキー(秘密鍵)の発行が必要。
サービスキーは以下フォーマットでDLされ、gsutilで署名付きURL作成時に指定する。

{
  "type": "service_account",
  "project_id": "hogehoge",
  "private_key_id": "xxxxxxx",
  "private_key": "-----BEGIN PRIVATE KEY-----\nxxxxxxxx-----END PRIVATE KEY-----\n",
    :
}

期限切れでアクセス不可になる他、サービスアカウントキーが無効化(削除)されるとすでに発行された署名付きURLも無効化される。

保持ポリシー

• バケットに設定することで特定期間、バケット内のオブジェクトの削除/上書きを禁止する。S3オブジェクトロック機能相当。
• 保持ポリシーにはロックをかけることで、ポリシー事体の削除や保持期間の短縮が不可となる。

Object Lifecycle

• 指定日数が経過したオブジェクトのストレージクラスを自動で変化させる。

アップロードしたファイルの同一性確認

• オンプレミスのファイルのCRC32Cハッシュを取得し(gsutil hash コマンド)、指定のバケット内のオブジェクトのハッシュを計算する(gstil lsコマンド)ことでアップロードしたファイルの同一性を確認できる。

gcs-fuse

• インスタンスからバケットををローカルファイルシステムとしてマウントするFUSEアダプタ。
• パフォーマンスは低下する。

暗号化

• KMSでキーを作成し、バケットの暗号化キーに設定することでCMEK可能。(デフォルトならGoogle側で管理のキー)
• KMSのencryptメソッドを使って手元でデータを暗号化することも可能だが、ローテーションをサポートしない。
• .boto設定ファイルに顧客提供の暗号化キーを指定することで、gsutilコマンドでファイルアップロードする際に自動で暗号化キーが使用される。

gsutil

.boto構成ファイルを利用することで以下が可能。

• プロキシ経由で使用できるように gsutil を設定する。
• 顧客管理または顧客指定の暗号鍵を使用する。
• 独自の運用に合わせて gsutil の動作を全体的にカスタマイズする。
  https://cloud.google.com/storage/docs/boto-gsutil?hl=ja

Cloud Filestore

• ファイル共有サービス。AWS EFS相当。
• NFSのみ対応。SMB非対応。
• POSIX準拠のファイルシステム。インスタンス間で共有してWrite/Read可能。
  • Persistent Diskの場合は共有できてもReadだけになる。(previewでマルチライター機能あり : 最大2台のVMから書き込める)

Memorystore (Redis / Memcached)

インメモリキャッシュ。 Redisとmemcachedの2つをサポート。
AWSのElasticache相当。

• shared
  • 他のユーザとリソースを共有する。利用リソースは保証されず(=ベストエフォート)、他のユーザの影響を受けうる。
• dedicated
  • 自分だけが占有するmemcache。利用リソースが保証される。

BigQuery

サーバレスなDWH。大量のデータから複雑なクエリを高速に実行する(OLAP)ビッグデータ分析向けサービス。
SQLでアクセス可能。
コンピューティングとストレージが分離されている。AWS RedShift Spectrum的な？
バッチ読み込みのほか、DataflowやPub/Subに繋いでストリーミング読み込みも可能。

データセットはプロジェクトに関連付く。
ジョブ(クエリやコピー、エクスポートなどの操作)はプロジェクトに紐づく。(異なるプロジェクトのデータでも実行可能。)
→ グループ会社でデータを提供する時にはIAM権限をあげるだけ。
→ Analytics Hubでデータ共有も可能。
- Analytics Hubに一度公開

• リアルタイムな分析には向いていない。→ リアルタイム性ならBigtable
• 特定の行を削除するクエリは非推奨 → テーブルの再作成が必要になりコストがかかる。
• パーティションをタイムスタンプにし、time_partitioning_expirationオプションを使用して有効期限を設定できる。
  • https://qiita.com/Fea/items/c6ea946ad07e294450d6
• アクセス制御リスト (ACL)
  • 特定のオブジェクトへのアクセス権を管理できる。
• データアクセス監査ログは明示的に有効にする必要がある。

コンポーネント

データセット

• ロケーションにデータを保存する。
• クエリ実行は同一ロケーションのデータにのみ。別ロケーションのデータにはアクセスできない。

テーブル

通常のDBのテーブル

ビュー

仮想的なテーブル。
通常のビュー : 実態は事前定義したSELECT文なので毎回ソースにアクセスが発生する
マテリアライズドビュー : 事前計算済みのテーブル。キャッシュするのでコストメリットがある。ソースデータに変更を加えると再計算される。

ルーティン

種々のデータ処理。
ユーザ定義の関数を実行したり、CLoud Functionsの関数と連携して実行することが可能。

外部データソース

サポートされたBigQuery以外のデータソースに対して直接接続してデータ操作可能。

パフォーマンス

パーティショニング : テーブルの分割。Athenaとかと考えは一緒。
クラスタリング : 特定列の値に基づくソートやフィルタ

BI Engine

各種BIからのリクエストをインメモリにキャッシュすることでデータアクセスを高速化することができる。 (AthenaのSPICE相当？)

データレイクの設計

以下の構成がある。

• データレイクを中央に置き、各部門がデータマートとして必要なデータのサブセットを取り出す。
• 各部門がデータレイクとして一次データを所有し、中央のデータウェアハウスに集計して取り込ませる。

BigQuery ML

DWHのデータを抽出し、MLにかけ、また戻すといったパイプラインを組む必要がない。中に組み込まれている。→ SQL文でモデル(一般的な線形回帰やロジスティック回帰...etc)を作成できる。

ACL

特定のオブジェクトへのアクセス権を管理できる。

• 列レベルのきめ細かいアクセス制御
  • アクセス不可にするか
  • 他にもnullや0でマスクして返すなど挙動を指定することも可能。
• 行レベルのきめ細かいアクセス制御
  • パフォーマンスメリットはないのでTableを分ける方がいい。
    VPCサービスコントロールで保護可能。

データセット単位で権限を与えるとそのデータセットのデータが全て閲覧できてしまうため、他のプロジェクトから一部のテーブルやデータのみを閲覧させる場合、該当プロジェクト用にデータセットを別途作成する。共有したいデータへのアクセスはビューを作成することで解決する。
該当プロジェクトからビュー/データセットへのアクセス権を付与し、ビューからオリジナルのデータセットへのアクセスを許可することで対応できる。

他

• テーブルスナップショット
  • 読み取り専用
• テーブルクローン
  • 読み書き可能

Cloud Tasks

Pub/Subとの比較。
https://cloud.google.com/pubsub/docs/choosing-pubsub-or-cloud-tasks?hl=ja

• 順序保証なし
• デッドレターなし

クラスタ

• シングルゾーンクラスタ
• マルチゾーンクラスタ
• リージョンクラスタ (AutoPilotではこれ)

ネットワーク

ルートベースクラスタ (非推奨)

• クラスタ内でPodやServiceの使用するIPアドレス範囲をノードが作成されるVPCネットワークと異なるネットワークとする。

VPC ネイティブクラスタ

• 推奨。Autopilotモードではこれ。
• クラスタ内でPodやServiceの使用するIPアドレス範囲をノードが作成されるVPCネットワークと同一のネットワークに揃える。
  • 各リソースにVPCサブネットを割り当てることでVPCに関連する機能(ピア接続、CloudVPN、ネットワークエンドポイントグループによる負荷分散、FWなど)を直接利用できるようになる。
• 限定公開クラスタを設定可能。

プライベートクラスタ(限定公開クラスタ)

パブリックに公開されるエンドポイントを制限しセキュリティを高めたもの。

• 通常のGKEクラスタは、ノードに対してパブリックIPが付与されており、Nodeportを利用してワークロードを公開することで外部からアクセスできる。
• コントロールプレーンに対してはパブリックエンドポイント(kube-apiserverのエンドポイント)が提供されており、インターネットからクラスタに対するkubectlによる操作が可能。

コントロールプレーンのエンドポイント(kube-apiserver APIエンドポイント)の種類

• パブリックエンドポイント
  • 承認済みネットワーク (Master Authorized Network)を設定することでパブリックエンドポイントへのアクセス元IPを制限できる。ホワイトリスト的なイメージ。
• プライベートエンドポイント
  • ノードにはプライベート IP アドレスのみが付与されクラスタの属するVPC内からのみアクセス可。→ GCEでbastionを立てる必要がある。
    • さらにパブリックエンドポイント同様に承認済みネットワーク (Master Authorized Network)を設定してbastionのサブネットを登録する必要がある。

クラスタの種類

• パブリッククラスタ(デフォルト)
  • コントロールプレーンとノードプレーンの間はパブリックIPでアクセス。
  • コントロールプレーンはパブリックエンドポイント。
  • ノードプレーンはインターネットアクセス可能。
    • もちろんVPCリソースなのでファイアウォール設定で許可された通信のみ。
• プライベートクラスタ
  • コントロールプレーンとノードプレーンの間はVPCピアリング接続されVPC間でプライベートIPでアクセス。
  • コントロールプレーンはプライベートエンドポイント。
  • ノードはプライベート IP アドレスのみが付与されクラスタの属するVPC内からのみアクセス可。
    • 外部からアクセスさせたい場合にはLB(Service/Ingress)を構成しインターネットアクセスできる様にする
    • ノードからインターネットアクセスが必要になる場合はCloud NATをVPCに構築する必要がある。
    • Google Cloud APIにアクセスが必要な場合、Private Google AccessでもOK。
      

Network Endpoint Group (NEG)

GKEではCloud Load Balancing + kube-proxyの2種類のロードバランシングがかかっている。
→ 極めて低レイテンシな通信を要求する場合にはLBから直接Podにバランシングさせる方法。(ネイティブクラスタでは内部的にPodのIPがわかるので直接飛ばせている。)

DodeLocal DNS Cache

ノード上でDNSをキャッシュできるアドオン。

ストレージ管理

• Persistent Disk
  • 1つのPodが書き込み可能。Readは複数から可能。
• Cloud Filestore
  • 複数Podが読み書き可能

アップグレード

リリースチャネル

• Rapid : 最新 (SLA対象外)
• Regular : バランス型
• Stable : 安定

メンテナンスウィンドウ

DBと同様。割愛。

ノードアップグレード

In-place(サージ)アップグレード

• 無停止てアップグレート可能。
• ローリングアップレード
• Nodeのアップグレード速度を支配するパラメータ
  • Max Surge
  • Max unavailable
• Podを落とす設定
  • PodDisruptionBudget (Nodeのと同様の設定)
  • TerminationGracePeriodSeconds (猶予期間)

Blue/Greenアップグレード(ノードレベル)

一部ユーザによる手動操作が必要になる

Blue/Greenアップグレード(クラスタレベル)

一部ユーザによる手動操作が必要になる

クラスタのスケーリング

ノードのスケーリング

ClusterAutoscaler

Node自体のスケーリング。
一般にCPU/メモリ使用率などをもとにしてスケーリングする場合にはHorizontalPodAutoscalerなどのPodのスケーリングと共に設定する。

Node Auto-Provisioning (NAP)

• スケジューリングされたPodサイズに応じて適切なマシンサイズをプロビジョニングし、ノードプール(=クラスタ内で同じ構成を持つノードのグループ)単位で増減させる。
• GKE AutopilotではNAPを利用してプロビジョニングされている。

Podのスケーリング

Horizontal Pod Autoscaler (HPA)

• 水平スケール
• CPU/メモリなどのインスタンスメトリクスに基づいたスケーリングのほか、Pub/Subキューのメッセージ数を元にしたスケールなども可能。

Vertical Pod Autoscaler (VPA)

• 垂直スケール
• 以下の更新モードが提供される。
  • Off : 推奨値を算出するのみ
  • Initial : 既存のPodの再起動は伴わない
  • Auto : 既存のPodの再起動を伴う
• ユースケース
  • 基本HPA推奨。Offモードとして推奨スペックの見積もりに利用する用途としては有用。

Multidimensional Pod AutoScaler (MPA)

• HPAとVPAの併用版。
• ユースケース
  • CPU UtilizationベースでPod数をスケーリングさせつつ、OOM予防のためにメモリベースの垂直スケールも含めるなどの場合に有用。

セキュリテイ

Workload Identity

特定のPodからのGoogleCloud内へのリソースアクセスを与える場合、クラスタにIAMサービスアカウントを設定すると全てのPodにアクセス権を当ててしまう。
→ k8sのリソースであるサービスアカウントとIAMサービスアカウントを紐づける(Workload Identity)ことでよりきめ細かいアクセス制御が可能となる。

オートヒール

Node Auto Repair

• UnhealthyなNodeを自動的に再作成する。

オートアップグレード

クラスタのアップグレードにおける運用負荷を軽減する。

リリースチャネル

• リリースチャネルにクラスタを登録することでControl PlaneのみではなくNode Planeもバージョンアップグレードもマネージドに更新される。(Autopilotモードでは自動でリリースチャネルに登録される。)
• Rapid、Regular、Stableの3つのチャネルの種類を提供。
• 予めメンテナンスウィンドウを指定し、アップデートの適用時間帯を指定することが可能。

ロールアウトシーケンス

• 複数クラスタ間での自動アップグレードの順序を制御する。
  • dev環境→stg環境→prd環境の順でアップグレードを適応できる様にするなど。

アップグレード戦略

• サージアップグレード : ローリング方式。一時的に縮退運転となりうる。
• Blue/Greenアップグレード : 一時的にノード数が2倍になる分コストにはなる。ロールバックは迅速。

参考

• https://gihyo.jp/article/2023/09/modern-app-development-on-google-cloud-02
• https://blog.g-gen.co.jp/entry/gke-explained

他

GKE On-prem

オンプレミス環境でGKEを利用するためのサービス。
現在はAnthos Cluster for VMWare。

Cloud DNS for GKE

クラスタ内のDNSコンポーネント(kube-dns)をCloud DNSに拡張したもの。
NodeLocal DNSCacheアドオンを有効にすることで各NodeでDNSキャッシュが可能。

Backup for GKE

アドオン。GKE クラスタ全体をバックアップ可能。

Cloud Operations for GKE

• 有効にすることでGKEクラスタのトラブルシュートやシステム全体のパフォーマンスの可視化を行うことが可能。

[廃止] kubemci (k8s-multicluster-ingress)

→ Ingress for Anthosが後継。

• 複数のKubernetesクラスターに跨ったIngressを作成するGoogle Cloudのツール。
• グローバルロードバランサを作成し複数のクラスタ間でトラフィックを分散させることが可能。

https://developers.cyberagent.co.jp/blog/archives/25912/

GKE vs Cloud Run

• 規模 大規模かどうか
• サーバレス(ゼロスケール)可能な点
• カーネルレベルのパフォーマンスチューニング要否

ワークロード

Kubernetes上で実行中のアプリケーションです。
ワークロードが1つのコンポーネントからなる場合でも、複数のコンポーネントが協調して動作する場合でも、KubernetesではそれらはPodの集合として実行されます。

https://kubernetes.io/ja/docs/concepts/workloads/

GKEで対応するワークロード

• Deployment
  • ステートレスアプリケーション
  • 多くのWebアプリケーション向け
• Stateful
  • ステートフルアプリケーション
  • DBやメッセージキュー向け
• Job
  • バッジジョブ
• DeamonSet
  • デーモン。ユーザーの介入を必要とせずに、割り当てられたノードで継続的なバックグラウンド タスクを実行する。
  • ログ収集やモニタリングツール向け

https://cloud.google.com/kubernetes-engine/docs/how-to/deploying-workloads-overview?hl=ja

Cloud Logging

ログ管理。
Google Cloudの全てのアクティビティ(リソースの作成/削除/変更など)も記録される。Cloud TrailとCloudWatchの機能の統合版？
→ ログエクスプローラで確認可能。

• Google Cloudのログ
• エージェントのログ
• VPCフローログ
• ユーザ作成のログ
• 監査ログ ( = Cloud Audit Logs)
  • 管理アクティビティ監査ログ
    • メタデータ/構成情報の作成/変更/削除などユーザ操作を伴うGoogle Cloud内の変更。
    • _Requiredパケット
    • デフォルト有効
  • システムイベント監査ログ
    • ユーザ操作を伴わないGoogle Cloud内の変更。
    • _Requiredパケット
    • デフォルト有効
  • ポリシー拒否監査ログ
    • VPC サービスコントロールのポリシーで拒否されたログを記録。
    • _Defaultパケット
    • デフォルト有効
  • データアクセス監査ログ
    • データに対する変更。メタデータ/構成情報の読み取り
    • デフォルト無効
      • ただしBigQueryのselect文の実行はデフォルト有効。無効化できない。
    • _Defaultバケット
• アクセスの透明性ログ
  • サポートで環境に触った際のログ

GCEからログ出力する場合はOpsエージェントが必要。 (AWSと一緒。CWLogsエージェント入れる)

• シンク
  • Cloud Loggingの受け取るログは全てLog Routerを通過する。
  • シンクはLog Routerにおいてログの振り分けを行うコンポーネント。
  • デフォルトでは_Requiredシンク、_Defaultシンクがあり、それぞれのCloud Loggingバケットに対して転送し、前者は400days、後者は30days保持される。 CloudWatchログストリーム相当。
  • ユーザ定義のシンクを作成することで任意の場所にログを転送することができ、転送先としては、Cloud LoggingバケットやGCSバケットのほか、BigQueryデータセット、Pub/Sub、Splunkなどがサポートされる。Pub/Subを通しCloudFunctionsなどをトリガするアーキテクチャが可能。
  • 集約エクスポート(集約シンク)を組織やフォルダリソースに作成することで組織やフォルダに属するすべてのプロジェクトからログをエクスポート可能となる。
  • _Requiredバケット、_Defaultバケットはデフォルトでグローバルに作成されるが任意のリージョンに変更可能。ただし組織全体にかかる設定。また、作成後は変更不可。

https://cloud.google.com/blog/ja/products/gcp/best-practices-for-working-with-google-cloud-audit-logging
https://zenn.dev/cloud_ace/articles/d9cfed34bb2427

Cloud Monitoring

各種メトリクス収集。

• メトリクスをトリガとしたアラートを設定可能。

• SLOを定義し監視することも可能。

• 標準メトリクスのほかカスタムメトリクスを格納できる。ダッシュボード化することでサービスのKPI監視として有用。

• アップタイムチェック

  • 公開サービスの稼働時間をチェックできる。
  • 死活監視などに有用。 → 失敗時にCloud Functionsをトリガして通知などの運用が可能。

スコーププロジェクト

• 複数のプロジェクトを横断して管理したい場合、監視対象のプロジェクトを束ねた監視専用のプロジェクト(=スコーププロジェクト)を作成することがベスト。

インシデントの管理

アラートにインシデントを定義でき、それらの対応状況を管理できる。

メトリクスエクスプローラ

グラフで可視化→ ダッシュボードに登録できる。

稼働時間チェック

SLO(目標)を定義し管理可能。(※SLAは保証。)
SLOの定義するには　SLIを定義する必要がある。
ErrorBudget = (1 - SLO)
ErrorBudgetが100%であることがいいことではない。=アプリケーションに変更を加えなければ達成される。→ ErrorBudgetの範囲で変更を加えアプリケーションを進化させることが重要(SREの考え方)

メトリクス

• 一度に 1 つの値で構成される測定値 → valueTypeはBOOLやINT64などを指定。
• 分布の測定の場合、値は単一の値ではなく集合となる。valueTypeはDISTRIBUTION。

https://cloud.google.com/monitoring/api/v3/kinds-and-types?hl=ja

metricKind フィールド

• GAUGE : 特定の時点で測定される値（時間単位の温度レコードなど）。
• CUMULATIVE 指標 : 特定の時点に測定対象となったデータの累積値が保存されます（例: 車両の走行距離計）。
• DELTA 指標 : 特定の期間に測定される対象の値の変化（株式の損失や損失を示す株式の概要など）。

https://cloud.google.com/monitoring/docs/monitoring-overview?hl=ja

アラートポリシー (通知ポリシー)

ClousWatch Alarm相当。
メトリクスを選択し条件式と異常時の通知先を指定する。

https://blog.g-gen.co.jp/entry/how-to-create-monitoring-alerts

Cloud Trace

トレースを提供。AWS X-Ray相当。OSSだとOpenTelemetry。
複数のマイクロサービスで構成される一連のアプリケーションのパフォーマンスを計測し、ボトルネックとなっている箇所を割り出す。

• Cloud Monitoringにメトリクスではダメなのはなぜか？
  • 複数のサービスがを横断する状況だと個々のサービスのパフォーマンス、処理時間を見ることが難しい。

Cloud Profiler

アプリケーションのパフォーマンス(リソース消費(CPUやヒープ)など)を継続的にプロファイリングする。
リアルタイムのレイテンシ確認(Traceの仕事)やアラート(Monitoringの仕事)の発報には向かない。
リソースを消費しているパスやコードを特定する。
プログラミング言語ごとにエージェントがあり、アプリケーション環境にインストールすることでパフォーマンスを解析し問題のあるコードを特定できる。

数行のコードを埋め込むだけでProfilerパッケージを利用し分析できるようになる。

https://zenn.dev/magicmoment/articles/perf-improvement-with-cloud-profiler-202302#cloud-profiler-の導入方法

Cloud Debugger

リアルタイムのアプリケーションデバッグなどトラブルシュートに役立つツール。

デバッグログポイント

サービス再起動や再デプロイ不要で、実行中のサービスにロギングを挿入することができる機能。
プリントデバッグを行う場合に何度もデプロイし直す必要がなくなる。

https://www.topgate.co.jp/blog/google-service/6317

Error Reporting

内部にはCloud Logging上で稼働。
実行中のアプリケーションで発生したエラーを自動的に追跡、分析、通知するツール。エラーカウントや分析に利用。
アプリケーションの死活監視のように稼働状況を定期的に監視して通知するような用途のサービスではない。→ 監視したいならCloud Monitoringでアップタイムチェック(ヘルスチェック機能)。
https://cloud.google.com/monitoring/uptime-checks?hl=ja

Managed Service for Prometheus

フルマネージドのPrometheus(GKEの外形監視OSS)。

Log Analytice

ログデータをBigQueryで直接ログ分析できるCloud LoggingとBigQueryの統合サービス。

VPCフローログ

傾向分析。VPCのトラフィックをサンプリング。

パケットミラーリング

VPCのトラフィックをミラーリング。

Cloud CDN

コンテンツキャッシュ。CloudFront相当。
ただ、注意すべきはLBに組み込まれている。Google Cloudにおいては前段に立てるという認識は間違い。

ちなみに、他の CDN ですと「CDN」という別種のサービスがあって、それを自分のサービスの手前(エンドユーザーとの間)に置く、といったイメージの方が多いと思います。つまり、CDN サービス → ロードバランサー → バックエンド、みたいなイメージです。そのため CDN の設定というと、「ロードバランサー( → バックエンド)」を指定することになると思います。
しかし、GCP では HTTP(S) Load Balancing 自体が巨大な CDN 機能付きロードバランサーなので、「CDN サービス → ロードバランサー」が一体化しており、CDN の設定というのは「バックエンド」の部分を指定する形になります。
絵にすると ↓ みたいな感じです。少し考え方が異なるので戸惑いがあるかもしれません。

▲ 引用元: https://medium.com/google-cloud-jp/cloud-cdn-custom-origins-dd496092b395

• キャッシュ
  • スキーム(プロトコル)やホスト名、クエリパラメータなどのキャッシュキーに基づきキャッシュされる。
  • すなわちキーにプロトコルを含んでいるとHTTPSとHTTPを区別するためキャッシュ効率が低下し得る。

Cloud Armor

AWS WAF相当。アプリケーションレイヤの攻撃を検知し、防御する。
基本、Cloud Load Balancing の背後にある Web アプリケーションのみを保護可能。

セキュリティポリシー

• 以下3種類
  • バックエンドセキュリティポリシー
    • エッジロケーションからバックエンドにルーティングされたリクエストを評価。
    • すなわちキャッシュヒットしなかったリクエストや動的コンテンツなどが対象。
    • エッジからキャッシュで返されるリクエストは評価対象外。
  • エッジセキュリティポリシー
    • エッジからキャッシュを返す前に評価。
    • Cloud CDN を有効化したバックエンドや Cloud Storage バケットが対象となる。
  • ネットワークエッジセキュリティポリシー
    • LBを使わない VMにも利用可能なポリシー。
    • 接続元IPなどによる制限をかけ、Googleのネットワークのエッジでブロックする。
    • 不正アクセスやDDoSを防げる。
• セキュリティポリシー内には複数のルールを定義する。

ルール

• ルールは優先度の高いものから評価される。
• gclout compute security-policiesコマンドで操作する。

DDoS保護

Standard Tier と Enterprise Tier の2種類。

• Enterprise TierではDDOSの請求保護が受けられる。(Shield Advanced相当。)
• Adaptive Protectionに対応。(Enterprise Tierでは全機能、Standardではアラート機能のみ利用可能。)
  • 機械学習モデルに基づき、DDoS攻撃と思われる挙動を検出、アラートやシグネチャを自動生成する機能。
• Enterprise Tierに登録すると、Cloud Logging と Cloud Monitoring でDDoS攻撃の状況を可視化できる。

https://blog.g-gen.co.jp/entry/cloud-armor-explained

スロットリング

リクエストにレート制限をかけることが可能。

他

• reCAPTCHA Enterprise との統合によりbot対策可能。
• WAFのブロックログはCLBのログを有効にする必要がある。

https://blog.g-gen.co.jp/entry/cloud-armor-explained

Cloud Datalab

Jupyter Notebookをベースとして作られた大規模データ分析・可視化のためのツール。
CLoud Monitoringのメトリクスをより深く掘り下げて確認したいようなケースで利用される。

https://cloud.google.com/blog/ja/products/gcp/explore-stackdriver-monitoring-data-with-cloud-datalab
https://topgate.co.jp/blog/google-service/4409