본문 바로가기

분류 전체보기

(62)
65. 초당 100만 이벤트로 개인화를 만든다: 에어비앤비 User Signals Platform 아키텍처 분석 원문: Building a User Signals Platform at Airbnb — Kidai Kwon 외, The Airbnb Tech Blog 이 글은 원문의 내용을 아키텍처 중심으로 재구성하고, 설계 의도와 트레이드오프에 대한 제 해석을 덧붙인 글입니다. 들어가며"방금 본 숙소와 비슷한 곳", "찜한 곳의 가격이 내려갔어요" 같은 개인화는 사용자 입장에선 그냥 자연스러운 기능처럼 보입니다. 하지만 이걸 초당 100만 건의 이벤트 규모에서, 1초 이내의 지연으로, 그것도 스트림 처리를 모르는 팀들도 직접 만들 수 있게 제공하려면 이야기가 완전히 달라집니다.에어비앤비는 이 문제를 USP(User Signals Platform) 라는 사내 플랫폼으로 풀었습니다. 이 글에서는 USP를 세 가지 관점으로..
64. MySQL 샤딩을 미들웨어에 맡기다. (2·완) — Vitess 아키텍처와 도입 판단 기준 원문: Scaling YouTube's Backend: The Vitess Trade-offs — @Scale 2014 (Sugu Sougoumarane)이 글은 위 발표를 재구성한 2부작 중 2편(해법편) 입니다.1편: MySQL 한 테이블에 수년간 로그를 쌓으면 생기는 일2편: Vitess 아키텍처, 운영 자동화, 그리고 우리 팀은 써야 할까 (현재)1편 요약: 우리는 여기까지 왔다1편에서는 단일 MySQL이 무너지는 과정을 따라갔습니다. 배송 시스템(TMS)과 물류센터 입고 시스템(WMS Inbound)은 서로 완전히 분리된 별개 시스템이지만, 각자의 작업 로그 테이블이 독립적으로 똑같은 벽에 부딪혔습니다. 수십억 행·수백 GB에 도달한 테이블에서는 ALTER TABLE 한 번이 수 시간짜리 작업이..
63. MySQL 한 테이블에 수년간 로그를 쌓으면 생기는 일 (1/2) — YouTube가 Vitess를 만든 이유 원문: Scaling YouTube's Backend: The Vitess Trade-offs — @Scale 2014 (Sugu Sougoumarane)이 글은 위 발표를 재구성한 2부작 중 1편(문제편) 입니다.1편: 단일 MySQL이 무너지는 과정과 각 단계의 트레이드오프 (현재)2편: Vitess 아키텍처와 운영 자동화, 그리고 도입 판단 기준들어가며: 어느 물류 시스템의 작업 로그 테이블배송 시스템(TMS)과 물류센터 입고 시스템(WMS Inbound)은 서로 완전히 분리된 시스템입니다. 담당 조직도, 코드베이스도, 데이터베이스도 다릅니다. 배포 주기도 따로 돌아갑니다.그런데 이 두 시스템에는 묘한 공통점이 있습니다. 각자 자기 도메인의 모든 작업을 로그로 남긴다는 것, 그리고 그 로그 테이블이..
62. Netflix는 1억 명의 시청 기록을 어떻게 저장할까? — Cassandra 시계열 데이터 스토리지 확장기 Netflix Tech Blog의 «Scaling Time Series Data Storage» Part I(2018.01) · Part II(2018.11)를 재구성한 글입니다.하루 1억 4천만 시간 분량의 시청 데이터를 저장하기 위해 Netflix가 거쳐온 세 번의 아키텍처 진화를 따라가 봅니다.1. 시작하기 전에: 이 글에서 얻어갈 것시계열 데이터를 Cassandra에 저장할 때 "한 유저 = 한 로우" 모델이 왜 무너지는가Live / Compressed 분리와 롤업(rollup) 패턴의 동작 원리초대형 데이터를 다루는 청킹(chunking) + 병렬 읽기/쓰기 전략데이터의 종류(type) · 나이(age) · 상세도(level of detail) 를 기준으로 클러스터를 쪼개는 3차원 샤딩우리 서비..
61. 코틀린으로 배우는 디자인 패턴 (4·완) — 행동 패턴: Chain of Responsibility, Command, Iterator, Mediator, Memento 시리즈 안내1편 — 생성 패턴: Abstract Factory, Builder, Prototype, Singleton2편 — 구조 패턴 ①: Adapter, Bridge, Composite, Decorator3편 — 구조 패턴 ②: Facade, Flyweight, Proxy4편 — 행동 패턴: Chain of Responsibility, Command, Iterator, Mediator, Memento (현재 글)들어가며시리즈 마지막 편입니다. 생성 패턴이 "어떻게 만드는가", 구조 패턴이 "어떻게 엮는가"였다면, 행동 패턴은 "객체들이 어떻게 협력하는가"를 다룹니다.앞의 두 분류가 주로 클래스 관계도의 문제였다면, 행동 패턴은 런타임에 흐르는 요청과 상태의 문제입니다. 그래서 이번 편은 예제를 물류 ..
60. 코틀린으로 배우는 디자인 패턴 (3/4) — 구조 패턴 ②: Facade, Flyweight, Proxy 시리즈 안내1편 — 생성 패턴: Abstract Factory, Builder, Prototype, Singleton2편 — 구조 패턴 ①: Adapter, Bridge, Composite, Decorator3편 — 구조 패턴 ②: Facade, Flyweight, Proxy (현재 글)4편 — 행동 패턴: Chain of Responsibility, Command, Iterator, Mediator, Memento들어가며구조 패턴의 나머지 세 가지입니다. 2편에서 "구조 패턴은 코드 모양이 다 비슷하고 의도만 다르다"고 했는데, 이번 편의 Proxy가 그 말의 결정판입니다. Decorator와 코드가 글자 단위로 같을 수도 있습니다.그래서 이번 편은 마지막에 구조 패턴 7개를 한 표로 정리하고 갑니다...
59. 코틀린으로 배우는 디자인 패턴 (2/4) — 구조 패턴 ①: Adapter, Bridge, Composite, Decorator 시리즈 안내1편 — 생성 패턴: Abstract Factory, Builder, Prototype, Singleton2편 — 구조 패턴 ①: Adapter, Bridge, Composite, Decorator (현재 글)3편 — 구조 패턴 ②: Facade, Flyweight, Proxy4편 — 행동 패턴: Chain of Responsibility, Command, Iterator, Mediator, Memento들어가며1편에서 다룬 생성 패턴이 "객체를 어떻게 만드는가"였다면, 구조 패턴은 "이미 만들어진 객체들을 어떻게 엮는가"를 다룹니다.구조 패턴을 관통하는 도구는 하나입니다. 합성(composition). 네 패턴 모두 "다른 객체를 필드로 들고 있으면서, 그 객체에 일을 넘긴다"는 골격을 공유..
58. 코틀린으로 배우는 디자인 패턴 (1/4) — 생성 패턴: Abstract Factory, Builder, Prototype, Singleton 시리즈 안내1편 — 생성 패턴 (현재 글)2편 — 구조 패턴 ①: Adapter, Bridge, Composite, Decorator3편 — 구조 패턴 ②: Facade, Flyweight, Proxy4편 — 행동 패턴: Chain of Responsibility, Command, Iterator, Mediator, Memento들어가며디자인 패턴은 "이런 상황에서는 보통 이렇게 풉니다"라는 선배 개발자들의 관습을 이름 붙여 정리해 둔 카탈로그입니다. 새로운 기술이 아니라 공통 어휘에 가깝습니다. 코드 리뷰에서 "여기 데코레이터로 빼는 게 낫지 않을까요?" 한마디로 설명이 끝나는 것, 그게 패턴을 아는 실익입니다.다만 자바 기준으로 쓰인 패턴 설명을 코틀린에 그대로 옮기면 어색해집니다. 코틀린은 GoF ..

반응형