Datastream ネットワーク設計
目的
Google Cloud Platform（GCP）のDatastreamサービスを利用したデータレプリケーション基盤におけるネットワーク設計について定義する。
ゴール
- AWSの転送対象DBの増加や複数VPC構成を実現できる拡張性の高い構成である
- コストが最適化された冗長化構成で可用性が担保がされている
構成図
要件
- データ損失なし
- RTO 10分以内（目標復旧時間）
- 転送遅延は10分以内
- プライベート内での転送
設計
GCP
プロジェクト
- Datastream専用プロジェクトを作成する経緯
- 権限管理と分析を重視しマイクロサービス毎にDatastream用GCPプロジェクトを作成する方針としていた。
- AWS仮想プライベートGWの制約でAWS側のVPCに対して1つしか作成できないことが判明し、拡張性に課題が出た。
- また、プロジェクトが増える毎にVPNを作成しなければならず、コストが肥大化する。
- Datastream専用プロジェクトに集約しVPNを共通化することで上記の制約を回避する。
- Datastream専用プロジェクトを作成する
- Datastream専用プロジェクトからマイクロサービス毎に作成されたプロジェクトからビューを使ってデータを参照する
- 権限の基本方針
- 医療情報等の機密性の高いデータを閲覧できるのは最小限にする必要があり、データ管理を行う人に集約してGoogleGroupを用いて権限管理を行える状態を作っていく
- Datastream専用プロジェクトはSREをオーナーとする
VPC
- VPC 参考
- Datastream専用VPCを作成
- 動的ルーティングモードはGLOBALを指定
- 通信先のAWSで異なるリージョンでサービスが稼働する場合があるため
最適なパスの選択モードはSTANDARD 推奨- サブネット作成はカスタムモードを使用する
- 指定したリージョンのみに作成するため
- VPN接続先とのCIDR重複を避けるため
- サブネット
- プライベート IPv6 アドレスは無効とする
- 作成するサブネット
- LB, GCE, VPNを配置するプライベートサブネット
10.128.0.0/16内で作成- サブネットは
/20で利用する
- LB, GCE, VPNを配置するプライベートサブネット
- 外部接続
- GCPマネージドVPC(Datastream用), AWS(VPN経由)での接続のみ
- GCPマネージドVPC(Datastream用)とは設定時に自動でVPCピアリングが設定される
- セキュリティ
- 外部IPアドレスは持たないが、GCS, KMSなどのセキュリティ、監査目的で利用が考えられるサービスに対してアクセスする可能性があるため限定公開 Google アクセスを有効とする
- https://cloud.google.com/vpc/docs/private-google-access?hl=ja
- 今後Google API とサービスにアクセスが必要になった場合に改めて構成を検討する
- ファイアウォールについては後述する
- 外部IPアドレスは持たないが、GCS, KMSなどのセキュリティ、監査目的で利用が考えられるサービスに対してアクセスする可能性があるため限定公開 Google アクセスを有効とする
- ログ
CIDR
| サービス | fd-datastream-stg | fd-datastream-stg |
|---|---|---|
| 確保するCIDRブロック | 10.128.0.0/16 | 10.128.0.0/16 |
| プライベートサブネット(東京) | 10.128.0.0/20 | 10.128.0.0/20 |
| Datastreamプライベートサブネット（詳細後述） | 10.128.16.0/20 | 10.128.16.0/20 |
DataStream
- プライベート構成としVPN経由でAWSのAuroraに接続する
- Datastreamを配置するプライベートサブネット 公式
- サブネットマスクは
/20- 仕様のため、LB, GCE, VPNを配置するプライベートサブネットとは別レンジで作成
- 今後Datastreamを追加する際はこのサブネットに追加していくこととする
- サブネットマスクは
VPN
- Cloud VPN
- 動的ルーティングするため、対応しているHA VPNとする
- 冗長化
- トンネル数は最大4つで99.99% のサービス可用性の SLA を実現できるが、以下を理由にトンネル数は2つとする
- トンネル数2つでもリージョン内で冗長化できている
- ダウンタイムは10分は許容できる
- コストを削減できる(GCPのみで$177/月削減想定)
- トンネル数は最大4つで99.99% のサービス可用性の SLA を実現できるが、以下を理由にトンネル数は2つとする
- セキュリティ
- セキュアかつ高速なIKEv2を採用
- BGPピア設定
- BGP ピア IPv4アドレスは手動設定にしAWSのIPアドレスを指定
- Cloud Router
- ルートの割り当て数は上限を超えていないか監視導入を別途検討（TBD） 参考
- 上記で作成したプライベートサブネットのみアドバタイズする
- ASN
- ステージング
- 65520
- 本番
- 65521
- ステージング
GCE
- プロキシサーバの役割
- 冗長化方針
- インスタンスグループを作成し2台でマルチゾーンで稼働させる
- 運用
- ヘルスチェックを行い、自動修復ポリシーで異常時に新規でインスタンスを起動させる
- リソースの負荷状況によってスケーリング別途検討（TBD: チケット
- メンテナンス
- OSのパッチやアップデート等でイメージの更新が発生した場合はダウンタイムなしで、GCEを最低1台稼働させ、入れ替えながら更新を行う。詳細は別途検討（TBD: チケット
- 監視
- リソースや死活監視は別途検討（TBD: チケット
- 起動設定
- インスタンステンプレートのstartup scriptでDBエンドポイントを指定してフォワーディングする
- Datastreamの仕様により、DBエンドポイントはライターインスタンスのIPアドレスを指定する必要があるが、フェイルオーバー時に接続が切れるため、rinetdを利用してクラスタのライターエンドポイントを名前解決する形で回避する
- 1つのDatastreamに対して1セットのインスタンステンプレートとインスタンスグループを作成する
LB
- 外部接続はないため内部リージョンを指定
- 接続元のDatastreamのIPアドレス情報を保持しないと通信が返ってこないためパススルーのNLBとする
- 仕様上、レスポンスは直接Datastreamに返すDSRとなる
- Datastreamで参照するIPアドレスを固定化するため静的IPを取得する
- 1つのDatastreamに対して1セットの静的IPとパススルーNLBを作成する
BigQuery
- マイクロサービス + スキーマ毎にデータセットを分ける
- 例）
- online_karte_public
- user_table
- online_karte_public
- 例）
- 各マイクロサービスのプロジェクトでビューを作成し、開発者がデータを利用するため、マイクロサービスのプロジェクト毎にアクセス権限を付与する
ファイアウォール
- IP直接指定はせず、サブネットを跨いだ通信の場合は
サブネット分離、サブネット内では**ターゲット フィルタリング**を検討しタグやサービスアカウントで通信を制御する - アウトバウンドは全て許可し、インバウンドを最低限必要な通信のみ許可する
- インバウンド通信
| 対象VPC | 接続元 | 接続先 | プロトコル | 備考 |
|---|---|---|---|---|
| プライベートサブネット | Datastreamプライベートサブネット | LB | 5432 | |
| プライベートサブネット | LB | GCE | 5432 | |
| プライベートサブネット | GoogleマネージドNW(35.191.0.0/16,130.211.0.0/22) | LB | 22 | ヘルスチェック(デフォルトで解放されている22番を使用) |
AWS
VPN
- GCPとのVPN接続のためSite to Site VPNを設定する
- カスタマーゲートウェイは1つ用意しGCP側に合わせてトンネル数を2とする
- 冗長性を考慮しルーティングは動的とする
- アクセスログはCloudwatch Logsに取得する
- トンネルエンドポイントのライフサイクル制御を有効化し、AWSのメンテによる内部IPの変更やフェイルオーバなどによる更新に対応できるようにする
- BFDがサポートされていないため障害検知のための監視を別途検討する
- ASN
- ステージング
- 65510
- 本番
- 65511
- ステージング
ルートテーブル
- ルートテーブルで
ルート伝播を有効化しGCPのサブネットに自動伝達する(自動で有効化される)
セキュリティグループ
以下のインバウンドを許可する
| 対象SG | 接続元 | プロトコル |
|---|---|---|
| マイクロサービスのAurora | プライベートサブネットのCIDR | 5432 |
コスト
1プロジェクトあたり
転送対象の数に関わらず共通でかかるコスト
AWS 月額コスト試算
| リソース | 台数/設定 | 単価 | 月額コスト |
|---|---|---|---|
| Site-to-Site VPN | 1接続 | $36.50/月 | $36.50 |
| AWS合計 | $36.50 |
GCP 月額コスト試算
| リソース | 台数/設定 | 単価 | 月額コスト |
|---|---|---|---|
| HA VPN Gateway | 1台（2トンネル） | $0.075/時間 | $108.00 |
| GCP合計 | $108.00 |
総合計月額コスト
| プラットフォーム | 月額コスト |
|---|---|
| AWS | $36.50 |
| GCP | $108.00 |
| 総合計 | $144.50 |
1マイクロサービスあたり
転送対象のマイクロサービスが1つ増えるごとにかかるコスト
AWS 月額コスト試算
| リソース | 台数/設定 | 単価 | 月額コスト |
|---|---|---|---|
| データ転送 (VPN) | 50GB(仮)/月 | $0.02/GB | $1.00 |
| AWS合計 | $1.00 |
GCP 月額コスト試算
| リソース | 台数/設定 | 単価 | 月額コスト |
|---|---|---|---|
| GCE VM (e2-micro) | 2台 | $6.12/月 × 2 | $12.24 |
| Static IP Address | 1個 | $1.46/月 | $1.46 |
| 転送ルール (LB) | 1 | $18.25/月 | $18.25 |
| データ処理 (LB) | 50GB/月想定 | $0.008/GB × 50 | $0.4 |
| Datastream | 1ストリーム | $2.00/GiB CDC × 50GiB | $100.00 |
| BigQuery ストレージ | 50GB想定 | $0.01/GB/月 × 50GB | $1.00 |
| GCP合計 | $133.35 |
総合計月額コスト
| プラットフォーム | 月額コスト |
|---|---|
| AWS | $1.00 |
| GCP | $133.35 |
| 総合計 | $134.35 |
注記:
- コストは東京リージョン（ap-northeast-1, asia-northeast1）での試算
- データ転送量は月50GB、BigQueryストレージは50GBで想定(online-karteは実測値約25GB)
- 実際の運用では、オートスケーリングや負荷状況により変動する可能性あり
検討必要なもの
GCP
- セキュリティ
- FW, IAMから独立しておりデータ保護が難しいもの、例えばBQやGCSを保護する仕組み
- 外部NWやGCPマネージドVPC, プロジェクト間での利用制限のポリシーの作成
- サービスアクセスの監視・モニタリング
- 監査ログの取得
- 参考
- GCEのイメージのバージョンアップの運用
- FW, IAMから独立しておりデータ保護が難しいもの、例えばBQやGCSを保護する仕組み
- ログ保管
- NW
- VPCフローログを有効化しS3に転送・保管する仕組み(詳細は別途検討)
- Audit
- 監査ログをしS3に転送・保管する仕組み(詳細は別途検討)
- NW
- 監視
- ルートの割り当て数は上限を超えていないか監視導入を別途検討 参考
- 負荷対策
- GCEのオートスケーリング
AWS
- ログ保管
- NW
- VPNログのS3転送・保管する仕組み
- NW