[Git] 대용량 Repository 이전하기 - nginx, git config, L7 Loadbalancer 까지

Git 저장소를 AWS에서 GCP로 이전하면서 여러 가지 문제를 겪었다. 특히 대용량 저장소 이전에서 예상치 못한 난관이 많았고, 다양한 방법을 시도해 해결했다. 이번 글에서는 처음 시도한 방법과 실패한 이유, 그리고 최종적으로 성공한 방법을 정리해보려 한다.

 

Git 저장소 이전 방법

1. 기본적인 Git 이전 방법

가장 먼저 아래와 같은 방식으로 저장소를 이전했다.

1) 기존 저장소를 클론 (mirror 방식)

git clone --mirror <기존_저장소_URL>

 

2)  새로운 저장소에 푸시

cd <저장소_이름>.git
git remote set-url origin <새로운_저장소_URL>
git push --mirror

하지만... 대용량 저장소에서는 실패! 😭

---

push 실패 원인과 해결 방법

❌ 실패 원인: push 중 RPC 에러 발생

파일 크기가 크면 아래와 같은 에러가 발생하며 push가 실패할 수 있다.

error: RPC failed; HTTP 504 curl 22 The requested URL returned error: 504  
send-pack: unexpected disconnect while reading sideband packet  
fatal: the remote end hung up unexpectedly  

이 에러는 보통 다음과 같은 이유로 발생한다.
✅ 클라이언트에서 보낼 수 있는 버퍼 크기가 작은 경우
✅ 서버에서 응답 처리가 지연되어 클라이언트가 연결을 끊는 경우

---

✅ 해결 방법

1. Git 클라이언트 설정 변경

Git은 기본적으로 HTTP 전송 크기에 제한이 있기 때문에, 클라이언트와 서버 모두 설정을 조정해야 한다.

git config --global http.postBuffer 2147483648  # HTTP POST 버퍼 크기를 2GB로 설정
git config --global http.lowSpeedLimit 0        # 전송 속도 제한 해제
git config --global http.lowSpeedTime 999999    # 시간 초과 전에 최대 대기 시간 설정

2. Nginx 설정 변경

Nginx의 기본 업로드 제한이 1MB이므로, 업로드 가능한 파일 크기를 늘려야 한다.
또한, 백엔드 서비스와 연결이 끊어지지 않도록 proxy 설정도 추가했다. (혹시 몰라 아주 넉넉하게 설정함 😅)

http {
    client_max_body_size 2G;   # 최대 업로드 크기 (2GB)
    proxy_read_timeout 600;    # 응답 대기 시간 (600초)
    proxy_connect_timeout 600; # 연결 대기 시간 (600초)
    proxy_send_timeout 600;    # 데이터 전송 시간 (600초)
    send_timeout 600;          # 클라이언트와 유지 시간 (600초)
}

여기까지 하면 대부분의 경우 대용량 Git 저장소도 문제없이 push할 수 있다.
하지만... 나는 여전히 실패했다. 😭

---

🚨 여전히 push가 실패하는 경우

특정 저장소는 .git 폴더 크기만 1.1GB였고, 계속 실패했다.
이쯤 되니 git history를 싹 밀어버리고 싶은 유혹이 들었지만... 그럴 수는 없지 😭

3. 서버 리소스 확인

혹시 자원 부족 문제일까? 나는 Docker를 사용하고 있지만, 컨테이너별 자원 제한을 따로 설정하지 않고 호스트 자원을 그대로 사용하고 있었다.

$ docker stats

결과적으로 CPU(4코어), 메모리(16GB) 모두 여유가 많았다.
즉, 리소스 문제는 아니었다. 🤔

---

🔍 문제의 원인은 GCP Load Balancer의 타임아웃!

마지막으로 Nginx 로그를 확인하는데... 499 에러가 보였다.
*499 에러는 클라이언트가 요청을 보내고 응답을 받기 전에 연결을 끊었을 때 발생하는 에러*이다.

클라이언트가 연결을 끊었다고? 🤔
그럼 클라이언트는... Git client인가?

여기서 클라이언트는 바로! GCP Load Balancer(L7)이었다.

---

📌 문제 발생 과정

GCP LB의 백엔드 서비스 타임아웃 기본값이 30초로 설정되어 있었다.

⚡ 문제 흐름

1. Git 클라이언트가 git push 실행 → GCP LB로 요청 전송
2. GCP LB가 요청을 Nginx로 전달
3. Nginx → Gitea로 전달 후, Gitea가 데이터 처리
4. Gitea에서 데이터 처리 시간이 길어지면?
   • GCP LB는 30초 후 타임아웃 발생
   • GCP LB가 Nginx와의 연결을 끊음
5. 하지만! Git 클라이언트는 여전히 데이터를 전송 중
6. 결국 Git 클라이언트는 응답을 받지 못하고 HTTP 499 에러 발생

---

✅ 최종 해결: Load Balancer 타임아웃 설정 변경

GCP LB의 백엔드 서비스 타임아웃을 늘려서 해결했다.

💡 교훈: 문제 해결할 때 인프라 구성도를 꼭 확인하자!
Git 클라이언트 → GCP LB → Nginx → Gitea 흐름을 정확히 이해했다면 더 빠르게 해결할 수 있었을 것이다.

이번 삽질을 통해 "Git push 실패의 원인이 꼭 Git 때문만은 아니다!"라는 것을 확실히 깨달았다.
나처럼 GCP LB를 사용한다면, 타임아웃 설정 꼭 확인하자! 🚀