일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- 백엔드
- vm
- Container
- HTTP
- virtualization
- 스프링 배치
- 스프링
- web server
- 도커
- 스프링 시큐리티
- spring batch
- 데이터베이스
- CI/CD
- Spring Security
- ORM
- JPA
- CS
- spring cloud
- 웹 서버
- mysql
- Spring
- computer science
- 배포
- 스프링 부트
- 가상화
- spring boot
- Java
- 영속성 컨텍스트
- 컨테이너
- 자바
- Today
- Total
개발 일기
[AWS] Region와 AZ 본문
최근 다양한 AWS Service들을 접하게 되면서 기본적인 것들도 짚고 넘어가야 겠다는 생각이 점차 들게 됐다.
VPC와 Subnet 설정 등 매번 그냥 뭔지도 모르고 블로그 따라서 설정하고 default로 선택하고 넘어가고 이래서는 안되겠다는 생각이 들어 우선 자주 등장하는 개념들인 Region, AZ에 대해서 정리해보고자 한다.
이 아키텍처를 하나씩 뜯어 보면서 차례대로 이해해보자.
Region
AWS를 써보면 알겠지만 Region별로 서비스(리소스)를 제공한다. 그래서 특정 Region에는 제공하지만 또 어디서는 그 서비스를 제공하는 경우를 확인할 수 있다.
클라우드 서비스는 사용자가 물리적인 데이터 센터를 고려하지 않도록 논리적인 컴퓨터를 제공하는데 당연하게도 그 기반으로 어딘가에는 결국 물리적 서버가 존재한다.
AWS 리전 공식 문서를 보면 정말 다양한 리전이 존재한다. 그중에서 우리는 ap-northeast-2 아시아 태평양(서울)에 주로 집중하지 않을까 싶다. 이때 실제로 물리적 서버가 존재하는 곳이 서울이라는 것은 아니고 한국의 대표 지역의 이름을 땄을 뿐이다.
이때 미국과 한국 리전을 비교했을때 미국이 더 저렴하다. 그런데 내가 이전에 실수로 eu-north-1 유럽(스톡홀름) 리젼에다가 EC2를 생성하여 배포한적이 있는데 너무 느렸던 경험이 있다. 즉, 저렴하다고해서 그 Region을 택하기보다는 가까운 리전을 택하는 것이 중요하다는 사실을 몸소 배울 수 있었다. 그래서 나는 한국 사람들을 대상으로 하는 서비스만 경험했기 때문에 서울만 쓴다!
AZ(Availability Zone)
그런데 대한민국에 AWS에서 제공하는 데이터 센터가 오직 한 군데이고 만약 그 데이터 센터가 테러나 지진이나 화재 등의 천재지변으로 파괴가 된다면? 한국 리전을 통해 진행중인 서비스는 모두 다운되는 것이다. 즉, 안정성, 가용성이 떨어진다.
이러한 문제를 막기 위해 Availability Zone 가용 영역이라는 개념이 도입된다. AWS는 리전 별로 최소 2개 이상의 AZ를 제공한다.
서울을 예로 들면 현재 4개의 AZ가 있는 것으로 확인된다.
그래서 2개 이상의 가용 영역에 배포하게 되면 특정 데이터 센터가 다운되더라도 다른 가용 영역을 통해 계속 서비스가 가능하게 된다.
ap-northeast-2a ap-northeast-2b ap-northeast-2c ap-northeast-2d
또한 추가적으로 이 각각의 가용영역이 실제 물리적 데이터 센터와 매번 똑같이 1대1 매핑되는 것이 아니다. 예를들어보면 철수에겐 ap-northeast-2a가 서울에 있는 것일 수도 있지만 영희에게는 ap-northeast-2a가 대구에 있을 수 있다. 이를 통해 하나의 가용 영역으로 유저가 몰리는 것을 막을 수 있다고 한다.
'DevOps > AWS Services' 카테고리의 다른 글
[AWS] NAT Gateway와 Bastion Host (0) | 2024.11.23 |
---|---|
[AWS] VPC - 보안그룹과 NACL (0) | 2024.11.23 |
[AWS] VPC와 Subnet (0) | 2024.11.23 |
[AWS] Amazon Elastic Container Service 도입기 (0) | 2024.11.23 |
[AWS] 퍼블릭 IP, 프라이빗 IP 그리고 탄력적 IP (0) | 2024.06.28 |