Google ACE: ストレージ、データベース、データサービス — 学習ガイド

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

こちらの一部です： Google Associate Cloud Engineer — 学習ガイド. 検証済みの解答で練習： Google試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

このセクションでは、Google Cloudのストレージ、データベース、分析データサービスに関する、運用に焦点を当てた実践的なリファレンスを提供します。構成パターン、アクセス制御、耐久性メカニズム、パフォーマンスとコストの特性、そして安全な復旧プラクティスに重点を置いています。その目的は、特定のワークロードにどのサービスを使用するかを決定し、運用上のトレードオフを理解し、一般的な障害モードを予測するのに役立つことです。

Cloud Storageの設計、アクセス、ライフサイクル、保護

Cloud Storageは、非構造化データやバックアップのための、耐久性と可用性の高いオブジェクトストレージです。

• バケットとオブジェクト: バケットは、ロケーション（リージョンまたはデュアル/マルチリージョン）内に存在するグローバルな名前空間であり、不変のオブジェクトバージョンを格納します。下り（エグレス）を最小限に抑え、データ所在地の要件を満たすようにバケットのロケーションを選択します。
• ストレージクラス: アクセス頻度に応じて、Standard（ホット）、Nearline（最小約30日）、Coldline（最小約90日）、Archive（最小約365日）を使用します。DR（災害復旧）バックアップには、Coldlineが一般的なデフォルトです。バケット内でオブジェクトごとにクラスを混在させることができます。
• ライフサイクルルール: Age、CreatedBefore、MatchesStorageClass、NoncurrentVersionといった条件によって、移行と削除を自動化します。90日で移行し、365日で削除する例：
  1. lifecycle.json: { “rule”: [ {“action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 90}}, {“action”: {“type”: “Delete”}, “condition”: {“age”: 365}} ] }
  2. 適用: gsutil lifecycle set lifecycle.json gs://my-bucket
• 保持ポリシーとリーガルホールド: 保持ポリシーは、期間が経過する前のオブジェクトの削除や変更を防ぎます。ポリシーのロックは元に戻せません。リーガルホールドはオブジェクトごとに設定され、削除する前に解除する必要があります。

アクセス制御と共有:

• 均一 vs 詳細: IAMのみで権限を管理するために、均一なバケットレベルのアクセス（UBLA）を推奨します。詳細アクセス（オブジェクトACL）はレガシーであり、可監査性と権限の伝播を複雑にします。UBLAを有効にするとACLが無効になり、ACLに依存していた既存のインテグレーションに即座に影響を与える可能性があります。
• 署名付きURL: Google IDなしでの短期的なアクセスには、署名付きURLを使用します。IAMで署名することにより、サービスアカウントのキーファイルの使用を避けます: gcloud storage sign-url gs://my-bucket/path/object –duration=4h –impersonate-service-account sa-sharing@proj.iam.gserviceaccount.com サービスアカウントが自身に対して、または署名者のロールを介して、サービスアカウントトークン作成者の権限を持っていることを確認してください。
• 暗号化: デフォルトでサーバー側の暗号化が有効です。鍵と監査証跡の管理が必要な場合は、バケットまたはオブジェクト単位のスコープでCMEKを有効にします。KMSキーの可用性とローテーションを監視してください。CMEKが利用できない場合、アップロードと復号がブロックされます。
• バージョニング: オブジェクトのバージョニングを有効にすると、上書き/削除後も非現行バージョンが保持されます。ライフサイクルルールと組み合わせて非現行バージョンを期限切れにし、ストレージの増加を制御します。多数のバージョンが存在する場合、クライアント側のリストロジックに注意してください。

障害モードと緩和策:

• 偶発的な削除または上書き: バージョニングと保持ポリシーを使用します。厳格なコンプライアンスのためには、保持ポリシーをロックします。
• パブリックアクセスの設定ミス: パブリックアクセス防止とUBLAを強制します。Cloud Asset InventoryとPolicy Analyzerで定期的に監査します。
• 過剰なコスト: ライフサイクルルール、オブジェクトレベルのクラス、リクエスタ支払いを活用することで、予期せぬコストを削減します。Cloud Monitoringのメトリクスと予算で監視します。

便利なコマンド:

• UBLAと保持ポリシーを設定してバケットを作成: gcloud storage buckets create gs://my-bucket –location=us-central1 –uniform-bucket-level-access –default-storage-class=STANDARD gcloud storage buckets update gs://my-bucket –retention-period=365d

コンピューティングワークロード向けのブロックストレージとファイルストレージ

Compute EngineとGKEのストレージは、アクセスパターン、パフォーマンス要件、耐久性要件に基づいて選択します。

• Persistent Disk (PD): 耐久性のあるブロックストレージで、ゾーンまたはリージョン単位で利用できます。種類: シーケンシャルスループット向けのStandard (HDD)、低レイテンシと高IOPS向けのBalanced (pd-balanced) および SSD (pd-ssd)。リージョンPDはゾーン間で同期的に複製され、より高速な復旧を可能にします。PDはスナップショットを作成したり、オンラインでサイズ変更したり、複数のVMに読み取り専用でアタッチしたりできます（読み書き用にはシングルライター）。
  • トレードオフ: SSDではIOPSコストが高くなります。HDDはコスト効率が良いですが、ランダムIOでは高レイテンシです。リージョンPDはコストが高いですが、RTOを削減します。
• Local SSD: NVMeまたはSCSIで接続されたエフェメラルストレージで、非常に高いIOPSと低レイテンシを特徴とします。データはVMの停止やホストメンテナンス時に失われます。エフェメラルなキャッシュや複製されたデータにのみ使用してください。データ損失を避けるために、他の場所にバックアップまたは複製してください。
• Filestore: POSIX準拠の共有ファイルセマンティクスを提供するマネージドNFSです。Basicティアはゾーン単位です。Enterprise以上のティアは、同期複製とより高いIOPSを備えたリージョンHA（高可用性）を提供します。GCVE、HPCのスクラッチ領域、メディアレンダリング、共有ファイルロックを必要とするアプリに最適です。
  • トレードオフ: NFSはクライアント側のキャッシュとロックセマンティクスを導入します。スループットとレイテンシはティアによって異なります。Local SSDのような1桁マイクロ秒のレイテンシでの小さなランダムIOには適していません。

障害に関する考慮事項:

• ホストメンテナンス: Local SSDのデータが失われます。アプリケーションレベルのレプリケーションで保護してください。
• ゾーン障害: ゾーンPDとBasicティアのFilestoreが中断します。HAのためにはリージョンPDまたはFilestore Enterpriseを使用してください。
• スナップショットの整合性: アプリケーション整合性のあるPDスナップショットを作成するには、ファイルシステムのフリーズやデータベースネイティブの静止と連携し、クラッシュリカバリウィンドウを回避します。

マネージドデータベースとデータサービス

Cloud SQL (マネージドMySQL, PostgreSQL, SQL Server):

• 設定: マシンシェイプ、ストレージタイプ、接続（プライベートIP推奨）、パブリックIPを使用する場合は承認済みネットワーク、メンテナンスウィンドウ、パフォーマンス診断のためのInsightsを選択します。コネクションプーリング（例: Cloud SQL Auth Proxy, PGbouncer）を使用して、接続数とCPUの上限内に収めます。
• 高可用性: リージョンHAインスタンスは、同期ストレージレプリケーションを使用して別のゾーンにスタンバイをデプロイします。フェイルオーバーは自動です。フェイルオーバー中は、短い書き込み不可の時間が発生することを想定します。
• レプリカ: 読み取りのスケーリングとBIのオフロードのためのリードレプリカ、移行のための外部レプリケーション。レプリカラグを監視し、べき等なリーダーを設計します。
• バックアップとPITR: 自動バックアップと、ポイントインタイムリカバリのためのバイナリ/WALロギングを有効にします。定期的に復元をテストします。

undefined

• 障害モード: 長時間実行されるトランザクションはvacuum/チェックポイント処理をブロックします。接続の急増はスラッシングを引き起こします。ストレージの自動拡張は、割り当てが不十分な場合に停止することがあります。CPU、メモリ、接続数、レプリカラグ、ディスク使用量に対するアラートを設定します。

Cloud Spanner:

• スケールとリージョン性: 同期レプリケーションとグローバルな強整合性を備えた、リージョンまたはマルチリージョンのインスタンス。スループットとストレージのためにノードをスケールします。リーダーリージョンの配置は書き込みレイテンシに影響します。
• スキーマとキー: ホットスポットを回避するように主キーを設計します。時系列データには、書き込みを分散させるためにハッシュ化またはランダム化されたプレフィックスを持つ複合キーを使用します。クエリパターンに合わせてセカンダリインデックスを使用し、頻繁にフィルタリングされる列をまとめて格納することを検討します。ロック競合を最小化するために、トランザクションは小さく、範囲を限定します。
• トランザクション: TrueTimeによる外部整合性を備えた、強整合性を持つ分散トランザクション。書き込みレイテンシはクォーラムによって制約されます。競合が発生するとトランザクションは中止されるため、バックオフ付きでリトライします。

FirestoreとBigtable:

• Firestore (Native mode): コレクション、リアルタイムリスナー、1トランザクションあたり最大500ドキュメントにまたがるトランザクション、ドキュメントの読み取りとほとんどのクエリに対する強整合性を備えたドキュメントストア。モバイル/Webアプリのデータ、階層的なJSON、イベント駆動型アプリに最適です。
• Bigtable: ペタバイトスケールと10ミリ秒未満のレイテンシを実現するワイドカラムデータベース。単一行トランザクションのみ。ホットスポット化を避けるように行キーを設計します。時系列、IoT、パーソナライゼーション、大規模なカウンターに最適です。アドホックな結合や複雑な集計には向きません。

Memorystore:

• RedisとMemcached: マイクロ秒からミリ秒のレイテンシを実現するインメモリキャッシュ。ベーシックティアにはHAがありません。スタンダードティアは、Redis向けに自動フェイルオーバー付きのリージョンHAを提供します。エフェメラル（一時的）なものとして扱い、正系のシステムとして使用しないでください。

BigQuery:

• データセットとテーブル: データセットごとに整理します。プロジェクト、データセット、テーブル、列、行レベルでアクセスを制御します。パーティション化テーブルとクラスタ化テーブルを使用して、スキャンされるバイト数とコストを管理します。
• 読み込みジョブとクエリジョブ: Cloud Storage、Cloud SQLのエクスポート、またはストリーミング挿入から読み込みます。ドライランを使用してコストを見積もります:

undefined

• アクセス制御: 読み取り専用のコンシューマーには、データセットスコープでBigQueryデータ閲覧者を付与します。最小権限の原則に従い、承認済みビューまたは行レベル/列レベルのセキュリティを使用します。

データの移動、移行、検証、運用のトレードオフ

移行と転送:

• Database Migration Service (DMS): レプリケーションを介して最小限のダウンタイムで Cloud SQL へ同種移行する場合に使用。ラグメトリクスとチェックサム比較でカットオーバーを検証。
• Cloud Storage 転送: 繰り返しまたはイベント駆動の転送には Storage Transfer Service を使用。チェックサム付きの1回限りの同期コピーには gsutil -m rsync を使用。大規模なオフライン移動には Transfer Appliance を使用。
• インポート/エクスポート: Cloud SQL は Cloud Storage にエクスポート。再インポートは PITR のブートストラップとデータ検証をサポート。BigQuery は Cloud Storage からのバッチロードと、ダウンストリームで使用するための Avro/Parquet へのエクスポートをサポート。
• 検証: オブジェクトのチェックサム (CRC32C)、行数、サンプリングクエリ、アプリケーションレベルの不変条件を使用。BigQuery の場合、ソースとターゲット間で GROUP BY のカウントまたはハッシュを比較。

パフォーマンス、可用性、キャパシティ、コストのトレードオフ:

• Cloud Storage: コンピュートを同じ場所に配置して下り（egress）を最適化。アクセス頻度に応じてストレージクラスを選択。ゾーン間の回復性と高可用性を実現するためにデュアル/マルチリージョンを使用（ストレージコストは高くなる）。
• PD/Filestore: 低レイテンシの IO には SSD、スループットには HDD を使用。HA のためにはリージョンレプリケーションを使用。スロットリングを避けるために IOPS を適切なサイズに設定。
• Cloud SQL: 垂直スケーリングはシンプルだが制限がある。リードレプリカは読み取りトラフィックをオフロードする。HA は可用性を追加するが、読み取りキャパシティは追加しない。ストレージクラスはレイテンシとコストに影響する。
• Spanner: 強力な整合性を保ちながら水平にスケーリング。グローバルな RPO/RTO と簡素化されたシャーディングにより、プレミアムコストが相殺される。書き込みはキー設計とリーダーリージョンのレイテンシに敏感。
• Firestore/Bigtable/Memorystore: レイテンシ、データモデル、整合性によって選択。インメモリキャッシュはデータベースの負荷を軽減するが、キャッシュ無効化の複雑さが増す。
• BigQuery: オンデマンドコストはスキャンされたバイト数に比例。パーティショニング/クラスタリングと述語プッシュダウンにより費用を削減。定額予約は、コミットメントと引き換えに予測可能性を提供する。

トラブルシューティングと安全な復旧:

• Cloud Storage: オブジェクトのバージョニングと保持ポリシーを使用して復旧。Cloud Logging のデータアクセスログを調べて読み取り/書き込みイベントを監査。復旧中に CMEK キーが有効になっていることを確認。
• PD/Filestore: スナップショットまたはバックアップから復元。fsck とデータベースのリカバリモードを実行。スナップショット作成前にアプリケーションレベルで静止させ、整合性を確保。
• Cloud SQL: プライマリでのデータ損失を避けるため、PITR のために新しいインスタンスに復元。読み取り専用テストで検証。安全なカットオーバーパターンのためにファイアウォールとプライベート DNS を維持。
• Spanner/Bigtable: キーアクセスの偏りによるホットスポットを調査。Monitoring を使用してレイテンシとスロットリングを追跡。中断されたトランザクションやレート制限されたオペレーションに対してバックオフとリトライを実装。
• BigQuery: 実行詳細を介して遅いクエリを診断。パーティションとクラスタリングを追加。SELECT * を制限。必要に応じて中間結果をマテリアライズ。タイムトラベル期間内に削除されたテーブルは、スナップショットを復元するか、スナップショット時刻からコピーして復旧。

実践的な問題シナリオ

Contoso Retail 社は、バックアップと分析データを統合すると同時に、アクセス制御を強化し、トランザクションシステムのポイントインタイムリカバリを有効にしようとしています。彼らは、自動階層化によるアプリケーションバックアップの保存、サードパーティへの短期間のファイル共有の提供、小規模なリレーショナルワークロードに対する PITR の有効化、そして実行前の分析クエリコストの見積もりを行う必要があります。

アプローチ:

1. UBLA、保持ポリシー、ライフサイクルを設定したリージョン Cloud Storage バケットを作成する。

   • コマンド: gcloud storage buckets create gs://contoso-backups –location=us-central1 –uniform-bucket-level-access –default-storage-class=STANDARD gcloud storage buckets update gs://contoso-backups –retention-period=365d gsutil lifecycle set lifecycle.json gs://contoso-backups
   • 理由: UBLA は IAM で認可を一元化し、監査可能性を向上させます。1年間の保持期間は偶発的な削除を防ぎます。ライフサイクルは、90日後にバックアップを Coldline に移行し、有効期限切れ時に削除することでコストを管理します。

2. 専用のサービスアカウントを介して、バックアップジョブに書き込み専用アクセスを許可する。

   • コマンド: gcloud storage buckets add-iam-policy-binding gs://contoso-backups –member=serviceAccount:backup-writer@contoso.iam.gserviceaccount.com –role=roles/storage.objectCreator
   • 理由: storage.objectCreator は、メタデータの改ざんや機密性の高いバックアップの読み取りを防ぎ、最小権限の原則に従います。

3. キーを配布せずに、署名付き URL を使用して機密性の高いバックアップをベンダーと4時間共有する。

   • コマンド: gcloud storage sign-url gs://contoso-backups/db-dump-2024-09-30.sql.gz –duration=4h –impersonate-service-account share-signer@contoso.iam.gserviceaccount.com
   • 理由: 期間限定のアイデンティティレスなアクセスにより、外部アイデンティティや長期間有効なシークレットの作成を回避できます。権限借用は、KMS に裏付けられた一元的な署名を使用し、キー漏洩のリスクを排除します。

4. 注文データベースに対して Cloud SQL のバックアップと PITR を有効にする。

   • コマンド: gcloud sql instances patch orders-sql –backup-start-time=02:00 –enable-bin-log
   • 理由: 自動バックアップとバイナリ/WAL ロギングを組み合わせることで、保持期間内の任意の秒への復元ポイントが提供され、論理的な破損やオペレーターのエラーから保護します。

5. 新しいインスタンスに復元してリカバリをテストし、カットオーバー前にデータを検証する。

   • コマンド: gcloud sql backups list –instance=orders-sql gcloud sql instances restore-backup orders-restore –backup-id=LATEST –destination-instance=orders-restore
   • 理由: 別のインスタンスに復元することで、本番環境への影響を避け、DNS やアプリケーションレベルの切り替え前にチェックサムやサンプルクエリによる検証が可能になります。

6. ドライランで BigQuery のクエリコストを見積もり、パーティショニングで最適化する。

   • コマンド: bq query –use_legacy_sql=false –dry_run=true ‘SELECT COUNT(*) FROM contoso.analytics.sales WHERE sale_date >= “2026-01-01”’
   • 理由: ドライランによりスキャンされるバイト数が明らかになります。sale_date がパーティション列であり、有界の述語を持つことを保証することで、スキャンされるバイト数を削減し、オンデマンドコストを管理します。

7. アクセスを監視および監査する。

   • 手順:
     • Cloud Storage と BigQuery のデータアクセスログを有効にする。
     • Cloud SQL の接続、ディスク使用量、バックアップ失敗に関する Cloud Monitoring アラートを設定する。
   • 理由: データアクセスログは、コンプライアンスのためにオブジェクトレベルの読み取り/書き込みの可視性を提供します。プロアクティブなアラートは MTTR を短縮し、バックアップと PITR が効果的に機能し続けることを保証します。

8. 障害モードとランブックを文書化する。

   • 手順:
     • オブジェクトバージョンの復元、署名付き URL の失効、Cloud SQL の PITR、タイムトラベルを使用した BigQuery テーブルの復旧手順を記録する。
   • 理由: 明確でテスト済みのランブックは、インシデント発生時の運用リスクを低減し、チーム全体で安全な復旧プラクティスを標準化します。

← VPC ネットワーキング、接続性、トラフィック管理 · すべてのドメイン · デプロイ、構成、自動化 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Googleを閲覧 →