# 문제점
실제 애플리케이션이 사용자로부터 사용되기 위해서 로컬환경이 아닌 외부 원격 서버에 배포되어야 하는 필요성이 있었고, 이를 위해 AWS에 배포환경을 구성해보기로 했습니다. 하지만 AWS에 배포하기 전 AWS에서 제공해주는 서비스는 무엇이 있으며 어떻게 활용해야 이전에 작성한 아키텍처 설계와 같은 동작을 할 수 있는지 학습부터 할 필요가 있었습니다.
# 해결방안
AWS는 전자 상거래 사이트를 운영하는 아마좃닷컴의 자회사인 아마존 웹서비스 사가 제공하는 클라우드 플랫폼으로 전 세계에서 이용합니다. AWS를 이용하면 IT와 관련된 각종 시스템을 구축하고 운영할 수 있습니다. 개인은 물론 글러볼로 전개되는 대규모 서비스에 이르기까지 다양한 분야에서 AWS를 활용할 수 있습니다.
어플리케이션/서비스를 구축하고 운영하는 환경을 인프라스트럭처라고 부르는데 AWS는 이러한 인프라스트럭처를 구축하고 다양한 AWS 서비스를 제공합니다.
예를 들어 어플리케이션 개발자나 개발업체는 비즈니스나 업무에 필요한 독자적인 어플리케이션을 개발합니다. 이렇게 개발한 어플리케이션을 움직이는 인프라스트럭처를 AWS로 준비하고, 해당 어플리케이션을 인프라스트럭처 위에 배포합니다.
이후 어플리케이션 사용자는 브라우저나 스마트폰등으로 해당 어플리케이션에 접속하고 이용하지만 인프라스트럭처를 AWS를 이용해 구축했는지 여부는 알 수 없습니다. 그러나 결론적으로는 안정된 서비스를 제공받을 수 있게 됩니다.
AWS와 같은 클라우드 플랫폼으로 배포하는 경우 얻을 수 있는 장점은 다음과 같습니다.
- 1. 고정비용을 변동 비용으로 전환
온프로미스 방식으로 서버를 구축하던 기업은 초기에 매우 높은 가격의 투자비용을 지불하고 이후에 투지 비용을 회수하는 방법으로 수익을 가져갔다면 클라우드 방식을 이용할 경우에는 매월 일정 금액만큼만 지불하면 되기에 성장이 필요한 기업의 입장에서 매우 매력적인 방식으로 다가올 수 밖에 없습니다.
- 2. 성장을 고려한 용량 예측 불필요
클라우드 환경에서는 서버의 규모를 늘리거나 줄이는 것이 매우 간단하기에 회사 규모의 변화에 따라 유연하게 서버를 관리해 불필요한 소비를 방지할 수 있습니다.
- 3. 검증 및 개발 기간 단축
시간 단위로 기기를 임대하는 클라우드에서는 신기술을 검증하는 최신 기자재 등을 정해진 기간에 제공할 수 있습니다. 따라서 변화가 빠른 IT 기술에 뒤쳐지지 않고 따라갈 수 있습니다.
- 4. 데이터센터 유지보수 불필요
서버나 네트워크 등의 장비는 클라우드 제공자가 운용하기 때문에 기기 설치나 케이블 배선, 기자재 조달이나 계약같은 일체의 보수 작업은 신경쓰지 않아도 됩니다.
다음은 AWS에서 인프라스트럭처를 구성하는데 필요한 개념들과 제가 구성한 인프라스트럭처를 소개하고 설명하겠습니다.
1. VPC
AWS를 이용해 네트워크를 구축할 때는 VPC(Virtual Private Cloud)라는 시스템을 이용해야 합니다.
VPC는 AWS의 데이터센터에 있는 전용 기기에서 서버나 네트워크 장비가 가진 기능을 에뮬레이션하는 소프트웨어를 작동시켜, 물리적인 기기를 이용하지 않고 가상의 네트워크를 구축할 수 있습니다. 따라서 기기 추가나 삭제를 소프트웨어 실행이나 정지처럼 간단히 수행할 수 있고 타 VPC와는 독립적이므로 서로 영향을 미치지 않습니다.
2. 서브넷
VPC는 하나 이상의 서브넷을 가져야 합니다. 서브넷은 VPC의 IP 주소 범위를 나누는 단위를 의미합니다.
서브넷을 나누는 이유는 크게 외부에 공개되는 리소스 여부를 구분하고 내결함성 높이기 위해 물리적인 이중화를 수행하기 위함이라고 볼 수 있습니다. 즉, 각 리소스의 공개 여부를 나눠 역할을 구분하고 가용영역을 구분해 특정 서브넷 서버의 다운으로 인한 장애를 방지할 수 있습니다.
서브넷의 CIDR과 리소스 수는 트레이드 오프 관계입니다. 즉 서브넷 비트 수를 증가시키면 해당 서브넷에서 생성할 수 있는 리소스의 수는 줄어드는 구조입니다. 그래서 서브넷 범위와 리소스 수를 고려해 가각의 여유있는 크기로 구성하는 것이 중요합니다.
3. EC2
EC2는 가상 서버를 의미합니다. EC2 인스턴스를 특정 서브넷에 생성하면 EC2에서 CPU, 메모리, 디스크 등이 제공되고 MacOS, Linux와 같은 OS도 설치해 사용할 수 있습니다.
Amazon Linux vs Ubuntu
EC2의 AMI(Amazon Machine Image)를 선정해본다면 Amazon Linux와 Ubuntu에서 하나를 선택해보기로 했고 각 이미지의 차이점과 장점을 비교해봤습니다.
| Amazon Linux | Ubuntu |
|---|---|
| Amazon에서 개발하고 지속적으로 유지 관리합니다. | Canonical에서 개발 및 유지 관리합니다. |
| Amazon 웹 서버 및 컴퓨팅 클라우드만 지원합니다 | Microsoft Azure, Google 클라우드 및 IBM 클라우드를 포함하되 이에 국한되지 않는 모든 주요 웹 호스팅 및 컴퓨팅 서비스를 지원합니다 |
| 웹 서비스 및 머신 이미지에만 사용됩니다 | 가정용 컴퓨터와 웹 서버 모두에서 사용할 수 있습니다 |
| Amazon EC2 사용자에게는 무료입니다 | 무료 및 프리미엄 플랜이 있습니다 |
| Amazon 웹 서비스 도구가 사전 설치되어 제공되므로 EC2 인스턴스 내에서 스크립팅이 가능합니다 | AWS 관련 도구가 사전 설치되어 제공되지 않습니다 |
두 AMI를 비교해본 결과, Ubuntu가 이후에 변경될 수 있는 작업 및 배포 환경에 대해서 지원가능하다는 점이 유연한 대처가 가능할 것이라는 판단 하에 Ubuntu를 AMI로 선정하게 되었습니다.
4. 로드밸런서
로드밸런서는 Scale Out을 통해 서버의 개수를 늘리는 확장 서버에서 트래픽 과부하를 방지하기 위해 사용자의 요청을 대신 받아 웹서버로 분산해 전달해주는 역할을 합니다.
AWS 에서 로드밸런서는 ELB로 구성할 수 있고 HTTP나 HTTPS 접근에 대한 처리를 위해선 ELB(Elastic Load Balancer)를 사용할 수 있습니다. ALB는 웹사이트나 REST API를 제공하는 사이트를 구성할 때 주로 사용됩니다. 그 외에도 Network Load Balancer(채팅, 게임 등), Classic Load Balancer(앞의 두 로드밸런서가 등장하기 전에 사용)도 제공해줍니다.
로드밸런서는 요청 분산에 대한 역할 뿐만 아니라 SSL(송수신 데이터 암호화), 부정 요청 대응(부정 요청에 대한 선제적 조치), 요청 라우팅(포트 번호 변환 기능) 등의 기능도 소화해줍니다.
5. RDS
Private 서브넷에서 위치한 웹서버와 DB를 연동하기 위해서는 RDS를 활용해볼 수 있습니다. RDS는 AWS에서 다양한 DB 플랫폼을 구성하는데 있어서 매니지드 서비스를 제공해 사용자가 단순히 이용할 제품이나 성능 등을 지정만 하면 그 외의 작업은 알아서 제공해줘 EC2에 직접 DB를 설치해 활용하는 것보다 안전하고 간편한 구성을 할 수 있습니다.
6. ElastiCache
ElastiCache도 RDS와 같은 맥락의 역할로써 Redis나 Memcached를 이미 적용한 환경을 제공해줍니다. 또한 클러스터 모드와 프리어머리&복제 노드를 구성하는 것도 사용자가 스펙을 지정만 하면 ElastiCache에서 생성해주기 때문에 편리한 저장소 구성이 가능합니다.
7. 작성된 인프라스트럭처
위의 개념을 학습하고 제가 구성한 아키텍처 설계에 맞게 구성한 AWS 인프라스트럭처는 다음과 같습니다.
VPC & 서브넷
하나의 VPC를 구성하고 그 안에 public, private 서버로 두개의 서브넷을 구성했습니다.
CIDR은 서브넷 비트수를 4비트로 구성하면서 리소스는 12비트로 구성했습니다. 이렇게 되면 서브넷은 최대 16개까지, 리소스는 4091개까지 구성이 가능해 일반적인 상황에서 가장 보편적인 배분을 선택했습니다.
채팅 서버(배스천 서버)
채팅 서버의 경우, 사용자의 웹소켓 연결을 위해 직접 사용자가 접근해야 합니다. 그래서 채팅 서버를 위한 인스턴스는 public 서브넷에 구성했습니다.
그리고 해당 인스턴스는 배스천 서버의 역할도 동시에 수행합니다. 배스천 서버는 외부에서 직접 접근할 수 없는 private 서브넷에 존재하는 인스턴스에 접근하기 위한 중간 매개체 역할을 하는 서버를 의미합니다.
API 서버(웹 서버)
API 서버의 경우, 외부에서 직접 접근하지 않고 사용자의 접근에 대해 로드 밸런서에서 대신 요청을 받아 넘겨주도록 구성하기 위해 private 서브넷에 구성했습니다. 외부 접근을 제한함으로써 보안성을 높이고 리소스의 손실을 방지할 수 있습니다. 그리고 API 서버만이 RDS와 ElastiCache와 연동되어 동작하도록 구성했습니다.
로드밸런서
로드밸런서는 ELB로 public 서브넷에 생성해 사용자의 요청을 API 서버 대신 받아 분산처리, SSL의 역할을 해주도록 구성했습니다. 채팅서버의 경우에도 Heart Beat 정보를 API 서버에 전달할 때, 로드밸런서에 요청을 보내도록 했습니다.
RDS & ElastiCache
앞서 말했던 것처럼 RDS와 ElastiCache는 private 서브넷에 위치한 API 서버와만 연동되어 동작하도록 구성했습니다.
# 마치며
AWS 인프라스트럭처 설계를 직접 해보면서 EC2 인스턴스를 추가하거나 다른 가용영역에 서브넷을 구성하기에 무리없는 설계를 구성할 수 있었고, AWS의 여러 서비스를 직접 다뤄보면서 배포환경을 구성하는 경험을 할 수 있었습니다.
# 참고자료
- http://www.yes24.com/Product/Goods/109747932
- https://velog.io/@alicewland/AWS-1