여나리 개발 일지

게시글 조회수 설계 고민과 이 과정에서 Redis를 선택한 이유와 방식에 대해 작성해두려고 한다. 조회수 설계어뷰징 방지 정책사용자는 게시글당 10분에 1번만 조회수로 집계 / 10분 동안 같은 게시글을 100번 조회해도 조회수는 1번만 증가데이터의 중요도와 일관성 - 조회수는 다른 데이터(댓글 수, 좋아요 수 등)처럼 정확해야 하는 데이터가 아니다. 즉, 약간의 불일치가 발생해도 사용자 경험에 큰 영향을 미치지 않는다.게시글/댓글/좋아요 수 : 원본 데이터를 기반으로 개수가 파생되므로, 불일치가 발생하면 안 된다.조회수 : 사용자가 직접 확인할 수 없으며, 정확한 개수보다 트래픽 분산이 중요하다.데이터 저장 방식 - 조회수는 단순한 카운트 값이므로, 비정규화된 단일 레코드로 저장해도 충분하다.SQL에 ..

좋아요 수 설계 고민과 어떤 식으로 진행했는지 해결 방법에 대해 작성해두려고 한다. 좋아요 수 설계좋아요 수는 실시간으로 빠르게 조회되어야 한다.좋아요가 생성/삭제될 때마다 미리 좋아요 수를 갱신하는 방식이 필요하다.좋아요 테이블에서 게시글별 좋아요 수를 미리 비정규화하여 저장하는 방안을 고려한다.게시글 테이블에 좋아요 수 칼럼 추가?장점게시글과 좋아요 수가 1:1 관계이므로, 비정규화가 어색하지 않다.데이터 조회 시 추가적인 조인이 필요 없어 성능적으로 유리할 수 있다.문제점Record Lock 및 분산 트랜잭션 문제좋아요 수가 업데이트될 때마다 게시글 테이블의 동일한 행이 갱신되므로 동시성 제약이 발생할 수 있다.트래픽이 많아지면 Lock 경합이 심해져 성능 저하가 발생할 수 있다.분산 환경에서 트랜..

데이터베이스에서 Primary Key(PK)는 각 레코드를 고유하게 식별하는 중요한 요소이다. 특히 분산 데이터베이스 환경에서는 PK 생성 전략이 데이터 정합성과 성능에 큰 영향을 미친다. 이번 포스팅에서는 다양한 PK 생성 전략을 비교하고, 프로젝트에서 Snowflake 기반의 유니크 정렬 숫자 방식을 선택한 이유에 대해서 알아보자. Primary Key 생성 전략1. DB Auto Increment문제점분산 데이터베이스 환경에서 PK 중복 가능성 - 여러 샤드에서 동일한 PK가 생성될 수 있어 유일성이 보장되지 않음클라이언트에 노출될 경우 공격자가 데이터를 예측할 수 있음예) 방금 가입했더니 user_id가 100이면 100명의 사용자가 있다고 예측 가능함유리한 상황보안적 문제를 크게 고려하지 않는 ..

이전 포스팅에서 대규모 시스템을 보다 효율적으로 운영하기 위해 사용되는 MSA를 선택했다고 설명했다. 대규모 시스템에서는 데이터베이스 관리 또한 중요한 과제로, MSA를 활용하는 시스템에서는 이에 맞춰 확장 가능하도록 설계되어야 한다. 따라서 분산 관계형 데이터베이스 개념과 그중에서도 샤딩 기법에 대해 알아보자. 대규모 데이터베이스에서의 확장성 문제서비스가 활성화됨에 따라 단일 데이터베이스에서 모든 요청을 처리하기에는 부담이 커진다. 확장성을 고려할 때 다음 두 가지 방법이 있다.Scale-Up (수직 확장): 서버의 성능을 높여 더 많은 요청을 처리하도록 하는 방법이다. 하지만 하드웨어적인 한계로 인해 무한정 확장이 어렵고 비용이 많이 든다.Scale-Out (수평 확장): 여러 개의 서버를 사용하여 ..

오늘은 내가 진행할 프로젝트에 적용하려는 마이크로서비스 아키텍처(MSA)에 대해 알아보고, 왜 이 아키텍처를 선택했는지에 대해 살펴보려고 한다. 기존의 모놀리식 아키텍처에서 벗어나 여러 개의 독립적인 서비스로 구성된 시스템을 만드는 것이 프로젝트에 어떤 이점을 줄 수 있는지 정리해 보자. 모놀리식 아키텍처(Monolithic Architecture)애플리케이션의 모든 기능과 비즈니스 로직이 하나의 프로젝트로 통합된 형태 전통적인 방식으로, 하나의 코드베이스에서 모든 기능이 실행되며, 모든 프로세스가 긴밀하게 결합되어 있다.이러한 구조에서는 애플리케이션의 한 프로세스에 대한 수요가 급증하면 해당 아키텍처 전체를 확장해야 한다.  장점소규모 프로젝트에서는 합리적이다.개발, 빌드, 배포, 테스트가 단순하여 빠..