Static Stability
선박의 경우 용골(Keel)1이 있는데, 회전(Rolling)에 의해 배가 전복되지 않고 바른 자세를 유지하도록 역할을 한다. 비행기나 배가 회전하면서 휘청일 때 안정적인 자세를 유지하도록 만들어주는 특성을 정적 안정성(Static Stability)라고 부르는데 정지, 가속 및 감속 중에도 똑바로 자세를 유지하는 능력을 말한다.2
AWS에서도 서비스들의 복원력(Resilience) 특성 중 가장 중요한 한 가지로 정적 안정성을 정의하고 있다. 이 용어의 의미는 시스템이 정적 상태로 작동하며, 의존성 대상이 실패하거나 사용할 수 없게 되는 동안에도 어떠한 변경을 하지 않더라도 정상적으로 계속 작동한다는 것을 의미한다. 정적 안정성을 구현하기 위한 방법 중 한 가지는 서비스 중 하나가 성공적으로 복구되지 않을 수 있도록 하는 순환 종속성을 제거하는 것이다.
또 다른 방법은 기존 상태를 유지하는 방법인데, 통계적으로 제어 영역(Control Plane)이 데이터 영역(Data Plane)보다 실패할 가능성이 높다는 것을 고려하여, 제어 영역과 데이터 영역을 분리하는 것이다. 데이터 영역은 일반적으로 제어 영역으로 부터 오는 데이터에 의존하지만, 일단 프로비저닝된 자원에 대해 데이터 영역에 대한 접근은 제어 영역에 대해 의존성이 없으므로 제어 영역이 손상되더라도 이미 갖고 있는 데이터를 활용하여 기존 상태를 유지하면서 동작할 수 있다. 즉, 자원을 생성, 변경, 삭제하는 기능에 문제가 생겨서 사용할 수 없더라도 이미 할당 받은 기존 자원은 계속 사용할 수 있다. 비슷한 방법을 활용하면 다양한 유형의 종속성 장애에 대해 정적으로 안정되도록 다양한 패턴을 구현할 수 있다.
정적 안정성은 AWS 서비스 설계에 중요하게 작용하는 개념이지만, 같은 개념을 활용하여 아키텍처를 개선하는 데 도움을 줄 수 있다. 시스템을 설계할 때, 복구를 완료하기 위해 가장 적은 변경을 요구하도록 안정적인 복구 및 완화 조치 체계를 세우는 것이다. 예를 들어, 장애가 발생한 가용 영역(Availability Zone)3으로부터 복구하기 위해 EC2 제어 영역에 종속적인 새로운 EC2 인스턴스 신규 생성대신, 미리 프로비저닝되어 있는 여분의 자원을 활용하여 정적 안정성을 확복하는 것이다. 따라서 제어 영역(자원에 대한 변경을 만드는 API)에 대한 의존성을 제거하면 보다 탄력적인 워크로드(Workloads)를 위한 복구 방식을 구현할 수 있게된다.4 5
동작-대기(Active-Standby) 방식은 전통적으로 고가용성(High-Availability, HA)을 활용하기 위한 전략으로 사용해왔다. 주로 동작하는 장비가 있고, 문제가 생기면 대기 상태의 장비가 즉시 투입된다는 매우 직관적인 전략이기 때문에 많은 곳에서 활용해왔다. 이러한 전략에 정적 안정성을 고려하면 상태를 저장하는(Stateful) 애플리케이션에 대한 고가용성 아키텍처를 만들 수 있다.
AWS의 RDS(Relational Database Service)는 데이터의 일관성에 우선순위를 둔 관계형 데이터베이스를 제공하는 서비스이기 때문에 셔플 샤딩(Shuffle Sharding)6과 같은 위험 분산 설계를 도입하기 어렵다.7 대신 주로 동작하는 장비와 비상 상황에 대응하기 위한 대기 장비를 구성하고 실시간으로 데이터를 동기화 한다. 만약 주 장비가 설치된 가용 영역에 문제가 발생하거나, 주 장비 자체에 문제가 생기면, 상태 확인 타임 아웃과 같은 기준을 통해 이상 상황을 탐지하고 즉시 자동으로 대기 장비를 투입한다. 이러한 장애 대응 과정에서 새로운 서버나 네크워크 자원을 요청하지 않아도 되기 떄문에, 제어 영역에 대한 의존성 없이 RDS 서비스 자체적으로 고가용성 확보가 가능하다.
상태를 저장하지 않는(Stateless) 애플리케이션의 경우 여러 가용 영역에 분산 배치한 서버를 동시에 구성하고 부하를 분산시켜 고가용성을 확보할 수 있다. 가장 보편적으로 활용할 수 있는 다중 활성화(Active-Active) 아키텍처이며, 인터넷에 연결되어 외부 요청을 처리하는 부분(Internet-facing)과 내부에서 요청을 처리하는(Internel) 부분 모두가 전체 가용 영역을 최대한 활용하도록 설계하는 것이다. AWS 에서는 여러 가용 영역의 묶음으로 리전(Region)을 사용한다. 외부로 부터 요청을 받는 서비스도 리전에 걸쳐 배포하고, 내부의 서비스도 리전에 걸쳐서 배포한다면(Regional to regional), 단일 가용 영역 장애가 발생하더라도 나머지 가용 영역에 있는 장비가 요청을 처리하기 때문에 고가용성을 확보할 수 있다.
대체로, 이와 같은 다중 활성화 아키텍처는 단일 가용 영역 장애에 대해 잘 대응한다. 하지만, 생각해봐야할 부분이 몇 가지 있다.
1/ 애플리케이션이 문제 없이 잘 동작하고 있었다는 가정을 하고 있다. 만약 신규 기능을 배포했는데, 문제가 있다면 전체 가용 영역에 영향을 주기 때문에 서버는 고가용성을 확보했지만, 애플리케이션의 가용성이 떨어질 수 있다. 이를 해결하기 위해서 가용 영역 단위 롤아웃 배포 전략이 필요하다. 셀 기반 아키텍처와 같이 장애를 격리하는 전략로 고려해 볼 필요가 있다.8
2/ 단일 가용 영역 장애에 대해, 오토스케일링(Auto-Scaling) 기능으로 나머지 가용 영역에 추가 자원을 생성하면서 대응하는 전략을 세웠다면, 비용은 절감할 수 있겠지만 실제 장애 상황에서는 변수가 생길 수 있다. 신규 서버 자원을 생성 요청했을 때 제어 영역의 동작이 불가능해서 자원 생성에 실패할 수 있고, 제어 영역이 잘 동작한다 하더라도 정상적인 가용 영역에 물리적인 장비가 부족할 수 있다. 이러한 상황을 고려하여, AWS에서는 정적 안정성을 위해 여분의 자원을 미리 생성해둔다. 예를 들어 3개의 가용 영역에서 각 가용 영역이 처리할 수 있는 용량의 30% 정도의 여분을 만들어 둔다면, 단일 가용 영역 장애에 대해 나머지 가용 영역들이 추가 자원 생성 없이 트래픽을 수용할 수 있다.
리전에서 리전으로(Regional to regional) 요청을 전달하는 다중 활성화 방식은 상태를 저장하지 않는 대부분의 서비스들의 높은 가용성을 확보하기 충분하다. 하지만 위에서 언급한 내용에 더해 더 생각해 봐야 할 내용이 있다.
1/ 단일 가용 영역 장애 발생 시 내부 서비스로 접속할 때, 사용 가능한 자원을 한 번 더 확인해야 하는 문제가 있다. 단순하게 계산해 보면, 처음 접속 시 영향을 받은 가용 영역을 회피할 가능성은 2/3이고, 내부 서비스 요청 시에도 2/3이므로 요청이 영향 받은 가용 영역을 회피할 경우의 수는 2/3 * 2/3 = 4/9이 된다.
2/ 또한, 고객 접점이 있는 애플리케이션 뿐아니라 내부에서 처리하는 서비스들에서도 여러 가용 영역 사이의 네트워크 비용이 발생한다.
이러한 문제를 개선하기 위해서 리전에서 가용 영역(Regional to zonal) 전달하거나 가용 영역에서 가용 영역(Zonal to zonal) 방식을 선택적으로 활용할 수 있다. 다음과 같이 외부 망과 연결하는 서비스의 경우는 리전 전체에 걸쳐서 다중 활성화 방식을 적용하여 단일 가용 영역 장애를 회피할 수 있다. 대신 내부 서비스를 호출할 때는 같은 가용 영역의 애플리케이션만 활용하여 네트워크 비용과 가용 영역 간 부하 분산(Load Balancing) 처리 비용을 절감할 수 있다. 한 가지 의문이 생길 수 있는데, 다중 가용 영역을 권장하던 기조와 다르게 내부 시스템은 가용 영역 단위로 격리를 한다고 하면 단일 가용 영역 장애를 회피하기 어렵다고 생각할 것이다.
아래 그림과 같이 외부에서 높은 가용성을 이미 확보 했고, 특정 가용 영역에 문제가 생겼다면, 외부 서비스에서부터 요청을 보내지 않을 것이기 때문에 문제가 없다. 그림에서 eu-west-1b 에 문제가 생겼다고 생각해보면, 1b 가용 영역에 존재하는 로드 발란서와 애플리케이션 서버는 전면 장애가 발생한다. 하지만 그 앞에 서 외부 요청을 받는 주황색으로 표시된 시스템의 경우, 1b 가용 영역의 서버를 회피해서 1a, 1c의 서버로 요청이 전달될 것이기 때문에 높은 가용성을 확보할 수 있게 된다.
또한, 외부 고객에게 직접적으로 노출하지 않는 내부 서비스의 경우 기대하는 서비스의 가용율 수준이 99.5% 처럼 상대적으로 높지 않을 수 있기 때문에 단일 가용 영역 장애를 어느 정도 감수하도록 설계할 수 있다. 99.999% 가용율은 365일 기준으로 사용 불가능한 시간의 합이 5분 정도일 정도로 매우 낮은 수준의 고장율이며 읽을 때는 Five-Nines라고 읽는다. 99.99는 Four-Nines이고 99.95는 Three-Nines Five라고 읽는다.9 99.95%의 가용율을 목표로 한다면, 비용 절감을 위해 가용 영역에서 가용 영역(Zonal to zonal)으로 전달하는 방식을 선택할 수 있다. 예를 들어, 시급하지 않은 배치(Batch) 작업의 경우 데이터를 처리하는 부분(Data plane)은 가용 영역 별로 격리해두고, 스케쥴을 관리하는 제어 영역(Control plane)과 데이터를 저장하는 부분은 높은 가용성을 확보하도록 설계를 할 수 있다.
99.999% 가용율은 매우 달성하기 힘든 목표이며, 특히 글로벌 대규모 서비스의 경우는 더욱 달성 하기 힘들다. 그래도 목표를 달성하고 싶다면, 시스템 뿐아니라 우수한 엔지니어 채용까지 많은 비용을 지불해야 한다. 하지만 이미 쏘리 아키텍처(Sorry Architecture)10에서 이야기했듯이 클라우드 컴퓨팅과 소프트웨어 엔지니어링의 목표는 세계 최고라는 성취가 아니라 비용 효율적인 비지니스가 핵심이기 때문에, 기대하는 가용성과 투입 비용을 계산하여 가장 적절한 아키텍처를 선택할 필요가 있다. 높은 가용성은 공짜가 아니다.
- Keel - Wikipedia [본문으로]
- Static_stability - Wikipedia [본문으로]
- AWS Infrastructure를 구성하는 요소이며, 1 개 이상의 데이터 센터로 되어 있다. 여러 가용 영역끼리는 재해가 전파되지 않을 정도의 거리만큼 물리적으로 떨어져 있지만, 애플리케이션 동작에 문제가 없을만큼 빠른 통신망으로 연결되어 있다. [본문으로]
- Static stability using Availability Zones [본문으로]
- Static stability [본문으로]
- Workload isolation using shuffle sharding [본문으로]
- CAP(Consistency, Aailability, Partition Tolerance)이론에 따라 확장성이나 가용성, 내결함성 등에 우선순위를 둔 NoSQL은 데이터를 분산 저장하며, 복제를 통해 내구성과 가용성을 확보하고 있다. [본문으로]
- Cell-based Architecture [본문으로]
- High_availability - Wikipedia [본문으로]
- Sorry Architecture [본문으로]