전체 글206

• 수학자 허준이 선생님 축사를 듣고 오랜만에 티스토리에 개인 생각을 끄적여보는것같다. 제목만 봐도 알겠지만, 허준이 선생님의 서울대 축사 영상을 보고 작성하는글이다. 사실 허준이 선생님의 축사를 영상으로 접한진 꽤 되었다. 그런데 딱 오늘, 집에서 맥주한잔하고 알고리즘에 의해 노출되어 오랜만에 다시 한번 보았다. 웬걸 몇달 전 보고 들었던 필자의 느낌, 생각과 지금의 필자가 느끼는 생각은 꽤나 달랐다. 일단 필자의 근황을 살펴보면 최근에도 회사에서 여전히 제품 개발 일을 하고있고, 이 과정에서 생각만치 잘 풀리지않는것의 연속을 경험하고있다. 과연 이 부정적인 연속성이 끊길까, 시간이 지나면 끊기긴할까에 대한 두려움이 계속 있다. (이 두려움이 때로는 도전적인 재미로 올때도 있긴하지만.. ㅋㅋ) 그런데 사실 회사 일 뿐만 아니라 가족, 지인.. Self-Development/생각 정리 - 회고 2025. 3. 1.

• 블로그를 이원화합니다 ! 요즘도 개발을 하며 항상 마주치는 트레이드 오프 속 머리가 깨져라 고민하며 살고있어요. 하루하루 깨지고 넘어지는 경우가 많은데, 이 과정에서 얻은 깨달음을 잃고싶지않더라고요.관련해서 다시 열심히 포스팅을 하며 남겨보려해요.  '나의 과거일지'가 저에겐 여러모로 많은 의미가 있는 블로그라, Deprecated 시킬 생각은 당장 없고요. 조금 로우한 내용들은 여기서 계속 다룰거같고, 생각들을 정제한 내용들은 신설 블로그에 남기는 방식이 될거같아요. 마지막으로 새로 개설한 블로그 링크를 남기고 끝내봅니다! (작성한 글도 하나 있어요)블로그 보러가기  물음표 엔지니어기술적 접근에 있어 트레이드 오프에 대한 고민을 다뤄보려합니다jeongkyun.hashnode.dev 카테고리 없음 2024. 12. 18.

• 

  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.