今回も、Professional Cloud Data Engineer認定取得するために、私が勉強した内容をアウトプットしていきます。
今回は、Datastore、指数バックオフ、Apache Beamについて説明します！
ぜひ、最後までご覧いただけると嬉しいです！
Datastore
Google Cloud Datastoreは、スケーラブルで高可用性な NoSQL データベースサービスです。構造化データを柔軟に扱うことができ、アプリケーションの成長に応じて自動的にスケーリングします。トランザクションやインデックス作成、強整合性のオプションなども備えており、Web やモバイルアプリケーションに最適です。現在はFirestoreの Datastoreモードとして提供されています。
主な特徴
- フルマネージド：サーバーのプロビジョニングや管理、パッチ適用、バックアップなどが不要です。
- 自動スケーリング：アプリケーションの負荷に応じて、ストレージとトラフィックが自動的にスケールします。
- 高可用性と高耐久性：データは複数のデータセンターに自動的に複製され、高い可用性と耐久性を備えています。
- 柔軟なスキーマ (スキーマレス)：同じ「種類 (Kind)」のエンティティ（データレコード）でも、それぞれ異なるプロパティ（属性）を持つことができます。アプリケーションの進化に合わせてデータ構造を柔軟に変更できます。
- ACIDトランザクション：複数のエンティティにまたがる操作（制限あり）であっても、アトミック性、一貫性、分離性、耐久性（ACID）を保証するトランザクションをサポートします。
- SQLライクなクエリ言語 (GQL)：SQLに似た構文のクエリ言語（GQL）や、クライアントライブラリのメソッドを通じて、データのフィルタリングや並べ替えが可能です。
- インデックス：プロパティに対するインデックスが自動的に作成され、効率的なクエリが可能です。複数のプロパティにまたがるクエリには、複合インデックスの設定が必要です。
- 無料枠：日々一定量の無料枠が提供されており、小規模なアプリケーションや開発・テスト用途に適しています。
- 整合性：デフォルトでは結果整合性のあるクエリが主ですが、強整合性のある読み取り（祖先クエリなど）も可能です。
データモデルの基本
- エンティティ：データの基本単位（オブジェクトや行に相当）。
- 種類 ：エンティティの分類（テーブルに相当）。
- プロパティ：エンティティ内の名前付きデータ値（フィールドや列に相当）。
- キー：各エンティティの一意な識別子。種類、ID/名前、オプションの祖先パスで構成されます。
Datastoreを選択すべきユースケース
Datastoreが特に適しているユースケースは以下の通りです。
- ユーザープロファイル
- ユーザーごとに異なる属性（例：新機能利用ユーザーのみ特定の属性を持つ）を持つ可能性があるため、Datastoreの柔軟なスキーマが適しています。
- ユーザー数の増加に合わせて自動的にスケールします。
- 商品カタログ
- 商品によって属性セットが異なる場合（例：本には著者、服にはサイズと色）でも、柔軟なスキーマで容易に対応できます。
- 豊富なインデックスとクエリ機能により、様々な条件での商品検索を実装できます。
- ゲームの状態管理
- プレイヤーデータ、スコア、インベントリ、セッション情報など、構造が変化しうるデータの保存に適しています。
- アイテムの取得やスコア更新など、複数のデータ更新を伴う操作に対してACIDトランザクションを利用し、データの整合性を保つことができます。
- プレイヤー数の増減に合わせて自動スケールします。
- ウェブおよびモバイルアプリケーションのバックエンド
- サーバーレスでインフラ管理が不要なため、アプリケーション開発に集中できます。
- 自動スケーリングと高可用性により、トラフィックの増減に対応し、安定したサービス提供が可能です。
- 特に App Engine Standard 環境との親和性が高いです。
- コンテンツ管理
- ブログ記事、ニュース記事、ドキュメントなど、構造が固定されていない、あるいは時間とともに変化する可能性のあるコンテンツの保存に適しています。
選択のポイント
Datastoreは、インフラ管理の手間をかけずに、自動でスケールする高可用なNoSQLデータベースが必要で、かつスキーマの柔軟性やトランザクションによる一貫性、SQLライクなクエリ機能を求める場合に有力な選択肢となります。リレーショナルな結合が多用される場合（→ Cloud SQL/Spanner）、超低レイテンシのKey-Valueアクセスが最優先の場合（→ Memorystore/Bigtable）、大規模な分析クエリが主目的の場合（→ BigQuery）は、他のサービスのほうが適している可能性があります。
Datastoreのまとめ
Datastoreは、スケーラブルで高可用なフルマネージドNoSQLデータベースです。柔軟なスキーマ設計やACIDトランザクション、SQLライクなクエリが特徴で、インフラ管理不要で自動スケーリングにも対応します。ユーザープロファイル、商品カタログ、ゲーム状態、モバイル/ウェブアプリのバックエンドなどに適しており、アプリケーション開発を効率化できます。
指数バックオフ
指数バックオフは、ネットワークリクエストやAPI呼び出し、データベースアクセスなど、一時的に失敗する可能性のある操作を再試行（リトライ）する際に用いられるアルゴリズムまたは戦略の一つです。失敗が繰り返されるたびに、次の再試行までの待機時間を指数関数的に（例：倍々に）増やしていく点が特徴です。
目的と利点
主な目的は以下の通りです。
- 一時的な障害からの回復
ネットワークの輻輳（ふくそう）やサーバーの一時的な過負荷など、短時間で解消する可能性のある問題に対して、時間を置いて再試行することで成功の機会を与えます。 - システムの過負荷防止
失敗した操作を即座に、または短い固定間隔で繰り返し再試行すると、障害が発生しているシステムに対してさらに負荷をかけてしまい、回復を妨げる可能性があります。待機時間を指数関数的に増やすことで、リクエストの間隔を広げ、システムの負荷を軽減します。 - サンダリング・ハード問題の回避
多数のクライアントが同時にエラーを検知し、同じ固定遅延で一斉に再試行すると、再びサーバーに負荷が集中してしまいます（サンダリング・ハード問題）。指数バックオフ（特にジッターと組み合わせる場合）は、再試行のタイミングを分散させる効果があります。
仕組み
基本的なアルゴリズムは以下のようになります。
- 操作を実行します。
- 成功した場合、処理を終了します。
- 失敗した場合、事前に定められた初期待機時間（例: 100ミリ秒）だけ待ちます。
- 操作を再試行します。
- 成功した場合、処理を終了します。
- 再び失敗した場合、待機時間を指数関数的に（例: 前回の2倍）増やして待ちます（例: 200ミリ秒）。
- 操作を再試行します。
- このプロセスを、成功するか、事前に定められた最大再試行回数または最大待機時間に達するまで繰り返します。
- 最大回数/時間に達しても成功しない場合は、永続的なエラーとして処理します。
変動（ジッター）の導入
単純な指数バックオフでは、複数のクライアントが同じタイミングで失敗した場合、再試行のタイミングも（ある程度）同期してしまう可能性があります。これを避けるために、計算された待機時間にランダムな変動（ジッター）を加えることが一般的です。例えば、「計算された待機時間 ± ランダムな小さな値」や「0秒から計算された待機時間までのランダムな値」を実際の待機時間とします。これにより、再試行のタイミングがより効果的に分散されます。
一般的な適用例
- APIクライアントライブラリ（例: Google Cloud Client Libraries）
- ネットワーク通信を行うアプリケーション
- メッセージキューのコンシューマー
- データベース接続の再試行
設定可能な要素
指数バックオフを実装する際には、通常以下の要素を設定できます。
- 初期待機時間
- 待機時間の増加率（乗数、通常は2）
- 最大待機時間
- 最大再試行回数
- ジッターの適用方法
指数バックオフのまとめ
指数バックオフは、一時的な障害に対してシステムの安定性を高め、回復力を向上させるための重要なエラーハンドリング戦略です。待機時間を指数関数的に増やすことと、多くの場合変動（ジッター）を組み合わせることで、効率的かつ効果的に再試行を行い、システムの過負荷を防ぎます。
Apache Beam
Apache Beamは、バッチ処理とストリーミング処理の両方に対応するデータ処理パイプラインを定義するための、オープンソースの統合プログラミングモデルです。
主な目的
Beamの主な目的は、データ処理のロジックを一度記述すれば、それを様々な分散処理バックエンド（実行エンジン）で実行できるようにすることです。これにより、特定の実行エンジンに縛られることなく、処理ロジックの移植性（ポータビリティ）を高めることができます。
主要な概念
Beamは、データ処理パイプラインを構築するためのいくつかの基本的な抽象概念を提供します。
- Pipeline (パイプライン)
データ処理ジョブ全体を表すオブジェクト。データの入力から変換処理、出力までの一連のステップ（変換）を含みます。 - PCollection (Parallel Collection / 並列コレクション)
パイプラインによって処理される、分散される可能性のあるデータセットを表します。これは不変（イミュータブル）であり、多数の要素を含むことができます。データソースから読み込まれたデータや、変換処理の途中結果・最終結果などがPCollectionになります。バッチ処理の場合は有界 (Bounded)、ストリーミング処理の場合は無限 (Unbounded) になり得ます。 - Transform (PTransform / 変換)
パイプライン内の一つの処理ステップを表します。1つ以上のPCollectionを入力として受け取り、何らかの処理（要素ごとの処理、フィルタリング、グループ化、集計など）を行い、0個以上のPCollectionを出力します。BeamはParDo（並列処理）、GroupByKey、Combine、Flattenといった多くの組み込み変換を提供し、カスタム変換を作成することも可能です。 - Runner (ランナー / 実行エンジン)
Beamパイプラインを実際に実行する分散処理バックエンドです。開発したパイプラインの定義を解釈し、そのランナーが管理するクラスターやリソース上で実行します。- 主なランナーの例
- Google Cloud Dataflow (フルマネージドサービス)
- Apache Flink
- Apache Spark
- Apache Samza
- Direct Runner (ローカルマシンでのテスト・デバッグ用)
- 主なランナーの例
- SDK (Software Development Kit)
Beamパイプラインを記述するための言語固有のライブラリ。主要なSDKとして Java、Python、Go が提供されています（他にもSQL, TypeScriptなどがあります）。開発者はこれらのSDKを使ってパイプラインを定義します。
Apache Beamの主な利点
- 統合モデル
バッチ処理とストリーミング処理に対して、単一のプログラミングモデル（API）を提供します。イベント時間、ウォーターマーク、ウィンドウ処理、トリガーといったストリーミング固有の概念も、モデル内で統一的に扱われます。 - 移植性
パイプラインのロジックを一度書けば、異なるランナー（Dataflow、Spark、Flinkなど）上で実行可能です。これにより、特定の実行環境へのロックインを避けられます。 - 拡張性
カスタムのデータソース、シンク、変換処理を容易に作成できます。 - 多言語対応
Java, Python, Goなどの主要な言語でパイプラインを開発できます。
Google Cloud Dataflowとの関係
- Google Cloud Dataflow は、Apache Beamパイプラインを実行するためのフルマネージドな実行エンジン（ランナー）の一つです。
- Apache Beamモデル自体は、Googleが開発した内部技術（FlumeJavaやMillWheel）に基づいており、GoogleがオープンソースとしてApacheソフトウェア財団に寄贈したものです。
- Dataflowでジョブを開発・実行するということは、実質的にApache Beam SDK（JavaやPythonなど）を使ってパイプラインを定義し、それをDataflowランナーに送信してGoogle Cloudのマネージドインフラ上で実行することを意味します。
Apache Beamのまとめ
Apache Beamは、バッチ・ストリーミング両用のデータ処理ロジックを記述するための強力で移植性の高い標準仕様（プログラミングモデル）であり、開発者はビジネスロジックに集中できます。そして、そのパイプラインをGoogle Cloud Dataflowを含む様々な実行エンジン上で実行することができます。
まとめ
今回は、下記３点について説明しました。
- Cloud Datastore
- 指数バックオフ
- Apache Beam
本記事では、Datastoreの柔軟かつスケーラブルな特長、障害耐性を高める指数バックオフの考え方、そしてバッチ・ストリーミング両対応のApache Beamについて解説しました。これらの技術を組み合わせることで、堅牢で拡張性の高いクラウドアーキテクチャを構築するための知識が深まります。Google Cloudを活用したシステム設計の参考としてご活用ください。
これからも、Macのシステムエンジニアとして、日々、習得した知識や経験を発信していきますので、是非、ブックマーク登録してくれると嬉しいです！
それでは、次回のブログで！
