티스토리 뷰

이 문제는 아마도 모든 AWS JAVA SDK 1.0 에서 일어나는 문제일테니 주의가 필요하다..

 

S3 SDK를 처음 서버에 적용할 때도 발생했던 문제였는데, SQS 적용 과정에서도 똑같은 문제를 겪었다.

 

분명 로컬에서 테스트할 때는 잘 동작하는게, dev서버만 올라가면 제대로 동작하지 않는 문제가 있었다.

 

서버가 배포되는 과정에서 아래와 같은 WARNING을 띄웠다.

{
  "@timestamp": "2023-08-04T09:26:57.140Z",
  "message": "Ignoring queue with name '[큐이름]': The queue does not exist or no access to perform action sqs:GetQueueUrl.; 
  nested exception is com.amazonaws.services.sqs.model.QueueDoesNotExistException: The specified queue does not exist or you do not have access to it. 
  (Service: AmazonSQS; Status Code: 400; Error Code: AWS.SimpleQueueService.NonExistentQueue; Request ID: 9a2e6305-3320-517d-851d-3e43f5815a0e; Proxy: null)",
  "logger_name": "io.awspring.cloud.messaging.listener.SimpleMessageListenerContainer",
  "level": "WARN"
}

처음 배포과정에서 뜨는 WARN이라 대수롭지 않게 생각했는데, 메시지를 읽어보니 문제를 일으킬 만한 내용이었다.

 

분명 큐는 정상적으로 세팅했기 때문에 어떤 문제인지 도저히 알 수가 없었는데,

 

진짜 우연히 EKS 공식 문서를 보다가 문제를 찾았다.

 

...

 

아직 MSA로 서버가 구성되어있진 않지만 dev 서버군이 EKS로 구성되어 있었다.

 

더군다나 SQS의 의존성을 설정할 때 sqs sdk로 잡은게 아니라 이게 1.0버전인지도 몰랐었다.

implementation platform('software.amazon.awssdk:bom:2.20.56')
implementation 'io.awspring.cloud:spring-cloud-starter-aws-messaging'

dependencyManagement {
    imports { mavenBom "org.springframework.cloud:spring-cloud-dependencies:2021.0.5" }
    imports { mavenBom "io.awspring.cloud:spring-cloud-aws-dependencies:2.4.4" }
}

사실 디펜던시가 2021년인걸 보고 눈치를 챘어야했다.

 

이런 트러블 슈팅을 할 때마다 아직도 경험이 부족하다는걸 느낀다.

 

S3 문제를 해결할 때는 단순히 S3 JAVA SDK의 버전을 2.0으로 올리면서 해결됐다.

 

아마도 이 문제도 SQS의 Java SDK의 버전을 2.0으로 올리면 해결된다.

 

그러나 상용 시스템의 SQS의 버전을 올리기 위해서 aws cloud의 버전을 2022년으로 올리면서 더 큰 산을 만나게됐다.

 

이 내용은 다음 포스팅에 정리해보겠다.

공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/10   »
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31
글 보관함