Razelo 기술노트

DynamoDB의 근간은 2007년 AWS에서 내놓은 Dynamo 논문에 기반을 둔다. 해당 논문을 읽어보고 간략하게 내용을 정리해보고자 한다.  주의 개인 학습을 위해 러프하게 읽어본 내용이라서 중간에 잘못 해석한 내용이 있을 수 있습니다. 간략하게 1회독 한 것이라서 정확하지 않습니다. 요약을 차차 수정할 예정이니 내용을 파악하고 싶다면 논문을 직접 보시는 게 좋습니다.  1. 서론 아마존은 전세계급 서비스를 운용이 논문에서는 Dynamo라 불리는 고가용성의 키벨류 저장소 시스템을 다룸 즉 always-on이 가능하게 하는 서비스임 토네이도 때문에 데이터 센터가 날아가거나 혹은 네트워크 장애가 발생하더라도 언제나 가용한 저장소 기술에 대한 니즈는 항상 있다. RDB의 일반적인 패턴은 비효율성을 가져왔..

최근 Dynamo 논문을 읽어보면서 흥미로운 개념을 발견했다. 대부분의 DB의 경우 last writes wins라는 전략을 택한다고 한다. 간단하게 말하자면 마지막에 쓴 자가 기존 데이터를 덮어씌우는 방식이다. 동시 쓰기의 문제를 심플하게 나중에 쓴 사람 걸 채택하는 방식으로 해결한다는 것이다. 이렇게 하는 이유는 개발자의 편의에 있기도 하고, (개발자들은 본인의 client단에 복잡한 충돌 처리 로직을 작성하는 걸 싫어한다고 한다) 단순하게 그 방법이 가장 간단하기 때문이라고도 한다. 그런데 Dynamo 논문에서는 DynamoDB의 경우 last writes wins가 아니라 애플리케이션에서 해당 충돌에 대한 권한을 가질 수 있도록 만들었다고 한다. 즉 애플리케이션 단의 로직으로 해당 충돌 문제를 해..

아래 것들을 공부해야할 것 같다...  KotlinMSA DynamoDB MySQL

용어 RabbitMQ의 클라이언트 브로커와 통신하는 모든 애플리케이션을 의미함 Producer 메세지를 생성하고 RabbitMQ 브로커로 전송함 Consumer RabbitMq 브로커로부터 메세지를 받아서 처리함 RabbitMQ의 브로커 중앙 메시징 시스템 브로커는 Producer로부터 메세지를 받아서 적절한 큐에 저장하고 그 큐의 메세지를 Consumer에게 전달함 구성요소 Exchange 메세지를 받아 적절한 큐로 라우팅하는 컴포넌트 direct, topic, fanout, headers등 타입을 가짐 각 타입에 따라 메세지를 다른 방식으로 라우팅함 Queues 메세지가 저장되는 곳 메세지를 컨슈머에게 전달하기 전에 일시적으로 저장하는 버퍼 역할 Blindings Exchange와 큐 사이의 연결을 ..

이번 주에 RabbitMQ에 대해서 알아보았다. 꽤나 재밌는 내용이 많았다. 단순히 producer, consumer만 있는게 아니라 exchange라는 개념까지? 그리고 클러스터링과 미러링, 성능에 대한 이야기도 모두 재밌게 보았다. AMQP라는 새로운 프로토콜에 대해서도 알 수 있었다. (디테일한 스펙은 내용이 너무 많아서 다 보지 못했다.) 공부하면서 보던 링크를 기록해둔다. RabbitMQ에 대해서 간략하게 학습하고 싶은 분이 계시다면 아래 링크를 참고하시기 바란다. RabbitMQ 공식 사이트 https://www.rabbitmq.com/ RabbitMQ 성능 가이드 https://chopstick-91.tistory.com/160 RabbitMQ internal https://github.co..

vhost mandatory message channel cluster mirroring

vhost는 무엇일까? vhost 즉 virtual host는 메시징 시스템 내에서 논리적으로 분리된 파티션 또는 네임스페이스임 vhost는 사용자, exchange, queue 및 binding 등 RabbitMQ 리소스에 대한 독립적인 네임스페이스를 제공 다양한 프로젝트나 환경에서 동일한 RabbitMQ 인스턴스나 클러스터를 공유하면서 리소스 간 충돌이나 권한 문제를 방지함 왜 vhost를 사용해야할까? 리소스 논리적 분리 vhost는 RabbitMQ 서버에서 논리적 분리를 제공함 각 vhost는 독립된 네임스페이스에서 exchanage, queue, binding등의 리소스를 관리함 이 점이 여러 애플리케이션, 프로젝트, 또는 팀이 동일한 RabbitMQ 인스턴스를 공유하면서도 각자의 리소스를 분리..

RabbitMQ에 대해 학습하는 도중 RabbitMQ와 Kafka에 대해 비교한 흥미로운 논문을 발견했다. 학사 학위 논문으로 보이는 이 논문을 읽어보고 간략하게 정리해보았다. 메세지 브로커에 대한 깊은 난이도라기보다는 두 오픈소스간 성능 비교를 해본 논문이다. 꽤 재밌다. RabbitMQ vs Kafka에 대해 재밌게 읽을 수 있다. 커피마시면서 읽기에 딱 좋다. 논문 링크 https://www.diva-portal.org/smash/get/diva2:1674316/FULLTEXT01.pdf 내용 요약 분산 시스템, MSA 구조는 컴포넌트의 결합도를 낮추는 방향임 그래서 각 디바이스로 컴포넌트가 분산되있을때,시스템 내 컴포넌트 간 통신을 위해 MOM이 필요하다. 메세지 브로커는 MOM의 핵심이다. (M..

RabbitMQ 클러스터링을 공부하던 중 AWS EBS에 대한 내용이 등장했다. 처음 들어본 기술 용어이므로 관련 내용을 간략하게 정리하고자 한다. EBS란 무엇인가? Elastic Block Storage는 AWS 클라우드의 EC2 인스턴스에 사용할 영구 블록 스토리지 볼륨을 제공함 각 EBS 볼륨은 가용 영역 내에 자동으로 복제되어서 구성 요소 장애로부터 보호하고 고가용성 및 내구성을 제공함 요약 가상 하드드라이브임 EC2 인스턴스가 종료되어도 계속유지 가능함 인스턴스랑은 별개의 개념이라고 보면 됨 인스턴스와 EBS는 네트워크로 연결로 되어있기 때문임 하나의 EC2 인스턴스에 여러 하드드라이브 즉 EBS를 계속 네트워크에 붙여서 추가시킬 수 있음 인스턴스 정지 후 재기동 가능함 하나의 EBS를 여러 ..

최근 RabbitMQ를 사용할 일이 있었다. 이해가 부족해서 중간에 잘못된 코드를 사용해서 문제가 발생했다. 이번 기회에 RabbitMQ란 무엇인지, 왜 쓰는지, 어디에 쓰는지 학습해보고 간략하게 정리해보고자 한다. 메세지 드리븐? 서비스 사이에 비동기적으로 메세지를 전달하는 방식이다. 그래서 서비스들은 느슨한 결합 -> decoupling 된 의존성을 가지게 된다. -> 부하 관리, 탄력적인 흐름 제어가 가능함 이 메세지 드리븐의 장점을 얻기 위해 메세지 미들웨어를 쓸 수 있다. -> 그래서 MQ를 쓸 수 있다. 그런데 카프카는? RabbitMQ는 큐 카프카는 로그 큐 선입 선출 메세지는 소비되면 큐에서 삭제됨 일시적인 메세지 보관 생산자, 소비자가 독립적 비동기적으로 존재할 수 있다. 큐잉, 버퍼 역..