[클라우드 활용 포트폴리오] 멀티 AZ와 ELB를 활용한 고가용성 및 장애 복구 설계

1. 학습 개요

이번 포트폴리오는 클라우드 활용 12주차 강의자료를 바탕으로, AWS에서 고가용성 아키텍처를 설계하는 방법과 멀티 AZ, ELB, 헬스 체크, Auto Scaling을 활용한 장애 복구 흐름을 정리한 글이다.

이전 글에서는 EC2를 통해 가상 서버를 생성하고, VPC와 서브넷을 통해 네트워크 구조를 구성했으며, CloudWatch와 CloudTrail을 통해 운영 상태와 사용자 활동을 추적하는 방법을 학습했다. 12주차에서는 여기서 한 단계 더 나아가, 서버나 가용 영역에 장애가 발생해도 서비스가 중단되지 않도록 구성하는 방법을 학습했다.

클라우드 환경에서 서버 한 대만으로 서비스를 운영하면 구조는 단순하지만, 해당 서버에 장애가 발생했을 때 전체 서비스가 중단될 수 있다. 따라서 실제 운영 환경에서는 여러 가용 영역에 리소스를 분산하고, Load Balancer를 통해 트래픽을 분산하며, 헬스 체크를 통해 비정상 인스턴스를 자동으로 제외하는 구조가 필요하다.

이번 글에서 다룰 내용은 다음과 같다.

• 고가용성의 개념
• 가용성 수준과 중단 시간
• AWS 리전과 가용 영역의 관계
• 멀티 AZ 배포의 필요성
• ELB와 로드 밸런서의 개념
• ELB 유형과 사용 목적
• Target Group과 Health Check
• Auto Scaling Group과 장애 복구
• 멀티 AZ + ELB 아키텍처 설계 실습
• 실습 중 문제점 및 해결 방안
• 12주차 학습 후기

---

2. 고가용성(HA)이란?

고가용성(High Availability, HA)은 서비스를 가능한 한 오랫동안 중단 없이 제공하는 능력을 의미한다. 즉, 장애가 발생하더라도 빠르게 복구하거나 자동으로 우회하여 사용자가 서비스를 계속 이용할 수 있도록 하는 것이 목적이다.

예를 들어 웹 서버 한 대만 운영하는 구조에서는 해당 서버가 중지되면 사용자는 웹사이트에 접속할 수 없다. 반면 여러 서버를 두고 트래픽을 분산하면 한 서버에 문제가 생겨도 다른 서버가 요청을 처리할 수 있다. 이것이 고가용성 설계의 기본 아이디어이다.

고가용성은 단순히 좋은 서버를 사용하는 것이 아니라, 장애가 발생한다는 것을 전제로 시스템을 설계하는 방식이다.

고가용성 설계에서 중요한 질문은 다음과 같다.

• 하나의 서버가 중단되어도 서비스가 유지되는가?
• 하나의 가용 영역에 장애가 나도 다른 영역에서 서비스가 가능한가?
• 비정상 인스턴스를 자동으로 감지할 수 있는가?
• 트래픽을 정상 인스턴스로 자동 우회할 수 있는가?
• 장애가 발생한 인스턴스를 자동으로 교체할 수 있는가?
• 서비스 상태를 모니터링하고 알림을 받을 수 있는가?

즉, 고가용성의 핵심은 단일 장애점(SPOF, Single Point of Failure)을 제거하고, 장애 발생 시 자동 복구 또는 자동 우회가 가능하도록 설계하는 것이다.

---

3. 가용성 수준과 중단 시간

가용성은 보통 백분율로 표현한다. 예를 들어 99% 가용성과 99.99% 가용성은 숫자로 보면 큰 차이가 없어 보이지만, 실제 연간 중단 시간으로 환산하면 차이가 크다.

가용성1년 기준 중단 시간의미

99%	약 87시간	다소 자주 중단될 수 있음
99.9%	약 8시간 45분	일반 중소 서비스 수준
99.99%	약 52분	AWS 권장 수준
99.999%	약 5분	금융, 헬스케어 등 민감 시스템 수준

서비스 중단 시간이 길어질수록 비즈니스 손실, 고객 불만, 브랜드 신뢰 하락, SLA 위반 가능성이 커진다. 따라서 실제 운영 서비스에서는 어느 정도의 가용성을 목표로 할 것인지 먼저 정하고, 그 목표에 맞는 아키텍처를 설계해야 한다.

예를 들어 개인 실습용 서비스라면 99.9% 수준도 충분할 수 있지만, 결제 시스템이나 병원 시스템처럼 민감한 서비스는 더 높은 가용성을 목표로 해야 한다.

---

4. 고가용성이 중요한 이유

고가용성이 중요한 이유는 단순히 “서비스가 잘 켜져 있어야 한다”는 수준을 넘어선다. 서비스 중단은 직접적인 매출 손실과 신뢰도 하락으로 이어질 수 있다.

고가용성이 중요한 이유는 다음과 같다.

이유설명

비즈니스 영향	서비스 중단으로 인한 매출 손실 발생
고객 신뢰 하락	접속 장애가 반복되면 고객 이탈 가능성 증가
법적 책임 가능성	SLA 위반 시 손해배상 또는 계약 문제 발생
운영 안정성	장애 발생 시 빠른 복구와 영향 범위 축소
확장성 확보	트래픽 증가 시 유연하게 대응 가능

고가용성 설계의 기본 아이디어는 모든 기능은 언젠가 장애가 발생할 수 있다는 가정하에 역방향으로 설계하는 것이다. 가능한 모든 지점에 중복성을 구현하고, 단일 장애로 전체 시스템이 중단되지 않도록 해야 한다.

---

5. AWS 리전과 가용 영역(AZ)의 관계

5.1 AWS 리전

AWS 리전(Region)은 전 세계에 분산된 AWS의 지리적 인프라 단위이다. 각 리전은 서로 물리적으로 분리되어 있으며, 사용자는 서비스 대상 지역, 지연 시간, 규정 준수, 비용 등을 고려하여 리전을 선택한다.

예를 들어 서울 리전은 ap-northeast-2, 도쿄 리전은 ap-northeast-1, 오하이오 리전은 us-east-2와 같이 표현된다.

리전을 선택할 때 고려할 요소는 다음과 같다.

• 사용자와의 거리
• 네트워크 지연 시간
• 데이터 위치 규정
• 서비스 제공 여부
• 비용 차이
• 장애 복구 전략

리전 선택 화면

 

---

5.2 가용 영역(AZ)

가용 영역(Availability Zone, AZ)은 하나의 리전 안에 존재하는 독립된 데이터센터 집합이다. 하나의 리전은 일반적으로 3개 이상의 가용 영역으로 구성된다.

AZ는 서로 물리적으로 분리되어 있지만, 고속 네트워크로 연결되어 있다. 따라서 한 AZ에 장애가 발생하더라도 다른 AZ는 영향을 받지 않도록 설계되어 있다.

AZ의 특징은 다음과 같다.

구성 요소특징

독립성	독립된 전원, 냉각, 보안 시스템 보유
네트워크	AZ 간 초고속 저지연 네트워크로 연결
장애 격리	AZ 하나에 장애가 나도 다른 AZ는 영향 없음
고가용성	여러 AZ에 리소스를 분산하여 장애 대응 가능

AZ를 나누어 사용하는 이유는 물리적인 장애를 분산하기 위해서이다. 지진, 정전, 화재, 네트워크 장애 등이 특정 AZ에 영향을 주더라도 다른 AZ에 배치된 리소스가 서비스를 이어갈 수 있다.

---

6. 멀티 AZ 배포

멀티 AZ 배포는 두 개 이상의 가용 영역에 애플리케이션 구성 요소를 복제하거나 이중화하여, 장애 발생 시에도 서비스를 유지하도록 설계하는 방식이다.

단일 AZ에만 리소스를 배치하면 해당 AZ 장애 시 전체 서비스가 중단될 수 있다. 반면 여러 AZ에 리소스를 분산하면 한 AZ에 장애가 발생해도 다른 AZ에서 요청을 처리할 수 있다.

멀티 AZ 배포의 핵심은 다음과 같다.

• 최소 2개 이상의 AZ에 리소스 배치
• 웹/앱 서버를 여러 AZ에 분산
• ELB를 통해 AZ 간 트래픽 자동 분산
• RDS는 Primary와 Standby를 서로 다른 AZ에 배치
• Auto Scaling Group으로 인스턴스 개수 자동 조정
• Health Check로 비정상 인스턴스 제외
• 장애 발생 시 정상 인스턴스로 트래픽 우회

---

6.1 서비스별 멀티 AZ 기능

AWS의 주요 서비스들은 멀티 AZ 구성을 통해 고가용성을 제공할 수 있다.

서비스멀티 AZ 기능설명

RDS	Multi-AZ 배포	자동 장애 조치(Failover) 지원
EC2	Auto Scaling + ALB	AZ 간 인스턴스 분산 배포
EFS	AZ 간 고가용성 제공	파일 스토리지 이중화
Elastic Load Balancer	트래픽 자동 분산	AZ별 정상 인스턴스로 요청 전달

예를 들어 EC2 기반 웹 서비스는 여러 AZ에 인스턴스를 배치하고, ALB를 통해 사용자 요청을 분산할 수 있다. RDS는 하나의 주 인스턴스와 다른 AZ의 대기 인스턴스를 구성하여 장애 시 자동 장애 조치가 가능하다.

---

6.2 멀티 AZ 설계 점검 항목

멀티 AZ 아키텍처를 설계할 때는 다음 항목을 점검해야 한다.

점검 항목설명

최소 2개 AZ 배포	한 AZ 장애 시 다른 AZ에서 서비스 가능해야 함
자동 장애 조치 구성	장애 발생 시 수동 개입 없이 복구 가능한지 확인
Health Check 설정	비정상 인스턴스를 자동으로 감지하는지 확인
트래픽 우회 설정	정상 인스턴스로 요청이 자동 전달되는지 확인
Auto Scaling 구성	트래픽 증가 또는 인스턴스 장애 시 확장 가능한지 확인
DB 이중화	RDS Multi-AZ 또는 백업 전략이 있는지 확인
모니터링 구성	CloudWatch로 상태 확인 및 알림 구성

멀티 AZ 구성은 단순히 인스턴스를 여러 개 만드는 것이 아니라, 장애 감지와 트래픽 우회, 자동 복구까지 함께 설계해야 의미가 있다.

---

7. ELB와 로드 밸런서 개념

7.1 로드 밸런서란?

로드 밸런서(Load Balancer)는 사용자 요청을 여러 서버로 나누어 전달하는 장치 또는 서비스이다. AWS에서는 이를 ELB(Elastic Load Balancing)라는 관리형 서비스로 제공한다.

서버 한 대에 모든 트래픽이 집중되면 과부하가 발생할 수 있다. 또한 해당 서버가 장애를 일으키면 전체 서비스가 중단된다. ELB는 이러한 문제를 해결하기 위해 여러 인스턴스에 트래픽을 분산하고, 비정상 인스턴스를 자동으로 제외한다.

ELB가 해결하는 대표적인 문제는 다음과 같다.

문제 상황해결 방법

서버 한 대에 트래픽 집중	트래픽을 여러 서버로 분산
하나의 서버 다운 시 전체 중단	헬스 체크 후 정상 서버로 트래픽 전환
트래픽 변동이 클 때 수동 확장 어려움	Auto Scaling + ELB 연동

즉, ELB는 고가용성 아키텍처에서 사용자 요청을 받아 정상 인스턴스로 전달하는 핵심 진입점 역할을 한다.

---

7.2 ELB의 기본 동작 흐름

ELB의 기본 동작 흐름은 다음과 같다.

사용자 요청
→ Internet Gateway
→ Application Load Balancer
→ Target Group
→ 정상 상태의 EC2 인스턴스
→ 응답 반환

ELB는 연결된 대상 그룹의 인스턴스 상태를 지속적으로 확인한다. 만약 특정 인스턴스가 헬스 체크에 실패하면, ELB는 해당 인스턴스로 더 이상 트래픽을 보내지 않고 정상 인스턴스로 요청을 우회시킨다.

이 구조를 통해 하나의 인스턴스 장애가 전체 서비스 중단으로 이어지는 것을 방지할 수 있다.

---

8. ELB의 주요 유형

ELB에는 여러 유형이 있으며, 트래픽의 성격에 따라 적절한 로드 밸런서를 선택해야 한다.

유형주요 계층사용 목적

Application Load Balancer	Layer 7	HTTP/HTTPS 웹 애플리케이션 트래픽 분산
Network Load Balancer	Layer 4	TCP/UDP 기반 고성능 트래픽 처리
Gateway Load Balancer	Layer 3/4	방화벽, 보안 어플라이언스 연동
Classic Load Balancer	이전 세대	기존 환경 호환용

이번 12주차 실습과 웹 서비스 구조에서는 주로 Application Load Balancer(ALB)를 기준으로 이해하는 것이 적절하다. ALB는 HTTP/HTTPS 요청을 처리할 수 있고, 경로 기반 라우팅이나 호스트 기반 라우팅 같은 웹 애플리케이션 계층 기능을 제공하기 때문이다.

예를 들어 /api 경로는 API 서버 Target Group으로 보내고, /images 경로는 이미지 서버 Target Group으로 보내는 식의 라우팅도 가능하다.

---

9. Target Group과 Health Check

9.1 Target Group

Target Group은 로드 밸런서가 트래픽을 전달할 대상들의 묶음이다. ALB는 직접 EC2 인스턴스 하나를 지정하는 것이 아니라, Target Group에 등록된 인스턴스 중 정상 상태인 대상에게 요청을 전달한다.

Target Group에는 다음과 같은 대상이 포함될 수 있다.

• EC2 인스턴스
• IP 주소
• Lambda 함수
• 컨테이너 기반 서비스

웹 서버 구조에서는 일반적으로 여러 EC2 인스턴스를 Target Group에 등록한다.

---

9.2 Health Check

Health Check는 Target Group에 등록된 인스턴스가 정상적으로 요청을 처리할 수 있는지 주기적으로 확인하는 기능이다.

예를 들어 웹 애플리케이션 내부에 /health 경로를 만들고, ALB가 해당 경로로 주기적으로 요청을 보내도록 설정할 수 있다. 응답 코드가 정상 범위이면 해당 인스턴스를 Healthy로 판단하고, 응답이 없거나 오류가 발생하면 Unhealthy로 판단한다.

Health Check의 주요 설정 항목은 다음과 같다.

항목설명

Protocol	HTTP 또는 HTTPS
Path	상태 확인용 경로, 예: /health
Port	트래픽 포트 또는 별도 헬스 체크 포트
Healthy threshold	정상으로 판단하기 위한 연속 성공 횟수
Unhealthy threshold	비정상으로 판단하기 위한 연속 실패 횟수
Timeout	응답 대기 시간
Interval	헬스 체크 요청 주기
Success codes	정상 응답으로 인정할 HTTP 상태 코드

Health Check가 중요한 이유는 장애가 발생한 서버를 자동으로 트래픽 대상에서 제외할 수 있기 때문이다. 정상 상태의 인스턴스만 트래픽 대상(Target)으로 유지하면 장애 격리 효과를 얻을 수 있다.

헬스체크

 

---

10. Auto Scaling Group과 장애 복구

Auto Scaling Group(ASG)은 EC2 인스턴스의 개수를 자동으로 조절하는 기능이다. CPU 사용률, 요청 수, 헬스 체크 상태 등을 기준으로 인스턴스를 늘리거나 줄일 수 있다.

고가용성 관점에서 Auto Scaling Group은 두 가지 역할을 한다.

첫째, 트래픽이 증가하면 인스턴스를 자동으로 추가하여 성능 저하를 줄인다.
둘째, 인스턴스가 비정상 상태가 되면 새 인스턴스로 교체하여 서비스 상태를 유지한다.

Auto Scaling Group과 ELB를 함께 사용하면 다음과 같은 흐름으로 장애 복구가 가능하다.

1. 사용자가 ALB로 요청 전송
2. ALB가 Target Group 내 EC2 인스턴스로 트래픽 분산
3. 특정 EC2 인스턴스가 장애 발생
4. Health Check 실패
5. ALB가 해당 인스턴스를 Unhealthy로 판단
6. ALB가 정상 인스턴스로 트래픽 우회
7. Auto Scaling Group이 비정상 인스턴스를 교체
8. 새 인스턴스가 정상 상태가 되면 Target Group에 다시 포함

이 구조를 사용하면 장애가 발생했을 때 관리자가 직접 서버를 재시작하지 않아도 자동으로 복구 흐름이 진행된다.

---

11. 멀티 AZ + ELB 아키텍처 설계

12주차에서 핵심적으로 이해해야 할 아키텍처는 다음과 같은 구조이다.

사용자
→ Internet Gateway
→ Application Load Balancer
→ Public Subnet 또는 Private Subnet의 EC2 Web/App Server
→ RDS Primary / Standby

더 구체적으로는 다음과 같이 설계할 수 있다.

AWS Cloud
└── Region: ap-northeast-2
    └── VPC: 10.10.0.0/16
        ├── Availability Zone A
        │   ├── Public Subnet 1
        │   │   ├── NAT Gateway
        │   │   └── ALB 연결
        │   └── Private Subnet 1
        │       ├── EC2 Web/App Server
        │       └── RDS Primary
        └── Availability Zone C
            ├── Public Subnet 2
            │   ├── NAT Gateway
            │   └── ALB 연결
            └── Private Subnet 2
                ├── EC2 Web/App Server
                └── RDS Standby

이 구조에서 각 구성 요소의 역할은 다음과 같다.

구성 요소역할

VPC	전체 네트워크 격리 공간
Public Subnet	ALB, NAT Gateway 등 외부 연결 리소스 배치
Private Subnet	EC2 Web/App Server와 RDS 배치
Internet Gateway	외부 인터넷과 VPC 연결
Application Load Balancer	사용자 요청을 정상 EC2로 분산
Target Group	ALB가 요청을 전달할 EC2 인스턴스 묶음
Health Check	정상/비정상 인스턴스 판단
Auto Scaling Group	EC2 인스턴스 자동 확장 및 교체
RDS Multi-AZ	DB 장애 시 Standby로 장애 조치
CloudWatch	지표 모니터링 및 알림

이 구조의 핵심은 사용자가 직접 EC2 인스턴스 하나에 접속하는 것이 아니라, ALB를 통해 서비스에 접속한다는 점이다. ALB는 여러 AZ에 분산된 인스턴스의 상태를 확인하고 정상 인스턴스로만 트래픽을 전달한다.

---

12. 멀티 AZ + ELB 실습 과정

12.1 실습 목적

이번 실습의 목적은 멀티 AZ 환경에서 EC2 인스턴스를 구성하고, Application Load Balancer를 통해 여러 인스턴스로 트래픽을 분산하는 구조를 이해하는 것이다. 또한 Health Check를 통해 장애가 발생한 인스턴스를 제외하고 정상 인스턴스로 트래픽이 우회되는 흐름을 확인하는 것이다.

---

12.2 실습 구성

실습에서는 다음과 같은 구성을 기준으로 진행했다.

항목설정 예시

리전	ap-northeast-2
VPC	10.10.0.0/16
AZ	ap-northeast-2a, ap-northeast-2c
Public Subnet	각 AZ에 1개씩
Private Subnet	각 AZ에 1개씩
EC2	각 AZ에 웹 서버 1대씩
Load Balancer	Application Load Balancer
Target Group	EC2 인스턴스 2대 등록
Health Check Path	/ 또는 /health
Auto Scaling	선택적으로 연결

 

---

12.3 실습 단계 1: VPC와 서브넷 준비

먼저 VPC와 여러 서브넷을 준비했다. 고가용성을 위해 최소 두 개의 가용 영역을 선택하고, 각 AZ에 퍼블릭 서브넷과 프라이빗 서브넷을 구성했다.

예시는 다음과 같다.

서브넷AZCIDR용도

public-subnet-a	ap-northeast-2a	10.10.11.0/24	ALB, NAT Gateway
private-subnet-a	ap-northeast-2a	10.10.21.0/24	EC2 Web/App Server
public-subnet-c	ap-northeast-2c	10.10.12.0/24	ALB, NAT Gateway
private-subnet-c	ap-northeast-2c	10.10.22.0/24	EC2 Web/App Server

퍼블릭 서브넷에는 인터넷 게이트웨이로 향하는 라우팅을 설정하고, 프라이빗 서브넷에는 필요 시 NAT Gateway를 통한 아웃바운드 경로를 설정할 수 있다.

VPC 생성

 

---

12.4 실습 단계 2: EC2 인스턴스 2대 생성

다음으로 서로 다른 AZ에 EC2 인스턴스를 각각 1대씩 생성했다. 두 인스턴스에는 간단한 웹 서버를 설치하여 접속 시 서로 다른 메시지가 보이도록 구성하면 트래픽 분산 여부를 확인하기 쉽다.

예를 들어 각 인스턴스의 웹 페이지 내용을 다음과 같이 다르게 설정할 수 있다.

<h1>Web Server A - ap-northeast-2a</h1>

<h1>Web Server C - ap-northeast-2c</h1>

이렇게 설정하면 ALB DNS 주소로 접속했을 때 새로고침에 따라 서로 다른 서버 응답이 보일 수 있다.

EC2 생성

 

---

12.5 실습 단계 3: 보안 그룹 설정

ALB와 EC2 인스턴스에는 각각 다른 보안 그룹을 적용하는 것이 좋다.

ALB 보안 그룹은 외부 사용자의 HTTP/HTTPS 요청을 받을 수 있어야 한다.

대상유형포트소스

ALB 보안 그룹	HTTP	80	0.0.0.0/0
ALB 보안 그룹	HTTPS	443	0.0.0.0/0

EC2 보안 그룹은 전체 인터넷에서 직접 접근을 허용하지 않고, ALB 보안 그룹에서 오는 트래픽만 허용하도록 설정한다.

대상유형포트소스

EC2 보안 그룹	HTTP	80	ALB Security Group
EC2 보안 그룹	SSH	22	내 IP

이렇게 구성하면 사용자는 EC2에 직접 접근하는 것이 아니라 ALB를 통해서만 웹 서버에 접근하게 된다. 이는 보안 측면에서 더 안전한 구조이다.

---

12.6 실습 단계 4: Target Group 생성

EC2 인스턴스를 ALB의 트래픽 대상으로 등록하기 위해 Target Group을 생성했다.

설정 예시는 다음과 같다.

항목설정

Target type	Instances
Protocol	HTTP
Port	80
VPC	실습용 VPC
Health Check Path	/ 또는 /health
Success codes	200

Target Group 생성 후, 앞에서 만든 EC2 인스턴스 2대를 대상에 등록했다.

---

12.7 실습 단계 5: Application Load Balancer 생성

Application Load Balancer를 생성하여 두 AZ의 퍼블릭 서브넷에 연결했다.

설정 예시는 다음과 같다.

항목설정

Load Balancer Type	Application Load Balancer
Scheme	Internet-facing
Listener	HTTP:80
VPC	실습용 VPC
Availability Zones	2개 이상 선택
Security Group	ALB용 보안 그룹
Target Group	앞에서 생성한 Target Group

ALB는 사용자의 HTTP 요청을 받아 Target Group에 등록된 정상 EC2 인스턴스로 전달한다.

---

12.8 실습 단계 6: Health Check 상태 확인

ALB 생성 후 Target Group의 Targets 탭에서 각 인스턴스의 Health Check 상태를 확인했다. 정상적으로 웹 서버가 동작하고 보안 그룹이 올바르게 설정되어 있다면 두 인스턴스가 Healthy 상태로 표시된다.

만약 Unhealthy로 표시된다면 다음 항목을 확인해야 한다.

• EC2 인스턴스가 Running 상태인지
• 웹 서버가 80번 포트에서 정상 실행 중인지
• EC2 보안 그룹이 ALB 보안 그룹으로부터 HTTP 80 포트를 허용하는지
• Health Check Path가 실제 응답 가능한 경로인지
• 성공 코드가 200으로 설정되어 있는지
• ALB와 EC2가 같은 VPC에 있는지

---

12.9 실습 단계 7: ALB DNS로 접속 확인

ALB가 생성되면 DNS 이름이 제공된다. 브라우저에서 ALB DNS 주소로 접속하면 Target Group에 등록된 EC2 인스턴스 중 하나로 요청이 전달된다.

새로고침을 반복하면 Web Server A 또는 Web Server C가 번갈아 응답하는 것을 확인할 수 있다. 이를 통해 ALB가 트래픽을 여러 인스턴스로 분산하고 있음을 확인할 수 있다.

---

12.10 실습 단계 8: 장애 상황 테스트

고가용성 구조를 확인하기 위해 한 EC2 인스턴스의 웹 서버를 중지하거나 인스턴스를 중지하는 방식으로 장애 상황을 테스트했다.

장애 테스트 흐름은 다음과 같다.

1. 두 EC2 인스턴스가 모두 Healthy 상태인지 확인
2. 한 인스턴스의 웹 서버 중지 또는 인스턴스 Stop
3. Target Group에서 해당 인스턴스가 Unhealthy로 변경되는지 확인
4. ALB DNS로 접속
5. 정상 인스턴스로만 트래픽이 전달되는지 확인
6. 장애 인스턴스를 복구한 뒤 다시 Healthy 상태가 되는지 확인

이 실습을 통해 ELB의 Health Check와 트래픽 우회 기능이 고가용성 구조에서 핵심 역할을 한다는 점을 확인할 수 있다.

 

---

13. Auto Scaling 연동 실습

13.1 실습 목적

Auto Scaling Group을 사용하면 EC2 인스턴스 수를 자동으로 유지하거나 조절할 수 있다. 이번 실습에서는 ALB와 Auto Scaling Group을 함께 사용하여 인스턴스 장애 발생 시 자동으로 새 인스턴스가 생성되는 구조를 이해했다.

---

13.2 Launch Template 생성

Auto Scaling Group은 새 인스턴스를 생성할 때 어떤 AMI, 인스턴스 타입, 키 페어, 보안 그룹, 사용자 데이터 스크립트를 사용할지 알아야 한다. 이를 정의하는 것이 Launch Template이다.

Launch Template에는 다음 정보를 설정한다.

항목설명

AMI	인스턴스 생성에 사용할 이미지
Instance type	인스턴스 사양
Key pair	접속용 키 페어
Security Group	인스턴스에 적용할 보안 그룹
User Data	웹 서버 자동 설치 스크립트
IAM Role	필요 시 EC2에 부여할 역할

launch wizard

 

---

13.3 Auto Scaling Group 생성

Auto Scaling Group 생성 시 여러 AZ의 서브넷을 선택하고, 앞에서 생성한 Target Group과 연결한다.

설정 예시는 다음과 같다.

항목설정

Desired capacity	2
Minimum capacity	2
Maximum capacity	4
Subnet	2개 AZ의 서브넷 선택
Load Balancer	기존 ALB에 연결
Target Group	기존 Target Group 선택
Health check	ELB Health Check 사용

이렇게 설정하면 Auto Scaling Group은 기본적으로 인스턴스 2대를 유지하고, 필요 시 최대 4대까지 확장할 수 있다.

---

13.4 Auto Scaling 장애 복구 확인

Auto Scaling Group에 의해 관리되는 인스턴스 중 하나를 종료하면, ASG는 원하는 인스턴스 수를 유지하기 위해 새 인스턴스를 생성한다. 새 인스턴스가 부팅되고 Health Check를 통과하면 Target Group에 Healthy 상태로 등록된다.

이 흐름을 통해 단순한 트래픽 우회뿐 아니라 인스턴스 자동 교체까지 가능하다는 점을 확인할 수 있다.

 

---

14. 실습 중 문제점 및 해결 방안

14.1 문제점 1: Target Group의 인스턴스가 Unhealthy로 표시됨

처음 Target Group에 EC2 인스턴스를 등록했을 때 인스턴스 상태가 Healthy가 아니라 Unhealthy로 표시될 수 있다.

원인 분석

이 문제는 보통 다음 원인 중 하나로 발생한다.

• EC2 인스턴스의 웹 서버가 실행되지 않음
• Health Check Path가 실제 존재하지 않는 경로임
• EC2 보안 그룹에서 ALB의 HTTP 접근을 허용하지 않음
• 인스턴스가 다른 VPC 또는 잘못된 서브넷에 있음
• 웹 서버가 80번 포트가 아닌 다른 포트에서 실행 중임
• Health Check 성공 코드가 실제 응답 코드와 맞지 않음

해결 방안

먼저 EC2 인스턴스에 직접 접속하여 웹 서버가 실행 중인지 확인했다. 이후 보안 그룹에서 EC2의 80번 포트 소스를 ALB 보안 그룹으로 허용했다. 마지막으로 Target Group의 Health Check Path를 / 또는 실제 존재하는 /health로 수정했다.

이후 Target Group 상태가 Healthy로 변경되었고, ALB DNS로 접속했을 때 정상적으로 웹 페이지가 표시되었다.

---

14.2 문제점 2: ALB DNS로 접속했을 때 페이지가 열리지 않음

ALB는 생성되었지만 브라우저에서 ALB DNS 주소로 접속했을 때 페이지가 열리지 않는 문제가 발생할 수 있다.

원인 분석

가능한 원인은 다음과 같다.

• ALB가 Internet-facing이 아니라 Internal로 생성됨
• ALB가 퍼블릭 서브넷에 연결되지 않음
• ALB 보안 그룹에서 80번 포트를 허용하지 않음
• 퍼블릭 서브넷 라우팅 테이블에 Internet Gateway 경로가 없음
• Target Group에 Healthy 인스턴스가 없음

해결 방안

ALB의 Scheme이 Internet-facing인지 확인하고, 두 개 이상의 퍼블릭 서브넷에 연결되어 있는지 점검했다. 또한 ALB 보안 그룹에서 HTTP 80 포트를 0.0.0.0/0으로 허용했는지 확인했다. 마지막으로 Target Group에 Healthy 상태의 인스턴스가 있는지 확인한 뒤 다시 접속했다.

이 과정을 통해 ALB 접속 문제는 단순히 ALB 하나의 문제가 아니라, 서브넷, 라우팅 테이블, 보안 그룹, Target Group 상태가 모두 연결된 문제라는 점을 알게 되었다.

---

14.3 문제점 3: 장애 테스트 후 트래픽이 계속 실패한 인스턴스로 전달됨

한 인스턴스를 중지했는데도 ALB가 바로 정상 인스턴스로만 트래픽을 보내지 않는 것처럼 보일 수 있다.

원인 분석

Health Check는 즉시 한 번 실패했다고 바로 Unhealthy로 판단하지 않는다. Unhealthy threshold와 interval 설정에 따라 여러 번 실패해야 비정상 상태로 변경된다. 따라서 장애를 발생시킨 직후에는 잠시 동안 상태 변경을 기다려야 한다.

해결 방안

Target Group의 Health Check 설정에서 Interval과 Unhealthy threshold를 확인했다. 이후 일정 시간이 지나자 장애 인스턴스가 Unhealthy로 변경되었고, ALB가 정상 인스턴스로만 트래픽을 전달하는 것을 확인했다.

이를 통해 Health Check는 실시간 즉시 반응이 아니라, 설정된 주기와 임계값에 따라 판단된다는 점을 이해했다.

---

15. 기존 학습 내용과의 연결

12주차의 고가용성 설계는 이전에 학습한 여러 AWS 개념과 연결된다.

기존 학습 내용12주차와의 연결

EC2	여러 AZ에 웹 서버 인스턴스를 분산 배치
VPC	Public/Private Subnet과 라우팅 테이블 기반 네트워크 구성
보안 그룹	ALB와 EC2 간 접근 제어
RDS	Multi-AZ 구성으로 DB 장애 대응
CloudWatch	CPU, Target 상태, ALB 지표 모니터링
CloudTrail	인스턴스 생성, 종료, 보안 그룹 변경 기록 추적
AWS Budgets	ALB, NAT Gateway, EC2 사용 비용 모니터링
IAM	EC2, Auto Scaling, ELB 사용 권한 제어

즉, 12주차는 EC2, VPC, 보안 그룹, RDS, CloudWatch 등 이전에 학습한 서비스들을 하나의 고가용성 아키텍처로 조합하는 주차라고 볼 수 있다.

---

16. 리소스 정리 및 비용 주의

고가용성 실습은 여러 리소스를 사용하기 때문에 실습 후 정리가 중요하다. 특히 ALB, NAT Gateway, EC2, EBS, RDS 등은 방치하면 비용이 발생할 수 있다.

실습 후 확인해야 할 리소스는 다음과 같다.

리소스정리 방법

EC2 인스턴스	더 이상 사용하지 않으면 Terminate
Auto Scaling Group	삭제 또는 Desired capacity 0으로 변경 후 삭제
Launch Template	불필요하면 삭제
Target Group	ALB 삭제 후 함께 정리
Application Load Balancer	사용 후 삭제
NAT Gateway	비용이 발생하므로 반드시 삭제
Elastic IP	NAT Gateway 삭제 후 남아 있으면 해제
EBS Volume	인스턴스 종료 후 남은 볼륨 확인
RDS	실습용이면 삭제 또는 스냅샷 확인 후 삭제
CloudWatch Alarm	불필요한 알람 삭제

특히 NAT Gateway와 Load Balancer는 인스턴스처럼 눈에 잘 보이지 않아 실습 후 방치하기 쉽다. 따라서 실습이 끝나면 VPC, EC2, Load Balancer, Auto Scaling, RDS, Elastic IP 메뉴를 차례대로 확인하는 것이 좋다.

---

17. 12주차 학습 정리

이번 12주차 학습을 통해 AWS에서 고가용성을 확보하려면 단일 서버 중심 구조에서 벗어나 멀티 AZ, ELB, Health Check, Auto Scaling을 함께 활용해야 한다는 점을 이해했다.

핵심 내용을 정리하면 다음과 같다.

핵심 개념정리

고가용성	서비스를 가능한 한 중단 없이 지속적으로 제공하는 능력
SPOF	하나가 고장 나면 전체 장애로 이어지는 단일 장애점
리전	지리적으로 분리된 AWS 인프라 단위
AZ	리전 내부의 독립된 데이터센터 집합
멀티 AZ	여러 AZ에 리소스를 분산하여 장애에 대비하는 구조
ELB	여러 서버로 트래픽을 자동 분산하는 서비스
ALB	HTTP/HTTPS 웹 애플리케이션 트래픽 분산에 적합
Target Group	ALB가 트래픽을 전달할 대상 묶음
Health Check	인스턴스 정상 여부를 주기적으로 확인하는 기능
Auto Scaling	인스턴스 수를 자동으로 조절하고 장애 인스턴스를 교체
Failover	장애 발생 시 정상 리소스로 자동 전환하는 과정

---

18. 학습 후기

이번 12주차 학습을 통해 클라우드 아키텍처에서 “서버가 실행된다”는 것과 “서비스가 안정적으로 운영된다”는 것이 다르다는 점을 이해했다.

이전 EC2 실습에서는 하나의 인스턴스를 생성하고 접속하는 방법을 중심으로 학습했다. 하지만 실제 운영 환경에서 하나의 인스턴스만 사용하면 해당 인스턴스가 중지되거나 장애가 발생했을 때 전체 서비스가 중단될 수 있다. 이번 주차에서는 이러한 문제를 해결하기 위해 여러 AZ에 인스턴스를 분산하고, ELB를 통해 트래픽을 정상 인스턴스로 자동 분산하는 구조를 학습했다.

특히 Health Check의 역할이 인상적이었다. ELB는 단순히 요청을 나누는 역할만 하는 것이 아니라, 각 인스턴스가 정상인지 지속적으로 확인한다. 인스턴스가 응답하지 않거나 오류를 반환하면 해당 인스턴스를 Unhealthy로 판단하고 트래픽 대상에서 제외한다. 이를 통해 장애가 발생한 서버로 사용자의 요청이 계속 전달되는 문제를 줄일 수 있다.

또한 Auto Scaling Group과 ELB를 함께 사용하면 장애 복구가 더 자동화될 수 있다는 점을 알게 되었다. ALB가 비정상 인스턴스로의 트래픽을 중단하고, Auto Scaling Group이 새 인스턴스를 생성하여 원하는 개수를 유지하면 운영자가 직접 개입하지 않아도 서비스 안정성을 높일 수 있다.

실습 과정에서 가장 헷갈렸던 부분은 Target Group의 Health Check 상태였다. 처음에는 인스턴스가 Running 상태이면 당연히 Healthy로 표시될 것이라고 생각했지만, 실제로는 웹 서버 실행 여부, 보안 그룹, Health Check Path, 성공 응답 코드가 모두 맞아야 Healthy 상태가 된다는 점을 알게 되었다. 이를 통해 클라우드 장애 분석은 하나의 설정만 보는 것이 아니라 네트워크, 보안, 애플리케이션 상태를 함께 확인해야 한다는 점을 배웠다.

이번 학습을 바탕으로 앞으로 AWS 기반 서비스를 설계할 때는 단일 EC2 인스턴스에 의존하지 않고, 최소 두 개 이상의 AZ에 리소스를 분산하고, ALB와 Health Check, Auto Scaling을 함께 구성하는 방향으로 설계하고자 한다. 또한 실습 후에는 Load Balancer, NAT Gateway, Auto Scaling Group, RDS 같은 비용 발생 리소스를 반드시 정리하여 안정성과 비용 관리까지 함께 고려하는 클라우드 운영 습관을 가지려고 한다.