질문 & 답변 & 피드백
김준영 튜터님(카카오헬스케어)
질문:
•
아키텍처 상으로 생각보다 돈이 많이 들지 않았는지
답변:
•
생각보다 돈이 많이 들었다 (한 달에 10만원)
피드백:
•
OK
질문:
•
Redis Cluster를 어떻게 구성하신건지
답변:
•
Redis Cluster를 구성하지는 않았고, ElastiCache를 구성하고, 이에 대한 Read-Replication을 적용한 상태이다.
피드백:
•
이 부분은 그림을 수정해서 오해를 줄였으면 좋겠다.
질문:
•
Grafana 와 Prometheus 를 어떻게 사용하신 건지
답변:
•
부하테스트를 통해 서버의 상태를 모니터링 하기 위해 적용하였다.
피드백:
•
OK
질문:
•
AWS 설정을 직접 스크립트나 yaml을 사용하여 구성하였는지
답변:
•
Github Actions, Secret Key와 Code Deploy를 사용하여 자동으로 Blue/Green 배포를 할 수 있게 하였다.
•
yaml을 작성하여 구성하였다.
피드백:
•
테라폼을 사용하여 코드레벨로서 AWS 구성을 관리할 수 있다.
•
이런 구성은 서비스 환경이전에 대하여 유연하게 적용할 수 있다는 이점을 띈다.
◦
Local 스테이지
◦
Dev 스테이지
◦
Integration 스테이지
◦
QA 스테이지
◦
Production 스테이지
•
이런 부분은 FinOps와도 연관되는데 — 요즘은 Devops라 안 부르고 FinOps라 부른다 — 궁금하면 찾아보자
질문:
•
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를 적용하여 조회와 쓰기 트래픽을 분리하였다.
피드백:
•
꼭 적용해서 캐싱 전략에 대해서도 이야기하면서 덧붙이면 좋을 것 같다.
이성국 튜터님
질문:
•
mysql primary와 secondary간 동기화가 되어있어서 몇초정도는 데이터 정합성이 차이가 날텐데 이럴 때 a 사용자가 게시글을 작성하고 b사용자가 직후에 조회한다면 해당 게시글이 보이지 않을텐데 이럴땐 어떻게 개선할 건지?
답변:
•
두 가지 방법을 고려하여 개선할 예정이다.
◦
메세지 큐를 사용하여, 어플리케이션 레벨에서 더욱 빠른 비동기적 동기화를 진행
◦
캐싱 테이블에 선행적으로 저장하여 더욱 빠른 조회를 하게 할 예정
피드백:
•
두 방법 모두 그렇게 좋은 접근방법은 아닌 것 같다.
◦
메세지 큐
▪
관리 허들이 높다
▪
큐로 처리되기 때문에 오히려 성능이 저하될 것 같다
◦
캐싱 테이블
▪
관리사항이 높아지고
▪
오히려 데이터 정합성이 깨질 가능성이 높다
•
아래와 같이 답변하여 비즈니스 적인 측면을 고려하는 개발자임을 어필하는 것도 좋을 것 같다.
만약, 데이터의 정합성의 차이를 최대한 줄여야한다면 스케일업을 하여 조금 더 빠르고 정확한 데이터를 제공할 수 있습니다.
다만, 저희는 비용적인 측면에서 ~초 정도는 비즈니스적으로 허용하게 하였습니다.
,,,
질문:
•
왜 offset 기반 페이지네이션을 채택하셨는지?
답변:
•
큰 단점이 없다고 판단하였다.
•
offset 기반으로 선 적용한 뒤, 추이에 따라 cursor 기반 페이지네이션을 적용할 예정이다.
피드백:
•
cursor 기반에 비해 offset 방식은 이점이 크게 없다.
•
현업에서도 이러한 이유로 거의 cursor 기반을 채택하고 있다.
•
페이지네이션에 대해서 많이 물어보니 이 부분은 꼭 공부했으면 좋겠다.
이력서
김준영 튜터님(카카오헬스케어)
•
진짜 Contribution이 아니라면 잔디를 보여줄 때 Contribution이라고 적지 않는 게 좋을듯
•
몇 달씩 비어있는 잔디를 보여주는 것은 그렇게 메리트가 있다고 생각되지 않음
•
기술스택에 대해서는 버전을 꼭 명시할 것
◦
해당 버전에 대해서 아래 사항에 대해 답변 준비할 것
▪
해당 버전을 왜 채택했는지
▪
이전버전과의 차이점
▪
버전만의 특정 기술을 사용한 부분
•
블로그 내의 내용들을 자신있게 말할 수 있어야 함
◦
까먹지 말고, 어디서 복붙한 것들은 최대한 올리지 말 것
•
프로젝트의 주요 개발 내역에 대해서, “~API” 사용했다라고 쓰기보다 더욱 구체적인 개발사항을 서술할 것
•
강조하고 싶은 내용은 Color를 사용해서 강조할 것
◦
그렇다고 너무 많은 것을 Color를 사용해서 강조하지 말 것
•
꼭 구체적인 수치를 최대한 많이 보여주자
•
읽는 사람으로 하여금 더욱 친절하게 — 아마 수치와 디테일한 사항들을 저술하라는 것 같다 — 적어줬으면 좋겠다.
◦
하루에 50건씩 들어온다.
공부가 더 필요한 부분이 뭐라고 생각하는가
임지훈
•
솔직히 아키텍처 관련해서 CI/CD 정도만 공부하려 했는데 정말 중요하구나 생각들어서 깊게 공부할 생각
◦
인강을 듣거나 손수 만들어봐야겠다
•
AWS를 사용하지 않고 직접 구현해도 무관한 것들은 반드시 공부해야겠다
◦
서버비를 아끼는 개발자를 어필할 수 있지 않을까 실제로도 이런 개발자가 지혜롭기도 하고
•
스프링 내부의 기본기를 탄탄히 해야겠다는 생각이 들었다.
◦
스레드 풀
◦
히카리
◦
어떤 흐름으로 트랜잭션 메서드가 호출되어 하나의 스레드가 부여되고, 실행되는지
•
캐싱에 대해서도 공부를 해보고 싶다
◦
캐싱 메모리 전략
◦
데이터 정합성
•
이력서와 면접, 특히 알고리즘과 CS 공부를 좀 더 탄탄히 해야겠다
•
동시성 제어 관련하여 비관적 락보다 분산락을 채택했을 때의 이점을 공부하고 싶다
•
MySQL 내부구조와 MHA 방식도 공부해야겠다
•
Offset 기반 페이지네이션과 Cursor 기반 페이지네이션 또한 공부해야겠다
추가적으로 궁금한 사항들은?
임지훈
•
CQRS 패턴에서 꼭 모델을 나눠야 할까
•
추가 질의응답 관련해서 적절한 답변을 한걸까
◦
특히, CQRS 모델 분리여부에 대한 질의응답에 대해 궁금하다
◦
모델 분리를 고려해야하는 이유와 우리가 이를 채택하지 않은 이유
•
무중단 배포 다른 효율적인 방법 ?
배포전략 종류와 Blue/Green 의 장점에 대해서 잘 설명해주셨습니다.
- 다만 Blue/Green 의 경우 서버 배포시 해당 노드에서 운영중인 서버의 2배 리소스를 일시적으로 사용한다는 단점이 있는데요.
- 이때 노드당 리소스 사용량 제한에 의해 Green Pod 가 리소스 할당을 받지 못할 수 있습니다.
- 그부분도 인지하고 넘어가면 좋을 것 같습니다.
•
쿠폰 코드레벨 더 효율적인 관리 ???
쿠폰의 종류가 엄청나게 많아질 것이기 때문에 ENUM으로만 확장성을 대응하기엔 어려워 보입니다.
- 다만, 결재 상세내역에 어떤 쿠폰인지 연관관계를 남겨놓지 않고 쿠폰이름과 할인가격만 남기는것도 괜찮은 방법이긴 합니다.
- 우리 서비스에서 쿠폰 도메인이 얼마나 중요하냐에 따라 다를 것 같네요.
•
