사용자 지정 작업

사용자 지정 작업 배포 3가지 방법

소개

사용자 지정 작업을 배포하는 가장 빠른 방법은 무엇일까요? 워크플로를 완벽하게 사용자 지정할 수 있는 가장 활용도 높은 설정은 무엇일까요? 사용자 지정 작업을 포착하고 처리하기 위해 선택하는 환경은, 그에 따른 워크플로 단계에서 데이터를 통해 무엇을 할 수 있는지를 결정하는 중요한 요소입니다. 기본적인 옵션은 다음과 같습니다.

  1. Zapier, Integromat, Microsoft Power Automate와 같은 자동화 플랫폼을 사용하는 노코드 배포
  2. AWS Lambda나 Azure Functions와 같이 완전히 유지 관리되는 환경에서 간단한 스크립트를 ‘작업’으로 실행할 수 있는 로우코드 솔루션;
  3. 직접 실행하고 유지 관리하는 서버

이 다이어그램은 사용자 지정 작업의 아키텍처를 보여줍니다.

사용자 지정 작업 다이어그램

노코드: Zapier에 배포

Zapier의 “클릭 앤 크리에이트” 인터페이스는 Frame.io에서 인기 앱이나 생산성 도구로 에셋, 코멘트, 상태 이벤트를 전송하는 것이 목표인 기본적인 자동화에 적합한 선택입니다.

Zapier 설정

장점

  • 사용이 간편합니다. 포인트 앤 클릭 방식으로 자동화를 생성할 수 있습니다.
  • 작업 기록은 Zapier의 런타임 로그 도구로, 모든 자동화 실행 시 각 워크플로 단계의 데이터 I/O를 요약해 줍니다.
  • 프리미엄 계정을 결제하면 자동화에 분기 로직을 추가하는 도구인 Paths를 사용할 수 있습니다.

단점:

  • Zapier의 웹훅 지원은 제한적이어서, 사용자 지정 작업이 실행될 때 자세한 메시지나 Frame.io 사용자와의 상호 작용을 지원하지 않습니다. 이 제한 사항은 Zapier 지원 문서에 다음과 같이 설명되어 있습니다.
Zapier는 웹훅을 수집할 때마다 디버깅 정보 페이로드가 포함된 성공 메시지를 반환합니다. 이는 웹훅 뒤에 Zap이 있는지, 일시 중지되었는지 여부와 관계없이 동일합니다… Catch Hook URL로 보내는 요청에 대한 응답은 사용자 지정할 수 있는 방법이 없습니다. Zap이 트리거되어 웹훅 요청에서 실행되기 전에 응답이 전송되기 때문입니다.
  • 사용자 지정 작업이 제대로 작동하는지 검증할 때 Zapier의 UI는 번거로울 수 있습니다. 예를 들어 테스트 중에는 테스트 데이터를 확인하고 새로 고쳐야 합니다. 테스트 데이터가 라이브 데이터와 일치하지 않으면 Zap 설계가 실제로 정확하더라도 Zapier에서 ‘거짓 음성’을 발생시키고 오류를 표시할 수 있습니다. 작업 단계에서 File URL과 같은 필수 데이터를 필요로 할 때 해당 데이터가 없으면, Zap에 오류가 발생하거나 예상대로 작동하지 않을 수 있습니다.
이에 대한 가이드가 준비되어 있습니다!

Zapier 통합 설계 방법에 대한 광범위한 가이드와 Zapier에 사용자 지정 작업을 배포하는 방법에 대한 자세한 가이드를 작성했습니다.

로우코드: AWS에 배포

사용자 지정 작업은 AWS의 API Gateway로 전송되어 Amazon의 엄청나게 방대한 클라우드 서비스 세트와 통합될 수 있습니다. 가장 간단한 패턴은 사용자 지정 작업에 포함된 Frame.io 이벤트를 서버리스 함수를 실행하기 위한 컴퓨팅 서비스인 AWS Lambda로 전달(proxy)하는 것입니다. 다음은 파일 보관 서비스의 설계 예시입니다. AWS Lambda

장점:

  • AWS Free Tier는 서비스 요금이 부과되기 전에 매월 320만초의 컴퓨팅 시간을 제공합니다.
  • API Gateway와 Lambda는 CloudWatch 및 X-Ray와 같은 환상적인 테스트 및 모니터링 도구를 지원합니다.
  • 서비스를 확장하여 대용량 파일 크기(500GB 이상)를 지원할 수 있습니다.

단점:

  • 여러 서비스를 연결하거나(웹훅 -> API Gateway -> Lambda 1 -> Lambda 2) AWS Fargate와 같은 최신 서비스를 사용하는 방법을 배우는 데 시간이 많이 걸릴 수 있습니다.
  • AWS 설명서는 종종 오래되었거나 주요 세부 정보가 부족합니다. 예를 들어 API Gateway를 구성할 때 페이로드가 Base64로 인코딩되는지 여부를 파악하기가 쉽지 않습니다.
  • 일반적으로 구성이 약간 복잡합니다.

사용자 지정 작업을 AWS에 배포하는 전체 과정은 가이드를 참조하세요. 참고: AWS뿐만 아니라 모든 클라우드 컴퓨팅 서비스(Azure, Google Cloud Platform, Digital Ocean 등)에 사용자 지정 작업을 배포할 수 있습니다.

서버를 실행하고 자체 코드 호스팅하기

클라우드 서비스는 매우 편리하지만, 데이터를 완벽하게 제어하고자 하는 워크플로의 경우 자체 서버를 작성하고 배포하기로 결정할 수 있습니다.

DevRel 팀에서는 Python으로 FastAPI 서버를 작성하는 것을 선호합니다. 생성하기가 쉽고 사용자 지정 작업의 요청-응답 패턴과 잘 맞기 때문입니다.

장점:

  • 데이터의 엔드투엔드 흐름을 제어할 수 있습니다. 예상치 못한 변수가 전혀 없습니다.
  • 클라우드에 추가로 노출할 필요 없이 데이터를 NAS 또는 파일 시스템으로 동기화합니다.

단점:

  • 서버 관리, 자체 보안 기능 구축, 네트워크 검색, 부하 처리 등이 필요합니다.

사용자 지정 작업을 처리하기 위한 FastAPI 서버를 배포하려면 저희의 샘플 코드를 복제하세요.

고객의 요구에 가장 적합한 설계에 대해 이야기해 봅시다

커뮤니티에 요구 사항을 게시해 주시면, 귀하의 워크플로에 가장 적합한 설계를 파악할 수 있도록 기꺼이 도와드리겠습니다.