Azure IoT 참조 아키텍처

Blob Storage
Functions
IoT Hub
Logic Apps
Stream Analytics

이 참조 아키텍처에서는 PaaS(platform-as-a-service) 구성 요소를 사용하는 Azure에서 IoT 애플리케이션에 대한 권장 아키텍처를 보여줍니다.

아키텍처의 다이어그램

IoT 애플리케이션은 인사이트 를 생성하는 데이터를 보내는 사물(디바이스)로 설명될 수 있습니다. 이러한 인사이트는 비즈니스 또는 프로세스를 개선하는 작업 을 생성합니다. 온도 데이터를 보내는 엔진(사물)이 예제입니다. 이 데이터를 사용하여 예상대로 엔진이 수행되었는지 여부를 평가합니다(인사이트). 인사이트를 사용하여 적극적으로 엔진에 대한 유지 관리 일정의 우선 순위를 지정합니다(작업).

이 참조 아키텍처는 Azure PaaS(Platform-as-a-service) 구성 요소를 사용합니다. Azure에서 IoT 솔루션을 빌드하는 데 권장되는 또 다른 옵션은 다음과 같습니다.

  • 를 Azure IoT Central. IoT Central은 완전 관리형 SaaS(Software-as-a-service) 솔루션입니다. 이를 통해 기술 선택 항목을 추상화하고 단독으로 솔루션에 집중할 수 있습니다. 이러한 단순성은 PaaS 기반 솔루션보다 덜 사용자 지정 가능하다는 단점이 수반됩니다.

높은 수준에서 원격 분석 데이터, 실행 부하 과다 경로 및 실행 부하 미달 경로를 처리하는 두 가지 방법이 있습니다. 차이점은 대기 시간 및 데이터 액세스에 대한 요구 사항과 관련이 있습니다.

  • 실행 부하 과다 경로 는 데이터가 도착하는 대로 거의 실시간으로 분석합니다. 실행 부하 과다 경로에서 원격 분석은 매우 짧은 대기 시간으로 처리되어야 합니다. 실행 부하 과다 경로는 일반적으로 스트림 처리 엔진을 사용하여 구현됩니다. 출력은 경고를 트리거하거나, 분석 도구를 사용하여 쿼리될 수 있는 구조화된 형식으로 작성될 수 있습니다.
  • 실행 부하 미달 경로 는 긴 간격(매시간 또는 매일)으로 일괄 처리를 수행합니다. 실행 부하 미달 경로는 일반적으로 많은 양의 데이터를 통해 작동하지만 결과는 실행 부하 과다 경로처럼 시기 적절할 필요가 없습니다. 실행 부하 미달 경로에서 원시 원격 분석은 캡처된 다음, 일괄 처리에 전달됩니다.

Architecture

이 아키텍처는 다음과 같은 구성 요소로 구성됩니다. 일부 애플리케이션에는 여기에 나열된 모든 구성 요소가 필요하지 않을 수 있습니다.

IoT 디바이스. 디바이스는 클라우드에서 안전하게 등록할 수 있고 클라우드에 연결하여 데이터를 받고 보낼 수 있습니다. 일부 디바이스는 디바이스 자체 또는 필드 게이트웨이에서 데이터 처리를 수행하는 에지 디바이스 일 수 있습니다. 에지 처리에 Azure IoT Edge를 사용하는 것이 좋습니다.

클라우드 게이트웨이. 클라우드 게이트웨이는 클라우드로 안전하게 연결하고 데이터를 전송하기 위해 디바이스에 클라우드 허브를 제공합니다. 또한 디바이스의 명령 및 컨트롤을 비롯한 디바이스 관리, 기능을 제공합니다. 클라우드 게이트웨이의 경우 IoT Hub를 사용하는 것이 좋습니다. IoT Hub는 디바이스에서 이벤트를 수집하는 호스트된 클라우드 서비스이며 디바이스와 백 엔드 서비스 간에 메시지 broker 역할을 합니다. IoT Hub에서는 보안 연결, 이벤트 수집, 양방향 통신 및 디바이스 관리를 제공합니다.

디바이스 프로비저닝. 일련의 대규모 디바이스를 등록하고 연결하기 위해 IoT Hub DPS(Device Provisioning Service)를 사용하는 것이 좋습니다. DPS를 통해 대규모로 특정 Azure IoT Hub 엔드포인트에 디바이스를 할당하고 등록할 수 있습니다.

스트림 처리. 스트림 처리는 데이터 레코드의 대형 스트림을 분석하고 해당 스트림에 대한 규칙을 평가합니다. 스트림 처리의 경우 Azure Stream Analytics를 사용하는 것이 좋습니다. Stream Analytics는 시간 이동 함수, 스트림 집계, 외부 데이터 원본 조인을 사용하여 대규모의 복잡한 분석을 실행할 수 있습니다. 다른 옵션은 Azure Databricks의 Apache Spark입니다.

기계 학습 을 사용하면 예측 유지 관리와 같은 시나리오를 사용하여 예측 알고리즘을 원격 분석 기록 데이터에 대해 실행할 수 있습니다. 기계 학습의 경우 Azure Machine Learning을 사용하는 것이 좋습니다.

웜 경로 스토리지 는 보고 및 시각화를 위해 디바이스에서 즉시 사용할 수 있어야 하는 데이터를 보유합니다. 웜 경로 스토리지의 경우 Cosmos DB를 사용하는 것이 좋습니다. Cosmos DB는 전역적으로 배포된 다중 모델 데이터베이스입니다.

실행 부하 미달 경로 스토리지 는 장기적 유지되고 일괄 처리에 사용되는 데이터를 포함합니다. 실행 부하 미달 경로 스토리지의 경우 Azure Blob Storage를 사용하는 것이 좋습니다. 데이터는 저렴한 비용으로 무기한 Blob 스토리지에 보관될 수 있고 일괄 처리에 쉽게 액세스할 수 있습니다.

데이터 변환 은 원격 분석 스트림을 조작하고 집계합니다. 이진 데이터를 JSON으로 변환하거나 데이터 요소를 결합하는 등의 프로토콜 변환을 예로 들 수 있습니다. IoT Hub에 도달하기 전에 데이터가 변환되어야 하는 경우 프로토콜 게이트웨이를 사용하는 것이 좋습니다(표시되지 않음). 그렇지 않으면, IoT Hub에 도달한 후에 데이터를 변환할 수 있습니다. 이 경우 IoT Hub, Cosmos DB 및 Blob 스토리지와 기본적으로 통합되는 Azure Functions를 사용하는 것이 좋습니다.

비즈니스 프로세스 통합 은 디바이스 데이터의 인사이트에 따라 작업을 수행합니다. 여기에는 정보 메시지를 저장하거나, 경보를 발생시키거나, 이메일 또는 SMS 메시지를 보내거나, CRM와 통합하는 작업이 포함될 수 있습니다. 비즈니스 프로세스 통합의 경우 Azure Logic Apps를 사용하는 것이 좋습니다.

사용자 관리 는 펌웨어 업그레이드 등 디바이스에서 작업을 수행할 수 있는 사용자 또는 그룹을 제한합니다. 또한 애플리케이션에서 사용자에 대한 기능을 정의합니다. Azure Active Directory를 사용하여 사용자를 인증하고 권한을 부여하는 것이 좋습니다.

IoT용 보안 모니터링 Azure Security Center IoT 워크로드에 대한 엔드투엔드 보안 솔루션을 제공하고 클라우드를 통해 뿐만 아니라 리프 디바이스의 워크로드에서 통합된 가시성 및 제어, 적응형 위협 방지, 지능형 위협 탐지 및 대응을 제공하여 보호를 간소화합니다.

확장성 고려 사항

IoT 애플리케이션은 독립적으로 크기를 조정할 수 있는 불연속 서비스로 빌드되어야 합니다. 다음 확장성 지점을 고려하세요.

IoTHub. IoT Hub의 경우 다음 크기 조정 요소를 고려하세요.

  • IoT Hub에 대한 메시지의 최대 일일 할당량
  • IoT Hub 인스턴스에서 연결된 디바이스의 할당량
  • 수집 처리량 — IoT Hub에서 메시지를 신속하게 수집할 수 있는 정도
  • 처리 처리량 — 들어오는 메시지를 신속하게 처리할 수 있는 정도

각 IoT 허브는 특정 계층에서 특정한 단위 수로 프로비전됩니다. 단위의 계층 및 수는 디바이스에서 허브에 보낼 수 있는 메시지의 최대 일일 할당량을 결정합니다. 자세한 내용은 IoT Hub 할당량 및 제한을 참조하세요. 기존 작업을 중단하지 않고 허브를 강화할 수 있습니다.

를 Stream Analytics. Stream Analytics 파이프라인의 모든 지점에서 병렬인 경우 출력을 쿼리하는 입력 중 Stream Analytics 작업의 규모가 가장 적합합니다. 완전 병렬 작업을 사용하면 Stream Analytics가 여러 컴퓨팅 노드에 작업을 분할할 수 있습니다. 그렇지 않으면, Stream Analytics는 스트림 데이터를 한 곳에 결합해야 합니다. 자세한 내용은 Azure Stream Analytics에서 쿼리 병렬 처리 활용을 참조하세요.

IoT Hub는 디바이스 ID에 따라 디바이스 메시지를 자동으로 분할합니다. 특정 디바이스의 모든 메시지는 항상 동일한 파티션에 도착하지만 단일 파티션에는 여러 디바이스의 메시지가 포함됩니다. 따라서 병렬 처리의 단위는 파티션 ID입니다.

함수. Event Hubs 엔드포인트로부터 읽을 때 이벤트 허브 파티션당 최대 함수 인스턴스가 있습니다. 최대 처리 속도는 하나의 함수 인스턴스가 단일 파티션의 이벤트를 빠르게 처리할 수 있는 정도로 결정됩니다. 함수는 일괄 처리로 메시지를 처리해야 합니다.

를 Cosmos DB. Cosmos DB 컬렉션을 확장하려면 파티션 키를 포함한 컬렉션을 만들고 작성하는 각 문서에 파티션 키를 포함합니다. 자세한 내용은 파티션 키를 선택할 때 모범 사례를 참조하세요.

  • 디바이스당 단일 문서를 저장하고 업데이트하는 경우 디바이스 ID는 적절한 파티션 키입니다. 쓰기는 키에 균일하게 분산되어 있습니다. 각 키 값에 대한 단일 문서가 있기 때문에 각 파티션의 크기가 엄격하게 제한됩니다.
  • 모든 디바이스 메시지에 대한 별도 문서를 저장하는 경우 디바이스 ID를 파티션 키로 사용하면 쉽게 파티션당 10GB 제한을 초과합니다. 이 경우에 메시지 ID가 더 적합한 파티션 키입니다. 일반적으로 인덱싱 및 쿼리의 경우 문서에 디바이스 ID가 여전히 포함될 수 있습니다.

TSI(Azure Time Series Insights)는 SQL과 같은 필터링 및 집계를 비롯한 기능을 제공하여 사용자 정의 함수의 필요성을 완화하는, 시간 계열 데이터에 대한 분석, 스토리지 및 시각화 서비스입니다. Time Series Insights REST 쿼리 API뿐만 아니라 데이터를 시각화하고 쿼리하는 데이터 탐색기를 제공합니다. TSI는 계열 데이터 외에도 대규모 데이터 집합에 대한 집계를 쿼리해야 하는 솔루션에도 적합합니다. 다중 계층 스토리지, 풍부한 API, 모델을 지원하며 Azure IoT 에코시스템, 시각화 탐색기 및 Power BI 통한 확장성과 통합됩니다. TSI는 Time Series 데이터 스토리지 및 분석에 대한 권장 사항입니다.

보안 고려 사항

신뢰할 수 있는 보안 통신

디바이스 간에 보내고 받은 모든 정보는 신뢰할 수 있어야 합니다. 디바이스가 다음 암호화 기능을 지원하지 않으면 로컬 네트워크로 제한되어야 하고 모든 네트워크 간 통신은 필드 게이트웨이를 통해야 합니다.

  • 일반적으로 안전하고, 공개적으로 분석되고, 광범위하게 구현된 대칭 키 암호화 알고리즘을 사용하는 데이터 암호화
  • 일반적으로 안전하고, 공개적으로 분석되고, 광범위하게 구현된 대칭 키 서명 알고리즘을 사용하는 디지털 서명
  • TCP 또는 기타 스트림 기반 통신 경로의 경우 TLS 1.2에 대한 지원 또는 데이터그램 기반 통신 경로의 경우 DTLS 1.2에 대한 지원 X.509 인증서를 처리하는 지원은 선택 사항이며 TLS에 대해 미리 공유한 계산 효율적이고 연결 효율적인 키 모드에 의해 바꿀 수 있습니다. 이것은 AES 및 SHA-2 알고리즘에 대한 지원을 사용하여 구현될 수 있습니다.
  • 업데이트 가능한 키 저장소 및 디바이스별 키 각 디바이스에는 시스템에 대해 식별하는 고유한 키 자료 또는 토큰이 있어야 합니다. 디바이스는 해당 디바이스에서 키를 안전하게 저장해야 합니다(예: 보안 키 저장소 사용). 디바이스는 키 또는 토큰을 정기적으로 업데이트하거나 시스템 위반과 같은 응급 상황에서 업데이트할 수 있어야 합니다.
  • 디바이스의 펌웨어 및 애플리케이션 소프트웨어는 발견된 보안 취약성의 복구를 사용하도록 설정하기 위한 업데이트에 허용되어야 합니다.

그러나 디바이스는 대부분 이러한 요구 사항을 지원하기에는 너무 제한되어 있습니다. 이 경우에 필드 게이트웨이를 사용해야 합니다. 디바이스는 로컬 영역 네트워크를 통해 필드 게이트웨이에 안전하게 연결되고, 게이트웨이를 사용하면 클라우드에 대한 보안 통신을 사용할 수 있습니다.

물리적 변조 방지

디바이스 디자인이 전체 시스템의 보안 무결성 및 신뢰성을 보장할 수 있기 위해 실제 조작 시도로부터 방어하는 기능을 통합하는 것이 좋습니다.

예:

  • TPM(신뢰할 수 있는 플랫폼 모듈) 통합과 같은 암호화 키 자료의 보안 스토리지 및 사용을 제공하는 마이크로 컨트롤러/마이크로프로세서 또는 보조 하드웨어를 선택합니다.
  • 부팅 로더 및 소프트웨어 로드를 보호하고 TPM에 고정합니다.
  • 센서를 사용하여 침입 시도를 검색하고 디바이스의 경고 및 잠재적인 "디지털 자체 소멸"을 사용하여 디바이스 환경을 조작하려고 합니다.

추가 보안 고려 사항은 IoT(사물 인터넷) 보안 아키텍처를 참조하세요.

모니터링 및 로깅

로깅 및 모니터링 시스템을 사용하여 솔루션이 작동하는지 확인하고 문제를 해결합니다. 모니터링 및 로깅 시스템은 다음 운영 질문에 대답하는 데 도움이 됩니다.

  • 디바이스 또는 시스템이 오류 조건 상태인가요?
  • 디바이스 또는 시스템이 올바르게 구성되었나요?
  • 디바이스 또는 시스템이 정확한 데이터를 생성하고 있나요?
  • 시스템이 비즈니스 및 최종 고객의 기대를 충족하고 있나요?

로깅 및 모니터링 도구는 일반적으로 다음 네 가지 구성 요소로 구성됩니다.

  • 시스템 및 기본 문제 해결을 모니터링하는 시스템 성능 및 타임라인 시각화 도구
  • 로그 데이터를 버퍼링하는 버퍼링된 데이터 수집
  • 로그 데이터를 저장하는 지속성 저장소
  • 자세한 문제 해결에서 사용할 로그 데이터를 보는 검색 및 쿼리 기능

모니터링 시스템은 상태, 보안 및 안정성과 IoT 솔루션의 성능에 대한 인사이트를 제공합니다. 이러한 시스템은 보다 자세한 보기를 제공하여 구성 요소 구성 변경 내용을 기록하고, 잠재적인 보안 취약성을 노출하고, 인시던트 관리 프로세스를 향상시키고, 시스템 문제 해결 문제의 소유자를 도울 수 있는 추출된 로깅 데이터를 제공할 수도 있습니다. 포괄적인 모니터링 솔루션에는 특정 하위 시스템에서 정보를 쿼리하거나 여러 하위 시스템에서 집계하는 기능이 포함됩니다.

정상 작업, 규정 준수 및 감사 요구 사항을 정의하여 모니터링 시스템 개발을 시작해야 합니다. 수집된 메트릭에는 다음이 포함될 수 있습니다.

  • 구성 변경 내용을 보고하는 실제 디바이스, 에지 디바이스 및 인프라 구성 요소
  • 관리형 언어에 대한 구성 변경 내용, 보안 감사 로그, 요청 속도, 응답 시간, 오류 비율 및 가비지 수집 통계를 보고하는 애플리케이션
  • 쿼리 및 쓰기 성능, 스키마 변경 내용, 보안 감사 로그, 잠금 또는 교착 상태, 인덱스 성능, CPU, 메모리 및 디스크 사용량을 보고하는 데이터베이스, 지속성 저장소 및 캐시
  • 종속 시스템 상태 및 성능에 영향을 주는 상태 메트릭 및 구성 변경 내용을 보고하는 관리형 서비스(IaaS, PaaS, SaaS 및 FaaS)

모티터링 메트릭의 시각화를 통해 운영자에게 시스템 불안정에 대해 경고하고 인시던트 대응을 용이하게 할 수 있습니다.

원격 분석 추적

원격 분석을 추적하면 운영자가 시스템을 통해 생성에서부터 원격 분석의 기록을 따라갈 수 있습니다. 추적은 디버깅 및 문제 해결에서 중요합니다. Azure IoT Hub 및 IoT Hub 디바이스 SDK를 사용하는 IoT 솔루션의 경우 추적 데이터그램은 클라우드-디바이스 메시지로 시작되고 원격 분석 스트림에 포함될 수 있습니다.

로깅

로깅 시스템은 솔루션을 수행하고, 오류가 발생하고, 해당 오류를 수정하는 데 도움을 줄 수 있는 작업을 이해하기 위해 필수적입니다. 로그를 분석하여 오류 조건을 이해하고 해결하며, 성능 특징을 향상시키고, 제어 규칙 및 규정을 준수하는 데 도움을 줄 수 있습니다.

일반 텍스트 로깅이 선불 개발 비용에 대해 많은 영향을 주지 않지만 머신이 구문 분석/읽기하는 경우 더 어렵습니다. 수집된 정보가 모두 머신에서 구문 분석할 수 있고 사람이 읽을 수 있으므로 구조적 로깅을 사용하는 것이 좋습니다. 구조적 로깅은 로그 정보에 상황 컨텍스트 및 메타데이터를 추가합니다. 구조적 로깅에서 속성은 검색 및 쿼리 기능을 향상시키기 위해 키/값 쌍으로 형식이 지정되거나 고정된 스키마가 있는 주요 요소입니다.

DevOps 고려 사항

IaC(Infrastructure as Code)를 사용합니다. IaC는 선언적 접근 방식을 통해 인프라(네트워크, 가상 머신, 부하 분산기 및 연결 토폴로지)를 관리합니다. 템플릿은 버전 관리되고 릴리스 파이프라인의 일부여야 합니다. 가장 안정적인 배포 프로세스는 자동화되고 idempotent입니다. 한 가지 방법은 IoT 리소스 및 인프라를 프로비전하기 위한 Azure Resource Manager 템플릿을 만드는 것입니다.

인프라 배포를 자동화 하기 위해 Azure DevOps Services, Jenkins 또는 기타 CI/CD 솔루션을 사용할 수 있습니다. Azure 파이프라인Azure DevOps 서비스의 일부이며 자동화된 빌드, 테스트 및 배포를 실행합니다.

다음 단계로 이동 하기 전에 여러 단계를 배포 하 고 각 단계에서 유효성 검사를 실행 하 여 워크 로드를 준비 하는 것이 좋습니다. 이렇게 하면 프로덕션 환경에 대 한 업데이트를 매우 제어 된 방식으로 푸시 하 고 예기치 않은 배포 문제를 최소화할 수 있습니다. 라이브 프로덕션 환경을 업데이트 하기 위한 배포 전략에는 Blue-녹색 배포카나리아 릴리스가 권장 됩니다. 또한 배포에 실패 한 경우에 대 한 좋은 롤백 전략을 고려해 야 합니다. 예를 들어 배포 기록에서 이전에 성공한 배포를 자동으로 다시 배포할 수 있습니다. Azure CLI의--오류-오류 플래그 매개 변수는 좋은 예입니다.

Azure Monitor를 사용 하 여 솔루션을 모니터링 하는 것이 좋습니다. Azure Monitor은 모든 Azure 서비스에 대 한 모니터링 및 로깅의 주요 원본 이며, Azure 리소스에 대 한 진단 정보를 제공 합니다. 예를 들어 IoT hub 내에서 수행 되는 작업을 모니터링할 수 있습니다. Azure 진단 로그에 대 한 서비스, 스키마 및 범주 뿐만 아니라 Azure Monitor 지 원하는 특정 메트릭 및 이벤트가 있습니다.

자세한 내용은 Microsoft Azure Well-Architected Framework의 devops 섹션을 참조 하십시오.

비용 고려 사항

일반적으로 Azure 가격 책정 계산기 를 사용 하 여 비용을 예측 합니다. 기타 고려 사항은 Microsoft Azure Well-Architected Framework의 비용 섹션에 설명 되어 있습니다.

이 참조 아키텍처에서 사용 되는 서비스와 관련 된 비용을 최적화 하는 방법이 있습니다.

Azure IoT Hub

이 아키텍처에서 IoT Hub는 장치에서 이벤트를 수집 하는 클라우드 게이트웨이입니다. IoT Hub 요금은 작업 유형에 따라 달라 집니다. Create, update, insert, delete는 무료입니다. 장치-클라우드 및 클라우드-장치 메시지와 같은 성공적인 작업에는 요금이 부과 됩니다.

성공적으로 전송 된 장치-클라우드 메시지는 IoT Hub 수신 시 4kb 청크로 청구 됩니다. 예를 들어 6KB 메시지는 두 개의 메시지로 요금이 청구 됩니다.

IoT Hub 디바이스 쌍 JSON 문서에서 연결된 각 디바이스에 대한 상태 정보를 유지 관리합니다. 디바이스 쌍 문서에서 읽기 작업은 요금이 청구됩니다.

IoT Hub 기본표준 의 두 가지 계층을 제공합니다.

IoT 아키텍처에서 양방향 통신 기능을 사용하는 경우 표준 계층을 사용하는 것이 좋습니다. 이 계층은 테스트 목적에 가장 적합한 무료 버전도 제공합니다.

디바이스에서 클라우드로의 단방향 통신만 필요한 경우 저렴한 기본 계층을 사용합니다.

자세한 내용은 IoT Hub 가격 책정을 참조하세요.

Azure Stream Analytics

Azure Stream Analytics 스트림 처리 및 규칙 평가에 사용됩니다. Azure Stream Analytics 시간당 SU(스트리밍 단위) 수로 가격이 책정되며, 데이터를 처리하는 데 필요한 컴퓨팅, 메모리 및 처리량이 필요합니다. IoT Edge의 Azure Stream Analytics 작업당 요금이 청구됩니다. 작업 상태, 실행 중, 실패 또는 중지에 관계없이 Stream Analytics 작업이 디바이스에 배포되면 청구가 시작됩니다.

가격 책정에 대한 자세한 내용은 Stream Analytics 가격 책정을 참조하세요.

Azure 기능

Azure Functions IoT Hub 도달한 후 데이터를 변환하는 데 사용됩니다. 비용 관점에서 사용하는 컴퓨팅 리소스에 대해서만 요금을 지불하므로 소비 계획을 사용하는 것이 좋습니다. 이벤트가 함수 실행을 트리거할 때마다 초당 리소스 소비량에 따라 요금이 청구됩니다. 단일 실행 또는 일괄 처리에서 여러 이벤트를 처리하면 비용이 절감됩니다.

Azure Logic Apps

이 아키텍처에서 Logic Apps 비즈니스 프로세스 통합에 사용됩니다.

논리 앱 가격은 종량제 모델에서 작동합니다. 트리거, 작업 및 커넥터 실행은 논리 앱이 실행될 때마다 계량됩니다. 트리거를 포함하여 성공 및 실패한 모든 작업은 실행으로 간주됩니다.

예를 들어 논리 앱은 하루에 1000 메시지를 처리 합니다. 5 개의 작업 워크플로는 $6 보다 저렴 합니다.

자세한 내용은 Logic Apps 가격 책정을 참조 하세요.

데이터 스토리지

콜드 경로 저장소의 경우 Azure Blob Storage 가장 비용 효율적인 옵션입니다.

웜 경로 저장소의 경우 Azure Cosmos DB를 사용 하는 것이 좋습니다. 자세한 내용은 Cosmos DB 가격 책정을 참조 하세요.

다음 단계