얼마전에 두더지씨의 메세지가 모두에게 잘 못 간 적이 있어요 🥲 광역질문을 테스트하던 중 실수로 모두에게 이메일을 날리는 실수를 범했는데요. 더위를 먹었었나 봐요. 미안해요. 지금은 모든 문제가 수정 되어서 앞으로 이런 실수는 없을거에요. 🙃 제발.

정말 반가와요 여러분. 오랜만의 Mr.두더지 질문이에요. 기나긴 장마 끝에 곧 해가 찾아 올까요? 두더지는 땅속이 너무 습하게 젖어서 너무 힘든 나날을 보내고 있어요. 🥲 여러분은 여름휴가 계획 잡았나요? 더지팀은 아직 마땅한 여름 휴가지를 정하지 못했어요. 성수기 가격이 워낙 비싸서 엄두가 안 나기도 하고.. 익명의 두더지들은 어떤가요?

주문서 경험 개발한 기분 이었습니당 좋은 밋업 열어주셔서 감사해요!!!!!

마스터 디비로 Insert/Update를 하고 난 뒤 읽기전용 슬레이브 디비에서 Select하는 시나리오를 몇차례 말씀해주셨는데요. (1. 쓰기, 2. 읽기, 3. 복제) 한 어플리케이션 내에선 Insert/Update를 했을때 변경이 반영된 현재 열(row)에 대한 최신변경해시를 응답하고, Select한 열의 최신변경해시와 일치하지 않으면 다시 Select해오는 전략은 어떻게 생각하시나요? 물론 여러 열에 대해서는 조금 다르게 해야하겠지만 단일 열에 대해선 괜찮지 않을까 싶어서요. (책읽다말고 생각나서 적어서 책 어딘가에 적힌 내용일 수도 있겠네요)

제가 속한 조직에서는 같은 서비스를 운영하더라도, 사용하는 장비 수를 줄이는 것이 가장 큰 목표 중에 하나여서 컨테이너 기반의 어플리케이션은 생각하기 어렵고 서버 렉을 (어느 정도는) 고려하며 베어메탈 장비에서 프로세스를 직접 띄우는 경우가 대부분입니다. 페이 서비스를 예시로 들어주실 때 이런 부분을 잘 느끼지 못하였는데, 혹시 가용할 수 있는 리소스의 양은 현재로서는 크게 고려되지 않는 상황인가요? (k8s 환경에서 비용 절감을 어떻게 할 수 있는지 궁금해서 여쭤봅니다)

pod 이 오토스케일링 될 때 웜업이 되지 않아서 장애를 키웠다고 하셨는데요 Consumer Group에 Consumer가 포함되는 시점을 웜업이 끝난 이후로 컨트롤 할 수는 없는 건가요? 이런 게 불가능한 상황이 존재하는 걸까요?

제가 들어본 메시지큐가 Kafka랑 RabbitMQ 있는데, 혹시 두 가지 또는 Kafka 외 메시지큐랑 비교를 해보셨을까요? 그렇다면 Kafka를 선정하게된 이유가 있을까요?

혹시 부하측정을 따로 할 수 있는 상황이었는지 궁금합니다! 100배 개선이라는 수치를 언급해주셨던 것 같은데 어떻게 계산되었던 것인지 궁금합니다.

확장성을 위해 카프카를 없애고 레디스만 사용하는 방법으로 가는 선택지는 힘들까요???

파티션 증가와 컨슈머 증가(pod 늘리기) 가 동시에 되지 않으면 의미없다고 말씀하신 것 같은데(맞을까요?!), 컨슈머만 늘려도 처리량이 늘어나게 되니까, 유의미한 시도였을 것 같은데, 파티션 증가까지 꼭 같이되어야 하는 이유가 궁금합니다!