Lambda, SQS, SNS (1)

"이벤트 기반 아키텍처를 구성할 때, Lambda + SQS를 사용한다."

 

이 문장을 뜯어보는 중이다.

 

일단 아래 포인트들을 알아야 한다.

1. 이벤트 기반 아키텍처가 뭐지?

2. Lambda가 뭐지?

3. SQS가 뭐지?

4. 그래서, Lambda + SQS로 이벤트 기반 아키텍처를 구성 가능한가?

이런 포인트들을 짚고 결론을 낸 후, 알아보는 과정에서 파생된 의문점들을 알아보자.

 

1. 이벤트 기반 아키텍처가 뭐지?

단어 그대로 이해하면 된다.

기존 아키텍처들은 요청과 응답을 기반으로 굴러갔다면, 이건 이벤트를 기반으로 굴러간다는 의미.

그럼 뭐가 달라지는가? 애초에 요청을 보내고 응답을 받으려면 어디로 요청을 보낼지, 응답을 어디로 보낼지 알고 있어야 한다. 해당 리소스(서버/인프라 등등)는 긴밀하게 연결되어 있어야 한다. 긴밀하게 연결되었다는 의미는 하나가 망가지면 연결된 리소스에도 문제가 발생한다는 것이다. 이러한 형태는 기존에 사용되던 모놀리스 구조(대충 일체형 구조)에서 많이 보인다.

이벤트 기반 아키텍처는 느슨한 결합을 지향한다. 이벤트 생성자(Publisher)가 발생한 이벤트를 이벤트 소비자(Consumer)에게 보내는데, 소비자가 받은 이벤트를 어떻게 사용하든 그것은 생성자의 관심 밖이다. 아니, 애초에 누가 받는지도 별 관심이 없다. 이러한 구조는 마이크로서비스 구조(MSA)에 적합한 작동 방식이다. 리소스 하나에서 문제가 발생해도 다른 리소스의 장애로 이어지지는 않기 때문이다. 

 

출처 : https://www.redhat.com/ko/topics/integration/what-is-event-driven-architecture

이벤트 기반 아키텍처란 무엇일까요?

 

자세하고 깊게 들어가기 시작하면 더 복잡하지만, 이벤트 기반 구조가 대충 저런 느낌이라고만 알고 있어도 충분하다.

느낌만 알고 있으면 필요한 상황이 닥쳤을 때 대입하는 것으로 유연하게 이해할 수 있다.

 

2. Lambda가 뭐지?

AWS에서 제공하는 Serverless 서비스다. 이벤트에 대한 응답으로 코드를 실행하고 리소스를 관리한다고 한다.

예를 들면, 어떤 이벤트를 처리하는 리소스(코드/서버 등)를 계속 작동시켜 놓는 것이 아니라 이벤트가 오면 준비된 함수/템플릿에 따라 후다닥 올려서 처리하고, 끝나면 다시 내리는 방식이다.

 

이것도 더 깊게 들어가는 것은 필요할 때 해도 늦지 않으니 느낌만 이해하자. 

 

3. SQS가 뭐지?

Simple Queue Service. AWS에서 제공하는 완전 관리형 메시지 대기열 서비스다. 이름에서 딱 보이듯 큐 구조로 굴러간다.

큐가 이벤트를 발생시킬 수는 없다. 얘는 그저 이벤트(메시지)를 받아서 쌓아두는 용도다(메시지 브로커).

 

이벤트 기반 구조에서 얘를 왜 사용하느냐?

생성자가 이벤트(메시지)를 생성하고, 소비자가 응답을 보내는 것을 기다리는 것이 아니라 그냥 브로커(SQS)에게 던지고 신경을 끊는다. 해당 이벤트의 처리가 성공했는지, 실패했는지는 생성자가 알 필요 없다.

그런데 생성자가 생성하는대로 소비자에게 막 던져대면 소비자가 제때 처리를 못하는 경우가 발생할 수 있다.

비유하자면 악기바리 식고문마냥 입에 음식이 가득 찼는데 계속 음식을 던져주는 꼴. 이러면 집어넣지 못한 음식(메시지)는 폐기되는 상황이 발생할 수 있다. 생성자가 던진 이벤트를 잠시 받아두는 역할을 하는 것이다.

큐 용량 제한이 있겠지만, 생성자는 하던대로 이벤트를 막 던지면 되고, 소비자는 처리하는대로 큐에서 다음 이벤트를 받아 처리하면 된다.

 

4. 그래서, Lambda + SQS로 이벤트 기반 아키텍처를 구성 가능한가?

가능하다. 하지만 우리가 관심있는 부분은 가능하다 아니다에서 끝나는 것이 아니다.

구축/진행 할 때 어떤 부분을 주의해야 하고, 무엇을 고려해야 하는지 조금 더 깊게 들어가 보자.

 

Lambda, SQS, SNS (2)