20260329 TIL - AWS 서비스

[서론]

주말이라 그런가 오늘은 푹 잤다. 거의 overslept 정도로. 근데 피로가 안풀리긴 한다. 인프라에 관한 구축을 하려고 했는데, 오늘 내로 못할 것 같아서 TIL 을 쓰고 나서 더 해야겠다. AWS 구성요소에 관한 글을 쓰려고 한다.

 

[오늘의 추천곡] ADOY - Grace

우리나라에서 신스팝을 하는 몇 안되는 그룹 중 하나이다. 몇 년전부터 신스웨이브에 빠지게 되었다. 신스웨이브는 전자 음악을 기반으로 뇌파가 이상해지는 멜랑꼴리한 사운드이다. 도쿄 80s 노래와 비슷한 느낌이다. 그쪽이랑은 조금 다르지만 신스쪽을 좋아해서 위켄드니 다프트 펑크니 그 분야 음악을 주로 들었다. 인디쪽은 잘 모르지만 ADOY, 실리카겔, 검정치마 등등 나도 들을만한 곡들이 있다. ( 사실 내 엑스가 좋아했던 그룹들이다.) 코딩이나 집중하면서도 좋으니 바란다.

 

 

 

 

[AWS 서비스]

AWS에서의 핵심은 서버를 만드는 것이 아니라, 트래픽 증가와 장애 상황에서도 서비스가 무너지지 않도록 분산 + 확장 + 격리 구조를 설계하는 것이다.

이를 위해 ALB는 요청을 분산하고, ECS는 서비스를 유지하며, Auto Scaling은 처리 용량을 확장하고, ECR은 배포 일관성을 보장하고, EC2는 실행 환경을 제공한다. 이제 각 서비스에 대해서 설명해보겠다.

 

1. ALB

문제

• 요청이 한 서버로 몰리면 Gateway가 먼저 죽음

해결

• 요청을 여러 인스턴스로 분산 (Load Balancing)

보호 대상

• Gateway / Thread / CPU (전체 진입 지점)

역할

• 현재 살아있는(Healthy) 대상에게만 로드 밸런싱을 함.
• 여러 인스턴스로 요청을 분산
• 헬스 체크 실패 인스턴스는 제외.
• Layer 7 기반 라우팅(경로/도메인 기준 분기 가능)

Trade-off

• 가용성과 분산성 증가
• 비용 증가
• 네트워크 홉 1단계 증가
• 구조 복잡도 증가
• 디버깅 시 어느 인스턴스로 갔는지(A/B테스트 같은 것 할 때) 추적 어려움

 

2. Target Group

문제

• 로드 밸런서를 붙여도 어디로 보낼지와 누가 살아있는지 모르면 의미 없음

해결

• Target Group이 ALB가 요청 전달할 대상 집합 관리
• 헬스 체크로 정상인지 판별
• 정상 대상만 트래픽 받게 함

역할

• 요청 전달할 대상 집합 관리
• 헬스 체크 수행 및 상태 유지
• ALB와 실제 인스턴스/Task 연결
• 포트 단위로 트래픽 라우팅(서비스 단위 분리 가능)
• 비정상 대상 자동 제외 및 복구 시 재등록

보호 대상

• ALB 뒤 실제 서버
• 죽은 인스턴스로 잘못 보내는 요청
• 결과적으로는 사용자 성공률 -> 정상 대상만 받게 하는 정합성 보호

Trade-off

• 헬스 체크 설정 복잡도
• 잘못 설정하면 멀쩡해도 unhealthy 되는 문제
• 배포시 일시적 health mismatch 생김

 

3. Auto Scaling

문제

• ALB 분산해도 뒤에 서버 수가 고정이면 과부하될 시 트래픽 한계있음 (응답시간 증가, 타임아웃, 장애 전파)

해결

• 트래픽 증가 감지
• 새 인스턴스/태스크 생성
• Target Group에 새 서버 자동 등록(처리 용량 보호)
• ALB가 새 인스턴스로도 분산

역할

• 트래픽/지표(CPU/Request) 모니터링
• 스케일링 정책 기반 인스턴스/Task 수 조절
• Scale-out/Scale-in 자동 수행
• Target Group과 연동하여 신규 인스턴스 자동 등록/제거
• 필요 시 EC2와 Task 확장을 함께 수행

보호 대상

• 개별 서버의 CPU/Memory/Thread
• 트래픽 처리 한계
• 처리 용량 보호로 서비스 가용성 증가

Trade-off

• 비용 증가
• 운영 예측 어려움
• scale-out이 즉시 되지는 않음
• 상태 저장형 서버는 확장 어려움
• 로그/세션/디버깅 복잡도 증가

 

4. ECS

문제

• 서비스를 EC2에 수동 배포만 하면 운영 꼬임
• 컨테이너 단위로 일관되게 올리고 교체 못하면 운영 취약

해결

• ECS는 컨테이너 원하는 개수만큼 띄우고 유지함

역할

• Task Definition 기반 컨테이너 실행
• 비정상 Task 자동 재생성
• Desired Count 유지 (지정 개수 자동 유지)
• ALB와 연동하여 트래픽 분산
• 롤링 배포 및 무중단 배포 지원
• 서비스 단위 스케일링 지원

보호 대상

• 배포 일관성
• 서비스 실행 환경
• 장애 후 복구 속도
• 운영 인력의 수작업 부담

Trade-off

• AWS 종속성
• 네트워크/배포 구조 학습 비용
• 로컬 실행과 운영 환경 차이 관리 필요
• 디버깅 복잡도

5. ECR

문제

• 서버마다 다른 Docker 이미지 사용 → 배포 불일치
• 이미지 버전 관리 어려움 → 롤백 불가능

해결

• Docker 이미지를 중앙 저장소에서 관리
• ECS/EC2가 동일한 이미지를 pull

보호 대상

• 배포 일관성
• 이미지 버전 관리

역할

• Docker 이미지 저장 및 버전 관리
• ECS / EC2에서 이미지 pull
• CI/CD(GitHub Actions)와 연동
• 배포 기준점(Single Source of Truth) 제공

Trade-off

• 저장 비용
• 이미지 관리 필요

6. EC2

문제

• 애플리케이션 실행할 물리적/가상 서버 필요
• 단일 서버일 경우 장애 시 전체 서비스 중단

해결

• 가상 서버 제공
• Auto Scaling을 통해 서버 수 확장

보호 대상

• 애플리케이션 실행 환경
• 인프라 레벨 가용성

역할

• 애플리케이션 실행 환경 제공
• ECS Container Instance로 사용 (ECS on EC2)
• Auto Scaling Group을 통해 서버 확장
• 컨테이너(Task)가 올라갈 물리적 리소스 제공

Trade-off

• 서버 관리 필요
• 운영 부담 증가
• 리소스 낭비 가능성

 

[결론]

이제 회복은 충분히 되었다 생각하자. 물론 아직도 힘들다... 내일은 열심히 프로젝트에만 열중해야겠다. 그 전까지 인프라 구축하고, 명세서 다 작성해야겠다... 참 피폐해져가는 것을 느낀다.