region
- AWS의 모든 서비스(리소스)가 위치하고 있는 물리적인 장소
- 정확히 물리적인 장소는 아니고 조금은 추상적 개념
- 네트워크 기술이 아무리 발전했더라도, 물리적으로 먼 거리는 시간이 많이 걸릴 수 밖에 없음
- 경유하는 라우터의 개수가 많기 떄문
- 어떻게든 물리적인 거리를 좁히는게 최적의 방법임
- 리전을 바꾸고 테스트해보면 속도차이를 확실히 느낄 수 있음 https://dezang.github.io/aws-ping-latency-check/
- 전 세계 주요 지역에 위치하고 있음
- 서비스가 크다면 자연재해 등을 대비하여 여러 리전을 사용하는것을 권장함
- seoul 리전이 맛탱이 갔을때 쿠팡, 배민 등의 서비스가 모두 중지되었었다
- 영업 손실이 보통 수준이 아니었을 것이다
- 리전간 리소스는 공유되지 않음
- 리전간 리소스 복사는 가능함
- 계정당 액세스 할 수 있는 리전이 정해져있다?
- 한국은 여러곳에 열려있다?
- e.g. 중국은 몇몇 지역 접근 못함
- 각자가 사용할 수 있는 리전과 가용영역이 있다
가용영역(AZ, Avaliability Zone)
- 실질적으로 IDC 센터가 위치하는 장소
- 리전은 여러개의 AZ를 가짐
- Seoul 리전이라고 해서 서울에 IDC가 있는것이 아님
- 수도이기 때문에 그렇게 표기한 것임
- 가용영역의 위치가 실제 IDC가 있는 위치임
- Seoul 리전의 경우 3개의 AZ가 있는데, 이는 한국에 AWS IDC가 3군데 있음을 뜻함
- 가용영역의 위치는 비공개임
- 물리적 피해를 막기 위함
- 가용영역간 fail over를 elastic IP로 해결할 수 있다?
- 리소스가 리전의 가용 영역에 걸쳐 배포될 수 있도록 AWS는 각 AWS 계정의 이름에 가용 영역을 독립적으로 매핑합니다. 예를 들어 AWS 계정의 us-east-1a 가용 영역은 다른 AWS 계정에 대한 us-east-1a 가용 영역과 위치가 동일하지 않을 수 있습니다
- 1a가 특정 위치를 명시하는게 아닐 수 있음을 말하는 듯?
- AZ ID를 설정하면 특정 위치를 아예 지정할 수 있다
- 이번 AZ 추가가 테라폼 설정에 왜 문제가 되었을까?
- AZ간 통신은 가능한가?
- 리전간 통신은 가능한가?
- AZ간 VPC는 묶지만, 리전간은 안된다?
- 리전간 failover는 가능한가?
- 리전간 스위칭이 가능한가?(seoul -> tokyo)
- 최종 도메인에 연결되는 AWS 주소를 바꿔주면 될 듯 하다
- 데이터베이스 동기화는 어떻게하는가?
- AZ가 망가지는 경우?
- 리전이 망가지는 경우?
- 컨테이너 4개를 띄운다고 하면 2개는 2a에 2개는 2c에?
- 가용영역에 영향받을 수 있는 리소스들은 가용영역을 선택하지 않는다
- 아마도 모든 가용영역끼리 복사되어있지 않을까?
- e.g. Elastic Beanstalk 등
- beanstalk 은 가용영역이 없고 ec2 를 가용영역을 선택해서 띄운다
- loadbalancer에서 az 범위 선택하고 그 범위 내에서 로드밸런싱