다음을 통해 공유

상위 수준 코어 애플리케이션 디자인 제안

  • 아티클

Important

Azure Sphere(레거시) 설명서입니다. Azure Sphere(레거시)는 2027년 9월 27일에 사용 중지되며 사용자는 이 시간까지 Azure Sphere(통합)로 마이그레이션해야 합니다. TOC 위에 있는 버전 선택기를 사용하여 Azure Sphere(통합) 설명서를 볼 수 있습니다.

견고한 기반에서 상위 수준(HL) 핵심 애플리케이션을 빌드하려면 기본 모범 사례를 사용해야 합니다. 다음은 가장 관련성이 높습니다.

상위 수준(HL) 핵심 애플리케이션은 Azure Sphere OS에서 컨테이너화된 실행됩니다. 고객 솔루션의 코드 및 디자인 검토 중에 HL 코어 애플리케이션과 관련된 몇 가지 일반적인 문제를 발견했습니다. 이 항목에서는 이러한 문제를 해결하기 위한 디자인 개선에 대한 제안에 대해 설명합니다.

일반적인 기본 사항

견고한 기반에서 HL 코어 애플리케이션을 빌드하려면 기본 모범 사례를 사용해야 합니다. 다음은 가장 관련성이 높습니다.

  • 초기화 및 종료: 항상 Azure Sphere OS의 SIGTERM 신호를 처리하고 종료 시 크래시 또는 오류 발생 시 모든 처리기(예: 주변 장치용 처리기)를 적절하게 초기화하고 삭제해야 합니다. 자세한 내용은 초기화 및 종료 및 종료 신호에 대한 GNU 설명서를 참조하세요.
  • 항상 종료 코드 사용: HL 코어 애플리케이션이 종료 또는 충돌 시(예: SIGTERM 처리기 사용) 항상 의미 있는 반환 코드를 제공하는지 확인하는 것은 특히 디바이스의 크래시 덤프 원격 분석에서 디바이스의 동작을 올바르게 진단하는 데 필수적입니다. 자세한 내용은 종료 코드 및 오류 데이터 수집 및 해석을 참조하세요.
  • 오류 사례로 인해 교착 상태가 아닌 애플리케이션 종료 또는 충돌이 항상 발생하는지 확인합니다. 정교한 오류 복구 논리는 버그 또는 동작을 발생시켜 교착 상태 또는 진단하기 어려운 상태를 유발할 수 있으므로 비생산적일 수 있습니다. 잘 디자인된 Azure Sphere 애플리케이션은 잠재적인 교착 상태 상황에 대해 항상 충돌 또는 종료(0이 아닌 종료 코드 포함)를 선호해야 합니다.
    • 오류 원격 분석, 이 문제에 대한 진단 사용
    • Azure Sphere OS가 애플리케이션을 다시 시작하기 때문에 작업 상태로 즉시 복구될 수 있습니다.
  • 오류 처리 및 로깅: 정확한 오류 처리 및 로깅은 품질 애플리케이션 개발의 핵심입니다. 빠른 기능 구현은 코드 계층에 묻혀 있는 상태로 유지된 다음, 애플리케이션이 최대 규모로 발전함에 따라 빌드할 수 있습니다. 모범 사례에 대한 자세한 내용은 오류 처리 및 로깅을 참조하세요.
  • 시스템 타이머를 watchdog로 사용: 가장 중요한 모범 사례 중 하나는 중요한 애플리케이션 상태를 추적하고 교착 상태를 감지하고 그에 따라 작동하는 "watchdog 타이머" 콜백(예: 원격 분석 종료 및 전송)을 구현하는 것입니다. 자세한 내용은 시스템 타이머를 Watchdog로 사용하세요.
  • 베타 릴리스 도구 집합을 대상으로 빌드된 프로덕션 애플리케이션을 배포하지 마세요. 베타 릴리스 도구 집합을 사용하는 것은 베타 하위 집합이 후속 OS 버전에서 변경되지 않도록 보장할 수 없으므로 권장되지 않습니다. 베타 도구 집합은 공식 SDK 릴리스 전에 새로운 기능을 테스트하기 위해 단독으로 릴리스됩니다.

동시성 처리

  • 가능한 경우 EventLoop 사용: 스레드 및 동기화 개체(즉, 뮤텍스, 세마포 등)는 거의 동시 작업을 수행하는 데 사용되지만 포함된 시스템 내에서는 시스템 리소스 사용량 측면에서 비용이 많이 듭니다. 따라서 성능을 향상시키려면 엄격하게 시간이 중요하지 않고 상호 차단에 민감하지 않은 작업에 대해 스레드 대신 epoll을 사용하는 것이 좋습니다. 관련 샘플을 포함하여 EventLoop을 사용하여 이벤트를 모니터링하고 디스패치하는 방법에 대한 자세한 내용은 Applibs eventloop.h를 참조하세요.
  • 동시 작업에 대한 효율성 찾기: 차단 작업 및 시간 제한이 epoll 콜백 내에서 최소로 유지되고, 그렇지 않으면 다른 모든 epoll 콜백이 영향을 받도록 하는 것이 중요합니다.
  • 스레드(pthread)를 사용하는 경우: 호출 차단이 불가피한 경우와 같은 특정 시나리오의 경우 스레드를 사용하는 것이 도움이 될 수 있지만 일반적으로 이러한 시나리오는 수명이 제한되며 특정 작업으로 범위가 지정되어야 합니다. 예를 들어 Azure Sphere OS(Linux 실행)가 HL 코어 애플리케이션에 IRQ를 노출하지 않는 경우(RT 코어 앱에만 사용 가능) epoll 및 pthread 작업의 조합을 사용하면 인터넷에서 데이터를 다운로드하는 동안 다운스트림 직렬 통신을 처리하는 데 최적일 수 있습니다.

Important

Azure Sphere OS는 특히 디바이스 증명을 수행하거나, 업데이트를 확인하거나, 원격 분석을 업로드하는 경우 적시에 작업을 중단할 수 있습니다. 시간이 중요한 제어 작업의 경우 M4 코어로 이동하고 코어 간 사서함을 통해 적절한 프로토콜로 조정하는 것이 좋습니다. 자세한 내용은 코어 간 통신 샘플을 참조 하세요.

이러한 제안 외에도 비동기 이벤트 및 동시성에 대한 Azure Sphere 설명서를 검토합니다.

연결 모니터링

잘 디자인된 상위 수준(HL) 코어 애플리케이션은 적절한 연결 상태 검사 작업을 구현해야 합니다. 이 작업은 Networking_IsNetworkingReady API를 활용하여 인터넷 연결의 상태(예: epoll 타이머 사용)를 정기적으로 확인하는 강력한 상태 컴퓨터를 기반으로 해야 합니다. 경우에 따라 Networking_GetInterfaceConnectionStatus 함수를 사용할 수 있습니다. HL 코어 애플리케이션이 상태를 더 잘 해결하는 데 사용할 수 있는 특정 네트워크 인터페이스와 관련된 연결 상태를 보다 심층적으로 제공하기 때문에 90초마다 더 자주 호출하지 않는 것이 좋습니다.

상태 머신 콜백에는 일반적으로 다음과 같은 특성이 있어야 합니다.

  • 가능한 한 빨리 실행합니다.
  • 특정 애플리케이션 시나리오 및 전반적인 솔루션 요구 사항(예: 일정한 시간, 증분 지연 등)에 따라 폴링 간격을 신중하게 설계해야 합니다.
  • 연결 끊김이 감지되면 Networking_GetInterfaceConnectionStatus 한 번 호출하여 특정 네트워크 인터페이스의 상태를 기록하는 것이 유용할 수 있습니다. 이 상태를 사용하여 문제를 진단하고 UI(예: LED, 디스플레이, 터미널)를 통해 사용자에게 알릴 수 있습니다. 이 방법의 샘플은 Azure Sphere DHCP 샘플의 기본 코드에서 찾을 수 있습니다.
  • 연결이 다시 설정될 때까지 리소스 소비를 최적화하기 위해 네트워크 통신을 수행하거나 연결되는 HL 코어 애플리케이션의 다른 모든 작업을 중지하는 메커니즘(예: 전역 변수를 통해)을 활성화합니다.
  • cURL은 최근 콜백 동작 및 모범 연습을 업데이트했습니다. Azure Sphere는 이전 버전의 cURL 동작이 예상대로 계속 작동하도록 하기 위해 노력해 왔지만 재귀 콜백을 사용하면 예기치 않은 충돌, 연결 중단 및 잠재적인 보안 취약성이 발생할 수 있으므로 curl_multi 사용할 때 보안 및 안정성에 대한 최신 지침을 따르는 것이 좋습니다. TimerCallback이 0ms의 시간 제한으로 발생하는 경우 재귀 콜백을 방지하기 위해 1ms의 시간 제한으로 처리합니다. curl_multi_add_handle 호출한 후 한 번 이상 명시적으로 curl_multi_socket_action 호출해야 합니다.

이전 제안 외에도 전원 관리를 위해 다음 시나리오를 고려해야 합니다.

  • 데이터를 보낸 후 Azure Sphere 칩의 전원을 닫습니다. 자세한 내용은 Azure Sphere 디바이스에 대한 Power Down 상태 관리를 참조 하세요.
  • 몇 가지 문제는 긴 지수 백오프 시간 제한으로 인해 발생할 수 있으므로 총 가동 시간을 추적하고 종료 타이머를 적절한 제한으로 설정하여 외부 중단이나 애플리케이션의 제어를 벗어나는 기타 요인으로 인해 연결이 더 이상 불가능한 조건에서 배터리를 소모하지 않도록 하는 것이 중요합니다.
  • 가동 중단 시 연결 모니터링을 제어할 때 Wi-Fi 트랜시버는 네트워크 인터페이스를 사용하지 않도록 설정wlan0(Networking_SetInterfaceState 참조)하고 다음 번 연결 확인까지 기다리면 약 100mW를 절약할 수 있습니다.

메모리 관리 및 사용량

메모리 제한 플랫폼에서 자주 메모리 할당 및 할당 해제를 수행하는 애플리케이션은 OS의 메모리 관리가 효율성에 어려움을 겪게 하여 과도한 조각화 및 메모리 부족이 발생할 수 있습니다. 특히 Azure Sphere MT3620에서 이로 인해 Azure Sphere OS의 cgroup OOM 킬러 가 시작될 수 있는 메모리 부족 조건이 발생할 수 있습니다.

당연히 애플리케이션은 초기 개념 증명에서 시작하여 개발되는 경우가 많으며, 이는 점진적 릴리스에 필요한 기능으로 더 포괄적이 되며, 결국에는 처음에 포함된 사소한 기능을 무시합니다. 다음은 필드에서 분석된 많은 시나리오에 대해 효과적인 것으로 입증된 제안 및 최적화입니다.

  • 특히 메모리를 많이 사용하는 HL 코어 애플리케이션 내에서 런타임 애플리케이션 RAM 사용량 확인에 설명된 Azure Sphere API를 통해 애플리케이션 메모리 사용량을 추적하는 것이 중요합니다. 일반적으로 이는 epoll-timer watchdog에서 구현되며 애플리케이션은 적절한 방식으로 다시 시작하기 위해 예기치 않은 메모리 사용량에 적절하게 반응합니다. 예를 들어 적절한 종료 코드를 사용하여 종료합니다.

    여러 고객 및 파트너는 Azure Sphere 갤러리에 게시된 힙 추적기 메모리 추적 유틸리티를 사용하는 것이 유용하다는 것을 알게되었습니다. 이 라이브러리는 기존 HL 코어 애플리케이션에 투명하게 연결되고 메모리 할당 및 관련 포인터를 추적하여 대부분의 메모리 누수 및 포인터 오용 사례를 간단하게 검색할 수 있습니다.

Important

이 방법은 설명할 수 없는 디바이스가 응답하지 않거나 필드에서 자주 보고되는 오류를 줄일 수 있습니다. 이러한 오류는 일반적으로 HL 코어 애플리케이션에서 제대로 처리되지 않는 메모리 누수 또는 오버런으로 인해 발생하며 OOM 킬러가 애플리케이션의 프로세스를 종료하도록 합니다. 이렇게 하면 Azure Sphere OS가 원격 분석을 보내지 못하도록 차단하는 연결이 빠짐과 함께 Azure Sphere OS의 진단 로그를 끌어 서만 진단이 감지될 수 있으므로 잠재적인 필드 인시던트가 발생할 수 있습니다.

  • 메모리 제한 플랫폼에서는 가능할 때마다 특히 자주 호출되는 함수 내에서 동적 메모리 할당을 방지하는 것이 좋습니다. 이렇게 하면 힙의 메모리 조각화와 후속 힙 할당 실패 가능성이 크게 줄어듭니다. 또한 임시 작업 버퍼를 반복적으로 할당하는 것에서 스택에 직접 액세스(적절한 크기의 변수의 경우) 또는 전역적으로 할당된 버퍼로 전환하여 오버플로 시 크기가 증가(통해realloc)하는 패러다임 전환을 고려합니다(동적 컨테이너 및 버퍼 참조). 메모리를 오프로드해야 하는 요구 사항이 있는 경우 데이터 캐싱을 위한 간단한 RT 코어 애플리케이션과 함께 각각 256KiB가 있는 M4 코어(Azure Sphere에서 사용 가능한 메모리 참조)에서 사용되지 않는 메모리를 활용하는 것이 좋습니다. 결국 외부 SD 카드 또는 플래시를 사용할 수 있습니다. 샘플은 다음 리포지토리에서 찾을 수 있습니다.

위의 제안을 따르면 HL 코어 애플리케이션이 수명 주기 동안 전체 용량에서 작동하는 데 필요한 메모리를 예측하고 예약하는 동시에 나중에 디자인 최적화를 위해 애플리케이션의 전체 메모리 공간을 더 잘 예측할 수 있습니다. Azure Sphere OS 및 Visual Studio의 기능을 포함하여 HL 코어 애플리케이션에서 메모리 사용량을 최적화하는 방법에 대한 자세한 내용은 다음 문서를 참조하세요.