질문 & 답변 & 피드백

김준영 튜터님(카카오헬스케어)

질문:

• 아키텍처 상으로 생각보다 돈이 많이 들지 않았는지

답변:

• 생각보다 돈이 많이 들었다 (한 달에 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사용자가 직후에 조회한다면 해당 게시글이 보이지 않을텐데 이럴땐 어떻게 개선할 건지?

답변:

• 두 가지 방법을 고려하여 개선할 예정이다.
  • 메세지 큐를 사용하여, 어플리케이션 레벨에서 더욱 빠른 비동기적 동기화를 진행
  • 캐싱 테이블에 선행적으로 저장하여 더욱 빠른 조회를 하게 할 예정