はじめのProfessional Cloud Developer認定取得講座⑪ECサイト向けBigtable高速データ設計ガイド、OpenTelemetry と Google Cloud Trace で始める分散トレーシング実践ガイド、Memorystore for Redis 高可用性（HA）構成完全ガイドを説明します！

クラウド

Google Cloud の Professional Cloud Developer 試験では、単にアプリケーションをデプロイできるだけでなく、「高性能」「高可用性」「可観測性」を備えたクラウドネイティブなシステム設計を理解していることが求められます。


特に、リアルタイムデータ処理、高速なデータアクセス、分散システムの監視、障害に強いキャッシュ基盤などは、実務でも試験でも頻出の重要テーマです。


本記事では、Cloud Bigtable を活用した高速データ設計、OpenTelemetry と Cloud Trace による分散トレーシング、そして Memorystore for Redis の高可用性構成について、実践的な観点から解説します。
それぞれのサービス単体の知識だけでなく、「どのような課題に対して、なぜその設計を選ぶのか」というアーキテクチャ視点を身につけることが目的です。


Professional Cloud Developer 試験対策としてはもちろん、実際のGoogle Cloudシステム設計・運用にも役立つ内容となっています。

今回は音声ファイルも挿入していますので、ブログの内容を音声でご確認いただけます。通勤中などにご利用いただければと思います。

是非、最後までご覧いただけると嬉しいです。

ECサイト向けBigtable高速データ設計ガイド

ECサイトでは、わずかなレスポンス遅延がユーザー体験を悪化させ、売上低下に直結します。特に、リアルタイムなユーザー行動データや閲覧履歴を扱うシステムでは、「超低レイテンシ」と「高スケーラビリティ」を両立できるデータ基盤が不可欠です。しかし、単に高速なデータベースを選ぶだけでは不十分で、行キー設計やデータ保持ポリシーまで含めた設計が求められます。
本記事では、Cloud Bigtable を活用した低遅延なEC向けデータ基盤の構築方法について、ホットスポット対策やTTL運用、Dataplex Universal Catalogによるガバナンスまで含めて実践的に解説します。

1. データベースの選定①：なぜ Cloud Bigtable なのか？

「いつでも最新データにアクセスできること」という要件に対し、最も適しているのは Cloud Bigtable です。

  • 超低レイテンシ：読み取り・書き込みともにシングルデジット（一桁台）ミリ秒の応答速度を誇り、リアルタイム性が求められるECサイトのバックエンドに最適です。
  • 高いスケーラビリティ：トラフィックの増大に合わせてノードを増やすだけで、ダウンタイムなしに処理能力を拡張できます。
  • 時系列データの得意分野：適切な行キー設計（後述）により、特定ユーザーの最新情報を最速で取得できます。
Bigtable の概要  |  Google Cloud Documentation
docs.cloud.google.com

2.データベースの選定②：Cloud Bigtable が向いていないのはどんな場合か？

「超低レイテンシ」と「巨大スケール」に最適化されたBigtableには、裏を返せば「苦手な領域」も明確に存在します。公式ドキュメントでも「Bigtableは従来のリレーショナルデータベースではなく、用途によっては別のデータベースの方が適している」と明記されています。誤ったデータベース選定はパフォーマンスとコスト両面で大きな損失につながるため、以下の3点を事前に確認してください。

  • トランザクションや結合が必要なデータ：ACIDトランザクションやSQL的な結合クエリが必要なドキュメント型データを扱う場合は、Firestoreの方が適しています。Bigtableは単一行レベルの操作は得意ですが、複数行にまたがるトランザクションは保証されません。注文管理や在庫管理のような「整合性が命」のデータには不向きです。
  • インタラクティブな集計分析：OLAP（オンライン分析処理）システムでのインタラクティブなクエリが必要な場合は、BigQueryの方が適しています。SQLで集計・結合・ウィンドウ関数を駆使するような分析ワークロードは、Bigtableの設計思想と根本的に合いません。
  • 小規模なアプリケーション：Bigtableの料金体系は大規模ワークロードに有利であり、小規模なアプリケーションにはFirestoreのような別のGoogle Cloudデータベースの方が適しています。最小構成でもノード単位の固定費が発生するため、データ量やリクエスト数が少ない段階でBigtableを採用するとコストが割高になります。

3. 重要：行キーの設計とホットスポット対策

Bigtableを正しく活用するには、行キーの設計が最も重要な要素です。設計を誤るとホットスポット（特定ノードへのアクセス集中）が発生し、性能が著しく低下します。

❌ やってはいけない設計

タイムスタンプを行キーの先頭または単独で使用することは禁止されています。書き込みが常に同じノードに集中し、ホットスポットを引き起こします。 

# NG例：タイムスタンプ先頭
1713883000#user_001
1713883001#user_002

✅ 推奨される設計

ユーザーIDのような高カーディナリティの値を先頭に置き、タイムスタンプをその後に配置します。最新データを効率的に取得したい場合は、逆タイムスタンプ（Reversed Timestamp）を使います。 

# OK例：ユーザーID先頭 + 逆タイムスタンプ
user_001#<Long.MAX_VALUE - timestamp>
user_002#<Long.MAX_VALUE - timestamp>

逆タイムスタンプはlong型最大値からタイムスタンプを引いた値で、これによりデータが新しい順（降順）に格納され、最新データへの高速アクセスが可能になります。なお逆タイムスタンプも行キーの先頭には置かないよう注意が必要です。

これにより、特定ユーザーの最新アクティビティを先頭から順にスキャンするだけで取得できるようになります。

4. 自動削除の実装：ガベージ コレクションの設定

「30日より古いデータは自動的に削除する」というポリシーを、アプリケーションコードで実装するのは非効率です。Cloud Bigtable に備わっている 「ガベージ コレクション（GC）」 機能を使えば、データベース側でこの処理を完結できます。

4-1. 年齢ベースのポリシー（TTL）

Bigtableでは、カラムファミリー単位で「データの有効期限（Max Age）」を設定できます。

  • 設定内容：max_age を 30d（30日間）に設定します。
  • 挙動：30日を過ぎたデータ（セル）は、Bigtableのバックグラウンド処理によって自動的に削除対象となります。

4-2. セルレベルの細かな制御

Bigtableは1つの「セル」に複数のバージョン（タイムスタンプ付きのデータ）を保持できます。

「最新のデータ1つだけを残し、かつ作成から30日過ぎたものは消す」といった、バージョン数と年齢を組み合わせた高度なルール設定も可能です。

4-3. パフォーマンスへの影響

このガベージコレクションは非同期で行われるため、読み取りや書き込みのパフォーマンスを低下させることはありません。運用者は、削除用スクリプトの実行やバッチ処理のスケジュール管理から完全に解放されます。

⚠️ 注意：GC完了までのタイムラグ
GCポリシーを設定してから実際にデータが削除されるまで、最大で1週間程度のラグが生じる場合があります。期限切れデータをクエリで除外したい場合は、タイムスタンプ範囲フィルターを使って読み取り時に明示的に除外することを推奨します。

5. ガバナンスの強化：Dataplex Universal Catalog による一元管理

個別のデータベース設定だけでなく、会社全体のポリシーとして「30日削除」が守られているかを管理・監視する必要があります。ここで役立つのが Dataplex Universal Catalog です。

  • データカタログによる可視化：Dataplexのデータカタログ機能を使えば、どのテーブルにどのような削除ポリシー（TTL）が設定されているかをメタデータとして管理できます。
  • データガバナンスの統一：複数のプロジェクトやバケットにまたがるデータを論理的にグループ化し、一貫したセキュリティポリシーやデータ管理ルールを適用できます。
  • コンプライアンスの証明：会社のポリシーが正しく適用されているかを一目で確認できるため、監査対応などの工数も大幅に削減されます。

6. 効率的なソリューションのまとめ

要件採用技術設定内容
ミリ秒のデータ取得Cloud BigtableユーザーID先頭＋逆タイムスタンプの行キー設計
30日自動削除Bigtable GCポリシーmax_age = 30d をカラムファミリーに設定
ポリシー統制・監査Dataplex Universal CatalogTTLメタデータの管理・コンプライアンス可視化

ECサイト向けBigtable高速データ設計ガイドのまとめ

Cloud Bigtable は、ミリ秒単位の応答性能と高いスケーラビリティを兼ね備えた、リアルタイムECシステムに最適なデータベースです。特に、ユーザーIDを先頭にした行キー設計や逆タイムスタンプの活用は、ホットスポットを回避しながら最新データへ高速アクセスするための重要なポイントとなります。
また、ガベージコレクション（TTL）を利用することで、古いデータの削除を自動化でき、運用負荷を大幅に削減できます。さらに、Dataplex Universal Catalogを組み合わせることで、データ保持ポリシーやガバナンスを全社レベルで統一管理することも可能です。
単に「高速なDBを使う」のではなく、データ設計・削除ポリシー・統制まで含めて最適化することが、安定した高性能EC基盤を実現する鍵となります。

OpenTelemetry と Google Cloud Trace で始める分散トレーシング実践ガイド

分散システムやマイクロサービスアーキテクチャを採用すると、リクエストがどのサービスで時間を費やし、どこでエラーが発生しているかを把握するのが困難になります。この「ブラックボックス化」を解消し、パフォーマンスのボトルネックを特定するための最適解が、OpenTelemetry を用いたトレース計測と Google Cloud Trace による可視化です。本記事では、公式ドキュメントと最新の業界標準に基づき、アプリケーションにトレースを導入し、分析を最大化する方法を解説します。

1. 分散トレーシングが必要な理由

単一のサーバーであればログだけで十分かもしれませんが、複数のサービスが連鎖する現代のアプリでは、「ユーザーがボタンを押してから応答が返るまでの全工程」を追いかける必要があります。

  • 遅延の特定：10個ある API 呼び出しのうち、どれが全体の足を引っ張っているか。
  • 依存関係の可視化：予期せぬサービス間の呼び出しが発生していないか。
  • エラーの文脈把握：ログだけでは分からない、上流・下流サービスの状態を含めたトラブルシューティング。

2. 業界標準「OpenTelemetry」を採用するメリット

Google Cloud Trace を利用する際、以前は Google 独自の SDK が使われていましたが、現在は OpenTelemetry (OTel) の使用が強く推奨されています。

OpenTelemetry とは？

OpenTelemetry は、トレース、メトリクス、ログといったテレメトリデータを生成・収集・エクスポートするためのオープンソース標準フレームワークです。

  • ベンダー中立：コードを書き換えずに、送信先を Google Cloud Trace から別のツールへ変更できます。
  • 多言語サポート：Java、Python、Go、Node.js など主要な言語に対応しています。
  • 自動計装 (Auto-instrumentation)：ライブラリを導入するだけで、HTTP リクエストやデータベースクエリを自動的に記録できる機能が強力です。
OpenTelemetryとは
OpenTelemetryが何であり、何でないかについての簡潔な説明。
opentelemetry.io

3. 実装の最適ルート：3つのステップ

ステップ1：SDK の導入と自動計装

まず、アプリケーションに OpenTelemetry SDK を組み込みます。多くの言語では、コードを一行も書かずに一般的なライブラリ（Express、Django、gRPC など）の計測を開始できる「自動計装エージェント」が用意されています。

ステップ2：エクスポータの設定（推奨構成）

現在の公式推奨は、アプリケーションに OTLP エクスポータを設定し、OpenTelemetry Collector へデータを送信、Collector が Google Cloud Trace へ転送する構成です。この構成により、アプリケーションコードはベンダー中立のままに保たれます。

アプリ（OTLPエクスポータ）→ OpenTelemetry Collector → Google Cloud Trace
💡 Cloud Trace Exporter について
アプリから直接 Cloud Trace に送信する「Cloud Trace Exporter」も利用可能ですが、Collector経由の構成が現在の推奨方式です。既存の直接エクスポート構成を使っている場合は、OTLP方式への移行を検討してください。

ステップ3：コンテキスト伝播 (Context Propagation)

分散トレーシングの核となるのが「コンテキスト伝播」です。HTTP リクエストでは traceparent や tracestate ヘッダー（W3C 標準）を用いてコンテキストを伝播します。Google Cloud サービスはこの traceparent ヘッダーと旧来の X-Cloud-Trace-Context ヘッダーの両方をサポートしていますが、新規実装では traceparent ヘッダーの使用が推奨されています。

これにより、下流（downstream）のサービスへトレース情報が渡され、バラバラのサービスで発生したスパン（処理単位）を一つの「トレース」として連結できます。

4. Google Cloud Trace での分析と可視化

データが Cloud Trace に届くと、強力な分析ツールが利用可能になります。

  • トレース詳細ビュー：ウォーターフォール図を用いて、各処理（スパン）の開始時間と期間をミリ秒単位で確認できます。
  • 分析レポート：「昨日の同時刻と比べて、どのスパンのレイテンシがどれくらい悪化したか」といった比較レポートを自動生成します。
  • ボトルネックの自動検出：統計的に見て異常に時間がかかっているリクエストを素早く特定できます。

5. 運用のベストプラクティス

サンプリングの最適化

すべてのリクエストを記録するとコストと負荷が増大します。本番環境では 1%〜5% 程度に抑えるヘッドベースサンプリングが基本です。エラーが発生したリクエストは確実に記録したい場合は「テールベースサンプリング」も有効ですが、以下の点に注意してください。

⚠️ テールベースサンプリングの注意点
テールベースサンプリングでは、サンプリング判断を行う前にトレースのすべてのスパンを一時保存する必要があります。そのため大量の一時ストレージや処理オーバーヘッドが生じます。また、同一トレースIDのスパンが同じCollectorへルーティングされるよう設計する必要があります。

属性（Attributes）の活用

スパンに customer_id や region などのカスタム属性を付与することで、「特定の顧客だけで発生している遅延」といったフィルタリングが可能になります。

Cloud Logging との連携

トレース ID をログに埋め込むことで、Cloud Trace の画面から該当するスパンのログへ一クリックでジャンプできるようになり、デバッグ効率が飛躍的に向上します。

OpenTelemetry と Google Cloud Trace で始める分散トレーシング実践ガイドのまとめ

OpenTelemetry と Google Cloud Trace を組み合わせることで、マイクロサービス環境におけるリクエストの流れをエンドツーエンドで可視化できるようになります。特に、OpenTelemetry を採用することで、ベンダー中立かつ多言語対応の柔軟なトレーシング基盤を構築できる点が大きなメリットです。
また、OpenTelemetry Collector を経由する推奨構成により、将来的な監視基盤の変更にも柔軟に対応できます。
traceparent を用いたコンテキスト伝播や、Cloud Trace のウォーターフォール分析を活用することで、レイテンシや障害箇所の特定を効率化できます。さらに、サンプリング戦略や属性設計、Cloud Logging 連携を組み合わせることで、運用負荷とコストを抑えながら高度な可観測性を実現できます。
これらを実践することで、複雑化した分散システムでも、安定した運用と迅速なトラブルシューティングが可能になります。

Memorystore for Redis 高可用性（HA）構成完全ガイド

キャッシュサーバーやシンプルなデータストアとして圧倒的な人気を誇るRedis。しかし、本番環境のバックエンドとして採用する場合、「もしRedisがダウンしたら？」という問いに備える必要があります。Google CloudのMemorystore for Redisでは、マネージドサービスならではの堅牢な高可用性（HA）構成が用意されています。本記事では、公式ドキュメントに基づき、可用性を最大化するための構成パターンと実装のポイントを解説します。

1. 運命の分かれ道：「基本ティア」か「標準ティア」か

Memorystore for Redisには2つのティア（階層）がありますが、高可用性を求めるなら選択肢は「標準ティア（Standard Tier）」一択です。

特徴基本ティア (Basic Tier)標準ティア (Standard Tier)
可用性低（単一インスタンス）高（プライマリ＋レプリカ）
自動フェイルオーバーなしあり
SLAなし99.9%
メンテナンス時の停止約5分約15秒
主な用途開発、テスト、一時的なキャッシュ本番環境、重要なバックエンド

基本ティアはコスト面で有利ですが、インスタンス障害が発生するとデータが失われ、再起動までサービスが停止します。標準ティアは、データをリアルタイムでレプリカに複製することで、不測の事態に備えます。

💡 より高いSLAが必要な場合
Memorystore for Valkey および Memorystore for Redis Cluster は 99.99% の SLA を提供しています。より厳格な可用性要件がある新規設計では、これらも選択肢として検討してください。
Memorystore for Redis の概要  |  Google Cloud Documentation
docs.cloud.google.com

2. 高可用性（HA）を支える仕組み

標準ティアを選択すると、Memorystoreは異なるゾーンに「プライマリ」と「レプリカ」を配置します。

自動フェイルオーバーのプロセス

プライマリインスタンスに異常（ハードウェア故障、パッチ適用、ゾーン障害など）が発生すると、以下のプロセスが自動的に実行されます。

  1. 検出：ヘルスチェックがプライマリの異常を検知します。
  2. 昇格：待機していたレプリカが新しいプライマリに昇格します。
  3. 再接続：アプリケーションの接続先（固定のサービスIPアドレス）が自動的に新しいプライマリへ切り替わります。
  4. 復旧：旧プライマリが修復され、新しいレプリカとして復帰・同期が始まります。

フェイルオーバーの所要時間は、自動修復の場合で平均約30秒、メンテナンスイベントの場合は約15秒です。なお、MemorystoreはDNSではなく固定のサービスIPアドレスで接続するため、DNSの伝播待ちは発生しません。 

⚠️ 重要：フェイルオーバー中の書き込みロスに注意
MemorystoreはRedisの非同期レプリケーションを採用しているため、フェイルオーバー中に「確認済み（acknowledged）の書き込みが失われる可能性」があります。アプリケーション側でこのデータロスを許容できる設計にする必要があります。

3. リードレプリカによるパフォーマンスと可用性の向上

さらに高い負荷や可用性が求められる場合は、リードレプリカの活用を検討してください。

なぜリードレプリカを使うのか？

  • 読み取りの負荷分散：書き込みはプライマリ、読み取りは複数のレプリカに分散させることで、アプリ全体のレスポンスを向上させます。
  • 冗長性の強化：リードレプリカを有効にすると、プライマリ＋最大5つのレプリカ（合計最大6ノード）の構成が可能です。リードレプリカは読み取りのスケーリングだけでなく、HAフェイルオーバー先としても機能します。 
⚠️ リードレプリカの注意点
・リードレプリカはデフォルトでは無効です。明示的に有効化する必要があります。
・リードレプリカはインスタンスサイズが 5GB以上 の場合のみサポートされます。
・リードレプリカへの通信は、メインの「プライマリ・エンドポイント」とは別の「読み取りエンドポイント」を介して行われます。アプリケーション側で読み取りクエリをこのエンドポイントに向ける実装が必要です。
・非同期レプリケーションのため、レプリカからの読み取りは数秒のラグが生じる場合があります。「書き込み後すぐに読み取る」一貫性が必要な場合は、プライマリエンドポイントを使用してください。

4. 安定運用のためのRedis構成（Config）

HA構成を組んだだけでは不十分です。データの「溢れ（エビクション）」を防ぐ設定も重要です。

  • maxmemory-policy：メモリが上限に達した際の挙動を決めます。HA構成では、古いデータを消して新しいデータを優先する allkeys-lru や volatile-lru が一般的です。
  • メモリ使用率の管理：エクスポートやスケーリングなどの重要な操作時には、メモリ使用率を50%以下に保つことが推奨されています。これにより、レプリケーション用バッファの確保と、万が一の障害時のリスクを最小化できます。

Memorystore for Redis 高可用性（HA）構成完全ガイドのまとめ

Memorystore for Redis で高可用性を実現するには、標準ティア（Standard Tier）の採用が基本となります。
標準ティアでは、異なるゾーンにプライマリとレプリカを配置し、自動フェイルオーバーによって障害時でも短時間でサービスを復旧できます。さらに、リードレプリカを活用することで、読み取り負荷の分散と冗長性の向上を同時に実現できます。
一方で、Redis の非同期レプリケーション特性上、フェイルオーバー時には書き込みロスが発生する可能性があるため、アプリケーション設計側での考慮も重要です。
また、maxmemory-policy の適切な設定や、メモリ使用率を抑えた運用は、安定したHA構成を維持するための重要なポイントになります。
これらを正しく組み合わせることで、可用性・性能・運用性を兼ね備えたRedis基盤を構築できます。

まとめ

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

  1. ECサイト向けBigtable高速データ設計ガイド
  2. OpenTelemetry と Google Cloud Trace で始める分散トレーシング実践ガイド
  3. Memorystore for Redis 高可用性（HA）構成完全ガイド

Professional Cloud Developer 試験では、単なるサービス知識ではなく、要件に応じた最適なアーキテクチャ設計能力が問われます。


Cloud Bigtable では、行キー設計やTTL運用を通じて、高速かつスケーラブルなデータ基盤を実現する考え方が重要です。また、OpenTelemetry と Cloud Trace を組み合わせることで、マイクロサービス環境における可観測性とトラブルシューティング能力を大きく向上できます。さらに、Memorystore for Redis の HA 構成では、自動フェイルオーバーやリードレプリカを活用しながら、高可用性と性能を両立する設計が求められます。


これらはいずれも、「スケーラビリティ」「可用性」「運用性」というクラウドネイティブ設計の中核となる考え方です。各サービスの特徴だけでなく、制約や設計上の注意点まで理解することが、試験合格と実践力向上への近道となります。

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

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

スポンサーリンク
タイトルとURLをコピーしました