Education*
Devops
Architecture
F/B End
B.Chain
Basic
Others
CLOSE
Search For:
Search
BY TAGS
linux
HTTP
golang
flutter
java
fintech
개발환경
kubernetes
network
Docker
devops
database
tutorial
cli
분산시스템
www
블록체인
AWS
system admin
bigdata
보안
금융
msa
mysql
redis
Linux command
dns
javascript
CICD
VPC
FILESYSTEM
S3
NGINX
TCP/IP
ZOOKEEPER
NOSQL
IAC
CLOUD
TERRAFORM
logging
IT용어
Kafka
docker-compose
Dart
Airbnb System design 분석
Recommanded
Free
YOUTUBE Lecture:
<% selectedImage[1] %>
yundream
2023-05-05
2021-10-28
15420
**인프런 [빅데이터 파이프라인 마스터 강의] 선착순 할인중** [기간내 신청하러 가기](https://www.joinc.co.kr/w/lecture_bigdata_pipeline) ## 들어가기 전에 소프트웨어 개발은 문서로 시작해서 문서로 끝난다. 이유는 아래와 같다. - 코드의 소유 - 동적 평형 모든 이의 코드스타일을 알고 있으며, 함께 수년 동안 하나의 솔류션을 개발해 왔다면, 눈빛만으로 무얼하는지 알고 있다면, 즉 이미 아키텍처와 코드를 전부 다 이해하는 팀이라면 문서는 필요 없을 수 있다. 초기에 소수의 창업멤버끼리 사업 모델과 코드를 함께 만든 경우가 되겠다. 하지만 극 초반이 지나면 이런 식의 코드(아키텍처)소유는 불가능해진다. 조직이 **동적으로 변화**하기 때문이다. 사업의 연속성을 확보하기 위해서 조직은 **동적 평형 상태**를 유지해야 한다. 동적 평형이란 외부에서 새로운 요소가 추가되고 내부에 있던 요소가 외부로 빠져나가더라도 건강함이 유지되는 상태다. 1. 비즈니스에 대한 요악 2. 제품 3. 마켓 분석 4. 핵심 기능 5. 도메인 모델 6. 전체 아키텍처 7. 마일스톤 이 문서로 정리가 되고, 이를 공유할 수 있는 조직이 되어야 변화, 새로운 것들을 받아들여야 하는 환경속에서도 건강함을 유지 할 수 있다. 개인도 이러한 조직에 있어야 한다. 왜냐하면 이러한 환경에 익숙해져 있어야 다른 회사에서도 그 상태에 들어갈 수 있기 때문이다. 평생직작이라는 개념이 없는 요즘에는 개인의 이러한 능력이 매우 중요하다. 이 문서는 Airbnb 시스템을 기반으로 하는데, 위에서 언급한 "코드의 소유"라는 관점에서 분석 할 것이다. ## Airbnb System 분석 우리가 분석하려는 문서다. [Airbnb System Design: Most frequently asked question in technical interviews](https://medium.com/@himanishaik48/airbnb-system-design-most-frequently-asked-question-in-technical-interviews-262e999f437) 분석은 아래와 같이 진행 할 것이다. 1. Airbnb 비즈니스 목적과 요구사항 2. Airbnb 비즈니스 목적을 달성하기 위한 시스템의 디자인 3. Airbnb 시스템을 위한 인프라 아키텍처 ## airbnb 소개 airbnb는 미국 샌프란시스코에서 시작한 **숙박 공유 서비스**다. 주로 관광객을 위한 홈스테이 서비스를 제공한다. 웹 사이트와 모바일 앱을 통해 액세스 할 수 있다. airbnb는 자산을 소유하지 않으며 숙박을 제공자로부터 수수료를 받아서 이익을 얻고 있다. 주택 임대료가 인상되었으며 임대 부동산 근처에 사는 사람에게 이런 저런 성가신 일을 야기할 가능성이 있다는 비판을 받아왔다. 실제 유럽연합과 샌프란시스코 및 뉴욕시와 같은 여러 지역에서 규제를 받고 있다. 호텔업계는 경쟁상대로 보고 있다. ## airbnb 서비스 모델 ![airbnb 서비스 모델](https://docs.google.com/drawings/d/e/2PACX-1vTS-7VjF6e9luK3pGxf92s-51671PYD9QzNhUznwhXRp-Tvz_6Tz3Y1N8ZrHWRKtwa0THzw4a-UJse1/pub?w=690&h=468) 여행자는 개인 생활 공간이 필요하다. Airbnb는 여행자들이 모바일 애플리케이션을 이용해서 개인이 생활할 수 있는 공간을 쉽고 빠르게 찾을 수 있도록 도와주는 플랫폼이다. Airbnb는 생산자와 소비자가 참여하는 양면서비스다. 생산자는 자신이 소유하고 있는 공간을 온라인에 노출하고 임대해서 수익을 얻을 수 있다. 다른 한편에 있는 소비자(여행자)는 쉽게 개인이 거주할 공간을 얻을 수 있다. Airbnb는 34,000개의 도시와 190개 국가에 1,500,000 이상의 광범위한 접근가능한 호스트를 가지고 있다. 따라서 소비자는 전세계에 실시간으로 머무를 곳을 구할 수 있다. ## Airbnb 서비스 프로세스 소비자와 호스트가 Airbnb 플랫폼을 이용해서 서비스를 제공하고 소비하는 일련의 과정을 다이어그램으로 나타내보자. 이 다이어그램은 정보의 흐름을 나타내는데, 이를 통해서 우리는 정보의 흐름을 관리하기 위한 기술을 선택 할 수 있다. ![Airbnb 서비스 프로세스](https://docs.google.com/drawings/d/e/2PACX-1vQBCrTZ32-mcx1Nsb6k19p5o-eVojgxj7F2Tp_3D0dEXKwXCf1Z47-B1F3vXhQXB1dyCvhaEkXLMIB4/pub?w=1534&h=468) ## 컴포넌트 다이어그램 컴포넌트 다이어그램은 복잡한 시스템 구조를 단순하게 묘사하기 위해서 사용한다. 시스템 구조를 단순하게 함으로써, 이해 당사자들은 전체 구조를 쉽게 이해할 수 있다. 이는 개발팀의 구성, 인터페이스의 개발을 용이하게 한다. 기본적으로 컴포넌트 다이어그램은 독립적으로 개발/배포/조립이 가능한 수준으로 분해하고 연결한다. ![컴포넌트 다이어그램](https://docs.google.com/drawings/d/e/2PACX-1vSMwJKL9I_Y0_AW-TVTyIpG9-cp37SCiMnO22I5rSJOZjlZGM4MpCA0cXrr5lZfcRUD_pfDA04chnvl/pub?w=688&h=566) 컴포넌트는 Frontend APP, Backend APP, Storage 크게 3개 영역으로 분류 했다. - 고객 앱 : 이동이 낮은 고객이다 보니 모바일 First로 해야 할 것이다. Push 서비스가 좀 마음에 걸리기는 하지만 모바일 웹부터 시작해도 큰 문제는 없을 것이다. PWA 정도면 매우 무난하지 않을까 싶다. - 호스트 앱 : 호스트 입장에서는 "업무용" 소프트웨어이므로 모바일 퍼스트가 아니어도 상관없을 거라 생각 할 수 있을 것이다. 하지만 Airbnb는 호텔과 같은 전문기업이 아닌 사람들도 호스트를 할 수 있을 것이다. 이들은 고정된 사무실이 없을 수 있으므로 모바일 환경이 중요하다. 역시 모바일 퍼스트로 해야 할 것 같다. - 유저 서비스 : 고객과 호스트 운영자 모두 유저다. 이들 유저는 하나의 데이터베이스에서 타입만 달리해서 관리한다. - 호스트 정보관리 서비스 : 호스트가 자신이 소유하는 룸 정보를 입력하면 이 데이터를 처리해서 색인한다. - 예약 서비스 : 고객은 고객 앱을 이용해서 예약 작업을 할 수 있다. 예약 서비스 전에 호스트 검색 서비스를 이용할 것이다. - 예약관리 서비스 : 예약 히스토리, 예약 상태가 저장된다. 호스트와 유저는 이 서비스를 이용해서 예약고객 관리, 룸관리, 일정관리, 일전 변경 등의 작업을 수행 할 것이다. - 호스트 검색 서비스 : 위치, 방의크기, 가격 등의 조건으로 검색한다. 스토리지는 아래와 같다. - 유저 DB : 유저 데이터를 저장한다. 유저 데이터는 유저 관리 및 유저인증/권한을 위해서 사용한다. - 예약 Index DB : 예약은 이커머스 시스템의 **주문**에 해당한다. 호스트가 올린 룸정보는 여기에 저장이 된다. - 예약 관리 DB : 모든 예약 정보(history)가 저장된다. 호스트와 유저는 예약의 상세정보를 확인 할 수 있다. 이 데이터는 데이터 분석에 사용 한다. - 색인 DB : 호스트 정보가 색인된다. 이커머스 시스템의 **상품**정보에 해당한다. 기타 Push 서비스와 Payment 서비스등이 있는데, 이들은 각 컴포넌트의 상태변화 전/후에 실행되는 기능으로 봐서 주요 컴포넌트에 포함하지 않았다. 이들 기능들은 소프트웨어 아키텍처에 표현될 것이다. ## 소프트웨어 아키텍처 ![airbnb 소프트웨어 아키텍처](https://docs.google.com/drawings/d/e/2PACX-1vS1tWYoxi19JLS81wQ6nLejHH9NWEcI5cZvVl9X9pqyia6HIQrZMH6VfymfU8Luyy3h5Ue_zSdxBn1F/pub?w=1019&h=464) #### 호스트 & 유저 앱 UI는 사람과 소프트웨어가 디바이스에서 상호작하고 통신하기 위해서 사용하는 인터페이스다. 앱을 이용해서 사용자와 호스트간에 채팅을 하고, 호스트는 방, 호텔등의 이미지를 추가할 수 있다. #### 밸런서 클라이언트와 서버 사이에는 보통 로드밸런서가 놓인다. 로드밸런서는 클라이언트의 요청을 받아서 서버에 분배하는 역할을 한다. 로드밸런서는 다수의 서버를 두고 요청을 분선하고, 실패한 서버로 요청을 보내지 않는 작업을 한다. 시스템의 확장, 안정성, 보안을 최전선에서 책임진다. #### 호스트 관리 서비스 방, 호텔등의 이미지의 추가, 숙박조건, 위치, 스케쥴, 가격 등의 호스트 정보의 관리 서비스를 제공한다. 이들 정보는 MySQL에 저장된다. 호스트의 정보는 MySQL에 저장되는 한편 Kafka로 전송을 한다. 이를 통해서 호스트 서비스와 고객 서비스(검색/예약)의 데이터 모델을 분리 할 수 있다. #### CDN CDN은 **컨텐츠를 전송하는 네트워크**다. 클라이언트와 서버 사이에서 컨텐츠를 중계하는 일을 한다. CDN에는 호스트가 업로드하는 이미지, 동영상등의 복사본이 저장된다. 컨텐츠의 원본은 데이터베이스나 파일 시스템등에 저장되는데, 이미지가 추가되면 CDN을 통해서 전 세계에 흩어져 있는 저장소에 저장된다. CDN 덕분에 유저는 어느 지역에 있든지 빠르게 컨텐츠에 접근 할 수 있다. ### Kafka Kafka를 이용해서 Event Bus를 구성한다. 호스트 관리 서비스를 통해서 호스트 정보가 MySQL에 저장되는 한편, Kafka로도 전송된다. Kafka에는 여러 컨슈머가 실행될 수 있다. Kafka는 크 게 두가지 일을 한다. **데이터모델의 분리**. 소프트웨어 아키텍처를 보면, 동일한 데이터가 MySQL과 ElasticSearch에 저장되는 것을 볼 수 있을 것이다. 이 것은 꽤나 쓸데없는(낭비를 가져다주는) 구성으로 보일 수 있을 것이다. 하지만 동일한 데이터라고 하더라도 호스트 관리자가 사용하는 데이터 모델과 고객이 사용하는 데이터 모델은 달라져야 한다는 것을 알 수 있을 것이다. Kafka를 이용하여 궁극적 일관성을 유지하면서, 각 서비스에 최적화된 데이터 모델을 유지 할 수 있다. **ElasticSearch** : 호스트 정보는 ElasticSearch에 색인된다. ElasticSearch는 Lucene를 기반으로 만들어진 오픈소스 검색 솔류션이다. 풀텍스트 검색, Range 검색, 위치 검색 등 다양한 검색 기능을 제공한다. **유저앱** : 호스트를 검색하고, 예약하는 두 가지 기능이 유저앱의 핵심 기능이다. 유저의 요청은 로드밸런서를 통해서 검색 서비스와, 예약 서비스에 전달된다. **예약 서비스** : 유저의 예약정보는 MySQL 데이터베이스에 저장된다. 그리고 Kafaka로 전송된다. **예약 관리 서비스** : 호스트는 MySQL 데이터베이스에 저장된 예약정보를 조회 할 수 있다. Cassandara에는 예약과 관련된 유저의 모든 activity 가 저장되는데, 이 정보를 이용해서 유저의 상세 예약정보를 조회 할 수 있다. ## 예약 서비스의 작동 프로세스 예약 서비스의 작동 방식을 묘사해 보자. ![예약 서비스](https://docs.google.com/drawings/d/e/2PACX-1vQf74HnZOngMklTm7RPEvRdZG5eRn2GA7WQMdpjdYHJftbNubqWim14ndwiTqIn2hUjDWHRb6c-RZLV/pub?w=350&h=339) 1. 사용자는 예약가능한 방을 찾았다. 2. 사용자는 방을 예약한다. 이 방은 예약상태가 된다. 3. 이 정보는 데이터베이스에 즉시 기록되어서, 다른 사용자가 중복 예약 할 수 없게 한다. 4. 이 정보는 REDIS에 기록된다. REDIS는 캐시로 작동하며, 사용자와 호스트가 우선 접근한다. 데이터베이스의 부하를 줄여줄 것 이다 5. 결제 서비스로 이동한다. 이 과정을 좀 더 자세히 살펴서 해결해야 할 문제가 있는지 알아보자. 프로세스를 세밀하게 살피고 싶다면, 시퀀스 다이어그램을 그려보자. ![Airbnb 예약 시퀀스 다이어그램](https://docs.google.com/drawings/d/e/2PACX-1vRab93e8hS1baRMuENJOp8m_OuiARpAU5qPUAnSiJuO1gSLNI4kC3F3es8JhOANFmm1fa4nAjUyBFCF/pub?w=646&h=805) 시퀀스 다이어그램은 어떤 객체가 어떤 순서로 상호작용하는지를 보여준다. 이 다이어그램은 존재하는 시스템이 어떤 시나리오로 움직이는지 이해하는데 도움을 준다. 시나리오는 비즈니스로직을 나타내기 때문에, 기획의도도 함께 검토 할 수 있다. ## Kafka 작동 프로세스 위의 예약 서비스 프로세스는 쉽게 이해할 수 있지만 **Kafka**가 어떻게 작동할지 예상하기 힘들다. Kafka의 작동 원리/프로세스를 확인해 보자. 역시 시퀀스 다이어그램으로 나타냈다. ![Kafka를 이용한 비동기 이벤트 처리 프로세스](https://docs.google.com/drawings/d/e/2PACX-1vQ7sVw2y4i29kUkgL85Pa8S56GfA2IMRv6gCW5O35bCmTtSIVJyWX_okpIOFr9fyJ-HskaAFo59xzGn/pub?w=974&h=546) Kafka는 링크드인에서 데이터 처리 시스템의 복잡도가 증가하는 문제를 해결하기 위해서 만들었다. Kafka를 적용하기 전과 후의 링크드인 시스템을 비교해 보자. **Kafka 도입 전** ![링크드인 Kafka 도입 전](https://docs.google.com/drawings/d/e/2PACX-1vQg1wvYT2isLtsHwuBXSjIZRd-AXiUXgoImHjJtwTwpG6jkVdSAxBhV105y9jykywzw1ZZ9nOPGw6sl/pub?w=822&h=582) **Kafka 도입 후** ![링크드인 Kafka 도입 후](https://docs.google.com/drawings/d/e/2PACX-1vRpKvwoah3qFitkPtjAYr1O_RE5qFzkEg4-kODbTkNWr659L9KofMeXwvYtRK8w7ZuJ4QCZKWYxDbGd/pub?w=612&h=631) ## AWS 인프라 아키텍처 지금은 간략하게 기술한다. 내용이 길어져서 다른 문서에 상세히 정리해야 할 것 같다. ![AWS Airbnb 아키텍처](https://docs.google.com/drawings/d/e/2PACX-1vRcQ3q35q6aZ3qTzzc0PLE01-PBUceCDTUSWE84up24vZKOVgDfAx6HNA26HRozD5_dY_EIroP0EpYc/pub?w=739&h=781)
Recent Posts
SLA 다운타임 계산기
Docker로 GitLab 설치하기
Ubuntu Linux에 NVIDIA 드라이버 설치
Gemini를 이용한 E-commerce 제품 설명서 생성
프롬프트 엔지니어링 101
Llama3와 MySQL을 이용한 Text2SQL
Llama3.1 설치한 김에 Few-Shot 프롬프팅
Llama3.1 설치 및 프롬프트 테스트
신뢰할 수 있는 AI 앱을 설계하기 위한 LLM 개발원칙
LiteLLM을 이용하여 OpenAI API로 멀티 LLM 통합
Archive Posts
Tags
internet service
Copyrights © -
Joinc
, All Rights Reserved.
Inherited From -
Yundream
Rebranded By -
Joonphil
Recent Posts
Archive Posts
Tags