FastDoctor AWS Infrastructure

Appearance

feature-flag-service インフラ削除手順書 ​

staging / production の feature-flag-service インフラを廃止する際の手順書です。

0. 前提・全体方針 ​

  • 対象環境: staging → production の順で実施（staging で検証してから本番）。
  • コード削除 PR（feature-flag-service/{staging,production} ディレクトリ削除等）は、 AWS リソースを destroy / 手動削除し終えた後の最終仕上げとしてマージする。 コードを先に消すと terraform destroy ができなくなるため、順序厳守。
  • 残置するもの（他サービスが使用 / 共有のため触らない）:
    • bastion SG・chronic-api の ECS SG・VPC / subnet / Network ACL（feature-flag 側からは remote_state 参照のみ）
    • 共有 Datadog ログアーカイブ用 S3 バケット（common state 管理の共有バケット）
    • us-east-1 の CodeStar Connection（共有）
  • 削除されるが特別扱いが必要なもの:
    • RDS Aurora: deletion_protection=true が共有モジュール（modules/rds_aurora）に ハードコードされ、skip_final_snapshot 未設定（=false）。共有モジュールは編集しないため RDS は手動削除する。最終スナップショットは残さない。
    • ECR / S3（deploy・ALBログ）: force_delete / force_destroy 未設定 → 中身を空にしてから destroy。
    • Secrets Manager: recovery_window_in_days=0 → destroy で即時完全削除（復旧不可）。
    • KMS キー（2個）: deletion_window_in_days=7 → destroy 後 7日間 Pending Deletion （必要なら aws kms cancel-key-deletion で復旧可）。

⚠️ 事前確認: chronic-api → feature-flag-service（SG :80）のアプリ依存が解消済みであること。 本作業前に Datadog / ALB のアクセスメトリクスで feature-flag-service への流入が無いことを確認する。

1. 事前準備（環境ごと） ​

bash
# 対象環境のアカウントへ role assume（staging / production を間違えない）
aws sts get-caller-identity   # アカウントID を必ず確認

cd fastdoctor-template/feature-flag-service/<staging|production>
./download-tfvar.sh           # S3 から terraform.tfvars を取得
terraform init
terraform state list          # 削除対象リソース一覧を確認（バケット名等の実名もここで確定）

リソース実名の確認（destroy 前に控える）:

bash
terraform state show 'module.microservice-ecs.module.db.aws_rds_cluster.default' | grep -E 'cluster_identifier|deletion_protection'
# S3 バケット実名（s3_prefix 既定のため概ね下記。state で要確認）
#   deploy:   feature-flag-service-<staging|production>
#   ALB logs: feature-flag-service-alb-logs-<staging|production>
# ECR リポジトリ名: feature-flag-service

2. 手動の事前クリーンアップ（destroy をブロックする中身の削除） ​

2-1. ECR イメージ削除（コンソール推奨） ​

force_delete 未設定のため、イメージが残っていると repository の destroy が失敗する。

  • コンソール: ECR → Repositories → feature-flag-service → 全イメージ選択 → Delete（件数が多くても速い）

  • CLI 例:

    bash
    aws ecr list-images --repository-name feature-flag-service --query 'imageIds[*]' --output json > /tmp/ff-images.json
aws ecr batch-delete-image --repository-name feature-flag-service --image-ids file:///tmp/ff-images.json

2-2. S3 バケットを空にする（コンソール推奨） ​

force_destroy 未設定のため、オブジェクトが残っていると bucket の destroy が失敗する。 バージョニング有効な場合は旧バージョン / 削除マーカーも消す必要があり、コンソールの「空にする(Empty)」が確実かつ速い。

  • コンソール: 対象バケット → 「空にする」
    • feature-flag-service-<env>（deploy）
    • feature-flag-service-alb-logs-<env>（ALBアクセスログ）
  • CLI を使う場合（バージョニング無しなら）: aws s3 rm s3://<bucket> --recursive

2-3. 進行中の Pipeline / デプロイがないこと確認 ​

CodePipeline / CodeDeploy が実行中だと ECS / ALB の destroy が詰まる。実行中なら停止を待つ。

2-4. RDS Aurora を手動削除（最終スナップショットなし） ​

共有モジュールの deletion_protection=true / skip_final_snapshot=false により terraform destroy では消せないため手動で削除する。

  1. 削除保護を解除

    bash
    aws rds modify-db-cluster --db-cluster-identifier feature-flag-service \
  --no-deletion-protection --apply-immediately

    （コンソール: RDS → 該当クラスター → 変更 → 「削除保護」オフ → すぐに適用）

  2. クラスター削除（最終スナップショット作成しない）

    • コンソール: RDS → クラスター feature-flag-service → アクション → 削除 → 「最終スナップショットを作成」チェックを外す → 確認入力して削除（インスタンスも一括削除される）

    • CLI の場合（インスタンス → クラスターの順）:

      bash
      aws rds delete-db-instance --db-instance-identifier feature-flag-service-0 --skip-final-snapshot
aws rds delete-db-instance --db-instance-identifier feature-flag-service-1 --skip-final-snapshot
aws rds delete-db-cluster  --db-cluster-identifier feature-flag-service --skip-final-snapshot

  3. クラスターが完全に消えるまで待つ（削除完了後、terraform からは「存在しない」と認識され、 後続の destroy でスナップショット要求は発生しない）。

補足: 手動削除後に terraform 側に残る db_subnet_group / parameter_group / rds-sg / 拡張モニタリング IAM ロールは、後続の terraform destroy が通常通り削除する。

3. terraform destroy（★ここで terraform 実行 / 複数回になる想定） ​

bash
cd fastdoctor-template/feature-flag-service/<env>
terraform plan -destroy -var-file=terraform.tfvars   # 削除対象をレビュー（残置すべき共有リソースが含まれていないか確認）
terraform destroy -var-file=terraform.tfvars
  • 複数回実行する想定: ALB / ENI の解放や SG の依存解決でタイミング依存の失敗が起きやすい。 失敗したら数分待って terraform destroy を再実行する（2〜3回想定）。
  • destroy で削除される SG ingress ルール（db-sg-from-bastion / lb-sg-from-chronic-api）は feature-flag 自身の SG 上のルールであり、参照元の bastion / chronic-api SG 本体は残置される。
  • Datadog ログアーカイブ設定（datadog_logs_archive）も destroy 対象。download-tfvar.sh 取得済みの tfvars に Datadog API / APP キーが含まれている必要がある（含まれていないと destroy 中に失敗するので、 その場合は enable_datadog_logs_archive=false 相当の対応を検討）。
  • terraform state list が空になったら destroy 完了。

4. state / tfvars の後片付け ​

destroy 完了後、残る backend / 変数ファイルを削除（コンソール推奨）。

  • tfstate: s3://fd-tfstate-<staging|prd>/feature-flag-service.tfstate
  • tfvars: s3://fd-<staging|production>-tfvars-files/（feature-flag-service 用）

これらは destroy では消えない（backend と入力ファイルのため）。コンソールから該当オブジェクトを削除。

5. コード削除 PR のマージ（★全環境の AWS 削除完了後） ​

staging / production 両方の上記 1〜4 が完了したのを確認してから、コード削除 PR をマージする。PR の内容:

  • fastdoctor-template/feature-flag-service/{staging,production}/ 削除
  • .github/CODEOWNERS / .github/config/categories.yaml / .github/filters-terraform-plan@{staging,production}.yml から feature-flag-service 記述を除去
  • docs/aws/architecture/network-diagrams.md / network-impact.md の記述更新

6. 完了後チェック ​

  • [ ] staging / production とも terraform state list が空
  • [ ] ECR / RDS / ALB / ECS / SG / Secrets / S3（deploy・ALBログ）がコンソール上で消えている
  • [ ] KMS キー2個が Pending Deletion（7日後完全削除。誤削除時は aws kms cancel-key-deletion）
  • [ ] tfstate / tfvars オブジェクト削除済み
  • [ ] 残置対象（bastion / chronic SG・VPC・共有 Datadog バケット）が残っていること
  • [ ] chronic-api 側でエラー増加が無いこと（Datadog で監視）