이노베이션 13주차 - 실전 프로젝트 회고 6 및 마무리

기술적 의사결정

• MSA
  • 모놀리스는 트래픽에 따른 서버증설을 하게되면 필요없는 서비스까지 Scale Out을 하게 됨. 이러한 점은 비용적인 측면에서 비효율적이기 때문에 대용량 트래픽이 예상되는 특정 서비스에 부분적으로 Scale Out이 가능한 MSA를 채택
  • 팀원들이 각자 맡은 도메인에서 자유롭게 아키텍처를 변경할 수 있거나, 자신의 스타일대로 코드를 작성함으로써 독립적으로 개별 서비스 구현이 가능한 점을 고려
  • 하나의 서비스가 스파게티 코드로 만들어지게 되면, 리팩토링 및 특정 서비스 변경시 다른 서비스에 영향이 가기 때문에 의도하지 않은 에러가 발생할 수 있음 MSA는 이러한 점도 최소화
• html,css,js,axios
  • 초반에 리액트로 프론트엔드를 구현하려고 했으나, 난이도와 투자 시간 대비 효율성이 매우 떨어지는 것을 경험
  • 어느 정도 가이드라인만 있다면 보다 쉽게 작성할 수 있는 html,css,바닐라 js를 택했고 백엔드와 통신 및 토큰 관련 처리를 위해 axios까지 채택
• Spring Cloud Eureka, Spring Cloud Gateway
  • MSA 도입으로 로드 벨런서와 게이트웨이 서버에 사용
• JWT
  • 인증 처리와 관련해서 가장 많이 다뤄본 기술이고 회원 인증 쪽에 많은 노력을 들이는 서비스가 아니기 때문에 쉽고 빠르게 구현할 수 있는 점에서 채택
• Jmeter, nGrinder
  • 개발 초기에 간단하게 부하에 따른 성능을 테스트 하기 위해 Jmeter 사용.
  • 서버 배포 후, nGrinder 를 활용. agent로 여러 환경에서의 부하를 직접적으로 주며, 목표한 성능과, 한정된 자원으로 인한 scale-out 과 scale-up 보다 적절히 선택하는데 사용.
• QueryDSL
  • 카테고리와 검색 조건을 포함하는 동적 쿼리를 작성하기에 기존 jpql은 복잡한 코드를 작성해야하기에 좀 더 직관적인 QueryDSL을 도입
• Apache Kafka
  • 입찰,낙찰,결제, 총 3 가지의 이벤트를 발행하여 다른 마이크로서비스로 전파하는 데이터 스트리밍 플랫폼이 필요. 이 중 카프카는 비동기 처리가 기본이고, 분산 처리가 가능하다는 점에서 성능적으로 우수할 것이라 기대했고 안정적이며 현업에서 많이 사용되기 때문에 이를 활용
  • 이벤트 도메인의 경우 쿠폰 발행 서버의 부담을 줄이기 위해 대기열 서버 도입. 이때 대기열 서버와 쿠폰 서버간의 비동기 데이터 통신으로 사용. Redis Pub Sub 은 메세지의 유실 가능성이 있고, Redis에 pub sub 까지 한다면 Redis 의 성능 저하가 우려되어 이를 활용.
• Prometheus,Grafana
  • Prometheus 를 통해 마이크로 서비스 에서 뽑아온 메트릭을 수집하고, 이 메트릭 정보들로 Grafana 를 사용해 정보들을 시각화 함. 그로 인해 각 서버의 자원들을 모니터링하며 서버를 보다 안정성 있게 구현할 수 있도록 도움을 주기 위해 사용.
• Zipkin,Micrometer
  • 각 서비스마다 개별적으로 배포되는 MSA의 특성상 병목지점, 장애발생 지점들을 확인하기 까다로울 것이라고 판단. 효율적인 MSA를 위해서는 이러한 단점을 보완하기 위해 분산추적이 필수적이라고 생각했고 ZIpkin의 UI가 직관적으로 로그들을 확인할 수 있고 추가적인 정보들까지 얻을 수 있기 때문에 채택.
  • Spring Sleuth는 Spring Boot 3.x 부터는 지원되지 않기 때문에 Micrometer 사용
• Resilience4j
  • 일반적으로 분산 아키텍처에서 한 서비스에 장애가 발생하면 다른 서비스에게도 해당 장애가 연쇄적으로 전파. 이러한 전파는 기존의 서비스에 영향을 주게 되며 결과적으로 서비스의 장애 내성을 낮춤. 비록 지금은 작은 프로젝트라서 장애내성을 갖추고 사용자에게 최적의 응답을 제공해줄 수는 없지만 이러한 이 후 서비스의 확장 및 수정을 생각한다면 미리 장애 내성을 갖춘 서비스를 만들고자 했음
  • 따라서 서비스 간의 통신에서 발생할 수 있는 장애들에 대해서 사용자에게 최적의 응답성을 보장할 수있도록 CircuitBreaker 패턴을 구현.
  • Hystrix 와 Resilience4j 중, Hystrix는 사실상 Deprecated 처리가 된 기술이므로 경량화가 된 Resilience4j 채택
• MySQL
  • 가장 많이 사용해본 RDB. 설정도 쉽고 다루기도 편하다는 점에서 DB와 관련된 개발 시간을 단축시길 수 있을 것이라 기대했기 때문에 활용
• Redis
  • 동시에 많은 요청이 들어오게 되면 DB에 부하 발생 → 이를 방지하기 위해 DB가 처리할 수 있을 수준의 트래픽만 순차적으로 전송하기 위해 Queue로써 사용
  • In-Memory DB이므로 속도 측면에서 우수한 성능을 발휘
  • 요청을 Queue에 적재함으로써 동시성 확률 저하의 이점
• GitHub Action / Docker
  • 여러 사람이 함께 개발을 진행함에 있어서 OS, 환경에 구애받지 않고 동일한 개발, 배포 환경을 구축하기 위해 Docker 사용
  • 개발 환경과 배포 환경의 일관성을 유지하고 각각의 도메인의 확장성과 독립성을 보장해줄 수 있음
  • 도메인 서비스의 배포 자동화를 통해 코드 변경사항을 자동으로 배포하고 통합할 수 있는 파이프라인 구축을 위해 Github Actions 사용

---

프로젝트 담당 역할

- 상품 데이터 수집

- 전반적인 MSA 설계 및 요구사항 정립

- 모놀리스에서 로깅, Dto, 경매 입찰 기능 구현

- 모놀리스에서 Junit, Mockito를 활용한 Test 코드 작성

- MSA에서 Junit,Mockito를 활용한 Test 코드 작성

- Jmeter를 활용한 동시성 제어

- 경매 도메인 등록/조회/입찰/낙찰 기능 구현

- 스프링 AOP를 활용한 로깅

- Zipkin, Micrometer를 활용한 분산추적 기능 구현 및 배포

- Resilience4j를 활용한 CircuitBreaker 패턴 구현

- 소프트웨어 아키텍처 변경

- 경매, 상품의 카프카 메세지 Producer, Consumer 구현

- 상품 상세 조회 Front-End 구현

- 경매 조회/낙찰 Front-End 구현

- 중간, 최종 프로젝트 ppt 작성 및 발표

---

마무리

6주 간의 프로젝트가 마무리 되었다. 공부하고 새로 알게 된 것들을 잘 정리하면서 완성하고 싶었지만, 생각처럼 잘 되진 않은 것 같다. 다만 새롭게 시도해본 것들, 알게된 것들을 위주로 짤막하게나마 꾸준히 쓰려고 하면서 해당 개념들에 익숙해지고 다시 또 접하게 되더라도 헤메지 않고 빠르게 원하는 답을 찾을 수 있도록 기록하는 과정은 꽤 열심히 했던 것 같다.

 

최대한 MSA에 대해 완성도 있게 해보고 싶었기에 각자의 역할을 배분하여 프로젝트를 진행했었다. 그런 과정에서 서로가 하고 싶어하는 분야가 겹치기도 했지만, 보다 여러 문제들에 대해 관심이 있던 나는 이번 기회에 아키텍처에 대해서 깊게 공부해보고자 트래픽 처리를 양보했었다. 팀 프로젝트를 진행하면서 가장 크게 느꼈던 점은 결국 프로그래밍을 하는 주체도 사람이기에 많은 대화와 배려, 양보가 필수라는 점이다. 단순히 개인적 욕심을 고집하게 되면 이번 프로젝트도 지금처럼은 완성되지 못했을 것 같다. 어떤 상황이든 긍정적으로 바라보려하는 내 성격이 마냥 낙관적으로 상황을 방치하는 게 아니라, 팀원 간의 소통, 대화에 있어서 진전을 이끌어내고 프로젝트를 진행하는 데 있어서 큰 역할을 한 것 같다고 생각했고, 이러한 부분에 대해서도 팀원들이 고마움을 많이 표현해줘서 내가 오히려 더 고마웠던 것 같다.

 

사실 이번 프로젝트는 여러 문제들을 핸들링하는 과정이었기에 자칫하면 스코프가 커져서 제출 기한 내에 완성되지 못할 수도 있겠다는 생각이 간혹 들었었다. 뿐만 아니라 내가 정말로 잘 할 수 있을까라는 자기 의심과, 겨우 이 정도로 만족하고 싶지 않다는 욕심이 서로 부딪혀서 6주 동안 잠도 잘 못 자면서 노력했던 것 같다. 지금에서야 돌이켜보면, 모든 욕심이 해소되지는 않았지만, 나에 대한 의심은 차츰 없어졌던 것 같다. 결국 처음에 내가 가졌던 마음처럼 새롭게 배우는 것에 대해서 놀라워하고 재밌어하는 게 원동력이었다. 많은 기술적 시도와 접근들을 경험할 수 있었던 것도 이번 프로젝트에서 얻어갈 수 있는 점들이었지만, 쉽지 않은 과제에 직면하게 되었을 때 어떤 태도, 자세로 해당 문제들을 대할 것인가를 직접 느낄 수 있었던 게 이번 프로젝트에서 얻어갈 수 있는 가장 좋았던 점이다.

 

길지 않게 잠깐의 휴식기를 가지고 여태까지 내가 배워왔던 것들은 무엇이고 앞으로는 어떤 방향으로 나아갈 지에 대해 고민해보는 시간을 가져보고 싶다. 6주동안 정말 노력했고 잘 해낸 나 스스로에게 박수를 보내면서 이번 이노베이션 캠프를 마무리지어보고자 한다. 그 동안 만났던 팀원들, 기술 멘토들, 그리고 지원해준 많은 사람들에게 감사하다고 말해야겠다.