AWS로 3 Tier Architecture 고도화하기

이번 포스팅에선 AWS를 다채롭게 사용하여 대부분의 웹을 이루고 있는 3티어 아키텍처를 고도화하는 과정을 포스팅해보도록 하겠습니다. 

 

 

3 Tier Architecture

3계층 구조라고도 불리는 이 아키텍처는 현재 대부분의 웹의 구조입니다. 

 

이 3티어 아키텍처 말고도 1티어 2티어도 있는데 그냥 티어라는 것은 "서버를 물리적으로 분리했다"라고 생각하시면 됩니다. 

 

1티어 2티어 아키텍처에 대한 내용은 구글링하시면 쉽게 접할 수 있는 내용이기 때문에 이번 포스팅에선 넘어가도록 하겠습니다. 저는 3티어 아키텍처만 집중적으로 파보겠습니다. 

 

클라이언트 계층

흔히 정적 데이터(html, css, js, image)들이 들어가있는 계층으로서 3티어 아키텍처에선 주로 웹서버가 이 자리를 차지하고 있습니다. 

 

웹에선 이 계층을 "프론트엔드"라고도 부릅니다. 프론트엔드에선 UI / UX를 담당하기도 하고 서버로 트래픽을 분산시켜주는 로드밸런싱 역할을 하기도합니다. 

 

그래서 클라이언트계층에서 사용자와 조금 더 가까운 부분과 서버쪽에 조금 더 가까운 부분이 있습니다. 

 

조금 더 잘게 쪼갠다면 이렇게 될 수 있습니다. 

 

서버 계층

흔히 비즈니스 로직이 들어가있는 서버 계층은 클라이언트 계층과 소통하면서 사용자의 요청을 받아 데이터베이스에서 조회하기도하고 데이터를 가공하기도합니다. 

 

이 서버 계층은 보통 WAS (Web Application Server) 라고 부르기도 하고 더 잘 알려져있기를 "백엔드"라고 부릅니다. 제가 주로 공부하는 분야이기도하죠. 

 

클라이언트 계층에서 주로 사용되는 언어는 자바스크립트이지만 서버 계층에서 주로 사용되는 언어는 정말 다양합니다. Java, Node.js, Ruby, Python, C#, Go 등 다양한 언어로 개발할 수 있습니다. 

 

 

데이터베이스 계층

데이터베이스 계층은 3티어 중 가장 뒤에 위치하고 보통 서버와 소통하면서 데이터를 관리하는 계층입니다. 

 

데이터베이스에는 RDBMS와 NoSQL, IoT라면 RTDB등을 사용하고 어떤 데이터베이스 종류를 사용할 것인지는 팀에서 결정하고 우리의 아키텍처에 가장 잘 어울리는 것을 결정하면 좋을 것 같습니다. 

 

 

3 Tier Architecture With AWS

3티어 아키텍처에 대해서 대충 훑어봤고 이제 이 포스팅의 핵심 내용인 AWS를 이용해 3티어 아키텍처를 고도화하는 과정을 알아보겠습니다. 

 

하나하나씩 뜯어보면서 고도화해볼까요? 

 

클라이언트 계층

 

클라이언트 계층에서 AWS는 다양한 서비스들을 제공합니다. 

 

 - Route53 -

먼저 제일 앞에는 사용자가 검색창에 google.com을 검색하면 제일먼저 DNS인 Route53을 호출합니다. Route53이 DNS인지 모르시는 분들도 꽤 있더라구요. Route53에서 53이 DNS에서 사용하는 포트번호라서 이름이 Route53입니다. 

 

Route53은 가중치를 두고 동적으로 사용자의 요청을 분배할 수도 있기 때문에 이걸 로드밸런서로 사용할 수도 있다고 들었습니다. 하지만 Route53은 보통 DNS로 사용하는 경우가 일반적이라고 하더군요. 

 

- Web Application Firewall (WAF) -

WAF는 보통은 설계할 때 빼긴 할텐데... DDoS에 위험이 있는 경우에 Route53뒤에 위치하게 해서 DDoS의 위험으로부터 애플리케이션을 지켜줍니다. 

 

하지만 DDoS에 위험이 있는줄 어떻게 아나요 그냥 맞아보기 전까지 모르는거죠. 아무튼 WAF를 이용해서 방화벽을 설치하고 DDoS로부터 안전하게 지켜냅니다. 

 

- CloudFront -

CloudFront는 이름에서도 예측할 수 있듯이 정적 데이터들을 위치시키는 곳입니다. CloudFront는 CDN의 역할도 하기 때문에 빠르게 데이터를 사용자에게 전달할 수 있습니다. CDN에 대해서는 해당 포스팅과 결이 맞지않아 넘어가도록 하겠습니다. 

 

CloudFront는 아까 3티어 아키텍처 설명에서 클라이언트 계층에서 진짜 프론트엔드와 로드밸런서 이렇게 두개로 나눌 수 있다고 말씀드렸는데 바로 프론트엔드에 해당하는 AWS 서비스입니다. 

 

- Application Load Balancer (ALB) -

ALB는 로드밸런서로서 서버로 요청을 분산시키는 역할을 수행합니다. ALB는 로드밸런서 알고리즘 중 Round Robin과 Least Connection 이렇게 두가지를 제공해줍니다. Round Robin은 정적 로드밸런싱 알고리즘, Least Connection은 동적 로드밸런싱 알고리즘이죠. 정적하나 동적하나 이렇게 제공해줍니다. 

 

개인적으로 조금 더 많은 알고리즘을 제공해주면 좋을 것 같은데... AWS의 개발자들이 이거면 충분하다싶어서 이거 두개만 제공해주는거겠죠...

 

 

서버 계층

서버계층은 의외로 조금 간단하죠? 하나씩 알아보겠습니다. 

 

- EC2 -

EC2는 우리에게 매우 친숙하죠. 컴퓨터 한대를 AWS에게 빌리는거죠. AMI라는 이미지로 EC2를 언제든지 복제할 수 있다는 장점을 극대화한 ASG를 이용할 수도 있습니다. 

 

- Auto Scaling Group (ASG) -

EC2를 AMI로 이미지화하여 템플릿을 만들어두고 이를 ASG에 등록하면 ASG는 개발자가 설정한대로 EC2를 복제할 수 있습니다. 

 

ASG의 좋은 점은 ALB의 타겟 그룹으로 ASG를 설정할 수 있어서 ASG에 의해 늘어난 EC2를 즉각적으로 ALB에 부착시킬 수 있습니다. 

 

쉽게 설명하자면 ALB가 ASG를 바라보고 있어서 ASG에서 생성되는 EC2를 늘어나는 족족 로드밸런싱할 수 있다는 것입니다. 

 

- Cloud Watch -

Cloud Watch는 AWS의 모니터링 서비스입니다. Cloud Watch에 EC2인스턴스를 등록하고 다양한 메트릭을 모니터링할 수 있습니다. CPU사용량부터 메모리 사용량, 네트워크 I/O 등등 다양한 것들을 모니터링할 수 있죠. 

 

또한 Cloud Watch의 큰 장점은 알람을 보내준다는 것입니다. Cloud Watch Alarm이라는 Cloud Watch속 서브 서비스로서 특정 조건에 EC2 인스턴스가 도달하면 알람을 보내줍니다. 

 

또한 알람뿐만 아니라 이벤트를 걸어줄 수도 있습니다. 이 이벤트를 이용해서 다양한 것들을 할 수 있는데, 예를 들어서, CPU사용량이 80퍼센트에 도달하면 ~행동을 해라 라고 명령할 수 있다는 것이죠. 

 

 

데이터베이스 계층

데이터베이스도 간단합니다! 한번 알아보죠!

 

- Relational Database (RDS) - 

RDS는 가장 기본적은 RDBMS를 제공해줍니다. 다양한 데이터베이스를 선택할 수도 있고 자동으로 레플리카를 만들어주기도합니다. 또한, 백업본까지 만들어줍니다 (대박)

 

하지만 제가 생각하는 RDS의 단점은 겁나 비싸다는것... 제가 아직 배움이 부족해 싼 RDS가 있을 수도 있는데 제가 프로젝트 진행하면서 RDS를 알아봤는데 죄다 비싸더군요. 

 

- DynamoDB - 

DynamoDB는 AWS에서 제공해주는 NoSQL 데이터베이스입니다. NoSQL 데이터베이스이니만큼 NoSQL의 장점을 그대로 흡수했습니다. 확장성과 유연성이 대단한 데이터베이스입니다. 

 

- Key Management Service (KMS) -

KMS는 AWS에서 키를 관리해주는 서비스입니다. 엥? 키? 하겠지만 이 키를 이용해서 Secret Manager와 함께 사용하면 데이터베이스의 접근이라던가 이런 것들을 더 쉽게 해줄 수 있습니다. 

 

KMS는 AWS서비스 전반에 걸친 키를 관리해주는데 예를 들어서 S3를 보호하는 목적으로도 쓰입니다. 일단 제가 아는건 데이터베이스와 S3와 같은 스토리지에 적용할 수 있는 것으로 알고있습니다. 아마 EFS도 가능할지도?

 

- Secret Manager -

Secret Manger는 KMS를 이용해서 데이터베이스와 관련된 다양한 비밀정보들을 관리할 수 있게 해줍니다. 예를 들어서 데이터베이스 유저라던가 아니면 다양한 파라미터들을 관리해주는 것이죠. 

 

 

번외

3티어 아키텍처에서 가장 중요하지만 빠진 것이 있습니다. 바로 네트워크입니다. AWS에선 네트워크를 VPC라는 서비스로 관리하는데 VPC는 private subnet과 public subnet을 이용해서 네트워크를 설정해줄 수도 있습니다. 

 

보통 네트워크는 서버 계층과 데이터베이스 계층을 private subnet으로 두어 외부에서 접근을 막는 것이 일반적입니다. 그래서 ALB를 앞에 두고 이 ALB의 Target Group이 private subnet의 EC2로 향하게 하여 EC2의 접근을 외부에서 막는 것이 좋다고 합니다. 

 

엥? 외부에서 접근을 못하면 서버에 어떻게 들어가요...

 

바로 바스티온 서버를 두면 됩니다. 바스티온 서버는 외부에 열려있고 내부에 있는 서버로 접근을 위한 용도로 두는 서버입니다. 이렇게 두면 장점이 서버로 들어가는 모든 요청은 ALB를 타고 들어가야한다는 것입니다. 

 

ALB앞엔 앞서 말했다시피 WAF라는 방화벽이 있기 때문에 왠만한 것들은 전부 막을 수 있죠. 

 

 

정리

자 여기까지 3티어 아키텍처를 AWS를 이용해서 고도화해봤습니다. 제가 써본 것도 있고 안써본 것도 있네요. 

 

개인적으로 AWS의 장점이자 단점이라고 생각하는게 하나부터 열까지 다 세팅해줘야한다는 점입니다. 위의 3티어 아키텍처에서 빠진게 네트워크 설정인데 네트워크 설정까지 직접 개발자가 다 관리해줘야합니다. 

 

3티어 아키텍처만 해도 사용하는 서비스가

 

• Route53
• Web Application Firewall (WAF)
• CloudFront
• Application Load Balancer (ALB)
• AWS Certificate Manager (ACM)
• Auto Scaling Group (ASG)
• Elastic Cloud Compute (EC2)
• CloudWatch
• Relational Database (RDS) or DynamoDB
• Key Management Service (KMS)
• Secret Manager

우와... 나열하고 보니 엄청 많네요... 여기에 네트워크인 VPC까지 설정해주면 정말 인프라 개발자 죽는 소리가 여기까지 들립니다...

 

굵직굵직한 서비스만 이정도지 EC2의 Security Group (SG) 라던가, ALB의 Target Group (TG), Listener 등등을 더 추가하면 더 많은 것들을 직접 설정해줘야합니다. 

 

그거까지 나열하면 정말 엄청나게 많네요. 

 

마지막으로 이 세개의 계층을 하나로 보여주는 AWS 아키텍처 그림을 마지막으로 저는 다음 포스팅으로 찾아뵙도록 하겠습니다. 긴 글 읽어주셔서 정말 감사합니다.