<aside>
☁️ 클라우드웨이브 · W07 · 1/5 · 예상 읽기 7분
</aside>
웹 서버 한 대를 만드는 일은 쉽지만, 요청이 몰리거나 한 노드가 멈췄을 때도 서비스가 계속 응답하게 만드는 일은 구조의 문제다. 오늘은 웹 서버를 여러 대 둔 클러스터와 로드 밸런서를 Terraform으로 생각하면서, 그 뒤에 있는 상태 관리까지 한 흐름으로 연결했다. 핵심은 자원 선언 자체보다 누가 현재 인프라를 알고 있고, 변경 중 충돌을 어떻게 막는가에 있었다.
로드 밸런서는 외부 요청을 받아 리스너와 규칙을 거쳐 대상 그룹으로 보낸다. 대상 그룹은 헬스 체크에 통과한 노드에만 요청을 전달한다. 오토 스케일링 그룹은 부하와 가용성 요구에 따라 노드 수를 조정한다. 따라서 사용자는 특정 서버 주소를 알 필요가 없고, 운영자는 개별 노드보다 클러스터의 건강 상태를 관리하게 된다.
flowchart LR
U[사용자] --> D[DNS]
D --> L[로드 밸런서]
L --> R[리스너와 규칙]
R --> T[건강한 대상 그룹]
T --> A[오토 스케일링 웹 서버]
A --> H[헬스 체크]
애플리케이션 포트와 외부 수신 포트를 분리하면 외부 경계와 내부 통신을 구분하기 쉽다. 다만 포트 번호를 바꾸는 것만으로 보안이 완성되는 것은 아니다. 보안 그룹, 서브넷 경로, 로그와 헬스 체크가 함께 검토되어야 한다.
Terraform 구성 파일은 원하는 상태를 표현하고, 상태 파일은 Terraform이 관리한다고 판단한 실제 자원과 구성의 관계를 기록한다. 계획 단계는 선언과 상태, 제공자 조회 결과를 비교해 변경 후보를 보여 준다. 그래서 상태가 오래되거나 서로 다른 사람이 각자 가진 상태를 사용하면 삭제·중복·충돌의 위험이 생긴다.
팀에서는 원격 백엔드를 사용해 상태를 공유하고, 잠금으로 동시에 변경을 적용하지 않게 해야 한다. 환경별로 키나 디렉터리를 분리하면 개발·검증·운영 상태가 섞이지 않는다. 상태 접근 권한은 인프라 변경 권한과 동일하게 민감하게 다뤄야 하며, 버전 관리와 복구 절차도 함께 준비한다.
terraform {
backend "s3" {
bucket = "<STATE_BUCKET_PLACEHOLDER>"
key = "<ENVIRONMENT>/<STACK>/terraform.tfstate"
region = "<REGION_PLACEHOLDER>"
use_lockfile = true
encrypt = true
}
}
백엔드 설정에는 자격증명이나 비밀값을 넣지 않는다. 실행 주체의 역할과 외부 자격증명 제공 방식을 별도로 설계하고, 공개 접근 차단과 버전 관리 정책을 저장소 측에 적용한다. 상태 격리는 workspace만으로 충분한지, 디렉터리와 계정 경계를 함께 둘지 팀의 위험도에 맞춰 결정한다.
상태를 공유한다는 말에는 운영 규칙도 포함된다. 백엔드 초기화 시점, 상태 잠금 대기 시간, 계획 결과를 저장하는 위치, 적용 승인자를 미리 정해 두면 도구 사용법을 둘러싼 혼선을 줄일 수 있다. 변경자가 작업을 중단했을 때 잠금과 프로세스가 어떤 상태인지 확인하는 절차도 런북에 넣는다. 특히 상태 파일을 수동으로 편집하는 방식은 최후의 복구 상황을 제외하고 피하며, 복구 전에는 원본을 보존한다.
변경 전에는 계획 결과를 검토하고, 변경 후에는 로드 밸런서 헬스 체크와 대상 수, 오류율을 확인한다. 상태 잠금이 풀리지 않는 상황을 대비해 강제 해제 절차는 승인된 운영자와 증거 기록을 전제로 문서화한다. 새 노드를 추가하는 변경도 연결 드레이닝, 초기화 시간, 관측 지표가 준비되지 않았다면 무중단이라고 부르기 어렵다.
원격 상태는 자원을 자동으로 안전하게 만드는 기능이 아니다. 공유 저장소는 협업의 단일 기록을 제공하고 잠금은 동시 변경을 줄일 뿐이다. 잘못된 계획을 승인하면 중앙 상태에도 잘못된 결과가 남는다. 또 로드 밸런서는 장애를 숨겨 주지만 애플리케이션의 데이터 일관성이나 느린 의존성까지 해결하지 않는다.