https://www.youtube.com/watch?v=8uesJLEXxyk&t=246s

독립적인 서버클러스터에 있는 AZ

• 서버 클러스터란 각기 다른 서버(Server Enterprise or Server Datacenter)들을 하나로 묶어서 하나의 시스템같이 동작하게 함으로써, 클라이언트들에게 고가용성의 서비스를 제공하는 것을 말한다.

• 클러스터로 묶인 한 시스템에 장애가 발생하면, 정보의 제공 포인트(End Point)는 클러스터로 묶인 다른 정상적인 서버로 이동한다. 서버클러스터는 사용자로 하여금 서버 기반 정보를 지속적이고, 끊기지 않게 제공받을수 있게 한다.

컨텐츠 배포네트워크 Edge Location

Edge Location이란 AWS가 CDN을 제공하기 위해서 만든 서비스인 CloudFront의 캐시 서버라고 생각하면 된다.

사용자가 들어오면 기본적으로 우리의 서버들이 AZ라는것을 통해서 나뉘어진다

이 AZ는 독립적인 데이터센타 또는 서버클러스터를 구성하고있기때문에 고 가용성을 확보할수있다.

논리적으로는 하나의 네트워크처럼 보이지만 실제로는 분산되어있는 서버 자원을 통해 고 가용성을 확보할수 있다.

Edge Location도 분산되어있기때문에 많은 유저들이 빠르게 컨텐츠 Access를 할수있다.

1. 언제나 원하는 만큼 사용할수 있다.

CPU가 32장 GPU가 4장 꼽혀있는 g2.8xlarge라는것이 있다.

스팟인스턴스를 이용하면 남아있는 여유자원 인스턴스에 비딩을이용해서 최대 90퍼샌트까지 낮은가격에 사용가능하다

EC2는 가상서버이다.

머신이미지(부트디스크) OS를 선택하는 화면

컴퓨팅 파워 선택

ssh 접속을 위한 pem키 발급

처음에 ec-2user라는 아이디로 만들어진다

우분투를 선택했다면 우분투로 아이디가 만들어짐

서버에 사용자가 늘어난다고 하면 서버의 CPU메모리를 늘려야할 필요성이 있다. 기존 데이터센터에서는 불가능하다. 서버를 끄고 새로운 메모리를 꺼내고 그걸 다시 꼽고 서버를 다시키고 이러한 과정을해야하기때문이다.

하지만 클라우드 환경에서는 그냥 인스턴스를 스탑만하고 CPU메모리를 인스턴스타입만 바꾸면 인스턴스의 CPU메모리가 증가한다.

문제는 인스턴스에 데이터베이스도 깔고 웹서버도 깔고 그외 모든것들을 서버에 다 저장을 해놓으면 서버가 죽으면 다 죽는거다.

** User > 10 **

해법 1

기능에 따라 인스턴스의 역할을 나눈다.

• 웹서버용 인스턴스
• DB용 인스턴스

DB서버를 운영하는 방법은 직접 DB서버를 운영을하던지 아마존 웹서비스에서 제공하는 관리 서비스를 선택하면된다.

직접 운영하게되면 업데이트도 해야하고 패치도해야하고 백업도해야되는데 Amazon RDS를 이용하면 기존의 Relational Database Engine을 그대로 이용할수가 있다.

Amazon DynamoDB를 이용하면 NoSQL기반의 Database를 이용할수 있다.

Amazone Redshift를 이용하면 DW(데이터웨어)서비스를 이용할수 있다.

이렇게되면 관리를 아마존에서 해주기때문에 우리는 DB의 엔드포인트만 쓰면된다.

Amazon Aurora

RDS vs NoSQL

데이터가 갑자기 늘어나거나 유저가 좀 헤비하다면 NoSQL을 고려할만하다

Amazon DynamoDB

아마존을 예로들면 Amazon DynamoDB는 아마존닷컴에서 장바구니와 같은 Write 업데이트가 굉장히 Heavy한 시스템을 구축하면서 만든 노하우를 가지고 만든 서비스이다. 또한 장점으로는 Read Capacity와 Write Capacity를 언제든 Dynamic하게 바꿀수있다. Read-heavy한 쿼리가 돌때는 Read Capacity가 높게 Write-heavy한 쿼리가돌때는 Write Capacity가 높게 스위칭가능

User > 100

유저가 100명쯤되면 내가 디비 운영하는게 좀 부담이되니까 나는 애플리케이션에 집중하고 인프라관리는 아마존에 맡겨보자

User > 1000

이럴때 해법은 서버를 두개로 나누고 Elastic Load Balancing을 하는것이다.

Elastic Load Balancing은 소프트웨어 기반의 Load Balancing Service이다.

그것을 통해서 두개 이상의 인스턴스에다가 로드 밸런싱을 할수있다.

로드밸런싱의 장점은 혼자 스케일링을 자동으로 한다는것이다.

그림을 자세히보면 노란색으로 두개가 나뉘어져있는데 하나는 서버가 A에 있고 하나는 서버가 B에 있다.

완전히 분리되어있는 두개의 독립된 데이터 센터에 두개의 서버가 따로 분산되어있고 로드밸런서가 그걸 조정한다.

천재지변에 의해서 하나의 서버가 날라가도 또 다른 하나의 서버를 사용함으로서 고가용성을 확보할수있다.

만명에서 십만명쯤 되면 그냥 위와같이 서버를 늘리면된다.

지금까지 했던건 기존의 데이터센터가 하던 작업을 조금더 쉽게한것뿐이지 크게 다르지않다

오토스케일링이라던지 클라우드에서 제공하는 더많은 이점을 누리기위해서는 성능과 가용성을 가지고있는 클라우드 아키텍쳐로 진화시킬필요성이 있다.

1.

첫번째로는 로드벨런서 뒤에있는 우리가 관리하고있는 인스턴스의 로드를 줄여야한다.

인스턴스에다가 우리의 애플리케이션만 있어야하는데 이 인스턴스에다가 웹서버도 깔고 디비도 깔고 파일서버로도 운영을하고 하면서 가볍지 않은것들이 많아진다.

우리는 이 인스턴스를 가볍게 만들 필요가있다 그래야 성능을 최대로 끌어내고, 손쉽게 확장도 가능하기 때문이다.

유저데이터, 업로드된 파일들, 볼륨에 들어있는 파일들을 S3라는 Storage Service에 옮겨야한다.

그래야 애플리케이션이 가벼워지니까 나중에 Auto Scaling도 쉽게 할수있다.

유저의 Data, 이미지파일들을 CloudFront라는 서비스를 이용해서 이미지파일들을 접근하게 하는게 첫번째 중요한 것이다.

두번째는 디비의 분산을 하기위해 캐시를 추가한다. (Memcached, Redis 활용)

방법 3

동적 컨텐츠에 대해서도 Amazon CloudFront 활용한다.

위 사진에서 왼쪽아래를 자세히 보면 CDN이 있냐 없냐에 따라서 Server의 Response시간이 줄어드는것을 볼수있다.

오토스케일링

기존의 회사는 피크타임을 기준으로 서버대수를 미리 마련을 해놓는다

파란색이 인스턴스인데 인스턴스의 숫자가 트래픽에따라 점진적으로 증가하는것을 볼수있다.

지금 그림이 밤에는 1대만 돌아가고 낮에는 최대 6대까지 돌아가는것이다.

이것이 오토 스케일링인데 유저의 네트워크 트래픽, CPU 사용률에 따라서 스케일링을 할수있도록 정책을 정하면되고

Minimum 몇대, Maximum 몇대, AZ를 어디에 설치할것인지, CPU가 몇퍼센트 이상올라가면 한대 더추가해라 라는 명령어이다.