[reinvent 2024] AWS에서 미션 크리티컬 애플리케이션 운영을 위한 탄탄한 아키텍처

들어가며

빠르게 변화하는 클라우드 환경 속에서 어떻게 안정성과 복원력을 유지할 수 있는지 궁금했던 저는 이 세션을 신청하게 되었습니다. 세션을 통해 격리 설계, 세밀한 관측 가능성, 그리고 효과적인 복구 전략 등 실제 사례를 바탕으로 한 실용적인 지식을 배우고자 합니다..해당 세션을 통해서 더 강력하고 신뢰할 수 있는 클라우드 아키텍처를 구축하는 데 도움이 되었으면 좋겠습니다.

실패 격리(Fault Isolation)와 물리적 설계

AWS에서 애플리케이션의 복원력을 강화하려면 실패 격리(Fault Isolation)를 효과적으로 설계하는 것이 중요합니다. 실패 격리란 시스템이 고장나더라도 전체 애플리케이션에 영향을 최소화할 수 있도록 경계를 설정하는 것을 의미합니다. 이를 위해 AWS는 Zonal Services, Regional Services, 그리고 Global Services라는 세 가지 주요 경계 수준을 제공합니다.

1. Zonal Services
   가용 영역(AZ) 내에서 동작하는 서비스입니다. Amazon RDS, Amazon EC2, Amazon EBS와 같은 서비스는 가용 영역별로 격리되어 동작하며, 데이터 평면(Data Plane)이 Zonal로 설계됩니다. 즉, 특정 가용 영역에서 장애가 발생하더라도 다른 가용 영역은 영향을 받지 않습니다.
   
   
2. Regional Services
   여러 가용 영역(AZ)을 포함한 지역 단위로 설계된 서비스입니다. Amazon S3, Amazon SQS, Amazon DynamoDB는 데이터 평면과 제어 평면 모두 Regional 단위로 동작하여, 가용 영역 하나에 문제가 생기더라도 데이터를 유지할 수 있는 강력한 복원력을 제공합니다.
   
   
3. Global Services
   전 세계적으로 동작하는 서비스로, AWS CloudFront, Amazon Route 53, AWS Global Accelerator 등이 포함됩니다. 이러한 서비스는 데이터 평면이 글로벌 단위로 설계되어, 단일 지역이나 가용 영역의 장애로부터 영향을 받지 않도록 설계되었습니다.

셀룰러 아키텍처(Cellular Architecture)는 애플리케이션의 확장성과 복원력을 높이기 위해 각 서비스를 독립적인 단위, 즉 “셀(Cell)”로 나누는 디자인 패턴입니다. 이 설계 방식은 대규모 애플리케이션에서 장애의 영향을 최소화하고, 관리 효율성을 극대화하는 데 중점을 둡니다.

셀룰러 아키텍처의 핵심 특징:

1. 독립적인 서비스 인스턴스
   각 셀은 서비스의 독립적인 인스턴스로 동작합니다. 즉, 셀 간에는 종속성이 없으므로 하나의 셀이 실패하더라도 다른 셀에는 영향을 미치지 않습니다.
   
   
2. 데이터 분할 및 고객 할당
   각 셀은 특정 데이터와 고객의 일부를 전담합니다. 예를 들어, 고객의 지리적 위치나 서비스 사용량에 따라 셀이 나뉘어 배치될 수 있습니다.
   
   
3. 완전한 업무 처리
   각 셀은 할당된 고객의 모든 워크로드를 독립적으로 처리합니다. 셀은 자체적인 컴퓨팅 리소스와 스토리지를 사용하여 전체 애플리케이션을 지원합니다.
   
   
4. 데이터 공유 없음
   셀 간에는 데이터베이스나 저장소 등의 자원을 공유하지 않습니다. 이로 인해 셀 내부 장애가 다른 셀로 확산되는 것을 방지할 수 있습니다.

셀룰러 아키텍처는 클라우드 네이티브 환경에서 특히 유용하며, 대규모 사용자 기반을 지원하는 애플리케이션에서 안정성을 크게 향상시킵니다. 예를 들어, 특정 지역의 트래픽 급증으로 인해 하나의 셀이 과부하 상태가 되어도 다른 셀은 정상적으로 운영될 수 있습니다. 또한, 개별 셀에서 장애 복구를 수행하거나 업그레이드를 진행하는 동안에도 전체 시스템의 가용성을 유지할 수 있습니다.

이러한 구조는 AWS에서 제공하는 Application Load Balancer(ALB) 및 컴퓨팅, 스토리지 리소스와 잘 맞아떨어지며, 클라우드 기반 서비스의 핵심 설계 패턴으로 자리 잡고 있습니다.

실패 격리(Fault Isolation)는 시스템 설계에서 가장 중요한 원칙 중 하나로, 장애 발생 시 전체 애플리케이션의 영향을 최소화하는 데 중점을 둡니다. 특히 실패의 영향을 제한하려면 각 서비스와 애플리케이션이 장애에 어떻게 대응할지를 미리 계획해야 하며, 물리적 경계와 논리적 경계를 결합한 설계가 필수적입니다. 물리적 경계란 가용 영역(AZ)이나 리전(Region) 단위의 장애 대응 방식을 의미하며, 논리적 경계는 셀룰러 아키텍처가 마이크로서비스 구조를 통해 애플리케이션의 특정 부분을 독립적으로 관리할 수 있도록 설계해야 합니다.

관측 가능성 강화 (Enhancing Observability)

관측 가능성(Observability)은 시스템의 상태를 실시간으로 모니터링하고 장애를 신속하게 감지하며 해결하기 위한 중요한 도구입니다.

모니터링의 순환을 위해서 더 나은 운영으로 이루어지기 위해서는 그림과 같은 순환구조의 사이클 구성이 필요합니다.

• 도구 설정 (Instrumentation)
  먼저, 애플리케이션이나 서비스의 주요 지점에 모니터링 도구를 설치합니다. 이를 통해 데이터가 수집되며, 서비스의 성능과 상태를 실시간으로 추적할 수 있습니다.
  
  
• 로그, 메트릭, 추적 (Logs, Metrics, Traces)
  설정된 도구를 통해 수집된 데이터는 로그, 메트릭, 트레이스 형태로 저장됩니다. 이는 장애의 근본 원인을 분석하거나, 애플리케이션의 전반적인 상태를 이해하는 데 중요한 역할을 합니다.
  
  
• 알람과 대시보드 (Alarms and Dashboards)
  데이터를 실시간으로 활용하기 위해 알람과 대시보드를 설정합니다. 이는 문제가 발생했을 때 즉각적인 알림을 제공하고, 대시보드를 통해 전반적인 시스템 상태를 시각적으로 확인할 수 있습니다.
  
  
• 질문과 개선 (Questions and Improvements)
  마지막 단계에서는 관찰된 데이터를 기반으로 “왜 이런 문제가 발생했는가?”, “어떻게 개선할 수 있을까?”라는 질문을 던집니다. 이를 통해 얻은 통찰은 다시 모니터링 도구와 프로세스를 조정하며, 운영 효율성을 지속적으로 높입니다.

이러한 사이클은 단발적인 개선이 아니라, 반복적인 프로세스를 통해 시스템 운영을 점진적으로 향상시킵니다.

AWS는 관측 가능성을 강화하기 위해 점검 과정을 조직적으로 운영합니다. 운영상태를 끊임없이 리뷰하여 지속적으로 점검이 가능하도록 해야 합니다.

• 팀 리뷰 (Weekly Team Metrics Review)
  각 팀은 주간 단위로 주요 메트릭을 검토하며, 발생 가능한 문제를 사전에 파악합니다. 이는 작은 수준의 오류도 놓치지 않고 개선할 수 있는 기회를 제공합니다.
  
  
• 조직 리뷰 (Weekly Org Review)
  팀 단위에서 수집된 데이터를 조직 차원에서 다시 검토합니다. 이는 팀 간 협력을 통해 더 큰 관점에서 문제를 해결하고, 서비스 전반의 안정성을 강화합니다.
  
  
• AWS 운영 리뷰 (Weekly AWS Ops Metrics Review)
  마지막으로, AWS의 전체 운영 메트릭을 검토하는 회의를 통해 글로벌 수준에서의 운영 개선점을 논의합니다. 이는 AWS가 서비스 전반의 안정성과 신뢰성을 지속적으로 유지할 수 있는 핵심 프로세스입니다.

관측 가능성은 장애를 조사하고 복구하는 데 필요한 세부 정보를 제공하며, 시스템의 복원력을 결정짓는 핵심 요소입니다. AWS에서는 메트릭과 경계 설계가 잘 연계되도록 설정하며, 주기적인 리뷰와 점검을 통해 운영 효율성을 지속적으로 개선합니다. 이러한 접근 방식은 단순히 문제가 발생했을 때 해결하는 것을 넘어, 사전에 문제를 감지하고 예방할 수 있는 시스템을 구축하는 데 초점이 맞춰져 있습니다.

효과적인 복구 전략 (Effective Recovery Strategies)

복구전략은 장애가 발생했을 때, 시스템을 빠르고 안정적으로 정상 상태로 되돌리기 위한 요소입니다. 이를 위해서 복구 작업은 별도의 절차로 관리해야 하는 것이 아니라, 기존 배포 프로세스와 자연스럽게 융합될 수 있도록 설계해야 합니다.

이를 위해  AWS에서는 복구 계획이 배포 과정과 긴밀히 연결될 수 있도록 다음과 같은 원칙을 제시합니다:

• 복구와 배포 경계 정렬
  복구 작업은 배포 파이프라인의 각 단계와 동일한 경계를 따릅니다. 예를 들어, 배포 파이프라인이 가용 영역 단위로 이루어진다면, 복구 계획 역시 같은 단위를 기준으로 설계합니다. 이렇게 하면 복구 과정에서 중복 작업을 줄이고 효율성을 극대화할 수 있습니다.
  
  
• 배포 도구의 재활용
  배포에 사용되는 코드는 복구 작업에도 동일하게 사용될 수 있어야 합니다. 이를 통해 복구 프로세스를 단순화하고, 새로운 도구나 절차를 학습하는 부담을 줄일 수 있습니다.
  
  
• 복구 작업을 배포처럼 느끼게 설계
  복구는 배포와 마찬가지로 익숙한 절차와 도구를 활용해 실행되어야 합니다. 이렇게 하면 장애 상황에서도 팀이 혼란 없이 복구 작업에 즉각적으로 대응할 수 있습니다.

이미지에서 지휘자가 악단을 조화롭게 이끄는 모습은 바로 이런 복구와 배포의 조화를 상징합니다. 배포와 복구가 하나의 통일된 작업으로 진행될 때 시스템은 더욱 유연하고 안정적으로 작동할 수 있습니다.

복구를 더욱 효과적으로 만들기 위해 AWS가 제안한 몇 가지 전략은 다음과 같습니다:

• 정적 안정성 (Static Stability)
  장애가 발생했을 때, 시스템이 새로운 작업을 필요로 하지 않고도 안정적으로 유지되도록 미리 준비해야 합니다. 예를 들어, 미리 프로비저닝된 리소스를 사용하면, 장애 시 즉각적인 복구가 가능합니다.
  
  
• 스마트 리트라이 (Smart Retry)
  단순한 리트라이 로직은 장애를 더욱 악화시킬 수 있습니다. 이를 방지하기 위해 AWS는 지수적 백오프(Exponential Backoff)와 지터(Jitter)를 활용할 것을 권장합니다. 이 방법은 리트라이 요청 간 간격을 늘려 과도한 부하를 방지합니다.
  
  
• 트래픽 우회 (Routing Around)
  장애가 발생한 영역을 빠르게 감지하고 트래픽을 우회하는 것이 가장 빠른 복구 방법 중 하나입니다. 이를 통해 정상적으로 작동하는 시스템 부분이 최대한 활용될 수 있습니다.
  
  
• 배포와 복구의 일관성
  복구 작업은 배포와 동일한 절차와 도구를 사용해 수행되어야 합니다. 이를 통해 복구 계획 실행이 자연스럽고 효율적으로 이루어질 수 있습니다.

AWS는 복구 전략의 효과를 미리 검증하고 최적화하기 위한 도구로 AWS Fault Injection Simulator(FIS)를 제공합니다. 이는 다양한 장애 상황을 인위적으로 생성해 복구 전략을 테스트하고 개선할 수 있는 강력한 도구입니다.

AWS FIS를 통해 사전의 여러 장애시나리오를 작성하고 이를 직접 테스트하여, 실제 장애환경에서 어떠한 문제점이 나타나는지 확인할 수 있으며, 이를 통한 복구 시나리오 및 개선 방안을 도출할 수 있습니다.

결론

이번 세션은 단순한 이론적 설명에 그치지 않고, 실질적인 도구와 사례를 통해 클라우드 애플리케이션의 탄력성을 어떻게 설계하고 강화할 수 있는지 명확한 방향을 제시했습니다. 앞으로 클라우드 환경에서 더욱 안정적이고 신뢰할 수 있는 시스템을 구축하기 위해, 이번 세션에서 배운 원칙과 전략을 적극적으로 활용하고 싶습니다. 이러한 노력을 통해 사용자의 신뢰를 얻고, 예기치 않은 상황에서도 서비스 품질을 유지할 수 있는 역량을 갖추는 데 한 걸음 더 나아갈 것입니다.