AWS 5단계 · ALB·Auto Scaling

목표

서버 1대짜리 구조를 여러 AZ에 분산된 다중 서버 구조로 전환하고, 장애 발생 시 자동으로 복구되는지 검증한다.

A. AMI 생성 및 대상 그룹 준비

상황

지금까지 서버는 한 대뿐이었다. 이제 여러 대로 늘려야 하는데, 두 번째·세 번째 서버를 매번 처음부터 만들면 EC2 생성 → Nginx 설치 → 설정을 서버 수만큼 반복해야 한다.

AMI를 만든 이유

잘 돌아가는 지금 서버를 통째로 이미지로 떠두면, 그 이미지로 찍어낸 서버는 Nginx가 이미 설치된 상태로 생성된다. 붕어빵 틀을 만들어 두는 것과 같다.

• EC2-> 인스턴스 -> 작업 -> 이미지 및 템플릿 -> 이미지 생성
• 이미지 이름: nginx-base-ami
• 상태가 available이 되어야 사용 가능

대상 그룹 생성

• EC2 → 로드 밸런싱 → 대상 그룹 → 대상 그룹 생성
• 이름 nginx-tg
• 대상 유형: 인스턴스 / 프로토콜·포트: HTTP 80
• VPC: vpc-0a554abdad04c9620
• 상태 검사 경로: /
• 인스턴스는 등록하지 않고 생성 (ASG가 자동으로 등록)

대상 그룹을 만든 이유

대상 그룹은 ALB가 트래픽을 보낼 서버들의 명단이다. ALB에 EC2를 바로 연결하지 않고 명단을 따로 두는 이유는 두 가지의 관심사가 다르기 때문이다.

분리해두면 나중에 서버 구성이 통째로 바뀌어도 ALB는 건드리지 않고 명단만 교체하면 된다.

상태 검사 경로를 /로 둔 이유

ALB가 주기적으로 이 경로로 요청을 보내 서버가 응답하는지 확인한다. 존재하는 경로여야 정상 응답이 오고, 이 확인 결과가 나중에 자동 복구의 출발점이 된다.

인스턴스를 등록하지 않고 생성한 이유

ASG가 서버를 만들 때 자동으로 명단에 등록해 주기 때문이다. 손으로 등록하면 ASG가 서버를 교체할 때마다 다시 손으로 고쳐야 한다.

B. ALB 구성 및 보안 그룹 재설정

상황

A에서 서버를 찍어낼 틀(AMI)과 서버 명단(대상 그룹)을 만들었다. 이제 그 명단으로 트래픽을 보내줄 입구를 만들 차례다. 지금까지는 사용자가 EC2의 퍼블릭 IP로 직접 접속했다. 서버가 여러 대가 되면 이 방식은 성립하지 않는다. 사용자가 "오늘은 A서버, 내일은 B서버" 하고 주소를 바꿔가며 접속할 수는 없기 때문이다. 그래서 주소는 하나로 두고, 뒤에서 여러 서버에 나눠주는 장치가 필요하다. 그게 로드 밸런서다.

ALB용 보안 그룹 생성

EC2 → 네트워크 및 보안 → 보안 그룹 → 보안 그룹 생성

• 이름 alb-sg
• 인바운드: HTTP 80 ← 0.0.0.0/0

따로 만든 이유

ALB는 EC2와 별개의 리소스이므로 자기 방화벽이 따로 필요하다. EC2의 보안 그룹을 공유하지 않는다. 그리고 ALB는 이제 사이트 방문자를 직접 받는 입구이므로 인바운드 80을 전체(0.0.0.0/0)에 열어야 한다. 여기를 좁히면 아무도 사이트에 들어올 수 없다.

ALB 생성

EC2 → 로드 밸런싱 → 로드밸런서 → 로드 밸런서 생성

생성된 DNS 이름: <ALB DNS> 상태가 프로비저닝 중 → active로 바뀌어야 사용 가능하다.

왜 가용 영역을 2개 이상 골라야 하는가

ALB 자체도 소프트웨어이므로 어딘가에서 돌아가야 한다. 만약 ALB가 AZ 한 곳에만 있으면, 그 AZ가 죽었을 때 뒤에 서버가 아무리 많아도 입구가 사라져 서비스가 멈춘다. 즉 서버를 여러 AZ에 나누는 이유와 동일한 이유가 ALB에도 적용된다. AWS가 이를 강제하기 때문에 2개 미만으로는 생성 자체가 되지 않는다.

리스너가 하는 일

리스너는 몇 번 포트로 들어온 요청을 어디로 보낼지 정하는 규칙이다.

사용자 요청 (80번 포트)
      ↓
   리스너가 받음
      ↓
대상 그룹 nginx-tg로 전달
      ↓
명단에 있는 서버 중 한 대로

나중에 HTTPS를 붙이면 443 리스너를 추가하고, 경로에 따라 다른 대상 그룹으로 보내는 규칙(/api는 API 서버로, 나머지는 웹 서버로)도 여기서 설정한다.

EC2 보안 그룹 수정

EC2 → 보안 그룹 → launch-wizard-1 → 인바운드 규칙 편집

• HTTP 80의 소스를 0.0.0.0/0 → alb-sg로 변경
• SSH 22 규칙 2개(<퍼블릭 IP>/32, <퍼블릭 IP>/29)는 유지

왜 EC2의 80번을 좁혀야 하는가

ALB를 붙이기 전에는 사용자가 EC2에 직접 접속해야 했으므로 80번이 전체에 열려 있어야 했다. ALB를 붙인 뒤에는 모든 정상적인 요청이 ALB를 거쳐서 온다. 그런데 EC2의 80번이 여전히 전체에 열려 있으면, 누군가 EC2의 IP를 알아내 ALB를 건너뛰고 직접 접속할 수 있다. 그러면 ALB에서 하는 검사나 제어를 전부 우회하게 된다. 소스를 alb-sg로 지정하면 그 보안 그룹을 달고 있는 리소스(=ALB)에서 오는 트래픽만 통과한다.

소스에 IP가 아니라 보안 그룹을 지정하는 이유

ALB는 내부적으로 여러 IP를 사용하고, 그 IP는 AWS가 필요에 따라 바꾼다. IP로 지정하면 바뀔 때마다 규칙을 고쳐야 한다. 보안 그룹으로 지정하면 "이 그룹에 속한 것"이라는 관계로 판단하므로, IP가 바뀌든 ALB가 확장되든 규칙을 손댈 필요가 없다. 이는 4단계에서 SSH를 내 IP(<퍼블릭 IP>/32)로 제한했을 때와 대비된다. 그때는 IP가 바뀌면 규칙을 다시 고쳐야 한다는 한계가 있었다.

이 단계에서 바뀐 구조

[이전]
사용자 → EC2 퍼블릭 IP(<퍼블릭 IP>) → Nginx

[이후]
사용자 → ALB 주소 → 대상 그룹 → EC2 여러 대 → Nginx
                                    ↑
                          80번은 ALB에서 온 것만 허용

사용자는 더 이상 EC2의 IP를 알 필요도, 알 수도 없다. 따라서 4단계에서 붙인 탄력적 IP는 ALB 구조에서는 불필요해진다.

C. Launch Template · Auto Scaling Group 구성

상황

B에서 입구(ALB)와 명단(대상 그룹)까지 만들었다. 그런데 아직 명단에 올라갈 서버가 없다. 여기서 선택지가 두 가지다.

1. EC2를 손으로 두 대 더 만들어서 명단에 등록한다
2. 서버를 자동으로 만들고 관리하는 장치를 둔다

1번은 당장은 빠르지만, 서버가 죽었을 때 내가 직접 알아채고 다시 만들어야 한다. 새벽에 죽으면 새벽에 일어나야 한다. 2번을 택하면 그 일을 시스템이 대신한다. 그게 Auto Scaling Group이다.

Launch Template 생성

EC2 → 인스턴스 → 시작 템플릿 → 시작 템플릿 생성

Launch Template이 필요한 이유

ASG는 "서버를 몇 대 유지할지"만 관리한다. 그런데 서버를 새로 만들려면 어떤 사양으로, 어떤 이미지로, 어떤 보안 그룹을 달고 만들지를 알아야 한다. 그 정보를 담아둔 것이 Launch Template이다.

서브넷을 지정하지 않은 이유 서버를 어느 AZ에 배치할지는 ASG가 결정한다. Launch Template은 "무엇을 만들지"만 담당하고, "어디에 놓을지"는 ASG가 담당하도록 역할을 나눈 것이다.

Auto Scaling Group 생성

EC2 → Auto Scaling → Auto Scaling 그룹 → Auto Scaling 그룹 생성

희망 · 최소 · 최대의 의미

희망을 2로 둔 순간 ASG는 즉시 서버 두 대를 만들기 시작했다. 실제로 인스턴스 목록에 2a, 2b에 한 대씩 생성된 것을 확인했다.

ELB 상태 검사를 켜야 하는 이유

이 옵션이 5단계에서 가장 중요한 설정이다. 기본 상태 검사는 EC2 자체가 살아있는지만 본다. 즉 인스턴스는 켜져 있는데 그 안의 Nginx만 죽은 경우, ASG는 아무 문제가 없다고 판단한다. ELB 상태 검사를 켜면 ALB가 내린 Unhealthy 판정을 ASG가 받아들인다. 그래서 "인스턴스는 살아있지만 웹서버가 응답하지 않는" 상황에서도 서버를 교체할 수 있다.

D단계에서 Nginx를 중지시켰을 때 서버가 자동으로 교체된 것은 이 설정 덕분이다.

ASG가 대상 그룹에 자동 등록하는 흐름

ASG가 서버 생성
      ↓
대상 그룹 nginx-tg에 자동 등록
      ↓
ALB의 헬스체크 시작
      ↓
통과하면 Healthy → 트래픽 전달 시작

A단계에서 대상 그룹을 만들 때 인스턴스를 등록하지 않았던 이유가 여기에 있다. ASG가 서버를 만들고 없앨 때마다 명단이 자동으로 갱신되므로, 손으로 등록해두면 오히려 어긋난다.

이 단계에서 완성된 구조

ALB
 ↓
대상 그룹 (명단)
 ↑ 자동 등록
Auto Scaling Group  ← 대수 유지 · 교체
 ↑ 참조
Launch Template     ← 어떻게 만들지
 ↑ 참조
AMI                 ← 어떤 상태로 만들지

아래에서 위로 읽으면 AMI(내용물) → Launch Template(설계도) → ASG(관리자) → 대상 그룹(명단) → ALB(입구) 순서로 이어진다.

생성 결과

• 인스턴스가 자동으로 2대 생성되어 2a, 2b에 각각 배치됨
• 기존 my_first_nginx(2c)를 포함해 총 3대 실행 중

D. 검증 및 리소스 정리

상황

A~C에서 구조를 다 만들었다. 이제 의도한 대로 동작하는지 확인할 차례다. 확인할 것은 두 가지다.

1. 요청이 정말 여러 서버에 나뉘어 가는가
2. 서버 하나가 죽어도 서비스가 유지되고, 자동으로 복구되는가

검증 ① 트래픽 분산

문제: ASG가 만든 두 서버는 같은 AMI로 찍어냈기 때문에 페이지 내용이 동일하다. 새로고침해도 어느 서버가 응답했는지 구분할 수 없다. 해결: 각 서버에 접속해 페이지를 다르게 수정했다.

sudo vi /usr/share/nginx/html/index.html

• 2a 서버 → "서버 A(AZ-2a)"
• 2b 서버 → "서버 B(AZ-2b)"

확인: ALB 주소에서 강제 새로고침(Ctrl+Shift+R)을 반복하니 A와 B가 번갈아 표시됐다. 주소창은 계속 nginx-alb-...elb.amazonaws.com으로 동일한데 응답하는 서버만 바뀐다. 이것이 로드 밸런싱이다. 사용자는 뒤에 서버가 몇 대인지, 어느 서버가 응답했는지 알 필요가 없다.

검증 ② 장애 자동 복구

장애 발생: 서버 A의 Nginx를 중지시켰다.

sudo systemctl stop nginx

관찰된 순서

ASG 작업 기록에서 확인한 내용

Terminating EC2 instance: i-037618579a012c4f0
→ an instance was taken out of service in response to
  an ELB system health check failure

Launching a new EC2 instance: i-0be041dc89b603c6f
→ an instance was launched in response to
  an unhealthy instance needing to be replaced

AWS가 직접 "ELB 헬스체크 실패로 서비스에서 제외했고, 교체가 필요해 새 인스턴스를 생성했다"고 기록했다. 이 과정에 사람이 개입한 지점이 없다. 3단계는 장애를 사람이 진단하고 고치는 것이었다면, 5단계는 시스템이 스스로 고치는 구조를 만든 것이다.

• 대상 그룹 상태 변화 확인
  • 서버 A → Draining
  • 서버 B → Healthy
  • 새로 생성된 인스턴스 → Healthy

• ASG 작업 기록 확인

Terminating EC2 instance: i-037618579a012c4f0
→ an instance was taken out of service in response to an ELB system health check failure

Launching a new EC2 instance: i-0be041dc89b603c6f
→ an instance was launched in response to an unhealthy instance needing to be replaced

트러블슈팅 1 — 502와 정상 페이지가 번갈아 표시됨

증상: Nginx를 중지한 직후, 새로고침할 때마다 502 Bad Gateway와 정상 페이지가 교대로 나타남 원인: ALB의 헬스체크는 주기적으로 수행되며, 연속 실패가 누적되어야 Unhealthy로 판정한다. 판정 전까지 ALB는 중지된 서버에도 계속 트래픽을 분배했고, 그 서버가 응답하지 않으니 502를 반환한 것이다.

• 502는 "중계 장치까지는 도달했으나 뒤쪽 서버가 무응답"이라는 의미
• 3단계에서 본 TIMED_OUT(방화벽 차단), REFUSED(프로세스 없음)와 발생 지점이 다르다

해결: 별도 조치 없이 헬스체크가 Unhealthy 판정을 내린 뒤 자동으로 해소됨 재발 방지: 장애 발생과 자동 복구 사이에는 감지 지연 구간이 존재하며, 이 시간 동안 사용자는 에러를 볼 수 있다. 헬스체크 주기와 실패 임계값을 서비스 특성에 맞게 조정할 필요가 있다.

트러블슈팅 2 — 새로 생성된 서버에 수정 내용이 없음

증상: ASG가 자동 생성한 인스턴스에 접속하니, 서버 A/B 구분 문구가 없는 원본 페이지가 표시됨 원인: AMI는 문구를 수정하기 이전 시점에 생성되었다. 이후 각 서버에서 직접 수정한 내용은 AMI에 반영되지 않는다. ASG는 AMI를 그대로 복제하므로 원본 상태로 생성된다. 해결 방향

재발 방지: 서버에 직접 손으로 적용한 설정은 인스턴스가 교체되면 사라진다. 반복 가능한 배포 수단을 통해 적용해야 한다. 이것이 다음 단계에서 인프라를 코드로 관리해야 하는 이유다.

리소스 정리

실습 후 비용 발생을 막기 위해 아래 순서로 삭제했다.

순서가 중요한 이유: ASG를 남겨둔 채 인스턴스만 종료하면, ASG가 희망 용량을 맞추기 위해 즉시 새 인스턴스를 만든다. 반드시 ASG를 먼저 제거해야 한다.

5단계 용어

5단계에서 처음 나온 개념. A → D 진행 순서대로 정리했다.

A. AMI 생성 및 대상 그룹 준비

대상 그룹과 ALB를 분리하는 것은 관심사 분리다. ALB는 분배를 맡고, 대상 그룹은 목록과 상태 관리를 맡는다.

B. ALB 생성

ALB는 최소 2개 가용 영역에 배치해야 한다. 한 AZ 전체가 장애를 겪어도 다른 AZ에서 서비스가 계속되도록 하기 위해서다.

C. Launch Template과 ASG

Launch Template은 설계도이고 ASG는 그 설계도로 몇 대를 유지할지 관리하는 주체다. 인스턴스 수는 서브넷 개수가 아니라 희망 용량(desired capacity) 으로 결정된다.

D. 자동 복구 검증

AMI의 한계

ASG가 새로 만드는 인스턴스는 AMI 생성 이후의 수동 변경사항을 반영하지 않는다. 서버에 직접 접속해 파일을 고쳐도 그 변경은 AMI에 포함되지 않으므로 새 서버에는 적용되지 않는다. 이것이 Terraform 같은 IaC 도구를 도입하는 직접적인 이유다.