[트러블 슈팅] ECS 클러스터 안의 서비스간 네트워크 연결 불가

글을 시작하기 전에 짧게 배경을 설명합니다.

필자의 인프라 지식과 경험은 아래와 같습니다.

- [On-premise] 서버 이중화 구성 & 운영 경험 O
- [AWS] EC2 기반의 Elastic Beanstalk 구성 & 운영 경험 O
- [AWS] ECS 운영 경험 O EKS X
- [AWS] VPC, 보안그룹, 인바운드 규칙에 대한 이해
- Docker 에 대한 이해
- MSA 개발에 대한 이해 O MSA 인프라에 대한 이해 X
- 그리고 이 정도로 거대한 규모의 인프라는 처음 만져봄

저는 9/1 일 신생 PG 회사로 이직하면서 모기업의 승인&정산 업무를 배정받았고, 이전 담당자는 퇴사가 예정되어 있었습니다. 이 글을 쓰는 시점에 이미 퇴사하신
승인/정산은 어느 회사에서나 가장 민감한 도메인 중 하나이고, 그 중에서도 본사의 트래픽은 업계 탑 이었습니다.
하지만 외주에 개발을 의존하고 있었고, 전임자는 팀장급의 도메인 지식에 보안 업무까지 할 정도로 인프라 실력자이신 분이었기에 상당한 부담이 되었습니다.

 

이슈의 시작

본사의 정산 시스템 어드민을 통해 정산 마감한 데이터가 필자 회사의 정산 시스템의 어드민에서는 보이지 않는다.

처음 CS 가 들어왔을 때는 어디 서버를 말하는 것인지도 모르겠고, 내가 AWS 권한이 있긴 한가? 조차 몰랐습니다.
저는 이럴 때 일단 업무 흐름도를 그립니다. 이하의 글에서는 접두사로 시스템을 구분합니다.
본사 정산 시스템 settlement / 필자 회사의 정산 시스템 ksettlement 

그림을 그리고나니 확인할 포인트가 보이기 시작했습니다.

 

settlement-scheduler 에서 ksettlement-interface 로 signal 이 전송되었는가?

본사의 정산 마감 처리는 성공 했습니다. 따라서 db 기록은 남았을 것이라고 생각했고 정상이었습니다.
서버의 전송 기록을 확인해야되는데 아쉽게도 datadog 과 같은 모니터링 툴이 설치되어 있지 않아 cloudwatch 로 봐야 했습니다.

개발 소스 분석을 통해 로깅을 남기는 부분을 확인하고, settlement-scheduler 에서 signal 전송 성공 로그를 확인했습니다.

 

ksettlement-interface 에서 settlement-interface 를 통해 데이터를 가져왔는가?

실패 로그를 찾았습니다! 이것을 통해 문제를 추정할 수 있었습니다.

• ksettlement-interface 와 settlement-interface 구간에 문제가 있다.
• 로깅 간격이 매우 짧은 것을 볼 때 네트워크 이슈가 의심된다.

 

하지만 이상한 점도 있었습니다.

• settlement-scheduler 는 왜 성공으로 기록한거지?
  settlement-interface 로 전달했다는 것만으로 역할을 다 한 것인가?
• 그렇다면 settlement-interface 는 왜 재시도를 하지 않은거지? 
• choreography 패턴이라고 보기에는 예외 처리/복구 전략이 너무 빈약하지 않나..?

 

추가 확인 과정에서 알게 되었지만 개발단의 버그가 있었습니다.

• 네트워크 이슈는 특정 에러코드로 기록하고, 재시도 대상에서 제외합니다.
  저는 네트워크 이슈도 재시도 해야된다고 생각합니다.
• 실패한 트랜잭션임에도 불구하고 settlement-scheduler 는 정상 건으로 기록하는 버그가 있었습니다.

 

어쨋든 네트워크 이슈도 확인해야 될 것 같습니다.

보안을 위해 많은 정보를 가렸지만 컨테이너 이름이 다르고, VPC/서브넷/보안 그룹은 모두 같음을 확인할 수 있습니다.

사실 여기까지 보고 네트워크도 문제 없네 라고 생각했습니다.
하지만 ECS 와 Fargate 에 대한 이해가 부족하니 확신이 없어 좀 더 찾아보고 있었습니다.
그러던 중 운 좋게도 오늘부터 메가존 엔지니어 분들이 상주 지원을 한다는 사실을 떠올리고 바로 물어보러 갔습니다.

서로 다른 서비스는 서로 다른 fargate 에 올라가 있는 것이다.
따라서 보안그룹에서 자기 자신을 호출하는 인바운드 규칙이 있어야 한다.

저 같은 경우가 종종 있는지 바로 눈치를 채시더라구요..!
다시 확인해보니 8080 의 인바운드 규칙이 있긴 하지만 211 대역인 것을 보면 테스트를 위해 임시 등록한 것 같습니다.
분명히 이 부분도 봤다고 생각했는데 포트만 보고 간과했습니다.. ㅠ

보안그룹에 8080 포트를 인바운드 규칙으로 추가하고 이슈를 해결했습니다!

 

마치며

중간이 많이 생략되었지만 처음에는 prod 환경이기에 네트워크를 의심하지 않았고, 완전히 다른 흐름을 보는 실수를 하기도 했습니다. ECS 지식이 부족했기에 중요한 포인트를 찾지 못해 헤맨 것도 있구요.
해결하고 나니 창피할 정도로 쉽고 당연한 것이었네요.

기성 대기업이었다면 담당자가 따로 있었고 관련 확인이 완전히 위임 됩니다.
업무의 분리와 집중이라는 관점에서는 좋지만, 상대적으로 느리고 전체 업무 흐름에 대한 이해도가 떨어지게 됩니다.

지금 제가 다니는 회사는 트래픽은 업계 상위권이지만 스타트업의 성격으로 일하고 있습니다.
그렇기에 구성원에게도 AWS 권한이 있고, 다행히도 인프라 기본 지식이 있었기에 직접 트러블 슈팅할 수 있었습니다.
들어온지 얼마 안되었음에도 이렇게 전체 흐름에 관련된 이슈를 처리할 수 있어서 보람차고 꽤 재미있는 경험이었습니다!
devops 님.. 어서 와주세요.. 제발..