실제 아키텍처에 WAF 패턴 적용

실제 아키텍처에 WAF 패턴을 적용하는 것은 이론적인 연습이 아닙니다. 각 설계 결정을 다섯 가지 핵심 요소에 따라 평가하고 정보에 근거한 상충 관계를 결정해야 합니다. 일반적인 시작점은 아키텍처 다이어그램입니다. 모든 구성 요소를 거쳐 사용자 요청이 이동하는 경로를 추적하면서 각 단계마다 해당 구성 요소가 실패하면 어떻게 되는지, 비용은 얼마인지, 어떻게 보호되는지를 질문합니다.

전통적인 모놀리식 웹 애플리케이션을 생각해 보겠습니다. 공용 IP 뒤에서 웹 서버와 데이터베이스를 함께 실행하는 단일 VM입니다. WAF 핵심 요소를 기준으로 평가하면 다음 다섯 가지 모두에서 낮은 점수를 받습니다. 중복성 없음(안정성), 웹 계층과 동일한 호스트에 데이터베이스 배치(보안), 트래픽과 관계없이 항상 실행되는 VM(비용), CI/CD 없음(운영 우수성), 수직 확장만 가능(성능 효율성)입니다.

안정성 핵심 요소를 충족하려면 웹 계층을 서로 다른 가용성 영역에 있는 여러 VM에 분산하고, 데이터베이스를 보조 지역에 지역 간 복제로 백업하며, 앞단에 Azure Load Balancer를 배치합니다. 이렇게 하면 단일 장애 지점이 제거되고 수동 개입 없이도 영역 또는 지역 장애가 발생해도 애플리케이션이 계속 작동할 수 있습니다.

보안 핵심 요소를 충족하려면 웹 계층과 데이터베이스를 서로 다른 서브넷에 분리하고, 웹 계층에서 데이터베이스 포트로 연결하는 것만 허용하는 NSG 규칙을 적용합니다. 데이터베이스 연결 문자열은 Azure Key Vault에 저장하고 웹 앱에서 관리 ID를 사용해 실행 시 가져오도록 합니다. 이렇게 하면 애플리케이션 코드와 구성 파일에 자격 증명을 하드코딩하지 않아도 됩니다.

비용 최적화를 위해 항상 실행되는 VM을 사용량이 적은 시간대에 축소되는 Virtual Machine Scale Set으로 교체합니다. 데이터베이스의 경우 적절한 DTU 계층을 사용하는 Azure SQL Database와 SQL Server가 설치된 전체 VM 중 어느 쪽의 비용이 더 낮은지 평가합니다. 12개월 전에 예측할 수 있는 기본 용량에는 Reserved Instances를 구매합니다.

버전 제어에 저장된 Bicep 또는 ARM 템플릿으로 전체 인프라를 정의하여 운영 우수성을 높입니다. Azure Pipelines 또는 GitHub Actions에서 인프라 변경과 애플리케이션 코드를 자동으로 배포하는 CI/CD 파이프라인을 구축합니다. 변경 사항이 프로덕션에 반영되기 전에 자동 스모크 테스트와 수동 승인이라는 배포 게이트를 추가합니다.

성능 효율성을 위해 데이터베이스 앞에 Azure Cache for Redis를 도입하여 자주 읽는 쿼리를 캐시하고 데이터베이스 부하를 줄입니다. 정적 자산(이미지, CSS, JavaScript)은 Azure CDN을 통해 배포하여 전 세계 사용자와 가까운 에지 노드에서 제공되도록 합니다. 변경할 때마다 애플리케이션의 부하 테스트를 수행하여 개선 효과를 측정할 수 있는지 확인합니다.

모든 아키텍처 변경에는 상충 관계가 따릅니다. 예를 들어 다중 영역 아키텍처로 전환하면 안정성은 향상되지만 비용이 증가합니다(영역 두 개 = VM 두 개). Redis 캐싱을 추가하면 성능은 향상되지만 운영 복잡성이 증가합니다(모니터링하고 유지 관리해야 할 서비스가 하나 더 생김). 좋은 아키텍처 문서는 이러한 상충 관계를 명시적으로 기록하여 향후 아키텍트가 의사 결정의 이유를 이해할 수 있도록 합니다.

한 번의 재설계로 완벽을 이루려 하지 마십시오. 이러한 방식은 비용이 많이 들고 위험하며 느립니다. 대신 반복적 개선 주기를 도입합니다. Well-Architected Review를 실행하고, 영향이 가장 큰 상위 세 가지 문제를 식별한 다음 수정하고, 개선 정도를 측정한 후 반복합니다. 이 방식은 아키텍처 개선을 애자일 제공 방식에 맞추고 각 스프린트에서 진행 상황을 이해관계자에게 보여 줍니다.

Microsoft는 Azure Architecture Center에서 일반적인 워크로드 패턴을 위한 참조 아키텍처를 제공합니다. 여기에는 웹 애플리케이션 아키텍처, AKS의 마이크로서비스, 데이터 분석 파이프라인 등이 포함됩니다. 각 참조 아키텍처는 이미 WAF 핵심 요소를 기준으로 평가되었으며, 해당 패턴에서 이루어진 상충 관계에 대한 설명도 포함합니다.

아키텍처 결정 기록(ADR)을 사용하여 중요한 아키텍처 선택, 선택 당시의 맥락, 검토한 대안 및 WAF 핵심 요소에 미치는 영향을 문서화합니다. 코드베이스와 함께 버전 제어에 저장된 ADR은 감사 가능한 이력을 만들어 새로운 팀원이 현재 아키텍처가 이러한 형태가 된 이유를 이해하도록 돕습니다.

이 lesson에서 다룬 Microsoft Azure Fundamentals (AZ-900) 개념을 얼마나 이해했는지 확인해 보십시오.

이 lesson에서는 다음을 배웠습니다. WAF 패턴은 각 아키텍처 결정을 다섯 가지 핵심 요소 모두에 비추어 평가하여 적용합니다. 개선은 영향이 가장 큰 문제부터 시작해 반복적으로 진행할 수 있습니다. 또한 향후 아키텍트가 의사 결정의 근거를 이해할 수 있도록 상충 관계를 문서화해야 합니다. 다음 lesson에서는 Azure SLA와 다중 서비스 아키텍처의 결합 SLA 계산 방법을 살펴봅니다.