성능 추천 사항

아티클
07/17/2024

Azure Advisor 성능 권장 사항은 중요 비즈니스용 애플리케이션의 속도 및 응답성을 향상시키는 데 도움이 될 수 있습니다. Advisor 대시보드의 성능 탭에서 Advisor를 사용하여 성능 권장 사항을 볼 수 있습니다.

Azure Portal에 로그인합니다.
아무 페이지에서나 Advisor를 검색하고 선택합니다.
Advisor 대시보드에서 성능 탭을 선택합니다.

AI + 기계 학습

429 이 리소스에서 제한이 검색됨

Microsoft는 하루 동안 이 리소스에 대해 1,000개 이상의 429개 제한 오류가 있는 것을 관찰했습니다. 자동 크기 조정을 사용하도록 설정하여 더 많은 호출 볼륨을 더 잘 처리하고 429 오류 수를 줄이는 것이 좋습니다.

Azure AI 서비스 자동 크기 조정에 대해 자세히 알아봅니다.

Text Analytics 모델 버전 사용 중단

모델 버전을 최신 모델 버전 또는 최신 모델로 업그레이드하여 최신 및 최고 품질의 모델을 활용하세요.

Cognitive Service - TAUpgradeToLatestModelVersion(Text Analytics 모델 버전 사용 중단)에 대해 자세히 알아보세요.

Text Analytics 모델 버전 사용 중단

모델 버전을 최신 모델 버전 또는 최신 모델로 업그레이드하여 최신 및 최고 품질의 모델을 활용하세요.

Cognitive Service - TAUpgradeModelVersiontoLatest(Text Analytics 모델 버전 사용 중단)에 대해 자세히 알아보세요.

분석

최적의 성능을 위한 적절한 크기의 Data Explorer 리소스.

이 권장 사항은 권장 데이터 용량(80%)을 초과하는 모든 Data Explorer 리소스를 표시합니다. 성능을 향상시키기 위한 권장 작업은 표시된 권장 구성으로 확장하는 것입니다.

Data Explorer 리소스 - 적절한 크기의 ADX 리소스(최적의 성능을 위한 크기의 Data Explorer 리소스)에에 대해 자세히 알아보세요.

Data Explorer 테이블에 대한 테이블 캐시 정책 검토

이 권장 사항은 구성된 캐시 기간(정책)을 초과하여 되돌아보는 쿼리 수가 많은 Data Explorer 테이블을 표시합니다. 즉, 캐시 외부 데이터에 액세스하는 쿼리 백분율 기준 상위 10개 테이블이 표시됩니다. 성능을 향상시키기 위한 권장 조치: 이 테이블에 대한 쿼리를 필요한 최소 시간 범위(정의된 정책 내)로 제한합니다. 또는 전체 시간 범위의 데이터가 필요한 경우 캐시 기간을 권장 값으로 늘립니다.

Data Explorer 리소스 - UpdateCachePoliciesForAdxTables(Data Explorer 테이블에 대한 테이블 캐시 정책 검토)에 대해 자세히 알아보세요.

성능 향상을 위해 Data Explorer 테이블 캐시 정책 줄이기

테이블 캐시 정책을 줄이면 리소스 캐시에서 사용되지 않는 데이터가 정리되고 성능이 향상됩니다.

Data Explorer 리소스 - ReduceCacheForAzureDataExplorerTablesToImprovePerformance(성능 향상을 위해 Data Explorer 테이블 캐시 정책 줄이기)에 대해 자세히 알아보세요.

캐시 정책에서 캐시 늘리기

지난 달의 실제 사용량을 기반으로 캐시 정책을 업데이트하여 테이블의 핫 캐시를 늘립니다. 보존 기간은 항상 캐시 기간보다 길어야 합니다. 캐시를 늘리고 보존 기간이 캐시 기간보다 짧으면 보존 정책을 업데이트합니다. 분석은 데이터를 검사한 사용자 쿼리만을 기반으로 합니다.

Data Explorer 리소스 - IncreaseCacheForAzureDataExplorerTablesToImprovePerformance(캐시 정책에서 캐시 증가)에 대해 자세히 알아보세요.

데이터 탐색기 리소스에 최적화된 자동 크기 조정 사용

리소스에서 자동으로 크기를 조정하여 성능을 향상시킬 수 있었던 것 같습니다(지난주의 실제 사용량, 캐시 사용률, 수집 사용률, CPU 및 스트리밍 수집 사용률 기준). 비용과 성능을 최적화하려면 최적화된 자동 크기 조정을 사용하는 것이 좋습니다.

Data Explorer 리소스 - PerformanceEnableOptimizedAutoscaleAzureDataExplorer(Data Explorer 리소스에 최적화된 자동 크기 조정 사용)에 대해 자세히 알아보세요.

가장 최근 데이터에서 발생하는 읽기

75%가 넘는 읽기 요청이 memstore에 도달합니다. 이는 주로 최근 데이터에 대한 읽기임을 나타냅니다. 최근 데이터 읽기는 memstore에서 플러시가 발생하더라도 최근 파일에 액세스하여 캐시에 배치해야 한다고 제안합니다.

HDInsight 클러스터 - HBaseMemstoreReadPercentage(가장 최근 데이터에서 발생하는 읽기)에 대해 자세히 알아보세요.

클러스터 성능을 향상시키려면 HBase 클러스터에서 가속 쓰기 기능을 사용하는 것이 좋습니다.

HDInsight 팀의 시스템 로그에 지난 7일 동안 클러스터에서 다음 시나리오가 발생했다고 표시되므로 이 Advisor 권장 사항이 표시됩니다.

긴 WAL 동기화 대기 시간
많은 쓰기 요청 수(1시간에 avg_write_requests/second/node 1000건 초과가 3번 이상)

이러한 조건은 클러스터의 과도한 워크로드로 인해 클러스터에서 긴 쓰기 대기 시간이 발생하고 있음을 나타냅니다.

클러스터의 성능을 향상시키려면 Azure HDInsight HBase에서 제공하는 가속화된 쓰기 기능을 활용하는 것이 좋습니다. HDInsight Apache HBase 클러스터의 가속 쓰기 기능은 클라우드 스토리지를 사용하는 대신 모든 RegionServer(작업자 노드)에 프리미엄 SSD 관리 디스크를 연결합니다. 따라서 애플리케이션에 대해 쓰기 대기 시간이 단축되고 복원력이 향상됩니다.

이 기능에 대한 자세한 내용은 다음 링크를 참조하세요.

HDInsight 클러스터 - AccWriteCandidate(클러스터 성능을 향상시키려면 HBase 클러스터에서 가속화된 쓰기 기능을 사용하는 것이 좋습니다.)에 대해 자세히 알아보세요.

75%가 넘는 쿼리가 전체 검사 쿼리임

클러스터의 검사 쿼리 중 75% 이상이 전체 지역/테이블 검사를 수행하고 있습니다. 전체 지역 또는 테이블 검사를 방지하도록 검사 쿼리를 수정합니다.

HDInsight 클러스터 - ScanQueryTuningcandidate(전체 검색 쿼리가 쿼리의 75%를 초과합니다.)에 대해 자세히 알아보세요.

업데이트를 차단하는 지역 수 확인

업데이트 차단 방지를 위해 지역 수를 조정해야 합니다. 새 노드를 추가하여 클러스터를 스케일 업해야 할 수 있습니다.

HDInsight 클러스터 - RegionCountCandidate(업데이트를 차단하는 지역 수를 확인합니다.)에 대해 자세히 알아보세요.

플러시 스레드를 늘리는 것이 좋습니다.

지역 서버의 플러시 큐 크기가 100보다 크거나 업데이트가 자주 차단됩니다. 플러시 처리기를 튜닝하는 것이 좋습니다.

HDInsight 클러스터 - FlushQueueCandidate(플러시 스레드를 늘리는 것이 좋습니다.)에 대해 자세히 알아보세요.

압축을 더 빠르게 완료하기 위해 압축 스레드를 늘리는 것이 좋습니다.

지역 서버의 압축 큐가 2000보다 많으므로 더 많은 데이터에 압축이 필요합니다. 압축이 느리면 읽을 파일 수가 많아지므로 읽기 성능에 영향을 줄 수 있습니다. 압축되지 않은 파일이 많아지면 Azure 파일 시스템과 파일이 상호 작용하는 방법과 관련된 힙 사용량에도 영향을 줄 수 있습니다.

HDInsight 클러스터 - CompactionQueueCandidate(압축을 더 빠르게 완료하기 위해 압축 스레드를 늘리는 것이 좋습니다.)에 대해 자세히 알아보세요.

행이 6천만 개 미만인 CCI(클러스터형 Columnstore 인덱스)가 있는 테이블

클러스터형 columnstore 테이블은 데이터가 세그먼트로 구성됩니다. columnstore 테이블에 대해 최적의 쿼리 성능을 구현하려면 높은 세그먼트 품질을 유지하는 것이 중요합니다. 세그먼트 품질은 압축된 행 그룹의 행 수를 기준으로 측정할 수 있습니다.

Synapse 작업 영역 - SynapseCCIGuidance(행이 6천만 개 미만인 CCI(Clustered Columnstore Indexes)가 있는 테이블)에 대해 자세히 알아보세요.

SynapseManagementClient SDK 버전 업데이트

새로운 SynapseManagementClient는 .NET SDK 4.0 이상을 사용합니다.

Synapse 작업 영역 - UpgradeSynapseManagementClientSDK(SynapseManagementClient SDK 버전 업데이트)에 대해 자세히 알아보세요.

컴퓨팅

vSAN 용량 사용률이 위험 임계값을 초과했습니다.

VSAN 용량 사용률이 75%에 도달했습니다. 클러스터 사용률은 SLA 준수를 위해 75% 중요 임계값 미만으로 유지되어야 합니다. vSphere 클러스터에 새 노드를 추가하여 용량을 늘리거나 VM을 삭제하여 사용량을 줄이거나 VM 워크로드를 조정하세요.

Azure VMware 솔루션 프라이빗 클라우드 - vSANCapacity(vSAN 용량 사용률이 임계 임계값을 초과함)에 대해 자세히 알아봅니다.

사용자의 위치에 더 가깝게 VM을 배포하여 사용자 환경 및 연결을 개선합니다.

VM이 사용자가 Azure Virtual Desktop에 연결하는 지역과 다르거나 멀리 있는 지역에 있는 것이 확인되었습니다. 사용자 지역이 멀면 연결 응답 시간이 길어지고 전체 사용자 환경에 영향을 줄 수 있습니다.

가상 머신 - RegionProximitySessionHosts(사용자의 위치에 더 가깝게 VM을 배포하여 사용자 환경 및 연결 개선)에 대해 자세히 알아보세요.

관리 디스크를 사용하여 디스크 I/O 제한 방지

가상 머신 디스크가 속한 스토리지 계정이 확장성 목표에 도달했으며, I/O 제한의 영향을 받게 됩니다. 가상 머신의 성능 저하를 방지하고 스토리지 관리를 간소화하려면 관리 디스크를 사용하세요.

가상 머신 - ManagedDisksStorageAccount(관리 디스크를 사용하여 디스크 I/O 제한 방지)에 대해 자세히 알아보세요.

성능을 위해 표준 HDD에서 프리미엄 SSD로 Managed Disks 변환

표준 HDD 디스크가 성능 목표에 근접하고 있습니다. Azure 프리미엄 SSD는 IO 집약적 워크로드가 있는 가상 머신에 대기 시간이 짧은 고성능 디스크를 지원합니다. 표준 HDD 디스크를 프리미엄 SSD 디스크로 업그레이드하여 디스크 성능을 향상시킵니다. 업그레이드하려면 VM을 다시 부팅해야 하며 3~5분이 걸립니다.

디스크 - MDHDDtoPremiumForPerformance(성능을 위해 표준 HDD에서 프리미엄 SSD로 Managed Disks 변환)에 대해 자세히 알아보세요.

가속화된 네트워킹을 사용하여 네트워크 성능 및 대기 시간 개선

이 기능을 지원할 수 있는 기존 배포의 VM 리소스에서 가속화된 네트워킹이 사용하도록 설정되지 않은 것이 감지되었습니다. 설명서에 자세히 나와 있는 대로 VM OS 이미지가 가속화된 네트워킹을 지원하는 경우 이러한 VM에서 이 무료 기능을 사용하도록 설정했는지 확인하여 클라우드에서 네트워킹 워크로드의 성능 및 대기 시간을 최대한 개선합니다.

가상 머신 - AccelNetConfiguration(가속화된 네트워킹을 사용하여 네트워크 성능 및 대기 시간 개선)에 대해 자세히 알아보세요.

프로덕션 워크로드에 SSD 디스크 사용

동일한 VM에서 SSD 디스크를 사용하는 동시에 표준 HDD 디스크도 사용하는 것이 확인되었습니다. 표준 HDD 관리 디스크는 개발/테스트 및 백업에 사용하고, 프리미엄 SSD 또는 표준 SSD는 프로덕션에 사용하는 것이 좋습니다. 프리미엄 SSD는 IO 사용량이 많은 워크로드가 탑재된 가상 시스템에 고성능 및 대기 시간이 짧은 디스크 지원을 제공합니다. 표준 SSD는 일관되고 더 짧은 대기 시간을 제공합니다. 대기 시간, 안정성 및 가용성을 개선하려면 지금 디스크 구성을 업그레이드하세요. 업그레이드하려면 VM을 다시 부팅해야 하며 3~5분이 걸립니다.

가상 머신 - MixedDiskTypeToSSDPublic(프로덕션 워크로드에 SSD 디스크 사용)에 대해 자세히 알아보세요.

일관된 성능 및 향상된 대기 시간을 위해 프로덕션 가상 머신을 프로덕션 디스크와 맞춤

최상의 성능을 얻으려면 프로덕션 가상 머신에 프로덕션 디스크가 필요합니다. 프로덕션 수준 가상 머신을 실행하지만 표준 HDD가 포함된 성능이 낮은 디스크를 사용하는 것으로 확인됩니다. 프로덕션 디스크에 연결된 디스크(표준 SSD 또는 프리미엄 SSD)를 업그레이드하면 더 일관된 환경과 향상된 대기 시간의 이점을 얻을 수 있습니다.

가상 머신 - MatchProdVMProdDisks(일관된 성능 및 향상된 대기 시간을 위해 프로덕션 가상 머신을 프로덕션 디스크와 맞춤)에 대해 자세히 알아보세요.

가속화된 네트워킹을 사용하려면 VM을 중지했다가 시작해야 할 수 있음

기능이 요청된 경우에도 가속화된 네트워킹이 기존 배포의 VM 리소스에서 사용되지 않는 것이 감지되었습니다. 이와 같은 드문 경우에는 편의상 AccelNet을 다시 사용하기 위해 VM을 중지했다가 시작해야 할 수 있습니다.

가상 머신 - AccelNetDisengaged(가속화된 네트워킹을 사용하려면 VM을 중지했다가 시작해야 할 수 있음)에 대해 자세히 알아보세요.

로그 디스크에 대해 Ultra Disk 낮은 대기 시간을 활용 및 데이터베이스 워크로드 성능 향상

데이터베이스 워크로드와 동일한 지역에서 Ultra Disk를 사용할 수 있습니다. Ultra Disk는 데이터베이스 워크로드를 위해 높은 처리량, 높은 IOPS 및 일관된 낮은 대기 시간 디스크 스토리지를 제공합니다. 이제 Oracle DB의 경우 Oracle DB 버전에 따라 Ultra Disk에 4k 또는 512E 섹터 크기를 사용할 수 있습니다. SQL Server의 경우 Ultra Disk를 로그 디스크에 사용하면 더 많은 성능을 데이터베이스에 제공할 수 있습니다. 로그 디스크를 Ultra Disk로 마이그레이션하기 위한 지침은 여기를 참조하세요.

가상 머신 - AzureStorageVmUltraDisk(로그 디스크에 대해 Ultra Disk 낮은 대기 시간 활용 및 데이터베이스 워크로드 성능 향상)에 대해 자세히 알아보세요.

가장 활동적인 가상 머신의 크기를 업그레이드하여 리소스 소진을 방지하고 성능을 개선합니다.

지난 7일 동안의 데이터를 분석한 결과 다양한 메트릭(즉, CPU, 메모리 및 VM I/O) 전반에서 사용률이 높은 VM(가상 머신)이 식별되었습니다. 이러한 VM은 SKU 제한에 근접하거나 도달하므로 성능 문제가 발생할 수 있습니다. 성능을 개선하려면 SKU를 업그레이드하는 것이 좋습니다.

가상 머신 - UpgradeSizeHighVMUtilV0(가장 활동적인 가상 머신의 크기를 업그레이드하여 리소스 소모를 방지하고 성능을 향상시킴)에 대해 자세히 알아보세요.

컨테이너

지원되지 않는 Kubernetes 버전이 검색됨

지원되지 않는 Kubernetes 버전이 검색됩니다. Kubernetes 클러스터가 지원되는 버전으로 실행되는지 확인합니다.

Kubernetes 서비스 - UnsupportedKubernetesVersionIsDetected(지원되지 않는 Kubernetes 버전이 검색됨)에 대해 자세히 알아보세요.

지원되지 않는 Kubernetes 버전이 검색됨

지원되지 않는 Kubernetes 버전이 검색됩니다. Kubernetes 클러스터가 지원되는 버전으로 실행되는지 확인합니다.

HDInsight 클러스터 풀 - UnsupportedHiloAKSVersionIsDetected(지원되지 않는 Kubernetes 버전이 검색됨)에 대해 자세히 알아봅니다.

단일 노드 풀이 있는 클러스터

단일 노드 풀을 사용하는 대신 하나 이상의 노드 풀을 추가하는 것이 좋습니다. 여러 풀을 사용하면 중요한 시스템 Pod를 애플리케이션에서 격리하여 잘못 구성되었거나 악성 애플리케이션 Pod에서 실수로 시스템 Pod를 종료하지 못하도록 방지할 수 있습니다.

Kubernetes 서비스 - ClustersWithASingleNodePool(단일 노드 풀이 있는 클러스터)에 대해 자세히 알아보세요.

Fleet API를 최신 버전으로 업데이트

이 구독에 포함된 리소스에 대한 오래된 Fleet API의 SDK 호출이 식별되었습니다. 최신 기능과 향상된 성능을 얻으려면 최신 SDK 버전으로 전환하는 것이 좋습니다.

Kubernetes Fleet Manager | 미리 보기 - UpdateToLatestFleetApi(Fleet API를 최신 버전으로 업데이트)에 대해 자세히 알아보세요.

데이터베이스

Azure Cosmos DB 쿼리 페이지 크기(MaxItemCount)를 -1로 구성

100인 쿼리 페이지 크기를 Azure Cosmos DB 컨테이너의 쿼리에 대한 사용하고 있습니다. 빠른 검색의 경우에는 페이지 크기를 -1로 사용하는 것이 좋습니다.

Azure Cosmos DB 계정 - CosmosDBQueryPageSize(Azure Cosmos DB 쿼리 페이지 크기(MaxItemCount)를 -1로 구성)에 대해 자세히 알아봅니다.

Azure Cosmos DB 컨테이너에 복합 인덱스 추가

Azure Cosmos DB 컨테이너는 높은 RU(요청 단위) 요금을 발생시키는 ORDER BY 쿼리를 실행하고 있습니다. 복합 인덱스를 컨테이너의 인덱싱 정책에 추가하여 RU 사용량을 개선하고 이러한 쿼리의 대기 시간을 줄이는 것이 좋습니다.

Azure Cosmos DB 계정 - CosmosDBOrderByHighRUCharge(Azure Cosmos DB 컨테이너에 복합 인덱스 추가)에 대해 자세히 알아봅니다.

필요한 항목만 인덱싱하도록 Azure Cosmos DB 인덱싱 정책 최적화

Azure Cosmos DB 컨테이너는 문서의 모든 속성을 인덱싱하는 기본 인덱싱 정책을 사용하고 있습니다. 대용량 문서를 저장하기 때문에 많은 수의 속성이 인덱싱되어 요청 단위 사용이 많아지고 쓰기 대기 시간이 느려집니다. 쓰기 성능을 최적화하려면 쿼리에 사용된 속성만 인덱싱하도록 기본 인덱싱 정책을 재정의하는 것이 좋습니다.

Azure Cosmos DB 계정 - CosmosDBDefaultIndexingWithManyPaths(필요한 항목만 인덱싱하도록 Azure Cosmos DB 인덱싱 정책 최적화)에 대해 자세히 알아봅니다.

최적의 데이터 배포를 위해 계층적 파티션 키 사용

계정에는 컨테이너의 논리 파티션 크기가 20GB 제한을 초과할 수 있도록 허용하는 사용자 지정 설정이 있습니다. Azure Cosmos DB 팀에서 다른 파티션 키를 사용하여 애플리케이션을 다시 설계할 시간을 제공하기 위해 이 설정을 임시 조치로 적용했습니다. 제한이 증가하면 SLA 보증이 적용되지 않으므로 장기 솔루션으로 권장되지 않습니다. 이제 계층적 파티션 키(미리 보기)를 사용하여 애플리케이션을 다시 설계할 수 있습니다. 이 기능을 사용하면 최대 3개의 파티션 키를 설정하여 20GB 제한을 초과할 수 있으므로 가상 키를 사용하는 다중 테넌트 시나리오 또는 워크로드에 적합합니다.

Azure Cosmos DB 계정 - CosmosDBHierarchicalPartitionKey(최적의 데이터 배포를 위해 계층적 파티션 키 사용)에 대해 자세히 알아봅니다.

SDK에서 직접 연결을 사용하도록 Azure Cosmos DB 애플리케이션 구성

Azure Cosmos DB 애플리케이션이 Azure Cosmos DB .NET 또는 Java SDK를 통해 게이트웨이 모드를 사용 중임을 확인했습니다. 짧은 대기 시간 및 더 높은 확장성을 위해 직접 연결로 전환하는 것이 좋습니다.

Azure Cosmos DB 계정 - CosmosDBGatewayMode(SDK에서 직접 연결을 사용하도록 Azure Cosmos DB 애플리케이션 구성)에 대해 자세히 알아봅니다.

최적의 리소스 사용률을 위한 크기 조정으로 성능 향상

최고의 성능을 유지하려면 시스템 리소스의 효율성을 최대화해야 합니다. Microsoft 시스템은 CPU 사용량을 면밀히 모니터링하고 12시간 동안 CPU 사용량이 90% 임계값을 초과하면 사전 경고가 트리거됩니다. 이 경고는 Azure Cosmos DB for MongoDB vCore 사용자에 증가된 CPU 사용량을 알릴 뿐만 아니라 더 높은 계층으로 크기 조정하는 데 유용한 지침도 제공합니다. 보다 강력한 계층으로 업그레이드하면 개선된 성능을 활용하고 시스템이 최고의 잠재력을 발휘할 수 있도록 보장할 수 있습니다.

Azure Cosmos DB for MongoDB vCore 클러스터 크기 조정 및 구성에 대해 자세히 알아보세요.

PerformanceBoostervCore

CPU 사용량이 12시간 내에 90%를 초과하면 사용자에게 높은 사용량에 대한 알림이 표시됩니다. 또한 더 나은 성능을 얻기 위해 더 높은 계층으로 확장하는 것이 좋습니다.

Cosmos DB 계정 - ScaleUpvCoreRecommendation(PerformanceBoostervCore)에 대해 자세히 알아보세요.

MariaDB 서버용 스토리지 제한 확장

시스템에서 서버가 현재 프로비전된 스토리지 값의 제한에 도달하고 있어 제한될 수 있음을 보여줍니다. 스토리지 제한에 근접하면 성능이 저하되거나 서버가 읽기 전용 모드로 전환될 수 있습니다. 지속적인 성능을 보장하려면 프로비저닝된 스토리지 용량을 늘리거나 자동 스토리지 증가를 위해 "자동 증가" 기능을 켜는 것이 좋습니다.

MariaDB 서버 - OrcasMariaDbStorageLimit(MariaDB 서버용 스토리지 제한 확장)에 대해 자세히 알아보세요.

MariaDB 서버 vCores 수 늘리기

시스템에서 CPU가 지난 7일 동안 장기간 높은 사용률로 실행되었음을 보여줍니다. CPU 사용률이 높으면 쿼리 성능이 저하될 수 있습니다. 성능을 높이려면 더 큰 컴퓨팅 크기로 전환하는 것이 좋습니다.

MariaDB 서버 - OrcasMariaDbCpuOverload(MariaDB 서버 vCores 증가)에 대해 자세히 알아봅니다.

MariaDB 서버를 상위 SKU로 확장

시스템에서 특정 SKU에 대해 지원되는 최대 연결로 인해 서버가 연결 요청을 지원하지 못할 수 있음을 보여줍니다. 이에 따라 성능에 부정적인 영향을 미치는 많은 수의 연결 요청 실패가 발생할 수 있습니다. 성능을 높이려면 vCore 수를 늘리거나 메모리 최적화 SKU로 전환하여 상위 메모리 SKU로 이동하는 것이 좋습니다.

MariaDB 서버 - OrcasMariaDbConcurrentConnection(MariaDB 서버를 상위 SKU로 확장)에 대해 자세히 알아보세요.

MariaDB 서버를 메모리 최적화 SKU로 이동

시스템에서 이 서버의 버퍼 풀에 높은 변동이 있어 쿼리 성능이 느려지고 IOPS가 증가할 수 있음을 보여줍니다. 성능을 높이려면 워크로드 쿼리를 검토하여 메모리 사용량을 최소화할 기회를 살펴보세요. 이러한 기회를 찾을 수 없는 경우 더 많은 메모리를 제공하는 상위 SKU로 전환하거나 스토리지 크기를 늘려서 IOPS를 늘리는 것이 좋습니다.

MariaDB 서버 - OrcasMariaDbMemoryCache(MariaDB 서버를 메모리 최적화 SKU로 이동)에 대해 자세히 알아보세요.

감사 로그의 안정성 향상

시스템에서 지난 하루 동안 서버의 감사 로그가 손실되었을 수 있음을 보여줍니다. 서버에서 CPU 사용량이 많은 워크로드가 발생하거나 서버에서 짧은 기간 동안 많은 수의 감사 로그를 생성하는 경우 감사 로그 손실이 발생할 수 있습니다. audit_log_events, audit_log_exclude_users, audit_log_include_users 서버 매개 변수를 사용하여 감사 목적에 필요한 이벤트만 기록하는 것이 좋습니다. 워크로드로 인해 서버의 CPU 사용량이 높으면 서버의 vCore를 늘려서 성능을 향상시키는 것이 좋습니다.

MariaDB 서버 - OrcasMariaDBAuditLog(감사 로그의 안정성 향상)에 대해 자세히 알아보세요.

MySQL 읽기 복제본 서버 추가

시스템에서 읽기 집약적인 워크로드가 실행되고 있을 수 있음을 보여줍니다. 이에 따라 이 서버에 대한 리소스 경합이 발생할 수 있습니다. 이 리소스 경합으로 인해 서버의 쿼리 성능이 저하될 수 있습니다. 성능을 향상하려면 읽기 복제본을 추가하고 읽기 워크로드 중 일부를 복제본에 오프로드하는 것이 좋습니다.

MySQL 서버 - OrcasMySQLReadReplica(MySQL 읽기 복제본 서버 추가)에 대해 자세히 알아보세요.

MySQL 연결 관리 개선

시스템에서 MySQL 서버에 연결하는 애플리케이션이 연결을 제대로 관리하지 못할 수 있음을 보여줍니다. 이로 인해 불필요한 리소스를 사용하고 전반적인 애플리케이션 대기 시간이 길어질 수 있습니다. 연결 관리를 향상시키려면 수명이 짧은 연결 수를 줄이고 불필요한 유휴 연결을 제거하는 것이 좋습니다. 이 작업은 ProxySQL과 같은 서버 쪽 연결 풀러를 구성하여 수행할 수 있습니다.

MySQL 서버 - OrcasMySQLConnectionPooling(MySQL 연결 관리 개선)에 대해 자세히 알아보세요.

감사 로그의 안정성 향상

시스템에서 지난 하루 동안 서버의 감사 로그가 손실되었을 수 있음을 보여줍니다. 서버에서 CPU 사용량이 많은 워크로드가 발생하거나 서버에서 짧은 기간 동안 많은 수의 감사 로그를 생성하는 경우 이 감사 로그 손실이 발생할 수 있습니다. audit_log_events, audit_log_exclude_users, audit_log_include_users 서버 매개 변수를 사용하여 감사 목적에 필요한 이벤트만 기록하는 것이 좋습니다. 워크로드로 인해 서버의 CPU 사용량이 높으면 서버의 vCore를 늘려서 성능을 향상시키는 것이 좋습니다.

MySQL 서버 - OrcasMySQLAuditLog(감사 로그의 안정성 향상)에 대해 자세히 알아보세요.

MySQL 임시 테이블 크기 조정을 최적화하여 성능 향상

시스템에서 낮은 임시 테이블 매개 변수 설정으로 인해 MySQL 서버에서 불필요한 I/O 오버헤드가 발생할 수 있음을 보여줍니다. 이로 인해 불필요한 디스크 기반 트랜잭션이 발생하고 성능이 저하될 수 있습니다. 디스크 기반 트랜잭션 수를 줄이려면 'tmp_table_size' 및 'max_heap_table_size' 매개 변수 값을 늘리는 것이 좋습니다.

MySQL 서버 - OrcasMySqlTmpTables(MySQL 임시 테이블 크기 조정을 최적화하여 성능 향상)에 대해 자세히 알아보세요.

MySQL 연결 대기 시간 개선

시스템에서 MySQL 서버에 연결하는 애플리케이션이 연결을 제대로 관리하지 못할 수 있음을 보여줍니다. 이로 인해 애플리케이션 대기 시간이 길어질 수 있습니다. 연결 대기 시간을 개선시키려면 연결 리디렉션을 사용하도록 설정하는 것이 좋습니다. PHP 드라이버의 연결 리디렉션 기능을 사용하도록 설정하여 이 작업을 수행할 수 있습니다.

MySQL 서버 - OrcasMySQLConnectionRedirection(MySQL 연결 대기 시간 개선)에 대해 자세히 알아보세요.

MySQL 유연한 서버의 저장 한도 늘리기

시스템에서 서버가 현재 프로비전된 스토리지 값의 제한에 도달하고 있어 제한될 수 있음을 보여줍니다. 스토리지 제한에 근접하면 성능이 저하되거나 서버가 읽기 전용 모드로 전환될 수 있습니다. 지속적인 성능을 보장하려면 프로비저닝된 스토리지 양을 늘리는 것이 좋습니다.

Azure Database for MySQL 유연한 서버 - OrcasMeruMySqlStorageUpsell(MySQL 유연한 서버에 대한 저장 한도 증가)에 대해 자세히 알아봅니다.

MySQL 유연한 서버를 더 높은 SKU로 확장

시스템에서 유연한 서버가 현재 SKU와 연결된 연결 제한을 초과하고 있음을 보여줍니다. 실패한 연결 요청 수가 많으면 서버 성능에 부정적인 영향을 미칠 수 있습니다. 성능을 개선하려면 vCore 수를 늘리거나 더 높은 SKU로 전환하는 것이 좋습니다.

Azure Database for MySQL 유연한 서버 - OrcasMeruMysqlConnectionUpsell(MySQL 유연한 서버를 더 높은 SKU로 크기 조정)에 대해 자세히 알아봅니다.

MySQL 유연한 서버 vCore를 늘립니다.

Azure Database for MySQL 유연한 서버 - OrcasMeruMysqlCpuUpcell(MySQL 유연한 서버 vCores 증가)에 대해 자세히 알아봅니다.

MySQL 임시 테이블 크기 조정을 최적화하여 성능을 개선합니다.

시스템에서 낮은 임시 테이블 매개 변수 설정으로 인해 MySQL 서버에서 불필요한 I/O 오버헤드가 발생할 수 있음을 보여줍니다. 불필요한 I/O 오버헤드로 인해 불필요한 디스크 기반 트랜잭션이 발생하고 성능이 저하될 수 있습니다. 디스크 기반 트랜잭션 수를 줄이려면 'tmp_table_size' 및 'max_heap_table_size' 매개 변수 값을 늘리는 것이 좋습니다.

Azure Database for MySQL 유연한 서버 - OrcasMeruMysqlTmpTable(MySQL 임시 테이블 크기를 최적화하여 성능 개선)에 대해 자세히 알아봅니다.

MySQL 서버를 메모리 최적화 SKU로 이동

시스템에서 이 서버에 대한 메모리 사용량이 높아 쿼리 성능이 느려지고 IOPS가 증가할 수 있음을 보여줍니다. 성능을 높이려면 워크로드 쿼리를 검토하여 메모리 사용량을 최소화할 기회를 살펴보세요. 이러한 기회를 찾을 수 없는 경우 더 많은 메모리를 제공하는 상위 SKU로 전환하거나 스토리지 크기를 늘려서 IOPS를 늘리는 것이 좋습니다.

Azure Database for MySQL 유연한 서버 - OrcasMeruMysqlMemoryUpsell(MySQL 서버를 메모리 최적화 SKU로 이동)에 대해 자세히 알아봅니다.

MySQL 읽기 복제본 서버 추가

시스템에서 읽기 집약적인 워크로드가 실행되고 있을 수 있음을 보여줍니다. 이에 따라 이 서버에 대한 리소스 경합이 발생할 수 있습니다. 이로 인해 서버의 쿼리 성능이 저하될 수 있습니다. 성능을 향상하려면 읽기 복제본을 추가하고 읽기 워크로드 중 일부를 복제본에 오프로드하는 것이 좋습니다.

Azure Database for MySQL 유연한 서버 - OrcasMeruMysqlReadReplicaUpsell(MySQL 읽기 복제본 서버 추가)에 대해 자세히 알아봅니다.

work_mem을 늘려 정렬 및 해시에서 과도한 디스크 분산 방지

시스템에서 work_mem 구성이 PostgreSQL 서버에 비해 너무 작아서 디스크 유출이 발생하고 쿼리 성능이 저하되었음을 보여줍니다. 이를 개선하려면 서버에 대한 work_mem 제한을 늘리는 것이 좋습니다. 그러면 디스크에서 정렬 또는 해시가 발생할 때 발생하는 이 시나리오를 줄이고 전체 쿼리 성능을 향상시킬 수 있습니다.

PostgreSQL 서버 - OrcasPostgreSqlWorkMem(work_mem을 늘려 정렬 및 해시에서 과도한 디스크 분산 방지)에 대해 자세히 알아보세요.

새로운 Ev5 컴퓨팅 하드웨어로 워크로드 성능 30% 향상

새로운 Ev5 컴퓨팅 하드웨어를 사용하면 더 높은 동시성과 더 나은 처리량으로 워크로드 성능을 30% 높일 수 있습니다. Azure Portal에서 컴퓨팅+스토리지 옵션으로 이동하여 추가 비용 없이 Ev5 컴퓨팅으로 전환합니다. Ev5 컴퓨팅은 QPS 및 대기 시간 측면에서 다른 VM 시리즈 중 최고의 성능을 제공합니다.

Azure Database for MySQL 유연한 서버 - OrcasMeruMySqlComputeSeriesUpgradeEv5(새 Ev5 컴퓨팅 하드웨어를 사용하여 워크로드 성능을 30% 향상)에 대해 자세히 알아보세요.

하이퍼스케일(Citus) 서버 그룹에 대한 스토리지 제한 증가

시스템에서 서버 그룹에 있는 하나 이상의 노드가 현재 프로비전된 스토리지 값의 제한에 도달하고 있어 제한될 수 있음을 보여줍니다. 이로 인해 성능이 저하되거나 서버가 읽기 전용 모드로 이동될 수 있습니다. 지속적인 성능을 보장하려면 프로비저닝된 디스크 공간을 늘리는 것이 좋습니다.

PostgreSQL 서버 - OrcasPostgreSqlCitusStorageLimitHyperscaleCitus(하이퍼스케일(Citus) 서버 그룹에 대한 스토리지 제한 증가)에 대해 자세히 알아보세요.

PostgreSQL 서버 vCores 수 늘리기

7일 동안 CPU 사용량은 2시간 이상 동안 90% 이상, 50% 시간 동안 50% 이상, 20% 시간 동안 최대 사용량 중 하나 이상이었습니다. CPU 사용률이 높으면 쿼리 성능이 저하될 수 있습니다. 성능을 개선하려면 서버를 더 높은 컴퓨팅 성능을 갖춘 더 큰 SKU로 이동하는 것이 좋습니다. Azure Database for PostgreSQL 유연한 서버 - Azure 데이터베이스의 PostgreSQL용 고급 서버 SKU에 대해 자세히 알아봅니다.

Azure Database에서 PostgreSQL에 대한 log_statement 설정 최적화

시스템에서 log_statement가 사용하도록 설정되어 있음을 보여줍니다. 더 나은 성능을 위해 NONE으로 설정합니다.

Azure Database for PostgreSQL 유연한 서버 - Azure 데이터베이스에서 PostgreSQL에 대한 log_statement 설정 최적화에 대해 자세히 알아봅니다.

Azure Database에서 PostgreSQL에 대한 log_duration 설정 최적화

로깅 설정으로 인해 잠재적인 성능 저하가 발생할 수 있습니다. 이러한 설정을 최적화하려면 log_duration 서버 매개 변수를 OFF로 설정합니다.

Azure Database for PostgreSQL 유연한 서버 - Azure 데이터베이스에서 PostgreSQL의 log_duration 설정 최적화에 대해 자세히 알아봅니다.

Azure Database에서 PostgreSQL에 대한 log_min_duration 설정 최적화

log_min_duration 서버 매개 변수가 60,000ms(1분) 미만으로 설정되어 있으며, 이로 인해 성능이 저하될 수 있습니다. log_min_duration_statement 매개 변수를 -1로 설정하여 로깅 설정을 최적화할 수 있습니다.

Azure Database for PostgreSQL 유연한 서버 - Azure 데이터베이스에서 PostgreSQL의 log_min_duration 설정 최적화에 대해 자세히 알아봅니다.

Azure Database에서 PostgreSQL에 대한 log_error_verbosity 설정 최적화

서버가 VERBOSE 오류 로그를 출력하도록 구성되었습니다. 이는 데이터베이스의 문제를 해결하는 데 유용할 수 있지만 데이터베이스 성능이 저하될 수도 있습니다. 성능을 개선하려면 log_error_verbosity 서버 매개 변수를 DEFAULT 설정으로 변경하는 것이 좋습니다.

Azure Database for PostgreSQL 유연한 서버 - Azure 데이터베이스에서 PostgreSQL에 대한 log_error_verbosity 설정 최적화에 대해 자세히 알아봅니다.

PostgreSQL - 유연한 서버 성능을 개선하기 위해 검사점이 너무 자주 발생하는지 식별

서버에서 검사점이 자주 발생합니다. 문제를 해결하려면 max_wal_size 서버 매개 변수를 늘리는 것이 좋습니다.

Azure Database for PostgreSQL 유연한 서버 – max_wal_size 늘리기에 대해 자세히 알아봅니다.

비활성 논리적 복제 슬롯을 식별하여 PostgreSQL - 유연한 서버 성능 개선

서버에 비활성 논리 복제본 슬롯이 있어 서버 성능 및 가용성이 저하될 수 있습니다. 비활성 복제 슬롯을 삭제하거나 LSN(로그 시퀀스 번호)이 서버의 현재 LSN에 근접하도록 이러한 슬롯에서 변경 내용을 사용하는 것이 좋습니다.

Azure Database for PostgreSQL 유연한 서버 – 사용되지 않거나 비활성 논리적 복제 슬롯에 대해 자세히 알아봅니다.

PostgreSQL - 유연한 서버 성능 개선을 위한 장기 실행 트랜잭션 식별

24시간 이상 실행되는 트랜잭션이 있습니다. 문제를 식별하고 완화하려면 문제 해결 가이드의 높은 CPU 사용량-> 장기 실행 트랜잭션 섹션을 검토합니다.

Azure Database for PostgreSQL 유연한 서버 – 문제 해결 가이드를 사용한 장기 실행 트랜잭션에 대해 자세히 알아봅니다.

PostgreSQL - 유연한 서버 성능 개선을 위한 분리된 준비된 트랜잭션 식별

고아아가 된 준비된 트랜잭션이 있습니다. 준비된 트랜잭션을 롤백/커밋합니다. 권장 사항은 문제 해결 가이드의 자동 진공 블로커 -> 자동 진공 블로커 섹션에서 공유됩니다.

Azure Database for PostgreSQL 유연한 서버 – 문제 해결 가이드를 사용하여 분리된 준비된 트랜잭션에 대해 자세히 알아봅니다.

PostgreSQL - 유연한 서버 성능 개선을 위한 트랜잭션 랩어라운드 식별

서버가 10억 건의 트랜잭션을 포함하여 50% 랩어라운드 제한을 초과했습니다. 문제 해결 가이드의 자동 진공 블로커 -> 긴급 자동 진공 및 랩어라운드 섹션에서 공유된 권장 사항을 참조하세요.

Azure Database for PostgreSQL 유연한 서버 – 문제 해결 가이드를 사용한 트랜잭션 랩어라운드에 대해 자세히 알아봅니다.

PostgreSQL - 유연한 서버 성능 개선을 위한 높은 블로트 비율 식별

서버에는 bloat_ratio(데드 튜플/(라이브 튜플 + 데드 튜플) > 80%)가 있습니다. 문제 해결 가이드의 Autovacuum 모니터링 섹션에서 공유된 권장 사항을 참조하세요.

Azure Database for PostgreSQL 유연한 서버 - 문제 해결 가이드를 사용하여 높은 블로트 비율에 대해 자세히 알아봅니다.

하이퍼스케일(Citus) 서버 그룹에 대한 스토리지 제한 증가

하이퍼스케일(Citus) 서버 그룹 - MarlinStorageLimitRecommendation(하이퍼스케일(Citus) 서버 그룹에 대한 스토리지 제한 증가)에 대해 자세히 알아보세요.

데이터베이스를 SSPG에서 FSPG로 마이그레이션

영역 복원력 HA, 예측 가능한 성능, 최대 제어, 사용자 지정 유지 관리 기간, 비용 최적화 제어 및 간소화된 개발자 환경과 같은 다양한 기능을 제공하는 새 Azure Database for PostgreSQL 유연한 서버 제품을 고려합니다.

Azure Database for PostgreSQL 유연한 서버 - OrcasPostgreSqlMeruMigration(데이터베이스를 SSPG에서 FSPG로 마이그레이션)에 대해 자세히 알아보세요.

네트워크 대역폭이 높은 상태에서 실행할 때 캐시 및 애플리케이션 성능 개선

캐시 인스턴스는 응답 없음, 데이터 손실 또는 사용할 수 없음이 발생할 수 있는 높은 네트워크 대역폭에서 실행되지 않으면 가장 효율적으로 수행됩니다. 네트워크 대역폭을 줄이거나 용량이 더 많은 다른 크기 또는 SKU로 확장하는 모범 사례를 적용합니다.

Redis Cache Server - RedisCacheNetworkBandwidth(네트워크 대역폭이 높은 상태에서 실행할 때 캐시 및 애플리케이션 성능 개선)에 대해 자세히 알아보세요.

여러 클라이언트가 연결된 상태에서 실행할 때 캐시 및 애플리케이션 성능 개선

캐시 인스턴스는 응답 없음, 데이터 손실 또는 사용할 수 없음이 발생할 수 있는 높은 네트워크 대역폭에서 실행되지 않으면 가장 효율적으로 수행됩니다. 서버 부하를 줄이거나 용량이 더 많은 다른 크기 또는 SKU로 확장하는 모범 사례를 적용합니다.

Redis Cache Server - RedisCacheConnectedClients(여러 클라이언트가 연결된 상태에서 실행할 때 캐시 및 애플리케이션 성능 개선)에 대해 자세히 알아보세요.

여러 클라이언트가 연결된 상태에서 실행할 때 캐시 및 애플리케이션 성능 개선

Redis Cache Server - RedisCacheConnectedClientsHigh(여러 클라이언트가 연결된 상태에서 실행할 때 캐시 및 애플리케이션 성능 개선)에 대해 자세히 알아보세요.

서버 부하가 높은 상태에서 실행할 때 캐시 및 애플리케이션 성능 개선

Redis Cache Server - RedisCacheServerLoad(서버 부하가 높은 상태에서 실행할 때 캐시 및 애플리케이션 성능 개선)에 대해 자세히 알아보세요.

서버 부하가 높은 상태에서 실행할 때 캐시 및 애플리케이션 성능 개선

Redis Cache Server - RedisCacheServerLoadHigh(서버 부하가 높은 상태에서 실행할 때 캐시 및 애플리케이션 성능 개선)에 대해 자세히 알아보세요.

메모리 압력이 높은 상태에서 실행할 때 캐시 및 애플리케이션 성능 개선

캐시 인스턴스는 응답 없음, 데이터 손실 또는 사용할 수 없음이 발생할 수 있는 높은 네트워크 대역폭에서 실행되지 않으면 가장 효율적으로 수행됩니다. 메모리를 줄이거나 용량이 더 많은 다른 크기 또는 SKU로 확장하는 모범 사례를 적용합니다.

Redis Cache Server - RedisCacheUsedMemory(메모리 압력이 높은 상태에서 실행할 때 캐시 및 애플리케이션 성능 개선)에 대해 자세히 알아보세요.

메모리 RSS 사용량이 높을 때 캐시 및 애플리케이션 성능을 개선시킵니다.

Redis Cache 서버 - RedisCacheUsedMemoryRSS(메모리 RSS 사용량이 많을 때 캐시 및 애플리케이션 성능 개선)에 대해 자세히 알아봅니다.

캐시 인스턴스는 클라이언트 애플리케이션이 실행되는 호스트 컴퓨터에서 캐시의 응답을 따라갈 수 있으면 가장 효율적으로 수행됨

캐시 인스턴스는 클라이언트 애플리케이션이 실행되는 호스트 컴퓨터에서 캐시의 응답을 따라갈 수 있으면 가장 효율적으로 수행됩니다. 클라이언트 호스트 컴퓨터가 메모리, CPU 또는 네트워크 대역폭에서 핫 실행되는 경우 캐시 응답이 애플리케이션에 충분히 빠르게 도달하지 못하여 대기 시간이 더 길어질 수 있습니다.

Redis Cache 서버 - UnresponsiveClient(캐시 인스턴스는 클라이언트 애플리케이션이 실행되는 호스트 컴퓨터가 캐시의 응답을 따라갈 수 있을 때 가장 잘 수행됨)에 대해 자세히 알아봅니다.

DevOps

통합

API Management 리소스를 대체 버전으로 업그레이드

구독이 사용 중단으로 예약된 이미지에서 실행되고 있습니다. 2023년 9월 30일에 2021-08-01 이전의 Azure API Management 서비스에 대한 모든 API 버전이 사용 중지되고 API 호출이 실패합니다. 서비스 중단을 방지하기 위해 최신 버전으로 업그레이드하세요.

API Management - apimgmtdeprecation(API Management 리소스를 대체 버전으로 업그레이드)에 대해 자세히 알아보세요.

모바일

채팅 SDK 권장 버전 사용

Azure Communication Services 채팅 SDK를 사용하여 다양한 실시간 채팅을 애플리케이션에 추가할 수 있습니다. 최신 수정 사항 및 기능을 확인하려면 권장 버전의 채팅 SDK로 업데이트합니다.

Communication Service - UpgradeChatSdk(채팅 SDK 권장 버전 사용)에 대해 자세히 알아보세요.

Resource Manager SDK의 권장 버전 사용

Resource Manager SDK는 Azure Communication Services 리소스를 만들고 관리하는 데 사용할 수 있습니다. 최신 수정 사항 및 기능을 확인하려면 Resource Manager SDK의 권장 버전으로 업데이트합니다.

Communication Service - UpgradeResourceManagerSdk(Resource Manager SDK의 권장 버전 사용)에 대해 자세히 알아보세요.

권장되는 ID SDK 버전 사용

Azure Communication Services ID SDK를 사용하여 ID, 사용자 및 액세스 토큰을 관리할 수 있습니다. 최신 수정 사항 및 기능을 확인하려면 권장되는 버전의 ID SDK로 업데이트합니다.

Communication Service - UpgradeIdentitySdk(권장되는 ID SDK 버전 사용)에 대해 자세히 알아보세요.

SMS SDK 권장 버전 사용

Azure Communication Services SMS SDK를 사용하여 SMS 메시지를 보내고 받을 수 있습니다. 최신 수정 사항 및 기능을 확인하려면 SMS SDK의 권장 버전으로 업데이트합니다.

Communication Service - UpgradeSmsSdk(SMS SDK 권장 버전 사용)에 대해 자세히 알아보세요.

전화 번호 SDK의 권장 버전 사용

Azure Communication Services 전화 번호 SDK를 사용하여 전화 번호를 가져오고 관리할 수 있습니다. 최신 수정 사항 및 기능을 확인하려면 전화 번호 SDK의 권장 버전으로 업데이트합니다.

Communication Service - UpgradePhoneNumbersSdk(전화 번호 SDK의 권장 버전 사용)에 대해 자세히 알아보세요

통화 SDK 권장 버전 사용

Azure Communication Services 통화 SDK를 사용하여 음성, 동영상, 화면 공유 및 기타 실시간 통신을 사용하도록 설정할 수 있습니다. 최신 수정 사항 및 기능을 확인하려면 통화 SDK의 권장 버전으로 업데이트합니다.

Communication Service - UpgradeCallingSdk(통화 SDK 권장 버전 사용)에 대해 자세히 알아보세요.

통화 자동화 SDK의 권장 버전 사용

Azure Communication Services 통화 자동화 SDK는 호출 만들기 및 관리, 오디오 재생 및 기록 구성에 사용할 수 있습니다. 최신 수정 사항 및 기능을 확인하려면 통화 자동화 SDK의 권장 버전으로 업데이트합니다.

Communication Service - UpgradeServerCallingSdk(통화 자동화 SDK의 권장 버전 사용)에 대해 자세히 알아보세요.

Network Traversal SDK의 권장 버전 사용

Azure Communication Services Network Traversal SDK는 하위 수준 데이터 전송을 위해 TURN 서버에 액세스하는 데 사용할 수 있습니다. 최신 수정 사항 및 기능을 확인하려면 권장되는 Network Traversal SDK 버전으로 업데이트합니다.

Communication Service - UpgradeTurnSdk(Network Traversal SDK의 권장 버전 사용)에 대해 자세히 알아보세요

Rooms SDK 권장 버전 사용

Azure Communication Services Rooms SDK를 사용하여 통화에 참가할 수 있는 사용자, 모임 시기 및 협업 방법을 제어할 수 있습니다. 최신 수정 사항 및 기능을 확인하려면 Rooms SDK의 권장 버전으로 업데이트합니다. 지난 48~60시간 동안 권장되지 않는 버전이 발견되었습니다.

Communication Service - UpgradeRoomsSdk(권장되는 대화방 SDK 버전 사용)에 대해 자세히 알아보세요.

네트워킹

SDK 버전 권장 업그레이드

최신 버전의 Azure Front Door 표준 및 프리미엄 클라이언트 라이브러리 또는 SDK에는 고객이 보고하고 QA 프로세스를 통해 적극적으로 식별된 문제에 대한 수정 사항이 포함되어 있습니다. 최신 버전은 Azure Front Door 표준 및 프리미엄을 사용하여 전반적인 환경을 개선할 수 있는 새로운 기능 외에도 안정성 및 성능 최적화를 제공합니다.

Front Door 프로필 - UpgradeCDNToLatestSDKLanguage(업그레이드 SDK 버전 권장 사항)에 대해 자세히 알아봅니다.

SDK 버전 권장 업그레이드

최신 버전의 Azure Traffic Collector SDK는 QA 프로세스를 통해 사전에 식별된 이슈에 대한 수정 사항을 포함하고, 최신 리소스 모델을 지원하며, ATC를 사용하여 전반적인 환경을 개선할 수 있는 안정성 및 성능 최적화를 제공합니다.

Azure Traffic Collector - UpgradeATCToLatestSDKLanguage(SDK 버전 업그레이드 권장 사항)에 대해 자세히 알아보세요.

대역폭 요구 사항에 맞게 ExpressRoute 회로 대역폭 업그레이드

최근 제공된 회로 대역폭의 90% 이상 사용 중입니다. 할당된 대역폭을 초과하면 ExpressRoute를 통해 보내는 삭제된 패킷이 증가합니다. 대역폭 요구 사항이 높은 상태로 유지되는 경우 성능을 유지하기 위해 회로 대역폭을 업그레이드합니다.

ExpressRoute 회로 - UpgradeERCircuitBandwidth(대역폭 요구 사항에 맞게 ExpressRoute 회로 대역폭 업그레이드)에 대해 자세히 알아보세요.

Azure에 대한 프라이빗 연결로 더 예측 가능하고 일관된 대기 시간을 환경합니다.

Azure ExpressRoute를 사용하여 온-프레미스 네트워크를 Azure로 확장하여 중요 비즈니스용 앱의 성능, 개인 정보 보호 및 안정성을 개선합니다. 클라우드 교환 시설을 통해 또는 POP 및 IPVPN 연결을 통해 WAN에서 직접 프라이빗 ExpressRoute 연결을 설정합니다.

구독 - AzureExpressRoute(Azure에 대한 프라이빗 연결로 더 예측 가능하고 일관된 대기 시간 환경)에 대해 자세히 알아봅니다.

워크로드 API를 최신 버전으로 업그레이드(Azure Center for SAP solutions API)

이 리소스 그룹 아래의 리소스에 대해 오래된 워크로드 API 버전에 대한 호출을 확인했습니다. Azure Center for SAP solutions의 최신 기능 및 성능 향상에 대한 중단 없는 액세스를 보장하려면 최신 워크로드 API 버전으로 전환하는 것이 좋습니다. SAP 솔루션(VIS)에 대해 여러 개의 가상 인스턴스가 권장 사항에 표시되는 경우 모든 VIS 리소스에 대한 API 버전을 업데이트해야 합니다.

구독 - UpdateToLatestWaasApiVersionAtSub(워크로드 API를 최신 버전(Azure Center for SAP solutions API)으로 업그레이드)에 대해 자세히 알아보세요.

워크로드 SDK를 최신 버전으로 업그레이드(Azure Center for SAP solutions SDK)

이 리소스 그룹 아래의 리소스에서 오래된 워크로드 SDK 버전에 대한 호출을 확인했습니다. Azure Center for SAP solutions의 모델 품질, 성능 및 서비스 가용성 측면에서 최신 기능과 최상의 결과를 얻으려면 최신 워크로드 SDK 버전으로 업그레이드합니다. SAP 솔루션(VIS)에 대해 여러 개의 가상 인스턴스가 권장 사항에 표시되는 경우 모든 VIS 리소스에 대한 SDK 버전을 업데이트해야 합니다.

구독 - UpgradeToLatestWaasSdkVersionAtSub(워크로드 SDK를 최신 버전(Azure Center for SAP solutions SDK)으로 업그레이드)에 대해 자세히 알아보세요.

DNS TTL(Time to Live)을 60초로 구성

TTL(Time to Live)은 클라이언트에서 Azure Traffic Manager에 요청하면 받는 응답에 대한 최근 시점에 영향을 줍니다. TTL 값을 줄이면 장애 조치(failover) 시 클라이언트가 정상으로 작동하는 엔드포인트로 더 빠르게 라우팅됩니다. 가능한 한 빨리 상태 엔드포인트로 트래픽을 라우팅하기 위해 TTL을 60초로 구성합니다.

Traffic Manager 프로필 - ProfileTTL(DNS TTL(Time to Live)을 60초로 구성)에 대해 자세히 알아보세요.

DNS TTL(Time to Live)을 20초로 구성

TTL(Time to Live)은 클라이언트에서 Azure Traffic Manager에 요청하면 받는 응답에 대한 최근 시점에 영향을 줍니다. TTL 값을 줄이면 장애 조치(failover) 시 클라이언트가 정상으로 작동하는 엔드포인트로 더 빠르게 라우팅됩니다. 가능한 한 빨리 상태 엔드포인트로 트래픽을 라우팅하기 위해 TTL을 20초로 구성합니다.

Traffic Manager 프로필 - FastFailOverTTL(DNS TTL(Time to Live)을 20초로 구성)에 대해 자세히 알아보세요.

DNS TTL(Time to Live)을 60초로 구성

Traffic Manager 프로필 - ProfileTTL(DNS TTL(Time to Live)을 60초로 구성)에 대해 자세히 알아보세요.

지속적으로 높은 CPU 사용을 처리하기 위해 가상 네트워크 게이트웨이 SKU의 크기 증가 고려

트래픽 부하가 높으면 높은 CPU 사용으로 인해 VPN 게이트웨이에서 패킷을 삭제할 수 있습니다.

가상 네트워크 게이트웨이 - HighCPUVNetGateway(지속적으로 높은 CPU 사용을 처리하기 위해 VNet(가상 네트워크) 게이트웨이 SKU의 크기 증가 고려)에 대해 자세히 알아보세요.

높은 P2S 사용을 처리하기 위해 가상 네트워크 게이트웨이 SKU의 크기 증가 고려

각 게이트웨이 SKU는 지정된 수의 동시 P2S 연결만 지원할 수 있습니다. 연결 수가 게이트웨이 제한에 근접하여 더 많은 연결 시도가 실패할 수 있습니다.

가상 네트워크 게이트웨이 - HighP2SConnectionsVNetGateway(높은 P2S 사용을 해결하기 위해 VNet 게이트웨이 SKU 크기를 늘리는 것이 좋습니다.)에 대해 자세히 알아보세요.

트래픽을 지원하기에 충분한 인스턴스가 Application Gateway에 있는지 확인

Application Gateway가 최근 높은 사용률로 실행되었으며 부하가 많으면 트래픽 손실 또는 대기 시간 증가가 발생할 수 있습니다. 이에 따라 Application Gateway의 크기를 조정하고 버퍼를 추가하여 트래픽 급증에 대비하고 QoS에 미칠 수 있는 영향을 최소화하는 것이 중요합니다. Application Gateway v1 SKU(Standard/WAF)는 수동 크기 조정을 지원하며, v2 SKU(Standard_v2/WAF_v2)는 수동 및 자동 크기 조정을 지원합니다. 수동 크기 조정을 사용하는 경우 인스턴스 수를 늘립니다. 자동 크기 조정이 사용하도록 설정되면 트래픽 증가에 따라 Application Gateway가 스케일 아웃할 수 있도록 최대 인스턴스 수가 더 높은 값으로 설정되어 있는지 확인합니다.

애플리케이션 게이트웨이 - HotAppGateway(트래픽을 지원하기에 충분한 인스턴스가 Application Gateway에 있는지 확인)에 대해 자세히 알아보세요.

Azure용 SAP

Mellanox 드라이버에서 소프트 잠금을 방지하려면 SAP 워크로드의 App VM OS에서 can_queue 값을 줄입니다.

Mellanox 드라이버의 간헐적인 소프트 잠금을 방지하려면 OS에서 can_queue 값을 줄입니다. 값은 직접 설정할 수 없습니다. 동일한 효과를 얻으려면 다음 커널 부팅 라인 옵션을 추가합니다. 'hv_storvsc.storvsc_ringbuffer_size=131072 hv_storvsc.storvsc_vcpus_per_sub_channel=1024'

앱 서버 인스턴스 - AppSoftLockup(Mellanox 드라이버의 소프트 잠금을 방지하려면 SAP 워크로드의 앱 VM OS에서 can_queue 값 감소)에 대해 자세히 알아보세요.

Mellanox 드라이버에서 소프트 잠금을 방지하려면 SAP 워크로드의 ASCS VM OS에서 can_queue 값을 줄입니다.

중앙 서버 인스턴스 - AscsoftLockup(Mellanox 드라이버의 소프트 잠금을 방지하려면 SAP 워크로드의 ASCS VM OS에서 can_queue 값 감소)에 대해 자세히 알아보세요.

Mellanox 드라이버에서 소프트 잠금을 방지하려면 SAP 워크로드의 DB VM OS에서 can_queue 값을 줄입니다.

데이터베이스 인스턴스 - DBSoftLockup(Mellanox 드라이버의 소프트 잠금을 방지하려면 SAP 워크로드의 DB VM OS에서 can_queue 값 감소)에 대해 자세히 알아보세요.

ANF를 사용하는 HANA DB의 파일 시스템 성능 개선을 위해 tcp_wmem OS 매개 변수 최적화

매개 변수 net.ipv4.tcp_wmem은 TCP 소켓에 사용되는 최소, 기본 및 최대 보내기 버퍼 크기를 지정합니다. SAP Note 302436에 따라 매개 변수를 설정하여 HANA DB가 ANF로 실행되도록 인증하고 파일 시스템 성능을 향상시킵니다. 최댓값은 net.core.wmem_max 매개 변수를 초과할 수 없습니다.

데이터베이스 인스턴스 - WriteBuffersAllocated(ANF를 사용하는 HANA DB의 파일 시스템 성능 향상을 위해 tcp_wmem OS 매개 변수 최적화)에 관해 자세히 알아봅니다.

ANF를 사용하는 HANA DB의 파일 시스템 성능 향상을 위해 tcp_rmem OS 매개 변수 최적화

매개 변수 net.ipv4.tcp_rmem은 TCP 소켓에 사용되는 최소, 기본 및 최대 수신 버퍼 크기를 지정합니다. SAP Note 3024346에 따라 매개 변수를 설정하여 HANA DB가 ANF로 실행되도록 인증하고 파일 시스템 성능을 향상시킵니다. 최댓값은 net.core.rmem_max 매개 변수를 초과할 수 없습니다.

데이터베이스 인스턴스 - OptimizeReadTcp(ANF를 사용하는 HANA DB의 파일 시스템 성능을 향상시키기 위해 tcp_rmem OS 매개 변수 최적화)에 대해 자세히 알아보세요.

ANF를 사용하는 HANA DB의 파일 시스템 성능 향상을 위해 wmem_max OS 매개 변수 최적화

ANF 스토리지 유형의 HANA DB에서는 net.core.wmem_max 매개 변수로 정의된 최대 쓰기 소켓 버퍼를 나가는 네트워크 패킷을 처리할 수 있을 만큼 충분히 크게 설정해야 합니다. net.core.wmem_max 구성은 ANF에서 실행되도록 HANA DB를 인증하고 파일 시스템 성능을 향상시킵니다. SAP Note 3024346을 참조하세요.

데이터베이스 인스턴스 - MaxWriteBuffer(ANF를 사용하는 HANA DB의 파일 시스템 성능 향상을 위해 wmem_max OS 매개 변수 최적화)에 관해 자세히 알아봅니다.

ANF를 사용하는 HANA DB의 파일 시스템 성능 향상을 위해 tcp_rmem OS 매개 변수 최적화

데이터베이스 인스턴스 - OptimizeReadTcp(ANF를 사용하는 HANA DB의 파일 시스템 성능 향상을 위해 tcp_rmem OS 매개 변수 최적화)에 관해 자세히 알아봅니다.

ANF를 사용하는 HANA DB의 파일 시스템 성능 향상을 위해 rmem_max OS 매개 변수 최적화

ANF 스토리지 유형을 사용하는 HANA DB에서는 net.core.rmem_max 매개 변수로 정의된 최대 읽기 소켓 버퍼를 들어오는 네트워크 패킷을 처리할 수 있을 만큼 충분히 크게 설정해야 합니다. net.core.rmem_max 구성은 ANF에서 실행되도록 HANA DB를 인증하고 파일 시스템 성능을 향상시킵니다. SAP Note 3024346을 참조하세요.

데이터베이스 인스턴스 - MaxReadBuffer(ANF를 사용하는 HANA DB의 파일 시스템 성능 향상을 위해 rmem_max OS 매개 변수 최적화)에 관해 자세히 알아봅니다.

ANF를 사용하는 HANA DB의 파일 시스템 성능 개선을 위해 수신자 백로그 큐 크기를 300000으로 설정합니다.

net.core.netdev_max_backlog 매개 변수는 네트워크 인터페이스에서 커널이 처리할 수 있는 것보다 더 빠르게 패킷을 수신하는 경우 사용되는 수신기 백로그 큐의 크기를 지정합니다. SAP 참고: 3024346에 따라 매개 변수를 설정합니다. net.core.netdev_max_backlog 구성은 ANF에서 실행되도록 HANA DB를 인증하고 파일 시스템 성능을 향상시킵니다.

데이터베이스 인스턴스 - BacklogQueueSize(ANF를 사용하는 HANA DB의 파일 시스템 성능 향상을 위해 수신자 백로그 큐 크기를 300000으로 설정)에 관해 자세히 알아봅니다.

ANF를 사용하는 HANA DB에서 파일 시스템 성능을 개선시키려면 TCP 창 크기 조정 OS 매개 변수를 사용하도록 설정합니다.

SAP 참고: 302436에 따라 TCP 창 크기 조정 매개 변수를 사용하도록 설정합니다. TCP 시간 범위 크기 조정 구성은 ANF에서 실행되도록 HANA DB를 인증하고 SAP 워크로드에서 ANF를 사용하는 HANA DB의 파일 시스템 성능을 향상시킵니다.

데이터베이스 인스턴스 - EnableTCPWindowScaling(ANF를 사용하는 HANA DB의 파일 시스템 성능 향상을 위해 TCP 창 스케일링 OS 매개 변수 사용)에 관해 자세히 알아봅니다.

ANF를 사용하는 HANA DB의 파일 시스템 성능 개선을 위해 OS에서 IPv6 프로토콜을 사용하지 않도록 설정합니다.

파일 시스템 성능을 향상시키기 위해 ANF를 사용하는 HANA DB용 Azure의 SAP에 대한 권장 사항에 따라 IPv6을 사용하지 않도록 설정합니다.

데이터베이스 인스턴스 - DisableIPv6Protocol(ANF를 사용하는 HANA DB의 파일 시스템 성능 향상을 위해 OS에서 IPv6 프로토콜 사용 안 함)에 관해 자세히 알아봅니다.

ANF가 있는 HANA DB에서 파일 시스템 성능을 개선시키려면 유휴 상태 이후 느린 시작에 대한 매개 변수를 사용하지 않도록 설정합니다.

net.ipv4.tcp_slow_start_after_idle 매개 변수는 일정 시간 동안 유휴 상태였던 TCP 연결에 대한 TCP 시간 범위 크기를 증분 방식으로 스케일 업할 필요가 없도록 합니다. SAP Note: 302436에 따라 이 매개 변수를 0으로 설정하면 이전에 유휴 상태였던 TCP 연결에 대해 처음부터 최대 속도가 사용됩니다.

데이터베이스 인스턴스 - ParamterSlowStart(ANF를 사용하는 HANA DB의 파일 시스템 성능 향상을 위해 유휴 상태 이후 느린 시작에 대한 매개 변수 사용 안 함)에 관해 자세히 알아봅니다.

ANF를 사용하는 HANA DB의 파일 시스템 성능 향상을 위해 tcp_max_syn_backlog OS 매개 변수 최적화

짧은 시간 프레임에서 많은 연결 요청을 보내는 경우 커널에서 SYN 쿠키를 사용하지 못하도록 방지하고 시스템 로그에서 잠재적인 SYN 플러드 공격에 대한 경고를 방지하기 위해 SYN 백로그의 크기를 합리적으로 높은 값으로 설정해야 합니다. SAP Note 2382421을 참조하세요.

데이터베이스 인스턴스 - TCPMaxSynBacklog(ANF를 사용하는 HANA DB의 파일 시스템 성능 향상을 위해 tcp_max_syn_backlog OS 매개 변수 최적화)에 관해 자세히 알아봅니다.

ANF가 포함된 HANA DB의 파일 시스템 성능 개선을 위해 tcp_sack OS 매개 변수를 사용하도록 설정합니다.

SAP 참고: 302436에 따라 tcp_sack 매개 변수를 사용하도록 설정합니다. tcp_sack 구성은 ANF에서 실행되도록 HANA DB를 인증하고 SAP 워크로드에서 ANF를 사용하는 HANA DB의 파일 시스템 성능을 향상시킵니다.

데이터베이스 인스턴스 - TCPSackParameter(ANF를 사용하는 HANA DB의 파일 시스템 성능 향상을 위해 tcp_sack OS 매개 변수 사용)에 관해 자세히 알아봅니다.

AND를 사용하는 HANA DB의 고가용성 시나리오에서 tcp_timestamps OS 매개 변수를 사용하지 않도록 설정합니다.

SAP 참고: 302436에 따라 tcp_timestamps 매개 변수를 사용하지 않도록 설정합니다. tcp_timestamps 구성은 ANF에서 실행되도록 HANA DB를 인증하고 SAP 워크로드에서 ANF를 사용하는 HANA DB에 대한 고가용성 시나리오의 파일 시스템 성능을 향상시킵니다.

데이터베이스 인스턴스 - DisableTCPTimestamps(ANF를 사용하는 HANA DB의 고가용성 시나리오에서 tcp_timestamps OS 매개 변수 사용 안 함)에 관해 자세히 알아봅니다.

ANF를 사용하는 HANA DB의 파일 시스템 성능을 개선시키려면 tcp_timestamps OS 매개 변수를 사용하도록 설정합니다.

SAP 참고: 302436에 따라 tcp_timestamps 매개 변수를 사용하도록 설정합니다. tcp_timestamps 구성은 ANF에서 실행되도록 HANA DB를 인증하고 SAP 워크로드에서 ANF를 사용하는 HANA DB의 파일 시스템 성능을 향상시킵니다.

데이터베이스 인스턴스 - EnableTCPTimestamps(ANF를 사용하는 HANA DB의 파일 시스템 성능 향상을 위해 tcp_timestamps OS 매개 변수 사용)에 관해 자세히 알아봅니다.

ANF가 있는 HANA DB에서 파일 시스템 성능을 개선시키려면 TCP 수신 버퍼 크기 자동 튜닝을 사용하도록 설정합니다.

net.ipv4.tcp_moderate_rcvbuf 매개 변수를 사용하면 TCP에서 버퍼 자동 튜닝을 수행하여 자동으로 버퍼 크기를 튜닝할 수 있습니다(경로에서 전체 처리량에 필요한 크기와 일치하는 tcp_rmem보다 크지 않음). 파일 시스템 성능을 향상시키기 위해 SAP Note: 302436에 따라 이 매개 변수를 사용하도록 설정합니다.

데이터베이스 인스턴스 - EnableAutoTuning(ANF를 사용하는 HANA DB의 파일 시스템 성능 향상을 위해 TCP 수신 버퍼 크기 자동 튜닝 사용)에 관해 자세히 알아봅니다.

ANF를 사용하는 HANA DB의 파일 시스템 성능 향상을 위해 net.ipv4.ip_local_port_range 최적화

HANA는 내부 통신을 위해 상당한 수의 연결을 사용하므로 이 목적을 위해 가능한 한 많은 클라이언트 포트를 사용하는 것이 좋습니다. 최적의 내부 HANA 통신을 위해 OS 매개 변수 net.ipv4.ip_local_port_range 매개 변수를 SAP note 2382421에 따라 설정합니다.

데이터베이스 인스턴스 - IPV4LocalPortRange(ANF를 사용하는 HANA DB의 파일 시스템 성능 향상을 위해 net.ipv4.ip_local_port_range 최적화)에 관해 자세히 알아봅니다.

ANF를 사용하는 HANA DB의 파일 시스템 성능 향상을 위해 sunrpc.tcp_slot_table_entries 최적화

SAP 워크로드에서 ANF를 사용하는 HANA DB의 파일 시스템 성능을 향상시키기 위해 권장 사항에 따라 sunrpc.tcp_slot_table_entries 매개 변수를 128로 설정합니다.

데이터베이스 인스턴스 - TCPSlotTableEntries(ANF를 사용하는 HANA DB의 파일 시스템 성능 향상을 위해 sunrpc.tcp_slot_table_entries 최적화)에 관해 자세히 알아봅니다.

HANA DB에서 고성능을 보장하기 위해 /hana/data 볼륨에 대한 LVM의 모든 디스크가 동일한 유형이어야 함

/hana/data 볼륨에서 여러 디스크 형식을 선택한 경우 SAP 워크로드에서 HANA DB의 성능이 제한될 수 있습니다. 모든 HANA 데이터 볼륨 디스크가 동일한 유형이고 Azure의 SAP 권장 사항에 따라 구성되어 있는지 확인합니다.

데이터베이스 인스턴스 - HanaDataDiskTypeSame(HANA DB에서 고성능을 보장하기 위해 /hana/data 볼륨에 대한 LVM의 모든 디스크가 동일한 유형이어야 함)에 대해 자세히 알아보세요.

SAP 워크로드에서 HANA DB 성능을 향상시키기 위해 /hana/data에 대한 스트라이프 크기가 256KB여야 함

LVM 또는 mdadm을 사용하여 스트라이프 세트를 여러 Azure 프리미엄 디스크에 작성하는 경우 스트라이프 크기를 정의해야 합니다. 최신 Linux 버전을 사용하는 환경에 따라 HANA DB 성능을 향상시키기 위해 Azure에서 256KB의 스트라이프 크기를 /hana/data 파일 시스템에 사용하도록 권장합니다.

데이터베이스 인스턴스 - HanaDataStripeSize(SAP 워크로드에서 HANA DB 성능을 향상시키기 위해 /hana/data에 대한 스트라이프 크기가 256KB여야 함)에 대해 자세히 알아보세요.

ANF를 사용하는 HANA DB의 파일 시스템 성능 향상을 위해 매개 변수 vm.swappiness 최적화

SAP 워크로드에서 ANF를 사용하는 HANA DB의 파일 시스템 성능을 향상시키기 위해 권장 사항에 따라 vm.swappiness OS 매개 변수를 10으로 설정합니다.

데이터베이스 인스턴스 - VmSwappiness(ANF를 사용하는 HANA DB의 파일 시스템 성능 향상을 위해 매개 변수 vm.swappiness 최적화)에 관해 자세히 알아봅니다.

ANF를 사용하는 HANA DB에서 파일 시스템 성능을 개선시키려면 net.ipv4.conf.all.rp_filter를 사용하지 않도록 설정합니다.

SAP 워크로드에서 ANF를 사용하는 HANA DB의 파일 시스템 성능을 향상시키기 위해 권장 사항에 따라 net.ipv4.conf.all.rp_filter 역방향 경로 필터 Linux OS 매개 변수를 사용하지 않도록 설정합니다.

데이터베이스 인스턴스 - DisableIPV4Conf(ANF를 사용하는 HANA DB의 파일 시스템 성능 향상을 위해 net.ipv4.conf.all.rp_filter 사용 안 함)에 관해 자세히 알아봅니다.

Ultradisk를 사용하는 경우 HANA DB 성능을 향상시키기 위해 /hana/data 볼륨에 대한 IOPS가 7000 이상이어야 함

Ultradisk를 사용할 때 SAP 워크로드에는 /hana/data 볼륨에서 최소 7000의 IOPS를 사용하는 것이 좋습니다. DB의 고성능을 보장하기 위해 이 요구 사항에 따라 /hana/data 볼륨에 대한 디스크 유형을 선택합니다.

데이터베이스 인스턴스 - HanaDataIOPS(Ultradisk를 사용하는 경우 HANA DB 성능을 향상시키기 위해 /hana/data 볼륨에 대한 IOPS가 7000 이상이어야 함)에 대해 자세히 알아보세요.

ANF를 사용하는 HANA DB의 파일 시스템 성능을 개선시키려면 tcp_max_slot_table_entries 매개 변수를 변경합니다.

SAP 워크로드에서 ANF를 사용하는 HANA DB의 파일 전송 성능을 향상시키기 위해 SAP Note: 302436에 따라 tcp_max_slot_table_entries OS 매개 변수를 128로 설정합니다.

데이터베이스 인스턴스 - OptimizeTCPMaxSlotTableEntries(ANF를 사용하는 HANA DB의 파일 시스템 성능 향상을 위해 매개 변수 tcp_max_slot_table_entries 변경)에 관해 자세히 알아봅니다.

HANA DB의 성능 향상을 위해 /hana/data 볼륨의 읽기 성능이 400MB/초 이상인지 확인

Azure의 SAP 워크로드에는 16MB 및 64MB I/O 크기에 대해 /hana/data에 대해 최소 400MB/초의 읽기 작업이 권장됩니다. DB의 고성능을 보장하고 SAP HANA에 대한 최소 스토리지 요구 사항을 충족하기 위해 이 요구 사항에 따라 /hana/data에 대한 디스크 유형을 선택합니다.

데이터베이스 인스턴스 - HanaDataVolumePerformance(HANA DB의 성능 향상을 위해 /hana/data 볼륨의 읽기 성능이 400MB/초 이상인지 확인)에 관해 자세히 알아봅니다.

HANA DB 성능을 향상시키기 위해 /hana/log 볼륨의 읽기/쓰기 성능이 250MB/초 이상이어야 함

Azure의 SAP 워크로드에는 1MB I/O 크기에 대해 /hana/log에 대해 최소 250MB/초의 읽기/쓰기 작업이 권장됩니다. DB의 고성능을 보장하고 SAP HANA에 대한 최소 스토리지 요구 사항을 충족하기 위해 이 요구 사항에 따라 /hana/log 볼륨에 대한 디스크 유형을 선택합니다.

데이터베이스 인스턴스 - HanaLogReadWriteVolume(HANA DB 성능을 향상시키기 위해 /hana/log 볼륨의 읽기/쓰기 성능이 250MB/초 이상이어야 함)에 대해 자세히 알아보세요.

Ultradisk를 사용하는 경우 HANA DB 성능을 향상시키기 위해 /hana/log 볼륨에 대한 IOPS가 2000 이상이어야 함

Ultradisk를 사용할 때 SAP 워크로드에는 /hana/log 볼륨에서 최소 2000의 IOPS를 사용하는 것이 좋습니다. DB의 고성능을 보장하기 위해 이 요구 사항에 따라 /hana/log 볼륨에 대한 디스크 유형을 선택합니다.

데이터베이스 인스턴스 - HanaLogIOPS(Ultradisk를 사용하는 경우 HANA DB 성능을 향상시키기 위해 /hana/log 볼륨에 대한 IOPS가 2000 이상이어야 함)에 대해 자세히 알아보세요.

HANA DB의 고성능을 보장하기 위해 /hana/log 볼륨에 대한 LVM의 모든 디스크가 동일한 유형이어야 함

/hana/log 볼륨에서 여러 디스크 형식을 선택한 경우 SAP 워크로드에서 HANA DB의 성능이 제한될 수 있습니다. 모든 HANA 데이터 볼륨 디스크가 동일한 유형이고 Azure의 SAP 권장 사항에 따라 구성되어 있는지 확인합니다.

데이터베이스 인스턴스 - HanaDiskLogVolumeSameType(HANA DB의 고성능을 보장하기 위해 /hana/log 볼륨에 대한 LVM의 모든 디스크가 동일한 유형이어야 함)에 대해 자세히 알아보세요.

HANA DB의 쓰기 대기 시간 개선을 위해 프리미엄 디스크를 사용하여 /hana/log 볼륨에서 쓰기 가속기를 사용하도록 설정합니다.

Azure 쓰기 가속기는 Azure M-시리즈 VM을 위한 기능입니다. Azure Premium Storage에 대한 쓰기의 I/O 대기 시간을 개선합니다. SAP HANA의 경우 쓰기 가속기는 /hana/log 볼륨에 대해서만 사용됩니다.

데이터베이스 인스턴스 - WriteAcceleratorEnabled(HANA DB의 쓰기 대기 시간 향상을 위해 프리미엄 디스크를 사용하여 /hana/log 볼륨에서 쓰기 가속기 사용)에 관해 자세히 알아봅니다.

SAP 워크로드에서 HANA DB 성능을 향상시키기 위해 /hana/log에 대한 스트라이프 크기가 64KB여야 함

LVM 또는 mdadm을 사용하여 스트라이프 세트를 여러 Azure 프리미엄 디스크에 작성하는 경우 스트라이프 크기를 정의해야 합니다. 더 큰 I/O 크기를 사용하여 충분한 처리량을 가져오려면 HANA DB 성능을 향상시키기 위해 Azure에서 64KB의 스트라이프 크기를 /hana/log 파일 시스템에 사용하도록 권장합니다.

데이터베이스 인스턴스 - HanaLogStripeSize(SAP 워크로드에서 HANA DB 성능을 향상시키기 위해 /hana/log에 대한 스트라이프 크기가 64KB여야 함)에 대해 자세히 알아보세요.

보안

증명 API 버전 업데이트

이 구독에 포함된 리소스에 대한 오래된 증명 API의 API 호출이 식별되었습니다. 최신 증명 API 버전으로 전환하는 것이 좋습니다. 최신 API 버전을 사용하도록 기존 코드를 업데이트해야 합니다. 최신 API 버전을 사용하면 최신 기능과 성능 향상을 얻을 수 있습니다.

증명 공급자 - UpgradeAttestationAPI(증명 API 버전 업데이트)에 대해 자세히 알아보세요.

Key Vault SDK 버전 업데이트

새 Key Vault 클라이언트 라이브러리는 키, 비밀 및 인증서 SDK로 분할되며, 모든 언어 및 환경에서 Key Vault에 원활한 인증을 제공하기 위해 권장되는 Azure ID 라이브러리와 통합됩니다. 또한 고객이 보고하고 QA 프로세스를 통해 사전에 식별된 문제에 대한 몇 가지 성능 수정 사항이 포함되어 있습니다. Key Vault가 이전 Key Vault SDK를 사용할 수 있는 Azure Storage, 디스크 또는 기타 Azure 서비스와 통합되고 현재 모든 사용자 지정 애플리케이션에서 .NET SDK 4.0 이상을 사용하는 경우 권장 사항을 해제합니다.

Key Vault - UpgradeKeyVaultSDK(Key Vault SDK 버전 업데이트)에 대해 자세히 알아보세요.

Key Vault SDK 버전 업데이트

새 Key Vault 클라이언트 라이브러리는 키, 비밀 및 인증서 SDK로 분할되며, 모든 언어 및 환경에서 Key Vault에 원활한 인증을 제공하기 위해 권장되는 Azure ID 라이브러리와 통합됩니다. 또한 고객이 보고하고 QA 프로세스를 통해 사전에 식별된 문제에 대한 몇 가지 성능 수정 사항이 포함되어 있습니다.

Important

액세스 권한이 있는 사용자 지정 애플리케이션에 대한 권장 사항만 수정할 수 있습니다. 새 SDK 버전으로 업데이트 중인 Storage, 디스크 암호화와 같은 다른 Azure 서비스와의 통합으로 인해 권장 사항이 표시될 수 있습니다. 모든 애플리케이션에서 .NET 4.0을 사용하는 경우 권장 사항을 해제하세요.

관리형 HSM 서비스 - UpgradeKeyVaultMHSMSDK(Key Vault SDK 버전 업데이트)에 대해 자세히 알아보세요.

스토리지

256MB 미만 Blob에는 "Put Blob" 사용

256MB 이하 블록 Blob을 작성할 때(2016-05-31 이전 버전의 REST를 사용하는 요청은 64MB) "Put Blob"을 사용하여 쓰기 작업 한 번으로 전체를 업로드할 수 있습니다. 집계된 메트릭에 따라, 스토리지 계정의 쓰기 작업을 최적화할 수 있습니다.

Storage 계정 - StorageCallPutBlob(256MB 미만 Blob에는 ""Put Blob"" 사용)에 대해 자세히 알아보세요.

IOPS(초당 I/O 작업) 또는 파일 공유에 대한 처리량 제한에 도달하면 프리미엄 파일 공유에 대한 요청이 제한됩니다. 요청이 제한되지 않도록 방지하려면 프리미엄 파일 공유의 크기를 늘립니다.

Storage 계정 - AzureStorageAdvisorAvoidThrottlingPremiumFiles(요청 제한을 방지하기 위해 프리미엄 파일 공유의 프로비전된 크기 증가)에 대해 자세히 알아보세요.

테이블 열에 대한 통계 만들기

테이블 통계가 없는 것을 확인했으며 이로 인해 쿼리 성능이 저하될 수 있습니다. 쿼리 최적화 프로그램은 통계를 사용하여 쿼리 결과의 카디널리티 또는 행 수를 예상하며, 이를 통해 쿼리 최적화 프로그램이 고품질 쿼리 계획을 만들 수 있습니다.

SQL 데이터 웨어하우스 - CreateTableStatisticsSqlDW(테이블 열에 대한 통계 만들기)에 대해 자세히 알아보세요.

데이터 기울이기를 제거하여 쿼리 성능 향상

배포 데이터 기울이기가 15%보다 큰 것으로 검색되었습니다. 이로 인해 비용이 많이 드는 성능 병목 상태가 발생할 수 있습니다.

SQL 데이터 웨어하우스 - DataSkewSqlDW(데이터 기울이기를 제거하여 쿼리 성능 향상)에 대해 자세히 알아보세요.

테이블 열에 대한 통계 업데이트

쿼리 성능에 영향을 줄 수 있는 최신 테이블 통계가 없는 것이 감지되었습니다. 쿼리 최적화 프로그램은 최신 통계를 사용하여 쿼리 결과의 카디널리티 또는 행 수를 예측합니다. 이를 통해 쿼리 최적화 프로그램에서 고품질 쿼리 계획을 만들 수 있습니다.

SQL 데이터 웨어하우스 - UpdateTableStatisticsSqlDW(테이블 열에 대한 통계 업데이트)에 대해 자세히 알아보세요.

SQL Data Warehouse를 사용하여 캐시 사용률을 최적화하도록 확장

캐시 사용 비율은 높고 적중 비율이 낮은 것이 감지되었습니다. 이는 워크로드 성능에 영향을 줄 수 있는 높은 캐시 제거 비율을 나타냅니다.

SQL 데이터 웨어하우스 - SqlDwIncreaseCacheCapacity(SQL Data Warehouse를 사용하여 캐시 사용률을 최적화하도록 확장)에 대해 자세히 알아보세요.

SQL Data Warehouse를 사용하여 tempdb 경합을 줄이려면 리소스 클래스를 확장하거나 업데이트합니다.

워크로드 성능에 영향을 줄 수 있는 tempdb 사용률이 높은 것이 감지되었습니다.

SQL 데이터 웨어하우스 - SqlDwReduceTempdbContention(SQL Data Warehouse를 사용하여 tempdb 경합을 줄이려면 리소스 클래스를 확장하거나 업데이트합니다.)에 대해 자세히 알아보세요.

SQL Data Warehouse를 사용하여 테이블을 복제된 테이블로 변환

복제된 테이블 사용의 이점을 활용할 수 있음이 감지되었습니다. 복제된 테이블은 비용이 많이 드는 데이터 이동 작업을 방지하고 워크로드 성능을 크게 향상시킵니다.

SQL 데이터 웨어하우스 - SqlDwReplicateTable(SQL Data Warehouse를 사용하여 테이블을 복제된 테이블로 변환)에 대해 자세히 알아보세요.

스토리지 계정에서 준비된 파일을 분할하여 로드 성능 향상

스토리지 계정에서 준비된 압축 파일을 분할하여 로드 처리량을 늘릴 수 있음을 발견했습니다. 좋은 방법은 압축된 파일을 60개 이상으로 분할하여 로드를 최대한 병렬 처리하는 것입니다.

SQL 데이터 웨어하우스 - FileSplittingGuidance(스토리지 계정에서 준비된 파일을 분할하여 로드 성능 향상)에 대해 자세히 알아보세요.

데이터베이스에 로드할 때 일괄 처리 크기를 늘려 로드 성능 및 처리량을 늘릴 수 있음을 발견했습니다. COPY 문을 사용하는 것이 좋습니다. COPY 문을 사용할 수 없는 경우 SQLBulkCopy API 또는 BCP와 같은 로드 유틸리티를 사용하면 일괄 처리 크기를 늘리는 것이 좋습니다. 경험적으로 일괄 처리 크기는 10만~100만 개 행이 적합합니다.

SQL 데이터 웨어하우스 - LoadBatchSizeGuidance(로드 처리량, 데이터 압축 및 쿼리 성능을 최대화하기 위해 로드할 때 일괄 처리 크기를 늘립니다.)에 대해 자세히 알아보세요.

SQL 풀과 다른 지역에서 로드하고 있음이 감지되었습니다. 데이터를 로드할 때 대기 시간을 최소화하려면 SQL 풀과 동일한 지역에 있는 스토리지 계정에서 로드하는 것이 좋습니다.

데이터 웨어하우스 SQL - ColocateStorageAccount(로드할 때 대기 시간을 최소화하기 위해 스토리지 계정을 동일한 지역 내에 공동 배치)에 대해 자세히 알아보세요.

안정성 및 성능 향상을 위해 Storage 클라이언트 라이브러리를 최신 버전으로 업그레이드

최신 버전의 Storage 클라이언트 라이브러리/SDK에는 고객이 보고하고 QA 프로세스를 통해 사전에 식별된 문제에 대한 수정 사항이 포함되어 있습니다. 또한 최신 버전은 Azure Storage를 사용하여 전반적인 환경을 개선할 수 있는 새로운 기능 외에도 안정성 및 성능 최적화를 제공합니다.

Storage 계정 - UpdateStorageSDK(안정성 및 성능을 향상시키기 위해 스토리지 클라이언트 라이브러리를 최신 버전으로 업그레이드)에 대해 자세히 알아보세요.

안정성 및 성능 향상을 위해 Storage 클라이언트 라이브러리를 최신 버전으로 업그레이드

Storage 계정 - UpdateStorageDataMovementSDK(안정성 및 성능 향상을 위해 Storage 클라이언트 라이브러리를 최신 버전으로 업그레이드)에 대해 자세히 알아보세요.

일관되고 향상된 성능을 위해 표준 SSD 디스크로 업그레이드

표준 HDD 관리 디스크에서 IaaS 가상 머신 워크로드를 실행하므로 이제 표준 SSD 디스크 옵션을 모든 Azure VM 유형에 사용할 수 있습니다. 표준 SSD 디스크는 일관된 성능이 필요한 엔터프라이즈 워크로드에 최적화된 비용 효율적 스토리지 옵션입니다. 대기 시간, 안정성 및 가용성을 개선하려면 지금 디스크 구성을 업그레이드하세요. 업그레이드하려면 VM을 다시 부팅해야 하며 3~5분이 걸립니다.

Storage 계정 - StandardSSDForNonPremVM(일관되고 향상된 성능을 위해 표준 SSD 디스크로 업그레이드)에 대해 자세히 알아보세요.

프리미엄 성능 블록 Blob Storage 사용

하나 이상의 스토리지 계정에 저장된 블록 Blob 데이터의 GB당 트랜잭션 비율이 높습니다. 빠른 스토리지 응답 시간 및/또는 높은 트랜잭션 비율이 필요한 워크로드에 표준 성능 스토리지 대신 프리미엄 성능 블록 Blob Storage를 사용하여 잠재적으로 스토리지 비용을 절감합니다.

Storage 계정 - PremiumBlobStorageAccount(프리미엄 성능 블록 Blob Storage 사용)에 대해 자세히 알아보세요.

성능을 위해 표준 HDD에서 프리미엄 SSD로 비관리 디스크 변환

비관리 HDD 디스크가 성능 목표에 근접하고 있습니다. Azure 프리미엄 SSD는 IO 집약적 워크로드가 있는 가상 머신에 대기 시간이 짧은 고성능 디스크를 지원합니다. 표준 HDD 디스크를 프리미엄 SSD 디스크로 업그레이드하여 디스크 성능을 향상시킵니다. 업그레이드하려면 VM을 다시 부팅해야 하며 3~5분이 걸립니다.

디스크 - UMDHDDtoPremiumForPerformance(성능을 위해 표준 HDD에서 프리미엄 SSD로 비관리 디스크 변환)에 대해 자세히 알아보세요.

서버 그룹에 데이터를 배포하여 노드 간에 워크로드 분산

데이터가 이 서버 그룹에 배포되지 않지만 코디네이터에 남아 있는 것으로 보입니다. 전체 하이퍼스케일(Citus) 이점을 얻기 위해 데이터를 서버 그룹의 작업자 노드에 배포합니다.

하이퍼스케일(Citus) 서버 그룹 - OrcasPostgreSqlCitusDistributeData(서버 그룹에 데이터를 배포하여 노드 간에 워크로드 분산)에 대해 자세히 알아보세요.

하이퍼스케일(Citus) 서버 그룹의 데이터를 리밸런싱하여 작업자 노드 간에 워크로드를 보다 균등하게 분산

이 하이퍼스케일(Citus) 서버 그룹의 작업자 노드 간에 데이터가 잘 밸런싱되지 않은 것 같습니다. 하이퍼스케일(Citus) 서버 그룹의 각 작업자 노드를 사용하기 위해 이 서버 그룹의 데이터를 효과적으로 리밸런싱합니다.

하이퍼스케일(Citus) 서버 그룹 - OrcasPostgreSqlCitusRebalanceData(하이퍼스케일(Citus) 서버 그룹의 데이터를 리밸런싱하여 작업자 노드 간에 워크로드를 보다 균등하게 분산)에 대해 자세히 알아보세요.

가상 데스크톱 인프라

VM을 사용자 위치에 더 가깝게 배포하여 사용자 환경 및 연결 향상

VM이 사용자가 Azure Virtual Desktop에 연결하는 지역과 다르거나 멀리 있는 지역에 있는 것이 확인되었습니다. 이로 인해 연결 응답 시간이 길어지고 전체 사용자 환경에 영향을 줄 수 있습니다. 호스트 풀에 대한 VM을 만드는 경우 사용자에게 더 가까운 지역을 사용하려고 합니다. 가까운 근접성을 사용하면 Azure Virtual Desktop 서비스에 대해 계속 만족할 수 있으며 전반적인 환경의 품질이 향상됩니다.

호스트 풀 - RegionProximityHostPools(사용자의 위치에 더 가깝게 VM을 배포하여 사용자 환경 및 연결 개선)에 대해 자세히 알아보세요.

깊이를 우선하여 부하 분산된 호스트 풀의 최대 세션 제한을 변경하여 VM 성능 향상

깊이를 우선한 부하 분산은 최대 세션 제한을 사용하여 단일 세션 호스트에서 동시 세션을 가질 수 있는 최대 사용자 수를 결정합니다. 최대 세션 제한이 너무 높으면 모든 사용자 세션이 동일한 세션 호스트로 지정됩니다. 이로 인해 성능 및 안정성 문제가 발생할 수 있습니다. 따라서 깊이 우선 부하 분산을 사용하도록 호스트 풀을 설정하는 경우 배포 구성 및 VM 용량에 따라 적절한 최대 세션 제한도 설정합니다. 이 문제를 해결하려면 호스트 풀의 속성을 열고 "최대 세션 제한" 설정 옆의 값을 변경합니다.

호스트 풀 - ChangeMaxSessionLimitForDepthFirstHostPool(깊이를 우선하여 부하 분산된 호스트 풀의 최대 세션 제한을 변경하여 VM 성능 향상)에 대해 자세히 알아보세요.

웹

성능 향상을 위해 App Service 계획을 프리미엄 V2로 이동

앱에서 지난 3일 동안 하루에 1000개가 넘는 요청을 처리했습니다. 앱은 프리미엄 V2 App Service 계층에서 사용할 수 있는 더 높은 성능 인프라의 이점을 활용할 수 있습니다. 프리미엄 v2 계층은 더 빠른 프로세서, SSD 스토리지 및 이전 인스턴스와 비교하여 두 배의 메모리 대 코어 비율을 보여 주는 Dv2 시리즈 VM이 특징입니다. 설명서에서 프리미엄 V2로 업그레이드하는 방법에 대해 자세히 알아보세요.

App Service - AppServiceMoveToPremiumV2(성능 향상을 위해 App Service 계획을 프리미엄 V2로 이동)에 대해 자세히 알아보세요.

App Service 리소스에서 아웃바운드 연결 확인

앱에 너무 많은 TCP/IP 소켓 연결이 열려 있습니다. 사용 후 삭제되는 TCP/IP 포트 연결 제한을 초과하면 앱에 예기치 않은 연결 이슈가 발생할 수 있습니다.

App Service - AppServiceOutboundConnections(App Service 리소스에서 아웃바운드 연결 확인)에 대해 자세히 알아보세요.

다음 단계

성능 효율성 - Microsoft Azure Well Architected Framework

다음을 통해 공유

성능 추천 사항

AI + 기계 학습

429 이 리소스에서 제한이 검색됨

Text Analytics 모델 버전 사용 중단

Text Analytics 모델 버전 사용 중단

최신 Cognitive Service Text Analytics API 버전으로 업그레이드

최신 Azure Cognitive Service for Language API 버전으로 업그레이드

최신 Cognitive Service Text Analytics SDK 버전으로 업그레이드

최신 Cognitive Service Language SDK 버전으로 업그레이드

최신 Azure AI 언어 SDK 버전으로 업그레이드

분석

최적의 성능을 위한 적절한 크기의 Data Explorer 리소스.

Data Explorer 테이블에 대한 테이블 캐시 정책 검토

성능 향상을 위해 Data Explorer 테이블 캐시 정책 줄이기

캐시 정책에서 캐시 늘리기

데이터 탐색기 리소스에 최적화된 자동 크기 조정 사용

가장 최근 데이터에서 발생하는 읽기

클러스터 성능을 향상시키려면 HBase 클러스터에서 가속 쓰기 기능을 사용하는 것이 좋습니다.

75%가 넘는 쿼리가 전체 검사 쿼리임

업데이트를 차단하는 지역 수 확인

플러시 스레드를 늘리는 것이 좋습니다.

압축을 더 빠르게 완료하기 위해 압축 스레드를 늘리는 것이 좋습니다.

행이 6천만 개 미만인 CCI(클러스터형 Columnstore 인덱스)가 있는 테이블

SynapseManagementClient SDK 버전 업데이트

컴퓨팅

vSAN 용량 사용률이 위험 임계값을 초과했습니다.

최신 API 버전으로 Automanage 업데이트

사용자의 위치에 더 가깝게 VM을 배포하여 사용자 환경 및 연결을 개선합니다.

관리 디스크를 사용하여 디스크 I/O 제한 방지

성능을 위해 표준 HDD에서 프리미엄 SSD로 Managed Disks 변환

가속화된 네트워킹을 사용하여 네트워크 성능 및 대기 시간 개선

프로덕션 워크로드에 SSD 디스크 사용

일관된 성능 및 향상된 대기 시간을 위해 프로덕션 가상 머신을 프로덕션 디스크와 맞춤

가속화된 네트워킹을 사용하려면 VM을 중지했다가 시작해야 할 수 있음

로그 디스크에 대해 Ultra Disk 낮은 대기 시간을 활용 및 데이터베이스 워크로드 성능 향상

가장 활동적인 가상 머신의 크기를 업그레이드하여 리소스 소진을 방지하고 성능을 개선합니다.

컨테이너

지원되지 않는 Kubernetes 버전이 검색됨

지원되지 않는 Kubernetes 버전이 검색됨

단일 노드 풀이 있는 클러스터

Fleet API를 최신 버전으로 업데이트

데이터베이스

Azure Cosmos DB 쿼리 페이지 크기(MaxItemCount)를 -1로 구성

Azure Cosmos DB 컨테이너에 복합 인덱스 추가

필요한 항목만 인덱싱하도록 Azure Cosmos DB 인덱싱 정책 최적화

최적의 데이터 배포를 위해 계층적 파티션 키 사용

SDK에서 직접 연결을 사용하도록 Azure Cosmos DB 애플리케이션 구성

최적의 리소스 사용률을 위한 크기 조정으로 성능 향상

PerformanceBoostervCore

MariaDB 서버용 스토리지 제한 확장

MariaDB 서버 vCores 수 늘리기

MariaDB 서버를 상위 SKU로 확장

MariaDB 서버를 메모리 최적화 SKU로 이동

감사 로그의 안정성 향상

MySQL 서버용 스토리지 제한 확장

MySQL 서버를 상위 SKU로 확장

MySQL 서버 vCores 수 늘리기

MySQL 서버를 메모리 최적화 SKU로 이동

MySQL 읽기 복제본 서버 추가

MySQL 연결 관리 개선

감사 로그의 안정성 향상

MySQL 임시 테이블 크기 조정을 최적화하여 성능 향상

MySQL 연결 대기 시간 개선

MySQL 유연한 서버의 저장 한도 늘리기

MySQL 유연한 서버를 더 높은 SKU로 확장

MySQL 유연한 서버 vCore를 늘립니다.

MySQL 임시 테이블 크기 조정을 최적화하여 성능을 개선합니다.

MySQL 서버를 메모리 최적화 SKU로 이동

MySQL 읽기 복제본 서버 추가

work_mem을 늘려 정렬 및 해시에서 과도한 디스크 분산 방지

새로운 Ev5 컴퓨팅 하드웨어로 워크로드 성능 30% 향상

하이퍼스케일(Citus) 서버 그룹에 대한 스토리지 제한 증가

PostgreSQL 서버 vCores 수 늘리기

Azure Database에서 PostgreSQL에 대한 log_statement 설정 최적화

Azure Database에서 PostgreSQL에 대한 log_duration 설정 최적화

Azure Database에서 PostgreSQL에 대한 log_min_duration 설정 최적화

Azure Database에서 PostgreSQL에 대한 log_error_verbosity 설정 최적화

PostgreSQL - 유연한 서버 성능을 개선하기 위해 검사점이 너무 자주 발생하는지 식별

비활성 논리적 복제 슬롯을 식별하여 PostgreSQL - 유연한 서버 성능 개선