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

Professional Cloud Database Engineer

🌞 合栌2025幎03月07日

合栌メモ

感想

  • 問題数50問
  • 100/120 皋床で1呚完了→ 15分皋床で芋盎し完了し終了
  • 予想埗点率は75%~85%

初めおの英語の詊隓であったが、集䞭力が日本語詊隓よりも発揮できたこずでなんずかなった。時間も、問題をなんずか理解できたこずや、短文の問題も半分くらいあったためなんずかなった。 英語の単語がわからない関係で解けない問題は倚分,問 くらいだったず想像する。 芋たこずのある問題が倚数あった。たた、出題傟向もUdemyの問題集の範囲から逞脱しおいる問題はなかったので、狭い範囲の問題を䜿い回しおいる可胜性が高いこずを想像できた。

出題傟向

  • Spanner
  • Cloud SQL
  • Datastream / Dataproc
  • 可甚性やフォヌマンスチュヌニングに関する問題
  • 認蚌認可
  • CMEK

詊隓抂芁

受隓情報 2025 幎 3 月 7 日​

詊隓名: Professional Cloud Database Engineer オフラむン詊隓・吉谷ビル7階 2025幎3月7日15:00 (JST)

🔥受隓に向けた戊略🔥​

孊習戊略​
苊手項目​

リヌドレプリカ Cloud SQL

リヌドレプリカを䜿甚しお Cloud SQL むンスタンスから䜜業をオフロヌドしたす。リヌドレプリカずは、プラむマリ むンスタンスの正確なコピヌです。プラむマリ むンスタンスのデヌタやその他の倉曎は、リヌドレプリカでほがリアルタむムで曎新されたす。 リヌドレプリカは読み取り専甚です。曞き蟌みはできたせん。リヌドレプリカは、ク゚リ、読み取りリク゚スト、アナリティクス トラフィックを凊理し、プラむマリ むンスタンスの負荷を䜎枛したす。

ク゚リタグでフィルタリングする cloud SQL

アプリケヌションのトラブルシュヌティングを行うには、最初に SQL ク゚リにタグを远加する必芁がありたす。

デヌタベヌスの保護Terraform on Google Cloud

デヌタベヌスなどのステヌトフル リ゜ヌスの堎合は、削陀保護deletion_protectionが有効になっおいるこずを確認したす。次に䟋を瀺したす。

Cloud SQL むンスタンスの Recommender

オヌバヌプロビゞョニングされた Cloud SQL むンスタンスの Recommender は、30 日以䞊経過したプラむマリ むンスタンスの䜿甚状況の指暙を分析したす。この Recommender は、むンスタンスごずに過去 30 日間の特定の指暙倀に基づいお CPU ずメモリの䜿甚率を分析したす。Recommender はリヌドレプリカを分析したせん。

MongoDB Atlas ずは

MongoDB Atlas は、MongoDB の構築に埓事する人々が手掛けるマルチクラりド デヌタベヌス サヌビスです。デヌタベヌスの配眮ず管理を簡玠化し、遞択したクラりドプロバむダヌで堅牢で高性胜なグロヌバルアプリケヌションを構築するために必芁な柔軟性を提䟛したす。

珟圚進行䞭実行䞭のオペレヌションのステヌタスを確認Cloud SQL

Google Cloud コン゜ヌルでは、オペレヌションの完了時に成功たたは倱敗のみが衚瀺されたす。譊告やその他の情報を衚瀺するように蚭蚈されおいたせん。 特定の Cloud SQL むンスタンスのすべおのオペレヌションを確認するには、gcloud sql operations list コマンドを実行したす。

Database Migration Service移行元の必芁な蚭定

移行元むンスタンスに pglogical パッケヌゞをむンストヌルし、 shared_preload_libraries 倉数に含たれおいるこずを確認したす

デフォルトのリヌダヌ リヌゞョンを構成するSpanner

デヌタベヌスのデフォルト リヌダヌ リヌゞョンの堎所を倉曎しお、接続するクラむアントに近づけるこずでアプリケヌションのレむテンシを短瞮

Spanner から Avro にデヌタベヌスを゚クスポヌトする

゚クスポヌト プロセスでは、Dataflow を䜿甚しお、Cloud Storage バケット内のフォルダにデヌタを曞き蟌みたす。凊理埌のフォルダには、䞀連の Avro ファむルず JSON マニフェスト ファむルが栌玍されたす。

ストレヌゞの自動増量automatic-storage-increaseを有効にするCloud SQL

この蚭定を有効にするず、Cloud SQL によっお利甚可胜なストレヌゞが 30 秒ごずにチェックされたす。利甚可胜なストレヌゞがしきい倀サむズを䞋回るず、自動的にストレヌゞ容量が远加されたす。利甚可胜なストレヌゞがしきい倀サむズを繰り返し䞋回る堎合、最倧 64 TB に達するたで続けおストレヌゞが远加されたす。

Firestore の抂芁

Firestore は、Firebase ず Google Cloud からのモバむル、りェブ、サヌバヌ開発に察応した、柔軟でスケヌラブルなデヌタベヌスです。 リアルタむム リスナヌを介しおクラむアント アプリ間でデヌタを同期し、モバむルずりェブのオフラむン サポヌトを提䟛したす。これにより、ネットワヌク レむテンシやむンタヌネット接続に関係なく機胜するレスポンシブ アプリを構築できたす。

Google Cloud に移行する: 倧芏暡なデヌタセットを転送する

デヌタ転送の時間やメゞャヌパタヌンなど時間があれば䞀読すべきたずめ蚘事

高可甚性に぀いお SQL手軜最適な可甚性

HA 構成では、デヌタの冗長性が確保されたす。HA 向けに構成された Cloud SQL むンスタンスはリヌゞョン むンスタンスずも呌ばれ、構成されたリヌゞョン内にプラむマリ ゟヌンずセカンダリ ゟヌンがありたす。*リヌゞョン むンスタンスはプラむマリ むンスタンスずスタンバむ むンスタンスで構成されたす。各ゟヌンの氞続ディスクぞの同期レプリケヌションにより、トランザクションが commit されたずしおレポヌトされる前に、プラむマリ むンスタンスぞの曞き蟌みのすべおが䞡方のゟヌンのディスクに耇補されたす。むンスタンスたたはゟヌンに障害が発生した堎合、スタンバむ むンスタンスが新しいプラむマリ むンスタンスになりたす。ナヌザヌは新しいプラむマリに再転送されたす。このプロセスは、フェむルオヌバヌず呌ばれたす。

゚クスポヌトのパフォヌマンスぞの圱響を最小限に抑えるCloud SQL

  1. リヌドレプリカから゚クスポヌトを取埗したす。゚クスポヌトを頻繁に毎日たたはそれ以䞊の頻床で行う堎合、゚クスポヌトされるデヌタ量が少なければ、これが適切な遞択肢になりたす。
  2. サヌバヌレス ゚クスポヌトCloud SQL ServerLess゚クスポヌトを䜿甚したす。倧芏暡なデヌタベヌスの 1 回限りの゚クスポヌトを䜜成する堎合は、これが適切な遞択肢になりたす。

Google Cloud VMware Engine

Google Cloud VMware Engine は、 Google Cloudで VMware プラットフォヌムを運甚できるフルマネヌゞド サヌビスです。VMware Engine では、クラりド消費モデルのメリットを享受し総所有コストを䜎枛できるように、VMware 運甚の継続性を実珟したす。

デフォルトのメンテナンスの時間枠Default maintenance windowsCloud SQL

むンスタンスのトラフィック凊理量が最も少ない時間垯日曜日の深倜 0 時頃にメンテナンスを行いたいず考えおいたす。たた、幎末商戊の繁忙期はメンテナンスを避ける必芁がありたす。この堎合、本番環境のむンスタンスのメンテナンスを次のように蚭定 → Cloud SQLでのメンテナンス時間の蚭定が可胜

CMEKずCSEK

顧客管理鍵(CMEK)による暗号化は、ナヌザがCloud KMSを䜿甚しお鍵を管理したす。
顧客提䟛鍵(CSEK)による暗号化は、ナヌザ自身が鍵を䜜成し管理したす。

  • CMEK: Customer-Managed Encryption Keys
  • CSEK: Customer-Supplied Encryption Keys

Query Insights Cloud SQL

Query Insights では、Cloud SQL デヌタベヌスに察するク゚リ パフォヌマンスの問題を怜出、蚺断、防止できたす。盎感的なモニタリングをサポヌトし、怜出するだけでなくパフォヌマンスの問題の根本原因の特定に圹立぀蚺断情報を提䟛したす。

Spanner : LIKE 非掚奚

Spanner はパラメヌタ化された LIKE パタヌンを実行時たで評䟡しないので、すべおの行を読み取っお LIKE 匏で評䟡し、䞀臎しない行を陀倖しなければなりたせん。 LIKE パタヌンの圢匏が foo%たずえば、固定文字列で始たり、単䞀のワむルドカヌド パヌセントで終わるで、列にむンデックスが付けられおいる堎合、LIKE の代わりに STARTS_WITH を䜿甚したす。このオプションを䜿甚するず、Spanner はク゚リ実行プランをより効果的に最適化できたす。

䞊列レプリケヌションを構成するCloud SQL

レプリケヌション ラグは、リヌドレプリカの曎新がプラむマリ むンスタンスの曎新よりも遅れた堎合に発生したす。このセクションでは、ナヌザヌが䞊列レプリケヌションを有効にしお、レプリケヌション ラグを枛らす

高可甚性を有効たたは無効にする Cloud SQL

むンスタンスの高可甚性は、むンスタンスを䜜成するずきに構成するこずも、既存のむンスタンスで有効にするこずもできたす。gcloud sql instances patch INSTANCE_NAME \ ...

SSD ストレヌゞず HDD ストレヌゞを切り替えるCloud SQL

Cloud SQL むンスタンスを䜜成した埌は、そのむンスタンスでの SSD ストレヌゞたたは HDD ストレヌゞの遞択は倉曎できたせん。 既存の HDD むンスタンスを SSD にたたはその逆に倉曎する必芁がある堎合には、既存のむンスタンスからデヌタを゚クスポヌトし、新芏むンスタンスにデヌタをむンポヌトしたす。むンスタンス党䜓の移行には時間がかかりたす。

HDD ストレヌゞのナヌスケヌスCloud SQL

10 TB 以䞊のデヌタを保存する予定である。 ※ 倧量のデヌタを保存しない限り、HDD によるコスト削枛はごくわずかです。10 TB 以䞊のデヌタを保存する堎合以倖は、HDD ストレヌゞの䜿甚を怜蚎する必芁はありたせん。

Rotate server CA certificatesCloud SQL

  • 新しいサヌバヌを䜜成したす。
  • 新しいサヌバヌCA蚌明曞情報をダりンロヌドしたす。
  • クラむアントを曎新しお、新しいサヌバヌCA蚌明曞情報を䜿甚したす。
  • アクティブな蚌明曞を移動する回転を完了したす 「前の」スロットは、新しく远加された蚌明曞を アクティブな蚌明曞。

How to Achieve PostgreSQL High Availability with pgBouncer : PostgreSQL

デヌタベヌス接続のプヌリングにPGBouncerを䜿甚するこずは、クラりドSQLプラむマリず読み取りレプリカむンスタンスの間にアプリケヌション負荷を均等に配垃し、デヌタベヌスのパフォヌマンスずリ゜ヌスの利甚を最適化するための適切な遞択です

マルチリヌゞョン構成のパフォヌマンスに関するベスト プラクティスSpanner

最適な曞き蟌みレむテンシを実珟するには、曞き蟌みの倚いワヌクロヌドのコンピュヌティング リ゜ヌスをデフォルトのリヌダヌ リヌゞョン内たたはその近くに配眮したす。

Spanner から Avro にデヌタベヌスを゚クスポヌトする

REST API たたは Google Cloud CLI を䜿甚しお Spanner デヌタベヌスを゚クスポヌトするには、このペヌゞのはじめにの手順を完了し、Dataflow ドキュメントの Spanner to Cloud Storage Avro の詳现な手順を参照しおください。゚クスポヌト プロセスでは、Dataflow を䜿甚しお、Cloud Storage バケット内のフォルダにデヌタを曞き蟌みたす。凊理埌のフォルダには、䞀連の Avro ファむルず JSON マニフェスト ファむルが栌玍されたす。

パフォヌマンスオヌバヌヘッドなしで Cloud SQL からデヌタを゚クスポヌト

 Cloud SQL  Serverless Exportsの新しい機胜を起動したした。 ServerLess゚クスポヌトを䜿甚するず、PerformanceたたはRisksのリスクに圱響を䞎えずに、MySQLおよびPostgreSQLデヌタベヌスむンスタンスからデヌタを゚クスポヌトできたす。

ファむル システムずパヌティションのサむズを倉曎するGCE

非ブヌト デヌタディスク䞊のファむル システムのサむズを倉曎したす。 ext4 を䜿甚しおいる堎合は、resize2fs コマンドを䜿甚しおファむル システムを拡匵したす。 sudo resize2fs /dev/DEVICE_NAME

自動フェむルオヌバヌBigtable

アプリのプロファむルで耇数クラスタ ルヌティングを䜿甚しおいる堎合、 Bigtable は自動的にフェむルオヌバヌを凊理したす。最も近いクラスタがリク゚ストを凊理できない堎合、Bigtable は察応可胜な最も近いクラスタにトラフィックをルヌティングしたす。

移行元むンスタンスを構成するDatabase Migration Service  > PostgreSQL

移行元むンスタンスに pglogical パッケヌゞをむンストヌルし、 shared_preload_libraries 倉数に含たれおいるこずを確認したす。 環境の移行元むンスタンスに pglogical パッケヌゞをむンストヌルするをご芧ください。

メンテナンスの圱響を最小限に抑えるCloud SQL

接続の切断による圱響を最小限に抑えるには、接続プヌルを䜿甚したす。プヌラヌずデヌタベヌスの間の接続はメンテナンス䞭に切断されたすが、アプリケヌションずプヌラヌの間の接続は保持されたす。これにより、接続の再確立がアプリケヌションに察しお透過的になり、接続プヌラヌにオフロヌドされたす。 長時間実行トランザクションの数を制限するこずで、トランザクションの倱敗を枛らすこずができたす。ク゚リを小さくしお、より効率的に曞き換えるこずで、メンテナンスのダりンタむムが短瞮されるだけでなく、デヌタベヌスのパフォヌマンスず信頌性も向䞊したす。

接続の切断やトランザクション ゚ラヌから効率的に埩旧するには、効率的にデヌタベヌス接続を管理したす。指数バックオフを䜿甚しお、アプリケヌションず接続プヌラヌに接続ずク゚リの再詊行ロゞックを構築できたす。ク゚リが倱敗した堎合、たたは接続が切断された堎合、システムは再詊行の前に埅機期間を蚭定したす。埅機時間は、埌続の再詊行ごずに増加したす。たずえば、最初の再詊行ではシステムは数秒しか埅機したせんが、4 回目の再詊行では最倧で 1 分間埅機する堎合がありたす。このパタヌンに埓うこずで、サヌビスに過倧な負荷をかけるこずなく、これらの問題を確実に修正できたす。

スキヌマ曎新のパフォヌマンスCloud Spanner

Spanner のスキヌマの曎新には、ダりンタむムは必芁ありたせん。DDL 文のバッチを Spanner デヌタベヌスに察しお発行した堎合、Spanner が曎新を長時間実行オペレヌションずしお適甚する間も、䞭断なくデヌタベヌスでの曞き蟌みず読み取りを続けるこずができたす。

クロスリヌゞョン レプリカCloud SQLデヌタ移行

クロスリヌゞョン レプリカを䜿甚するず、最小限のダりンタむムでデヌタベヌスを別のリヌゞョンに移行できたす。通垞は、別のリヌゞョンにレプリカを䜜成し、レプリケヌションが完了したらレプリカを昇栌させ、新しく昇栌したむンスタンスにクラむアントをリダむレクトしたす。

ベアメタル向け Google Distributed CloudGDC for bare metal 

Anthos clusters on bare metal は、ベアメタル向け Google Distributed Cloud゜フトりェアのみになりたした。詳现に぀いおは、プロダクトの抂芁をご芧ください。

Google Distributed Cloud は、Google Cloud のむンフラストラクチャずサヌビスをお客様のデヌタセンタヌオンプレに拡匵する Google の゜リュヌションです。Google Distributed Cloud は、Google 提䟛のハヌドりェア䞊で動䜜する接続された構成ず゚アギャップのある構成の䞡方で䜿甚できたす。

倖郚サヌバヌにデヌタを移行するCloud SQL デヌタ移行

デヌタのプラむマリ コピヌを Cloud SQL から倖郚サヌバヌに最小限のダりンタむムで移行するには、倖郚サヌバヌを倖郚レプリカずしおセットアップしおから、その倖郚サヌバヌのレプリカになるように Cloud SQL むンスタンスを降栌したす。

ポむントむンタむム リカバリPITRを䜿甚する Cloud SQL

Cloud SQL は PITR にバむナリログを䜿甚したす。 2023 幎 8 月 11 日、Google は、PITR のトランザクション ログの Cloud Storage ぞの保存を開始したした。今回のリリヌス以降、次の条件が適甚されたす。

Cloud Spanner ノヌド数 ノヌド数の倉曎蚭定

線集画面からノヌド数の倉曎するだけで蚭定倉曎完了 ダりンタむムなしで倉曎可胜

exactly-once ストリヌミングDataflowトランザクション的凊理

非確定的な凊理を効果的に確定的な凊理にするには、チェックポむンティングを䜿甚したす。チェックポむンティングを䜿甚するず、倉換からの各出力は、次のステヌゞに配信される前に、䞀意の ID を持぀安定したストレヌゞにチェックポむントが蚭定されたす。Dataflow のシャッフル配信の再詊行は、チェックポむントされた出力をリレヌしたす。コヌドが耇数回実行される堎合でも、Dataflow は、それらの実行のうちの 1 ぀だけの出力が保存されるようにしたす。Dataflow は敎合性ストアを䜿甚しお、安定したストレヌゞぞの曞き蟌みが重耇しないようにしたす。

デュアルリヌゞョン クォヌラムの可甚性Cloud Spanner

デュアルリヌゞョン クォヌラムの可甚性instance/dual_region_quorum_availabilityは、デュアルリヌゞョン むンスタンス構成でのみ䜿甚できたす。デュアルリヌゞョン クォヌラムず各リヌゞョンの単䞀リヌゞョン クォヌラムの 3 ぀のクォヌラムの健党性のタむムラむンが衚瀺されたす。 グラフには、クォヌラムの可甚性プルダりンがあり、正垞モヌドたたは䞭断モヌドのリヌゞョンを確認できたす。このグラフを゚ラヌ率ずレむテンシの指暙ずずもに䜿甚するず、リヌゞョン障害が発生した堎合に、セルフマネヌゞド フェむルオヌバヌのタむミングを決定できたす。

Google Kubernetes Engine から Cloud SQL に接続するGKE / Cloud SQL

Cloud SQL Auth Proxy は、sidecar パタヌンでPod をアプリケヌションず共有する远加のコンテナずしお動䜜させるこずをおすすめしたす。次のいく぀かの理由から、これを個別のサヌビスずしお実行するよりも、この方法をおすすめしたす。

SQL トラフィックがロヌカルで公開されないようにしたす。Cloud SQL Auth Proxy は送信接続を暗号化したすが、受信接続の公開を制限する必芁がありたす。

レプリケヌション構成の䟋Bigtable

このペヌゞでは、Bigtable レプリケヌションの䞀般的なナヌスケヌスに぀いお説明し、これらのナヌスケヌスをサポヌトするために䜿甚できる蚭定を玹介したす。

Cloud SQLにおけるHTTPステヌタス゚ラヌを簡朔にたずめた衚​
HTTP ステヌタス゚ラヌ番号゚ラヌメッセヌゞ堎面/原因
400Bad Requestリク゚ストの圢匏が䞍正䟋: 必芁なパラメヌタ䞍足、無効な倀
401Unauthorized認蚌情報無効、アクセス暩限が䞍足しおいる堎合
403Forbiddenアクセス暩限がない、IAM蚭定によりアクセス拒吊される堎合
404Not Found指定したリ゜ヌスが存圚しない堎合䟋: 䞍正なリ゜ヌスID
409Conflictリ゜ヌスの競合、むンスタンス䜜成時の競合など
429Too Many RequestsAPIリク゚ストが制限を超えた堎合リク゚スト過倚
500Internal Server Errorサヌバ偎で予期しない゚ラヌが発生した堎合
502Bad Gatewayゲヌトりェむたたはプロキシで゚ラヌが発生した堎合
503Service Unavailableサヌビス停止䞭やメンテナンス䞭、サヌバが䞀時的に䜿甚䞍可
504Gateway Timeoutリク゚ストがタむムアりトした堎合䟋: 長時間埅機埌にタむムアりト
受隓圓日のTODOPSE / PNE / PDE / PCA 受隓時の成功事䟋 ⭐

前日

  • しっかり寝る
    • アむマスク、耳栓、枕のセッティング

圓日

  • 9時たでに起きる疲劎が回埩しおいるこずが重芁

  • カフェで詊隓前の確認を実斜

    • 気分的にドトヌル倧通り店
      • 公匏暡詊 の間違った問題を埩習
      • 苊手項目の埩習
      • 問題集で間違った問題の埩習
      • その他、重芁蚘事を読曞

  • 14:00 にカフェを出る

  • 受隓メヌルを印刷する

    • アプリにメヌルを転送

  • 䌚堎到着前に仮眠を10分皋床取り、十分に脳をリフレッシュさせる

    • 糖分も十分にずる

  • 15時00分テスト開始の30分前には䌚堎に到着しお受付を完了させる

    • 遞択肢から読むこずを意識する
    • 芋盎しの時間を確保するよう意識する