[CLOUD-002][입문] 리전·가용영역·엣지 구분하기
페이지 정보
작성자 기술팀장 작성일 26-08-29 22:33 조회 258 댓글 0본문
[이번 수업]
클라우드 위치를 설명하는 리전, 가용영역, 엣지를 구분합니다. 두 가용영역에 서비스를 나누면 어떤 장애를 견디는지, 리전 전체 장애에는 왜 별도 설계가 필요한지 로컬 코드로 확인합니다.
[선수지식]
CLOUD-001의 클라우드·가상화·공유 책임 개념과 NET-001의 클라이언트·서버 흐름을 알면 됩니다. Python 3만 있으면 실습할 수 있습니다.
[학습목표]
1. 리전·가용영역·엣지의 범위와 역할을 구분한다.
2. 단일 영역과 다중 영역 구성의 장애 범위를 비교한다.
3. 엣지 캐시와 원본 서버의 관계를 설명한다.
[핵심개념]
리전은 클라우드 사업자가 서비스를 제공하는 큰 지리적 영역입니다.
가용영역은 한 리전 안에서 전원·냉각·네트워크 같은 장애 영향을 분리하도록 설계된 위치 또는 실패 영역입니다. 한 영역의 앱이 멈춰도 다른 영역의 앱이 요청을 받을 수 있게 로드밸런서와 인스턴스를 나누면 영역 장애에 대비할 수 있습니다. 그러나 앱만 나누고 데이터베이스나 네트워크 경로가 한 영역에 남아 있으면 전체 서비스는 멈출 수 있습니다. 모든 핵심 의존성을 함께 점검해야 합니다.
다중 가용영역은 리전 전체 장애까지 자동으로 해결하지 않습니다. 더 넓은 재해에 대비하려면 다른 리전에 백업이나 복제본을 두고 전환 절차를 준비해야 합니다.
엣지는 사용자와 가까운 접속 지점에서 콘텐츠 전달, 캐시, 연결 종료 같은 일을 수행하는 계층입니다. 이미지·CSS처럼 자주 읽는 파일이 캐시에 있으면 원본 리전까지 가지 않아도 응답할 수 있습니다. 캐시에 없는 요청과 동적 데이터는 원본으로 전달될 수 있으며 엣지는 원본 데이터베이스를 자동으로 대신하지 않습니다.
[따라하기]
cloud_locations.py에 다음을 저장하세요. 실제 클라우드 계정이나 비용은 필요하지 않습니다.
architecture = {
"region": "region-a",
"zones": {
"zone-a": ["app-1"],
"zone-b": ["app-2"],
},
"edge_cache": {"logo.svg", "style.css"},
}
def healthy_apps(failed_zones):
return [
app
for zone, apps in architecture["zones"].items()
if zone not in failed_zones
for app in apps
]
print("normal:", healthy_apps(set()))
print("zone-a outage:", healthy_apps({"zone-a"}))
print("region outage:", healthy_apps({"zone-a", "zone-b"}))
for path in ["logo.svg", "api/users"]:
print(path, "edge hit:", path in architecture["edge_cache"])
Windows는 py cloud_locations.py, macOS·Linux는 python3 cloud_locations.py로 실행합니다. 예상 결과는 다음과 같습니다.
normal: ['app-1', 'app-2']
zone-a outage: ['app-2']
region outage: []
logo.svg edge hit: True
api/users edge hit: False
한 영역 장애에는 app-2가 남지만 두 영역을 포함한 리전 장애에는 앱이 없습니다. logo.svg는 엣지 캐시에서 찾지만 동적 API는 원본 처리가 필요하다는 모형입니다.
[흔한 실수]
첫째, 리전과 가용영역을 같은 크기의 장소로 생각합니다. 둘째, 서버 두 대를 같은 영역에 두고 다중 영역이라고 부릅니다. 셋째, 다중 영역 구성을 백업과 동일하게 봅니다. 복제는 잘못된 삭제도 전달할 수 있으므로 별도 백업이 필요합니다. 넷째, 엣지에 두면 모든 API가 원본 없이 동작한다고 생각합니다.
[보안 주의]
리전 선택만으로 법규 준수나 보안이 완성되지 않습니다. 저장·전송 암호화, 최소 권한 IAM, 비밀 관리, 네트워크 제한, 로그와 패치를 별도로 설정하세요. 엣지 캐시에 사용자별 응답이나 인증정보가 섞이지 않도록 캐시 키와 Cache-Control을 검토합니다. 예제와 문서에는 실제 계정 ID, 내부 주소, 접근 키를 넣지 마세요.
[직접 해볼 과제]
zone-c와 app-3을 추가하고 zone-b만 실패했을 때 남는 앱을 확인하세요. 이어서 api/users를 엣지 캐시에 넣지 말아야 할 이유와 리전 장애에 대비해 별도로 필요한 항목 세 가지를 적으세요.
[확인문제]
1. 리전과 가용영역은 범위와 장애 격리 측면에서 어떻게 다른가요?
2. 두 영역에 앱만 배치해도 서비스 전체가 고가용성이 되지 않는 이유는 무엇인가요?
3. 엣지 캐시 적중과 실패 시 요청 경로는 어떻게 달라지나요?
[다음 학습]
순환 커리큘럼의 다음 글은 DEVOPS-002 Docker 이미지와 컨테이너입니다. 클라우드 트랙에서는 CLOUD-003 IAM 사용자·역할·최소 권한으로 이어집니다.
[공식 참고 자료]
AWS 리전과 가용영역
https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-regions-availability-zones.html
Azure 가용영역 개요
https://learn.microsoft.com/en-us/azure/reliability/availability-zones-overview
Google Cloud 리전과 영역
https://cloud.google.com/compute/docs/regions-zones
CloudFront 엣지 전달 개요
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html
클라우드 위치를 설명하는 리전, 가용영역, 엣지를 구분합니다. 두 가용영역에 서비스를 나누면 어떤 장애를 견디는지, 리전 전체 장애에는 왜 별도 설계가 필요한지 로컬 코드로 확인합니다.
[선수지식]
CLOUD-001의 클라우드·가상화·공유 책임 개념과 NET-001의 클라이언트·서버 흐름을 알면 됩니다. Python 3만 있으면 실습할 수 있습니다.
[학습목표]
1. 리전·가용영역·엣지의 범위와 역할을 구분한다.
2. 단일 영역과 다중 영역 구성의 장애 범위를 비교한다.
3. 엣지 캐시와 원본 서버의 관계를 설명한다.
[핵심개념]
리전은 클라우드 사업자가 서비스를 제공하는 큰 지리적 영역입니다.
가용영역은 한 리전 안에서 전원·냉각·네트워크 같은 장애 영향을 분리하도록 설계된 위치 또는 실패 영역입니다. 한 영역의 앱이 멈춰도 다른 영역의 앱이 요청을 받을 수 있게 로드밸런서와 인스턴스를 나누면 영역 장애에 대비할 수 있습니다. 그러나 앱만 나누고 데이터베이스나 네트워크 경로가 한 영역에 남아 있으면 전체 서비스는 멈출 수 있습니다. 모든 핵심 의존성을 함께 점검해야 합니다.
다중 가용영역은 리전 전체 장애까지 자동으로 해결하지 않습니다. 더 넓은 재해에 대비하려면 다른 리전에 백업이나 복제본을 두고 전환 절차를 준비해야 합니다.
엣지는 사용자와 가까운 접속 지점에서 콘텐츠 전달, 캐시, 연결 종료 같은 일을 수행하는 계층입니다. 이미지·CSS처럼 자주 읽는 파일이 캐시에 있으면 원본 리전까지 가지 않아도 응답할 수 있습니다. 캐시에 없는 요청과 동적 데이터는 원본으로 전달될 수 있으며 엣지는 원본 데이터베이스를 자동으로 대신하지 않습니다.
[따라하기]
cloud_locations.py에 다음을 저장하세요. 실제 클라우드 계정이나 비용은 필요하지 않습니다.
architecture = {
"region": "region-a",
"zones": {
"zone-a": ["app-1"],
"zone-b": ["app-2"],
},
"edge_cache": {"logo.svg", "style.css"},
}
def healthy_apps(failed_zones):
return [
app
for zone, apps in architecture["zones"].items()
if zone not in failed_zones
for app in apps
]
print("normal:", healthy_apps(set()))
print("zone-a outage:", healthy_apps({"zone-a"}))
print("region outage:", healthy_apps({"zone-a", "zone-b"}))
for path in ["logo.svg", "api/users"]:
print(path, "edge hit:", path in architecture["edge_cache"])
Windows는 py cloud_locations.py, macOS·Linux는 python3 cloud_locations.py로 실행합니다. 예상 결과는 다음과 같습니다.
normal: ['app-1', 'app-2']
zone-a outage: ['app-2']
region outage: []
logo.svg edge hit: True
api/users edge hit: False
한 영역 장애에는 app-2가 남지만 두 영역을 포함한 리전 장애에는 앱이 없습니다. logo.svg는 엣지 캐시에서 찾지만 동적 API는 원본 처리가 필요하다는 모형입니다.
[흔한 실수]
첫째, 리전과 가용영역을 같은 크기의 장소로 생각합니다. 둘째, 서버 두 대를 같은 영역에 두고 다중 영역이라고 부릅니다. 셋째, 다중 영역 구성을 백업과 동일하게 봅니다. 복제는 잘못된 삭제도 전달할 수 있으므로 별도 백업이 필요합니다. 넷째, 엣지에 두면 모든 API가 원본 없이 동작한다고 생각합니다.
[보안 주의]
리전 선택만으로 법규 준수나 보안이 완성되지 않습니다. 저장·전송 암호화, 최소 권한 IAM, 비밀 관리, 네트워크 제한, 로그와 패치를 별도로 설정하세요. 엣지 캐시에 사용자별 응답이나 인증정보가 섞이지 않도록 캐시 키와 Cache-Control을 검토합니다. 예제와 문서에는 실제 계정 ID, 내부 주소, 접근 키를 넣지 마세요.
[직접 해볼 과제]
zone-c와 app-3을 추가하고 zone-b만 실패했을 때 남는 앱을 확인하세요. 이어서 api/users를 엣지 캐시에 넣지 말아야 할 이유와 리전 장애에 대비해 별도로 필요한 항목 세 가지를 적으세요.
[확인문제]
1. 리전과 가용영역은 범위와 장애 격리 측면에서 어떻게 다른가요?
2. 두 영역에 앱만 배치해도 서비스 전체가 고가용성이 되지 않는 이유는 무엇인가요?
3. 엣지 캐시 적중과 실패 시 요청 경로는 어떻게 달라지나요?
[다음 학습]
순환 커리큘럼의 다음 글은 DEVOPS-002 Docker 이미지와 컨테이너입니다. 클라우드 트랙에서는 CLOUD-003 IAM 사용자·역할·최소 권한으로 이어집니다.
[공식 참고 자료]
AWS 리전과 가용영역
https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-regions-availability-zones.html
Azure 가용영역 개요
https://learn.microsoft.com/en-us/azure/reliability/availability-zones-overview
Google Cloud 리전과 영역
https://cloud.google.com/compute/docs/regions-zones
CloudFront 엣지 전달 개요
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html
댓글목록 0
등록된 댓글이 없습니다.