Stateless Web App(WhatIsTheTime.com)
- 사람들에게 시간을 알려주는 기능
- 단순하기에 DB가 필요없다.
- 각각의 인스턴스와 서버는 시간이 몇 시인지 알고 있다.
- 작게 시작하고 싶고 가동 중지시간(downtime)을 받아들일 수 있다
- 이 앱은 전반적으로 점점 더 인기를 얻게 된다.
가동 중지 시간을 제거할 수 있도록 수직 및 수평적으로 확장할 필요가 있다.
솔루션 아키텍트 과정(WhatIsTheTime.com)
간단한 시작(첫 번째 PoC)
사용자가 시간을 물어보면 인스턴스는 시간을 알려준다.
- 공용 인스턴스
- 무슨 일이 생기면 재시작 가능하도록 고정 IP를 갖는다.
-> 탄력적 IP 주소 연결 - 시간이 지나면서 사용자가 점점 늘어나 많은 트래픽을 갖게 된다.
t2.micro인스턴스로는 충분하지 않음을 깨닫는다.
수직 스케일링 조정
- t2.micro를 좀 더 큰 인스턴스로 수직 확장
t2.micro -> m5.large 교체- 인스턴스 중지
- 인스턴스 유형 변경
- 인스턴스 시작
- 탄력적 IP를 갖고 있기 때문에 이전과 동일한 공용 IP를 갖고 있다.
- 그러나 M5로 업그레이드 하는 동안 다운타임 발생
수평 스케일링 조정
- 사용자들이 더 많아져 수평 스케일링 고려
- M5 인스턴스는 하나의 공용 IP에 탄력적 IP가 연결 되어있다.
- 3개의 m5.large 인스턴스로 수평 확장
모두 탄력적 IP가 연결되어 있다.
-> 3개의 인스턴스, 3개의 탄력적 IP
-> 사용자들은 인스턴스와 통신하려면 탄력적 IP의 정확한 값을 알아야 한다. - 그러나 사용자들이 점점 늘어남에 따라 알아야하는 IP와 인프라 관리가 힘들어진다.
접근 방식을 변경해 보자
- 한 계정의 리전마다 최대 5개의 탄력적 IP만 가질 수 있다.
탄력적 IP를 제거하고 Route 53사용을 선택 - 웹 사이트 URL은 api.whatisthetime.com으로 Route 53 설정.
TTL = 1h
A record -> DNS로 IP 리스트를 받는다.
-> 사용자가 쿼리를 하면 자동으로 인스턴스의 IP주소를 얻어 통신.(자동 업데이트 및 동기화)
상황에 따라 인스턴스 확장/제거 가능하게 해보자
- 만약 그냥 인스턴스 하나를 종료한다면?
TTL이 1시간으로 설정되어 있기 때문에 종료한 인스턴스 사용자들은 1시간동안 사용할 수 없다.
한 시간 후에야 다른 인스턴스로 접속해 서비스를 사용할 수 있게 된다.
그렇다면 로드 밸런서를 추가해보자
- 공용 인스턴스 대신 사설 인스턴스를 사용하고 하나의 가용 영역에서 실행
- 로드 밸런서의 상태 확인(Health Checks)기능으로 인스턴스의 상태를 확인하자.
인스턴스가 다운되면 해당 인스턴스로 트래픽을 전송하지 않게 한다.
-> ELB는 공개되겠지만 인스턴스들은 뒷단에 있다.
-> 보안 그룹 규칙으로 둘 사이의 트래픽을 제한 - 사용자들이 웹사이트에 쿼리하지만 로드 밸런서가 IP주소를 자속적으로 바꾼다.
A 레코드가 될 수 없다.
대신 Alias 레코드를 사용할 수 있다.(로드 벨런서이기 때문)
-> Alias는 Route 53으로부터 ELB를 가리켜 접속 가능. - DNS를 바꾸지만 사용자들은 로드 밸런서에 접속할 수 있다.
로드 밸런서는 인스턴스로 리디렉션 - 이제 로드 밸런서로 인스턴스를 추가/제거할 수 있다.
- 추가로 상태 확인으로 다운타임도 없앴다.
- 그러나 아직 수동으로 인스턴스를 추가하고 제거하기는 힘들다.
오토 스케일링 그룹
- 오토 스케일링 그룹을 통해 관리하도록 한다.
시간에 따라 트래픽이 많을때와 적을때에 따라 인스턴스를 확장/제거한다.
이번엔 자연재해에 대비해보자(다중 AZ)
- 지진으로 가용 영역 1번이 다운되면?
애플리케이션이 다운된다. - 이때를 대비해 다중 AZ로 가용성을 높이자
ELB로 상태 확인 뿐만 아니라 다중 AZ도 추가하자.
AZ 3개로 확장
오토 스케일링 그룹도 다중 AZ에 분배 - 이것으로 가용성을 확보함으로 장애 발생에 대비했다.
이제 애플리케이션 비용을 줄여보자(용량 예약)
- 2개의 AZ가 있고 각각의 AZ에는 최소 하나 이상의 인스턴스가 실행중이다.
- 오토 스케일링 그룹의 용량을 최소화하기 위해 인스턴스를 예약해 비용을 절감하자.
새 인스턴스가 실행되도 일시적이고 요청에따라 생성 되는것이라 괜찮다
더 줄이고 싶다? -> 스팟 인스턴스 사용 (주의: 인스턴스 종료될 수 있음)
생각해보기
- 공용IP와 사설IP를 갖는 목적
- 탄력적 IP와 Route 53 vs 로드 밸런서를 사용할때의 장점
- Route 53 TTL 때문에 A 레코드를 사용할 수 없어 로드 밸런서의 Alias를 사용했다.
- 인스턴스를 수동으로 관리하는 법 vs 오토 스케일링 그룹 사용
- 다중 AZ를 통해 재난 극복
- 정상적인 인스턴스만 트래픽을 받도록 ELB 상태 확인 활성화
- 인스턴스가 ELB의 트래픽만 받도록 보안 그룹 규칙을 설정
- 비용 절감을 위한 예약
AWS 프레임워크
AWS에는 좋은 아키텍처를 가진 프레임워크가 있다.
- 잘 설계된 애플리케이션을 위한 5가지 원칙
비용: 인스턴스 수직 확장, ASG, 인스턴스 예약
성능: 수직 확장, ELB, 오토 스케일링 그룹
신뢰성: 트래픽을 안정적으로 전달하는 Route 53, 다중 AZ
보안: 로드 밸런서, 보안 그룹
우수한 운영: 수동 프로세스에서 오토 스케일링 그룹의 기능을 갖춰 자동화되도록 개선
