질문:
- 아키텍처 상으로 생각보다 돈이 많이 들지 않았는지
답변:
- 생각보다 돈이 많이 들었다 (한 달에 10만원)
피드백:
- OK
질문:
- Redis Cluster를 어떻게 구성하신건지
답변:
- Redis Cluster를 구성하지는 않았고, Elastic Cache를 구성하고, 이에 대한 Read-Replication을 적용한 상태이다.
피드백:
- 이 부분은 그림을 수정해서 오해를 줄였으면 좋겠다.
질문:
- Grafana 와 Prometheus 를 어떻게 사용하신 건지
답변:
- 부하테스트를 통해 서버의 상태를 모니터링 하기 위해 적용하였다.
피드백:
- OK
질문:
- AWS 설정을 직접 스크립트나 yaml을 사용하여 구성하였는지
답변:
- Github Actions, Secret Key와 Code Deploy를 사용하여 자동으로 Blue/Green 배포를 할 수 있게 하였다.
- yaml을 작성하여 구성하였다.
피드백:
- 테라폼을 사용하여 코드레벨로서 AWS 구성을 관리할 수 있다.
- 이런 구성은 서비스 환경이전에 대하여 유연하게 적용할 수 있다는 이점을 띈다.
- Local 스테이지
- Dev 스테이지
- Integration 스테이지
- QA 스테이지
- Production 스테이지
- 이런 부분은 Pinops와도 연관되는데 — 요즘은 Devops라 안 부르고 Pinops라 부른다 — 궁금하면 찾아보자
질문:
- Jmeter를 사용하여 어떤 단계별 부하테스트를 거쳤는지?
- 아래 테스트를 알고 사용했는지?
- 스모크 테스트
- 새니티 테스트
- ,,,
답변:
- 잘 알지 못 한다,,, 처음 들어봤다,,,
피드백:
- 부하테스트 단계 별로 테스트 목표와 테스트 방법이 다르니 꼭 공부해보길 바란다
- 위 내용을 모르고 부하테스트를 했다고 어필한다면 마이너스 점수를 줄 것 같다
질문:
- 부하테스트 시, TPS를 500초로 잡았는데 그러한 근거가 있는지?
답변:
- 500 TPS에 대한 정확한 근거는 없다.
- 다만, 케이스의 갯수를 제한두지 않고 Infinite Load를 하였기에 500 TPS로 잡았다
피드백:
- 보통 부하테스트에 대한 목표값 측정을 하고 테스트한다
- TPS 500초면 굉장히 널널한 거다.
- 목표값 측정 과정은 공부해보길 바란다
- 목표치 설정에 대한 근거가 없는 부하테스트라면 마이너스 점수를 줄 것 같다.
질문:
- 부하테스트의 시나리오는 어떻게 구성하였는지?
- 왜 Read 하나에 대해서 테스트를 하는지?
답변:
- Auto - Scale 에 대한 개선효과를 추정하기 위해 대표적인 케이스인 전체 상품 조회만을 테스트하였다.
- 각 개선효과에 대한 부하테스트 별, 시나리오를 구성하여 테스트하였다.
피드백:
- 실제 환경에서는 Read만 할 수가 없다. 꼭 여러 케이스들을 조합해서 테스트하길 바란다.
질문:
- Read 와 Write 중 어느 것이 DB의 부하가 많다고 생각하는지?
답변:
- 트래픽 관점으로는 Read가, DB의 CPU 사용률 관점으로는 Write 가 많다고 생각한다.
피드백:
- MySQL 내부적으로도 캐싱을 하기 때문에 Read가 더 빠르다. 따라서 Write가 상대적으로 부하가 높다.
- MySQL 내부 아키텍처 또한 공부를 해볼 것
질문:
- 부하테스트 시, HicariCP의 커넥션 수와 톰캣의 Thread Pool 에서는 문제가 없었는지?
- 기본 HicariCP의 커넥션 수와 이에 대한 커스텀을 어떻게 할 수 있는지 알고 있는지?
- 기본 Tomcat Thread Pool 의 Size가 몇인지,
- 왜 그렇게 구성되는지
- 어떻게 커스텀할 수 있는지 알고 있는지?
답변:
- HicariCP의 커넥션은 10개로 알고 있다.
- Thread Pool의 커넥션은 220개로 알고 있다.
- 둘 다 어떻게 개선하면 좋을지는 고려하지 않았다.
피드백:
- 부하테스트 시, 첫 발목을 잡는 것이 바로 이 둘이다.
- 꼭 왜 그렇게 구성되어있는지, 내부적으로 어떻게 처리되는지, 어떻게 하면 수정하여 개선할 수 있을지를 공부해보길 바란다.
질문:
- 동시성 이슈를 제어하시려고 하셨다 했는데 어떤 시나리오에서 어떤 동시성 이슈가 발생하고, 어떻게 대처하셨는지
답변:
- 상황
- 하나의 입찰에 대한 다량의 동시 주문 요청 케이스에서 데드락 이슈가 발생하였다.
- 해결
- 해당 유스케이스 내에서, 조회 이후 수정,삭제가 이루어지고 있다
- 이러한 이유로 조회할 때 배타적 잠금을 걸어서 해결하였다.
- 개선사항
- 만약 다량의 트래픽이 유입된다면, 다른 스레드가 무한정 대기하여 timeout 이 나는 것을 보았다.
- 이러한 이유로 Redis의 분산락을 통해 개선 예정이다.
피드백:
- OK
질문:
- Redisson을 사용한 동시성 제어를 추후 개선방법으로 채택하셨는데, 다른 방법은 없었는지?
답변:
- 배타적 잠금과
@Retryable사용하여 대처하는 방법
- 이 떄 동일한 스레드를 사용하게 되어 스레드 풀에 반납하지 못 한다
- 따라서 Retry handler에 스레드 풀 사이즈를 배정하여 대처
- 다만 트래픽에 따라 스레드 풀 사이즈가 변경되어야 하므로 스레드 풀 사이즈를 얼마나 정할지가 어렵다.
- 이러한 이유로 Redis 분산락을 채택할 예정이다.
피드백:
- 처음 들어보는 방안이라 낯설다. 다만 나쁘지 않은 방법인 것 같다.
질문:
- 서비스 특성 상, 조회가 굉장히 많을 것 같은데 이에 대해서 어떻게 대처하고 있는지?
답변:
- 프로젝트 시간 상, 상품 데이터 관련하여 캐싱처리만을 하였다.
- 기존에 회의를 통해 캐싱처리 전략을 고려해보았다.
- 이를 기반으로 추후에 다른 데이터 관련해서도 적용할 예정이다.
- (말을 못 하고 지나감) CQRS를 적용하여 조회와 쓰기 트래픽을 분리하였다.
피드백:
- 꼭 적용해서 캐싱 전략에 대해서도 이야기하면서 덧붙이면 좋을 것 같다.
질문:
- myql primary와 secondary간 동기화가 되어있어서 몇초정도는 데이터 정합성이 차이가 날텐데 이럴 때 a 사용자가 게시글을 작성하고 b사용자가 직후에 조회한다면 해당 게시글이 보이지 않을텐데 이럴땐 어떻게 개선할 건지?
답변:
- 두 가지 방법을 고려하여 개선할 예정이다.
피드백:
- 두 방법 모두 그렇게 좋은 접근방법은 아닌 것 같다.
- 아래와 같이 답변하여 비즈니스 적인 측면을 고려하는 개발자임을 어필하는 것도 좋을 것 같다.
질문: