[대규모 시스템] 대용량 데이터 처리의 어려움

이 글은 '대규모 서비스를 지탱하는 기술'을 보고 학습한 내용을 정리한 글입니다.

 

---

 

새롭게 읽기 시작한 책.

 

 학습을 목적으로 하는 토이 프로젝트에서는 테이블당 레코드의 개수가 많지 않습니다. 전에 진행했던 프로젝트에서는 많아봐야 40 ~ 50개의 데이터를 넣어놓고 나름 만족했던 기억도 있습니다. 데이터가 적으니 I/O 또한 당연히 적을 수 밖에 없고 AWS 프리티어 ec2 인스턴스에서도 성능과 최적화 부족으로 인한 장애는 겪어본 적이 없습니다. 장애는 모두 제 실수로 일어난.... 설정 파일을 잘못 작성했거나, 어플리케이션에 잘못된 코드가 있다거나 하는 문제였습니다.

 

 그런데, 대형 서비스에서는 다른 이야기입니다. 도서에 나온 '하테나' 웹 사이트에서는 2009년 기준으로 한 테이블에 200GB 이상의 데이터가 쌓여있기도 합니다. 13년 전의 이야기니까 지금은 얼마나 클지 가늠도 어렵습니다. 이렇게 큰 테이블을 대상으로 일반적인 조회(ex: ' select * from user; ')를 수행하면 당연히 작동되지 않습니다. 바꿔 말해, 대규모 시스템에서 생각없이 만든 쿼리는 응답해주지 않는(못한)다는 뜻이기도 합니다.

 

---

 

 왜 대규모 시스템에서 이런 어려움이 나타날까요?

 

#  메모리 내에서 계산할 수 없다

 첫번째 어려움은 '메모리 내에서 계산할 수 없다'는 점입니다. 처리해야 하는 데이터의 용량이 가용한 메모리보다 너무 크기 때문에 아예 메모리에 올릴 수 없게 됩니다. 메모리에 적재하지 못하는 데이터는 기본적으로 보조기억장치를 읽어가면서 탐색하게 됩니다. '데이터를 읽을 때 까지 조금 기다리면 되지' 라고 생각할 수도 있겠지만, 보조기억장치(HDD)는 주기억장치(RAM)보다 매우 느립니다. 1초 기다릴 것을 2초 기다리면 되는 문제가 아니라 이론적으로 1초 기다릴 것을 100만 초(277시간) 기다리게 될 수도 있다는 점이 중요한 부분입니다.

 

 또한, 전송의 영역에서도 불리한 모습을 보입니다. 데이터 조회는 크게 '탐색'과 '전송'으로 나뉩니다. 위에서 보았듯 탐색에서 메모리와 디스크는 약 10~100만배의 성능차이를 보입니다.

그리고 전송에 있어서도 약 100배 정도의 차이를 보입니다. 메모리와 CPU는 상당히 빠른 버스를 통해 연결되어 있습니다. 디스크는 메모리의 버스보다 1/100 성능을 가진 버스로 연결되어 있다고 보면 됩니다.

 

 

---

 

 결론적으로, 대용량 시스템에서는 메모리와 디스크의 속도 차이가 있다는 것을 잘 이해하고 어플리케이션을 만들어야 합니다. 설계 단계부터 앞으로 발생할 병목을 예상해가며 코드와 인프라를 잘 예측하여 작성하고 쌓아놓는 것이 중요합니다.