크론으로 예측 가능한 트래픽은 미리 스케일링할 수 있지만 패턴을 벗어난 상황은 그렇지 못했습니다. 이벤트 기반으로 워크플로를 실행하기 위해 Argo Events를 도입하며 EventBus·EventSource·Sensor를 구성한 과정과 트러블슈팅을 정리했습니다. || 들어가며
안녕하세요, 비브로스에서 DevOps 엔지니어로 일하고 있는 박도준입니다.
최근 비브로스에 새롭게 합류하여 온보딩 기간을 거쳐 첫 업무를 맡게 되었습니다. 해당 업무는 Argo Events를 사내에 도입하는 것이였습니다. 이번 글에서는 "왜" Argo Events를 도입하는지와 "어떻게" 구성하고 사용하는지 공유드리려 합니다.
배경
저희 똑닥 서비스는 실시간 병원 접수 및 예약 서비스을 제공하고 있습니다.
현재 대부분의 유저들은 병원 접수, 예약 기능을 이용하기 위해 똑닥 서비스를 사용하기 때문에 병원 이용을 많이 하는 시간대에 서비스 트래픽이 몰리는 현상이 있습니다.
이러한 현상은 요일별 그리고 시간대별로 상이하지만 어느 정도 패턴화가 되었기 때문에 크론 작업을 통해 매일 인프라 스케일링 동작이 수행되도록 자동화해두었습니다.
하지만 위와 같이 정기적이고 패턴화된 상황이 아닌 경우도 있습니다. 
마케팅 이벤트
연휴 다음날
연휴날은 대부분 병원도 휴무인 경우가 많기 때문에 연휴 다음날 아침 평소대비 트래픽이 증가하는 경향이 있습니다.
이런 경우에 이전에는 (1)마케터분들께 마케팅 이벤트 관련 정보를 미리 받거나 (2)연휴 전날 수작업으로 크론 작업을 새롭게 생성하여 등록하는 번거로운 방식으로 운영해왔습니다.
물론 크론 작업에 대한 정의를 helm chart로 관리하여 템플릿화했지만 이벤트에 따라 달라지는 설정값들을 일일이 수정하여 배포까지 해줘야했기 때문에 조금은~~(많이)~~ 귀찮은 작업이였습니다.
똑닥 서비스가 계속해서 성장하고 확장됨에 따라 이러한 이벤트가 더욱 비번하게 발생할 것으로 예상되어 해당 프로세스를 개선할 필요성이 점점 더 커지게 되었습니다.
그래서 왜 Argo Events야?
배경을 읽으셨다면 대충 'Argo Events를 통해 앞선 문제를 해결했겠구나'라는 것을 알 수 있을 것입니다.
??? : 그래서 어떻게 해결했어?!?
바로 본론으로 들어가기에 앞서 Argo Events가 무엇이고 왜 Argo Events를 선택했는지부터 간단히 공유드리겠습니다.
Argo Events란?
Argo Events의 공식 Docs에 나와있는 소개글을 번역해보면 아래와 같습니다.
Argo Events는 webhook, S3, 스케줄 등을 다양한 소스들의 이벤트에서 k8s 객체, Argo workflows, 서버리스 워크로드 등을 트리거할 수 있도록 지원하는 kubernetes용 이벤트 기반 워크플로우 자동화 프레임워크입니다.
간단하게 정리하면 다양한 이벤트들을 통해 k8s 객체나 Argo Workflows 등을 트리거하여 자동화된 워크플로우를 제공하는 서비스입니다.
Argo Events Architecture
Argo Events의 구성요소와 아키텍처는 아래와 같습니다.
위 아키텍처 그림에 잘 표현되어 있지만 구성 요소에 대해 간단하게 살펴보겠습니다.
Event Soucre : AWS SNS, Webhooks 등과 같은 외부 소스의 이벤트를 사용하는데 필요한 구성을 정의
지원하는 이벤트 타입
Event Bus : EventSource와 Sensor를 연결하는 전송 계층 역할
NATS는 deprecated 되기 때문에 Jetstream과 Kafka 이렇게 2가지 선택지가 존재
Sensor : 일련의 이벤트 종속성(입력) 및 트리거(출력)를 정의
Sensor 당 하나 이상의 Trigger를 가질 수 있으며, 이를 통해 다양한 워크플로우를 실행할 수 있음
Argo Events 선택 이유
저희 팀에서 Argo Events를 선택한 이유는 크게 3가지입니다.
1. 이벤트 기반(Event-Driven) 아키텍처 구축
이전에는 직접 크론 작업을 직접 작성해서 등록해야했지만, Argo E
마케팅 이벤트
연휴 다음날
연휴날은 대부분 병원도 휴무인 경우가 많기 때문에 연휴 다음날 아침 평소대비 트래픽이 증가하는 경향이 있습니다.
이런 경우에 이전에는 (1)마케터분들께 마케팅 이벤트 관련 정보를 미리 받거나 (2)연휴 전날 수작업으로 크론 작업을 새롭게 생성하여 등록하는 번거로운 방식으로 운영해왔습니다.
물론 크론 작업에 대한 정의를 helm chart로 관리하여 템플릿화했지만 이벤트에 따라 달라지는 설정값들을 일일이 수정하여 배포까지 해줘야했기 때문에 조금은~~(많이)~~ 귀찮은 작업이였습니다.
똑닥 서비스가 계속해서 성장하고 확장됨에 따라 이러한 이벤트가 더욱 비번하게 발생할 것으로 예상되어 해당 프로세스를 개선할 필요성이 점점 더 커지게 되었습니다.
그래서 왜 Argo Events야?
배경을 읽으셨다면 대충 'Argo Events를 통해 앞선 문제를 해결했겠구나'라는 것을 알 수 있을 것입니다.
??? : 그래서 어떻게 해결했어?!?
바로 본론으로 들어가기에 앞서 Argo Events가 무엇이고 왜 Argo Events를 선택했는지부터 간단히 공유드리겠습니다.
Argo Events란?
Argo Events의 공식 Docs에 나와있는 소개글을 번역해보면 아래와 같습니다.
Argo Events는 webhook, S3, 스케줄 등을 다양한 소스들의 이벤트에서 k8s 객체, Argo workflows, 서버리스 워크로드 등을 트리거할 수 있도록 지원하는 kubernetes용 이벤트 기반 워크플로우 자동화 프레임워크입니다.
간단하게 정리하면 다양한 이벤트들을 통해 k8s 객체나 Argo Workflows 등을 트리거하여 자동화된 워크플로우를 제공하는 서비스입니다.
Argo Events Architecture
Argo Events의 구성요소와 아키텍처는 아래와 같습니다.
위 아키텍처 그림에 잘 표현되어 있지만 구성 요소에 대해 간단하게 살펴보겠습니다.
Event Soucre : AWS SNS, Webhooks 등과 같은 외부 소스의 이벤트를 사용하는데 필요한 구성을 정의
지원하는 이벤트 타입
Event Bus : EventSource와 Sensor를 연결하는 전송 계층 역할
NATS는 deprecated 되기 때문에 Jetstream과 Kafka 이렇게 2가지 선택지가 존재
Sensor : 일련의 이벤트 종속성(입력) 및 트리거(출력)를 정의
Sensor 당 하나 이상의 Trigger를 가질 수 있으며, 이를 통해 다양한 워크플로우를 실행할 수 있음
Argo Events 선택 이유
저희 팀에서 Argo Events를 선택한 이유는 크게 3가지입니다.
1. 이벤트 기반(Event-Driven) 아키텍처 구축
이전에는 직접 크론 작업을 직접 작성해서 등록해야했지만, Argo E