728x90

메시지 큐란?

메시지 큐 사이 비동기 통신 프로토콜을 제공 송신자  수신자 가 같은 시간에 메시지 큐와 상호 작용 필요가 없습니다 메시지를. 큐에 배치 된 메시지는받는 사람이 검색 할 때까지 저장됩니다.

메시지 큐 패러다임은 pub-sub 패턴 의 형제입니다 . 그러나 pub-sub 패턴을 사용하면 게시자 라고하는 메시지 발신자 가 어떤 구독자가 존재하는지 알지 못해도 채널을 통해 구독자 라고하는 수신자 에게 메시지를 게시 할 수 있습니다. 모든 구독자는 수신 된 메시지가 동시에 메시지를 수신 할 수있는 시점에 존재합니다..

 

Redis는 pub-sub 패턴 을 명시 적으로 지원합니다 . 그러나이 기사에서는 Redis의 List 기본 제공 유형을 사용하여 Message Queueing을 구현하는 방법을 살펴 봅니다.

 

게시물 끝에서 Redis가 지원하는 Job Dispatcher (Nodejs) 및 Job Consumer (Golang)를 구현하는 방법을 살펴 보겠습니다.

Redis의 List 데이터 구조에 대해 알아보기

Redis에는 삽입 순서로 정렬 된 문자열 목록 인 내장 목록 데이터 유형이 있습니다. 목록 LPUSH의 맨 앞 ( RPUSH) 또는 꼬리 ( )에 요소를 밀어 넣을 수 있습니다 .

LPUSH mylist a   # now the list is "a"
LPUSH mylist b   # now the list is "b","a"
RPUSH mylist c   # now the list is "b","a","c" (RPUSH was used)

다음은 목록에 사용할 수있는 모든 요소입니다.

목록 명령 (확대하려면 클릭)

redis-cli 작업

이 게시물에서는 기본 메시지 대기열 기능 을 구현 하기 위해 PUSH  POP 작업을 사용하는 방법을 살펴 봅니다 . AWS의 다음 다이어그램에 표시된 것처럼 메시지 대기열은 Redis 용 Amazon ElastiCache 의 사용 사례 중 하나 입니다.

그러나이 게시물에서는 시리즈의 첫 번째 기사에서 수행 한 로컬 Redis 설치를 사용합니다.

를 사용하여 명령을 시도해 보겠습니다. redis-cli먼저 1 부에서 Redis VM 에 연결해야합니다 .

$ vermin ssh vm_01

위와 같이 오른쪽에있는 두 개의 스택 터미널에서 실행했습니다. BLPOP jobQueue 0즉, 이름이 지정된 목록의 선두에서 POP를 실행 jobQueue하고 요소가 추가 될 때까지 영원히 기다립니다 (따라서 시간 제한 값 0).

그리고 세 번째 터미널 (오른쪽 중 하나)에서 목록 끝에 2 개의 요소 ( "Hello"및 "world")를 푸시했습니다.

두 요소를 푸시하면 각 요소가 클라이언트 세션에 의해 팝되고 있음을 알 수 있습니다.

다음 섹션에서는 Node.js와 Golang을 사용하여 간단한 작업 대기열을 구현하고 Redis를 메시지 대기열로 사용할 것입니다.

간단한 작업 대기열 구현

먼저 환경을 설정하겠습니다. Nodejs 앱을 사용하여 작업을 작업 대기열 ( job-dispatcher ) 로 발송 하고 Golang 앱을 사용하여 작업을 소비하고 작업 ( job-consumer )합니다. 디스패처와 소비자로부터 몇 가지 애플리케이션을 배포 할 것입니다.

이제 Redis VM 내부에 로컬 파일 시스템 디렉터리를 마운트 할 수 있는 vermin의 한 기능을 사용해 보겠습니다 . 호스트 OS 콘솔에서 다음을 작성하십시오.

$ mkdir -p ~/temp/mq
$ vermin mount vm_01 ~/temp/mq

호스트 OS에 코드를 작성한 다음 VM 내에서 실행 해 보겠습니다.

IntellijIDEA를 사용하지만 원하는 편집기를 사용할 수 있습니다 (VSCode도 좋은 선택입니다).

내부에 두 개의 디렉토리를 만들 것입니다 ~/temp/mq.

$ mkdir -p ~/temp/mq/{job-dispatcher,job-consumer}

먼저 Golang ( go-redis 사용)에서 작업 소비자를 구현 하고 redis-cli클라이언트 에서 메시지를 전송하여 테스트합니다 .

다음은 소스 코드입니다.

// ~/temp/mq/job-consumer/main.go
package main

import (
   "fmt"
   "github.com/go-redis/redis/v7"
   "log"
   "time"
)

const key = "myJobQueue"

func main() {

   c := redis.NewClient(&redis.Options{
      Addr: "localhost:6379",
   })

   fmt.Println("Waiting for jobs on jobQueue: ", key)

   go func() {
      for {
         result, err := c.BLPop(0*time.Second, key).Result()

         if err != nil {
            log.Fatal(err)
         }

         fmt.Println("Executing job: ", result[1])
      }
   }()

   // block for ever, used for testing only
   select {}
}
$ GOOS=linux go build
vermin@verminbox:~$ /vermin/job-consumer/job-consumer
Waiting for jobs on jobQueue:  myJobQueue
vermin@verminbox:~$ redis-cli
127.0.0.1:6379> RPUSH myJobQueue "100"
(integer) 1
redis-cli를 사용하여 작업 소비자 앱에 작업 보내기

다음 단계는 Nodejs 에서 작업 디스패처를 만들고 높은 빈도로 여러 작업을 보내는 클라이언트를 시뮬레이션하는 것입니다.

작업 디스패처 구현

Nodejs 내에서 Node Redis 를 Redis 클라이언트로 사용할 것입니다 . 소스 코드는 다음과 같습니다.

// ~/temp/mq/job-dispatcher/index.js
const redis = require("redis");
const client = redis.createClient({
    address: "localhost:6379"
});

client.on("error", function (error) {
    console.error(error);
});

let myArgs = process.argv.slice(2);
let start = Number(myArgs[0])
let end = start + 10000

console.log(end)

for (let i = start; i < end; i++) {
    client.rpush("myJobQueue", i);
}

client.quit();
 

하지만 먼저 job-consumer6 개의 다른 터미널에서 6 개의 인스턴스를 실행 해 보겠습니다 . ( /vermin/job-consumer/job-consumer이전 섹션에 표시된 명령 사용 )

 

그리고 job-dispatcher다음과 같이 두 개의 터미널 에서 2 를 실행 해 보겠습니다 .

$ cd /vermin/job-dispatcher
$ node index.js 0
$ cd /vermin/job-dispatcher
$ node index.js 10000

Redis의 Lists를 Message Queue 로 사용하고이를 사용 하여 NodeJs에서 job-dispatcher 를 구현하고 Golang에서 job-consumer 를 구현하여 Job Queue 를 구축하는 방법 을 살펴 보았습니다.

RabbitMQ 또는 ActiveMQ와 같은 완전한 메시지 브로커를 가져 오는 대신 간단한 메시지 큐가 필요한 경우이 방법을 간단한 대안으로 사용할 수 있습니다.

 

Github에서 디스패처 및 소비자에 대한 소스 코드를 찾을 수 있습니다. https://github.com/mhewedy-playground/redis-mq

 

게시물에서 본 구현은 기본 작업 대기열이지만 처리중인 작업이 포함 된 처리 대기열을 포함하는 고급 작업 대기열을 찾는 경우 명령 RPOPLPUSH및 BRPOPLPUSH설명서를 확인하여 신뢰할 수있는 대기열 사용 사례를 확인할 수 있습니다 .

 

참조 : Korean (ichi.pro)

반응형
728x90

1. 개요[편집]

수강 신청, 예매, 온라인 접수, 게시판 폭주 등 동시 접속 폭주로 발생하는 시스템 마비와 서비스 중단을 방지할 수 있는 솔루션을 말한다.

접속을 거부하거나 지연시키는 기존의 접근제어 솔루션과 달리 임계치를 초과하는 접속 요청은 대기 정보를 제공해 순차적으로 접속할 수 있도록 한 것이다. 기존 접속자의 접속을 최대한 보장함과 동시에 접속 예상시간과 대기 인원을 확인할 수 있도록 함으로써 웹 접속자의 이용 편의성도 개선한 솔루션이다.

2. 원리[편집]


서비스를 제공하는 메인 서버와 접속제어 솔루션이 위치한 대기 서버를 별개로 분리시킨 후, 모든 요청을 대기 서버로 리다이렉트 한다. 이후 접속제어 솔루션은 설정된 동시접속 수 및 초당 접속인원을 제어하며 대기순번 부여 및 API를 통한 메인 서버의 접근 권한을 제어한다.

대기순번 부여방식은 선착순 부여방식과 동시 부여방식이 있다. 선착순 부여방식은 예정된 시간부터 접속한 순서대로 순번을 부여하지만, 시간이 되자말자 새로고침 또는 접속을 하는 사람이 많아 자칫하면 대기 서버가 터져 버리거나 바이패스[1]가 작동해 메인 서버까지 터져버릴 수 있다.

동시 부여방식은 예정된 시간까지 접속해있던 모든 클라이언트에게 랜덤으로 대기순번을 부여하고, 이후 접속자는 제일 후순위로 배정하는 방법이다. 사람들이 순차적으로 접속하기 때문에 서버에 가해지는 부담은 적으나, 유리한 순번을 얻기 위해 중복 접속하는 경우가 많다.

3. 도입[편집]

대학교, 기업, 공공기관, 정부, 각종 시험 접수 관련 사이트 등.

주로 수강신청이나 명절 기차표 예매와 같이, 짧은 시간에 대량의 접속자가 몰리면서도 누락되거나 중복되는 등의 잘못된 정보가 발생하면 안 되는 상황에서 사용한다. 게임에서도 주말 저녁과 같이 접속자가 몰리면 품질 유지의 일환으로 대기열이 발생하기도 한다.

클라우드 시스템이 도입된 IT 서비스들에서는 의외로 접속제어를 찾아보긴 어렵고, 백엔드 시스템이 열악하고 각종 서버와 프레임워크로 연계된 정부와 공공기관 사이트에서 절찬리에 사용되고 있다.

4. 개발 업체[편집]

  • (주)에스티씨랩 - NetFUNNEL(넷퍼넬)
  • (주)웰컨 - TRACER v2.0
  • (주)데브와이 - MEGA-FENCE

 

퍼옴 : 나무위키 대량접속제어

반응형
728x90

✔개요

대기열 시스템의 탄생 배경

이번에 회사에서 새로운 상품을 오픈하기 위해 대대적인 마케팅?을 진행한다는 것을 전달받아 대기열 시스템을 설계, 개발을 진행했습니다. 


왜? 우리는 대기열 시스템이 필요했을까?

현재 대고객 서비스를 위한 개발 및 운영하고 있으며, 상품에 대한 주요정보 등을 코어영역와의 통신을 통해 처리하고 있다. (우리는 고객을 상대하는 채널이다.)
우리가 도입하려는 대기열 시스템은 고객의 동접을 대응하지 못할때 FIFO(선입선출) 방식으로 순차적으로 트래픽을 처리하기 위한 방안입니다.
레거시 시스템의 경우에는 On-Premise 환경으로 구성이 되어있어 트래픽이 몰릴 시 서버 확장 대응에 어려움이 있다. (오토 스케일링이 불가능) 신규 시스템의 경우에는 (클라우드 환경) 트래픽이 몰릴 시 서버 확장 대응에 용이 하다

결국에 레거시 시스템에서 병목이 발생하고... 모든 사이트는 마비가 된다. 
우리는 장애전파(Circuit Breaker)를 막기 위해 대기열 시스템을 만들자!

 


✔ 설계시 생각한 방안

  • 1안
    • MQ(Kafka)를 활용한 대기열 시스템.
    • 장점
      • 미들웨어를 활용하므로써 정확한 MQ 시스템 구성
      • 속도 및 안정성 최고
      • 구축 경험이 있어 러닝커브 적음
    • 단점
      • 기존에 도입되지 않아서 구성 시간이 필요.
      • 단발성으로 사용하기에 비용적 측면으로 비효율적.
  • 2안
    • Redis를 활용한 대기열 시스템
    • 장점
      • List, Sorted Set와 같은 자료형을 사용하면 MQ 구현가능 할 듯
      • Cache의 장점 부각, 속도 최고.
      • 러닝커브 적음
    • 단점
      • Redis가 죽으면 끝이다.

 ✅ 우리는 2안을 선택했고 시간적인 여유가 없었고, 현명한 선택이라 생각한다.

 


 시스템구성

우리는 k8s 기반의 MSA 시스템 환경을 맞추기 위해, Spring Boot 기반의 Spring WebFlux를 도입하여 사용하였다.
Spring WebFlux는 Srping MVC와는 달리 Servlet과는 관계없이 만들어졌으며, WebFlux에서의 웹서버는 기본 설정은 Netty기반이지만 우리는 Spring Boot 에서 공식 지원 내장하는 (Lightweight, WebFlux에 적합, WebSocket 지원) Undertow를 적용했다.
WebFlux를 기반으로 논블록킹(Non-blocking) 비동기(Async) 프로그래밍을 도입했으며 Redis를 활용하였는데 reactive에 맞추어 제공되는 redis-reative 라이브러리를 사용햇다.

Fornt end와의 통신은 WebSocket과 REST API를 통해 통신을 진행하였으며,
Stomp(Simple Text Oriented Mssage Protocol)을 통해 WebSocket을 효율적으로 다루기 위한 프로토콜을 적용했다.
기존 WebSocket과는 다르게 Stomp는 Publisher/Subscriber 구조로 되어있다.
(즉, 구독한 사람들에게 메시지를 요청하면 메시지를 전달하는 형태)
대기열에서 작업열로 이동하는데 사용한 Spring-Batch도 도입하였다.

  • Java 11
  • Undertow
  • AWS WebServer
  • websocket (Stomp, SockJS)
  • Spring webflux
  • Redis-reactive
  • Junit5
  • Spring Batch

 


✔ 대기열의 구성은?

대기열의 구성은 오직 Redis와 Spring Boot 기반으로 구축하였다.
Redis 자료형 중 하나인 SortedSet을 사용했으며,
SortedSet은

  • Set과 Hash가 혼합된 타입이며,
  • 하나의 Key에 Score와 Value로 구성되어 있다.
  • Score기준으로 정렬이 가능하고
  • Queue 처럼 사용 가능하다

SortedSet 채택이유는 아래와 같다.

  • 각 명령어들의 효율적인 시간복잡도 O(1) ~ O(log(N)
    • 현재순위 조회 - Element의 현재위치 확인가능 ZRANK 명령어
      • 시간복잡도 - O(log(N))
    • 대기자 전체 크기 - Value의 전체 크기 ZCARD
      • 시간복잡도 - O(1)
    • 대기열에서 이동하는 Element Range 조회
      • 시간복잡도 - O(log(N))
    • 대기열의 Element 삭제
      • 시간복잡도 - O(log(N))
      • 자료형 List을 사용했을때는 Element 삭제시 시간복잡도 O(N)

 ✅ 우리가 대기열을 구성하기에 필요한 Queue를 적용할때 충분한 요건을 가진 자료형이다.

 


  • 대기열 로직
    1. 고객 대기열 페이지 진입.
    2. 대기열 Queue에 고객 Key값 Insert
    3. Batch에서 일정 시간마다 작업업열로 이동 가능한 Capability 확인
    4. 가능한 Capability 있으면 대기열에서 작업열로 이동.
  • 대기열 페이지에 진입한 고객
    1. 현재 위치 확인, 대기열 전체 사이즈 및 작업열 이동여부 조회.
    2. 작업열 이동 가능 여부 확인.
    3. 작업열에 유효한 Key값인지 확인
    4. 기존 발급된 이력이나, 만료된 Key값인지 확인.
    5. 동접 Ticket 발부.
    6. 세션 유지.
    7. 고객 이탈시 expire을 통해 세션 삭제.

 🔥 즉, 고객은 대기열 진입시 발급된 Key 값을 통해 작업열까지 진입하고, 티켓을 발급 받으면 티켓과 key값을 통해 고객 세션을 유지한다. 고객 세션이 만료되면 작업 가능한 Capability가 생긴다.


✔ WebSocket (Stomp)

WebSocket (Stomp) 사용 이유

  • 우리는 REST API를 통해서 통신을 진행할 수 있었지만 WebSocket을 사용했다.
  • 왜?
    • HTTP 통신의 Connection에 Cost를 줄이고자 하였고, WebSocket을 적용하였을때 Handshake를 최초에만 진행하여 전체적인 네트워크 Cost를 줄일 수 있다는걸 결론으로 도출했다.
    • WebSocket은 HTTP Protocol로 Connection을 초기에 맺고, ws(WebSocket),wss Protocol로 Upgrade한 후 서로에게 Heartbeat를 주기적으로 발생시켜 Connection을 유지하고 있는지 확인한다.
    • WebSocket(Stomp)은 브라우저에 대한 호환성 때문에도 채택을 진행했다.

 💡 즉, Cost를 절감해 고객의 유입폭이 더 증가 할 수 있다 라는 결과를 뽑았다. ( HTTP API 통신을 안한 것은 아니다. 필요에 따라 사용했다. )

WebSocket (Stomp) 연결

@Slf4j
@Configuration
@EnableWebSocketMessageBroker
public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {

    private final StompHandler stompHandler;

    public WebSocketConfig(StompHandler stompHandler) {
        this.stompHandler = stompHandler;
    }

    @Override
    public void configureMessageBroker(MessageBrokerRegistry config) {
        config.setApplicationDestinationPrefixes("/app");
        config.enableSimpleBroker("/topic");
    }

    @Override
    public void registerStompEndpoints(StompEndpointRegistry registry) {
        registry.addEndpoint("/connect")
                .setAllowedOriginPatterns("*")
                .withSockJS()
                .setClientLibraryUrl("<https://cdnjs.cloudflare.com/ajax/libs/sockjs-client/1.3.0/sockjs.min.js>");
    }

    @Override
    public void configureClientInboundChannel(ChannelRegistration registration) {
//        registration.interceptors(new HeaderCheckInterceptor());
        registration.interceptors(stompHandler);
    }

}
  • registerStompEndpoints
    • Websocket Connection에 관련된 설정이다.
    • SockJS를 이용해 STOMP end-point를 설정해준다.
    • withSockJS()
      • 브라우저에서 Websocket을 지원하지 않을 경우 Fallback 옵션을 활성화 하는데 사용한다.
      Enable SockJS fallback options.
    • setAllowedOriginPatterns("*")
      • WebSocket에서 Cors 처리를 위한 허용 패턴.
      • 일정 버전부터 setAllowedOrigins 메서드가 사용되지 않아 setAllowedOriginPatterns을 사용함.
      Alternative to setAllowedOrigins(String...) that supports more flexible patterns for specifying the origins for which cross-origin requests are allowed from a browser. Please, refer to CorsConfiguration.setAllowedOriginPatterns(List) for format details and other considerations. By default this is not set. Since: 5.3.2
  • configureMessageBroker
    • 메시지브로커에 대한 Prefix 설정.
    • config.setApplicationDestinationPrefixes
      • Socket 통신시 End-Point 목적지의 Prefix 설정이다.
      • 즉, Client Side에서 Server 사이드로 보내는 Message
      Configure one or more prefixes to filter destinations targeting application annotated methods. For example destinations prefixed with "/app" may be processed by annotated methods while other destinations may target the message broker (e.g. "/topic", "/queue"). When messages are processed, the matching prefix is removed from the destination in order to form the lookup path. This means annotations should not contain the destination prefix. Prefixes that do not have a trailing slash will have one automatically appended.
    • config.enableSimpleBroker
      • Subscriber에게 메시지를 보낼때의 목적지의 Prefix 설정이다.
      • 즉, Server Side에서 Client Side로 보내는 Message
      Configure the prefix used to identify user destinations. User destinations provide the ability for a user to subscribe to queue names unique to their session as well as for others to send messages to those unique, user-specific queues. For example when a user attempts to subscribe to "/user/queue/position-updates", the destination may be translated to "/queue/position-updatesi9oqdfzo" yielding a unique queue name that does not collide with any other user attempting to do the same. Subsequently when messages are sent to "/user/{username}/queue/position-updates", the destination is translated to "/queue/position-updatesi9oqdfzo". The default prefix used to identify such destinations is "/user/".
  • configureClientInboundChannel
    • Inbound 메시지에 대한 Intercepter처리를 할 수 있다.
    • JWT 인증과 같은 인증 로직에 주로 이용하고 있으며, @ChannelInterceptor 어노테이션을 이용하니 필요하면 참고해보길 바란다.

publish / subscribe

@Slf4j
@RestController
public class SocketHandler {

    @MessageMapping("/sendMessage/{key}")
    @SendTo("/topic/public/{key}")
    public String hello(String str){
        log.info("Check in hello -> " + str);
        return "your message -> " + str;
    }

}
  • @MessageMapping
    • Publish Target Url
    • Client to Server
    Destination-based mapping expressed by this annotation. For STOMP over WebSocket messages this is AntPathMatcher-style patterns matched against the STOMP destination of the message.
  • @SendTo
    • Subscribers 한테 Message를 전송한다
    • Server to Client
  • {key}
    • 우리는 고객마다 고유한 End-Point를 Key값을 통해 지정했다.

Junit 을 이용한 Client Test

@ActiveProfiles("local")
class SocketControllerTest {

    final String TARGET_URI = "<http://localhost:30001/connect>";
		final String SENDMESSAGE_URI = "/app/sendMessage/123456";
		WebSocketStompClient stompClient;

    private List<Transport> createTransportClient(){
        List<Transport> transports = new ArrayList<>();
        transports.add(new WebSocketTransport(new StandardWebSocketClient()));
        return transports;
    }

    @BeforeEach
    public void setup() throws InterruptedException{
        stompClient = new WebSocketStompClient(new SockJsClient(createTransportClient()));

        stompClient.setMessageConverter(new MappingJackson2MessageConverter());
    }

		@Test
    public void contextLoad() throws ExecutionException, InterruptedException, TimeoutException {

            WebSocketHttpHeaders httpHeaders = new WebSocketHttpHeaders();
            httpHeaders.add("jwt" , "test");
            StompHeaders stompHeaders = new StompHeaders();
            StompSession stompSession = stompClient.connect(TARGET_URI, httpHeaders, stompHeaders, new StompSessionHandlerAdapter() {
            }).get(1, TimeUnit.SECONDS);

            // Send
            stompSession.send(SENDMESSAGE_URI, "test");

		}
}
  • Junit의 WebSocketStompClient을 사용하여 Server side와의 WebSocket 연동 Test를 진행.
    • 소스참고.

 


✔ Redis

대기열에 큰 Point를 가지고 있는 Redis에 대한 셋팅이다.

Redis reative 설정

@Slf4j
@Configuration
@EnableCaching
public class RedisConfiguration {

    @Value("${spring.redis.host}")
    private String host;
    @Value("${spring.redis.port}")
    private int port;

    
    @Bean
    public RedisConnectionFactory redisConnectionFactory() {
        return new LettuceConnectionFactory(host, port);
    }

    @Bean
    public RedisTemplate<String, Object> redisTemplate() {
        RedisTemplate<String, Object> redisTemplate = new RedisTemplate<>();
        redisTemplate.setConnectionFactory(redisConnectionFactory());
        redisTemplate.setKeySerializer(new StringRedisSerializer());
        return redisTemplate;
    }

    @Bean
    public ReactiveRedisTemplate<String, String> reactiveRedisTemplate(ReactiveRedisConnectionFactory connectionFactory) {
        RedisSerializer<String> serializer = new StringRedisSerializer();
        Jackson2JsonRedisSerializer jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer<>(String.class);
        RedisSerializationContext serializationContext = RedisSerializationContext
                .<String, String>newSerializationContext()
                .key(serializer)
                .value(jackson2JsonRedisSerializer)
                .hashKey(serializer)
                .hashValue(jackson2JsonRedisSerializer)
                .build();

        return new ReactiveRedisTemplate<>(connectionFactory, serializationContext);
    }

}
  • Redis를 Reative 방식으로 Template 설정.

주로 사용한 RedisUtils

@Slf4j
@Component
@AllArgsConstructor
public class RedisUtils {

    private final RedisTemplate<String ,Object> redisTemplate;

    private final ReactiveRedisTemplate<String, String> reactiveRedisTemplate;

		/**
     * @desc: Sorted Set 삭제.
     */
		public Mono<Long> delete(String key){
       return reactiveRedisTemplate.delete(key);
    }

		/**
     * @desc: Sorted Set 조회
     */
		public Mono<String> getValue(String key){
        return reactiveRedisTemplate.opsForValue().get(key);
    }

		/**
     * @desc: RedisTemplate에 SortedSet 초기화.
     */
    public ReactiveZSetOperations opsForZSet(){
        return reactiveRedisTemplate.opsForZSet();
    }

		/**
     * @desc: Sorted Set 자료형 사이즈
     */
    public Mono<Long> zCard(String str){
        ReactiveZSetOperations z = reactiveRedisTemplate.opsForZSet();
        return z.size(str);
    }

		/**
     * @desc: Sorted Set 자료형 start ~ end 까지 조회.
     */
    public Flux<String> zRange(String key, Long start, Long end){
        return opsForZSet().range(key, Range.closed(start, end));
    }

		/**
     * @desc: Sorted Set 자료형 Value의 현재위치 조회.
     */
    public Mono<Long> getzRank(String key, String value){
        return opsForZSet().rank(key, value);
    }
}

 


✔ 스트레스 테스트

고민한 설계와 개발을 끝냈으니 성능 테스트를 진행했다.
테스트 Tool 선택에 대한 고민이 컸다. nGrinder, JMeter들을 사용했으나 정확한 테스트가 진행되지 못했고, JUnit을 통해 부하 테스트를 진행했다.

시나리오

  • Connection → Subscribe → Send 와 같은 시나리오로 부하 테스트를 진행했다.

Stress Size

  • 약 15분간 총 12만건 진입
    • 분당 약 7천명
    • 초당 약 120명

결과

아래 수치를 보면 더 정확하게 확인이 가능하다.

  • Redis는 역시나 강력했고, 12만명의 동접자를 충분히 버틸 수 있는 수치가 측정되었다.
  • CPU와 RAM이 20% 까지는 쳤지만 이정도 수치를 3~4배로 가정해도 서비스가 버틸 수 있는 수치이다.

 


 

✔ 마무리

상품을 오픈하고 대기열 서비스를 오픈했었고, 큰 이슈 없이 프로모션들을 넘어갔다. 그리고 아쉽게 죽어있는 상태 ㅎㅎ
많은 사람들이 레거시에 대한 문제와 기술 도입에 대한 보수적인 의견을 가지고 있다고 생각한다.
틀린말은 아니다. 그걸 해결하고 극복하기 위해 내가 존재하며, 좋은 결과물을 도출해낼 것이다.

 

퍼옴 :

제제의 개발 발자취

반응형

'BigData > 웹대기' 카테고리의 다른 글

Redis를 사용하여 작업 대기열 구현  (0) 2023.04.03
대량접속제어 기본개념 (나무위키)  (0) 2023.04.03

+ Recent posts