Cost and Teardown

สิ่งที่จะสร้าง

ทุกอย่างจนถึงตอนนี้เพิ่ม resource บทนี้เกี่ยวกับมิเตอร์ที่หมุนอยู่และวิธีปิด สามส่วน:

cost model — ตัวเลขคร่าว ๆ แบบซื่อสัตย์ว่า CloudDeploy มี cost ต่อเดือนเท่าไหร่: สาม managed control plane, สามชุด worker node, สาม managed Postgres instance, สาม load balancer, บวก state และ egress
ทำให้มองเห็น — tag/label บนทุก resource เพื่อให้ spend attribute ได้ต่อ cloud และต่อ project และ budget พร้อม alert บนแต่ละ cloud เพื่อให้ resource ที่หลุดควบคุม ping คุณก่อนใบแจ้งหนี้จะมา
teardown ที่สะอาด — terragrunt run --all destroy ต่อ cloud ในลำดับที่ถูกต้อง บวก resource ที่ ไม่ หายไปเอง และจะยัง charge คุณต่อถ้าลืม

และสุดท้าย ส่วนที่คอร์สติดค้างคุณอยู่: trade-off ที่ตรงไปตรงมา ของการสร้างสิ่งนี้บนสาม cloud แทนที่จะเป็น cloud เดียว

ทำไม

multi-cloud capstone ที่คุณปล่อยรันทิ้งไว้คือวิธีพิสูจน์ประเด็นที่แพง ทักษะไม่ใช่แค่การตั้ง platform ขึ้นมา — แต่คือการรู้ว่า cost เท่าไหร่ตอนที่รันอยู่ เห็น cost นั้นแยกย่อยเพื่อให้ reason ได้ และเอาลงได้ ทั้งหมด ด้วยความมั่นใจว่าไม่มีอะไรถูกทิ้งให้ bill อยู่เงียบ ๆ load balancer ที่ถูกทิ้งและ disk ที่ไม่ถูกลบคือรายการคลาสสิกของ “นึกว่า destroy ไปแล้ว”; วินัยตรงนี้คือการทำให้ teardown เชื่อถือได้เท่ากับ apply

why ที่ใหญ่กว่าคือความซื่อสัตย์ทางปัญญา “เรารันบนสาม cloud” ฟังดูน่าประทับใจ และโครงสร้าง DRY Terragrunt ทำให้ จัดการได้ — แต่ไม่ฟรี และไม่ลึกต่อ cloud เท่า single-cloud build การเรียกชื่อ trade นั้นตรง ๆ คือความต่างระหว่าง portfolio piece กับ cargo cult

ข้อดีข้อเสีย

Managed ทุกอย่าง (EKS/GKE/AKS + RDS/Cloud SQL/Azure DB) เทียบกับ self-hosting บน VM เปล่า

Pros: managed control plane, patching, และ backup คือสิ่งที่ทำให้คนเดียวรัน platform รูปทรง production บนสาม cloud ได้เลย คุณจ่ายค่า control-plane hour และ managed-DB instance แล้วได้เวลาคืนมา
Cons: สาม managed control plane บวกสาม managed database คือส่วนใหญ่ของ bill และเป็นพื้นที่คุณจ่ายแม้ตอน cluster idle self-hosting บน VM ถูกกว่าตอนพักและเป็นงานมากกว่ามาก — trade ที่ผิดสำหรับ teaching platform, trade ที่ถูกที่จะ รู้ ว่ามีอยู่

Destroy ตอน idle เทียบกับปล่อย platform รัน

Pros: run --all destroy ต่อ cloud ลด spend เหลือแทบไม่มีอะไร (แค่ state storage) และเพราะทั้ง platform อยู่ใน code run --all apply เอากลับมา byte-for-byte เมื่อคุณต้องการ สำหรับคอร์สหรือ demo destroy-ตอน-idle คือ default ที่ถูก
Cons: cold rebuild กินเวลาจริง (cluster และ DB สร้างช้า) และอะไรก็ตามที่อยู่แค่ใน cluster — data ใน DB ของ ShopMicro, Keycloak user ที่สร้างด้วยมือ — หายไปเว้นแต่คุณ export ออกมา persistent environment เลี่ยงเรื่องนั้นโดยแลกกับการจ่ายเงินเปิดทิ้งไว้

ติดตั้ง

1. Tag and label everything

attribution เริ่มที่ provisioning ตั้ง default tag/label ที่ระดับ provider เพื่อให้ทุก resource ใน cloud พกไว้ และ cost tool slice ได้ตาม project และ cloud AWS ใช้ default_tags บน provider; GCP ใช้ resource labels; Azure ใช้ resource tags:

# generated per cloud from root.hcl — AWS example
provider "aws" {
  region = "us-east-1"
  default_tags {
    tags = {
      project = "clouddeploy"
      cloud   = "aws"
      managed = "terragrunt"
    }
  }
}

ด้วย tag ที่สม่ำเสมอ cost explorer ของแต่ละ cloud (AWS Cost Explorer, billing report ของ GCP, Azure Cost Management) ตอบ “CloudDeploy cost ฉันเท่าไหร่บน cloud นี้” ได้ใน filter เดียว

2. A budget with alerts, per cloud

budget ไม่หยุด spend แต่เปลี่ยนใบแจ้งหนี้ที่ทำให้ตกใจให้เป็นสัญญาณเตือนล่วงหน้า นิยามหนึ่งตัวต่อ cloud ใน Terraform — aws_budgets_budget, google_billing_budget, azurerm_consumption_budget_subscription — แต่ละตัวมี limit รายเดือนและ alert threshold (เช่น 50% / 80% / 100%) ที่ email หรือ page คุณ:

# modules/aws/... — an AWS monthly cost budget with alerts
resource "aws_budgets_budget" "clouddeploy" {
  name         = "clouddeploy-monthly"
  budget_type  = "COST"
  limit_amount = "300"
  limit_unit   = "USD"
  time_unit    = "MONTHLY"

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 80
    threshold_type             = "PERCENTAGE"
    notification_type          = "ACTUAL"
    subscriber_email_addresses = ["you@example.com"]
  }
}

สาม budget, สาม threshold — เพื่อให้ load balancer ที่ค้างหรือ node pool ที่ใหญ่เกินประกาศตัวเองตอนที่ยังเป็นเศษปัดเศษ

3. A clean `terragrunt run --all destroy` per cloud

teardown คือ apply ย้อนกลับ terragrunt run --all destroy เดิน dependency graph ถอยหลัง — ShopMicro และ platform Helm release ก่อน, จากนั้น IAM, จากนั้น cluster และ data, จากนั้น network ท้ายสุด — เพื่อให้ไม่มีอะไรถูก destroy ขณะที่ยังมีตัวอื่นพึ่งอยู่:

cd live/aws
terragrunt run --all destroy --terragrunt-non-interactive

ทำแบบนี้ต่อ cloud (live/aws, live/gcp, live/azure) บางสิ่ง ไม่ หายไปกับ graph และจะยัง charge คุณต่อถ้าลืม:

Cloud load balancer ที่สร้างโดย Kubernetes Service type=LoadBalancer / ingress, ไม่ใช่โดย Terraform destroy Helm release (หรือ kubectl delete ingress) ก่อน cluster เพื่อให้ cloud LB ถูกปล่อย; LB ที่ค้างจะอยู่รอด cluster ของตัวเองและ bill ต่อ
Persistent volume / managed disk ที่ back StatefulSet (Keycloak, datastore ของ GrowthBook) เช็กว่าถูก reclaim จริง
State backend เอง — S3/GCS/Azure Storage bucket และ DynamoDB lock table พวกนี้ตั้งใจ ไม่ อยู่ใน graph ของ live/ (ไม่งั้นจะเป็น chicken-and-egg) จึงรอด run --all destroy ลบด้วยมือเมื่อคุณเสร็จจริง ๆ เท่านั้น และหลังจากยืนยันว่า state ว่างเปล่าแล้ว

ลำดับสำคัญ: tear workload และ platform ลงก่อน (ปล่อย cloud LB และ disk), จากนั้น infrastructure, จากนั้น — อย่างจงใจ, ท้ายสุด, ด้วยมือ — state backend

4. The honest multi-cloud trade-offs

การสร้างบนสาม cloud ซื้ออะไรมาจริง ๆ และ cost อะไร:

DRY, ไม่ใช่ฟรี Terragrunt กันไม่ให้ config ถูก triplicate แต่ยังมีสาม IAM model, สาม ingress/LB behavior, และสาม managed-DB quirk ที่ต่างกันจริง — module interface ที่สม่ำเสมอซ่อนความต่างจาก live/ wiring, ไม่ใช่จากคุณ
กว้าง, ไม่ใช่ลึก หนึ่ง region และหนึ่ง environment ต่อ cloud พอที่จะ demonstrate portability; นี่ ไม่ใช่ production single-cloud build ที่มี multi-region, ความลึกของ autoscaling, และ tuning ต่อ cloud single-cloud course จะลงลึกในที่ที่บทนี้ไปกว้าง
cost floor 3 เท่า สาม control plane และสาม managed DB คือขั้นต่ำรายเดือนจริงที่คุณจ่ายแม้ตอน idle — ราคาตรงของ portability
Portability มีเพดาน platform layer ที่ cloud-neutral (Datadog/Keycloak/GrowthBook บน Helm) ย้ายได้จริงโดยไม่เปลี่ยน; layer ที่อยู่ข้างใต้ (network, cluster, data, IAM) ไม่ได้ และการแกล้งว่าทุก layer สลับกันได้ คือจุดที่ multi-cloud project เข้าสู่ปัญหา

multi-cloud คือคำตอบที่ถูกเมื่อ portability หรือการเลี่ยง lock-in เป็นความต้องการจริง เมื่อไม่ใช่ cloud เดียวที่ทำลึก ๆ มักเป็น engineering ที่ดีกว่า — และตอนนี้คุณพูด ได้ว่าทำไม พร้อมใบเสร็จ

ตรวจสอบผล

Tear down หนึ่ง cloud แล้วยืนยันว่าว่างเปล่าจริง destroy AWS tree:

cd live/aws
terragrunt run --all destroy --terragrunt-non-interactive

คาดหวัง: Terragrunt destroy ในลำดับ dependency ย้อนกลับและจบอย่างสะอาด:

INFO   The stack at . will be processed in the following order for command destroy:
Group 1
- Module ./shopmicro
Group 2
- Module ./platform
- Module ./iam
Group 3
- Module ./cluster
- Module ./data
Group 4
- Module ./network
...
Destroy complete! Resources: 34 destroyed.

จากนั้นยืนยันว่าไม่มีอะไรค้าง — re-plan ควรอยาก สร้าง ทุกอย่างใหม่อีกครั้ง (พิสูจน์ว่า state ว่างเปล่า) และ cloud LB ควรหายไป:

terragrunt run --all plan --terragrunt-non-interactive | tail -n 3
# => Plan: 34 to add, 0 to change, 0 to destroy.

aws elbv2 describe-load-balancers --region us-east-1 \
  --query "LoadBalancers[?contains(Tags[?Key=='project'].Value, 'clouddeploy')]"
# => []   (no CloudDeploy load balancer left billing)

run --all plan ที่อยากเพิ่มทุกอย่างกลับมา และ load-balancer list ที่ว่างเปล่า คือ teardown ที่สะอาด ทำซ้ำสำหรับ gcp และ azure จากนั้นลบ state backend ด้วยมือ

ตรวจสอบความเข้าใจ

ทำไมรายการที่ใหญ่ที่สุดบน CloudDeploy ถึงมาจากบริการ managed และเหตุผลบรรทัดเดียวที่ยังเป็น trade ที่ถูกสำหรับ platform นี้คืออะไร?
terragrunt run --all destroy เดิน graph ถอยหลัง ทำไม ShopMicro และ platform Helm release ต้องถูก destroy ก่อน cluster — อะไรรั่วถ้าคุณไม่ทำ?
state backend bucket รอด run --all destroy ทำไมจึงตั้งใจอยู่นอก graph ของ live/ และคุณลบเมื่อไหร่?
ระบุ case ที่ซื่อสัตย์ทั้งฝ่ายสนับสนุนและคัดค้านการสร้างสิ่งนี้บนสาม cloud multi-cloud เป็นทางเลือกที่ถูกเมื่อไหร่ และ one-cloud-deep เป็น engineering ที่ดีกว่าเมื่อไหร่?

สรุป

ตอนนี้คุณ account platform และปิดได้อย่างสะอาด: cost model คร่าว ๆ ที่ครอบงำโดยสาม managed control plane และสาม managed database, default tag/label ที่ทำให้ spend attribute ได้, budget ต่อ cloud พร้อม alert เป็นมิเตอร์เตือนล่วงหน้า, และ terragrunt run --all destroy ที่ tear แต่ละ cloud ลงในลำดับ dependency ย้อนกลับ — โดยระวัง cloud LB, disk, และ state backend ที่ไม่หายไปเอง และคุณ defend ทางเลือก multi-cloud ได้อย่างซื่อสัตย์: DRY แต่ไม่ฟรี, กว้างแต่ไม่ลึก, portable ที่ platform layer แต่ไม่ใช่ชั้นที่อยู่ข้างใต้

นั่นคือ lifecycle เต็ม — provision, run, observe, secure, ship, และ tear down ข้ามสาม cloud ถึงเวลาถอยออกมาดูสิ่งที่คุณสร้างและสิ่งที่คุณ defend ได้แล้ว: Wrap-up →