2022-10-05-TIL
2022-10-05-TIL
Today I Learned
Web Server Architecture
확장 가능한 웹 서비스 구조를 다룬 자료를 모았다. NAVER D2의 “확장성 있는 웹 아키텍처와 분산 시스템”은 『The Architecture of Open Source Applications』의 “Scalable Web Architecture and Distributed Systems” 장을 번역한 글이다. 웹 시스템 설계에서 가용성, 성능, 신뢰성, 확장성, 관리 용이성, 비용을 함께 고려해야 한다는 관점에서 서비스 분리, 중복(redundancy), 파티셔닝, 캐시, 프록시, 인덱스, 로드밸런서, 큐 같은 구성 요소를 설명한다.
기본 구성 요소를 하나씩 짚는 글은 9월 5일 TIL에도 정리했다. InfoQ 발표는 Spotify가 광고 서빙 시스템을 대규모로 개편한 사례다.
- https://62che.com/blog/architecture/%EC%84%9C%EB%B2%84-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%EC%84%A4%EA%B3%84.html
- https://d2.naver.com/helloworld/206816
- https://kschoi.github.io/cs/the-basic-archtecture-concepts/
- https://www.infoq.com/presentations/spotify-ad/
Instagram Architecture
인스타그램 같은 사진 공유 서비스의 구성 요소와 연결 관계를 그린 자료다. 시스템 설계 관점의 정리(사진 저장소 분리, 읽기·쓰기 경로 분리, 피드 생성 방식)는 8월 24일 TIL에 적었다. 첫 번째 링크는 현재 열리지 않는다.
- https://medium.com/interviewnoodle/instagram-system-architecture-fdbec22e48ee
- https://www.researchgate.net/figure/The-components-and-connectors-of-Instagram-architecture_fig1_266655113
Spotify Architecture
Spotify 엔지니어링 블로그의 이벤트 전달 시리즈는 음악 스트리밍 서비스의 데이터 수집 구조를 보여 준다. 사용자가 곡을 듣거나 아티스트를 검색할 때마다 클라이언트가 작은 이벤트를 서버로 보내고, 이 이벤트를 전 세계 클라이언트에서 중앙 처리 시스템까지 유실 없이 옮기는 것이 이벤트 전달(event delivery) 문제다. A/B 테스트, 추천(Discover Weekly), 정산 같은 기능이 이 데이터에 의존한다. 1편은 기존 시스템과 운영하며 얻은 교훈을, 이후 편은 Google Cloud Pub/Sub을 전송 수단으로, Dataflow를 소비 단계로 쓰는 새 시스템 설계를 다룬다.
- https://www.nicepng.com/maxp/u2w7t4y3e6w7y3o0/
- https://engineering.atspotify.com/2016/02/spotifys-event-delivery-the-road-to-the-cloud-part-i/
- https://engineering.atspotify.com/2016/08/commodity-music-ml-services/
- https://medium.com/geekculture/spotify-system-architecture-6bb418db6084
- https://www.youtube.com/watch?v=L14enOBwi1A
Streaming Service Architecture
미디어 스트리밍 서비스는 대략 수집(원본 업로드), 처리(트랜스코딩으로 여러 해상도·비트레이트 생성, 패키징), 저장, 전송(CDN), 재생(클라이언트가 네트워크 상황에 맞춰 품질을 바꾸는 적응형 스트리밍) 단계로 나뉜다. 라이브 스트리밍은 여기에 지연 시간 제약이 더해진다. Azure의 라이브 스트리밍 솔루션 아이디어 문서와 Alibaba Cloud 글이 이 흐름을 클라우드 서비스 구성으로 보여 주고, DataArt 자료는 음악 스트리밍에서 데이터 파이프라인이 메우는 공백을 다룬다.
- https://www.alibabacloud.com/forum/read-573
- https://learn.microsoft.com/en-us/azure/architecture/solution-ideas/articles/digital-media-live-stream
- https://www.dataart.com/media/jssfaiux/dataart-bridging-the-gaps-in-music-streaming-with-data-pipelines.pdf
Data Ingestion Pipeline
데이터 수집(ingestion) 파이프라인은 여러 소스의 데이터를 받아서 정해진 형식으로 정규화한 뒤 저장소에 적재하는 과정이다. 소스마다 형식이 다르기 때문에 적재 직전에 변환 단계를 두는 경우가 많다. Elasticsearch(OpenSearch)의 ingest pipeline이 그 예로, 색인 시점에 grok, set, remove, drop, script 같은 프로세서를 차례로 적용해 필드를 추출하거나 정리하고, 형식이 맞지 않는 데이터는 따로 분리할 수 있다(AWS Big Data Blog). 음원 서비스라면 유통사에서 들어오는 곡 메타데이터와 음원 파일이 대표적인 수집 대상이다.
- https://heung-bae-lee.github.io/2020/03/01/data_engineering_09/
- https://aws.amazon.com/ko/blogs/big-data/normalize-data-with-amazon-elasticsearch-service-ingest-pipelines/
- https://www.quora.com/What-is-the-data-ingestion-process-on-large-music-stores
DDEX
DDEX(Digital Data Exchange)는 디지털 미디어 유통 과정에서 메타데이터를 만들고 관리하고 주고받는 방식을 표준화하는 단체다. 음반사, 유통사, 스트리밍 플랫폼이 회원으로 참여한다. 대표 표준으로 새 음원 발매 정보를 전달하는 ERN(Electronic Release Notification), 판매·재생 실적을 보고하는 DSR(Digital Sales Reporting) 메시지 등이 있다. 각자 다른 형식으로 메타데이터를 주고받으면 연동마다 변환기를 만들어야 하므로, 공통 XML 스키마로 이 비용을 줄이는 것이 목적이다(DDEX: Purpose).
- https://ddex.net/
댓글
아직 댓글이 없습니다