Stateless Web App: WhatIsTheTime.com Stateless web app: What time is it?
무상태형 타입의 웹 애플리케이션으로 단지 시간만 입력하며, 질문에 답하기 위해 어떤 데이터베이스나 외부 정보도 필요 없음
사람들에게 시간을 알게 해 줌
매우 간단하기 때문에 데이터베이스가 필요 없음
각 인스턴스와 서버는 현재 시간을 알며 작게 시작하길 원하므로 다운타임을 받아 들였지만, 앱이 조금씩 더 인기를 얻게 되어 전세계의 시간을 알기를 원해 수직, 수평으로 조정이 필요하며 다운타임을 제거시켜야 할 때의 솔루션 아키텍트
Starting simple
하나의 유저가 몇 시인지 물어보면 5:30pm이라고 답을 하는 앱
우리는 퍼블릭 EC2 인스턴스를 가지고 있고, 어떤 일이 발생하여 다시 시작해야 할 경우를 대비하여 EC2 인스턴스에 고정 IP 주소를 갖도록 만들고 싶기 때문에 여기에 탄력적 IP 주소를 연결하므로 유저들이 앱에 접근할 수 있음
Scaling vertically
또다른 유저가 들어와서 몇 시인지 물어보면 7:30pm이라고 답을 하며, 또다른 유저가 들어와서 몇 시인지 물어보면 6:30pm이라고 답을 함
이를 통해 앱에 점점 더 많은 트래픽이 생겨 t2.micro 인스턴스로는 충분하지 않다는 것을 깨닫게 됨 그리하여 t2.micro 인스턴스를 조금 더 큰 무언가(M5)로 대체해야 하므로 수직 확장이라고 불리며 인스턴스를 멈추고 인스턴스 유형을 바꾸고 다시 시작
탄력적 IP 주소를 갖고 있기 때문에 동일한 퍼블릭 IP를 가지므로 유저들은 여전히 앱에 접근할 수 있음
하지만 M5로 업그레이드하는 동안 다운타임을 경험하므로 유저들을 그 순간동안 앱에 접근할 수 없음
Scaling horizontally
앱 M5가 하나의 퍼블릭 IP가 있고 탄력적 IP가 연결되어 있을 때 수많은 유저가 몇 시인지 물어볼 때 수평 확장이 필요하므로 이를 위해 인스턴스 유형이 m5.large인 EC2 인스턴스를 추가하며 이들은 모두 연결된 탄력적 IP 주소를 가짐
하지만 점점 더 많은 유저들로 인해 더 많은 기반시설을 관리해야 하는 한계에 도달하게 될 경우 접근 방법 변경 필요
3개의 m5.large인 EC2 인스턴스가 있고 관리하지 못했으므로 이들의 탄력적 IP를 모두 제거한 후 Route 53을 활용 웹사이트의 URL은 api.whatisthetime.com이고 TTL을 한 시간으로 설정하며 A 레코드가 될 것으로 Route 53을 설정
유저들은 Route 53에 쿼리를 해서 물어보게 되면, A 레코드는 DNS에서 EC2 인스턴스의 IP 주소 리스트를 전해주게 됨 탄력적 IP 주소가 없어 IP 주소는 계속 바뀌지만 Route 53이 계속 업데이트하고 동기화 상태를 유지하므로 문제 발생하지 않음
Scaling horizontally, adding and removing instances
인스턴스를 즉석으로 추가하여 확장하고 제거할 수 있기를 원해 인스턴스 하나를 제거한 경우
유저들은 Route 53에 쿼리를 해서 물어보게 되면 TTL을 한 시간으로 설정하였으므로 한 시간동안 똑같은 응답을 받게 되며 한 시간동안 유저들은 인스턴스에 연결을 시도하지만 인스턴스는 사라졌으므로 한 시간 후에나 다른 인스턴스에 연결 가능 그러므로 유저들은 한 시간 동안 앱이 다운되었다고 생각할 것임
Scaling horizontally, with a load balancer
프라이빗 EC2 인스턴스를 갖고 있으므로 공개된 인스턴스가 없을 때 이들은 똑같은 AZ영역에서 시작 로드 밸런서를 사용하여 먼저 상태 확인을 하며 한 인스턴스가 다운되거나 작동하지 않는 경우 그곳으로 트래픽을 보내지 않음 프라이빗 EC2 인스턴스는 ELB 뒤에 있어 공개되지 않지만, ELB는 유저들에게 공개가 되며 보안 그룹 규칙을 사용해 트래픽 규제
유저들이 쿼리를 할 경우, 로드 밸런서는 항상 IP가 변경되기 때문에 A 레코드 대신 Alias 레코드를 사용 Alias 레코드는 Route 53에서 ELB까지 가리키므로 이를 이용해 DNS를 변경
변경 이후 유저들이 쿼리를 할 경우, 유저들은 로드 밸런스에 연결되고 로브 밸런서를 유저들을 EC2 인스턴스로 보내게 되며 이를 통해 트래픽의 균형을 유지할 수 있음
또한 로드 밸런서가 정렬하고 상태 확인이 있으므로 인스턴스를 더하거나 제거에 있어 다운타임이 발생하지 않음
Scaling horizontally, with an auto-scaling group
위와 동일하지만 이번에는 자동 확장 그룹이 EC2 인스턴스들을 관리하며 필요에 따라 확장할 수 있게 함
아침에는 아무도 시간을 알고 싶지 않아하고, 퇴근 시간에만 시간을 알고 싶은 경우 등을 위해 수요에 따라 확장하거나 축소 가능 (아침 시간 : M5 1개 → 퇴근 시간 : M5 3개)
이 과정에서 로드 밸런서 기능과 자동 확장 기능이 존재하므로 다운타임이 발생하지 않음
Making our app multi-AZ
만약 지진 등으로 인해 장애가 발생할 앱이 완전히 다운되는 것을 막기 위해 매우 가용성이 높은 Multi AZ 앱을 실행
이는 ELB를 가져 상태 확인을 하며, 상태 확인 또한 Multi AZ가 될 것이며 AZ 1에서 3까지 확인하며 자동 확장의 경우에도 Multi AZ에 걸쳐짐
아래의 경우 만약 AZ 1이 다운된다면 AZ 2와 3을 가지고 유저들을 위한 트래픽을 제공하므로 매우 고기능이고 실패에 강함
Minimum 2 AZ => Let’s reserve capacity
두 개의 AZ가 있을 때 적어도 하나의 인스턴스가 각 AZ에서 작동한다는 것을 알면 용량을 예약하자 우리는 두 개의 인스턴스가 1년 동안 항상 작동해야하는 것을 확실히 아므로 앱 비용을 절감하기 위해 용량 예약을 실행 또한, 자동 확장 그룹의 최소한의 용량을 위해 인스턴스를 따로 보관하면 미래에 많은 비용을 절약할 수 있음
이 후에 만약 새로운 인스턴스가 시작되면 일시적일 수도 있으므로 온디맨드 방식으로 실시하거나 스팟 인스턴스를 사용
In this lecture we’ve discussed…
EC2 인스턴스의 경우 퍼블릭 IP를 갖는 것과 프라이빗 IP를 갖는 것 비교
탄력적 IP 갖는 Route 53의 이점과 Route 53을 사용할 땨와 로드 밸런서를 사용할 때 비교
Route 53 TTL, A 레코드 및 Alias 레코드 비교
EC2 인스턴스 수동 유지 관리와 자동 확장 그룹을 통한 자동 관리 비교
재난에서 살아남기 위한 다중 AZ
ELB 상태 확인
EC2 인스턴스가 오직 ELB에서 들어오는 트래픽만 수신하도록 보안 그룹 규칙 설정
가능한 경우 비용 절감을 위한 용량 예약
잘 설계된 애플리케이션을 위해 비용, 성능, 안정성, 보안, 운영 우수성 5가지를 고려 예) 비용 : 수직적 확장을 사용하거나, 비용 최적화를 위해 ASG를 사용해서 로드에 따라 적정량의 인스턴스를 가지게 함 성능 : 수직적 확장, ELB, 자동 확장 그룹 안정성 : 안정적으로 트래픽을 전달하기 위해서 ELB를 위해 Multi AZ를 사용하고, ASG를 위해서도 Multi AZ를 사용 보안 : 보안그룹을 사용해 인스턴스에 안정적으로 로드 밸런서를 연결하는 방법 운영 : 투박한 수동 절차에서 완전히 자동화하는 방법인 자동 확장 그룹 사용
