IT아키텍처/MSA(MicroServiceArchitecture)

메시지 큐를 사용해야하는 12 가지 이유

vell_zero 2021. 11. 8. 23:11

https://modest-developer.tistory.com/m/30

 

메시지 큐를 사용해야하는 12 가지 이유

1. 이중화를 통한 지속성 이중화는 메시지 큐의 가장 명백한 장점 중 하나이다. 보통 애플리케이션은 충돌, 시간 초과, 코드 오류 등의 기타 문제가 있다. 이는 특히 매달 수백만 또는 수십억 건

modest-developer.tistory.com

 

1. 이중화를 통한 지속성
이중화는 메시지 큐의 가장 명백한 장점 중 하나이다. 보통 애플리케이션은 충돌, 시간 초과, 코드 오류 등의 기타 문제가 있다. 이는 특히 매달 수백만 또는 수십억 건의 트랜잭션을 처리하는 애플리케이션에서 적용된다.
큐는 메시지를 읽는 프로세스를 통해 트랜잭션이 완료되었으며 제거해도 안전하다는 것을 확인함으로써 이중화를 돕는다. 만약 어떤 것이 실패한다면, 메시지는 어딘가에 저장되어 있고 손실되지 않을 것이다. 나중에 재처리할 수 있다.

 

 

2. 트래픽 폭주
응용 프로그램이 얼마나 많은 트래픽을 발생시킬지 항상 정확히 아는 것은 아니다. 예를 들어, Stackify에서 한 달에 수십억 개의 메시지를 받는다. 고객이 우리에게 무엇을 보낼지 알 길이 없다. 데이터를 대기열에 넣음으로써 우리는 높은 트래픽 급증으로 인해 평소보다 조금 더 오래 걸리더라도 데이터가 유지되고 결국 처리될 것이라고 확신할 수 있다.

 

 

3. 웹 애플리케이션 페이지로딩 시간 향상
큐는 사용자의 요청이 빨리 완료될 수 있도록 백그라운드 스레드에서 복잡한 논리를 수행하는 데 웹 응용 프로그램에서 유용할 수 있다. 만약 누군가가 당신의 웹사이트에 주문을 한다면, 그것은 일어나야만 하는 많은 다른 일들을 수반할 수 있다. 전체 메시지 큐 시스템 및 배경 앱을 사용하지 않고 사용자에게 최소 성공과 반환을 수행하고 나머지 성공 사례를 백그라운드 스레드에서 시작하십시오. 대부분의 프로그래밍 언어들은 지금 이것을 하는 방법을 가지고 있다. 예: Resque, Hangfire 등

 

 

4. 효율을 위한 일괄 처리
일괄 처리는 메시지 큐를 사용하는 좋은 이유다. 한 번에 1개씩, 100개씩 하는 대신 한 번에 100개의 레코드를 데이터베이스에 넣는 것이 훨씬 효율적이다. 우리는 ElasticSearch 와 SQL Server에 많은 데이터를 삽입한다. 일괄처리는 트랜잭션 규모를 조정함으로써 성능을 최적화할 수 있도록 도와준다.

 

 

5. 비동기 메시징
대기열은 애플리케이션에 무언가 수행이 필요하지만 지금 수행 할 필요가 없거나 결과에 신경을 쓰지 않는 시나리오에서 유용 할 수 있습니다. 웹 서비스를 호출하고 완료 될 때까지 기다리는 대신 큐에 메시지를 쓰고 나중에 동일한 비즈니스 로직이 발생하도록 할 수 있습니다. 대기열은 비동기 프로그래밍 패턴 을 구현하는 훌륭한 방법 입니다.

 

 

6. 데이터 계약을 사용하여 분리
소프트웨어의 서로 다른 부분 사이에 대기열을 사용하여 하드 종속성을 분리할 수 있다. 대기열에 있는 메시지의 형식은 당신의 데이터 계약이 되고 그 메시지 형식을 읽는 방법을 아는 모든 것이 트랜잭션을 처리하는 데 사용될 수 있다. 이것은 심지어 다른 프로그래밍 언어로 쓰여진 코드의 일부에 유용할 수 있다.

 

 

7. 트랜잭션 순서 및 동시성 문제
만약 1000명의 사람들이 한 번에 당신의 웹사이트에 주문을 한다면, 그것은 동시성과 첫 번째 주문이 먼저 끝나도록 하는 것에 약간의 문제를 야기할 수 있다. 줄을 서면 주문을 보장하고 동시에 처리되는 개수의 수를 제어할 수 있다.

 

8. 확장성 향상
메시지 큐를 사용하면 응용 프로그램의 여러 부분을 분리하고 독립적으로 확장할 수 있다. Azure, AWS 또는 기타 호스팅 솔루션을 사용하면 CPU 사용량 또는 기타 메트릭에 따라 백그라운드 서비스를 동적으로 확장할 수도 있다. 메시지 큐는 확장성과 탄력성으로 많은 도움을 줄 수 있다.

 

9. 복원력 생성
앱을 분할하고 대기열별로 서로 다른 구성 요소를 분리하면 본질적으로 더 많은 복원력을 얻을 수 있습니다. 주문 백엔드 처리의 일부가 약간 지연 되더라도 웹 사이트는 계속 작동 할 수 있습니다. Stackify에서는 다른 어떤 것도 데이터 수신 기능을 저하시킬 수 없도록 데이터를 대기열에 추가하는 것 외에 가능한 한 적은 작업을 수행하도록 들어오는 API를 설계합니다. SQL Server가 다운 되더라도 데이터를받을 수 있기를 원합니다!

 

10. 하나의 트랜잭션
메시지 큐는 트랜잭션으로 설계되었습니다. 큐에서 처리를 완료한 위치를 알려야 메시지가 대기열에서 완전히 제거된다. 이는 트랜잭션이 한 번만 발생하도록하는 데 도움이됩니다.

 

11. 큰 작업을 여러 작은 작업으로 나누기
메시지 큐의 또 다른 좋은 용도는 더 큰 작업을 많은 작은 조각으로 나눈 다음 모두 대기열에 넣는 것입니다. Stackify에 이에 대한 좋은 예가 있습니다. 서버 그룹에 대한 모니터링 템플릿을 편집하는 경우 해당 템플릿을 사용하는 모든 서버에서 모니터를 업데이트해야합니다. 우리는 모든 서버에 대한 메시지를 대기열에 넣고 잠재적으로 소규모 작업으로 동시에 수행 할 수 있습니다.

 

12. 모니터링
메시지 큐잉 시스템을 사용하면 큐에있는 항목 수, 메시지 처리 속도 및 기타 통계를 모니터링 할 수 있습니다. 이는 애플리케이션 모니터링 관점에서 데이터가 시스템을 통과하는 방식과 백업 중인지 여부를 주시하는 데 매우 유용 할 수 있습니다.

 

 

 

모든 앱에 메시지 큐가 필요합니까? 

물론 아닙니다.

그러나, 적어도 백그라운드 작업을 사용하여 오래 실행되는 일부 트랜잭션을 오프로드함으로써 웹 애플리케이션의 성능을 향상시키는 것에 대해 생각해보길 제안합니다!