분류 전체보기209

• 

  MySQL Concept & Structure 블랙박스 뽀개기 Mysql 아키텍처mysql은 모듈식 아키텍처 형태로 설계되었다.커넥터 레이어해당 레이어에서 다양한 커넥터 (드라이버)를 제공한다.client가 mysql 서버에 연결할 수 있도록 지원한다.client 요청은 sql 형태로 전달된다.SQL 레이어sql parser와 optimizer가 해당 레이어에서 동작하낟.query를 분석 및 최적화하고, 실행 계획을 수립한다.데이터 접근 및 처리를 위한 논리적 인터페이스 역할을 한다.스토리지 엔진실제 데이터는 스토리지 엔진이 관리한다.mysql은 plugin 방식으로 다양한 스토리지 엔진을 지원하고, 대표적으로 innodb, myisam이 있다.각 엔진별로 데이터 read/ write 및 indexing 방식이 다르다.innodbmysql의 default 엔진이다... Self-Development/Study 2024. 11. 16.

• 

  빈약한 도메인 모델은 어떤게 해로운걸까? DDD에서 풍부한 도메인 모델 (Rich Domain Models), 빈약한 도메인 모델 (Anemic Domain Models) 두 명칭을 갖고 여러가지 이야기를 다룬다. 이번 글에선 빈약한 도메인 모델이 개인적인 경험 기반으로 왜 해로운지 정리해보고자한다. (정말 해로운건 맞는지?, 있다면 그게 왜 해로운건지?, 트레이드 오프는 어떤게 있는지? 등을 파고자하는게 주 목적이다) 우선 두괄식으로 개인적으로 생각할 때, 빈약한 도메인 모델이 가장 크게 해롭다고 다가오는 이유는 캡슐화인것같다. 이를 형상화해보면, 빈약한 도메인 모델은 도메인 객체가 데이터를 담기만하고 논리(로직, 행위)는 서비스 클래스에 구현된다. 유저 금액을 예금하는 코드로보면 다음과 같다. data class User(val name: .. Self-Development/Study 2024. 10. 26.

• 

  CQRS Journey Guide 톺아보기 우선 나오는 개념들 정리하면.. Bounded Context1. 각각의 Domain Model을 포함하고있는 일종의 문맥이기도 하면서 유비쿼터스 랭귀지를 포함한다. 2. Bounded Context는 일관성을 보장해야하는 하나의 개념적 단위, 컴포넌트로 볼 수 있다. 3. Bounded Context는 보통 사건(Event)을 발생시켜 다른 B.C.와 통신한다 Context Map1. B.C. 간의 관계를 그리는것으로 접점을 설명하고, 의사소통의 수단으로 사용된다. 2. 각각의 서로 다른 B.C. 간 어떤 관계를 갖고있는지, 어떤 상호작용을 하는지 알 수 있도록 하는것이 목적이다. 3. Context Map은 상호 교류하는 시스템의 목록을 제공하고 팀 내 의사소통의 촉매 역할을 한다. Command1. .. Self-Development/Study 2024. 10. 21.

• what is a domain services? 에릭 에반스는 도메인 서비스를 다음과 같이 말했다.엔터티에 부여하기 적합하지 않은 책임을 도메인 서비스에 부여하라즉, 도메인 서비스는 말 그대로 도메인을 위해 존재하는 객체이므로 기술에 의존성이 없는 POJO 형태로 구현되어야한다. 반 버논의 "도메인 주도 설계 구현"에서는 도메인 서비스를 사용해야할 때 세가지 휴리스틱을 제시했다. 중요한 비지니스 프로세스를 수행할 때어떤 컴포지션에서 다른 컴포지션으로 도메인 객체를 변환할 때하나 이상의 도메인 객체에서 요구하는 입력값을 계산할 때 중요한 비지니스 프로세스를 수행할 때사례로 에릭 에반스는 도메인 주도 설계에서 계좌 이체로 설명했다.계좌 이체는 입금, 출금, 잔액조회 같은 계좌의 책임이 아니라 두 계좌간 연속적인 입금과 출금의 과정이다. 계좌 이체는 Tra.. Self-Development/Study 2024. 9. 28.

• 

  Bucket4j를 이용하여 Rate Limiting Pattern 구현하기 서론이전 글인 Redis로 간단하게 구현하며 알아보는 Rate Limiting Pattern 에서는 Redies로 구현하며 Rate Limit을 구현했었다. 이번글에서는 bucket4j를 이용하여 rate limit을 간단하게 구현하며 해당 개념들을 알아보려한다. (참고로 bucket4j에서도 redis의 글로벌 캐시 의존성을 주입하여 사용할 수 있는 방법이 있으나 이번엔 순수 bucket4j로만 구현해보았다) 배경이전 글에서도 언급했듯이, API 요청을 관리하고 제어하는것은 시스템의 안정성과 성능을 유지하는데 중요한 요소이다. 특히 동일한 사용자가 과도하게 요청을 보낼 경우 시스템에 문제가 생겨 고객 경험에 큰 악영향을 줄 수 있다. 이로인해 이탈되는 고객은 반드시 존재한다고 생각한다. 그래서 필자는 .. Architecture 2024. 9. 8.

• 

  Redis로 구현한 Rate Limiting Pattern 서론웹 애플리케이션에서 Rate Limiting Pattern은 제품 사용자 규모가 커질 수록 중요한 역할을 한다.이는 서버의 과부하를 방지하고, 사용자 경험을 개선하며, 서비스의 안정성을 보장하는 데 필수적인 기능이다. Rate Limiter는 일정 시간 동안 특정 사용자나 IP의 요청 수를 제한하여, API 남용을 방지한다. 이번 글에서는 Kotlin/Spring + Redis를 사용하여 Rate Limiter 구현하는 방식에 대해서 소개해보려한다. Redis를 선택한 이유Rate Limiting 구현 시 Redis를 사용하는 이유는 다음과 같다:빠른 성능: Redis는 인메모리 데이터베이스로, 읽기 및 쓰기 성능이 뛰어나다.간편한 데이터 구조: Redis의 데이터 구조를 활용하여 간편하게 카운트와.. Architecture 2024. 9. 2.

• 

  CAP 이론 이해하기 근래 다양한 아키텍처와 시스템 구성이 발표되면서, 분산 컴퓨팅 시스템이 많이 대중화가 되어가고 있는것같다. 관련된 개념으로 CAP 이론이 존재하는데, 처음 읽었을 때 정말 기가막히게 Conceptualization 해놓아서 매우 공감하면서 이해했다.  CAP는 이런 개념이다분산 컴퓨팅 개념에서 일관성(Consistency), 가용성(Availability), 분할 내성(Partion Tolerance) 중 두가지만 동시에 만족시킬 수 있다는 이론이다. 이해를 위해 분산 환경 속에서 위 개념들을 뽀개보면 아래와 같다. 일관성(Consistency)모든 노드가 같은 시점에 동일한 데이터를 갖는 것을 의미한다. 즉, 하나의 노드에서 업데이트 된 데이터는 즉시 다른 모든 노드에 반영되어야한다. 가용성(Avail.. Self-Development/Study 2024. 7. 6.

• 

  Replication의 데이터 동기화는 어떻게 되는걸까 레플리카 셋(Repliaca Set)에 대해 먼저 이해해보면레플리카 셋의 주 목적은 DB의 가용성을 확보하고 장애 복구(Fail Over) 처리하기 위해 구성한다. 하나의 주 서버(Primary)와 하나 이상의 복제본 서버(Secondary)로 구성된다. 주 서버(Primary)는 모든 쓰기와 대부분의 읽기 작업을 처리하며, 복제본 서버(Secondary)는 주 서버의 데이터를 실시간으로 복제하여 읽기 작업을 분담하거나 장애 발생 시 주 서버를 대체하는 메커니즘이다.  어떻게 주 서버의 데이터를 복제본 서버로 Sync하는걸까?데이터 동기화 하는 방식엔 여러 방식이 있지만, 이번엔 RDB의 처리 프로세싱에 대해서만 다뤄보려한다.1) 빈 로그 기록 (Binary Log Recording)primary에서 데.. Self-Development/Study 2024. 7. 6.

• 

  DDD의 Repository Pattern은 왜 사용할까 # 서론최근 많은 개발자분들이 Spring Data Jpa에서 제공하는 `JpaRepository`를 사용하면서 자연스럽게 DDD의 리포지토리 패턴을 사용하고있다. 이번글에서는 DDD의 Repository Pattern의 등장 배경과 개념, 그리고 적용시 얻는 이점들에 대해서 소개해보고자 한다. # 본론리포지토리 패턴이란?리포지토리 패턴은 도메인 주도설계에서 중요한 역할을 하는 설계 패턴 중 하나이다. 이 패턴은 도메인 객체를 영속화하는 작업을 추상화하여 도메인 모델과 데이터베이스 접근 로직을 분리하는것을 목표로 한다. 등장 배경은?DDD의 리포지토리 패턴은 복잡한 어플리케이션에서 다음과 같은 문제를 해결하기 위해 등장했다고한다. 1. 도메인 로직과 데이터 접근 로직의 분리도메인 모델은 비지니스 로직을.. Self-Development/Study 2024. 6. 8.

• 

  애그리거트(Aggregate) 디자인하기 # 서론일단 제목에서 나온 키워드의 사전적 개념부터 간단히 정리하고 시작한다. 그리고 애그리거트를 왜, 어떻게 그리고 이를 어떻게 활용하는지에 대한 내용을 소개해보려한다. 애그리거트(Aggregate)데이터 변경의 단위로 다루는 연관 객체의 불변 집합체를 말한다. (사전적 개념만 정리했을땐 간단해보이지만, 애그리거트 개념은 굉장히 많은 내용을 내포하고있어 더 깊이 알아볼 필요가있다.) # 본론왜 애그리거트 (Aggregate) 경계 설정이 중요할까?가장 대중적인 주문(Order) 도메인으로 설명을 해보려한다. 필자는 주문 시스템을 만들기 위한 엔터티들을 아래와 같이 설정했다. data class Address( val street: String, val city: String, val state: St.. Self-Development/Study 2024. 6. 7.

• 도메인과 도메인 모델(Domain Model) # 도메인넓은 의미에서 도메인이란 한 조직이 행하는 일과 그 조직 안의 세계를 일컫는다. 비지니스 담당자는 시장을 파악하고 상품과 서비스를 판매한다. 각기 다른 종류의 조직은 그 나름대로 독특한 노하우를 가진 영역과 업무를 수행하는 방법이 있다. 그 이해의 영역과 조직의 작업을 수행하는 방법이 그 조직의 도메인이다. 다시말해 당신이 한 조직을 위해 소프트웨어를 개발한다면, 그 조직의 도메인 안에서 일하고있는것이다. # 도메인 모델도메인 모델의 아름다운 소리 우리의 모델이 음악이였다면, 그 모델은 실수 없이 완벽한 소리, 순수성, 힘, 우아함과 아름다움을 가졌을 것이다. 도메인 모델이라는 용어에도 `도메인` 이라는 단어가 들어가있으므로, 한 조직의 전체 비지니스 도메인을 위한 하나로 응집력 있게 모든 항목.. Self-Development/Study 2024. 6. 5.

• 

  메세지 브로커로 동시성 이슈 트러블 슈팅하기 (feat. AWS SQS) 이번 글에서는 B2B SaaS 제품을 만들면서 발생한 동시성 제어 이슈를 트러블 슈팅한 이야기를 정리해보려한다. Background도메인 서비스들은 MSA 환경으로 이루어져있다.스케줄(schedule), 수납(purchase), 시술권(ticket)이라는 Bounded Context가 존재한다. 각 B.C간 의존 관계는 다음과 같다. 스케줄 -> 수납 스케줄 -> 시술권 시술권 -> 수납 수납을 하면, "수납됨" 이벤트에 속한 구매 항목 기반으로 시술권 그룹이 생성된다. (Purchase B.C.) Purchased Event Publish (Ticket B.C.) Purchased Event Consume -> Handle Event -> Process Event -> Create Ticket 생성된 .. Architecture 2024. 5. 10.