본문 바로가기

전체 글137

LSM(Log Structured Merge) 아래 두 책에 있는 내용들을 기반으로 LSM(Log Structured Merge) 개념 정리한 글이다. Log 보통 Log 라 하면 애플리케이션에서 무슨 일이 일어났는지 기술한 텍스트를 출력하는걸 말한다. 하지만 여기서 말하는 Log 는 append only 를 의미한다. 그럼 append only 는 무슨 뜻이냐? '데이터 중심 애플리케이션 설계' 책에 나온, 세상 제일 간단한 DB 코드를 보자. #!/bin/bash db_set () { echo "$1,$2" >> database } db_get () { grep "^$1," database | sed -e "s/^$1,//" | tail -n 1 } key 는 num, value 는 json 으로 db_set 을 통해 파일에 저장한다. $ db_.. 2024. 4. 14.
사내 강의(분산 애플리케이션 개발) 후기 시작한 계기 나는 원래 내가 아는 지식들을 공유하는 걸 좋아한다. 그럼으로써 더 깊이 공부하게 되고 정확하게 내 것이 되기 때문이다. 그동안 내가 얼마나 제대로 알고 있는지, 경험했던 일을 내 언어로 잘 표현할 수 있는지를 신경 썼는데 테스트 해보고 싶었다. 그래서 이번 사내 강의를 시험무대로 삼았다. 준비하고 진행하면서 느낀 점 1~2 월 두 달 동안 일주일에 1시간씩, 총 8번 강의를 진행했다. 발표 자료까지는 만들 여력이 없어 오프라인에서 칠판 강의로만 했다. 강의 커리큘럼을 모두 준비한 후 시작한 게 아녀서 주말마다 새로운 강의준비 하늬라 바빴다. 수업 난이도 설정을 위해 연차 설문을 했는데 1~3년 차 주니어 개발자가 제일 많았다. 그렇다고 난이도를 낮추지는 않았고 같은 주제를 한번 더 하는 식.. 2024. 3. 4.
Isolation level 차이에 따른 이슈 공유 이전 글 에서 db transaction 과 isolation level 에 대해서 정리했다. 하지만 이것만으론 실제 개발할 때 뭘 어떻게 신경써야 하는지 바로 이해하기 어렵다. 그래서 isolation level 에 따라 동시성 문제가 어떻게 발생하는지, 다시말해 isolation level 에 따라 lock 결과가 어떻게 달라지는지 예를 들어 설명해 보겠다. 아래 주문서는 오직 하나의 상품만 주문 및 결제가 가능하다. 현실에선 말이 안되지만 문제를 단순화 시키기 위해 그렇게 만들었다. 그리고 브라우저에서 주문서 창을 여러개 띄워서 여러번 결제가 가능한 상황이다. 여기서 우리는 '하나의 주문서로 단 한번만 결제 가능'하도록 만들고 싶다. 상품 table 은 다음과 같다. pk 는 상품 id 이다. 주.. 2024. 3. 3.
트랜잭션 ACID Isolation 트랜잭션은 애플리케이션에서 몇 개의 읽기와 쓰기를 하나의 논리적 단위로 묶는 방법이다. 트랜잭션은 전체가 성공(commit) 하거나 실패(abort) 한다(p222). 트랜잭션 상태에 대해 좀 더 자세히 보자. 트랜잭션이 시작되고(Active) 진행중에 실패하면 Failed 상태가 되고 롤백이 다 끝난 후 Aborted 가 된다. 그리고 데이터를 persist 하는 중(commit 진행중)에 실패하면 Failed 상태가 된다. ACID Isolation 다음은 ACID Isolation 에 대해서 살펴보자. '격리시킨다' 는 말의 의미가 무엇인지 이해하려면 애플리케이션 보다 db 관점에서 봐야한다. 아래 그림처럼 여러 트랜잭션들이 동시에 실행중인 상황에서, interleaving 하는 트랜잭션들을 어떻게.. 2024. 1. 14.
분산 시스템의 골칫거리, 못다한 이야기 '분산 시스템의 골칫거리' 주제로 강의 할 때 gc, tcp, timeout 등 키워드 중심으로만 설명했다. 그러다보니 전체적인 숲에 대한 이야기는 하지 못했다. 왜 그렇게 진행 했을까를 생각해보면 나는 fact 전달에만 집중했던거 같다. gc 나 tcp 같이 기술적인 deep 한 접근은 내가 주는 정보에 이견이 생기기 어렵다(오랜 세월 공고히 발전해온 기술들이니까). 하지만 청자들은 분산 애플리케이션을 경험하면서 겪은 어려움이 구체적으로 뭐였는지 더 궁금했을거 같다. 그 이야기를 하면서, 내가 잘못된 정보를 제공하더라도 일단 설명하고 지적 받으면 정정하면서 나도 같이 성장하는게 맞는 방향이라 생각한다. 분산 시스템이 왜 필요할까? 먼저 왜 필요한지 근본적인 질문에서부터 이야기를 시작해보겠다. 사실 답은.. 2024. 1. 14.
신뢰성 없는 네트워크, asynchronous / 시계 문제 synchronous / asynchronous / blocking / non-blocking 을 어떻게 해석해야 될까? 학계에서도 명확한 정의가 없다. 나는 아래 3가지 관점으로 나눠지는 것을 경험했다. 어떤것도 명확히 정답이라고 볼 순 없지만 개인적으로 1번을 선호한다. 1. synchronous/asynchronous 와 blocking/non-blocking 는 별개 카테고리로 봐야한다. synchronous/asynchronous blocking/non-blocking 2. synchronous 는 blocking 이고 asynchronous 는 non-blocking 이다. synchronous -> blocking asynchronous -> non-blocking 3. asynchronou.. 2024. 1. 8.
신뢰성 없는 네트워크, GC 이야기 데이터 중심 애플리케이션 설계 8장 '분산 시스템의 골칫거리' 에서 GC 이야기가 나온다. 원격 노드가 일시적으로 응답하기를 멈췄지만(가비지 컬렉션 휴지가 길어졌을 수 있다), 나중에는 다시 응답하기 시작할 수 있다(p278). 심지어는 I/O 중단과 GC 중단이 공모해서 지연을 결합하기도 한다(p297). 원문: I/O pauses and GC pauses may even conspire to combine their delays cf) conspire 는 실제로 공모(직역)했다기 보다 두 가지 독립적인 요소가 서로 의도적으로 협력하는 것처럼(비유적 표현) 보이는 상황을 설명하는 데 사용됐다고 보는게 맞을거 같다. 두 가지 지연 요소가 어떻게 시스템의 전반적인 성능에 더 큰 부정적 영향을 미치는지 강조.. 2024. 1. 7.
네이버페이 주문서 시스템 전환 완료 길고 길었던(월 거래액 5조가 넘는 주문/결제 시스템 전환은 정말 오래걸렸다) 신주문서 프로젝트가 드디어 끝났다. 아직 남은 작업들이 존재 하지만 중요한 작업들은 모두 마쳤다. 6월에 8부능선 넘었다고 글을 썼는데 최종 전환까지의 과정은 순탄치 않았다. 다양한 문제가 발생해서 하루에도 몇번씩 운영 배포 하고 모니터링을 계속했다. 눈앞에 결승점이 보이는데 자꾸 넘어져서 앞으로 못간다는 느낌을 많이 받았다. 그래도 그 힘든 과정을 다 이겨내고 끝을 맺을수 있어서 행복하다. 개인적으로 신주문서TF 로 온건 정말 잘한 선택이었다. 더 큰 세상을 경험할 수 있었고 그만큼 나도 더 강해졌다. 그전까지는 5년 정도 플랫폼 조직에서 개발했다(어느덧 벌써 8년차). 플랫폼을 개발 한다는건 아래 그림과 같은 느낌이다. 후.. 2023. 11. 25.
Kafka consumer 와 partition 개수 증가시키기 사용자 트래픽이 높아짐에 따라, 특정 시간대에 Lag 이 쌓이면서 처리 지연이 발생했다. 그래서 consumer 와 partition 개수를 증가시키기로 했고 운영중인 상황에서 증가시키는 순서를 정리했다. 먼저 우리 시스템은 1:1:1 구조로 되어 있다. ex) consumer 서버 5대, producer 서버 5대, topic 의 partion 개수 5개 이제 Kafka consumer 와 partition 개수를 각각 2배씩 증가 시키려고 한다. 먼저 consumer concurrency 를 2로 올린다. 각 서버당 2니까 consumer 는 총 10이 된다. [아파치 카프카 애플리케이션 프로그래밍 p217] partition 을 여러 개로 운영하는 경우 데이터를 병렬처리하기 위해서 partition.. 2023. 11. 11.
WebClient "Only one connection receive subscriber allowed" 에러 아직 정확한 원인은 파악되지 않았고, 기록차원으로 작성했다. WebClient 에서 간헐적으로 "Only one connection receive subscriber allowed" 에러가 계속 발생하는것을 경험했다. 엄밀히 말하면 reactor-netty 에서 에러가 발생한다. Exception:java.lang.IllegalStateException: Only one connection receive subscriber allowed. at reactor.netty.channel.FluxReceive.startReceiver(FluxReceive.java:182) 샘플 프로젝트를 만들고 에러를 재현해서 reactor-netty 에 문의 해봤는데 Spring Framework issue 라는 답변만 줬.. 2023. 8. 15.
MIT 인턴 기술스터디 후기 MIT 대학생들이 여름방학을 맞아 8주간 네이버 체험형 인턴십을 진행했다. 그중 한명(이하 A)이 우리팀에 오게됐다. 왜 FAANG 같은 빅테크 기업에서 인턴을 안하고 네이버로 왔는지 너무 궁금했다. A 는 부모님이 모두 한국에 계셔 겸사겸사 왔다고 했다. 그리고 한국에서 지냈던 시간이 많아 한국말도 잘 했다. 나는 EDA 를 주제로 A 와 1:1 스터디를 진행 했다. 사실 이 스터디에 개인적인 목적은 따로 있었다. 나의 일을 나의 언어로 잘 설명할 수 있는지 테스트 해보고 싶었다. 그래서 8주 동안 내가 개발하고 있는 EDA 를 정리하고 발표했다. 물론 A 의 전공이 수학이고 컴퓨터 수업은 몇개 안들은 상태였기 때문에 주제가 너무 어려울수 있겠다는 생각도 했다. 그래도 우리 시스템에서 발생할 수 있는 .. 2023. 8. 13.
EDA 에서 Event 중복 발행(동시성 이슈) 먼저 spring application 서버는 kafka 메세지를 consuming 하고 producing 하는것을 반복하는 구조다. 왜 Event 가 중복 발행됐는지를 이해하려면, Kafka 이벤트 발행과 DB 저장(redis) 트랜잭션 을 이해해야 한다. 메세지 유실을 막기위해 db update 를 두번하는데 그 과정이 이해 안가면 아래 흐름을 받아들이기 어렵다. 핵심은 9번(redis 에 update) 이 끝나기전, 10번에서 order 가 조회된다는 부분이다. consume 타이밍을 제어할 수 없으므로 결국 reids db lock 이 필요하다. 9번(redis 에 update) 이 끝날 때까지 lock 을 잡고, 10번(order 조회) 을 기다리도록 해서 문제를 해결했다. lock 기능은 s.. 2023. 7. 22.

티스토리툴바