Zenn
Open17

GCP PCAの勉強メモ

Google Cloud
模擬試験の復習
korallekoralle

Cloud SQLのHA構成

  • HA構成 = クラスタのこと。
  • HA構成にした場合、Cloud SQLのインスタンスはリージョナルリソースとして同一リージョン内の2つのゾーン（プライマリゾーンとセカンダリゾーン）に配置される。
  • プライマリインスタンスへの書き込みはセカンダリゾーンのスタンバイインスタンスにも同期される。
  • HA構成にした場合、単一インスタンス構成の場合の2倍の料金がかかってしまうので注意。

フェイルオーバー

HA構成にした場合にプライマリインスタンスが正常に機能しなくなると、自動的にセカンダリゾーンのスタンバイインスタンスに接続を切り替える動作。

korallekoralle

Compute Engineの永続ディスクの暗号化に使用する鍵はユーザーが用意したものを使用することが可能。

korallekoralle

Google Cloud Storage（GCS）で使えるセキュリティ機能

  • 署名付きURL
  • データ保存時の暗号化設定
    -Access Control List （ACL）によるアクセス権限制御
  • データ転送時の暗号化
  • IAMによるアクセス権限制御

ただし、不審なアクティビティを検知したときにアラートを出すことはできない

署名付きURL

この署名付きURLさえ知っていればGoogleアカウントの有無に関係なく一定期限内にリソースへアクセスできるようになる。

Access Control List（ACL）

GCSのバケットへのアクセス権限は、ほとんどの場合IAMで制御するだけで十分。
しかし、IAMによるアクセス権限はバケット内の全てのオブジェクトに一括で適用されてしまう仕様になっている。
そのため、バケット内のそれぞれのオブジェクトのアクセス権限を個別に管理したい場合はIAMでは不十分で、ACLを使用する必要がある。

1つのACLは、1つ以上のエントリ（権限 + スコープの組合せ）で構成される。

  • 権限 ... ユーザーが実行できる操作
  • スコープ ... 誰がその権限を行使できるか
korallekoralle

Google Compute Engine（GCE）のストレージオプション つまみ食いメモ

GCEで使用できるストレージオプションにはさまざまな種類がある。

  • ゾーン永続ディスク
  • リージョン永続ディスク
  • ローカルSSD
  • Google Cloud Storageバケット
  • Google File Store

GCEのインスタンスには元々ブート用の永続ディスクが1つ存在している。

ゾーン永続ディスク

後述のローカルSSDとは異なり、GCEインスタンスを削除した後でもデータを保持することができるディスク。
データは複数の物理ディスクに分散して保存されるので、ゾーン永続ディスクに保存されたデータは冗長性が担保されている。

スナップショットを作成可能。
ディスク内のデータは暗号化されて保存される。この時、暗号化に使用する鍵はユーザーが用意したものを使用できる。

ディスクタイプが以下の3つから選択できる。

  • 標準永続ディスク（HDD）
  • バランス永続ディスク（SSD）...コスパが良い？
  • SSD永続ディスク ... 一番性能が高い

リージョン永続ディスク

永続ディスクとしての仕様はゾーンディスクとほぼ同じ。
しかしゾーン永続ディスクとは異なり、リージョン永続ディスクは同一リージョン内の2つのゾーンにまたがって使用できるため、データの耐久性や可用性がより高くなる。

ローカルSSD

標準永続ディスクやSSD永続ディスクに比べるとスループットが高くレイテンシーも低い一方で、ローカルSSDに格納されたデータはGCEインスタンスが停止/削除されると消失するという特徴がある。

1つのローカルSSDのサイズは375GBだが、1つのGCEインスタンスごとに最大で24個のローカルSSDを接続して合計容量を9TBまで拡張することが可能（以前は8本で3TBだった？）。

  • パフォーマンスは高いが、インスタンス依存のリソースなので冗長性が無い。
  • ディスク内のデータは暗号化されるが、ユーザが用意した鍵が使用できない。
korallekoralle

App Engineの料金設定

前提として、App EngineのStandard Environment（SE）とFlexible Environment（FE）では料金設定が異なる。

Standard Environment（SE）

SEには無料枠があり、無料枠を越えた分だけ課金される。

SEにおける課金料金は以下の2つ

  • インスタンスの使用時間
  • 通信トラフィック

インスタンスの使用時間

インスタンスが起動した時点から終了時点までの時間に対して課金が発生するが、その金額はインスタンスが属するインスタンスクラスによって異なる。

終了時点の定義がスケーリングのタイプによって異なる

  • 基本/自動スケーリング => リクエストの処理完了から15分後
  • 主導スケーリング => シャットダウンから15分後

なので、感覚としてはインスタンスの使用には15分間ぶんのイニシャルコストが発生すると思ってよさそう。

通信トラフィック

受信トラフィックは無料だが、送信トラフィックはインスタンスが属するゾーンによりの異なる金額の課金が発生する。

Flexible Environment（FE）

FEでは無料枠が無い。
デプロイ時に指定したタイプの仮想マシンのコンピューティングリソースを使用した時間に対して課金が発生する。
その金額は、仮想マシンが属するリージョンによって異なる。

課金の対象となるコンピューティングリソースは以下（受信トラフィックは無料）。

  • vCPU
  • メモリ
  • 永続ディスク
  • 送信トラフィック
korallekoralle

Cloud Audit Logsってなんだ

プロジェクト、フォルダ、組織ごとにいろんな監査ログを吐いてくれるサービス。
Cloud Audit LogsによってGCPの各リソースに対して「誰がどこでいつ何をした」を把握できる。
監査ログは一定期間経過すると削除されるので、必要があればエクスポートする。

Cloud Audit Logsで監査ログが確認できる例

  • Cloud Storageのバケットを削除した
  • プロジェクトへのIAMポリシーを変更した
  • GCEのVMインスタンスを作成した

吐いてくれるログの種類

  • 管理アクティビティ監査ログ
  • データアクセス監査ログ
  • システムイベント監査ログ
  • ポリシー拒否監査ログ

管理アクティビティ監査ログ

リソースの構成やメタデータを変更するような操作を実行したときに吐かれるログ。

データアクセス監査ログ

リソースの構成やメタデータの読み取り、ユーザーによるリソースの作成あるいはユーザーが作成したリソースの変更や読み取り操作に対して吐かれるログ。

システムイベント監査ログ

リソースの構成を変更したときに吐かれるが、これはGoogle側が吐くログで、ユーザーの操作によって直接的に吐かれることは無い。

ポリシー拒否監査ログ

IAMのポリシー違反が発生したときに吐かれるログ。

korallekoralle

Google Compute Engine（GCE）のインスタンスグループ

GCEのVMインスタンスを複数まとめてインスタンスグループという単一のエンティティとして管理することが可能。

インスタンスグループは2つのタイプに分類される。

  • マネージド ... スケーリングや修復、更新などを全て自動で行う。大体のケースはこっちを採用する。
  • 非マネージド ... 2種類以上のタイプのインスタンス群でインスタンスグループを作成する場合に採用する。ただし、インスタンスグループは単一ゾーン依存のリソースになるので注意が必要だったりもする。
korallekoralle

Cloud VPNってなんだ

VPN技術を使用してGCPのVPCネットワークと他のネットワークをプライベート接続するネットワーキングサービス。

Cloud VPNのタイプ

Cloud VPNでは、VPNゲートウェイを2つのタイプから選択できる。

  • HA VPN
  • Classic VPN

HA VPN

  • インターフェースと外部IPを2つずつ使って構成することで99.99%のSLAを確保できる。
  • ルーティングはBGPによる動的ルーティングのみ可能。

Classic VPN

  • 要件を満たすと99.9%のSLAを確保できる。
  • 静的ルーティングとBGPによるルーティングが可能。

帯域幅

Cloud VPNのトンネルの帯域幅は上り・下りで合わせて3Gbps。

korallekoralle
  • GCPでは世界で142の拠点からリソースにアクセスできる。参考
  • Cloud CDNでは93以上の拠点で構成されるエッジネットワークを使用している。参考
  • Dedicated Interconnectは86の拠点で利用できる。参考
korallekoralle

BigQueryってなんだ

サーバレスなデータウェアハウスで、データ分析のように大量のデータを検索するサービスで採用できる。
BigQueryはWebコンソール上かSDKのbqコマンド、あるいはクライアントライブラリを使ってAPIを呼び出すことで使用できる。

BigQueryのいいところ

  • サーバレス
  • 標準SQLが使える
  • 実質リアルタイムな分析ができる

パーティション分割

BigQueryのデータセットはパーティションという単位で分割できる。
1つの大きなテーブルを複数の小さなパーティションに分割することで以下のようなメリットがある。

  • クエリのパフォーマンス向上
  • クエリ実行により走査するデータ量の削減（= コストの削減）

パーティション分割の方法は3つある。そのいずれかの方法で分割するようにテーブルを作成すると、BigQueryはその方法で自動的にパーティションを作成する。

  1. データの取り込み・受信時間による分割
  2. TIMESTAMP列 or DATE列 or DATETIME列による分割
  3. 特定のINTEGER列による分割

注意点

BigQueryのクエリをCloud Storage、Cloud Bigtable、Google Drive、Cloud SQLといった外部データソースに対して実行する場合、BigQueryのデータセットと外部データソースのロケーションを一致させる必要がある。

料金

BigQueryにおいて発生する課金の要因は主に2つ。

  • ストレージ ... BigQueryに格納されているデータの量に依存する
  • クエリ ... BigQuery上で実行したクエリの内容に依存する
korallekoralle

Cloud Load Balancingってなんだ

ソフトウェアベースのマネージドなロードバランサー。
プレウォーミングしなくても秒間100万クエリに応答できるように設計されている。

Cloud Load Balancingで使用できるロードバランサーの種類

  • 内部TCP/UDP
  • 内部HTTP(S)
  • TCP/UDPネットワーク
  • TCPプロキシ
  • SSLプロキシ
  • 外部HTTP(S)

ロードバランサーを選ぶポイント

負荷分散はグローバル or リージョン？

  • 単一のIPアドレスを使用して複数のリージョンに分散するバックエンドを対象に負荷分散する場合はグローバル負荷分散を選択する。
  • 負荷分散の対象となるバックエンドが同一リージョン内に分散している場合はリージョン負荷分散を選択する。
korallekoralle

そもそもDNSサーバーって何

ドメイン名とIPアドレスの変換処理（名前解決）を行うサーバー。
多くのDNSサーバーが互いに連携しあうことでDNSレコードに関する1つの大きな分散型データベースを構成する。

DNSサーバーには2つの種類がある

  • 権威DNSサーバー
  • 再帰リゾルバ

権威DNSサーバー

コンテンツサーバーとも言われたりする。
クライアントから受信した名前解決要求（DNSクエリ）に対して、自身が持つゾーン情報を参照してクライアントが要求しているIPアドレスを返す役割がある。

負荷分散のために2台以上配置することが多い。

再帰リゾルバ

キャッシュDNSサーバーとも言われたりする。
権威DNSサーバーやその他のサーバーに対して名前解決要求を投げる。

再帰リゾルバは、一度投げた名前解決要求の結果を一定期間保持する（キャッシュする）。

DNSレコード

1組のドメイン名とIPアドレスのマッピング。

ゾーンとゾーン情報

  • 1台の権威DNSサーバーで管理できる名前解決の範囲をゾーンと呼ぶ。
  • そのゾーン内で名前解決するための情報はゾーン情報と呼ぶ。
  • ゾーン情報を構成するのは多数のDNSレコードである

ざっくりとした名前解決の例

参考

korallekoralle

GCPのビッグデータサービス外観

  • Cloud Composer
  • Cloud Dataproc
  • Cloud Pub/Sub
  • Cloud Dataflow
  • BigQuery
  • Cloud Dataprep

Cloud Composer

Cloud Dataproc

分散処理基板であるHadoopとSparkをフルマネージドで使用できる様にしたサービスで、ビッグデータを分散処理したい場合に採用できる。

参考

Cloud Dataprep

参考：ノンプログラマーでもデータ加工ができるDataprepを触ってみた(前編) | apps-gcp.com

ノンコーディングで使用できるフルマネージドなETLサービス。
GoogleがTrifactaと言うサードパーティ企業と提携することで実現している。
実際のジョブ実行時は裏でCloud Dataflowが動いている。
そのため、Cloud Dataprep自体に料金は発生しないが、裏で実行したCloud Dataflowに対して課金が発生する。

Cloud Dataflow

データ処理のパイプラインを実現するサービスで、Cloud Pub/Sub、BigQuery、Cloud Storageなどの他の様々なサービスとの連携が可能。

Dataflowで実行するパイプライン処理の実行単位をジョブと呼び、そのジョブを実際に実行するリソースはワーカーと呼ぶ。
ワーカーの実体は特殊なGCEのインスタンスで、下記のワーカーリソースに対して秒単位の課金が発生する。

  • vCPU
  • メモリ
  • 永続ディスク