Knative 연구하기(Eventing)

반응형

Knative Eventing 연구하기

안녕하세요 김민욱입니다.

 

이전 포스팅에서 ServingAuto Scaling에 대해서 알아보았습니다. Knative는 서버리스 서비스의 라이프사이클 뿐만아니라 서비스로 전달되는 다양한 이벤트를 관리하거나 혹은 이벤트를 직접 생성할 수있는 기능을 제공하고 있습니다. 

 

따라서 이번 포스팅에서는 Eventing에 속해 있는 개념들과 이러한 Eventing들이 제공하는 다양한 기능들에 대해서 설명드리겠습니다. 

 

Knative Eventing

서버리스 서비스들을 개발하는 개발자들은 이벤트를 기반으로하여 다양한 서비스들을 개발할 수 있습니다. Knative Eventing에서는 특히 이벤트를 생성하는 이벤트 생성자와 이벤트를 수신하는 이벤트 컨슈머등의 개념을 기반으로 기능을 제공하고 있습니다. 

 

Knative Eventing에서는 표준 HTTP POST를 통해 이벤트를 송수신하게 되는데, 이러한 이벤트 형식들은 모두 CloudEvents Specifications 표준을 따르게 됩니다. 

그림 1. Knative Eventing Pods 

Knative Eventing은 두개의 Pod로 구성되어 있고, 이름에서 알수 있는 것처럼 Controller에 의해 모든 기능들이 제공되어지게 됩니다. 따라서 해당 Pod의 역할은 코드레벨에서 추후 분석할 예정이고 이제 Eventing에서 나오는 주요한 개념과 이벤트 송수신 방법들에 대해 설명 드리겠습니다.

 

Eventing은 Source라는 개념을 가지고 있는데, 외부 이벤트들(e.g. AWS SQS,Kafka, GCP Pub/Sub)에게 리소스를 읽어서 이를 이벤트 대상자에게 전달하거나, Cronjob처럼 스스로 이벤트를 생성하여 전달하는 개념입니다.

 

Sink는 이벤트를 수신할 대상을 의미하는데,  그림 2와 같이 이벤트 Source를 생성할 때 Sink를 명시하여 수신할 대상을 지정할 수 있게 됩니다 .

그림 2. Evneting Sink

Eventing Source와 Sink 개념만으로도 이벤트를 생성하고 수신할 수 있는데 해당 구조는 그림 3과 같습니다.

그림 3. 간단한 이벤트 송수신 예
그림 4. Source yaml

그림 3과 같이 간단하게 이벤트를 생성하고 수신할 수 있는 구조는 그림 4의 Yaml을 통해 작성할 수 있습니다. 먼저 일반적인 CronJob의 개념과 동일한 Source의 CronJobSource는 주기적으로 Data를 Sink에 작성된 서비스에게 작성하게 됩니다. 따라서 CronJobSource를 통해 이벤트를 생성하고 Sink를 통해 대상 서비스에게 이벤트를 전달합니다. 

 

이외에도 Channel, Subscription을 통한 이벤트 전달 방법이 존재합니다. Channel은 이벤트를 전달하기 위한 일종의 버퍼로 GCP Pub/Sub, Kafka와 같은 외부 프로젝트의 이벤트들 뿐만아니라 이벤트를 메모리에 저장하고 불러와 전달하는 In Memory 방식들을 제공하고 있습니다. 

 

그림 5. Channel Object Yaml

하지만 Channel은 단순히 메세지를 전달하기 위해 일종의 저장소이기 때문에 해당 이벤트를 서비스로 전달하기 위한 전달자 역할을 하는 컴포넌트가 필요합니다. 이러한 컴포넌트가 바로 Subscription으로 Channel과 Service사이에서 이벤트를 전달하는 역할을 합니다.

 

그림 6. Channel - Subscription 기반 이벤트 
그림 7. Channel - Subscription Yaml

그림 6에서 보이는 것처럼 이벤트를 서비스로 전달하기 위해 Source로부터 생성된 이벤트는 Channel에 저장되고, Subscription을 통해 Service로 전달됩니다. 그림 7에서 보이는 Yaml 내용에서는 대상 channel과 대상 service를 명시하는 것을 보실 수 있습니다. 

 

다음은 Broker와 Trigger를 통해 이벤트를 전달하고 필터링하는 내용을 확인해 보겠습니다. 먼저 Broker는 일종의 이벤트 수신을 위한 엔드포인트입니다. 

그림 8. Broker 생성 방법

그림 7에서 namespace의 라벨링하여 broker를 설정하거나, Knative CLI인 kn을 통해 직접 broker를 생성하혹은 yaml을 통해 생성할 수도 있습니다.  

 

그림 9. Trigger Yaml

그림 9에서는 Trigger Yaml을 나타내는데, Trigger는 Broker가 수신한 이벤트들을 다양한 조건에 맞게 필터링하여 Service로 전달하는 역할을 합니다. 

 

그림 10 Trigger-Broker 이벤트

그림 10에서 보이는 것처럼 Source를 통해 이벤트를 생성하고 이는 Broker(엔드포인트)로 전달됩니다. Trigger는 자신이 필터링할 조건을 보고있다가, 특정 이벤트가 발생하면 해당 이벤트를 자신에게 등록되어있는 Service에게 전달하게됩니다.

 

결론

이번 포스팅에서는 Eventing에 대해서 알아보았습니다. Eventing은 다양한 방법으로 이벤트를 전달할 수 있는 기능들을 제공하고 있습니다. 따라서 해당 Eventing Source 등의 기능을 이용하여 다양한 시도를 해볼 수 있을 것같습니다.

오류가 있다면 말씀주시면 수정하겠습니다.  읽

어주셔서 감사합니다.

인용글

업데이트로그

--------------------------------------------------------------------------------------------------------------

해당 글은 스스로 연구한 내용을 통한 주관적인 이해를 바탕으로 작성 되었습니다. 수정 할 부분이 있거나, 다른 의견이 있으시다면 언제든지 말씀해주시면 반영하도록 하겠습니다. 읽어 주셔서 감사합니다. 끝으로 불법으로 복제하는 것은 금합니다.

 

반응형

댓글

Designed by JB FACTORY