k6으로 새로운 AWS ARM CPU 테스트

최근AWS made the new ARM processors for Lambda functions generally available . 이러한 변화로 서버리스 기능은 이제 더 낮은 비용으로 더 나은 성능을 제공한다고 알려진 Graviton2를 사용합니다.

저는 API Gateway와 Lambda를 사용하여 AWS에서 샘플 API를 구축했고 두 개의 끝점을 작성했습니다. 하나는 CPU-intensive(Leibniz의 공식을 사용하여 Pi 계산), 다른 하나는 일반적인data transfer 끝점(임의의 바이트 수 반환)입니다. 내 실험에 대한 두 개의 매우 다른 종점.

내 실험 규모에 대한 한 가지 엄격한 제한은 내 개인 AWS 계정이 예약되지 않은 동시성을 50개 이하로 허용한다는 것이었습니다. 그러나 통찰력을 얻기 위해 큰 숫자가 필요하지는 않습니다.
.

테스트

.
x86_64(Intel) 및 arm64(Graviton2) 모두에 두 엔드포인트를 배포했습니다. 테스트는 거의 동일하고 램프 업 유형 테스트였습니다. CPU를 많이 사용하는 경우에는 라이프니츠 공식(정확히 50만 회)의 반복을 많이 사용했습니다. 데이터 전송은 100킬로바이트를 요청했습니다.
.
CPU 집약적 테스트:
.

// Parts omitted
​
export const options = {
    scenarios: {
        x86: {
            // Parts omitted
            env: {
                ARCH: 'x86',
                ITERATIONS: '500000'
            }

        },
        arm: {
            // Parts omitted
            env: {
                ARCH: 'arm',
                ITERATIONS: '500000'
            }
        }
    }
}
​
export default function () {
    // Parts omitted
    url.pathname = `/pi/${__ENV.ARCH}`;
    url.searchParams.append('iterations', ENV.ITERATIONS);
    // Parts omitted
}

.
그리고 데이터 전송 테스트:
.

// Parts omitted
​
export const options = {
    scenarios: {
        x86: {
            // Parts omitted
            env: {
                ARCH: 'x86',
                COUNT: '102400'
            }

        },
        arm: {
            // Parts omitted
            env: {
                ARCH: 'arm',
                COUNT: '102400'
            }
        }
    }
}
​
export default function () {
    // Parts omitted
    url.pathname = `/zerobytes/${__ENV.ARCH}`;
    url.searchParams.append('count', ENV.COUNT);
    // Parts omitted
}

.

결과(데이터 전송)

.
데이터 전송 끝점에 대한 테스트 결과는 내가 예상했던 것과 거의 일치했습니다. 엔드포인트가 실제로 많은 작업을 수행하도록 CPU를 밀어붙이지 않는다는 점을 보면 두 아키텍처 간에 약간의 차이가 있습니다.

그러나 한 가지 흥미로운 점은 응답 시간이 250ms에서 시작하여 100ms에서 안정화된다는 것입니다. 이는 Lambda cold start에 대해 일반적이며 Lambda 콜드 스타트는 ~100/200ms 범위 내에 있습니다. Lambda 함수를 처음 트리거할 때 AWS는 그 아래에 있는 인프라(아마도 컨테이너)를 가동해야 합니다. 인스턴스를 실행하면 모든 후속 요청에 훨씬 적은 시간이 소요됩니다.


.

결과(CPU 부하)

.
CPU를 많이 사용하는 엔드포인트의 경우 다시 콜드 스타트를 볼 수 있지만 일반 응답 시간이 훨씬 더 크기 때문에 그래프가 이전 예만큼 가파르지는 않습니다. 여기서 흥미로운 점은 x86이 새 칩보다 20% 더 빠르다는 것입니다. 이는 AWS가 주장하는 것과 정반대입니다.


.

결과

.
이 경험에서 배운 것은 AWS가 대담하게 arm이 20% 더 빠르고 20% 더 저렴하다고 주장하는 반면 내 실험 결과는 오히려 20% 더 느리고 20% 더 저렴하다는 것입니다. 이것은 사용하는 칩 명령에 따라 다를 수 있습니다. 라이프니츠 공식의 이 구현은 루프, 할당, 추가 및 기타 기본 수학 연산으로 구성됩니다. 그러나 Narakeet의 사람들과 같은 다른 사람들도 비슷한 결과를 보고 있는 것으로 나타났습니다.

그래도 나쁜 소식은 아닙니다. 비 CPU 워크로드는 여전히 속도 절충 없이 가격 혜택을 받습니다. 팔은 또한 더 적은 전력을 소모하므로 지구에 더 좋습니다.

실험에서 Lambda를 다루는 동안 이러한 결과는 EC2로 추정할 수 있습니다.

동시성(동시에 실행되는 람다 인스턴스 수)은 대략적으로 API에 대해 실행 중인 초당 요청 수에 응답 시간(초)을 곱한 것과 같습니다. 이것이 시간이 지남에 따라 더 높은 부하에서 어떻게 작동하는지 모니터링하는 것이 흥미로울 것입니다.