Google Cloud Professional Architect の勉強メモ
概要
自分の勉強用に、知らなかったサービスや設定などをサービスごとに羅列するページ
すでに知っていることは書かないので、網羅的なものを求める他の人の参考にはならないかもしれません。
いろんなネット記事の内容やChatAIとの壁打ちも含んでいるので誤った情報があるかもしれません。
参考元のURLを途中から張り出したので、引用しているのに参考元の記載がない箇所は受かったあと追って直します。
Cloud Load balancing
外部ロード バランシングと内部ロード バランシング
-
外部ロードバランサは、インターネットからのトラフィックを Google Cloud Virtual Private Cloud（VPC）ネットワークに分散します。
-
内部ロードバランサは、ロードバランサと同じ VPC ネットワーク内のクライアント、または VPC ネットワーク ピアリング、Cloud VPN、または Cloud Interconnect を使用して VPC ネットワークに接続されたクライアントからのトラフィックを分散します。
グローバル ロード バランシングとリージョン ロード バランシング
ロードバランサで処理する必要のあるトラフィックの種類と、クライアントが内部か外部かにより、グローバル ロードバランサとリージョン ロードバランサのどちらを選択するのかが決まります。
グローバル ロードバランサとして使用できるのは、外部ロードバランサのみです。※クロスリージョン内部ロードバランサもグローバルなトラフィックを扱うことは可能
バックエンドが複数のリージョンにある内部ロードバランサの場合は、クロスリージョン ロードバランサを選択します。クロスリージョン ロードバランサには、VPC ネットワーク内のリージョン サブネットから取得したリージョン内部 IP アドレスを使用してアクセスできます。
1 つのリージョンにのみバックエンドが必要な場合や IPv4 終端のみが必要な場合（IPv6 ではない）、あるいは、トラフィックを特定のリージョン内に維持することが法令で義務付けられている場合は、リージョン ロードバランサを選択します。
プロキシ ロード バランシングとパススルー ロード バランシング
ロードバランサで処理する必要のあるトラフィックの種類と、クライアントが内部か外部かにより、プロキシ ロードバランサとパススルー ロードバランサのどちらを選択するのかが決まります。
プロキシ ロードバランサ
ロードバランサで受信クライアント接続を終端し、ロードバランサからバックエンドへの新しい接続を開きます。すべてのアプリケーション ロードバランサとプロキシ ネットワーク ロードバランサは、このように動作します。クライアント接続は、Google Front End（GFE）または Envoy プロキシを使用して終端されます。
パススルー ロードバランサ
クライアント接続を終端しません。ロード バランシングされたパケットは、パケットの送信元、宛先、ポート情報（該当する場合）が変更されずにバックエンド VM によって受信されます。接続は、バックエンド VM によって終端されます。バックエンド VM からのレスポンスは、ロードバランサを経由せず、クライアントに直接送信されます。これを Direct Server Return といいます。クライアント パケットの情報を保持する必要がある場合は、パススルー ロードバランサを使用します。名前が示すように、パススルー ネットワーク ロードバランサはこのカテゴリに分類されます。
Google Cloud Armor による外部ロードバランサの保護
| ロードバランサのタイプまたはモード | Google Cloud Armor セキュリティ ポリシー | サポートされているセキュリティ ポリシーの種類 |
|---|---|---|
| グローバル外部アプリケーション ロードバランサ | ◯ | - バックエンド セキュリティ ポリシー - Edge のセキュリティ ポリシー |
| 従来のアプリケーション ロードバランサ | ◯ | - バックエンド セキュリティ ポリシー - Edge のセキュリティ ポリシー |
| リージョン外部アプリケーション ロードバランサ | ◯ | - リージョン バックエンド セキュリティ ポリシー |
| グローバル外部プロキシ ネットワーク ロードバランサ | ◯ | - バックエンド セキュリティ ポリシー - 従来のプロキシ ネットワーク ロードバランサ - バックエンド セキュリティ ポリシー |
| 外部パススルー ネットワーク ロードバランサ | 制限有 | - ネットワーク エッジのセキュリティ ポリシー |
Google Cloudのロードバランシング全体の流れ
- フロントエンド
- ロードバランサーがクライアントからのリクエストを受け取ります。
- 例: グローバルHTTP(S)ロードバランサーがTLS/SSLを終端。
- バックエンドサービス
- トラフィックのルーティングポリシーやヘルスチェックが定義されます。
- 複数のNEGを参照可能。
- Network Endpoint Group（NEG）
- ロードバランサーがトラフィックを送信するエンドポイントを定義するグループ
- 実際にリクエストを処理するエンドポイント（Compute Engine、Kubernetes、Cloud Runなど）をリスト化。
- 動的にスケール可能で、高可用性を実現。
- 例：GKEクラスタ内で稼働するアプリケーションをNEGとして登録 → Podがスケールアウト/インすると、NEGが動的にエンドポイントを更新
- エンドポイント（Compute EngineやKubernetesなど）
- ロードバランサーがトラフィックをどのように配信するかを定義する設定
- トラフィックを処理するアプリケーションが動作。
参考
Virtual Private Cloud
Virtual Private Cloud（VPC）は、Compute Engine 仮想マシン（VM）インスタンス、Google Kubernetes Engine（GKE）クラスタ、サーバーレス ワークロードにネットワーキング機能を提供します。VPC は、クラウドベースのリソースとサービスに、スケーラブルで柔軟性に優れたグローバルなネットワーキングを提供します。
内部アプリケーション ロードバランサ用に内部パススルー ネットワーク ロードバランサとプロキシ システムを提供します。
Cloud VPN トンネルと、Cloud Interconnect 用の VLAN アタッチメントを使用して、オンプレミス ネットワークに接続します。
Google Cloud の外部ロードバランサからバックエンドにトラフィックを分散します。
内部通信だけに関して言えば、内部LBと似ているところがありつつもVPCはIP層のプロトコルである。また、負荷分散は行わなずネットワーク全体の設計に関わる機能として利用するもの。なので、アプリやNEGには関係なくGoogleCloud内の全体のリソース間通信に使う。
また、CloudVPNはIPsec VPNトンネルで動作する。そのためメインの役割は暗号化通信による保護であるため、負荷分散やヘルスチェックは行わない。こちらはセキュアな通信が必要なオンプレとの通信や別リージョンVPCとの通信などに使う。
ファイアーウォールルール
暗黙の許可Egressルール
アクションがallow、宛先が0.0.0.0/0、優先度が最低（65535）のegressルールは、GCPによってブロックされたトラフィックを除き、任意のインスタンスが任意の宛先にトラフィックを送信することができます。
アウトバウンドアクセスは、より高い優先度のファイアウォールルールによって制限される場合があります。
インターネットアクセスは、他のファイアウォール・ルールがアウトバウンド・トラフィックを拒否しておらず、インスタンスが外部IPアドレスを持つか、NATインスタンスを使用している場合に許可されます。
暗黙の拒否のIngressルール
アクションがdeny、ソースが0.0.0.0/0、優先度が最低値（65535）の受信ルールは、インスタンスへの受信トラフィックをブロックすることで、すべてのインスタンスを保護します。
着信アクセスは、より高い優先度のルールによって許可される場合があります。
デフォルトのネットワークには、このルールを上書きする追加のルールがいくつかあり、特定のタイプの着信トラフィックを許可することに注意してください。
VPC の共有とピアリング
共有 VPC
1 つのプロジェクト（ホスト プロジェクトと呼ばれます）から Google Cloud 組織内の他のプロジェクトに VPC ネットワークを共有できます。共有 VPC ネットワーク全体へのアクセスを許可するか、特定の IAM 権限を使用してサブネットを選択できます。
VPC ネットワーク ピアリング
VPC ネットワーク ピアリングを利用すると、Google Cloud に Software as a Service（SaaS）エコシステムを構築できます。これにより、ネットワークが同じプロジェクト、異なるプロジェクト、または別の組織のプロジェクトかどうかに関係なく、異なる VPC ネットワーク間でサービスを非公開で利用できるようになります。
VPC ネットワーク ピアリングでは、内部 IP アドレスを使用してすべての通信が行われます。ファイアウォール ルールに従い、ピアリングしたネットワーク内の VM インスタンスは、外部 IP アドレスを使用せずに互いに通信できます。
ピアリングしたネットワークは、プライベート IP アドレス範囲のサブネット ルートを自動的に交換します。VPC ネットワーク ピアリングでは、次の種類のルートを交換するかどうかを構成できます。
- 非公開で再利用されるパブリック IP 範囲のサブネット ルート
- カスタムの静的ルートと動的ルート
ピアリングされる各ネットワークのネットワーク管理は変わりません。IAM ポリシーが VPC ネットワーク ピアリングによって交換されることはありません。たとえば、1 つの VPC ネットワークのネットワーク管理者とセキュリティ管理者が、ピアリングされたネットワークのロールを自動的に取得することはありません。
プライベート(限定公開)サービスアクセス
Virtual Private Cloud（VPC）ネットワークと Google または(GoogleCloud内の)サードパーティが所有するネットワークとのプライベート接続です。
Google またはサードパーティ（サービスを提供しているエンティティ）は、サービス プロデューサーとも呼ばれます。プライベート接続を使用すると、VPC ネットワーク内の VM インスタンスとアクセスするサービスで、内部 IP アドレスを使用して排他的に通信できるようになります。VM インスタンスは、インターネット アクセスまたは外部 IP アドレスがなくても、限定公開サービス アクセスを介してサービスにアクセスできます。
ごちゃごちゃ書いてるけど、つまり
GoogleCloud内でプライベートIPでネイティブサービスとマーケットプレイスのサービスで接続する仕組み
ってことかと。
参考
VPC Service Controls
サービス境界（service perimeters）と呼ばれる論理的な囲いを作り、その囲いの外から中へのアクセスを防いだり、逆に囲いの中から外へのデータ流出等を防ぐことができます。
VPC Service Controls では、Google Cloud サービスに対する API リクエストの接続元を制限することができます。
- できることの例
BigQuery に対するクエリの発行元を制限
Cloud Storage からのオブジェクト読み取りのアクセス元を制限
Google Kubernetes Engine（GKE）クラスターの設定変更のアクセス元を制限
VPC Service Controls では、例えば VPCへのネットワーク的なアクセスを制限することはできません。それは「VPC ファイアウォール」や「WAF（Cloud Armor）」といった仕組みが担います。
- できないことの例
VM への SSH ログインの接続元 IP アドレスを制限
Webサイトの管理画面へのアクセスの接続元 IP アドレスを制限
Web アプリへの攻撃を防御
サーバーレス VPC アクセス
サーバーレス VPC アクセスを使用すると、Cloud Run、App Engine、Cloud Run functions などのサーバーレス環境から Virtual Private Cloud（VPC）ネットワークに直接接続できます。サーバーレス VPC アクセスを構成すると、サーバーレス環境で、内部 DNS と内部 IP アドレス（RFC 1918 および RFC 6598 で定義）を使用して VPC ネットワークにリクエストを送信できます。これらのリクエストに対するレスポンスも内部ネットワークを使用します。
サーバーレス VPC アクセスを使用する主な利点は次の 2 つです。
VPC ネットワークに送信されたリクエストは、インターネットに公開されることはありません。
サーバーレス VPC アクセスを介した通信では、インターネットに比べてレイテンシが低くなります。
ハイブリッド クラウド
Cloud VPN 後述
Cloud VPN では、安全なバーチャル プライベート ネットワークを使用して、VPC ネットワークを物理的なオンプレミス ネットワークまたは別のクラウド プロバイダに接続できます。
Cloud Interconnect 後述
Cloud Interconnect は、高速の物理接続を使用して、VPC ネットワークをオンプレミス ネットワークに接続します。
Cloud Router
Cloud VPN
ネットワークを再接続する際に注意しなければならないことは、既存のアドバタイズを削除することはできますが、IP 範囲を拒否リストに追加することはできないということです。
つまり、カスタムルートアドバタイズをIP範囲のブロックのために使用することができないということです。
したがって、データセンターと通信するためには、IP空間が重複しないように新しいIPアドレス範囲を適用する必要があります。
オンプレとの接続 HA VPN トポロジ
高可用性Cloud VPN HA VPN トポロジ
Cloud VPN では、オンプレミス ホストが 1 つ以上の IPsec VPN トンネルを介してプロジェクトの Virtual Private Cloud（VPC）ネットワーク内の Compute Engine 仮想マシン（VM）インスタンスと通信します。
Cloud Interconnect
Cloud Interconnect は低レイテンシで高可用性の接続を提供し、Google Cloud Virtual Private Cloud（VPC）ネットワークと他のネットワークとの間でデータを確実に転送できます。また、Cloud Interconnect 接続から提供される内部 IP アドレス通信により、双方のネットワークから内部 IP アドレスへの直接アクセスが実現されます。
Cloud Interconnect には、Google Cloud を含むようにネットワークを拡張するための次のオプションが用意されています。
- Dedicated Interconnect は、オンプレミス ネットワークと Google ネットワークの間の物理的な直接接続を提供します。いわゆる専用線。
- Partner Interconnect は、サポート対象のサービス プロバイダを介して、オンプレミス ネットワークと VPC ネットワークを接続します。
- Cross-Cloud Interconnect は、別のクラウドのネットワークと Google ネットワークを物理的に直接接続します。
ビジネスクリティカルとでてきたら、Interconnectで可能ならサブ回線も用意する。
Cloud Storage
コマンドによるアクセス
gsutil含めコマンドはオンプレでもインストールすれば使用可能
特に試験ではGoogle Cloudへの移行を多く問われるので、gsutilコマンドもたまに見かける。
マルチスレッド実行 gsutil -m オンプレのデータを圧縮してそのままGoogleStorageにマルチスレッドで転送とかに使う
保持ポリシーの使用とロック
必要な権限
バケットに対するストレージ管理者（roles/storage.admin）
制限
オブジェクトのバージョニングを無効にする
バケットのロックは元に戻すことができません。
バケットをロックする場合、次の点に注意してください。
- バケットから保持ポリシーを削除することはできません。
- ポリシーの保持期間を短縮することはできません。(延長はできる)
ロックされたポリシーの保持期間を削除または短縮しようとすると、400 BadRequestException エラーが発生します。
保持ポリシーをロックした場合、Cloud Storage はバケットを含むプロジェクトのprojects.delete 権限にリーエンを自動的に適用します。これにより、プロジェクトが削除できなくなります。プロジェクトを削除するには、このようなリーエンをすべて削除する必要があります。リーエンを削除するには、roles/owner ロールと roles/resourcemanager.lienModifier ロールに含まれる resourcemanager.projects.updateLiens 権限が必要です。
*リーエン：lien 担保権のこと
暗号化
デフォルトでは、Cloud Storage は、Google 管理の暗号鍵と AES256 暗号化アルゴリズムを使用して、すべてのオブジェクト データを暗号化します。
ただし、顧客指定の暗号鍵（CSEK）または Google Cloud KMS で管理する顧客管理の暗号鍵（CMEK）のいずれかの暗号鍵タイプを使用することもできます。
Cloud Storage では、CSEK を Google のサーバーに永続的に保存したり、管理したりすることはありません。
gsutil は、JSON API を使用して Cloud Storage オブジェクトを操作するための CSEK を受け入れます。これらの鍵は、次のように .boto 構成ファイルで指定します。
[GSUtil]
encryption_key = ...
decryption_key1 = ...
decryption_key2 = ...
Storage Transfer Service
- 他のクラウド ストレージ プロバイダから、またはオンプレミス ストレージから Cloud Storage バケットにデータを転送またはバックアップします。
- ある Cloud Storage バケットから別の Cloud Storage バケットにデータを転送し、さまざまなユーザー グループやアプリケーションで使用できるようにします。
- データ処理パイプラインまたは分析ワークフローの一部として、データを定期的に移動します。
Transfer Appliance
Transfer Appliance は、Google アップロード施設に転送して安全にデータを保存できる大容量ストレージ デバイスで、データは Google アップロード施設から Cloud Storage にアップロードされます。
つまり、高速にUploadできる近距離のGoogle施設のディスクにマウントを行いUploadし、そこからHDDなりSDDを運送してCloud StorageにUploadしてくれる。
- 暗号化、改ざん防止、他人が開けられない仕組みでセキュリティ確保
https://cloud.google.com/transfer-appliance/docs/4.0/overview?hl=ja
Cloud Firestore
Filestore インスタンスは、さまざまなクライアント タイプに接続できる、Google Cloud 上のフルマネージド ファイル サーバーです。
- Compute Engine VM
- Google Kubernetes Engine（GKE）クラスタ
- Google Cloud VMware Engine などの外部データストア
- オンプレミス マシン
- Cloud Run サービス
プロビジョニングが完了すると、必要に応じてダウンタイムを発生させずにインスタンスの容量をスケーリングできます。
Cloud Storageや、PersistentSSDと何が違うのかというと、
Firestoreはドキュメント指向のデータベース。ドキュメント指向と聞くと概念的で掴みづらいが、NoSQLのValue部分にドキュメントを登録するということ。
Firestore の NoSQL データモデルに従い、値に対応するフィールドを含むドキュメントにデータを格納します。これらのドキュメントはコレクションに格納されます。コレクションは、データの編成とクエリの作成に使用できるドキュメントのコンテナです。ドキュメントでは、単純な文字列や数値から複雑なネスト オブジェクトまで、さまざまなデータタイプがサポートされています。また、ドキュメント内にサブコレクションを作成し、データベースの拡大に合わせて拡張できる階層型データ構造を構築できます。Firestore データモデルでは、アプリに最適なあらゆるデータ構造がサポートされています。
Firestoreのいいところはドキュメントを管理するだけでなく、クエリによる検索を行うことができる。
非構造化データを扱うことができます。
非常に高速で、容量も大きいのでPOSIX準拠のシステムにマウントしてドキュメント保管するユースケースが問題で出ます。
Cloud Storage FUSE などのオブジェクト ストレージと比較すると、このプロダクトはいくつかのファイル システム セマンティクスを提供しますが、Filestore によって提供されるファイル ストレージのより堅牢な特性の一部が欠けています。Cloud Storage FUSE ではなく Filestore でサポートされている機能の例として、次のものがあります。
- POSIX コンプライアンス
- ハードリンクとファイルロック
- 同じオブジェクトへの複数の書き込みに対する同時実行制御がない
Ggenさんのブログが非常にわかりやすい図を書いていたので引用させていただく。
補足しておくと、Google公式によれば
- ブロックストレージ
- Persistent Disk：GCE と GKEクラスタにデプロイされたアプリとDB専用のHDDとSSD
- Google Cloud Hyperdisk：GCEための高速で冗長なネットワークストレージ
- ローカルSSD：高パフォーマンスアプリ用にローカルで接続される一時(エフェメラル)ストレージ
- ファイルストレージ
- Google Cloud Firestore：GCEとGKSクラスタ用のNFSv3 ファイル サーバー。マウント可能。
- Google Cloud NetApp Volumes：NFSv3、NFSv4.1、SMB を使用するファイルベースのストレージ。マウント可能。
- サードパーティのマケプレNAS
- オブジェクトストレージ
- Cloud Storage：Cloud Storage FUSEでマウント可能
らしい。
- Cloud Storage：Cloud Storage FUSEでマウント可能
でもFirestoreをわざわざ選ばせる問題は、POSIX準拠と絡めてくると思われる。
ChatGPT的には、open(), read(), write(), close(), fsync()などのシステムコールをサポートしている必要があるらしい。
Persistent Diskも準拠はもちろんしているが、Persistent Diskは複数台のVMやスケールした環境に1つのPersistent Diskでマウントは制限がつき、読み取り専用となってしまう。複数台にもマウントできるという点で、Firestoreとの選択肢の差別化を行う。なので分散型とかのキーワードではFirestoreのほうが向くことが多い。
Cloud SQL
概要
Cloud SQL は、MySQL、PostgreSQL、SQL Server 用のフルマネージド リレーショナル データベース サービスです。
使用可能なデータベース
- MySQL
- PostgreSQL
- SQL Server
Cloud SQL インスタンス
Cloud SQL インスタンスは 1 つの仮想マシン（VM）に対応します。VM には、データベース インスタンスを稼働するためのデータベース インスタンスと付属のソフトウェア コンテナが含まれています。
データベース インスタンス
データベース インスタンスは、データベースを操作するソフトウェアとファイルのセット（MySQL、PostgreSQL、SQL Server）です。
IPについて
Cloud SQL では、パブリック IP は、インスタンスに公共のインターネット経由でアクセスできることを意味します。逆に、プライベート IP のみを使用するインスタンスに、公共のインターネットからはアクセスできませんが、Virtual Private Cloud（VPC）経由ではアクセスできます。Cloud SQL インスタンスでは、パブリック IP アドレスとプライベート IP アドレスのどちらも使用できます。
高可用性
まず、Cloud SQLはリージョナルサービスです。
そのため、高可用性の問題ではリージョンをまたいだ設定はできないことを覚えておくと、答えやすいかも。
高可用性（HA）を使用する Cloud SQL インスタンスは HA 以外のインスタンスよりも信頼性が高くなります。
HA 構成の目的は、ゾーンまたはインスタンスが利用できなくなったときのダウンタイムの削減です。これは、ゾーンの停止中やハードウェアに問題がある場合に発生する可能性があります。
Cloud SQL の HA は、プライマリ インスタンスとスタンバイ インスタンスの 2 つの同期されたインスタンスによって機能します。各インスタンスには 1 つの VM が存在します。各インスタンスは、同じリージョン内の異なるゾーンにあります。
HA 向けに構成された Cloud SQL インスタンスはリージョン インスタンスとも呼ばれ、構成されたリージョン内にプライマリ ゾーンとセカンダリ ゾーンがあります。
各ゾーンの同期レプリケーションにより、トランザクションが commit されたとしてレポートされる前に、プライマリ インスタンスへの書き込みのすべてが両方のゾーンのディスクに複製されます。インスタンスまたはゾーンに障害が発生した場合、スタンバイ インスタンスが新しいプライマリ インスタンスになります。ユーザーは新しいプライマリ インスタンスに再転送されます。このプロセスは、フェイルオーバーと呼ばれます。
フェイルオーバー
フェイルオーバーは、Cloud SQL が元のプライマリ インスタンスからスタンバイ インスタンスにサービスを切り替えるときのものです。
自動フェイルオーバーとは、Cloud SQL インスタンスで前のインターバルでハートビートを実行しなかった場合にフェイルオーバーを自動的にトリガーするメカニズムです。
フェイルオーバー後は、元のインスタンスが再びオンラインになっても、フェイルオーバーを受信したインスタンスがプライマリ インスタンスのままとなります。
サービスが停止したゾーンまたはインスタンスが再び使用可能になると、元のプライマリ インスタンスは破棄され、再作成されます。
その後、それが新しいスタンバイ インスタンスになります。将来、フェイルオーバーが発生した場合、新しいプライマリは元のゾーン内の元のインスタンスにフェイルオーバーします。
1 つ以上の専用 CPU を持つ Cloud SQL HA 構成のリージョン永続ディスク サポートには、完全なサービスレベル契約（SLA）が適用されます。HA 用に構成されたインスタンスは、スタンドアロン インスタンスの 2 倍の費用がかかります。
高可用性HAのSLA
リードレプリカ
リードレプリカで可用性が問題になる場合は、レプリカで HA を有効にできます。このようなレプリカをプライマリ インスタンスにプロモートさせた場合、そのレプリカは高可用性インスタンスとしてすでに設定されています。
ゾーンでサービスが停止している間、そのゾーンのリードレプリカへのトラフィックは停止します。ゾーンが再び使用可能になると、ゾーン内のリードレプリカはプライマリ インスタンスからレプリケーションを再開します。サービスが停止しているゾーンにリードレプリカがない場合、スタンバイ インスタンスがプライマリ インスタンスになると、リードレプリカはスタンバイ インスタンスに接続します。
ベストプラクティス
ベスト プラクティスとして、リードレプリカの一部をプライマリ インスタンスやスタンバイ インスタンスとは異なるゾーンに置くことを検討してください。たとえば、ゾーン A にプライマリ インスタンスが、ゾーン B にスタンバイ インスタンスがある場合、ゾーン C にリードレプリカを置いて信頼性を向上させます。これにより、プライマリ インスタンスのゾーンがダウンしても、リードレプリカが引き続き稼働します。また、リードレプリカが利用できないときは、プライマリ インスタンスに読み取りを送信するビジネス ロジックをクライアント アプリケーションに追加する必要もあります。
クロスリージョンレプリカ
リージョナルサービスではあるものの、クロスリージョンというデータを別のリージョンにリードレプリカを作成する機能があります。
注意として、この機能はメインリージョンのDBが災害などで損害を受けたときにプロモートして別リージョンにフェイルオーバーできますが、リードレプリカが持つ情報はプライマリにコミットされた直近のトランザクションは持っていないかもしれない点があります。
そのため、クロスリージョンレプリカを昇格するかどうかの判断が必要となることから、プロモートして昇格は手動で行う必要があります。(多分
BigTable
Bigtable は、ML、運用分析、ユーザー向けオペレーション用の低レイテンシ NoSQL データベース サービスです。これは、数十億行や数千列の規模にスケールできるワイドカラム型の Key-Value ストアです。Bigtable を使用すると、世界中のリージョンにデータを複製して、高可用性とデータの復元力を実現できます。
大規模データセットの管理と分析に特化した高性能なソリューションです。
AWSのDynamoDBのようなサービス
KVSなので、キー項目の分布に気をつけなければならない。
例えば、GmailやGoogleマップなどのサービスは、Cloud Bigtableを活用してリアルタイムでデータを処理しています。分析、IoTデータ、ログデータなどの大規模データ処理で使用。
- パフォーマンス
- 高スループット
- 低レイテンシ
- スケーリング
- オート
- 対象規模
- ペタバイト級
- データモデル
- 構造化データ、半構造化データ、非構造化データ
- 高可用性
- あり
キーワードは、「高パフォーマンス」「スケーラビリティ」「大規模データ」
- あり
Firestore
Google Cloudが提供するNoSQLデータベースであり、自動的にスケーリングやレプリケーションを行います。これにより、高可用性と耐久性を実現し、アプリケーションのパフォーマンスを維持します。具体的には、FirestoreはACIDトランザクションをサポートし、データの整合性を確保します。また、SQLライクなクエリ機能を備えており、開発者は直感的にデータを操作できます。さらに、Firestoreは多様なデータ型をサポートしており、アプリケーションのニーズに応じたデータ管理が可能です。
例えば、 モバイルアプリ、ウェブアプリ、リアルタイムデータの同期など。リアルタイム性が必要なときに使用する。
- スケーリング
- オート
- 高可用性
- あり
- 負荷分散
- あり
- ACIDトランザクション
- あり
キーワードは、「高可用性」「ACIDトランザクション」「リアルタイム同期」
- あり
DatastoreとFirestoreの関係性
FirestoreはDatastoreの後継サービスとして設計されています。
- Firestoreの「Datastoreモード」は、Datastoreと互換性があり、Datastoreを利用しているアプリケーションもFirestoreに移行可能。
- Firestoreは、Datastoreの機能をベースにしつつ、リアルタイムデータの同期や新しい機能を追加した進化版。
モード
- Datastoreモード: Datastoreと完全互換性があり、既存のDatastoreアプリケーションをそのまま利用可能。
- ネイティブモード: Firestore独自の新機能（リアルタイム同期、オフラインサポートなど）を使用可能。
検索について
Firestoreでは、非キー項目（フィールド）に基づく検索でも全スキャンにはなりません。
Firestoreは、すべてのフィールドに対してデフォルトで単一フィールドインデックスを作成します。これにより、キー項目でないフィールド（非キー項目）でも効率的に検索できます。
逆に意図的にインデックスがないキーにクエリ実行はできない。
{
"temperature": 25,
"location": "Tokyo"
}
クエリ: SELECT * FROM measurements WHERE temperature > 20
処理の流れ:
- Firestoreはtemperatureフィールドに対して作成されたインデックスを利用。
- Bツリーなどのデータ構造を使って、temperatureが20より大きいデータを効率的に絞り込む。
- 条件に合うデータのみを返す。
BigQuery
BigLake
BigQueryにデータレイクとデータウェアハウスのような分析を付け加えた拡張
BigLake を使用することで、エンドユーザーにファイルレベルのアクセスを許可する必要がなくなります。既存の BigQuery テーブルと同様に、オブジェクトストアテーブルに対して、テーブルや行、列レベルのセキュリティポリシーを適用できます。
簡単に言うと、BigLake は "データを保存する場所や形式に依存しない一貫したデータ管理とアクセス" を実現するためのサービスです。
サポート形式
Avro
CSV
Delta Lake
Iceberg
JSON
ORC
Parquet
サポートされているデータストア
Amazon S3（BigQuery Omni を使用）
Blob Storage（BigQuery Omni を使用）
Cloud Storage
BigLakeの利用イメージ
BigLakeはBigQueryだけでなく、他のサービスとの利用も可能。
BigLakeは単体の「ツール」ではなく、Google Cloudにおける「統一的なデータアクセスフレームワーク」と考えると分かりやすいです。利用には、以下のように他のGoogle Cloudサービスとの連携が基本になります。
利用例1: Cloud Storage + BigLake
Cloud Storage上のParquetファイルにBigLake経由でクエリ。
データをBigQueryに取り込むことなく、直接分析。
利用例2: BigQuery + BigLake
BigLakeを利用して、BigQueryでCloud Storageの外部テーブルを扱う。
異なるストレージに保存されたデータも、BigQueryで一元管理。
利用例3: Dataproc + BigLake
データパイプラインをDataprocで作成し、Cloud StorageのデータをBigLake経由で処理。
BigQuery Omni
BigQuery Omni を使用すると、BigLake テーブルを使用して、Amazon Simple Storage Service（Amazon S3）または Azure Blob Storage に保存されたデータに対して BigQuery 分析を実行できます。
BigQuery ML
BigQuery ML では、GoogleSQL クエリを使用して、ML モデルの作成と実行を行えます。
また、BigQuery MLを通じてVertex AIモデルやCloud AI APIと連携し、生成モデルや予測モデルを利用可能です。テキスト生成や機械翻訳などの AI タスクを実行できます。
BigQuery ML では、次のものを使用できます。
- Google Cloud Console
- bq コマンドライン ツール
- BigQuery REST API
- Jupyter ノートブックやビジネス インテリジェンス プラットフォームなどの外部ツール
Vertex AI
ML モデルと AI アプリケーションのトレーニングとデプロイを行い、AI を活用したアプリケーションで使用する大規模言語モデル（LLM）をカスタマイズできる機械学習（ML）プラットフォームです。
かつてはCloud Datalabが使われていたが、非推奨となりVertex AI Notebooksが推奨されている。
ワークフローを統合している。CICDのようにイテレーションを行える。
Vertex AI には、モデルのトレーニングとデプロイのオプションが複数用意されています。
- AutoML
- コードの記述やデータ分割の準備を行わずに、表形式、画像、テキスト、動画のデータをトレーニングできます。
- カスタムトレーニング
- 任意の ML フレームワークの使用、独自のトレーニング コードの記述、ハイパーパラメータ チューニング オプションの選択など、トレーニング プロセスを完全に制御できます。
- Model Garden
- Vertex AI と厳選されたオープンソース（OSS）モデルとアセットを調査、テスト、カスタマイズ、デプロイできます。
- 生成 AI
- 複数のモダリティ（テキスト、コード、画像、音声）を対象とした Google の大規模な生成 AI モデルを利用できます。
Vertex AI Vizier
複雑な機械学習（ML）モデルでのハイパーパラメータのチューニングを支援するブラックボックス最適化サービスです。
Vertex AI Experiments
Vertex AI Experiments は、さまざまなモデル アーキテクチャ、ハイパーパラメータ、トレーニング環境を追跡および分析し、テストの実行の手順、入力、出力を追跡する際に役立つツールです。Vertex AI Experiments では、テスト データセットに対して、トレーニングの実行中に、モデルの集計のパフォーマンスを評価することもできます。この情報を使用して、特定のユースケースに最適なモデルを選択できます。
Vertex AI Model Registry
Vertex AI Model Registry は、ML モデルのライフサイクルを管理できる中央リポジトリです。Model Registry ではモデルの概要を確認できるため、新しいバージョンの整理、追跡、トレーニングの向上が実現します。
TensorFlow
TensorFlowとは、Googleが開発しオープンソースで公開している、機械学習に用いるためのソフトウェアライブラリである。Google Cloud専用の製品ではなく、あくまでOSS。k8sと同じ感じ。
Kubernates Engine
Cron
Kubernates EngineにはCronの仕組みがネイティブでは提供されていない。
ただし、KubernatesとしてCronJob の機能がある。
kubectlで管理できるリソースとして、ジョブを定期的に作成して実行します。
ユーザーはyamlを記述して設定することができる。
ただ、管理をGoogleに丸投げはできないのでGoogleCloudにおいては定期実行系は他の手段を選んだ方が良い。例えば、Cloud SchedulerからAPIエンドポイントを叩くとか、Pub/Subを挟むとか、App Engine Cron Serviceとか。
ページ下部に羅列する。
利点
柔軟性: コンテナベースのタスクをGKE上で実行可能。
スケーラビリティ: Kubernetesクラスタ内でタスクをスケジュールでき、分散環境での処理に対応。
制限
クラスタ依存: CronJobはGKEクラスタ内で実行されるため、クラスタ障害やリソース不足の影響を受ける。
運用コスト: Kubernetesクラスタの管理と、CronJobの設定・保守が必要。
高度な管理が必要: ジョブの状態監視、失敗時のリトライ、リソース管理を自前で行う必要がある。
調査関連
Cloud Operations for GKE
Google Kubernetes Engineには
- Cloud Logging デフォルト有効
- Cloud Monitoring デフォルト有効
- Cloud Managed Service for Prometheus
との インテグレーションが含まれています。
「Cloud Operations for GKE」は、Google Kubernetes Engine（GKE）クラスタとその上で稼働するワークロードの監視と管理を支援する、Google Cloudの一連のサービスを指します。これは特定のサービス名ではなく、複数の機能を総合的に組み合わせたものです。
補足：Prometheus
Prometheus でできること
監視の機能としてはあんまり目新しいものはないですが、監視対象が動的に変更されるようなスケーラブルな環境のリソース監視を意識した設計になっています
- 監視対象のサーバーから情報を取得 & 保管
- 保管済みデータに対して集計クエリを発行できる
- しきい値を超えた場合のアラート (メール、Slack、がんばればTwilioで電話)
- 柔軟なアラート設定 (同じエラーはまとめて通知とかの設定ができる)
|名称|説明|
| --- | --- |
|exporter|監視対象サーバー上で動かすプログラム
テキスト形式でリソース情報を公開するWeb API のようなもの
監視対象のリソース毎に exporter が用意されている
|
|prometheus|監視サーバーのプログラム
定期的に全ての exporter をポーリングしてリソース情報を収集する
監視したデータは prometheus 内の DB に保持される|
セキュリティ
検証済みのコンテナのみデプロイする方法
Web Security Scanner
ワークロードをデプロイする前に、脆弱性スキャンを使用して脆弱性がないことを確認するようにContainer Registryを構成。デプロイの安全性と一貫性を確保するためには、コンテナ分析でイメージの脆弱性を自動的にスキャンすることが有効です。
Web Security Scanner は、App Engine、Google Kubernetes Engine（GKE）、Compute Engine の各ウェブ アプリケーションにおけるセキュリティの脆弱性を特定します。アプリケーションをクロールして、開始 URL の範囲内にあるすべてのリンクをたどり、できる限り多くのユーザー入力とイベント ハンドラの処理を試みます。現在、Web Security Scanner は、ファイアウォールの背後にない、公開 URL と IP のみをサポートしています。
対象サービス
- App Engine スタンダード環境
- App Engine フレキシブル環境
- Compute Engine インスタンス
- GKE リソース
Binary Authorization
GKEでBinary Authorizationを有効にし、CI/CDパイプラインの一部としてコンテナに署名する。バイナリ認証機能を利用することで、検証済みのコンテナのみをデプロイすることができます。
Binary Authorization は、コンテナベースのアプリケーションを開発してデプロイするときに、ソフトウェア サプライ チェーンのセキュリティ対策を実装するために使用できる Google Cloud プロダクトです。
機能
- モニタリング
- チェックベースのプラットフォーム ポリシーを使用した継続的検証（CV）（プレビュー）を構成すると、実行中の Pod に関連付けられたコンテナ イメージが、管理者が作成したポリシーを遵守しているかどうかを定期的にモニタリングできます。イメージがポリシーを遵守していない場合、CV は Cloud Logging にログエントリを生成します。
- 適用
- Binary Authorization の適用を構成して、サポートされているコンテナベースのプラットフォームに、定義したポリシーを遵守しているイメージがデプロイされるようにします。ポリシーを遵守するイメージのデプロイは許可され、それ以外のイメージはデプロイが拒否されます。
対象サービス
- Google Kubernetes Engine（GKE）: Google Cloud でホストされているクラスタでイメージを実行します。
- Cloud Run: フルマネージドのサーバーレス プラットフォーム上で、コンテナ化されたアプリケーションを実行します。
- Cloud Service Mesh（プレビュー）: オンプレミスまたは Google Cloud で信頼性の高いサービス メッシュを管理します。
- Google Distributed Cloud ソフトウェア: 自前のハードウェアでホストする GKE クラスタでイメージを実行します。
関連
Binary Authorization は、次の関連プロダクトを含むデプロイ アーキテクチャの一部です。
- Artifact Registry、Container Registry、デプロイするイメージを格納するその他のレジストリ。
- Artifact Analysis。デプロイを制御するために Binary Authorization で使用できる脆弱性情報を提供します。これとは別に、Artifact Analysis は、認証プロセスで使用される、信頼できるメタデータを保存します。
- セキュリティ モニタリング。Binary Authorization など、相互に関連する Google Cloud プロダクト全体のアプリケーションのセキュリティ ポスチャーを評価できるダッシュボード。
- Cloud Build。Binary Authorization が適用とモニタリングに使用できる証明書と来歴を生成します。
- Cloud Deploy は継続的デリバリーを実現するマネージド サービスで、定義した順序で、一連のターゲット環境へのアプリケーションの配信を自動化します。
Binary Authorization は、Grafeas オープンソース プロジェクトの一部である Kritis 仕様に基づいています。
Anthos
Anthos（アントス）は、Google Cloud Platform（GCP）が提供するアプリケーションの管理プラットフォームです。ハイブリッドクラウドやマルチクラウド環境で、アプリケーションの開発や運用を効率的に行うことを目的としています。
Anthosの主な機能には、次のようなものがあります。
- マネージドな Kubernetes クラスタの提供
- サーバーレス、セキュリティ管理、ハイブリッド負荷分散などの機能
- さまざまな環境の Kubernetes クラスタに対して、一元的にポリシー管理を行う機能
- マイクロサービスごとにプロキシを配置することで、可視性やセキュリティの課題、トラフィックコントロールの問題を解決する機能
サービスメッシュの文脈でよく見かける。
サービスメッシュは、アプリケーションから通信を分離してインフラストラクチャ層で管理できるようにしたアーキテクチャ。https://dev.classmethod.jp/articles/servicemesh/
Anthos Config Management
- 目的: Anthos Config Management (ACM) は、Kubernetesクラスタ全体でポリシーや構成を一貫して管理するためのツールです。
- クラスター内のリソースの状態を一元管理。
- リポジトリに保存されたYAMLファイルを通じて、クラスタの構成を宣言型で適用。
※ただし、ACMはSLOやアラートポリシーの直接的な管理には適しません。
Anthos Service Mesh
- 目的: Anthos Service Mesh (ASM) は、サービス間通信を管理するためのサービスメッシュ技術です。これにより、分散システムでのトラフィック管理、セキュリティ、可観測性を提供します。
- SLO (Service Level Objective) の作成やトラフィックの可視化、トレースなどが可能。
- アラートポリシーも、これらのSLOに基づいて定義できます。
Istio
Istio は、統一された方法でマイクロサービスの接続、管理、保護を実現するオープン サービス メッシュです。
マイクロサービス コードを変更することなく、サービス間のトラフィックフローの管理、アクセス ポリシーの適用、テレメトリー データの集計を行うことができます。
Anthos Service Meshは内部でIstioAPIを使用している。(多分)
サービス間のトラフィックも扱うため、例えば遅延障害や中断フォールトを故意に発生させて障害復旧テストなども実施できます。
Compute Engine
ストレージオプション
- Persistent Disk: 高パフォーマンスで冗長性のあるネットワーク ストレージ。各ボリュームは、何百もの物理ディスクにストライプ化されています。デフォルトでは、VM はゾーン Persistent Disk を使用。リージョン Persistent Disk ボリュームを作成すると、2 つのゾーンにあるディスク間でデータを同期的にレプリケートし、ゾーンが利用不能になった場合でもデータを使用できるようにします。
- Hyperdisk: Compute Engine 用の最速の冗長ネットワーク ストレージ。パフォーマンスとボリュームを構成可能で、動的にサイズを変更できます。各ボリュームは、何百もの物理ディスクにストライプ化されています。Hyperdisk ストレージ プールを使用して容量とパフォーマンスを事前に購入することで、コストとディスク管理の複雑さを軽減することもできます。Hyperdisk ストレージ プールでは、プールに作成されたディスク間で共有できる容量とパフォーマンスの合計量が提供されます。
- ローカル SSD: コンピューティング インスタンスと同じサーバーに直接接続される物理ドライブ。パフォーマンスは向上しますが、耐久性はありません。インスタンスがシャットダウンされると、ローカル SSD ディスクが削除されます。
インスタンスグループ
これはE.G.Gである程度やったので簡易的にだけ。
Compute Engine には、マネージドと非マネージドの 2 種類の VM インスタンス グループがあります。
- マネージド インスタンス グループ（MIG）では、複数の同一 VM でのアプリケーション操作が可能です。自動スケーリング、自動修復、リージョン（マルチゾーン）デプロイメント、自動更新などの自動化 MIG サービスを活用することで、スケーラブルで可用性に優れたワークロード処理を実現します。インスタンステンプレートを使う。
- 自動で障害が発生したVMを停止し切り替えてくれる
- ヘルスチェックもある
- リージョンMIG(<>ゾーンMIG)によりゾーンで負荷分散＆ゾーン障害の回避
- MIG内インスタンスで負荷分散
- 自動スケーリング
- CPU 使用率、負荷分散能力、Cloud Monitoring の指標、スケジュールに基づいてグループをスケーリングできます。ゾーン MIG の場合は、キューベースのワークロード（Pub/Sub など）を使用します。
- LB
- Google Cloud Load Balancing では、インスタンス グループを使用してトラフィックを処理します。このインスタンス グループは、選択したロードバランサのタイプに応じてターゲット プールやバックエンド サービスに追加できます。
- ネットワークとサブネット
- インスタンス テンプレートで、メンバー インスタンスで使用する VPC ネットワークとサブネットを定義
- 非マネージド インスタンス グループでは、ユーザー自身が管理する一連の VM 間での負荷分散が可能です。自動スケーリング、自動修復、マルチゾーン サポート、ローリング アップデート、インスタンス テンプレートを利用できない。非マネージド インスタンス グループが適しているのは、異種のインスタンスのグループをロードバランスする場合や、ユーザー自身でインスタンスを管理する必要がある場合。
マシンタイプ
事前定義されたマシンタイプ
highcpu - vCPU あたり 1～3 GB のメモリ（通常は vCPU あたり 2 GB のメモリ）
standard - vCPU あたり 3～7 GB のメモリ（通常は vCPU あたり 4 GB のメモリ）
highmem - vCPU あたり 7～14 GB のメモリ（通常は vCPU あたり 8 GB のメモリ）
megamem - vCPU あたり 14～19 GB のメモリ
hypermem - vCPU あたり 19～24 GB のメモリ（通常は vCPU あたり 21 GB のメモリ）
ultramem - vCPU あたり 24～31 GB のメモリ
c3-standard-22 → 88Gのメモリ
シリーズ-マシンタイプ-個数
カスタムマシンタイプ
事前定義されたマシンタイプがワークロードのニーズに合わない場合は、汎用マシン ファミリーの N マシンシリーズと E マシンシリーズのカスタム マシンタイプを使用して VM インスタンスを作成できます。
カスタム マシンタイプの使用にかかる費用は、同等の事前定義されたマシンタイプと比較して若干高くなります。また、カスタム マシンタイプで選択できるメモリ量と vCPU 数には上限があります。カスタム マシンタイプのオンデマンド料金には、事前定義されたマシンタイプのオンデマンド料金とコミットメント料金に対して 5% のプレミアムが含まれています。
拡張メモリ（カスタム マシンタイプでのみ使用可能）を使用すると、vCPU ベースの制限を受けることなく、カスタム マシンタイプのメモリ容量を指定できます。指定された vCPU の数に基づくデフォルトのメモリサイズを使用するのではなく、マシンシリーズの上限まで拡張メモリを指定できます。
共有コア マシンタイプ
E2 シリーズと N1 シリーズには、共有コア マシンタイプが含まれています。このようなマシンタイプでは物理的なコアを時分割で使用します。この方法は、小規模でリソース消費量がそれほど多くないアプリを実行する場合に費用対効果に優れていることがあります。
- E2: 短時間のバースト用に 2 個の vCPU を提供します。
- N1: 短時間のバーストに使用できる最大 1 個の vCPU を備えた f1-micro と g1-small の共有コア マシンタイプを提供します。
プリエンプティブルVM
Compute Engine は、24 時間実行した後で、必ずプリエンプティブル インスタンスを停止します。この 24 時間カウンタは、特定のアクション↓によってリセットされます。
インスタンスを停止して開始すると、インスタンスが TERMINATED 状態に移行するため、Compute Engine がカウンタをリセットします。ただし、インスタンスのリセットや、VM からの sudo reboot の実行など、インスタンスが RUNNING 状態で保持される他のアクションでは、カウンタはリセットされません。
ネットワーキング
すべての VM は VPC ネットワークの一部であり、VPC ネットワークでは、VM インスタンスから他の Google Cloud プロダクトへの接続とインターネット接続が利用できます。VPC ネットワークは自動モードまたはカスタムモードにできます。
自動モード(defaultネットワーク)
リージョンごとに 1 つのサブネットワーク（サブネット）
すべてのサブネットに 10.128.0.0/9 の IP アドレス範囲に含まれています。
自動モードのネットワークでは IPv4 サブネット範囲のみがサポートされます。
カスタムモード
サブネット構成がありません。
指定した IPv4 範囲を使用して、選択したリージョンで作成するサブネットを決定します。
カスタムモードのネットワークでは IPv6 サブネット範囲もサポートされます。
ネットワーク インターフェース コントローラ（NIC）
VPC ネットワーク内のすべてのインスタンスには、デフォルトのネットワーク インターフェースがあります。VM に接続するネットワーク インターフェースを追加できますが、各インターフェースはそれぞれ異なる VPC ネットワークに接続する必要があります。複数のネットワーク インターフェースを使用することで、1 つのインスタンスが複数の VPC ネットワークに直接接続する構成を作成できます。
IPアドレス
各 VM インターフェースにはサブネットから割り振られる内部 IPv4 アドレスがあります。必要に応じて外部 IPv4 アドレスを構成できます。
内部 IP アドレスは、次のいずれかに対してローカル アドレスになります。
- VPC ネットワーク
- VPC ネットワーク ピアリングを使用して接続された VPC ネットワーク
- Cloud VPN、Cloud Interconnect、またはルーター アプライアンスを使用して VPC ネットワークに接続されたオンプレミス ネットワーク
外部IPアドレスは普通CloudNATで設定し、インスタンス自体に持たせることは実運用上あまりないと思う。
内部ドメイン ネーム システム（DNS）名
仮想マシン（VM）インスタンスを作成すると、Google Cloud では VM 名から内部 DNS 名を作成します。カスタムホスト名を指定しない限り、Google Cloud は自動的に作成された内部 DNS 名を VM に提供するホスト名として使用します。
同じ VPC ネットワークでの VM 間の通信の場合、内部 IP アドレスを使用する代わりに、ターゲット インスタンスの完全修飾 DNS 名（FQDN）を指定できます。この FQDN はインスタンスの内部 IP アドレスに自動的に解決されます。
ロール
かつてはアクセススコープという古い方法がありました。
これはOAuthにおけるスコープです。
一方今はサービスアカウントなどIAMのロールで制御することが望ましいので、アクセススコープが出てきたら非推奨とは公式はいってませんがまあ正解ではないでしょう。
Google Cloud Observability
Google Cloud Observabilityは、Google Cloudが提供する一連のサービスで、アプリケーションやシステムの動作、健全性、パフォーマンスを深く理解するためのものです。これにより、複雑なクラウド環境における問題の検出、診断、解決が容易になります。
Observability（可観測性）は、システムの内部状態を外部から観測可能なデータ（ログ、メトリクス、トレースなど）を通じて把握する能力を指します。これにより、システム内で発生する問題の原因を迅速に特定し、対応することが可能となります。
NEW RELIC
Google Cloud Observabilityは、以下の主要なサービスで構成されています：
- Cloud Monitoring: システムやアプリケーションのメトリクスを収集・可視化し、アラートを設定することで、リアルタイムの監視を実現します。
- Cloud Logging: アプリケーションやシステムからのログデータを集約・分析し、問題のトラブルシューティングを支援します。
- Cloud Trace: 分散トレーシングを行い、リクエストの遅延やボトルネックを特定することで、パフォーマンスの最適化をサポートします。
- Cloud Profiler: アプリケーションのリソース使用状況をプロファイリングし、最適化のポイントを明らかにします。
- Cloud Debugger: 本番環境で稼働中のアプリケーションの状態をリアルタイムで検査し、デバッグを行います。
OpenTelemetryも使える。
OpenTelemetryとは分散トレーシングやメトリクスなどのオブザーバビリティデータを収集、処理、エクスポートするためのオープンソースプロジェクト。
Cloud Monitoring
指標の収集
VM からの指標
一部のシステム指標は、Compute Engine インスタンスから自動的に取得されます。ただし、自動的に収集される Compute Engine の指標で、サービスのモニタリングに必要なすべての情報が提供されるとは限りません。
Compute Engine インスタンスから追加のシステム指標を収集するには、エージェントをインストールします。たとえば、Ops エージェントの指標には、CPU、ディスク、メモリ、スワップの指標が含まれます。これらの指標やその他の指標は、Linux や Windows の VM から収集できます。
統合からの指標
Cloud Monitoring は、Compute Engine と Google Kubernetes Engine で実行しているデプロイメント向けに、Apache ウェブサーバー、MySQL、Redis などのアプリケーションからテレメトリーを収集できる統合を提供します。
-
Compute Engine を使用する場合、サードパーティのテレメトリーは Ops エージェントによって収集されます。
-
GKE を使用する場合、サードパーティのテレメトリーは Google Cloud Managed Service for Prometheus によって収集されます。
アラート
- アラート ポリシー、アラートを受け取る状況とインシデントの通知方法を記述します。アラート ポリシーでは、Monitoring によって保存された時系列データまたは Cloud Logging によって保存されたログをモニタリングできます。そのデータがアラート ポリシーの条件を満たす場合、Monitoring はインシデントを作成し、通知を送信します。
- 通知チャネルは、Monitoring によってインシデントが作成されたときに通知を受け取る方法を定義します。たとえば、通知チャネルを構成して、my-support-team@example.com にメールを送信し、チャネル #my-support-team に Slack メッセージを投稿できます。アラート ポリシーには、1 つ以上の通知チャネルを含めることができます。
アラート ポリシーでは、次の 2 種類のデータを評価できます。
- 時系列データ（指標データとも呼ばれる）。Monitoring によって保存されます。これらのタイプのポリシーは、指標ベースのアラート ポリシーと呼ばれます。
- Cloud Logging によって保存されたログデータ。これらのタイプのポリシーは、ログベースのアラート ポリシーと呼ばれます。 ログベースのアラート ポリシーは、ログに特定のメッセージが表示されるときに通知します。
カスタムダッシュボード
一時的なグループと一時フィルタを追加して、各ウィジェットを変更することなく、カスタム ダッシュボードに表示するデータを変更する方法
カスタムダッシュボードは、Cloud Monitoring内で提供される、メトリクスを視覚化するためのインターフェース（UI）です。
ユーザーが自由にメトリクスやグラフの表示内容、形式、レイアウトを設計できます。
カスタムメトリクス
カスタムメトリクスは、Google Cloudの標準メトリクス（CPU使用率、ネットワークトラフィックなど）に含まれない、ユーザー独自のメトリクスです。
アプリケーションやシステムから直接送信されたデータを、Cloud Monitoringで追跡・分析するために作成します。
ログベースのメトリクスを生成し、アラートポリシーの条件として活用することも可能です。
アラートとの関係
- アラートポリシーとメトリクスの関係
アラートポリシーは、特定の条件が満たされたときに通知をトリガーする仕組みです。
条件を設定する際の基準（指標）はメトリクスに基づいて決定します。
つまり、アラートポリシーのトリガーは、何らかのメトリクス（標準メトリクスまたはカスタムメトリクス）を参照して設定されます。アラートポリシーは、メトリクスを監視し、異常な状態を検知するための仕組みであり、メトリクスがアラートポリシーのトリガーとなる、ということです。 - アラートポリシーとダッシュボードの関係
特に直接の関係はありません。
ダッシュボードはメトリクスで収集されたデータを可視化するためのものです。
Cloud logging
Cloud Audit Logs
Google Cloud サービスでは、管理アクティビティと Google Cloud リソース内のアクセスを記録する監査ログを書き込みます。監査ログは、Google Cloud リソース内でオンプレミス環境と同じレベルの透明性を確保しながら「いつ誰がどこで何をしたか」という問いに答えるために役立ちます。監査ログを有効にすると、セキュリティ、監査、コンプライアンス エンティティが Google Cloud のデータとシステムをモニタリングして、脆弱性や外部データの不正使用の可能性を確認できます。
監査ログを書き込む Google Cloud サービスの一覧については、監査ログ付きの Google サービスをご覧ください。最終的には、すべての Google Cloud サービスが監査ログを提供するようになります。
基本あるものと思って良さそう。以下はよく使いそうな例
- BigQueryのクエリログデータ
必要な権限
見るだけ
- ログ閲覧者（roles/logging.viewer
- このロールだけでは_Default バケット内のデータアクセス監査ログを閲覧することはできません
- プライベート ログ閲覧者（roles/logging.privateLogViewer）
- _Required バケットと _Default バケットのすべてのログへのアクセス権
監査ログのタイプ
データアクセス監査ログ（BigQuery 用を除く）は、デフォルトで無効になっています。Google Cloud サービスにデータアクセス監査ログを書き込むには、明示的に有効にする必要があります。詳細については、このページのデータアクセス監査ログを構成するをご覧ください。
- 管理アクティビティ監査ログ
- リソースの構成またはメタデータを変更する API 呼び出しやその他の管理アクションに関するログエントリが含まれます。これらのログは、たとえば、ユーザーが VM インスタンスを作成したときや Identity and Access Management 権限を変更したときに記録されます。
- 管理アクティビティ監査ログは常に書き込まれます。構成する、除外する、または無効にすることはできません。
- データアクセス監査ログ
- リソースの構成やメタデータを読み取る API 呼び出しや、ユーザー提供のリソースデータの作成、変更、読み取りを行うユーザー主導の API 呼び出しが含まれます。
- 監査ログはデータサイズが非常に大きくなる可能性があるため、BigQuery データアクセス監査ログを除き、データアクセス監査ログはデフォルトで無効になっています。
- システム イベント監査ログ
- リソースの構成を変更する Google Cloud アクションのログエントリが含まれます。システム イベント監査ログは、直接的なユーザーのアクションによってではなく、Google システムによって有効化されます。
- システム イベント監査ログは常に書き込まれます。構成したり、除外したり、無効にしたりすることはできません。
- ポリシー拒否監査ログ
- セキュリティ ポリシー違反が原因で、Google Cloud サービスがユーザーやサービス アカウントへのアクセスを拒否した場合は、ポリシー拒否監査ログが記録されます。
- ポリシー拒否監査ログはデフォルトで生成され、Google Cloud プロジェクトにはログ ストレージの料金が発生します。ポリシー拒否監査ログを無効にすることはできませんが、除外フィルタを使用して、ポリシー拒否監査ログの Cloud Logging への保存を防ぐことができます。
機密データの保護
機密データの保護は、Google Cloud の内部と外部の機密データを検出、分類、匿名化するのに役立ちます。このページでは、機密データの保護を構成するサービスについて説明します。
機密データの検査方法
- Cloud Data Loss Prevention（DLP API）を使用して、検査またはハイブリッド ジョブを作成
- content.inspect リクエストを DLP API に送信
Jobによる検査
検査とハイブリッド ジョブは、Google Cloud コンソールまたは Cloud Data Loss Prevention API を使用して構成できます。検査とハイブリッド ジョブの結果は Google Cloud に保存されます。
- 検査ジョブ
- 機密データの保護は、一部の Google Cloud プロダクトのサポートが組み込まれています。
- BigQuery テーブル
- Cloud Storage バケットまたはフォルダ
- Datastore
- ハイブリッド ジョブ
- ハイブリッド ジョブを使用すると、任意のソースから送信されたデータのペイロードをスキャンし、検査の検出結果を Google Cloud に保存できます。
- ハイブリッドジョブは、DLP API のジョブベースの検査機能と、リアルタイムでスキャンするcontent.inspectリクエストの特性を組み合わせたものです。
大量データ向け。
content.inspect リクエストによる検査
DLP API の content.inspect メソッドを使用すると、DLP API にデータを直接送信して検査できます。レスポンスには検査の検出結果が含まれます。同期オペレーションが必要な場合、または検出結果を Google Cloud に保存しない場合は、この方法を使用します。
少量のデータを検査するのに使えます。
その他のサービスのデータ
例えばCloud Loggingなどであれば、直接DLPは使えない。
そのため、Cloud Storageへエクスポートしたり、Pub/Subでcontent.inspectしたりになる。
Cloud Dataprep
データを分析や機械学習、その他の処理に適した形に整えるサービス。ETL的な。
- ポイント1: GUIベースのデータ準備ツール
プログラミング不要でデータのプロファイリング、クリーニング、変換が可能。
データ処理のワークフローを視覚的に構築できます。 - ポイント2: 大規模データの処理にも対応
BigQueryやCloud Storageと連携し、ペタバイト規模のデータを処理可能。
Dataprepは、プログラミング不要でデータ整形に特化しており、データ準備やクリーニングに最適
データのスケーラビリティに優れています。 - ポイント3: インテリジェントな提案機能
データのパターンを自動的に認識し、クリーニングや変換方法を提案します。 - ポイント4: トランスフォーメーションをコード化
データの変更操作はWrangle（トランスフォーメーション）スクリプトとして保存され、再利用可能。
他のサービスとの違い
Cloud DataprepとDataproc
- Cloud Dataprep:
GUIベースで簡単にデータを整形・変換。
プログラミング不要、非技術者でも操作可能。
主にデータ前処理（ETLの「T」）に特化。 - Dataproc:
HadoopやSparkベースのクラスターで大規模データを処理。
プログラミングやスクリプトによる高度な処理が可能。
データ分析や機械学習モデルのトレーニングなど、より広範な処理をカバー。
メリットと制約
- メリット
非技術者でも簡単にデータを準備可能。
インタラクティブなインターフェースで操作が直感的。
大規模なデータにも対応可能で、Google Cloudの他のサービスとシームレスに統合。 - 制約
非技術者向けの設計が中心のため、高度なカスタマイズや複雑な処理には不向き。
処理スピードはDataflowやDataprocに比べて劣る場合がある。
コストが発生するため、頻繁な利用や大量データには注意が必要。
オンプレには接続できないので、一旦Cloud Storageに上げる必要あり。
Cloud Shell
-
Ephemeral VM（短命の仮想マシン）:
Cloud Shellセッションは短命のVM上で実行されます。
このVMはセッション終了後に破棄されるため、ローカルに保存された一時的なファイルは消えます。 -
持続するファイルの保存場所:
Cloud Shellには**5GBの持続性ストレージ（ホームディレクトリ ~）**が割り当てられています。
このストレージに保存されたファイルは、セッションを超えて保持されます。 -
デフォルトの実行パス ~/bin:
~/bin はホームディレクトリ内の持続性ストレージに属します。
このディレクトリは、Cloud ShellのデフォルトPATHに含まれているため、インストールしたユーティリティがすぐに使用可能です。
Terraform
本筋ではないけど使ったことはないので記載。
Terraformは、IaCを実現するツールです。
Terraformはオープンソースであり、HashiCorpによってGo言語で開発されました。
具体的にはTerraformではインフラの構成をコードで宣言します。構造化された構成ファイルでは、手動で操作することなくインフラ構成を自動で管理できます。インフラの初期プロビジョニング、更新、破棄、いずれもTerraformではコードにより宣言し、実行します。
Puppet
PuppetはUnix系やMicrosoft Windowsの設定を管理するようデザインされている。ユーザーはシステムリソース及び状態をパペットによる表現もしくはRubyのDSLで表現する。この情報は"Puppet manifests"と呼ばれるファイルに保存される。
サービスに関連しない話
料金の話
継続利用割引
請求月の 4 分の 1 を超えて該当するリソースを使用すると、そのリソースの継続使用に対して 1 時間ごとに自動的に割引が適用されます。割引率は使用量に応じて徐々に高くなります。1 か月間連続稼働している仮想マシン（VM）インスタンスでは、リソース料金に実質最大 30% の割引が適用されます。
確約利用割引(CUD)
確約利用契約（コミットメントとも呼ばれる）を購入することで、CUD が提供されます。コミットメントを購入すると、指定された契約期間（1 年間または 3 年間）の最小リソース使用量または最小利用額について確約することになります。
Compute Engine の場合、1 年間または 3 年間のご利用を確約していただくことで、VM インスタンスの料金が大幅に割引されます。
Cron系サービス一覧
1. App Engine Cron Service
- 概要
App Engineが提供する完全マネージドなCronサービス。
定期的にHTTPリクエストを特定のURLに送信する。 - マネージドレベル: 完全マネージド。
- スケジュール指定: cron.yamlファイルで指定（cron形式または自然言語形式）。
- トリガー方法: HTTPリクエスト（HTTPS推奨）。
- 実行頻度: 最短1分間隔。
- コスト: App Engine無料利用枠の対象。
2. Cloud Scheduler
- 概要
Google Cloudが提供する汎用的なスケジュールサービスで、幅広いトリガー方法に対応。
主な特徴 - マネージドレベル: 完全マネージド。
- スケジュール指定: cron形式。
- トリガー方法:
HTTP/HTTPSリクエスト（任意のエンドポイント）。
Cloud Pub/Subメッセージの発行。
Cloud Tasksキューのタスク作成。
※Pub/Sub以外のトリガーは追加のサービスが必要（例: HTTPリクエスト用のCloud Functions）。 - 認証: サービスアカウントを使用して認証付きリクエストが可能。
- 実行頻度: 最短1分間隔。
- コスト: 低コスト。月3500ジョブまで無料。
3. Kubernetes CronJob
- 概要
Kubernetesでスケジュールされたタスクを実行するためのリソース。
GKE（Google Kubernetes Engine）で動作。
主な特徴 - マネージドレベル: 部分マネージド（GKEのクラスタ管理が必要）。
- スケジュール指定: cron形式。
- トリガー方法: Kubernetes内でジョブを実行（Podとして動作）。
- 柔軟性: 任意のコンテナイメージを実行可能。
- 実行頻度: 最短1分間隔（高頻度ジョブにはスクリプトの工夫が必要）。
- コスト: GKEクラスタのコストが発生。
戦略
指数バックオフ
An exponential backoff algorithm is a form of closed-loop control system that reduces the rate of a controlled process in response to adverse events. For example, if a smartphone app fails to connect to its server, it might try again 1 second later, then if it fails again, 2 seconds later, then 4, etc. Each time the pause is multiplied by a fixed amount (in this case 2). In this case, the adverse event is failing to connect to the server. Other examples of adverse events include collisions of network traffic, an error response from a service, or an explicit request to reduce the rate (i.e. back off).
雑訳すると、
指数バックオフアルゴリズムとは、閉ループ制御システムの一種であり、発生した問題（好ましくないイベント）に応じて制御プロセスの速度を減少させるものです。例えば、スマートフォンのアプリがサーバーへの接続に失敗した場合、1秒後に再接続を試み、それでも失敗した場合は2秒後、さらに失敗すれば4秒後、といった具合に試行の間隔を徐々に広げます。この場合、待機時間は一定の比率（この例では2倍）で増加します。このケースにおける「好ましくないイベント」とは、サーバーへの接続失敗を指します。
つまり、再試行の間隔を伸ばしながら再試行をする仕組み
API Versioning
Google API はバージョニング スキームを使用して、互換性を破る変更を防止します。さらに、Google API は、アルファ コンポーネントやベータ コンポーネントなど、特定の安定性レベルでのみ利用可能な一部の機能を提供します。
すべての Google API インターフェースは、メジャー バージョン番号（protobuf パッケージの最後にエンコードされ、REST API の URI パスの最初の部分として含まれます）を提供する必要があります。
API でフィールドの削除や名前変更など、互換性のない変更が行われた場合は、既存のユーザーコードが突然破損しないように、API のバージョン番号を増やす必要があります。
カットオーバー
システムや業務、制度などの改革・変更において、古い方法の適用を終えて新しい方法を（一斉に）使い始めること。または、その切り替え時期をいう。
あるタイミングでバツンとその機能の提供を切って、一斉に新しいバージョンを開始する感じ。
Blue/Green deployment
現状の本番環境（ブルー）とは別に新しい本番環境（グリーン）を構築した上で、ロードバランサーの接続先を切り替えるなどして新しい本番環境をリリースする運用方法のこと。
現状の本番環境を変更しないのがミソだ。現状の本番環境は、新しい本番環境に切り替えて正常に動作することを確認した上で破棄する。
よく出てくるのは、Kubernatesのデプロイとセット出てくる。
ローリングアップデート
ローリングアップデートでは、Podインスタンスを新しいインスタンスで段階的にアップデートすることで、ダウンタイムなしでDeploymentをアップデートできます。
少しずつ新しいインスタンスに切り替えていくこと。
これもKubernatesとセットが多い。
カナリアリリース
新しいバージョンのソフトウェアを提供するにあたって一部のユーザーに先にリリースする手法です。 一部のユーザーに先にリリースし、新しいバージョンの機能が問題を起こさないかを最小限の影響で確認できます。
テスト自体の演習
Udemy
悪いとまでは言わないが、解答が古かったり誤った説明がたまにある。
なぜほかが不正解かの記載もないことが多い。
ExamTopics
ちょっとページ遷移ごとの認証が面倒だが割とよい。英語の勉強も兼ねて。
他の人の最も選んだ解答が解答として表示される。
解答について議論する場が問題ごとにあるため、古い解答は淘汰される自浄作用がきいてそう。
Discussion