HarbourBridge を使用して DynamoDB から Cloud Spanner へ
Google Cloud Japan Team
※この投稿は米国時間 2021 年 9 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。
このたび、評価やテストを含む Cloud Spanner への移行作業の大部分を自動化するオープンソースのツールキット HarbourBridge が、従来の PostgreSQL と MySQL のサポートに加えて、DynamoDB にも対応するようになりました。これにより、DynamoDB ユーザーは構成を要することなく Cloud Spanner を試すことができます。HarbourBridge は、ユーザーがスキーマやデータの移行中に発生した問題を迅速に解決し、できるだけ早く Cloud Spanner を試せるようサポートします。
ワークフロー
今回 HarbourBridge では、複数の DynamoDB テーブルから Cloud Spanner に自動的にデータを読み込めるようになりました。まず、DynamoDB のデータを学習して Cloud Spanner のスキーマを構築します。次に、HarbourBridge は、このスキーマを使用して Cloud Spanner データベースを作成し、DynamoDB テーブルのデータをデータベースに入力します。さらに、発生したすべての問題と移行に失敗した行を含む詳細な評価レポートを生成します。DynamoDB の場合、HarbourBridge は公開 API を使ってソーステーブルに直接接続します。このツールは評価と移行の目的で設計されています（数十 GB までの使用が最適）。
HarbourBridge のスキーマ変換方法
スキーマレス データベースからリレーショナル データベースへの移行は大変難しい作業です。DynamoDB のサポートにおいては、スキーマ変換に関する次の問題を解決する必要があります。
スキーマレス - DynamoDB はスキーマレス データベースです。プライマリ インデックスとオプションのセカンダリ インデックス以外の列名と型には基本的に制約がなく、行ごとに異なる可能性があります。ただし、多くのお客様は、一貫した構造的な方法で、かなり明確に定義された列や型を使用して DynamoDB を利用しています。HarbourBridge による DynamoDB のサポートでは、このユースケースに焦点を当てており、テーブルデータを検査することで Spanner スキーマを構築します。小さなテーブルの場合は、テーブルのすべての行を検査します。大規模なテーブルの場合、テーブル全体をスキャンするには高いコストと時間がかかるため、テーブル スキャンの最初の N 行（schema-sample-size フラグで定義され、デフォルト値は 100,000）のみを検査します。実際には、DynamoDB スキャンは結果を順番に返さないため、これにより、作業対象データの妥当なサンプルが得られます。原則的には、無作為に行を選択することでより代表的なサンプルを取得できますが、それにはかなりのコストがかかります。
Number - ほとんどの場合、DynamoDB の Number 型を Spanner の Numeric 型にマッピングします。ただし、Cloud Spanner の Numeric の範囲は DynamoDB の Number の範囲よりも小さいため、この変換で範囲外となり、精度が低下する可能性があります。この問題に対処するため、サンプルデータの変換を試行し、それが一貫して失敗する場合はその列に STRING 型を選択します。
Null - DynamoDB では、列は不明または未定義の状態を表す Null データ型を持つ場合があります。また、各行では（主キーではなく）列に対して独自のスキーマを定義します。そのため、行に列がない場合があります。Cloud Spanner では、上述の 2 つのケースを Null 値と同じように扱います。列に Null 値が含まれている場合や、列が存在しない場合は、その列に null 可能性があることを示しています。
List と Map - DynamoDB は、複雑なデータ構造を保存する List と Map をサポートしています。たとえば List では ["Book", "Camera", 3.14159] というように、各要素が異なるデータ型であることもあります。Cloud Spanner では、List と Map の値を JSON 文字列としてエンコードします。これらの値を Cloud Spanner から読み取る際には解析が必要となります。
時折発生するエラー - DynamoDB テーブルへの書き込み時にはスキーマが適用されないため、少数のデータ行が誤って挿入される場合があり、時にはユーザーが気づかないこともあります。Cloud Spanner では、テーブルのスキーマが厳密に適用されており、テーブルのスキーマと異なる行を書き込むことはできません。この問題に対処するために、HarbourBridge では列の型を推測する際にエラーのしきい値を定義しています。ある型が非常に少ない割合（0.1% 以下）でしか行に表示されない場合、その行をエラーとして扱います。このような行は、列の型を判別する際に無視されます。これにより、Cloud Spanner スキーマを構築する際に、ある程度のノイズをフィルタできます。
マルチタイプの列 - 状況によっては、2 つのデータ型が均等に分布している列を取得する場合があります。たとえば、ある列の 40% の行が String で、60% の行が Number であるとします。型として Number を選択した場合、データ変換時に 40% の行が削除されてしまいます。この問題に対処するため、（Null データ型と列が存在しない行を削除した後）正規化された行に競合しきい値を定義します。デフォルトでは、競合しきい値は 5% で、2 つ以上のデータ型の割合がこれよりも大きい場合、列に競合するデータ型があると判断します。安全策として、Cloud Spanner ではこの列を STRING 型として定義します。
変換中、推測されたスキーマへの変換に失敗した行（少なくとも 1 つの列が変換に失敗）、または Cloud Spanner に書き込めなかった行は、評価で不良行として報告されます。不良行は * .dropped.txt に書き込まれますが、数が多くなる可能性があるので、ユーザーに不良行のサンプルを提供するためロギングを 100 行に制限しています。
スキーマ変換の詳細についてはこちらをご覧ください。
開始方法
HarbourBridge は Cloud Spanner インスタンスで直接使用できます。利便性を高めるために、Cloud Spanner エミュレータを使用することも可能です。これは、テストや評価のための Cloud Spanner のローカルなインメモリ エミュレーションです。エミュレータを使用して、Cloud Spanner の機能を無料でお試しいただけます。
エミュレータを使用するには、エミュレータの説明の手順に沿って設定してください。gcloud、docker、または Linux バイナリでエミュレータ サービスを開始できます。次に、SPANNER_EMULATOR_HOST 環境変数を設定する必要があります。これにより、HarbourBridge は実際の Cloud Spanner インスタンスと通信する代わりに、エミュレータに接続します。
DynamoDB からデータを取得する権限を得るためには、次の環境変数を使用して AWS の認証情報とリージョンを設定する必要があります。
また、これらを構成する別の方法もこちらからご確認いただけます。
デフォルトでは、DynamoDB は環境変数 AWS_REGION を使用してエンドポイントの URL を解決します。カスタム エンドポイントを提供するには、次の環境変数を使用できます。
HabourBridge の実行を開始する前に、必ず次のコマンドを実行してください。
GCLOUD_PROJECT 環境変数を Google Cloud プロジェクト ID に設定します。
次に、Go をインストールし、GOPATH 環境変数を適切に設定する必要があります。その後、次のコマンドで HarbourBridge をインストールできます。
デフォルトでは、$GOPATH/bin/harbourbridge にバイナリがインストールされます。DynamoDB 上でツールを直接使用（すべてのテーブルを移行）するには、次のコマンドを実行します。
新しい Cloud Spanner データベースの生成、スキーマのモデルリングによるテーブルの作成、ソーステーブルからのデータの読み込みが行われます。さらに、次の生成ファイルが表示される場合があります。
*.report.txt: 評価レポート。
*.schema.txt: ソーステーブルの Cloud Spanner スキーマ。
*.session.json: スキーマ変換の永続化された状態。将来のデータ移行のために変更 / 使用できます。
*.dropped.txt: 変換できない行が含まれます。
HarbourBridge によって生成されるファイルの詳細については、こちらを参照してください。
これで、Cloud Spanner インスタンスまたはエミュレータに移動すると、DynamoDB ソースから読み込まれたレコードのテーブルを含む新しいデータベースが表示されるはずです。
スキーマ変換の最適化
さまざまなシナリオに合わせて最適化できる側面は他にもあります。
サンプルサイズ - 大規模なデータベースを使用してテストを行おうとした場合、デフォルトのサンプルデータ サイズ（100,000 行）では不十分なことがあります。サンプルサイズを増やしたい場合は、「-schema-sample-size」というコマンド オプションが用意されており、ニーズに合わせて数値を設定できます。たとえば、次のコマンドを実行すると、スキーマのモデリングに 100 万レコードをサンプリングします。
セカンダリ インデックス - HarbourBridge は良い出発点となりますが、現時点ではインデックスの変換をサポートしていません（主キーの変換のみ）。パフォーマンスの向上やソース データベースとの公正な比較のためには、インデックスを追加することをおすすめします。詳細については、キーとインデックスをご覧ください。
インターリーブ テーブル - これは、局所性を高め、テーブル レイアウトを最適化するための、Cloud Spanner の重要な概念です。インターリーブ テーブルとは、他のテーブルの子となることを宣言したテーブルのことです。子テーブルの行を、関連する親テーブルの行と一緒に物理的に格納することで、お互いに関連するデータを検索する時間を節約できます。その結果、結合と書き込みのパフォーマンスが向上します。
まとめ
HarbourBridge は、Cloud Spanner の評価と移行のためのオープンソース ツールであり、PostgreSQL、MySQL、DynamoDB をサポートします。手動の手順を自動化し、初期移行を可能な限り迅速に作成することで、時間と労力を節約します。また、生成されたスキーマを改善、最適化するためのオプションも用意されています。
皆さまからのご意見やご提案をお聞かせください。ディスカッションや機能のリクエストをご希望の場合は、問題を登録することが可能です。Google には HarbourBridge のロードマップがあります。HarbourBridge は Cloud Spanner Ecosystem の一部であり、ユーザー コミュニティの取り組みによって所有、管理されています。Cloud Spanner の一部として Google が公式にサポートしているわけではありません。
- ソフトウェア エンジニア Hengfeng Li
- ソフトウェア エンジニア Deep Chowdhury
