はじめのProfessional Cloud Data Engineer認定取得講座㉓Cloud KMSで鍵が盗まれた時の対応手順、Dataproc Serverless、Memorystore for Redisのリードレプリカ機能について説明します！

今回も、Professional Cloud Data Engineer認定取得するために、私が勉強した内容をアウトプットしていきます。

今回は、Cloud KMSで鍵が盗まれた時の対応手順、Dataproc Serverless、Memorystore for Redisのリードレプリカ機能について説明します！

ぜひ、最後までご覧いただけると嬉しいです！

Cloud KMSで鍵が盗まれた時の対応手順

近年、クラウド環境でのセキュリティ事故は増加しており、とくに暗号鍵が漏洩した場合はデータの機密性が直ちに危険にさらされます。Google Cloud の Cloud KMS（Key Management Service）を利用している場合も例外ではなく、万が一鍵が盗まれた際には迅速かつ正確な対応が求められます。本記事では、Cloud KMS の鍵が漏洩したときに取るべき具体的な手順を解説します。

推奨対応手順

推奨の対応手順は以下になります。

(1) 漏洩した鍵の利用を止める

• Cloud KMS の 鍵バージョンを無効化する または 破棄する（destroy） → 以後、新しい暗号化・復号に使えなくなります。
• ただし、破棄すると復号もできなくなるため、事前に後続手順の準備が必要です。

(2) 新しい鍵を作成する

• 新しい Cloud KMS 鍵、または新しい鍵バージョンを作成します。
• Cloud Storage バケットの暗号化設定を、新しい鍵に切り替えます。

(3) データを再暗号化する

Cloud Storage は「バケットの暗号鍵を切り替えるだけ」では既存オブジェクトは再暗号化されません。旧鍵を有効化します。

• オブジェクトを「再書き込み」する必要があります（コピーまたは再アップロード）。

(4) 旧鍵の完全破棄

• すべてのデータが新しい鍵で再暗号化されたことを確認したら、旧鍵のバージョンを destroy します。
• destroy した鍵バージョンは 24 時間後に使用不可となり、完全に復号不能になります。

(5) 監査・再発防止

• Cloud Audit Logs を確認し、不審なアクセスや利用がなかったか調査します。
• 鍵管理ポリシー（アクセス制御、IAM、ネットワーク制御、Secret Manager との併用）を見直します。
• 可能なら VPC Service Controls や Cloud DLP を組み合わせて情報流出対策を強化します。

Cloud KMSで鍵が盗まれた時の対応手順まとめ

Cloud KMS の鍵が漏洩した場合、対応の遅れは重大な情報流出につながります。最初にすべきことは「被害拡大を止める」ことであり、その後は新しい鍵を使った再暗号化と旧鍵の廃棄、そして徹底した監査が不可欠です。今回紹介したフローを理解しておけば、万一の際にも落ち着いて行動できます。また、事前にアクセス制御や鍵管理ポリシーを整備しておくことが、最大の防御策となります。

Dataproc Serverless

Dataproc Serverlessは、Apache Sparkのバッチジョブやインタラクティブセッション（Jupyterノートブックなど）を実行するためのサーバーレスプラットフォームです。ユーザーはインフラを意識することなく、コンソール、CLI、またはAPIを通じて直接Sparkジョブを送信するだけで済みます。

リソースはワークロードに応じて自動でスケールし、処理が実行されている時間だけ課金されるため、コスト効率にも優れています。

従来のDataprocとの違い

従来のCompute Engine上でクラスタを構築するDataprocと比較すると、以下のような特徴があります。

要するに、Dataproc Serverlessは 「手軽さと俊敏性」 に特化しており、従来のDataprocは 「柔軟性とカスタマイズ性」 に強みがあると言えます。

応用例：高度な使い方

Dataproc Serverlessは、他のGoogle Cloudサービスと連携することで、さらに強力なデータパイプラインを構築できます。

BigQueryとの連携

SparkジョブからBigQueryのテーブルを直接読み書きすることが可能です。BigQuery Connector for Sparkを利用することで、以下のようなETL/ELTパイプラインを簡単に実現できます。

Cloud Storageのデータ → Sparkで加工・集計 → 結果をBigQueryテーブルに書き込み

この際、ジョブ送信時に[--jars]オプションでコネクタのJARファイルを含める必要があります。

カスタムコンテナの利用

標準の実行環境に含まれていないPythonライブラリやOSパッケージが必要な場合は、カスタムコンテナ機能が役立ちます。

自分で作成したDockerイメージをArtifact Registryにプッシュし、ジョブ送信時にそのイメージを指定することで、独自のライブラリや設定を持つカスタマイズされた環境でSparkジョブを実行できます。

設計上の考慮事項と注意点

Dataproc Serverlessを利用する際には、以下の点を念頭に置いて設計することが重要です。

• クラスタ設定の制限：VMタイプなどのインフラを直接制御することはできません。細かなチューニングが必要な場合は、従来のDataprocが適しています。
• ランタイムバージョン：サポートされているSparkのバージョンは限られているため、ジョブに合ったバージョンを選択する必要があります。
• 起動オーバーヘッド：サーバーレスの性質上、ジョブ開始時にリソース確保のためのウォームアップ時間が発生します。数秒で終わるような非常に短いジョブでは、このオーバーヘッドが効率を低下させる可能性があります。
• ネットワーク設定：Sparkジョブがアクセスするデータソース（Cloud Storage, BigQueryなど）への疎通性を確保するため、VPC、サブネット、ファイアウォール、IAM権限などを正しく設定することが不可欠です。
• 依存ライブラリの管理：外部ライブラリは、-deps-bucketやカスタムコンテナを使って事前に準備しておく必要があります。
• モニタリング：実行ログやリソース消費量を監視し、ジョブの失敗やパフォーマンスボトルネックに迅速に対応できる仕組みを整えましょう。

Dataproc Serverlessは、インフラ管理の手間をかけずにSparkのパワーを活用したい場合に最適な選択肢です。その特性を理解し、適切に活用することで、データ処理基盤の開発と運用を大幅に効率化できるでしょう。

Dataproc Serverlessのまとめ

Dataproc Serverlessは、Sparkをサーバーレスで実行できる手軽さと俊敏性が大きな特徴です。従来のDataprocに比べ、インフラ管理やリソース調整の手間を省きながら、自動スケーリングによって効率的な処理が可能となります。さらに、BigQueryやCloud Storageとの連携やカスタムコンテナの利用によって、柔軟なデータパイプラインを構築できます。一方で、クラスタ設定の制限や起動オーバーヘッドといった注意点も理解しておく必要があります。適切に活用すれば、データ処理基盤を迅速かつコスト効率よく運用できる強力な選択肢となるでしょう。

Memorystore for Redisのリードレプリカ機能

Google Cloudのインメモリデータストアサービスである Memorystore for Redis は、Standardティアにおいてリードレプリカ機能を提供しています。この機能を利用することで、読み取りリクエストを複数のノードに分散させ、アプリケーションの読み取り性能をスケールさせるとともに、可用性を高めることが可能です。

この記事では、リードレプリカの仕組みから具体的なユースケース、導入時の注意点、運用ベストプラクティスまでを分かりやすく解説します。

リードレプリカの基本的な仕組み

Memorystore for Redisのリードレプリカは、「書き込み用」と「読み取り用」の窓口を分けることで機能します。

• 書き込み：データ更新や追加などの書き込み操作は、常にプライマリノードに対して行われます。この接続にはプライマリエンドポイントを使用します。
• 読み取り：データの取得 (GETコマンドなど) は、複数のレプリカノードに分散されます。アプリケーションは読み取り用エンドポイントに接続することで、Google Cloudが自動的に読み取り負荷を各レプリカに振り分けます。

データの同期は非同期レプリケーション方式で行われます。これは、プライマリノードでの書き込みが完了した後、少し遅れてレプリカノードにデータが反映されることを意味します。このため、レプリカとプライマリの間にはレプリケーションラグ（遅延）が生じる可能性があります。

この特性上、「自分が書き込んだ内容を直後に読み出したい」といった強い整合性が求められる処理では、レプリカから古いデータが返される可能性があります。このようなケースでは、読み取りであってもプライマリエンドポイントを利用することが推奨されます。

主なユースケース

リードレプリカは、特に読み取り処理が頻繁に発生するワークロードで真価を発揮します。非同期レプリケーションによる多少のデータ遅延が許容できる、以下のような用途に最適です。

• セッションストア：ログイン情報など、書き込みよりも参照の頻度が圧倒的に高いセッションデータの管理。
• リーダーボード：ゲームのランキングなど、頻繁に更新されるが、それ以上に多くのユーザーが閲覧するデータの表示。
• レコメンデーションエンジン：ユーザーごとのおすすめ商品など、キャッシュされたデータの高速な読み出し。
• 読み取り主体のキャッシュ全般：APIレスポンスのキャッシュなど、読み取り負荷が高い様々なキャッシュ用途。

制限と注意点

リードレプリカを導入する際には、いくつかの前提条件と制限があります。

その他の注意点

• フル同期の発生：レプリカの遅延が大きくなりすぎると、プライマリから全データを再送するフル同期が発生します。この間、対象のレプリカは一時的に読み取り不可となることがあります。
• READONLYエラー：稀にプライマリエンドポイントへの書き込み時に READONLY エラーが返ることがあります。この場合は、クライアント接続を再確立することで解決します。

高可用性を実現するフェイルオーバー

プライマリノードに障害が発生した場合、Memorystoreが自動的に正常なレプリカの1つを新しいプライマリに昇格させます。このフェイルオーバー処理は通常30秒未満で完了し、サービスのダウンタイムを最小限に抑えます。

フェイルオーバー中はプライマリエンドポイントへの接続が一時的に切断されるため、アプリケーション側には自動再接続ロジックを実装しておくことが不可欠です。

運用上のベストプラクティス

リードレプリカを効果的かつ安全に運用するためのポイントを以下にまとめます。

• 再接続ロジックの実装：フェイルオーバーに備え、クライアントアプリケーションには必ず接続の再試行ロジックを組み込みましょう。
• 整合性要件の確認：処理ごとに必要な整合性のレベルを判断し、強い整合性が必要な場合はプライマリエンドポイントを使用します。
• 計画的なスケーリング：レプリカの追加は、プライマリへの負荷を考慮し、オフピーク時に行いましょう。
• モニタリング：レプリケーションラグやエラー率などのメトリクスを監視し、システムの健全性を常に把握しておくことが重要です。
• レプリカ数の最適化：実際の読み取り負荷に応じてレプリカ数を調整し、コストとパフォーマンスのバランスを取ります。

Memorystore for Redisのリードレプリカ機能のまとめ

Memorystore for Redisのリードレプリカ機能は、読み取り性能の向上と高可用性を同時に実現できる有効な仕組みです。非同期レプリケーションの特性を理解し、整合性要件に応じて適切にエンドポイントを使い分けることが重要です。フェイルオーバーへの備えや再接続ロジックの実装、モニタリングによる運用管理は欠かせません。ユースケースに応じて最適なレプリカ数を構成すれば、コスト効率とパフォーマンスの両立が可能になります。正しく活用することで、Redisを基盤としたアプリケーションの信頼性とスケーラビリティを大幅に強化できるでしょう。

まとめ

今回は、下記３点について説明しました。

1. Cloud KMSで鍵が盗まれた時の対応手順
2. Dataproc Serverless
3. Memorystore for Redisのリードレプリカ機能

Cloud KMSの鍵漏洩対応、Dataproc Serverless、Memorystore for Redisのリードレプリカ機能は、いずれもクラウド環境におけるセキュリティとスケーラビリティを確保するうえで重要なテーマです。鍵漏洩時には被害拡大を防ぎ、速やかな鍵の再発行と監査を行うことが不可欠です。Dataproc Serverlessではインフラ管理の手間を省き、柔軟かつコスト効率の高いデータ処理を実現できます。また、Memorystoreのリードレプリカ機能を活用すれば、読み取り性能と可用性を強化できます。これらを理解し適切に活用することで、安全で効率的なクラウド基盤の運用が可能となるでしょう。

これからも、Macのシステムエンジニアとして、日々、習得した知識や経験を発信していきますので、是非、ブックマーク登録してくれると嬉しいです！

それでは、次回のブログで！