Azure 활용: 매우 유연한 SQL 데이터베이스 인프라를 구축하는 방법

최근 몇 년 동안 서비스형 인프라(Infrastructure as a Service)와 서비스형 플랫폼(Platform as a Service)이 그 기능, 특히 리소스 효율성과 유연성으로 인해 다양한 프로젝트에서 점점 더 널리 보급되고 있다는 것은 비밀이 아닙니다. 이에 따라 마이크로소프트는 SQL을 사용할 수 있는 사용자 친화적인 환경을 만드는데 많은 시간과 노력을 쏟았다.

Social Discovery Group 팀은 SQL을 포함한 다양한 데이터베이스를 사용하여 제품을 강화합니다. 전 세계적으로 만나고 연결하는 데 도움이 되는 40개 이상의 글로벌 서비스 포트폴리오를 통해 당사의 사용자 기반에는 전 세계 2억 5천만 명 이상의 사용자가 포함됩니다. 사용자를 위한 제품의 신뢰성을 보장하기 위해 우리는 핵심 인프라의 일부를 클라우드에 유지합니다. 이는 탄력성, 보안 및 유연성을 향상시키는 데 도움이 됩니다.

우리는 Kubernetes 클러스터를 포함한 다양한 플랫폼에 서버 및 서비스 데이터베이스를 배포한 경험이 풍부합니다. 그러나 우리는 Azure 클라우드에서 관련 SQL 데이터베이스 인프라의 일부를 최대한 유연하고 효율적이며 안정적으로 만들어야 하는 필요성에 직면했습니다. Microsoft Azure 클라우드에서 SQL을 사용하는 방법에는 세 가지가 있습니다.

• Azure SQL 데이터베이스
• Azure SQL 관리형 인스턴스
• Azure 가상 머신의 SQL Server

조사 후에 우리는 Azure SQL 데이터베이스를 사용하기로 결정했습니다. 소위 Azure SQL 데이터베이스에 대해 들어본 적이 없는 사람들을 위해 명확히 하자면, 이는 Microsoft Azure의 일부로 제공되는 관리형 클라우드 데이터베이스입니다.

저는 다음과 같은 이점을 강조했습니다.

• 업데이트나 단종 지원에 대해 걱정할 필요가 없습니다.
• 간편한 구성 및 배포
• 배포(따라서 개발) 속도 및 확장성
• 고가용성
• 결함 허용;
• 백업 용이성;
• 비용 최적화;
• 통합된 Microsoft Azure 모니터링 시스템입니다.

이제 단계별로 이야기하고 데이터베이스를 배포하고 생성하는 과정을 살펴보겠습니다. Power Shell 스크립트나 Azure CLI를 사용하여 이 작업을 수행할 수 있지만 명확성을 위해 포털의 그래픽 인터페이스를 사용하여 프로세스를 살펴보겠습니다. 이렇게 하려면 Azure SQL로 이동하여 '만들기'를 클릭하고 'SQL 데이터베이스'를 선택합니다.

리소스 그룹을 지정하고 기존 서버가 있는지 여부를 선택하거나 새 서버를 생성하고(관리자의 이름 및 데이터 표시) 데이터베이스 이름을 지정합니다. 일반적인 워크로드에 대해 컴퓨팅 및 스토리지 리소스가 균형있게 혼합된 DTU(데이터베이스 트랜잭션 단위) 기반 번들 패키지를 선택하는 것이 좋습니다.

네트워크, 보안, 추가 설정 및 태그와 같은 설정 탭도 있습니다. 최소 표준 구성의 경우 기본적으로 변경하지 않고 그대로 둘 수 있습니다. 그런 다음 데이터베이스가 생성될 때까지 기다립니다. 이로써 최소한의 설정이 완료되고 베이스는 완성됩니다.

데이터베이스 리소스의 크기는 말 그대로 클릭 한 번으로 매우 쉽게 변경할 수 있으며, 리소스가 부족한 경우 크기와 성능 측면에서 필요한 매개변수를 설정할 수 있습니다.

그런 다음 IP 주소나 서브넷을 추가하거나 이 데이터베이스가 호스팅되는 서버의 방화벽에서 모든 연결을 허용하는 것을 잊지 않고 외부에서 원하는 방식으로 데이터베이스에 연결할 수 있습니다.

SSMS(SQL Server Management Studio)를 통해 연결하고 추가로 관리하는 것이 편리하지만 다른 도구와 Azure Portal 자체를 통해서도 가능합니다.

공용 연결 지점 외에도 필요한 서브넷에 서버를 추가하고 개인 DNS 영역을 구성하여 개인 연결 지점을 생성할 수도 있습니다.

내결함성에 대해 말하자면, 여기서는 다양한 지역에 기반을 둔 보호 서버 그룹인 장애 조치의 매우 편리하고 직관적인 구현을 볼 수 있습니다.

Azure에서는 장애 조치(failover) 그룹, 강제 장애 조치(failover) 및 자동 장애 조치(failover) 모드의 서버에서 데이터베이스를 추가 및 제거할 수 있습니다.

아래 스크린샷에서 이를 확인할 수 있습니다. 장애 조치 그룹의 이름을 정하고 서버를 장애 조치에 넣어 보겠습니다. 지정된 데이터베이스의 동기화가 자동으로 시작됩니다. 두 번째 서버는 읽기 전용 모드가 됩니다. 장애가 발생하면 트래픽이 자동으로 두 번째 지역으로 전환되고 기본 서버와 보조 서버가 자동으로 전환됩니다.

그러나 데이터베이스 자체에 데이터 수준 문제가 있는 경우 장애 조치는 도움이 되지 않습니다. 이 경우 반드시 백업을 생성해야 합니다. 포털 내에서 그리고 타사 도구 또는 예를 들어 Azure DevOps(파이프라인에서 SqlAzureDacpacDeployment + AzureFileCopy 작업을 사용할 수 있음)를 통해 백업을 구성할 수 있습니다. 포털 내의 백업 탭에서 백업이 구성되고 필요한 스토리지 정책이 설정됩니다.

타사 백업 도구를 사용하려는 경우 Azure DevOps 또는 SQL 패키지 도구를 고려하는 것이 좋습니다.

제 생각에는 포털 자체의 복구 프로세스가 그다지 편리하지 않습니다. 가장 먼저 눈에 띄는 것은 간단한 테스트 데이터베이스의 경우 복구 시간이 길다는 것입니다. 예를 들어, 어제 백업에서 30MB 기본 크기 데이터베이스를 복원하는 데 30분 이상이 걸렸습니다. Microsoft Azure 지원팀에 문의한 후 복구를 위해 PowerShell 스크립트를 사용하라는 조언을 받았으며 복구 프로세스를 위해 데이터베이스 크기가 S3 이상이어야 하며 나중에 크기를 줄일 수 있다는 알림을 받았습니다. 아래에서는 이 주제에 대한 내 스크립트와 개발 내용 중 일부를 제시할 것입니다. 이러한 내용은 개선되고 향상될 수 있지만 많은 분들이 유용하다고 생각하실 것입니다.

단계별로 안내해 드리겠습니다.

1. Windows에 PowerShell ISE가 설치되어 있지 않은 경우 여기에서 다운로드하세요. https://github.com/PowerShell/Pohell/releases/download/v7.3.0/PowerShell-7.3.0-win-x64.msi
   https://github.com/PowerShell/PowerShell/releases/download/v7.3.0/PowerShell-7.3.0-win-x86.msi
2. 다음으로 Azure 모듈을 설치해야 합니다. Install-Module Az
3. AZ 모듈을 설치한 후 AZ 모듈을 가져옵니다. Import-Module Az
4. 가져온 후에는 Azure 계정인 Connect-AzAccount에 연결할 수 있습니다. Azure 계정에 로그인하라는 팝업이 나타나면 연결됩니다.
5. PowerShell 스크립트 자체를 실행하십시오.

 “ #Variables in use $Database = Get-AzSqlDatabase -ResourceGroupName "Test" -ServerName "test-serv1" -DatabaseName "dbforscript" $TargetDB = "dbforscript_new" $PITRtimedate = "2022-12-02 10:00:00Z" ##вам нужно увидеть действительную дату и время на портале $PITRSLO = "S3" $PITRNEWSLO = "S0" $PITRedition = "Standard" $failoverGroupRG = "Test" $failoverGroupS = "test-serv1" $failoverGroupDB = "dbforscript" $removedbfromfgRG = "Test" $removedbfromfgS = "test-serv1" $removedbfromfgDB = "XXXXX" $dropreplicaRG = "Test" $dropreplicaS = "test-serv2" $dropreplicaDB = "dbforscript" $sourcedbRG = "Test" $sourcedbS = "test-serv1" $sourcedbDBname = "dbforscript" $sourcedbDBNEWname = "dbforscript_old" $TargetDBNEWname = "dbforscript" “

1 - 이 코드는 다른 이름으로 데이터베이스 복원을 시작합니다. 복원 중인 데이터베이스의 원래 이름이 "dbforscript"인 경우 복원된 데이터베이스의 이름은 dbforscript_new가 됩니다. 복원된 데이터베이스는 SLO 버전 S3 이상입니다. 이는 이 작업을 수행하는 데 권장되는 방법입니다. 이에 대한 변수는 $PITRSLO = "S3"이며 S3 이상을 사용할 수 있습니다. 그런 다음 SLO 수준을 원래 수준으로 재설정합니다. 이는 복구 전용입니다.

 “Restore-AzSqlDatabase -FromPointInTimeBackup -PointInTime $PITRtimedate -ResourceGroupName $Database.ResourceGroupName -ServerName $Database.ServerName -TargetDatabaseName $TargetDB -ResourceId $Database.ResourceID -Edition $PITRedition -ServiceObjectiveName $PITRSLO”

2 - 이 코드는 장애 조치 그룹(소스 데이터베이스: dbforscript)에서 소스 데이터베이스를 제거합니다.

 “$failoverGroup = Get-AzSqlDatabase -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -DatabaseName $failoverGroupdb | Remove-AzSqlDatabaseFromFailoverGroup -ResourceGroupName $removedbfromfgRG -ServerName $removedbfromfgS -FailoverGroupName $removedbfromfgDB”

3 - 이 코드는 복제본 데이터베이스가 위치한 서버(test-serv2 서버의 dbforscript)에서 복제본 데이터베이스를 제거합니다.

 “Remove-AzSqlDatabase -ResourceGroupName $dropreplicaRG -ServerName $dropreplicaS -DatabaseName $dropreplicaDB”

4 - 이 코드는 원래 데이터베이스의 이름을 다른 이름으로 바꿉니다. 이름을 바꾼 후 dbforscript는 dbforscript_old가 됩니다.

 “Set-AzSqlDatabase -ResourceGroupName $sourcedbRG -DatabaseName $sourcedbDBname -ServerName $sourcedbS -NewName $sourcedbDBNEWname”

5 - 이 코드는 복원된 데이터베이스의 이름을 원래 데이터베이스 이름으로 바꾸고 dbforscript_new의 이름을 dbforscript로 바꿉니다.

 “Set-AzSqlDatabase -ResourceGroupName $Database.ResourceGroupName -DatabaseName $TargetDB -ServerName $Database.ServerName -NewName $TargetDBNEWname”

6 - 이 코드는 데이터베이스 SLO 수준을 이전(원래) S0 값으로 되돌립니다. 데이터베이스가 기본인 경우 포털에서 S0에서 기본으로 업그레이드할 수 있습니다.

 “Set-AzSqlDatabase -ResourceGroupName $Database.ResourceGroupName -DatabaseName $TargetDBNEWname -ServerName $Database.ServerName -Edition $PITRedition -RequestedServiceObjectiveName $PITRNEWSLO -MaxSizeBytes 10737418240”

7 - 마지막 코드는 복원된 데이터베이스를 이미 원래 이름을 가진 장애 조치 그룹에 추가합니다(이전 코드에서 이름을 변경했기 때문에).

 “$failoverGroup = Get-AzSqlDatabase -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -DatabaseName $TargetDBNEWname | Add-AzSqlDatabaseToFailoverGroup -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -FailoverGroupName $removedbfromfgDB”

명령 뒤에 -ErrorAction Stop 매개변수를 추가하는 것을 고려할 수 있습니다. 이렇게 하면 오류 발생 시 다음 명령이 실행되지 않으며 눈덩이처럼 쌓이는 현상도 발생하지 않습니다.

또한 스크립트의 시작과 끝 부분에 Get-Date를 추가하여 실행 시간을 계산할 수 있습니다. 내 경우에는 이런 스크립트를 통해 약 3.3GB의 데이터베이스가 6분도 안 되어 복원됐다.

원한다면 반드시 스크립트를 최적화하고, Azure DevOps를 통해 추가하고, 변수 수를 줄이거나, 무언가를 하드코딩할 수 있지만 저는 가능한 한 자세하게 모든 사람이 이해할 수 있는 방식으로 설명하려고 노력했습니다.

Azure의 데이터베이스 모니터링과 Datadog과 같은 다양한 시스템과의 통합 기능은 특별한 주의를 기울일 가치가 있습니다. 모니터링은 매우 편리하지만 뉘앙스가 없는 것은 아닙니다. 예를 들어, 읽기 전용 사용자는 한 데이터베이스에 대한 모니터링만 볼 수 있었고 한꺼번에 볼 수는 없었습니다. 여기에 음영이 있습니다.

결론적으로 우리 팀은 업데이트 및 지원 중단과 관련된 문제를 해결하는 동시에 비용을 성공적으로 최적화했습니다. 성능, 탄력성, 개발 속도 및 유연성이 향상되었습니다. 또한 스크립트 구현을 통해 필요할 때 신속하게 복구할 수 있는 능력이 눈에 띄게 향상되었습니다.

Social Discovery Group의 수석 DevOps 엔지니어인 Pavel Shapurau가 작성했습니다.