Python을 사용하여 업로드 및 다운로드 성능 튜닝
애플리케이션이 Python용 Azure Storage 클라이언트 라이브러리를 사용하여 데이터를 전송하는 경우 속도, 메모리 사용량, 요청의 성공 또는 실패에도 영향을 줄 수 있는 몇 가지 요인이 있습니다. 데이터 전송 성능과 안정성을 극대화하려면 앱이 실행되는 환경에 따라 클라이언트 라이브러리 전송 옵션을 사전에 구성하는 것이 중요합니다.
이 문서에서는 데이터 전송 옵션을 튜닝하기 위한 몇 가지 고려 사항을 안내합니다. 제대로 조정되면 클라이언트 라이브러리는 여러 요청에 데이터를 효율적으로 분산할 수 있으므로 작업 속도, 메모리 사용량, 네트워크 안정성이 향상될 수 있습니다.
업로드에 대한 성능 튜닝
데이터 전송 옵션을 올바르게 튜닝하는 것은 안정적인 업로드 성능의 핵심입니다. 스토리지 전송은 이러한 인수 값에 따라 여러 하위 전송으로 분할됩니다. 지원되는 최대 전송 크기는 작업 및 서비스 버전에 따라 다르므로 설명서를 확인하여 한도를 결정해야 합니다. Blob 스토리지 전송 크기 제한에 대한 자세한 내용은 Blob 스토리지의 스케일링 대상을 참조하세요.
업로드를 위한 전송 옵션 설정
다음 인수는 앱의 요구 사항에 따라 튜닝할 수 있습니다.
- max_single_put_size: 단일 요청으로 업로드할 Blob의 최대 크기입니다. 기본값은 64MiB입니다.
- max_block_size: 블록 Blob을 청크로 업로드할 때 최대 전송 길이(바이트)입니다. 기본값은 4MiB입니다.
max_concurrency
: 병렬로 사용할 수 있는 최대 하위 전송 수입니다.
참고 항목
클라이언트 라이브러리는 각 데이터 전송 옵션에 대해 기본값을 사용합니다(제공하지 않는 경우). 이러한 기본값은 일반적으로 데이터 센터 환경에서 수행되지만 일반 소비자 환경에는 적합하지 않을 수 있습니다. 데이터 전송이 제대로 튜닝되지 않으면 작업이 지나치게 오래 걸리고 요청 시간 제한도 발생할 수 있습니다. 이러한 값을 테스트하고 애플리케이션 및 환경 요구 사항에 따라 튜닝하는 것이 가장 좋습니다.
max_single_put_size
max_single_put_size
인수는 단일 요청 업로드에 대한 최대 Blob 크기(바이트)입니다. Blob 크기가 max_single_put_size
보다 작거나 같은 경우 Blob은 단일 Blob 배치 요청으로 업로드됩니다. Blob 크기가 max_single_put_size
보다 크거나 Blob 크기를 알 수 없는 경우 Blob은 일련의 블록 배치 호출과 블록 목록 배치를 사용하여 청크로 업로드됩니다.
max_block_size
에 대해 지정하는 값이 max_single_put_size
에 대해 정의하는 값을 제한하지 않는다는 점에 유의해야 합니다. max_single_put_size
인수는 요청이 전체 작업을 한 번에 수행하도록 하위 전송 없이 별도의 크기 제한을 정의합니다. max_single_put_size
가 적어도max_block_size
에 대해 정의한 값만큼 크도록 하려는 경우가 많습니다(더 크지 않은 경우). 데이터 전송 크기에 따라 단일 요청으로 전송이 완료되고 여러 요청의 오버헤드를 방지하므로 이 방법은 더 우수한 성능을 발휘할 수 있습니다.
상황에 가장 적합한 값이 무엇인지 잘 모르는 경우 안전한 옵션은 max_single_put_size
를 max_block_size
에 사용되는 값과 동일한 값으로 설정하는 것입니다.
max_block_size
max_block_size
인수는 블록 Blob을 청크로 업로드할 때 최대 전송 길이(바이트)입니다. 앞에서 설명한 것처럼 이 값은 max_block_size
보다 클 수 있는 max_single_put_size
를 제한하지 않습니다.
데이터를 효율적으로 이동하기 위해 클라이언트 라이브러리가 전송할 때마다 항상 max_block_size
값에 도달할 수 있는 것은 아닙니다. 작업에 따라 전송 크기에 지원되는 최대 값이 다를 수 있습니다. Blob 스토리지 전송 크기 제한에 대한 자세한 내용은 Blob 스토리지의 스케일링 대상의 차트를 참조하세요.
코드 예
다음 코드 예제에서는 BlobClient
개체를 만들 때 데이터 전송 옵션을 지정하는 방법과 해당 클라이언트 개체를 사용하여 데이터를 업로드하는 방법을 보여 줍니다. 이 샘플에 제공된 값은 권장 사항이 아닙니다. 이러한 값을 올바르게 튜닝하려면 앱의 특정 요구 사항을 고려해야 합니다.
def upload_blob_transfer_options(self, account_url: str, container_name: str, blob_name: str):
# Create a BlobClient object with data transfer options for upload
blob_client = BlobClient(
account_url=account_url,
container_name=container_name,
blob_name=blob_name,
credential=DefaultAzureCredential(),
max_block_size=1024*1024*4, # 4 MiB
max_single_put_size=1024*1024*8 # 8 MiB
)
with open(file=os.path.join(r'file_path', blob_name), mode="rb") as data:
blob_client = blob_client.upload_blob(data=data, overwrite=True, max_concurrency=2)
이 예제에서는 메서드 호출 시 max_concurrency
인수를 사용하여 병렬 전송 작업자 수를 2로 설정합니다. 이 구성은 최대 2개의 연결을 동시에 열어 업로드가 병렬로 수행되도록 합니다. 클라이언트 인스턴스화 중에 max_single_put_size
인수를 8MiB로 설정합니다. Blob 크기가 8MiB보다 작은 경우 작업을 완료하려면 단일 요청만 필요합니다. Blob 크기가 8MiB보다 큰 경우 Blob은 max_block_size
인수에 설정된 대로 최대 청크 크기가 4MiB인 청크로 업로드됩니다.
업로드 성능 고려 사항
업로드하는 동안 스토리지 클라이언트 라이브러리는 클라이언트 구성 중에 정의된 구성 옵션에 따라 지정된 업로드 스트림을 여러 하위 업로드로 분할합니다. 각 하위 업로드에는 REST 작업에 대한 자체 전용 호출이 있습니다. BlobClient
개체의 경우 이 작업은 블록 배치입니다. Storage 클라이언트 라이브러리는 전송 옵션에 따라 이러한 REST 작업을 병렬로 관리하여 전체 업로드를 완료합니다.
클라이언트 라이브러리가 다음 섹션에서 버퍼링을 처리하는 방법을 알아볼 수 있습니다.
참고 항목
블록 Blob의 최대 블록 수는 50,000개입니다. 블록 Blob의 최대 크기는 max_block_size
의 50,000배입니다.
업로드 중 버퍼링
Storage REST 계층은 중단한 REST 업로드 작업을 선택하지 않습니다. 개별 전송은 완료되거나 손실됩니다. 스트림 업로드에 대한 복원력을 보장하기 위해 스토리지 클라이언트 라이브러리는 업로드를 시작하기 전에 각 개별 REST 호출에 대한 데이터를 버퍼링합니다. 네트워크 속도 제한 외에도 이 버퍼링 동작은 순서대로 업로드하는 경우에도 더 작은 max_block_size
값을 고려해야 하는 이유입니다. max_block_size
값을 줄이면 각 요청 및 실패한 요청의 각 재시도에서 버퍼링되는 최대 데이터 양이 줄어듭니다. 특정 크기의 데이터를 전송하는 동안 시간 초과가 자주 발생하는 경우 max_block_size
값을 줄이면 버퍼링 시간이 줄어들고 성능이 향상될 수 있습니다.
기본적으로 SDK는 동시 하위 업로드 요청당 max_block_size
바이트 데이터를 버퍼링하지만 다음 조건이 충족되면 메모리 사용이 요청당 4MiB로 제한될 수 있습니다.
max_block_size
인수는min_large_block_upload_threshold
보다 커야 합니다.min_large_block_upload_threshold
인수는 클라이언트 인스턴스화 중에 정의할 수 있으며 메모리 효율적인 알고리즘을 사용하는 데 필요한 최소 청크 크기(바이트)입니다.min_large_block_upload_threshold
인수의 기본값은4*1024*1024 + 1
입니다.- 제공된 스트림은 검색할 수 있어야 합니다. 검색 가능한 스트림은 스트림 내에서 현재 위치 쿼리 및 수정을 지원하는 스트림입니다.
- Blob은 블록 Blob이어야 합니다.
대부분의 경우에 이 전략이 통하지만, 코드에서 버퍼링이 필요한 다른 클라이언트 라이브러리 기능을 사용하는 경우에도 더 많은 버퍼링이 발생할 수 있습니다.
다운로드 성능 튜닝
데이터 전송 옵션을 올바르게 튜닝하는 것은 안정적인 다운로드 성능의 핵심입니다. 스토리지 전송은 이러한 인수 값에 따라 여러 하위 전송으로 분할됩니다.
다운로드를 위한 전송 옵션 설정
다음 인수는 앱의 요구 사항에 따라 튜닝할 수 있습니다.
max_chunk_get_size
: Blob을 다운로드하는 데 사용되는 최대 청크 크기입니다. 기본값은 4MiB입니다.max_concurrency
: 병렬로 사용할 수 있는 최대 하위 전송 수입니다.max_single_get_size
: 단일 호출에서 다운로드할 Blob의 최대 크기입니다. 총 Blob 크기가max_single_get_size
를 초과하면 나머지 Blob 데이터가 청크로 다운로드됩니다. 기본값은 32MiB입니다.
코드 예
def download_blob_transfer_options(self, account_url: str, container_name: str, blob_name: str):
# Create a BlobClient object with data transfer options for download
blob_client = BlobClient(
account_url=account_url,
container_name=container_name,
blob_name=blob_name,
credential=DefaultAzureCredential(),
max_single_get_size=1024*1024*32, # 32 MiB
max_chunk_get_size=1024*1024*4 # 4 MiB
)
with open(file=os.path.join(r'file_path', 'file_name'), mode="wb") as sample_blob:
download_stream = blob_client.download_blob(max_concurrency=2)
sample_blob.write(download_stream.readall())
다운로드 성능 고려 사항
업로드하는 동안 스토리지 클라이언트 라이브러리는 클라이언트 구성 중에 정의된 구성 옵션에 따라 지정된 다운로드 요청을 여러 하위 다운로드로 분할합니다. 각 하위 다운로드에는 REST 작업에 대한 자체 전용 호출이 있습니다. 전송 옵션에 따라 클라이언트 라이브러리는 이러한 REST 작업을 병렬로 관리하여 전체 다운로드를 완료합니다.
다운로드에 대한 max_single_get_size
다운로드하는 동안 스토리지 클라이언트 라이브러리는 다른 작업을 수행하기 전에 max_single_get_size
를 사용하여 단일 다운로드 범위 요청을 수행합니다. 이 초기 다운로드 요청 중에 클라이언트 라이브러리는 총 리소스 크기를 알 수 있습니다. 초기 요청이 모든 콘텐츠를 성공적으로 다운로드하면 작업이 완료됩니다. 그렇지 않으면, 클라이언트 라이브러리는 전체 다운로드가 완료되는 max_chunk_get_size
까지 범위 요청을 계속 수행합니다.
다음 단계
- 이 문서는 Python용 Blob Storage 개발자 가이드의 일부입니다. 앱 빌드에서 개발자 가이드 문서의 전체 목록을 참조하세요.
- Azure Storage 작업 성능에 영향을 줄 수 있는 요인에 대한 자세한 내용은 Blob 스토리지의 대기 시간을 참조하세요.
- Blob 스토리지를 사용하여 앱의 성능을 최적화하기 위한 디자인 고려 사항 목록을 보려면 Blob 스토리지의 성능 및 확장성 검사 목록을 참조하세요.