사용자가 몰릴 때 및 발송 실패 처리에 관한 문의의 件

[Iamdohyun]

사용 중인 프로그래밍 언어 및 버전

JDK 8

SDK 버전

2.2 ( nurigo:javaSDK:2.2 )

운영 환경

AWS/클라우드/호스팅 서버 등 상용 웹 서버

질문/문제 설명

최근 대규모의 인원이 2차 인증(메세지 발송)을 통해 접속하는 일이 빈번하게 발생하여 문의드립니다.
사용하는 솔루션은 쿨SMS입니다.

1. coolSms.sendOne(new SingleMessageSendingRequest(message));
   해당 함수 호출 시 return이 늦습니다.
   쇼핑몰 이벤트 진행 시 최초 오픈 시에는 사용자가 N천명 정도 몰리는 경우가 있습니다.

2. 알림톡 발송불가 케이스때 실패 처리가 너무 늦습니다.
   
   상기 사진 처럼 계속 로딩 중이고 누르면 발송 실패했다고 나와서 실패처리가 너무 늦어 문의드립니다.

코드 예시

No response

시도한 해결 방법

No response

기대하는 결과

자사가 보유한 Cool SMS 계정은 총 5개이며, 5개 계정에서 보내는 총 양은 한달 평균 46,000건 정도 됩니다.
이에, 해당 부분을 해결할 수 있는 부분이 있을지(누리고 社의 다른 솔루션을 사용하거나, 발송 건 수가 많으면 다른 조취를 해주시는 지 등) 문의 드립니다.

확인사항

• 관련 문서를 확인했습니다
• 이전 토론/이슈에서 유사한 질문이 없는지 확인했습니다
• 문의 전 읽어야 하는 사항(문의 전 꼭 읽어봐주세요! #7)을 확인했습니다

[Palbahngmiyine]

안녕하세요, 솔라피 기술지원팀입니다.
말씀하신 상황을 조금 더 자세히 파악하기 위해 관련하여 몇가지 여쭈어보고자 합니다.

첫째로 말씀주신 sendOne의 경우, 최신 Java SDK에서 제공되는(javaSDK 2.2가 아닌, 4.x 버전) 함수를 사용하시는 것으로 보입니다. 실제 발송환경이 2.2 버전의 SDK를 사용하시는 것일지 확인 부탁드리며, 그 외에 return이 늦게 반환된다는 말씀이 대략적으로 얼마나 오래걸리는 것이실지 문의드립니다.

그 외의 알림톡 실패처리 관련하여 01000000000 형식으로 발송되는 요소들은 실제 발송을 위한 통신사(알림톡이라면 알림톡 딜러사)에 전달되지 않고 내부의 별도 프로세스로 처리되는 관계로 일반 이동통신사/딜러사 메시지 그룹 처리시간에 비해 시간이 소요될 수 있습니다. 혹여 01000000000 과 같은 존재하지 않은 수신번호에도 그룹처리가 빠르게 처리되어야 하실지 문의드립니다, 그룹 처리의 경우 접수와는 별개의 프로세스로, 실제 API 호출 이후의 처리되는 과정인 점은 미리 참고 부탁드립니다.

[Iamdohyun]

두번째의 경우 그룹처리를 하기 애매한 부분이 있습니다.
자사가 이벤트를 안내하는 메세지는 그룹을 통해 발송 할 수 있지만, 사용자들이 로그인 시 2차 인증을 통해 인증 번호를 받는 것은 사용자에 의해 발송 되다 보니 그룹처리를 할 수 없습니다.(이때, 사용자 몰릴 경우 자체적으로 발송이 늦어 집니다.

결론적으로 단일 발송 시 응답이 빠른 편이지만, 사용자가 몰려서 단일 발송이 여러번 호출 되면 Cool SMS자체가 느려지는 것 같아서 해당 부분을 타개하는 방법에 대해 문의 드립니다.

[Palbahngmiyine]

다소 상호간에 착오가 발생한 것 같아서 안내 및 재문의 드리고자 합니다. 그룹처리에 대한 부분은 SDK 사용자가 API를 호출하는 과정이 아닌, SDK에서 API를 호출하는 당시는 SDK <-> API 간 접수 처리만 진행됩니다(실제 발송이 아닙니다). API 호출이 정상적으로 진행되어 메시지 접수가 완료가 되면 발송 API와 무관하게 별도 내부 프로세스를 통해 발송 및 발송 후의 전체적인 메시지 건의 대한 그룹의 상태를 처리하는 과정을 진행합니다(이는 다시 한번 말씀드리지만 SDK 이용자와는 무관한 프로세스입니다).

일련의 과정속에서 API 응답시간에 지연이 발생한다면 개선을 해야하는 사항이지만, API 외의 그룹 상태(실제 발송이 처리되기까지의 상황) 처리는 실제 알림톡 딜러사/이동통신사의 처리 응답시간에 따라 처리 시간이 상이할 수 있습니다. 또한, 01000000000 과 같은 번호를 수신번호로 적재하여 발송요청하시는 경우 앞서 안내드린바와 같이 실제 이동통신사/딜러사로 전달하는게 아닌 내부의 별도 서버 프로세스를 통해 처리하는 관계로 그룹 상태가 변경됨에 있어 실제 발송건과는 다소 차이가 있을 수 있습니다.

따라서 실제 회원님께서 API 호출자체의 응답이 지연된다라고 말씀해주시는 것일지, 혹은 실제 발송 자체(그룹 상태 처리 등)의 처리 시간에 지연이 발생된다고 말씀하시는 것일지 확인 후 답변 부탁드리겠습니다.

[Iamdohyun]

API 호출 자체의 응답이 지연됩니다.

상황 설명을 조금 더 상세하게 말씀 드리겠습니다.
작일 이벤트가 오픈하였고 사용자가 2차 인증 시 메세지를 받기 위해 몰렸습니다.
그 중 실제 번호가 아닌 가짜 번호를 넣은 사용자들로 인해 API 호출 자체의 응답이 지연되었습니다.

이에, 해당 상황을 금일 테스트 해보고자 010-0000-0000으로 테스트를 진행 하였을 때 발송 실패 처리가 되지 않는 것을 확인하여 문의를 드리게 되었습니다.

[Palbahngmiyine]

네 회원님, 그러시다면 자세한 확인을 위해 지연이 발생한 대략적인 일시, 대략적인 지연의 정도(예) 단일 SMS 발송에 API 응답이 3초 이상 소요됨, 혹은 sendOne 메소드 호출 후 3초 이상이 소요됨)를 말씀해주시면 빠르게 확인 후 답변드릴 수 있도록 하겠습니다.

그 외에 발송 요청 당시의 로그를 첨부해주신다면 문제 해결에 큰 도움이 될 것 같습니다.

[Iamdohyun]

2025년 6월 10일 10:00 ~ 10:20 사이에 coolSms.sendOne(new SingleMessageSendingRequest(message)) 메소드를 호출하는 API에서 평균적으로 30초 이상 걸리는 요청이 분당 360건을 초과한 것으로 확인되었습니다. 이러한 단기간에 반복적인 메소드 호출이 COOL SMS 측의 처리 속도에 영향을 미쳤을 가능성이 있는지 궁금합니다.

로그는 운영 쪽에서 저장 시 파일이 커지는 이슈로 인해 따로 저장하지 않아 제공이 어려운 점 양해 부탁드립니다.
계정 고유 번호: 2409 **** 9891 21
사업자: 이트너스(주) (201-81-66865)
ID: pr_bill@etners.com

[Palbahngmiyine]

회원님께서 말씀하신 계정과, 그 당시의 latency 로그를 확인했을 때에는 별다른 이상상황을 식별하지 못했습니다. 분당 360건이라고 말씀주셨었는데, 말씀하신 계정의 해당 시간대 알림톡 발송건 수는 19건으로 확인됩니다.

실제 해당 시간대 발송 API의 최대 응답시간은 일시적으로 2초로 집계되었으며(HTTP 클라이언트 <-> 서버간의 완벽히 동일한 응답 시간은 아닐 수 있습니다) 관련한 자료도 아래에 공유드리며, 실제 당사 쿨에스엠에스의 서비스가 늦게 응답이 된 것일지 번거로우시겠지만 다시 한번 확인 부탁드리며, 이후에 동일한 건이 발생될 경우 커뮤니티를 통해 문의 남겨주시면 빠르게 확인 후 답변드릴 수 있도록 하겠습니다.

[Iamdohyun]

계정고유번호: 38**16
사업자: 이트너스(주) (201-81-66865)
ID: [etners01]

죄송합니다. 계정이 너무 많아 잘못된 계정을 드린 것 같습니다.

발송 건수를 조회 했을 때 약 6000건 정도가 찍힙니다.

[Palbahngmiyine]

말씀하신 계정도 확인했을 때, 송구스럽지만 마찬가지로 별다른 이상현상을 식별하지 못했습니다.
앞서 말씀드린 바와 같이 해당 시간의 최대 API 응답시간은 2초였으며, 앞서 공유드린 이미지는 당사 발송 서비스의 전체 계정, 트래픽에 대한 응답시간 지표입니다(특이사항이 있을 때만 점의 형태로 표시되고 있습니다).

정말 송구스럽지만 실제 해당 시간대에 쿨에스엠에스 서비스가 30초 이상 지연이 발생한 것이 맞을지 다시 한번 확인 부탁드리며, 해당 응답시간 지표외에 더 필요하신 정보가 있다면 말씀해주시면 확인 후 답변드릴 수 있도록 하겠습니다.