[대규모 시스템 설계 기초2] 1장 근접성 서비스 (1)

들어가며

: [가상 면접 사례로 배우는 대규모 시스템 설계 기초1] 책을 우연히 읽고 배우게된 내용이 많아 [가상 면접 사례로 배우는 대규모 시스템 설계 기초2]도 바로 구매하여 읽게 되었다. 어떤 서브스에 대하여 시스템이 어떤 구조로 설계되어 있고 그런 구조로 설계된 근거들에 대해서 단계 단계 설명한다. 특히나, 새로운 feature에 대하여 개발할 때 참고하여 적용할만한 내용을 많이 담고 있어 읽으면서 이미 구현해본 내용에 대한 아쉬움과 앞으로 적용해볼만 사항들을 정리해볼 수 있을 것 같다. 

 

---

1장 근접성 서비스(proximity service)

 

근접성 서비스는 음식점, 호텔, 극장, 박물관 등 현재 위치에서 가까운 시설을 찾는데 이용된다. 

 

 

1단계: 문제 이해 및 설계 범위 확정

 

서비스를 구현하기 위하여 기능 요구사항/비기능 요구사항은 아래와 같다.

- 기능적 요구사항

1. 사용자의 위치(위도/경도)와 검색 반경 정보에 매치되는 사업장 목록을 반환한다. 
2. 사업장 소유주가 사업장 정보를 추가/삭제/갱신 할 수 있도록 하고 그 정보가 검색 결과에 실시간으로 반영될 필요는 없다. (사업장 목록은 매일 자정 업데이트가 반영됨)
3. 고객은 사업장의 상세 정볼를 확인 할 수 있다.

- 비기능적 요구사항(Non-functional requirement) 

1. 낮은 응답 지연(latency) : 사용자는 주변 사업장을 신속히 검색할 수 있다.
2. 데이터 보호(data privacy): 사용자 위치는 민감한정보이므로 위치 기반 서비스(Location-Based Service, LBS)를 설계할 때 언제나 사용자의 정보를 보호 할 방법을 고려해야한다. 또한 GDPR/HIPPA와 같은 데이터 사생활 보호 법안을 준수하도록한다. 
3. 고가용성(high availability) 및 규모 확장성(scalability) 요구사항: 인구 밀집 지역에서 이용자가 집중되는 시간에 트래픽이 급증해도 감당할 수 있도록 시스템을 설계

 

나의 생각 

 

 

해당 내용을 읽으며 비기능적 요구사항은 거의 모든 시스템에 동일하게 적용되는 내용이어서 현재 개발 중인 시스템에서도 위 요구 사항들이 잘 반영되고 있는지 고민을 해보았다. 

 

Latency는 설계 및 구현 시 매번 고민하게 되는 포인트이다. 다만 고민을 살짝할 뿐, 실제 배포 환경의 데이터와 아키텍쳐를 토대로 정량적인 수치를 계산해보고 고민해본적은 없었다. 때문에 "현재 개발 환경의 데이터랑 상용 환경의 데이터량이 달라서 감이 오지 않는다."라는 이야기를 했던 기억이 난다. 하지만 정확한 수치에 대하여 깊게 고민을 안 해보았기 때문에 알 수 없고 몰랐던 것이었다. 즉, 깊게 안 해본 나의 핑계 였다고 생각한다. 이 부분은 "시간이 없어서 고민할 수 없었다"가 아닌 구현/설계 전에 미리 파악을하고 계산을 해 본 후 설계/구현을 하는 방향으로 무조건 개선해야겠다는 생각을 했다. 

 

 

요구사항에 대한 정리가 끝났다면 개략적 규모를 추정해본다. 

 

시스템의 규모와 수준에 따라 설계가 달라지기 때문에 개략적인 추정(back-of-the-envelope calculation)을 해 보아야한다. 

일간 능동 사용자(Daility Active User, DAU)는 1억 명(100 million) 그리고 등록된 사업장 수는 2억(200milion)이라고 하자.

 

QPS(Query Per Second)를 계산해보면, 

 

1일 = 24시간 * 60분 * 60초 = 86400초 이다. 대략 100000(10⁵) 로 올림하자. 유저가 하루에 5회 검색을 시도한다고 가정한다. 따라서 QPS = (1억 * 5) / 10⁵ = 5000 이다. 

 

나의 생각 

 

이렇게 시스템 설계 전에 대략적인 QPS를 계산하는 것이 굉장히 중요하다고 생각한다. 이를 위해서 대략적인 비즈니스적 숫자가 필요하다고 생각한다. 때문에 시스템에서 비즈니스적 데이터를 쌓는 것 역시 굉장히 중요한 역할을 한다고 생각한다. 

 

---

2단계: 개략적 설계안 제시 및 동의 구하기

- API 설계 및 목록 정리 : API 를 모두 리스트업한다. 

 

- 데이터 모델링

• 이번장에서는 읽기/쓰기 비율(read/write ratio) 및 스키마 계에 대해 알아본다. 
  • 읽기/쓰기 비율 : 이용 빈도가 높은 기능은 `주변 사업장 검색`그리고 `사업장 정보 확인` 두가지 기능으로 읽기 연산의 비중이 높다. 반면 쓰기 연산의 실행 빈도는 사업자 정보 추가/삭제/편집 기능으로 상대적으로 빈번하지 않다. 이렇게 읽기 연산이 압도적인 시스템에서는 MySQL같은 관계형 데이터 베이스가 바람직하다. 
  • 데이터 스키마 : 이 시스템의 핵심이 되는 테이블은 business 테이브과 지리적 위치 색인 테이블(geospatial index table)이다.
  • 개략적 설계

• 이 시스템은 위치 기반 서비스(Location-based service, LBS)와 사업장 서비스로 나뉘어 구성된다.
  • 로드 밸런서(Load Balancer)는 유입 트래픽을 서비스에 분산 시키는 컴포넌트이다. URL 경로를 분석하여 어느 서비스에 트래픽을 전달할지 결정한다. 
  • 위치기반 서비스(LBS)는 시스템의 핵심 부분으로 주어진 위치와 반경 정보를 이용하여 주변 사업장을 검색한다. 
    • 쓰기 요청이 없고 읽기 요청만 빈번하게 발생하는 서비스
    • QPS가 높고 특정 시간대에 인구 밀집 지역일수록 걍향이 심함
    • 무상태(stateless) 서비스이므로 수평적 규모 확장이 쉽다
      • 무상태 서비스란, 클라이언트의 상태 정보를 서비스에 저장하지 않고 각 요청이 독립적으로 처리되는 서비스이다. 각 요청이 이전 요청과 무관하게 독립적으로 수행되고 서버는 각 요청을 완전히 새롭게 처리한다.
  • 사업장 서비스는 기본적으로 QPS가 높지 않고 고객이 사업장 정보를 조회하는 특정 시간대에 QPS가 높아진다.
  • 데이터 베이스 클러스터는 Primary/Secondary형태로 구성하여 primary에서 쓰기 요청을 처리하고 Secondary에서 읽기 요청을 처리한다. 때문에 primaryDB에 기록되고 secondary로 복사된다. 복제에 걸리는 시간 지연(delay) 때문에 Primary와 Secondary 사이에 차이가 있을 수 있다.
  • 사업장 서비스와 LBS와 규모 확장성은 사업장 서비스와 LBS둘 다 무상태 서비스이므로 트래픽이 몰리는 특정 시간대에 자동으로 서버를 추가하고 삭제하도록 구성할 수 있다. 시스템을 여러 지역, 여러 가용성 구역에 서버를 두어 시스템 가용성을 높일 수 있다. 

내 생각

 

책에서 고려하지 않은 점이 한 가지 있던 것 같다. 해당 서비스가 글로벌 서비스인지 아니면 특정 국가에서만 운영되는 서비스인지에 대한 고려되지 않았다. 아무래도 글로벌 서비스가되면 아키텍쳐가 상당히 복잡해지고 특정 시간대에 서버를 확장한다고 했으나, 전세계적으로 보면 전세계 도시의 TZ를 고려하여 서버가 확장되어야되지 않을까라는 생각을 했다. 또한 매번 궁금했던 부분이 MongoDB에서 Primary가 업데이트 되었을 때 Secondary에 반영되기까지의 delay가 어느정도인지 수치적으로 궁금했다. 

 

복제 지연 시간은 대개 몇 밀리초에서 수 초 이내로 측정됩니다. 하지만 위에서 언급한 요인들에 따라 이 시간이 달라질 수 있다고한다. 완벽한 실시간이 보장되어야하는 상황이 아니라면 CQRS 구조로 Primary/Secondary를 쓰고 읽도록 구조를 가져가는 것이 좋을 것 같다.