거대 용량 시스템에서의 설계 이슈

대용량도 아닌 거대 용량 아키텍처 끝 무렵에 이베이 시스템을 간단하게 평했다. 이에 5throck님께서 거대 용량 아키덱처 설계 시의 데이터베이스의 역할라는 글로 답변해주셔서 좀더 많은 이야기를 풀어나갈 기회가 생겼다.


이베이는 극단적인 상황에서 극단적인 조치를 취한 셈인데, 과연 올바른 선택이었냐는 데 의문이 생긴다. 성능을 위해서라고 하지만 데이터베이스의 핵심 기능을 모조리 쓰지 못하는 상황은 지나친 게 아닌가 싶다.

이베이 아키텍쳐요? DB를 SAM파일 수준으로만 사용하고 그 위에 OR매핑 올린 거 말씀이죠? 몇 년 전에는 몰라도 지금은 시대에 뒤떨어진 아키텍쳐지요. 이런 아키텍쳐의 근본적인 사상은 옛날 TP모니터 시절, 모든 트랜잭션은 TP모니터에서 관리해야 한다는 사상에서 나온 건데 이건 너무 이상적인 것이죠.

출처: 거대용량 시스템 아키텍쳐

데이터베이스의 부담을 줄이고자 계산 작업을 애플리케이션 계층으로 분산시키자는 의도는 알겠다. 다만 데이터베이스 관리 시스템의 최적화 기능을 활용 못하게 된다는 점도 생각해야 한다. MSSQL 같은 제품에선 텍스트 SQL 문보단 저장 프로시저를 쓰는 편이 좋다. 최적화기는 자주 실행되는 명령의 실행계획을 캐싱하는데, 이때 저장 프로시저가 텍스트 SQL문보다 처리하기 월등히 쉽다.

또 하나, 로직을 전부 상위 계층에 이전하면 오히려 성능 개선이 어려워지고 관리상의 난점만 더해질지 모른다는 걸 지적하고 싶다. MSSQL의 경우를 예로 들자면, 성능 개선에 앞서 프로파일링부터 한다. 소규모 사이트라 하더라도 쿼리문을 100여 개 이상 사용한다. 포스의 힘을 믿고 이 놈이 문제다라고 찍어도 되겠지만, 좋은 결과가 나올지는 보장 못한다. 그러니 어떤 쿼리가 얼마나 자주 실행되는지, CPU를 얼마나 사용하는지, 디스크 입출력은 어느 정도나 되는지 통계부터 낸다. 그리고 나서 못된 놈부터 골라 차례대로 혼내주면 된다. 로직을 전부 상위 계층으로 넘기면 이런 분석 작업이 힘들어진다. 저장 프로시저엔 이름이 있다. 그러니 매개변수 값이 다르게 들어오더라도 똑같은 저장 프로시저라는 걸 쉽게 알 수 있다. 그러나 텍스트 SQL엔 이름이 없다. 어떤 변수가 바뀌면 복잡한 패턴 분석 작업 없이는 똑같은 SQL 구문인지 파악하기 힘들다. (사실상 불가능하다.)

저장 프로시저는 데이터베이스 관리 시스템이 관리한다. 그러니 데이터베이스에서 어떤 작업이 이뤄지는지 파악하기 쉽다. 반면 애플리케이션에 올리면, 누구 자식인지도 모르는 쿼리가 난잡하게 번창하는 사태가 벌어지기 쉽다. 특별히 관련 규정을 마련해서 준수해야 문제가 발생하지 않는다.

소모성, 단순 반복적인 명령이라면 상위 계층에서 처리하는 편이 낫겠지만, 계층화에 지나치게 집착하다 보면 데이터베이스 관리 시스템 특유의 장점을 놓치게 된다.

물론 데이터베이스를 SAM 파일 수준으로만 사용하면 장점도 있다.

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

출처: 거대 용량 아키덱처 설계 시의 데이터베이스의 역할

이 문제에 대해선 어떻게 대답해야 할지 아직 모르겠다. 위험 분산이라는 비즈니스적 계산이 깔려 있기 때문에 틀렸다고 반박하기 쉽지 않다. 상황에 따라 마이그레이션이 무엇보다 중요한 이슈가 될 수도 있기 때문이다. 그래도 소심하게나마 반박해보겠다.

마이그레이션의 장점이 있다고 하더라고 이런 용도로 데이터베이스 관리 시스템을 사용하는 건 낭비가 아닐까? 이럴 바엔 구글처럼 대용량 처리에 적합한 파일 시스템을 하나 더 만드는 편이 나을 듯 하다. 데이터베이스(Database)는 있어도 데이터베이스 관리 시스템(Database Management System)이 빠진 셈이니, 굳이 값비싼 제품을 구입할 필요가 있을까? 직접 개발하면 자사 서비스에 가장 적합한 시스템을 구축할 수 있다. 제품 라이센스 비용을 감안하면 비용도 충당할 수 있을 듯 하다.

마지막으로 데이터베이스의 분산화에 관한 이슈를 생각해봐야겠다.

최근에 일부 데이터베이스의 경우 여러 대의 서버를 이용해서 하나의 데이터베이스를 운영할 수 있다고 하지만, 대규모 시스템의 경우에는 검증되지 않은 기술인 최신의 기술을 함부로 적용하는 것은 아직 시기상조라 생각이 됩니다. 게다가 아직 실제적으로 어느 정도 수준까지 지원이 가능한지 잘 모르겠습니다.

출처: 거대 용량 아키덱처 설계 시의 데이터베이스의 역할

이 문제에 대한 해답은 대용량도 아닌 거대 용량 아키텍처에서 잘 설명되었다고 생각한다. 수백 개의 데이터베이스 인스턴스가 돌아가는 사례는 의외로 많다. 물론 초거대용량 시스템이라면 좀 더 신중하게 설계해야 할 것이다. 용도별로 최대한 데이터베이스를 분리시키고 캐시 데이터베이스를 붙이는 등의 조치가 필요하다. Flickr에도 유사한 설계가 사용되고 있다. 마이스페이스의 사례에서처럼 자체 기술이 필요하게 되겠지만, 그 정도는 어쩔 수 없는 수고라고 생각한다.

알립니다. 이렇게 반박성 글을 쓰긴 했어도, 제가 옳다고 주장하는 바는 아닙니다. 단지 사람들이 계층화 등 몇몇 확장성 이슈에 대해 비판 없이 기존 주장을 답습하는 게 아닐까 하는 생각이 들어서 문제 제기를 해보고 싶었습니다.

최 재훈

블로그, 페이스북, 트위터 고성능 서버 엔진, 데이터베이스, 지속적인 통합 등 다양한 주제에 관심이 많다.
Close Menu