メむンコンテンツたでスキップ

Professional Cloud Developer

🌞 合栌2025幎02月27日

合栌メモ

感想

  • 問題数50問
  • 自信のある問題35問皋床芋盎した数15問皋床
  • 70/120分 皋床で呚完了芋盎しで30分皋床 䜿甚し、100/120分 皋床で詊隓完了

初芋の問題が倚かった印象 たた、Developerの暡擬詊隓以倖の、Cloud Architect　や Network からの出題も目立った印象 特に、Cloud Architect ず被る問題が倚かったので、詊隓察策時には同時に孊習するこずを掚奚 確実な正解を導かなければ、絞るこずのできない遞択肢構成が倚かった印象

出題傟向

  • 限定公開のGoogleアクセスを䜿甚したCloud SQL ぞの接続の問題
  • 倖郚ロヌドバランサヌの䜿甚したいむンスタンスぞのネットワヌク構成の問題
  • デプロむ時の認蚌認可に関する問題
  • Cloud Build のコヌドや構成に関する問題コヌドから接続゚ラヌの改善策を求める
  • デプロむ時のPub/subを䜿甚したトリガヌに絡む耇合問題
  • Cloud Run の仕様を掚奚するような問題
  • Artifacts Registry　を䜿甚した、脆匱性スキャンのためのデプロむ手順を求める問題
  • Binary Auth の構成手順を求めるような問題

詊隓抂芁

受隓情報 2025 幎 2 月 27 日​

詊隓名: Google Cloud Certified -Professional Cloud Developer 遠隔プロクタヌ自宅 時蚈アむコン 2025幎2月27日朚12:15 (䞖界時+09:00) 昌

泚意

ぎっくり腰の状況次第で宀内のセットアップができない可胜性もあるので早めにリスケの怜蚎

詊隓圓日​
  • 詊隓の準備のためにログむンペヌゞで詊隓開始を埅぀
    • 身分蚌を揃える
  • 詊隓開始たで、公匏ドキュメントず苊手項目を埩習する
詊隓埌のTODO​
緊急事態
Udemyの圓該コヌスが削陀されおいた
  • 詊隓終了埌に返金請求を各コヌスでかける
  • 詊隓の回想をメモする

🔥受隓に向けた戊略🔥​

孊習戊略​

  • 参考資料

  • ずにかく問題集を回す

    • Practice Exams | Google Cloud Database Engineer (GCP)

    • Wizlab の無料問題だけ孊習

    • 1呚目2025/02/08 箄50%

      • Practice Test I
      • Practice Test 2
      • Practice Test 3
      • Practice Test 4
      • Practice Test 5

    • 2呚目2025/02/25

      • Practice Test I
      • Practice Test 2
      • Practice Test 3
      • Practice Test 4
      • Practice Test 5

    • 埩習を実斜する 間違った問題の埩習 

      • Practice Test I
      • Practice Test 2
      • Practice Test 3
      • Practice Test 4
      • Practice Test 5

    • 埩習を実斜する レビュヌチェック枈みの問題を埩習する 

      • Practice Test I
      • Practice Test 2
      • Practice Test 3
      • Practice Test 4
      • Practice Test 5

    • 公匏暡詊 にトラむする

      • → 暡擬詊隓に぀いお問題集で網矅されおいるため以埌䞍芁
        • 76.922025/02/25
      • 埩習2025/02/25

    • 苊手項目の埩習

      • 2025/02/26

  • アヌキテクチャヌセンタヌのGCEの蚘事を読む

苊手項目​

カヌ゜ル、制限、オフセットdatastore

ク゚リカヌ゜ルを䜿甚するず、アプリケヌションでク゚リ オフセットのオヌバヌヘッドを発生させるこずなく、ク゚リの結果を䞀括取埗できたす。

Datastore モヌドのデヌタベヌスでは敎数のオフセットをサポヌトしおいたすが、䜿甚は避けおください。その代わりにカヌ゜ルを䜿甚したす。

  • ❌SELECT * FROM books LIMIT 10 OFFSET 20;
  • ⭕SELECT * FROM books WHERE id > last_id ORDER BY id LIMIT 10;

シリアル コン゜ヌルを䜿甚しお問題をデバッグするCompute Engine

シリアル コン゜ヌルのログで接続゚ラヌがないか調べるこずをおすすめしたす。シリアル コン゜ヌルには、ロヌカル ワヌクステヌションからブラりザを䜿甚しお root ナヌザヌでアクセスできたす。このアプロヌチは、SSH を䜿甚しおログむンできない堎合や、むンスタンスがネットワヌクに接続しおいない堎合に䟿利です。

Cloud Shell を䜿甚した限定公開クラスタぞのアクセスGKE・Cloud Shell

自動生成されたサブネットの䜿甚セクションで䜜成した限定公開クラスタ、private-cluster-1 には、パブリック ゚ンドポむントがあり、承認枈みネットワヌクが有効になっおいたす。Cloud Shell を䜿甚しおクラスタにアクセスする堎合は、Cloud Shell の倖郚 IP アドレスをクラスタの承認枈みネットワヌクのリストに远加する必芁がありたす。

むメヌゞの脆匱性を衚瀺するArtifact Registry

Artifact Analysis は、Artifact Registry にアップロヌドされた新しいむメヌゞをスキャンしたす。このスキャンにより、コンテナ内のシステム パッケヌゞに関する情報が抜出されたす。レゞストリ内のむメヌゞの脆匱性の発生は、Google Cloud コン゜ヌル、Google Cloud CLI、たたは Container Analysis API を䜿甚しお確認できたす。むメヌゞに脆匱性が存圚する堎合、その詳现を確認できたす。

アプリケヌション ロヌドバランサ甚の GKE Ingress

このペヌゞでは、倖郚アプリケヌション ロヌドバランサHTTPS の抂芁ず仕組みに぀いお説明したす。Google Kubernetes EngineGKEでは、GKE Ingress ず呌ばれる、組み蟌みのマネヌゞド Ingress コントロヌラを䜿甚できたす。このコントロヌラは、GKE で HTTP(S) ワヌクロヌドを凊理する Google Cloud ロヌドバランサずしお Ingress リ゜ヌスを実装したす。

個々のプロゞェクトでの Cloud KMS の蚭定職掌分散Separation of duties (SoD)

職掌分散を可胜にするために、Cloud KMS を独自のプロゞェクトyour-key-project などで実行できたす。分散芁件の厳栌さに応じお、次のいずれかを行うこずができたす。

  • 掚奚プロゞェクト レベルで owner なしで your-key-project を䜜成し、組織レベルで付䞎された組織管理者を指定したす。owner ずは異なり、組織管理者は盎接鍵の管理や䜿甚はできたせん。鍵の管理や䜿甚ができるナヌザヌを制限する IAM ポリシヌの蚭定に限定されたす。組織レベルのノヌドを䜿甚するず、組織内のプロゞェクトに察する暩限をさらに制限するこずができたす。

トラフィック管理 Traffic DirectorCloud Service Mesh

Cloud Service Mesh では、メッシュ内のすべおのサヌビスのサヌビス レゞストリを名前別およびそれぞれの゚ンドポむント別に管理したす。このリストを維持しお、トラフィック フロヌKubernetes Pod の IP アドレス、マネヌゞド むンスタンス グルヌプ内の Compute Engine VM の IP アドレスなどを管理したす。メッシュは、このサヌビス レゞストリを䜿甚しおサヌビスず同時にプロキシを実行するこずで、適切な゚ンドポむントにトラフィックを転送したす。プロキシレス gRPC ワヌクロヌドは、Envoy プロキシを䜿甚するワヌクロヌドず䞊行しお䜿甚するこずもできたす。

むンスタンス メタデヌタ サヌバヌCloud Run

Cloud Run むンスタンスは、プロゞェクト ID、リヌゞョン、むンスタンス ID、サヌビス アカりントなど、コンテナに関する詳现情報を取埗するために䜿甚できるメタデヌタ サヌバヌを公開したす。メタデヌタ サヌバヌを䜿甚しお、サヌビス ID のトヌクンを生成するこずもできたす。メタデヌタ サヌバヌのデヌタにアクセスするには、Metadata-Flavor: Google ヘッダヌを䜿甚しお http://metadata.google.internal/ ゚ンドポむントに HTTP リク゚ストを送信したす。

BigQuery Job User

BigQuery Job User (roles/bigquery.jobUser)

  • Provides permissions to run jobs, including queries, within the project.
  • プロゞェクト内でク゚リを含むゞョブを実行する暩限を付䞎したす。

コンピュヌティング容量を倉曎するCloud Spanner

むンスタンスを䜜成した埌で、そのコンピュヌティング容量を増やすこずができたす。ほずんどの堎合、リク゚ストは数分で完了したす。たれに、スケヌルアップが完了するたでに最倧 1 時間かかるこずがありたす。...

コンピュヌティング容量を削陀するずきは、Cloud Monitoring で CPU 䜿甚率ずリク゚スト レむテンシをモニタリングし、リヌゞョンのむンスタンスで CPU 䜿甚率が 65% を䞋回り、マルチリヌゞョンのむンスタンスの各リヌゞョンで 45% を䞋回るようにしおください。コンピュヌティング容量の削陀䞭に、リク゚ストのレむテンシが䞀時的に増加する堎合がありたす。

Cloud Trace ず Zipkin の䜿甚

Zipkin サヌバヌは、アプリケヌションが Zipkin でむンストゥルメントされおいるが、独自のトレヌス バック゚ンドを実行したくない堎合や、Cloud Trace の高床な分析ツヌルを利甚したいずう堎合に圹立ちたす。

GKEベストプラクティス掚奚

リヌゞョンクラスタヌは、3぀のKubernetesコントロヌルプレヌンクォヌラムで構成され、ゟヌンクラスタヌがクラスタヌのコントロヌルプレヌンAPIに提䟛できるよりも高い可甚性を提䟛したす。たた、コントロヌルプレヌンが利甚できない堎合、ノヌドで実行されおいる既存のワヌクロヌドは圱響を受けたせんが、䞀郚のアプリケヌションはクラスタヌAPIの可甚性に倧きく䟝存しおいたす。これらのワヌクロヌドには、リヌゞョンクラスタヌトポロゞを䜿甚するこずをお勧めしたす。

初期化期間旧称クヌルダりン期間GCE

初期化期間旧称クヌルダりン期間は、VM むンスタンスでアプリケヌションが初期化されるのにかかる時間です。アプリケヌションがむンスタンスで初期化されおいる間に、むンスタンスの䜿甚状況は通垞の状況を反映しおいない可胜性がありたす。 : むンスタンスの初期化に芁する時間よりも倧幅に長い初期化期間の倀を蚭定するず、オヌトスケヌラヌが適正な䜿甚率デヌタを無芖しおしたう可胜性がありたす。その結果、グルヌプの必芁なサむズが過小評䟡され、スケヌルアりトの遅延が生じるこずがありたす。

Gateway API リ゜ヌスGKEネットワヌク

図が有益

Kubernetes Service ずは

Service の目的は、䞀連の Pod ゚ンドポむントを 1 ぀のリ゜ヌスにグルヌプ化するこずです。このグルヌプにアクセスするさたざたな方法を構成できたす。デフォルトでは固定クラスタ IP アドレスを取埗し、クラスタ内のクラむアントはそれを䜿っお Service 内の Pod ず通信できたす。

クラスタの可甚性タむプGKE

ベスト プラクティス:

  • 本番環境ワヌクロヌドには、ゟヌンクラスタよりも可甚性が高いリヌゞョン クラスタを䜿甚したす。開発環境の堎合は、ゟヌン ノヌドプヌルを䜿甚するリヌゞョン クラスタを䜿甚したす。リヌゞョン コントロヌル プレヌンずゟヌン ノヌドプヌルを䜿甚するクラスタの費甚は、ゟヌンクラスタず同じです。

ネットワヌク分離の遞択肢GKE

ベスト プラクティス:

  • Cloud NAT を䜿甚しお、GKE Pod がパブリック IP アドレスでリ゜ヌスにアクセスできるようにしたす。Cloud NAT を䜿甚するず、Pod は盎接むンタヌネットに公開されたせんが、むンタヌネットに接続するリ゜ヌスにはアクセスできるため、クラスタの党䜓的なセキュリティ ポスチャヌが向䞊したす。

GKE クラスタのアヌキテクチャ

構成図が有益

コンテナログを曞き蟌むCloud Run ログ

サヌビスたたはゞョブからログを䜜成する堎合、ログの出力先が次のいずれかであれば、Cloud Logging によっおログが自動的に取埗されたす。

  • 暙準出力stdoutたたは暙準゚ラヌstderrストリヌム
  • /var/log ディレクトリにあるすべおのファむル
  • syslog/dev/log
  • Cloud Logging クラむアント ラむブラリを䜿甚しお䜜成されたログ。このログは、倚くの䞀般的な蚀語で利甚可胜です。

ほずんどのデベロッパヌは、ログの出力先ずしお暙準出力ず暙準゚ラヌを想定しおいたす。

フレヌムグラフCloud Profiler

Cloud Profiler では、フレヌムグラフを䜿甚しおプロファむリング デヌタが衚瀺されたす。フレヌムグラフでは、ツリヌや他のグラフより画面スペヌスが効率的に䜿甚され、倧量の情報がコンパクトで読みやすい圢匏で衚瀺されたす。 枠には関数の名前が付き、その幅はその関数の合蚈 CPU 時間の枬定倀に盞察した長さになりたす。

リク゚スト レヌトを埐々に増やすCloud Strage

Cloud Storage の自動スケヌリングを垞に最適に機胜させるためには、高いリク゚スト レヌトが数日間なかったバケットや、オブゞェクト キヌの新しい範囲を持぀バケットのリク゚スト レヌトを埐々に増やす必芁がありたす。毎秒の曞き蟌みリク゚ストが 1,000 件未満、たたは読み取りリク゚ストが 5,000 件未満のリク゚スト レヌトに぀いおは、増やす必芁はありたせん。リク゚スト レヌトがこれらのしきい倀を超えるず予想される堎合は、しきい倀より䜎いたたは近いリク゚スト レヌトから埐々にレヌトを䞊げおいきたす。ただし、20 分間でレヌトが倍にならないようにする必芁がありたす。 レむテンシや゚ラヌレヌトの増倧などの問題が発生した堎合は、䞀時的にリク゚スト レヌトの段階的な増加を䞭止するか、リク゚スト レヌトを枛らしお、Cloud Storage でバケットがスケヌリングされるたでもうしばらく埅っおみたす。指数バックオフを䜿甚しおリク゚ストを再詊行するのは、次のようなずきです。

  • 408 ず 429 のレスポンス コヌドで゚ラヌが発生する。
  • 5xx レスポンス コヌドで゚ラヌが発生する。

uptime checksCloud Monitoring

HTTP ず HTTPS の堎合、すべおの URL リダむレクトを行い、皌働時間チェックで受信した最終的なレスポンスを䜿甚しお成功基準を評䟡したす。HTTPS チェックの堎合、SSL 蚌明曞の有効期限は、最埌のレスポンスで受信したサヌバヌ蚌明曞に基づいお蚈算されたす。

障害埩旧アヌキテクチャCloud SQL 図を芁確認

Cloud SQL の 2 ぀のむンスタンスプラむマリ むンスタンスずスタンバむ むンスタンスは、単䞀のリヌゞョンプラむマリ リヌゞョン内の 2 ぀の別々のゟヌンにありたす。むンスタンスは、リヌゞョン氞続ディスクを䜿甚しお同期されたす。

Cloud SQLクロスリヌゞョン リヌドレプリカの 1 ぀のむンスタンスが 2 番目のリヌゞョンセカンダリ リヌゞョンにありたす。DR の堎合、クロスリヌゞョン リヌドレプリカは、リヌドレプリカの蚭定を䜿甚しお非同期レプリケヌションを䜿甚プラむマリ むンスタンスずの同期をずるように蚭定されたす。