.gif&collectionId=dcb50d88-6307-4897-975e-13c151621a8a)
과거 모놀리식 아키텍처로 구성되었던 인프라를 분산형 구조로 마이그레이션했던 스토리를 담은 글입니다.
웹사이트의 역사
1세대 웹 서비스에서 모든 웹사이트는 전부 정적(static) 페이지였다.
단순히 정보를 제공하는 목적으로 HTML 마크업 언어만을 이용하여 작성했다.
서버에서 페이지를 만들어서 그대로 사용자에게 제공을 해주었고, 따로 프론트엔드와 백엔드라는 개념 자체가 없었다.
(오히려 프론트엔드와 백엔드라고 하면 컴파일러에서 컴파일 단계를 나눌 때를 말했다. 소스 코드를 입력 받아 구문 분석 및 검증을 수행하여 중간코드를 만드는 부분을 프론트엔드로 부르고, 중간코드를 기계어로 변환하는 곳을 백엔드로 부른다.)
그러나 유저와의 상호작용(버튼 클릭 등)이 요구됨에 따라 2세대부터 Javascript를 이용한 동적 사이트가 제공되기 시작하였다. 하지만 아직까지도 Javascript는 토핑 느낌으로 얹혀져서 사용되었다.
그러나 3세대에 들어서는 유저와의 상호작용을 위해 웹사이트가 존재한다고 말할 수 있을 정도로, 동적인 요소가 중요해졌다.
Javascript 위주의 코드가 작성되고, HTML 요소도 Javascript를 통해 동적으로 생성하는 경우가 많아졌다.
이에따라 SPA(Single Page Application)이라는 개념이 등장했다.
SPA는 UX(User Experience) 향상을 목표로 하는 어플리케이션으로, 최초에 한 번 모든 정적 리소스를 받아온 후, 이후 새로운 요청이 왔을 때 필요한 데이터만 받아 페이지를 갱신한다.
SPA는 전통적인 방식(매 요청마다 새로운 정적 리소스를 받아와서 전체 페이지를 다시 렌더링)과는 대조된다.
주로 CSR(Client Side Rendering) 방식으로 SPA를 구현한다. (클라이언트 측에서 페이지를 렌더링)
SPA 개념이 발달하면서 점점 UI/UX를 담당하는 측과 서버의 데이터와 통신을 처리하는 측이 명확히 구분되기 시작했다.
오늘날에는 이렇게 프론트엔드와 백엔드가 나누어서 개발을 하게 되었다.
중앙 집중식 시스템과 분산 시스템
중앙 집중식 시스템이란 모든 기능이 단일 시스템 내에 중앙 집중적으로 구성되어 있고, 서비스를 담당하는 하나의 어플리케이션으로 구동되는 시스템을 말한다.
ex) 기존 까비는 백엔드 서버, 프론트엔드 정적 파일, 데이터베이스가 EC2 인스턴스 하나로 구동 됐었다.
중앙 집중식 시스템은 전통적인 방식의 서비스 구조이다.
프론트와 백엔드가 나누어지기 전의 시절인 1세대와 2세대는 전부 중앙집중식 시스템이었다.
그런데 프론트와 백엔드의 역할이 나누어지면서, 각각이 가지고 있는 관심사도 달라지게 되었다.
프론트는 초기 렌더링 성능을 어떻게 최적화할 수 있는지, 사용자와 상호작용하는 과정에서 부드러운 렌더링, 반응성 향상을 위해 성능 최적화, 반응형으로 어플리케이션 제공, 브라우저 호환성 등에 대해 초점을 가진다.
반면 백엔드는 데이터베이스 관리, 데이터 모델링, 비즈니스 로직 개발, RESTful한 API 설계 및 구현, 웹 어플리케이션 보안 및 인증 등에 대해 초점을 가진다.
이렇게 관심사가 명확히 나누어짐에 따라 이에 따라 프론트와 백엔드의 물리적인 서버를 따로 분리하여 독립적으로 확장하는 경향이 증가하게 되었다. 이와 같은 시스템을 분산형 시스템이라고 부른다.
서비스의 규모의 큰 곳은 여기서 한 발 더 나아가 관심사가 다른 서비스들을 모두 마이크로 단위의 모듈로 분리하여 별도의 서버로 구동하는 마이크로 서비스 아키텍처(Micro Service Architecture) , 즉 MSA로 이어지기도 한다.
그런데 까비는..?
까비는 백엔드 서버(AWS EC2)에서 서버측 자원 뿐만 아니라 프론트엔드에서 사용하는 소스코드, 이미지 파일 등 모든 리소스를 제공해주고 있고, DB도 함께 구동되고 있다.
MSA와 대비해서 이런 형태의 어플리케이션을 모놀리식 아키텍처(Monolithic Architecture)라고 부른다.
까비는 백엔드와 프론트엔드의 관심사가 서로 다름에도 하나의 물리적인 서버에서 컨텐츠가 제공되고 있었다.
뿐만 아니라 DB까지 같은 서버에 구동되다보니, 만약 EC2 인스턴스에 문제가 생긴다면, 프론트에서 제공하는 소스코드에도 접근하지 못하고, DB도 접근하지 못해 마지막으로 했던 백업과 서버가 다운된 시점 사이 데이터를 모두 잃어버리게 된다.
이것이 모놀리식 아키텍처의 단점이기도 하고, 까비가 가지고 있었던 문제이기도 하고, 사실 이 문제 때문에 서버 이전이 논의 되었었다.
그래서 까비팀은 백엔드면 백엔드, 프론트면 프론트, DB면 DB로, 관심사가 다른 서비스들을 별도의 서버로 운영하는 것을 목표로 AWS 이전 작업을 진행하였다.
AWS 이전 작업
백엔드 서버는 기존 방식대로 EC2 인스턴스로 구동을 한다.
프론트는 AWS에서 제공해주는 클라우드 스토리지인 S3와 CDN(Content Delivery Network)을 통해 이를 배포하게 해주는 CloudFront 활용한다.
DB는 마찬가지로 AWS에서 제공해주는 클라우드 RDBS RDS(Relational Database Service) 활용한다.
AWS S3란?
AWS CloudFront란?
AWS RDS란?
AWS 이전으로 얻은 것
클라우드 서비스 인프라 경험
실서비스를 운영하는 것을 넘어서 클라우드 서비스같은 인프라도 직접 건들여볼 수 있었던 기회가 절대 흔치 않을 것이기 때문에 정말 재밌게 작업할 수 있었던 것 같았다. 실제로 이것저것 만져보면서 정말 많이 배울 수 있었다.
특히 팀원들이 DB 백업에 대해서 고민이 많았는데, RDS가 DB를 자동으로 백업해주고 만약 실 운영중인 DB에 문제가 생기면 백업된 스냅샷으로 즉각적으로 복구를 해주어 이러한 고민이 해결되었다.
실제로 DB에 일부 데이터의 타임존이 다르게 찍혔던 문제가 발생한적이 있었는데, 스냅샷 기능 덕분에 어느 시점에 문제가 발생했었는지 정확히 파악이 가능하여 빠르게 이슈에 대응한 적도 있었다.
서비스 확장가능성 재고
백엔드, 프론트엔드, DB 서버를 분리하면서 자연스럽게 시스템의 부하를 분산시켜 확장성을 높일 수 있게 되었다.
단순 페이지나 이미지 요청을 백엔드가 아닌 프론트 서버에 요청을 하고, 마찬가지로 DB에서 데이터를 얻어오는 작업도 AWS RDS에서 이루어지기 때문에 백엔드 서버의 부하를 낮추어졌다.
물론 당장은 월 트래픽이 약 1000회정도로 작은 서비스이지만 서비스의 규모가 커지더라도 발빠르게 대응할 수 있는 준비를 맞추어둔 것이나 다름 없다.
현업에서 적용
사실 AWS 이전 작업이 결과적으로 봤을 때 소잡는 칼로 닭을 잡은 느낌은 있다.
특히 Cloudfront는 물론 캐싱 기능을 제공해주고 높은 보안성을 담보해주는 장점이 있긴하지만, 서비스가 한국 중에서 42 서울 교육생들을 대상으로 하는 것이기 때문에 사실상 글로벌 로케이션 기능이 쓸모가 없게되어서, 있어서 나쁠건 없지만 너무 과하지 않았나 생각이 들었다.
비용적인 측면을 전혀 고려하지 않아도 됐었기에 경험해보는 측면에서 Cloudfront를 이용했지만, 우리가 실제 기업이었다면 아마 절대 사용하지 않았을 것 같았다.. ㅎㅎ
하지만 현업에서는, 특히 스타트업에서는 여기서 얻었던 경험이 크게 도움이 될 수 있을 것이라고 생각한다.
갑자기 회사가 크게 성장하여 서비스 규모를 확장해야 하는 상황에서, 이미 서비스를 어떻게 확장할 수 있는지 경험을 해본 사람과 그렇지 않은 사람의 차이는 분명히 존재할 것이기 때문이다.
