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

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

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

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

일반적으로 볼 때 대부분의 웹사이트는 개인이 소규모로 시작하거나 작은 기업이 운영하는 경우가 많습니다. 그러다가 사용자가 증가해서 케즘(Chasm)을 넘어서게 되면 갑자기 데이터베이스의 용량이 폭주를 해서 엄청난 규모를 처리할 수 있는 데이터베이스 - 혹은 분산파일 시스템 - 으로 전환이 진행되어야 합니다. 이럴 경우 만약 데이터베이스 부분에 핵심적인 코딩을 해놓은 경우라면 낮은 처리용량을 가진 데이터베이스에서 상위 처리용량을 가진 데이터베이스로 전환 시에 상당한 어려움이 존재를 하게 됩니다. 심지어는 새로 시스템을 구축해야 할 정도의 문제도 발생할 수 있다고 생각합니다.

이러한 문제가 발생하는 이유는 일반적으로 미들웨어의 경우는 확장성을 고려해서 설계를 할 경우, 어플리케이션 서버나 추가적인 미들웨어를 도입할 것을 예상하여 병렬처리방안을 설계 시에 고려하면 추후 용량이 증가될 시에 추가적인 하드웨어 증설 등을 통해 어느 정도의 운영의 묘를 살릴 수가 있지만, 데이터베이스의 경우는 현재의 기술로는 복수의 데이터베이스를 운영하기가 상당히 어렵기 때문입니다. (최근에 일부 데이터베이스의 경우 여러 대의 서버를 이용해서 하나의 데이터베이스를 운영할 수 있다고 하지만, 대규모 시스템의 경우에는 검증되지 않은 기술인 최신의 기술을 함부로 적용하는 것은 아직 시기상조라 생각이 됩니다. 게다가 아직 실제적으로 어느 정도 수준까지 지원이 가능한지 잘 모르겠습니다.)

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

보통 정보계에서 Sorting 기술을 사용하는 것은 병렬처리를 보다 효율적으로 진행을 하기 위해서인데, 대규모 데이터를 정렬시켜 적당한 중간단위로 데이터를 쪼개는 것이 병렬처리에는 필수적이기 때문입니다. 기간계가 정보계와는 많이 다른 방식으로 설계 및 운영이 되기는 하지만 아마도 병렬처리를 위해서 Sorting을 하지 않았나 추정해봅니다.

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

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.