빌드 속도 최적화 및 AWS 비용 최적화 작업을 진행중에 있다. MR (Merge Request) / PR (Pull Request) 하나에 10개 이상의 빌드가 동시에 돌아가고 이에 따라 AWS 비용이 엄청나게 증가하고 있다. 또한 경우에 따라 빌드가 안정적이지 않아 다양한 이슈가 생기고 있다.
Yocto Shared State Cache
Yocto 프로젝트의 sstate cache(Shared State Cache)는 빌드 속도를 크게 향상시키기 위해 사용되는 기능이다. 이를 통해 Yocto는 재빌드 시 동일한 작업을 반복하지 않고 이미 완료된 작업을 재사용할 수 있다. 이전 글 (https://www.yocto.co.kr/291) 에서 Shared State Cache에 대해서 조금 더 이야기 했으니 자세한 내용은 위의 링크를 참고하기 바란다.
CI는 Gitlab CI (Gitlab을 코드 관리 도구를 사용하는 경우) 또는 Jenkins를 많이 사용하고 EC2 Instance를 Gitlab Runner나 Jenkins Slave로 사용한다. 이때 Yocto Shared State Cache는 공유를 해야하기 때문에 모든 빌드 머신이 Mount를 하여 사용할 수 있도록 AWS EFS (Elastic File System)를 사용하고 있다. 거의 200대 넘는 EC2가 동시 사용되고 EFS에 접속을 해야하기 때문에 기본 설정을 사용하면 오히려 Bandwidth로 인해 성능이 저하된다. Throughput을 올려서 사용하고 있고 이에 엄청난 비용을 매달 지불하고 있다.
AWS EFS vs S3
이에 EFS 대신 S3를 이용하면 비용문제도 훨씬 줄어들고 네트워크 대역폭도 향상된다는 것을 알아서 UI팀에서 사용중에 있다. 그 팀도 몇백명 규모의 개발자가 작업을 하는데 큰 문제는 없다고 한다. 하지만 최종 Integration 환경은 훨씬 더 규모가 커서 부하를 잘 견딜지 테스트 중에 있다.
Shared State Cache는 작은 단위의 파일들이 많아서 대규모 개발에서 S3가 효과적인지는 테스트를 조금 더 거쳐봐야한다.
테스트 방법
다음과 같이 두가지 방법을 생각하고 있다.
1. 전체 Shared State Cache 디렉토리를 tarball로 압축하여 빌드할 때마다 다운로드하고 압축을 풀어 사용하는 방법
2. aws s3 sync 명령어를 사용하는 방법 (명령어 사용방법은 간단하다. scp와 비슷하고 아래 예제를 보면 된다.)
작은 파일이 엄청나게 많은 개수로 쪼개서 다른 디렉토리에 있기 때문에 파일을 압축하고 푸는 시간만 해도 엄청나게 소요되어 2번 방법으로 하기로 결정했다. 현재 다운로드를 위한 sync 시간만 최대 15분정도 걸린다. upload할 때는 5분 정도로 훨씬 더 적다. 차이는 download할 때는 아무것도 없고, upload할 때는 이미 데이터가 있기 때문이다. (물론 추후에 추가적인 Trick를 사용할 예정이다.)
다운로드 할 때는 전체를 받는 것이기 때문에 aws s3 cp가 aws s3 sync에 비해 비교하는 루틴이 없어서 오버헤드가 더 적을 수 있다.
결론
캐시 저장공간을 위해 EFS를 사용하고 있는 것을 S3로 바꾸는 작업을 진행중에 있다. 장점은 AWS 비용 절약 및 시스템 안정성이다. 단점은 sync하는데 드는 시간인데 이는 엄청난 단점이 현재로써 되지는 않는다. 대규모 환경에서 조금 더 테스트 해봐야겠지만 현재까지는 가능성이 있어 보인다.
'Yocto' 카테고리의 다른 글
| Yocto 소스 코드 MIRROR를에 대한 이해 및 AWS Storage Service (0) | 2024.08.14 |
|---|---|
| Yocto Shared State Cache 디버깅 하기 (0) | 2024.07.31 |
| Yocto의 PREMIRROR와 Shared State Cache (빌드 속도 향상) (0) | 2024.06.13 |
| Yocto 병렬 빌드 옵션 최적화 (0) | 2024.06.10 |
| git send-email 에서 gmail 사용시 비밀번호는? (0) | 2024.05.28 |