API 1차 개발 끝!

이제 API의 1차 개발은 다 끝나서, 곧 배포만을 앞두고 있는데 개발하면서 느낀점과 서비스의 아키텍쳐에대해 설명해보려고합니다.

Architecture

현재 서비스의 아키텍쳐는 위와 같습니다.

사용자 요청 처리

Extension에서 서버로 요청을 하게 되면, Cloudflare가 요청을 1차적으로 https를 통해 받고 그것을 실제 서버로 보낸 뒤 NginX를 거쳐서 Express에서 요청을 처리하게 됩니다.

NginX, Express, 그리고 ElasticSearch는 각각 Docker 컨테이너에서 구동중이며 Docker Network를 통해 연결되어있습니다.

Express와 ElasticSearch 통신

Express는 사용자가 검색에 대한 요청을하게 되면, JWT를 통한 검증을 끝낸 뒤 ElasticSearch에게 요청을하여 검색 결과를 얻게 됩니다.

Docker 컨테이너 위에서 구동중이지만, network로 연결되어있어 통신이 가능합니다.

CI/CD

CI/CD는 CircleCI를 이용하였습니다.

CircleCI 설정은 이미 velog에 올려져있으며 이 포스트를 참고하시면 좋을 것 같습니다.

어쨌든, 간단히 설명하자면 CI/CD는 아래와 같은 구조로 동작합니다.

• feature 브랜치에 Push
  • CircleCI에서 테스트 진행
• main 브랜치에 merge
  • CircleCI에서 테스트 후 배포 스크립트 실행
  • 배포 스크립트가 실행되면, 서버에서 git을 통해 최신 코드를 pull해오고 docker 이미지를 빌드
  • 빌드 후, 이전 컨테이너를 종료하고 즉시 새로운 컨테이너를 실행

물론 이 배포방식은 무중단이 아니라는 것에 문제가 있습니다만..

저희 서비스의 특징상 새벽시간대에는 많은 사용자가 없을 것이라 판단하였고

사실 컨테이너 종료 및 실행에는 몇 초 걸리지 않기 때문에, 새벽에 merge하여 CI/CD를 실행하게 되면 큰 문제는 없을 것 같다고 생각하였습니다.

만약 문제가 발생한다면, 무중단 배포를 고려해봐야할 것 같습니다.

무중단 배포는 보통 컨테이너를 다른 포트로 하나 더 실행하고 이전 컨테이너를 종료한 뒤 바꾸는 방식인 것 같은데, 그 부분을 한 번 체크해봐야 할 것 같습니다.

테스트 코드 ( TDD )

테스트 코드 작성에서 느낀점은 이미 이 포스트에 언급했으니 간단하게 언급만하겠습니다.

어렵습니다.
정말 어렵습니다.

사실 현업에서의 경험도 없고, 학교 다니면서 동아리 사람들과 프로젝트해본 경험밖에 없어서 더 그럴수밖에 없다는 생각을하지만 정말 생소했던 느낌이라 더 어려웠습니다.

만약 다른 프로젝트를 진행할 때 TDD를하게 된다면, 더 많은 참고자료와 좋은 예시들을 보고나서 그것을 따라갈 수 있도록 공부를하고 진행해야겠다는 생각이 들었습니다.

로깅 ( Logging )

로그는 원래는 그냥 내부에서 log를 파일형태로만 관리했었는데, 그것의 불편함과 에러가 발생했을 때 실시간으로 파악하기 어렵다는 것을 깨달았습니다.

그걸 해결하기위해 Sentry를 도입했고, Sentry는 아주 간편하지만 아주 강력한 도움을 저에게 주고있습니다.

더 자세한 설명은 이 포스트를 참고해주세요!

느낀점

오랜만에 여러 사람들과 팀단위로 진행한 프로젝트라 재미있었습니다.

아직 끝나지않았다는것을 알고 있습니다!

실제 배포이후 겪게될 여러 에러들을 기다리는 중이고.. 그것을 고쳐나가면서 실제 서비스를 개선해나가는 작업을 진행 할 예정입니다.