다음을 통해 공유

클라우드의 새 DBA - 마이그레이션 후 Azure SQL Database 관리

  • 아티클

적용 대상: Azure SQL Database

기존의 자체 관리형 및 자체 제어 환경에서 PaaS 환경으로 전환하는 것은 처음에는 약간 부담스러울 수 있습니다. 앱 개발자 또는 DBA는 애플리케이션을 언제나 사용 가능하고, 성능이 뛰어나고, 안전하고, 복원력이 있게 유지하는 데 도움이 되는 플랫폼의 코어 기능을 알아야 할 것입니다. 이 문서의 목적이 바로 그것입니다. 이 문서는 리소스를 간결하게 구성하며 단일 데이터베이스 및 풀링된 데이터베이스로 Azure SQL Database의 주요 기능을 사용하여 클라우드에서 애플리케이션이 효율적으로 실행되도록 관리 및 유지하고 최적의 결과를 달성하는 최선의 방법에 관한 몇 가지 지침을 제공합니다. 이 문서의 일반적인 대상 그룹은 다음과 같은 사용자입니다.

  • Azure SQL Database로 애플리케이션 마이그레이션을 평가 중인 경우 - 애플리케이션 현대화.
  • 애플리케이션을 마이그레이션하는 과정에 있는 경우 - 상시적인 마이그레이션 시나리오.
  • 최근에 Azure SQL Database로 마이그레이션을 완료한 경우 - 클라우드의 새 DBA

이 문서에서는 탄력적 풀에서 단일 데이터베이스 및 풀링된 데이터베이스로 작업할 때 쉽게 사용할 수 있는 플랫폼으로서 Azure SQL Database의 핵심 특성 중 일부에 대해 설명합니다. 이는 다음과 같습니다.

  • Azure Portal을 통해 데이터베이스 모니터링
  • 비즈니스 연속성 및 재해 복구(BCDR)
  • 보안 및 규정 준수
  • 지능형 데이터베이스 모니터링 및 유지 관리
  • 데이터 이동

참고 항목

Microsoft Entra ID는 이전에 Azure Active Directory(Azure AD)로 알려졌습니다.

Azure Portal을 통해 데이터베이스 모니터링

권장되는 경고 규칙을 포함한 Azure Monitor 메트릭 및 경고는 메트릭 및 경고를 사용하여 Azure SQL Database 모니터링을 참조하세요. 서비스 계층에 대한 자세한 내용은 DTU 기반 구매 모델 및 vCore 기반 구매 모델 문서를 참조하세요.

성능 메트릭에 대한 경고를 구성할 수도 있습니다. 메트릭 창에서 경고 추가 단추를 선택합니다. 마법사에 따라 경고를 구성합니다. 메트릭이 특정 임계값을 초과하거나 특정 임계값 아래로 떨어지는 경우 경고를 보내는 옵션이 있습니다.

예를 들어 데이터베이스의 워크로드가 증가할 것으로 예상하는 경우 데이터베이스가 성능 메트릭 중 어느 것에서라도 80%에 도달할 때마다 이메일 경고를 구성하도록 선택할 수 있습니다. 이를 조기 경고로 사용하여 한 단계 높은 컴퓨팅 크기로 전환해야 하는 시기를 파악할 수 있습니다.

성능 메트릭은 더 낮은 컴퓨팅 크기로 다운그레이드해야 하는지 여부를 판단하는 데 도움이 될 수도 있습니다. 그러나 더 낮은 컴퓨팅 크기로 전환을 결정하기 전에 워크로드가 급증하거나 변동하는 것에 유의하세요.

비즈니스 연속성 및 재해 복구(BCDR)

비즈니스 연속성 및 재해 복구 기능을 사용하면 재해 발생 시에도 평소와 같이 비즈니스를 계속할 수 있습니다. 재해는 데이터베이스 수준 이벤트(예: 누군가가 실수로 중요한 테이블을 삭제하는 경우) 또는 데이터 센터 수준 이벤트(쓰나미와 같은 지역적 재해)일 수 있습니다.

SQL Database에서 백업을 만들고 관리하려면 어떻게 해야 하나요?

Azure SQL Database에 백업을 만들지는 않으며 그럴 필요가 없습니다. SQL Database는 자동으로 데이터베이스를 백업하므로 백업 예약, 사용, 관리에 대해 더 이상 걱정할 필요가 없습니다. 이 플랫폼은 매주 전체 백업, 몇 시간마다 차등 백업, 5분마다 로그 백업을 수행하여 효율적인 재해 복구를 지원하며 데이터 손실을 최소화합니다. 첫 번째 전체 백업은 데이터베이스를 생성하자마자 이루어집니다. 이러한 백업은 “보존 기간”이라고 하는 특정 기간 동안 사용할 수 있으며, 선택한 서비스 계층에 따라 달라집니다. SQL Database는 PITR(지정 시간 복구)을 사용하여 이 보존 기간 내의 특정 시점으로 복원하는 기능을 제공합니다.

LTR(장기 보존) 기능을 사용하면 백업 파일을 최대 10년까지 훨씬 오랜 기간 동안 보관할 수 있으며, 해당 기간 내에 언제든지 백업의 데이터를 복원할 수 있습니다. 뿐만 아니라 데이터베이스 백업은 지역적으로 복제된 스토리지에 보관되어 지역적 재해로부터 복원력을 보장합니다. 또한 이러한 백업을 보존 기간 내의 어느 시점이든 Azure 지역에서 복원할 수 있습니다. 자세한 내용은 무중단 업무 방식 개요를 참조하세요.

데이터 센터 수준의 재해 또는 지역 재난 발생 시 비즈니스 연속성을 보장하려면 어떻게 해야 하나요?

데이터베이스 백업은 지역 재해가 발생 시 다른 Azure 지역으로 백업을 복원할 수 있도록 지역적으로 복제된 스토리지에 저장됩니다. 이를 지역 복원이라고 합니다. 지역 복원의 RPO(복구 지점 목표)는 일반적으로 < 1시간 미만이며 ERT(예상 복구 시간)는 수 분에서 수 시간까지입니다.

중요 업무용 데이터베이스의 경우 Azure SQL Database는 활성 지역 복제를 제공하여 다른 지역에 원본 데이터베이스의 지역 복제 보조 복사본을 생성합니다. 예를 들어 데이터베이스가 처음에 Azure 미국 서부 지역에서 호스트되고 지역 재해 복원력을 원하는 경우 미국 서부에서 미국 동부로 데이터베이스의 활성 지역 복제본(replica)를 만듭니다. 미국 서부에서 재난이 발생한 경우 미국 동부 지역으로 장애 조치(failover)할 수 있습니다.

활성 지역 복제 외에도 장애 조치(failover) 그룹은 데이터베이스 그룹의 복제 및 장애 조치(failover)를 편리하게 관리하는 방법을 제공합니다. 동일하거나 다른 지역에 있는 여러 데이터베이스를 포함하여 장애 조치(failover) 그룹을 만들 수 있습니다. 그런 다음 장애 조치(failover) 그룹의 모든 데이터베이스를 보조 지역으로 장애 조치(failover)를 시작할 수 있습니다. 자세한 내용은 장애 조치(failover) 그룹을 참조하세요.

데이터 센터 또는 가용성 영역 장애에 대한 복원력을 구현하려면 데이터베이스 또는 Elastic Pool에 대해 영역 중복이 사용 설정되어 있는지 확인합니다.

재해 대비를 위해 애플리케이션을 적극적으로 모니터링하고 보조 애플리케이션으로 장애 조치(failover)를 시작합니다. 서로 다른 Azure 지역에 이러한 활성 지역 복제본(replica)을 최대 4개까지 만들 수 있습니다. 장점은 이것뿐만이 아닙니다. 또한 읽기 전용 액세스를 위해 이러한 두 번째 활성 지역 복제본에 액세스할 수도 있습니다. 이는 지역적으로 분산된 애플리케이션 시나리오의 대기 시간을 줄이는 데 매우 유용합니다.

SQL Database에서의 재해 복구는 어떻게 이뤄지나요?

활성 지역 복제 또는 장애 조치(failover) 그룹을 사용하는 경우 Azure SQL Database에서 몇 단계만으로 재해 복구를 구성하고 관리할 수 있습니다. 다만 계속해서 지역 재해 대비를 위해 애플리케이션 및 해당 데이터베이스를 모니터링하고 보조 지역으로 장애 조치(failover)하여 비즈니스 연속성을 복원해야 합니다.

자세한 내용은 Azure SQL Database 재해 복구 101을 참조하세요.

보안 및 규정 준수

SQL Database는 보안 및 개인 정보 보호를 매우 중대하게 생각합니다. SQL Database 내의 보안은 데이터베이스 수준 및 플랫폼 수준에서 사용할 수 있으며 여러 계층으로 분류할 때 가장 잘 이해할 수 있습니다. 각 계층에서 애플리케이션에 대한 최적의 보안을 제어하고 제공할 수 있습니다. 계층은 다음과 같습니다.

Microsoft Defender for Cloud는 Azure, 온-프레미스 및 기타 클라우드에서 실행되는 작업 전반에 걸친 중앙 집중식 보안 관리를 제공합니다. 감사 및 TDE[투명한 데이터 암호화]와 같은 필수 SQL Database 보호가 모든 리소스에 구성되어 있는지 확인하고 자체 요구 사항에 따라 정책을 만들 수 있습니다.

SQL Database에서 제공되는 사용자 인증 방법에는 무엇이 있나요?

SQL Database에서 두 가지 사용자 인증 방법이 제공됩니다.

Windows 인증은 지원되지 않습니다. Microsoft Entra ID는 중앙 집중식 ID 및 액세스 관리 서비스입니다. 이 서비스를 사용하면 조직의 모든 인원에게 SSO(Single Sign-On) 액세스를 아주 편리하게 제공할 수 있습니다. 즉, 더 간단한 인증을 위해 자격 증명이 Azure 서비스에 걸쳐 공유됩니다.

Microsoft Entra ID는 다단계 인증을 지원하며 Windows Server Active Directory와 쉽게 통합할 수 있습니다. 또한 SQL Database 및 Azure Synapse Analytics는 Microsoft Entra 도메인 내에서 다단계 인증 및 게스트 사용자 계정을 제공할 수 있습니다. 이미 Active Directory 온-프레미스를 사용하는 경우 이를 Microsoft Entra ID와 페더레이션하여 디렉터리를 Azure로 확장할 수 있습니다.

SQL 인증은 사용자 이름 및 비밀번호만 지원하여 지정된 서버의 모든 데이터베이스에 사용자를 인증합니다.

조건 SQL Database / Azure Synapse Analytics
SQL Server 온-프레미스에서 AD를 사용하는 경우 AD를 Microsoft Entra ID와 페더레이션하고 Microsoft Entra 인증을 사용합니다. 페더레이션하면 Single Sign-On을 사용할 수 있습니다.
다단계 인증을 적용해야 하는 경우 Microsoft 조건부 액세스를 통해 정책으로 다단계 인증을 요구하고 Microsoft Entra 다단계 인증을 사용합니다.
페더레이션된 도메인에서 Microsoft Entra 자격 증명을 사용하여 Windows에 로그인하는 경우 Microsoft Entra 통합 인증을 사용합니다.
Azure와 페더레이션되지 않은 도메인에서 자격 증명을 사용하여 Windows에 로그인하는 경우 Microsoft Entra 통합 인증을 사용합니다.
SQL Database 또는 Azure Synapse Analytics에 연결해야 하는 중간 계층 서비스가 있는 경우 Microsoft Entra 통합 인증을 사용합니다.
SQL 인증을 사용해야 하는 기술 요구 사항이 있는 경우 SQL 인증 사용

내 데이터베이스에 대한 연결 액세스를 제한 또는 제어하려면 어떻게 할까요?

애플리케이션에 맞는 최적의 연결을 조직하는 데 사용할 수 있는 여러 가지 기술이 있습니다.

  • 방화벽 규칙
  • VNet 서비스 엔드포인트
  • 예약된 IP

방화벽

방화벽은 특정 엔터티에 대해서만 서버에 액세스를 허용하여 외부 엔터티의 서버 액세스를 방지합니다. 기본적으로 서버 내의 데이터베이스에 대한 모든 연결은 허용되지 않지만, 다른 Azure 서비스에서 들어오는 연결(선택 사항으로 7개)은 제외합니다. 방화벽 규칙을 사용하여 방화벽을 통해 개발자 컴퓨터의 IP 주소를 허용하면 직접 승인하는 엔터티(예: 개발자 머신)에 대해서만 서버 액세스를 개방할 수 있습니다. 또한 서버에 대한 액세스를 허용할 IP 범위를 지정할 수도 있습니다. 예를 들어 방화벽 설정 페이지에서 범위를 지정하여 조직 내 개발자 컴퓨터의 IP 주소를 한 번에 추가할 수 있습니다.

서버 수준 또는 데이터베이스 수준의 방화벽 규칙을 만들 수 있습니다. Azure Portal 또는 SSMS를 사용하여 서버 수준의 IP 방화벽 규칙을 만들 수 있습니다. 서버 수준 및 데이터베이스 수준 방화벽 규칙을 설정하는 방법에 대해 자세히 알아보려면 SQL Database에서 IP 방화벽 규칙 만들기를 참조하세요.

서비스 엔드포인트

기본적으로 데이터베이스는 "Azure 서비스 및 리소스가 이 서버에 액세스하도록 허용"으로 구성되며, 이는 Azure의 모든 Virtual Machine이 데이터베이스에 연결하려고 시도할 수 있다는 것을 의미합니다. 이러한 시도는 여전히 인증을 받아야 합니다. 모든 Azure IP가 데이터베이스에 액세스하지 못하도록 하려면 "Azure 서비스 및 리소스가 이 서버에 액세스하도록 허용"을 사용하지 않도록 설정할 수 있습니다. 또한 VNet 서비스 엔드포인트를 구성할 수 있습니다.

서비스 엔드포인트(SE)를 사용하면 중요한 Azure 서비스 리소스가 Azure의 자체 프라이빗 가상 네트워크에만 노출되도록 할 수 있습니다. 그렇게 하면 기본적으로 사용자의 리소스에 대한 공용 액세스가 제거됩니다. 가상 네트워크와 Azure 간의 트래픽은 항상 Azure 백본 네트워크에 남아 있습니다. SE가 없으면 강제 터널링 패킷 라우팅을 사용합니다. 사용자의 가상 네트워크는 인터넷 트래픽을 강제로 사용자의 조직으로 이동하며 Azure 서비스 트래픽은 같은 경로를 통해 이동합니다. 서비스 엔드포인트를 사용하면 패킷이 가상 네트워크에서 Azure 백본 네트워크의 서비스로 바로 전달되므로 이를 최적화할 수 있습니다.

예약된 IP

다른 옵션은 VM에 대해 예약된 IP를 프로비전하고, 서버 방화벽 설정에 특정 VM IP 주소를 추가하는 것입니다. 예약된 IP를 할당하면 IP 주소를 변경하여 방화벽 규칙을 업데이트해야 하는 번거로움을 줄일 수 있습니다.

SQL Database의 어느 포트에 연결해야 하나요?

포트 1433에 연결해야 합니다. SQL Database는 이 포트를 통해 통신합니다. 회사 네트워크 내에서 연결하려면 조직의 방화벽 설정에 아웃바운드 규칙을 추가해야 합니다. 참고로 포트 1433을 Azure 경계 외부에 노출하지 마세요.

SQL Database에서 서버 및 데이터베이스에서의 활동을 모니터링하고 규제하려면 어떻게 해야 하나요?

SQL 데이터베이스 감사

SQL Database를 사용하면 감사를 켜서 데이터베이스 이벤트를 추적할 수 있습니다. SQL Database 감사는 데이터베이스 이벤트를 기록하고 Azure Storage 계정의 감사 로그 파일에 이를 기록합니다. 감사는 잠재적인 보안 및 정책 위반에 대한 인사이트를 얻고 규정 준수 등을 유지하려는 경우에 특히 유용합니다. 감사가 필요하다고 생각되는 특정 범주의 이벤트를 정의하고 구성할 수 있으며, 이를 기반으로 미리 구성된 보고서와 대시보드를 가져와 데이터베이스에서 발생하는 이벤트에 대한 개요를 얻을 수 있습니다. 이러한 감사 정책을 데이터베이스 수준 또는 서버 수준에서 적용할 수 있습니다. 서버/데이터베이스에 대해 감사를 켜는 방법에 대한 지침은 SQL Database 감사 사용을 참조하세요.

위협 감지

위협 감지를 사용하면 감사에서 발견된 보안 또는 정책 위반에 대해 매우 쉽게 대응할 수 있습니다. 시스템의 잠재적 위협 또는 위반을 해결하기 위해 보안 전문가가 될 필요가 없습니다. 위협 감지에는 SQL 삽입 감지과 같은 몇 가지 기본 제공 기능도 있습니다. SQL 삽입은 데이터 변경 또는 훼손 시도이며 일반적으로 데이터베이스 애플리케이션을 공격할 때 아주 많이 사용되는 방법입니다. 위협 감지는 잠재적 취약성 및 SQL 삽입 공격뿐만 아니라 비정상적인 데이터베이스 액세스 패턴(예: 비정상적인 위치 또는 알 수 없는 보안 주체의 액세스)을 감지하는 여러 알고리즘 집합을 실행합니다. 데이터베이스에서 위협이 감지되면 보안 책임자 또는 기타 지정된 관리자가 이메일 알림을 수신합니다. 각 알림은 의심스러운 활동에 대한 세부 정보를 제공하고 해당 위협을 자세히 조사하고 완화하는 방법에 대한 권장 사항을 제공합니다. 위협 감지를 켜는 방법에 대해 알아보려면 위협 감지 사용을 참조하세요.

일반적으로 SQL Database에서 내 데이터를 보호하려면 어떻게 해야 하나요?

암호화는 중요 데이터를 침입자로부터 보호하고 안전하게 지키는 강력한 메커니즘을 제공합니다. 암호화된 데이터는 암호 해독 키가 없으면 침입자에게 아무 소용이 없습니다. 따라서 SQL Database에서 기본 제공되는 기존 보안 계층 위에 추가 보호 계층을 추가합니다. SQL Database에서 데이터를 보호하는 데는 두 가지 측면이 있습니다.

  • 데이터 및 로그 파일에 있는 미사용 데이터
  • 이동 중인 데이터

SQL Database에서 기본적으로 스토리지 하위 시스템에 있는 데이터 및 로그 파일의 미사용 데이터는 TDE[투명한 데이터 암호화]를 통해 완전하게 항상 암호화됩니다. 백업 또한 암호화됩니다. TDE를 사용하면 이 데이터에 액세스하는 애플리케이션 쪽에서는 어떤 변경도 필요하지 않습니다. 암호화 및 암호 해독은 이름 그대로 투명하게 수행됩니다. 이동 중 및 미사용 중요 데이터를 보호하기 위해 SQL Database는 AE(Always Encrypted)라는 기능을 제공합니다. AE는 데이터베이스의 중요한 열을 암호화하는 클라이언트 쪽 암호화의 한 형태입니다(따라서 데이터베이스 관리자 및 권한이 없는 사용자에게는 암호 텍스트로 되어 있습니다). 서버는 암호화된 데이터를 수신함으로써 시작합니다. 또한 Always Encrypted를 위한 키는 클라이언트 쪽에 저장되어 권한 있는 클라이언트만이 중요한 열을 암호 해독할 수 있습니다. 암호화 키가 클라이언트에 저장되기 때문에 서버 관리자 및 데이터 관리자는 중요한 데이터를 볼 수 없습니다. AE는 권한이 없는 클라이언트에서부터 물리적인 디스크까지 테이블의 중요한 열을 엔드투엔드로 암호화합니다. AE는 현재 같음 비교를 지원하므로 DBA는 계속해서 암호화된 열을 해당 SQL 명령의 일환으로 쿼리할 수 있습니다. Always Encrypted는 Azure Key Vault, Windows 인증서 저장소, 및 로컬 하드웨어 보안 모듈과 같은 다양한 키 저장소 옵션과 함께 사용될 수 있습니다.

특성 Always Encrypted 투명한 데이터 암호화
암호화 범위 엔드투엔드 미사용 데이터
서버는 중요 데이터에 액세스 가능 아니요 예, 암호화는 미사용 데이터를 위한 것이므로
허용되는 T-SQL 작업 같음 비교 모든 T-SQL 노출 영역 사용 가능
기능을 사용하려면 앱 변경이 필요함 최소 매우 최소
암호화 세분성 열 수준 데이터베이스 수준

데이터베이스의 중요한 데이터에 대한 액세스를 제한하려면 어떻게 해야 하나요?

모든 애플리케이션의 데이터베이스에는 모든 사용자가 볼 수 없도록 보호해야 하는 중요한 데이터가 어느 정도 있습니다. 조직의 특정 인원은 이 데이터를 보아야 하지만, 다른 인원은 이 데이터를 볼 수 없어야 합니다. 한 가지 예로 직원 임금이 있습니다. 관리자는 자신의 직접 보고서의 임금 정보에 액세스해야 할 수 있지만, 개인 팀원은 자신의 동료의 임금 정보에 대한 액세스 권한이 없어야 합니다. 또 다른 시나리오는 데이터 개발자가 개발 단계 또는 테스트 중에 중요한 데이터(예: 고객의 SSN)와 상호 작용할 수 있는 경우입니다. 이 정보 역시 개발자에게 노출되지 않아야 합니다. 이러한 경우 중요한 데이터를 마스킹하거나 전혀 노출되지 않도록 해야 합니다. SQL Database는 권한이 없는 사용자가 중요한 데이터를 볼 수 없도록 하는 두 가지 방식을 제공합니다.

동적 데이터 마스킹은 애플리케이션 계층에서 권한이 없는 사용자에게 데이터를 마스킹하여 중요한 데이터 노출을 제한하는 데이터 마스킹 기능입니다. 마스킹 규칙을 정의하여 마스킹 패턴(예: XXX-XX-0000처럼 국적 ID SSN의 마지막 4자리만을 보여주고 나머지를 X로 표시함)을 만들 수 있고 마스킹 규칙에서 제외할 사용자를 식별할 수 있습니다. 마스킹은 즉시 이루어지며 여러 데이터 범주에 사용할 수 있는 다양한 마스킹 기능이 있습니다. 동적 데이터 마스킹을 사용하면 데이터베이스에서 중요한 데이터를 자동으로 감지하여 마스킹을 적용할 수 있습니다.

행 수준 보안을 사용하면 행 수준에서 액세스를 제어할 수 있습니다. 즉, 쿼리를 실행하는 사용자(그룹 멤버십 또는 실행 컨텍스트)에 따라 데이터베이스 테이블의 특정 행이 숨겨집니다. 액세스 제한은 앱 논리를 간소화하기 위해 애플리케이션 계층 대신에 데이터베이스 계층에서 수행됩니다. 먼저 필터 조건자를 만들고 노출되지 않는 행을 필터링한 다음 보안 정책에서 해당 행에 액세스할 수 있는 사용자를 정의합니다. 마지막으로 최종 사용자가 자신의 쿼리를 실행하면 사용자의 권한에 따라 제한된 행을 보거나 해당 행을 전혀 볼 수 없습니다.

클라우드에서 암호화 키를 관리하려면 어떻게 해야 하나요?

Always Encrypted(클라이언트 쪽 암호화) 및 투명한 데이터 암호화(미사용 암호화) 모두에 대한 키 관리 옵션이 있습니다. 암호화 키를 정기적으로 회전하는 것이 좋습니다. 회전 빈도는 내부 조직 규정은 물론 규정 요구 사항과도 일치해야 합니다.

TDE(투명한 데이터 암호화)

TDE에는 두 가지 키 계층 구조가 있습니다. 각 사용자 데이터베이스의 데이터는 대칭 AES-256 데이터베이스 고유 DEK(데이터베이스 암호화 키)로 암호화되고, 이 키는 다시 서버 고유 비대칭 RSA 2048 마스터 키로 암호화됩니다. 마스터 키는 다음 방식 중 하나를 통해 관리할 수 있습니다.

  • 플랫폼(SQL Database)에 의해 자동으로.
  • 또는 Azure Key Vault를 키 저장소로 사용하여.

기본적으로 투명한 데이터 암호화의 마스터 키는 편의를 위해 SQL Database 서비스에서 관리됩니다. 조직에서 마스터 키를 제어하려는 경우, Azure Key Vault를 키 저장소로 사용하는 옵션이 있습니다. Azure Key Vault를 사용하여 조직은 키 프로비저닝, 회전 및 권한 제어에 관한 제어권을 갖습니다. 회전 또는 TDE 마스터 키 형식 전환은 DEK을 다시 암호화함으로 빠릅니다. 보안과 데이터 관리 간에 역할이 분리된 조직의 경우 보안 관리자는 Azure Key Vault에서 TDE 마스터 키에 대한 키 자료를 프로비전하고 데이터베이스 관리자에게 서버의 미사용 데이터 암호화에 사용할 수 있도록 Azure Key Vault 키 식별자를 제공할 수 있습니다. Key Vault는 Microsoft가 암호화 키를 보거나 추출할 수 없게 설계되어 있습니다. 조직에 대한 중앙 집중식 키 관리도 얻게 됩니다.

Always Encrypted

또한 Always Encrypted에는 두 키 계층 구조가 있습니다. 중요한 데이터의 열은 AES 256열 암호화 키(CEK)로 암호화되고, 이 열은 다시 열 마스터 키(CMK)로 암호화됩니다. Always Encrypted에 제공되는 클라이언트 드라이버는 CMK 길이에 제한이 없습니다. CEK의 암호화된 값은 데이터베이스에 저장되고 CMK는 Windows 인증서 저장소, Azure Key Vault 또는 하드웨어 보안 모듈과 같은 신뢰할 수 있는 키 저장소에 저장됩니다.

  • CEK 및 CMK는 모두 회전할 수 있습니다.
  • CEK 회전은 데이터 작업의 크기이며 암호화된 열이 포함된 테이블의 크기에 따라 시간이 많이 소요될 수 있습니다. 따라서 그에 따라 CEK 회전을 신중하게 계획해야 합니다.
  • 반면 CMK 회전은 데이터베이스 성능을 방해하지 않으며, 역할을 분리하여 수행할 수 있습니다.

다음 다이어그램은 Always Encrypted에서 열 마스터 키에 대한 키 저장소 옵션을 보여줍니다.

Always Encrypted CMK 저장소 공급자의 다이어그램입니다.

조직과 SQL Database 간의 트래픽을 최적화하고 보호하려면 어떻게 해야 하나요?

조직과 SQL Database 간의 네트워크 트래픽은 일반적으로 공용 네트워크를 통해 경로 설정됩니다. 그러나 이 경로를 최적화하고 더 안전하게 보호하려면 Azure ExpressRoute를 살펴볼 수 있습니다. ExpressRoute를 사용하면 기본적으로 프라이빗 연결을 통해 회사 네트워크를 Azure 플랫폼으로 확장할 수 있습니다. 이렇게 하면 공용 인터넷을 통해 이동하지 않게 됩니다. 또한 보안, 안정성 및 라우팅 최적화가 향상되어 일반적으로 공용 인터넷을 사용할 때보다 네트워크 대기 시간이 짧고 속도가 훨씬 빨라집니다. 조직과 Azure 간에 중요 데이터 청크를 전송할 계획인 경우 ExpressRoute를 사용하면 비용 면에서 유리할 수 있습니다. 조직에서 Azure로 연결할 때 세 가지 연결 모델 중에서 선택할 수 있습니다.

또한 ExpressRoute를 사용하면 추가 요금 없이 구입한 대역폭 제한을 최대 2배까지 버스트할 수 있습니다. ExpressRoute를 사용하여 지역 간 연결을 구성하는 것도 가능합니다. ExpressRoute 연결 공급자 목록을 보려면 ExpressRoute 파트너 및 피어링 위치를 참조하세요. 다음 문서에서는 Express Route에 대해 자세히 설명합니다.

SQL Database는 모든 규정 요구 사항을 준수하나요? 이는 조직의 규정 준수에 어떤 도움이 되나요?

SQL Database는 다양한 규격을 준수합니다. SQL Database에서 충족된 최신 규격 집합을 보려면 Microsoft Trust Center를 방문하여 SQL Database가 호환되는 Azure 서비스에 포함되어 있는지 확인하기 위해 조직에 중요한 규정 준수에 대해 드릴다운합니다. SQL Database가 규정 준수 서비스로 인증되었다 하더라도, 이는 조직 서비스의 규정 준수를 지원하지만 자동으로 보장하지는 않는다는 점에 유의해야 합니다.

마이그레이션 후 지능형 데이터베이스 모니터링 및 유지 관리

데이터베이스를 SQL Database로 마이그레이션한 후에는 데이터베이스를 모니터링하거나(예: 리소스 사용률의 상태 또는 DBCC 검사) 정기 유지 관리(예: 인덱스, 통계 등을 다시 빌드 또는 재구성)를 수행하려고 할 것입니다. 다행히 SQL Database는 과거 추세와 기록된 메트릭 및 통계를 사용하여 선제적으로 데이터베이스를 모니터링하고 유지 관리하여 애플리케이션이 항상 최적으로 실행될 수 있도록 지원한다는 점에서 지능형입니다. 경우에 따라 Azure SQL Database는 구성 설정을 기반으로 유지 관리를 자동으로 수행할 수 있습니다. SQL Database에서 데이터베이스 모니터링에는 세 가지 패싯이 있습니다.

  • 성능 모니터링 및 최적화.
  • 보안 최적화.
  • 비용 최적화.

성능 모니터링 및 최적화

Query Performance Insights를 사용하면 애플리케이션이 언제나 최적 수준으로 실행될 수 있도록 데이터베이스 워크로드에 대한 맞춤형 권장 사항을 받을 수 있습니다. 또한 이러한 권장 사항이 자동으로 적용되도록 설정할 수 있으므로 유지 관리 작업을 수행하지 않아도 됩니다. SQL Database Advisor를 사용하면 워크로드에 기초하여 인덱스 권장 사항을 자동으로 구현할 수 있으며, 이 기능을 자동 조정이라 합니다. 권장 사항은 애플리케이션 워크로드의 변경 사항에 맞춰 진화하여 가장 관련성이 큰 제안을 제공합니다. 또한 이러한 권장 사항을 수동으로 검토하고 원하는 대로 적용하는 옵션이 있습니다.

보안 최적화

SQL Database는 데이터를 보호하도록 도와 주는 실행 가능한 보안 권장 사항 및 데이터베이스에 잠재적 위협을 일으킬 수 있는 의심스러운 데이터베이스 활동을 식별 및 조사하기 위한 위협 감지를 제공합니다. 취약성 평가는 데이터베이스의 보안 상태를 대규모로 모니터링하고, 보안 위험을 파악하고, 사용자가 정의한 보안 기준에서 드리프트할 수 있는 데이터베이스 검사 및 보고 서비스입니다. 모든 검사 후에는 실행 가능한 단계 및 수정 스크립트의 사용자 지정 목록과 규정 준수 요구 사항을 충족하는 데 사용할 수 있는 평가 보고서가 제공됩니다.

Microsoft Defender for Cloud를 사용하여 보드에서 보안 권장 사항을 식별하여 신속하게 적용합니다.

비용 최적화

Azure SQL 플랫폼은 서버의 데이터베이스에 대해 사용률 기록을 분석하여 비용 최적화 옵션을 평가하고 권고합니다. 이 분석은 일반적으로 실행 가능한 권장 사항을 분석하고 구축하는 데 몇 주간의 활동이 필요합니다.

SQL Database에서 성능 및 리소스 사용률을 모니터링하려면 어떻게 해야 하나요?

다음 방법을 사용하여 SQL Database에서 성능 및 리소스 사용률을 모니터링할 수 있습니다.

데이터베이스 Watcher

데이터베이스 Watcher는 심층 워크로드 모니터링 데이터를 수집하여 데이터베이스 성능, 구성 및 상태에 대한 자세한 보기를 제공합니다. Azure Portal의 대시보드는 Azure SQL 자산의 단일 창 보기와 모니터링되는 각 리소스에 대한 자세한 보기를 제공합니다. 데이터는 Azure 구독의 중앙 데이터 저장소로 수집됩니다. 수집된 데이터를 쿼리, 분석, 내보내기, 시각화하고 다운스트림 시스템과 통합할 수 있습니다.

데이터베이스 Watcher에 대한 자세한 내용은 다음 문서를 참조하세요.

Azure Portal

Azure Portal은 개요 창에서 데이터베이스를 선택하고 차트를 선택하면 데이터베이스의 사용률을 보여 줍니다. CPU 비율, DTU 비율, 데이터 IO 비율, 세션 비율 및 데이터베이스 크기 비율을 포함하는, 여러 가지 메트릭을 표시하도록 차트를 수정할 수 있습니다.

데이터베이스 DTU의 모니터링 차트에 대한 Azure Portal의 스크린샷.

또한 이 차트로부터 리소스로 경고를 구성할 수도 있습니다. 이러한 경고를 사용하면 리소스 상태에 이메일로 응답하거나 HTTPS/HTTP 엔드포인트에 쓰거나 작업을 수행할 수 있습니다. 자세한 내용은 경고 만들기를 참조하세요.

동적 관리 뷰

지난 1시간 동안의 리소스 사용량 통계 기록을 반환하려면 sys.dm_db_resource_stats 동적 관리 뷰를 쿼리하고, 지난 14일 동안의 기록을 반환하려면 sys.resource_stats 시스템 카탈로그 뷰를 쿼리할 수 있습니다.

쿼리 성능 Insight

쿼리 성능 Insight를 사용하면 상위 리소스 소비량 쿼리 및 특정 데이터베이스에 대한 장기 실행 쿼리 기록을 볼 수 있습니다. 리소스 사용률, 기간 및 실행 빈도별로 최상위 쿼리를 신속하게 식별할 수 있습니다. 쿼리를 추적하고 재발을 검색할 수 있습니다. 이 기능을 사용하려면 데이터베이스에 대해 쿼리 저장소를 사용하도록 설정되어 있어야 하며 활성 상태여야 합니다.

쿼리 성능 Insight의 Azure Portal 스크린샷.

성능 문제를 겪고 있습니다. SQL Database 문제 해결 방법론은 SQL Server와 어떻게 다른가요?

쿼리 및 데이터베이스 성능 문제를 진단하는 데 사용하는 문제 해결 기술의 대부분은 동일하게 유지됩니다. 결국 동일한 데이터베이스 엔진이 클라우드를 구동합니다. 그러나 플랫폼, 즉 Azure SQL Database가 기본 제공 ‘지능’을 포함합니다. 이를 통해 성능 문제를 보다 쉽게 해결하고 진단할 수 있습니다. 또한 사용자를 대신하여 이러한 수정 작업 중 일부를 수행할 수 있으며 경우에 따라 선제적으로 자동 수정할 수도 있습니다.

사용자의 성능 문제 해결 방법은 쿼리 성능 Insight(QPI) 및 Database Advisor와 같은 지능형 기능을 함께 사용하면 상당히 유리할 수 있으며, 문제를 직접 해결하는 데 도움이 될 수 있는 필수 세부 정보를 더 이상 수동으로 찾을 필요가 없다는 점에서 방법론적 차이가 있습니다. 힘든 작업은 플랫폼이 대신 수행합니다. 그 중 한 가지 예가 QPI입니다. QPI를 사용하면 쿼리 수준까지 드릴다운하고 과거 추세를 살펴보고 쿼리가 회귀한 정확한 시기를 파악할 수 있습니다. Database Advisor는 인덱스 누락, 인덱스 삭제, 쿼리 매개 변수화 등 전반적인 성능을 개선하는 데 도움이 될 수 있는 항목에 대한 권장 사항을 제공합니다.

성능 문제 해결의 경우 애플리케이션 성능에 영향을 주는 것이 애플리케이션인지 아니면 애플리케이션을 지원하는 데이터베이스인지 파악하는 것이 중요합니다. 종종 성능 문제는 애플리케이션 계층에 있는 경우가 많습니다. 아키텍처 또는 데이터 액세스 패턴일 수도 있습니다. 예를 들어 네트워크 대기 시간에 중요한 대화 애플리케이션이 있다고 생각해 보겠습니다. 이 경우 애플리케이션과 서버 간에 짧은 요청이 많이 오가고("채팅이 많음") 혼잡한 네트워크에서는 이러한 왕복 횟수가 빠르게 추가되기 때문에 애플리케이션 성능이 저하됩니다. 이 경우 성능을 향상시키려면 Batch 쿼리를 사용할 수 있습니다. 일괄 처리를 사용하면 요청이 일괄 처리되므로 왕복 대기 시간을 줄이고 애플리케이션 성능을 개선하는 데 큰 도움을 줍니다.

또한 데이터베이스의 전반적인 성능이 저하되는 경우 sys.dm_db_resource_stats 및 sys.resource_stats 동적 관리 뷰를 모니터링하여 CPU, IO, 메모리 사용량을 파악할 수 있습니다. 데이터베이스에 리소스가 부족하면 성능에 영향을 미칠 수도 있습니다. 증가하고 줄어드는 워크로드 수요에 따라 컴퓨팅 크기 및/또는 서비스 계층을 변경해야 할 수 있습니다.

성능 문제 튜닝에 대한 포괄적인 권장 사항은 데이터베이스 튜닝을 참조하세요.

적절한 서비스 계층 및 컴퓨팅 크기를 사용하고 있는지 확인하려면 어떻게 해야 하나요?

SQL Database는 이전 DTU 모델과 적응성이 더 높은 vCore 구매 모델이라는 두 가지 구매 모델을 제공합니다. 차이점에 대한 자세한 내용은 Azure SQL Database의 vCore 및 DTU 기반 구매 모델 비교를 참조하세요.

컴퓨팅 크기가 올바른지 확인하기 위해 구매 모델에서 쿼리 및 데이터베이스 리소스 사용량을 모니터링할 수 있습니다. 자세한 내용은 모니터 및 성능 튜닝을 참조하세요. 쿼리/데이터베이스가 지속적으로 과다 실행되는 경우 더 큰 컴퓨팅 크기로 확장하는 것을 고려할 수 있습니다. 마찬가지로, 최고 사용량 시간에도 리소스를 그리 많이 사용하지 않는 것으로 확인되면 현재 컴퓨팅 크기를 축소하는 것이 좋습니다. Azure Automation을 사용하여 일정에 따라 SQL Database의 크기를 조정하는 것이 좋습니다.

SaaS 앱 패턴 또는 데이터베이스 통합 시나리오가 있으면 비용 최적화를 위해 탄력적 풀을 사용하는 것이 좋습니다. 탄력적 풀은 데이터베이스 통합 및 비용 최적화를 달성할 수 있는 좋은 방법입니다. 탄력적 풀을 사용하여 여러 데이터베이스를 관리하는 방법에 대한 자세한 내용은 풀 및 데이터베이스 관리를 참조하세요.

내 데이터베이스에 대해 데이터베이스 무결성 검사를 얼마나 자주 실행해야 하나요?

SQL Database는 특정 부류의 데이터 손상을 자동으로 데이터 손실 없이 처리할 수 있는 몇 가지 스마트 기술을 사용합니다. 이러한 기술은 서비스에 기본 제공되며 필요할 때 서비스에서 활용합니다. 정기적으로 서비스 전체의 데이터베이스 백업을 복원하고 DBCC CHECKDB를 실행하여 백업을 테스트합니다. 문제가 있는 경우 SQL Database에서 문제를 사전에 해결합니다. 자동 페이지 수리는 손상되거나 데이터 무결성 문제가 있는 페이지를 수정하기 위해 이용됩니다. 데이터베이스 페이지는 항상 페이지의 무결성을 확인하는 기본 CHECKSUM 설정으로 확인됩니다. SQL Database는 데이터베이스의 데이터 무결성을 사전에 모니터링하고 검토하며 문제가 발생하면 가장 높은 우선 순위로 해결합니다. 이 외에도 필요에 따라 자체적으로 무결성 검사를 실행하도록 선택할 수 있습니다. 자세한 내용은 SQL Database의 데이터 무결성을 참조하세요.

마이그레이션 후 데이터 이동

Azure Portal을 사용하여 SQL Database에서 BACPAC 파일로 데이터를 내보내고 가져오려면 어떻게 해야 하나요?

  • 내보내기: Azure Portal에서 Azure SQL Database의 데이터베이스를 BACPAC 파일로 내보낼 수 있습니다.

Azure Portal에서 Azure SQL Database의 데이터베이스 내보내기 버튼의 스크린샷.

  • 가져오기: Azure Portal을 사용하여 Azure SQL Database의 데이터베이스에 BACPAC 파일로 데이터를 가져올 수도 있습니다.

Azure Portal에서 Azure SQL Server의 데이터베이스 가져오기 버튼의 스크린샷.

SQL Database와 SQL Server 간에 데이터를 동기화하려면 어떻게 해야 하나요?

이 작업을 수행할 수 있는 방법은 여러 가지가 있습니다.

  • 데이터 동기화 – 이 기능은 여러 SQL Server 데이터베이스와 SQL Database 사이에 양방향으로 데이터를 동기화하도록 도와 줍니다. SQL Server 데이터베이스와 동기화하려면 로컬 컴퓨터 또는 가상 머신에 동기화 에이전트를 설치 및 구성하고 아웃바운드 TCP 포트 1433을 열어야 합니다.
  • 트랜잭션 복제 – 트랜잭션 복제를 사용하여 SQL Server 데이터베이스에서 Azure SQL Database까지의 데이터를 게시자인 SQL Server 인스턴스 및 구독자인 Azure SQL Database와 동기화할 수 있습니다. 현재는 이 설정만 지원됩니다. 가동 중지 시간을 최소화하면서 SQL Server 데이터베이스에서 Azure SQL로 데이터를 마이그레이션하는 방법은 트랜잭션 복제 사용을 참조하세요.

관련 콘텐츠