Gitlab MR 병목현상

1. VPC와 서버 이미지 

[회사 사용자 PC]
   ↓
[DBSafer]
   ↓
[운영 VPC 10.0.0.0/16]
   ├─ 192.xx.xx.10 : prod-jenkins
   ├─ 192.xx.xx.20 : stg-jenkins
   ├─ 192.xx.xx.30 : prod-app-1
   ├─ 192.xx.xx.40 : stg-app-1
   └─ 192.xx.xx.50 : bastion or utility server
-----------------------------------------------------------
[VPC]
 ├─ EC2 A: 운영 관리/접속 대상 (192.xx.xx.xx) 
 │   └─ Linux OS 
 │       └─ SSH 접속
 │
 ├─ EC2 B: STG Jenkins 	<- 물리/가상머신 자체 (EC2 한대/ 리눅스 설치된 VM한대) 
 │   └─ Linux OS 	<- ✨ 운영체제 
 │       └─ Jenkins 	<- 그 위에서 동작하는 역할/프로그램  
 │
 ├─ EC2 C: 운영 Jenkins
 │   └─ Linux OS
 │       └─ Jenkins
 │
 ├─ EC2 D: GitLab 서버
 │   └─ Linux OS
 │       └─ Docker
 │           └─ GitLab / Worker / Queue
 │
 ├─ EC2 E,F,G: STG App 서버들
 │   └─ Linux OS
 │       └─ 앱 실행
 │
 ├─ EC2 H,I,J: 운영 App 서버들
 │   └─ Linux OS
 │       └─ 앱 실행
 │
 └─ DB 서버 / RDS
     └─ 데이터 저장

 

• EC2는 가상 서버 인스턴스고
• 그 EC2에 네트워크 인터페이스(ENI)가 붙어 있고
• 그 인터페이스에 사설 IP가 할당되고
• 리눅스 OS는 그 네트워크 인터페이스를 통해 통신

 

2. 서버 자체 접속 과정 

 

 

OS위에 Docker

1. 먼저 DBSafer가 중간에서

• 접속 권한을 확인하고
• 누가 들어갔는지 기록하고
• 허용된 대상만 오픈

2. PuTTY는 실제 SSH 접속 도구

• 즉, DBSafer가 “문을 열어주는 통제 장치”라면,
• PuTTY는 그 문을 통해 실제로 SSH 세션을 여는 클라이언트

3. 192.xx.xx.xx는 보통 그 EC2의 사설 IP

• 그래서 이 IP로 들어간다는 건 보통 운영 VPC 안에 있는 특정 EC2의 Linux OS에 로그인

4. 로그인 후에는 OS 쉘에 들어간 상태
여기서부터는

• 서버 자체 상태를 보거나
• Docker를 확인하거나
  리눅스 OS 위에서 GitLab 같은 서비스를 컨테이너로 실행하게 해주는 도구
  
• Jenkins/GitLab 관련 프로세스를 보고
• 로그를 읽고
• queue worker를 재시작하거나
• stuck job 원인을 찾는 작업

 

3. Git 병목 문제 현상 원인 

개발자 PC
  ↓
GitLab 웹 접속
  ↓
STG 브랜치로 MR 생성 (DB 인입)
  ↓
GitLab Web/API가 요청 처리
  ↓
MR 관련 백그라운드 작업을 Queue에 넣음 ✨
  ↓
Worker가 Queue에서 작업을 꺼내 처리
  ├─ diff 계산
  ├─ 상태 갱신
  ├─ pipeline 연동
  └─ 각종 메타데이터 처리

 

컨테이너 직접 접속 

PuTTY로 Linux OS 접속
  ↓
OS 쉘에서 Docker 상태 확인
  ↓
Docker 컨테이너 목록 확인
  ↓
GitLab 관련 컨테이너 / worker 확인
  ↓
queue 적체 원인 점검
  ├─ worker 멈춤?
  ├─ Redis 문제?
  ├─ stuck job 존재?
  └─ 자원 부족?
  ↓
재시작 / 정리 / 복구