실전을 견디는 Azure 설계 — MVP Mike Martin과 함께

Azure 아키텍처는 모든 것이 정상적으로 작동할 때는 쉬워 보입니다.진짜 시험은 의존성이 실패하고, 리전이 사용 불가 상태가 되고, 트래픽이 급증하고, 가정이 틀린 것으로 드러나고, 요구사항이 바뀌고, 결국 누군가 불편한 질문을 던질 때 시작됩니다. "우리는 애초에 왜 이렇게 설계했는가?"이번 M365.FM 에피소드에서 Mirko Peters는 Mike Martin [MVP]과 함께 다이어그램에서 보기 좋은 수준을 넘어, 실제 운영 환경의 조건을 견뎌야 할 때 Azure 아키텍처가 어떤 모습이어야 하는지 이야기합니다.Mike는 개발, 인프라, 아키텍처, 리더십, 코칭, 교육, 그리고 Microsoft Azure 분야에서 수십 년의 경험을 가지고 있습니다. 그의 가장 중요한 통찰 중 하나는 오늘날 아키텍트가 마주하는 많은 문제가 사실 새로운 것이 아니라는 점입니다. DNS는 여전히 문제를 일으키고, IP 의존성은 여전히 중요하며, 비용은 여전히 골칫거리이고, 통합은 여전히 실패하며, 의존성은 가장 나쁜 순간에 사라집니다.달라진 것은 이러한 문제 주변에 쌓아 올리는 복잡성의 수준입니다.

비주얼 베이직에서 현대 Azure 아키텍처까지
Mike는 거의 30년에 걸친 IT 경력을 돌아봅니다. 1990년대 Visual Basic 개발자로 시작해 분산 시스템, 네트워킹, 엔터프라이즈 소프트웨어, 인프라를 거쳐 결국 Azure에 이르렀습니다.그의 핵심 관찰은 단순합니다. 업계는 여전히 많은 근본적인 문제를 해결하고 있지만, 그 문제를 둘러싼 아키텍처는 훨씬 더 복잡해졌다는 것입니다.현대 시스템은 클라이언트-서버 애플리케이션에서 분산 아키텍처, 클라우드 플랫폼, 컨테이너, 마이크로서비스, Kubernetes, 하이브리드 환경, 그리고 이제는 AI 지원 개발로 이동했습니다.이는 엄청난 가능성을 만들어내지만, 동시에 새로운 위험도 만듭니다. 바로 과잉 설계입니다.Mike는 오늘날 많은 팀이 단순한 문제를 불필요하게 복잡하게 만든다고 주장합니다. 좋은 아키텍처는 종종 더 많은 기술을 추가하는 것이 아니라, 무엇을 추가하지 않아야 하는지를 아는 것에 가깝습니다.

Azure 아키텍트는 실제로 무엇을 하는가?
Mike에게 아키텍처란 가장 많은 Azure 서비스를 고르거나 인상적인 다이어그램을 만드는 것이 아닙니다.어떤 구성 요소가 함께 가야 하는지, 어떤 것을 피해야 하는지, 어떤 것이 필요한지, 그리고 유지보수가 가능하고, 확장 가능하며, 안전하고, 회복력 있는 시스템을 어떻게 구축할지 이해하는 것입니다.아키텍처에는 컴퓨팅보다 훨씬 많은 것이 포함됩니다.

• ID
• 네트워킹
• 데이터 흐름
• 보안
• 모니터링
• 통합
• 의존성
• 확장성
• 운영
• 복구
• 배포
• 비용

Mike는 또한 클라우드 네이티브가 자동으로 Kubernetes나 컨테이너를 의미한다는 생각에도 도전합니다. Azure는 불필요한 운영 부담을 도입하지 않고도 문제를 해결할 수 있는 관리형 및 네이티브 서비스를 많이 제공합니다.아키텍트의 역할은 전체 솔루션을 이해하고, 실제 요구사항을 여전히 충족하면서도 가장 단순한 아키텍처를 선택하는 것입니다.

Azure 서비스가 아니라 비즈니스 요구사항에서 시작하라
이 에피소드에서 가장 중요한 교훈 중 하나는 단순합니다. 기술에서 시작하지 말라는 것입니다.Azure Kubernetes Service, App Service, Azure Functions, 컨테이너, Service Bus 또는 다른 플랫폼 중 무엇을 선택하기 전에, 팀은 먼저 솔루션이 실제로 무엇을 해야 하는지 이해해야 합니다.던져야 할 질문:

• 내부용인가, 고객용인가?
• 얼마나 많은 사용자가 의존하게 되는가?
• 전 세계적으로 확장되어야 하는가?
• 얼마나 오랫동안 사용할 수 없어도 되는가?
• 비즈니스가 감당할 수 있는 데이터 손실은 얼마인가?
• 어떤 규정 준수 요구사항이 적용되는가?
• 애플리케이션이 몇 시간 동안 사라지면 어떻게 되는가?
• 누가 영향을 받는가?
• 필요한 운영 지원 수준은 어느 정도인가?

이 질문들은 SLA, SLO, RTO, RPO와 같은 개념으로 직접 이어집니다.또한 아키텍처가 단일 리전, 다중 리전, 액티브-액티브, 액티브-패시브 중 무엇이어야 하는지, 혹은 훨씬 더 단순해야 하는지를 결정합니다.

전문 용어 없이 이해하는 RTO와 RPO
RTO와 RPO는 종종 기술적인 약어로 논의되지만, 그 실제 의미는 비즈니스 지향적입니다.

• RTO — 복구 시간 목표: 장애 후 시스템은 얼마나 빨리 복구되어야 하는가?
• RPO — 복구 시점 목표: 허용 가능한 데이터 손실은 얼마인가?

중요하지 않은 모니터링에 사용되는 시스템은 몇 시간의 다운타임이나 데이터 손실을 견딜 수 있습니다.반면 일선 대응 인력, 금융 운영, 상거래, 또는 중요 인프라를 지원하는 시스템은 몇 분 안에 복구되어야 할 수 있습니다.중요한 점은 이 숫자들을 아키텍트가 임의로 만들어서는 안 된다는 것입니다.실제 장애의 비즈니스 영향에서 도출되어야 합니다.이러한 요구사항이 이해되면, 기술적인 설계 결정으로 변환될 수 있습니다.

회복력은 고가용성과 같지 않다
Mike는 가용성과 회복력의 차이를 설명하기 위해 간단한 비유를 사용합니다.고가용성 시스템은 기본 구성 요소가 실패할 때 인수할 준비가 된 다른 구성 요소를 가질 수 있습니다.회복력 있는 시스템은 문제를 흡수하고, 계속 기능하며, 완전히 무너지지 않고 우아하게 복구되어 정상 상태로 돌아오도록 설계됩니다.이 차이는 중요합니다.애플리케이션은 기술적으로는 사용 가능하면서도 나쁜 사용자 경험을 제공할 수 있습니다.다음과 같을 수 있습니다.

• 느림
• 스로틀링
• 부분적으로 사용 불가
• 실패 중인 백엔드에 의존
• 통합 문제의 영향을 받음
• 리전 차원의 압박을 받음

따라서 진정한 회복력은 가동 시간 이상을 요구합니다.부하, 애플리케이션 오류, 부분적 장애, 리전 문제, 깨진 의존성, 운영 사고를 견딜 수 있는 아키텍처가 필요하며, 사고가 지나간 후에도 복구가 가능해야 합니다.

Azure가 애플리케이션을 자동으로 회복력 있게 만들어 주지는 않는다
위험한 가정 중 하나는, Azure 자체가 고가용성이므로 Azure에서 실행되는 모든 애플리케이션이 자동으로 그 회복력을 물려받는다고 생각하는 것입니다.그렇지 않습니다.Microsoft는 회복력 있는 아키텍처를 가능하게 하는 서비스와 기능을 제공합니다.하지만 회복력을 설계하는 것은 여전히 고객의 몫입니다.여기서 아키텍처 패턴이 중요해집니다.

• 서킷 브레이커
• 느슨한 결합
• 비동기 처리
• 독립적인 확장
• 다중 가용성 영역
• 다중 리전
• 장애 조치 메커니즘
• 모니터링
• Infrastructure as Code
• 검증된 복구 절차

Microsoft는 구성 요소를 제공합니다.실제로 회복력 있는 시스템을 만드는 것은 아키텍처가 그 구성 요소들을 어떻게 조합하느냐에 달려 있습니다.

비동기 설계가 중요한 이유
이 토론에서 가장 강력한 사례 중 하나는 세금 신고 포털처럼 예측 가능한 트래픽 급증을 경험하는 시스템에서 나옵니다.흔한 설계 문제는 모든 동작이 동기식 백엔드 작업에 의존하는 경우입니다.사용자가 버튼을 클릭합니다.프론트엔드는 백엔드를 기다립니다.백엔드는 다른 서비스를 기다립니다.다른 의존성이 느려지고, 결국 전체 사용자 경험이 영향을 받습니다.Mike는 느슨하게 결합된 시스템이 종종 더 회복력이 있는 이유를 설명합니다.모든 백엔드 작업을 프론트엔드가 기다리도록 강제하는 대신, 애플리케이션은 작업을 큐나 이벤트 기반 시스템에 넣고 구성 요소들이 작업을 독립적으로 처리하도록 할 수 있습니다.이는 몇 가지 장점을 만듭니다.

• 서로 다른 구성 요소를 독립적으로 확장할 수 있음
• 하나의 서비스가 실패해도 전체 플랫폼이 무너지지 않음
• 백엔드가 작업을 비동기적으로 처리할 수 있음
• 트래픽 급증을 더 쉽게 흡수할 수 있음
• 사용자 대면 구성 요소가 백엔드 타이밍에 덜 의존하게 됨
• 장애를 더 쉽게 격리할 수 있음

100% 가동 시간이라는 신화
토론의 또 다른 주요 주제는 100% 가용성에 대한 집착입니다.Mike는 분명히 말합니다. 100% 가동 시간은 현실적인 아키텍처 목표가 아닙니다.솔루션은 보통 여러 서비스로 구성됩니다.각 서비스는 자체 SLA를 가집니다.여러 의존성을 결합하면…