Azure에서 중요 업무용 워크로드에 대한 데이터 플랫폼 고려 사항

효과적인 애플리케이션 데이터 플랫폼의 선택은 다른 디자인 영역에 걸쳐 광범위한 영향을 미치는 더 중요한 의사 결정 영역입니다. Azure는 궁극적으로 기능에서 크게 다른 다양한 관계형, 비관계형 및 분석 데이터 플랫폼을 제공합니다. 따라서 일관성, 조작성, 비용 및 복잡성과 같은 다른 의사 결정 요소와 함께 주요 비기능적 요구 사항을 완전히 고려해야 합니다. 예를 들어 다중 지역 쓰기 구성에서 작동하는 기능은 전역적으로 사용 가능한 플랫폼의 적합성에 중요한 영향을 갖습니다.

이 디자인 영역은 애플리케이션 디자인을 확장하여 최적의 데이터 플랫폼 선택을 알리는 주요 고려 사항 및 권장 사항을 제공합니다.

Important

이 문서는 Azure 잘 설계된 중요 업무용 워크로드 시리즈의 일부입니다. 이 시리즈에 익숙하지 않은 경우 중요 업무용 워크로드로 시작하는 것이 좋습니다.

빅 데이터 4개 대

'4대 빅 데이터'는 고가용성 데이터 플랫폼의 필수 특성과 데이터를 사용하여 비즈니스 가치를 극대화하는 방법을 더 잘 이해할 수 있는 프레임워크를 제공합니다. 따라서 이 섹션에서는 적절한 데이터 기술을 사용하여 데이터 플랫폼을 설계하는 데 도움이 되도록 볼륨, 속도, 다양성 및 진실성 특성을 개념적 수준에서 적용하는 방법을 살펴봅니다.

• Volume: 스토리지 용량 및 계층화 요구 사항을 알리기 위해 들어오는 데이터의 양입니다. 즉, 데이터 세트의 크기입니다.
• Velocity: 일괄 처리 또는 연속 스트림으로 데이터가 처리되는 속도입니다. 즉, 흐름 속도입니다.
• VAriety: 여러 저장소 또는 형식의 데이터인 구조화되고 반구조화되고 구조화되지 않은 형식을 캡처하는 데이터의 조직 및 형식입니다.
• V연대: 거버넌스 및 데이터 품질 보증을 위해 고려된 데이터 집합의 출처 및 큐레이션을 포함합니다. 즉, 데이터의 정확도입니다.

디자인 고려 사항

부피

• 비즈니스 목표 및 계획에 부합하는 예측 데이터 증가율을 기반으로 하는 기존(있는 경우) 및 예상 미래 데이터 볼륨

  • 데이터 볼륨은 데이터 자체와 인덱스, 로그, 원격 분석 및 기타 적용 가능한 데이터 세트를 포함해야 합니다.
  • 대규모 중요 비즈니스용 애플리케이션 및 중요 업무용 애플리케이션은 일반적으로 매일 대량(GB 및 TB)을 생성하고 저장합니다.
  • 데이터 확장과 관련된 상당한 비용 영향이 있을 수 있습니다.

• 비즈니스 상황이나 관리 절차의 변화로 인해 데이터 양이 변동될 수 있습니다.

• 데이터 볼륨은 데이터 플랫폼 쿼리 성능에 큰 영향을 미칠 수 있습니다.

• 데이터 플랫폼 볼륨 제한에 도달하면 심각한 영향을 미칠 수 있습니다.

  • 가동 중지 시간이 발생합니까? 그리고 만약 그렇다면, 얼마나 오래?
  • 완화 절차란? 완화하려면 애플리케이션을 변경해야 합니까?
  • 데이터 손실의 위험이 있나요?

• TTL(Time to Live)과 같은 기능을 사용하면 레코드 만들기 또는 수정을 통해 경과된 시간이 지나면 자동으로 레코드를 삭제하여 데이터 증가를 관리할 수 있습니다.

  • 예를 들어 Azure Cosmos DB는 기본 제공 TTL 기능을 제공합니다.

개발속도

• 다양한 애플리케이션 구성 요소에서 데이터를 내보내는 속도와 데이터를 커밋하고 검색해야 하는 속도에 대한 처리량 요구 사항은 주요 워크로드 시나리오에 가장 적합한 데이터 기술을 결정하는 데 중요합니다.

  • 처리량 요구 사항의 특성은 읽기가 많거나 쓰기가 많은 것과 같은 워크로드 시나리오에 따라 달라집니다.
    • 예를 들어 분석 워크로드는 일반적으로 대규모 읽기 처리량을 충족해야 합니다.
  • 필요한 처리량은 무엇인가요? 그리고 처리량은 어떻게 증가할 것으로 예상합니까?
  • 참조 부하 수준에서 P50/P99의 데이터 대기 시간 요구 사항은 무엇인가요?

• 잠금 없는 디자인, 인덱스 튜닝 및 일관성 정책 지원과 같은 기능은 높은 처리량을 달성하는 데 중요합니다.

  • 높은 처리량에 대한 구성을 최적화하면 절판이 발생하므로 완전히 이해해야 합니다.
  • CQRS 및 이벤트 소싱과 같은 부하 평준화 지속성 및 메시징 패턴을 사용하여 처리량을 추가로 최적화할 수 있습니다.

• 로드 수준은 처리량과 대기 시간을 유지하면서 다양한 수요를 처리하기 위해 충분한 탄력성을 요구하는 자연적인 최대치와 함께 다양한 애플리케이션 시나리오에서 자연스럽게 변동됩니다.

  • 민첩한 확장성은 용량 수준을 과도하게 프로비전하지 않고 다양한 처리량과 로드 수준을 효과적으로 지원하는 데 핵심입니다.
    • 읽기 및 쓰기 처리량 모두 애플리케이션 요구 사항 및 로드에 따라 크기 조정되어야 합니다.
    • 변화하는 부하 수준에 대응하기 위해 수직 및 수평 규모 작업을 모두 적용할 수 있습니다.

• 처리량 감소의 영향은 워크로드 시나리오에 따라 달라질 수 있습니다.

  • 연결이 중단되나요?
  • 제어 평면이 계속 작동하는 동안 개별 작업이 실패 코드를 반환합니까?
  • 데이터 플랫폼이 제한을 활성화하고, 그렇다면 얼마나 오래 활성화합니까?

• 활성-활성 지리적 분포를 사용하기 위한 기본 애플리케이션 디자인 권장 사항은 데이터 일관성과 관련한 과제를 소개합니다.

  • 전체 ACID 트랜잭션 의미 체계와 기존 잠금 동작과 관련하여 일관성과 성능이 절충됩니다.
    • 쓰기 대기 시간을 최소화하면 데이터 일관성의 비용이 발생합니다.

• 다중 지역 쓰기 구성에서는 필요한 경우 충돌 해결을 통해 모든 복제본 간에 변경 내용을 동기화하고 병합해야 하며, 이는 성능 수준 및 확장성에 영향을 줄 수 있습니다.

• 읽기 전용 복제본(지역 내 및 지역 간)을 사용하여 왕복 대기 시간을 최소화하고 트래픽을 분산하여 성능, 처리량, 가용성 및 확장성을 높일 수 있습니다.

• 캐싱 계층을 사용하여 읽기 처리량을 늘려 사용자 환경 및 엔드투엔드 클라이언트 응답 시간을 향상시킬 수 있습니다.

  • 데이터 최근성을 최적화하려면 캐시 만료 시간 및 정책을 고려해야 합니다.

종류

• 데이터 모델, 데이터 형식, 데이터 관계, 의도된 쿼리 모델은 데이터 플랫폼 결정에 큰 영향을 줍니다.

  • 애플리케이션에 관계형 데이터 모델이 필요합니까, 아니면 변수 스키마 또는 비관계형 데이터 모델을 지원할 수 있나요?
  • 애플리케이션은 데이터를 어떻게 쿼리합니까? 그리고 쿼리는 관계형 조인과 같은 데이터베이스 계층 개념에 따라 달라지나요? 또는 애플리케이션이 이러한 의미 체계를 제공합니까?

• 애플리케이션에서 고려하는 데이터 세트의 특성은 이미지 및 비디오와 같은 구조화되지 않은 콘텐츠 또는 CSV 및 Parquet과 같은 구조화된 파일에서 다양할 수 있습니다.

  • 복합 애플리케이션 워크로드에는 일반적으로 고유한 데이터 세트 및 관련 요구 사항이 있습니다.

• 관계형 또는 비관계형 데이터 플랫폼 외에도 그래프 또는 키-값 데이터 플랫폼은 특정 데이터 워크로드에도 적합할 수 있습니다.

  • 일부 기술은 데이터 항목이 의미상 유사하거나 함께 저장 및 쿼리되지만 구조적으로 다른 가변 스키마 데이터 모델을 수용합니다.

• 마이크로 서비스 아키텍처에서 개별 애플리케이션 서비스는 단일 모놀리식 데이터 저장소에 종속되지 않고 고유한 시나리오 최적화 데이터 저장소로 빌드할 수 있습니다.

  • SAGA와 같은 디자인 패턴을 적용하여 서로 다른 데이터 저장소 간의 일관성 및 종속성을 관리할 수 있습니다.
    • 데이터베이스 간 직접 쿼리는 공동 위치 제약 조건을 적용할 수 있습니다.
  • 여러 데이터 기술을 사용하면 포괄 기술을 유지하기 위해 어느 정도의 관리 오버헤드가 추가됩니다.

• 각 Azure 서비스에 대한 기능 집합은 언어, SDK 및 API에 따라 다르므로 적용할 수 있는 구성 튜닝 수준에 큰 영향을 미칠 수 있습니다.

• 데이터 모델 및 포괄 데이터 형식과의 최적화된 맞춤 기능은 데이터 플랫폼 결정에 큰 영향을 줍니다.

  • 저장 프로시저 및 개체 관계형 매퍼와 같은 쿼리 계층
  • 보안 REST API 계층과 같은 언어 중립적 쿼리 기능입니다.
  • 백업 및 복원과 같은 비즈니스 연속성 기능

• 분석 데이터 저장소는 일반적으로 다양한 유형의 데이터 구조에 대한 다각형 스토리지를 지원합니다.

  • Apache Spark와 같은 분석 런타임 환경에는 다각형 데이터 구조를 분석하기 위한 통합 제한이 있을 수 있습니다.

• 엔터프라이즈 컨텍스트에서 기존 프로세스 및 도구의 사용과 기술의 연속성은 데이터 플랫폼 디자인 및 데이터 기술 선택에 상당한 영향을 미칠 수 있습니다.

정확성

• 애플리케이션 내 데이터의 정확도의 유효성을 검사하려면 여러 요소를 고려해야 하며, 이러한 요소의 관리는 데이터 플랫폼 디자인에 중요한 영향을 미칠 수 있습니다.

  • 데이터 일관성.
  • 플랫폼 보안 기능.
  • 데이터 거버넌스
  • 변경 관리 및 스키마 진화.
  • 데이터 세트 간의 종속성입니다.

• 여러 데이터 복제본이 있는 분산 애플리케이션에서는 CAP 및 PACELC 정리에 표현된 대로 일관성과 대기 시간 간에 장단 관계가 있습니다.

  • 판독기와 기록기가 명확하게 배포되는 경우 애플리케이션은 다른 복제본에서 해당 데이터 항목의 방금 완료된 쓰기(업데이트)에 비해 최신 버전이 아니더라도 데이터 항목의 사용 가능한 가장 빠른 버전을 반환하도록 선택하거나 최신 상태를 확인하고 가져오는 데 추가 대기 시간이 발생할 수 있는 최신 버전의 데이터 항목을 반환하도록 선택해야 합니다.
  • 일관성 및 가용성은 플랫폼 수준 또는 개별 데이터 요청 수준에서 구성할 수 있습니다.
  • 다른 복제본의 최신 상태를 반영하지 않는 사용자와 가장 가까운 복제본에서 데이터를 제공하려는 경우 사용자 환경은 어떻게 되나요? 즉, 애플리케이션에서 오래된 데이터 제공을 지원할 수 있나요?

• 다중 지역 쓰기 컨텍스트에서 변경 내용을 복제하기 전에 두 개의 별도 쓰기 복제본에서 동일한 데이터 항목이 변경되면 해결해야 하는 충돌이 생성됩니다.

  • "마지막 쓰기 우선"과 같은 표준화된 충돌 해결 정책 또는 사용자 지정 논리를 사용하는 사용자 지정 전략을 적용할 수 있습니다.

• 보안 요구 사항의 구현은 처리량 또는 성능에 부정적인 영향을 줄 수 있습니다.

• 필요한 경우 클라이언트 쪽 암호화 및/또는 서버 쪽 암호화를 사용하여 데이터 계층을 사용하여 애플리케이션 계층에서 미사용 암호화를 구현할 수 있습니다.

• 서비스 관리형 키를 사용하는 서버 쪽 암호화, Key Vault의 고객 관리형 키 또는 고객 제어 하드웨어의 고객 관리형 키를 비롯한 다양한 암호화 모델을 Azure 지원.

  • 클라이언트 쪽 암호화를 사용하면 Key Vault 또는 다른 보안 위치에서 키를 관리할 수 있습니다.

• MACsec(IEEE 802.1AE MAC) 데이터 링크 암호화는 Microsoft 백본 네트워크의 Azure 데이터 센터 간에 이동하는 모든 트래픽을 보호하는 데 사용됩니다.

  • 패킷은 전송되기 전에 디바이스에서 암호화되고 암호 해독되어 물리적인 '맨인 더 미들' 또는 스누핑/도청 공격을 방지합니다.

• 데이터 평면 및 컨트롤 플레인에 대한 인증 및 권한 부여

  • 데이터 플랫폼은 애플리케이션 액세스 및 운영 액세스를 인증하고 권한을 부여하려면 어떻게 할까요?

• 플랫폼 상태 및 데이터 액세스를 모니터링하여 관찰할 수 있습니다.

  • 허용 가능한 운영 경계를 벗어난 조건에 대한 경고는 어떻게 적용되나요?

디자인 권장 구성

부피

• 유기적 성장과 관련된 향후 데이터 볼륨이 데이터 플랫폼 기능을 초과할 것으로 예상되지 않는지 확인합니다.

  • 비즈니스 계획에 맞춰 데이터 증가율을 예측하고 설정된 비율을 사용하여 지속적인 용량 요구 사항을 알립니다.
  • 데이터 플랫폼 제한에 대해 집계 볼륨 및 데이터 레코드별 볼륨을 비교합니다.
  • 예외적인 상황에서 한도에 도달할 위험이 있는 경우 가동 중지 시간 및 데이터 손실을 방지하기 위한 운영 완화 조치가 마련되어 있는지 확인합니다.

• 규모 제한과 예상 데이터 증가율을 고려하여 데이터 볼륨을 모니터링하고 용량 모델과 비교하여 유효성을 검사합니다.

  • 크기 조정 작업이 스토리지, 성능 및 일관성 요구 사항에 부합하는지 확인합니다.
  • 새 배율 단위가 도입되면 복제가 발생하는 동안 시간이 걸리고 성능 저하가 발생할 수 있는 기본 데이터를 복제해야 할 수 있습니다. 따라서 가능한 경우 이러한 작업이 중요한 업무 시간 외에 수행되는지 확인합니다.

• 이전 데이터의 제거 또는 오프로드를 용이하게 하기 위해 사용량 및 중요도에 따라 데이터 세트를 분류하는 애플리케이션 데이터 계층을 정의합니다.

  • 데이터 세트를 '핫', '웜' 및 '콜드'('보관') 계층으로 분류하는 것이 좋습니다.
    • 예를 들어 기본 참조 구현은 Azure Cosmos DB를 사용하여 애플리케이션에서 적극적으로 사용하는 '핫' 데이터를 저장하는 반면, Azure Storage는 분석을 위해 '콜드' 작업 데이터에 사용됩니다.

• 데이터 증가를 최적화하고 쿼리 성능 및 데이터 확장 관리와 같은 데이터 효율성을 높이기 위한 하우스키핑 절차를 구성합니다.

  • 더 이상 필요하지 않고 장기 분석 값이 없는 데이터에 대한 TTL(Time To Live) 만료를 구성합니다.
    • 애플리케이션에 부정적인 영향을 주지 않고 오래된 데이터를 보조 스토리지에 안전하게 계층화하거나 완전히 삭제할 수 있는지 유효성을 검사합니다.
  • 중요하지 않은 데이터를 보조 콜드 스토리지로 오프로드하되 분석 가치와 감사 요구 사항 충족을 위해 유지합니다.
  • 데이터 플랫폼 원격 분석 및 사용 통계를 수집하여 DevOps 팀이 하우스키핑 요구 사항 및 '적절한 크기' 데이터 저장소를 지속적으로 평가할 수 있도록 합니다.

• 마이크로 서비스 애플리케이션 설계에 따라 특정 워크로드 시나리오 및 볼륨 요구 사항에 최적화된 데이터 솔루션과 함께 여러 다른 데이터 기술을 병렬로 사용하는 것이 좋습니다.

  • 확장으로 인한 데이터 볼륨을 관리하기 어려울 수 있는 단일 모놀리식 데이터 저장소를 만들지 마세요.

개발속도

• 데이터 플랫폼은 기본적으로 높은 처리량을 지원하도록 설계되고 구성되어야 하며, 워크로드는 시나리오 최적화 데이터 솔루션을 사용하여 성능을 최대화하기 위해 다른 컨텍스트로 구분됩니다.

  • 각 데이터 시나리오의 읽기 및 쓰기 처리량은 예상되는 부하 패턴에 따라 크기 조정될 수 있으며 예기치 못한 변동에 대한 충분한 허용 범위를 보장합니다.
  • 트랜잭션 및 분석 작업과 같은 다양한 데이터 워크로드를 고유한 성능 컨텍스트로 분리합니다.

• 비동기 비차단 메시징(예: CQRS 또는 이벤트 소싱 패턴 사용)을 사용하여 부하 수준입니다.

  • 쓰기 요청과 새 데이터를 읽을 수 있게 되면 사용자 환경에 영향을 줄 수 있는 대기 시간이 있을 수 있습니다.
    • 이러한 영향은 주요 비즈니스 요구 사항의 컨텍스트에서 이해하고 허용해야 합니다.

• 가변 처리량 및 부하 수준을 지원하는 민첩한 확장성을 보장합니다.

  • 부하 수준이 매우 휘발성인 경우 용량 수준을 과도하게 프로비전하여 처리량 및 성능이 유지되도록 하는 것이 좋습니다.
  • 처리량을 유지할 수 없는 경우 복합 애플리케이션 워크로드에 미치는 영향을 테스트하고 유효성 검사합니다.

• 부하 수준 변동성에 대한 신속한 응답을 촉진하기 위해 자동화된 크기 조정 작업을 통해 Azure 네이티브 데이터 서비스의 우선 순위를 지정합니다.

  • 서비스 내부 및 애플리케이션 설정 임계값을 기반으로 자동 크기 조정을 구성합니다.
  • 크기 조정은 비즈니스 요구 사항과 일치하는 기간 내에 시작되고 완료되어야 합니다.
  • 수동 상호 작용이 필요한 시나리오에서는 수동 운영 작업을 수행하는 대신 트리거될 수 있는 자동화된 운영 '플레이북'을 설정합니다.
    • 자동화된 트리거를 후속 엔지니어링 투자의 일부로 적용할 수 있는지 여부를 고려합니다.

• P50/P99 대기 시간 요구 사항에 대한 애플리케이션 데이터 읽기 및 쓰기 처리량을 모니터링하고 애플리케이션 용량 모델에 맞춥니다.

• 초과 처리량은 데이터 플랫폼 또는 애플리케이션 계층에서 정상적으로 처리되고 작동 표현을 위해 상태 모델에 의해 캡처되어야 합니다.

• '핫' 데이터 시나리오에 대한 캐싱을 구현하여 응답 시간을 최소화합니다.

  • 가출 데이터 증가를 방지하기 위해 캐시 만료 및 집 보관에 적절한 정책을 적용합니다.
    • 백업 데이터가 변경되면 캐시 항목을 만료합니다.
    • 캐시 만료가 엄격하게 TTL(Time-To-Live)을 기반으로 하는 경우 오래된 데이터를 제공하는 데 따른 영향과 고객 환경을 이해해야 합니다.

종류

• 클라우드 및 Azure 네이티브 디자인의 원칙에 따라 관리되는 Azure 서비스의 우선 순위를 지정하여 운영 및 관리 복잡성을 줄이고 Microsoft의 향후 플랫폼 투자를 활용하는 것이 좋습니다.

• 느슨하게 결합된 마이크로 서비스 아키텍처의 애플리케이션 디자인 원칙에 따라 개별 서비스에서 고유한 데이터 저장소 및 시나리오 최적화 데이터 기술을 사용할 수 있습니다.

  • 특정 워크로드 시나리오에 대해 애플리케이션이 처리할 데이터 구조 형식을 식별합니다.
  • 단일 모놀리식 데이터 저장소에 대한 종속성을 만들지 마세요.
    • 데이터 저장소 간의 종속성이 있는 SAGA 디자인 패턴을 고려합니다.

• 선택한 데이터 기술에 필요한 기능을 사용할 수 있는지 유효성을 검사합니다.

  • 필요한 언어 및 SDK 기능에 대한 지원을 확인합니다. 모든 기능이 동일한 방식으로 모든 언어/SDK에 사용할 수 있는 것은 아닙니다.

정확성

• 다중 지역 데이터 플랫폼 디자인을 채택하고 데이터를 애플리케이션 엔드포인트에 더 가깝게 이동하여 안정성, 가용성 및 성능을 극대화하기 위해 여러 지역에 복제본을 배포합니다.

  • 지역 내의 가용성 영역(AZs)에 데이터 복제본을 배포하거나 영역 중복 서비스 계층을 사용하여 지역 내 가용성을 최대화합니다.

• 일관성 요구 사항이 허용하는 경우 다중 지역 쓰기 데이터 플랫폼 디자인을 사용하여 전반적인 글로벌 가용성 및 안정성을 최대화합니다.

  • 두 개의 별도 쓰기 복제본에서 동일한 데이터 항목을 변경한 후 변경 내용을 복제하여 충돌이 발생할 경우 충돌 해결을 위한 비즈니스 요구 사항을 고려합니다.
    • 가능한 경우 "마지막 1승"과 같은 표준화된 충돌 해결 정책 사용
      • 사용자 지정 논리를 사용하는 사용자 지정 전략이 필요한 경우 사용자 지정 논리를 관리하기 위해 CI/CD DevOps 사례를 적용해야 합니다.

• 지속적인 배달 프로세스 내에서 비정상 상황 테스트를 통해 백업 및 복원 기능 및 장애 조치(failover) 작업을 테스트하고 유효성을 검사합니다.

• 성능 벤치마크를 실행하여 처리량 및 성능 요구 사항이 암호화와 같은 필수 보안 기능 포함의 영향을 받지 않도록 합니다.

  • 지속적인 업데이트 프로세스에서 알려진 성능 벤치마크에 대한 부하 테스트를 고려하도록 합니다.

• 암호화를 적용할 때 관리 복잡성을 줄이는 방법으로 서비스 관리 암호화 키를 사용하는 것이 좋습니다.

  • 고객 관리형 키에 대한 특정 보안 요구 사항이 있는 경우 고려되는 모든 키의 가용성, 백업 및 회전을 보장하기 위해 적절한 키 관리 절차가 적용되는지 확인합니다.

참고 항목

더 광범위한 조직 구현과 통합하는 경우 애플리케이션 디자인에서 데이터 플랫폼 구성 요소의 프로비전 및 운영에 애플리케이션 중심 접근 방식을 적용하는 것이 중요합니다.

특히 안정성을 최대화하려면 개별 데이터 플랫폼 구성 요소가 다른 애플리케이션 구성 요소를 포함할 수 있는 운영 작업을 통해 애플리케이션 상태에 적절하게 대응하는 것이 중요합니다. 예를 들어 추가 데이터 플랫폼 리소스가 필요한 시나리오에서는 용량 모델에 따라 다른 애플리케이션 구성 요소와 함께 데이터 플랫폼의 크기를 조정해야 할 수 있습니다. 중앙 집중식 운영 팀이 격리된 데이터 플랫폼과 관련된 문제를 해결하기 위해 하드 종속성이 있는 경우 이 접근 방식은 궁극적으로 제한됩니다.

궁극적으로 중앙 집중식 데이터 서비스(중앙 IT DBaaS)를 사용하면 크게 텍스트가 없는 관리 환경을 통해 민첩성을 크게 저해하는 운영 병목 현상이 발생하며 중요 업무용 또는 중요 비즈니스용 컨텍스트에서 피해야 합니다.

추가 참조

추가 데이터 플랫폼 지침은 Azure 애플리케이션 아키텍처 가이드 내에서 사용할 수 있습니다.

• Azure Data Store 의사 결정 트리
• 데이터 저장소를 선택하기 위한 조건
• 비관계형 데이터 저장소
• 관계형 OLTP 데이터 저장소

전역적으로 분산된 다중 지역 쓰기 데이터 저장소

애플리케이션 디자인의 전역적으로 분산된 활성-활성 포부를 완벽하게 수용하려면 별도의 쓰기 가능한 복제본에 대한 변경 내용이 모든 복제본 간에 동기화되고 병합되는 분산 다중 지역 쓰기 데이터 플랫폼을 고려하는 것이 좋습니다. 이 플랫폼은 필요한 경우 충돌 해결을 사용합니다.

Important

마이크로 서비스가 모두 분산된 다중 지역 쓰기 데이터 저장소를 필요로 하는 것은 아니므로 각 워크로드 시나리오의 아키텍처 컨텍스트 및 비즈니스 요구 사항을 고려해야 합니다.

Azure Cosmos DB는 전역적으로 분산되고 고가용성 NoSQL 데이터 저장소를 제공하여 다중 지역 쓰기 및 튜닝 가능한 일관성을 기본적으로 제공합니다. 따라서 이 섹션의 디자인 고려 사항 및 권장 사항은 최적의 Azure Cosmos DB 사용에 초점을 맞춥니다.

디자인 고려 사항

Azure Cosmos DB

• Azure Cosmos DB는 빠른 트랜잭션 읽기 및 쓰기를 허용하도록 설계된 인덱싱된 행 기반 트랜잭션 저장소인 Containers 내에 데이터를 저장하며 응답 시간은 밀리초 단위입니다.

• Azure Cosmos DB는 SQL, Cassandra 및 MongoDB와 같은 다양한 기능 집합이 있는 여러 API를 지원합니다.

  • NoSQL용 자사 Azure Cosmos DB는 가장 풍부한 기능 집합을 제공하며 일반적으로 새 기능을 먼저 사용할 수 있는 API입니다.

• Azure Cosmos DB는 게이트웨이 및 직접 연결 모드를 지원합니다. 여기서 Direct는 TCP를 통해 Azure Cosmos DB 복제본 노드를 백 엔드로 쉽게 연결하여 적은 수의 네트워크 홉으로 성능을 향상시키고 게이트웨이는 프런트 엔드 게이트웨이 노드에 대한 HTTPS 연결을 제공합니다.

  • 직접 모드는 NoSQL용 Azure Cosmos DB를 사용하는 경우에만 사용할 수 있으며 현재 .NET 및 Java SDK 플랫폼에서만 지원됩니다.

• 가용성 영역 사용 지역 내에서 Azure Cosmos DB는 지역 내의 영역 오류에 대한 고가용성 및 복원력에 대한 AZ(가용성 영역) 중복 지원을 제공합니다.

• Azure Cosmos DB는 단일 지역 내에서 4개의 데이터 복제본을 유지 관리하며, AZ(가용성 영역) 중복성을 사용하도록 설정하면 Azure Cosmos DB는 영역 오류로부터 보호하기 위해 여러 AZ에 데이터 복제본을 배치하도록 합니다.

  • Paxos 합의 프로토콜은 지역 내의 복제본에서 쿼럼을 달성하기 위해 적용됩니다.

• Azure Cosmos DB 계정은 단일 지역을 사용할 수 없게 될 위험을 완화하기 위해 여러 지역에 데이터를 복제하도록 쉽게 구성할 수 있습니다.

  • 복제는 단일 지역 쓰기 또는 다중 지역 쓰기로 구성할 수 있습니다.
    • 단일 지역 쓰기를 사용하면 기본 '허브' 지역이 모든 쓰기를 처리하는 데 사용되며, 이 '허브' 지역을 사용할 수 없게 되면 다른 지역을 쓰기 가능으로 승격하려면 장애 조치(failover) 작업이 발생해야 합니다.
    • 다중 지역 쓰기를 사용하면 애플리케이션이 구성된 배포 지역에 쓸 수 있으며 다른 모든 지역 간에 변경 내용을 복제합니다. 지역을 사용할 수 없는 경우 나머지 지역은 쓰기 트래픽을 제공하는 데 사용됩니다.

• 다중 지역 쓰기 구성 에서 기록기가 여러 지역에서 동일한 항목을 동시에 업데이트하는 경우 업데이트(삽입, 바꾸기, 삭제) 충돌이 발생할 수 있습니다.

• Azure Cosmos DB는 충돌을 자동으로 해결하기 위해 적용할 수 있는 두 가지 충돌 해결 정책을 제공합니다.

  • LWW(Last Write Wins)는 시스템 정의 타임스탬프 속성을 충돌 해결 경로로 사용하여 시간 동기화 클록 _ts 프로토콜을 적용합니다. 충돌 시 충돌 해결 경로의 값이 가장 높은 항목이 승자가 되고, 여러 항목의 숫자 값이 같으면 모든 지역이 커밋된 항목의 동일한 버전으로 수렴할 수 있도록 시스템이 승자를 선택합니다.
    • 삭제 충돌이 발생하면 삭제된 버전은 충돌 해결 경로 값에 관계없이 삽입 또는 바꾸기 충돌을 항상 우선합니다.
    • 최종 작성자 인정(Last Write Wins)은 기본 충돌 해결 정책입니다.
    • NoSQL용 Azure Cosmos DB를 사용하는 경우 사용자 지정 타임스탬프 정의와 같은 사용자 지정 숫자 속성을 충돌 해결에 사용할 수 있습니다.
  • 사용자 지정 해결 정책을 사용하면 애플리케이션 정의 의미 체계가 충돌이 감지될 때 자동으로 호출되는 등록된 병합 저장 프로시저를 사용하여 충돌을 조정할 수 있습니다.
    • 시스템은 커밋 프로토콜의 일부로 병합 프로시저의 실행에 대해 정확히 한 번의 보장을 제공합니다.
    • 사용자 지정 충돌 해결 정책은 NoSQL용 Azure Cosmos DB에서만 사용할 수 있으며 컨테이너를 만들 때만 설정할 수 있습니다.

• 다중 지역 쓰기 구성에서는 단일 Azure Cosmos DB '허브' 지역에 종속되어 모든 충돌 해결을 수행하며, 허브 지역 내의 복제본 간에 쿼럼을 달성하기 위해 Paxos 합의 프로토콜이 적용됩니다.

  • 이 플랫폼은 부하 수준을 로드하고 일시적인 오류에 대한 중복성을 제공하기 위해 허브 지역 내의 쓰기 충돌에 대한 메시지 버퍼를 제공합니다.
    • 버퍼는 합의가 필요한 몇 분 분량의 쓰기 업데이트를 저장할 수 있습니다.

Azure Cosmos DB 플랫폼의 전략적 방향은 다중 지역 쓰기 구성에서 충돌 해결을 위한 이 단일 지역 종속성을 제거하는 것이며, 2단계 Paxos 접근 방식을 활용하여 전역 수준 및 지역 내에서 쿼럼을 달성합니다.

• 기본 '허브' 지역은 Azure Cosmos DB가 구성된 첫 번째 지역에 의해 결정됩니다.

  • 우선 순위 순서는 장애 조치(failover) 목적으로 추가 위성 배포 지역에 대해 구성됩니다.

• 데이터 모델 및 논리 및 물리적 파티션 간 분할은 최적의 성능과 가용성을 달성하는 데 중요한 역할을 합니다.

• 단일 쓰기 지역을 사용하여 배포하는 경우 모든 읽기 지역 복제본을 고려하여 정의된 장애 조치(failover) 우선 순위에 따라 자동 장애 조치(failover)를 위해 Azure Cosmos DB를 구성할 수 있습니다.

• Azure Cosmos DB 플랫폼에서 제공하는 RTO는 최대 10~15분이며, 허브 지역에 치명적인 재해가 발생한 경우 Azure Cosmos DB 서비스의 지역 장애 조치(failover)를 수행하는 데 경과된 시간을 캡처합니다.

  • 이 RTO는 충돌 해결을 위한 단일 '허브' 지역에 대한 종속성을 고려할 때 다중 지역 쓰기 컨텍스트에서도 관련이 있습니다.
    • '허브' 지역을 사용할 수 없게 되면 서비스가 장애 조치(failover)되고 새 허브 지역이 설정될 때까지 충돌 해결이 수행될 수 없으므로 메시지 버퍼가 채워지면 다른 지역에 대한 쓰기가 실패합니다.

Azure Cosmos DB 플랫폼의 전략적 방향은 파티션 수준 장애 조치(failover)를 허용하여 RTO를 최대 5분으로 줄이는 것입니다.

• RPO(복구 지점 목표) 및 RTO(복구 시간 목표)는 일관성 수준을 통해 구성할 수 있으며 데이터 내구성과 처리량 간의 장단점이 있습니다.

  • Azure Cosmos DB는 단일 쓰기 지역과의 강력한 일관성을 위해 다중 지역 쓰기를 사용하는 완화된 일관성 수준에 대해 최소 RTO 0 또는 RPO 0을 제공합니다.

• Azure Cosmos DB는 쓰기 가능한 여러 Azure 지역으로 구성된 데이터베이스 계정에 대한 읽기 및 쓰기 가용성 모두에 대해 99.999% SLA를 제공합니다.

  • SLA는 100% - 평균 오차율로 계산되는 월별 가동 시간 백분율로 표시됩니다.
  • 평균 오류율은 청구 월의 각 시간에 대한 오류 비율의 합계로 청구 월의 총 시간 수로 정의됩니다. 여기서 오류율은 지정된 1시간 간격 동안 총 요청으로 나눈 실패한 요청의 총 수입니다.

• Azure Cosmos DB는 5가지 일관성 수준으로 구성된 경우 단일 Azure 지역으로 범위가 지정된 데이터베이스 계정의 처리량, 일관성, 가용성 및 대기 시간에 대해 99.99% SLA를 제공합니다.

  • 99.99% SLA는 완화된 4개의 일관성 수준 중 어느 것으로 구성된 여러 Azure 지역에 걸쳐 있는 데이터베이스 계정에도 적용됩니다.

• Azure Cosmos DB, 표준 및 자동 크기 조정에서 프로비전할 수 있는 처리량에는 초당 요청 단위(RU/s)를 사용하여 측정되는 두 가지 유형의 처리량이 있습니다.

  • 표준 처리량은 지정된 RU/s 값을 보장하는 데 필요한 리소스를 할당합니다.
    • 표준은 프로비전된 처리량에 대해 매시간 청구됩니다.
  • 자동 크기 조정은 최대 처리량 값을 정의하며, Azure Cosmos DB는 최대 처리량 값과 최대 처리량 값의 최소 10% 사이에서 애플리케이션 부하에 따라 자동으로 확장 또는 축소됩니다.
    • 자동 크기 조정은 사용된 최대 처리량에 대해 매시간 청구됩니다.

• 가변 워크로드를 사용하여 정적 프로비전된 처리량으로 인해 제한 오류가 발생할 수 있으며 이는 인식된 애플리케이션 가용성에 영향을 미칩니다.

  • 자동 크기 조정은 Azure Cosmos DB가 필요에 따라 스케일 업되도록 하여 제한 오류로부터 보호하는 동시에 부하가 감소할 때 다시 축소하여 비용 보호를 유지합니다.

• Azure Cosmos DB가 여러 지역에 복제되면 프로비전된 RU(요청 단위)는 지역당 요금이 청구됩니다.

• 다중 지역 쓰기 및 단일 지역 쓰기 구성 간에 상당한 비용 델타가 있으며, 대부분의 경우 다중 마스터 Azure Cosmos DB 데이터 플랫폼 비용이 엄청나게 커질 수 있습니다.

단일 지역 읽기/쓰기	단일 지역 쓰기 - 이중 지역 읽기	이중 지역 읽기/쓰기
1RU	2RU	4RU

단일 지역 쓰기와 다중 지역 쓰기 간의 델타는 실제로 위의 표에 반영된 1:2 비율보다 작습니다. 더 구체적으로, 단일 쓰기 구성에서 쓰기 업데이트와 관련된 지역 간 데이터 전송 요금이 있으며, 다중 지역 쓰기 구성과 마찬가지로 RU 비용 내에서 캡처되지 않습니다.

• 사용된 스토리지는 지정된 시간 동안 데이터 및 인덱스를 호스트하는 데 사용된 총 스토리지 양(GB)에 대해 고정 요금으로 청구됩니다.

• Session 는 쓰기와 동일한 순서로 데이터를 받기 때문에 가장 널리 사용되는 기본 일관성 수준 입니다.

• Azure Cosmos DB는 겹치는 기능을 제공하는 Microsoft Entra ID 또는 Azure Cosmos DB 키 및 리소스 토큰을 통한 인증을 지원합니다.

• 키 또는 리소스 토큰을 사용하여 리소스 관리 작업을 사용하지 않도록 설정하여 키 및 리소스 토큰을 데이터 작업으로만 제한할 수 있으므로 Microsoft Entra RBAC(역할 기반 액세스 제어)를 사용하여 리소스 액세스 제어를 세분화할 수 있습니다.

  • 키 또는 리소스 토큰을 통해 컨트롤 플레인 액세스를 제한하면 Azure Cosmos DB SDK를 사용하는 클라이언트에 대한 컨트롤 플레인 작업이 비활성화되므로 철저히 평가 및 테스트해야 합니다.
  • ARM disableKeyBasedMetadataWriteAccess 템플릿 IaC 정의를 통해 또는 기본 제공 Azure Policy를 통해 설정을 구성할 수 있습니다.

• Azure Cosmos DB의 Microsoft Entra RBAC 지원은 계정 및 리소스 제어 평면 관리 작업에 적용됩니다.

  • 애플리케이션 관리자는 사용자, 그룹, 서비스 주체 또는 관리 ID에 대한 역할 할당을 만들어 Azure Cosmos DB 리소스에 대한 리소스 및 작업에 대한 액세스 권한을 부여하거나 거부할 수 있습니다.
  • 역할 할당에 사용할 수 있는 몇 가지 기본 제공 RBAC 역할이 있으며 사용자 지정 RBAC 역할을 사용하여 특정 권한 조합을 구성할 수도 있습니다.
    • Cosmos DB 계정 판독 기를 사용하면 Azure Cosmos DB 리소스에 대한 읽기 전용 액세스를 사용할 수 있습니다.
    • DocumentDB 계정 기여자는 키 및 역할 할당을 포함하여 Azure Cosmos DB 계정을 관리할 수 있지만 데이터 평면 액세스를 사용하도록 설정하지는 않습니다.
    • Cosmos DB 연산자는 DocumentDB 계정 기여자와 유사하지만 키 또는 역할 할당을 관리하는 기능을 제공하지 않습니다.

• Azure Cosmos DB 리소스(계정, 데이터베이스 및 컨테이너)는 리소스 잠금을 사용하여 잘못된 수정 또는 삭제로부터 보호할 수 있습니다.

  • 리소스 잠금은 계정, 데이터베이스 또는 컨테이너 수준에서 설정할 수 있습니다.
  • 리소스에 설정된 리소스 잠금은 모든 자식 리소스에서 상속됩니다. 예를 들어 Azure Cosmos DB 계정에 설정된 리소스 잠금은 계정 내의 모든 데이터베이스 및 컨테이너에서 상속됩니다.
  • 리소스 잠금은 컨트롤 플레인 작업에만 적용되며 데이터 만들기, 변경 또는 삭제와 같은 데이터 평면 작업을 방지하지 않습니다.
  • 컨트롤 플레인 액세스가 disableKeyBasedMetadataWriteAccess제한되지 않으면 클라이언트는 계정 키를 사용하여 컨트롤 플레인 작업을 수행할 수 있습니다.

• Azure Cosmos DB 변경 피드는 Azure Cosmos DB 컨테이너의 데이터에 대한 변경 내용의 시간 순서 피드를 제공합니다.

  • 변경 피드에는 원본 Azure Cosmos DB 컨테이너에 대한 삽입 및 업데이트 작업만 포함됩니다. 삭제는 포함되지 않습니다.

• 변경 피드는 원본 컨테이너의 변경 피드에서 공급되는 대상 데이터 저장소에 대한 지속적인 업데이트와 함께 애플리케이션에서 사용하는 기본 컨테이너와 별도의 데이터 저장소를 유지하는 데 사용할 수 있습니다.

  • 변경 피드를 사용하여 추가 데이터 플랫폼 중복 또는 후속 분석 시나리오에 대한 보조 저장소를 채울 수 있습니다.

• 삭제 작업이 원본 컨테이너 내의 데이터에 정기적으로 영향을 주는 경우 변경 피드에서 공급되는 저장소는 정확하지 않고 삭제된 데이터를 반사하지 않습니다.

  • 데이터 레코드가 변경 피드에 포함되도록 일시 삭제 패턴을 구현할 수 있습니다.
    • 데이터 레코드를 명시적으로 삭제하는 대신 항목이 삭제된 것으로 간주되도록 플래그(예: IsDeleted)를 설정하여 데이터 레코드가 업데이트됩니다.
    • 변경 피드에서 공급되는 모든 대상 데이터 저장소는 삭제된 플래그가 True로 설정된 항목을 검색하고 처리해야 합니다. 일시 삭제된 데이터 레코드 를 저장하는 대신 대상 저장소에 있는 기존 버전의 데이터 레코드를 삭제해야 합니다.
  • 짧은 TTL(Time-To-Live)은 일반적으로 일시 삭제 패턴과 함께 사용되므로 Azure Cosmos DB는 만료된 데이터를 자동으로 삭제하지만 삭제된 플래그가 True로 설정된 변경 피드 내에 반영된 후에만 사용됩니다.
    • 변경 피드를 통해 삭제를 전파하는 동시에 원래 삭제 의도를 수행합니다.

• Azure Cosmos DB는 기존 ETL 파이프라인에서 발생하는 복잡성 및 대기 시간 문제를 해결하기 위해 최적화된 분석 쿼리에 열 형식을 적용하는 분석 저장소로 구성할 수 있습니다.

• Azure Cosmos DB는 성능 또는 가용성에 영향을 주지 않고 RU/s를 사용하지 않고 정기적으로 데이터를 자동으로 백업합니다.

• Azure Cosmos DB는 두 가지 고유한 백업 모드에 따라 구성할 수 있습니다.

  • 정기적인 백업은 모든 계정에 대한 기본 백업 모드로, 백업은 주기적인 간격으로 수행되고 지원 팀과 요청을 만들어 데이터가 복원됩니다.
    • 기본 정기 백업 보존 기간은 8시간이고 기본 백업 간격은 4시간입니다. 즉, 기본적으로 최신 두 백업만 저장됩니다.
    • 백업 간격 및 보존 기간은 계정 내에서 구성할 수 있습니다.
      • 최대 보존 기간은 최소 백업 간격이 1시간인 한 달까지 연장됩니다.
      • 백업 스토리지 중복성을 구성하려면 Azure "Cosmos DB 계정 읽기 권한자 역할"에 대한 역할 할당이 필요합니다.
    • 두 개의 백업 복사본은 추가 비용 없이 포함되지만 추가 백업에는 추가 비용이 발생합니다.
    • 기본적으로 정기 백업은 직접 액세스할 수 없는 별도의 GRS(지역 중복 스토리지) 내에 저장됩니다.
      • 백업 스토리지는 기본 '허브' 지역 내에 있으며 기본 스토리지 복제를 통해 쌍을 이루는 지역에 복제됩니다.
      • 기본 백업 스토리지 계정의 중복 구성은 영역 중복 스토리지 또는 로컬 중복 스토리지로 구성할 수 있습니다.
    • 고객이 직접 복원을 수행할 수 없으므로 복원 작업을 수행하려면 지원 요청이 필요합니다.
      • 지원 티켓을 열기 전에 백업 보존 기간을 데이터 손실 이벤트의 8시간 이내에 최소 7일로 늘려야 합니다.
    • 복원 작업은 데이터가 복구되는 새 Azure Cosmos DB 계정을 만듭니다.
      • 기존 Azure Cosmos DB 계정은 복원에 사용할 수 없습니다.
      • 기본적으로 명명 <Azure_Cosmos_account_original_name>-restored<n> 된 새 Azure Cosmos DB 계정이 사용됩니다.
        • 원래 계정이 삭제된 경우 기존 이름을 다시 사용하는 등 이 이름을 조정할 수 있습니다.
    • 처리량이 데이터베이스 수준에서 프로비전되면 데이터베이스 수준에서 백업 및 복원이 수행됩니다.
      • 복원할 컨테이너의 하위 집합을 선택할 수 없습니다.
  • 연속 백업 모드를 사용하면 지난 30일 이내에 모든 시점으로 복원할 수 있습니다.
    • 복원 작업을 수행하여 1초 단위로 PITR(특정 시점)으로 돌아갈 수 있습니다.
    • 복원 작업에 사용할 수 있는 기간은 최대 30일입니다.
      • 리소스 인스턴스화 상태로 복원할 수도 있습니다.
    • 연속 백업은 Azure Cosmos DB 계정이 있는 모든 Azure 지역 내에서 수행됩니다.
      • 연속 백업은 가용성 영역 지원하는 지역 내에서 LRS(로컬 중복 스토리지) 또는 ZRS(영역 중복 스토리지)를 사용하여 각 Azure Cosmos DB 복제본과 동일한 Azure 지역 내에 저장됩니다.
    • 셀프 서비스 복원은 Azure Portal 또는 ARM 템플릿과 같은 IaC 아티팩트를 사용하여 수행할 수 있습니다.
    • 연속 백업에는 몇 가지 제한 사항이 있습니다 .
      • 연속 백업 모드는 현재 다중 지역 쓰기 구성에서 사용할 수 없습니다.
      • 현재는 NoSQL용 Azure Cosmos DB 및 MongoDB용 Azure Cosmos DB만 연속 백업에 대해 구성할 수 있습니다.
      • 컨테이너가 TTL을 구성한 경우 TTL을 초과한 복원된 데이터는 즉시 삭제될 수 있습니다.
    • 복원 작업은 특정 시점 복원에 대한 새 Azure Cosmos DB 계정을 만듭니다.
    • 연속 백업 및 복원 작업에 대한 추가 스토리지 비용이 있습니다.

• 기존 Azure Cosmos DB 계정은 주기적에서 연속으로 마이그레이션할 수 있지만 연속에서 주기적으로 마이그레이션할 수는 없습니다. 마이그레이션은 단방향이며 되돌릴 수 없습니다.

• 각 Azure Cosmos DB 백업은 프로비전된 처리량, 인덱싱 정책, 배포 지역 및 컨테이너 TTL 설정에 대한 데이터 자체 및 구성 세부 정보로 구성됩니다.

  • 백업에는 방화벽 설정, 가상 네트워크 액세스 제어 목록, 프라이빗 엔드포인트 설정, 일관성 설정(계정이 세션 일관성으로 복원됨), 저장 프로시저, 트리거, UDF 또는 다중 지역 설정이 포함되지 않습니다.
    • 고객은 기능 및 구성 설정을 다시 배포할 책임이 있습니다. Azure Cosmos DB 백업을 통해 복원되지 않습니다.
  • Azure Synapse Link 분석 저장소 데이터도 Azure Cosmos DB 백업에 포함되지 않습니다.

• 주기적 및 연속 접근 방식이 적합하지 않은 시나리오에 대해 사용자 지정 백업 및 복원 기능을 구현할 수 있습니다.

  • 사용자 지정 접근 방식은 상당한 비용과 추가 관리 오버헤드를 도입하며, 이를 이해하고 신중하게 평가해야 합니다.
    • 데이터 항목에서 계정, 데이터베이스, 컨테이너의 손상 또는 삭제와 같은 일반적인 복원 시나리오를 모델링해야 합니다.
    • 백업 확산을 방지하기 위해 하우스키핑 절차를 구현해야 합니다.
  • Azure Storage 또는 대체 데이터 기술(예: 대체 Azure Cosmos DB 컨테이너)을 사용할 수 있습니다.
    • Azure Storage 및 Azure Cosmos DB는 Azure Functions 및 Azure Data Factory와 같은 Azure 서비스와 네이티브 통합을 제공합니다.

• Azure Cosmos DB 설명서는 사용자 지정 백업을 구현하기 위한 두 가지 잠재적 옵션을 표시합니다.

  • 별도의 스토리지 시설에 데이터를 쓰도록 Azure Cosmos DB 변경 피드 입니다.
    • Azure 함수 또는 해당 애플리케이션 프로세스는 변경 피드 프로세서를 사용하여 변경 피드에 바인딩하고 항목을 스토리지에 처리합니다.
  • 변경 피드를 사용하여 연속 또는 정기(일괄 처리) 사용자 지정 백업을 모두 구현할 수 있습니다.
  • Azure Cosmos DB 변경 피드는 아직 삭제를 반영하지 않으므로 부울 속성 및 TTL을 사용하여 일시 삭제 패턴을 적용해야 합니다.
    • 변경 피드가 완전 충실도 업데이트를 제공하는 경우에는 이 패턴이 필요하지 않습니다.
  • Azure Cosmos DB 용 Azure Data Factory 커넥터(NoSQL 용 Azure Cosmos DB 또는 MongoDB API 커넥터) 데이터를 복사합니다.
    • ADF(Azure Data Factory)는 수동 실행 및 일정, 연속 창 및 이벤트 기반 트리거를 지원합니다.
      • 스토리지 및 Event Grid 둘 다에 대한 지원을 제공합니다.
    • ADF는 일괄 처리 지향 오케스트레이션으로 인해 주기적인 사용자 지정 백업 구현에 주로 적합합니다.
      • 오케스트레이션 실행 오버헤드로 인해 이벤트가 자주 발생하는 연속 백업 구현에는 적합하지 않습니다.
    • ADF는 높은 네트워크 보안 시나리오를 위해 Azure Private Link 를 지원합니다.

Azure Cosmos DB는 많은 Azure 서비스의 디자인 내에서 사용되므로 Azure Cosmos DB에 대한 상당한 지역 중단은 해당 지역 내의 다양한 Azure 서비스에 연속적인 영향을 미칩니다. 특정 서비스에 대한 정확한 영향은 기본 서비스 디자인에서 Azure Cosmos DB를 사용하는 방법에 따라 크게 달라집니다.

디자인 권장 구성

Azure Cosmos DB

• 요구 사항이 허용되는 기본 데이터 플랫폼으로 Azure Cosmos DB를 사용합니다.

• 중요 업무용 워크로드 시나리오의 경우 대기 시간을 줄이고 최대 중복성을 제공하도록 각 배포 지역 내에 쓰기 복제본을 사용하여 Azure Cosmos DB를 구성합니다.

  • 애플리케이션 부하, 성능 및 지역 RU/s 사용을 최적화하기 위해 쓰기 및 읽기에 로컬 Azure Cosmos DB 복제본 의 사용 우선 순위를 지정하도록 애플리케이션을 구성합니다.
  • 다중 지역 쓰기 구성은 상당한 비용으로 제공되며 최대 안정성이 필요한 워크로드 시나리오에 대해서만 우선 순위를 지정해야 합니다.

• 덜 중요한 워크로드 시나리오의 경우 전 세계적으로 분산된 읽기 복제본에서 단일 지역 쓰기 구성(가용성 영역 사용 시)의 사용 우선 순위를 지정합니다. 이는 높은 수준의 데이터 플랫폼 안정성(읽기의 경우 99.999% SLA, 쓰기 작업의 경우 99.995% SLA)을 보다 강력한 가격대에서 제공하므로 우선 순위를 지정합니다.

  • 로컬 Azure Cosmos DB 읽기 복제본을 사용하여 읽기 성능을 최적화하도록 애플리케이션을 구성합니다.

• 다중 지역 쓰기 구성에서 충돌 해결이 발생하고 모든 쓰기가 단일 지역 쓰기 구성에서 수행되는 최적의 '허브' 배포 지역을 선택합니다.

  • 주 지역을 선택할 때 다른 배포 지역과 관련된 대기 시간과 가용성 영역 지원과 같은 필수 기능을 기준으로 거리를 고려합니다.

• AZ를 지원하는 모든 배포 지역에서 AZ(가용성 영역) 중복성을 사용하여 Azure Cosmos DB를 구성하여 지역 내의 영역 오류에 대한 복원력을 보장합니다.

• 특히 성능 튜닝과 관련된 가장 포괄적인 기능 집합을 제공하므로 NoSQL용 Azure Cosmos DB를 사용합니다.

  • 대체 API는 주로 마이그레이션 또는 호환성 시나리오에 대해 고려해야 합니다.
    • 대체 API를 사용하는 경우 필요한 기능을 선택한 언어 및 SDK와 함께 사용할 수 있는지 확인하여 최적의 구성 및 성능을 보장합니다.

• 직접 연결 모드를 사용하여 네트워크 '홉' 수가 줄어드는 Azure Cosmos DB 노드에 대한 직접 TCP 연결을 통해 네트워크 성능을 최적화합니다.

Azure Cosmos DB SLA는 평균 실패한 요청을 계산하여 계산되며, 이는 99.999% 안정성 계층 오류 예산에 직접 부합하지 않을 수 있습니다. 따라서 99.999% SLO를 설계할 때 지역 및 다중 지역 Azure Cosmos DB 쓰기를 사용할 수 없도록 계획하여 후속 재생을 위한 지속형 메시지 큐와 같이 오류가 발생할 경우 대체 스토리지 기술이 배치되도록 하는 것이 중요합니다.

• 데이터 모델에 따라 데이터 배포를 최적화하기 위해 논리 파티션과 실제 파티션 모두에서 분할 전략을 정의합니다.

  • 파티션 간 쿼리를 최소화합니다.
  • 최적의 성능을 보장하기 위해 분할 전략을 반복적으로 테스트하고 유효성을 검사 합니다.

• 최적의 파티션 키를 선택합니다.

  • 컬렉션 내에서 파티션 키를 만든 후에는 변경할 수 없습니다.
  • 파티션 키는 변경되지 않는 속성 값이어야 합니다.
  • 카디널리티가 높은 파티션 키를 다양한 범위의 가능한 값으로 선택합니다.
  • 파티션 키는 RU 사용량과 데이터 스토리지를 모든 논리 파티션에 균등하게 분산하여 실제 파티션 간에 RU 사용량 및 스토리지 분산을 보장해야 합니다.
  • 분할된 열에 대해 읽기 쿼리를 실행하여 RU 사용량 및 대기 시간을 줄입니다.

• 인덱싱 은 성능에도 중요하므로 인덱스 제외를 사용하여 RU/s 및 스토리지 요구 사항을 줄여야 합니다.

  • 쿼리 내에서 필터링하는 데 필요한 필드만 인덱싱합니다. 가장 자주 사용되는 조건자의 디자인 인덱스입니다.

• Azure Cosmos DB SDK의 기본 제공 오류 처리, 재시도 및 광범위한 안정성 기능을 활용합니다.

  • 클라이언트의 SDK 내에서 재시도 논리를 구현합니다.

• 서비스 관리 암호화 키를 사용하여 관리 복잡성을 줄입니다.

  • 고객 관리형 키에 대한 특정 보안 요구 사항이 있는 경우 백업 및 회전과 같은 적절한 키 관리 절차가 적용되는지 확인합니다.

• 기본 제공 Azure Policy를 적용하여 Azure Cosmos DB 키 기반 메타데이터 쓰기 액세스를 사용하지 않도록 설정합니다.

• Azure Monitor를 사용하여 프로비전된 처리량(RU/s)과 같은 주요 메트릭 및 진단 로그를 수집할 수 있습니다.

  • Azure Monitor 운영 데이터를 애플리케이션 디자인 내의 Azure Cosmos DB 및 기타 글로벌 리소스 전용 Log Analytics 작업 영역으로 라우팅합니다.
  • Azure Monitor 메트릭을 사용하여 애플리케이션 트래픽 패턴이 자동 크기 조정에 적합한지 확인합니다.

• 애플리케이션 트래픽 패턴을 평가하여 프로비전된 처리량 유형에 대한 최적의 옵션을 선택합니다.

  • 자동 크기 조정 프로비전된 처리량을 고려하여 워크로드 수요를 자동으로 평준화합니다.

• Azure Cosmos DB에 대한 Microsoft 성능 팁을 평가하여 클라이언트 쪽 및 서버 쪽 구성을 최적화하여 대기 시간 및 처리량을 개선합니다.

• AKS를 컴퓨팅 플랫폼으로 사용하는 경우: 쿼리 집약적 워크로드의 경우 대기 시간 및 CPU 지터를 줄이기 위해 가속화된 네트워킹을 사용하도록 설정된 AKS 노드 SKU를 선택합니다.

• 단일 쓰기 지역 배포의 경우 자동 장애 조치(failover)를 위해 Azure Cosmos DB를 구성하는 것이 좋습니다.

• Azure Cosmos DB에 업데이트를 작성하는 시스템 흐름 내에서 비동기 비차단 메시징을 사용하는 부하 수준입니다.

  • 명령 및 쿼리 책임 분리 및 이벤트 소싱과 같은 패턴을 고려합니다.

• 지난 30일 동안 복구 지점의 세분성을 세분화하도록 연속 백업에 대한 Azure Cosmos DB 계정을 구성합니다.

  • 포함된 데이터 또는 Azure Cosmos DB 계정이 삭제되거나 손상된 시나리오에서 Azure Cosmos DB 백업을 사용하는 것이 좋습니다.
  • 반드시 필요한 경우가 아니면 사용자 지정 백업 방법을 사용하지 마세요.

• 표준 비즈니스 연속성 작업 준비의 일환으로 비프로덕션 리소스 및 데이터에 대한 복구 절차를 연습하는 것이 좋습니다.

• IaC 아티팩트를 정의하여 Azure Cosmos DB 백업 복원의 구성 설정 및 기능을 다시 설정합니다.

• Azure Cosmos DB 백업 및 복구에 대한 Azure 보안 기준 제어 지침을 평가하고 적용합니다.

  • BR-1: 정기적인 자동화된 백업 확인
  • BR-3: 고객 관리형 키를 포함한 모든 백업의 유효성 검사
  • BR-4, 키 손실 위험 완화

• 다중 지역 가용성이 필요한 분석 워크로드의 경우 최적화된 분석 쿼리에 열 형식을 적용하는 Azure Cosmos DB 분석 저장소를 사용합니다.

관계형 데이터 기술

관계형 데이터 모델 또는 기존 관계형 기술에 대한 종속성이 있는 시나리오의 경우 다중 지역 쓰기 구성에서 Azure Cosmos DB를 사용하는 것은 직접 적용되지 않을 수 있습니다. 이러한 경우에는 애플리케이션 디자인의 다중 지역 활성-활성 목표를 지원하도록 사용된 관계형 기술을 설계하고 구성해야 합니다.

Azure는 MySQL, PostgreSQL 및 MariaDB를 비롯한 일반적인 OSS 관계형 솔루션을 위해 Azure SQL Database 및 Azure Database를 비롯한 많은 관리형 관계형 데이터 플랫폼을 제공합니다. 따라서 이 섹션의 디자인 고려 사항 및 권장 사항은 안정성 및 글로벌 가용성을 최대화하기 위해 Azure SQL Database 및 Azure Database OSS 버전의 최적 사용량에 초점을 맞춥니다.

디자인 고려 사항

• 관계형 데이터 기술은 읽기 작업의 크기를 쉽게 조정하도록 구성할 수 있지만 일반적으로 쓰기는 확장성 및 성능에 상당한 제약을 주는 단일 주 인스턴스를 통과하도록 제한됩니다.

• 분할을 적용하여 여러 동일한 구조화된 데이터베이스에 데이터 및 처리를 분산하고 데이터베이스를 수평으로 분할하여 플랫폼 제약 조건을 탐색할 수 있습니다.

  • 예를 들어, 분할은 다중 테넌트 SaaS 플랫폼에 적용되어 테넌트 그룹을 고유한 데이터 플랫폼 구문으로 격리하는 경우가 많습니다.

Azure SQL Database

• Azure SQL Database는 SQL Server 데이터베이스 엔진과 기본 운영 체제의 안정적인 최신 버전에서 항상 실행되는 완전 관리형 데이터베이스 엔진을 제공합니다.

  • 성능 튜닝, 위협 모니터링 및 취약성 평가와 같은 지능형 기능을 제공합니다.

• Azure SQL Database는 Azure 지역에 읽기 복제본을 배포하는 기본 제공 지역 고가용성 및 턴키 지역 복제를 제공합니다.

  • 지역 복제를 사용하면 장애 조치(failover)가 시작될 때까지 보조 데이터베이스 복제본이 읽기 전용으로 유지됩니다.
  • 동일하거나 다른 지역에서 최대 4개의 보조 복제본이 지원됩니다.
  • 읽기 전용 쿼리 액세스에 보조 복제본을 사용하여 읽기 성능을 최적화할 수도 있습니다.
  • 장애 조치(failover)는 수동으로 시작해야 하지만 자동화된 운영 절차로 래핑할 수 있습니다.

• Azure SQL Database는 보조 서버에 데이터베이스를 복제하고 오류가 발생한 경우 투명한 장애 조치(failover)를 허용하는 자동 장애 조치(failover) 그룹을 제공합니다.

  • 자동 장애 조치(failover) 그룹은 그룹의 모든 데이터베이스를 다른 지역에 있는 하나의 보조 서버 또는 인스턴스로만 지역 복제할 수 있도록 지원합니다.
  • 자동 장애 조치(failover) 그룹은 현재 하이퍼스케일 서비스 계층에서 지원되지 않습니다.
  • 보조 데이터베이스를 사용하여 읽기 트래픽을 오프로드할 수 있습니다.

• 프리미엄 또는 중요 비즈니스용 서비스 계층 데이터베이스 복제본은 추가 비용 없이 가용성 영역 분산할 수 있습니다.

  • 또한 제어 링은 세 개의 GW(게이트웨이 링)로 여러 영역에 걸쳐 복제됩니다.
    • 특정 게이트웨이 링에 대한 라우팅은 Azure Traffic Manager에서 제어됩니다.
  • 중요 비즈니스용 계층을 사용하는 경우 영역 중복 구성은 5세대 컴퓨팅 하드웨어를 선택한 경우에만 사용할 수 있습니다.

• Azure SQL Database는 모든 서비스 계층에서 기준 99.99% 가용성 SLA를 제공하지만 가용성 영역을 지원하는 지역의 중요 비즈니스용 또는 프리미엄 계층에 대해 더 높은 99.995% SLA를 제공합니다.

  • 영역 중복 배포에 대해 구성되지 않은 Azure SQL Database 중요 비즈니스용 또는 프리미엄 계층의 가용성 SLA는 99.99%입니다.

• 지역 복제로 구성된 경우 Azure SQL Database 중요 비즈니스용 계층은 배포된 시간의 100%에 대해 30초의 RTO(복구 시간 목표)를 제공합니다.

• 지역 복제로 구성된 경우 Azure SQL Database 중요 비즈니스용 계층에는 배포된 시간의 100%에 대해 5초의 RPO(복구 지점 목표)가 있습니다.

• 둘 이상의 복제본으로 구성된 Azure SQL Database 하이퍼스케일 계층의 가용성 SLA는 99.99%입니다.

• 예약 할인을 사용하여 Azure SQL Database와 연결된 컴퓨팅 비용을 줄일 수 있습니다.

  • DTU 기반 데이터베이스에 예약된 용량을 적용할 수 없습니다.

• 지정 시간 복원 을 사용하여 데이터베이스 및 포함된 데이터를 이전 시점으로 반환할 수 있습니다.

• 지역 복원 을 사용하여 지역 중복 백업에서 데이터베이스를 복구할 수 있습니다.

Azure Database For PostgreSQL

• Azure Database for PostgreSQL은 세 가지 배포 옵션으로 제공됩니다.

  • 단일 서버, SLA 99.99%
  • 가용성 영역 중복성을 제공하는 유연한 서버, SLA 99.99%
  • 하이퍼스케일(Citus), 고가용성 모드를 사용하는 경우 SLA 99.95%

• 하이퍼스케일(Citus) 은 애플리케이션을 변경하지 않고 분할을 통해 동적 확장성을 제공합니다.

  • 여러 PostgreSQL 서버에 테이블 행을 분산하는 것은 하이퍼스케일(Citus)에서 확장 가능한 쿼리를 보장하는 데 중요합니다.
  • 여러 노드는 기존 데이터베이스보다 더 많은 데이터를 집합적으로 보유할 수 있으며, 대부분의 경우 작업자 CPU를 병렬로 사용하여 비용을 최적화할 수 있습니다.

• 변경되는 트래픽 패턴에 대응하여 탄력성을 보장하기 위해 Runbook 자동화를 통해 자동 크기 조정을 구성할 수 있습니다.

• 유연한 서버는 서버를 중지/시작하는 기능과 연속 컴퓨팅 용량이 필요하지 않은 워크로드에 적합한 버스트 가능한 컴퓨팅 계층을 통해 비프로덕션 워크로드에 대한 비용 효율성을 제공합니다.

• 프로비전된 총 서버 스토리지의 최대 100%에 대한 백업 스토리지에 대한 추가 요금은 없습니다.

  • 백업 스토리지의 추가 사용량은 소비된 GB/월에 따라 청구됩니다.

• 단일 서버 예약 할인 또는 하이퍼스케일(Citus) 예약 할인을 사용하여 Azure Database for PostgreSQL과 관련된 컴퓨팅 비용을 줄일 수 있습니다.

디자인 권장 구성

• 다양한 애플리케이션과 데이터 컨텍스트를 기반으로 관계형 데이터베이스를 분할하는 분할을 고려하여 플랫폼 제약 조건을 탐색하고 확장성과 가용성을 최대화하며 오류 격리를 지원합니다.

  • 이 권장 사항은 관계형 기술 제약 조건이 전역적으로 분산된 데이터 플랫폼을 크게 방해할 수 있으므로 애플리케이션 디자인에서 3개 이상의 Azure 지역을 고려할 때 특히 널리 사용됩니다.
  • 분할은 모든 애플리케이션 시나리오에 적절하지 않으므로 상황에 맞는 평가가 필요합니다.

• Azure 플랫폼의 성숙도와 광범위한 안정성 기능으로 인해 관계형 요구 사항이 존재하는 Azure SQL Database 사용에 우선 순위를 둡니다.

Azure SQL Database

• 중요 비즈니스용 서비스 계층을 사용하여 중요한 복원력 기능에 대한 액세스를 포함하여 안정성과 가용성을 최대화합니다.

• vCore 기반 소비 모델을 사용하여 워크로드 볼륨 및 처리량 요구 사항에 맞게 컴퓨팅 및 스토리지 리소스를 독립적으로 선택할 수 있습니다.

  • 컴퓨팅 및 스토리지 리소스 요구 사항을 알리기 위해 정의된 용량 모델이 적용되는지 확인합니다.
    • 잠재적인 비용 최적화를 제공하려면 예약된 용량을 고려하세요.

• 동일한 지역 내의 중요 비즈니스용 데이터베이스 복제본을 가용성 영역 분산하도록 영역 중복 배포 모델을 구성합니다.

• 활성 지역 복제를 사용하여 모든 배포 지역 내에서 읽을 수 있는 복제본을 배포합니다(최대 4개).

• 자동 장애 조치(failover) 그룹을 사용하여 읽기 최적화 및 데이터베이스 중복성을 위해 추가 배포 지역에 복제를 제공하기 위해 지역 복제가 적용된 보조 지역에 투명한 장애 조치(failover)를 제공합니다.

  • 두 개의 배포 지역으로만 제한된 애플리케이션 시나리오에서는 자동 장애 조치(failover) 그룹 사용이 우선시되어야 합니다.

• 자동 장애 조치(failover) 그룹 내의 주 및 보조에 영향을 미치는 오류가 발생하는 경우 지역 복제 인스턴스에 대한 장애 조치(failover)를 수행하려면 애플리케이션 상태 모델에 맞게 조정된 경고에 따라 자동화된 운영 트리거를 고려합니다.

Important

4개 이상의 배포 지역을 고려하는 애플리케이션의 경우 Azure Cosmos DB와 같은 다중 지역 쓰기 기술을 지원하기 위해 애플리케이션 범위 분할 또는 리팩터링에 대해 진지하게 고려해야 합니다. 그러나 애플리케이션 워크로드 시나리오 내에서 이것이 가능하지 않은 경우 단일 지리 내의 지역을 보다 균등하게 분산된 읽기 액세스로 지역 복제 인스턴스를 포함하는 기본 상태로 승격하는 것이 좋습니다.

• 읽기 성능을 최적화하기 위해 읽기 쿼리에 대한 복제본 인스턴스를 쿼리하도록 애플리케이션을 구성합니다.

• Azure SQL DB의 거의 실시간 운영 인사이트를 위해 Azure Monitor 및 Azure SQL Analytics 를 사용하여 안정성 인시던트를 검색합니다.

• Azure Monitor를 사용하여 모든 데이터베이스의 사용량을 평가하고 크기가 적절하게 지정되었는지 확인합니다.

  • 적절한 데이터 플랫폼 동작의 유효성을 검사하기 위해 CD 파이프라인이 대표적인 부하 수준에서 부하 테스트를 고려하는지 유효성을 검사합니다.

• 모니터링 및 경고를 사용하여 적절한 경우 자동화된 운영 작업을 추진하여 비즈니스 요구 사항 및 리소스 사용률을 기준으로 상태를 관찰하도록 데이터베이스 구성 요소에 대한 상태 메트릭을 계산합니다 .

  • 서비스 성능 저하가 발생할 때 신속한 조치를 취할 수 있도록 키 쿼리 성능 메트릭이 통합되었는지 확인합니다.

• Query Performance Insights 및 Microsoft에서 제공하는 일반적인 성능 권장 사항을 사용하여 쿼리, 테이블 및 데이터베이스를 최적화합니다.

• SDK를 사용하여 재시도 논리 를 구현하여 Azure SQL Database 연결에 영향을 미치는 일시적인 오류를 완화합니다.

• 미사용 데이터 암호화에 TDE(서버 쪽 투명한 데이터 암호화)를 적용할 때 서비스 관리형 키의 사용 우선 순위를 지정합니다.

  • 고객 관리형 키 또는 클라이언트 쪽(AlwaysEncrypted) 암호화가 필요한 경우 백업 및 자동화된 회전 기능을 사용하여 키가 적절하게 복원되도록 합니다.

• 특정 시점 복원을 운영 플레이북으로 사용하여 심각한 구성 오류를 복구하는 것이 좋습니다.

Azure Database For PostgreSQL

• 유연한 서버는 가용성 영역 지원으로 인해 중요 비즈니스용 워크로드에 사용하는 것이 좋습니다.

• 중요 비즈니스용 워크로드에 하이퍼스케일(Citus)을 사용하는 경우 고가용성 모드에서 99.95% SLA 보증을 받도록 설정합니다.

• 하이퍼스케일(Citus) 서버 구성을 사용하여 여러 노드에서 가용성을 최대화합니다.

• 데이터 플랫폼 내에서 컴퓨팅 및 스토리지 리소스 요구 사항을 알리기 위해 애플리케이션에 대한 용량 모델을 정의합니다.

  • 잠재적인 비용 최적화를 제공하려면 하이퍼스케일(Citus) 예약 할인 을 고려하세요.

핫 계층 데이터에 대한 캐싱

메모리 내 캐싱 계층을 적용하여 읽기 처리량을 크게 늘리고 핫 계층 데이터 시나리오에 대한 엔드투엔드 클라이언트 응답 시간을 개선하여 데이터 플랫폼을 향상시킬 수 있습니다.

Azure는 데이터 플랫폼 읽기 액세스를 추상화하고 최적화하기 위해 Azure Cache for Redis를 배치하여 주요 데이터 구조를 캐싱하기 위한 적용 가능한 기능을 제공하는 여러 서비스를 제공합니다. 따라서 이 섹션에서는 추가 읽기 성능 및 데이터 액세스 내구성이 필요한 시나리오에서 Azure Cache for Redis의 최적 사용량에 초점을 맞춥니다.

디자인 고려 사항

• 캐싱 계층은 기본 데이터 기술에 영향을 주는 중단이 발생하더라도 캐싱 계층을 통해 애플리케이션 데이터 스냅샷에 계속 액세스할 수 있으므로 추가 데이터 액세스 내구성을 제공합니다.

• 특정 워크로드 시나리오에서는 애플리케이션 플랫폼 자체 내에서 메모리 내 캐싱을 구현할 수 있습니다.

Azure Cache for Redis

• Redis cache는 오픈 소스 NoSQL 키-값 메모리 내 스토리지 시스템입니다.

• 엔터프라이즈 및 엔터프라이즈 플래시 계층은 지역 복제를 통해 지역 및 다른 Azure 지역 내 가용성 영역 걸쳐 활성-활성 구성으로 배포할 수 있습니다.

  • 모든 캐시 인스턴스에 대해 활성 지역 복제가 활성화된 상태에서 각 지역에 3개 이상의 Azure 지역 및 3개 이상의 가용성 영역 배포된 경우 Azure Cache for Redis는 하나의 지역 캐시 엔드포인트에 연결하기 위해 99.999%의 SLA를 제공합니다.
  • 단일 Azure 지역 내의 세 가용성 영역 배포되는 경우 99.99% 연결 SLA가 제공됩니다.

• 엔터프라이즈 플래시 계층은 RAM과 플래시 비휘발성 메모리 스토리지의 조합으로 실행되며, 이로 인해 성능 저하가 적어지지만 클러스터링으로 최대 13TB의 매우 큰 캐시 크기를 사용할 수 있습니다.

• 지역 복제를 사용하면 캐시 인스턴스와 관련된 직접 비용 외에 지역 간 데이터 전송에 대한 요금도 적용됩니다.

• 예약된 업데이트 기능에는 기본 VM 운영 체제에 적용된 Azure 업데이트 또는 업데이트가 포함되지 않습니다.

• 데이터가 새 인스턴스로 마이그레이션되는 동안 스케일 아웃 작업 중에 CPU 사용률이 증가합니다.

디자인 권장 구성

• 읽기 처리량을 늘리고 응답 시간을 개선하려면 '핫' 데이터 시나리오에 최적화된 캐싱 계층을 고려합니다.

• 데이터 폭증을 방지하려면 캐시 만료 및 관리에 적절한 정책을 적용합니다.

  • 지원 데이터가 변경되면 캐시 항목 만료를 고려합니다.

Azure Cache for Redis

• Premium 또는 Enterprise SKU를 사용하여 안정성 및 성능을 최대화합니다.

  • 데이터 볼륨이 매우 큰 시나리오에서는 Enterprise Flash 계층을 고려해야 합니다.
  • 수동 지역 복제만 필요한 시나리오에서는 프리미엄 계층도 고려할 수 있습니다.

• 고려되는 모든 배포 지역에 걸쳐 활성 구성에서 지역 복제를 사용하여 복제본 인스턴스를 배포합니다.

• 복제본 인스턴스가 각 Azure 지역 내에서 가용성 영역 배포되는지 확인합니다.

• Azure Monitor를 사용하여 Azure Cache for Redis를 평가합니다.

  • 지역 캐시 구성 요소의 상태 점수를 계산하여 비즈니스 요구 사항 및 리소스 사용률을 기준으로 상태를 관찰합니다.
  • 높은 CPU, 높은 메모리 사용량, 높은 서버 부하 및 제거된 키와 같은 주요 메트릭을 관찰하고 경고하여 캐시 크기를 조정할 때 인사이트를 얻습니다.

• 재시도 논리, 시간 제한을 구현하고 Redis 연결 멀티플렉서의 싱글톤 구현을 사용하여 연결 복원력을 최적화합니다.

• 예약된 업데이트를 구성 하여 Redis Server 업데이트 가 캐시에 적용되는 날짜 및 시간을 규정합니다.

분석 시나리오

중요 업무용 애플리케이션에서 분석 시나리오를 포괄 데이터 흐름에서 추가 가치를 유도하는 수단으로 고려하는 것이 점점 더 일반적입니다. 따라서 AIOps(애플리케이션 및 운영) 분석 시나리오는 매우 신뢰할 수 있는 데이터 플랫폼의 중요한 측면을 형성합니다.

분석 및 트랜잭션 워크로드에는 각 컨텍스트 내에서 허용되는 성능을 위해 다양한 데이터 플랫폼 기능과 최적화가 필요합니다.

설명	분석	거래
사용 사례	매우 많은 양의 데이터 분석("빅 데이터")	매우 많은 양의 개별 트랜잭션 처리
최적화 기준	여러 레코드에 대한 쿼리 및 집계 읽기	몇 개의 레코드에 대한 CRUD(거의 실시간 만들기/읽기/업데이트/삭제) 쿼리
주요 특징	- 레코드의 데이터 원본에서 통합 - 열 기반 스토리지 - 분산 스토리지 - 병렬 처리 -비 정규화 된 - 낮은 동시성 읽기 및 쓰기 - 압축을 사용하여 스토리지 볼륨 최적화	- 애플리케이션에 대한 레코드의 데이터 원본 - 행 기반 스토리지 - 연속 스토리지 - 대칭 처리 -정규화 된 - 높은 동시성 읽기 및 쓰기, 인덱스 업데이트 - 메모리 내 스토리지를 사용하여 빠른 데이터 액세스 최적화

Azure Synapse는 Azure Cosmos DB와 같은 Azure 서비스와 기본 제공 통합을 사용하여 빅 데이터 분석을 용이하게 하는 Spark 기술과 관계형 및 비관계형 데이터를 결합하는 엔터프라이즈 분석 플랫폼을 제공합니다. 따라서 이 섹션의 디자인 고려 사항 및 권장 사항은 분석 시나리오에 대한 최적의 Azure Synapse 및 Azure Cosmos DB 사용량에 초점을 맞춥니다.

디자인 고려 사항

• 일반적으로 대규모 분석 시나리오는 후속 분석 쿼리에 최적화된 별도의 데이터 플랫폼으로 데이터를 추출하여 촉진됩니다.
  • ETL(추출, 변환 및 로드) 파이프라인은 데이터를 추출하는 데 사용되며 처리량을 사용하고 트랜잭션 워크로드 성능에 영향을 줍니다.
  • 처리량 및 성능 영향을 줄이기 위해 ETL 파이프라인을 자주 실행하면 분석 데이터가 최신 상태가 되지 않습니다.
  • 데이터 변환이 복잡해짐에 따라 ETL 파이프라인 개발 및 유지 관리 오버헤드가 증가합니다.
    • 예를 들어 원본 데이터가 자주 변경되거나 삭제되는 경우 ETL 파이프라인은 분석 데이터에 대한 추가/버전 관리 방식, 덤프 및 다시 로드 또는 현재 위치 변경 내용을 통해 분석 쿼리에 대한 대상 데이터의 변경 내용을 고려해야 합니다. 이러한 각 방법은 인덱스 다시 생성 또는 업데이트와 같은 파생 영향을 줍니다.

Azure Cosmos DB

• Azure Cosmos DB 트랜잭션 데이터에서 실행되는 분석 쿼리는 일반적으로 대량의 데이터에 대한 파티션 간에 집계되며, 상당한 RU(요청 단위) 처리량을 소비하므로 주변 트랜잭션 워크로드의 성능에 영향을 줄 수 있습니다.

• Azure Cosmos DB 분석 저장소는 Azure Cosmos DB 트랜잭션 워크로드에 영향을 주지 않고 Azure Synapse의 Azure Cosmos DB 데이터에 대한 대규모 분석을 가능하게 하는 완전히 격리된 스키마화된 열 지향 데이터 저장소 를 제공합니다.

  • Azure Cosmos DB 컨테이너를 분석 저장소로 사용하도록 설정하면 컨테이너의 운영 데이터에서 새 열 저장소가 내부적으로 만들어집니다. 이 열 저장소는 컨테이너에 대한 행 지향 트랜잭션 저장소와 별도로 유지됩니다.
  • 운영 데이터에 대한 만들기, 업데이트 및 삭제 작업은 분석 저장소에 자동으로 동기화되므로 변경 피드 또는 ETL 처리가 필요하지 않습니다.
  • 운영에서 분석 저장소로의 데이터 동기화는 컨테이너 또는 데이터베이스에 프로비전된 처리량 RU(요청 단위)를 사용하지 않습니다. 트랜잭션 워크로드에는 성능에 영향을 주지 않습니다. 분석 저장소는 Azure Cosmos DB 데이터베이스 또는 컨테이너에 추가 RU를 할당할 필요가 없습니다.
  • 자동 동기화는 운영 데이터 변경 내용이 분석 저장소에 자동으로 동기화되는 프로세스입니다. 자동 동기화 대기 시간은 일반적으로 2분 미만입니다.
    • 자동 동기화 대기 시간은 공유 처리량과 많은 수의 컨테이너가 있는 데이터베이스의 경우 최대 5분이 될 수 있습니다.
    • 자동 동기화가 완료되는 즉시 Azure Synapse에서 최신 데이터를 쿼리할 수 있습니다.
  • 분석 저장소 스토리지는 데이터 볼륨 및 읽기 및 쓰기 작업 수에 대한 요금을 부과하는 소비 기반 가격 책정 모델을 사용합니다. 분석 저장소 가격 책정은 트랜잭션 저장소 가격 책정과는 별개입니다.

• Azure Synapse Link를 사용하여 Azure Cosmos DB 분석 저장소를 Azure Synapse에서 직접 쿼리할 수 있습니다. 이렇게 하면 Synapse에서 HTAP(하이브리드 트랜잭션 분석 처리)가 없는 ETL을 사용할 수 있으므로 Azure Cosmos DB 데이터를 거의 실시간으로 Synapse의 다른 분석 워크로드와 함께 쿼리할 수 있습니다.

• Azure Cosmos DB 분석 저장소는 기본적으로 분할되지 않습니다.

  • 특정 쿼리 시나리오의 경우 쿼리 조건자에서 자주 사용되는 키를 사용하여 분석 저장소 데이터를 분할하여 성능이 향상됩니다.
  • 분할은 Synapse Link를 사용하여 Spark Notebook을 실행하는 Azure Synapse의 작업에 의해 트리거됩니다. 이 작업은 Azure Cosmos DB 분석 저장소에서 데이터를 로드하고 Synapse 작업 영역의 기본 스토리지 계정에 있는 Synapse 분할된 저장소에 씁니다.

• Azure Synapse Analytics SQL Serverless 풀은 자동으로 업데이트된 뷰 또는 명령을 통해 SELECT / OPENROWSET 분석 저장소를 쿼리할 수 있습니다.

• Azure Synapse Analytics Spark 풀은 자동으로 업데이트된 Spark 테이블 또는 명령을 통해 분석 저장소 를 쿼리할 spark.read 수 있습니다.

• Spark 를 사용하여 Azure Cosmos DB 분석 저장소에서 전용 Synapse SQL 풀로 데이터를 복사할 수도 있으므로 프로비전된 Azure Synapse SQL 풀 리소스를 사용할 수 있습니다.

• Azure Cosmos DB 분석 저장소 데이터는 Azure Synapse Spark를 사용하여 쿼리할 수 있습니다.

  • Spark Notebook을 사용하면 Spark 데이터 프레임 조합을 사용하여 다른 데이터 집합으로 Azure Cosmos DB 분석 데이터를 집계 및 변환하고, 변환된 데이터를 다른 저장소에 쓰거나 AIOps Machine Learning 모델을 학습하는 등 다른 고급 Synapse Spark 기능을 사용할 수 있습니다.

• Azure Cosmos DB 변경 피드를 사용하여 분석 시나리오에 대해 별도의 보조 데이터 저장소를 유지 관리할 수도 있습니다.

Azure Synapse

• Azure Synapse 는 로그 및 시계열 분석을 위한 SQL 데이터 웨어하우징, Spark 빅 데이터 및 데이터 탐색기를 비롯한 분석 기능을 함께 제공합니다.

  • Azure Synapse는 연결된 서비스를 사용하여 Azure Storage와 같은 다른 서비스에 대한 연결을 정의합니다.
  • 지원되는 원본에서 복사 작업 통해 Synapse Analytics로 데이터를 수집할 수 있습니다. 이렇게 하면 원본 데이터 저장소에 영향을 주지 않고 Synapse에서 데이터 분석을 수행할 수 있지만 데이터 전송으로 인한 시간, 비용 및 대기 시간 오버헤드가 추가됩니다.
  • 지원되는 외부 저장소에서 데이터를 현재 위치에서 쿼리하여 데이터 수집 및 이동의 오버헤드를 방지할 수도 있습니다. Data Lake Gen2를 사용하는 Azure Storage는 Synapse에 지원되는 저장소이며 , Log Analytics에서 내보낸 데이터는 Synapse Spark를 통해 쿼리할 수 있습니다.

• Azure Synapse Studio 는 수집 및 쿼리 작업을 통합합니다.

  • Azure Cosmos DB 분석 저장소 데이터 및 Log Analytics 내보내기 데이터를 포함한 원본 데이터는 비즈니스 인텔리전스 및 기타 집계된 분석 사용 사례를 지원하기 위해 쿼리 및 처리됩니다.

디자인 권장 구성

• 분석 워크로드가 트랜잭션 애플리케이션 워크로드에 영향을 주지 않도록 하여 트랜잭션 성능을 유지합니다.

Application Analytics

• Azure Cosmos DB 분석 저장소와 함께 Azure Synapse Link를 사용하여 트랜잭션 성능에 영향을 주지 않는 최적화된 데이터 저장소를 만들어 Azure Cosmos DB 운영 데이터에 대한 분석을 수행합니다.

  • Azure Cosmos DB 계정에서 Azure Synapse Link를 사용하도록 설정합니다.
  • 분석 저장소에 사용하도록 설정된 컨테이너를 만들거나 분석 저장소에 대한 기존 컨테이너를 사용하도록 설정합니다.
  • Azure Synapse 작업 영역을 Azure Cosmos DB 분석 저장소 에 연결하여 Azure Synapse의 분석 워크로드가 Azure Cosmos DB 데이터를 쿼리할 수 있도록 합니다. 읽기 전용 Azure Cosmos DB 키와 함께 연결 문자열 사용합니다.

• Azure Cosmos DB 변경 피드를 사용하여 분석 데이터 저장소를 유지하는 대신 Azure Synapse Link를 사용하여 Azure Cosmos DB 분석 저장소의 우선 순위를 지정합니다.

  • Azure Cosmos DB 변경 피드는 매우 간단한 분석 시나리오에 적합할 수 있습니다.

AIOps 및 운영 분석

• 리소스의 운영 데이터가 전송되는 각 원본 Azure Storage 계정에 대해 연결된 서비스 및 데이터 집합을 사용하여 단일 Azure Synapse 작업 영역을 만듭니다.

• 전용 Azure Storage 계정을 만들고 이를 작업 영역 기본 스토리지 계정으로 사용하여 Synapse 작업 영역 카탈로그 데이터 및 메타데이터를 저장합니다. Azure Data Lake Gen2를 사용하도록 계층 구조 네임스페이스를 사용하여 구성합니다.

  • 원본 분석 데이터와 Synapse 작업 영역 데이터와 메타데이터 간의 분리를 유지합니다.
    • 운영 데이터가 전송되는 지역 또는 글로벌 Azure Storage 계정 중 하나를 사용하지 마세요.

다음 단계

네트워킹 고려 사항에 대한 고려 사항을 검토합니다.

네트워크 및 연결