이번 조사에서는 서비스를 처음부터 직접 설계한다고 가정하고, 단일 서버 환경에서 시작해 단계별로 발생하는 문제와 해결 과정을 하나씩 따라가 보았다. 그동안 컴플라이언스 관점에서 “가용성을 확보해야 한다”, “단일 장애점을 제거해야 한다”와 같은 통제 항목들을 체크리스트 형태로만 접해왔다. 그러다 보니 실제 네트워크 구조 내에서 서버가 어떻게 작동하는지에 대한 실증적인 이해가 부족했음을 느꼈다. 이에 따라 본 조사에서는 인프라의 단계별 확장 과정을 파악하고, AWS의 어떤 인스턴스와 서비스들이 각 역할을 수행하는지 구체적으로 알아보고자 하였다.
먼저 제일 단순한 구조부터 시작한다. 서버 한 대에 웹 서버, 애플리케이션, DB를 전부 설치하는 것이다. 모든 서비스를 처음 만들 때는 이게 제일 빠르고 간단한 방법이다.
만약 사용자가 10명에서 10000명으로 늘어난다고 생각해보자. 예전과 달리 서버가 느려졌는데, 웹 처리가 느린 건지, 애플리케이션 로직이 느린 건지, DB 조회가 느린 건지 전혀 구분이 안 된다. 심지어 하나를 고치려고 서버를 재시작하면 나머지 기능까지 같이 멈춰버렸다.
원인을 따져보니 당연한 결과일 것이다. 웹 서버는 HTTP 요청 처리나 정적 파일 응답을 하면서 주로 네트워크 I/O를 쓰고, 애플리케이션은 비즈니스 로직 연산 때문에 CPU를 많이 쓰고, DB는 데이터 조회·저장을 하느라 디스크 I/O와 메모리를 주로 쓴다. 성격이 완전히 다른 세 가지 작업이 한 서버의 자원을 공유하고 있으니, 원인 분리도 안 되고 장애도 전파되고 개별 확장도 불가능한 게 당연했다.
그래서 역할이 다른 작업을 물리적으로 분리하기로 했다.
Web은 Presentation Tier, Application은 Application Tier, DB는 Data Tier로 나누는 것이다.
여기서 궁금했던 게 하나 있었다. "굳이 서버를 나누지 않고, 단일 서버 내에서 프로세스만 분리해도 되지 않을까?" 싶었는데, 찾아보니 두 가지 분리 방식이 있었다.
논리적 분리만으로는 프로세스는 나뉘어도 CPU·메모리·디스크 같은 물리 자원은 여전히 공유하고, 서버 자체가 죽으면 다 같이 죽는다는 한계가 있었다. 그래서 실제로 정상적인 서비스를 위해서는 서버 세 대로 나누는 물리적 분리인 3-Tier 아키텍처 구성이 필수적이게 되는 것이다.
웹서버와 DB는 여전히 여유가 있는데, 사용자의 접속량이 늘어나면서 과도한 CPU 연산량으로 인해 Application 서버만 CPU 100%를 찍게 되었다. 처음에는 더 좋은 서버로 교체했는데, 잠깐 버티다가 또 한계가 왔고, 교체할 때마다 서비스를 내려야 하는 문제가 생겼다.
이게 Vertical Scaling의 한계이다. 기존 서버에 프로세서, 메모리, 디스크 같은 하드웨어 리소스를 추가하는 방식이라 설정이 단순하고 데이터 일관성을 유지하기 쉽다는 장점이 있지만, 결국 하드웨어 자체의 물리적 상한이 있고, 교체하려면 다운타임이 필요하다는 게 한계점이다.
반면에 Horizontal Scaling은 서버 사양을 올리는 대신 같은 사양의 서버를 여러 대 두고, 로드밸런서가 요청을 나눠주는 방식이다. 이 방식은 거의 한계 없는 확장성을 가질 수 있고, 높은 가용성과 단일 장애점 제거가 가능하다는 게 큰 장점이다. 다만 아키텍처 구조가 복잡해지고 네트워크 통신 비용이 늘어난다는 점의 한계가 있다.
