일단 진행시켜

[legacy] JMS+SQS → 레거시에 대한 나의 생각 본문

🗞️ 보안 동향 파악 및 나의 생각 정리

[legacy] JMS+SQS → 레거시에 대한 나의 생각

2024. 8. 23. 17:10

1. Using SQS With JMS for Legacy Applications

https://dzone.com/articles/using-sqs-with-jms-for-legacy-applications

 

Using SQS With JMS for Legacy Applications - DZone

In this article, take an in-depth look at the steps to integrate a legacy Java application with SQS through JMS.

dzone.com

 

 

 

[ 요약 ]

Amazon SQS를 Java Message Service(JMS)와 통합하여 레거시 애플리케이션이 클라우드 기반 메시징 시스템에서 작동할 수 있도록 하기 위한 업데이트  방법이 설명되어 있다.

Java Message Service(JMS)는 엔터프라이즈 시스템에서 일반적으로 사용되는 메시징 프로토콜인 반면,

SQS는 AWS의 확장 가능한 클라우드 기반 메시징 큐다.

SQS 호환 Java Message Service(JMS) 클라이언트 라이브러리를 사용하면 레거시 애플리케이션은 SQS 큐를 통해 원활한 메시지 송수신이 가능하여, 최신 클라우드 인프라와 상호 작용할 수 있다.

위와 같은 접근 방식을 통해 이전 시스템의 기능은 유지하면서 클라우드로 원활한 전환이 가능하다.

 

주요 아키텍쳐 변경 없이 레거시 애플리케이션을 클라우드로 마이그레이션 한다는 점이 강점이다.

 

 

Amazon SQS를 JMS와 통합하여 레거시 애플리케이션 업데이트 ?

위 내용만 보면 말이 어려워서 이해가 잘 안 간다.

그래서 다시 알아봤다.

그전에, 레거시 애플리케이션에 대한 이해가 필요하다.

 

레거시 애플리케이션?

legacy: 유산. 현재까지 남아 사용되고 있거나 현재의 체계에 영향을 미치는 과거의 체계.

  • legacy application: 오래된 소프트웨어 시스템
  • 오랜 기간 동안 사용되었고, 기존의 환경과 기술에 의존하는 애플리케이션
  • 비즈니스적으로 중요한 역할을 하지만 유지 관리 및 확장이 어려움

 

즉, 레거시 애플리케이션이라 불리는 JMS는 오래됐지만 중요해서 유지 관리 및 확장을 함부로 하기엔 무리가 있는 프로토콜이다.

 

이제 내가 준비한 예시를 보자.

[예시]

회사에는 여러 부서가 있다.
여러 부서 간에 소통은 회사 운영에 있어 중요하다.
과거에는 부서 간 소통을 위해 '메모'를 주고받았다. 이것이 Java Message Service(JMS)다.
메모가 아니라, 오래된 메시징 시스템=JMS라고 생각해야 한다!

반면, AWS SQS는 새롭고 빠른 최신 메시징 시스템이다.
모든 것을 처음부터 다시 만드는 대신, SQS 호환 JMS 라이브러리와 같은 특수 도구를 사용하여 기존 메일 시스템을 새 클라우드 시스템에 연결할 수 있다.
이렇게 하면 기존 핵심 로직을 변경하지 않고도 최신 클라우드 기술을 적용할 수 있다.

 

AWS SQS = 클라우드에서 작동하는 확장 가능하고 빠른 메시징 서비스
JMS = 오랫동안 사용된 전통적인 메시징 프로토콜


두 시스템을 연결하면 기존 레거시 애플리케이션이 클라우드 인프라와 상호작용할 수 있게 되어,

처음부터 손댈 필요 없이 클라우드 기술로 전환할 수 있다!

 

 

 


 

🤔 이에 대한 나의 생각

오래됐지만 필수적인 무언가를 새로운 것과 접목시켜 업데이트하되, 기존의 것을 유지하는 행위는 어느 분야에나 다 존재하나 보다.

레거시 시스템은 늘 없어져야 할 골칫거리라고 생각했는데 이것만이 가져다주는 핵심 장점을 잘 활용하는 것 또한 프로그래머에게 필요한 능력이라는 생각이 든다.

 

나는 그 장점이 '지속성'이라고 생각한다.

레거시가 왜 레거시인가? 웃기지만 레거시니까.

오래됐기 때문에 레거시인 거다.

근데, "오래된 시스템"이 되기 위해서는 그만큼 오랜 시간 사용자들이 사용하고

hw/sw가 계속 작동하고, 네트워크가 지원되어 왔음을 의미한다.

 

오래 유지되어 왔다는 것은 그만큼 필요하기 때문이 아닐까.

그리고 그만큼 쌓아져 온 신뢰 또한 절대 무시 못 한다.

 

이 '지속성'을 유지하여 신기술을 발전 및 업데이트하는 행위는 리스크 부분에서 이롭다고 생각한다.

1부터 10까지 하나하나 만드는 것보다 기존에 있던 거와 융합하는 것이 실패 가능성을 상당히 줄일 수 있기 때문이다.

(반반 합친다고 했을 때, 이미 반은 검증이 되어있으니까!)

 

오늘 기사

매우 흥미롭고 재밌었다.