はじめに

GCPのProfessional Cloud Architectに合格したので記録します。

やったこと

知っておくこと

ベストプラクティス

エンタープライズ企業のベストプラクティスを読んでおく
- https://cloud.google.com/docs/enterprise/best-practices-for-enterprise-organizations
アプリケーションホスティング
- コンテンツ配信のためにアプリをGoogle App Engineに移植する。
- トラブルシューティングのための監視機能を追加する
- CI/CDワークフローを使用して、安定したアプリケーションのためのテストと継続的な配信を行う。
Dockerセキュリティ
- 特権付きコンテナを実行していないこと
  - https://josys-navi.hiblead.co.jp/tmsb_21jan20_docker-in-docker
- ネイティブロギングメカニズムを使用していること
  - https://cloud.google.com/blog/ja/products/management-tools/using-logging-your-apps-running-kubernetes-engine
請求管理
- 請求先アカウントを使用して、一連のプロジェクトのリソース使用量の支払い者を定義する
- 請求書を分析してエクスポートする
  - CSV または JSON ファイルにエクスポートして Cloud Storage に保存する
  - BigQuery へのエクスポートを構成する
  - リソースに適用されているラベルもエクスポートされる
費用管理

Cloud DNS (=Amazon Route 53)

マネージドクラスタ DNS インフラストラクチャ。
GKE 向けの DNS プロバイダとして使用可能。
- 完全な Kubernetes DNS 仕様をサポートし、GKE クラスタ内の Service の A、AAAA、SRV、PTR の各レコードの解決を行う。
  - PTR レコードは、レスポンスポリシールールを使用して実装される。
- クラスタ内の DNS サーバー（kube-dns など）を管理する必要はなし。
- マネージド DNS で Pod と Service の DNS 解決を行うことが可能。
- Pod と Service の DNS レコードは、クラスタ IP、ヘッドレス、外部名の各 Service 向けに Cloud DNS に自動でプロビジョニングされる。
- サービスを GKE 用 Service Directory に登録することも可能。

Cloud Router(=Amazon VPC)

Border Gateway Protocol（BGP）を使用し、Virtual Private Cloud（VPC）とオンプレミスネットワーク間でルートを動的に交換。
VPC AのサーバがプライベートIPを持ち、内部通信でVPC B、VPC Cそれぞれと通信できるようにする
- AB間、BC間をそれぞれCloud VPNで接続する
- VPCピアリングは推移的な通信となるため接続できない
サーバーレス VPC アクセス
- Google Cloud のサーバーレス環境から VPC ネットワークに直接接続可能。
- この接続により、サーバーレス環境が内部 IP アドレスを経由して VPC ネットワーク内のリソースにアクセスできるようになります。
- サーバーレス VPC アクセスでは、Google Cloud プロジェクトにコネクタを作成して VPC ネットワークに接続。
- 内部ネットワークトラフィックにコネクタを使用するように、サーバーレスサービス（Cloud Run サービス、App Engine アプリ、Cloud Functions など）を構成。

VPC Service Controls

Cloud Storage や BigQuery などのIAMから独立したサービスに対するセキュリティ強化
リソースのサービス境界（ペリメーター）を作り、GCPサービスのデータに対して境界外向けのアクセスをブロックできる。
- 境界全体での下り（外向き）データの制御など、コンテキストベースの境界セキュリティが可能。
- 内部から外部へのデータ流出を遮断でき、データが漏洩するリスク軽減。
オンプレからクラウドへ安全なハイブリッド接続が可能。

Cloud Identity Aware Proxy（IAP ID認証プロキシ）

Googleアカウントの認証機能を提供するリバースプロキシサービス
- Google Cloud内のVPCで認証を通し、外部にある HTTP ベースアプリ（オンプレ内の業務アプリ等）にアクセス可能。
- リバースプロキシをアプリケーションの前段に配置
- コンテキストベースのアクセスポリシーを適用
- ユーザー・アプリ間の暗号化を強制
- DDoS からの保護と TLS の終端
- SSH や RDP 等のプロトコルにも対応
IAP コネクタ
- Google Cloud の外部にある HTTP ベースアプリにアクセスできます。

BeyondCorp リモートアクセス

アプリケーションやリソースへの安全なアクセスを可能にし、統合型の脅威対策とデータ保護を提供するゼロトラストソリューション
参照）https://cloud.google.com/blog/ja/products/identity-security/keep-your-teams-working-safely-with-beyondcorp-remote-access

Cloud Armor (=AWS WAF)

WAF (Web Application Firewall)
- サービス拒否攻撃やウェブ攻撃からのアプリケーションとウェブサイト保護
- インフラに対する DDoS 攻撃の軽減
  - SYN f lood 攻撃、DNS アンプ攻撃、IP フラグメンテーション攻撃など
- IP、地理情報, カスタムルール (L3 - L7) を元にしたトラフィックの許可、拒否
- アプリケーションレイヤの攻撃からの防御 (SQLi、XSS など) IAP と共に利用可能
- Cloud Logging や Monitoring へ記録するテレメトリ(稼働データ)

Cloud CDN (=Amazon CloudFront)

ウェブコンテンツと動画コンテンツをグローバルに、効率的かつ確実に配信。

Cloud Load Balancing (=AWS Elastic Load Balancing)

ロードバランサの種類と選択
- 外部からアクセス可能な一つの IP アドレスを取得
- トラフィックを受信するのは正常な状態のバックエンドのみ
- トラフィックはユーザーに近い位置にある拠点から

Google Kubernetes Engine (GKE)　(=Amazon Elastic Kubernetes Service（EKS）)

- Binary Authorization

コンテナベースのアプリケーションにソフトウェアサプライチェーンのセキュリティを提供する Google Cloud のサービス
ソフトウェアが内部のベストプラクティスと標準に従い、構築、テスト、リリース、デプロイされるようにすることを目的としたツール

Anthos (=Amazon EKS Anywhere)

ハイブリッドクラウド・マルチクラウド環境に対応したアプリケーション管理プラットフォーム。オンプレやAWS(EC2)上でGKEを動かすことができる。
全ての環境のKubernetesがGCPコンソール上から一元的に管理・操作できたり、他のGCPサービスとの連携がしやすくなる。
- クラスタ管理（Anthos Clusters）
- サービス管理（Anthos Service Mesh）
  - サマリーと詳細の両方のメトリクス、チャート、グラフを表示し、サービスの挙動をモニタリングできます。
  - 特定のサービスをドリルダウンしてサービスレベル目標（SLO）を設定できます。また、問題のトラブルシューティングを行うこともできます。
- ポリシー管理（Anthos ConfigManagement）
参照） https://cloud.google.com/service-mesh/docs/observability/explore-dashboard
参照） https://future-architect.github.io/articles/20210319/

App Engine (=AWS Elastic Beanstalk)

フルマネージド型のサーバレスでフレキシビリティを備えたPaaS
App Engineのリソース階層は、アプリケーション＞サービス＞バージョン＞インスタンス　となる。
トラフィック分割機能を使用すると、トラフィックの配分比率を指定して同じサービスの複数のバージョンにトラフィックを振り分けることが可能。
- バージョン間で A/B テストを実行することが可能になり、機能をデプロイする際のペースを制御できます。
特にスタンダードとフレキシブルの2つの環境がある
- スタンダード環境　安価、言語ランタイムに制限がある
- フレキシブル環境　Dockerコンテナが利用可能。

Cloud Run (=AWS Fargate、AWS Lambda、AWS App Runner)

フルマネージドのサーバーレスプラットフォーム上で、スケーラブルなコンテナ化されたアプリケーションを開発し、高速デプロイ（数秒）。
トラフィックに応じてほぼ瞬時にゼロから自動的にスケールされる。
インフラストラクチャの管理は一切不要になり、かつ1秒あたり50万件のリクエストを処理することも可能。
使用した正確なリソース量に対してのみ課金されるため、よりコスト最適なオプション。
言語やライブラリの制約なし
ロックイン排除
タイムアウトまでの最大60分の稼働
デプロイについて、トラフィック分割は複数のリビジョン間で分割できるため、カナリアデプロイや Blue/Green デプロイなどはリビジョン分割を利用する
Cloud Runはリージョナルなサービスです。グローバルなユーザーにサービスを提供するためには、グローバルHTTP LBとバックエンドとしてNEGを設定する必要があります。
Cloud Runのサービスを個々のリージョンに展開し、外部のHTTP(S)ロードバランシングを設定することで、ユーザーをサービスの異なるリージョンにルーティングすることができます。
ネットワークエンドポイントグループ（NEG）は、ロードバランサーのバックエンドエンドポイントのグループを指定します。
サーバーレスNEGは、Cloud Run、App Engine、またはCloud Functionsのサービスを指すバックエンドです。

Cloud Build (=AWS CodeBuild、AWS CodeDeploy、AWS CodePipeline)

Google Cloud サーバーレス CI / CD プラットフォームでビルド、テスト、デプロイを行います。

App Engineフレキシブルと Cloud Run

App Engineフレキシブルは表でVMを起動するため、Cloud Runの起動時間の方が早い。
Cloud Runは0までスケールできるので、常時起動でなければコスト的にメリットが出る可能性が高い。
逆に常時一定の起動があるのであれば、App Engineフレキシブルの方がコストメットが出る。

Cloud Functions (= AWS Lambda)

自動的にゼロスケーリングするマネージドコンピューティングサービス。

Compute Engine (=Amazon Elastic Compute Cloud（EC2）)

マネージドインスタンスグループを推奨。
- 複数のVMで構成され、自動スケール、自動復旧、デプロイメント等をマネージドでやってくれる。
- ローリングアップデート/ローリング再起動ができる。
非マネージドインスタンスグループ（ユーザー自身で管理）
プリエンティブインスタンスは、最大80%引きで利用できる一方、24時間いないに削除される（確か24時間以上稼働するバッチで途中停止されたら初めからになるシステムのコスト最適化はどれか？みたいな問題が出てた気がします）
ライブマイグレーションがデフォルトで採用
使用されていない仮想マシン（VM）インスタンスを識別できるように、アイドル状態の VM に対するrecommend(レコメンド)が表示されます。この推奨は Cloud Monitoring サービスが過去 14 日間に集めたシステム指標に基づいて自動的に生成されます。
アイドル状態の VM のrecommendを使用して、アイドル状態の VM インスタンスを見つけて停止することで、リソースの無駄を減らし、コンピューティング料金を削減できます。
次の場合にアイドル状態のrecommendが使用できません。
- ローカル SSD を使用するインスタンス
- GPU / TPU を使用するインスタンス
- App Engine フレキシブルリソース
- Dataflow リソース
- Google Kubernetes Engine のリソース
永続ディスクのパフォーマンス改善
- インスタンスに接続された永続ディスクの総容量とインスタンスが持つvCPUの数に基づいています。永続ディスクの容量を増やすと、スループットとIOPSが増加し、その結果、パフォーマンスが改善されます。
- 例えば、リージョンSSD PDの場合、読み取り・書き込みIOPSはディスクサイズが1GB増加するごとに30 IOPS向上します。ディスクサイズは最大500GBまで増やすことが可能で
リージョン永続ディスクを利用時、万一ゾーンが停止した場合
- --force-attach フラグを使用することにより、リージョン永続ディスクで実行されているワークロードを別のゾーンにフェイルオーバーできます。
- 参照）https://cloud.google.com/compute/docs/disks/repd-failover?hl=ja
Computing Engine の単一テナントノード
- AWS EC2のハードウェア専有インスタンスみたいなユースケース。
- ノードグループを作って、アフィニティラベルを使ってグループ内の特定のノードで実行させる。
- https://cloud.google.com/compute/docs/nodes/sole-tenant-nodes?hl=ja
特定のインスタンスにルートを適用したい
- VMにネットワークタグ追加してファイアウォールルール設定
VMの有効ポリシー
- VMに割り当てたポリシーと親リソースから継承したポリシー
起動/停止を繰り返す状態持続
- --no-auto-deleteフラグを使用することで、インスタンス停止時に永続ディスクは削除されない
自動スケーリングの設定
- オートスケールのマネージドインスタンスグループを使用することで、ピーク時に自動的にインスタンスを立ち上げて負荷分散をする
- マネージドインスタンスグループを使用する際には、インスタンステンプレートの利用が推奨されています。
  - 既存のディスクから作成したカスタムイメージをベースイメージとし作成する
  - カスタムイメージからインスタンステンプレートを作成する。
  - インスタンステンプレートからオートスケールのマネージドインスタンスグループを作成する

Deployment Manager (=AWS CloudFormation)

VM インスタンスやその他の Google Cloud インフラストラクチャのプロビジョニングを自動化する
preview オプションをつければ構成のプレビュー可

Cloud Data Loss Prevention（DLP） (=Amazon Macie)

データのサニタイズができる。ログ保存前に機密情報守る。
GCSやBigQuery上にあるデータをユーザーへ提供する際、事前に機密情報を検出し、除外もしくは匿名化などの処理を施し、ユーザーへデータを提供できる。
各プロジェクトのCloud Monitaringを一元的に管理したいときは、指標スコープを使用する

Cloud Monitoring (=Amazon CloudWatch Logs)

アプリケーションとインフラストラクチャのパフォーマンス、可用性、健全性を可視化できます。
サイト信頼性エンジニアリング（SRE）のベストプラクティスをビジネスに取り入れる方法
- Cloud Monitoringのワークスペースで定義済みのダッシュボードを表示し、メトリクスを追加してアラートポリシーを作成することが挙げられます。
- 参考：https://cloud.google.com/blog/ja/products/operations/dashboards-cloud-monitoring-made-easier-samples

Cloud Logging (=Amazon CloudWatch Logs)

エクサバイト規模で行われるストレージ、検索、分析、アラートを備えたフルマネージドでリアルタイムなログ管理。
デフォルトでLogging内に保存されるが、フィルタ機能を用いて、 BQやGCS、Pub／Sub（からのサードパーティ）などへExporteが可能
システムログの確認方法
- 各VMにCloud Logging agentをインストール

Cloud Audit Logs (=AWS CloudTrail)

Google Cloud が提供するログの集まりで、Google Cloud サービスの使用に関連する運用上のログを把握することができます。 Cloud Audit Logsは、管理者の活動、データアクセス、システムイベントなどの監査ログを保持します。

BigQueryのクエリログデータも自動的にCloud Audit Logsへ送信されます。また、Cloud Audit Logsのフィルタ機能を使うことで、関連するBigQuery Auditメッセージをフィルタリングすることができます。これによって、各ユーザーごとにクエリ数を確認することもできます。
https://cloud.google.com/logging/docs/audit

StackDriver

モニタリングとロギングでパフォーマンスと使用状況の一元管理
Logging エージェントとインストールすれば StackDriver にログを転送できる
- Logging
  - モジュールのログエントリを確認
  - VMの様々なメトリクスを集計して時系列で表示することが可能
  - すべての VM インスタンスで Logging エージェントを実行することを推奨
- Trace
  - 各ステップでのAPIレイテンシをトレースするために有効なツールです。
  - アプリケーションを計測し、各マイクロサービスのリクエストの待ち時間を把握することが可能
- Debugger
  - 監視ツール

Cloud Firewall

各層にタグを追加し、ファイアウォールルールを設定して、目的のトラフィックフローを許可
数字が低いものほど優先順位が高い
![image.png](https://image.docbase.io/uploads/2f7d5015-1da6-4f1e-b90d-00a5482caa80.png =WxH)
ファイアウォールインサイト
- ファイアウォールルールについて適切な判断を下すことができるメトリクスと分析情報を生成します。これによって、ファイアウォールルールの設定についての理解を深めながら、安全にルールの最適化ができます。ファイアウォールルールの使用状況に関するデータを使用して、構成の誤りを確認し、より厳格なルールを特定できます。
- ファイアウォールインサイトでルールに関するメトリクスを利用するためには、ファイアウォールルールのロギングを有効にする必要があります。
  参照）https://cloud.google.com/blog/ja/products/identity-security/eliminate-firewall-misconfigurations-with-firewall-insights

Cloud VPN (=AWS Virtual Private Network（VPN）)

2つのリージョンにまたがる単一のVPCにCompute Engineアプリケーションを構築し、アプリケーションは、オンプレミスのネットワークとVPNで通信する必要がある
- 各リージョンにCloud VPNゲートウェイを展開
- 各リージョンには、オンプレミスのピア・ゲートウェイへのVPNトンネルが少なくとも1つあること

参考) https://medium.com/google-cloud-jp/routing-google-cloud-vpc-and-on-prem-46fe51624ba0

Artifact Registry (=Amazon Elastic Container Registry)

コンテナイメージを保存・管理するためのサービス

Cloud Storage (=AWS Simple Storage Service（S3）)

スケーラビリティに優れたサービス。
キャパシティを超過するリクエストを投げつづけると、5xxや429エラーを返却します。
- レイテンシやエラーレートの増大などの問題が発生した場合は、一時的にリクエストレートの段階的な増加を中止するか、リクエストレートを減らして、Cloud Storage でバケットがスケーリングされるまでもうしばらく待ってみます（指数的バックオフ戦略）。
既存Bucketにライフサイクル管理ルールセットアップ
- JSON入力
- gsutilを使ってBucketにプッシュする
  - PUT APIからのコールリクエスト（ ' gsutil lifecycle ' のnoコマンド）
Cloud Storage に保存するデータを外部発行鍵を使って暗号化する
- デフォルトで、Google 管理の暗号鍵と AES256 暗号化アルゴリズムを使用して、すべてのオブジェクトデータを暗号化する
- 顧客指定の暗号鍵（CSEK）または Google Cloud KMS で管理する顧客管理の暗号鍵（CMEK）のいずれかの暗号鍵タイプを使用することもできます
  - CSEK を Google のサーバーに永続的に保存したり、管理したりすることはありません。
- JSON API を使用して Cloud Storage オブジェクトを操作するための CSEK を .boto 構成ファイルで指定します。gsutil を使ってファイルをアップロード -
バッチファイル転送を最適化
- 転送するファイル数が多い場合は、マルチスレッド/マルチプロセッシングの並列コピーを実行することができます。
- 具体的には以下のようなコマンドを使用します。
  - gsutil -m option (gsutil help optionsを参照):
  - gsutil -m cp -r dir gs://my-bucket

Filestore (=Amazon Elastic File System（EFS）)

高パフォーマンスでフルマネージドのファイルストレージ
アプリケーションに低レイテンシのストレージオペレーションを提供
ハイパフォーマンスコンピューティング、データ分析、その他のメタデータ量の多いアプリケーションなど、レイテンシの影響を受けやすいワークロードに対して、最大 100 TB の容量と、25 GB/秒、920K IOPS のスループットをサポート
ファイルストレージを必要とする GKE で実行されるアプリに対して、Filestoreはステートフルとステートレスアプリケーションをサポート

Cloud SQL (=Amazon Relational Database Service（RDS）、Amazon Aurora)

マネージド型のSQLデータベース
対応エンジン MySQL、PostgreSQL、SQL Server
高可用性を実現するための方法、ポイントインタイムリカバリに必要な設定など
- リードレプリカは、レイテンシーの短縮とパフォーマンスの向上
- フェイルオーバーレプリカは、高可用性
Cloud SQL インスタンス
- 「リージョンインスタンス」とも呼ばれ、構成されたリージョン内のプライマリゾーンとセカンダリゾーンに配置されます。
- データ損失を最小限にする方法
  - バイナリロギング
  - バックアップの自動化
ストレージの自動増量の有効化
- Cloud SQLの設定として行うことができます。この設定を有効にすると、Cloud SQL によって利用可能なストレージが 30 秒ごとにチェックされます。利用可能なストレージがしきい値サイズを上回ると、自動的にストレージ容量が追加されます。利用可能なストレージがしきい値サイズを繰り返し上回る場合、最大 64 TB に達するまで続けてストレージが追加されます。
Stackdriverアラートの作成
- CPU利用率を監視することができ、閾値を超過したらアラートを飛ばすことができます。なお、CPU容量の大きいマシンタイプに変更するためには再起動が必要です。
データベースのシャーディング
- シャーディングは、データベースをより小さく、より管理しやすいパーツ（シャード）に分割し、そのパーツをマシンのクラスター全体にデプロイすることで、水平方向のスケーリングを可能にします。これによって、レプリケーション時間の短縮が実現できます。
  ※フェールオーバーレプリカの作成にチェックを入れる必要あり
  ※Cloud SQLはMySQL、PostgreSQL、SQL Serverに対応（Oracleは現在未対応）
  参照） https://cloud.google.com/sql/docs/sqlserver/high-availability
  参照）https://cloud.google.com/sql/docs/db-versions?hl=ja

Cloud Bigtable (=Amazon DynamoDB)

高スループット分析
- 超大容量データを Key-Value ストアに格納するのに理想的で、大量のデータにすばやくアクセスできる
- 適切なコンピューティングリソースと組み合わせることで、1秒に50万件のデータ読み書きを実現可能
低レイテンシ
- 高スループットの読み取りと書き込みをサポート
ネイティブな時系列のサポート
ワークロード
- IoT、金融、アドテクなど
- パーソナライゼーション、レコメンデーション
- 監視
- 地理空間データセット
ホットスポット
- 行キーの偏りは、タイムスタンプやシーケンシャル数値IDなどを使用すると発生し、パフォーマンスの極端な低下につながります。
  - RowKey戦略を見直し、キーがアルファベットに均等になるようにする

Datastore(次世代バージョンFireStore) (=Amazon DynamoDB )

ウェブ、モバイルアプリケーションのためのスケーラビリティの高い NoSQL データベース。
1秒間に数百万回の書き込みが可能なDatastoreモードで実行可能
ローカルのインデックス設定に基づき、新しいデータストアのインデックスを作成する。
- gcloud datastore create-indexes
- インデックスファイルに存在しないインデックスが作成される
デフォルトでグローバルに展開可能, かつ複数行Transactionに対応
決定論的アルゴリズムで与えられた入力セット（カード番号、有効期限、userID）で暗号化可能

Cloud BigQuery (=Amazon Athena、Amazon Redshift)

サーバーレスでスケーラビリティと費用対効果に優れたマルチクラウドデータウェアハウスで、最大 99.99% の可用性
ACLやビューを利用することで、アクセスを制限可能
- テーブルACLでは、テーブルレベルのアクセス権を設定することができます。テーブルレベルのパーミッションは、テーブルやビューにアクセスできるユーザー、グループ、サービスアカウントを決定します。
- データセット全体へのアクセスをユーザーに与えることなく、特定のテーブルまたはビューへのアクセスを与えることができます。
  - たとえば、BigQuery Data Viewer（ロール/bigquery.dataViewer）というロールを付与して、データセットへのアクセスなしにテーブルまたはビューへのクエリーを実行できるようにします。
[エクスポートされたCloud Billingのデータをクエリできる]
不要ログの処理
- パーティションテーブルで有効期限設定
MLによる機械学習と予測モデリングでデータの予測分析が可能

Cloud Spanner(=Amazon Aurora)

大規模なスケーリング、世界的規模の強整合性、最大 99.999% の可用性でリレーショナルデータを管理します。

Memorystore (=Amazon ElastiCache)

Redis と Memcached 向けの、スケーラブルで安全かつ可用性の高いインメモリサービスでレイテンシを短縮します。

Cloud Dataprep

データクレンジングサービス。構造化データと非構造化データを視覚的に探索し、簡単にクレンジング処理を行うことができます
データ調査に最適
DataPrepは、高速な探索と異常検知を実現し、読み込み元媒体としてCloud Storageが含まれる。

Cloud Dataflow (=Amazon Kinesis)

バッチデータであってもリアルタイムストリームデータであっても、データの変換を行うことができるサービスです

Cloud Dataproc (=Amazon Elastic MapReduce（EMR）、AWS Batch、AWS Glue)

Apache Spark、Apache Flink、Presto をはじめ、30 以上のオープンソースツールやフレームワークを実行するための、フルマネージドでスケーラビリティの高いサービス
Dataproc を使用すれば、データレイクのモダナイゼーション、ETL、安全なデータサイエンスを、Google Cloud と完全に統合された極めてスケーラブルな環境で、低コストで実現できます。

Storage Transfer Service (=AWS Storage Gateway)

他のクラウドストレージプロバイダ、またはオンプレミスストレージから Cloud Storage バケットにデータを転送またはバックアップする。
ある Cloud Storage バケットから別の Cloud Storage バケットにデータを転送し、さまざまなユーザーグループやアプリケーションで使用できる。
データ処理パイプラインまたは分析ワークフローの一部として、データを定期的に移動します。

Data Studio

ストレージコストを抑えて分析 (クエリ実行）が容易に可能

CI/CDパイプライン

脆弱性セキュリティスキャナを実行することは、アプリケーションおよびインフラストラクチャの安全性を担保する上でのベストプラクティスです。
CI CDパイプラインの一部として、静的/動的なソースコード解析ツールを使用することもベストプラクティスです。
参照） https://cloud.google.com/container-registry/docs/container-analysis

Cloud Pub/Sub (=Amazon Simple Notification Service（SNS）、Amazon Simple Queueing Service（SQS）)

信頼性の高いリアルタイムメッセージングサービス
ローカルのアプリ開発か本番環境アプリケーションの開発か問わずサービスアカウントの利用が推奨
スケーラブルで安定したイベントの受配信
秒間数百万件のイベントを受信
多様な配信方式(一対一, 一対多, 多対多)
Push および Pull 配信
Cloud Dataflow や Cloud Data Analytics 製品群とのシームレスなインテグレーション
サブスクライバーのGKEが処理開始までいつも数分かかってるのを解決する
- アプリケーションサーバーVMから機密トランザクションデータのバッチをCloud Pub/Subにプッシュして処理と保存する際に、アプリケーションが必要なGoogle Cloudサービスを認証するために、Googleが推奨する方法
- VMサービスアカウントに適切なCloud Pub/Sub IAMロールが付与されていることを確認する
- subscription/num_undelivered_messages メトリクスは、確認応答されていないメッセージの数を表示します。
- この数が大きくなった場合、現在のポッドの状態ではキャパシティーを超過していることになるので、スケーリングが必要になります。

オンプレ接続

パブリックアドレス設定
- 専用ダイレクトピアリング（SLA なし）
  - Google や Google Cloud のプロパティに直接接続でアクセス
- 共有キャリアピアリング（SLA なし）
  - Google や Google Cloud のプロパティにキャリアピアリングパートナーからアクセス
プライベートアドレス設定
- 専用 Dedicated Interconnect
  - オンプレミスネットワークを直接 GCP VPC に接続
  - ファイアウォール向けに新しいハードウェアを購入して、10 GB のインターフェースを入手が必要
- 共有 Partner Interconnect
  - 対応しているサービスプロバイダを介して、オンプレミスネットワークを GCP VPC に接続
  - 直接接続されているパートナーのネットワークに直接接続すると、レイテンシを下げられます。
  - 現在のファイアウォールで使用している低い帯域幅のインターフェースを使用
本番環境アクセスのInterconnectを、ベストプラクティスに沿った接続にしたい。
- Interconnect のベストプラクティス構成
- ドキュメントでは本番環境の可用性 99.99% と非ミッションクリティカルの可用性 99.9% 、それぞれの構成が書かれています。
  - https://cloud.google.com/network-connectivity/docs/interconnect/tutorials?hl=ja
オンプレからクラウドにデータ転送したい場合
- Dedicated Interconnect とtransfer appliance データはCloudStorageへ転送
- transfer appliance障害時はCloudVPN構成
Transfer Appliance
- 大容量データ（数百テラバイトから1ペタバイトまで）を、業務を中断することなく安全にGoogle Cloud Platformに移行するために利用できるハードウェア。
- Transfer Applianceを注文して、オンプレミス上のデータをロード・返送して、Google Cloud上に保存されるまでの所要日数は約20日。
- 1Gbpsの回線で1PBのデータを転送するとなると、123日かかるため、今回のケースであればTransfer Applianceの使用が最適
  ![image.png](https://image.docbase.io/uploads/79e488bc-464f-4100-8d65-e56882caf460.png =WxH)
ApigeeとCloudEndpointでオンプレとGCPの両環境への接続を維持可能

Migrate for Compute Engine (=AWS Server Migration Service)

オンプレミスの仮想マシンからGoogle CloudのVMへ移行

HIPPA

HIPAA：United States Health Insurance Portability and Accountability Act of 1996（米国における医療保険の相互運用性と説明責任に関する法令）の略称
Google Cloudのコンプライアンスページには、HIPAAに準拠しているサービスのリストが表示される。
- EHRが使用しているサービスがHIPPAに準拠しているかを知ることが可能。

BAA締結

Googleとお客様との間で締結されたHIPAA業務提携修正条項または業務提携契約のこと。

CVE（脆弱性）対応

Google Cloud Platform Security Bulletins に掲載されている CVE情報を確認し、影響を把握する
CVEに関するサポートケースを開き、サポートエンジニアとチャットする

PCIDSS

GKEをはじめいくつかのサービスでPCI DSSの認定を受けています。
全てのサービスについて認定を受けているわけではない。
- 参照) https://cloud.google.com/security/compliance/pci-dss

継続利用割引

請求月の特定の Compute Engine リソースの実行時間が一定の割合を超えた場合に自動的に適用される割引。
あるマシンタイプのVMリソースの実行時間が 1 か月の 25% を超えると、そのインスタンスについて分単位で自動的に割引が適用。
必要以上にインスタンスを稼働させる必要なし。

コミットメントユース割引

リソースの必要量が予測可能なワークロードに最適。
コミットユース契約を購入すると、1年または3年間、これらのリソースの支払いを約束する代わりに、計算リソース（vCPU、メモリ、GPU、ローカルSSD）を割引価格で購入可能。
マシンタイプやGPUなど、ほとんどのリソースで最大57%の割引が適用。
メモリ最適化マシンタイプでは、最大70%の割引が適用。

その他

顧客が提供した暗号化キーを使用してファイルを暗号化
- boto構成ファイルに追加
Debian Linux で動かすアプリ、OSの更新を効率化
- Patch Manager を使ってパッチ展開を自動化
PCI（Payment Card Industry）コンプライアンスの範囲を最小限にしたいが、トランザクションデータや、どの支払い方法が使われているかに関連するトレンド分析は行えるようにしたい
- トークン化されたデータのみを保存