컨테이너 생태계에서 Docker runtime이 왜 하나로 통합되지 않고, 이미지별로 다른 runtime이 필요한지에 대해 의문이 들었습니다. 이를 이해하기 위해 OCI와 CRI의 개념을 중심으로 컨테이너 런타임의 역할과 구조를 정리해 보았습니다.
주로 흔들리는 도커(Docker)의 위상 - OCI와 CRI 중심으로 재편되는 컨테이너 생태계 를 중심으로 정리했습니다. OCI와 CRI의 개념을 중심으로 해당 내용을 풀어가려고 합니다.

세줄 요약

• OCI는 컨테이너 런타임 표준화의 출발점입니다. OCI 가 모든 통일을 하진 않았기에 다양한 컨테이너 런타임이 생성됐습니다. CRI는 쿠버네티스가 다양한 런타임과 통신하도록 설계된 인터페이스입니다.

핵심 키워드

• 컨테이너 레벨 분리
• OCI (=Open Container Initiative)
  • docker 등의 포맷과 런타임에 대한 약속입니다.
  • runC : 도커에서 컨테이너 실행용 라이브러리로 시작. low level 이라 high 레벨 에서 이미지 관련 API 와 같이 이용됩니다.
• CRI (=Container Runtime interface)
  • 쿠버네티스의 컨테이너 런타임을 만든다. 컨테이너 런타임의 추상화 계층입니다.
  • CRI-O

OCI

컨테이너 표준화를 위한 OCI의 등장

도커가 사실상 컨테이너 표준 역할을 해왔지만, 다른 회사들은 자체 규격을 통해 표준화를 시도할 여지가 있었습니다. 이를 해결하기 위해 2015년 6월, 도커를 비롯한 주요 플랫폼 벤더들(AWS, 구글, 마이크로소프트 등)은 컨테이너 포맷과 런타임에 대한 개방형 업계 표준을 정의하고자 OCI(Open Container Initiative)를 구성하였습니다.

컨테이너 실행 과정

컨테이너 실행 과정은 크게 세 단계로 이루어집니다:

1. 이미지 다운로드
2. 이미지를 번들로 압축 해제
3. 번들에서 컨테이너 실행 이 중 OCI는 컨테이너 실행(3번) 단계에 초점을 맞추어 표준화했으며, 나머지 두 단계는 고수준 런타임이 담당합니다.

고수준과 저수준 컨테이너 런타임의 역할

정리하자면,

• 고수준 컨테이너 런타임: 컨테이너 이미지의 다운로드, 관리, 압축 해제 등을 수행합니다. (containerd, CRI-O 등)
• 저수준 컨테이너 런타임: 컨테이너 실행을 담당하며, namespace와 cgroup을 설정해 프로세스를 격리 및 제어합니다. (runc)

저수준 컨테이너 런타임

통일된 저수준 컨테이너 런타임에 대해 알아보겠습니다. 저수준 런타임은 컨테이너의 핵심인 namespace와 cgroup을 활용합니다.

• namespace: 가상화된 자원 격리를 제공하여, 각 컨테이너가 독립된 파일 시스템, 네트워크 등을 가지도록 합니다. 예를 들어, 하나의 컨테이너가 'eth0'이라는 네트워크 인터페이스를 사용할 때 다른 컨테이너는 동일한 네트워크 인터페이스를 보지 못하도록 격리합니다.
• cgroup: CPU, 메모리 등 자원을 제한하거나 할당하여 각 컨테이너가 시스템 자원을 효율적으로 사용하도록 합니다. 예를 들어,하나의 컨테이너가 과도한 메모리를 사용할 경우 cgroup을 통해 이를 제한하여 다른 컨테이너와 시스템 전체의 안정성을 유지합니다.

OCI의 런타임 사양(runtime-spec)을 구현한 대표적인 도구는 runC로, 대부분의 컨테이너 플랫폼에서 사용됩니다.

OCI 의 한계

모든 컨테이너 표준화를 한것은 아니기때문에 다양한 컨테이너 런타임이 생성됐습니다.

CRI

= 쿠버네티스의 컨테이너 런타임 인터페이스

• 2016년 12월, 쿠버네티스(Kubernetes)는 다양한 컨테이너 런타임과의 호환성을 높이고 특정 런타임에 종속되는 문제를 해결하기 위해 CRI(Container Runtime Interface)를 도입했습니다. 이는 쿠버네티스가 컨테이너 런타임과 상호작용하는 방식을 표준화한 인터페이스로, 유연성과 확장성을 제공합니다.

CRI의 핵심 개념

CRI는 쿠버네티스가 컨테이너 런타임과 상호작용할 때 사용하는 추상화 계층입니다. 이를 통해:

• 컨테이너 런타임에 대한 의존성을 제거하고,
• 개발자가 필요에 따라 새로운 런타임을 추가하거나 직접 구축할 수 있도록 합니다. 이러한 표준화를 통해 쿠버네티스는 특정 런타임(Docker 등)에 국한되지 않고 다양한 런타임(containerd, CRI-O 등)과 호환성을 유지할 수 있습니다.

대표적인 CRI 기반 컨테이너 런타임

1. containerd

Docker에서 분리된 경량화된 컨테이너 런타임으로, 현재 쿠버네티스의 기본 런타임으로 널리 사용됩니다. 컨테이너 실행, 네트워크 설정, 볼륨 관리 등 고수준 런타임 기능을 지원합니다.

2. CRI-O

CRI-O(Container Runtime Interface OpenContainer Initiative)는 CRI의 구현을 위해 개발된 경량화된 런타임입니다. Docker 없이도 컨테이너 실행을 지원하며, 주로 레드햇, SUSE, IBM 등 다양한 벤더가 오픈소스로 개발에 참여했습니다.

정리하자면, CRI-O는 CRI와 OCI의 연결 고리 역할을 하며, Docker 의존성을 제거하고 가볍고 효율적인 런타임 환경을 제공합니다. 주로 레드햇, SUSE, IBM 등의 기업이 지원하며, 최소한의 기능으로 구성되어 높은 확장성을 제공합니다.

주요 특징:

• 고수준 런타임 생략: 최소한의 기능만 구현하여 CRI와 OCI를 연결합니다.
• 도커 의존성 제거: 컨테이너 실행에는 도커가 필요 없지만, 컨테이너 이미지를 생성하거나 빌드할 때는 도커와 같은 추가 도구를 사용할 수 있습니다.
• 효율적인 리소스 사용과 가벼운 실행 환경을 제공합니다.

결론

결론적으로는 OCI는 컨테이너 런타임 표준화의 출발점이었고, OCI 가 모든 통일을 하진 않았기에 다양한 컨테이너 런타임이 생성됐습니다. CRI는 쿠버네티스가 다양한 런타임과 통신하도록 설계된 인터페이스입니다. CRI에 대한 설명을 통해 상위레벨에서 다양한 컨테이너 런타임을 쿠버네티스에서 이용하고 있다라 설명하고자 했습니다.

참고문헌

https://www.samsungsds.com/kr/insights/docker.html

1. 스케줄러(Scheduler)는 "무엇을 처리할지"를 결정합니다. 특정 요청이 완료되었는지, 새로운 요청이 들어왔는지를 확인하며, 이러한 요청을 처리하기 위해 KV 캐시에 필요한 메모리를 할당합니다. 본질적으로 스케줄러는 각 model executor 가 배칭 단계에서 수행해야 할 작업을 결정합니다.

   => 스파크드라이버랑 사실상 유사해.

2. 모델 실행기(Model Executor)는 스케줄링된 작업을 가져와 GPU 워커에 전달하는 역할을 합니다. vLLM 내부에서는 텐서 병렬 처리(tensor parallelism)를 지원하며, 모델을 여러 GPU에 분산 처리합니다. VM 내부에는 복잡한 레이어가 있어 입력 데이터를 준비하고 이를 각 워커에 브로드캐스트하는 작업을 처리합니다. 이 작업은 CPU에서 수행됩니다.

   => 스파크 익스큐터인데 cpu 로 돼있으니 , gpu 로 통신하는거지. 이거는 사실상, (스케줄러--> cpu ---> gpu ) 이렇게 되고, gpu 단위를 워커라 부르는 것.

   여기 사이에 워커도 있고 러너도 있고 복잡한 레이어가 있는데 이 작업이 cpu 에서 수행된다.

3. 마지막으로 모델이 실행된 이후에는 출력 처리(Processing Outputs)를 수행해야 합니다. 이 단계에서는 API 서버로 스트리밍하거나 중지 시퀀스를 감지하고, 완료된 항목을 배치에서 제거하는 작업 등을 처리합니다. 이 역시 CPU에서 실행되며, 이를 통해 배칭의 효율성을 극대화하는 데 필요한 메타데이터와 상태를 관리합니다.

요약하자면, vLLM의 구조는 간단히 보면 이렇게 세 단계로 이루어져 있지만, 실제로는 더 많은 복잡성을 내포하고 있습니다. vLLM 내부에서 모델을 실제로 실행하는 부분은 이 구조의 일부에 불과하며, 상위 수준의 대부분의 코드는 메모리 관리와 작업을 처리하기 위해 필요한 데이터를 전달하는 데 초점이 맞춰져 있습니다. 이를 통해 자동 회귀(autoaggressive) 생성의 높은 처리량을 달성합니다.

ref:

• https://www.youtube.com/watch?v=vJA1BGkAdNo&t=782s
• https://github.com/vllm-project/vllm

서비스 API 를 생성한 개발자 중에, 부하테스트를 하고자하는 분들을 위해, 해당 글을 작성하였습니다. 해당 페이지를 읽고 나시면, 성능테스트의 개념, 성능테스트 도구의 종류에 대해 이해하실 수 있습니다.

성능테스트의 개념

• 다중사용자 지원 능력을 평가하는데 흔히 세 가지 유형의 성능 테스트(성능, 부하, 스트레스)가 수행됩니다. 성공적인 성능 테스트는 데이터베이스, 네트워크, 소프트웨어, 하드웨어 등과 관련 될 수있는 대부분의 성능 문제를 예측해야 합니다.

성능테스트의 종류들

자료마다 다른 정의. 약간 다른 뉘앙스. 다른 접근.

best common to Graph

다양한 정의의 성능테스트

성능 테스트 유형에 대한 정의를 정확히 이해해 보고자, 여러 자료들을 비교해가며 하나씩 짚어서 읽어가다 보면, 예상과 달리 그 정의하고 있는 용어와 매핑되는 내용들이 조금씩 다른 것을 보게 됩니다. 예를 들어, 성능 테스트 유형에 대해서도 아래의 경우와 같이 ‘Baseline Testing’이라는 용어를 시작으로, 그 ‘부하량’과 ‘기간’ 등의 정도에 따라 성능 테스트 유형을 정의하는 경우도 있습니다.

성능 테스트 유형’에 대한 기본적인 이해를 가질 수 있도록, 일반적으로 성능 테스트에는 어떠한 종류들이 있는지, 그리고 각각은 대략적으로 어떤 차이점을 가지고 성능 업무에 적용되고 있는지에 대해 몇가지 자료들을 중심으로 살펴봄으로써, 성능테스트가 수행되는 다양한 형태들에 대한 기본적인 이해를 돕고자 합니다.

첫번째로 살펴볼 자료는, 성능 테스트 유형에 대해 사용자의 부하발생 패턴별로 시각화하여 차이점을 비교하고 있는 DCube’s Practices 자료입니다.

DCube’s Practice

• Web Performance Testing — DCube’s Practices https://medium.com/singapore-gds/web-performance-testing-dcubes-practices-fbbc20606000

그래프의 Y축은 가상사용자(Virtual Users), X축은 지속 시간(Test Time)을 각각 나타내고 있으며, 사용자의 증가, 유지, 감소 등 부하패턴 변화에 따라 각각의 테스트 유형을 구분지어 비교하고 있습니다. 참고로, 성능 테스트 Tool에서는 이러한 그래프와 유사하게 Workload를 설계하여 사용하고 있습니다. 예를 들어, 500명의 가상사용자(Virtual Users)를 이용한다면, 5분간 500명 증가(Ramp Up), 10분간 부하지속(Steady State), 1분간 부하 감소(Ramp Down) 등과 같은 형태로 설계하여 실제 부하를 발생시키고 있습니다.

1. Load Test (most common out of the five)= 부하테스트

• It verifies the system performance under the predetermined peak load, and this peak load is typically simulated and sustained for an hour. This test ensures the system can handle peak hour traffic at an acceptable performanc

사전에 결정된 Peak시점의 부하 상황에서 시스템의 성능을 검증하는 것으로, Peak Load는 일반적으로 1시간동안 유지됩니다.
 이 테스트는 적정한 성능으로 Peak Hour Traffic을 감당할 수 있는지 확인합니다.

2. Stress Test= 스트레스 테스트

• A verification on the system performance during extremely high load which is way above the peak load (a common practice is to use twice the peak load). It checks if the system will crash or remain usable and whether it recovers gracefully when the load goes back to normal.

Peak Load보다 훨씬 높은 부하 상황에서 시스템의 성능을 검증합니다.(일반적으로는 Peak Load의 2배를 사용합니다.) 

이러한 상황에서 시스템이 장애가 발생하는지 또는 사용 가능한 상태로 유지되는지, 
그리고 부하가 정상 수준으로 돌아갈 때 우아하게(gracefully) 복구되는지 체크합니다.

3. Endurance Test=내구성테스트

• A prolonged test to verify system stability over periods of 8 hours or more in order to sniff out issues like memory leakage that surface over longer time.

장기간에 걸ㅁ쳐 나타나는 메모리 누수와 같은 이슈들을 감지하기 위해, 8시간 이상의 기간에 걸쳐 시스템의 안정성을 확인하는 장기적인 테스트입니다.

4. Spike Test=스파이크 테스트

• Spike Test simulates the unique scenario of sudden high usage of the system. This is relevant for situations like a popular product launch (e.g. iPhone) or big sales (e.g. Singles’ Day). The script is configured to synchronize multiple threads to perform a step simultaneously.

시스템의 갑작스러운 사용량 급증에 대한 독특한 시나리오에 대해 시뮬레이션합니다. 
이것은 인기있는 제품 출시(e.g. iPhone) 또는 Big Sales(e.g. Singles’ Day)와 같은 상황과 관련이 있습니다.

5. Breakpoint Test =브레이크 포인트 테스트

• This test determines the point of system failure by gradually increasing the number of simulated concurrent users. After the test, a graph can be plotted to observe the point the system becomes unusable, which is the breakpoint of the system.

동시단말 사용자(concurrent users)의 수를 점진적으로 증가시켜서, 시스템의 장애 지점을 결정합니다.
 테스트 이후, 시스템을 사용할 수 없게 되는 지점,
 즉 시스템의 중단점(the breakpoint of the system)을 관찰하기 위해 그래프를 그릴 수 있습니다.

정리해 보면, DCube’s Practices에서 단순하게 구분짓고 있는 다섯가지 성능테스트 유형은 다음과 같이 요약할 수 있습니다.

• ‘적정 부하’(=Peak 시점의 부하)를 유지하는 것을 Load Testing
• ‘적정 부하의 2배’를 유지하는 것을 Stress Testing
• ‘장시간 부하’를 유지하는 것을 Endurance Testing
• ‘순간적인 대량 부하’를 발생하는 것을 Spike Testing
• ‘부하를 점차 증가’시켜 임계점을 확인하는 것을 Breakpoint Testing

netsolutions's performance-testing

여기서는, Stress Testing의 정의가 ‘적정 부하의 2배’ 등의 예시로 단순화하여 설명되었지만, 원래의 의미는 좀 더 넓은 개념으로 사용되고 있습니다. 예를 들어, 아래 그림에서 부하 유형의 그래프들 중 사선으로 표시한 부분을 보면, Stress Testing에 대한 설명이 ‘Find the Performance Limits of the System’으로 되어 있어서, 앞서 언급된 Breakpoint Testing과 비슷한 의미로 사용되기도 합니다. 좀더 자세한 설명은 두번째 예시에서 참조하시기 바랍니다.

출처 : https://netsolutions.com/insights/performance-testing/

Soak Testing은 오랜 시간동안 대량 부하(huge volume of load) 상황에서, 애플리케이션의 성능을 측정하는데 사용되는 비기능 테스트의 한 유형입니다. 이 유형의 테스트에서 기본적으로 모니터링 되는 것은 시스템의 애플리케이션에 의한 메모리의 사용율입니다.

Why do Soak Testing?

시스템이 2시간 동안 사용될 때는 정상적으로 동작할 수 있지만, 동일한 시스템을 10시간 이상 사용하면 장애가 발생하거나 비정상적인 상황이 발생할 수 있습니다. 이러한 상황을 예측하기 위해 Soak Testing이 수행됩니다.

When to do Soak Testing?

빌드가 고객에게 배포되기 전에, 즉 특정 플랫폼에서 애플리케이션이 출시되기 전에 일련의 Load Tests가 수행된 이후, Soak Tesitng이 수행됩니다. 메모리 누수/ 메모리 손상 등과 같은 이슈가 발견되면 즉시 보고해야 합니다.

Source: guru99.com

Software Testing Class's performance-testing

Software Testing Class에서는 성능테스트(Performance Testing)의 주요 유형을 6가지로 정의하고 있습니다. 위에서 언급되었던 ‘Breakpoint Testing’이 빠지고, 여기서는 ‘Volume Testing’과 ‘Scalability Testing’이 추가되어 있습니다. 참고자료로 남깁니다.

https://www.softwaretestingclass.com/what-is-performance-testing/

1. Load Testing

Load Testing은 부하가 임계치(Threshold Value)에 도달할 때까지 시스템의 부하를 지속적으로 증가시키면서 시스템을 확인하는, Performance Testing의 한 유형입니다. 여기서 부하를 증가시킨다는 것은, 동시단말사용자(concurrent users)와 트랜잭션을 증가시키면서 테스트 중인 애플리케이션의 동작을 확인하는 것을 의미합니다. ‘Endurance testing’ 또는 ‘Volume testing’이라고 불리기도 합니다.

Load Testing의 주요 목적은 과부하 상태(under heavy load)에서 시스템이 잘 작동될 때, 응답시간과 애플리케이션의 지구력(staying power)을 모니터링하는 것입니다. Load Testing과 아래에 기술된 테스트들은 모두 비기능 테스트(NFT/ Non Functional Testing)에 속하며, 소프트웨어 애플리케이션의 비기능 요구사항을 테스트하기 위해 설계되었습니다.

Load Testing은 테스트중인 애플리케이션이 견딜 수 있는 부하의 양을 확인하기 위해 수행됩니다. ‘성공적으로 수행된 Load Testing’은 지정된 테스트 케이스가 할당된 시간동안 오류없이 수행된 경우에만 가능합니다.

2. Stress Testing

Stress Testing은 CPU, Memory, Disk Space 등과 같은 하드웨어 자원이 충분하지 않을 때, 소프트웨어의 안정성을 확인하는 Performance Testing의 한 유형입니다. Stress Testing의 기본 개념은 시스템의 오류를 확인하고, 어떻게 시스템이 정상적으로 복구되는지를 살펴보는 것입니다.

“To determine or validate an application’s behavior when it is pushed beyond normal or peak load conditions.”

Stress Testing은 시스템 하드웨어 자원에서 처리할 수 없는 많은 수의 동시단말사용자(concurrent users)/프로세스로 소프트웨어에 부하를 주는 Negative Testing입니다. 이 Testing은 피로시험(Fatigue testing)으로도 알려져 있습니다.

Stress Testing의 기본 개념은 시스템의 장애를 확인하고 시스템이 어떻게 정상적으로 복구되는지를 주시하는 것입니다. 이러한 품질 특성을 회복성(recoverability)이라고 합니다.

3. Spike testing

Spike testing은 Stress Testing의 Subset입니다. 테스트 대상 시스템에 대해, 상용 운영환경에서 예상되는 부하 이상의 Workload를 짧은 기간동안 반복적으로 증가시킬 때 나타나는 성능 특성을 검증하기 위해 수행합니다.

4. Endurance testing

Endurance testing은 시스템의 동작을 확인하기 위해, 장기간에 걸쳐 예상되는 부하량에 기반하여 시스템을 테스트 하는 것을 포함합니다. 예를 들어, 시스템이 3시간동안 작업을 수행하도록 설계되었다면, 동일 시스템이 6시간동안 지속되어도 시스템이 지구력을 유지하는지를 확인하는 것입니다. 가장 일반적인 테스트 케이스는 메모리 누수, 시스템 장애 또는 무작위적인 동작(random behavior)과 같은 시스템의 동작을 확인하기 위해 수행됩니다. 때때로, Endurance testing은 ‘Soak testing’이라고도 합니다.

5. Scalability Testing

Scalability Testing은 사용자 부하, 트랜잭션 수, 데이터 볼륨 등과 같은 비기능 측면에서 확장할 수 있는 역량을 판단하기 위한 소프트웨어 애플리케이션 테스트입니다. 이 테스트의 주요 목적은 더이상 확장(Scaling)하지 못하도록 막는 ‘시스템의 Peak’가 무엇인지 확인하는 것입니다.

6. Volume testing

Volume testing은 처리해야 할 많은 양의 데이터를 가진 애플리케이션의 효율성을 확인하기 위한 테스트입니다. 이 테스트의 주요 목표는 다양한 Database Volumes 하에서 애플리케이션의 성능을 모니터링 하는 것입니다.

성능테스트 기본 동작방식

• ngrinder 를 통해, 기본적으로 성능테스트가 어떻게 동작하는지 확인해봅시다.

https://github.com/naver/ngrinder/wiki/Architecture#general-architecture

웹 애플리케이션을 서비스하기 전에 서버가 얼마나 많은 사용자를 수용할 수 있는지 요청을 전송해봄으로써 서버의 성능을 측정해볼 수 있다.

nGrinder는 Controller와 Agent로 이루어져 있다.

✔️ Controller
  ├── 성능 측정을 위한 웹 인터페이스 제공
  ├── 테스트 프로세스 조정
  ├── 테스트 통계를 수집하고 표시
  └── 스크립트 수정 기능 제공

✔️ Agent
  ├── 에이전트 모드에서 실행할 때 대상 시스템에 부하를 주는 프로세스 및 스레드를 실행
  └── 모니터 모드에서 실행 시 대상 시스템 성능(CPU/메모리) 모니터링

✔️ Agent
  ├── 성능 측정에 사용할 Agent 개수
  └── Agent를 여러개로 구성하고 싶은 경우 클라우드 서비스 이용하기
      └── 여러개의 인스턴스를 생성해서 Agent 설치하기

✔️ Vuser per agent
  ├── Agent 당 설정할 가상 사용자 수
  └── 동시에 요청을 날리는 사용자 수를 의미

✔️ Process / Thread
  └── 하나의 Agent에서 생성할 프로세스와 스레드 개수

✔️ Script
  ├── 성능 측정 시 각 Agent에서 실행할 스크립트
  └── 앞서 API 호출 과정에서 생성한 Script를 연결(.groovy)하거나 Github에서 가져올 수 있다.

✔️ Duration (HH:MM:SS)
   └── 성능 측정 수행 시간

✔️ Run Count
   └── 스레드 당 테스트 코드를 수행하는 횟수

✔️ Enable Ramp-Up
  └── 성능 측정 과정에서 가상 사용자를 점진적으로 늘리도록 활성화

✔️ Initial Count
  └── 처음 시작 시 가상 사용자 수

✔️ Initial Sleep Time
  └── 테스트 시작 시간

✔️ Incremental Step
  └── Process 또는 Thread를 증가시키는 개수

✔️  Interval
  └── Process 또는 Thread를 증가시키는 시간 간격

성능 테스트 도구 소개

k6

k6 소개

• Grafana k6는 오픈소스 부하 테스팅 툴이다. 성능 테스트를 쉽게 수행할 수 있고, 엔지니어링 팀의 생산성을 향상 시킨다. k6를 이용하면 신뢰성 있고, 시스템의 성능테스트를 수행할 수 있다. 이를 통해 성능을 측정하고, 문제를 쉽게 해결할 수 있는 초석이됩니다.
  • https://k6.io/
  • https://github.com/grafana/k6

설치 방식

• https://k6.io/docs/get-started/installation

k6의 특징

• 현존하는 도큐먼트 중에 가장 설명이 잘 되어있습니다.

• cicd 를 공식 지원합니다.

• Js 를 이용합니다.

• 평균 output 으로 결과가 나오지만, 그라파나를 활용해 대시보드를 구성가능합니다.

• threadsholds 라는 임계값이라는 개념이 있어, 테스트 지표에 대해 정의하는 평균치에 대한 통과, 실패 기준이 있습니다.

  • 해당 부분에 대한 예시입니다. 공식페이지에서 더 많은 옵션을 확인할 수 있습니다.

  •   thresholds: {
        // 90% of requests must finish within 400ms, 95% within 800, and 99.9% within 2s.
        http_req_duration: ['p(90) < 400', 'p(95) < 800', 'p(99.9) < 2000'],
        // During the whole test execution, the error rate must be lower than 1%.
        http_req_failed: ['rate<0.01'],
      },

Locust

Locust 소개

• 파이썬 기반 부하테스트 툴입니다.
  • https://github.com/locustio/locust
  • https://docs.locust.io/en/stable/installation.html

Locust의 특징

• constant_throughput : tps 를 유지하게 노력합니다.
• python 기반으로 보다 편리합니다.
• 또한, pip install locust 로 가능한 파이썬 라이브러리로, ncc 및 로컬 이식에 용이합니다.
• ui 가 존재합니다. 에러 페이지, response time graph , 리퀘스트 보낸것을 확인 가능한 기본 대시보드를 제공합니다. 가상 유저와, spawn rate를 처음에 작성하라고 하는데, 초심자 입장에서 이해하기 어렵습니다. (다양한 성능테스트용으로는 좀 더 좋을지..)
• 도큐먼트 설명이 불친절합니다. 처음부터 끝까지 정독해야만, constant_throughput : tps 를 유지하게 노력 함. 이런 옵션들을 획득할 수 있습니다.
• 실패가 request 단건으로 존재합니다.

Apache JMeter

Apache JMeter 소개

성능 및 로드 테스트 애플리케이션을 측정하도록 설계된 오픈 소스 Java 애플리케이션입니다.

Apache JMeter의 특징

• 문서수가 제일 많고, 다수의 플러그인을 가지고 있는데, 젠킨스와 비슷한 느낌이지 않나 싶습니다. 자바 공화국에서는 많이 쓰이고 있어보이는데요, 진입장벽이 높습니다. (그와 동시에 많은 블로그, 사용자문서를 가지고 있는 것이 장점. )
• 개구린 gui 를 가지고 있습니다. (물론 http 테스트는 가능합니다.)
• vscode처럼 하나하나 다 공부해가면서 플러그인을 설치해야합니다.
• 녹화 기능이 있어, 스크립트를 작성하지 않아도 녹화 가능합니다.
• junit - jmeter 연동이 가능합니다.
• 상위 에러 사유, response 사유, 바이트 처리량, 연결 시간, 지연 시간 모두 보여줍니다 . https://jmeter.apache.org/usermanual/generating-dashboard.html

Apache JMeter를 사용한 간단한 부하 테스트 예제

1. https://jmeter-plugins.org/?search=jpgc-casutg에 접속하여 신버전을 다운받습니다.
2. 압축 해제 후 /apache-jmeter-5.4.3/lib 에 복사합니다.
3. Jmeter를 재실행하면 Stepping Thread Group이 추가된 것을 확인할 수 있습니다.

설정 값은 다음과 같습니다.

• [ this group will start ] 해당 그룹에서 최대 생성되는 Thread 개수
• [ Next, add ] 추가되는 Thread의 수 몇 개씩 더해질 것인가
• [ threads every ] Thread 추가되는 시간 간격(s)
• [ using ramp-up ] Thread가 추가되는데 걸리는 시간(s)
• [ Then hold load for ] 최대 쓰레드가 유지되는 시간(s)
• [ Finally, stop ] Thread가 몇 개씩 줄어들 것인가
• [ threads every ] Thread가 줄어드는데 걸리는 시간(s)

NGrinder

NGrinder 소개

• NHN의 1억 명 이상의 사용자를 보유한 대규모 시스템을 테스트하는 데 사용되는 검증된 솔루션입니다.
  • https://github.com/naver/ngrinder
  • 쉽게 시작하기 위해 참고 블로그 : https://1-7171771.tistory.com/155, https://velog.io/@hellonayeon/nGrinder-install-and-how-to-use-memo

NGrinder의 특징

• python, groovy, jar 등을 제공합니다.
• 캐시효과 제거하기 : 여러 파라미터를 활용
• input : agent 개수, vuser, 테스트 시간
• 허용가능한 tps 를 output 으로 정의해줍니다.

참고 문헌

• ngrinder 시스템 아키텍처 blog : https://velog.io/@hellonayeon/nGrinder-install-and-how-to-use-memo
• ngrinder 시스템 아키텍처 : https://github.com/naver/ngrinder/wiki/Architecture#general-architecture
• 부하테스트 개념 : https://loosie.tistory.com/821#%EB%B6%80%ED%95%98_%ED%85%8C%EC%8A%A4%ED%8A%B8_(Load_Test)
• Web Performance Testing — DCube’s Practices https://medium.com/singapore-gds/web-performance-testing-dcubes-practices-fbbc20606000
• https://engineering-skcc.github.io/performancetest/Performance-Testing-Terminologies/
• locust architecture : https://locust.dev/docs/architecture

벌써 2024년 4분기가 시작되었네요. 시간이 정말 빠르게 지나가는 것 같습니다. 올해를 돌아보면, 여러 가지 생각이 스쳐 지나가네요. 요약하자면, 업무만 열심히 하고 놀았습니다..

개발자로서의 삶과 개발 외의 삶을 구분지어 보자면,

개발자로서의 삶에서는 특히 지표의 중요성에 대해 많이 고민한 한 해였던 것 같아요. 오픈서치를 공부하고, SRE(사이트 신뢰성 엔지니어링)에 대한 고민도 깊었던 한 해였습니다. 최근 가장 흥미롭게 본 주제는 vLLM였고 쉽고 빠르게, 그리고 비용 효율적으로 LLM 서빙이 가능하다는 점이 굉장히 매력적이었어요.

개발 외의 삶으로는 최근에 치앙마이로 여행다녀왔어요! 치앙마이 여행에서 많은 아름다운 추억을 쌓았지만, 가장 잊을 수 없는 순간은 홍수를 겪은 일이었습니다. 도로에 물이 가득 차서 택시 기사님도 두 번이나 운행을 포기하셨고, 겨우 공항에 도착했지만, 제 시간에 한국으로 돌아갈 수 있을지 불안했습니다. 하지만 이런 위기 속에서도 삶의 아름다움을 다시 한번 느꼈고, 인생을 더 열심히 살아가야겠다는 다짐을 하게 되었습니당...

직장인 개발자로 4년 차에 접어들면서, 자기 개발보다는 경제적인 부분에 대한 고민이 커진 것 같아요. 요즘은 아파트나 주식 같은 투자에 더 관심이 생기고, 더 나은 미래를 위해 무엇을 해야 할지 깊이 생각하게 됩니다..

근황과 관련된 주제를 쓰면서도 야무지게 열심히 논게 느껴지네요 희희 재밌었어용

글또 10기에 참여하게된 계기

오랜만에 글또 10기에 참여하게 되었어요.

참여하게된 계기는 최근에 개발외의 삶에 너무 집중하지 않았나 반성중이었고, "마지막" 글또라는 키워드는 글또에서 많이 배우고 얻어간 사람으로써 놓칠 수 없는 기회였던 것같습니다. 글쓰는 사람끼리의 커뮤니티도 너무 재밌기도 한건 덤..

이전에도 글또 8기까지 활동을 하면서 https://kils-log-of-develop.tistory.com/ 글을 작성했었었는데요, 놀랍게도 글또 활동을 쉬자마자 바로 글을 쓰지 않았네요. 네, 반성합니다. 새로운 마음으로 해보고자 블로그 도메인을 velog 로 변경했습니다.

글또는 저에게 많은 영감을 주는 모임입니다. 다양한 개발 관심사를 가진 사람들과의 소통을 통해 많은 것을 배웠었고, 블로그 글을 쓰는 것을 초월해, 더 명확한 사고 방식을 가지게 되고, 스스로의 지식을 정리하는 데 도움이 되었었는데요, 이번 10기에서는 더 많은 글을 쓰고 읽고 소통 하고고싶어요.!

주제로는 주로, 개발자로서 겪은 문제 해결 과정이나 새로 공부한 지식 공유, 프로젝트에서 얻은 인사이트를 공유하고자 합니다.

글또 10기 다짐

이번 글또에서의 목표는 기억하고싶은 것들은 글로 재구성하는것을 이번 글들의 목표로하려고 합니다. 기존에 쓰던 블로그에서 URL 변동도 하고, 글감 주제도 많이 바뀔 수 있을 것같네요. 오랜만이라,, 그리고 글또를 쉬던 1-2년 간의 라이프사이클의 변화때문일 수 도 있을 거같긴한데 , 다시 정진해보겠습니다..

핵심 kpi 는 다음과 같습니다.

1. 글또 제출일 전날 글 3개 제출 (글도 제출하고, 전날! 미리미리 준비하겠다)
2. 새로운 사람 2명 이상 알아가기

다른 개발자들과의 소통을 통해 새로운 시각을 얻고, 피드백을 통해 더 나은 글을 작성하는 경험이 벌써 기대되네요

이렇게 올해를 돌아보니, 많은 것들이 있었고, 앞으로도 더 많은 것들이 기다리고 있을 것 같아요. 다짐을 잊지 않고, 긍정적인 마음으로 한 걸음씩 나아가고 싶습니다! 아자아자!

#글또 #다짐글 #회고 #자기개발 #프로젝트 #2024년