aws WhatlsTheTime.com

AWS WhatlsTheTime.com

- 사람들에게 시간을 알려줍니다

- 너무 단순하기 때문에 데이터베이스가 필요 없습니다.

- 각각의 인스턴스와 서버는 시간이 몇 시인지 알고 있습니다. 작은 것부터 시작합니다.

- 다운타임을 수용할 수 있지만 우리 앱은 전반적으로 점점 더 인기를 얻게 됩니다. 

- 사람들은 전 세계에 걸쳐 시간을 알고 싶어하기 때문에 다운타임을 제거할 수 있도록 수직 및 수평적으로 확장할 필요가 있습니다.

 

 

t2.micro 인스턴스와 사용자가 있습니다. 사용자가 시간을 물어봅니다. 오후 5시 30분이라고 답합니다. 이게 제 앱입니다.

공용 EC2 인스턴스가 있고 무슨 일이 생기면 재시작할 수 있도록 EC2 인스턴스가 고정 IP주소를 갖도록 하고 싶습니다. 그렇게에 탄력적 IP 주소를 연결할합니다. 이것이 첫 번째 PoC입니다. 

사용자들이 우리 애플리케이션에 접근할 수 있고 반응도 매우 좋습니다. 다음으로 일어날 일은 이렇습니다. 사용자들이 우리 애플리케이션을 정말 잘 사용하다가 친구들에게도 이 애플리케이션을 사용하도록 추천합니다. 한 친구가 와서 시간을 물어봅니다, 오후 7시 30분입니다. 다른 친구가 와서 시간을 물어봅니다, 오후 6시 30분입니다. 여기서 우리는 애플리케이션이 점점 더 많은 트래픽을 갖게 되면서 t2.micro 인스턴스로는 충분하지 않다는 것을 깨닫게 됩니다. .우리는 솔류션스 아키텍트로서 부하를 처리하기 위해 t2.mirco 인스턴스를 조금 더 큰것으로 교체해야겠다고 생각합니다. 이를 수직 확장이라고 합니다, 따라 m5.large 유형의 인스턴스로 교체하려고 합니다. 인스턴스를 중지시키고 인스턴스 유형을 바꾼닙다

 

 

이것은 M5 유형 인스턴스입니다. 이는 탄력적 IP를 가지고 있기 때문에 동일한 공용 IP를 가지게 되고 사람들은 여전히 애플리케이션에 접근할 수 있습니다. 그러나 M5로 업그레이드 하는 동안 다운타임이 발생했고 사용자들은 이를 그리 좋아하지 않았습니다. 그동안에 애플리케이션에 접근이 불가능하기떄문입니다. 해결은 했지만 그렇게 좋지는 않습니다.

 

 

이제는 수평 확장을 해야 할 때입니다. 이 M5 애플리케이션은 하나의 공용 IP를 가지고 있고 탄력적 IP가 연결되어 있다는 것을 기억하세요 이제 정말 많은 사용자들이 와서 모두들 시간을 물어봅니다  그래서 이제는 수평 확장을 하려고 합니다. 먼저 EC2 인스턴스들을 추가합니다. 모두 m5.large입니다. 이것들 모두 탄력적 IP가 연결되어 있습니다. 즉 세 개의 EC2 인스턴스가 있고 세 개의 탄력적 IP가 있습니다. 따라서 우리 사용자들이 인스턴스들과 통신하려면 이 세 개의 탄력전 IP의 정확한 값을 일고 있어야합니다. 이것이 수평 확장입니다. 이제 한계가 느껴지기 시작합니다. 사용자들은 점점 더 많은 IP를 알아여 하고 우리는 더 많은 인프라를 관리해야 합니다. 꽤 어려운 일입니다.

 

 

접근 방식을 바꿔봅니다. M5 유형의 EC2 인스턴스 세 개가 있습니다. 탄력적 IP를 제거합니다. 관리하기 너무 어려우니까요 한 계정에서 리전마다 겨우 다섯 개의 탄력적 IP만을 가질수 있습니다. 그 대신 우리 사용자들은 Route 53를 활용하게 됩겁니다. 이를 위해 Route 53를 설정했고 웹사이트 URL은 api.whatisthetime.com입니다. TTL이 한 시간인 A 레코드로 정했습니다. A 레코드로 정했다는 건 이와 같이 DNS로부터 IP 리스트를 받는다는 의미입니다. Route 53의 A 레코드는 IP라는 걸 기억합니다. 사용자들이 Route 53을 쿼리합니다 .그러면 EC2 인스턴스들의 IP 주소들을 얻게 되고 이는 시간에 따라 변하고 Route 53이 업데이트될 것이니 전혀 문제가 되지 않습니다. 업데이트를 하고 동기화를 유지할 겁니다. 이제 사용자들은 EC2 인스턴스에 접근할 수 있고 관리할 탄력적 IP도 더 이상 존재하지 않습니다. 즉 Route 53을 사용하여 상당한 개선을 이루었습니다. 그러나 이번에는 상황에 따라 즉시 인스턴스를 추가하고 제거하면 어떨까요?

 

 

가장 위쪽 사용자들이 이 m5.large 인스턴스의 통신 중이었는데 이제 그것이 없어졌습니다. 그리고 TTL이 한 시간이었기 때문에 Route 53 쿼리를 시도하면 동일한 응답을 한 시간 동안 사용하게 됩니다. 따라서 사용자들이 한 시간 동안 그 인스턴스에 접속하여 하겠지만 그 인스턴스는 더 이상 존재하지 않습니다. 이건 바람직하지 않습니다. 사용자들이 아마 한 시간 후에는 이 두 인스턴스에는 접속할 수 있어 다시 즐길 수 있겠지만 지금 당장은 만족할 수 없기 때문입니다. 이것은 아키텍처이고 그 한계도 명확합니다.

 

 

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

 

오토 스케일링을 추가했습니다.  이제 요청에 따른 확장이 가능합니다. 확장과 축고 모두 가능합니다. 애플리케이션에 다운타임은 없고 오토 스케일링과 로드 밸런싱이 있으니 가능합니다. 이번에는 지진이 발생합니다. 가용 영역 1번이 다운됩니다. 그러면 어떻게 될까요? 우리 애플리케이션도 완전히 다운됩니다. 

 

 

다중 AZ도 추가합니다. AZ 1부터 3에서 실행될 것이며 이 ELB는 세 개의 AZ가 있습니다. AZ 1에 두 개의 인스턴스가 있고 AZ 2에 두 개의 인스턴스가 있고 AZ 3에는 하나가 있기 때문에 사용자를 위한 트래픽을 처리할 수 있다는 장점이 있습니다. 이제 앱을 다중 AZ로 만들었고 높은 가용성을 확보했으며 장애 발생에도 대비가 됐습니다. 

 

 

두 개의 AZ가 있습니다. 그리고 각각의 AZ에는 최소 하나 이상의 인스턴스가 샐행 중입니다. 그러면 용량을 예약하면 어떨까요?  기본적으로 애플리케이션의 비용을 줄이는 작업을 시작하는 것입니다. 1년 내내 두 개의 인스턴스가 항상 실행 중일 것이기 떄문입니다. 즉 오토 스케일링 그룹의 용량을 최소하기 위해 인스턴스를 예약함으로써 미래에 상당한 비용을 절감할 수 있을겁니다. 새로운 인스턴스가 실행되더라도 일시적일 것이고 요청에 따른 것은 괜찮습니다. 좀 더 적극적으로는 비용 절감을 위해 스팟 인스턴스를 사용할 수도 있습니다. 그러나 이는 인스턴스들을 종료 시키게 될 수도 있습니다. 아키텍처가 아주 작은 애플리케이션에서 시작하여 로드 밸런싱, 오토 스케일링 그룹 다중 AZ, 상태 확인 예약 인스턴스 까지 진행되됩니다.