자동차용 소프트웨어의 컨테이너화(Containerization)

인프라 플랫폼(Infrastructure Platform)으로써 컨테이너와 쿠퍼네티스가 대세인 시대임은 분명합니다. 그렇다면 ADAS, Digital Cockpit, Infotainment 같은 자동화용 소프트웨어도 컨테이너로 실행할 수 있을까요? 이에 대한 답변이 될 만한 기사 요약 및 공유합니다. 🍀 2021년에 Red Hat은 소프트웨어 정의 차량(이하 'SDV')으로의 전환을 촉진하기 위해 자동차 산업과 협력할 계획을 발표했는데요, 2022년 5월 Red Hat과 General Motors가 Edge에서 SDV를 선제적으로 지원하기 위한 협력을 발표하면서 이러한 의도가 구체화되었습니다. 🍀 이 협력의 궁극적인 목표는 안전이 중요한(safety-critical) 유즈케이스와 비안전(non-safety) 유즈케이스를 위해 모든 종류의 차량 내 소프트웨어를 실행하는 기본 운영 체제를 생성하는 것입니다. 🍀 컨테이너는 IT 산업에서 사실상의 표준이 되었으며 SDV의 비전에서 전면 및 중앙에 위치하여 애플리케이션(이하 'App')을 격리할 수 있고 개발자 및 배포에 더 많은 유연성을 제공하며 일반적으로 더 빠른 혁신을 허용합니다. Red Hat은 클라우드에서 컨테이너 작업을 주도하고 있으며 이제 그 전문 지식을 자동차 산업에 적용할 때입니다. 🍀 그러나 "컨테이너"라는 단어는 많은 것을 의미할 수 있으며 그 의미는 종종 사람과 조직에 따라 다릅니다. 이는 "컨테이너는 App 격리를 위한 커널 지원을 의미"와 같은 낮은 수준의 세부 정보에서 "컨테이너는 대규모의 클러스터에서 분산 소프트웨어 실행을 위한 지원을 의미"와 같은 대규모 아이디어에 이르기까지 다양합니다. ❗️이 기사에서는 몇 가지 자동차 산업별 요구 사항과 이러한 경우 컨테이너를 활용하는 방법에 대해 설명합니다. 1️⃣ FuSa(Functional safety) - 자동차 산업에서 소프트웨어의 핵심 차별화 요소 중 하나는 FuSa에 대한 요구 사항입니다. FuSa의 주요 목적은 제품에 불합리한 위험이 없도록 하는 것입니다. FuSa은 "제품이 사용자가 기대하는 대로 작동합니까?"라는 전통적인 하드웨어 및 소프트웨어 질문을 넘어 확장됩니다. (품질) "오작동 동작으로 인해 이 제품이 고장나 사람에게 신체적 상해를 입힐 수 있습니까?" (안전). 이론적으로 가장 안전한 차는 한 번도 운전한 적이 없는 차이지만 이것은 명백히 비현실적입니다. 즉, 자동차 경험을 개발하는 데 중요한 요소는 품질 뿐 아니라 가용성, 신뢰성, 보안 및 FuSa입니다. - 특히 Linux, Red Hat 제품은 널리 사용되고 테스트되므로 일반적으로 품질 수준이 높습니다. 그러나 FuSa은 일반적으로 기존 오픈 소스 개발에서 다루지 않습니다. 시스템이 요구되는 "안전" 수준을 충족한다는 것을 증명하기 위해 개발자는 전체 시스템에서 해결해야 할 모든 위험에 대해 안전 주장을 해야 합니다. 이는 Red Hat이 2021년 초에 시작한 여정입니다. - 시스템이 복잡할수록 시스템에 대한 FuSa 주장을 하기가 더 어려워집니다. 따라서 코드가 적고 공식적인 방법과 같은 더 간단한 구조와 기술을 사용하는 것이 도움이 됩니다. - 시스템의 모든 소프트웨어가 동일한 안전 요구 사항을 가질 필요는 없습니다. 일반적으로 안전 수준이 혼합되어 있습니다. 이를 'mixed criticality'이라고 합니다. 컨테이너는 본질적으로 시스템이 안전 인증 여부에 관계없이 여러 유형의 워크로드 및 App을 실행할 수 있도록 합니다. 이러한 유연성 덕분에 컨테이너 기술은 'mixed criticality'에 이상적인 솔루션입니다. 그러나 컨테이너에서 기능적으로 안전한 코드를 실행하려면 컨테이너 런타임 및 관리 시스템도 기능적으로 안전해야 합니다. - 기능적으로 안전한 코드를 컨테이너에서 실행할 수 있는 시스템을 제공하려면 컨테이너 런타임 및 관리 시스템에 들어가는 항목에 대해 매우 주의해야 합니다. 2️⃣ 분산 시스템(Distributed systems) - 컨테이너 개념은 분산 시스템에서 매우 자주 사용됩니다. 분산 시스템은 느슨하게 결합되고 일반적으로 지리적으로 분산된 여러 시스템이 클러스터로 결합된 시스템입니다. 분산 시스템은 또한 일반적으로 확장 가능합니다. 즉, 시간이 지남에 따라 요구 사항이 변경되면 클러스터에 더 많은 컴퓨터를 추가하여 런타임에 리소스를 확장할 수 있습니다. - 분산 시스템은 네트워크가 불안정하고 동시적이기 때문에 복잡합니다. 예를 들어 개별 컴퓨터가 동의하지 않거나 오류가 발생하거나 네트워크 오류로 인해 클러스터가 별도의 하위 집합으로 분할될 수 있으며 분산 시스템은 이러한 상황을 고려해야 합니다. - 이러한 복잡성은 리소스 초과 할당 및 투표와 같은 복잡한 알고리즘과 "eventual consistency"이라는 개념으로 처리됩니다. eventual consistency은 시스템이 항상 일관된 상태에 있지 않을 수 있지만 항상 이를 향한 진전이 있음을 의미합니다. - 전반적으로 분산 시스템은 결정적이지(not deterministic) 않습니다.(예를 들어, 개별 실행은 서로 다른 순서로 실행되거나 서로 다른 시스템에서 실행될 수 있음을 미리 알지 못한 채 서로 다른 코드 경로가 실행될 수 있음). 이것은 또한 시스템의 복잡성을 증가시키며, 이는 차례로 시스템 전체에 대한 기능 안전 인수를 작성하는 데 어려움을 더합니다. - 많은 유즈케이스에서 분산 시스템 사용의 복잡성은 그러한 시스템에서 얻을 수 있는 엄청난 유연성과 동적 속성 때문에 그만한 가치가 있습니다. 또한 이러한 유즈케이스 중 다수는 해결하기 위해 존재하는 문제의 특성으로 인해 분산된 상태로 유지되어야 합니다. 예를 들어 전 세계에 스트리밍되는 Netflix는 항상 분산됩니다. - 반면에 자동차의 소프트웨어는 진정한 의미에서 배포되지 않습니다. 하드웨어는 고정되어 있어 자동차가 사용되는 동안 변경되지 않으므로 걱정할 실제 확장성도 없습니다. 또한 이전에 테스트되지 않은 성능 저하 모드(untested degraded mode)에서 시스템을 실행하여 장애를 처리하는 일반적인 방법은 일반적으로 안전하지 않습니다. 자동차의 이러한 저하된 상태(degraded mode)는 안전하지 않은 것으로 간주하고 최선의 노력 모드를 계속하는 대신 안전 모드(예: 천천히 정지)로 전환해야 합니다. - 컨테이너 에코시스템의 대부분은 차량 내 유즈케이스에 적합하지 않은 분산 시스템에 초점을 맞추고 있습니다. 사실, 이러한 시스템의 장점에서 파생된 복잡성은 FuSa의 관점에서 차량 내 사용 사례에 영향을 미칩니다. 3️⃣ 컨테이너 요구 사항: 자동차 컨테이너의 실제 요구 사항은 무엇입니까? - 첫째, 우리는 컨테이너가 SDV을 향한 자동차 산업의 진화에서 필수적인 부분이 될 것이라고 믿습니다. 우리는 또한 이러한 컨테이너가 랩톱이나 클라우드와 같은 다른 곳에서 실행되는 컨테이너와 동일해야 한다고 생각합니다. 이는 개발자 경험과 클라우드에서 쉽고 비용 효율적으로 테스트하는 데 모두 중요합니다. - 둘째, 컨테이너는 리소스 사용 측면에서 효율적이어야 합니다. 최신 자동차에는 구형 차량에 비해 강력한 컴퓨터가 있지만 여전히 일부 리소스 제한이 있습니다. - 셋째, 높은 수준의 컨테이너 관리 형태가 필요합니다. 예를 들어 필요한 컨테이너는 자동차가 출발할 때 올바른 순서로 시작되어야 하며 충분한 모니터링을 통해 예상대로 작동해야 합니다. - 넷째, 시스템 전체가 각각 고유한 워크로드 세트가 실행되고 메인 시스템이 이러한 상태 사이에서 전체 자동차를 전환할 수 있을 것이라는 기대가 있습니다. 이러한 모든 상태는 리소스 요구 사항에 맞는지 확인하기 위해 미리 예약하고 검증해야 합니다. - 마지막으로, 전체 컨테이너 및 관리 시스템은 차량에 탑재된 컨테이너에서 기능적으로 안전한 코드를 실행할 수 있음을 입증하는 지원 가능한 안전 주장을 할 수 있을 만큼 충분히 단순해야 합니다. 4️⃣ Red Hat의 생각 - Red Hat은 오랫동안 Podman 프로젝트를 진행해 왔습니다. Podman은 K8s를 기반으로 하는 Red Hat OpenShift의 핵심 부분인 완전한 기능을 갖춘 컨테이너 시스템입니다. Podman은 또한 전 세계의 중요한 시스템에서 수백만 시간의 실행 시간으로 잘 테스트되었습니다. - Red Hat은 Podman이 특히 RHEL 9에서 기본적으로 활성화되는 새롭고 가벼운 컨테이너 런타임인 crun과 결합하여 차량 내 사용을 위한 훌륭한 컨테이너 시스템을 만들 것이라고 믿습니다. - 오케스트레이션과 관련하여 OpenShift는 클라우드 영역에서 매우 강력한 제품이지만 분산 시스템 사용 사례를 대상으로 하기 때문에 차량 내 사용 사례에는 적합하지 않습니다. 그러나 Podman은 RHEL의 일반 서비스 관리자인 systemd와도 잘 통합됩니다. Systemd는 차량 내 컨테이너 관리 측면에서 본 요구 사항에 훨씬 더 적합합니다. 특히 훨씬 더 간단하고 결정적이며 자동차에 필요한 기능을 제공합니다. - K8s는 다른 서비스 및 솔루션 중 개발자/테스트 경험과 같은 클라우드 작업과 관련하여 선택할 수 있는 도구입니다. 차량 내 사용 사례와 자동차 산업에 적합한 사용 가능한 모든 소프트웨어, 작업 흐름, 경험 및 개념을 통합하고 재사용할 수 있다면 도움이 될 것입니다. - Systemd와 함께 사용할 때 K8s스 App 설명을 지원하는 Podman의 최근 작업에서 예를 찾을 수 있습니다. 이는 K8s를 클라우드에서 사용할 수 있고 K8s 자체의 오버헤드와 복잡성 없이 동일한 K8s 설명을 차량에서 사용할 수 있는 이상적인 조합으로 이어집니다. 이것은 자동차와 클라우드라는 두 세계의 장점을 결합하는 첫 번째 단계가 될 것입니다. 원본 기사는 아래와 같습니다. 감사합니다.😃 [Source Link] https://www.redhat.com/en/blog/running-containers-cars