[AWS] 운영 서버와 AWS

졍·2022년 7월 7일

운영 서버

운영 서버는 개발이나 테스트 목적이 아닌 실제 사용자들을 대상으로 서비스하는 서버를 말한다. 테스트 목적의 서버라면 많은 요청이 발생할 일도 없고 장애가 발생하더라도 큰 문제가 생기지 않지만 운영 서버는 그와 다르게 트래픽 대응도 해야 하고 빠른 응답 속도와 높은 가용성을 보장해야 한다. 그러기위해 운영 서버는 테스트 서버와 다르게 다양한 구성 요소들을 포함해야 한다.

운영 서버 관리의 세 단계

1. 환경 구성

서비스할 코드를 구동시킬 수 있는 서버 인프라를 구축하는 것

2. 코드 배포

앞서 구성한 환경에 최신 버전의 코드를 빠르고 안전하게 배포하는 것

3. 모니터링

안정적인 서비스 운영을 위해 서버와 코드에 어떤 이상이 없는지 바로 파악하고 대응할 수 있게 도와주는 것

AWS

AWS의 탄생 배경

AWS는 미국 기업인 아마존에서 만든 클라우드 서비스 플랫폼이다. 인터넷 쇼핑몰을 운영하던 아마존은 2000년도 쯤 늘어난 트래픽과 주문량을 감당하다 보니 자연스럽게 굉장히 뛰어난 수준의 내부 인프라 시스템을 구축하게 됐다. 컴퓨팅, 스토리지, 데이터베이스 등 운영 서버에 필요한 인프라를 누구보다 안정적이고, 규모를 키울 수 있으며, 저렴하게 운영할 수 있는 능력을 아마존 쇼핑몰 하나에만 제공하기보다 전 세계 모든 회사를 대상으로 제공하자는 생각을 하게 됐고 결국 2006년부터 이 인프라를 누구나 쉽게 사용할 수 있게 만들어 다른 회사에 돈을 받고 서비스하게 되면서 AWS가 탄생했다.

운영 서버에 필요한 서비스들을 제공하는 AWS

AWS에서는 단순히 컴퓨팅 서버만을 제공하는 것이 아니라 운영 서버에서 자주 사용되는 온갖 서비스들을 함께 제공한다. 데이터베이스, 배포 자동화, 모니터링, 이메일, 보안, 테스트, 도메인 등 100가지가 훨씬 넘는 서비스들을 제공하고 있다. 이러한 서비스 대부분은 모두 아마존 내부에서 더 편하게 운영 서버를 관리하기 위해 만들어서 사용하다 어느 정도 완성도가 높아지면 다른 회사들도 사용할 수 있는 서비스로 공개한 것들이다.

AWS 같은 클라우드 서비스를 이용하지 않는다면 직접 서버를 구매하여 MySQL과 같은 RDB를 설치 및 관리해야 하지만 AWS의 DB서비스인 RDS를 이용하면 몇 번의 클릭만으로 RDB를 생성하고 안정적으로 운영할 수 있다.

클라우드 플랫폼 서비스로서의 AWS

아마존뿐만 아니라 구글(Google Cloud), 마이크로소프트(Azure), 네이버(네이버 클라우드 플랫폼) 같은 인터넷 대기업들도 클라우드 서비스를 제공하고 있다. 하지만 AWS는 전 세계 클라우드 시장에서 33%가 넘는 수준을 자랑하고 있다.

클라우드 서비스 플랫폼을 써야 하는 이유

AWS가 아니더라도 클라우드 서비스 플랫폼은 기존의 운영 서버 관리 방식보다 훨씬 많은 이점을 가져온다. 예전에는 서버를 직접 구매한 후 회사나 IDC에 설치해서 관리해야 했고, 이 서버들이 문제없이 돌아가게 하기 위한 전문 인력들도 필요했다. 서버뿐만 아니라 서버에 설치되는 수많은 인프라에 대해서도 전문 인력들이 필요했다. 또한 필요에 따라 유연하게 서버를 늘리거나 줄이기 힘들기 때문에 서버를 넉넉히 구매해놓고 사용하지 않는 비효율적인 자원 낭비도 많았다.

하지만 클라우드 서비스를 이용할 경우 필요한 사양의 서버를 몇 번의 클릭만으로 추가하거나 제거할 수 있고 사용한 시간만큼만 금액을 지불하면 된다. 또한 클라우드 서비스 제공 업체에 최고의 전문 인력들이 있으니 개개인이 안정성이나 성능 등에 대해서도 고민을 훨씬 덜 해도 된다. 결국 훨씬 적은 비용, 시간, 인력으로도 큰 규모의 서비스를 운영할 수 있는 것이다.

전 세계에서 사용할 수 있는 AWS

AWS는 현재(20220707기준) 전 세계 22개 지역에 인프라를 구축해서 호스팅하고 있는 글로벌 서비스다. 지리 영역을 리전(region)이라고 부르는데, 사용자가 가장 많은 곳부터 리전을 만들고 있으며, 그 수도 계속해서 늘려가고 있다. 서비스하려는 지역에 가장 가까운 리전을 선택해야 네트워크 지연 시간을 최소화할 수 있다. 한국에는 서울 리전이 있으며 일본에는 도쿄와 오사카 리전이 있다.

대부분의 서비스는 모든 리전에 제공되지만 새로 생성된 서비스는 리전에 따라 조금 늦게 오픈되는 경우도 있다. 리전별로 몇 개월 정도 차이가 있으며 서울 리전은 다른 리전에 비해 조금 늦게 오픈되는 편이다. 리전별로 제공하는 기능은 AWS 리전 표에서 확인할 수 있다.

AWS는 하나의 리전 안에서도 여러 격리된 위치에 데이터 센터들을 운영하고 있다. 이를 가용 영역이라고 한다. 가용 영역은 장애에 대응하는 것이 가장 큰 목적인데, 예를 들어 서울 리전 안에 있는 A 가용 영역 데이터 서버에 문제가 생기더라도 B 가용 영역에 있는 데이터 센터에서 정상적으로 서비스를 제공할 수 있다.

운영 서버의 환경 구성

운영 서버 아키텍처의 이해

단일 서버

가장 기본적인 구성이다. 요청을 보내는 클라이언트와 요청을 처리하는 서버가 한 대 있다. 여기서 얘기하는 클라이언트는 우리가 흔히 사용하는 핸드폰 앱이나 크롬과 같은 웹 브라우저 등을 의미한다. 서버 내에는 애플리케이션 코드와 데이터베이스가 실행된다. 매우 단순한 구성인 만큼 환경을 구축하기 쉽기 때문에 테스트 서버나 간단한 애플리케이션을 서비스할 때 많이 사용된다. 그리고 데이터베이스와 애플리케이션이 같은 서버에서 실행되고 있기 때문에 별도의 네트워크 설정을 할 필요 없이 로컬 호스트를 대상으로 하면 된다. 하지만 다음과 같은 단점이 있다.

첫 번째, 전체 서비스의 장애가 생길 확률이 높다.
애플리케이션과 데이터베이스가 같은 자원을 공유하기 때문에 둘 중 하나라도 자원을 모두 사용해버리거나 서버 하드웨어에 장애가 발생하면 해당 부분만 장애가 생기는 것이 아니라 전체 서비스가 완전히 죽어버린다.
두 번째, 서버 자원을 효율적으로 사용하기 어렵다.
애플리케이션과 데이터베이스는 각 속성에 따라 더 중요한자원의 종류(CPU, 메모리, 디스크)나 최적화를 위해 필요한 OS 설정(I/O 컨트롤러, 디스크 설정)이 다를 수 있다. 둘 다 만족시키기 위해서는 필요 이상으로 고사양 서버를 사용해야 할 수도 있다.
세 번째, 보안성이 떨어진다.
데이터베이스는 보안상 포트나 IP 등 접속 지점을 최소한으로 하는 것이 좋다. 하지만 웹 어플리케이션 특성상 다양한 IP 주소와 포트 번호에 대해 요청을 받을 수 있어야하고 서버 내 여러 파일들도 업로드 될 수 있으므로 데이터베이스가 공격당할 가능성이 높아진다.
마지막으로, 서버의 수를 여러 대로 늘려서 자원을 확장하는 스케일 아웃(scale out)이 힘들다.

서버자원의 확장을 위해 서버를 여러 대로 늘려야 하는 경우 클라이언트에서는 추가된 서버들의 주소를 새로 알아야 하며 데이터도 똑같은 복제본이 여러 개 생기므로 관리하기가 매우 힘들어진다.

애플리케이션/데이터베이스 서버 분리

단일 서버 구성에서 데이터베이스를 별도의 서버로 분리한 구성이다. 애플리케이션과 데이터베이스가 다른 자원을 사용하기 때문에 단일 서버에서 나온 전체 서비스 장애 확률, 효율적인 자원 사용, 떨어지는 보안성과 같은 단점들이 해결된다. 다만 두 대의 서버를 관리하기 때문에 구성이 조금 더 복잡해지고 서버 사이의 지연 시간과 네트워크 보안을 고려하기 시작해야 한다. 그리고 클라이언트에서는 하나의 서버만을 바라보고 있기 때문에 서버 자원 확장을 위해 서버의 수를 늘리는 스케일 아웃은 여전히 힘들다.

서버 단위의 로드 밸런서

클라이언트가 애플리케이션을 실행하는 서버와 직접 통신하는 대신 로드 밸런서라는 서버와 통신하고 그 뒤에 여러대의 애플리케이션 서버를 두는 방식이다. 클라이언트는 로드 밸런서하고만 통신하고 로드 밸런서가 클라이언트에게서 받은 요청을 뒤에 있는 서버들에게 나눠준다. 뒤에 있는 서버들이 요청을 처리하면 응답은 로드 밸런서를 통해 클라이언트에 전달된다.

이 구성의 가장 큰 장점을 스케일 아웃이 가능해진다는 것이다. 그리고 애플리케이션 서버 중 일부 서버에 장애가 발생해도 로드 밸런서에서 정상 서버에만 요청을 주면 되기 때문에 서비스 장애를 최소화 할 수 있다. 다만 모든 요청이 로드 밸런서를 통해 지나가기 때문에 로드 밸런서에 장애가 생기면 나머지 서버들이 정상이어도 전체 서비스 장애로 이어지기 때문에 주의해야 한다. 또한 구성이 매우 복잡해진다는 단점이 있다. 흔히 OSI 7 레이어의 L4 스위치라고 얘기하는 것이 이 로드 밸런서의 역할을 하는 장비다.

서버 내 앱 단위의 로드 밸런서

여러 서버에게 요청을 분산하는 서버 단위의 로드 밸런서 외에도 여러 애플리케이션 프로세스들에 요청을 분산시키는앱 단위의 로드 밸런서가 추가됐다. 애플리케이션 서버 안에서 똑같은 애플리케이션을 여러 프로세스로 만들어 실행해 놓고 외부에서 들어온 요청을 프로세스 중 하나로 보내주는 역할을 하는 방식이다. 이처럼 구성하면 하나의 서버에 여러 개의 프로세스를 실행해 하나의 서버에서 여러 개의 요청을 동시에 처리할 수 있으며 서버 자원을 최대한으로 사용할 수 있는 만큼의 프로세스를 실행해 서버 자원도 더욱 효율적으로 사용할 수 있다.