개요

해당 글은 가상의 사례들의 시나리오를 작성하고 각각 사례들에서 가정한 요구사항과 해결 방안을 통해 시스템이 확장해 나가는 과정을 정리한 글이다.

일상에서 발생할 수 있는 사례들의 가정을 통해 단일 서버로 구축되어 있던 작은 서비스에서 추후에 확장성을 고려해 다중화를 지원하는 서비스까지 확장해 나가며 시나리오를 작성하고,

다양한 상황에서 발생할 수 있는 다양한 요구사항 및 요구사항에 대한 해결 방안을 고민해보며 시스템 확장 설계에 대한 이해도를 길러보기 위해 작성한 글이다.

단일 웹서버

시나리오

A는 개발자의 꿈을 꾸며 코딩을 공부해나가던 통칭 “코린이” 이다.

A는 자신의 포트폴리오를 만들기 위해 고민하던 와중, 자신의 기술 스택 및 자기 소개를 담은
웹 페이지를 개발해 이력서에 링크로 남기면 어떨까 하는 생각이 들어 당장 개인 웹서버를 하나 개발하기로 결심했다.

A는 HTML, CSS, Javascript 만을 이용해 간단한 본인 PR만 업로드할 목적이므로, 별도의 Backend 없이 화면 몇 장을 퍼블리싱해 tomcat을 이용해 웹 서버를 구축하기로 결정했다.

A는 아직 웹 서버를 구축해본 경험이 없어 일단 경험해볼 겸 자신이 사용하던 개인 컴퓨터에 가벼운 단일 웹 서버를 구축하기로 결정하였다.

위의 시나리오에서, A군은 자신의 초기 서비스의 빠른 오픈을 위해 별도의 확장성을 고려하지 않고 서비스를 설계하였다.

A군은 별도의 설계 없이 자신이 전달할 몇 가지의 정보를 담은 웹 페이지 몇 장을 구현해 평소에 사용하던 개인 PC를 통해 웹 서버를 구축하여 서비스를 제공했다.

요구사항

서비스는 방문자가 페이지에 방문했을 때, 구현해놓은 웹 페이지를 방문자에게 전달해 줄 수 있어야 한다.

데이터베이스 도입

시나리오

자신의 기술 스택 및 자신이 어떤 사림인지를 소개하는 페이지를 개발한 A군.

하지만 A군은 모든 내용을 HTML 파일 안에 일일이 작성하여 웹 서버에 기재한 탓에,

기재한 내용에 대해 변경 사항이 생기거나, 오탈자를 발견했을 경우 웹서버에 올라가 있는 파일을 직접 수정하거나 최악의 경우 파일을 다시 개발하여 업로드 해야 하는 상황에 직면했다.

A군은 이와 같은 상황을 벗어나기 위해, 페이지에 기재된 내용 중 변경 사항이 발생할 수 있는 부분을 분리하여 따로 관리하려고 한다.

그리하여 A군은 데이터베이스를 구축하고 이후 구축 해놓은 데이터베이스에서 미리 작성한 내용을 읽어와 방문자에게 보여주는 역할을 수행할 Backend 서버를 개발하여 자신이 기존에 개발했던 화면에 연결하기로 결심했다.

위 가정의 상황에서, A군은 변경된 요구 사항을 충족시키기 위해 기존에 사용하던 단일 웹 서버 구조를 탈피하여 기존의 단일 웹 서버 구조에서 WEB & WAS 서버 / DB 서버의 구조로 시스템 구조를 변경하였다.

A군은 방문객이 자신의 사이트를 방문했을 때, DB에 저장되어 있는 포스트를 조회하여 화면을 구성한 후 방문객에게 전달하려고 한다.

이를 위해 본문을 미리 작성해 DB에 저장시켜 두고, 최초 방문 시 해당 내용을 DB에서 조회해 웹 페이지에 전달해주는 Backend 서버를 구축하였다.

요구사항

서비스는 사이트에서 보여줄 내용을 DB에 저장해 두다가, 방문자가 최초로 방문 시 해당 내용을 조회해 보여주어야 한다.

스케일 아웃

시나리오

서버 엔지니어 지망생인 B군.

B군은 요즘들어 자신이 진행하고 있는 프로젝트의 서버가 불안정한 모습을 보이는 것을 확인했다.

아마도 서버로 사용하고 있는 컴퓨터의 성능이 문제인 것으로 파악되지만, 학교에서 강의를 위해 제공되는 저 사양 PC를 이용해 서버를 구축한 터라 더 이상의 성능 업그레이드는 불가능 했다.

결국 B군은 이 문제를 해결하기 위해, 프로젝트 팀원 모두와 회의를 진행한 끝에 웹 서버를 분리하여 부하를 분산시키기로 결정했다.

그래서 기존에 단일로 존재하던 서버를 두 개의 PC에 설치하고 사용량에 따라 특정 서버에 부하가 많이 발생할 경우, 그 이외의 서버에 사용자를 연결해주게끔 설계를 진행했다.

위 가정의 상황에서, B군은 기존의 단일 서버에서 더 이상의 스케일 업이 불가능한 상황이라고 판단하고 스케일 아웃 형태로 서버를 확장하는 것을 선택하였다.

초기 사용자가 적을 때에는 서버를 분리하여 다중화 하는 것 보다 서버 단말 자체의 사양을 업그레이드 하는 것이 더 나은 선택이 될 수 있으나,

해당 경우에는 더 이상 서버 단말을 업그레이드 할 수 없는 특수한 상황이라 서버를 다중화 하는 것을 선택하였다.

요구사항

서비스는 사용자가 많아져 자신의 서버 단말에 부하가 발생했을 경우, 사용자의 요청에 대한 별도의 제한 없이 해당 부하를 해소시킬 수 있어야 한다.

로드 밸런서 도입

시나리오

스케일 아웃을 진행하기로한 B군과 B군의 팀원들.

하지만, 서버 자체에서 트래픽을 어떻게 감지하여 어떻게 다른 서버로 요청을 전달 하게끔 구현해야 하는지 방법을 몰라 고민하던 중,

서버의 트래픽 관리 및 부하 분산을 위해 로드 밸런서를 도입하기로 결정 했다.

기존의 사용자의 트래픽이 바로 서버로 전달되던 구조에서,

다중화한 서버의 앞에 로드 밸런서를 설치해 트래픽 발생 시 로드 밸런서가 먼저 해당 트래픽을 감지해 현재 가동중인 서버들의 상태를 확인하여 상태가 양호한 서버로 전달해주게끔 설정했다.

해당 부분에서 B군은 스케일 아웃을 적용하며 다중화된 서버에 트래픽을 분산해주기 위해 로드 밸런서를 설치하기로 결정했다.

로드 밸런서는 다중화된 서버의 트래픽을 모니터링 하며 하나의 서버 인스턴스에 트래픽이 몰리지 않고 고루 분산되도록 앞에서 먼저 사용자의 트래픽을 전달 받아 각각의 서버 인스턴스에 전달하는 역할을 한다.

요구사항

서비스는 사용자의 트래픽을 다중화된 서버에 고루 배분하여 리소스를 낭비하지 않고 처리할 수
있어야 한다.

세션 관리

시나리오

우여곡절 끝에 로드 밸런서까지 성공적으로 도입한 B군.

바뀐 설계를 토대로 서버를 구축한 상태에서 다시 부하 테스트를 시작하는데, 간헐적으로 사용자의 세션이 초기화되는 현상이 발생했다.

해당 문제의 원인을 찾기 위해 살펴보던 도중 사용자의 인증 세션 관리를 WAS에서 전담하고 있다는 것을 발견한 B군은

기존의 세션 관리 방식을 WAS에서 관리하는 것이 아닌 JWT 토큰 형식으로 변경해 별도의 세션 관리 없이 서버에서 토큰을 이용해 인증 및 인가를 관리하는 방식으로 변경했다.

위의 가정에서 B군은 부하 분산을 위해 사용자의 요청을 기존 WAS가 아닌 다른 WAS에 전달했을 경우에도 해당 사용자의 인증이 유지되어야 한다는 요구 사항을 충족하기 위해,

기존의 WAS의 세션 관리를 이용해 서버 단에서 세션을 유지하던 방식에서 사용자 인증 완료 시 토큰을 발급해 사용자의 쿠키에 담아 전달하고 해당 토큰을 이용해 인가를 진행하는 방식으로 구조를 변경하였다.

요구사항

사용자는 한 번 인증을 통과하여 세션이 유지되고 있는 경우, 어떤 서버에게 정보를 요청해도 해당 인증이 유지되어야 한다.

CDN 도입

시나리오

세션 관리 방식을 변경해 다중화된 서버에서도 사용자의 인증 상태를 유지할 수 있게된 B군과 B군의 팀원들.

그들은 이제 본격적으로 자신들이 구축한 서비스의 단위 테스트 및 부하 테스트를 진행하며 서비스를 안정화 시키고 불편 사항들을 개선해 나가는 중이었다.

그러던 중 자신들이 만든 서비스의 최초 화면 진입 속도가 최초 구현에 비해 조금씩 느려지고 있는 것을 확인하고는 해당 사유를 분석했고,

이내 자신들이 추가한 정적 리소스가 초기 구현에 비해 시간이 지날수록 점점 많아져 화면의 최초 로딩 속도를 떨어트리고 있다는 것을 발견했다.

B군과 팀원들은 이 문제를 해결하기 위해 정적 리소스들을 모아서 CDN을 구축해 해당 CDN을 통해 관리하기로 결정하였다.

위의 시나리오에서 B군은 자주 사용되는 정적 리소스들을 캐시하여 페이지의 로딩 속도를 개선하기 위해 CDN을 도입하기로 결정했다.

이를 이용해 자주 사용되는 로고 이미지나 메인 화면의 아이콘 및 사진들을 캐시하여 보관해두고, 추후 사용자 요청이 들어오면 접속 요청 지역에서 제일 가까운 캐시 서버를 통해 미리 캐시해 놓은 정적 리소스들을 사용자에게 전달하여 서비스 응답 속도를 향상시켰다.

요구사항

변경 사항이 적은 정적 컨텐츠(css, js, 그 밖의 resource 파일)을 보다 빠른 속도로 불러와 사용자의 요청에 전달 할 수 있어야 한다.

지금까지 다양한 가상의 사례들을 통해 시스템이 확장되어 가는 요구사항 및 해결 과정을 그려보며 그에 따른 확장 방법 및 개선 사항들을 알아보았다.

이 밖에도 다양한 사례들이 있는 만큼 설계 및 확장에 대한 대략적인 개념을 익혀 추후에 발생할 문제에 대해 더 잘 대응할 수 있게 되었으면 좋겠다.