mindlantern

안녕하세요 gunsung53님.말씀하신 상황은 일반적인 좋아요/싫어요 기능보다는 사용자가 좋아요를 연속해서 누를 수 있는 리액션 기능에 가까운 것으로 이해했습니다. 이런 경우에는 짧은 시간 동안 많은 쓰기 요청이 발생할 수 있고, 사용자는 현재 수치를 준실시간으로 확인하길 원하기 때문에 말씀해주신 것처럼 Write-behind 전략이 잘 어울리는 사례로 보입니다.“DB에는 언제 저장하는 게 좋을까?”에 대한 기준은 결국 서비스가 어느 정도 데이터 유실을 감당할 수 있느냐에 따라 달라질 것 같습니다. 예를 들어 말씀해주신 인스타 라이브 같은 케이스는 정확한 숫자 자체보다는 “실시간으로 좋아요 수가 올라가는 느낌”이 더 중요할 수 있습니다.그래서 장애가 발생하더라도 “1~2초 정도의 유실은 감당 가능하다” 혹은 “몇백 건 정도의 좋아요 수 차이는 감안한다” 정도로 기준을 정하고 운영할 수 있습니다. (어디까지 허용할지는 비즈니스적으로 결정해야 하는 부분인 것 같습니다. 만약 인프라적인 제약이 있다면 Kafka 지연이나 DB 부하 상황을 보면서 정책을 조정하기도 합니다.)Kafka에 어떤 메시지를 보내는지에 따라 DB에 flush 하는 전략은 달라질 수 있겠지만, <ul><li>이벤트가 1000건 이상 쌓이거나</li><li>최대 2초가 지나면</li><li>좋아요 증가량(delta)이 일정 수준 이상 차이나면</li></ul>flush 하는 전략을 사용할 수 있습니다. (보통은 batch size 조건과 flush timeout 조건을 OR로 조합해서 많이 사용합니다)좋은 질문 감사합니다 😊

캐시전략 - Write-behind

안녕하세요 KMC님, 정합성이 중요한 데이터를 어떻게 신뢰성 있게 관리할 수 있을지, 그리고 그 고민을 어떻게 프로젝트 설명에 녹여낼 수 있을지를 질문주신 것으로 이해했습니다.&nbsp;포인트나 금액같이 민감한 데이터의 경우, 정합성을 어떻게 지킬지나 정합성이 틀어졌을 때 어떻게 감지하고 복구할 수 있을지에 대한 고민이 매우 중요합니다. 스프링 배치를 사용한다고 하셨는데, 배치 실행 정보는 스프링 배치의 Job/Step 관련 테이블들로 관리되어서 이를 활용하면 자동 재시도 등을 통해 어느 정도 정합성을 보장할 수 있겠죠.하지만 배치 로직 자체에 문제가 있어 정합성이 깨진 경우 (예를 들어 특정 유저에게 포인트가 누락된 경우)를 파악하기는 어렵기 때문에 이런 경우에는 말씀해주신 대로 로그 테이블을 만들어 포인트 지급 이력을 남기는 방식을 고려할 수 있습니다. 다만 지속적으로 대량의 로그를 테이블에 쌓는것이 좋은 방식일지 한 번 고민해보면 좋습니다. 데이터 관리 측면에서 부담이 될 수 있기 때문에 파일로 관리하거나 ELK와 같은 로그 수집 시스템과 통합하는 방식, 로그 데이터를 일정 기간만 보관하는 방식 등을 함께 고려해볼 수 있습니다. (배치가 이벤트 기반으로 동작하고, 이벤트 자체로 집계를 재수행할 수 있는 구조라면 굳이 지급 이력 로그를 별도로 남기지 않아도 될 수 있습니다.) 결국 중요한 것은 정합성이 틀어진 경우에 어떻게 보정할 수 있을지 대비책이 마련되어 있는지입니다.&nbsp;정리하자면, 왜 로그 테이블이 필요했는지, 그리고 실제로 어떤 문제가 발생했고 로그 테이블을 활용해 어떻게 정합성을 복구했는지를 설명한다면, 신뢰성을 확보하려는 고민이 드러나는 좋은 자소서 소재가 될 수 있을 것 같습니다.

유저 별 포인트

안녕하세요, minseok5167님.많은 분들이 궁금해하실 부분인데 강의에서 언급을 안했었네요! 좋은 질문 남겨주셔서 감사합니다.&nbsp;실무에서 성능 목표는 인프라 제약보다는 사용자나 비즈니스 요구사항에 맞추어서 설정하는 경우가 많습니다. 물론 인프라 제약도 고려하기는 하지만, 성능이 크게 떨어지는 수준이 아니라면 인프라는 추후 수평확장 등으로 대응할 수 있기 때문에 목표치 자체를 결정짓는 주요 기준은 아닌 경우가 많습니다.&nbsp;개인적으로는 공부를 위한 프로젝트라면 성능 목표치의 숫자 자체보다는, 성능을 측정하고 병목을 찾아 개선하는 과정을 경험하는 것이 더 중요하다고 생각합니다.물론 프리티어를 사용해서 성능 테스트를 해볼 수는 있지만, 사실 CPU 1개, 메모리 1GB 정도로 리소스가 너무 제한적이다보니 부하를 주었을 때 CPU, 메모리, 디스크가 모두 바빠져서 어떤 자원이 병목인지 정확히 확인하기 어렵습니다. 이런 경우에는 성능 테스트를 해도 유의미한 결과를 얻기 어려울 수 있습니다.그래서 가능하다면 성능 테스트를 진행할 때만이라도 프리티어보다는 조금 더 성능이 좋은 (병목을 확인할 수 있을 정도의) 서버 환경에 배포해 테스트해보는 것을 추천드립니다. 병목을 발견하면, 해당 서버 스펙은 그대로 유지한 채 병목 지점을 개선한 후 다시 테스트해보는 방식이 좋을 것 같습니다.&nbsp;그리고 덧붙이자면, 성능 테스트 결과는 수행한 방법이나 환경에 따라 수치가 크게 달라질 수 있기 때문에, 성능 테스트 결과를 작성할 때 이를 상세하게 함께 적어두면 보는 사람도 환경을 감안해서 성능 테스트 결과 수치를 더 잘 이해할 수 있을 것입니다.&nbsp;

인프라 관련 질문

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

MSA 전환 시점

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

로드밸런싱 관련 질문

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

도움 되었어요!

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

mindlantern

Posts