<aside>
☁️ 클라우드웨이브 · W07 · 4/5 · 예상 읽기 7분
</aside>
오늘은 클라우드 아키텍처를 구성 요소 목록이 아니라 요청과 장애가 흐르는 경로로 그려 보았다. 3계층 구조는 프레젠테이션, 애플리케이션, 데이터를 분리해 변경과 확장의 단위를 나누는 기본 틀이다. 계층을 나눈다고 자동으로 탄력성과 안정성이 생기지는 않지만, 병목과 책임을 관찰하기 쉬워진다.
프레젠테이션 계층은 브라우저, CDN, 정적 콘텐츠 전달처럼 사용자와 가까운 영역이다. 애플리케이션 계층은 요청을 처리하는 컴퓨트와 서비스 로직을 담당하고, 데이터 계층은 관계형·비관계형 데이터베이스와 오브젝트 저장소처럼 보존과 조회를 담당한다. 각 계층 사이에는 필요한 통신만 허용하고, 장애가 다음 계층으로 확산되지 않도록 시간 제한과 재시도 정책을 둔다.
ALB는 HTTP 수준의 호스트·경로 기반 라우팅과 웹 요청 처리에 적합하다. NLB는 더 낮은 계층에서 높은 처리량과 연결 특성이 중요한 경우에 고려한다. 선택은 이름의 선호보다 프로토콜, 라우팅 요구, 연결 패턴, 관측 방식과 비용을 함께 비교해서 결정한다.
flowchart LR
B[브라우저 또는 CDN] --> P[프레젠테이션]
P --> A[ALB 또는 서비스 진입점]
A --> S[애플리케이션 계층]
S --> D[데이터 계층]
S --> O[로그·메트릭·트레이스]
장애를 만났을 때는 DNS 이름이 올바른 주소를 반환하는지, 캐시와 TTL이 기대와 맞는지부터 확인한다. 그다음 로드 밸런서의 대상 건강 상태, 애플리케이션 오류율과 지연시간, 데이터 계층 연결 수를 순서대로 본다. 이 흐름은 추측을 줄이고 문제의 계층을 좁혀 준다.
오토 스케일링은 CPU 하나만 보지 말고 요청 수, 대기열 길이, 지연시간처럼 사용자 경험과 가까운 지표를 함께 고려한다. 관측 시스템에는 정상 기준선과 알림 임계값, 배포 이벤트를 함께 남긴다. 확장 후 비용과 쿼터가 감당 가능한지도 운영 설계의 일부다.
Pod의 자원 요청은 스케줄러가 배치 가능성을 판단하는 기준이고, 제한은 컨테이너가 사용할 수 있는 상한이다. 요청을 실제보다 낮게 쓰면 과밀 배치가 생기고, 지나치게 높이면 노드가 남아도 배치가 실패할 수 있다. HPA는 지표에 따라 Pod 수를 조정하고, Cluster Autoscaler는 노드 수를 조정하는 역할을 맡는다.
resources:
requests:
cpu: "<CPU_REQUEST>"
memory: "<MEMORY_REQUEST>"
limits:
cpu: "<CPU_LIMIT>"
memory: "<MEMORY_LIMIT>"
노드나 Pod가 실패하면 컨트롤러는 원하는 복제 수를 회복하려고 새 위치에 재스케줄링한다. 하지만 상태 저장 애플리케이션, 지역 제약, 이미지 풀 시간, 데이터 복구는 별도 설계가 필요하다. 자동 복구는 원인 분석을 대신하지 않으므로 이벤트와 로그를 보존해야 한다.
런북에는 DNS 확인, 헬스 체크, 애플리케이션 지표, 데이터 연결, 최근 배포를 한 순서로 기록한다. 부하 테스트는 정상 부하만이 아니라 확장 지연과 노드 손실을 포함해야 한다. HPA와 클러스터 확장이 서로 기다리는 상황도 시뮬레이션해 임계값을 조정한다.