GitLab Geo 구성하기 — 분석 #1

Published in

Cloud Villains

9 min readSep 14, 2021

개요

고객에게서 GitLab DR구성(온프렘 ↔ AWS)에 대한 기술지원 요청이 왔습니다. 국내에는 구축한 사례도 없는 것 같습니다(슬픕니다 또 맨땅에 헤딩이라니😥). 새로운 기술적용은 언제나 즐겁고 재밌습니다. 삽질 과정이 어려울뿐이죠. 클라우드 빌런즈의 일원으로 맡은바 역할에 충실하기 위해 구성 전 분석과 테스트 과정 등을 작성합니다. 한 번에 다루기에 많은 내용이라, 이번 글에서 모든 내용을 다루진 않으며 구축 과정 및 후기는 다음 글에서 추가 작성할 예정입니다.

고객사에서 받았던 요구조건 중 큰 틀은 다음과 같습니다.

GitLab Self Managed 구성(Private)
AWS에 구성된 GitLab은 Primary이고 온프렘에 구성된 Gitlab은 Secondary

폐쇄망에서 사용해야 하니 Self Managed를 직접 구성해야 하며(SaaS 사용 X) ISMS인증 심사 요건인 저장소 DR구성이 필요합니다. 이 과정중에 또 여러가지 필요한 조건들이 있지만 자세한 내용은 뒷부분에 기술하겠습니다.

GitLab Geo?

GitLab Geo는 인스턴스의 로컬 읽기 전용 사이트를 제공합니다. Primary 서비스가 한국리전에 있다고 가정 할 경우 해외 리전에서는 읽고 쓰기가 매우 느릴겁니다. 이럴 경우 Geo를 사용하여 해외 리전에 읽기전용 인스턴스를 구축할 경우 Repository를 복제하고 가져오는 시간을 줄일 수 있습니다. 또한 Primary 서비스에 장애가 발생 하더라도 Secondary 를 통해 장애 복구 또한 가능해집니다.

주의사항

DR구성(Geo)을 구축하기 전에 알아야 할 사전정보와 주의점들을 확인해봅시다.

GitLab Release 마다 큰 변화가 있으니 기존에 구성되어 있는 작업 진행시 반드시 올바른 버전의 문서를 사용하고 있는지 확인합니다.
사용자가 천 명 이하일 경우 단일 Repository를 사용하는 것을 추천합니다. 반드시 DR구성을 해야 하는 요건 일 경우에만 작업하시는 것을 추천드립니다.

단일 GitLab 인스턴스에서 Geo 구성으로 변경 할 경우 추가비용과 관리포인트가 들어갑니다. 추가적인 비용과 관리포인트들이 생기니 확인하시길 바랍니다.

장점

Geo 구성시 다음과 같은 장점이 있습니다.

대규모 저장소 및 프로젝트를 복제하고 가져오는 시간을 크게 줄입니다.
모든 개발자가 어느 지역에서건 동시에 작업할 수 있습니다.
멀리 떨어진 사무실 간의 느린 연결이 극복 가능해지고 팀의 속도를 개선합니다.
재해 복구 시나리오를 통해 보조 사이트로 신속하게 장애 조치가 가능합니다.(자동으로 전환하는 작업을 지원하지 않으며 수 작업을 해야합니다.)

Geo 동작 방식 및 아키텍처

GitLab Geo 의 대략적인 아키텍처는 다음과 같습니다.

Primary GitLab은 기본적인 GitLab과 동일하게 동작하며 Secondary GitLab은 Clone, Pull등의 저장소 복제는 기본적인 GitLab과 동일하게 동작하지만 Push의 경우 Proxy를 통해 Primary 서버로 푸시를 진행하도록 되어 있습니다.
(이미지 출처 : GitLab 공식 문서)

(이미지 출처 : GitLab 공식 문서)

간략히 중요한 구성 몇가지만 살펴보겠습니다.

하나의 Primary 사이트와 여러개의 Secondary 사이트로 구성됩니다.
DB(PostgreSQL)의 쓰기는 오직 Primary 사이트에서만 수행하며 Secondary 사이트는 스트리밍 복제를 통해 DB를 업데이트 합니다.
LDAP이 있는 경우 LDAP 또한 재해복구 시나리오를 구성 해야합니다.
Primary에서 사용하는 DB와 Secondary에서 사용하는 DB를 각각 최소한 한벌씩 구성해야 합니다.

Geo 구성 요구 사항

OpenSSH v6.9 이상을 지원하는 OS

CentOS v7.4
Ubuntu v16.04

PostgreSQL v12

Primary, Secondary 각각에 PostgreSQL이 필요
Secondary DB는 ReadOnly

Git v2.9
Git-lfs v2.4.2
모든 Primary, Secondary 인스턴스에 동일한 GitLab Version 필요

Geo 방화벽 설정

다음과 같은 방화벽 포트가 열려있어야 합니다.

제한사항

Geo를 도입하여 구성할 경우 다음과 같은 제한사항들이 있습니다.

Secondary 로 Push할 경우 직접 처리하지 않으며 Primary로 리디렉션하거나 프록시로 전달합니다.
OAuth 로그인이 이루어지려면 Primary가 온라인 상태여야 합니다.
설치 과정에 따라 약 한시간 이상의 작업이 필요 할 수 있습니다.
GitLab Runner는 Secondary 서버에 등록 할 수 없습니다. (차후 지원 예정)

위와 같은 내용들을 확인후 다음장에서 실제 구성 테스트에 들어가도록 합니다.

재해복구(Disaster Recovery — Geo)

Primary의 노드가 장애로 서비스 중지가 되었을 때 Secondary 노드를 Primary로 승격시킬 경우 이전 Primary 에 있던 모든 데이터를 Replicate를 통해 복제하지 못 했을 경우 복제되지 않은 모든 데이터는 손실됩니다.

위와 같은 제약조건이 있으며 자동으로 승격하는 기능들이 현재에는 지원되고 있지 않습니다. 또한 재해복구시 서비스 중지는 무조건 일어난다 라고 생각해도 될 것 같습니다. 재해 복구를 진행할 때 Secondary 노드를 Primary로 승격할 경우 추가 Secondary 노드를 구성해야 할 수 있습니다.

고려사항

우리가 구성해야 할 Geo는 온프렘 ↔ AWS 간 DR 구성이므로 다음과 같은 내용들을 반드시 고려해야 합니다. 상세히 살펴 보시죠!

공통

GitLab 버전 픽스
스토리지 관리 방안
객체 스토리지 사용 유무
SSH 사용 유무(ISMS 인증 심사시 기본포트 사용에 이슈가 있을 수 있음)
인증서 관리 방안

스토리지

객체 스토리지를 사용하지 않을 경우 스토리지에 지속적으로 큰 데이터가 쌓일 수 있고 백업 시간도 늘어나게 됩니다.

SSH

SSH를 사용하여 Clone, Pull, Push 등을 사용할 수 있는데 22번 포트의 사용이 ISMS 심사로 인해 사용 할 수 없는 경우 포트를 변경하여 사용해야 할 수 있습니다. 사용 할 수 있는 기능을 막아놓고 안쓰기 보다 포트를 변경하여 사용할 수 있다면 좋겠죠.

인증서

AWS에서 사용하는 인증서는 외부에 빼올 수 없습니다. 즉, 자체적으로 구매한 인증서를 사용해야 할 것으로 예상합니다.(매해 인증서를 교체해야 하는 단점이 있습니다. 매우 불편하고 귀찬습니다.) 또한 GitLab이 제공하는 Lets Encrypt(무료 인증서를 자동으로 재발급하는 프로그램)도 사용 할 수 없습니다. 폐쇄망이니까요😫

IDC

서버 스펙
설치 OS 종류와 버전정보
PostgreSQL 직접 구성? GitLab에서 제공하는 PostgreSQL을 사용 할 것인지?
LB(HAproxy) 직접 구성? 구성된 LB가 있는지?

IDC에 구성하면 관리포인트가 많이 늘어납니다. 상세한 내용들을 살펴보겠습니다.

OS

GitLab을 설치하기 가장 좋은 OS는 Ubuntu, CentOS입니다(개인적인 의견입니다). 또한 GitLab에서 요구하는 최소 스펙 정보가 있습니다. 해당 기준을 맞춰야 합니다.

Database

데이터베이스를 구성하는 두가지 방법이 있습니다.

첫번째는 PostgreSQL을 서버에 직접 구성하고 GitLab에 엔드포인트를 제공하여 관리하는 방법입니다. 이 방법으로 진행 할 경우 DB를 구성할 DBA가 필요하고 GitLab 버전 업그레이드시 PostgreSQL의 버전 업그레이드를 자동으로 진행 할 수 없습니다.

두번째는 GitLab에서 제공하는 PostgreSQL을 사용하여 관리하는 방법입니다. GitLab에서 제공하는 번들이므로 자동 업그레이드와 데이터 관리도 진행됩니다.

LB

사용중인 LB가 있을 경우 인증서 관리를 LB에서 하고 Backend에는 인증서를 달지 않는 경우가 있습니다. 어떻게 구성할 것인지 사전에 고려를 해야 합니다.

AWS

VPC CIDR?
RDS(PostgreSQL) 사용?
Redis(ElastiCache) 사용?
Object Storage 사용?(S3)
ACM 사용 유무?(SSL 인증서 관리)

AWS는 클라우드 서비스이니 관리형 서비스들을 사용할 수 있습니다. 살펴봅시다!

VPC

IDC에 구성된 서버들이 사용중인 CIDR을 피해서 구성해야 합니다. 사용중인 CIDR이 있는지? CIDR Range가 얼마나 되는지를 반드시 체크해야 합니다.

Database

GitLab에서 제공하는 PostgreSQL을 사용할 수도 있지만 AWS에서 제공하는 관리형 서비스인 RDS를 사용 할 수도 있습니다. 구성하는 방법은 여러 가지가 있는데 앞서 설명한 IDC에서의 Database 구성방법을 모두 사용 할 수 있습니다. 추가적으로 AWS의 RDS를 사용할 수 있으며 버전 업그레이드 등의 작업은 직접 진행해야 합니다. RDS를 이용하면 백업에 관련한 부분을 AWS의 DBA담당자가 관리할 수 있습니다.

Redis

Redis의 경우 AWS에서 제공하는 ElastiCache Redis 를 사용 할 수 있으며 엔드포인트를 통해 연결하는 방식입니다. PostgreSQL과 마찬가지로 버전업그레이드 등은 수작업이 필요하고 백업등은 AWS의 담당자들이 직접 할 수 있습니다. GitLab에서 제공하는 설치형을 이용할 경우 업그레이드 부분은 자동으로 진행되지만 인스턴스의 자원을 사용하고 이슈가 생길 경우 인스턴스를 직접 확인하고 접속해야 하는 단점등이 있습니다.

Object Storage

AWS에서 제공하는 S3 스토리지를 사용할 경우 로컬 스토리지의 부담을 많이 덜 수 있으며 EBS 볼륨을 사용하는 것 보다 비용 효율적입니다. 또한 대용량파일을 저장할 경우 LFS 파일시스템을 이용하여 파일을 저장하게 되는데 이러한 큰 사이즈의 파일들은 S3에 저장하고 사용하는게 로컬 스토리지(EBS)를 이용하는 것보다 훨씬 비용 효율적입니다.

ACM

AWS에서 제공하는 인증서 관리 서비스입니다. 매해 혹은 2년에 한번씩 인증서를 교체해 주어야 하는 작업을 이 서비스를 통해 관리합니다. 별 다른 사유가 없다면 사용하는게 좋습니다.

참고) ACM 사용을 위해서는 AWS에서 제공하는 ELB를 사용하는게 좋습니다.

블랙홀?

IDC에 구축한 GitLab에서 사용하는 인증서와 AWS에 구축한 GitLab의 인증서가 서로 다를 경우 서비스가 정상적일지 검증이 되지 않았습니다. 반드시 테스트를 진행하고 구성해야 합니다. 만약 서로다른 인증서를 사용 할 수 없는 경우 ACM에 인증서를 등록해서 사용해야 할 수 있습니다.

Next?

고려사항과 아키텍처 구성에 대해 분석을 완료했으니 구성할 아키텍처를 그리고 테스트를 진행해야 합니다. 해당 내용은 다음장에서 진행하도록 하겠습니다.