MSA 전환 시점

안녕하세요 오늘님! 어려운 질문이네요 😄말씀해주신 것처럼 성능적인 이유나, 비즈니스 로직마다 적합한 기술 스택이 다른 경우 등 MSA를 도입할 이유는 다양합니다.하지만 개인적으로는 강의에서도 언급했듯이 도메인과 데이터가 가장 중요한 기준이라고 생각합니다. 조금 더 구체적으로 말하자면, 비즈니스가 성장하면서 데이터의 생명주기(데이터가 생성되고, 성장하고, 다른 데이터와 연결되는 흐름)가 명확히 구분되기 시작할 때가 MSA 전환을 고려(도입이 아닌!) 해볼 시점이라고 봅니다.이 시점이 오면 도메인별 데이터의 성장 속도나 방향이 달라지면서, 한 도메인의 변화가 다른 도메인에 영향을 주거나 개발/배포 과정에서 병목이 생기기 쉽습니다. 예를 들어 한 서비스의 작은 변경 때문에 전체 배포를 미루거나, 다른 개발자의 작업까지 영향을 받는 상황이 반복된다면 분리를 고려해볼 신호라고 생각합니다.그리고 개발 외적이지만 팀의 규모와 MSA 전환에 대한 구성원 간 합의 수준도 중요한 요소라고 생각합니다.MSA는 단순히 모듈 수만 늘어나는 것이 아니라, 각 서비스마다 별도의 설정, DB, 배포 파이프라인, 모니터링 체계 등이 필요해지고, 모듈 간 협업을 위한 개발자 간 커뮤니케이션 비용도 생깁니다.관리 포인트가 단순히 두 배가 아니라, 실제로는 세~다섯 배 이상 늘어나게 됩니다.그래서 팀 규모가 이런 복잡도를 감당할 수 있는지 (유지보수를 쉽게 하려고 분리했는데 정작 담당할 사람이 없는 상황이 생기지 않을지) 고민해봐야 합니다.그리고 어떻게 도메인을 분리할지에 대한 팀의 공감대가 형성된 시점에 전환을 고려해보는 것이 좋습니다. 아직 성숙하지 않은 서비스에서 각각의 도메인에 대한 정확한 이해 없이 성급히 분리하면 나중에 차라리 다시 합치는 게 낫겠다는 생각이 들 수도 있습니다.결론적으로는 분리로 인한 오버헤드를 감안하더라도 도메인과 데이터의 성장 관점에서 분리가 필수적이라는 확신이 팀 내에서 충분히 공유된 시점에점진적으로 정말 필요한 도메인부터 분리해 나가는 게 좋다고 생각합니다.

로드밸런싱 관련 질문

안녕하세요 etdong님,고객이 존재하는 실제 서비스 환경에서는 로드밸런서를 보통 처음부터 두는 경우가 많습니다. 단순히 트래픽 분산을 위한 용도뿐만 아니라, 가용성을 위해 보통 서버를 최소 2대 이상 두기 때문에 자연스럽게 로드밸런서를 두게됩니다.로드밸런서를 사용하면 여러 장점이 있는데, 예를 들어 SSL 처리가 간편해집니다. HTTPS 연결을 위해 각 서버마다 인증서 설치/설정을 해야하는 불편함이 있는데, 로드밸런서에 인증서를 설정해두면 뒷단 서버는 로드밸런서와 HTTP로 통신할 수 있습니다. (개별서버에 일일이 인증서를 설치하고 관리할 필요가 없어서 편리합니다.) 또, 서버가 한 대뿐이더라도 로드밸런서를 앞단에 프록시로 두고 시작하면 나중에 서버를 여러 대로 확장할 때 구조 변경이 훨씬 유연하다는 장점도 있습니다.꼭 L7 로드밸런서가 아니더라도 DNS나 L4 수준의 로드밸런서도 실무에서는 상황에 맞게 조합해서 사용되기 때문에, 트래픽이 많지 않더라도 어떤 형태로든 로드밸런서가 초기 설계에 거의 필수로 들어가는 편입니다.

도움 되었어요!

강의가 도움이 되었다니 다행입니다!공부하시다가 궁금한 점이나 더 깊이 알고 싶은 부분이 생기면 언제든 질문 남겨주세요~감사합니다!

멱등성. '같은 요청'의 기준?

안녕하세요, akakakak님.말씀해주신 것처럼, 기존 필드의 조합만으로는 동일한 요청인지 정확히 판단하기 어려운 경우가 많습니다. 그래서 API를 설계할 때 멱등성을 보장하는 대표적인 방법은 클라이언트가 요청 시 고유한 키를 함께 보내도록 하는 것입니다.이 외에도 시스템의 상태를 기반으로 멱등성 여부를 판단하거나, HTTP 메서드의 특성을 활용해 별도 처리가 필요 없는 방식도 있습니다.클라이언트가 요청에 고유한 키를 함께 보냄 (멱등성 키)예를 들어, 결제가 중복되지 않도록 하고 싶은 경우 클라이언트가 요청을 보낼 때 고유한 키(예: UUID) 를 만들어 함께 전송할 수 있습니다.서버는 이 키를 기준으로 중복 요청 여부를 판단해, 이미 처리한 요청이라면 다시 처리하지 않습니다.보통 서버는 이 키를 Redis 같은 캐시에 저장하고, 일정 시간 동안 유효하도록 설정해두는 경우가 많습니다.(이 방식은 10강 '서버와 서버 간 통신' 마지막 부분에서도 언급되니 참고해주시면 좋습니다.) 상태 기반 처리현재 시스템이 가진 데이터의 상태를 DB에서 확인해서 이를 기준으로 중복 요청 여부를 판단할 수도 있습니다.예를 들어, 주문을 '배송중'으로 업데이트하는 API에서 주문 123번이 이미 '배송중' 상태라면, 같은 상태로 변경하는 요청이 들어왔을 때 중복 요청으로 간주해 처리하지 않을 수 있습니다. 서버의 동작이 HTTP 메서드의 멱등성 의도에 맞게 구현HTTP 명세에서 PUT, DELETE, GET 등의 메서드는 같은 요청을 여러 번 보내도 같은 결과가 나와야 한다는 멱등성을 가진 요청입니다. 이 의도가 서버 API에 정확히 구현되어 있다면, 별도 처리 없이도 자연스럽게 멱등성이 보장될 수 있습니다.예를 들어, S3 같은 오브젝트 스토리지에 파일을 업로드할 때 'PUT /file1'처럼 같은 경로로 파일을 여러 번 업로드하더라도 기존 파일을 덮어쓰기 때문에 결과는 항상 같습니다.모든 API가 멱등성을 반드시 보장해야 하는 것은 아니므로,API의 역할과 도메인 특성을 고려해 필요한 경우에는 위 방법들 중 적절한 방식을 선택해 적용해줄 수 있습니다.