OTA 솔루션비교 in Yocto

목차

1. 들어가기
2. 비교기준
3. 솔루션 비교
4. 라이센스
5. 마무리

들어가기

Yocto 프로젝트에 OTA를 적용할 일이 생겼다. 관련된 문서를 찾아보다 보니 Yocto wiki 내에 다음 페이지가 있었다.

이 포스팅은 해당 wiki 내용을 정리한 내용이다.

이상적인 업데이트는 아래와 같다.

• 업데이트 과정이 깨지면 안된다.
• 업데이트 실패시에도 디바이스는 사용가능해야 한다. (ex : 복구모드)
• 최소한의 시스템 리소스를 사용해야 한다. (네트워크, 디스크, 램)
• 업데이트 중에 디바이스 downtime이 최소화되어야 한다.
• 모든 프로세스는 secure한 방식으로 진행되어야 한다.

비교기준

해당 wiki에서는 여러 오픈소스 OTA 솔루션들을 비교하기 위한 몇 가지 기준을 제시한다.

Type

1. Block-based update : 파일시스템을 거치지 않고 파티션내의 block을 직접적으로 수정하는 형태의 업데이트이다. 이 방식에서는 모든 디바이스는 동일한 파티션 형태를 가져야하고 그 파티션들의 사이즈 또한 동일해야 한다.
2. File-based update : 파일 및 디렉토리를 수정하는 형태의 업데이트이다. 서로 다른 파티션 사이즈를 가지고 있는 디바이스도 동일 업데이트 데이터를 사용할 수 있다. 그리고 재부팅없이 업데이트를 실시할 수 있다.

Disk layout

부트로더 의존성이나 파티션 개수제약 등에 해당한다. 융통성있는 솔루션의 경우 최소한의 (없으면 더 좋고) 요구사항이 있는 반면에 일반적인 솔루션들은 자체적인 셋업을 요구하기도 한다.

Rootfs

OS file들이 존재하는 파티션 혹은 이미지이다.  Block-based update에서는 readOnly 일 것이고 File-based update에서는 readWrite 일 것이다.

Updates from

업데이트 이미지의 위치를 나타낸다. 서버에 있을수도 있고 로컬일수도 있다.

Updates what

업데이트 대상을 의미한다. Kernel, BootLoader, RootFS, System 등이 될 수 있다.

Code stability

직역하자면 코드의 안정성이다. 오래된 프로젝트인지, 배포실적과 코드가 얼마나 자주 업데이트 되는지 등이 주요 요소이다.

OE/Yocto integration

OE/Yocto에 이미 사용가능한 솔루션인지 누가 유지하고 있는지 등이다.

Resource requirements on server / client

리소스 측면에서 서버와 클라이언트의 요구사항이다.

서버 측면에서는 빌드타임 그리고 용량에 영향을 미치게 된다.

클라이언트 측면에서는 임시 디스크 사이즈, CPU/네트워크 사용률 등이 포함된다.

Failure resilience

업데이트 과정에서 문제가 발생했을 때, 복구가능한지에 대한 부분이다.

Complexity

솔루션 적용이 얼마나 쉽냐의 기준.

Downtime

업데이트를 위해 Downtime이 얼마나 필요하냐는 기준.

Security

업데이트 프로세스 자체의 보안기준.

솔루션 비교

아래는 해당 페이지의 캡쳐이미지 (2019-01-19 현재)

클릭하면 크고 아름답게 볼 수 있다.

분석해보자. 우선 오픈소스 프로젝트를 사용할 때 가장 중요한 것이 '여전히 활발히 개발중인가' 이다. 이에 해당하는 기준은 'Code stability'이다. 그런데 모든 솔루션들이 '활발히' 개발중이고 '안정성'이 있다고 주장하고 있다.

확인해보자.

• RAUC (github : 링크 / home : 링크) : 별 160개, 1300개 커밋, 8개 릴리즈, 36명의 컨트리뷰터, 한달전 커밋
• OSTree (github : 링크 / home : 링크) : 별 290개, 4000개 커밋, 90개 릴리즈, 90명의 컨트리뷰터, 4일전 커밋
• Mender (github : 링크 / home : 링크) : 별 337개, 1000개 커밋, 27개 릴리즈, 18명 컨트리뷰터, 한달전 커밋
• swupd-client (github : 링크 / home : 링크) : 별 46개, 1000개 커밋, 90개 릴리즈, 33명 컨트리뷰터, 3일전 커밋
• swupdate (github : 링크 / home : 링크) : 별 390개, 1000개 커밋, 20개 릴리즈, 50명 컨트리뷰터, 4일전 커밋

확인결과 유의미한 결과를 뽑지 못했다. 개인적으로는 별개수 (즐겨찾기)를 주요한 기준으로 보는데 그 기준으로는 Mender, swupdate, OSTree가 상대적으로 높았다.

사용하기 편한가의 기준으로 보면, swupdate와 mender가 높은 점수를 받을 수 있겠다. 실제로 문서를 봐도 mender의 경우 굉장히 상세하게 잘 정리되어 있는 걸 볼 수 있다.

그외 주요한 차이는 file-based 인지, block-based 인지이다. Downtime이나 Rootfs 기준의 경우 이 차이에 의해서 결정난다고 볼 수 있다. RAUC와 swupdate가 두 방식 모두를 지원하고 있고 swupd-client와 OSTree는 file-based, Mender가 block-based임을 알 수 있다.

라이센스

OTA 솔루션을 적용할 때, 또 하나 중요한 것은 라이센스다. 아래를 확인해보자.

• Mender : Apache-2.0
• OSTree : LGPL-2.0
• RAUC : LGPL-2.1
• swupdate : GPL-2.0
• swupd-client : GPL-2.0

마무리

지금까지 오픈된 정보를 바탕으로 한다면 아래의 결과를 얻을 수 있다.

1. block-based update : Mender
2. file-based update : swupdate

물론 현재시점에서의 개인적인 판단일 뿐이고 실제로는 좀더 상세한 조사를 해봐야 알 수 있을 것 같다.

다음 포스팅에서는 각 솔루션에 대해서 deep하게 살펴보자.