[ DevOps ] - AWS 기반 대규모 아키텍트 설계 - (인프라) 마이크로 아키텍처 개발 시 문제점들

처음 마이크로서비스 도입할 때 겪은 문제점들

우선 모놀로식을 배포할 때는 그냥 하나의 코드 뭉테기를 배포하면 끝이였습니다. 하지만 마이크로 서비스는 이를 하기 위해 상당히 복잡한 프로세스 + 오랜 시간이 필요하게 됩니다. 그리고 에러가 났을 때 Debugging하기가 매우 힘들어집니다. 왜냐하면 이미즐 업로드 하는 과정에서 에러가 났다고 해 봅시다. 그럼 이게 이미지 업로드 하는 서비스 내부의 코드 문제인지, 아님 다른 서비스와 소통할 때 발생하는 문제인지 알 수가 없게 됩니다.

 

그래서 디버깅을 해서 에러를 잡아내기 위해서는 수십개의 서비스의 로그파일을 확인해야 합니다. 그리고 너무 서비스가 거대해서 한 눈에 알아볼 수 없습니다.

 

CI/CD 도입

CI/CD란 빌드 -> 테스팅 -> 배포의 모든 과정을 자동화 하는 것을 말합니다. 대부분의 회사가 테스팅이 제대로 안됩니다. 테스팅은 대부분 기획자가 짜게 되는데, Consisting시나리오만은 개발자가 짤 수도 있습니다. 

 

CI/CD의 중요한 점은 코드 변경사항을 주기적으로 빈번하게 머지해야 하는 것입니다. 왜햐하면 조금조금씩 해나가야 그만큼 오류를 찾기도 쉽기 때문입니다.

 

이러한 CI/CD를 위한 서비스는 Jenkins, circleci, Codepipeline...등이 있는데, 우리는 Codepipeline을 통해서 이 모든 과정을 자동화 해보겠습니다.

 

깃헙의 마스터 브랜치에 커밋하고 푸쉬하면, 이 코드가 자동적으로 빌드되어 테스팅되고, .. 이런식으로 자동화를 하게 됩니다.

 

로그 수집

앞에서도 말했듯이 마이크로 서비스 안에서 방대한 로그파일들을 다 확인할 시간이 없습니다. 따라서 저희는 S3, Glacier와 같은 대용량 파일을 저장할 수 있는 서비스에다가 모든 로그를 때려박습니다. 그래서 무조건 시간 순서대로 S3에 한 폴더에 다 때려 박아야 하는 겁니다. 그 후에, MYSQL에 올려야 합니다. 쿼리문을 날려서 저희가 찾고 싶은 에러부분을 찾아야 하기 때문입니다.

 

또한 Critical Event를 설정해 놓습니다. 이 이벤트가 찍히면 우리 서비스에 큰 타격이 생긴거다 라는 의미로요. 그리고 이를 Slack과 같은 업무 서비스와 연결해서, 모든 사람이 알게 할 수 있습니다.

 

다음시간부터는 여기서 살펴본 문제점을 CodePipeline을 통해서 직접 해결해 보겠습니다.