[AWS] AWS Integration & Messaging

미들웨어로 다른 서비스간 합동 작업을 하는 방법을 살표보자.
애플리케이션을 여러 개 배포하려고 할 때 커뮤니케이션을 할 수 밖에 없다.

우리의 서비스는 정보와 데이터를 공유해야 합니다. 

• 애플리케이션 커뮤니케이션은 두 가지 패턴으로 나뉘어진다.
• 먼저 동기 커뮤니케이션이 있다.
    - 애플리케이션이 또 다른 애플리케이션과 직접적으로 연결되는 것이다. 가령 온라인으로 물건을 사고 파는 서비스가 있다고 했을 때, 물건이 판매가 되면 배송 서비스에 연락해서 방금 판매된 물건을 배송해야 한다. 위에 보실 수 있는것처럼 구매 서비스와 배송 서비스는 직접적으로 연결되어 있기 때문에 동기 커뮤니케이션이 발생하고 있다. 구매 서비스가 배송 서비스에게 사건이 발생했으니 배송을 하라고 이야기하는 거죠.
• 다른 유형의 통합은 비동기 혹은 이벤트 기반 유형이다.
    - 대기열 등으로 불리는 미들웨어가 애플리케이션들을 연결한다. 이런 경우에는 구매 서비스가 '누군가 어떤 물건을 구매했으니 이를 대기열에 포함시키겠다.'라고 한다. 그리고 끝이다. 그러면 배송 서비스가 대기열에게 최근 구매 내역이 있는지 물어본다. 대기열이 해당 요소를 반환하면 배송서비스는 자기가 원하는 것을 무엇이든지 할 수 있다. 위의 보시는 것처럼 구매 서비스와 배송 서비스는 직접 연결되어 있지 않는다. 그 사이에 대기열이 있고, 서로 직접적으로 소통하지 않기 때문에 비동기적이라고 하는 것이다.
• 애플리케이션 간의 동기화는 때때로 문제가 될 수 있다.
    - 구매가 갑자기 너무 증가했거나 한 서비스가 다른 서비스를 압도하는 경우 큰 문제가 된다.
    - 만일 비디오 인코딩 서비스에서 평소에는 10개만 인코딩 해오고 있었다면 1,000개의 비디오를 인코딩해야 하는데 인코딩 서비스가 압도될 것이고 운용이 정지되는데 그래서 트래픽이 갑자기 급증하거나 아무것도 예측할 수 없을 때, 일반적으로 애플리케이션을 분리하고 분리 계층을 확장하는 것이 좋다.
• 대기열 모델에는 SQS를 pub/sub 모델의 경우 SNS를 실시간 스트리밍을 하고 대용량 데이터를 다룬다면 Kinesis로 분리할 수 있다.