젠킨스 아키텍처(Jenkins Architecture)

<마스터와 에이전트>
일반적으로 파이프라인은 매우 복잡해서 보통 소스코드를 컴파일 하고 파일을 다운로드 받고, 테스트를 실행하는데에는 상당한 시간이 소요된다. 빌드 한 번 하는데에 최소 몇분에서 몇시간까지 걸릴 수도 있다.
젠킨스에서 커밋을 자주 하는 팀은 과부하 상황이 발생해서 젠킨스 인스턴스가 죽기도 한다. 이런 이유 때문에 소규모가 아닌 프로젝트의 경우에는 빌드 작업을 에이전트 인스턴스에 위임해 실행하는 방식을 사용한다.

정리하면, 현재 젠킨스를 실행하고 있는 젠킨스 마스터가 있고, 실제 작업은 젠킨스 에이전트(슬레이브)에 위임해 실행하는 것이다.

분산 빌드 환경에서 젠킨스 마스터는 다음과 같은 작업을 수행한다. 
- 깃허브에 커밋이 발생한 직후 빌드 시작 명령을 받는다
- 빌드 실패시 알림을 보낸다
- 클라이언트와 통신을 하며 HTTP 요청을 처리한다.
- 에이전트에서 실행 중인 우선순위 조정 등의 빌드 환경을 관리한다.
빌드 에이전트는 빌드가 시작된 이후에 발생하는 모든 작업을 처리하는 기기를 말한다. 
에이전트는 가능한 범용성을 갖춘 기기여야 한다. 에이전트들에게 어떤 언어로 작성된 프로젝트를 할당해도 잘 수행했어야 한다.

확장성

젠킨스도 사용량 증가에 따라 급격히 과부하 상태가 되고 수행 속도가 떨어진다. 이를 방지하기 위해서 미리 확장(=스케일링)계획을 세우면 좋다. 확장에는 수직적 확장과 수평적 확장 두가지가 있다.

수직적 확장
마스터의 부하 증가에 대응해 마스터 시스템에 자원을 추가하는 방식이다. 즉, RAM, CPU를 추가하고 외장 하드 드라이브도 확장하는 것이다. 

수평적 확장
마스터 인스턴스의 수량을 늘려가는 방식이다. 극단적으로는 각 팀마다 한대씩의 마스터를 두게 될 수도 있다. 이 방식의 단점으로는 프로젝트 간의 통합 자동화가 어렵다는 것과 팀마다 젠킨스를 유지보수하는 시간이 필요하는 점이 있다. 하지만 장점으로는 마스터 역할의 하드웨어가 고사양할 필요가 없고 팀마다 플러그인을 다르게 설치 할 수 있다. 

테스트 인스턴스/프로덕션 인스턴스
확장 방식외에 고려할 점은 젠킨스 업그레이드와 신규 플러그인, 파이프라인 정의를 어떻게 할 것인가이다. 소프트웨어 품질을 보증하며 프로덕션 서버에 배포하는 역할을 하기 때문에 고가용성이 매우 중요하다. 그래서 젠킨스는 항상 동일한 두개의 인스턴스를 테스트용과 프로덕션용으로 분리 운영해야 한다.

*젠킨스는 다수의 에이전트와 (다수의) 마스터로 구성되며, 테스트 및 프로덕션 환경으로 이중화 구성을 해야한다.