다음을 통해 공유

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

  • 아티클

견고한 기반에서 상위 수준(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 작업의 조합을 사용하면 인터넷에서 데이터를 다운로드하는 동안 다운스트림 직렬 통신을 처리하는 데 최적일 수 있습니다.

중요

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

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

연결 모니터링

잘 디자인된 상위 수준(HL) 코어 애플리케이션은 적절한 연결 상태 검사 작업을 구현해야 하며, 이 작업은 Networking_IsNetworkingReady API를 활용하여 인터넷 연결의 상태 정기적으로 확인하는 강력한 상태 머신(instance, epoll 타이머 사용)을 기반으로 해야 합니다. 경우에 따라 Networking_GetInterfaceConnectionStatus 함수를 사용할 수 있습니다. 특정 네트워크 인터페이스와 관련된 연결 상태에 대한 보다 심층적인 상태 제공하므로 HL-core 애플리케이션이 상태를 더 잘 해결하는 데 사용할 수 있지만 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 코어 애플리케이션에 투명하게 연결되고 메모리 할당 및 관련 포인터를 추적하여 대부분의 메모리 누수 및 포인터 오용 사례를 간단하게 검색할 수 있습니다.

중요

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

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

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