Secrets Manager에 환경 설정 저장
이전에 RDS, ELASTIC CACHE(REDIS), MSK 클러스터를 생성했을 당시, 각각의 설정 완료 후 생성된 엔드포인트들과 부트스트랩 서버(MSK)의 엔드포인트를 복사해둔다. MSK 클러스터의 BootStrap Servers의 엔드포인트 형식은 아래와 같다.
boot-xxxxxxxx.c1.kafka-serverless.ap-northeast-2.amazonaws.com:9098
Secrets Manager에 보안 정보 저장
"보안 암호 생성"을 누르고, 보안 암호 유형으로는 "다른 유형의 보안 암호"를 선택한다. 암호화 키는 aws/secretsmanager (기본값)으로 설정해둔다.
키/값은 .env 파일에 정의해둔 모든 환경변수와 보안 정보들로 채운다.
보안 암호 이름은 "prod/rushdeal/common"으로 설정해두었다.

IAM ROLE 권한 정책 추가
이후에 할 작업으로는 IAM의 "역할"관리 대시보드에서 ecsTaskExecutionRole 역할에 Secrets Manager를 읽을 권한을 주어야 한다.
1. IAM > Roles > ecsTaskExecutionRole 선택
2. 권한 추가 -> 인라인 정책 선택
3. JSON에 아래 내용으로 수정해준다. (YOUR_ACCOUNT_ID는 AWS 계정 ID 숫자 12자리이다.)
4. ECSSecretsAccessPolicy라는 이름으로 ecsTaskExecutionRole 역할에 정책 권한을 추가해주었다.

로드밸런서(ALB) 및 대상 그룹(Target Group) 준비
서비스를 띄우기 전에, 외부에서 들어올 문(ALB)와 방(Target Group)을 먼저 만들어야 연결할 수 있다. MSA 서비스들 중 user-service 기준으로는 다음과 같다.
대상 그룹 생성
IP addresses (Fargate는 IP 타입 필수)
대상 그룹 이름 : user-service-tg
프로토콜: HTTP / 포트: 8060 (User Service 포트)
VPC: 해당 프로젝트 VPC 선택
상태검사 프로토콜: HTTP
상태검사 경로 : /actuator/health (중요! 이 부분이 안맞으면 안 맞으면 계속 재시작한다고 한다.)
IP 등록 화면 스킵 (NEXT)


"user-service-tg"가 생성된 모습니다. 대상 등록은 ECS 서비스에서 자동으로 해주므로 그냥 두면 된다. 이와 같이 나머지 다른 MSA 서비스들도 하나하나씩 대상 그룹(Target Group)을 생성해준다.
이후에 "로드 밸런서" 화면으로 들어가서 HTTP:80 항목 클릭
리스너 및 규칙 탭의 "리스너 추가"를 누른다. (이전 포스팅에서 ALB 생성 시 임의로 추가해둔 규칙은 삭제한다.)
기본 작업 란에서 대상 그룹으로 "user-service-tg"을 선택한다.


ALB Listener Rules 설정 (경로 기반 라우팅)
"로드 밸런서" 화면으로 돌아가서 HTTP:80 항목 체크 -> 규칙 편집
규칙 추가 선택 (각 msa 서비스마다 규칙을 추가해야 한다)
이름 : {msa 서비스 도메인}-service-rule
조건 : 경로 선택, 값 일치 패턴으로 설정한다.
// 예시
api/v1/users*
작업 : 대상 그룹으로 전달 -> 대상 그룹 "{msa 서비스 도메인}-service-tg" 선택
우선 순위 : 1 ... n (나의 경우에는 user-service라서 1로 시작했다. 그 다음 나머지 서비스들은 1씩 증가하며 우선순위를 설정했다.)
=> 나머지 MSA 서비스들도 개수에 맞게 똑같이 규칙을 추가해준다.

ECS 태스크 정의 (Task Definition)
"어떤 이미지를, 어떤 CPU/메모리로, 어떤 환경변수를 가지고 실행할지" 정의하는 설계도입니다. docker-compose.yml의 AWS 버전이라고 보시면 됩니다.
ECS -> 태스크 정의 -> 태스크 정의 생성
태스크 정의 패밀리 네임 : rushdeal-user-task
인프라 요구사항 : AWS Fargate, Linux/X86_64, .5 vCPU, 메모리 1 GB (MSA 기본 사이즈. 부하 테스트 때 필요하면 늘림)
태스크 역할 : ecsTaskRole (MSK 권한 있는 역할)
태스크 실행 역할 : ecsTaskExecutionRole (Secrets Manager 권한 있는 역할)

각 서비스 별 환경변수를 설정해주는 부분이다. 각 서비스의 application.yml에 정의되어 있는 환경변수들의 키와 그 값들을 넣어주면 되는데, SecretsManager에 등록해둔 값들은 ValueFrom 유형으로 선택하고,
arn:aws:secretsmanager:ap-northeast-2:{AWS_ACCOUNT_ID_12_DIGIT}:secret:prod/rushdeal/common:{SecretManager에 등록한 키 값}::
이런 식으로 등록해주면 Secrets Manager로부터 값을 가지고 올 수 있다.

위와 같이 나머지 MSA 서비스들도 ECS 태스크 정의를 하나하나씩 다 설정해준다.

ECS Service 생성
다시 ECS 화면으로 들어와 이전에 생성해둔 클러스터를 선택하여 서비스 생성을 시작한다.

서비스 세부 정보 & 환경
태스크 정의 : rushdeal-user-task (LATEST 버전)
Service name: rushdeal-user-service
Desired tasks: 1 (테스트용)
컴퓨팅 옵션 : Fargate
네트워킹 (중요!!)
VPC: 우리 VPC
서브넷 : Private Subnet 2개 선택 (앱은 안전하게 프라이빗에!)
보안 그룹 : 기존 그룹 선택 (rushdeal-app-sg)
퍼블릭 IP : 켜져있으면 꼭 비활성화해준다 (중요)

로드 밸런싱
로드 밸런싱을 구성하여 서비스의 정상 태스크 전체에 트래픽을 균등하게 분배한다.
컨테이너 : user-service 포트 선택
기존 로드 밸런서 사용 : rushdeal-alb
리스너 : 기존 리스너 선택
대상그룹 : 기존 대상 그룹 선택

위 설정을 하고 생성을 하면 user-service에 대한 ECS 서비스가 생성된 모습을 아래와 같이 볼수 있다!

다음 생성된 서비스에 대한 확인을 해볼 차례이다.
방금 만든 서비스(rushdeal-user-service)를 선택 -> 태스크 탭 확인하여 상태가 Running/Healthy인지 확인한다.
대상 그룹 확인 :
EC2 -> 대상 그룹 -> user-service-tg(서비스에 해당하는 대상 그룹)
대상 탭에서 IP가 "healthy" 상태인지 확인한다.
만약 IP 상태가 "healthy" 상태가 아닐 경우에는 cloudwatch 에서 로그를 통해 문제를 확인한다.
CloudWatch → Log groups → /ecs/user-service → 최근 로그 스트림 클릭 → 에러 메시지 확인
ECS 서비스 실행 실패 시
클라우드 워치(cloudwatch)에서 확인한 로그를 통해 문제점을 해결하고, 해당 서비스에서 "새 배포 강제 적용"을 하여 다시 배포한다. 강제 배포를 해야만 수정된 코드나 태스크 정의 등의 설정이 반영되기 때문이다.


ECS 서비스 태스크의 마지막 상태와 원하는 상태가 "실행 중"이면 정상적으로 잘 동작하는 것이다. 여기서 ECS 서비스가 "잘 돌아간다"의 기준은 ECS 컨테이너가 켜져 있다는 것뿐만 아니라, 로드밸런서가 트래픽을 보내줄 준비가 되었다는 것이다.
이 외에도 정상 동작 확인 기준은 아래를 통해 확인할 수 있다.
① ECS 서비스 이벤트 확인 (1차)
- 위치: ECS -> 클러스터 -> 서비스(rushdeal-user-service) -> 이벤트 탭
- 확인할 것:
- has reached a steady state. (안정 상태 도달) 메시지가 가장 위에 떠 있어야 함
- 만약 unable to place a task나 stopped가 계속 반복된다면 아직 에러가 있는 것이다
② 대상 그룹(Target Group) 상태 확인 (중요)

ECS 태스크가 실행 중(Running)이라도, 로드밸런서가 "실패"라고 판단하면 요청을 안 보낸다. 여기가 Healthy여야 진짜로 잘 동작하는 것이다.
- 위치: EC2 > 로드 밸런싱 > 대상 그룹(Target Groups)
- 확인할 것:
- rushdeal-user-service와 연결된 대상 그룹 클릭
- 하단 대상(Targets) 탭 확인
- 상태가 Healthy (초록색)여야 함
- 만약 Unhealthy나 Initial 상태라면, 로드밸런서가 컨테이너 상태 검사(Health Check)를 실패하고 있다는 뜻 (이 경우 보통 Spring Security 설정이나 Health Check 경로 문제)
'Project' 카테고리의 다른 글
| Antigravity를 활용한 포트폴리오 사이트 개발기 (0) | 2026.03.20 |
|---|---|
| [RUSH_CREW] 트러블슈팅 - AWS ECS 서비스 HEALTH CHECK 실패 해결기 (0) | 2025.12.30 |
| [SURFING THE GANGWON] 기상청 API 호출 성능 최적화 (0) | 2025.10.01 |