본문 바로가기

IT

(44)
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 ..
57. Netflix는 어떻게 초당 7만 5천 건의 이벤트를 카운팅할까? — Distributed Counter Abstraction 완전 분석 Netflix는 조회수, 좋아요, A/B 테스트 지표 등 매일 수십억 건의 이벤트를 카운팅합니다. 이 글에서는 Netflix Tech Blog에 소개된 Distributed Counter Abstraction의 아키텍처를 API 설계부터 캐싱, Rollup 파이프라인까지 단계별로 뜯어보고, 우리 서비스에 적용할 수 있는 인사이트를 정리합니다. 이 글에서 다룰 내용분산 카운팅이 왜 생각보다 어려운 문제인지Netflix가 정의한 두 가지 카운팅 요구사항 (Best-Effort vs Eventually Consistent)Counter Abstraction의 API 설계와 멱등성(Idempotency) 처리 방식Netflix가 검토했던 4가지 카운팅 구현 전략과 각각의 트레이드오프최종적으로 채택한 하이브리드 ..

반응형