look-forest

기본적인 마이크로서비스 구축프로젝트 아키텍처실무에서 쓸 MSA를 구축하려면 각 Service와 DB를 전부 독립적인 서버에 실행시켜야 한다.하지만 프로젝트의 심플함을 위해 로컬 컴퓨터 한 대에서 포트 번호만 다르게 해서 실행시킬 것이다 DB설계[모놀리식 아키텍처]모놀리식 아키텍처에서는 위 그림과 같이 user_id를 참조한 채로 DB를 설계하게 된다. [마이크로서비스 아키텍처]하지만 마이크로서비스에서는 DB가 독립적으로 분리되어 있기 때문에 user_id를 참조할 수 없다.하지만 특정 게시글이 어떤 사용자의 게시글인지 파악하기 위해 user_id에 대한 정보는 있어야 한다. 따라서 boards 테이블에서 user_id는 FK를 설정하지 않은 채로 컬럼을 생성하면 된다. MSA에서는 DB를 독립적으로 분리..

MSA(Microservice Architecture)란?하나의 큰 애플리케이션을 여러 개의 작고 독립적인 서비스로 나누어 개발하고 배포하는 소프트웨어 개발 아키텍처. 프로젝트 하나에 모든 API(결제 관련 API, 인증 관련 API, 상품 관련 API)를 전부 구현하는 모놀리식 아키텍처 방식과 비교해보자.이에 반해, 마이크로서비스 아키텍처(MSA)는 서비스에 필요한 API들을 하나의 프로젝트가 아닌 여러 개의 프로젝트로 나눠서 구현하는 방식이다. 아래 그림을 보면 결제 관련 API들끼리 모아놓은 프로젝트와, 인증 관련 API들끼리 모아놓은 프로젝트와, 상품 관련 API들끼리 모아놓은 프로젝트를 분리해서 구성했다. 그리고 MSA에서는 독립적으로 분리된 하나의 프로젝트를 서비스(service)라고 부른다...

조회 수 기능 구현을 통해 대규모 시스템에서 Redis를 어떻게 활용하는지 알아보자.조회수 어뷰징 방지 정책은 다음과 같다.- 각 사용자는 게시글 1개 당 10분에 1번 조회 수 집계조회수 설계조회 수는 게시글 수나 좋아요 수와는 달리, 다른 데이터의 개수로 파생되는 것이 아니다.좋아요 수에 비해 데이터 일관성이 덜 중요하고, 쓰기 트래픽이 비교적 많다.(게시글 조회만만 해도 트래픽이 증가하므로)따라서 디스크 접근 비용과 트랜잭션 관리 비용을 감수할 필요가 없다.따라서, In-memory Database를 사용해 볼 수 있고, 많이 사용되는 Redis를 사용하자.인기글 선정 시 필요하므로, 자체적인 백업 시스템도 간단히 구축해본다.(Redis에 저장된 데이터를 MySQL에 직접 백업)RedisIn-mem..

게시글에 '좋아요' 기능을 추가하면서, 동시성 문제에 대해 알아보자.사용자가 게시글에 '좋아요'를 추가/해제하는 작업과, 게시글마다 좋아요 수를 조회하는 것이 있다.좋아요 설계사용자는 게시글 하나에 좋아요 하나를 누를 수 있으므로, 제약조건으로써 (게시글ID + 사용자ID)로 유니크 인덱스를 만들면 된다.그리고 적절한 분산 단위로서, Shard key는 게시글ID로 한다. 구현@Service@RequiredArgsConstructorpublic class ArticleLikeService { private final Snowflake snowflake = new Snowflake(); private final ArticleLikeRepository articleLikeRepository; public A..

댓글 기능을 통해 계층형 구조에서 어떻게 페이징을 처리할 수 있는지 알아보자. 댓글 계층 구조를 데이터베이스에 표현하는 주요 설계 방식은 2가지로 나눌 수 있는데,depth에 따라 Adjacency List(최대 2 depth)와 Path Enumeration(무한 depth)로 나눌 수 있고, 각 방식은 데이터 구조가 다르다.댓글 목록 조회 - 최대 2 depth Adjacency List (인접 리스트) 방식단순히 시간 순으로 나열할 수 없다. 계층에 대한 고려가 필요하다.단순히 댓글의 생성 시간(commentId)로 정렬하면 안된다. 계층 관계에서는 더 늦게 작성된 대댓글이 먼저 노출될 수 있기 때문. 댓글이 조회되는 규칙을 살펴보자.1. 상위 댓글은 하위 댓글(대댓글)보다 반드시 먼저 생성된다.2..

게시글 CRUD API를 만들고, 대용량 데이터를 조회하는 상황을 가정하자.테이블 구조는 다음과 같다.분산 데이터베이스를 가정하기 때문에 게시글이 N개의 샤드로 분산되는 상황을 고려한다.Shard Key = board_id (게시판 단위로 게시글 목록을 조회하므로)Hash-based Sharding이라고 가정Primary Key는 오름차순 유니크 숫자를 애플리케이션에서 직접 생성한다. (Snowflake, TSID 등)페이징대규모 데이터에서 게시글 목록 조회는 왜 복잡할까?모든 데이터를 한 번에 보여줄 수 없다. (메모리, 네트워크, 성능 상 제약)=> 페이징 필요 페이징 처리를 하려면?디스크에 저장된 모든 데이터를 메모리로 가져오고, 특정 페이지만 추출하는 것은 비효율적디스크 I/O 비용메모리 용량 초..

분산 데이터베이스 환경에서는 PK를 어떻게 생성하면 좋을까?나는 당연히 auto_increment가 간단하고 좋을 것이라고 생각했다. 후보DB auto_increment유니크 문자열 or 숫자유니크 정렬 문자열유니크 정렬 숫자DB auto_increment문제점1. 분산 데이터베이스 환경에서 DB auto_increment를 쓸 경우, PK가 중복될 수 있기 때문에 식별자의 유일성이 보장되지 않는다!2. 클라이언트 측에 노출하면 보안 문제(데이터 개수 또는 특정 시점의 식별자 예측 가능) ex) 방금 가입했더니 user_id가 1000이라면 -> 1000명의 회원이 있음 유추 가능 장점간단하므로 다음 상황에서 유리보안적인 문제를 크게 고려하지 않는 상황단일 DB를 사용하거나 애플리케이션에서 PK ..

데이터베이스 트래픽을 분산하는 방법(Sharding), 고가용성을 확보하는 방법(Replica)을 알아보자.분산 데이터베이스서비스가 활성화 되면서 DB에 저장할 데이터와 트래픽이 많아졌다.먼저 Scale-Up을 적용했으나 얼마 후 서비스가 더욱 활성화되면서 단일 DB로 처리하기엔 부담이 커졌다.Scale-Out을 적용해 DB를 하나 더 늘렸다. 그렇다면, 데이터는 각 DB에 어떻게 분산될 수 있을까?Sharding샤딩을 이용해 데이터를 여러 DB에 분산할 수 있다.Sharding: 데이터를 여러 데이터베이스에 분산하여 저장하는 기술Shard: 샤딩된 각각의 데이터 단위샤딩을 이용하면각 샤드에 데이터가 분산 저장되므로 성능 및 공간 이점이 생긴다.하지만, 데이터의 분리로 인해 조인 및 트랜잭션 관리가 복잡..