전체 글139 [논문분석] MOSIQS 와 GSM(Group Split and Merge) 논문에서 소개 하는 MOSIQS 는 Persistent Memory(이하 PM) 에서 사용하는 객체 저장소 프레임워크다. PM 은 비휘발성 메모리로 인텔과 마이크론과 같은 회사들이 개발한 3D XPoint, 그리고 MRAM 등이 있다. MOSIQS 는 PM pool 위에 메모리 객체를 저장하고 접근할 수 있는 집합 메모리 풀을 제공함으로써 과학적 계산을 가속화한다. cf) MOSIQS 는 "Persistent Memory Object Storage with Metadata Indexing and Querying for Scientific Computing" 의 줄임말이다. 경량의 PM kev-value 저장소를 사용해서 메모리 객체의 메타데이터를 관리하고, 수백만 개의 메모리 객체에 대한 메타데이터 검색.. 2024. 5. 4. 개인 리뷰(2023)와 새로운 도전 개인리뷰2023년은 신주문서 프로젝트를 끝낸 해였다. 그러다 보니 동료 리뷰에는 좋은 얘기밖에 없었다. 나 또한 그동안 고생한 게 떠오르면서 좋은 얘기만 하게 되더라. 동료 리뷰에서 나에 해당하는 상위 키워드는 열정, 협력/기여, 공유/피드백 이었다. 아래 동료 피드백 일부를 가져왔다. 너무 좋은 말로 포장해 줘서 부끄럽긴 하지만 열심히 했다는 걸 인정받은 기분이다.동료 피드백 결과분명 귀찮을 수 있는 일이지만, 업무 공유 시 상대방이 100% 완전히 이해하여 습득할 수 있도록 지원을 아끼지 않으십니다. 덕분에 신주문서 유지보수에 필요한 지식을 더욱 빠르게 많은 유관부서에 전파할 수 있게 되었습니다.프로젝트 진행중 논의가 필요한 부분을 구조적으로 이해하여 팀원들에게 적극적으로 공유하십니다.커뮤니케이션을 .. 2024. 5. 1. 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 로 온건 정말 잘한 선택이었다. 더 큰 세상을 경험할 수 있었고 그만큼 나도 더 강해졌다. 그전까지는 4년 정도 플랫폼 조직에서 개발했다(어느덧 벌써 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. 이전 1 2 3 4 ··· 12 다음
