서버리스 오픈소스 - knative #2 비동기 처리를 위한 Eventing

Serveless를 위한 오픈소스 KNative #2 Eventing

조대협 (http://bcho.tistory.com)

knative의 다른 모듈로써는 비동기 메세지 처리를 위한 eventing 이라는 모듈이 있다. 카프카나, 구글 클라우드 Pub/Sub, AWS SQS와 같은 큐에서 메시지를 받거나 또는 Cron과 같은 타이머에서 이벤트가 발생하면 이를 받아서 처리할 수 있는 비동기 메커니즘을 제공하는 모듈이라고 보면 된다.

메시지 큐나 cron 과 같이 이벤트를 발생 시키는 자원들은 knative에 event source 라는 Custom Resource로 등록이 되고, 등록된 event source는 이벤트가 발생되면 지정된 knative 서비스로 이벤트 메시지를 HTTP로 전송한다. 이때 이벤트를 받는 knative 서비스는 앞에서 언급한 knative serving의 서비스이다. 이때 이벤트에 대한 스펙은 CNCF Serverless WG 에서 정의한 CloudEvents 스펙에 기반한다.

Hello Eventing

자세하게 Eventing에 대해서 알아보기 전에 간단한 예제를 살펴보자. 예제는 knative.dev의 cronjob  예제이다.  Crontab으로 이벤트를 생성하면, event-display 라는 서비스에서 이 이벤트를 받아서 이벤트의 내용을 간략하게 로그로 출력하는 예제이다.

먼저 이벤트를 읽어드릴 event-display 서비스를 배포하자. 해당 서비스는 HTTP post로 받은 이벤트의 내용을 log로 출력해주는 코드로 이벤트의 포맷은 앞에서 설명한 CloudEvent의 포맷을 따른다.

Go 로 구현된 코드이며, 코드 원본은 여기에 있다.

 해당 컨테이너를 배포하기 위해서 아래와 같이 service.yaml 파일을 만들고, kubectl apply -f service.yaml 을 이용해서 배포하면, crontab 에서 이벤트를 받는 serving 인스턴스가 준비된다.

apiVersion: serving.knative.dev/v1alpha1 kind: Service metadata:  name: event-display spec:  runLatest:    configuration:      revisionTemplate:        spec:          container:            image: gcr.io/knative-releases/github.com/knative/eventing-sources/cmd/event_display

<그림. Event consumer용 knative 서비스 배포>

다음 Crontab event 소스를 아래와 같이 yaml로 정의한다.

apiVersion: sources.eventing.knative.dev/v1alpha1 kind: CronJobSource metadata:  name: test-cronjob-source spec:  schedule: "*/2 * * * *"  data: '{"message": "Hello world!"}'  sink:    apiVersion: serving.knative.dev/v1alpha1    kind: Service    name: event-display

<그림. Crontab event source 정의>

spec>schedule 부분에 이벤트 주기에 대한 설정을 crontab 포맷을 따라서 하고, data 부분에 cron 이벤트가 발생할때 마다 보낼 데이타를 정의한다.

데이타를 보낼 목적지는 sink 부분에 지정하는데, kind에 타입을 정의하고 (여기서는 knative의 Service로 지정) 그리고 service 의 이름을 name에 정의한다. 앞에서 knative serving 서비스를 event-display로 지정하였기 때문에, 서비스명을 event-display로 정의한다.

yaml 파일 설정이 끝났으면 kubectl apply -f  명령을 이용해서 이벤트 소스를 등록하고, 동작을 하는지 확인해보도록 하자.

%kubectl logs -l serving.knative.dev/service=event-display -c user-container --since=10m

명령을 이용하면 앞에서 배포한 event-display 서비스의 로그를 볼 수 있는데, 결과를 보면 다음과 같다.

Data 부분에서 crontab 이벤트 소스에서 보내온 “message”:”Hello world!” 문자열이 도착한것을 확인할 수 있다.

Eventing detail

이벤트는 앞의 예제에서 본것과 같이 이벤트 소스에서 바로 Knative 서빙에서 받아서 처리하는 가장 기본적인 비동기 이벤트 처리 패턴이다.

Broker & Trigger

이러한 패턴이외에도 좀 더 다양한 패턴 구현이 가능한데, 두번째가 Broker와 Trigger이다. Broker는 이벤트 소스로 부터 메시지를 받아서 저장하는 버킷 역할을 하고, Broker에는 Trigger를 달 수 있는데, Trigger에는 메시지 조건을 넣어서, 특정 메시지 패턴만 서비스로 보낼 수 있다. 위의 패턴에서 필터를 추가한 패턴으로 보면 된다.

이해를 돕기 위해서 예제를 보자. 다음은 knative.dev 공식 사이트에 나와 있는 예제중에, Google Cloud Pub/Sub Source를 Broker로 연동하는 예제이다.

# Replace the following before applying this file: #   MY_GCP_PROJECT: Replace with the GCP Project's ID. apiVersion: sources.eventing.knative.dev/v1alpha1 kind: GcpPubSubSource metadata:  name: testing-source spec:  gcpCredsSecret:  # A secret in the knative-sources namespace    name: google-cloud-key    key: key.json  googleCloudProject: MY_GCP_PROJECT  # Replace this  topic: testing  sink:    apiVersion: eventing.knative.dev/v1alpha1    kind: Broker    name: default

<그림. github-pubsub-source.yaml>

위의 코드는 GCP Pub/Sub Source를 등록하는 부분인데, sink 부분은 이 소스에서 오는 메시지를 어디로 보낼지를 정하는 부분이다. 위에 보면 Broker로 보내는것을 볼 수 있다. Broker는 Default Broker로 보낸다.

다음은 Broker에서 받은 메시지를 Trigger 조건에 따라서 Knative Serving 서비스로 보내는 설정이다.

apiVersion: serving.knative.dev/v1alpha1 kind: Service metadata:  name: event-display spec:  template:    spec:      containers:      - # This corresponds to        # https://github.com/knative/eventing-sources/blob/release-0.5/cmd/event_display/main.go                   image: gcr.io/knative-releases/github.com/knative/eventing-sources/cmd/event_display@sha256:bf45b3eb1e7fc4cb63d6a5a6416cf696295484a7662e0cf9ccdf5c080542c21d --- # The GcpPubSubSource's output goes to the default Broker. This Trigger subscribes to events in the # default Broker. apiVersion: eventing.knative.dev/v1alpha1 kind: Trigger metadata:  name: gcppubsub-source-sample spec:  subscriber:    ref:      apiVersion: serving.knative.dev/v1alpha1      kind: Service      name: event-display

< 그림. Trigger와 이벤트 메시지를 수신하는 Service를 정의한 부분>

서비스는 event-display라는 서비스를 정의하였고, 그 아래 Trigger 부분을 보면 gcppubsub-source-sample 이라는 이름으로 Trigger를 정의하였다. Broker 명을 정의하지 않으면 이 Trigger는 default broker에 적용된다. 별다른 조건이 없기 때문에, Broker의 모든 메시지를 대상 서비스인 event-display로 전달한다.

Channel & subscription

다음 개념은 Channel과 subscription 이라는 개념인데, Channel을 메시지를 저장 후에, Channel에 저장된 메시지는 메시지를 수신하는 Subscription을 통해서 다른 Channel로 포워딩 되거나 또는 Service로 전달 될 수 있다.

<그림. Channel과 Subscription 개념도>

앞에서 Channel에서는 메시지를 저장한다고 했는데, 그러면 저장할 장소가 필요하다. 저장할 장소는 설정으로 다양한 메시지 저장소를 사용할 수 있는데, 현재 메모리, Apache Kafka 또는 NATS Streaming을 지원한다.

간단한 예제를 살펴보자 예제는 이 문서를 참고하였다

먼저 아래 설정을 보자

apiVersion: sources.eventing.knative.dev/v1alpha1 kind: GcpPubSubSource metadata:  name: testing-source spec:  gcpCredsSecret:  # A secret in the knative-sources namespace    name: google-cloud-key    key: key.json  googleCloudProject: knative-atamel  # Replace this  topic: testing  sink:    apiVersion: eventing.knative.dev/v1alpha1    kind: Channel    name: pubsub-test

< 그림. GCPPubSub Event Source 정의한 코드>

위 설정은 GCP Pub/Sub을 Event source로 등록하는 부분이다. 이벤트 소스로 등록 한후에, 이벤트를 sink 부분에서 pubsub-test라는 Channel로 전달하도록 하였다.

다음 아래는 Channel을 정의한 부분인데, pubsub-test 라는 이름으로 Channel을 정의하고 "provisioner” 부분에, 메시지 저장소를 "in-memory-channel” 로 지정해서 메모리에 메시지를 저장하도록 하였다.

apiVersion: eventing.knative.dev/v1alpha1 kind: Channel metadata:  name: pubsub-test spec:  provisioner:    apiVersion: eventing.knative.dev/v1alpha1    kind: ClusterChannelProvisioner    name: in-memory-channel

< 그림. Channel 정의한 코드>

apiVersion: serving.knative.dev/v1alpha1 kind: Service metadata:  name: message-dumper-csharp spec:  runLatest:    configuration:      revisionTemplate:        spec:          container:            # Replace {username} with your actual DockerHub            image: docker.io/{username}/message-dumper-csharp:v1 --- apiVersion: eventing.knative.dev/v1alpha1 kind: Subscription metadata:  name: gcppubsub-source-sample-csharp spec:  channel:    apiVersion: eventing.knative.dev/v1alpha1    kind: Channel    name: pubsub-test  subscriber:    ref:      apiVersion: serving.knative.dev/v1alpha1      kind: Service      name: message-dumper-csharp

< 그림. Serving과 subscription을 정의 코드>

Channel에 저장된 메시지를 다른 Channel로 보내거나 또는 Service로 보내려면 Subscription을 거쳐야 한다. 위에서 gcppubsub-source-sample-charp이라는 subscription을 정의하였고, 이 subscription이 연결되는 Channel은 spec > channel 부분에 아래와 같이 정의 하였다.

aspec:  channel:    apiVersion: eventing.knative.dev/v1alpha1    kind: Channel    name: pubsub-test

< 그림. 위의 Subscription 정의에서 Channel 정의 부분>

그리고 그 채널에서 받은 메시지를 subscriber > ref 부분에서 아래와 같이 message-dumper-charp이라는 서비스로 포워딩 하도록 하였다.

subscriber:    ref:      apiVersion: serving.knative.dev/v1alpha1      kind: Service      name: message-dumper-csharp

< 그림.위의 Subscription 정의에서 Service 정의 부분>

전체적으로 Eventing 모듈을 이해하는데 시간이 많이 걸렸는데, Eventing 모듈은 Serving 모듈에 비해서 예제가 적고, 공식 문서에 아직 설명이 부족하다. 예를 들어서 소스 → 서빙으로 메시지를 보낼때 스케일링할 경우 문제가 없는지. Channel → subscription 으로 메시지를 보낼때 Trigger를 사용할 수 있는지 등 정보가 아직 부족해서 자세한 분석이 어려웠다. Knative는 현재 0.5 버전으로 버전이고, Event Source 들도 아직 개발 단계가 아니라 PoC (Proof Of Concept : 기술적으로 가능한지 테스트를 하는 단계) 단계 이기 때문에 제대로 사용하기에는 시간이 더 걸릴 듯 하다.