☁️ 뭉게뭉게 클라우드

[Cloud | Deepdive| 트러블슈팅] 1차 프로젝트에서 겪은 험한 것 Deepdive

우주수첩 2025. 6. 27. 01:36
728x90

지금부터 1차프로젝트를 하면서 겪은 험한 것들에 대해 썰을 풀어드립니다. 
사실 별 거 없음. 다들 처음 하면 겪는 것들이긴 한데
 
그래도 꼬 
 
 

 

#1 VPC + ALB + EC2 연동 트러블 슈팅

 

# 플로우 희망편

(1) 클라이언트 브라우저 / 외부 사용자
       |
       |  HTTP 요청 (port 80)
       ▼
(2) ALB (인터넷 공개, 퍼블릭 서브넷에 위치)
       ├─ 보안 그룹: 80, 443 열림 (0.0.0.0/0)
       └─ 리스너: 80 → 타겟 그룹 포트 8080 으로 포워딩
       |
       ▼
(3) 타겟 그룹
       ├─ 대상: EC2 인스턴스 (IP or 인스턴스 ID 기준)
       └─ 포트: 8080
       |
       ▼
(4) EC2 인스턴스
       ├─ 위치: 퍼블릭 or 프라이빗 서브넷
       ├─ 보안 그룹: ALB 보안 그룹에서 8080 포트 허용
       └─ Spring Boot 서버가 8080에서 실행 중
       |
       ▼
(5) Spring Boot 서버
       └─ `/health`, `/actuator/health` 등 헬스체크 엔드포인트 제공

 
1차 프로젝트를 진행하면서 네트워크 구조 희망편은 위와 같았는데요 
분명 희망을 현실로 구현했는데 통신이 계속 안되고 타임아웃이 되거나 연결이 안되는 거 있죠. 
심지어 ALB 헬스 체크가 계속 비정상이 뜨는 거에요. 
 
아 이건 문제가 있다. 내가 ALB 대상 그룹을 잘못 설정했던가. 내 잘못이다. 
생각을 하고 
 
이 무슨 일인가. 하여 하나하나 찾아보기 시작했습니다. 
 

 

일단 ALB 생성 정보를 확인 해봤습니다. 

  • VPC : 목표 VPC와 일치. 
  • 리스너 규칙 : 80 / 443 접근 가능
  • 대상 그룹 : public subnet에 있는 인스턴스 (올바름)

암만 봐도 잘 해써.. 난 실수한 게 없쒀.... 난... 난...ㅠㅠㅠㅠㅠ
 
혹시 상태검사 경로를 잘못 적었나..? 했는데
잘적었듬. 너무 잘 적었음. 
 
 
 

분명 오늘 EC2 인스턴스 보안그룹도 깔끔하게 최소 권한 원칙 맞춰서 ALB에서 들어오는 인바운드만 허용되게 해 놨는데
왜 왜 왜 왜 왜 왜 왜 왜 안돌아가지..?
왜 인스턴스가 그러지...?
나 건든 적 없는데?
라는 굴레에 갇혀있다가
 
 
또 다른 자아의 내가 EC2 인스턴스 보안그룹을 건들였는가 하여 확인을 해 보니...
 
다른 팀원분께서 말 없이 보안그룹 규칙을 변경하셨었었섰섰었섰습니다....
 

그럴 수 있어~ 우린 모두 초보니까~ 해결했으니 되었어~
 

여럽훈?

타임아웃이 뜬다? 504가 뜬다?

일단 보안그룹을 확인하십쇼. 

 
 

 
다음날에 디코에 공지 한번 깔꼼하게 때리고 나니
이후에는 보안그룹 이슈 생긴 적이 없습니다.
너무 힘든 것. 
 
 

 

#2 CloudWatch - Ec2 모니터링 로그 추출 불가 

CloudFront (프론트) - Route53 - S3

  ↳ ALB - EC2 (Spring Boot) - CloudWatch Agent
                    ↳ 로그 수집 (out.log)
                    ↳ 로그 전송 to CloudWatch 로그 그룹(route33-logs)

 
위와 같은 환경에서 스프링 서버 어플리케이션이 돌아가고있는 EC2 인스턴스에서 로그를 수집해서 cloudwatch로 보내려고 하는데 
도통 수집이 안된다는 연락을 받아 같이 확인하러 갔단 말이죠. 

 

설정 확인 최종 체크리스트

  • [x] EC2 퍼블릭 IP + IGW 연결
  • [x] EC2 Outbound 443 허용
  • [x] 로그 그룹 이름 정확 (route33-logs)
  • [x] 로그 스트림 이름 정확 (route33-ec2 or {instance_id})
  • [x] 로그 파일 존재 + 읽기 권한 + 디렉터리 x권한
  • [x] CloudWatch Agent 실행 중 (systemctl status)
  • [x] curl <https://logs.ap-northeast-2.amazonaws.com> 성공

위와 같은 체크리스트를 기준으로 왜 로그 수집이 안되는지 파악을 하고자 했습니다. 
 

결론만 말하자면

CloudWatch Agent가 로그를 업로드하려면:
로그 파일은 읽기(r) 가능해야 하고 해당 파일이 있는 디렉터리는 x 권한으로 들어갈 수 있어야 함

권한문제였습니다. 

 
 
CloudWatch Agent는 아래와 같은 단계로 로그를 수집한다고 하는데요

  1. file_path로 설정한 경로("/home/route33/apps/out.log")에 접근
  2. 해당 디렉토리를 탐색해서 log 파일을 찾아 열기
  3. 이후 로그 파일을 읽고 변경 사항을 감지

 
이때 디렉터리 접근 권한이 없으면:

  • 에이전트가 파일이 존재하는지조차 확인하지 못함
  • 에러 로그는 뜨지 않고, 로그 업로드도 안 됨 

이런 상황이 벌어지게 됩니다. 
 
 
 
그래서 해결을 어떻게 하느냐 권한을 주면 되는겁니다

sudo chmod +x /home/route33
sudo chmod +x /home/route33/apps

 
Agent가 파일을 찾을 수 있게 디렉토리에 x권한을 부여해서 접근 가능 상태로 만들어주며
 
해결합니당
 
 
끗. 
 
 
 

728x90