다음을 통해 공유

일반 지침 및 모범 사례

  • 아티클

명명 규칙

Azure에서 서비스에 대한 이름 선택은 다음 이유 때문에 중요합니다.

  • 나중에 이름을 변경하기 어렵습니다.
  • 이름이 특정 리소스 유형의 요구 사항을 충족해야 합니다.

일관된 명명 규칙은 서비스를 쉽게 찾을 수 있습니다. 또한 솔루션에서 서비스의 역할을 나타낼 수도 있습니다.

Azure 서비스에 대한 명명 규칙 및 제한 사항과 명명 규칙에 대한 기본 권장 사항 집합을 요약하는 명명 규칙 문서를 참조하세요.

리소스 그룹

Azure에서 모든 리소스는 리소스 관리 그룹에 할당됩니다. 리소스 그룹은 손쉽게 컬렉션으로 사용할 수 있도록 리소스의 논리적 그룹을 제공하므로 리소스를 수명, 소유자 등의 기준으로 관리할 수 있습니다.

자세한 내용은 리소스 그룹 관리를 참조하세요.

Azure Storage 지역

각 스토리지 리소스의 입력 및 출력이 서로 다른 지역에 있는 경우 지역 간 데이터 이동에 대해 요금이 청구됩니다. 자세한 내용은 대역폭 가격 책정 세부 정보를 참조하세요. 동일한 지역에서 Azure 서비스를 페어링하여 아웃바운드 데이터 전송을 방지합니다.

팁

대부분의 사용자에게 가장 가까운 지역을 사용하도록 합니다.

보안

Azure를 사용하여 클라우드 솔루션을 디자인, 배포 및 관리하는 경우 이 보안 모범 사례 모음을 참조하세요. 이러한 모범 사례는 Azure에 대한 Microsoft의 경험과 개발자의 경험에서 비롯된 것입니다.

이 화이트페이퍼의 각 섹션은 다음과 같이 개별 문서로 게시됩니다.

추가적인 보안 모범 사례는 Azure 보안 모범 사례 및 패턴을 참조하세요.

또한 Azure DDoS Protection: 모범 사례 및 참조 아키텍처 문서도 참조하세요.

개인 정보 보호

개인 정보 보호 책임 부담을 줄이려면 사용자 데이터를 저장하는 일부 서비스에서 제공하는 기능을 활용합니다.

Azure Resource Manager

Azure Resource Manager를 활용하여 Azure 구독에서 리소스를 생성, 업데이트 및 삭제합니다. 문제가 발생하는 경우 Azure Resource Manager를 사용하여 Azure 배포 오류 문제 해결 및 리소스 공급자 등록 오류 해결을 참조하세요.

Azure 이벤트 허브 파티션

파티션을 만든 후에는 파티션 수를 변경할 수 없습니다. 프로덕션을 대상으로 하고 많은 사용자로부터 이벤트를 받을 수 있도록 계획하는 경우 부하 테스트 및 데이터 사용량에 의해 지원되는 몇 가지 사전 계산을 수행하여 필요한 파티션 수를 정확하게 파악해야 합니다.

Azure Event Hubs에서 글로벌 규모 원격 분석 플랫폼 디자인 및 크기 조정에 대한 전체 비디오 가이드를 보려면 이 비디오를 시청하세요.

1TU(처리량 단위)는 1MB/초 또는 초당 1,000개 메시지(먼저 도달하는 값)입니다. TU 기준으로 요금이 부과되므로 부하 요구 사항에 따라 TU를 변경하여 비용을 조정할 수 있습니다.

각 파티션은 1MB/초 또는 초당 1,000개 메시지(먼저 도달하는 값)에 의해 한도에 도달합니다. 파티션 수를 결정하려면 다음 원칙을 고려합니다.

  • 파티션이 고가용성을 제공합니다. 이벤트 허브에 메시지를 보낼 때 전송에 성공하려면 여러 개의 파티션을 만들고 EventHubClient.Send를 사용하여 전송해야 합니다.
  • 파티션 수는 이벤트 허브 파이프의 폭과 메시지를 받고 처리할 수 있는 속도를 결정합니다. Azure 이벤트 허브에 16개 파티션이 있는 경우 용량은 16TU가 한도입니다. 파티션을 고속도로 차선에 비유할 수 있습니다.
  • TU는 네임스페이스 수준에서 구성됩니다. 또한 하나의 이벤트 허브 네임스페이스에 여러 개의 Azure 이벤트 허브가 있을 수 있습니다. 각 Azure 이벤트 허브는 파티션 수가 다를 수 있습니다.

파티션 수보다 많은 TU를 이용할 수 없습니다. 파티션이 3개일 경우 3TU를 초과하여 사용할 수 없습니다. 다음과 같은 이유 때문에 TU보다 많은 수의 파티션을 사용하는 것이 일반적입니다.

  • 트래픽이 증가하는 경우 TU 수를 늘릴 수 있지만 파티션 수를 변경하는 것은 불가능합니다.
  • 동시 판독기가 파티션 수보다 많을 수 없습니다. 동시 판독기를 10개 사용하려면 파티션이 10개 필요합니다.

팁

권장 경로는 사용자가 솔루션을 개발하는 동안 1TU부터 시작하여 파티션 수를 모델링하는 것입니다. 모델링이 완료되면 비공개 베타에서 부하 테스트를 수행할 때 TU를 늘려 부하를 조정합니다. 동일한 이벤트 허브 네임스페이스에 여러 개의 Azure 이벤트 허브가 있을 수 있습니다. 따라서 Azure 이벤트 허브 네임스페이스 수준에서 20TU를 사용하고 각각 파티션이 4개 있는 이벤트 허브 10개를 사용하면 전체 Azure 이벤트 허브 네임스페이스에서 20MBPS를 제공할 수 있습니다.

Azure Cosmos DB

Azure Cosmos DB 리소스는 프로비전된 처리량 및 저장소를 기준으로 요금의 청구됩니다. Azure Cosmos DB 처리량은 초당 RU(요청 단위)(RU/s)로 표시됩니다.

예측 가능한 성능을 제공하려면 100RU/s 단위로 처리량을 예약해야 합니다. Azure Cosmos DB 요청 단위 계산기를 사용하여 처리량 요구를 예측할 수 있습니다.

팁

경험상, 최대 RU 수는 최소/안정 상태 처리량의 20배를 넘지 않는 것이 좋습니다.

  • 초기 프로비전된 처리량의 2배까지 즉시 늘릴 수 있습니다. 모든 처리량 값을 비동기적으로 최대 1M까지(지원 티켓을 통할 경우 더 높게) 늘릴 수 있습니다.
  • 초기 프로비전된 처리량의 10배까지 즉시 줄일 수 있습니다(총 범위 20x). 그러나 경우에 따라 이 범위를 초과하여 줄일 수도 있습니다.

자세한 내용은 Azure Cosmos 컨테이너 및 데이터베이스에서 처리량 프로비전을 참조하세요.

Azure Storage 계정 제한

Azure Storage에는 Azure 구독 서비스 제한 페이지에서 설명하는 특정 제한이 적용됩니다.

게임의 요구 사항이 단일 스토리지 계정의 확장성 목표를 초과하는 경우 애플리케이션을 여러 스토리지 계정을 사용하도록 빌드할 수 있습니다. 그런 다음 이러한 스토리지 계정 간에 데이터 개체를 분할할 수 있습니다.

Azure Storage Explorer

Azure Storage Explorer는 Azure Storage 리소스를 매우 쉽게 관리하는 데 사용할 수 있는 도구입니다. Blob, 파일, 큐, 테이블 및 Azure Cosmos DB 엔터티를 업로드하고 다운로드하고 관리합니다. 가상 컴퓨터 디스크를 관리하기 위해 쉽게 액세스할 수 있습니다. Windows, MacOS 및 Linux를 지원합니다.

Azure Stream Analytics 단위

특정 작업에 필요한 SU(스트리밍 단위)를 선택하는 것은 작업 내에 정의된 입력 및 쿼리에 대한 파티션 구성에 따라 달라집니다. 필요한 것보다 많은 SU를 할당하는 것이 모범 사례입니다. Azure Stream Analytics 처리 엔진은 추가 메모리를 할당하는 비용으로 대기 시간 및 처리량을 최적화합니다.

일반적으로 PARTITION BY를 사용하지 않는 쿼리에 대해 6개의 SU로 시작한 다음, 일반적인 데이터량을 전달하고 SU% 사용률 메트릭을 확인한 후 SU 수를 수정하는 시행착오 방법을 사용하여 최적의 개수를 결정하는 것이 모범 사례입니다. Stream Analytics 작업에 사용될 수 있는 최대 스트리밍 단위 수는 작업에 대해 정의된 쿼리의 단계 수와 각 단계에 대한 파티션 수에 따라 결정됩니다. 여기에서 제한에 대한 자세한 내용을 알아볼 수 있습니다.

올바른 SU 수를 선택하는 방법에 대한 자세한 내용은 처리량을 늘리기 위해 Azure Stream Analytics 작업 크기 조정 페이지를 참조하세요.

참고

특정 작업에 필요한 SU 수 선택은 입력에 대한 파티션 구성 및 작업에 정의된 쿼리에 따라 달라집니다. 특정 작업에 대한 SU에서 할당량까지 선택할 수 있습니다. 기본적으로 각 Azure 구독에는 특정 지역의 모든 분석 작업에 최대 200SU가 할당되어 있습니다. 이 할당량을 초과하여 구독에 대한 SU를 늘리려면 Microsoft 지원에 문의해야 합니다. 작업당 SU에 유효한 값은 1, 3, 6 및 6의 배수입니다.

또한 Azure Stream Analytics는 가변 크기 일괄 처리를 사용하여 이벤트를 처리하고 출력에 기록합니다. 일반적으로 Azure Stream Analytics 엔진은 메시지를 한 번에 하나씩 쓰고 효율성을 위해 일괄 처리를 사용합니다. 이벤트 수신 및 전송 비율이 모두 높으면 더 큰 일괄 처리를 사용합니다. 수신 비율이 낮으면 더 작은 일괄 처리를 사용하여 대기 시간을 낮게 유지합니다. 출력 일괄 처리에 대한 Azure Stream Analytics 고려 사항 몇 가지를 설명하는 출력 일괄 처리 크기 페이지를 참조하세요.

Azure Database for MySQL

다시 시도 논리와 연결 풀링은 Azure Database for MySQL를 사용하여 클라우드 네이티브 게임 애플리케이션을 개발할 때 필수 구성 요소입니다. Azure Database for MySQL이 삭제된 연결 및 실패한 트랜잭션을 감지하여 다시 시도하도록 빌드되는 것이 중요합니다. 애플리케이션이 다시 시도되면 애플리케이션의 연결이 새로 만든 인스턴스로 투명하게 리디렉션되고 이는 실패한 인스턴스에 우선합니다. Azure 내부적으로는 게이트웨이를 사용하여 새 인스턴스로 연결을 리디렉션합니다. 중단 시 전체 장애 조치(failover) 프로세스는 일반적으로 수십 초 정도 걸립니다. 리디렉션은 게이트웨이에서 내부적으로 처리되므로 외부 연결 문자열은 클라이언트 애플리케이션에 대해 동일하게 유지됩니다. 대부분의 게임 애플리케이션에는 짧은 대기 시간 요구 사항이 있으므로 Azure Database for MySQL에서 실행되는 게임 애플리케이션에 연결 풀링을 사용하는 것이 좋습니다. 연결 풀링이 없는 경우 세션 끝에서 연결 열기 및 닫기는 추가 대기 시간 오버헤드를 유발할 수 있습니다. 데이터베이스에 액세스할 때 연결을 적절히 사용하는 방법에 대한 자세한 내용은 연결 관리를 참조하세요.

확대 또는 축소와 관련하여, Azure Database for MySQL이 확대 또는 축소되는 경우 지정 된 크기의 새 서버 인스턴스가 만들어집니다. 기존 데이터 저장소는 원래 인스턴스에서 분리되어 새 인스턴스에 연결됩니다. 크기 조정 작업을 수행하는 동안 데이터베이스 연결이 중단됩니다. 클라이언트 애플리케이션 연결이 끊어지고 커밋되지 않은 미처리 트랜잭션이 취소됩니다. 클라이언트 애플리케이션이 연결을 다시 시도하거나 새 연결을 설정하면 게이트웨이는 새로 크기가 조정된 인스턴스로 연결을 디렉션합니다. 자세한 내용은 리소스 크기 조정을 참조하세요.

다음 링크에서는 데이터베이스 서비스의 용량, 스토리지 엔진 지원, 권한 지원, 데이터 조작 문 지원 및 기능 제한에 대해 설명합니다.

사용 가능한 저장소의 크기가 5GB 또는 프로비전된 저장소의 5%를 하회하면 서버가 읽기 전용으로 표시됩니다. 서버 저장소가 임계값에 근접할 경우 사용자에게 알리도록 경고를 설정하여 읽기 전용 상태를 방지하는 것이 좋습니다. 자세한 내용은 경고를 설정하는 방법에 대한 설명서를 참조하세요.

Azure Container Instances

일반적으로 Azure Container Instances에서는 Windows보다 Linux를 사용하는 것이 좋습니다. Windows 컨테이너는 스핀업하고 로드하는 데 시간이 더 오래 걸리는 무거운 배포 이미지인 경우가 많기 때문입니다. 또한 Linux에는 가상 네트워크와 같이 현재 Windows에서 지원되지 않는 Azure Container Instances 추가 기능 집합이 있습니다.