[AWS] Classic Solution Architecture

클래식 솔루션 아키텍쳐 토론

지금까지는 개별 기술을 그 기술 관점에서 살펴보았다.
이제는 솔루션 아키텍쳐 관점에서 기술들을 살펴보도록 하자.

WhatsTheTime.com

• 사람에게 시간을 알려주는 앱이다.
• 단순하기 때문에 DB는 필요없다.
• 시작할 때는 작아서 다운타임은 허용 가능하지만 점차 다운타임을 없애기 위해 수직, 수평적으로 확장할 필요가 있다.

1. 공용 EC2 instance가 있고, Elastic IP로 고정 IP를 가지고 싶다, 왜냐면 필요하면 종료하고 다시켜야 하기 때문이다.
2. 유저가 친구에게도 추천한다. 그렇게 유저가 늘어나면서 앱에 점점 트래픽이 증가한다. 부하를 처리하기 위해서는 인스턴스를 좀 더 큰걸로 확장해야 겠다고 한다. 수직 확장이다. 인스턴스 중지 후 인스턴스 교체 및 재 시작한다.
   탄력적 IP 덕분에 고정 IP라 유저는 그대로 접속 가능하나 다운타임이 있어서 유저 불만이 있다.
3. 이제 수평 확장을 해야할 시간이다. 여전히 고정 IP이다. 인스턴스를 추가하고 전부 고정 IP이다. 즉 유저가 우리와 통신하려면 이 고정 IP를 각각 정확히 알아야 한다. 하지만 증가할 때마다 유저는 IP를 알아야만 한다.
4. 탄력적 IP는 더 이상 관리하기 힘드며, 한 리전당 5개가 한계이기 때문에 없애기로 한다. Route 53을 대신 활용하기로 한다. 이 때 URL을 정하고 TTL이 1시간이 A 레코드를 지정했다. 유저들이 Route53을 쿼리하면 IP를 얻게 되고 사용자들은 인스턴스에 적절하게 접근이 가능하다.
5. 만약에 인스턴스를 제거하면 어떻게 될까? 특정 유저가 통신 중이었는데 인스턴스가 사라지면 TTL 1시간동안 접속을 할 수 없습니다.
6. 이런 경우에는 어떻게 해결할까요? 로드 밸런서를 생각해보자. 이제 퍼블릭 인스턴스는 없고, 동일 가용영역에 프라이빗 인스턴스가 있다고 생각해보자. ELB와 health check를 인스턴스와 연결한다. 이 연결은 보안 그룹 규칙으로 연결하여 트래픽을 제한한다. 이제 유저가 Route 53으로 쿼리를 보내지만 ELB가 주소를 계속 바꾸기 때문에 A 레코드로는 연결할 수 없다. 대신에 로드 밸런서기때문에 별칭 레코드를 사용하면 된다. 이제 로드벨런서는 트래픽을 조절하며 상태 확인을 하기 때문에 다운되는 경우는 거의 없다. 그런데 수동으로 인스턴스를 추가하고 제거하는건 불편하다.
7. ASG를 사용하면 이를 해결할 수 있다. ASG가 이제 프라이빗 인스턴스를 확장하거나 축소한다. 다운타임이 없고 요구에 따라 리소스를 증가하고 줄일 수 있다. 그런데 갑자기 지진이 발생해서 가용영역 1번이 망가진다면 어떨까
8. 가용성을 위해서는 다중 리전을 적용해야 한다. ELB에 상태 확인 뿐 아니라 다중 AZ기능도 들어간다. 이 ELB에는 세개의 AZ가 존재학도 ASC는 이 3개에 걸쳐 있다. 이제 AZ1이 다운되도 다른 곳에서 트래픽을 처리할 수 있다.
9. 만약에 우리가 2개의 AZ에 최소 하나 이상의 인스턴스가 실행 중이라고 생각해보자. 용량을 예약하면 어떻까? 1년 내내 인스턴스가 실행될거라면 예약을 하면 비용을 절감할 수 있다. 물론 스팟 인스턴스를 사용하면 비용을 극단적으로 줄일 수도 있지만 이 경우 인스턴스가 갑자기 종료될 수도 있으니 좋은 방법은 아니다.

MyClothes.com

이번에는 상태 유지 웹 앱이다.
사람들이 온라인으로 옷을 보고 장바구니에 담을 수 있고, 수백명이 사용합니다.
확장 할 수 있어야 하고, 수평적 확장이 가능해야 합니다.

사람들이 웹사이트를 둘러볼 때, 장바구니를 잃어버리지 말아야 하고, 주소 같은 정보는 디비에 담겨야 한다.

1. 기본적으로 이전 시스템과 유사한데, 기본적으로 Route 53이 있고, 3개의 AZ를 사용하며 ASG가 동작합니다. ELB가 트래픽을 조절한다. 만약에 사용자가 인스턴스1에 접근했다가 인스턴스2로 접근하게 되면 장바구니 정보가 사라집니다. 따라서 사용자는 버그가 있다고 생각할 수 있다. 매번 다시 접속하면 장바구니가 사라집니다.
2. 세션 밀접성 즉, Session Affinity, ELB Stickness를 활성화한다. 사용자가 첫 번째 인스턴스에서 다른 인스턴스로 가더라도 세션이 유지가 된다. 하지만 어떤 이유로 인스턴스가 종료되면 장바구니는 잃어버린다.
3. 사용자 쿠키를 살펴보자. 인스턴스가 사용자의 장바구니를 기억하는 대신에 사용자 쪽에서 장바구니 내용을 저장하도록 하는 것 이다. 로드 밸런서에 접속할 때마다 내 장바구니에 이게 있어라고 이야기하게 하는 것이다. 사용자가 직접 내용을 보내주는 것이다. 이렇게 되면 Stateless 상태를 유지할 수 있다. 하지만 HTTP requests가 점점 무거워진다. (왜냐면 거기에 정보를 실어서 보내야 하므로), 게다가 쿠키가 공격자에 의해 변조될 수도 있다. 따라서 인스턴스가 사용자 쿠키를 검증해야 한다. 그리고 쿠킨은 4KB 이하만 가능하기 때문에 대량의 정보를 저장할 수는 없다.
4. 서버 세션 개념을 도입해보자. 전체 장바구니 정보를 웹쿠키로 보내는 것이 아니라 단순히 세션 ID만 보내게 하는 것이다. 사용자에 대한 세션ID이다. 그리고 백그라운드에는 ElasiCache가 존재한다. 예를 들어 사용자가 인스턴스에게 특정 상품을 장바구니에 추가할거야 라고 하면 인스턴스는 해당 물건 정보를 ElasiCache에 전달하고 ElastiCaches는 장바구니 내용을 불러올 수 있는 세션 ID를 반환한다. 사용자가 세션 ID와 두번째 물건을 전달하면 다른 인스턴스에서도 해당 장바구니 정보를 볼 수 있다는 점이다. 그리고 성능은 1000 분의 1초 이하의 성능을 가진다. 매우 빠르다.
5. 우리는 사용자 정보를 디비에 저장하고 싶다. RDS는 장기적인 저장을 위해 좋다. 각각 인스턴스가 RDS와 직접 통신할 수 있으며, 일종의 다중 AZ 무상태 솔루션을 효과적으로 얻을 수 있다.
6. 우리는 사용자가 우리 웹사이트를 둘러보는데 쓰는 시간이 많다는걸 파악한다. 따라서 RDS를 읽기 전용 복제본을 만들어 읽기를 확장하게 한다. 최대 5개까지 생성이 가능하다.
7. ElastiCache에 정보를 캐싱할 수도 있다. 먼저 이런 정보가 있는지 물어보고 없다면 해당 정보를 RDS에 읽어서 캐싱해놓고 다시 사용한다. 따라서 즉시응답을 받을 수 있고 RDS 트레픽을 줄일 수 있다.
8. 재해에 대비해야 하는데, ELB를 멀티 AZ이고, instance도 멀티 AZ이며, RDS도 멀티 AZ를 가지고 있다. 게다가 재해 대비용 복제본도 있다. ElastiCahce의 경우 Redis를 사용하면 멀티 AZ 기능을 사용할 수 있다.
9. 보안과 관련해서는 ELB는 EC2로 가는 트래픽을 제한하고, ElasiCache는 EC2 보안그룹으로 부터 오는 트래픽을 제한한다. RDS도 EC2 보안그룹에서 오

MyWordPress.com

상태 유지 앱이다.
완전히 확장 가능한 워드프레스 사이트이다.

1. RDS가 있는 계층을 설계한다. 다중 AZ이다. 만약에 RDS 부분을 Aurora MySQL로 변경하면 다중 AZ, 읽기 복제본 원하면 글로벌 데이터베이스까지 적용이 가능하다. 오로라를 사용하므로써 연산을 줄일 수 있다.
2. 이미지 저장에 대해 다뤄보자. 한 인스턴스가 있고 하나의 EBS 볼륨이 있다고 해보자. ELB가 연결되어 있다 사용자는 ELB를 통해 이미지를 보내고 싶다. 이 이미지는 EBS에 저장된다. 인스턴스가 1개라면 잘 동작한다.
3. 인스턴스가 두 개 이상이면, 이미지를 보냈을 때 하나의 인스턴스 EBS에 저장될 것이다. 하지만 흔한 오류로는 만약에 사용자가 다른 인스턴스에 접근할 경우, 이미지를 볼 수 없다는 것이다.
4. 이를 해결하기 위해서는 EFS를 사용한다. EFS는 NFS(Network File System)의 일종으로 각 AZ에 ENI(Elastic Network Interface)를 생성한다. 이 ENI는 EFS에 접근하는 모든 인스턴스에서 사용 가능하며 EFS에 파일은 모든 인스턴스에서 공유가 가능하다.

애플리케이션을 빠르게 인스턴스화 하기

우리가 풀스텍으로 실행하려면 (EC2, EBS, RDS)

1. 앱 설치
2. initial data 삽입
3. 모든 설정 완료하기
4. 앱 실행

-> 시간이 많이 소요된다.

EC2 instance :
Use a Gloden AMI : Install your applications, OS dependencies etc.. beforehand and launch your EC2 instance from the Gloden AMI

Bootstrap using User Date : For dynamic configuration, user User Data Scripts

Hybrid : mix AMI and User Data(Elastic Beanstalk)

RDS DB : Restore from a snapshot

EBS Volumn : Restore from a snapshot

Beanstalk

개발자 입장에서 매번 인프라를 구축하고 코드를 배포하고, 디비나 로드밸런서를 설정하고 스켘일링을 고민하는 것은 낭비이다.

Beanstalk은 개발자 입장에서 앱을 AWS에 배포한다.
하나의 인터페이스에서 앞에서 본 EC2, ASG, ELB, RDS 등의 모든 컴포넌트를 재사용한다는 개념이다.
서비스를 관리해준다.

• 자동으로 캐패시티 프로비저닝, 로드밸런싱, 스케일링 등을 처리해준다.
• 개발자는 코드만 신경써도 되지만, 그래도 전체적인 제어권은 가지고 있는데 Beamstalk에서 하나의 인터페이스 번들로 이것을 제공해준다.

BeanStalk 자체는 무료지만, 설정하는 서비스는 유료이다.

Elastic BeanStalk Components

• Application : collection of Elastic Beanstalk components (environments, versions, configurations,...)
• Application Version : an iteration of your application code
• Environmnet :
  • Collection of AWS resources running an application version (only one application version at a time)
  • Tiers : Web Server Environment Tier & Worker Environment Tier
  • You can create multiple environments (dev, test, prod,...)

Supported Platforms
: Go, Java SE, Java with Tomcat, .Net core on Linux, ...

Web Server Tier : 보통 ELB가 있고, 해당 트래픽을 ASG에 전송하고 EC2 인스턴스가 다수있는 전통적인 아키텍쳐

Worker Tier : 여기에는 EC2 인스턴스에 직접 엑세스하는 클라이언트가 없다. 메세지 대기열인 SQS Queue를 사용하고 메시지가 전송되면 EC2는 워커가 된다. 메시지를 받아서 업무를 처리하는 것이다. 여기서 메시지에 따라 스케일링이 될 것이다. 웹 환경과 워커 환경은 SQS를 이용하여 하나로 구성하여 사용할 수도 있다.

Deployment Modes

1. Single Instance Great for Dev : 개발용으로 좋다. : 1개의 instance + Elastic IP + RDS master
2. High Avaliability with Load Balancer Great for Prod : 배포용으로 좋다.