세션명
Building a practice to optimize your customer’s resilience journey
(고객의 회복탄력성 여정을 최적화하기 위한 관행 구축)
강연자
- Diego Dalmolin – Principal Solutions Architect, Steph Rowan – Sr. Practice Lead
핵심 내용 요약
- Diego의 AWS Resilence 세션은 내구성에 중점을 둔 AWS의 접근 방식을 소개하며,
세션에서는 내구성의 중요성, AWS Resilience Lifecycle Framework, 다양한 내구성 서비스에 대한 설명이 포함됨 - AWS Resilience Lifecycle Framework라는 5가지 단계로 구성된 내구성 강화 프레임워크 소개
- AWS에서 제공하는 내구성을 정의하는 서비스인 AWS Resilience Hub와 Amazon Disaster Recovery Service(DRS)는
RP OS 및 RT OS를 정의하고 응용 프로그램 내구성을 평가하는 데 도움을 주며 가상 머신을 보호하고 클라우드에서 복구할 수 있도록 지원
세션 키워드
- AWS 가 이야기하는 내구성을 강화하는 방법
- AWS Resilience Lifecycle Framework
- AWS Resilience Hub
- Amazon Disaster Recovery
세션 요약자
베스핀글로벌 MSP본부 SRE실 공진수 님
서론
수석 솔루션 설계자 Diego Dalmonlin과 선임 실무 책임자 Steph Rowan은 AWS 파트너 조직에서 파트너가 고객 워크로드에 대한 내구성을 지원하는 제품을 구축하는 데 중점을 두는 일을 하고 있습니다. 이번 세션에서는 AWS에서 내구성을 어떻게 정의하고, 어떻게 고객과 파트너와 이 내구성에 대하여 어떻게 이야기할 것인지, 이에 따라 파트너들이 내구성을 둘러싼 고객의 요구를 어떻게 해결할 수 있을지에 대한 도움을 줄 것입니다.
본론
AWS에서 얘기하는 내구성은 클라우드의 내구성을 의미하며 서비스 및 글로벌 인프라, 가용영역의 내구성에 적용하고 있습니다.
그리고 고객 또는 파트너의 경우 클라우드 내의 내구성에 대하여 책임을 지고 있습니다.
AWS에서 제시하는 탄력성 공동 책임 모델(상단 그림)은 하드웨어, 서비스, 글로벌 인프라 측면에서의 책임을 AWS가 지고, 클라우드 내의 내구성에 대한 책임은 고객이나 파트너에게 있음을 강조합니다. 고객이 내구성에 대한 중요한 부분에서 책임을 지게 되는데, 이 모델에서 고객 측면의 책임이 상당히 중요하다는 것이 Diego가 다운타임으로 인한 부정적 영향을 예시로 들며 강조한 내용입니다.
다운타임은 예정된 업무 수행 뿐만 아니라 비용 측면에서 큰 영향을 미치며, 브랜드 평판, 생산성 저하, 규정 위반 등 여러 부정적인 영향을 미칠 수 있다는 점을 강조했습니다. 이러한 리스크는 애플리케이션 도입이 증가함에 따라 계속해서 증가하고 있어 고객이 파트너의 도움을 필요로 하는 상황이 발생하고 있습니다. 파트너들은 고객 기대치를 충족하기 위해 노력하지만, 원격 팀, 분산 시스템, 자주 발생하는 릴리스와 같은 트렌드로 인해 장애 위험이 증가하고 있습니다.
또한 DORA나 EU와 같은 규정이 부과되면서 IT 팀은 준수 유지에 대한 부담이 커지고 있습니다.
AWS는 이에 대응하여 내구성을 제공하는 서비스들을 보유하고 있지만, 이를 효과적으로 활용하고 서비스 간의 상호작용을 이해하는 것은 고객들에게 어려운 과제로 여겨집니다. 따라서 AWS는 이러한 어려움을 해결하고자 파트너들을 위한 내구성 실천 가이드를 개발하고 있습니다.
Diego는 내구성의 기초(기반, Foundation)를 파트너들이 도움을 주어 구현하는 것이 필요하다고 설명합니다. 여기에서 기초는 애플리케이션의 다운 리스크를 평가하고 이것이 전체 운영에 어떻게 영향을 미치는지를 디자인(Resilience design)하는 것을 의미합니다. 이런 기초를 마련한 후에는 환경의 복구 능력(Resilience recovery)을 설계해야 하며, 마지막으로 운영 측면에서도 장애 감지, 대응 및 정상 운영으로의 복구 시간을 고려하는 탄력성 운영(Resilience operation)을 해야 합니다.
Diego는 이러한 네가지 요소에 대해 더 자세히 설명하도록 했습니다.
1. Resilience foundation
Diego는 기초 단계에서 평가, 관측 가능성 DevOps를 다루게 됩니다.
평가 단계에서는 고객에게 HA가 true 또는 false 인지 묻는 대신 비즈니스의 영향과 리스크를 평가합니다. 이를 통해 고객이 데이터를 얼마나 잃을 수 있는지(RPO), 시스템을 얼마나 빨리 복구하고 싶은지(RTO)를 이해할 수 있습니다. 또한 각 시나리오에서 발생할 수 있는 리스크를 평가하고 분석하여 시스템이 어떻게 작동할지를 이해하는 것이 중요합니다. 이 과정은 일회성이 아니라 시스템이 발전하고 새로운 기능이 추가될 때마다 주기적으로 수행해야 합니다. 이를 통해 시스템이 진화함에 따라 발생 가능한 새로운 리스크를 신속하게 대응할 수 있습니다.
다운타임 없이 시스템의 가용성을 결정하는 핵심은 적절한 관측 가능성과 모니터링입니다. 비즈니스 메트릭스와 지표를 활용하여 업타임, 서비스 수준, 사용자 경험 등을 모니터링하는 것이 중요하며, 이를 통해 오류 예산을 얻고 사용자 관점에서 시스템의 가용성을 확인할 수 있습니다. 또한, 인프라 및 애플리케이션 동작뿐만 아니라 사용자 경험을 모니터링하는 데 CloudWatch, RUM, CloudWatch Synthetics Canary와 같은 도구를 활용하는 것이 핵심입니다.
이 기본 사항의 마지막 주제는 DevOps입니다. DevOps를 내구성에 필요한 가드 레일로 활용할 수 있다고 강조하며, 코드를 통한 모든 변경사항, Canary 배포, 파이프라인 테스트 등을 통해 DevOps를 효과적으로 활용하는 방법을 설명합니다. 특히 Canary 배포를 통해 새로운 버전을 점진적으로 배포하고 시스템의 행동을 모니터링하여 사용자에게 최소한의 영향을 미치도록 하는 방법을 소개하고, 모든 테스트를 파이프라인에서 수행하여 프로덕션에 배포되기 전에 문제를 사전에 감지할 수 있도록 하는 중요성을 강조합니다.
2. Resilience design
이 부분에서는 AWS 스태프가 마이그레이션 파트너들에게 현대화를 권장하며 특히 마이크로서비스 아키텍처에 투자할 것을 강조합니다.
마이크로 서비스 접근 방식을 사용하여 응용 프로그램에서 최대한 분리하도록 노력하라고 강조하며, 이는 컨테이너가 실패해도 대체할 수 있고 고가용성을 유지하는 데 도움이 되며, 응용 프로그램에 처리 대기열을 사용하고 특정 작업을 나중에 다시 시도할 수 있도록 하는 등 여러 가지 측면에서 이점이 있음을 설명합니다. 또한, 모던화하는 동안 Amazon S3, Dynamo DB와 같은 지역 기반 서비스를 사용하도록 권장하며, 이러한 서비스는 이미 지역 전체에서 사용되고 액세스되기 때문에 가용성 영향을 줄일 수 있다고 강조합니다.
고객과의 토론 중에 자주 나오는 주제 중 하나는 멀티 리전, 멀티 AZ 또는 때로는 멀티 클라우드로 이동해야 하는지 여부입니다. 적절한 평가를 수행한 후 대부분의 고객이 싱글 리전, 멀티 AZ을 사용하여 RP OS 및 RT OS를 달성할 수 있다고 말합니다. 특히 시스템 다운 타임에 민감한 고객에게 멀티 리전 전략이 필요할 수 있지만, 먼저 싱글 리전에서 필요한 내구성 수준을 달성할 수 있는지 확인하라고 강조합니다.
이 부분에서는 고가용성을 강조하면서, 소프트웨어 개발 생명주기에서의 몇 가지 구성 요소에 집중합니다. 서비스 클라이언트에서의 재시도, 백엔드에서의 재시도 구현에 대한 대화, 쓰로틀링과 같은 백엔드에서의 제한 구현, 그리고 회로 차단기(Circuit breakers)를 활용한 서비스 간 영향 최소화 등이 강조되었습니다. 이는 사용자에게 투명한 방식으로 시스템 내 구성 요소 간의 강건함을 확보하는데 중점이 있습니다.
3. Resilience recovery
이제는 재해 복구 측면에 대해 설명합니다. 고가용성과 재해 복구는 모니터링, 여러 위치에 배포, 고가용성이 실패할 경우 자동 장애 극복 등과 같이 유사한 또는 동일한 모범 사례를 기반으로 합니다. 고가용성에서는 구성 요소의 장애에 대응하는 반면, 재해 복구에서는 전체적인 재해 상황에 대비하여 다른 위치에서 환경을 복구해야 합니다.
이 섹션에서는 다양한 재해 복구 방법을 살펴보고 있습니다. 먼저 백업 및 복원 방법을 소개하며, 비용 효율적이지만 복원 시간이 길고 데이터 손실이 발생할 수 있다는 한계를 강조합니다. 다음으로 “Pilot Light” 방식을 언급하면서, 데이터를 다른 지역으로 복제하지만 해당 지역에는 실행 중인 서버가 없다고 설명합니다. 이 방법은 자동화된 스크립트를 사용하여 가동이 가능하며, 비용 효율적이지만 몇 시간이 걸릴 수 있습니다. 마지막으로 “Warm Standby” 방식을 소개하며, 일부 서버 또는 리소스가 가동 중인 상태이고 DNS 레코드를 전환하여 빠른 복원이 가능하다는 특징을 강조합니다. 이러한 방법 중 어떤 것을 선택할지는 RP OS와 RT OS를 강화하는 데 필요한 고객의 요구에 따라 다를 것입니다.
4. Resilience operations
탄력성 운영은 세 가지의 단계가 있습니다.
- 운영 준비 검토(Operational Readiness Reviews)는 내구성 운영의 첫 단계로, AWS 내부나 amazon.com에서 수행되는 작업 중 하나입니다. 이는 시스템이 프로덕션에 투입될 때 운영되는 방식, 참여 팀, 필요한 감시 및 경보 설정, 당직을 맡을 팀, 응용 프로그램의 중요성, 그리고 모니터링할 SLA 등을 정의하는 문서 및 프로세스입니다.
- 오류 수정(Correction of Error processes)은 이미 일부 사고 관리를 구현한 고객을 위한 단계로, 사고 발생 시 정확한 원인을 분석하고 그 교훈을 아키텍처나 운영에 대한 권장 사항으로 전환하여 해당 사고가 재발하지 않도록 보장합니다. 이는 책임전가가 없는 연습이며, 단순히 문제를 제거하는 것이 아니라 응용 프로그램의 가용성 수준을 향상시키기 위한 것입니다.
- 장애 시뮬레이션(Fault injection experimentations)은 모든 것이 원활하게 진행되고 사고가 없는 상황에서도 작동하는 방법을 확인하기 위한 과정입니다. 이를 위해 의도적으로 문제를 발생시키는 실험 또는 카오스 엔지니어링 게임 데이를 통해 시스템이 어떻게 반응하는지, 새 버전을 테스트하지 않은 채로 게시할 때 어떤 영향이 있는지 등을 확인합니다.
AWS Resilience Lifecycle Framework
제공된다고 언급하며 QR 코드를 통해 이를 참고할 수 있다고 안내합니다.
이 프레임워크는 내구성 학습과 모범 사례를 수집한 것으로, 여기서 배운 모든 것과 조화를 이룹니다.
첫 번째 단계는 목표를 설정하는 것입니다. 이는 기본적으로 고객이 원하는 RP OS, RT OS 및 SLA를 정확히 이해하는 것입니다. 그런 다음 이러한 고객의 수요와 관심사를 충족시키기 위해 고가용성 또는 재해 복구를 위한 설계를 시작합니다. 그 후에는 테스트를 시작합니다. 이 응용 프로그램이 정의된 기준을 충족시킬 수 있는지 확인해 보는 것입니다. 운영 중에는 사건이 발생할 수 있고 발생할 수 있으며, 사건을 처리하기 위해 운영팀을 투입하고 사건에서 얻은 교훈을 통해 운영이나 아키텍처를 개선하는 새로운 권장 사항을 생성합니다.
AWS에는 여러 관점에서 내구성을 정의하는 데 도움이 되는 다양한 서비스가 있습니다. AWS Resilience Hub는 RP OS 및 RT OS를 정의하고 응용 프로그램 내구성을 평가하여 정의된 수준을 충족할 수 있는지 확인합니다. 이 서비스는 시스템이 기준을 충족하지 못할 경우 아키텍처를 개선하는 권장 사항을 제공합니다. Resilience Hub은 또한 Amazon Systems Manager를 활용하여 표준 운영 절차, 빠른 복구를 위한 자동화, CloudWatch를 통한 모니터링 및 경보, Amazon Fis를 활용한 실험에 대한 권장 사항도 제공합니다. QR 코드 링크를 통해 파트너 전용으로 제공되는 내용 중 FIS를 활용한 평가 방법에 대한 안내서를 참고할 수 있습니다.
다음으로 소개되는 서비스는 Amazon Disaster Recovery Service(DRS)로, 가상 머신에 중점을 두고 있으며 가상 머신을 보호하고 클라우드에서 복구할 수 있도록 지원하는 서비스입니다. DRS를 통해 특정 시스템을 클라우드에서 빠르게 복구할 수 있게 해주는 것을 강조하며, AWS에서 AWS로의 복제 또한 가능하다고 소개합니다. 두 서비스에 대한 구체적인 가이드와 솔루션은 AWS 파트너에게 제공된다고 언급하며 QR 코드를 통해 이를 참고할 수 있다고 안내합니다.
결론
파트너가 내구성을 사업에 통합하면 고객 만족도가 향상되며, 안정적이고 빠른 서비스에 대한 고객 기대를 충족시킵니다. 내구성 강화된 애플리케이션은 시장에서 경쟁 우위를 가져오며, 신뢰성 있는 파트너로 인식될 수 있습니다. 또한, 내구성을 관리하는 경험이 있는 파트너는 시장에서 차별화되어 고객의 신뢰를 얻을 수 있고, 새로운 매출 기회를 창출할 수 있습니다. 이는 내구성이 비즈니스 성공에 긍정적인 영향을 미칠 수 있는 중요한 전략적 요소입니다.
Bespin’s Comment
이 세션에서는 AWS 파트너들이 고객 워크로드의 내구성을 강화하는 방법을 다루었습니다. AWS의 내구성 정의, 고객과의 소통 전략, 내구성에 대한 고객 요구를 해결하는 방법 등이 주요 주제로 다뤄졌습니다. 발표에서는 내구성의 기초, 디자인, 복구, 그리고 운영에 대한 강조가 이루어졌으며, AWS Resilience Hub 및 Disaster Recovery Service와 같은 서비스도 소개되었습니다. 파트너가 내구성을 사업에 통합하면 고객 만족도 향상과 시장에서의 경쟁 우위를 얻을 수 있음을 강조하며, 내구성 관리 경험이 있는 파트너는 새로운 매출 기회를 창출할 수 있습니다.
Written by 공 진수 / Jinsu Gong
Cloud Engineer
