DanzzaN

SOA-C03 06/16 — 확장·부하 분산·회복탄력성

정보보안기사 응시 후 학습을 위해 미리 작성한 본문이다. 작성·보존은 대화 전달이나 학습 완료를 뜻하지 않는다.

1. 수요 증가와 장애 대응을 구분한다

확장은 처리 능력을 조정하고, 부하 분산은 요청을 대상에 배치하며, 회복탄력성은 일부 실패 속에서도 기능을 유지하도록 설계한다. 서버 수가 많다는 사실만으로 세 가지가 모두 충족되지는 않는다.

요청량 증가 → 사용률·대기 증가 → 확장 정책 → 새 capacity 준비
                              ↓
                     load balancer의 healthy target
                              ↓
                   cache·DB가 증가한 요청을 처리

웹 서버만 늘려도 DB connection 한도에 막힐 수 있다. 따라서 04·05의 병목 관찰을 계층 전체에 적용한다.

2. 확장 지표는 자원이 늘면 압력이 줄어드는 값이어야 한다

EC2 Auto Scaling은 min·desired·max 안에서 용량을 관리한다. Target tracking은 목표 사용률을 유지하도록 조정한다. 총 요청 수보다 target당 요청 수, 총 queue 길이보다 worker당 backlog처럼 용량 변화에 따라 부하가 분산되는 값이 적합하다.

미리 정의된 지표의 정확한 이름은 ALBRequestCountPerTarget이며, ALB 전체의 RequestCount와 다르다. SQS 전체 queue 길이도 그대로 쓰기보다 ASG의 EC2 worker당 backlog로 계산한 custom metric을 검토한다. “요청 수와 backlog는 모두 대상 추적에 사용할 수 없다”는 일반화는 잘못이다.

새 instance의 warmup을 반영해야 준비 중인 자원 때문에 사용률을 잘못 해석하지 않는다. 여러 target tracking 정책은 가용성을 우선해 어느 하나가 scale-out을 요구하면 확장하고, scale-in이 활성화된 정책들이 함께 축소 조건을 만족해야 축소한다. Target tracking

정책의 관계는 다음과 같다.

방식질문
Target tracking목표 사용률 주변을 유지할 것인가
Step scaling임계값 초과 정도별로 조정량을 정할 것인가
Scheduled scaling이미 아는 시간의 수요 변화에 준비할 것인가
Predictive scaling반복 수요 패턴을 예측해 준비할 것인가

예측이나 예정 용량도 실제 workload health를 대신하지 않는다. max에 도달했는지, quota·부족한 capacity·subnet IP·잘못된 launch template 때문에 기동에 실패했는지 activity history를 본다. 확장 정책

ECS Service Auto Scaling은 service의 task 수를 조절한다. EC2 launch type에서 task 수를 늘리는 것과 task를 배치할 host capacity를 늘리는 것은 별도 경계다. Pending task가 많다면 CPU 사용률만 보지 않고 placement·capacity도 본다. ECS scaling

3. ELB health check는 특정 요청의 관찰이다

ALB에서는 listener·rule·target group·등록 target·활성 AZ가 연결되어야 트래픽이 간다. health check는 설정한 protocol·port·path와 응답 code·timeout으로 대상을 판정한다.

현상먼저 구분할 것
ResponseCodeMismatch앱 응답 코드, health path, redirect·인증 요구
Timeout보안 규칙·경로·listener·프로세스·응답 시간
unusedtarget 등록, listener 연결, AZ 활성화 여부
draining해제 중인 연결 처리 단계

모든 등록 target이 unhealthy일 때 ALB는 fail-open으로 이들에게 요청을 보낼 수 있다. 따라서 unhealthy라는 표시만으로 요청이 완전히 차단됐다고 가정하지 않는다. Health endpoint가 정상이어도 실제 결제·DB 쓰기 기능은 실패할 수 있다. 사용자 요청 성공률을 함께 본다. ALB health checks

ALB의 HTTP 계층 라우팅과 NLB의 전송 계층 부하 분산을 요구에 맞게 구분하며, ALB의 세부 동작을 모든 ELB 제품에 일반화하지 않는다.

4. Route 53은 DNS 응답 선택에 health를 사용한다

Route 53 health check는 endpoint, 다른 health check, CloudWatch alarm 등과 연결할 수 있다. DNS failover는 응답할 endpoint를 바꾸는 흐름이다. 이미 연결된 session을 다른 서버로 옮기는 기능과 다르며 resolver·client cache와 TTL의 영향을 받는다. Route 53 health checks

ALB target health는 LB가 어느 backend에 전달할지, Route 53 health는 DNS가 어느 endpoint를 알려 줄지에 연결된다. Health check가 접근할 수 있는 주소인지, 실제 서비스와 같은 실패를 관찰하는지도 확인한다. DNS 세부 라우팅은 14에서 이어진다.

5. Cache는 원천 부하를 줄이며 데이터 신선도 조건을 만든다

CloudFront는 edge에서 응답을 재사용해 origin 요청을 줄이고, ElastiCache는 애플리케이션 가까이에서 재사용 가능한 결과·데이터를 보관한다.

  • Cache-aside/lazy loading: miss이면 원천에서 읽어 cache에 넣는다. 첫 요청 지연과 만료 시 동시 miss를 고려한다.
  • Write-through: 쓰기 흐름에서 cache도 갱신한다. 쓰기 비용·실패 처리·실제로 읽히지 않는 데이터 저장을 고려한다.
  • TTL: stale data를 허용하는 시간과 원천 재조회 빈도를 조절한다.
  • Invalidation·갱신 실패: 오래된 값이 얼마나 남는지, 잘못된 데이터를 누구에게 공유할지 검토한다.

ElastiCache caching strategies

CloudFront는 cache policy·응답 헤더·TTL에 따라 객체를 보관한다. 사용자별 응답은 cache key와 접근 경계를 맞춰야 한다. Cache hit rate가 높아도 오래된 결과를 잘못 재사용한다면 목표를 달성한 것이 아니다. CloudFront expiration

6. DB 확장은 읽기·쓰기·가용성 축을 나눈다

수단주된 역할운영 경계
RDS instance class 변경CPU·메모리 등 능력 조정적용 방식·중단 영향·새 병목
Read replica읽기 부하 분산애플리케이션 라우팅·replication lag
Multi-AZ DB instancestandby를 통한 failoverstandby가 읽기를 처리하지 않음
Multi-AZ DB clusterwriter와 읽기 가능한 standby들DB instance 배포와 구조가 다름
DynamoDB auto scalingprovisioned RCU·WCU 조정min·max·지표·변경 반응 시간

Read replica로 쓰기를 자동 분산할 수 있다고 가정하지 않는다. 최신 읽기가 필요한 경로와 lag를 허용하는 경로를 나누고, 실제 read endpoint 사용 여부를 확인한다. RDS replicas, Multi-AZ 배포

DynamoDB에서 provisioned capacity auto scaling은 사용량에 반응해 capacity를 조정한다. 갑작스러운 증가에 즉시 무한 확장하는 보장은 없고 table·index 설정과 hot key도 확인해야 한다. On-demand capacity mode와 provisioned auto scaling을 같은 설정으로 설명하지 않는다. DynamoDB auto scaling

7. 완성된 운영 적용 — 한 AZ 장애와 동시 수요 증가

가정: 두 AZ의 웹 fleet 중 한쪽이 사용할 수 없게 됐다.

  1. 사용자 오류·healthy target 수·AZ별 capacity를 확인한다.
  2. 남은 AZ가 전체 수요를 감당할 여유가 있는지 본다.
  3. ASG desired와 실제 InService capacity 차이를 확인한다.
  4. 새 instance의 준비·health check·dependency 연결을 검증한다.
  5. DB failover·connection retry·cache miss 폭증을 함께 관찰한다.
  6. 복구 후 AZ 균형·비용·오류 추세와 데이터 기능을 확인한다.

서로 다른 AZ에 배치했어도 shared dependency가 단일 장애점이면 영향이 전파된다. 시험에서는 확장과 고가용성 수단을 요구에 맞게 선택하고, 운영에서는 남은 capacity와 dependency까지 검증한다. 범위: Domain 2 Tasks 2.1~2.2.

계획과 연결

  • ID: 06-scaling-load-balancing-and-resilience

  • 의존: 02-collection-alarms-dashboards-notifications, 04-compute-performance-and-resource-optimization, 05-storage-database-performance

  • 결정 축: 수요 변동·캐시·데이터 계층·장애 도메인을 확장 정책, 상태 확인, 다중 AZ 구성과 연결한다.

  • 범위: compute scaling, CloudFront·ElastiCache caching, RDS·DynamoDB scaling, ELB, Route 53 health checks, Multi-AZ와 fault tolerance.

  • 시험 매핑: Domain 2, Tasks 2.1–2.2.

  • 학습 안내

  • 전체 계획

그래프 뷰

백링크