앱 개발을 위한 모범 사례 고려
이 단원에서는 더 나은 성능, 복원력 및 보안을 보장하는 데 도움이 될 수 있는 Azure Database for MySQL - 유연한 서버를 사용하여 앱을 개발할 때 적용할 몇 가지 모범 사례를 살펴봅니다. 이러한 모범 사례는 다음과 같습니다.
- 리소스를 공동 배치합니다.
- 연결 풀링을 구현합니다.
- 올바른 앱 컨테이너 크기 선택
- 네트워킹 격리 및 SSL 연결을 구현합니다.
- 일시적인 오류를 관리하기 위한 재시도 논리를 구현합니다.
- 데이터베이스에 적합한 컴퓨팅 및 스토리지 크기를 선택합니다.
이러한 모범 사례는 다음 다이어그램과 같이 Azure Database for MySQL - 유연한 서버를 사용하여 앱 개발 프로세스 중 다양한 지점에서 활용됩니다.
참고 항목
이 모범 사례 목록은 완전하지 않습니다. 네트워킹, 보안, 모니터링, 성능 최적화, 비즈니스 연속성 및 재해 복구 등과 관련된 모범 사례 구현에 대한 자세한 가이드는 Azure Database for MySQL 설명서를 참조하세요.
리소스 공동 배치
Azure에 앱을 배포할 때 모든 리소스 종속성이 동일한 지역에서 호스트되는지 확인합니다. 지역 또는 가용성 영역에 리소스 인스턴스를 분산시키면 네트워크 대기 시간이 발생할 수 있으며, 이는 앱의 전반적인 성능에 영향을 미칠 수 있습니다.
연결 풀링 구현
앱 내에서 데이터베이스 연결을 관리하면 전체 앱 성능에 큰 영향을 미칠 수 있습니다. 앱 성능과 복원력을 개선하려면 연결 풀링을 구현하여 MySQL 유연한 서버에 연결하는 것이 좋습니다. 연결 풀러(예: ProxySQL)는 유휴 연결 수를 줄이고 기존 연결을 다시 사용할 수 있습니다.
팁
성능을 최적화하려면 키 코드 경로에서 연결이 설정되는 횟수와 이러한 연결을 설정하는 데 걸리는 시간을 줄입니다.
올바른 앱 컨테이너 크기 선택
앱 컨테이너에 적절한 크기를 선택하는 것이 중요하므로 앱에 예상 로드를 처리할 수 있는 충분한 컴퓨팅 및 메모리 리소스가 있는지 확인합니다. JMeter와 같은 도구를 사용하여 부하 테스트를 지원하면 결과에 따라 리소스 크기를 올바르게 조정하는 데 도움이 될 수 있습니다.
네트워크 격리 및 SSL 연결 구현
Azure Database for MySQL - VNet 통합(프라이빗 액세스 연결 방법)이 포함된 유연한 서버는 네트워크 보안 및 격리를 제공합니다. VNet 통합을 사용하여 VNet(가상 네트워크) 인프라에 대한 서버 액세스만 잠글 수 있습니다. 프라이빗 엔드포인트는 공용 인터넷에 대한 노출을 피하면서 개인 네트워크를 통해 안전하게 유연한 서버에 연결할 수 있도록 하여 이러한 보안을 강화합니다. 앱 및 데이터베이스 리소스를 단일 VNet 또는 동일하거나 다른 지역의 여러 VNet에서 보호할 수 있습니다(가상 네트워크 피어링을 사용하여 원활하게 연결됨).
또한 앱이 SSL(Secure Sockets Layer)을 사용하여 MySQL 유연한 서버에 연결되도록 하여 전송 중인 데이터를 보호하는 것이 좋습니다.
일시적인 오류를 관리하는 재시도 논리 구현
클라우드 환경은 네트워크 연결 중단 또는 서비스 시간 제한과 같은 일시적인 오류가 발생할 가능성이 높기 때문에 일반적으로 지연 후 요청을 다시 시도하여 앱에서 이러한 문제를 처리하는 논리를 구현하도록 해야 합니다.
첫 번째 재시도 전에 5초 동안 기다리는 것이 모범 사례입니다. 그런 다음 이후에 다시 시도할 때마다 대기 시간을 최대 60초까지 점차적으로 늘립니다. 고정된 횟수만큼 다시 시도한 후 앱은 작업이 실패한 것으로 간주하고 사용자가 지속적인 오류를 추가로 조사할 수 있도록 알려줄 수 있습니다.
데이터베이스에 적합한 컴퓨팅 및 스토리지 크기 선택
앱 성능과 비용 간에 적절한 균형을 이루려면 워크로드를 분석하고 MySQL 유연한 서버 인스턴스의 크기를 올바르게 조정해야 합니다.
Compute
세 가지 컴퓨팅 계층 중 하나에서 MySQL 유연한 서버를 만들 수 있습니다. 버스트 가능, 범용 및 중요 비즈니스용. 컴퓨팅 계층을 선택하기 위한 시작점으로 다음 표의 세부 정보를 고려합니다.
| 컴퓨팅 계층 | 대상 워크로드 |
|---|---|
| 버스트 가능 | 지속적으로 전체 CPU가 필요하지 않은 워크로드에 가장 적합합니다. 소규모 웹앱 및 개발 워크로드에 비용 효율적입니다. |
| 범용 | 확장성 있는 I/O 처리량과 함께 균형 잡힌 컴퓨팅 및 메모리가 필요한 대부분의 비즈니스 워크로드에 가장 적합합니다. 웹 및 모바일 앱과 기타 엔터프라이즈 앱을 호스트하는 서버를 예로 들 수 있습니다. |
| 중요 비즈니스용 | 더 빠른 트랜잭션 처리와 더 높은 동시성을 위해 메모리 내 성능이 필요한 고성능 데이터베이스 워크로드에 가장 적합합니다. 예를 들어 실시간 데이터를 처리하는 서버 및 고성능 트랜잭션 또는 분석 앱이 있습니다. |
MySQL 유연한 서버를 만든 후 크기를 조정할 수도 있지만 범용 또는 중요 비즈니스용 계층 간에만 스케일 업하거나 스케일 다운할 수 있습니다.
스토리지
스토리지 측면에서 스토리지 용량 한도에 가까워지면 확장할 수 있습니다. 스토리지 자동 증가 기능을 사용하도록 설정하여 스토리지 한도에 가까워지면 서비스가 스토리지 크기를 자동으로 조정하도록 할 수도 있습니다.
적시에 컴퓨팅 및 스토리지에 대한 합리적 결정을 내리려면 호스트 CPU 백분율, 호스트 메모리 백분율, Storage 백분율, IO 백분율, 활성 연결 등과 같은 주요 Azure Monitor 메트릭을 지속적으로 모니터링하거나 솔루션이 배포 제한에 접근할 때 알림을 표시하도록 경고를 설정합니다.
최적의 성능을 위해 IOPS 조정
Azure Database for MySQL - 유연한 서버에서 사용할 수 있는 중요한 향상된 기능은 기존의 사전 프로비전된 IOPS 기능을 보완하는 자동 크기 조정 IOPS(초당 입출력 작업) 기능입니다. 이 섹션에서는 사전 프로비전된 IOPS 및 자동 크기 조정 IOP 옵션을 사용하여 다양한 워크로드 요구 사항에 따라 데이터베이스 성능을 최적화하는 방법을 살펴봅니다.
미리 프로비전된 IOPS
사전 프로비전된 IOPS를 사용하여 데이터베이스 인스턴스에 특정 수의 IOPS를 할당할 수 있습니다. 이 기능은 일관되고 예측 가능한 성능이 필요한 워크로드에 매우 중요합니다. 정의된 IOPS 제한을 설정하여 데이터베이스가 초당 설정된 요청 수를 처리하여 안정적이고 신뢰할 수 있는 성능을 유지할 수 있도록 할 수 있습니다. 또한 워크로드 변경에 따라 프로비전된 IOPS 수를 유연하게 조정할 수 있으므로 데이터베이스 성능에 대한 확장성과 정밀한 제어가 모두 가능합니다.
IOPS 자동 크기 조정
자동 크기 조정 IOPS는 변동이 심한 워크로드를 효과적으로 관리하는 데 필수적인 기능인 동적 성능 크기 조정을 제공합니다. 이 기능을 사용하도록 설정하면 데이터베이스 서버는 사전 프로비저닝 없이 실시간 수요에 따라 IOPS를 자동으로 조정합니다. 이러한 유연성을 갖는 것은 다양한 성능 요구 사항을 경험할 수 있는 계층 1의 중요 업무용 앱에 특히 유용합니다.
자동 크기 조정 IOPS 기능을 사용하면 다음과 같은 주요 이점을 얻을 수 있습니다.
동적 스케일링: 자동 크기 조정 IOPS 기능은 실제 워크로드 수요에 따라 IOPS 제한을 자동으로 조정합니다. 이러한 동적 조정은 수동 개입 없이 데이터베이스가 최적의 성능 수준에서 일관되게 작동하도록 보장합니다.
워크로드 급증 처리: 이 기능을 사용하면 데이터베이스가 갑자스런 로드 증가를 원활하게 처리하여 최대치 기간 동안 앱 성능을 일관되게 유지할 수 있습니다. 이 기능은 서비스 가용성과 사용자 만족도를 유지하는 데 중요합니다.
비용 효율성: 실제 사용량에 관계없이 지정된 한도에 대해 비용을 지불하는 사전 프로비전된 IOPS와 달리 자동 크기 조정 IOPS는 실제로 사용된 I/O 작업에 대해서만 비용을 지불합니다. 이는 특히 변수 I/O 요구 사항이 있는 데이터베이스의 경우 상당한 비용 절감 효과를 가져올 수 있습니다.
간소화된 관리: 자동 크기 조정 IOPS는 수동 크기 조정 및 용량 계획의 필요성을 줄여 관리 리소스를 확보하므로 팀에서는 일상적인 유지 관리보다는 보다 전략적인 이니셔티브에 집중할 수 있습니다.