Go 기준 도구 만들기 이야기

이 글은 Applibot Advent Calendar 2021 13일째 되는 글이다.
전날은 @dears31 선생의 자유롭게 대답할 수 있는 질문을 댓글로 정리해 봤습니다. 기사였다.
개시하다
처음 뵙겠습니다.나는 응용 프로그램에서 서버 사이드 엔지니어로 일한다.
최근 평상시 업무에서 측량 서비스의 성능, 결과 총결산 기술로 선정된 재료라는 일이 조금씩 늘고 있다.
최근에 Elasticache Redis의 성능을 측정한 적이 있습니다.
최근 어떤 아우라3의 등장, TiDB와 스파너 등 분산DB 도입 사례의 증가, KeyDB가 관리 서비스로 제공되기 시작하는 등 앞으로도 다양한 중간부품의 기술 선정, 큰 버전의 업데이트 등을 통해 기존 기술을 대폭 교체할 기회가 늘어나지 않을까 한다.
신기술을 도입할 때 저는 비용 방면, 운용 방면, 성능 방면 등 여러 방면에서 신기술 도입을 탐구하고 싶습니다.
나는 성능을 보기 위해 문서를 읽을 뿐만 아니라 기준 도구를 사용하여 실제 측정하는 경우가 많다고 생각한다.
기준 도구는 각양각색이다. 리디스의 경우 공식 도구redis-benchmark가 있고memcached에 대응하는memtier_benchmark도 있다. HTTP계 기준 도구의 경우apache benchmark가 유명하다.
인터페이스는 도구에 따라 다르기 때문에 결과를 정리할 때 매우 번거롭거나 원래 적합한 도구가 존재하지 않는다.
또한 문서만 포착할 수 있는 사소한 행동을 확인하고, 설치된 언어에 따라 판독하기 어렵고, 맞춤형 시나리오를 원하는 경우도 있다
이를 실현하기 위해 평소 익숙한 고 개발 기준 도구를 활용해 당시 있었던 일을 기사로 정리하려 한다.
※ 이러한 요구를 모두 충족시킬 수 있는 도구를 개발한 것은 아니며, 개발을 시작한 것일 뿐입니다.
규격.

성능을 관찰하는 데 필요한 클라이언트 측 지표

Latency(avg, min, max, %tile)

RPS

시나리오의 맞춤형

최종 보고 기능 출력

이번에는 상술한 내용을 실시해 보자.
또한 Redis에 대해 수행할 수 있는 데이텀의 컨텐트를 설치합니다.
실제 검증할 때 서비스 측의 CPU 사용률과 지연 등도 감시하지만 실시하려면 상당히 어려울 수 있기 때문에 이 도구는 실시하지 않는다.
이루어지다
성과물은 github에 있다.
소스 코드가 정리되지 않아서 시간이 있을 때 정리하고 싶은데 이번에는 용서해 주세요.
개발된 것은 아래의 인터페이스가 매우 중요하다.

type Executor interface {
    Setup(context.Context) (context.Context, error)
    ExecContext(context.Context) (context.Context, error)
}

type Preparer interface {
    PrepareContext(context.Context) (context.Context, error)
}

Executor 방안을 구상했다.Setup 방법은 예처리입니다.Setup 기준을 시작하기 전에 한 번 실행하고 GET 명령이 Redis에 대한 기준이라면 여기에 데이터를 삽입하여 캐시 안전률을 높일 수 있다.
여기, Setup는context입니다.Context를 반환하는 구상은 context에서 이전 처리 단계의 정보를 보존하고 반환하는 것입니다.
예를 들어'Redis의 GET 방법의 캐시 안전률을 100%로 하려면 열쇠만 무작위로 생성하고 싶다'는 용례가 있다면 Setup이 미리 발행한 무작위 키를 사용하여 Redis에 SET를 하고 이 SET의 키를 context에 설치하여 실제 GET일 때 context에서 키를 얻어 GET에 들어간다
이렇게 처리하면 실현할 수 있다.ExecContext 방법은 실제 측정 처리를 실시하는 부분이다.
레디스로 따지면 여기는 사실상 GET 발매 방법입니다.
현재 이 방법으로context를 되돌릴 이유가 거의 없다.
앞으로 일련의 처리를 하나하나 측정할 때 ExecContext의 결과가 있기 때문에 아래의 처리 등을 갈 때 필요해지고 추가된다고 말했다.
※YAGNI.
다음은 Preparer, 여기ExecContext는 필요한 정보를 준비하는 처리를 하는interface입니다.
준비 처리가 결과에 영향을 미치는 지연을 방지하기 위해 인터페이스를 분리한다.
Prepter가 설치된 경우에만 호출됩니다.
기본적으로 이 인터페이스를 추가함으로써 리디스 이외의 콘텐츠를 구현할 수 있다.
다른 것은 특별한 설명이 없기 때문에 상세히 원본 코드를 참조하세요.
확인
그렇다면 실제로 검증해 보자.
이번에는 리디스의 기준 도구를 실시했기 때문에 비교redis-benchmark로도 검증했다.
환경 세부 사항
Redis는 Elasticache와 Redis6을 사용합니다.x 시스템을 사용하여 Redis 클러스터 모드가 비활성화되었습니다.Redis의 인스턴스 유형은 r6g입니다.large를 사용하고 있습니다.
실행 기준의 기계는 EC2 실례를 사용하는데 실례 유형은 c6g이다.4xlarge를 사용합니다.
하나씩 준비했어요.
이번 기준은 az 사이를 뛰어넘는 화환을 보고 싶다기보다는 Elastic ache Redis 자체의 화환을 보고 싶었다. 검증 도구 자체가 유효한지 확인하기 위해 az가 ap-northeast-1a에 보냈다.
Redis의 데이텀 컨텐트

GET 명령

캐시 보안 0%

클라이언트 500 동시 연결

이번에는 생각 안 한 거.

키 길이

실행 시간

실측

redis-benchmark의 결과

명령하다

$ redis-benchmark -h $HOST -t get -c 100 --threads 5 -n 40000000

결실

 ...

  throughput summary: 253900.53 requests per second
  latency summary (msec):
          avg       min       p50       p95       p99       max
        0.380     0.088     0.375     0.519     0.591    59.455

RPGS25만, 엘라스틱 치레디스 대단한데...
Latency의 성능도 평균 p95, p99를 포함합니까...
2. 이번 도구의 결과
명령하다

cmd bench --threads=500 --clients=500 --host=$HOST --duration=180 --output-json-path=result.json

결실

...
    {
      "avg(ms)": 1.953908553753247,
      "max(ms)": 9.575562,
      "min(ms)": 0.123043,
      "p50(ms)": 1.8975165033781725,
      "p90(ms)": 2.048262475701852,
      "p95(ms)": 2.1775845942189624,
      "p99(ms)": 3.569607007901278,
      "rps": 222619,
      "start_time": "2021-12-12T15:22:48.817915446Z"
    },
...

그게, redis-benchmark만큼 좋은 성능은 없어요(^^;)
RPS도 3만과 큰 차이가 있고 레이텐시도 4~6배 차이가...
※ 이번 시행 도구는 모든 간격으로 집계된 것이 아니라 1초 단위로 집계된 것이기 때문에 이번 기재의 결과는 단점으로 계산된 결과입니다.
총결산
이번에는 통용적으로 실시할 수 있는 기준 도구를 개발해 보았다.
그게, redis-benchmark만큼 좋은 성능은 없어요(^^;)
죄송합니다. 이 상태로 이 기사를 마치겠습니다.
나는 원인을 추구할 시간과 정력이 없다.
Redis-benchmark를 실행할 때 EC2의 CPU 사용률은 300% 정도였는데 이번에 제작된 도구는 600% 정도에 달했다.
redis-benchmark에 비해 부하성도 문제였고 결과적으로 그런 것을 기대하지 못했다.
goo측 코드에서 goredis를 사용했지만 TCP 클라이언트를 직접 사용한 것으로 변경해 보았지만 특별한 영향이 없었습니다. 병목이 어디 있겠습니까...
만약 누군가가 알고 있다면, 나에게 메시지를 남길 수 있다면 정말 좋겠다.
금후
이번에 개발한 공구는 정밀도가 상당히 낮아 개발하기 어려울 것 같다.
또 결과를 정리할 때 필요한 정보도 아직 다 내놓지 않아 완성도를 높일 수 있을 것 같다.
앞으로 팩스와 함께 필요할 때 신속히 추가 개발이 가능하니 활용할 수 있었으면 좋겠다