시작하며먼저 규모 확장성이 있는 시스템이 무엇일지 고민해 보았습니다.트래픽이 많이 늘어나더라도 안정적으로 동작하는 시스템.트래픽 변화에 맞게 진화 하는 시스템. 반복적으로, 수평적으로 확장할 수 있어야 함.수직적으로 확장할 수 있어도 규모 확장성 아니냐고 의문을 던질 수 있습니다. 수직적 확장이 좋지 않은 이유는 크게 2가지로, 하드웨어의 수직적 확장에 분명 한계가 존재한다는점, SPOF 문제가 발생한다는 점을 들 수 있을 것 같습니다.규모 확장성이 있는 시스템의 설계는 초기단계부터 고려되어야 합니다. 설계가 잘못되었으나, 지속적으로 서비스가 성장하고 데이터가 쌓여가는 경우에, 레거시로 인해 아예 시스템을 새로 만드는게 나을 것이라는 이야기가, 실제 사례들이 괜히 있는 것이 아니겠죠.어떻게 설계해야 규모..
전공자라면 스택과 힙에 대해서는 당연히 공부해 봤을 것입니다. 저 또한 그렇고요. 하지만, 내가 정말 이에 대하여 빠삭하게 이해하고 있는 것일까요? 확신이 들지 않습니다. 스스로에게 질문을 던져봅시다.스택이 뭐고, 힙은 뭐죠? 스택은 자료구조 시간에서도 배우죠. Problem Solving, 알고리즘 문제를 풀 때도 자주 활용하고요. 가장 먼저 생각나는 특징을 살펴보자면, LIFO (Last In First Out), 먼저 삽입된 요소가 가장 나중에 추출된다는 특징을 가지고 있습니다.이렇게 접근하니, 스택은 무언가 요소를 담았다가 뺄 때 사용되는 자료구조와 같이 느껴집니다. 이는 사실일까요? 함수 재귀 호출또한 스택에 쌓이는 방식으로 진행됩니다. 가장 먼저 호출된 함수가 가장 마지막에 리턴되죠.네, 스택..
책을 읽고 중요한 부분을 기록하고, 이해가 부족했던 부분을 탐구합니다.예상 독자는 같은 책의 같은 내용을 읽은 분들로, 편의상 상세 내용은 생략합니다.2021년 3월 기준 구글 맵의 DAU 는 10억 명이라고 합니다. 이 장에서는 구글 맵의 다양한 기능 중 다음 세가지 기능에 집중하여 설계합니다.사용자 위치 갱신경로 안내 서비스 (Estimated Time of Arrival, ETA 서비스 포함)지도 표시문제 이해 및 설계 범위 확정지오코딩지오코딩은 주소를 지리적 측위 시스템의 좌표로 변환하는 프로세스입니다. 1600 Amphitheatre Parkway, Mountain View, CA 의 지오코딩 결과는 (위도 37.423021, 경도 -122.083739)가 되는 식이죠.경로 안내 알고리즘을 위한..
책을 읽고 중요한 부분을 기록하고, 이해가 부족했던 부분을 탐구합니다.예상 독자는 같은 책의 같은 내용을 읽은 분들로, 편의상 상세 내용은 생략합니다.계략적 설계안10억 명의 사용자로 가정,1억 DAU 로 가정,동시 접속 사용자는 10% 로 가정, 1,000 만사용자는 30초마다 자기 위치를 시스템에 전송한다.위치 정보 갱신 QPS = 천만 / 30 =~ 334,000QPS 계산은 늘 흥미롭습니다.이제 여기서 인당 400 명의 친구를 갖는다고 가정하고, 그 가운데 10%가 인근에서 활성화 상태라고 가정하면,334,000 * 400 * 10 % = 1,400만즉, 초당 1,400 만 건의 위치 정보 갱신 요청이 처리되어야 하는 것입니다.이와 같은 시스템 설계에 초경량 메시지 버스 레디스 펍/섭이 아주 주요..
가상 면접 사례로 배우는 대규모 시스템 설계 기초 2권의 1장, 근접성 서비스 관련 내용에서 다음과 같은 설명을 보았습니다.지오해시 테이블은 샤딩이 까다로우므로, 면접 시에 이야기하지 않는 것이 좋다. 샤딩 로직을 애플리케이션 계층에 구현해야 하기 때문이다.??? 사실 잘 이해가 되지 않아요.. 지오해시 테이블은 왜 샤딩이 까다로운지, 샤딩 로직을 애플리케이션 계층에 구현해야 한다는 것이 무슨 소린지. 아 애초에, 사실 샤딩 자체를 제대로 이해하고 있지 못한 것을 깨달았습니다.샤딩에 대한 이해로부터, 일반적인 샤딩이란 어떤건지, 그래서 왜 지오해시 테이블은 샤딩이 까다로운 건지 이해해보고 싶어졌습니다.내가 아는 샤딩이란?이곳저곳에서 주워 들어 이해한 바로는, 여러 데이터베이스 서버에 같은 스키마 구조를 ..
김영한님의 자바 ORM 표준 JPA 프로그래밍 책에서, 트랜잭션을 지원하는 쓰기 지연 부분이 이해가 안되어서 공부한 내용이다.혹시 제목이 너무 당연하게 느껴진다면, 전혀 읽을 필요가 없는 포스팅임을 미리 밝힌다.책 몇판 몇쇄인지에 따라 페이지가 다를 수 있겠지만, 내 책 기준 690P 트랜잭션을 지원하는 쓰기 지연과 애플리케이션 확장성 파트를 읽는데 이해가 잘 안되었다. 결론 부터 말하자면, 이해가 안된 이유는 나의 DBMS 시스템에 대한 이해 부족때문이었다.우선, 다음과 같은 책의 설명을 보자.트랜잭션을 지원하는 쓰기 지연과 애플리케이션 확장성책의 내용을 간추렸습니다.JPA 의 트랜잭션을 지원하는 쓰기 지연과 변경 감지 기능의 진짜 장점은 데이터베이스 테이블 로우에 락이 걸리는 시간을 최소화..
제목 그대로의 문제 상황에 맞닥뜨렸다고 가정해 보자. 이러한 서비스의 성능을 개선해야 할 때 고려할 수 있는 방식은 정말 많을 것이다. 그 중 어떤 방식이 성능을 개선하는데 큰 영향을 줄 수 있을지 고민해보고, 각 개선안에 장단점을 비교해보자.이는 오직 백엔드 개발 관점에서 생각하고 작성한 글이다. 이와 같은 문제를 개선하는데엔 프론트엔드 측면이나, 정책적인 변경 등 다양한 해결책이 있을 수 있다는 점을 염두에 두자.페이지네이션만 잘 적용해도 성능이 상당히 좋아질 질 것 같은데? 처음부터 어렵게 접근하지 말고, 아주 단순한 게시판 서비스라고 생각해보자. 게시글이 늘어날 수록 처음 게시글 목록의 가짓 수도 늘어날텐데, 만약 페이지네이션이 적용이 되어있지 않고, 모든 게시글 데이터를 읽어오는 상황일 수..
Q. 어떤 게시글에 여러 사람이 동시에 댓글을 다는 일은 흔하다. 만약 게시글 테이블에서 칼럼으로 댓글 개수를 기록하고 있으면, 트랜잭션을 어떻게 활용해야 동시성 문제를 해결할 수 있을까? A-1. 트랜잭션 격리 수준 트랜잭션의 격리 수준은 여러 트랜잭션이 동시에 같은 데이터에 접근할 때 발생할 수 있는 문제들을 어떻게 격리시킬지를 정하는 설정입니다. 격리 수준에는 여러 옵션이 있지만, 주로 다음 네 가지 수준을 사용합니다: READ UNCOMMITTED - 가장 낮은 격리 수준으로, 다른 트랜잭션에서 커밋하지 않은 데이터도 읽을 수 있습니다. READ COMMITTED - 커밋된 데이터만 읽을 수 있어, "dirty reads"는 방지하지만 "non-repeatable reads"는 발생할 수 있습니다..
