개발놀이터

오랜만에 제가 좋아하는 데이터베이스 분야에서 신기술이 나왔습니다. 처음엔 영상으로 접했는데 그냥 AWS에서 신기술 냈구나 정도로 생각했지만 계속 영상을 보면서 흥미를 가질 수 밖에 없었습니다. Serverless RDBMS라고? 이게 무슨 혼종이지? 싶었죠. 오늘은 AWS Aurora의 후속 버전, 클라우드 데이터베이스의 미래 AWS Aurora DSQL에 대해서 공부한 내용을 정리해보는 포스팅을 작성해보려고합니다. AWS의 클라우드 데이터베이스 역사AWS는 처음엔 RDS를 선보였습니다. 이는 단순히 오픈소스로 되어있는 데이터베이스 엔진을 이용해서 RDBMS를 구축한 것에 불과했죠. AWS RDS를 시작으로 점점 사용자들은 다양한 니즈가 생기기 시작했습니다. 2009년에 RDS가 선보인 것을 시작으..

MSA 사고실험 첫번째 포스팅인 데이터베이스 설계에 이어 두번째는 Kafka를 유연하게 설계해보았습니다. 보통 MSA에서 이벤트 기반 아키텍처를 설계할 때 카프카를 주로 사용하게 되는데 카프카에 대한 이론적인 내용보다 설계에 초점을 맞추게 되다보니 두 가지 관점에서 카프카를 바라볼 수 있을 것 같습니다. 바로 쓰기 연산이 주를 이루는 애플리케이션과 읽기 연산이 주를 이루는 애플리케이션 이렇게 두 가지 관점에서 볼 수 있을 것 같은데요. 보통 쓰기 연산에 부하가 많이 가는 채팅앱, 읽기 연산이 자주 일어나는 쇼핑몰과 SNS처럼 두 가지 관점에서 설계를 해보려 합니다. 주의!!제 얄팍한 지식으로 설계하는만큼 실제 아키텍처를 공부하는게 아니고 직접 설계하는 능력을 기르기 위해서 쓰는 포스팅임을 알립니다. ..

가트너의 MSA 아키텍처에서 보면 MSA를 3티어 아키텍처로 두고 여러개의 파트로 분리해놓은 것을 보고 일단 데이터베이스부터 설계를 해야겠다는 생각을 했습니다. MSA에서 데이터베이스를 설계할 때 제가 중요하게 생각한 관점은 다음과 같습니다. RDBMS는 거대한 상태 덩어리이므로 stateless 애플리케이션에 적합한 k8s에 적합하지 않다. 때문에 데이터베이스는 클러스터 외부 베어메탈 머신에서 돌아가야한다. 이런 상황에서 쿠버네티스 클러스터 내부에 있는 애플리케이션과 상호작용 해야한다. 마스터 - 슬레이브 아키텍처로 마스터 노드에선 쓰기 작업을, 슬레이브 노드에선 읽기 작업을 해야하며 마스터 노드의 장애시 슬레이브 노드가 마스터 노드로 승격되어야한다. 되도록이면 Automatic Failover를 ..

MSA 사고실험 시작이번 포스팅을 시작으로 MSA에서 아키텍처 설계를 해보려고 합니다. 제 개인적인 생각이지만 k8s정도는 한번 구축해보는게 이해하는것도 편하고 여러모로 쓸모 있지만 MSA라는 거대 아키텍처는 하나하나가 모여 거대한 아키텍처를 이루기에 깔짝깔짝 해본다고 해봤다고 하기 좀 뭣 한 것 같습니다. 당연히 Hello World 수준에서는 쉽겠지만 실제 MSA를 적용하고 있는 여러 기업들에서 생기는 문제들은 이런 수준이 아닐 것이므로 Hello World 수준으로 실습하는건 적절하지 못하다고 판단했습니다. 근데 구인공고 여기저기서 "MSA에 대한 이해가 있는 분" 이라고 써놓으니 공부를 안할 수도 없고 곤란하던 차에 든 생각이 바로 "아인슈타인도 상대성 이론을 사고실험으로 만들었는데 나라고 못..

최근에 사이드 프로젝트를 하느라 코딩을 많이해서 그런가 요즘은 이론 공부에 집중하게 되더군요. 조금 딴소리지만 처음 공식문서를 읽게 된게 Baeldung의 로컬 트랜잭션과 글로벌 트랜잭션인데 이걸 처음 읽고 충격에 빠지지 않을 수 없었습니다. 이론공부를 한다는게 이렇게 재밌는 일인가? 싶은 생각이 들었었죠. 그 때가 벌써 2년전이네요. 그 이후로 공식 문서를 보는걸 좋아했는데 짧은 영어로 한글자 한글자 해석하면서 알게되는 변태같은 심연의 지식들이 너무 좋더라구요. 이번 포스팅에선 분산 시스템에서 합의를 이뤄 리더를 선출해내는 분산 합의 알고리즘을 공부해보고 정리해봤습니다. 분산 합의 알고리즘Raft 알고리즘을 본격적으로 들어가기 전에 분산 합의 알고리즘이 어떤 것이며 왜 필요한지 정리하고 넘어가겠습..

카프카에 대한 이론적인 내용은 아마 이게 끝일 것 같습니다. 아파치 카프카 카테고리는 개념, 심화, 응용을 마지막으로 이제 실습을 해볼 예정입니다.  이번 응용편에선 이렇게 진행됩니다.  Unclean Leader Election의 위험성과 사용 여부 판단Offset 관리 전략성능 최적화 및 튜닝카프카 스토리지와 OS 레벨 연계이렇게 네가지 섹션으로 이루어집니다. 한번 천천히 정리해보겠습니다.  Unclean Leader Election카프카는 장애시 ISR에서 리더 파티션을 새로 뽑아 장애 상황에 최적화된 움직임을 보여줍니다. 그런데 만약 ISR에 뽑을만한 리더 파티션이 없으면 어떻게 될까요?  이럴 때 개발자는 Unclean Leader 즉, ISR에 없는 파티션 중 리더로 선출할 수 있도록합니다. ..

요즘은 카프카와 NoSQL을 공부하고 있는데 카프카는 특히 공부하면 공부할수록 왜 개발자들이 많이 사용하는지 알 것 같습니다. 공부하면 공부할수록 왜 쓰는지 이해가 된달까요.. 이번 포스팅에선 카프카와 AWS SQS, SNS와 비교하면서 왜 카프카가 대용량 메세지 처리에 능하게 되었는지에 대해서 정리해봤습니다.  카프카 vs SQS, SNS왜 다른 메세지 큐도 아니고 SQS냐하면 RabbitMQ는 메세지를 소비할 곳을 세밀하게 조정하고 싶을 때 사용하는 것이 바람직하지 대용량으로 비동기 메세지 처리를 하는데 특화되어있지는 않습니다. 다른 메세지 큐인 Redis의 Pub/Sub 또한 대용량 비동기 메세지 처리에 특화되어있지 않기도 하구요.  그런 의미에서 SQS와 SNS를 조합한 메세지 큐잉 서비스는 완전..

이번 포스팅에서는 아파치 카프카에 대해서 개념만 잡았던 이전 포스팅에 이어 조금 딥한 내용을 공부해보고 정리해보았습니다. 처음엔 카프카의 구성 요소를 짧에 짚고 넘어가고 이후 카프카의 주요 개념에 대해서 알아보도록 하겠습니다.  아파치 카프카카프카의 구성요소로는 Broker, Topic, Partition, Producer, Consumer, Consumer Group이 있습니다. 하나씩 간단하게만 정리해보겠습니다.  브로커 : 브로커는 카프카가 설치되어있는 물리적인 서버에 해당합니다. 이런 브로커들이 모여서 카프카 클러스터가 되는데 이 브로커는 카프카 그 자체라고 볼 수도 있습니다. 토픽 : 메세지가 저장되어있는 "논리적인" 공간입니다. 메세지를 생산하는 프로듀서는 이 토픽을 바라보고 생산하고 컨슈머는..

마이크로 서비스와 메세지 브로커는 뗄 수 없는 사이입니다. 서로 다른 도메인이 여러개의 서버로 나눠져 있는 상황에서 모든 서버에 동일하게 데이터를 전달해야 하는 경우에 메세지 브로커만한게 없죠.  그렇기에 모놀리식에서는 메세지 브로커를 사용하는게 오버엔지니어링이 되기도 합니다.  이번 포스팅에서는 메세지 브로커의 근심과 걱정에 대한 내용을 공부해보고 정리해봤습니다.  메세지 브로커https://coding-review.tistory.com/504 아파치 카프카 (개념)저번 포스팅에서 파트2를 시작하면서 메세지 브로커의 장을 열었습니다. 메세지 브로커를 이용해서 서버간 통신을 조금 더 매끄럽게 진행할 수 있다는 것을 알았고 어떤 모델이 있는지 알았습coding-review.tistory.com메세지 브로커..

요즘 사이드 프로젝트 때문에 실습만 주구장창 했는데 오랜만에 이론 포스팅입니다. 쿠버네티스를 공부하다보면, 그리고 DevOps에 대해 공부하다보면 한번쯤은 보게 되는 논쟁 바로 "쿠버네티스 클러스터에 RDB배포? 시기상조다" VS "쿠버네티스 클러스터에 RDB배포 안해봤어? 겁나 편한데" 이 논쟁을 구글링하면 마땅한 답이 없습니다. 누가 시원하게 쓰면 좋아! 쓰면 나빠! 이걸 적어놓은걸 찾기 힘들었습니다. 그래서 GPT와 토론을 하면서 주장 -> 반박 -> 재반박 -> 반박에 반박 을 거듭하여 나름 정리해봤습니다.  우선 이 논쟁에 대해 짚어야 하는 부분은 크게 다섯가지입니다.  트랜잭션 롤백에 대한 관점마스터 슬레이브 노드 선출에 대한 관점네트워크 망분리로 인한 split-brain 상황에 대한 관점쿠..