적용 대상:
Azure SQL Database
자체 관리형 환경에서 Azure SQL Database와 같은 PaaS로 마이그레이션하는 것은 복잡할 수 있습니다. 이 문서에서는 단일 및 풀된 데이터베이스에 대한 Azure SQL Database의 주요 기능을 강조 표시하여 애플리케이션을 사용 가능하고 성능이 뛰어나며 안전하며 복원력을 유지할 수 있도록 지원합니다.
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는 자동으로 데이터베이스를 백업합니다. 이 플랫폼은 매주 전체 백업, 몇 시간마다 차등 백업, 5분마다 로그 백업을 수행하여 재해 복구가 효율적이고 데이터 손실이 최소화되도록 합니다. 첫 번째 전체 백업은 데이터베이스를 생성하자마자 이루어집니다. 이러한 백업은 선택한 서비스 계층에 따라 달라지는 보존 기간이라는 특정 기간 동안 사용할 수 있습니다. PITR(특정 시점 복구)을 사용하여 이 보존 기간 내 의 특정 시점으로 복원할 수 있습니다.
또한 장기 보존 백업 기능을 사용하면 최대 10년 동안 백업 파일을 유지하고 해당 기간 내에 언제든지 이러한 백업에서 데이터를 복원할 수 있습니다. 데이터베이스 백업은 지역 재해로부터 복원력을 제공하기 위해 지역 복제 스토리지에 보관됩니다. 또한 이러한 백업을 보존 기간 내의 어느 시점이든 Azure 지역에서 복원할 수 있습니다. 자세한 내용은 Azure SQL Database의 비즈니스 연속성을 참조하세요.
데이터 센터 수준 재해 또는 지역 재해 발생 시 비즈니스 연속성을 보장하려면 어떻게 해야 하나요?
데이터베이스 백업은 지역 재해가 발생 시 다른 Azure 지역으로 백업을 복원할 수 있도록 지역적으로 복제된 스토리지에 저장됩니다. 이를 지역 복원이라고 합니다. 지역 복원에 대한 자세한 내용 및 타이밍은 Azure SQL Database 대한지역 복원을 참조하세요.
중요 업무용 데이터베이스의 경우 Azure SQL Database는 활성 지역 복제를 제공하여 다른 지역에 원본 데이터베이스의 지역 복제 보조 복사본을 생성합니다. 예를 들어 데이터베이스가 처음에 Azure 미국 서부 지역에서 호스트되고 지역 재해 복원력을 원하는 경우 미국 서부에서 미국 동부로 데이터베이스의 활성 지역 복제본(replica)를 만듭니다. 미국 서부에서 재난이 발생한 경우 미국 동부 지역으로 장애 조치(failover)할 수 있습니다.
활성 지역 복제 외에도 장애 조치 그룹은 데이터베이스 그룹의 복제 및 장애 조치를 관리하는 데 도움이 됩니다. 동일하거나 다른 지역에 있는 여러 데이터베이스를 포함하여 장애 조치(failover) 그룹을 만들 수 있습니다. 그런 다음 장애 조치(failover) 그룹의 모든 데이터베이스를 보조 지역으로 장애 조치(failover)를 시작할 수 있습니다. 자세한 내용은 장애 조치(failover) 그룹 개요 및 모범 사례(Azure SQL Database)를 참조하세요.
데이터 센터 또는 가용성 영역 장애에 대한 복원력을 구현하려면 데이터베이스 또는 Elastic Pool에 대해 영역 중복이 사용 설정되어 있는지 확인합니다.
재해 대비를 위해 애플리케이션을 적극적으로 모니터링하고 보조 애플리케이션으로 장애 조치(failover)를 시작합니다. 서로 다른 Azure 지역에 이러한 활성 지역 복제본(replica)을 최대 4개까지 만들 수 있습니다. 장점은 이것뿐만이 아닙니다. 또한 읽기 전용 액세스를 위해 이러한 두 번째 활성 지역 복제본에 액세스할 수도 있습니다. 이렇게 하면 지역 분산 애플리케이션 시나리오의 대기 시간을 줄일 수 있습니다.
SQL Database에서 재해 복구는 어떤 모습인가요?
활성 지역 복제 또는 장애 조치(failover) 그룹을 사용하는 경우 Azure SQL Database에서 몇 단계만으로 재해 복구를 구성하고 관리할 수 있습니다. 다만 계속해서 지역 재해 대비를 위해 애플리케이션 및 해당 데이터베이스를 모니터링하고 보조 지역으로 장애 조치(failover)하여 비즈니스 연속성을 복원해야 합니다.
자세한 내용은 Azure SQL Database 재해 복구 101을 참조하세요.
보안 및 규정 준수
SQL Database 내의 보안은 데이터베이스 수준 및 플랫폼 수준에서 사용할 수 있습니다. 다음과 같이 애플리케이션에 대한 최적의 보안을 제어하고 제공할 수 있습니다.
- ID 및 인증 (Microsoft Entra ID를 사용한 SQL 인증 및 인증).
- 활동 모니터링(감가 및 위협 검색).
- 실제 데이터 보호(투명한 데이터 암호화 [TDE] 및 Always Encrypted).
- 중요한 권한 있는 데이터에 대한 액세스 제어(행 수준 보안 및 동적 데이터 마스킹).
Microsoft Defender for Cloud는 Azure, 온-프레미스 및 기타 클라우드에서 실행되는 작업 전반에 걸친 중앙 집중식 보안 관리를 제공합니다. 모든 리소스에 필수 SQL Database 보호 기능, 예를 들어 감사 및 투명한 데이터 암호화(TDE)가 구성되어 있는지 확인하고, 고유한 요구 사항에 따라 정책을 만들 수 있습니다.
SQL Database에서 제공되는 사용자 인증 방법은 무엇인가요?
SQL Database에서 두 가지 사용자 인증 방법이 제공됩니다.
Windows 인증은 지원되지 않습니다. Microsoft Entra ID는 중앙 집중식 ID 및 액세스 관리 서비스입니다. Microsoft Entra 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 Entra 다단계 인증을 사용합니다. |
| 페더레이션된 도메인에서 Microsoft Entra 자격 증명을 사용하여 Windows에 로그인됨 | Microsoft Entra 인증을 사용합니다. |
| Azure와 페더레이션되지 않은 도메인의 자격 증명을 사용하여 Windows에 로그인됨 | Microsoft Entra 통합 인증을 사용합니다. |
| SQL Database 또는 Azure Synapse Analytics에 연결해야 하는 중간 계층 서비스 사용 | Microsoft Entra 통합 인증을 사용합니다. |
| SQL 인증을 사용해야 하는 기술 요구 사항이 있는 경우 | SQL 인증 사용 |
데이터베이스에 대한 연결 액세스를 제한하거나 제어하려면 어떻게 해야 하나요?
애플리케이션에 맞는 최적의 연결을 조직하는 데 사용할 수 있는 여러 가지 기술이 있습니다.
- 방화벽 규칙
- 가상 네트워크 서비스 엔드포인트
- 예약된 IP
방화벽
기본적으로 다른 Azure 서비스에서 들어오는 연결을 제외하고 서버 내의 데이터베이스에 대한 모든 연결은 허용되지 않습니다. 방화벽 규칙을 사용하면 방화벽을 통해 해당 컴퓨터의 IP 주소를 허용하여 승인하는 엔터티(예: 개발자 컴퓨터)에 대해서만 서버에 대한 액세스를 열 수 있습니다. 또한 서버에 대한 액세스를 허용할 IP 범위를 지정할 수도 있습니다. 예를 들어 방화벽 설정 페이지에서 범위를 지정하여 조직 내 개발자 컴퓨터의 IP 주소를 한 번에 추가할 수 있습니다.
서버 수준 또는 데이터베이스 수준의 방화벽 규칙을 만들 수 있습니다. Azure Portal 또는 SSMS를 사용하여 서버 수준의 IP 방화벽 규칙을 만들 수 있습니다. 서버 수준 및 데이터베이스 수준 방화벽 규칙을 설정하는 방법에 대한 자세한 내용은 SQL Database에서 IP 방화벽 규칙 만들기를 참조하세요.
서비스 엔드포인트
기본적으로 데이터베이스는 Azure 서비스 및 리소스가 이 서버에 액세스할 수 있도록 구성됩니다. 즉, Azure의 Virtual Machine이 데이터베이스에 연결을 시도할 수 있습니다. 이러한 시도는 여전히 인증을 받아야 합니다. Azure IP에서 데이터베이스에 액세스할 수 없도록 하려면 Azure 서비스 및 리소스가 이 서버에 액세스하도록 허용을 사용하지 않도록 설정할 수 있습니다. 또한 가상 네트워크 서비스 엔드포인트를 구성할 수 있습니다.
서비스 엔드포인트를 사용하면 중요한 Azure 리소스를 Azure의 자체 프라이빗 가상 네트워크에만 노출할 수 있습니다. 이 옵션은 리소스에 대한 공용 액세스를 제거합니다. 가상 네트워크와 Azure 간의 트래픽은 항상 Azure 백본 네트워크에 남아 있습니다. 서비스 엔드포인트가 없으면 강제 터널링 패킷 라우팅이 표시됩니다. 사용자의 가상 네트워크는 인터넷 트래픽을 강제로 사용자의 조직으로 이동하며 Azure 서비스 트래픽은 같은 경로를 통해 이동합니다. 서비스 엔드포인트를 사용하면 패킷이 가상 네트워크에서 Azure 백본 네트워크의 서비스로 바로 전달되므로 이를 최적화할 수 있습니다.
예약된 IP
다른 옵션은 VM에 대해 예약된 IP를 프로비전하고, 서버 방화벽 설정에 특정 VM IP 주소를 추가하는 것입니다. 예약된 IP를 할당하면 IP 주소를 변경하여 방화벽 규칙을 업데이트해야 하는 번거로움을 줄일 수 있습니다.
SQL Database에 어떤 포트를 연결해야 하나요?
SQL Database는 포트 1433을 통해 통신합니다. 회사 네트워크 내에서 연결하려면 조직의 방화벽 설정에 아웃바운드 규칙을 추가해야 합니다. 참고로 포트 1433을 Azure 경계 외부에 노출하지 마세요.
SQL Database의 서버 및 데이터베이스에서 활동을 모니터링 및 규제하려면 어떻게 해야 하나요?
SQL 데이터베이스 감사
Azure SQL Database 감사는 데이터베이스 이벤트를 기록하고 Azure Storage 계정의 감사 로그 파일에 기록합니다. 감사는 잠재적인 보안 및 정책 위반에 대한 인사이트를 얻고 규정 준수를 유지하려는 경우에 특히 유용합니다. 이를 통해 감사가 필요하다고 생각되는 특정 범주의 이벤트를 정의하고 구성할 수 있으며, 이를 기반으로 미리 구성된 보고서와 대시보드를 가져와 데이터베이스에서 발생하는 이벤트에 대한 개요를 얻을 수 있습니다.
이러한 감사 정책을 데이터베이스 수준 또는 서버 수준에서 적용할 수 있습니다. 자세한 내용은 SQL Database 감사를 사용하도록 설정합니다.
위협 감지
위협 탐지를 사용하면 감사에서 검색된 보안 또는 정책 위반에 대해 조치를 수행할 수 있습니다. 시스템의 잠재적 위협 또는 위반을 해결하기 위해 보안 전문가가 될 필요가 없습니다. 위협 감지에는 데이터베이스 애플리케이션을 공격하는 매우 일반적인 방법인 SQL 삽입 검색과 같은 몇 가지 기본 제공 기능도 있습니다. 위협 탐지는 잠재적인 취약성 및 SQL 삽입 공격 및 비정상적인 데이터베이스 액세스 패턴(예: 비정상적인 위치 또는 익숙하지 않은 보안 주체의 액세스)을 검색하는 여러 알고리즘 집합을 실행합니다.
데이터베이스에서 위협이 감지되면 보안 책임자 또는 기타 지정된 관리자가 이메일 알림을 수신합니다. 각 알림은 의심스러운 활동에 대한 세부 정보를 제공하고 해당 위협을 자세히 조사하고 완화하는 방법에 대한 권장 사항을 제공합니다. 위협 탐지를 켜는 방법을 알아보려면 위협 탐지 사용을 참조하세요.
SQL Database에서 일반적으로 데이터를 보호하려면 어떻게 해야 하나요?
암호화는 중요 데이터를 침입자로부터 보호하고 안전하게 지키는 강력한 메커니즘을 제공합니다. 암호화된 데이터는 암호 해독 키가 없으면 침입자에게 아무 소용이 없습니다. 따라서 SQL Database에서 기본 제공되는 기존 보안 계층 위에 추가 보호 계층을 추가합니다. SQL Database에서 데이터를 보호하는 데는 두 가지 측면이 있습니다.
- 데이터 및 로그 파일에 저장된 미사용 데이터
- 전송 중인 데이터
SQL Database에서 기본적으로 스토리지 하위 시스템의 데이터 및 로그 파일의 미사용 데이터는 투명한 데이터 암호화[TDE]를 통해 완전하고 항상 암호화됩니다. 백업 또한 암호화됩니다. TDE를 사용하면 애플리케이션 쪽에서 이 데이터에 액세스하는 변경이 필요하지 않습니다. 암호화 및 암호 해독은 이름 그대로 투명하게 수행됩니다.
SQL Database는 비행 중 및 미사용 중요한 데이터를 보호하기 위해 Always Encrypted라는 기능을 제공합니다. Always Encrypted는 데이터베이스의 중요한 열을 암호화하는 클라이언트 쪽 암호화의 한 형태입니다(따라서 데이터베이스 관리자 및 권한이 없는 사용자에게 암호화되어 있습니다). 서버는 암호화된 데이터를 수신함으로써 시작합니다.
또한 Always Encrypted를 위한 키는 클라이언트 쪽에 저장되어 권한 있는 클라이언트만이 중요한 열을 암호 해독할 수 있습니다. 암호화 키가 클라이언트에 저장되기 때문에 서버 관리자 및 데이터 관리자는 중요한 데이터를 볼 수 없습니다. Always Encrypted는 권한이 없는 클라이언트에서 실제 디스크까지 테이블 엔드에서 끝까지 중요한 열을 암호화합니다.
Always Encrypted는 같음 비교를 지원하므로 DBA는 SQL 명령의 일부로 암호화된 열을 계속 쿼리할 수 있습니다. Always Encrypted는 Azure Key Vault, Windows 인증서 저장소, 및 로컬 하드웨어 보안 모듈과 같은 다양한 키 저장소 옵션과 함께 사용될 수 있습니다.
| 특징 | 항상 암호화됨 | 투명한 데이터 암호화 |
|---|---|---|
| 암호화 범위 | 엔드투엔드 | 미사용 데이터 |
| 서버는 중요 데이터에 액세스 가능 | 아니요 | 예, 암호화는 미사용 데이터를 위한 것이므로 |
| 허용되는 T-SQL 작업 | 같음 비교 | 모든 T-SQL 노출 영역 사용 가능 |
| 기능을 사용하려면 앱 변경이 필요함 | 최소 | 최소 |
| 암호화 세분성 | 열 수준 | 데이터베이스 수준 |
데이터베이스의 중요한 데이터에 대한 액세스를 제한하려면 어떻게 해야 하나요?
모든 애플리케이션에는 모든 사용자가 볼 수 로부터 보호해야 하는 중요한 데이터가 데이터베이스에 있습니다. 조직의 특정 인원은 이 데이터를 보아야 하지만, 다른 인원은 이 데이터를 볼 수 없어야 합니다. 이러한 경우 중요한 데이터를 마스킹하거나 전혀 노출하지 않도록 해야 합니다. SQL Database는 권한이 없는 사용자가 중요한 데이터를 볼 수 없도록 하는 두 가지 방식을 제공합니다.
동적 데이터 마스킹 은 애플리케이션 계층에서 권한이 없는 사용자에게 마스킹하여 중요한 데이터 노출을 제한할 수 있는 데이터 마스킹 기능입니다. 마스킹 패턴을 만들 수 있는 마스킹 규칙을 정의하고(예:
XXX-XX-0000국가 ID SSN의 마지막 4자리만 표시하고 대부분의 숫자를 문자로X마스킹) 마스킹 규칙에서 제외할 사용자를 식별합니다. 마스킹은 즉시 이루어지며 여러 데이터 범주에 사용할 수 있는 다양한 마스킹 기능이 있습니다. 동적 데이터 마스킹을 사용하면 데이터베이스에서 중요한 데이터를 자동으로 감지하여 마스킹을 적용할 수 있습니다.행 수준 보안을 사용하면 행 수준에서 액세스를 제어할 수 있습니다. 즉, 쿼리를 실행하는 사용자(그룹 멤버십 또는 실행 컨텍스트)에 따라 데이터베이스 테이블의 특정 행이 숨겨집니다. 액세스 제한은 앱 논리를 간소화하기 위해 애플리케이션 계층 대신에 데이터베이스 계층에서 수행됩니다. 먼저 필터 조건자를 만들고 노출되지 않는 행을 필터링한 다음 보안 정책에서 해당 행에 액세스할 수 있는 사용자를 정의합니다. 마지막으로 최종 사용자가 자신의 쿼리를 실행하면 사용자의 권한에 따라 제한된 행을 보거나 해당 행을 전혀 볼 수 없습니다.
클라우드에서 암호화 키를 관리하려면 어떻게 해야 하나요?
Always Encrypted(클라이언트 쪽 암호화) 및 투명한 데이터 암호화(미사용 암호화)에 대한 키 관리 옵션이 있습니다. 암호화 키를 정기적으로 회전하는 것이 좋습니다. 회전 빈도는 내부 조직 규정은 물론 규정 요구 사항과도 일치해야 합니다.
투명한 데이터 암호화(TDE)
TDE에는 두 가지 키 계층 구조가 있습니다. 각 사용자 데이터베이스의 데이터는 대칭 AES-256 데이터베이스 고유 DEK(데이터베이스 암호화 키)로 암호화되고, 이 키는 다시 서버 고유 비대칭 RSA 2048 마스터 키로 암호화됩니다. 마스터 키는 다음 방식 중 하나를 통해 관리할 수 있습니다.
- Azure SQL Database에 의해 자동으로
- 또는 Azure Key Vault를 키 저장소로 사용하여
기본적으로 TDE의 마스터 키는 Azure SQL Database에서 관리됩니다. 조직에서 마스터 키를 제어하려는 경우 Azure Key Vault 를 키 저장소로 사용할 수 있습니다. Azure Key Vault를 사용하여 조직은 키 프로비저닝, 회전 및 권한 제어에 관한 제어권을 갖습니다. 회전 또는 TDE 마스터 키 형식 전환은 DEK을 다시 암호화함으로 빠릅니다. 보안과 데이터 관리 간에 역할이 분리된 조직의 경우 보안 관리자는 Azure Key Vault에서 TDE 마스터 키에 대한 키 자료를 프로비전하고 데이터베이스 관리자에게 서버의 미사용 데이터 암호화에 사용할 수 있도록 Azure Key Vault 키 식별자를 제공할 수 있습니다. Key Vault는 Microsoft가 암호화 키를 보거나 추출할 수 없게 설계되어 있습니다. 조직에 대한 중앙 집중식 키 관리도 얻게 됩니다.
항상 암호화됨
또한 Always Encrypted에는 두 키 계층 구조가 있습니다. 중요한 데이터의 열은 AES 256열 암호화 키(CEK)로 암호화되고, 이 열은 다시 열 마스터 키(CMK)로 암호화됩니다. Always Encrypted에 제공되는 클라이언트 드라이버는 CMK 길이에 제한이 없습니다. CEK의 암호화된 값은 데이터베이스에 저장되고 CMK는 Windows 인증서 저장소, Azure Key Vault 또는 하드웨어 보안 모듈과 같은 신뢰할 수 있는 키 저장소에 저장됩니다.
CEK 및 CMK는 모두 회전할 수 있습니다.
CEK 회전은 데이터 작업의 크기이며 암호화된 열이 포함된 테이블의 크기에 따라 시간이 많이 소요될 수 있습니다. 따라서 그에 따라 CEK 회전을 신중하게 계획해야 합니다.
반면 CMK 회전은 데이터베이스 성능을 방해하지 않으며, 역할을 분리하여 수행할 수 있습니다.
다음 다이어그램은 Always Encrypted의 열 마스터 키에 대한 키 저장소 옵션을 보여줍니다.
조직과 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 보안 센터를 방문하여 조직에 중요한 규격을 검토하여 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 플랫폼은 서버의 데이터베이스에 대해 사용률 기록을 분석하여 비용 최적화 옵션을 평가하고 권고합니다. 이 분석은 일반적으로 실행 가능한 권장 사항을 분석하고 구축하는 데 몇 주간의 활동이 필요합니다.
비용 권장 사항의 Azure SQL 서버에서 배너 알림을 받을 수 있습니다. 자세한 내용은 Azure SQL Database에서 여러 데이터베이스를 관리 및 확장하고 Azure SQL Database에대한 비용을 계획하고 관리하는 데 도움이 되는 탄력적 풀을 참조하세요.
SQL Database의 성능 및 리소스 사용률을 모니터링하려면 어떻게 해야 하나요?
다음 방법을 사용하여 SQL Database에서 성능 및 리소스 사용률을 모니터링할 수 있습니다.
데이터베이스 Watcher
데이터베이스 Watcher는 심층 워크로드 모니터링 데이터를 수집하여 데이터베이스 성능, 구성 및 상태에 대한 자세한 보기를 제공합니다. Azure Portal의 대시보드는 Azure SQL 자산의 단일 창 보기와 모니터링되는 각 리소스에 대한 자세한 보기를 제공합니다. 데이터는 Azure 구독의 중앙 데이터 저장소로 수집됩니다. 수집된 데이터를 쿼리, 분석, 내보내기, 시각화하고 다운스트림 시스템과 통합할 수 있습니다.
데이터베이스 Watcher에 대한 자세한 내용은 다음 문서를 참조하세요.
- 데이터베이스 Watcher로 Azure SQL 워크로드 모니터링(프리뷰)
- 빠른 시작: Azure SQL을 모니터링하는 감시자 만들기(미리 보기)
- 감시자 만들기 및 구성(미리 보기)
- 데이터베이스 Watcher 데이터 수집 및 데이터 세트(프리뷰)
- 데이터베이스 Watcher 모니터링 데이터 분석(프리뷰)
- 데이터베이스 Watcher FAQ
Azure Portal
Azure Portal은 개요 창에서 데이터베이스를 선택하고 차트를 선택하면 데이터베이스의 사용률을 보여 줍니다. CPU 비율, DTU 비율, 데이터 IO 비율, 세션 비율 및 데이터베이스 크기 비율을 포함하는, 여러 가지 메트릭을 표시하도록 차트를 수정할 수 있습니다.
또한 이 차트로부터 리소스로 경고를 구성할 수도 있습니다. 이러한 경고를 사용하면 리소스 상태에 이메일로 응답하거나 HTTPS/HTTP 엔드포인트에 쓰거나 작업을 수행할 수 있습니다. 자세한 내용은 Azure Portal을 사용하여 Azure SQL Database 및 Azure Synapse Analytics에 대한 경고 만들기를 참조하세요.
동적 관리 뷰
지난 1시간 동안의 리소스 사용량 통계 기록을 반환하려면 sys.dm_db_resource_stats 동적 관리 뷰를 쿼리하고, 지난 14일 동안의 기록을 반환하려면 sys.resource_stats 시스템 카탈로그 뷰를 쿼리할 수 있습니다.
쿼리 성능 Insight
쿼리 성능 Insight를 사용하면 상위 리소스 소비량 쿼리 및 특정 데이터베이스에 대한 장기 실행 쿼리 기록을 볼 수 있습니다. 리소스 사용률, 기간 및 실행 빈도를 통해 쿼리를 빠르게 식별 TOP 할 수 있습니다. 쿼리를 추적하고 재발을 검색할 수 있습니다. 이 기능을 사용하려면 데이터베이스에 대해 쿼리 저장소를 사용하도록 설정되어 있어야 하며 활성 상태여야 합니다.
성능 문제가 발생합니다. SQL Database 문제 해결 방법론이 SQL Server와 어떻게 다른가요?
쿼리 및 데이터베이스 성능 문제를 진단하는 데 사용하는 문제 해결 기술의 주요 부분은 동일하게 유지됩니다. 동일한 데이터베이스 엔진이 클라우드를 구동합니다. Azure SQL Database를 사용하면 성능 문제를 더욱 쉽게 해결하고 진단할 수 있습니다. 또한 사용자를 대신하여 이러한 수정 작업 중 일부를 수행할 수 있으며 경우에 따라 자동으로 사전에 수정할 수도 있습니다.
QPI( Query Performance Insight ) 및 데이터베이스 관리자 와 같은 지능형 기능을 함께 사용하면 성능 문제 해결에 대한 접근 방식이 크게 도움이 될 수 있으므로 방법론의 차이는 이러한 측면에서 다릅니다. 즉, 현재 문제를 해결하는 데 도움이 될 수 있는 필수 세부 정보를 수동으로 분쇄하는 작업을 더 이상 수행할 필요가 없습니다. 힘든 작업은 플랫폼이 대신 수행합니다. 그 중 한 가지 예가 QPI입니다. QPI를 사용하면 쿼리 수준까지 드릴다운하고 과거 추세를 살펴보고 쿼리가 회귀한 정확한 시기를 파악할 수 있습니다. 데이터베이스 관리자는 인덱스 누락, 인덱스 삭제, 쿼리 매개 변수화 등 전반적인 성능을 개선하는 데 도움이 될 수 있는 항목에 대한 권장 사항을 제공합니다.
성능 문제 해결의 경우 애플리케이션 성능에 영향을 주는 것이 애플리케이션인지 아니면 애플리케이션을 지원하는 데이터베이스인지 파악하는 것이 중요합니다. 종종 성능 문제는 애플리케이션 계층에 있는 경우가 많습니다. 아키텍처 또는 데이터 액세스 패턴일 수도 있습니다. 예를 들어 네트워크 대기 시간에 민감한 수다스러운 애플리케이션이 있다고 생각해 보세요. 이 경우 애플리케이션이 애플리케이션과 서버 간의 빈번한 왕복 요청과 혼잡한 네트워크로 인해 영향을 받습니다. 이러한 짧은 요청이 빠르게 누적됩니다. 이 경우 성능을 향상시키려면 일괄 처리 쿼리를 사용하여 왕복 대기 시간을 줄이고 애플리케이션의 성능을 향상시킬 수 있습니다.
또한 데이터베이스의 전반적인 성능이 저하되는 경우 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의 데이터베이스에 BACPAC 파일로 데이터를 가져올 수도 있습니다.
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로 데이터를 마이그레이션하는 방법에 대한 자세한 내용은 트랜잭션 복제 사용을 참조하세요.