KAISTIZEN님의 블로그에 재미있는 글이 올라와서 해당 글에 대해서 제 개인적인 의견을 몇 자 적어봅니다.

대용량도 아닌 거대 용량 아키텍처

저의 경우 말씀하신 사양 정도의 크기는 아니더라도 어느 정도 규모의 시스템을 SE(System Engineer)로서 프로젝트 기간 동안 설계 및 운영을 해본 적이 있습니다. 제가 설계를 담당했던 영역은 기간계 시스템이 아닌 정보계 시스템이므로 상황은 많이 다를 것으로 판단되지만 그래도 제 짧은 지식을 동원해서 이야기 해보자고 합니다.

말씀하신 내용이 맞다면 이베이의 설계자는 MVC 모델에 철저하게 입각해서 설계한 것으로 생각됩니다. 다시 말해 Logic 부분은 절대로 데이터 영역에서 처리하지 않는다는 것이죠. 전 개인적으로 이 대목이 중요하다고 생각하는데, 그렇게 생각하는 이유는 회사의 사정이나 기타 이유로 인해 데이터베이스를 전환할 경우 데이터 영역을 단순 마이그레이션만으로도 전환할 수 있는 장점이 존재하기 때문입니다.

일반적으로 웹사이트는 작은 규모로 시작하여 큰 규모로 확대되는 경우가 많습니다. 사용자가 증가해서 일정 규모를 넘어서게 되면 갑자기 데이터베이스 용량이 폭주해서 엄청난 규모의 데이터를 처리해야 하는데, 이럴 경우 대용량 기반의 데이터베이스 - 혹은 분산파일 시스템 - 설계와 전환이 필요하게 됩니다. 하지만, 초기 단계에서 데이터베이스에 핵심적인 코딩을 해놓은 경우라면 데이터베이스 전환 시 코드 컨버젼 등으로 인해 상당한 어려움이 발생할 가능성이 있습니다. 초기 설계가 잘못되어 있는 경우에는 심지어 새롭게 시스템을 구축할 수도 있기에 초기 설계는 매우 중요하다고 생각합니다.

이러한 문제가 발생하는 배경에는 미들웨어의 경우 초기 개발 시부터 확장성을 고려해서 설계할 경우, 추가적인 어플리케이션 서버 증설 등을 통해 병렬처리를 할 수 있지만, 데이터베이스의 경우에는 현재의 기술로는 복수의 서버 증설 등을 통해 데이터베이스를 운영하기 어렵기 때문입니다. (최근 일부 데이터베이스의 경우 여러 대의 서버를 이용해서 하나의 데이터베이스처럼 운영할 수 있다고 하는데 대규모 시스템의 경우 검증되지 않은 최신의 기술을 함부로 적용하는 것은 매우 위험하다고 생각합니다. 게다가 아직까지 적용된 사이트가 적어서 실제적으로 어느 정도까지 지원이 가능할지에 대해 확신이 잘 서지 않는 것 같습니다.)

따라서, 추가적인 증설이 가능한 미들웨어나 어플리케이션 서버에 로직을 설계하고 용량에 제한이 있는 데이터베이스 서버는 최대한 부하가 걸리지 않는 방식으로 처리를 해야만 대용량 처리가 가능하게 됩니다. 이렇게 설계된 경우 데이터베이스는 단순한 파일저장소 정도의 역할만 수행하게 되고, 거의 대부분의 처리는 어플리케이션 서버에서 수행되어 데이터베이스의 부하가 상대적으로 적어지게 되며 개별 데이터베이스가 가지고 있는 기본기능 이외에 기능은 거의 사용되지 않는 방식으로 운영되게 됩니다.

보통 정보계에서 Sorting 기술을 사용하는 것은 병렬처리를 보다 효율적으로 진행하기 위한 방안인데, 대규모 데이터를 정렬시켜 적당한 중간 단위로 분할하는 것이 병렬처리에는 효과적이기에 이러한 작업이 필수적으로 일어날 가능성이 높습니다. 기간계는 정보계와는 다른 방식으로 설계와 운영되지만 아마도 대용량 데이터 처리를 위한 방안으로 병렬처리를 선택한 경우 데이터 Sorting을 통해 분산작업을 처리하지 않았나 추정해봅니다.

추신: 제가 이베이 정도의 시스템 사이징(System Sizing)을 해 본 적이 없다는 점을 미리 밝혀둡니다. 제가 말씀드린 내용이 틀릴 수도 있으므로 잘못된 내용에 대해서는 코멘트나 트랙백을 달아주시면 감사하겠습니다.