<aside> 💡

만들어보고 싶은 서비스 구현하는 MSA 기반의 개발 놀이터

</aside>

🌊 의식의 흐름

1️⃣ Why MSA?

• 알바를 하면서 느꼈다.

  • 서비스마다 사용량과 중요도는 엄청 다른 것 같다.
  • 어떤 기능은 트래픽이 몰리고, 어떤 기능은 거의 사용되지 않는다.

• 이 차이를 동일한 구조로 처리하면 비효율적이다.

  • 트래픽이 많은 기능 때문에, 트래픽 적은 기능까지 같이 확장해야 한다.
  • 중요도가 낮은 기능의 장애가 전체 서비스에 영향을 줄 수 있다.

• 이래서 MSA를 쓰는건가? MSA 공부해봐야겠다.

  • MSA
  • 특정 기능을 선택적으로 Scale-out할 수 있어서 유용하겠다.
  • 서버 간 통신이 필요해진다.
    • 여러 마이크로 서비스로 분리하면, 복잡한 기능은 여러 서버를 거쳐야 한다.
    • 생각만 해도 순탄치 않을 것 같다.
  • 그래서 비동기 이벤트 구조를 같이 쓰는 경우가 많은가보다.
    • 동기 방식에 비해, 서비스 간 결합도를 낮출 수 있다.
    • 장애 전파를 줄일 수 있다.
    • 재시도 전략으로 안정성을 높일 수 있다.
  • 근데 신경 써야되는 사항이 많다.
    • 일단 여러 서버를 거치는 트랜잭션을 고려해야 한다.
    • 이벤트 송수신 자체에 문제가 생기는 경우를 대비해 따로 보장을 해줘야 한다.
    • 서버별로 다운되면 어떻게 할지 전략을 짜야한다.

• 부담이 있지만 설계만 잘 되면, 모놀리식 구조보다 운영상 이점이 많을 것 같다는 생각이 자꾸 든다.

  → 학습 겸 그냥 만들어버려.

2️⃣ Why Hexagonal?

• 이벤트 플랫폼으로 실무 단골인 Apache Kafka를 쓰려고 했다.
• 근데 노트북이 카프카까지 쓰기는 어려운 성능이다.
  • 돌아는 간다. 발열이 마그마급일 뿐..
  • DIP로 추후에 전환하는 것까지 고려하고, 일단 비교적 가벼운 Redis Stream을 써보기로 했다.
• 이벤트 스트림까지 써야하는 상황에서 Layered가 좋은 구조 맞을까?라는 생각이 들었다.
  • 진짜 스프링 처음 배울 때, 스프링의 강점이 기술을 바꿔끼우기 쉬운 거라고 했다.
  • 바꿔끼우긴 쉬운거 같은데, 바꿔끼우려면 정작 바꿔끼우는 기술용으로 새로 구현해야 하는 느낌?이다.
• 진짜 최소한으로 기술을 바꿔끼울 수 있는 방법을 찾아봤다.
  • Hexagonal Architecture
  • 기술을 완전히 자유롭게 교체할 수 있는 것은 아니다.
  • 하지만 Layered 구조에 비해 유지보수 시 변경의 영향 범위를 줄일 수 있을 것 같다.
• 확실히 복잡하긴 하다.
  • 근데 Layered 구조보다 비즈니스 로직과 외부 기술을 더 명확하게 분리할 수 있다.
  • 확장성과 유지보수 측면에서 더 유리하다는 생각이 든다.

3️⃣ DB를 서비스별로 분리했는데, 꼭 다른 서버의 DB를 참고해서 처리해야되는 경우에는 어떻게 해야할까?

• 트래픽이 몰리는 상황에서는 동기로 통신하면 서비스가 느려지는 상황이 발생할 수 있다.
  • 스레드, DB 커넥션 같은 자원들이 빨리 회전되지 않을 거다.
  • 실시간성이 필요한 데이터가 아니라면, 비동기가 성능상 이점이 되는 이유 같다.
• 변동성이 낮은 데이터는 읽기용 모델을 두고, 변경이 있으면 비동기적으로 같이 변경해주면 된다.
• 만약에 실시간성이 중요한 데이터라면?
  • 비정규화로 데이터를 갖고있거나,
  • 캐시를 활용해야할 것 같다.

4️⃣ 추후의 DB 분산까지 고려할 때, 도메인 모델의 ID는 어떻게 부여하는게 좋을까?

• MSA조차 오버엔지니어링이긴 하지만, ID까지 고려하는건 더 오버인 것 같긴 하다.
  • 고민만 해보는 걸로.
  • 분산 ID 생성 전략