[1주차] 대규모 시스템 설계 2권 1장 스터디

월간-CS, 대규모 시스템 설계면접 2권 스터디 발표 자료입니다. - [Ref]
10.29.화 ~ 11.6. 수 까지 작성한 DIL을 기반으로 준비하였습니다. - [Ref]

시작에 앞서

대규모 시스템 설계 면접에서는 4가지 단계*로 인프라를 설계합니다.
보통 요구사항 이해, 개략적인 규모 추정, 추상적 설계, 상세 설계 순으로 진행됩니다.

요구사항을 확정하고 규모를 추정하면 시스템 설계*가 시작됩니다.
시스템 설계에서는 단순히 메세지, 솔루션 등을 연결하여 추상적인 연결고리를 만들면 안된다 생각합니다. 조금 더 추상적인 레벨에서 분산된 서비스가 CAP 정리 중 어떤 것을 만족하게 설계할지를 정해야 합니다.

분산 시스템에서 유명한 이론인 CAP 정리*를 빌어 말하자면
시스템 가용성을 보장하기 위해서 데이터 일관성을 다소간 포기하거나
데이터 일관성을 보장하기 위해서 시스테 가용성을 다소간 포기해야 합니다.

CAP 정리 - [Ref]

• Consistancy : 일관성

• Availailibity : 가용성

• Parition Tolerance : 파티션 내결함성

따라서 요구사항을 구체화 하면서
각 기능이 일관성과 가용성 중에 어떤 것이 우선되어야 하는지 반드시 물어봐야 합니다.

요구사항 이해

기본적으로 기능적 요구사항은 다음과 같습니다.

1. 사용자*의 위치(경도, 위도)로 주변 사업장 목록 반환

2. 사용자*는 선택한 사업장의 상세 정보를 반환

3. 사업자*는 사업장 정보를 추가, 삭제, 갱신이 가능하며 실시간으로 반영될 필요는 없음 (AP 정리) ⛳️

4. 최대 허용 반경은 20km

5. 선택가능한 반경은 0.5km, 1km, 2km, 5km, 20km

다만 요구사항에서 서비스 지역을 논의하지 않았습니다.
만약 북미나 유럽 등 민감한 지역에서 서비스를 운영한다면 강력한 보안 규칙을 지킬 뿐만 아니라, 북미의 데이터가 북미 외부로 나가지 않도록 설정해야 합니다.
즉, 데이터베이스 샤딩 전략까지 같이 구현해야 합니다.

본 도서에서는 GDPR*, CCPA* 등의 데이터 사생활 보호 법안을 준수해야 한다고 나옵니다. 하지만 세부적인 규정은 설게 관점에서 우선순위가 높지 않다고 생각합니다.

개략적인 규모 추정

사실 지구의 직경 길이를 외우고 다니는 사람은 없을 것 같습니다.
따라서 규모 추정 전, 반드시 면접관에게 허락을 구하고 직경을 검색해야 합니다.
지구의 가로 길이를 검색했을때 나온 길이인 6380km를 기준으로 하되 추정의 편의를 위해서 6500km에 맞추고 가로 세로 길이가 6500km라고 연산을 하겠습니다. - [Ref] 연산에서는 구형의 특성을 고려하지 않겠습니다.

또한 요구사항에서 기능의 성능 및 속도에 대한 내용을 다루지 않았습니다.
따라서 기능의 속도 측면이 아닌 가용성 및 알고리즘 측면에 대해서 다루는 것 같습니다.

• 평면 면적 : 6,500 * 6,500 = 42,250,000km

• 0.5km 기준 조각의 수 : (6,500km / 0.5km) * (6,500km / 0,5) = 169,000,000개

• 20km 기준 조각의 수 : (6,500km / 20km) * (6,500km / 20km) = 105,625개

추정의 편의를 통해서 1억 7천만, 10만으로 기준하겠습니다.

개략적인 설계

상식적인 선에서 이런 종류의 위치 기반 서비스는
사용자*의 숫자가 사업자*의 숫자보다 월등히 많습니다.
또한 사용자의 사용 빈도가 훨씬 높기 때문에 읽기 과정의 대책이 가장 중요합니다.

위치기반서비스(LBS)와 사업장 서비스를 분리합니다.
데이터베이스는 Read Replica를 통해서 읽기 성능을 최대한 보장합니다.

요구사항 중에 실시간으로 반영될 필요는 없음 (AP 정리)라고 하였습니다.
따라서 위치기반서비스 앞단에 캐시 타임을 낮게 설정한 CDN을 배치해도 됩니다.

추가적으로 위치기반서비스의 특정 URL 패턴에만 반응하는 CDN 서버를 배치합니다.
일반적으로 내가 자리잡은 국가의 식당을 찾을 것이라는 가정하에,
엣지 로케이션 기반의 CDN 서버는 그 자체만으로 트래픽을 효율적으로 분산합니다.



하지만 이런 방식의 시스템은 기본적으로
CDN의 엣지에서 물리적인 서버로 가는 요청의 거리가 불규칙적입니다.
서버가 한국에 있을 경우 유럽 사용자는 느린 요청 시간을 경험합니다.
따라서 주요 서비스 지역에 위치 기반 서비스를 배포하고 이를 접두사로 구분지을 수 있어 보입니다.

/asia/lbs → 서울의 로드밸런서를 원본으로
/america/lbs → 미국의 로드밸런서를 원본으로
/europe/lbs → 영국의 로드밸런서를 원본으로

다만 사업장 서비스의 경우
기본적으로 /business 요청에 대해서 전부 서울로 오게 할 수 있습니다.
또는 주요 국가에 서비스를 배포하고 /asia/business, /america/business 등과 같이 사용할 수 있습니다. 물론 이 경우에는 다수의 쓰기 인스턴스가 있거나, 사설 네트워크 망을 통해 연결한 단일 쓰기 인스턴스가 있을 것입니다.
이는 복잡성을 크게 높이고 기본적으로 중요도가 낮다고 판단해 더이상 언급하지 않습니다.

실제 서비스로 보면 다음과 같습니다.