Close Sea

첫 사이드 프로젝트 #


개요 #

내 프로젝트의 간단한 개요를 설명하려고한다. 사이드 프로젝트를 시작하려고 한 참에 단순한 도메인은 싫어서 nft마켓플레이스로 정하고 개발을 시작했다. 프로젝트의 목적은 내가 회사에서 사용해보지 못한 기술을 적용하기 위함이였다(공부의 목적이 제일 컸음)

사실 프로젝트가 어느정도 진행되고 이 글을 작성한다. 기록하는 습관도 없고 구현에만 급급해서 간간히 PR에만 이슈해결을 적었지만, 최근에 계속 설계장벽에 무너지다보니 다시 재설계하는 과정이 많았다. 처음부터 설계를 제대로 하지 않았던 나의 오만이다ㅠㅠ 나름 애자일하게 기능단위로 개발하기로했는데 산을 보지못하고 나무만 보았던것이다. 재설계를 하는과정이 많았기에 내 스스로도 정리가 안되는 부분이 컸다. 이쯤에서 서비스단위로 리빌딩하는 시간을 갖기위해 글을 작성해보려한다.

적용해보고 싶은 기술 #

  • MSA
    • 대규모시스템에 관심을 갖게 되다가 msa 로 설계를 해보고싶다라는 생각은했다, 장애에 대응하기 빠르다는 장점과, 확장성이 크기때문에 채택했다.
    • 회사에서 작은 오류를 수정해도 배포시 빌드,테스트 수행시간때문에 10분이상은 소요해야했다 상당히 불편했던 기억이난다
  • WebFlux
    • 논블럭킹에 비동기라는점이 일단 매력적이게 다가왔다
    • 사실 하드웨어는 한계가 있고, 비지니스는 더 커질거라는 생각에 Reactive Programing을 배워두면 언젠간 좋을거라고 생각했다.
  • R2DBC
    • 회사에서 코루틴을 적용했던 경험이 있는데, JPA가JDBC구현체로 DB에 접근하므로 blocking 방식이라 코루틴의 이점을 제대로 살리지못했다
    • R2도 리액티브 스트림기반이니 webflux 사용하면 이점이 클거라 생각했다.
  • EDA
    • 이 프로젝트의 꽃은 비동기이고 MSA 방식이니 kafka,rabbitMQ를 무조건 사용해야겠다고 생각했다
    • 회사에서 카프카의 경험은 있지만, 통신하는 서버가 외부 클라이언트도 사용하고있기에 아쉽지만 rest API로 통신이 주 였다.
  • SpringCloud
    • MSA 로 개발하기에 다양한 기능들이 포함되어있기에 추후에 사용해보고싶다
    • 회사에서 다른서버와 통신하다가 요청이 실패하는 경우가 종종있었다. 504 게이트웨이가 발생할때까지 스레드를 잡고있었고 에러를 응답받고 다음 로직을 수행할수없어서 센트리에 오류가 찍혔던 기억이있다 당시 예외처리를 해줬지만 해당 이슈를 해결하기위해 찾아보던 와중 기술블로그에 서킷브레이커로 해결하는 글을 보고 스프링 클라우드를 적용해보고싶었다.
  • Flayway
    • 실제 운영환경에서 엔티티 변경시에 DDL을 수동으로 바꿔줘야되는 번거로움이 잦았다. 깜박하고 안바꿔줘서 배포실패가 뜨는점도 잦았다는점 ㅎㅎ;; 변경사항을 자동화하기위해 이번 프로젝트에 적용할생각이다.
  • CQRS 패턴
    • 이 프로젝트에서는 특정 서비스에서 읽기작업이 많을거기에 책임을 분리하여 모델을 분리 할 생각이다.
  • 분산캐시
    • 모든서버에서 의존적인 데이터가 있다. 데이터가있는 서버에서 호출해서 취합하여 반환하려고했는데, MSA에서 특정서버에 의존적이게 설계하는게 맞나라는 의문이 항상있었다. 독립적으로 설계하기 위해 redis를 사용해야되는데, 데이터를 샤딩하여 빠르게 조회할수있도록 redis 클러스터를 사용해보려한다.
  • 카오스 몽키
    • 과연 나의 msa 설계가 문제없게 설계되었는지 테스트를 하기에는 카오스몽키를 적용해는게 좋을거같다라는 생각이든다 특정 서비스에 장애를 일으켜 시뮬레이션을 해볼예정이다
  • JMeter 부하테스트
    • 개인 프로젝트에서 경험할수없는 운영환경에서의 트러블슈팅과정은 매우 중요하다고 생각한다( 사실 운영환경에서 이슈터질때마다 쾌락을느꼈음, 동시성이슈 매우땡큐) 이 사이드프로젝트 어플리케이션이 운영까지는 계획이 없기에, 트래픽별 api 응답시간을 측정하려고한다.

이 기술들이 마켓플레이스를 구축하는데 오버헤드라고 생각하는데 나도 동감한다. 과연 이 기술이 필요한가? 라고 생각한다면 절대적으로 아니다
하지만 프로젝트의 목표는 평소에 사용해보지 못한 기술을 배우고싶기에 위에 나열한 모든 기술을 도입할수는 없겠지만 가능한 많은 기술들을 배우고 적용해보고싶다. 내 기술스택에 추가되는 그날까지

프로젝트를 리빌딩하기 위한 나의 문제점 #

  1. 도메인 지식이 부족

nft 마켓플레이스를 목표로 잡고 개발을 시작했을때, web3에 개념은 알았지만 이렇게 딥하게 들어갈줄은 몰랐다..
스마트컨트랙트가 무엇인지..web3를 사용하면 과연 백엔드에서 구현할부분이 많은가에 대해 고민이 많았던거같다. 단순한 기능개발이 아닌 설계를 하려면 도메인 공부는 필수같다

  1. MSA 설계 고려사항 인지

처음 설계를 시작할때 서비스를 나누는거부터 어려움이 있었다 서비스를 나눌때 명확한 기준이 무엇인가?, 서비스간 의존관계는 어떻게 최소화할것인가? (동기적인 부분), 트랜잭션 관리는 어떻게 할것인가?, 특정 데이터는 어느서비스에 속해야되는것인가? 등등 고민해야될 부분이 컸다. 모든 반환값이 nft데이터가 필요했다 nft가 메인이다 보니 nft데이터를 모든 서비스에 저장하고있어야되는건지, nft데이터가 속해있는 서비스에 요청을 해야되는것인지 그럼 Nft 서비스에 의존이 높아져서 잘못된설계라고 생각했다 MSA에서 좋은설계가 무엇인지 고려사항을 인지하고 개발하는게 좋다고 생각한다. 물론 설계에 정답은 없지만 리빌딩하기위해 꼭 필요하다고 생각한다

  1. 시간에 구애받지 않기

개발을 3개월을 잡고 시작해서 처음엔 공부하면서 재미를 느꼈지만 시간에대한 촉박함을 느끼고 구현에 급급해지면서 서서히 프로젝트의 의미를 잃어버리는 느낌이 들었다. 기능이 제대로 동작하는가에만 초점을 두어서 그런지, 코드도 엉망이고 나중에 리팩토링해야겠다라는 생각만 컸던거같다. 리팩토링은 계속해야되겠지만 좋은코드가 무엇인지 계속 고민하면서 클린코드로 작성할것.