DDIA: Chapter 1: 신뢰할 수 있고 확장 가능하며 유지보수 하기 쉬운 어플리케이션

해당 카테고리와 글은 데이터 중심의 어플리케이션 설계 책을 Pair reading하는 스터디의 결과물을 저장합니다. 사실 데이터라는 말에 혹해서 선택한 책이지만 백엔드 관점에서 이상적인 설계가 무엇인지 다루는 책이긴 합니다. 그럼에도 불구하고 한번 읽어보려고 용기있게 스터디를 모았습니다. 해당 스터디는 다음 템플릿을 이용해 매주 작성할 예정입니다.

---

1. 스터디 방안

• 모집인원: 최대 10명
• 기간
  • 매주 약 chapter 1개 분량( 40 ~ 60 page)
  • Part1: 2025. 02. 09(일) ~ 2025.03.02(일) / 총 4주
  • Part2: 2025. 03. 09(일) ~ 2025.04.06(일) / 총 5주
  • Part3: 2025. 04. 13(일) ~ 2025.04.27(일) / 총 3주
• 진행방식
  • 매 주 1단원씩 책을 읽고 다음 템플릿(NDA)를 이용하여 본인의 블로그, 노션, 줄글로 주차별 스레드 등에 작성합니다.
  • 새롭게 알게된 점(New)
  • 어려웠거나 이해하지 못한 부분(Difficulty)
  • 추가 내용(Amendment): 학습이 도움이 되었던 블로그, 유튭, 사례 등
• 매주 일요일 22시에 허들로 모셔 학습에 대한 간단한 talk을 합니다. 30분정도?

 

2. 본문

일단 본인은 CS를 그냥 아는 데이터 분석가임을 밝힙니다. 그럼에도 불구하고 CS지식을 읽는데 그렇게 어려움을 느끼진 않습니다. 하지만 본 책을 읽는데는 확실히 기초지식이 떨어지기 때문에 용어와 흥미로운 레퍼런스 위주로 찾아보면서 꼬리 학습을 진행할 예정입니다.

Part1는 데이터 시스템의 기초로 Chatper 1은 신뢰할 수 있고 확장 가능하며 유지보수하기 쉬운 어플리케이션 이라는 거창한 제목으로 시작합니다. 마지 완벽한 이상향을 찾는 것 같지만 그래도 이상향을 추구해야 남는 쪼가리라도 이쁜 것이니 한번 살펴보려고합니다.  여기서 말하고자하는 데이터 시스템의 3가지 요소는 신뢰성(Reliability), 확장성(Scalability), 유지보수성(Maintainability) 3가지 입니다.

3. New

• 메시지 큐(Messae Queue): 큐(Queue)를 이용해서 메세지를 전달하는 시스템이며 메시지 지향 미들웨어(MOM)을 구현한 시스템이다. 
  라고 합니다. 근데 솔직히  API와 구별점을 잘 못찾겠어서 물어봤습니다.

	메시지 큐(Message Queue)	API
정의	비동기적인 메시지를 주고 받을 수 있는 큐 시스템	한 시스템이 다른 시스템의 기능을 호출할 수 있도록 정의된 인터페이스
주요 특징	메시지를 임시 저장하고 필요한 시점에 소비 가능	실시간 요청 - 응답 방식으로 동작
예시	이메일 전송 요청 -> 메시지 큐에 저장 -> 이메일 서버가 가서 처리	사용자가 웹 사이트에서 버튼 클릭 -> 서버에 API 요청 전송 -> 응답 반환

둘이 동등 비교하는 항목은 아닌 것 같은데 가장 핵심적인 부분은 동기 & 비동기 시스템이지 않을까 라고 생각했습니다. Kafka 와 같은 소프트웨어가 메시지를 저장하고 처리하는 브로커의 대표명사인 것 같습니다. 

Core Components of a Message Queue

 

4. Difficulty

이번 챕터에서 흥미로우면서도 명확하게 이해하지못 한 것은 확장성 단원의 부하기술하기 - 트위터 사례입니다. 

트윗 작성과 홈 타임라인의 처리를 위한 기존 레거시 구조는 다음과 같다고 합니다.

1. 트윗 작성은 새로운 트윗 전역 컬렉션에 삽입한다. 사용자가 자신의 홈 타임라인을 요청하면 팔로우하는 모든 사람을 찾고, 이 사람들의 모든 트윗을 찾아서 시간순으로 정렬해서 합친다. 그럼 그림 1-2와 같은 관계형 데이터베이스 에서는 다음과 같이 질의를 작성한다.

2. 각 수신 사용자용 트윗 우편함처럼 개별 사용자의 홈 타임라인 캐시를 유지한다.(그림 1-3 참고) 사용자가 트윗을 작성하면 해당 사용자를 팔로우하는 사람들을 모두 찾고 팔로워 각자의 홈 타임라인 캐시에 새로운 트윗을 삽입한다. 그러면 홈 타임라인의 읽기요청은 요청 결과를 미리 계산했기 때문이 비용이 저렴하다.

 

하기 문단은 책의 해설을 보고 제가 생각한 내용입니다.

위 내용을 보면 결국 트위터는 1,2번을 혼합한(Hybrid) 구조로 만들었다고 합니다. 생각해보건데  1번 지문에서 팔로우하는 모든 사람을 찾고 부분이 full scan이며, 시간순으로 정렬한다는 점  시간복잡도 관점에서 성능이 떨어지는 요인에 기인하지 않았을까 생각이 들긴합니다.  1번은 홈타임라인을 보는 시점에 부하가 많고 2번은 트위터를 쓰는 시점에 부하가 많으므로, 팔로워가 매우 많은 소수 사용자들은 1번을 이용해 보는 시점에 리소스를 쓰고(수많은 팔로워가 한번에 보진 않을거고 시점을 나눠서 타임라인을 볼꺼니까?) 그리고 대부분의 사용자들은 팔로워가 적으니까 2번처럼 쓰는 시점에 부하를 높혀  상호보완적으로 하지 않았을까 라는 생각이 들었습니다.

5. Amendement

- 샌드박스(Sandbox): 라이브 환경에 영향을 미치지않고 소프트웨어나 어플리케이션을 테스트하고 개발할 수 있는 제어된 환경. 번역 그대로는 나무나 플라스틱으로 만들어진 모래가 담긴 공간이며 간이 놀이터라는 의미를 담고 소프트웨어 쪽에서 사용되는 듯.

흔히 정부사업에서 (규제) 샌드박스라는 단어가 등장하는데, 이는 특정 산업의 육성을 위해 일정구간 규제를 면제하거나 유예하는 것을 의미함. 토스는 "선불전자지급수단으로 상품 구매 시 결제부족분에 대한 소액후불 결제 서비스"의 서비스명으로 규제 샌드박스를 지정받고 성과 낸 경험이 있음

https://sandbox.fintech.or.kr/business/enterprise.do?lang=ko&id=236