[AWS] Solutions Architectures(솔루션 아키텍처) 첫 번째

Stateless Web App : WhatIsTheTime.com

• WhatIsTheTime.com은 사람들에게 시간을 알려준다.
• 너무 단순하기 때문에 데이터베이스가 필요 없다.
• 각각의 인스턴스와 서버는 시간이 몇시인지 알고 있고, 사용자들은 작게 시작하기를 원하고 다운타임을 받아들일 수 있다.
    - 다운타임 : 시스템을 이용할 수 없는 시간
• 다운 타임을 제거할 수 있도록 수직 및 수평적으로 확장할 필요가 있다.
    : 다운타임을 수용할 수 있지만 만약, 사용자의 앱이 전반적으로 점점 더 인기를 얻게 되어서 전 세계에 걸쳐 시간을 알고 싶어하게된다.

 

Stateless Web App : What time is it?

Scaling vertically

(출처 : 구글이미지)

• t2.micro 인스턴스와 사용자가 있고, 사용자가 시간을 물어보게되면 오후 5시 30분이라고 답한다.
• 해당 EC2는 고정 IP주소를 가지고 있다.
   - 무슨 일이 생기면 재시작해도 IP가 변하지 않는 장점이 있다.
   - 탄력적 IP주소를 연결시킨다.
• 위의 이미지가 첫 번째 PoC이다.

(출처 : 구글이미지)

• 첫번째 이미지랑 이어지는 예시입니다.
• 애플리케이션을 사용하는 사용자들이 많아졌다.(= 트래픽이 증가)
• 한 친구가 와서 시간을 물어보게되면, 오후 7시 30분이라고 답한다.
  다른 친구가 와서 시간을 물어보게되면, 오후 6시 30분이라고 답한다.
   - 우리는 애플리케이션이 점점 더 많은 트래픽을 갖게 되면서 t2.micro 인스턴스로는 충분하지 않다는 것을 깨닫게 된다.
• 인스턴스를 중지시키고 인스턴스 유형을 바꾸고 그 후에 다시 인스턴스를 시작하게 된다.
    - T2에서 M5로!
      (t2.micro → m5.large)
    - M5 유형 인스턴스는 탄력적 IP를 가지고 있기 때문에 동일한 공용 IP를 가지게 된다.
    - M5로 업그레이드 하는 동안 다운타임이 발생해버리고, 사용자들은 이를 좋아하진 않는다.
• 이제 또 다음 예시로 넘어가 보자.

Scaling horizontally

(출처 : 구글이미지)

• 위의 M5 애플리케이션은 하나의 공용 IP를 가지고 있고, 탄력적 IP가 연결되어 있다는 것을 기억해보자.
• 이제 정말 많은 사용자들이 와서 모두들 시간을 물어본다. 그래서 이제는 수평 확정을 하려고 한다.
• 먼저 EC2 인스턴스들을 추가한다.
  모두 m5.large이다.
  이것들은 모두 탄력적 IP가 연결되어 있다. 즉, 세 개의 EC2 인스턴스가 있고 세 개의 탄력적 IP가 있다.
• 우리 사용자들이 인스턴스들과 통신하려면 이 세 개의 탄력적 IP의 정확한 값을 알고 있어야 한다.
• 사용자들이 점점 더 많은 IP를 알아야하고 더 많은 인프라를 관리해야한다.
• 또 다음 예시로 넘어가 보자.

(출처 : 구글이미지)

• 위의 이미지처럼 M5 유형의 EC2 인스턴스가 세 개가 있다.
  관리하기에 너무 어려우니깐 탄력적 IP를 제거한다. 
• 한 계정에서 리전마다 겨우 다섯 개의 탄력적 IP만을 가질 수 있다.
  그 대신 우리 사용자들은 Route 53을 활용하게 된다.
• 웹사이트 URL은 api.whatisthetime.com이다.
  TTL이 1시간인 A 레코드로 정했다.
  위에와 같이 DNS로부터 IP 리스트를 받는다는 의미이다.
  (Route 53의 A레코드는 IP라는 것을 기억하자)
• EC2 인스턴스들의 IP 주소들을 얻게 되고 이는 시간에 따라 변하고 Route 53이 업데이트 될 것이니 전혀 문제가 되지 않는다. 업데이트를 하고 동기화를 유지할 것이다.
• 사용자들은 EC2 인스턴스에 접근할 수 있고, 관리할 탄력적 IP도 더이상 존재하지 않는다.
  즉, Route 53을 사용하여 상당한 개선을 이루었다.
• 또 다음 예시로 넘어가 보자.

Scaling horizontally, adding and removing instances

(출처 : 구글이미지)

• 그러나, 이번에는 상황에 따라 즉시 인스턴스를 추가하고 제거할 수 있도록 확장하고 싶어졌다. 인스턴스를 제거하면 어떻게 될까?
• 가장 위쪽 사용자들이 이 m5.large 인스턴스와 통신 중이었는데 그것이 없어졌다고 생각해보자.
  그리고 TTL이 1시간이었기 때문에 Route 53 쿼리를 시도하면 동일한 응답을 한 시간 동안 사용하게 된다.
  따라서 사용자들이 한 시간동안 그 인스턴스에 접속하려 하겠지만, 그 인스턴스는 더 이상 존재하지 않게된다.
• 여기까지의 예시들 모두 아키텍처이고 그 한계도 명확하다.
• 로드 밸러서를 추가하여 위의 상황들을 해결해보자(다음 예시로 넘어가자)

Scaling horizontally, with a load balancer

(출처 : 구글이미지)

• 로드 밸런서 추가에 대해 알아보자.
• 이제 공용 인스턴스는 더이상 없다. 대신 사설 EC2 인스턴스들이 있다.
  이들을 같은 가용 영역에서 실행할 것이다.
• 수동으로 실행해보면 세 개의 m5.large 인스턴스가 있다. 
• 로드 밸런서의 상태 확인 기능
    - 한 인스턴스가 다운되거나 작동하지 않으면 사용자로부터 해당 인스턴스로 트래픽을 전송하지 않는다.
• ELB와 private EC2 인스턴스 둘을 연결하면 ELB는 공개되겠지만 사설 EC2 인스턴스들은 뒤에 숨어있게 된다.
  보안 그룹 규칙을 사용하여 이 둘 사이의 트래픽을 제한한다.
• 이제 WhatIsTheTime.com에 대해 사용자들이 쿼리하지만 로드 밸런서가 IP 주소를 지속적으로 바꾸기 때문에 이번에는 A 레코드가 될 수 없다.
  대신, 로드 밸러서이기 때문에 별칭 레코드를 사용할 수 있다.
  (Route 53으로부터 ELB를 가리킬 것이고, 모든 것이 매우 잘 작동할 것이다.)
• 여기서 DNS를 바꾸지만 사용자들은 이제 로드밸런서에 접속한다. 그리고 로드 밸런서는 EC2 인스턴스로 리디렉션하고 트래픽의 균형을 잡는다. 이제 로드 밸런서로 이 인스턴스들을 추가 및 제고하고 정렬할 수 있기 때문에 좋다. 또한 상태 확인 기능 덕분에 사용자들에게 다운타임도 없을 것이다.

Scaling horizontally, with an auto-scaling group

(출처 : 구글이미지)

• 이제 왼쪽에는 API, 즉 Route 53 ELB가 있고 오른쪽에는 가용 영역이 있다.
  그리고 사설 EC2 인스턴스를 실행할 것이다. 그러나 이번에는 오토 스케일링 그룹이 이들을 관리한다.
  즉, 기본적으로 오토 스케일링 그룹이 요청에 따라 확장하도록 하는 것이다.
• 요청에 따른 확장이 가능하다. (확장과 축소 모두)
• 애플리케이션에 다운타임은 없고 오토스케일링과 로드 밸런싱이 있어, 정말 안정적인 아키텍처입니다.
  그러나 지진이 발생하게 되면,
    - 가용 영역 1번이 다운된다. 그러면 어떻게 될까??
        : 애플리케이션도 완전히 다운되어버린다.

Making our app multi-AZ

(출처 : 구글이미지)

• 이번에는 ELB가 필요하다. 상태 확인 뿐만 아니라 다중 AZ도 추가된다. 
• AZ 1부터 3에서 실행될 것이며, 이 ELB는 세 개의 AZ가 있다.
  오토 스케일링 그룹 역시 다중 AZ에 걸쳐 있게 된다.
• 예를 들어, AZ 1에 두 개의 인스턴스가 있고 AZ 2에 두 개의 인스턴스가 있고 AZ 3에는 하나가 있다고 해보자.
• 이 경우 AZ 1이 다운되더라도 AZ 2와 AZ 3이 있기 때문에 사용자를 위한 트래픽을 처리할 수 있다는 장점이 있다.
• 앱을 다중 AZ로 만들었고 높은 가용성을 확보했으며 장애 발생에도 대비가 됐다.

Minimum 2 AZ = > Let's reserve capacity

(출처 : 구글이미지)

• 2개의 AZ가 있다. 그리고 각각의 AZ에는 최소 하나 이상의 인스턴스가 실행 중이다.
  그러면 용량을 예약하면 어떻게 될까?
• 기본적으로 애플리케이션의 비용을 줄이는 작업을 시작하는 것이다.
  1년 내내 두 개의 인스턴스가 항상 실행 중일 것이기 때문이다.
• 오토 스케일링 그룹의 용량을 최소화하기 위해 인스턴스를 예약함으로써 미래에 상당한 비용을 절감할 수 있을 것이다.
• 새로운 인스턴스가 실행되더라도 일시적일 것이고 요청에 따른 것은 괜찮다.
  좀 더 극단적으로는 비용 절감을 위해 스팟 인스턴스를 사용할 수도 있지만 이는 인스턴스들을 종료시키게 될 수도 있다.