(1) DLQ 연결 및 K6 성능테스트

 

 

 

 

DLQ란?

DLQ는 "Dead-Letter Queue"의 약자로, 일반적으로 메시지 지향 미들웨어에서 사용되는 용어입니다.

메시지 지향 미들웨어는 서로 다른 시스템 간에 메시지를 교환하는 데 사용됩니다.

메시지 전송이 실패하거나 처리 중에 문제가 발생할 경우, 해당 메시지는 일반적으로 DLQ로 이동됩니다.

 

DLQ는 실패한 메시지를 보관하는 특별한 큐입니다. DLQ에 있는 메시지는 일반적으로 사람이 수동으로 확인하고 다시 처리하거나 해당 메시지에 대한 문제를 해결한 후에 다시 전송할 수 있습니다.

따라서 DLQ는 메시지 처리 중에 발생할 수 있는 잠재적인 문제를 식별하고 해결하는 데 도움이 됩니다.

 

DLQ는 보통 중요한 데이터나 작업에 사용됩니다. 실패한 메시지는 제때 처리되지 않으면 큰 문제가 될 수 있기 때문에 DLQ를 사용하여 문제를 신속하게 해결할 수 있습니다.

 

 

 

 

 

K6란?

K6란 오픈소스의 성능 테스트 도구이다. 이 도구는 웹사이트, API, 마이크로서비스, 그리고 다른 네트워크 서비스의 성능을 측정하는 데 사용됩니다. k6는 js로 작성되어 있으며, Go 언어로 작성된 VU(가상 사용자) 엔진을 사용하여 대규모 가상 사용자를 부하를 생성합니다.

k6은 도구 자체에서 성능 프로파일링과 결과 분석을 제공하며, 데이터 시각화와 다양한 클라우드 기반 호스팅 옵션을 지원한다.

k6은 Docker와 함께 사용되어 쉽게 환경을 구성할 수 있으며 다양한 프로토콜(HTTP, WebSocker, gRPC 등)을 지원한다.

 

 

 

---

Step 3-1: DLQ 연결 및 K6 성능테스트

DLQ를 연결하고, K6 성능테스트 도구를 사용하여 여러 번의 producer함수 실행을 보다 전문적으로 테스트할 수 있다.

DLQ에 쌓이는 메시지의 현황은 AWS 콘솔에서 확인할 수 있다.

 

 

consumer에 실행 시간을 늘리는 코드 추가

function delay(time) {
  return new Promise(resolve => setTimeout(resolve, time));
}

const consumer = async (event) => {
  await delay(5000)
  for (const record of event.Records) {
    // 생략
  }
}

코드 수정 후

serverless deploy

디플로이 

 

테스트에서 "body" : "value1"를 테스트하고

결과를 받았다

---

이제 시간지연함수를 통해 지연해보기

 

 

await delay(15000)

소스코드를 15000으로 변경

 

배포 후

 

클라우드 와치를 확인해 보면

Task timed out이라는 에러를 볼 수 있다

 

람다함수는 실행제한이 6초로 걸려있기 때문에 그렇다.

 

보내지지 못한 메시지는 dlq로 넘어감을 확인할 수 있다.

 

 

배달 못한 편지 대기열을 보면 연결된 dlq를 볼 수 있다.

최대 수신 수는 3으로 설정되어 있음을 확인할 수 있다.

 

클라우드와치를 확인하면 3번 수신시도한 것을 볼 수 있다

 

dlq에 들어와서 메시지 전송 및 수신버튼을 클릭하면

메시지 폴링을 할 수 있다.

 

 

폴링 된 메시지를 확인하면 

아까 전송했지만 도착하지 못한 메시지를 확인할 수 있다!

 

=> 일반 큐에서 수신을 했지만 최종적으로 소비되지 않아서 지워지지 않는 메시지가 DLQ에 쌓이는 것을 확인했다

 

 

 

---

k6 성능 테스트 도구 활용

 

k6설치하기

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

Installation

공식홈페이지를 참조하여 설치를 진행하였습니다

저는 macOs를 사용하기때문에

brew install k6

위의 명령어를 사용하여 설치했습니다

 

 

step3 디렉토리는 아래와 같이 구성되어 있습니다.

step3

ㄴrun.sh

ㄴsingle-request.k6.js

 

---

run.sh

#!/bin/bash
k6 run -u 1 -i 100 ./single-request.k6.js

 

single-request.k6.js

import http from 'k6/http';
import { sleep, check } from 'k6';

// you can specify stages of your test (ramp up/down patterns) through the options object
// target is the number of VUs you are aiming for

export const options = {
  stages: [
    { target: 20, duration: '20s' },
    { target: 15, duration: '20s' },
    { target: 0, duration: '20s' },
  ],
  thresholds: {
    http_reqs: ['count <= 100'],
  },
};

export let input = 1

export default function () {
  // our HTTP request, note that we are saving the response to res, which can be accessed later
  const payload = { input: input++ };
  const headers = {
    'Content-Type': 'application/json',
    'dataType': 'json'
  };
  const res = http.request('POST', 'api주소/produce',
  JSON.stringify(payload),  {
    headers: headers,
  });
  console.log(JSON.stringify(payload))
  sleep(0.1);

  const checkRes = check(res, {
    'status is 200': (r) => r.status === 200, // 기대한 HTTP 응답코드인지 확인합니다.
    'response body': (r) => r.body.indexOf('{"message":"Message accepted!"}') !== -1,  // 기대한 응답인지 확인합니다.
  });
}

 

---

 

run.sh를 실행시켜서 테스트를 진행했습니다.

bash run.sh

 

첫 번째 부분

• running으로 표시된 부분을 보면 테스트가 실행되는 동안의 상태를 보여줍니다.
• 테스트가 시작 된 후 16.3초가 지났으며 가상 사용자(VU)는 0/1로 설정되어 있으며 100개의 요청이 완료된 상태이다.

두 번째 부분

• 테스트 결과의 세부 정보를 볼 수 있다
• 체크된 항목이 모두 통과되었으며 모든 요청이 상태코드 200을 반환했다.
• 데이터를 받은 양과 보낸양, 각 단계별로 소요된 시간 등의 세부 정보도 제공된다.

이 테스트는 하나의 가상 사용자를 사용하여 100개의 요청을 수행한 결과이다.

모든 요청은 성공적으로 완료되었으며, 각 단계별로 걸린 시간과 전송된 데이터의 양 등이 측정되었다.

이러한 결과를 통해 성능 테스트의 결과를 분석하고, 성능 개선을 위한 작업을 수행할 수 있다.

 

 

 

---

Step 3-2: Visibility Timeout 조절과 DLQ

 

함수 실행이 실패하지 않았음에도 표시 제한시간에 따라 메시지가 DLQ로 넘어갈 수도 있다.

 

jobs-worker 실행제한시간을 늘여보자.

20초로 수정해주었다.

body내용을 변경하여 테스트를 다시 시도했다

클라우드 와치를 통해서 메시지를 확인했다

 

---

이제 Visibillity Timeout을 조정해서 문제상황을 만들어줄 것이다.

큐를 살펴보면 기본 표시 제한이 36초로 설정되어있다.

 

 

 

 

표시 제한 시간을 5초로 변경한다.

 

기본 표시 제한 시간이 5초로 변경되었음을 확인할 수 있다.

 

---

 

다시 프로듀서로 가서 다시 테스트를 하고

클라우드 와치에서 도착한 메시지를 확인했다.

 

그러나 dlq에는 메시지가 110->111개로 하나 더 생겼다.

 

메세지가 두 개이상의 컨슈머에게 도착한 상황이다

하나는 람다, 하나는 DLQ에게

 

DLQ에 들어가 메시지폴링을 해보면 

Visibility timeout에의해 dlq로 들어간 메시지를 확인할 수 있다.