도롱뇽 닮은 개발자

스프링 개발자라면 Controller-Service-Repository 3계층 구조가 익숙하다. 프로젝트 규모와 관계없이 3계층 구조는 기본적으로 고려하는 대상이 되고 있다. 하지만 내가 생각했을때 로직 넣어도 된다고 생각한다.의미 없는 간접층// UserService.javapublic User getUser(Long id) { return userRepository.findById(id);}Repository 호출을 그대로 전달하는 것뿐이다. 일관성 있는 계층 구분을 하기 위한 코드라고 생각된다. 근데 이렇게 까지 해야하나?.. 싶기도 하다."어차피 분리할 거" 논리의 문제"나중에 복잡해지면 분리해야 하니까 처음부터 분리하자"는 주장이 있다.이건 예측 기반 설계다. "이 기능은 복잡해질 것이다"..

개요MySQL에서 쿼리가 인덱스를 제대로 활용하고 있는지 확인하는 방법을 정리한다. Buffer Pool 히트율, Handler 지표, EXPLAIN 결과를 통해 현재 상태를 진단할 수 있다.Buffer Pool 히트율 확인InnoDB는 자주 사용하는 데이터를 메모리(Buffer Pool)에 캐싱한다. 히트율이 높을수록 디스크 I/O 없이 메모리에서 데이터를 읽는다는 의미다.상태 확인SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';히트율 계산SELECT (1 - (Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests)) * 100 AS buffer_pool_hit_ratioFROM ( SELECT ..

문제 상황출결을 미리 생성 해놓는 기능을 개발하던 중 데드락이 발생했다. 여러 수업(lesson)에 대해 출결(attendance) 기록을 병렬로 INSERT하는 로직이었다. 성능을 위해 메인 스레드에서 수업 데이터를 조회하고 출결 INSERT는 별도 스레드 풀에 위임하는 구조였다. lesson 테이블에서 SELECT ... FOR UPDATE로 특정 레코드들을 조회하면 해당 레코드에 X락(배타락, 쓰기 락)이 걸린다.이 상태에서 attendance INSERT를 별도 스레드에 위임하면 문제가 발생한다. attendance 테이블의 lesson_id 컬럼이 lesson 테이블을 FK로 참조하고 있기 때문에, INSERT 시 MySQL이 "참조하는 lesson 레코드가 존재하는지" 확인하려고 S락(공유락,..

개념이 모호한 게 있어서 정리해본다.1. Shared Lock 으로 인한 쓰기 지연 문제MVCC는 결국 Shared lock(S락)의 한계점을 보완하기 위해 나왔다. S락은 말 그대로 공유할 수 있는 락이다. 동시에 읽기는 가능하지만, 내가 읽고 있는 동안 남이 '쓰기'는 불가능하다는 게 핵심이다. S락은 내가 읽는 동안 아무도 쓸 수 없게 막는것이다. 문제는 데이터의 정합성이다. T1에서 읽고 있는 row를 T2에서 수정(커밋 혹은 커밋 되지 않은 데이터를 읽기)할 수 있게 되면 데이터의 일관성이 깨질 수 있다. 정합성을 맞추기 위해 S락을 걸어버리면 읽기 작업이 쓰기 작업을 방해하게 되어 성능 저하가 발생한다. 이런 문제를 해결하기 위해 등장한 것이 MVCC다. MVCC는 데이터를 수정할 때 원본을 ..

상황학교 다닐때 출석부를 보면 출석 기록들이 이미 빈값으로 등록 되어있다. 비슷한 맥락으로 수업일마다 출결 기록을 초기화하는 배치 작업이 필요했다. 이 때 Failover를 위해 서버 2대를 운영 중이었고, 모든 서버에서 동일한 배치 로직이 실행되고 있었다.문제다중 서버 환경에서 출결 데이터를 생성할 때, 서버 간 동일 데이터에 대한 락 경합과 중복 처리 문제를 해결함과 동시에, 향후 추가될 다양한 배치 작업들에서도 동일하게 적용 가능한 일관된 병렬 처리 방법을 생각해서 시스템의 처리 효율과 데이터 무결성을 확보해야 한다.해결 방안 비교선택지 1: 유니크 인덱스가장 단순한 방법으로, 중복 삽입 시 DB 레벨에서 차단된다. 하지만 중복 INSERT 쿼리가 계속 발생하므로 불필요한 DB 리소스가 소모된다. ..