
Kafka모든 애플리케이션은 의미가 있는 데이터를 만들고, 그 다음 처리되어야 하는 작업과 같이 뭔가 중요한 정보를 담고 있다. 따라서 해당 데이터에 알기 위해서는 데이터를 생성된 곳에서 분석할 수 있는 곳으로 옮겨야 하는 만큼 파이프라인(pipeline)이 중요한 핵심적인 요소가 된다고 할 수 있다. 실제 링크드인에서 하루 4.5조 개 이상의 이벤트 스트림을 처리하고 있기 때문에 기존의 Messaging Platform(ex: MQ)로는 처리가 불가능하여 데이터(이벤트) 스트림 처리를 위해 카프카(Kafka)가 개발되었다. Kafka vs RabbitMQKafka와 RabbitMQ 둘 다 메시지 전송 플랫폼을 제공하지만 위 그래프에서도 볼 수 있듯이 카프카가 초당 600MB로 처리량이 훨씬 높은 것을 ..

분산 환경에서의 트랜잭션모놀리식 아키텍처(Monolithic Architecture)의 일관성을 보장하기 위해 관계형 데이터베이스를 공유하는 것이 보통이다. 하나의 DB 트랜잭션으로 처리하는 경우에는 개발자가 ACID(원자성(Atomicity), 일관성(Consistency), 격리성(Isolation), 지속성(Durability))을 보장하는 작업이 매우 단순해진다. 마이크로서비스 아키텍처도 마찬가지로 단일 서비스 내부의 트랜잭션은 ACID를 보장하지만, 여러 서비스의 데이터를 업데이트하는 트랜잭션을 구현 시 각 서비스마다 데이터베이스를 가지고 있기 때문에 데이터 일관성을 보장하기 까다로워진다. 분산 시스템 환경에서 트랜잭션과 데이터 일관성을 다루는 방법에 대해 알아보자. 2PC하나의 트랜잭션으로 데..

MSA(MicroService Architecture)기존 시스템들이 하나의 거대한 형태로 구축되어서 서비스되었다고 하면 마이크로 서비스라는 것은 전체 서비스를 구축하고 있는 개별적인 모듈이나 기능을 독립적으로 개발하고 운영할 수 있도록 세분화된 서비스라고 볼 수 있다. 일반적으로 사용하는 모놀리식 아키텍처와 MSA를 비교하고, MSA를 사용하는 이유에 대해 알아보자. 모놀리식 아키텍처(Monolithic Architecture)모놀리식 아키텍처는 모든 종류의 서비스가 하나의 애플리케이션으로 구성되어 있는 아키텍처를 의미하고 다음과 같은 특징이 있다.하나의 주요 프로세스로 구성모든 서비스가 하나의 DB 엔드포인트를 사용단 한줄만 코드 수정하더라도 모든 서비스 애플리케이션의 재배포가 따름싱글 혹은 멀티 모..

DockerDocker는 오픈소스 컨테이너화된 플랫폼으로 개발자는 어떤 환경에서도 해당 코드를 실행하는 데 필요한 애플리케이션 소스 코드와 운영 체제(OS) 라이브러리 및 종속성을 결합한 앱을 컨테이너로 패키지화할 수 있다. 즉, 어플리케이션을 개발하면서 여러 언어버전, 환경변수, 프레임워크 및 도구 간의 복잡한 인터페이스는 엄청난 복잡도를 해결하기 위해 Docker가 나오게 되었다. 예를 들어, 개발자가 로컬에서 어플리케이션을 개발하여 서버에 배포할 때, 로컬에서 잘 작동했는데 서버 환경에서는 잘 작동하지 않는 문제와 같은 문제를 Docker가 해결해줄 수 있다. Docker를 사용하는 이유가상화 환경 vs 컨테이너 환경처음 가상머신을 사용하는 이유 중 하나로는 언뜻 보기에 모순되어 보이는 조건인 격리..

RabbitMQRabbitMQ는 메시지 브로커(Message Broker)로서 매우 단순한 애플리케이션부터 대규모 시스템까지 다양한 분산 소프트웨어 아키텍처를 만들기 위한 매우 강력하고 가벼운 도구이다. RabbitMQ는 관리자 UI 플러그인과 함꼐 코어 어플리케이션을 구동하는데 40MB 미만의 메모리만 사용하여 가볍고, 이후 큐(Queue)에 전송되는 메시지양이 증가함에 따라 메모리 사용량이 점차 증가한다. 또한, 메시지를 배달하기 전에 디스크 또는 메모리에 저장하거나 클러스터를 설정할 때 큐를 HA(Highly Available)로 설정해서 여러 노드에 걸쳐 저장하도록 옵션을 설정하여 메시지 처리량 혹은 성능을 유연하게 제어하고 안정적으로 메시지를 전달할 수 있다. RabbitMQ 등장 배경 웹 사이..

JPA회사에서 Spring Data JPA와 QueryDSL을 사용하고 있다... Spring Data JPA와 QueryDSL을 공부하기 전 JPA에 대해 알아보고자 한다. MyBatis와 달리 JPA이 무엇이고, JPA를 사용함으로써 얻을 수 있는 장점과 사용 시 주의사항들에 대해서 살펴보자. SQL 중심적인 개발의 문제점과 대안자바를 사용하는 이유 중 하나인 객체 지향 프로그래밍은 추상화, 캡슐화, 정보은닉, 상속, 다형성 등 시스템의 복잡성을 제어할 수 있는 다양한 장치들을 제공하여 객체 모델링으로 저장할 수 있다. 하지만 MyBatis와 같은 SQL 중심의 개발은 SELECT, INSERT, UPDATE, DELETE의 무한 반복과 위 사진처럼 객체의 필드가 테이블에 맞추어 모델링되므로 의존적이..

nGrinder를 사용한 성능 테스트: 비관적 락 vs 분산 락 분산 환경에서는 비관적 락과 분산 락의 성능이 비교해보려고 한다. 비관적 락과 분산 락 비즈니스 로직 성능 테스트를 위해 두 비즈니스 로직을 똑같게 만들기 위해서 상품을 조회한 후 재고를 차감할 후 있는지 확인한 후 가능하다면 재고를 차감시킬 수 있도록 구현했다. 비관적 락과 분산 락 로직 차이 SELECT * FROM product WHERE id = #{id} SELECT * FROM product WHERE id = #{id} FOR UPDATE 가장 먼저, 상품을 조회했을 때 비관적 락은 SELECT ... FOR UPDATE를 통해서 조회한 레코드에 대해 배타락을 획득하는 반면, 분산 락은 애플리케이션 단에서 락을 획득하고 반납하기..

MySQL Replication 데이터베이스를 사용하고 운영할 때 가장 중요한 두 가지 요소는 확장성(Scalability)과 가용성(Availability)이다. 이 두 가지 요소를 위해 가장 일반적으로 사용되는 기술인 MySQL 복제는 소스 서버의 데이터를 하나 이상의 레플리카 서버로 복제하여 읽기 작업을 분산시켜 성능을 향상시키는 것을 말한다. 원본 데이터를 가진 서버를 소스(Source) 서버, 복제된 데이터를 가지는 서버를 레플리카(Replica) 서버라고 부른다. 소스 서버에서 데이터 및 스키마에 대한 변경이 최초로 발생하며, 레플리카 서버에서는 이러한 변경 내역을 소스 서버로부터 전달받아 자신이 가지고 있는 데이터에 반영함으로써 소스 서버에 저장된 데이터와 동기화시킨다. 복제 장점 복제를 통..

RDBMS vs NoSQL 이 글에서는 RDB와 NoSQL에 대해 알아보기 전에 CAP 이론을 살펴보고, CAP 이론을 통해 RDB와 NoSQL에서는 어떤 속성을 희생했는지에 대해서 살펴보자. CAP 이론 RDBMS와 NoSQL를 살펴볼 때 CAP이론을 살펴보면 좋다. CAP 이론은 분산 시스템에서 위 3가지 속성인 일관성(Consistency), 가용성(Availability), 분할 내성(Partition Tolerance) 중 두 가지만 동시에 보장할 수 있다는 이론이다. 즉, 완벽한 일관성, 가용성, 분할 허용성을 모두 동시에 보장하는 것은 불가능하며 다음 3가지 속성의 특징을 통해 어떠한 상황에서 속성을 희생해야 하는지에 대한 고려를 제공해준다. 하지만 완벽한 CP, AP 시스템은 사용할 수 없..
- Total
- Today
- Yesterday
- TDD
- mysql
- redis session
- postgresql
- annotation
- transaction
- 비관적 락
- amazon elb
- spring webflux
- nginx configuration
- sql
- 분산 락
- 카프카
- Synchronized
- jvm 메모리 구조
- mdcfilter
- 트랜잭션
- NeXTSTEP
- nginx
- ip cidr
- 넥스트스탭
- 구름톤챌린지
- amazon subnet
- Kafka
- spring session
- Java
- 람다
- 구름톤 챌린지
- pessimistic lock
- socket
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |