[aws] region, az

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 범위 선택하고 그 범위 내에서 로드밸런싱