오픈소스를 업무에 도입할 땐, 항상 참조하는 오픈소스의 문서화가 잘 되어 있는지를 확인하자.
이제 회사에서 내게 주는 업무가 본격적으로 중요도가 높아지면서, 하나씩 실제 AI와 밀접한 연관성을 갖는 것들이 주어지기 시작했다.
물론 여태까지도 간접적으로는 운영 서버에서 ML Pipeline components를 하나씩 도입해 나가기는 했지만, 타 부서와 직접적으로 밀접한 커뮤니케이션을 하면서 작업을 하게 된 것은 이번이 처음이다.
Flyte를 도입하면서 전사적으로 사용하기 위해 고민해야하는 포인트들이 무척 많아서(RBAC, Resource Management, Authorization…) 현재는 베타 서비스로 운영하면서 전사 배포 전 다양한 Use Case 등을 확인하고 있는데, 사내 AI 부서 중 한 곳에서 이번에 Production에 사용되는 부분을 Flyte에 직접 사용하고 싶다는 얘기가 나오게 되었고, 이번 주에 해당 사항이 배포가 되었다. (스타트업 정신…!)
Flyte 서비스와 관련해서 Github action을 사용해 CI를 관리하는 것은 나중에 설명할 것이지만 (또 개편될 예정이라 정리가 충분히 필요하다) Flyte를 사용하기 위해서는 익혀야하는 여러 CLI 등이 있어서, 해당 부분은 CI로 자동화 시켰고, 이 글에서 설명하고자 하는 것은 Flyte의 Notification에 대한 내용이다.
1. 쉬운 내용 notification, 그러나 누락된 official flyte docs 설명
사실 notification은 구현하는 것이 어려운 내용은 아니다.
요새 notification에 관련한 글들을 찾아보면, slack/telegram/email 등으로 지원 안하는 것이 없고, 개발 초급자들도 관련 자료 조금만 찾아보면 적용하기 쉬울 정도로 정리가 잘되어 있고, 이를 가능하게 하는 것이 cloud에서 제공하는 notification 관련 서비스들이 풍부하게 잘 갖춰진 것도 한 몫을 하고 있다.
문제는 이 쉬운 내용을 서비스의 기본이 되는 플랫폼에서 어떻게 사용할 수 있는지 안내하는 공식 문서 설명이 잘 되어 있어야하는데, Flyte는 안타깝게도 적용 과정에서 누락된 부분들이 종종 보인다.
특히, flyte 문서를 읽다보면 flyte 자체가 k8s native 플랫폼이라 k8s 사용 방법에 대한 기본 지식을 전제하고 설명하는 경우가 꽤 있는데, flyte를 SDK로 사용할 때와 k8s에 플랫폼으로 띄울 때, 구성하는 방식이 유독 난이도가 많이 다르다고 느껴지는 것은 공식문서의 영향이 큰 것으로 느껴진다.
flyte를 사용해서 notification을 발송하는 것도 결국은 k8s에서 설정이 되어 있는 것을 전제로 하는데, 하필 이 내용이 AWS 설정 사항과 관련해 조금 누락된 것이 있어 하루만에 할 수 있는 것을 일주일이나 시간을 소요하게 만들었다.
2. Flyte Admin Core의 낮은 버전으로 인한 configmap 에러
flyte는 현재 국내에서 사용하고 있는 업체를 찾는 것이 매우 어렵기 때문에, 서비스를 구성하기 위해서는 공식문서와 커뮤니티에 의존할 수 밖에 없는 경우가 발생한다.
때문에 notification 파트의 공식문서를 참조해서 values.yaml에 해당 설정 내용을 추가해주고, 배포하니 아래와 같은 에러가 발생했다.
에러가 발생하면 구글링하면 되는데, 문제는 이 케이스에 대해 구글링을 해도 flyte 사용층이 워낙 작아 구글링에 키워드가 안걸린다.
찾다찾다 flyte slack 커뮤니티에서 해당 내용을 문의해보니, flyte helm chart의 flyte-core에서 configmap에 해당 하는 내용 중 notification.yaml 에 설정되어 있는 template string에 tpl이라는 파싱값을 제거하라는 답변을 받았다.
처음에는 values.yaml에서 project / workflow / phase 등 설정된 template string에 대해 사용자가 직접 지정해줘야하는 것으로 생각했는데, 공식 문서 어디에도 그런 내용은 설명이 없었기 때문에 helm 내부에서 해당 내용을 인지할 것이라 생각했다.
문제는 내가 겪었던 반환한 에러 사항이 notification.yaml에 적용된 내용을 추론하기 힘들 정도로 연관성이 없어서, 찾느라 꽤 고생했다.
결국 저 단순한 템플릿 스트링 하나 때문에 배포하는 과정에서 시간을 소비하고, 개발 서버(운영서버 업로드 전 테스트 진행이 이뤄지는 서버)에 정상적으로 배포가 되었다.
3. AWS에서 발생하는 에러
사실상 k8s에서 notification 설정이 끝났다면, aws에서 메일링을 제공하는 것은 무척이나 쉽기 때문에 이 작업도 금방 끝날 것이라 생각했다.
근데, 또 다시 공식문서에서 누락된 설명으로 삽질을 크게 했다.
먼저 공식 문서 설명에 따르면, AWS만을 notification 서비스를 활성화할 때 사용 가능하다는 것을 볼 수 있다.
현재 회사에서 GCP & AWS를 함께 사용하고 있기 때문에 flyte 상황에 맞춰 AWS에 다음 서비스들을 생성하게 되었다.
첫번째로 SNS는 Simple Notification Service의 약자로, 애플리케이션 및 사용자간 통신을 위해 사용되는 완전 관리형 메시징 서비스이다.
쉽게 말해, Flyte에서 작업 중인 workflow에 상태 변화가 발생하면 (Success, Failure, Queued, Aborted) 사용자가 특정 상태에 대해 메일링 서비스를 launch plan으로 등록 가능하고, 등록된 메일에 대해 SNS로 메일을 뿌려주는 역할을 하는 것이다.
SQS는 Simple Queue Service의 약자로 SQS는 SNS에서 발급된 notification을 받아 처리하는 역할을 수행한다. 즉, notification을 queue에 넣어 처리하는 것이라 보면 된다.
SES는 Simple Email Service로 이메일로 안내를 전달할 때, 해당 이메일을 발급하는 주체를 등록하는 서비스다.
내가 이해한 바를 구조적으로 표현하면 다음과 같을 것이다.
AWS 공식문서에서 SES / SQS / SNS를 쓱 훑어보니, 내용이 어려운 건 아닌 것이라는 것을 알겠고 (단순 queue를 클라우드에 옮겨놓은 느낌) 구성을 진행했는데, Console UI를 통해 생성한 것이 아니라 Pulumi라는 IaC 툴을 사용해서 클라우드에 스크립트로 해당 서비스들을 생성하게 되었다.
다 끝났다…! 싶어서 flyte에 내 메일을 등록하고 메일이 오는지 확인해보니, 아무리 봐도 메일이 오지 않았다.
이상한 것은 flyte에서 Admin을 통해 메일은 분명히 발송되었다.
그렇다면 AWS에서 Flyte를 통해 보낸 메일이 안왔다는 것이고 이를 확인하는 절차를 수행했다.
함께 문제를 해결하기 위해 AWS CLI로 경과를 확인하던 리드 개발자님께서 SNS/SQS의 로그를 확인해보니, 이 쪽에 문제가 있던 것 같다.
SNS/SQS를 생성하면서, 혹시 모를 Access Policy 이슈가 있을 것을 염두해서 공식문서에서 권장하는대로 서비스 생성 이후 콘솔에서 다음 사항을 정책으로 반영했다.
그러나 SNS / SQS 모두 정책 설정을 해봐도, 여전히 flyte-admin에서 메일 발급되었다는 경과만 확인될 뿐, 정상 메일은 도착하지 않았다.
뭐가 문제지..? 하면서 리드 개발자님과 AWS 관련 내용을 찾다가 문득 IAM 설정을 리드 개발자님이 떠올렸다.
지금 사용 중인 계정 IAM 좀 볼까요?
결국 IAM 설정을 SQS, SNS에 대해 풀어놓으니,,, 원하는 결과가 드디어 메일링으로 도착했다.
4. 모든 일의 원인은 공식 문서의 부족한 설명…
문제를 해결하고 나서, 프로덕트 팀에서 메일링이 잘 도착한다는 결과를 확인하고 나서 잠시 한 숨을 돌리면서 어디서 많은 시간을 뺏었는지 결과를 돌이켜봤다.
Flyte Notification 등록 → AWS 서비스 생성 → 결과 메일 도착이라는 단순한 프로세스에서 AWS 정책 & IAM 설명의 공식 문서상 부재는 시간을 뺏기에 충분했다.
다행이도 코드 상의 에러는 아니라서, 코드를 고치고 나서 오픈소스 레포에 PR하는 상황은 만들어지지 않았지만, 아마 오픈 소스 코드가 만능은 아니기 때문에 중간 중간 문제점을 찾으면 PR해서 다른 사람들도 시간을 아낄 수 있도록 지원해야겠다는 생각이 들었다.
5. 이제는 Flyte Contribution에 참여해서 한 번 커뮤니티 잘 만들어보자.
flyte는 생각보다 잘 만들어져 있는 ML Pipeline 플랫폼이다.
지금 AI 프로덕트 관련 팀이 상용 서비스에 flyte를 이용하고 있다는 사실 하나만으로도 빠르게 도입이 가능하다는 반증이고, Airflow 로는 관리가 잘 안되는 버전 등을 용이하게 다루기 때문이다.
다만, 문서도 그렇고 코드에 대한 설명도 커뮤니티에 문의를 안하면 구글링으로 찾기 어렵기 때문에, 내 스스로도 Flyte에 컨트리뷰션을 해야겠다는 생각이 이번 주에 들었다.
오픈 소스 컨트리뷰션은 취준생 때 많이 했지만, 직장 다니면서 하려니 오픈 소스 코드에 기여하려는 부분이 끝이 없어서 계속하게 된다는 장점(?)이 있다.
아직 MLOps 생태계가 굉장히 활발하게 커지고 있는 만큼 (MLOps 춘추전국시대) 어떤 플랫폼이 살아남을지는 잘 모르겠다.
그러나 Lyft에서도 Flyte 생태계를 키워가고 싶은 욕구가 분명하고 (flyte문의에 대한 답변이 2시간 이내로 빠르게 온다) 내가 워낙 자주 물어보다 보니, 이제는 나보고 컨트리뷰션 해달라는 제의(?) 아닌 제의도 계속 물어보고 있다.
갈 길이 멀어서 막막한데, 고등학교 때부터 꾸준히 느꼈던거라 목표를 정하면 꾸준히 나아가기만 하면 되겠다.
근데 Flyte 컨트리뷰션하려면 GoLang 부터 알아야겠네…? ㅎㅎ
Ryan
