확장 가능한 시스템 설계 예시

단일서버 형태의 시스템은 실제 서비스를 운영하는데에는 무리가 있다.

하나의 웹 서버만으로 구성되어 있기 때문에 장애가 발생하거나 트래픽 증가로 서버 자원의 한계가 올 때 정상적으로 서비스를 제공할 수 없는 상황이 발생하기 때문이다.

• 이러한 문제를 해결하기 위해 웹 서버를 추가하여 성능을 개선하는 '스케일 아웃'의 규모 확장 전략을 사용한다.
• 그리고 추가된 여러대의 서버에 트래픽을 고르게 분산하기 위하여 로드벨런서를 사용한다.
• 데이터베이스 또한 비슷하게 데이터베이스 다중화 전략이 사용된다. 다중화 전략이란 데이터를 여러곳에 복사하여 보관하는 방법으로 성능 향상 및 장애 복구 등에 효율적이다.
• 클라우드 서비스를 이용하여 서버에 탄력성과, 장애나 재해 등에 대한 고가용성을 보장받기도 한다.

그러므로 실제 서비스 운영을 위해서 위 기술들을 포함하여 다른 여러가지 기술 및 아키텍쳐 패턴을 이용하여 안전한 웹 서비스 제공 환경을 구성한다.

이번글에서는 내가 겪어본 웹 서버 구조 중 하나를 그려서 정리해 보고, 더 나아가 사용했던 기술들을 간략하게 정리하려 한다. 아래는 간략하게 그려본 서버 구조 이미지이다.

 

 

웹 서버구조 설계 예시

 

 

① 서버를 직접 운용하지 않고 Azure 클라우드 플랫폼을 이용하였다. 클라우드 플랫폼에는 여러가지 장점이 있는데

그걸 직접 느껴본 경험이 몇가지 있다.

• 보안 : 해당 서비스를 운영하던 도중 서버 로그를 띄워 놓은 모니터가 미친듯이 요동쳤다. 서비스 되던 국가가 아닌 다른 국가의 IP로 트래픽이 몰리는 현상이 갑작스래 발생한 것이다. DDoS를 직접 목격한건 이때가 처음이여서 당황하였는데, 대응은 간단했다.  Azure에서 제공 하는 기능을 이용하여 조건부 엑세스로 공격오는 국가로부터의 요청을 차단한 뒤 DDoS Protection를 사용하였다. 타 클라우드 서비스도 비슷한 기능을 제공할 것이고, 이러한 기능을 이용하면 여러가지 보안 문제를 상대적으로 쉽게 대응 가능할 것이다.
• 확장성 : 서비스가 흥함에 따라 트래픽이 점점 증가하였는데, 이에 따른 VM 추가가 용의하였다. VM 추가 뿐만 아니라 스펙을 향상시키는 '스케일 업'도 간단하게 진행할 수 있었다. 트래픽 증가에 대한 대응이 쉬웠던 기억이 있다.
• 이밖에 백업 및 복구, 서비스의 관리 및 모니터링 등이 간편하였다.

② 로드벨런서로 NGINX를 사용하였다.

• 들어온 요청을 분산하여 부하를 분산시키기 위하여 NGINX를 로드벨런서로 사용하였다.
• 각 서버의 가용성을 주기적으로 검사하여, 특정 서버에 장애가 났을 때 명시한 다른 서버로 트래픽을 전환하는 방법으로 서버의 장애를 관리하였다.

③ 분산 서버

• 트래픽이 점점 늘어남에 따라 처음 2대였던 VM을 점차 늘려 나중에는 7대를 운용하게 되었다.
• 어쩌다 다양한 이유로 한대 혹은 두대정도 VM을 정상적으로 운용할 수 없는 상태가 될 때도 있었다.
• 물론 서비스는 정상적으로 제공될 수 있었다.

④ 세션 클러스터링

• 서버 세션에는 사용자 인증 정보, 세션 유효성 정보, 인증 토큰 등 여러가지 값을 갖고 있다.
• 그런데 서버가 여러대인 분산 서버 환경인 경우 로드벨런스로 인하여 한 서버에서만 정보를 처리하지 않는다.
• 따라서 서버간에 세션이 다를 수 있는 세션 동기화 문제가 발생할 수 있다.
• 그렇기 때문에 모든 서버가 세션을 공유하는 세션 클러스터링을 통하여 문제를 해결하는데 
  보통 Redis를 세션 저장소로 많이 사용한다.

⑤ DB Master-Slave 구조

• 읽기 및 쓰기 작업 모두를 처리하는 마스터 서버와, 읽기 작업만을 처리하는 슬레이브 서버들로 구성하였다.
• 이로인해 서버의 읽기 부하를 슬레이브 서버로 분산시켜 성능을 향상시킬 수 있다.
• 또한 마스터 서버 장애시 슬레이브 서버 중 하나를 마스터 서버로 승격시켜 서버 가용성을 향상시킬 수 있다.
• 슬레이브 서버는 DB의 백업 복사본으로 사용될 수 있어서 장애복구등에 이용할 수 있다.

⑥ 배포 서버

• CI/CD를 위한 공용 서버가 있는 구조이다.
• 도커에는 여러 서비스들의 CI/CD를 위한 젠킨스 컨테이너들이 서비스중인 상태이다.
• 'gitlab-cicd.yml'에 명시된 스크립트에 따라 배포서버를 이용하여 자동배포되는 구조이다.

⑦ Git Repository

• 당연하게도 Git Lab 원격 저장소를 사용하였다.
• 실무에서는 Git Repository의 히스토리를 조회하며 소스의 최신 변경 사항을 공유하고 동기화 한다.
• 가끔 형상관리 중에 당혹스러운 경우가 발생하였는데, Git에서 제공하는 기능들로 비교적 쉽게 해결했던 기억이 있다.

 

① ~ ⑦ 항목에 대해서 간단히 정리해 보았다. 앞으로의 글들은 각 항목에 대해 좀더 자세히 알아보는 시간을 

갖으려고 한다. 이러한 시간을 통해서 내가 알고 있던 점들은 명확히 하고, 잘 몰랐던 부분들은 배워나갈 수 있는

시간이 되길 기대한다.