GitLab HA 구성하기 (GitLab Korea Meetup 발표 요약)

GitLab으로 개발자의 업무시스템을 쓰신다고요? GitLab 서버가 장애로 Git 활동이나 MR 활동 못하면 협업에 지장이 생기고, 불편을 초래하게 되죠? 이를 방지하기 위해 GitLab도 HA로 구성을 할 수 있습니다.

GitLab Reference Architecture에는 3000명 이상 사용자 부터 HA를 구성에 대한 가이드를 하고 있습니다. 이를 토대로 GitLab Korea Meetup에서 우리회사 Jason 께서 세션 발표를 짧게 진행해 주셨습니다.

발표에서 나온 인사이트들을 정리해 보았습니다.

가용성? 고 가용성은 뭐고 왜 필요 할까요?

가용성 이란? 정상 사용 시간(Uptime)을 전체 사용시간(Uptime+Downtime)으로 나눈 값으로 높을 수록 높다고 표현하고 고 가용성이라고 합니다. DevOps 세상에서 고 가용성은 기본이죠? IT 전달 속도를 지속해서 높이려면... 결국 잘 죽지 않거나 죽어도 빨리 회복되어야 합니다.

고 가용성을 확보하면, 중단 없이 서비스를 쓸 수 있고 부하 분산에 따른 성능저하를 방지할 수 있으며, 달리는 자동차의 바퀴를 갈아 끼울 수 있게 됩니다!

GitLab으로 HA를 구성해야 하는 이유는 무엇 일까요?

GitLab은 개발자의 협업 도구 중에 중요한 코드 활동과 CI/CD 파이프라인을 담당합니다. 그래서 요구사항을 에픽과 이슈로 만들어 쓰고, 쓰레드로 커뮤니케이션하며 코드를 커밋하고 서버에 푸시하면 파이프라인이 자동으로 구동됩니다..

만약 이 업무 시스템이 다운되면 어떻게 될까요?

HA 구성하는 하드웨어 비용 및 운영비가 더 비쌀까요? 업무 시스템 중단으로 여러 사람들의 업무에 불편을 초래하는 것이 비쌀까요? 답은 이미 정해져 있습니다! HA 구성이 필요합니다!

GitLab Omnibus 라는 것이 있다는데요?

GitLab은 좀더 편하게 운영관리를 하도록 Omnibus 패키지라는 것을 제공 하고 있습니다. 설정에서 GitLab 내부에 포함된 다양한 컴포넌트를 껐다 켰다 하고, 구체적인 설정을 할 수 있도록 사전에 패키징을 모두 해놓은 거죠.

이걸 이용하면, 상대적으로 쉽게 HA를 구성 할 수 있습니다.

Omnibus GitLab 아키텍처의 특징은요?

단일 노드에서 GitLab 을 운영할 때는 하나의 노드에 모든 컴포넌트 패키지들이 담겨 있구요.

조금 더 많은 사용자가 이용하게 된다면, 노드를 분리해서 특정 목적을 가지는 노드를 별도로 운영하게 됩니다.

이것을 AWS의 컴퓨팅 리소스를 활용해서 만든다면, 더 쉬워지겠죠?

그래서 AWS 기반으로 구축 한다면?

GitLab에서 HA하기 위한 3000 사용자 아키텍처 패턴을 고려해서, 로드밸런서 노드, Redis 노드, PosgreSQL 노드, Gitaly 노드, GitLab Rails 노드 등의 적정 사이즈를 선택합니다.

Terraform 으로 노드를 프로비저닝 하고 gitlab을 설치하죠.

그리고 노드를 다운시켜 보며, 장에 발생시에 문제가 없는지 확인을 해보게 됩니다.

어려운 일은 아닌데, 해보려면 고려하거나 약간의 깊이가 필요한 부분들이 생깁니다.

인포그랩이 GitLab HA 구성을 잘 합니다. 정확하게는 Jason이 잘 합니다. 😊

앞으로 많이 애용해 주세요.

참고로 밋업 영상은 GitLab Korea 페이스북 그룹에서 찾을 수 있습니다.