소개
안녕하세요.
실용주의 프로그래머가 되고 싶은 평범한 엔지니어입니다.
- (前) 카카오엔터프라이즈 소프트웨어 엔지니어
- (前) 카카오 Ground X 소프트웨어 엔지니어
강의
전체2수강평
- 수준높은 강의 감사합니다.
강창환
2024.05.07
0
- 쉽게 접하기 힘든 주제의 강의을 접할 수 있어서 좋았습니다. 앞으로도 다양한 주제의 강의를 해주시면 좋을 것 같습니다.
ryuu.public
2024.05.06
0
게시글
질문&답변
2024.05.21
wallet service 구축에서 중복메시지 검증 로직이 필요한지 궁금합니다
안녕하세요~ 질문 남겨주셔서 감사합니다. 카프카 프로듀서에서 enable.idempotence=true 설정을 한다면 멱등성 프로듀서가 되서 중복 메시지는 발행안되는 건 맞습니다. 멱등성 프로듀서의 중복 메시지 제거 기법은 프로듀서 ID 와 메시지 Sequence Number 를 통해 중복을 제거하는데요. 중요한 건 프로듀서 어플리케이션이 새롭게 시작하는 경우 똑같은 프로듀서 ID 를 재발급 받을 수 없다는거에요. 그래서 이건 해당 프로듀서 어플리케이션이 살아있는 세션 내에서만 메시지 발행이 중복이 되지 않습니다. 만약 멱등성 프로듀서 어플리케이션이 메시지를 보내다가 죽은 경우, 다시 재부팅되서 메시지를 보내는 경우에는 두 개의 메시지가 전송되는 케이스는 존재하는거죠. 그래서 엄격하게 메시지 발행을 하나로만 보장하려면 카프카 트랜잭션을 사용해야하는거죠. 물론 현재 저희 어플리케이션에서는 Payment Service 가 트랜잭셔널 아웃박스 패턴으로 메시지를 하나만 발행하고 있기 때문에 메시지는 여러건 발행되지 않으므로 의미는 없긴합니다. 그리고 여담이긴 하지만 저 같은 경우는 일관성이 엄격하게 중요한 어플리케이션에서 하나만 믿고 로직을 작성하기 보다는 불확실한 것들이 있는 경우에는 여러가지 케이스를 고려해서 2차까지 방어 로직을 작성하는 것을 선호합니다. 도움이 되셨으면 좋겠네요. 감사합니다.
- 0
- 1
- 31
질문&답변
2024.05.21
완강!!!!!!!!!!!!!!
축하드립니다~~ 주말에도 열심히 하시는 것 같던데 항상 좋은 결과 있길 바랄게요. 질문도 필요하시면 언제든지 주세요~
- 1
- 2
- 50
질문&답변
2024.05.18
테스트 시 오류
안녕하세요~ 질문 남겨주셔서 감사합니다. 똑같이 따라 한 것 같은데 무결성 제약 조건이 나서 불편하셨겠네요.. 에러 메시지를 보니까 외래 키 제약 조건 위반을 나타내는 것 같네요. 이 경우, ledger_entries 테이블에 데이터를 삽입하려고 할 때 transaction_id 열의 값이 ledger_transaction 테이블의 id 열에 존재하지 않는 값이기 때문에 발생한 것으로 보입니다. ledger_entries 테이블에 삽입하려고 하는 transaction_id 값이 ledger_transaction 테이블의 id 열에 존재하지 않기 때문에 이 에러가 발생한 것으로 보이는데요. 비즈니스 로직이나 테스트 코드 로직을 다시 검토해보시는걸 추천드립니다~ 제 프로젝트에서는 잘되는데 왜 안되는지 모르겠군요..
- 0
- 1
- 70
질문&답변
2024.05.13
실무에서 prefix index를 어떤 요구사항이 있을때 사용하는지 궁금합니다!
안녕하세요~ 질문 남겨주셔서 감사합니다. 먼저, Prefix 인덱스는 꽤 다양하게 사용될 수 있는데요. 게시글 본문 내용을 색인하는 경우 이커머스 플랫폼에서 상품 설명이 저장된 긴 내용을 색인하는 경우 로그 데이터나 사용자의 행동을 기록하는 텍스트 필드에서 색인하는 경우 그리고 다음 질문 주신 내용인 prefix index의 한계점도 일부 맞는 말입니다: Prefix 인덱스는 해당 prefix로 시작하는 모든 행을 먼저 찾은 다음, 실제 데이터를 검색하여 추가적인 필터링을 수행해야 합니다. 이렇게 두 단계를 거치지만 인덱스를 사용하지 않는 경우보다는 빠를거에요. 물론 인덱스 검색도 전체 데이터의 20~25%이상 조회하는거라면 풀스캔이 더 빠르긴 하겠죠. Prefix 인덱스는 ORDER BY 나 GROUP BY 절에서의 정렬이나 그룹화 작업에 효과적이지 않아요. 이건 인덱스가 전체 값을 포함하지 않기 때문에, MySQL이 결과의 정확한 순서를 보장할 수 없기 때문이에요. 커버링 인덱스는 쿼리가 필요로 하는 모든 데이터를 인덱스에서 직접 가져올 수 있을 때 사용되는데요. Prefix 인덱스는 필드의 일부만을 포함하므로, 쿼리가 해당 필드의 전체 데이터를 필요로 하는 경우 추가적인 디스크 접근이 필요하기 때문에 사용할 수 없어요.
- 0
- 1
- 102
질문&답변
2024.05.13
innodb deadlock detect 비활성화 질문
안녕하세요~ 질문 남겨주셔서 감사합니다. 맞아요. 말씀 주신 내용처럼 매우 높은 동시성을 요구하는 환경이 아니라면 굳이 innodb_deadlock_detect=on 을 할 필요는 없습니다. 대부분의 국내 환경도 트래픽이 높지는 않아서 마찬가지일거에요. 대안 방법의 예시로 Redis 를 드셨는데 만약 Update 와 Insert 트래픽이 엄청 많은 상황에서는 고려해볼 수 있는 설정일거에요. 2번 질문 같은 경우는 innodb_deadlock_detect=off 로 했을 경우에 데드락 상황이 발생했을 때 감지할 수 있는 방법이 없으니 innodb_lock_wait_timeout 값을 짧게 줘서 성능 테스트를 해야할 것 같아요. 그리고 필요하다면 max_connections 값도 같이 증가시키는 게 좋을 수 있을 것 같습니다. 근데 이건 단순히 임시적인 조취일 수 있으니 문제가 일어났을 때 근본적인 해결을 찾는게 무엇보다 중요할 것 같네요. 원래는 dead_lock detect 상황을 실습해보려고 했는데 제 생각보다 더 많은 트래픽이 필요하더라구요. 그래서 로컬 환경에서는 진행하기가 어려웠어서 실습을 제외했습니다...
- 0
- 1
- 62