지난 번에는 댓글을 n depth 댓글도 허용하는 구조로 변경해보았다. 댓글 최적화 도전기커넥티스트 프로젝트를 진행하면서게시판의 댓글과 대댓글에 대해서 고민했다. 처음에는 댓글 테이블, 대댓글 테이블 따로 구현했는데, 댓글과 대댓글이 과연 분리되어야 하는 엔티티인가에hyogu.tistory.com 이때 발생했던 애로사항이 도메인에서는 트리 구조의 댓글을 사용하는데 디비에서는 그렇지 않다는게 문제였고,만약 읽기 쿼리와 쓰기 쿼리를 통일화 한다면 댓글의 depth를 기준으로 페이징 처리를 하지 못한다는 단점이 있었다. 그리고 또 디비에서 값을 가져올 때는 읽기 전용 쿼리를 사용하여서 클라이언트에서 트리 구조를 적용하였다. ⇒ 읽기/쓰기 쿼리를 통일화 하지 못한다면, 결국 도메인은 트리 구조로 관리되어야 할..

커넥티스트 프로젝트를 진행하면서게시판의 댓글과 대댓글에 대해서 고민했다. 처음에는 댓글 테이블, 대댓글 테이블 따로 구현했는데, 댓글과 대댓글이 과연 분리되어야 하는 엔티티인가에 대해 질문을 받게 되었고,나도 생각해보니 이 둘은 필연적으로 게시글에 속해있어 같다고 생각해 굳이 분리할 필요가 없다고 생각했다. 그리고 현재는 depth 2를 갖는 대댓글만 지원하고 있는데, 이 둘을 한 테이블에 합치면 n depth 대댓글을 효율적으로 구현할 수 있었다.→ 하지만, 도메인의 재설계는 필연적으로 필요했다.그래서 이들이 일단 구현될 수 있는지 실험해보았다. 일단 10 depth 대댓글을 지원할 수 있도록 다음과 같이 디비 스키마를 짜주고mysql> desc comments;+------------+--------..

guideme project를 진행하면서 생길 수 있는 분산 트랜잭션의 문제에 대해 정리해 봤다.msa를 구현하면서 매번 고민하는 건 역시 데이터 정합성 같다. 예시를 들자면,, 고요 속의 외침 같달까 문제 상황현재 프로젝트 구조auth service → user service 간 분산 트랜잭션을 kafka를 이용한 Choreography기반의 SAGA pattern으로 구현.현재 구조에서 생각해 본 문제:auth service 실패 시, Kafka이벤트를 발행한다. 그러나 Kafka 이벤트 발행에서 문제가 있을 수 있지 않나?auth service 실패 시 발행하는 이벤트는 도메인 이벤트인가? 만약 그렇다면 이벤트 스키마의 주인은 auth인가? 그리고 이를 통일시켜야 하는 것이 어렵다.만약 consu..

이 글에서는 교내 프로젝트에서 Docker Compose를 사용한 경험을 바탕으로 Docker Compose의 개념과 활용에 대해서 알아보고자 한다.Docker Compose란?가장 먼저 docker compose가 뭔지 알아보고 이를 왜 사용하는지 알아보고자 한다.Docker compose는 여러 컨테이너를 한 번에 정의하고 관리하기 위해서 사용한다. 단일 컨테이너를 Dockerfile로 정의하고 빌드-배포-사용하는 일련의 과정들은 꽤 간단하다. 하나의 Dockerfile로 전부 처리 가능하기 때문이다. 그런데, 만약 한 서비스에 여러 컨테이너가 필요하다면? 여러 Dockerfile을 한 번에 실행시키는 것은 여간 불편한 일이 아닐 수 없다.그래서 Docker Compose를 사용하는데, 이는 여러 개..

GDGoC GIST활동 중 Guide me 프로젝트에서 처음으로 OAuth2.0을 도입하여 인증 로직을 외부 IDP에 위임하는 시도를 해보았다. 이전까지는 직접 인증/인가 로직을 구현해 왔지만, 이번에는 GSA 통합 계정을 활용해 인증을 위임해 보았다.이 글에서는 코드 레벨의 구현보다는 좀 더 큰 레벨에서 로직을 어떻게 만들었는지 정리하고자 한다.왜 권한 위임을 하는가?권한 위임을 시도한 이유는 비즈니스 로직 간소화와 사용자 만족도 향상이다.사용자가 이미 신뢰하는 GSA IDP(Identity Provider)로 인증을 넘기면, 우리 서비스는 회원 정보 관리와 인가(Authorization)에만 집중할 수 있다. 그리고 사용자는 신생 서비스에 새 비밀번호를 맡기기보다, 기존 GSA 계정으로 Single ..

컨테이너 런타임은 컨테이너의 생성, 실행, 관리에 대한 기능을 담당하는 소프트웨어를 의미한다.가장 대표적으로는 docker가 있다. 요즘은 docker뿐만 아니라, containerd, CRI-O 의 런타임도 사용되는데 몇번 실무에서 일을 하거나 공부를 하다 보면 들을 수 있는 런타임이다. 오늘은 그 특징과 사용 사례를 정리해보았다.DockerDocker는 컨테이너의 개념을 대중화한 플랫폼이고, 컨테이너 빌드에서부터 배포 및 실행까지 커버하는 올인원 컨테이너 엔진이다.Docker는 클라이언트-서버 구조로 이뤄져 있다. dockerDemon(dockerd)에 개발자가 CLI를 통해 명령을 전달하고, dockerd는 컨테이너 생성/시작/중지, 이미지 관리 작업을 수행한다.내부적으로 Docker 엔진은 con..

컨테이너와 VM, 둘의 차이를 간단하고 명확하게 설명하기는 쉽지 않다.이 두 차이를 간단하게 정리하고, 학습한 기록이다.  Container와 VM(Virtual machine)은 모두 애플리케이션을 격리하여 실행하는 기술이지만, 격리하는 구성 요소가 다르다는 점이 근본적인 차이다. 가상머신은 하이퍼바이저를 통하여 하드웨어 수준에서 전체 OS를 격리하지만, 컨테이너는 단일 OS 커널에서 프로세스를 격리한다.사실 그림 하나로 설명할 수 있다.VM하이퍼바이저가 실제 컴퓨터의 하드웨어를 가상화한다. 그리고 그 위에 독립된 guest os를 설치한다. 그래서 vm은 자기만의 커너과 시스템을 갖고 있다.컨테이너하이퍼바이저가 필요 없고, 기존 OS의 커널을 공유한다. 대신에 컨테이너는 각자의 실행 환경만 갖고 있어..

본 게시글은 토스증권 기술 블로그 중 토스증권 Apache Kafka 데이터센터 이중화 구성 #1,2,3을 읽고, 그 개념을 정리하고 느낀 점을 정리한 글입니다. 정말 창의적이고 잘 정리된 기술 인사이트를 공유해 준 토스증권에 감사인사 드립니다. 토스증권 Apache Kafka 데이터센터 이중화 구성 #1토스증권은 데이터센터 장애 상황에도 유저에게 정상적으로 서비스를 제공하기 위해 대부분의 시스템을 이중화했습니다. Kafka 이중화 구성에 대한 개요를 소개드려요.toss.tech 토스증권 Apache Kafka 데이터센터 이중화 구성 #2: 데이터 미러링토스증권은 현재 Active-Active 구성으로 Kafka를 운영하고 있는데요. 오늘은 Active-Active를 유지하기 위해 필요한 양방향 데이터 ..