Yocto의 PREMIRROR와 Shared State Cache (빌드 속도 향상)

Yocto 빌드 속도를 향상시키는 방법 여러가지가 있다. 대표적으로 소스코드의 파일을 다운로드해서 미리 저장해 놓는 PREMIRROR, 그리고 Yocto에서 지원하는 Shared State Cache이다.

GPT 4o에게 요청해서 도식화한 그림

PREMIRROR

Yocto 프로젝트에서 premirror는 빌드 속도를 향상시키기 위한 중요한 기능 중 하나다. premirror는 빌드 중 다운로드되는 소스 코드, 패치 파일, 그리고 기타 필요한 파일들을 저장하는 미러 서버를 설정하는 기능을 말한다. 이를 통해 네트워크 다운로드 시간을 줄이고, 빌드 환경에 필요한 파일들을 신속하게 접근할 수 있다.

 

premirror를 설정하면 Yocto 빌드 시스템이 소스 파일을 다운로드할 때 먼저 지정된 미러 서버를 확인한다. 만약 미러 서버에서 파일을 찾지 못하면, 그때 비로소 원래 소스 URL에서 파일을 다운로드한다. 이렇게 함으로써 빌드 속도가 크게 향상될 수 있으며, 네트워크 문제로 인한 빌드 실패를 줄일 수 있다.

 

요약하자면, Yocto의 premirror는 빌드 시 필요한 파일들을 빠르게 다운로드하기 위해 미러 서버를 우선적으로 참조하는 설정으로, 이를 통해 빌드 시간을 단축시키고 네트워크 의존성을 줄이는 데 도움을 준다.

Shared State Cache

Yocto 프로젝트의 Shared State Cache(sstate-cache)는 빌드 프로세스에서 생성된 중간 결과물과 최종 결과물을 저장하는 캐시 시스템이다. 이 시스템은 빌드 시간을 단축하고 빌드의 일관성을 유지하는 데 중요한 역할을 한다.

 

PREMIRROR와 Shared State Cache 모두 간단한 설정으로 사용할 수 있고, 공용 저장소에 저장해서 Read Only 또는 Read/Write 모두 각각 설정하여 사용할 수 있는 방법을 Yocto에서 제공해준다.

 

DL_DIR, SSTATE_DIR는 빌드 할 때 Read/Write 가능하도록 하는 변수이고, PREMIRROR과 SSTATE_MIRRORS 는 Read Only로 원래 저장된 곳에서 빌드 할 때 가져다가 쓰도록 하는 변수이다. 각각 사용성에 맞게 설정하면 된다.

 

예를 들어 CI에서 설정하여 사용할 수 있는데, PREMIRROR이나 Shared State Cache 업데이트 정책을 다음과 같이 정할 수도 있다.

• Official 빌드: RW로 설정하여 빌드 과정중에 업데이트, 또는 빌드가 성공 후 최종적으로 업데이트한다.
• 개발자 Commit에 대한 빌드: RW로 사용할 수도 있고 경우에 따라서는 Read Only만 설정하여 Official 빌드에서 만들어 놓은 캐시를 사용하기만 한다.

각 프로젝트에 맞게 설정하여 사용하면 된다. 각기 장단점이 있다. 이상적으로는 Shared State Cache는 유니크해야하고 잘 동작해야하지만 가끔 깨지기도 하고 해서 개발자 Commit에 대한 빌드에서는 직접 업데이트를 하지 않는 경우도 많이 있다.

공용 캐시 설정 시 주의할 점

AWS와 같은 클라우드 환경에서 EFS (Elastic File System) 와 같은 저장공간을 활용하여 캐시를 공유하기도 한다. 하지만 여러 곳에서 동시에 접근할 때 Throughput 설정을 제대로 안해주면 오히려 성능 저하와 빌드할 때 캐시 문제로 에러가 발생할 수 있다. 경험상 EFS 기본 설정을 하면 조금만 동시 접속해도 100%가 넘어서 속도가 저하되고 빌드 실패가 나오기도 한다.

 

그렇다고 EFS 설정을 바꾸면 비용이 엄청나게 올라간다. 이 부분을 잘 감안해야하고, 그래서 요즘 S3로 가도록 하고 있고 이미 ccache는 S3에서 잘 동작하고 있다. 자세한 방법은 회사에서 잘 적용하고 난 후 글을 간단히 쓸 예정이다. 여러 방식을 고민했지만 ccache 적용한 방식과 비슷하게 가려고 할 예정이다. ccache 설명에 대해서는 아주 오래전에 https://www.yocto.co.kr/211 글을 남겼고, 회사에서 적용한 후 아직 글을 안썼는데 이번주 말이나 다음주에 적용 후기를 간단히 써볼 예정이다.

정리

Yocto 빌드는 host 도구부터 모든 것을 처음부터 빌드하도록 되어 있고 빌드 시간이 많이 걸린다. 개발자들에게 부담이지만 안정적으로 플랫폼과 제품을 운영할 수 있다. 당연히 이를 유지하는데 따르는 비용도 엄청나게 든다. 그래서 개발자들은 개발시에는 SDK를 이용하기도 하고 플랫폼 위에 단에서는 RPM과 같은 패키지 기반으로 통합하기도 한다. 이에 대한 것도 의존성 등 많은 것을 고려해야한다.

 

그래서 안정적으로 운영하려면 전체 빌드를 해야하고 이 글에서 이야기한 PREMIRROR과 Shared State Cache가 큰 도움을 준다. 그럼에도 불구하고 빌드는 오래걸리고 주기적으로 끊임 없이 최적화를 고민해야한다. 요즘 빌드 최적화 작업을 계속 진행하고 있고 현재까지 많은 방안을 고민하여 적용하고 있다. 결과는 상당히 괜찮고 여름 전에 관련 글을 써서 올릴 예정이다.

 

요즘 GPT 4o와 열심히 아이데이션을 하고 있고 Yocto 빌드 성능 최적화도 그중에 하나이다. 관련 내용을 하나 캡쳐해서 올리고 이 글을 마무리하고자 한다.