빅데이터라는 시대의 요구에 맞추어 NoSQL이 등장한 지 십 년이 넘는 세월이 흘렀습니다. 하지만, 아직 RDB에 비해서 스키마 설계를 위한 참고 자료가 부족하다고 생각되는데요. 저 또한 MySQL만 사용해오던 백엔드 개발자로서 신규 프로젝트에서 갑작스럽게 MongoDB 스키마를 설계하게 되어 꽤 당혹스러웠던 경험이 있습니다. 저처럼 NoSQL, 그중에서도 MongoDB를 처음 사용하게 된 개발자들을 위해서 빠르게 기본 개념을 훑고 바로 스키마 설계가 가능하도록 도움을 줄 수 있는 글을 써보려 합니다. 그래서 MongoDB를 도대체 왜 쓰는데? NoSQL/MongoDB 이름만 들어본 분들을 위해 특징 및 사용목적을 간단하게만 짚고 넘어가는 게 좋을 것 같습니다. 인터넷 서비스가 점점 많은 곳에 보급되고 ..
안녕하세요. Seller & SD Engineering 팀 박명훈입니다. 기존에는 프로젝트나 기술적인 내용에 중점을 주어 글을 작성했는데 오늘은 내용을 좀 환기하여 개발자의 글쓰기에 대해 이야기합니다. 회사에 와서 2년 동안 개인 위키 페이지 500개 이상을 썼으며, 팀 위키나 개발 문서, 개발 블로그를 운영하며 여러 글을 쓰고 있습니다. 글이나 문서를 쓰며, 신경 썼던 부분 그리고 어떻게 하면 더 글을 잘 쓸 수 있을까에 대해 공부한 내용에 대해 공유합니다. 너무 자세하게 설명하면 내용이 길어질 것 같아 핵심만 작성합니다. 글쓰기는 중요하다. 신입 입사자 혹은 다른 팀에서 어떤 정보를 확인할 때는 문서를 확인합니다. 팀이나 비즈니스를 파악할 때 가장 중요한 요소 중 하나가 문서이고, 문서가 없다면 하나..
카프카와 확장성 카프카를 사용하여 환경을 구성하는 과정에서 확장성이 필요한 서비스를 운영하기 위한 고민이 있었습니다. 일면의 가용성이나 확장성에 대해서는 카프카는 아주 훌륭한 도구였으나 또 다른 측면에서 딱딱하게 구는 부분도 있었습니다. 리파티셔닝과 리밸런싱 카프카가 제공하는 기능의 몇 가지는 파티션이라는 구조를 기반하고 있습니다. 일단 카프카는 기본적으로는 메시지의 순서를 보장하지 않지만 메시지의 순서를 일부 보장하며 해당 순서를 기반으로 commit과 offset을 제공하는 기반은 파티션입니다. 따라서, 파티션에 의해 좌우되는 요소들이 많습니다. 예를 들면 파티션은 메시지의 동시처리의 상한을 만듭니다. 파티션 수 보다 많은 컨슈머의 수는 메시지 처리 속도 측면에서 의미가 없습니다. 더 많은 컨슈머를 ..
안녕하세요. Seller 팀에서 판매자 대상으로 업무를 진행하고 있는 개발자 박명훈입니다. 오늘은 지난 회고록에서 이야기했던 업무에 대해 좀 더 정리해서 이야기해보려고 합니다. 아직까지 부족한 부분이 많지만 나름의 발전 정도라고 생각해주시면 감사하겠습니다. Gmarket과 Auction에서 쓰는 상품 리스트, 상품 상세 페이지에서 사용하는 브랜딩 서비스에 대해 서술합니다. 저는 뒷단의 백엔드 서비스를 담당하여 개발하였습니다. 브랜딩 정책은 비지니스 룰이 많아서 규칙이 까다롭기 때문에 여러 테이블을 조인해서 기준을 판단하며, 요청마다 이러한 테이블을 조인해서 응답을 주게 되면 이는 곧 성능 저하로 연결됩니다. Gmarket과 Auction의 상품에서 브랜드 정보 요청은 모든 사용자들이 사용하므로 많은 요청..
Linger Kafka 에 보면 linger 라는 개념이 나옵니다. 프로듀서가 메세지를 전송할 때, 전송을 위한 통신 오버헤드를 줄이기 위해 메세지를 어느 정도 모아서 보내는 방식입니다. 네트워크 비용은 대체적으로 큰 비용에 속하기 때문에 이를 줄이기 위한 방법입니다. 이 컨셉은 kafka 의 여러 곳에서 등장합니다. 기능만큼이나 성능 측면에서 비용을 낮추기 위해 여러 방안을 사용한 듯 싶습니다. 네트워크 비용만큼이나 비싼 비용은 바로 DB 비용입니다. 특히 RDB 에서는 원하는 목표를 위한 큰 비용을 마주하곤 합니다. 도메인의 특이한 제약은 종종 겪곤 하는데 저도 이번 경우에 몇몇 제약적인 상황 하에 RDB 의 비용을 효율적으로 다뤄보기 위해 linger 전략을 도입한 사례를 소개합니다. Linger ..
Data 모으기 사용할 다건의 data 목록을 마련할 때 상황에 따라 서로 다른 source 에서 조회해야 하는 경우가 있습니다. 예를 들면 data 가 일부 캐싱되는 경우를 들어봅시다. 10개의 data 를 조회하는데 일부는 캐시에서 조회가 가능할지도 모릅니다. 그리고 나머지는 DB 에서 조회해서 채워야 할 것 입니다. 이런 경우 캐시와 DB 라는 두 개의 data source 로 부터 필요한 data 목록을 조회하게 됩니다. 꼭 이런 경우가 아니더라도 우리의 data 아키텍쳐 상으로 여러 이유를 들어 data source 여러 곳에서 data 조회가 필요한 경우는 쉽게 생각할 수 있습니다. Data Source 우선순위 너무 복잡한 상황을 전제하지는 않을 예정이지만 기본적인 요구사항들은 짚어보려고 합..
실패한 작업 가끔 일련의 작업을 하나의 트랜잭션 마냥 수행해야 하는 경우가 있습니다. 분산처리나 분산 트랜잭션 등의 주제라면 또 다른 얘기가 되지만, 좀 더 단순하게 코드 레벨의 문제들을 마주할 경우가 있죠. 각 작업은 실패할 수 있고 하나라도 실패하는 경우 지금까지 수행한 작업들에 실패 처리를 하는 코드를 어떻게 짜면 좋을까요? 일단 하나의 작업에 대해서 실패를 대비하고 실패 시 처리방안을 마련하는 방법은 바로 try-catch 일 것입니다. 그러면 쉽게 생각해서 일련의 작업을 위한 try-catch 를 여러 번 사용하면 되지 않을까요? 중첩 Try Catch 하나의 작업은 다음과 같이 실패를 다룰 수 있습니다. try { // 실패할 가능성이 있는 작업 } catch (Exception e) { //..
After GC, Post GC Memory는 프로그래밍에 꽤 중요하고 기술적인 부분입니다. 만약 독자께서 malloc, calloc, free 등에 어색함이 없다면 더욱 Memory를 다루는 것에 기술적인 특징들을 공감하실 수도 있겠습니다. 그래서 또 Memory를 다룬다는 점은 꽤 신중하고 기교가 높아야 했으며 문제가 복잡해질수록 이 과정에서의 버그나 Side-effect의 해결이 쉽지 않습니다. 이런 고통(?)에 대한 공감은 어렵지 않은 일이죠. 그래서 등장한 것이 바로 Garbage Collection 입니다. Garbage Collection은 무려 1959년에 John McCarthy에 의해 Lisp에서 등장하는 역사를 가지고 있습니다. 벗어나는 이야기지만 Robert C. Martin은 Th..