유튜브, 우버, 틱톡, 인스타그램과 같은 서비스들은 어떻게 억 단위의 사용자를 처리할까? 🤔이러한 서비스들은 처음부터 완벽한 시스템으로 설계되지 않았습니다. 대규모 트래픽을 처리하고 급성장에 대응하기 위해서는 확장 가능한 시스템 설계 원리를 따르는 것이 중요하다. 초창기 출시부터, 아키텍처를 개선하는 시나리오를 통해 어떻게 설계하는지 알아보도록 하자. 아키텍처MVP 출시하기먼저, 최소한의 기능만을 갖춘 MVP(Minimum Viable Product)를 출시하는 것이 중요하다.모든 기능을 먼저 고려하면 오버헤드가 발생할 수 있고, 결국 사용자가 원치않는 기능들을 만들 수 있다는 이유이다.API 규격 선정: API 규격을 먼저 논의하여 개발 방향을 일치시킵니다.스크럼 기반 개발: 스크럼 기반으로 스프린트..

사내 프로젝트를 처음 맡았을 때 싱글 모듈로 구조를 잡아 시작했고,패키지 내 응집도가 견고해졌을 시점에 멀티 모듈로 분리를 하여 멀티 모듈 시스템이 만들어졌습니다. 그래서 현재는 지속 성장 가능한 시스템을 만들기 위해 모듈 마다 클린 아키텍처 개념을 포함시켜 개선해 나가고 있습니다. 클린 아키텍처와 멀티 모듈을 적용했으나 실제 구현 단계에 들어갔을 때, 수많은 난관이 발생했고 질문도 많이 떠올랐습니다.모듈이 가지는 모델 주도권을 어떻게 가져가고 공유할 수 있는지, 모듈마다 참조는 어디까지 하면 좋을지 등등 여러 고민이 발생했습니다. 이런 개념을 바로잡고자 문서를 작성하게 되었습니다.소스 코드 방향은 외부에서 내부로클린 아키텍처를 적용하는 이유를 찾아보면 내부를 최대한 안정적으로 유지하고, 외부를 변경 시..

사용자가 기존 데이터를 읽어 새로운 버전을 복사 생성하는 기능에서, 동일 사용자가 너무 빠르게 버튼을 눌러 동일한 데이터가 두 개 생성되는 문제가 발생했다. 이로 인해 불필요한 중복 요청과 함께 동일한 데이터가 공존하는 문제가 있었다. 기존 해결 방법 - DB Lock 사용초기에 이 문제를 해결하기 위해 데이터베이스에서 해당 Row에 Lock을 설정하여, 새로운 데이터가 커밋되기 전까지 동일한 데이터가 생성되지 않도록 조치했다.하지만 이 방법에는 단점이 있었다Lock 해제: 빠른 커밋이 발생하는 상황에서는 따닥 현상 해결을 보장하지 않음비정상적인 사용 패턴: 동일한 사용자가 짧은 시간내에 같은 CUD API를 여러 번 호출하는 것은 정상 요청이라고 보기 어려움새로운 데이터를 생성하는 요청에서는 Lock..

https://noose.tistory.com/38 이전 포스팅을 읽으면 도움이 됩니다. SpiceDB는 HTTP API 및 gRPC를 제공하고 있다.실무에서는 빠른 통신 속도를 위해 gRPC를 사용하는 것을 권장한다. gRPC 설정이 복잡해 보일 수 있지만, 공식 라이브러리를 활용하면 쉽게 적용할 수 있다.https://github.com/authzed/authzed-java GitHub - authzed/authzed-java: Official SpiceDB client library for JVM languagesOfficial SpiceDB client library for JVM languages. Contribute to authzed/authzed-java development by crea..

애플리케이션에서 권한 관리는 보안의 핵심 요소 중 하나다.예를 들어, 새로운 리소스를 생성할 때 누가 이 리소스를 소유하는지, 누가 읽거나 수정할 수 있는지를 명확하게 정의하고 검증해야 한다.하지만 권한 요구 사항이 복잡해질수록, 기존 RDBMS 기반의 접근 방식으로 이를 처리하는 것은 점점 더 어려워진다.일반적으로 RDB에서는 계층 구조를 표현하기 위해 부모 ID를 사용하지만, 시간이 지남에 따라 다음과 같은 문제가 발생할 수 있다.풀 스캔(Full Scan) 발생복잡한 조인으로 인한 성능 저하비즈니스 로직과 데이터 구조의 괴리로 인해 유지보수 난이도 증가이러한 문제를 해결하기 위해 등장한 것이 바로 SpiceDB다.SpiceDB는 권한 관리를 위해 설계된 특화된 데이터베이스로, 복잡한 권한 요구 사항..

사내에서 파일 업로드 기능을 두 가지 방식으로 제공하고 있습니다.서버에서 파일을 받고 S3에 업로드Presigned URL을 발급하고 클라이언트에서 Presigned URL로 직접 S3에 업로드문제첫 번째 방식은 구현이 간편하지만, 다음과 같은 CPU 사용 이슈가 있었습니다.속도 저하: 25MB PDF 파일 업로드 시 평균 4~6초 소요CPU 사용량 급등: 최대 80%, 평균 50%이를 해결하기 위해 Presigned URL 방식을 도입해 우회적으로 성능은 개선했지만, 또 다른 두 가지 문제가 발생했습니다.클라이언트 복잡성 증가: Presigned URL 관련 Flow 이해필요레거시 코드 호환성 문제: 기존 API를 사용하는 클라이언트 코드 수정의 불편함과 어려움현재 쿠버네티스 자원을 알뜰하고 사용하고 ..

이전 포스팅에서는 MongoDB 모델링에 대한 소개와 함께 OLTP 성 모델링을 어떻게 하면 좋을지에 대한 내용이었다.이번에는 더 다양한 사례를 정리한다.예측할 수 없는 행동 게임 로그 모델링게임 로그를 예로 들어, 예측할 수 없는 사용자 행동을 효과적으로 저장하고 분석할 수 있는 NoSQL 스키마 모델링 방법에 대해 알아보자 문제점: 비효율적인 배열 구조각 사용자들의 행동 패턴을 분석하기 위해 하루치 모든 행동을 기록한다고 가정해보자. 그러면 아래와 같은 형태의 스키마를 설계할 수 있다.{ "time": "2024-12-13", "visits": [], // 지역 방문 로그 "quests": [], // 퀘스트 로그 "trades": [], // 아이템 거래 로그 "...":..

스키마 모델링이란?MongoDB는 스키마리스(Schema-less) 데이터베이스로 잘 알려져 있지만, 데이터 모델링은 여전히 중요하다.애플리케이션 요구사항과 데이터베이스 성능 간의 균형을 맞추는 것이 핵심 과제이다.이번 포스팅에서는 스키마 설계를 통해 성능을 최적화하면서도 확장 가능한 구조를 만드는 방법에 대해 다룬다.Embedding vs ReferencingMongoDB 스키마 모델링에서 가장 먼저 마주하는 문제는 임베딩(Embedding)과 레퍼런싱(Referencing)이다.MongoDB의 기본 철학은 역정규화이지만, RDB를 주로 사용해왔던 입장에서는 낯선 방법이다. 아래 장단점을 통해 간단히 알아보자.Embedding (중첩, 내장)장점데이터가 한 문서 안에 있어 **조회 속도(read)**..

MongoDB를 선택하는 이유Schema가 자유롭다.HA와 Scale-Out Solution을 자체적으로 지원해서 확장이 쉽다.Secondary Index를 지원하는 NoSQL이다.다양한 종류의 Index를 제공한다.응답 속도가 빠르다.배우기 쉽고 간편하게 개발이 가능하다.데이터 중복이 발생할 수 있지만, 접근성과 가시성이 좋다.즉, MongoDB는 유연하고 확장성 높은 Opensource Document 지향 DB이다.SQL vs NoSQLSQL 장단점데이터 중복을 방지할 수 있다.Join 성능이 좋다.복잡하고 다양한 쿼리가 가능하다.잘못된 입력을 방지할 수 있다.하나의 레코드를 확인하기 위해 여러 테이블을 Join하여 가시성이 떨어짐스키마가 엄격해서 변경에 대한 공수가 큼NoSQL관계형 데이터베이스에..

사내에서 특정 Entity에 value 클래스를 도입해 사용하고 있다. 이 중에서 자리수가 중요한 사업자등록번호나 휴대폰 번호 같은 값은 value 클래스를 통해 유효성을 보장한다. 하지만 Kotlin JDSL 환경에서는 이러한 value 클래스를 직접 사용하기 위해 커스텀 시리얼라이저를 등록해야 한다. https://kotlin-jdsl.gitbook.io/docs/ko-1/faq/how-do-i-use-kotlin-value-class Kotlin value class 를 사용하려면 어떻게 해야할까요? | Kotlin JDSLLast updated 5 months agokotlin-jdsl.gitbook.ioKotlin JDSL 문서에 따르면, value 클래스의 필드를 사용하려면 기본적으로 시리얼라..