Azure Well-Architected

좋은 아키텍처 설계의 기준

참고

Microsoft Azure Well-Architected 프레임워크 소개 - Learn

Azure Well-Architected 요소

일반 설계 원칙

• 아키텍처 발전 활성화: 고정적인 아키텍처는 없습니다. 새 서비스, 도구 및 기술을 사용할 수 있는 경우 이를 활용하여 아키텍처를 발전시킬 수 있습니다.
• 데이터를 사용하여 결정: 데이터를 수집하고 분석하여 아키텍처에 대한 결정을 내리는 데 사용합니다. 비용 데이터, 성능, 사용자 로드 등 데이터를 사용하면 사용자 환경에서 적절한 선택을 할 수 있습니다.
• 교육 및 활성화: 클라우드 기술은 빠르게 발전합니다. 적절한 결정을 내리고 비즈니스 문제를 해결하는 솔루션을 구축할 수 있도록 개발, 운영 및 비즈니스 팀을 교육하세요. 조직 내에서 구성, 결정 사항 및 모범 사례를 문서화하고 공유해야 합니다.
• 자동화: 수동 작업을 자동화하면 운영 비용이 줄어들고 수동 단계에서 발생하는 오류를 최소화할 수 있으며 여러 환경 간에 일관성을 가질 수 있습니다.

1. 비용 최적화

조직은 인프라를 소유하기로 결정한 경우 대차대조표에 자산으로 기록되는 장비를 구매합니다. 자본 투자가 이루어졌기 때문에 회계사는 이 트랜잭션을 자본 비용(CapEx)으로 분류합니다. 시간이 지나면서 자산의 제한된 유효 수명에 따라 자산이 감가 상각 또는 상각 처리됩니다.

반면에 클라우드 서비스는 소비 모델 때문에 OpEx(운영 비용)로 분류됩니다. 이 체계에서는 상각 처리할 자산이 없습니다. 대신 OpEx는 순이익, 과세 소득 및 대차대조표의 관련 비용에 직접적인 영향을 미칩니다.

최적화된 프로비전

가능하면 IaaS에서 PaaS 서비스로 전환하는 것이 좋습니다. PaaS 서비스는 일반적으로 IaaS보다 저렴하며 운영비 절감에도 효과가 있습니다.

클라우드 지출 효율성 최대화

효율성은 사용자 환경 내에서 불필요한 지출을 구분하고 제거하는 데 중점을 두고 있습니다. 클라우드는 종량제 서비스이며, 일반적으로 요구량보다 더 많은 용량을 프로비전하는 경우 발생하는 비용은 방지할 수 있습니다. 또한 운영 비용은 불필요하거나 비효율적인 비용의 원인이 될 수 있습니다. 이러한 불필요한 운영 비용은 시간 낭비와 오류 증가로 표시됩니다. 아키텍처를 설계할 때 사용자 환경에서 낭비를 구분하고 제거하세요.

2. 운영 우수성

개발자의 민첩성을 향상하고 애플리케이션의 상태 및 성능에 대한 가시성을 개선하는 등, 클라우드를 사용하여 조직의 운영적 기능을 개선할 수 있습니다.

DevOps 및 연속 통합을 염두에 두고 최신 아키텍처를 설계해야 합니다. 최신 아키텍처는 필요에 따라 인프라를 코드로 사용하여 배포를 자동화하고, 애플리케이션 테스트를 자동화하며, 새 환경을 빌드하는 기능을 제공합니다. DevOps는 기술적이며 동시에 문화적이기 때문에 수용하는 조직에 많은 이점을 제공할 수 있습니다.

조직 내 사일로를 없애는 것이 DevOps 전반의 일반적인 스레드입니다. 변경 관리를 포함해 프로젝트의 모든 단계에서 공동 작업을 수행하는 것도 마찬가지입니다. 공유하며 협력하는 투명한 문화를 조성하면 조직에 운영 우수성을 불러올 수 있습니다.

모니터링 및 분석 기능을 사용하여 작업 인사이트 얻기

아키텍처 전체에 걸쳐 철저한 모니터링, 로깅 및 계측 시스템이 있어야 합니다. 아키텍처에서 진행 중인 작업을 모니터링하기 위한 효과적인 시스템을 만들면 사용자에게 영향을 미치기 전에 적절하지 않은 요소를 미리 파악할 수 있습니다. 모니터링에 대한 포괄적인 접근 방법을 사용하면 성능 문제를 구분하고, 비효율성을 없애고, 이벤트를 상호 연결하고, 문제를 해결하는 탁월한 기능을 얻을 수 있습니다.

운영 측면에서 강력한 모니터링 전략을 마련해야 합니다. 그러면 낭비의 영역을 식별하고, 문제를 해결하고, 애플리케이션의 성능을 최적화할 수 있습니다. 다단계 접근 방식은 필수입니다. 모든 계층의 구성 요소에서 데이터 요소를 수집하면 허용 가능한 범위를 벗어난 값에 대해 경고하고, 시간에 따른 지출을 추적할 수 있습니다.

자동화를 사용하여 번거로움과 오류 줄이기

최대한 많은 아키텍처를 자동화해야 합니다. 인적 요소는 운영 활동에 시간과 오류를 투자하는 등 비용이 많이 듭니다. 이로 인해 시간이 늘어나고 오류가 발생하여 운영 비용이 증가합니다. 리소스의 빌드, 배포 및 관리를 자동화할 수 있습니다. 일반적인 작업을 자동화하여 사람의 개입에 따른 대기 지연을 제거할 수 있습니다.

테스트

애플리케이션 배포 및 진행 중인 작업에 테스트를 포함해야 합니다. 적절한 테스트 전략은 애플리케이션을 배포하기 전에 문제를 파악하고 종속 서비스가 애플리케이션과 제대로 통신할 수 있는지 확인하는 데 도움이 됩니다.
- 기능 테스트: 개발 프로세스 초기에
- 보안 테스트: 개발 및 프로덕션 환경에서 애플리케이션 코드에 대한 정기 보안 테스트

3. 성능 효율성

성능 효율성이란 애플리케이션이 수신하는 요구와 애플리케이션에 사용할 수 있는 리소스를 일치시키는 것을 말합니다. 성능 효율성에는 리소스 크기 조정, 잠재적인 병목 상태 구분 및 최적화, 최고 성능에 대한 애플리케이션 코드 최적화가 포함됩니다.

강화(Scale Up), 확장(Scale Out)

자동 크기 조정은 성능 요구 사항에 맞게 리소스를 동적으로 할당하는 프로세스입니다. 작업 용량이 증가하면 원하는 성능 수준을 유지하고 SLA(서비스 수준 계약)를 충족하기 위해 애플리케이션에 추가 리소스가 필요할 수 있습니다. 수요가 감소하고 추가 리소스가 더 이상 필요하지 않으면 비용을 최소화하기 위해 할당을 취소할 수 있습니다.

네트워크 성능 최적화

서비스 간에 메시징 계층을 추가하면 성능 및 확장성에 이점이 될 수 있습니다. 메시징 계층을 추가하면 버퍼가 생성되므로 수신 애플리케이션이 요청을 감당할 수 없는 경우에도 요청은 오류 없이 계속해서 유입됩니다. 애플리케이션은 요청을 통해 작동하므로 수신된 순서에 따라 요청에 응답할 수 있습니다.

스토리지 성능 최적화

아키텍처에서 캐싱을 사용하면 성능을 향상할 수 있습니다. 캐싱은 빠른 검색을 위해 자주 사용되는 데이터 또는 자산(웹 페이지, 이미지)을 저장하는 메커니즘입니다. 애플리케이션의 다른 계층에 캐싱을 사용할 수 있습니다. 애플리케이션 서버 및 데이터베이스 간에 캐싱을 사용하여 데이터 검색 시간을 줄일 수 있습니다.

애플리케이션에서 성능 병목 상태 식별

성능 최적화에는 애플리케이션 자체가 작동하는 방법을 이해하는 것도 포함됩니다. 오류, 잘못 수행된 코드 및 종속 시스템의 병목 현상은 애플리케이션 성능 관리 도구를 통해 모두 파악할 수 있습니다. 사용자, 개발자 및 관리자에게는 이러한 문제가 숨겨져 있거나 가려진 경우가 많을 수 있습니다. 그러나 이러한 문제는 애플리케이션의 전반적인 성능에 부정적인 영향을 미칠 가능성이 있습니다.

4. 안전성

복잡한 애플리케이션의 많은 작업은 규모에 관계 없이 잘못될 수 있습니다. 개별 서버 및 하드 드라이브가 실패할 수 있습니다. 배포 문제로 인해 데이터베이스의 모든 테이블이 의도치 않게 삭제될 수 있습니다. 전체 데이터 센터에 연결할 수 없을 수 있습니다. 랜섬웨어 인시던트는 모든 데이터를 악의적으로 암호화할 수 있습니다. 애플리케이션이 신뢰할 수 있는 기능을 제공하고 지역적인 인시던트 및 광범위한 영향을 미치는 인시던트를 처리할 수 있도록 하는 것이 중요합니다.

안정성을 위한 설계는 부분 네트워크 중단 같은 소규모 인시던트 및 임시 조건을 통해 작동 시간을 유지하는 데 중점을 둡니다. 고가용성을 애플리케이션의 각 구성 요소에 통합하고 단일 실패 지점을 제거하여 애플리케이션이 지역화된 오류를 처리하도록 할 수 있습니다. 이러한 설계는 또한 인프라 유지 관리의 영향을 최소화합니다. 고가용성 설계는 일반적으로 인시던트의 영향을 신속하게 자동으로 제거하는 것을 목표로 하며 거의 영향을 주지 않고 시스템이 계속 요청을 처리할 수 있도록 보장합니다.

또한 안정성을 위한 설계는 데이터 손실 및 대규모 재해 복구에 중점을 둡니다. 이러한 유형의 인시던트를 복구하려면 적극적 개입이 필요한 경우가 많지만 자동화된 복구 단계를 통해 복구에 소요되는 시간을 줄일 수 있습니다. 이러한 유형의 인시던트 발생 시 가동이 일정 기간 동안 중지되거나 데이터가 영구적으로 손실될 수 있습니다. 재해 복구에는 실행 못지않게 신중한 계획이 중요합니다.

고가용성

• 클러스터링은 단일 VM을 조정된 VM 집합으로 바꿉니다. 하나의 VM이 실패하거나 연결될 수 없는 경우 서비스는 요청을 처리할 수 있는 다른 VM을 장애 조치(failover)할 수 있습니다.
• 부하 분산은 서비스의 많은 인스턴스에 요청을 분산하면서 실패한 인스턴스를 검색하고 해당 인스턴스로 요청이 라우팅되지 않도록 방지합니다.
• 단일 실패 지점 제거하기 위해 중복을 추가하는 것이 핵심 전략

오류 복구

• 복구 지점 목표(RPO): 허용 가능한 데이터 손실의 최대 기간입니다. RPO는 볼륨 단위가 아닌 시간 단위로 측정됩니다. “30분 동안의 데이터”, “4시간 동안의 데이터” 같은 식입니다. RPO는 데이터 도난이 아닌 데이터 손실의 제한 및 복구에 관한 것입니다. → 백업 빈도는 이 시간 범위내에 있어야 하며 정의된 RPO의 직접적인 영향을 받습니다.
• 복구 시간 목표(RTO): 허용되는 최대 가동 중지 시간으로, “가동 중지 시간”은 사양에 따라 정의됩니다. 예를 들어 재해 발생 시 허용되는 가동 중지 시간이 8시간이면 RTO는 8시간입니다.

5. 보안

보안이란 궁극적으로 조직에서 사용, 저장 및 전송하는 데이터를 보호하는 것입니다. 조직에서 저장하거나 처리하는 데이터는 보안 자산의 핵심입니다. 이 데이터는 고객의 중요한 데이터, 조직에 대한 재무 정보 또는 조직을 지원하는 중요한 기간 업무 데이터일 수 있습니다. 데이터가 존재하는 인프라는 물론 액세스에 사용하는 ID의 보안도 매우 중요합니다.

심층 방어

사용자 환경 보호에 대한 다단계 접근 방식은 사용자 환경의 보안 상태를 증진시킵니다. 일반적으로 심층 방어라고 하며, 계층은 다음과 같이 분석할 수 있습니다.

• 데이터
• 애플리케이션
• VM/컴퓨팅
• 네트워킹
• 경계
• 정책 및 액세스
• 물리적 보안

일반적인 공격으로부터 보호

• 데이터 계층: 암호화 키가 노출되거나 약한 암호화를 사용할 경우 무단 액세스 발생 시 데이터가 공격에 취약해질 수 있습니다.
• 애플리케이션 계층: 악성 코드 삽입 및 실행이 애플리케이션 레이어 공격의 특징입니다. 일반적인 공격에는 SQL 삽입 및 사이트 간 스크립팅(XSS)이 포함됩니다.
• VM/컴퓨팅 레이어: 맬웨어는 환경을 공격하는 일반적인 방법으로서 시스템을 손상시키는 악성 코드 실행을 포함합니다. 맬웨어가 시스템에 존재하면 자격 증명 노출 및 환경 전체에 걸쳐 수평으로 이동하는 추가 공격이 발생할 수 있습니다.
• 네트워킹 계층: 인터넷에 대해 불필요하게 개방된 포트는 일반적인 공격 방법입니다. 이러한 포트에는 가상 머신에 대해 개방된 SSH 또는 RDP가 포함될 수 있습니다. 프로토콜이 개방되어 있는 경우, 해당 프로토콜은 공격자가 액세스 권한을 얻으려고 할 때 시스템에 대한 무차별 공격을 허용할 수 있습니다.
• 경계 계층: 이 계층에서는 종종 서비스 거부(DoS) 공격이 발생합니다. 이러한 공격은 네트워크 리소스를 오프라인으로 강제 전환하거나 합법적인 요청에 응답할 수 없게 만들어 네트워크 리소스에 과부하가 걸리도록 유도합니다.
• 정책 및 액세스 계층: 이 계층에서는 애플리케이션에 대한 인증이 발생합니다. 이 계층에는 OpenID Connect, OAuth 또는 Active Directory 같은 Kerberos 기반 인증 등의 최신 인증 프로토콜이 포함될 수 있습니다. 이 계층에서 노출된 자격 증명은 위험하므로 ID 사용 권한을 제한해야 합니다. 또한 비정상적인 위치에서 들어오는 로그인 등 손상 가능한 계정을 검색하도록 모니터링을 마련하려고 합니다.
• 물리적 계층: 이 계층에서는 도어 드래프팅 및 보안 배지 도용 같은 방법을 통해 시설에 무단으로 액세스할 수 있습니다.

공동 보안 책임

공동 책임 모델을 다시 방문하면, 보안과 관련하여 이를 재구성할 수 있습니다. 선택한 서비스 유형에 따라 일부 보안 보호가 서비스에 기본적으로 제공되지만, 나머지 보안 보호는 사용자의 책임입니다.