GitLab.com을 Kubernetes로 마이그레이션한 XNUMX년간의 결과

메모. 번역: GitLab의 Kubernetes 도입은 회사 성장에 기여하는 두 가지 주요 요인 중 하나로 간주됩니다. 그러나 최근까지 GitLab.com 온라인 서비스의 인프라는 가상 머신을 기반으로 구축되었으며, 불과 8년 전만 해도 KXNUMXs로의 마이그레이션이 시작되었지만 아직 완료되지 않았습니다. 우리는 이것이 어떻게 발생하는지, 그리고 프로젝트에 참여하는 엔지니어들이 어떤 결론을 내리는지에 대한 GitLab SRE 엔지니어의 최근 기사 번역을 발표하게 된 것을 기쁘게 생각합니다.

약 XNUMX년 동안 우리 인프라 부서는 GitLab.com에서 실행되는 모든 서비스를 Kubernetes로 마이그레이션해 왔습니다. 이 기간 동안 우리는 서비스를 Kubernetes로 이동하는 것뿐만 아니라 전환 중 하이브리드 배포를 관리하는 것과 관련된 문제에 직면했습니다. 이 기사에서는 우리가 배운 귀중한 교훈을 살펴볼 것입니다.

GitLab.com의 초기부터 해당 서버는 가상 머신의 클라우드에서 실행되었습니다. 이러한 가상 머신은 Chef에 의해 관리되며 당사를 사용하여 설치됩니다. 공식 리눅스 패키지. 배포 전략 애플리케이션을 업데이트해야 하는 경우 CI 파이프라인을 사용하여 조정되고 순차적인 방식으로 서버 플릿을 업데이트하는 것으로 구성됩니다. 이 방법은 느리고 조금 느리긴 하지만 지루한 - GitLab.com이 오프라인 사용자와 동일한 설치 및 구성 방식을 사용하는지 확인합니다. (자체 관리) 이를 위해 Linux 패키지를 사용하여 GitLab을 설치합니다.

우리가 이 방법을 사용하는 이유는 GitLab 복사본을 설치하고 구성할 때 커뮤니티의 일반 구성원이 경험하는 모든 슬픔과 기쁨을 경험하는 것이 매우 중요하기 때문입니다. 이 접근 방식은 한동안 잘 작동했지만 GitLab의 프로젝트 수가 10만 개를 초과하자 더 이상 확장 및 배포 요구 사항을 충족하지 못한다는 것을 깨달았습니다.

Kubernetes 및 클라우드 기반 GitLab을 위한 첫 번째 단계

이 프로젝트는 2017년에 만들어졌습니다. GitLab 차트 클라우드 배포를 위해 GitLab을 준비하고 사용자가 Kubernetes 클러스터에 GitLab을 설치할 수 있도록 합니다. 우리는 GitLab을 Kubernetes로 전환하면 SaaS 플랫폼의 확장성이 향상되고 배포가 단순화되며 컴퓨팅 리소스의 효율성이 향상된다는 것을 알았습니다. 동시에 우리 애플리케이션의 많은 기능은 마운트된 NFS 파티션에 의존했기 때문에 가상 머신에서 전환하는 속도가 느려졌습니다.

클라우드 네이티브 및 Kubernetes로의 추진을 통해 엔지니어는 점진적인 전환을 계획할 수 있었으며, 그 동안 우리는 새로운 기능을 계속 개발하는 동시에 네트워크 스토리지에 대한 애플리케이션의 종속성 중 일부를 포기했습니다. 2019년 여름에 마이그레이션 계획을 시작한 이래로 이러한 제한 사항 중 많은 부분이 해결되었으며 GitLab.com을 Kubernetes로 마이그레이션하는 프로세스가 현재 순조롭게 진행 중입니다!

Kubernetes의 GitLab.com 기능

GitLab.com의 경우 모든 애플리케이션 트래픽을 처리하는 단일 지역 GKE 클러스터를 사용합니다. (이미 까다로운) 마이그레이션의 복잡성을 최소화하기 위해 우리는 로컬 스토리지나 NFS에 의존하지 않는 서비스에 중점을 둡니다. GitLab.com은 주로 모놀리식 Rails 코드베이스를 사용하며, 워크로드 특성을 기반으로 자체 노드 풀에 격리된 다양한 엔드포인트로 트래픽을 라우팅합니다.

프런트엔드의 경우 이러한 유형은 웹, API, Git SSH/HTTPS 및 레지스트리에 대한 요청으로 구분됩니다. 백엔드의 경우 상황에 따라 다양한 특성에 따라 대기열의 작업을 분할합니다. 사전 정의된 리소스 경계이를 통해 다양한 워크로드에 대한 서비스 수준 목표(SLO)를 설정할 수 있습니다.

이러한 모든 GitLab.com 서비스는 수정되지 않은 GitLab Helm 차트를 사용하여 구성됩니다. 구성은 하위 차트에서 수행되며 서비스를 점차적으로 클러스터로 마이그레이션하면서 선택적으로 활성화할 수 있습니다. Redis, Postgres, GitLab Pages 및 Gitaly와 같은 일부 상태 저장 서비스를 마이그레이션에 포함하지 않기로 결정했지만 Kubernetes를 사용하면 Chef가 현재 관리하는 VM 수를 근본적으로 줄일 수 있습니다.

Kubernetes 구성 가시성 및 관리

모든 설정은 GitLab 자체에서 관리됩니다. 이를 위해 Terraform과 Helm을 기반으로 한 세 가지 구성 프로젝트가 사용됩니다. GitLab을 실행하기 위해 가능할 때마다 GitLab 자체를 사용하려고 노력하지만 운영 작업을 위해 별도의 GitLab 설치가 있습니다. 이는 GitLab.com 배포 및 업데이트를 수행할 때 GitLab.com의 가용성에 의존하지 않도록 하기 위해 필요합니다.

Kubernetes 클러스터용 파이프라인은 별도의 GitLab 설치에서 실행되지만 다음 주소에서 공개적으로 사용할 수 있는 코드 저장소의 미러가 있습니다.

• k8s-워크로드/gitlab-com — GitLab Helm 차트를 위한 GitLab.com 구성 프레임워크;
• k8s-워크로드/gitlab-helmfiles - GitLab 애플리케이션과 직접 연결되지 않은 서비스에 대한 구성을 포함합니다. 여기에는 로깅 및 클러스터 모니터링을 위한 구성은 물론 PlantUML과 같은 통합 도구도 포함됩니다.
• Gitlab-com-인프라 — Kubernetes 및 레거시 VM 인프라를 위한 Terraform 구성입니다. 여기서는 클러스터 자체, 노드 풀, 서비스 계정 및 IP 주소 예약을 포함하여 클러스터를 실행하는 데 필요한 모든 리소스를 구성합니다.

변경사항이 있으면 공개 보기가 표시됩니다. 짧은 요약 클러스터를 변경하기 전에 SRE가 분석하는 자세한 차이점에 대한 링크가 포함되어 있습니다.

SRE의 경우 링크는 생산 및 액세스가 제한된 GitLab 설치의 세부 차이점으로 연결됩니다. 이를 통해 직원과 커뮤니티는 운영 프로젝트(SRE에만 공개됨)에 액세스하지 않고도 제안된 구성 변경 사항을 볼 수 있습니다. 코드용 공개 GitLab 인스턴스와 CI 파이프라인용 비공개 인스턴스를 결합함으로써 구성 업데이트를 위해 GitLab.com으로부터 독립성을 보장하는 동시에 단일 워크플로를 유지합니다.

마이그레이션 과정에서 알게 된 사실

이동하는 동안 Kubernetes의 새로운 마이그레이션 및 배포에 적용하는 경험을 얻었습니다.

1. 가용존 간 트래픽으로 인한 비용 증가

GitLab.com의 Git 저장소 플릿에 대한 일일 송신 통계(일일 바이트)

Google은 네트워크를 지역으로 나눕니다. 이는 차례로 접근성 영역(AZ)으로 구분됩니다. Git 호스팅은 대량의 데이터와 연관되어 있으므로 네트워크 송신을 제어하는 ​​것이 중요합니다. 내부 트래픽의 경우 동일한 가용성 영역 내에 있는 경우에만 송신이 무료입니다. 이 글을 쓰는 시점에서 우리는 일반적인 근무일에 약 100TB의 데이터를 제공하고 있습니다(Git 리포지토리에만 해당). 이전 VM 기반 토폴로지의 동일한 가상 머신에 있던 서비스는 이제 다른 Kubernetes 포드에서 실행됩니다. 이는 이전에 VM에 로컬이었던 일부 트래픽이 잠재적으로 가용성 영역 외부로 이동할 수 있음을 의미합니다.

지역 GKE 클러스터를 사용하면 중복성을 위해 여러 가용성 영역을 확장할 수 있습니다. 가능성을 고려하고 있습니다 지역 GKE 클러스터를 단일 영역 클러스터로 분할 대량의 트래픽을 생성하는 서비스의 경우. 이렇게 하면 클러스터 수준 중복성을 유지하면서 송신 비용이 줄어듭니다.

2. 제한, 리소스 요청 및 확장

Registry.gitlab.com에서 프로덕션 트래픽을 처리하는 복제본 수입니다. UTC 15:00에 트래픽이 최고조에 달합니다.

마이그레이션 스토리는 2019년 XNUMX월 첫 번째 서비스인 GitLab Container Registry를 Kubernetes로 마이그레이션하면서 시작되었습니다. 이 미션 크리티컬하고 트래픽이 많은 서비스는 외부 종속성이 거의 없는 상태 비저장 애플리케이션이기 때문에 첫 번째 마이그레이션에 적합한 선택이었습니다. 우리가 직면한 첫 번째 문제는 노드의 메모리 부족으로 인해 많은 수의 포드가 제거된다는 것입니다. 이로 인해 요청과 한도를 변경해야 했습니다.

시간이 지남에 따라 메모리 소비가 증가하는 애플리케이션의 경우 요청에 대한 낮은 값(각 Pod에 대한 메모리 예약)과 사용량에 대한 "관대한" 하드 제한이 포화를 초래하는 것으로 나타났습니다. (포화) 노드와 높은 수준의 퇴거. 이 문제를 해결하기 위해서였다. 요청을 늘리고 한도를 낮추기로 결정했습니다.. 이를 통해 노드에 대한 부담이 줄어들고 포드가 노드에 너무 많은 부담을 주지 않는 수명 주기를 갖도록 보장되었습니다. 이제 관대하고 거의 동일한 요청 및 제한 값으로 마이그레이션을 시작하고 필요에 따라 조정합니다.

3. 지표 및 로그

인프라 부문은 대기 시간, 오류율 및 설치 포화도에 중점을 두고 있습니다. 서비스 수준 목표 (SLO)에 연결됨 우리 시스템의 일반 가용성.

지난 한 해 동안 인프라 부문의 주요 이벤트 중 하나는 SLO 모니터링 및 작업이 개선된 것입니다. SLO를 통해 마이그레이션 중에 면밀히 모니터링한 개별 서비스에 대한 목표를 설정할 수 있었습니다. 그러나 이렇게 향상된 관찰 가능성에도 불구하고 메트릭과 경고를 사용하여 문제를 즉시 확인하는 것이 항상 가능한 것은 아닙니다. 예를 들어 지연 시간과 오류율에 중점을 두어 마이그레이션 중인 서비스의 모든 사용 사례를 완전히 다루지는 않습니다.

이 문제는 일부 워크로드를 클러스터로 마이그레이션한 직후에 발견되었습니다. 요청 수는 적지만 매우 특정한 구성 종속성을 갖는 기능을 확인해야 할 때 특히 심각해졌습니다. 마이그레이션을 통해 얻은 주요 교훈 중 하나는 모니터링 시 측정항목뿐만 아니라 로그 및 '롱테일'도 고려해야 한다는 점이었습니다. (이건 대략 그러한 분포 차트에서 - 대략. 번역) 오류. 이제 각 마이그레이션에 대한 자세한 로그 쿼리 목록이 포함됩니다. (로그 쿼리) 문제가 발생할 경우 한 교대에서 다음 교대로 전환할 수 있는 명확한 롤백 절차를 계획합니다.

이전 VM 인프라와 새로운 Kubernetes 기반 인프라에서 동일한 요청을 병렬로 처리하는 것은 독특한 과제를 제시했습니다. 리프트 앤 시프트 마이그레이션과 달리 (애플리케이션을 "있는 그대로" 새로운 인프라로 빠르게 이전합니다. 자세한 내용은 다음을 참조하세요. 여기에 - 대략. 번역), "기존" VM 및 Kubernetes에 대한 병렬 작업을 수행하려면 모니터링 도구가 두 환경 모두와 호환되고 메트릭을 하나의 보기로 결합할 수 있어야 합니다. 전환 기간 동안 일관된 관찰 가능성을 달성하려면 동일한 대시보드와 로그 쿼리를 사용하는 것이 중요합니다.

4. 트래픽을 새 클러스터로 전환

GitLab.com의 경우 서버의 일부는 다음 전용입니다. 카나리아 단계. Canary Park는 내부 프로젝트를 수행하며 다음과 같은 작업도 수행할 수 있습니다. 사용자가 활성화. 그러나 이는 기본적으로 인프라 및 애플리케이션에 대한 변경 사항을 테스트하도록 설계되었습니다. 첫 번째 마이그레이션된 서비스는 제한된 양의 내부 트래픽을 허용하는 것으로 시작되었으며 모든 트래픽을 클러스터로 보내기 전에 SLO가 충족되는지 확인하기 위해 계속 이 방법을 사용합니다.

마이그레이션의 경우 내부 프로젝트에 대한 요청이 먼저 Kubernetes로 전송된 다음 HAProxy를 통해 백엔드에 대한 가중치를 변경하여 나머지 트래픽을 점진적으로 클러스터로 전환한다는 의미입니다. VM에서 Kubernetes로 마이그레이션하는 동안 기존 인프라와 새 인프라 간에 트래픽을 쉽게 리디렉션하고 이에 따라 마이그레이션 후 처음 며칠 동안 기존 인프라를 롤백할 수 있도록 준비하는 것이 매우 유익하다는 것이 분명해졌습니다.

5. 포드의 예약 용량 및 용도

거의 즉시 다음과 같은 문제가 확인되었습니다. 레지스트리 서비스용 포드는 빠르게 시작되었지만 Sidekiq용 포드 시작은 시간이 오래 걸렸습니다. XNUMX분. 작업을 빠르게 처리하고 빠르게 확장해야 하는 작업자를 위해 워크로드를 Kubernetes로 마이그레이션하기 시작했을 때 Sidekiq 포드의 시작 시간이 길어 문제가 되었습니다.

이 사례에서 얻은 교훈은 Kubernetes의 HPA(Horizontal Pod Autoscaler)가 트래픽 증가를 잘 처리하는 반면, 워크로드의 특성을 고려하고 (특히 수요가 고르지 않게 분산된 경우) 포드에 여유 용량을 할당하는 것이 중요하다는 것입니다. 우리의 경우 갑작스러운 작업 급증으로 인해 급격한 확장이 이루어졌고, 이로 인해 노드 풀을 확장할 시간을 갖기도 전에 CPU 리소스가 포화되었습니다.

클러스터에서 최대한 많은 것을 짜내고 싶은 유혹은 항상 있습니다. 그러나 처음에는 성능 문제가 발생했기 때문에 이제 넉넉한 포드 예산으로 시작하고 나중에 이를 줄이면서 SLO를 면밀히 관찰하고 있습니다. Sidekiq 서비스용 포드 실행 속도가 크게 빨라졌으며 이제 평균 약 40초가 소요됩니다. 포드 실행 시간 단축에서 공식 GitLab Helm 차트를 사용하여 GitLab.com과 자체 관리 설치 사용자 모두를 확보했습니다.

결론

각 서비스를 마이그레이션한 후 우리는 프로덕션에서 Kubernetes를 사용하여 얻을 수 있는 이점, 즉 더 빠르고 안전한 애플리케이션 배포, 확장, 더 효율적인 리소스 할당에 만족했습니다. 또한 마이그레이션의 장점은 GitLab.com 서비스 그 이상입니다. 공식 Helm 차트의 모든 개선은 사용자에게 이익이 됩니다.

Kubernetes 마이그레이션 모험 이야기를 재미있게 즐기셨기를 바랍니다. 우리는 모든 새로운 서비스를 계속해서 클러스터로 마이그레이션합니다. 추가 정보는 다음 간행물에서 확인할 수 있습니다.

• «Kubernetes로 마이그레이션하는 이유는 무엇입니까?";
• «Kubernetes의 GitLab.com";
• GitLab.com을 Kubernetes로 마이그레이션하는 Epic.

번역가의 추신

블로그에서도 읽어보세요.

• «프로덕션 환경에서 Kubernetes를 사용한 3년: 우리가 이해한 내용은 다음과 같습니다.";
• «Kubernetes를 사용할 때 흔히 저지르는 10가지 실수";
• «프로덕션 분야의 Kubernetes 성공 사례. 3부: GitHub";
• «Tinder가 Kubernetes로 전환".

출처 : habr.com