가용성 요구 사항 파악

애플리케이션의 가용성은 대개 애플리케이션 전체의 단일 목표로 간주되는 경우가 많습니다. 하지만 자세히 살펴보면 애플리케이션이나 서비스의 특정 측면마다 가용성 요구 사항이 각기 다른 경우가 많습니다. 예를 들어 기존 데이터를 검색하기 전에 새 데이터를 수신하여 저장하는 기능이 더 중요한 시스템도 있습니다. 시스템 구성이나 환경을 변경하는 작업보다 실시간 작업을 우선적으로 처리하는 시스템도 있습니다. 그리고 특정 시간 동안에는 가용성 요구 사항이 매우 높지만 그 외의 시간에는 좀 더 오랫동안 중단되어도 되는 서비스도 있습니다. 이러한 점을 참조하여 애플리케이션 하나를 여러 구성 요소로 구분한 후 각 구성 요소의 가용성을 평가할 수 있습니다. 이렇게 하면 가장 엄격한 요구 사항에 따라 전체 시스템 엔지니어링을 진행하는 대신 특정 요구에 따라 가용성 관련 작업을 집중적으로 수행하고 경비를 중점 투입할 수 있습니다.

AWS에서 서비스는 주로 ‘데이터 플레인’과 ‘컨트롤 플레인’으로 구분됩니다. 데이터 플레인에서는 실시간 서비스를 제공하고, 컨트롤 플레인은 환경을 구성하는 데 사용됩니다. 예를 들어 Amazon EC2 인스턴스, Amazon RDS 데이터베이스, Amazon DynamoDB 테이블 읽기/쓰기 작업은 모두 데이터 플레인 작업입니다. 반면 새 EC2 인스턴스나 RDS 데이터베이스 시작 또는 DynamoDB의 테이블 메타데이터 추가/변경은 모두 컨트롤 플레인 작업으로 간주됩니다. 이러한 모든 기능에는 높은 수준의 가용성이 중요하지만, 일반적으로는 데이터 플레인의 가용성 설계 목표가 컨트롤 플레인보다 높습니다. 따라서 가용성에 대한 요구 사항이 높은 워크로드는 컨트롤 플레인 작업에 대한 런타임 의존성을 피해야 합니다.

대부분의 AWS 고객은 비슷한 방식을 통해 애플리케이션을 면밀하게 평가한 다음 가용성 요구가 각기 다른 하위 구성 요소를 확인합니다. 그런 후에는 각 측면에 맞게 가용성 설계 목표를 조정하고 적절한 작업을 수행해 시스템을 엔지니어링합니다. AWS는 99.999% 이상의 가용성을 요구하는 서비스 등 다양한 가용성 설계 목표가 있는 애플리케이션을 엔지니어링하는 데 풍부한 경험을 가지고 있습니다. AWS 솔루션스 아키텍트(SA)는 가용성 목표에 적합한 설계를 생성하는 데 도움을 줄 수 있습니다. 설계 프로세스 초기에 AWS를 활용하면 가용성 목표를 더욱 효율적으로 충족할 수 있습니다. 가용성 계획은 워크로드를 시작하기 전에만 수행하는 작업이 아닙니다. 즉, 운영을 진행하면서 설계를 구체화하고, 실제 이벤트에서 정보를 파악하며, 다양한 유형의 장애 발생 시에 복구를 할 수 있도록 지속적으로 가용성을 계획해야 합니다. 그런 후에는 구현 개선을 위해 적합한 작업을 적용할 수 있습니다.

워크로드에 필요한 가용성 요구 사항은 비즈니스 요구 사항 및 중요도와 일치해야 합니다. 먼저 정의된 RTO, RPO 및 가용성을 사용하여 비즈니스 중요도 프레임워크를 정의한 다음 각 워크로드를 평가할 수 있습니다. 이러한 접근 방식을 사용하려면 워크로드 구현에 관여한 사람들이 프레임워크에 대해 잘 알고 있어야 하며, 워크로드가 비즈니스 요구 사항에 미치는 영향을 잘 알고 있어야 합니다.