[CLOUD-012][실무] 장애에 버티는 3계층 서비스 설계하기 > IT 기술 공유

• 목록

[이번 수업]

웹 입구, 애플리케이션, 데이터 저장소를 세 계층으로 나누고 두 가용 구역에 배치하는 작은 클라우드 서비스를 설계합니다. 실제 자원을 만들지 않고 구조·통신·장애 대응·복구 기준을 문서와 검사 코드로 확인합니다.

[선수지식]

CLOUD-002의 리전과 가용영역, CLOUD-004의 서브넷과 보안그룹, CLOUD-009의 고가용성과 복구, NET-012의 네트워크 구성도를 먼저 알면 좋습니다.

[학습목표]

1. 3계층의 책임과 통신 경로를 분리한다.
2. 단일 장애 지점을 찾아 두 가용 구역에 분산한다.
3. 보안·복구·비용 점검 항목을 설계에 기록한다.

[핵심개념]

3계층 구조는 요청을 받는 웹 계층, 업무 규칙을 실행하는 애플리케이션 계층, 상태를 보관하는 데이터 계층을 분리하는 방식입니다. 각 계층을 따로 확장하고 보호할 수 있지만, 계층을 나눴다는 사실만으로 고가용성이 생기지는 않습니다. 고가용성은 일부 구성요소가 멈춰도 서비스를 이어 가는 성질입니다.

인터넷에는 HTTPS 입구만 공개하고 애플리케이션과 데이터 계층은 사설 구간에 둡니다. 웹→앱, 앱→데이터처럼 필요한 방향만 허용합니다. 웹과 앱 인스턴스는 서로 독립된 두 가용 구역에 배치하고, 데이터는 복제와 자동 전환 방법을 정합니다. 상태 확인, 요청 시간 제한, 백업, 복원 시험도 구성도 옆에 적어야 합니다.

복구 목표도 숫자로 정합니다. RTO는 장애 뒤 서비스를 다시 쓸 수 있을 때까지의 목표 시간이고, RPO는 잃어도 감당할 수 있는 데이터 시간 범위입니다. 예를 들어 RTO 30분, RPO 5분은 설계 검토용 가정이며 실제 값은 업무 영향과 비용을 근거로 결정합니다.

[따라하기]

architecture.json을 만드세요. 구역 이름은 특정 사업자의 실제 식별자가 아닌 연습용 값입니다.
```json
{
  "zones": ["zone-a", "zone-b"],
  "tiers": {
    "web":  {"public": true,  "replicas": 2},
    "app":  {"public": false, "replicas": 2},
    "data": {"public": false, "replicas": 2}
  },
  "allowed": [
    "internet:web:443",
    "web:app:8000",
    "app:data:5432"
  ],
  "rto_minutes": 30,
  "rpo_minutes": 5
}
```

같은 폴더에 check_architecture.py를 저장합니다.
```python
import json

with open("architecture.json", encoding="utf-8") as f:
    design = json.load(f)

assert len(design["zones"]) >= 2
assert all(v["replicas"] >= 2 for v in design["tiers"].values())
assert design["tiers"]["app"]["public"] is False
assert design["tiers"]["data"]["public"] is False
assert design["allowed"] == [
    "internet:web:443", "web:app:8000", "app:data:5432"
]
print("설계 점검 통과: 2개 구역, 3개 계층, 3개 허용 경로")
```

macOS·Linux는 `python3 check_architecture.py`, Windows는 `py check_architecture.py`를 실행합니다. 예상 결과는 `설계 점검 통과: 2개 구역, 3개 계층, 3개 허용 경로`입니다. data의 public을 true로 바꾸면 AssertionError가 나며 위험한 변경을 잡습니다. 이 검사는 설계 규칙의 최소 예제이지 실제 클라우드 설정 검증을 대신하지 않습니다.

[흔한 실수]

서버 수만 두 개로 늘리고 같은 가용 구역에 모두 두지 마세요. 데이터 복제만 믿고 복원 시험을 생략하거나, 구성도·방화벽 규칙·실제 배포가 서로 달라지는 것도 흔한 문제입니다. 자동 확장에는 상태 확인과 종료 중 요청 정리 기준이 함께 필요합니다.

[보안 주의]

데이터베이스와 관리 포트를 인터넷 전체에 열지 않습니다. 계층 사이에는 최소 권한 규칙을 적용하고 전송 구간을 암호화합니다. 문서와 예제에 실제 계정, 주소, 키, 토큰을 넣지 마세요. 비용이 생기는 실제 배포는 승인된 본인 계정의 격리 환경에서 예산 알림과 삭제 계획을 먼저 마련한 뒤 진행합니다.

[직접 해볼 과제]

구성도에 두 가용 구역, 상태 확인 경로, 백업 저장소를 추가하세요. 웹·앱·데이터가 각각 멈췄을 때 감지 방법, 자동 조치, 사람이 확인할 항목을 한 줄씩 적고 RTO·RPO를 만족하는지 설명합니다.

[확인문제]

1. 애플리케이션과 데이터 계층을 사설 구간에 두는 이유는 무엇인가요?
2. 복제본이 여러 개여도 같은 가용 구역에만 있으면 어떤 위험이 남나요?
3. RTO와 RPO는 각각 어떤 시간을 뜻하나요?

[다음 학습]

DEVOPS-012에서 이 설계를 빌드·테스트·배포·모니터링 파이프라인으로 연결합니다.

[공식 참고 자료]

https://csrc.nist.gov/pubs/sp/800/145/final
https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/n-tier
https://learn.microsoft.com/en-us/azure/well-architected/reliability/principles
https://csrc.nist.gov/pubs/sp/800/207/final
https://docs.python.org/3/library/json.html