리소스 사용

리소스 요청

우리의 모든 컨테이너에는 미리 정의된 리소스 요청 값이 포함되어 있습니다. 기본적으로 리소스 제한을 설정하지 않았습니다. 노드에 여유 메모리 용량이 없는 경우, 메모리 제한을 적용하는 한 가지 옵션은 더 많은 메모리(또는 노드)를 추가하는 것입니다. (Linux 커널의 메모리 부족 관리자가 중요한 Kube 프로세스를 종료할 수 있음을 고려해야 합니다.)

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

우리는 다음을 메트릭할 것입니다:

  • 유휴 부하 - 기본값이 이 값보다 작지 않아야 하지만, 유휴 프로세스는 유용하지 않으므로 일반적으로 이 값을 기준으로 기본값을 설정하지 않을 것입니다.

  • 최소 부하 - 가장 기본적이고 유용한 작업을 수행하는 데 필요한 값들입니다. 일반적으로 CPU에 대해서는 이 값이 기본값으로 사용되겠지만, 메모리 요청은 커널이 프로세스를 제거할 위험이 있으므로 이 값을 메모리의 기본값으로 사용할 것을 피할 것입니다.

  • 평균 부하 - 평균이라고 여겨지는 것은 설치에 따라 매우 의존적입니다. 우리의 기본값으로는 몇 가지 메트릭을 시도하여 합리적인 부하로 간주되는 몇 가지 메트릭을 사용합니다. (사용한 부하를 나열할 것입니다.) 서비스에 pod 오토스케일러가 있는 경우, 일반적으로 우리는 이 값을 기반으로 스케일링 대상 값을 설정하려고 할 것입니다. 그리고 또한 기본 메모리 요청입니다.

  • 스트레스 작업 - 서비스가 수행해야 할 가장 스트레스 받는 작업의 사용을 메트릭합니다. (부하에서는 반드시 발생하지 않음) 리소스 제한을 적용할 때에는 이보다 높거나 평균 부하 값 이상의 제한을 설정하려고 노력할 것입니다.

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

GitLab Shell

부하는 일부 동시성을 가지려는 목적으로 nohup git clone <프로젝트> <임의의 경로 이름>을 호출하는 bash 루프를 사용하여 테스트되었습니다. 향후 테스트에서는 다른 서비스에 대해 수행한 테스트 유형과 보다 일치하도록 지속적인 동시 부하를 포함하려고 할 것입니다.

  • 유휴 값
    • 0 작업, 2 pod
      • CPU: 0
      • 메모리: 5M
  • 최소 부하
    • 1 작업 (빈 클론 1개), 2 pod
      • CPU: 0
      • 메모리: 5M
  • 평균 부하
    • 5개 병렬 클론, 2 pod
      • CPU: 100m
      • 메모리: 5M
    • 20개 병렬 클론, 2 pod
      • CPU: 80m
      • 메모리: 6M
  • 스트레스 작업
    • Linux 커널을 SSH로 클론 (17MB/s)
      • CPU: 280m
      • 메모리: 17M
    • Linux 커널을 SSH로 푸시 (2MB/s)
      • CPU: 140m
      • 메모리: 13M
      • 업로드 연결 속도는 테스트 중에 아마도 영향을 미쳤을 것입니다
  • 고부하
    • 100개 병렬 클론, 4 pod
      • CPU: 110m
      • 메모리: 7M
  • 기본 요청
    • CPU: 0 (최소 부하에서)
    • 메모리: 6M (평균 부하에서)
    • 대상 CPU 평균: 100m (평균 부하 값에서)
  • 권장 제한
    • CPU: > 300m (스트레스 작업보다 큼)
    • 메모리: > 20M (스트레스 작업보다 큼)

gitlab.gitlab-shell.resources.limits.memory를 너무 낮게 설정하면 문제 해결 문서에서 어떤 문제가 발생할 수 있는지를 확인하십시오.

웹 서비스

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

Sidekiq

Sidekiq 리소스는 10k 사용자용 참조 아키텍처를 사용하여 테스트하는 중에 분석되었습니다. 자세한 내용은 Sidekiq 리소스 문서에서 찾을 수 있습니다.

KAS

사용자들의 필요성에 대해 더 많은 정보를 알기 전에, 우리는 우리의 사용자들이 다음과 같은 방식으로 KAS를 사용할 것으로 예상합니다.

  • 유휴 값
    • 0개의 에이전트가 연결되었고, 2 pod
      • CPU: 10m
      • 메모리: 55M
  • 최소 부하:
    • 1개의 에이전트가 연결되었고, 2 pod
      • CPU: 10m
      • 메모리: 55M
  • 평균 부하: 클러스터에 1개의 에이전트가 연결되어 있음.
    • 5개의 에이전트가 연결되었고, 2 pod
      • CPU: 10m
      • 메모리: 65M
  • 스트레스 작업:
    • 20개의 에이전트가 연결되었고, 2 pod
      • CPU: 30m
      • 메모리: 95M
  • 고부하:
    • 50개의 에이전트가 연결되었고, 2 pod
      • CPU: 40m
      • 메모리: 150M
  • 추가 고부하:
    • 200개의 에이전트가 연결되었고, 2 pod
      • CPU: 50m
      • 메모리: 315M

이 차트에 의해 설정된 KAS 리소스 기본값은 심지어 50개의 에이전트 시나리오를 처리하는 데 충분합니다. 우리가 추가 고부하로 간주하는 것에 도달하려면, 기본값을 조정하는 것을 고려해야 할 것입니다.

  • 기본값: 각각 다음과 같은 2개의 pod
    • CPU: 100m
    • 메모리: 100M

이러한 숫자가 어떻게 계산되었는지에 대한 자세한 내용은 이슈 토론을 참조하십시오.