개략적 규모 추정
저장소 사용량
- 저장해야 할 데이터는 크게 세 종류로 구분 할 수 있다.
- 세계지도(지도 타일)
- 메타데이터(지오해싱 등)
- 도로 정보(경로 타일)
Q? 메타데이터를 굳이 따로 명시한 이유가 있을까?
저자가 메타데이터를 강조하고 싶었던걸까?
세계지도
- 앞서 다루었듯, 지도 타일은 확대수준별로 한벌씩 준비해두어야 한다.
- 이를 위해 21단계의 확대수준을 가지고 있다고 가정한다.
- 21단계에서 타일의 수는 약 4.4조 개에 달한다.
- 각 타일을 256x256 픽셀의 PNG로 가정한다면, 각 타일은 약 100kb이다.
- 따라서 전체 지도 데이터는 약 4.4조 * 100kb = 440PB이다.
- 이를 위해 21단계의 확대수준을 가지고 있다고 가정한다.
- 다행히 지구 표면의 90%는 사람이 살지 않으므로, 보수적으로 고려해서 약 44~88PB로 계산한다.
- 이를 어림하여 약 50PB로 계산한다.
- 결과적으로, 모든 지도 타일을 저장하기 위해서는 약 100PB가량의 저장소가 필요하다.
서버 대역폭
-
우선 필요한 요청들이 무엇인지 정리해보자.
- 경로 안내 요청
- 위치 갱신 요청
-
각 사용자는 하루에 이 기능을 약 5분 사용한다고 가정하자.
-
DAU가 10억이었으므로, 하루에 약 50억 분이다.
-
Naive한 접근으로, 매 초 위치정보를 갱신한다고 가정하면, 하루에 3000억 번 위치정보 갱신이 이루어진다.
- 이는, 하루를 10만초로 가정하더라도 약 300만 QPS이다.
-
이를 최대한 줄이기 위해, 변경내역을 클라이언트에 기록해두고 15초마다 전송한다고 가정하자.
- 이 경우에는 약 20만 QPS가 된다.
-
최대 QPS는 평균의 약 5배로 가정한다면, 약 1백만 QPS가 된다.
❗ 많이 뭉뚱그려졌지만, 나름대로 합리적(으로 납득 가능한) 추론 과정이 있다.
하루 5분 사용이나, 최대 QPS가 평균의 5배라는 가정 등이 그렇다.
2단계: 개략적 설계안 제시 및 동의 구하기
개략적 설계안
- 위치 서비스
- 경로 안내 서비스
- 지도 표시
위치 서비스
- 앞서 다루었듯, 위치 정보를 매번 서버에 전송하는 것은 비효율적이다.
- 따라서 변경 내역을 클라이언트에 저장해두고 일정 주기마다 전송하는 방법을 사용한다.
- 사용할 프로토콜은 HTTP를 keep-alive로 사용한다.
경로 안내 서비스
- 경로는 무조건 최단 시간 경로일 필요는 없으나, 정확도는 보장되어야 한다.
지도 표시
-
클라이언트가 요청하는 지도들은 정적이므로, 지오해시 등으로 캐싱하여 사용한다.
-
CDN을 사용하면 성능과 확장성, POP(Point of Presence)도 보장할 수 있다.
-
또하나 고려할 사항은 위경도를 바탕으로 지오해싱된 데이터를 요청하는 것이다.
- 이 작업은 클라이언트에서도 충분히 가능하다.
- 하지만, 추후 확장성이나 유연성을 고려하면 서버에서 처리하는 것이 좋다.
- 오래된 기기나 여러 가지 플랫폼에서의 호환성을 고려해야 하기 때문이다.
- 이를 위해, 위경도와 확대수준을 바탕으로 타일 URL을 생성하는 서비스를 별도로 구성하는 방법도 좋다.
- 복잡도는 다소 높아지겠지만, 유연성과 확장성을 보장할 수 있다.
안녕하세요!