Datastream GCEプロキシ rinetd→HAProxy移行手順

作成日時: March 12, 2026 作成team: SRE 作成者: 大賀 関連JIRA: SRE-1744

本書について

Datastream用GCEプロキシのソフトウェアをrinetdからHAProxyに移行する手順を記載する
Aurora PostgreSQLフェイルオーバー時のIP変動に自動追従できるようにする
ダウンタイムゼロで移行できる

背景

問題

現在のrinetdは起動時のみDNS名前解決を行い、Auroraフェイルオーバー時のIP変動に追従できない
フェイルオーバー時にDatastream CDCパイプラインが停止し、手動でrinetd再起動が必要

解決策

HAProxyに変更し、5秒ごとの定期的なDNS再解決で自動追従する
検証結果: SRE-1744 にて実証済み（2026-02-13実施）

前提

環境

対象環境: staging → production の順に実施
GCP プロジェクト:
- staging: fd-datastream-stg
- production: fd-datastream-prd
対象サービス:
- online-ops
- online-karte
- 注意: 実施時期によってはonline-doctorも対象となる可能性があります
  - online-doctorが追加されている場合は、同様の手順で移行を実施してください
  - 移行順序: online-ops → online-karte → online-doctor（存在する場合）

現在の構成

GCE: 2台構成（e2-micro）、Instance Group Manager管理
プロキシソフト: rinetd
NLB: パススルーNLB（変更なし）
Datastream: 2つ（online-ops、online-karte）（変更なし）

必要な権限

GCP Project Editor権限
Terraform実行環境へのアクセス

影響

ダウンタイム

GCE: なし（ローリングアップデートにより常に最低2台稼働）
Datastream: なし（一時的な接続断は自動リトライで復旧）
BigQueryデータ転送: 継続（中断なし）

一時的なコスト増加

約3〜5分間、4台のGCEインスタンスが稼働（e2-micro × 2台追加）
追加コスト: 約$0.01〜0.02

Datastream監視設定（既存）

重要: 以下のDatastream監視が既に設定されており、異常時には自動でSlack通知されます。

Datadog監視（メトリクスベース）

監視項目:

datastream-freshness: Datastreamのデータ鮮度を監視
datastream-latency: Datastreamのレイテンシを監視（閾値: 3分）

対象サービス:

online-ops (staging/production)
online-karte (staging/production)

監視設定場所:

datadog/services/online-ops/staging/
datadog/services/online-ops/production/
datadog/services/online-karte/staging/
datadog/services/online-karte/production/

通知先: Slack（異常検知時に自動通知）

GCP Monitoring（ログベース）

監視項目:

datastream-status-error: Datastreamステータスエラー監視
- 検知条件: Datastreamのステータスがエラーに変更された場合（STREAM_STATE_CHANGED）
- 重要度: CRITICAL
- 内容: 同期できていない可能性
datastream-unsupported-events: サポート外イベント監視
- 検知条件: サポートされていないイベントが破棄された場合（UNSUPPORTED_EVENTS_DISCARDED）
- 重要度: CRITICAL
- 内容: BigQueryに転送できていないイベントあり

対象サービス:

online-ops (staging/production)
online-karte (staging/production)

監視設定場所:

gcp/services/fd-datastream/staging/monitoring.tf
gcp/services/fd-datastream/production/monitoring.tf

通知先: GCP Notification Channels経由でSlack通知

参考ドキュメント:

Datastreamの監視設計: 監視設計の考え方と実装の詳細

HAProxy移行後も、これらの監視によりDatastreamの健全性が継続的に監視されます。

作業時間

サービスごとの切り替え作業:

terraform apply実行: 5分
自動入れ替え: 3〜5分
検証: 15分
サービス1つあたり: 約25分

全体スケジュール:

staging環境:
- Day 1: online-ops 切り替え（25分）
- Day 1-3: online-ops 安定性確認（2〜3日）
- Day 4: online-karte 切り替え（25分）
- Day 4-11: 両サービス長期安定性確認（1週間）
- ※online-doctorが存在する場合は、同様に追加実施
production環境（staging確認後）:
- Day 1: online-ops 切り替え（25分）
- Day 1-3: online-ops 安定性確認（2〜3日）
- Day 4: online-karte 切り替え（25分）
- Day 4-: 両サービス長期安定性確認（1週間〜1ヶ月）
- ※online-doctorが存在する場合は、同様に追加実施

注意:

事前準備（スクリプト作成、Terraformコード修正）の時間は含まれていません
フェイルオーバーテストはinfra-dev環境で実施済みのため、staging/productionでは実施不要

概要手順

事前準備

HAProxy起動スクリプト作成
Terraformコード修正（instance_template.tf）
terraform plan確認

メンテ作業（ダウンタイムなし）

サービスごとに順次実施: online-ops → online-karte の順

各サービスごとに以下を実施：

Terraformコード修正
terraform plan確認
terraform apply実行（Instance Template作成）
自動ローリングアップデート監視
検証（HAProxyログ、Datastream接続）
次のサービスへ進む前に安定性確認（2〜3日）

事後作業

長時間安定性確認
- staging: 1週間
- production: 1週間〜1ヶ月
監視アラート設定（別途 SRE-1679 で対応）

注意: フェイルオーバーテストはinfra-dev環境（2026-03-13）で実施済みのため、staging/productionでは不要

詳細手順

Phase 1: 事前準備

1.1 HAProxy起動スクリプト作成

[ ] ディレクトリ作成

bash

mkdir -p gcp/services/fd-datastream/staging/scripts

[ ] HAProxy起動スクリプト作成（gcp/services/fd-datastream/staging/scripts/haproxy-startup.sh）

📄 haproxy-startup.sh の内容（クリックして展開）

bash

#!/bin/bash
set -e

DB_ENDPOINT="${db_endpoint}"
CONF_FILE="/etc/haproxy/haproxy.cfg"
LOG_FILE="/var/log/haproxy-setup.log"

# ログに記録
exec > >(tee -a $LOG_FILE) 2>&1
echo "$(date): Starting HAProxy setup"

# HAProxyとツールのインストール
apt-get update -y
apt-get install -y haproxy socat logrotate

# rsyslog設定（HAProxyログを専用ファイルに分離）
cat > /etc/rsyslog.d/49-haproxy.conf << 'RSYSLOG_EOF'
# HAProxyログを専用ファイルに出力
local0.* /var/log/haproxy.log
& stop
RSYSLOG_EOF

systemctl restart rsyslog

# logrotate設定（HAProxyログのローテーション）
cat > /etc/logrotate.d/haproxy << 'LOGROTATE_EOF'
/var/log/haproxy.log {
    daily
    rotate 7
    missingok
    notifempty
    compress
    delaycompress
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}
LOGROTATE_EOF

# HAProxy設定ファイルを作成
cat > "$CONF_FILE" << 'HAPROXY_EOF'
global
    log /dev/log local0
    log /dev/log local1 notice
    maxconn 256
    nbthread 1
    stats socket /run/haproxy/admin.sock mode 660 level admin

resolvers awsdns
    nameserver dns1 169.254.169.254:53
    resolve_retries 3
    timeout resolve 5s
    timeout retry   5s
    hold valid     5s
    hold other     5s
    hold refused   5s
    hold timeout   5s
    hold obsolete  5s

defaults
    log     global
    mode    tcp
    option  tcplog
    option  dontlognull
    timeout connect 10s
    timeout client  3600s
    timeout server  3600s
    retries 3

frontend pg_front
    bind *:5432
    default_backend pg_aurora

backend pg_aurora
    server aurora1 DB_ENDPOINT_PLACEHOLDER:5432 resolvers awsdns resolve-prefer ipv4 init-addr none check inter 5s
HAPROXY_EOF

# DB_ENDPOINTを置換
sed -i "s/DB_ENDPOINT_PLACEHOLDER/$DB_ENDPOINT/g" "$CONF_FILE"

# HAProxy起動
systemctl restart haproxy
systemctl enable haproxy

echo "$(date): HAProxy setup completed"
echo "Configuration:"
cat $CONF_FILE

注意: production環境用のスクリプトは、staging環境の1週間安定性確認後、production環境の準備時にコピーします（Phase 5.1で実施）

1.2 Terraformコード修正

以下の修正内容を理解した上で、実際の修正は各サービス移行時に実施します。

修正順序: online-ops → online-karte（実際の切り替え順序と同じ）

1. online_ops リソース（1-45行目）の修正内容:

この修正はPhase 2.1.3（online-ops移行時）に実施します。

hcl

# 変更前（3行目）
name = "${var.service_online_ops}-${var.env}-gce-template"

# 変更後
name_prefix = "${var.service_online_ops}-${var.env}-gce-template-"

hcl

# 変更前（22-33行目）
metadata_startup_script = <<EOT
  #! /bin/bash
  DB_ENDPOINT="${local.db_endpoint_online_ops}"
  CONF_FILE="/etc/rinetd.conf"
  apt update -y
  apt install -y rinetd
  if ! grep -q "$DB_ENDPOINT" "$CONF_FILE"; then
    echo "0.0.0.0 5432 $DB_ENDPOINT 5432" >> "$CONF_FILE"
  fi
  systemctl restart rinetd
  systemctl enable rinetd
  EOT

# 変更後
metadata_startup_script = templatefile("${path.module}/scripts/haproxy-startup.sh", {
  db_endpoint = local.db_endpoint_online_ops
})

hcl

# リソースの最後に追加（44行目の後）
lifecycle {
  # ゼロダウンタイムで切り替えるために必要
  # このブロックがないと、Terraformはtemplate削除→作成の順で実行しようとし、
  # Instance Group Managerが使用中のtemplateを削除しようとしてエラーになる
  # create_before_destroy = true により以下の順序が保証される：
  # 1. 新しいInstance Templateを作成（name_prefixで一意の名前）
  # 2. Instance Group Managerの参照を新テンプレートに更新
  # 3. 旧Instance Templateを削除（使用されなくなったため安全）
  create_before_destroy = true
}

2. online_karte リソース（47-91行目）の修正内容:

この修正はPhase 2.2.3（online-ops安定性確認後）に実施します。

hcl

# 変更前（49行目）
name = "${var.service_online_karte}-${var.env}-gce-template"

# 変更後
name_prefix = "${var.service_online_karte}-${var.env}-gce-template-"

hcl

# 変更前（68-79行目）
metadata_startup_script = <<EOT
  #! /bin/bash
  DB_ENDPOINT="${local.db_endpoint_online_karte}"
  CONF_FILE="/etc/rinetd.conf"
  apt update -y
  apt install -y rinetd
  if ! grep -q "$DB_ENDPOINT" "$CONF_FILE"; then
    echo "0.0.0.0 5432 $DB_ENDPOINT 5432" >> "$CONF_FILE"
  fi
  systemctl restart rinetd
  systemctl enable rinetd
  EOT

# 変更後
metadata_startup_script = templatefile("${path.module}/scripts/haproxy-startup.sh", {
  db_endpoint = local.db_endpoint_online_karte
})

hcl

# リソースの最後に追加（90行目の後）
lifecycle {
  # ゼロダウンタイムで切り替えるために必要
  # このブロックがないと、Terraformはtemplate削除→作成の順で実行しようとし、
  # Instance Group Managerが使用中のtemplateを削除しようとしてエラーになる
  # create_before_destroy = true により以下の順序が保証される：
  # 1. 新しいInstance Templateを作成（name_prefixで一意の名前）
  # 2. Instance Group Managerの参照を新テンプレートに更新
  # 3. 旧Instance Templateを削除（使用されなくなったため安全）
  create_before_destroy = true
}

重要: name_prefix + lifecycle.create_before_destroy の変更により、以下のエラーを回避できます：

Terraform削除エラー: "instance_template is already being used by instance_group_manager"
この修正により、新テンプレート作成→参照更新→旧テンプレート削除の順序が保証され、ゼロダウンタイムで適用できます

重要:

上記のTerraformコード修正は説明のみです
実際の修正とapplyは各サービス移行時に実施します（Phase 2で実施）
まずはonline-opsから開始し、安定性確認後にonline-karteを実施します

Phase 2: メンテ作業（Staging環境）

重要: サービスごとに順次実施します（online-ops → online-karte の順）

2.0 事前準備（Staging環境）

2.0.1 Terraformコード修正（online-ops）

[ ] gcp/services/fd-datastream/staging/instance_template.tf を修正
- online-opsリソース修正（1.2節の「1. online_ops リソース」参照）

2.0.2 Terraform Plan確認

[ ] terraform plan確認

bash

cd gcp/services/fd-datastream/staging
terraform plan

[ ] 確認ポイント:
- ✅ google_compute_region_instance_template.online_ops: 新規作成（+）
- ✅ google_compute_region_instance_group_manager.online_ops: 変更（~）
- ❌ LB、VPN、Datastream: 変更なし

2.0.3 チーム内レビュー・Approve

[ ] PRを作成し、チームメンバーにレビュー依頼
[ ] Approveを獲得

2.0.4 Featureチームへ事前通知（online-ops）

[ ] Slackで作業開始を通知

【staging環境メンテナンス開始】
作業内容: Datastream GCEプロキシのHAProxy移行（online-ops）
影響: なし（ダウンタイムゼロで実施）
作業時間: 約25分

2.1 online-ops 移行作業

2.1.1 Datastream接続状態確認（実行前）

[ ] GCP Console → Datastream → ステータス確認
- online-ops: 「実行中」であることを確認

2.1.2 Terraform Apply実行（online-ops のみ）

[ ] terraform apply実行（online-opsリソースのみ適用）
bash
```
cd gcp/services/fd-datastream/staging
terraform apply
```

2.1.3 自動ローリングアップデート監視（online-ops）

自動的に以下の流れで入れ替わる:

新しい2台のGCEインスタンスが追加起動（合計4台稼働）
ヘルスチェック待機（SSH port 22、約30秒）
古い2台のGCEインスタンスが自動削除
最終的に新しい2台（HAProxy）のみ稼働

[ ] Instance Group状態監視（online-ops）

bash

watch -n 10 'gcloud compute instance-groups managed list-instances \
  online-ops-staging-gce-group --region=asia-northeast1 \
  --project=fd-datastream-stg'

→ 4台 → 2台（新）に変わることを確認（約3〜5分）

2.1.4 online-ops 検証（Phase 3の内容を実施）

[ ] HAProxyログ確認
[ ] Datastream接続確認
[ ] Datastreamレイテンシ確認
[ ] Datastreamエラーログ確認

2.1.5 Featureチームへ完了通知（online-ops）

[ ] Slackで作業完了を通知

【staging環境メンテナンス完了】
作業内容: Datastream GCEプロキシのHAProxy移行（online-ops）
結果: 正常完了（online-ops Datastream継続稼働確認）

2.1.6 online-ops 安定性確認（2〜3日）

[ ] 2〜3日間監視し、以下を確認
- Datastream「実行中」状態維持
- Datastreamエラーログの確認
- Datastreamレイテンシ確認
- GCEインスタンス稼働状態
[ ] 問題なければonline-karte移行へ進む

2.2 online-karte 移行作業

online-opsの安定性確認（2〜3日）後に実施

2.2.1 Terraformコード修正（online-karte）

[ ] gcp/services/fd-datastream/staging/instance_template.tf を修正
- online-karteリソース修正（1.2節の「2. online_karte リソース」参照）

2.2.2 Terraform Plan確認

[ ] terraform plan確認

bash

cd gcp/services/fd-datastream/staging
terraform plan

[ ] 確認ポイント:
- ✅ google_compute_region_instance_template.online_karte: 新規作成（+）
- ✅ google_compute_region_instance_group_manager.online_karte: 変更（~）
- ❌ LB、VPN、Datastream: 変更なし

2.2.3 チーム内レビュー・Approve

[ ] PRを作成し、チームメンバーにレビュー依頼
[ ] Approveを獲得

2.2.4 Featureチームへ事前通知（online-karte）

[ ] Slackで作業開始を通知

【staging環境メンテナンス開始】
作業内容: Datastream GCEプロキシのHAProxy移行（online-karte）
影響: なし（ダウンタイムゼロで実施）
作業時間: 約25分

2.2.5 Datastream接続状態確認（実行前）

[ ] GCP Console → Datastream → ステータス確認
- online-karte: 「実行中」であることを確認

2.2.6 Terraform Apply実行（online-karte のみ）

[ ] terraform apply実行（online-karteリソースのみ適用）
bash
```
cd gcp/services/fd-datastream/staging
terraform apply
```

2.2.7 自動ローリングアップデート監視（online-karte）

[ ] Instance Group状態監視（online-karte）

bash

watch -n 10 'gcloud compute instance-groups managed list-instances \
  online-karte-staging-gce-group --region=asia-northeast1 \
  --project=fd-datastream-stg'

→ 4台 → 2台（新）に変わることを確認（約3〜5分）

2.2.8 online-karte 検証（Phase 3の内容を実施）

[ ] HAProxyログ確認
[ ] Datastream接続確認
[ ] Datastreamレイテンシ確認
[ ] Datastreamエラーログ確認

2.2.9 Featureチームへ完了通知（online-karte）

[ ] Slackで作業完了を通知

【staging環境メンテナンス完了】
作業内容: Datastream GCEプロキシのHAProxy移行（online-karte）
結果: 正常完了（online-karte Datastream継続稼働確認）

2.2.10 online-karte 安定性確認（2〜3日）

[ ] 2〜3日間監視し、以下を確認
- Datastream「実行中」状態維持
- Datastreamエラーログの確認
- Datastreamレイテンシ確認
- GCEインスタンス稼働状態

Phase 3: 検証（共通手順）

各サービス（online-karte、online-ops）で以下の検証を実施

3.1 新しいGCEインスタンス確認

[ ] 新しいインスタンス一覧確認

bash

gcloud compute instance-groups managed list-instances \
  <service>-staging-gce-group --region=asia-northeast1 \
  --project=fd-datastream-stg

→ 新しい2台のみ稼働を確認

3.2 HAProxyログ確認

事前準備: GCEへのSSHアクセス時は、一時的にfirewallで35.235.240.0/20（Google Cloud Console SSH用）を解放してください。

[ ] GCP Console → Compute Engine → VM instances から対象インスタンスを選択
[ ] 「SSH」ボタンをクリックしてブラウザSSHでログイン
[ ] ログイン後、以下のコマンドでHAProxyログを確認
bash
```
sudo tail -100 /var/log/haproxy.log
```
確認ポイント:
- DNS解決成功ログ
- Backend接続成功ログ
- エラーがないこと

3.3 Datastream接続確認

[ ] Datastream接続状態確認
- GCP Console → Datastream → 対象サービス
- ステータス: 「実行中」であることを確認
[ ] Datastreamレイテンシ確認
- GCP Console → Datastream → 対象サービス → 「レイテンシ」タブ
- レイテンシが3分以内であることを確認
[ ] Datastreamエラーログ確認
- GCP Consoleでの確認:
  - GCP Console → Datastream → 対象サービス → 「エラー」タブ
  - 接続エラーや同期エラーがないことを確認
- Cloud Loggingでの確認（詳細ログ）:
```
GCP Console → Logging → ログエクスプローラ

クエリ:
resource.type="datastream.googleapis.com/Stream"
resource.labels.stream_id="<service-stream-id>"
severity>=ERROR
timestamp>="<移行時刻>"
```
  - エラーレベルのログがないことを確認
  - 特に接続エラー（connection error）、認証エラー（authentication error）がないこと

Phase 4: 長時間安定性確認（Staging環境）

重要: Staging環境で1週間の安定性確認を実施してからProduction環境へ展開

[ ] 1週間、以下を監視
- Datastream接続状態（GCP Console）
  - online-karte: 「実行中」状態維持
  - online-ops: 「実行中」状態維持
- Datastreamエラーログの確認
- Datastreamレイテンシ確認
- GCEインスタンス稼働状態
[ ] 1週間の監視で問題なければProduction環境へ展開

Phase 5: Production環境展開

重要: サービスごとに順次実施します（online-ops → online-karte の順）

5.1 事前準備（Production）

5.1.1 スクリプトコピー

[ ] production環境用ディレクトリ作成

bash

mkdir -p gcp/services/fd-datastream/production/scripts

[ ] staging環境のスクリプトをproduction環境にコピー

bash

cp gcp/services/fd-datastream/staging/scripts/haproxy-startup.sh \
   gcp/services/fd-datastream/production/scripts/haproxy-startup.sh

5.1.2 Terraformコード修正（online-ops）

[ ] gcp/services/fd-datastream/production/instance_template.tf を修正
- online-opsリソース修正（1.2節の「1. online_ops リソース」参照）

5.1.3 Terraform Plan確認

[ ] terraform plan確認

bash

cd gcp/services/fd-datastream/production
terraform plan

[ ] 確認ポイント:
- ✅ google_compute_region_instance_template.online_ops: 新規作成（+）
- ✅ google_compute_region_instance_group_manager.online_ops: 変更（~）
- ❌ LB、VPN、Datastream: 変更なし

5.1.4 チーム内レビュー・Approve

[ ] PRを作成し、チームメンバーにレビュー依頼
[ ] Approveを獲得

5.2 Featureチームへ事前通知（online-ops）

[ ] Slackで作業開始を通知

【本番環境メンテナンス開始】
作業内容: Datastream GCEプロキシのHAProxy移行（online-ops）
影響: なし（ダウンタイムゼロで実施）
作業時間: 約25分

5.3 online-ops 移行作業（Production）

5.3.1 Terraform Apply実行（online-ops のみ）

[ ] terraform apply実行（online-opsリソースのみ適用）
bash
```
cd gcp/services/fd-datastream/production
terraform apply
```

5.3.2 自動ローリングアップデート監視

[ ] Instance Group状態監視（online-ops）

bash

watch -n 10 'gcloud compute instance-groups managed list-instances \
  online-ops-production-gce-group --region=asia-northeast1 \
  --project=fd-datastream-prd'

→ 4台 → 2台（新）に変わることを確認（約3〜5分）

5.3.3 検証

[ ] Datastream接続確認（Phase 3と同様）
[ ] Datastreamレイテンシ確認（Phase 3と同様）
[ ] Datastreamエラーログ確認（Phase 3と同様）

5.3.4 Featureチームへ完了通知（online-ops）

[ ] Slackで作業完了を通知

【本番環境メンテナンス完了】
作業内容: Datastream GCEプロキシのHAProxy移行（online-ops）
結果: 正常完了（online-ops Datastream継続稼働確認）

5.3.5 安定性確認（2〜3日）

[ ] 2〜3日間監視し、以下を確認
- Datastream「実行中」状態維持
- Datastreamエラーログの確認
- Datastreamレイテンシ確認
- GCEインスタンス稼働状態
[ ] 問題なければonline-karte移行へ進む

5.4 online-karte 移行作業（Production）

online-opsの安定性確認（2〜3日）後に実施

5.4.1 Terraformコード修正（online-karte）

[ ] gcp/services/fd-datastream/production/instance_template.tf を修正
- online-karteリソース修正（1.2節の「2. online_karte リソース」参照）

5.4.2 Terraform Plan確認

[ ] terraform plan確認

bash

cd gcp/services/fd-datastream/production
terraform plan

[ ] 確認ポイント:
- ✅ google_compute_region_instance_template.online_karte: 新規作成（+）
- ✅ google_compute_region_instance_group_manager.online_karte: 変更（~）
- ❌ LB、VPN、Datastream: 変更なし

5.4.3 チーム内レビュー・Approve

[ ] PRを作成し、チームメンバーにレビュー依頼
[ ] Approveを獲得

5.4.4 Featureチームへ事前通知（online-karte）

[ ] Slackで作業開始を通知

【本番環境メンテナンス開始】
作業内容: Datastream GCEプロキシのHAProxy移行（online-karte）
影響: なし（ダウンタイムゼロで実施）
作業時間: 約25分

5.4.5 Terraform Apply実行（online-karte のみ）

[ ] terraform apply実行（online-karteリソースのみ適用）
bash
```
cd gcp/services/fd-datastream/production
terraform apply
```

5.4.6 自動ローリングアップデート監視

[ ] Instance Group状態監視（online-karte）

bash

watch -n 10 'gcloud compute instance-groups managed list-instances \
  online-karte-production-gce-group --region=asia-northeast1 \
  --project=fd-datastream-prd'

→ 4台 → 2台（新）に変わることを確認（約3〜5分）

5.4.7 検証

[ ] Datastream接続確認（Phase 3と同様）
[ ] Datastreamレイテンシ確認（Phase 3と同様）
[ ] Datastreamエラーログ確認（Phase 3と同様）

5.4.8 Featureチームへ完了通知（online-karte）

[ ] Slackで作業完了を通知

【本番環境メンテナンス完了】
作業内容: Datastream GCEプロキシのHAProxy移行（online-karte）
結果: 正常完了（online-karte Datastream継続稼働確認）

5.4.9 安定性確認（2〜3日）

[ ] 2〜3日間監視し、以下を確認
- Datastream「実行中」状態維持
- Datastreamエラーログの確認
- Datastreamレイテンシ確認
- GCEインスタンス稼働状態

Phase 6: 事後確認

6.1 長時間安定性確認（Production）

[ ] 1週間〜1ヶ月、以下を監視
- Datastream「実行中」状態維持
- Datastreamエラーログの確認
- Datastreamレイテンシ確認
- GCEインスタンス稼働状態

6.2 監視設定（別タスク）

[ ] HAProxy固有の監視項目設定（issueで実施）
- HAProxyプロセス死活監視
- バックエンド接続エラー率の監視
- CPU/メモリ使用率の閾値設定

ロールバック手順（問題発生時）

万が一、HAProxy移行後に問題が発生した場合のロールバック手順:

ロールバック実行

[ ] Terraformコードを元に戻す（rinetd版）

[ ] terraform plan確認

bash

cd gcp/services/fd-datastream/staging
terraform plan

[ ] terraform apply実行（rinetd版に戻る）
bash
```
terraform apply
```
→ 同じ自動ローリングアップデートでrinetdに戻る（ダウンタイムゼロ）

トラブルシューティング

問題1: 新しいGCEインスタンスが起動しない

症状: Instance Groupが新しいインスタンスを起動できない

原因:

起動スクリプトのシンタックスエラー
リソース不足（Quota超過）

対処:

GCP Console → Compute Engine → VM instances → ログ確認
起動スクリプトのエラー確認
修正後、再度terraform apply

問題2: HAProxyがAuroraに接続できない

症状: HAProxyログに接続エラーが出る

原因:

DBエンドポイントの設定ミス
AWS VPN接続問題
Aurora セキュリティグループ設定

対処:

HAProxy設定ファイルのDBエンドポイント確認

bash

sudo cat /etc/haproxy/haproxy.cfg | grep "server aurora1"

VPN接続状態確認
Aurora セキュリティグループでGCEサブネット（10.128.0.0/20）からのアクセス許可確認

問題3: Datastreamが接続断エラーを出す

症状: Datastream接続プロファイルでエラー表示

原因:

一時的なネットワーク切断（正常）
HAProxy設定ミス

対処:

継続してエラーの場合、HAProxyログ確認
必要に応じてロールバック

Memo

参考ドキュメント

検証環境での事前テスト

本番・ステージング環境への適用前に、検証環境（infra-dev）でテスト済み:

環境: gcp/services/fd-datastream/infra-dev
検証日: 2026-02-13（初回）、2026-03-13（移行検証・性能実測）
結果:
- ✅ Auroraフェイルオーバー時にDatastream継続稼働確認（2回のフェイルオーバーテスト成功）
- ✅ rinetd→HAProxy移行ダウンタイム: 0秒
- ✅ DNS re-resolution速度: 1秒（設計目標5-15秒を大幅に上回る）
- ✅ Connection recovery時間: 約10秒
- ✅ name_prefix + lifecycle.create_before_destroy修正により全環境でゼロダウンタイム移行が可能

Datastream GCEプロキシ rinetd→HAProxy移行手順 ​

本書について ​

背景 ​

問題 ​

解決策 ​

前提 ​

環境 ​

現在の構成 ​

必要な権限 ​

影響 ​

ダウンタイム ​

一時的なコスト増加 ​

Datastream監視設定（既存） ​

Datadog監視（メトリクスベース） ​

GCP Monitoring（ログベース） ​

作業時間 ​

概要手順 ​

事前準備 ​

メンテ作業（ダウンタイムなし） ​

事後作業 ​

詳細手順 ​

Phase 1: 事前準備 ​

1.1 HAProxy起動スクリプト作成 ​

1.2 Terraformコード修正 ​

Phase 2: メンテ作業（Staging環境） ​

2.0 事前準備（Staging環境） ​

2.0.1 Terraformコード修正（online-ops） ​

2.0.2 Terraform Plan確認 ​

2.0.3 チーム内レビュー・Approve ​

2.0.4 Featureチームへ事前通知（online-ops） ​

2.1 online-ops 移行作業 ​

2.1.1 Datastream接続状態確認（実行前） ​

2.1.2 Terraform Apply実行（online-ops のみ） ​

2.1.3 自動ローリングアップデート監視（online-ops） ​

2.1.4 online-ops 検証（Phase 3の内容を実施） ​

2.1.5 Featureチームへ完了通知（online-ops） ​

2.1.6 online-ops 安定性確認（2〜3日） ​

2.2 online-karte 移行作業 ​

2.2.1 Terraformコード修正（online-karte） ​

2.2.2 Terraform Plan確認 ​

2.2.3 チーム内レビュー・Approve ​

2.2.4 Featureチームへ事前通知（online-karte） ​

2.2.5 Datastream接続状態確認（実行前） ​

2.2.6 Terraform Apply実行（online-karte のみ） ​

2.2.7 自動ローリングアップデート監視（online-karte） ​

2.2.8 online-karte 検証（Phase 3の内容を実施） ​

2.2.9 Featureチームへ完了通知（online-karte） ​

2.2.10 online-karte 安定性確認（2〜3日） ​

Phase 3: 検証（共通手順） ​

3.1 新しいGCEインスタンス確認 ​

3.2 HAProxyログ確認 ​

3.3 Datastream接続確認 ​

Phase 4: 長時間安定性確認（Staging環境） ​

Phase 5: Production環境展開 ​

5.1 事前準備（Production） ​

5.1.1 スクリプトコピー ​

5.1.2 Terraformコード修正（online-ops） ​

5.1.3 Terraform Plan確認 ​

5.1.4 チーム内レビュー・Approve ​

5.2 Featureチームへ事前通知（online-ops） ​

5.3 online-ops 移行作業（Production） ​

5.3.1 Terraform Apply実行（online-ops のみ） ​

5.3.2 自動ローリングアップデート監視 ​

5.3.3 検証 ​

5.3.4 Featureチームへ完了通知（online-ops） ​

5.3.5 安定性確認（2〜3日） ​

5.4 online-karte 移行作業（Production） ​

5.4.1 Terraformコード修正（online-karte） ​

5.4.2 Terraform Plan確認 ​

5.4.3 チーム内レビュー・Approve ​

5.4.4 Featureチームへ事前通知（online-karte） ​

5.4.5 Terraform Apply実行（online-karte のみ） ​

5.4.6 自動ローリングアップデート監視 ​

5.4.7 検証 ​

5.4.8 Featureチームへ完了通知（online-karte） ​

5.4.9 安定性確認（2〜3日） ​

Phase 6: 事後確認 ​

6.1 長時間安定性確認（Production） ​

6.2 監視設定（別タスク） ​

ロールバック手順（問題発生時） ​

Datastream GCEプロキシ rinetd→HAProxy移行手順

本書について

背景

問題

解決策

前提

環境

現在の構成

必要な権限

影響

ダウンタイム

一時的なコスト増加

Datastream監視設定（既存）

Datadog監視（メトリクスベース）

GCP Monitoring（ログベース）

作業時間

概要手順

事前準備

メンテ作業（ダウンタイムなし）

事後作業

詳細手順

Phase 1: 事前準備

1.1 HAProxy起動スクリプト作成

1.2 Terraformコード修正

Phase 2: メンテ作業（Staging環境）

2.0 事前準備（Staging環境）

2.0.1 Terraformコード修正（online-ops）

2.0.2 Terraform Plan確認

2.0.3 チーム内レビュー・Approve

2.0.4 Featureチームへ事前通知（online-ops）

2.1 online-ops 移行作業

2.1.1 Datastream接続状態確認（実行前）

2.1.2 Terraform Apply実行（online-ops のみ）

2.1.3 自動ローリングアップデート監視（online-ops）

2.1.4 online-ops 検証（Phase 3の内容を実施）

2.1.5 Featureチームへ完了通知（online-ops）

2.1.6 online-ops 安定性確認（2〜3日）

2.2 online-karte 移行作業

2.2.1 Terraformコード修正（online-karte）

2.2.2 Terraform Plan確認

2.2.3 チーム内レビュー・Approve

2.2.4 Featureチームへ事前通知（online-karte）

2.2.5 Datastream接続状態確認（実行前）

2.2.6 Terraform Apply実行（online-karte のみ）

2.2.7 自動ローリングアップデート監視（online-karte）

2.2.8 online-karte 検証（Phase 3の内容を実施）

2.2.9 Featureチームへ完了通知（online-karte）

2.2.10 online-karte 安定性確認（2〜3日）

Phase 3: 検証（共通手順）

3.1 新しいGCEインスタンス確認

3.2 HAProxyログ確認

3.3 Datastream接続確認

Phase 4: 長時間安定性確認（Staging環境）

Phase 5: Production環境展開

5.1 事前準備（Production）

5.1.1 スクリプトコピー

5.1.2 Terraformコード修正（online-ops）

5.1.3 Terraform Plan確認

5.1.4 チーム内レビュー・Approve

5.2 Featureチームへ事前通知（online-ops）

5.3 online-ops 移行作業（Production）

5.3.1 Terraform Apply実行（online-ops のみ）

5.3.2 自動ローリングアップデート監視

5.3.3 検証

5.3.4 Featureチームへ完了通知（online-ops）

5.3.5 安定性確認（2〜3日）

5.4 online-karte 移行作業（Production）

5.4.1 Terraformコード修正（online-karte）

5.4.2 Terraform Plan確認

5.4.3 チーム内レビュー・Approve

5.4.4 Featureチームへ事前通知（online-karte）

5.4.5 Terraform Apply実行（online-karte のみ）

5.4.6 自動ローリングアップデート監視

5.4.7 検証

5.4.8 Featureチームへ完了通知（online-karte）

5.4.9 安定性確認（2〜3日）

Phase 6: 事後確認

6.1 長時間安定性確認（Production）

6.2 監視設定（別タスク）

ロールバック手順（問題発生時）