Performance Optimization #

# Selalu ukur sebelum optimasi — jangan asumsi di mana bottleneck-nya

# Aktifkan logging detail
TF_LOG=INFO terraform plan 2>&1 | grep -E "provider|Refreshing|Reading"

# Atau gunakan timestamp untuk setiap fase
time terraform init
time terraform plan
time terraform apply

# Untuk profiling yang lebih detail (Terraform 1.2+)
TF_LOG=TRACE terraform plan 2>&1 | grep "provider.aws" | tail -50
# Ini menampilkan semua API call ke AWS provider

# Output yang perlu diperhatikan:
# [INFO] provider.aws: Refreshing state... (aws_instance.web)
# → Setiap baris ini adalah satu API call
# → Jika ada ratusan baris, ini sumber lambatnya

# ANTI-PATTERN: Selalu refresh (default)
terraform plan
# → Terraform memanggil API cloud untuk setiap resource di state
# → 200 resource = 200 API call sebelum plan mulai
# → Bisa memakan waktu menit jika banyak resource

# BENAR: Skip refresh jika state sudah diketahui akurat
terraform plan -refresh=false
# → Langsung bandingkan konfigurasi dengan state yang ada
# → Jauh lebih cepat, tapi tidak mendeteksi drift

# Kapan -refresh=false AMAN digunakan:
# ✓ Pipeline CI/CD di mana tidak ada yang bisa ubah infrastruktur di luar Terraform
# ✓ Saat iterasi cepat saat develop konfigurasi baru
# ✓ Setelah apply baru saja dijalankan (state pasti akurat)

# Kapan -refresh=false TIDAK AMAN:
# ✗ Jika ada kemungkinan perubahan manual di cloud
# ✗ Untuk drift detection (justru butuh refresh)
# ✗ Sebelum apply ke production yang sudah lama tidak di-plan

# Default parallelism adalah 10
terraform apply

# Naikkan untuk infrastruktur dengan banyak resource independen
terraform apply -parallelism=20

# Turunkan jika sering kena API rate limit
terraform apply -parallelism=5

# Untuk AWS: rate limit berbeda per service
# EC2: cukup tinggi (bisa parallelism 20+)
# IAM: lebih ketat (tetap di 5-10)
# CloudFormation: sangat ketat (turun ke 3-5)

# Temukan nilai optimal dengan eksperimen:
for p in 5 10 15 20; do
  echo "Testing parallelism=$p"
  time terraform apply -parallelism=$p -auto-approve
done

# ANTI-PATTERN: Data source yang dipanggil terlalu sering
# Setiap resource memanggil data source sendiri-sendiri
resource "aws_instance" "web_1" {
  ami = data.aws_ami.ubuntu.id  # 1 API call
}
resource "aws_instance" "web_2" {
  ami = data.aws_ami.ubuntu.id  # API call yang sama lagi (tapi Terraform cache-nya)
}
# Terraform otomatis cache data source yang sama — ini sebenarnya OK

# Yang BENAR-BENAR bermasalah: data source dengan filter yang berat
data "aws_instances" "all_running" {
  filter {
    name   = "instance-state-name"
    values = ["running"]
  }
  # Ini list SEMUA running instance → mahal jika ada ribuan instance
}

# BENAR: Gunakan filter yang lebih spesifik
data "aws_instances" "web_fleet" {
  filter {
    name   = "tag:Role"
    values = ["web-server"]
  }
  filter {
    name   = "tag:Environment"
    values = ["production"]
  }
  # Filter ketat → API call lebih ringan
}

# ANTI-PATTERN: Data source untuk nilai yang sudah diketahui
data "aws_region" "current" {}
data "aws_caller_identity" "current" {}

# Jika region dan account ID sudah diketahui dan tidak berubah,
# lebih efisien menggunakan variable atau local
locals {
  region     = "ap-southeast-1"
  account_id = "123456789012"
}

# Data source tetap berguna untuk nilai yang memang dinamis
# (AMI terbaru, AZ yang available, dll.)

# Hanya plan resource tertentu
terraform plan -target=aws_instance.web
terraform plan -target=module.database

# Hanya apply resource tertentu
terraform apply -target=aws_security_group.new_rule

# Berguna untuk:
# ✓ Debug — isolasi resource yang bermasalah
# ✓ Bootstrap — buat resource yang dibutuhkan sebelum yang lain
# ✓ Emergency fix — perbaiki satu resource tanpa risiko ke yang lain

# Setup provider cache (di CI/CD atau lokal)
export TF_PLUGIN_CACHE_DIR="$HOME/.terraform.d/plugin-cache"
mkdir -p $TF_PLUGIN_CACHE_DIR

# Sekarang terraform init akan cek cache sebelum download
terraform init
# Jika provider sudah di cache → langsung gunakan, tidak download ulang

# Di GitHub Actions: cache provider dengan actions/cache
- name: Cache Terraform Plugins
  uses: actions/cache@v4
  with:
    path: ~/.terraform.d/plugin-cache
    key: ${{ runner.os }}-terraform-${{ hashFiles('**/.terraform.lock.hcl') }}
    restore-keys: |
      ${{ runner.os }}-terraform-

- name: Terraform Init
  run: terraform init
  env:
    TF_PLUGIN_CACHE_DIR: ~/.terraform.d/plugin-cache

# ANTI-PATTERN: terraform init yang download ulang setiap saat
terraform init  # Selalu download dari registry

# BENAR: Gunakan -upgrade hanya saat memang perlu upgrade provider
terraform init          # Gunakan versi yang sudah di-lock
terraform init -upgrade # Hanya saat ingin upgrade ke versi terbaru

# Untuk CI/CD: skip backend init jika tidak perlu
terraform init -backend=false  # Untuk validate saja, tanpa akses state

# Waktu benchmark tipikal:
# terraform init tanpa cache:   30-60 detik (download provider)
# terraform init dengan cache:  2-5 detik (copy dari cache)
# Selisih ini signifikan jika pipeline berjalan puluhan kali sehari

# Default: 10 resource paralel
terraform apply

# Naikkan untuk infrastruktur besar
terraform apply -parallelism=20

# Turunkan jika API rate-limited
terraform apply -parallelism=3

# Untuk provider yang sensitif terhadap concurrent request
# (misalnya: beberapa SaaS API)
terraform apply -parallelism=1

# Monitoring waktu eksekusi
time terraform plan
time terraform apply -auto-approve

# Terraform trace logging untuk debugging performa
TF_LOG=TRACE terraform plan 2>&1 | tee trace.log
# Cari "applyable" untuk melihat resource mana yang lambat

# Enable provider plugin caching untuk percepat init
# ~/.terraformrc:
# provider_cache {
#   dir = "$HOME/.terraform.d/plugin-cache"
# }

# Atau set via environment variable
export TF_PLUGIN_CACHE_DIR="$HOME/.terraform.d/plugin-cache"
terraform init
# Provider hanya di-download sekali, workspace lain pakai cache

# Bersihkan cache jika perlu
rm -rf $TF_PLUGIN_CACHE_DIR/*

# Gunakan data source yang efisien
# BURUK: Mengambil semua instance
data "aws_instances" "all" {}

# BAIK: Filter spesifik
data "aws_instances" "web" {
  filter {
    name   = "tag:Role"
    values = ["web"]
  }
}

# Terraform tidak cache plan secara native
# Tapi ada beberapa strategi untuk percepat:

# 1. Simpan plan output dan apply nanti
terraform plan -out=plan.cache
terraform apply plan.cache
# Menghindari re-plan yang bisa memakan waktu

# 2. Targeted refresh (hanya resource yang berubah)
terraform plan -target=aws_instance.web
# Berguna saat development, JANGAN di production

# 3. Reduce data source calls
# Kurangi jumlah data source, gunakan locals caching

# 4. Parallel backend initialization
# Terraform init bisa mendownload provider secara parallel
terraform init -plugin-dir=/shared/plugin-cache

# Cache provider plugins untuk percepat init
mkdir -p ~/.terraform.d/plugin-cache

# ~/.terraformrc
# plugin_cache_dir = "$HOME/.terraform.d/plugin-cache"

# Atau set via environment variable
export TF_PLUGIN_CACHE_DIR="$HOME/.terraform.d/plugin-cache"

# Di CI/CD: persist cache antara runs
# GitHub Actions:
- uses: actions/cache@v3
  with:
    path: ~/.terraform.d/plugin-cache
    key: terraform-providers-${{ hashFiles('.terraform.lock.hcl') }}

# Shared plugin cache untuk team
# Simpan di shared filesystem atau S3
terraform init -plugin-dir=/shared/terraform/plugins