Yocto 프로젝트에서 MIRROR는 소스 코드를 다운로드할 때 참조할 수 있는 대체 저장소를 의미한다. 이는 빌드 시스템이 외부 인터넷 리소스에 의존하지 않고, 지정된 미러 서버나 로컬 저장소에서 필요한 소스를 먼저 다운로드할 수 있도록 하여, 빌드 효율성을 향상시키고, 네트워크 대역폭을 절약하며, 다운로드 실패 가능성을 줄이는 데 도움을 준다.
MIRROR의 주요 기능과 이점
1. 속도 향상: 내부 네트워크에 위치한 미러 서버를 사용할 경우, 인터넷보다 훨씬 빠르게 소스를 다운로드할 수 있다.
2. 대역폭 절약: 외부 인터넷 트래픽을 줄이고, 내부 네트워크를 활용하여 대역폭을 절약할 수 있다.
3. 빌드 안정성: 외부 서버의 가용성 문제나 네트워크 연결 문제에도 불구하고 안정적으로 빌드를 진행할 수 있다.
4. 일관성: 여러 개발자가 동일한 소스 미러를 사용함으로써, 모든 빌드가 동일한 소스 코드에 접근하여 일관성을 유지할 수 있다.
5. 오프라인 빌드: 인터넷 접속이 제한적이거나 없는 환경에서도 빌드를 진행할 수 있다.
Yocto에서 사용하는 MIRROR 종류 (소스 다운로드 우선순위 대로)
- DL_DIR: Yocto는 먼저 DL_DIR에서 필요한 파일을 찾습니다. DL_DIR은 이미 다운로드된 파일들이 캐시된 로컬 디렉토리다. 만약 필요한 파일이 여기에 있으면 네트워크를 통해 다시 다운로드하지 않는다.
- PREMIRRORS:
- 파일이 DL_DIR에 없으면 PREMIRRORS에 정의된 미러 사이트들을 확인한다. 이 변수는 소스 URI에서 지정된 원본 사이트로 가기 전에 참조할 미러 사이트들을 정의한다.
- 보통 빠른 접근을 위해 사내 캐시 서버나 로컬 네트워크의 미러를 설정한다. - SOURCE_MIRROR_URL:
- PREMIRRORS에서 파일을 찾지 못하면, SOURCE_MIRROR_URL에 설정된 내부 미러 서버를 시도한다.
- 이 URL은 소스 파일을 중앙에서 관리하기 위한 내부 서버로 지정되어 있는 경우가 많다. - SRC_URI:
- 위의 모든 단계에서 파일을 찾지 못하면, Yocto는 SRC_URI에 정의된 원본 소스 URL에서 파일을 다운로드하려고 시도한다.
- SRC_URI는 주로 공식 사이트나 오픈 소스 프로젝트의 저장소와 같은 원래의 소스 위치를 나타낸다. - MIRRORS:
- SRC_URI에서도 파일을 찾지 못하면, MIRRORS에 정의된 미러 사이트들을 마지막으로 시도한다. 이는 원본 사이트가 불안정하거나 접근이 불가능할 때 사용할 수 있는 대체 다운로드 경로이다.
이러한 방식으로 Yocto는 네트워크 사용을 최적화하고, 소스 파일의 가용성을 높이기 위해 다양한 경로를 통해 파일을 다운로드하려고 시도한다. SRC_URI는 소스의 원본 위치를 정의하며, 미러와 캐시가 실패했을 때 마지막으로 사용된다.
AWS에서 소스코드를 저장할 수 있는 공간 (EFS, S3, EBS)
AWS에서 Object를 저장할 수 있는 서비스는 EFS (Elastic File Store), S3 (Simple Storage Service), EBS (Elastic Block Store) 3개가 있다. EBS는 여러 AWS Instance에서 공유하는 목적이 아닌 단일 서버의 저장공간이므로 여기서 EFS와 S3를 사용할 수 있다.
AWS EFS (Elastic File System)
AWS EFS는 관리형 네트워크 파일 시스템(NFS)으로, 다중 EC2 인스턴스에서 동시에 파일 시스템을 마운트하고 사용할 수 있다.
장점
1. POSIX 호환성: EFS는 POSIX 파일 시스템으로, 기존 파일 시스템 API를 그대로 사용할 수 있어 애플리케이션 변경 없이 통합할 수 있다.
2. 동시 액세스: 여러 EC2 인스턴스에서 동시에 마운트하여 사용할 수 있어 협업 작업이나 동시 데이터 처리에 유리하다.
3. 확장성: 필요에 따라 자동으로 확장되고 축소되어 관리가 간편하다.
4. 파일 시스템 인터페이스: 파일 및 디렉토리 구조를 지원하여, 기존 파일 시스템과 유사한 방식으로 데이터 관리가 가능하다.
단점
1. 비용: EFS는 GB 단위로 청구되며, 특히 사용량이 많지 않은 경우 비용이 상대적으로 높을 수 있다. 또한 Throughput을 높은 것을 사용하면 높은 비용이 발생한다.
2. 지연 시간: 네트워크 파일 시스템이므로, 로컬 디스크에 비해 지연 시간이 길 수 있다.
3. 가용성 제한: 특정 리전 내에서만 사용할 수 있으며, 리전 간의 사용은 추가적인 설정이 필요하다.
AWS S3 (Simple Storage Service)
AWS S3는 객체 스토리지 서비스로, 대규모 데이터 저장 및 백업에 주로 사용된다.
장점
1. 저렴한 비용: S3는 대량의 데이터를 경제적으로 저장할 수 있어 장기 저장 및 백업에 유리하다.
2. 내구성 및 가용성: S3는 99.999999999%의 내구성을 제공하며, 높은 가용성을 보장한다.
3. 글로벌 접근성: S3는 전 세계 어디서나 접근할 수 있으며, 리전 간 복제를 통해 데이터의 지리적 중복성을 높일 수 있다.
4. 다양한 스토리지 클래스: 필요에 따라 다양한 스토리지 클래스를 선택하여 비용을 최적화할 수 있다 (예: S3 Standard, S3 Intelligent-Tiering, S3 Glacier 등).
단점
1. 객체 스토리지 제한: 파일 시스템 인터페이스가 아닌 객체 스토리지로, 전통적인 파일 시스템 API와의 호환성이 떨어질 수 있다.
2. 지연 시간: 데이터 액세스 시 네트워크 지연이 있을 수 있으며, 빈번한 데이터 읽기/쓰기가 필요한 워크로드에는 부적합할 수 있다.
3. 구현 복잡성: 파일 기반 접근을 위해 추가적인 코드 또는 도구(S3FS 같은)가 필요하다.
현재 프로젝트 설정 및 계획
현재 프로젝트에서 여러개의 AWS EFS를 사용하고 있다. 높은 Throughtput을 사용하도록 설정하여 기본 비용도 많이 들어가고 무제한적으로 확장 가능한 EFS 공간의 비용을 많이 사용하고 있어 엄청난 비용을 지불하고 있다.
계획은 AWS S3로 SOURCE_MIRROR_URL를 설정하여 사용하는 것이다. Local에서 기대한 봐야 같이 잘 동작했고 실제 설정에 대한 설명은 다음글에서 할 예정이다. 하지만 CI가 동시에 엄청나게 많이 돌고 있기 때문에 이에 대한 부하를 잘 견디는지에 대한 테스트가 실제 적용하기 전에 필요하다. 이에 대한 결과도 추후 공유할 예정이다.
'Yocto' 카테고리의 다른 글
| Yocto 소스 코드 MIRROR를에 AWS S3와 연결 (0) | 2024.08.15 |
|---|---|
| Yocto Shared State Cache 디버깅 하기 (0) | 2024.07.31 |
| AWS에서 Yocto Shared State Cache 설정 (CI 환경) (0) | 2024.06.25 |
| Yocto의 PREMIRROR와 Shared State Cache (빌드 속도 향상) (0) | 2024.06.13 |
| Yocto 병렬 빌드 옵션 최적화 (0) | 2024.06.10 |