해당 컨텐츠는 주간동안 읽은 아티클 중 일부를 정리한 내용입니다.
Article
HikariCP Maximum Pool Size 설정 시, 고려해야할 부분
지난 주 회사 서버 위클리에서 커넥션 풀 이슈를 공유해주었다. 관련해서 지식이나 경험이 부족한 상태라 해당 아티클을 추가로 찾아보게 되었다.
위 아티클은 save시에 시퀀스 번호 채번을 위해 추가적인 커넥션 점유가 발생하면서 한 요청에서 예상보다 많은 수의 커넥션 점유로 인해 데드락이 발생한 과정을 잘 설명하고 있다.
시퀀스 번호 채번시에도 이미 열려있던 트랜잭션에 속하게 된다면, 시퀀스 채번을 위한 테이블락이 길어져 다른 트랜잭션이 계속해서 기다리게 된다.
이외에도 하카리 커넥션 풀 점유에 대해 쉽게 잘 쓰여져있다. 아직은 개발중인 서비스가 런칭이 되지 않아 비슷한 이슈나 경험이 부족하지만, 런칭이 되면... 다시 읽어볼만한 소중한 글이다.
Better Rate Limiting With Redis Sorted Sets
최근에 대규모 시스템 설계 기초 스터디를 진행하고 있는데 4단원의 참고 문헌중 하나이다. Rate Limiting을 구현하는 가장 널리 알려진 알고리즘은 토큰 버킷이다. 그러나 토큰 버킷은 주기적으로 토큰을 채워넣어야하기에 유저가 많아질수록 쓰기(write) 부담이 있다.
토큰 버킷은 Book 챕터에서 다시 설명한다.
해당 아티클에서는 Redis의 자료구조 Sorted Set을 통해 개선된 방법을 설명하고 있다.
요약하면 타임스탬프를 함께 기록해, 특정 시점부터 얼마나 요청이 있는지를 카운터함으로서 처리율을 제한한다. 요청을 카운터하는 작업과 타임스탬프를 기록하는 작업은 원자적으로 이루어져야하는데 아티클에서는 멀티커멘드를 사용하고 있다. 이외에도 루아스크립트를 통해 레디스 트랜잭션 단위를 묶을 수도 있다.
Lombok 사용상 주의점(Pitfall)
회사에서 주로 kotlin으로 개발하다보니, 대부분 lombok을 사용하지 않았다. 그러다 Java 기반의 공통 모듈에서 작업을 하다 lombok 관련 이슈를 겪었다.
AllArgsConstructor 어노테이션을 활용해 객체를 생성하였는데, 같은 타입의 두 필드가 계속 값이 바뀌어 들어갔다. lombok에 익숙한 개발자라면 금방 찾을 이슈였지만, 필자는 익숙치 않아서 버그를 찾는데 시간이 걸렸다. 만약 api 동작확인을 하지 않고 배포가 되었더라면.. 끔찍한 상황을 마주할 뻔했다.
추가로 lombok에는 setter chaining을 구현해주는 설정도 있더라... (그래도 개인적으로는 setter를 열어놓기보다는 생성자를 통한 객체 생성을 더욱 선호한다...)
Book
대규모 시스템 설계 기초 - 4장 처리율 제한기 설계
4장은 위에서 살짝 언급한 것처럼 처리율 제한기 설계에대한 내용이다. 전 회사에서는 각 서버 인스턴스마다 처리율을 제한해주었는데, 이 방법은 구현은 간단하지만 사실 세부적으로 처리율을 제어하긴 힘들다. 책에서는 클라이언트 사이드의 처리율 제한도 언급하고 있는데 이 방법 역시 해당 클라이언트를 통하지 않으면 물거품이 됨으로, 보조적인 수단으로는 활용하되 독립적으로 사용하기는 힘들어 보인다.
클라이언트 사이드 처리율 제한에 대표적인 예는 카카오톡 이미지 보내기 30개 제한이다.
결국 정교한 처리율 제한을 위해서는 별도의 독립적인 저장소를 이용한 미들웨어 형식으로 구현되어야한다. 책에서는 이러한 처리율 제한기 설계를 위한 몇 가지 알고리즘을 소개하고 있는데 그 중 토큰 버킷과 누출 버킷 두 가지만 살짝 살펴보자
토큰 버킷
토큰 버킷 알고리즘에 대략적인 플로우는 아래와 같다.
- 클라이언트 요청시에 현재 유저에 할당된 버킷에 토큰이 존재하는지 확인
- 토큰이 있다면, 토큰을 제거하고 요청 수행, 없으면 버린다.
- 주기적으로 버킷에 토큰을 채운다.
유저 또는 API 마다 유연하게 토큰 수를 가져갈 수 있으며 구현도 간단해 가장 널리 쓰이는 알고리즘이다.
누출 버킷
- 토큰 버킷과 유사하나 토큰을 사용한 요청은 큐에 들어가 처리율이 고정속도로 제한된다.
- 때문에 안정적으로 출력이 가능하다.
두 알고리즘 모두 토큰을 획득하는 과정에서 경합이 발생할 수 있어 이 부분의 주의가 필요하다.
실용주의 프로그래머 - 예광탄과 프로토타입
같이 일하는 시니어 개발자분이 추천해주신 책으로 시간날 때마다 아주 조금씩 읽고 있다. 이번 주에 읽은 내용중 예광탄과 프로토타입 부분이 인상깊었다.
책에서 애기하는 예광탄과 프로토타입의 가장 큰 차이는 나중에 버릴 수 있는 코드인가, 전체적인 완결성을 가지는가 정도인데, 사실 아직 둘의 차이를 직관적으로 이해가 되지는 않는다.
지금 내가 하고 있는 것은 예광탄인가? 프로토타입인가? 이 둘을 잘 구분해서 상황에 맞게 잘 활용 할 수 있다면 좋은 시니어로 발전하고 있다는 증거가 아닐까..?
