리소스 사용

리소스 요청

우리의 모든 컨테이너에는 미리 정의된 리소스 요청 값이 포함되어 있습니다. 기본적으로 리소스 제한을 설정하지 않았습니다. 노드에 메모리 여유가 없는 경우 옵션 중 하나는 메모리 제한을 적용하는 것입니다. 그러나 메모리를 추가하는 것(또는 노드를 추가하는 것)이 더 좋을 것입니다. (쿠버네티스 노드 중 하나에서 메모리가 부족해지는 것은 피해야 합니다. 왜냐하면 리눅스 커널의 메모리부족 관리자가 중요한 Kube 프로세스들을 종료시키기 때문입니다)

우리의 기본 요청 값들을 설정하기 위해 애플리케이션을 실행하고 각 서비스에 대한 다양한 부하 수준을 생성하는 방법을 고안합니다. 우리는 서비스를 모니터링하고 우리가 최상의 기본값이라고 생각하는 것에 대한 결정을 내립니다.

우리는 다음을 측정할 것입니다:

  • 유휴 부하 - 기본으로 설정되지 않아야 하는 값들을 아래로 떨어뜨릴 수 없지만, 유휴 프로세스라는 것은 유용하지 않기 때문에 일반적으로 이 값을 기준으로 기본값을 설정하지 않을 것입니다.

  • 최소 부하 - 가장 기본적이고 유용한 작업을 수행하는 데 필요한 값들입니다. 일반적으로 CPU의 경우 이 값이 기본값으로 사용될 것이지만, 메모리 요청은 커널이 프로세스를 종료하는 위험이 있으므로 이 값은 메모리의 기본값으로 사용하지 않을 것입니다.

  • 평균 부하 - 평균이라고 생각되는 것은 설치에 따라 매우 의존적입니다. 우리의 기본값에서는 몇몇 합리적인 부하에 대한 몇 가지 측정을 시도할 것입니다. (사용하는 부하를 나열할 것입니다). 서비스에 파드 자동 스케일러가 있는 경우 일반적으로 이 값을 기준으로 스케일링 대상 값을 설정하려고 할 것입니다. 그리고 또한 기본 메모리 요청을 설정할 것입니다.

  • 스트레스 작업 - 서비스가 수행해야 하는 가장 스트레스 받는 작업의 사용을 측정합니다. (부하가 있는 경우 필요하지 않음). 리소스 제한을 적용할 때 이 값을 기준으로 한계를 설정하려고 합니다.

  • 높은 부하 - 서비스에 대한 스트레스 테스트를 시도하고, 해당 작업을 수행하는 데 필요한 리소스 사용을 측정하려고 합니다. 우리는 현재 이러한 값들을 기본값으로 사용하지는 않지만, 사용자는 일반적으로 평균 부하/스트레스 작업과 이 값 사이의 리소스 제한을 설정하고 싶어할 것입니다.

GitLab 셸

로드는 일정의 동시성을 갖기 위해 nohup git clone <프로젝트> <임의의-경로-이름>을 호출하는 bash 루프를 사용하여 테스트되었습니다. 향후 테스트에서는 지속적인 동시 부하를 포함하여 기타 서비스에 대해 수행한 테스트 유형과 더 잘 일치하도록 노력할 것입니다.

  • 유휴 값
    • 0 작업, 2 pods
      • cpu: 0
      • memory: 5M
  • 최소 부하
    • 1 작업 (빈 클론 한 개), 2 pods
      • cpu: 0
      • memory: 5M
  • 평균 부하
    • 5 동시 클론, 2 pods
      • cpu: 100m
      • memory: 5M
    • 20 동시 클론, 2 pods
      • cpu: 80m
      • memory: 6M
  • 스트레스 작업
    • 리눅스 커널을 SSH로 클론하기 (17MB/s)
      • cpu: 280m
      • memory: 17M
    • 리눅스 커널을 SSH로 푸시하기 (2MB/s)
      • cpu: 140m
      • memory: 13M
      • 업로드 연결 속도가 테스트 중에 영향을 미칠 가능성이 있었음
  • 높은 부하
    • 100 동시 클론, 4 pods
      • cpu: 110m
      • memory: 7M
  • 기본 요청
    • cpu: 0 (최소 부하에서)
    • memory: 6M (평균 부하에서)
    • 평균 CPU 대상값: 100m (평균 부하에서)
  • 권장 한도
    • cpu: > 300m (스트레스 작업 보다 크게)
    • memory: > 20M (스트레스 작업 보다 크게)

gitlab.gitlab-shell.resources.limits.memory가 너무 낮게 설정되었을 경우 발생할 수 있는 상황에 대한 자세한 내용은 문제 해결 문서를 확인하세요.

웹 서비스

웹 서비스 리소스는 10k 사용자 참조 아키텍처를 사용하여 테스트하는 동안 분석되었습니다. 자세한 내용은 웹 서비스 리소스 문서에서 확인할 수 있습니다.

Sidekiq

사이드키큐 리소스는 10k 사용자 참조 아키텍처를 사용하여 테스트하는 동안 분석되었습니다. 자세한 내용은 사이드키큐 리소스 문서에서 확인할 수 있습니다.

KAS

사용자들이 필요로 하는 정보를 더 알게 되기 전까지, 우리는 사용자들이 KAS를 다음과 같은 방식으로 사용할 것으로 예상합니다.

  • 유휴 값
    • 0개의 에이전트가 연결되었습니다, 2 pods
      • cpu: 10m
      • memory: 55M
  • 최소 부하:
    • 1개의 에이전트가 연결되었습니다, 2 pods
      • cpu: 10m
      • memory: 55M
  • 평균 부하: 클러스터에 1개의 에이전트가 연결됨.
    • 5개의 에이전트가 연결되었습니다, 2 pods
      • cpu: 10m
      • memory: 65M
  • 스트레스 작업:
    • 20개의 에이전트가 연결되었습니다, 2 pods
      • cpu: 30m
      • memory: 95M
  • 높은 부하:
    • 50개의 에이전트가 연결되었습니다, 2 pods
      • cpu: 40m
      • memory: 150M
  • 추가적인 높은 부하:
    • 200개의 에이전트가 연결되었습니다, 2 pods
      • cpu: 50m
      • memory: 315M

이 차트가 설정한 KAS 리소스 기본값은 50개의 에이전트 시나리오를 다루기에 충분합니다. 특히 추가적인 높은 부하에 도달할 계획이라면 기본값을 조정하는 것을 고려해야 할 것입니다.

  • 기본값: 각각에 2 pods를 가진
    • cpu: 100m
    • memory: 100M

이러한 숫자가 어떻게 계산되었는지에 대한 자세한 내용은 이슈 토론에서 확인하세요.