Operating Services with Argo Workflows: Essential Features Guide

Introduction

Argo Workflow와 Argo Event를 PoC로 설치 및 테스트를 진행 했었습니다.
이번 글에서는 서비스에서 사용하기 위해서 필요한 기능들을 가지고있는지, 확인하고자 합니다.

Install

이전글에서는 yaml을 사용해서 설치하였지만, 편하게 관리하기 위해 Helm Chart를 사용하여 설치합니다.
공식 문서에서도 충분히 설명한 되어있어, 링크로 대체합니다.

Argo Workflow
Argo Event
Github

Workflow Archive

Workflow를 통해 Job이나 CronJob을 실행할텐데요.
Workflow, Job, CronJob이 너무 많아질 경우, Kubernetes 동작에 문제를 일으킬 수 있습니다.
따라서 일정 시간이 지난 Workflow들을 삭제해 주어야합니다.

하지만 운영상의 이유로 Workflow가 언제 어떤 파라미터를 가지고서 사용되었는지 기록되어야 할 필요가 있습니다.
이걸 대비해서 실행 이력을 저장할 수 있는 기능을 지원하는데 Archive 라고 합니다.

Argo Workflow에서 Archive 기능을 사용하기위해서는 MySQL, PostgreSQL을 지원합니다.
이번 글에서는 MySQL로 설명드리도록 하겠습니다. PostgreSQL도 비슷합니다.
만들어진 MySQL Database를 사용하려면 2가지 작업이 필요합니다.

계정 및 권한을 Kubernetes Secret으로 생성
Database Option설정

계정 및 권한을 Kubernetes Secret으로 생성

계정설정은 아래의 예시를 참고해서 작성하면 됩니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


apiVersion: v1
kind: Secret
metadata:
  labels:
    app: mysql
  name: argo-mysql-config
  namespace: argo
stringData:
  password: ${비밀번호}
  username: ${계정명}
type: Opaque

Database Option 설정

생성된 MySQL을 Argo Workflow에 사용해보면, SSL관련 에러가 발생해서 연결할 수 없었습니다.

최근 버전(v3.3.x)에서는 해당 문제가 해결되었습니다.

에러 내용으로 조금만 검색해보면 알겠지만, MySQL의 옵션을 추가해주면 손쉽게 조치가 가능합니다.
하지만 Argo Workflow 공식문서에는 이 내용이 적혀있진 않습니다.
그렇지만 Git Issue(PR)를 뒤져보면 관련된 내용이 이미 논의되었고 이미 해결되었습니다.

다음으로는 Argo Workflow를 Helm으로 설치하기 때문에, Helm Chart에서 이 기능 고려해서 template이 만들어졌는지 확인이 필요합니다.
Database 연결 정보를 ConfigMap으로 만들어서 Archive 기능을 사용할수 있게 만들어주는데, 이때 MySQL Options도 함께 ConfigMap에 포함될 수 있는지를 보면 알 수 있습니다.

다행히 링크를 보면 Options가 포함될 수 있음을 알 수 있습니다.

Structure

Argo Event에서는 다양한 이벤트를 수신받아, 원하는 Job이나 Object를 Trigger할 수 있습니다.
Argo Workflow에서는 YAML파일로 정의된 대로 Workflow를 실행하는 역할을 수행합니다.
Calendar(Cron)과 Webhook EventSource를 사용하여 Event를 발생시키고, 발생된 Event를 사용하여 Workflow를 Trigger합니다.
여기까지의 설명을 그림으로 표현하면 아래의 Flow가 됩니다.

Event Trigger Flow.jpg

Requirement

기본적으로 제공하는 기능 외에도 필요한 필수 기능과 상세정보를 기록할 수 있는지 확인해야 했습니다.
아래의 항목들이 해당됩니다.

Webhook, Cron 사용 가능
History 관리
- 수동실행시, 실행한 사람 확인가능
- 자동실행시, 실행일자 확인 가능
- 실행시 사용한 파라미터 확인가능
UI 내에서 파라미터 수동설정 가능
template 화 가능, ArgoCD(helm)(GitOps)로 운영 가능

리소스 사용량과 Webhook, Cron 이용가능여부는 확인해보았으므로, 별도로 확인하진 않겠습니다.

History 관리

아래의 3개에 항목에 대해서 확인할 수 있는 방법을 스크린샷으로 대체하였습니다.
이로서 실행주체와 실행시간, 실행옵션에 대해 상세히 기록으로 남길 수 있다는 것을 확인할 수 있었습니다.

수동실행시, 실행한 사람 확인 가능 여부

manual

자동실행시, 실행일자 확인 가능

auto

실행시 사용한 파라미터 확인 가능

detail

Template화 가능

Argo Workflow를 사용하기위해는 Workflow Spec에 맞게 yaml을 작성해야 합니다.
하지만 각 사용자가 Workflow Spec을 참고하여 yaml 작성하기 쉽지않습니다.
Helm Chart로 만들어 Template을 작성한 후 Guide를 제공한다면, Workflow Spec과는 관계없이 Example로 제공한 values.yaml만 변경해도 사용할게 있게 됩니다.
복잡도를 낮추기위해 ArgoCD의 Helm의 기능들을 최대한 활용하였습니다.

아래의 그림은 예상한 모습에 대한 Diagram과 적용하였을때 보여지는 UI입니다.

예상한 Diagram

expected_diagram

Argo Workflow Visualized

applied_diagram

Workflow Variable

Template 화 했다고 하더라도, Spring Batch의 Parameter에서는 변수를 사용해야하는 경우도 존재합니다.
예를들면, 실행한 날의 date를 사용하는 경우가 있습니다. 이런 상황에 대비해서, Argo Workflow에서 변수화 할 수 있도록 기능을 지원하고 있습니다.
Golang Template Language을 기반으로 만들어지고, 문법이 생소할 수 있고 테스트하기 어려울 수 있습니다.
상세한 내용은 다른 글에서 상세히 설명하겠습니다.

Conclusion

Argo Workflow와 Argo Event를 통합해 사용하는데에는 큰 문제가 없었습니다.
여러 요구사항들이 있었는데, Argo Workflow가 이 기능들을 지원해서 사용하는데 문제가 없는것을 확인하였습니다.