개요도대체 서킷 브레이커가 무엇이고 이걸 왜 쓰는 걸까요...? 마이크로서비스 아키텍처에서 서비스 간의 장애 전파를 막기 위한 패턴이라고 하는데...오늘은 같이 공부하며 서킷 브레이커를 왜 사용해야 하는지에 대한 이해와 간단하게 적용을 한 번 해보고자 합니다. 1. 서킷 브레이커의 탄생 배경서킷 브레이커는 전기 회로에서 과부하를 방지하기 위한 장치에서 이름을 따왔습니다. 마이크로서비스 아키텍처가 대두되면서 서비스들이 분산되고, 서로 다른 네트워크 환경에서 통신하게 되었습니다.하지만 네트워크 지연이나 장애로 인해 하나의 서비스 장애가 다른 서비스로 전파되어 전체 시스템의 안정성을 해치는문제가 발생했습니다.이러한 문제를 해결하기 위해 마틴 파울러는 서킷 브레이커 패턴을 제안했습니다. 이는 서비스 간의 ..
트랜잭셔널 아웃박스 패턴이란?마이크로서비스 환경에서는 데이터베이스와 메시지 브로커를 함께 사용하는 경우가 많습니다. 예를 들어 콘서트 예매 시스템에서 결제가완료되면 사용자에게 알림을 보내야 하는데, 이 과정에서 데이터베이스 트랜잭션과 메시지 발행이 원자성을 가져야 합니다.트랜잭셔널 아웃박스 패턴은 이벤트를 바로 메시지 브로커로 보내지 않고, 먼저 데이터베이스의 아웃박스 테이블에 저장한 후 별도의프로세스가 이를 읽어서 메시지 브로커로 전송하는 방식입니다. 1. 기존 구현의 문제점기존 시스템은 결제 처리와 동시에 카프카로 메시지를 직접 전송했습니다@Transactionalpublic PaymentResult processPayment(PaymentCommand command) { Payment paym..
개요SAGA 패턴은 마이크로서비스 아키텍처에서 분산 트랜잭션을 관리하기 위한 패턴입니다. 각 서비스의 로컬 트랜잭션을 순차적으로 처리하고, 문제 발생 시 보상 트랜잭션을 통해 일관성을 유지하는 방식으로 동작합니다. 1. 왜 SAGA 패턴이 필요한가?1.1 분산 트랜잭션의 문제점마이크로서비스 아키텍처에서는 하나의 작업이 여러 서비스에 걸쳐 발생하며, 각 서비스는 독립적인 데이터베이스를 가지므로 전통적인 ACID 트랜잭션을 적용하기 어렵습니다. 이로 인해 데이터 일관성을 보장하기 위한 새로운 방법이 필요합니다.1.2 SAGA 패턴의 장점장애 격리 (Failure Isolation): 각 서비스의 로컬 트랜잭션 실패가 전체 시스템에 영향을 최소화.서비스 간 느슨한 결합: 각 서비스는 이벤트나 중앙 오케스트레이..
개요도대체 카프카가 무엇이고 이걸 왜 쓰는걸까요..? 여기서도 카프카 저기서도 카프카.. 그래서 카프카카 뭔데??대규모 실시간 데이터 스트리밍을 하기위한 분산 메시징 시스템 이라고 하는데..오늘 같이 공부하며 카프카를 왜 사용해야 하는지에 대한 이해 및 간단하게 적용을 한번 해보고자 합니다... 1. 카프카의 탄생배경카프카는 비즈니스 소셜 네트워크 서비스인 링크드인 (linked-in) 에서 개발했다고 합니다..(그런의미에서 제 링크드인 http://www.linkedin.com/in/dongmin-cheon-9967352a2) 링크드인 초기에는 파편화 된 데이터 수집 및 분배를 처리하기 위해 데이터를 생성하는 source Application과데이터가 최종 적재되는 target Application..
1. 기존 시스템의 문제점 분석1.1 강결합된 도메인 구조@Transactionalpublic PaymentConcertResult paymentConcert(String token, long reservationId) { long userId = Users.extractUserIdFromJwt(token); Users user = userRepository.findById(userId); Queue queue = queueRepository.findByToken(token); queue.tokenReserveCheck(); Reservation reservation = reservationRepository.findById(reservationId); user.check..
개요안녕하세요. 이번에 콘서트 예약 시스템을 만들면서 DB 성능 최적화를 위한 인덱스를 적용한 내용을 정리해보려고 합니다.특히 B-Tree 구조를 이해하고 나니 어떤 컬럼을 어떤 순서로 인덱스에 넣어야 할지가 더 명확해졌습니다. 1.콘서트 스케줄 조회 쿼리CREATE INDEX idx_schedule_availability ON CONCERT_SCHEDULE (total_seat_status, is_delete, open_dt); 제가 생각 한 B-Tree 구조입니다: [total_seat_status] / \ [AVAILABLE] [SOLD_OUT] / ..
1. 개요우리는 왜 데이터베이스 최적화를 해야 할까요? 데이터베이스 최적화를 하는 이유는 여러 가지가 있지만,주된 이유는 시스템의 성능을 높이고 사용자 경험을 향상시키기 위해서입니다. 흔히들 이런 질문을 하십니다. 물론 서버 성능을 높이는 것(Scale-up)도 하나의 방법이 될 수 있습니다.하지만 이는 다음과 같은 한계가 있습니다:비용 효율성: 서버 성능 향상은 비용이 기하급수적으로 증가합니다.한계 존재: 아무리 좋은 서버도 결국 물리적 한계가 존재합니다.근본적 해결 아님: 비효율적인 쿼리는 여전히 비효율적입니다. 2. 콘서트 예매 시스템의 특수성콘서트 예매 시스템은 다음과 같은 특징이 있습니다:극단적인 동시성인기 가수의 티켓 오픈 시 수만 명이 동시 접속1초 내에 수천 개의 좌석 조회 요청 발생같은..
개요이번 콘서트 예약 서비스에서는 "대기열 토큰 발급 및 조회" 기능을 위해 Redis를 사용했습니다. 해당 기능은 실시간 응답성과 빠른 처리속도가 중요하기 때문에, 기존 DB보다 인메모리 데이터베이스인 Redis가 더 적합하다고 판단했습니다. 이 보고서에서는Redis와 DB 간의 성능 비교 실험 결과를 상세히 설명하고, 대기열 기능에서 Redis를 선택한 이유를 기재했습니다. 성능 비교 테스트 개요성능 비교는 k6 부하 테스트 툴을 사용하여 Redis와 DB에서 각각 실행했습니다. 시나리오는 10명의 가상 사용자로 시작해 1분 동안 50명으로 증가시키고, 마지막 30초에 0명으로 감소하는 방식으로 2분간 부하를 유지했습니다. 이는 유저가 대기열 토큰을 발급받고 자신의 순서를 자주 확인해야 하는 실제 상..
개요우리는 왜 낙관적 락과 비관적 락을 도입해야 할까요? 동시성 제어 방식으로서 두 락을 도입하는 이유는 여러 가지가 있지만,주된 이유는 데이터의 일관성을 보장하고 동시성 문제를 해결하기 위해서입니다. 옛날과는 다르게 요즘은 모두 디지털화 되어있기 때문에 어떤 일이든 다 웹을 통해서 진행을 하게 됩니다. 그에 따라 수많은 사람들이한 서비스에 몰릴때도 많은데요, 예를 들어, 인터파크 같은 대형 서비스의 티켓팅 서비스에서 동일한 좌석을 여러 사용자가 동시에예매하려 할 때, 또는 특정 시간대의 예매 폭주로 인해 실제 좌석 수보다 더 많은 예약이 발생하는 등 데이터의 정합성이깨질 수 있는 상황이 빈번하게 발생합니다. 이러한 동시성 문제를 해결하기 위한 전략으로 낙관적 락과 비관적 락이 사용되며, 각각의 상황..
개요우리는 왜 클린아키텍처를 도입해야 할까요? 클린 아키텍처는 코드를 더 유지보수하기 쉽고, 확장 가능하며, 테스트하기 좋게 만들어줍니다. 그 이유는 크게 두 가지 입니다. 설명에 앞서 일단 객체지향의 설계 5원칙 "SOLID" 에 대해서 알아 볼 필요가 있습니다.(저도 다시 복습 해보고자...) SOLID 원칙이란? 객체 지향 설계의 다섯 가지 핵심 원칙소프트웨어 개발에서 중요한 목표 중 하나는 유지보수성, 확장성, 그리고 코드의 재사용성을 높이는 것입니다.이를 달성하기 위해서 SOLID 원칙이 제시되었습니다. SOLID는 소프트웨어 설계 원칙들의 약어로, 각 원칙은 객체 지향 프로그래밍에서 모듈을 더 유연하고 확장 가능하게 만들기 위해 제안되었습니다. 이 글에서는 SOLID 원칙이 무엇인지,각 ..