Troubleshooting — hybrid-hospital-system

01

GitHub Actions OIDC 인증 실패

GitHub Actions IAM OIDC

▶

증상

GitHub Actions 워크플로우(ecr-push.yml) 실행 시 Configure AWS Credentials 단계에서 오류 발생

Error: Could not assume role with OIDC: Not authorized to perform sts:AssumeRoleWithWebIdentity

원인

IAM 역할 github-actions-ecr-push의 Trust Policy에 설정된 레포지토리 이름이 실제와 불일치. GitHub 레포지토리가 msp_hospital_project → hybrid-hospital-system으로 이름이 변경되었으나 Trust Policy가 갱신되지 않음

해결

AWS Console → IAM → Roles → github-actions-ecr-push → Trust relationships → Edit trust policy에서 sub 조건 수정

# 변경 전
"token.actions.githubusercontent.com:sub": "repo:990402DAJEONGKIM/msp_hospital_project:*"

# 변경 후
"token.actions.githubusercontent.com:sub": "repo:990402DAJEONGKIM/hybrid-hospital-system:*"

02

로그인 500 에러 — api_user 테이블 권한 누락

PostgreSQL RDS GRANT

▶

증상

로그인 시도 시 500 Internal Server Error 발생. 로그인 인증 자체는 성공했으나 login_history 테이블에 INSERT하는 시점에 예외 발생

sqlalchemy.exc.ProgrammingError: permission denied for table login_history

원인

90일 로테이션 설정 시 IAM·SG 권한만 부여하고 DB 테이블 권한 전체를 점검하지 않아 api_user 계정의 테이블 권한이 누락됨. login_history를 포함한 15개 테이블 권한 누락

해결

hospital_user(RDS 마스터) 계정으로 누락된 테이블에 GRANT 일괄 실행. 조치 후 26개 테이블 권한 모두 정상 확인

GRANT SELECT, INSERT ON login_history TO api_user;
GRANT SELECT, INSERT, UPDATE ON appointments TO api_user;
GRANT SELECT, INSERT, UPDATE ON notifications TO api_user;
GRANT SELECT, INSERT, UPDATE, DELETE ON user_mfa TO api_user;
-- 이하 동일하게 누락된 15개 테이블 일괄 적용

✓ 500 에러 → 정상 응답으로 해소

03

RDS 스키마 불일치로 온프레미스 동기화 실패

PostgreSQL Schema deidentification-api

▶

증상

sync_* 테이블 중 일부만 동기화되고 나머지는 실패. deidentification-api 컨테이너 로그에서 컬럼명 불일치 오류 확인

column "patient_id_hash" of relation "sync_encounters" does not exist

원인

온프레미스 DB 스키마를 사전에 파악하지 않고 AWS RDS sync_* 테이블을 설계하면서 컬럼명·데이터 타입·VARCHAR 길이 불일치 발생. 주요 불일치 항목:

테이블	기존 컬럼명	API 기대 컬럼명
sync_encounters	`patient_hash`	`patient_id_hash`
sync_encounters	`visit_hour (TIMESTAMPTZ)`	`visit_date (DATE)`
sync_allergies	`allergy_code`	`allergy_name`
sync_surgery_histories	`surgery_yearmonth (VARCHAR)`	`surgery_date (DATE)`

해결

온프레미스 스키마를 덤프·분석한 뒤 패치 스크립트(rds-schema-patch-v2.sql)로 AWS RDS 테이블을 일괄 수정. 이후 스키마 변경 시 온프레미스 구조를 먼저 확인하는 협업 프로세스 정립

✓ 전체 7개 sync_* 테이블 동기화 성공 (총 609건)

04

시크릿 값 미설정으로 컨테이너 기동 실패

Secrets Manager TaskFailedToStart

▶

증상

ECS patient-service 배포 시 컨테이너가 기동되지 않고 30분 타임아웃 후 실패

TaskFailedToStart: Secrets Manager can't find the specified secret value for staging label: AWSCURRENT

원인

aws-ecs-patient-database-url-secret 시크릿이 생성은 되어 있었으나 실제 값(AWSCURRENT)이 한 번도 설정되지 않은 상태

해결

AWS Console → Secrets Manager → aws-ecs-patient-database-url-secret → Set secret value → Plaintext에 DB URL 입력 후 저장. 이후 Force new deployment 실행

05

DB URL 특수문자 URL 인코딩 누락으로 500 오류

Secrets Manager URL Encoding PostgreSQL

▶

증상

웹 페이지는 정상 로드되나 DB 조회 시 500 오류 발생. SSM으로 EC2 접속 후 docker logs 확인 결과

could not translate host name "#@aws-aurora-01.cluster-..." to address: Name or service not known

원인

DB 비밀번호에 포함된 특수문자(@, #)가 URL 인코딩 없이 사용됨. URL 형식에서 @는 자격증명과 호스트의 구분자로 해석되어 호스트 주소가 잘못 파싱됨

postgresql://user:password@#@host → host = "#@host" 로 잘못 파싱

해결

Secrets Manager DB URL 값에서 비밀번호 특수문자를 URL 인코딩으로 변환. patient, staff 두 시크릿 모두 수정 후 Force new deployment 실행

@ → %40,  # → %23
예시: postgresql://user:password%40%23@host:5432/dbname

06

Rotation Lambda 실행으로 인한 비밀번호 불일치

Secrets Manager Rotation Aurora

▶

증상

URL 인코딩 수정 후에도 500 오류 지속

FATAL: password authentication failed for user "ecs_patient_user"

원인

당일 ecs_db_rotator Rotation Lambda가 실행되어 Aurora DB의 비밀번호가 새로운 랜덤값으로 변경됨. 그러나 사용자가 Secrets Manager 값을 수동으로 덮어써서 Aurora와 Secrets Manager 간 비밀번호 불일치 발생

해결

rotate-secret 명령어로 rotation을 재실행하여 Aurora와 Secrets Manager를 동기화 후 ECS 재배포

aws secretsmanager rotate-secret \
  --secret-id aws-ecs-patient-database-url-secret \
  --region ap-south-2

07

Rotation Lambda → Aurora 네트워크 접근 불가

Lambda Security Group Aurora

▶

증상

rotate-secret 실행 시 Lambda 로그에서 타임아웃 오류 발생

OperationalError: connection to server at "aws-aurora-01..." port 5432 failed: timeout expired

원인

RDS 보안 그룹(aws-rds-sg)에 ecs_db_rotator Lambda의 보안 그룹(aws-ecs-db-rotator-sg)에서 오는 5432 포트 인바운드 규칙이 누락

해결

terraform/aws/rds/main.tf에 Lambda SG의 5432 인바운드 규칙 추가 후 terraform apply

ingress {
  from_port       = 5432
  to_port         = 5432
  protocol        = "tcp"
  security_groups = [data.aws_security_group.ecs_db_rotator.id]
  description     = "ECS DB Rotator Lambda to Aurora"
}

08

ECS 배포 데드락 (maximumPercent=100)

ECS Rolling Update ALB Draining

▶

증상

Force new deployment 실행 시 30분 이상 배포가 진행되지 않음

service was unable to stop or start tasks during a deployment because of the service deployment configuration.

원인

desired=1, maximumPercent=100 설정으로 동시에 최대 1개 Task만 실행 가능. 기존 Task가 ALB 드레이닝(기본 300초) 중이라 종료되지 않아 새 Task를 시작할 수 없는 데드락 발생

해결

maximumPercent=200으로 변경하여 배포 중 새 Task를 먼저 시작한 후 기존 Task를 종료하도록 허용

aws ecs update-service \
  --cluster aws-ecs-cluster-01 \
  --service patient-service \
  --deployment-configuration minimumHealthyPercent=50,maximumPercent=200 \
  --force-new-deployment \
  --region ap-south-2

09

desired=1 설정 후에도 EC2 2대 유지되는 문제

ASG Scale-in Protection Terraform

▶

증상

ASG desired_capacity=1, min_size=1로 변경 후에도 EC2 인스턴스가 2대로 유지됨

원인

lifecycle ignore_changes = [desired_capacity] 설정으로 인해 Terraform이 실제 AWS ASG의 desired_capacity를 변경하지 않음
Task가 없는 EC2도 ECS가 Scale-in Protection(ProtectedFromScaleIn=True)을 해제하지 않은 상태로 유지됨

해결

AWS CLI로 ASG desired 직접 변경 후, Task 없는 인스턴스의 Scale-in Protection 수동 해제

# ASG desired 직접 변경
aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name aws-ecs-asg-01 \
  --min-size 1 --desired-capacity 1 \
  --region ap-south-2

# Task 없는 인스턴스 보호 수동 해제
aws autoscaling set-instance-protection \
  --auto-scaling-group-name aws-ecs-asg-01 \
  --instance-ids i-05e1656fdd41c9207 \
  --no-protected-from-scale-in \
  --region ap-south-2

✓ EC2 2대 → 1대로 정상 축소

10

Wazuh 에이전트 설치로 인한 EC2 4대 연쇄 생성

ECS Auto Scaling Wazuh user_data

▶

증상

ASG desired=1로 설정했음에도 EC2 인스턴스가 4대로 증가하고 ECS Task는 0개인 상태 지속

원인

user_data에서 Wazuh 에이전트를 동기식으로 설치하면서 EC2 시작 시 CPU가 급증 → ECS Task CPU 70% 초과 → Task 스케일 아웃 → EC2 부족 감지 → ASG EC2 추가 → 새 EC2도 Wazuh 설치로 CPU 급증 → 연쇄 반복

EC2 시작 → Wazuh 설치 (CPU 급증)
→ ECS Task CPU 70% 초과 → Task 1→4
→ EC2 부족 감지 → ASG desired 1→4
→ 새 EC2도 동일 반복

해결

user_data에서 Wazuh 설치를 120초 딜레이 후 백그라운드 실행으로 변경 (ECS Task 안정화 후 설치)
ECS Service Auto Scaling의 scale_out_cooldown을 60초 → 300초로 변경하여 EC2 시작 후 안정화 시간 확보

# user_data.sh.tpl 변경
# 변경 전: EC2 시작 시 즉시 동기식 설치
# 변경 후: 120초 후 백그라운드 실행
nohup bash -c "sleep 120 && wazuh-agent 설치..." \
  > /var/log/wazuh-install.log 2>&1 &

✓ EC2 4대 → 1대로 정상화

트러블슈팅 기록