API에 이벤트 달기

Jun Hwang

API Eventing Is The Next Big Opportunity For API Providers

API에게 이벤트 달기

지난 10 년 여 동안 최신 웹 API는 Flickr와 같은 솔루션에서 새로운 비즈니스 모델을 생성하는 강력한 플랫폼으로 성장했습니다. 이 성장 기간 동안 대부분의 API는 HTTP를 통한 요청-응답으로 제한되었습니다. 이제 SaaS 솔루션을 연결하는 Webhook의 인기, 내부 메시징을 구동하는 Kafka와 같은 기술의 도입, IoT 장치 통합의 필요성과 함께 이벤팅으로 다시 돌아가고 있습니다. API 이벤트는 API 소비자가 API와 상호 작용하는 방식을 완전히 바꿔놓아서 요청-응답이 할 수 없는 새로운 가능성을 만듭니다. API 이벤트 지원을 API에 추가하는 것을 여러 분이 고려하도록 영감을 줄 기회와 함께 API 이벤트 발생에 기여하는 추동 요인 (driving factors)을 살펴 보겠습니다.

왜 여러분의 API가 이벤트를 지원해야 할까요?

이유 1: API 이벤트는 혁신을 주도합니다.

GitHub 플랫폼에 WebHooks가 도입됨에 따라 소프트웨어 개발이 크게 바뀌었습니다. 팀은 더 이상 빌드 프로세스를 버튼을 클릭하여 명시적으로 시작할 필요가 없습니다. 매일 또는 매시간 빌드를 생성한다는 아이디어는 과거의 일이 되었습니다. 대신 팀은 새 코드가 GitHub에 푸시 될 때마다 빌드 프로세스를 시작할 수 있습니다. Post-commit hooks는 항상 svn 및 git의 일부 였지만, GitHub는 이러한 이벤트 스트림을 전체 웹에 걸쳐 확장했습니다. 클라우드 공급 업체의 API와 결합 된 WebHooks는 팀이 자신이 선택한 어떤 환경에서든지 코드를 구축하고 배포 할 수있게 해주며, 모두 WebHooks에 의해 구동됩니다.

이유 2: API 이벤트는 협업을 가능하게 합니다.

HipChat 및 Slack과 같은 메시징 플랫폼은 팀원들이 협업하는 방식을 변화 시켰습니다. 이러한 팀 메시징 플랫폼은 bots와 command-line 자동화를 통합 할 기회를 열었습니다. 그 결과 기존의 IRC 및 그룹 채팅을 뛰어 넘는 새로운 커뮤니케이션 방법이 탄생했습니다. 이를 위해, 이러한 플랫폼은 요청-응답 API와 실시간 이벤트 스트리밍의 조합을 제공하여 외부 앱, 봇 및 API를 플랫폼에 원활하게 통합 될 수 있도록 합니다.

이유 3: API 이벤트는 코드 없는 통합을 주도합니다.

SaaS (Software-as-a-Service) 제품은 점점 더 통합을위한 API를 제공하고 있습니다. Zapier(link) 나 IFTTT와 같은 iPaaS (Integration Platform as a Service) 도구는 복-붙 없이 많은 공통 작업을 자동화하기 위해 서로 연결 할 수 있게 지원합니다. 많은 iPaaS 제품은 사용자를 대신하여 코드마저도 호스팅 해주기 때문에 서버와 인프라를 관리 할 필요가 없습니다.

이러한 종류의 통합은 항상 코드 작성을 요구하지는 않지만, API에서 제공하는 트리거 유형에 따라 제한됩니다. API가 요청 / 응답 지원만 제공하는 경우에는, 클라이언트는 중요한 데이터에 변경 사항이 있는지 확인하기 위해 폴링을 해야합니다. API 이벤트를 통해, 이러한 도구들은, 데이터가 변경 될 때 트리거 (해당 이벤트)를 수신하고 요구되는 자동화 흐름을 실행할 수 있습니다.

이유 4: API 이벤트는 유연한 아키텍처를 생성합니다.

점점 더 많은 팀이 전체 솔루션의 일부를 이해하는 데 필요한 인지 부하를 줄여 복잡한 솔루션 주변에 경계를 설정하는 방법으로서 마이크로 서비스 아키텍처를 탐색하고 있습니다. 이 모든 것은 신속하게 기능을 제공 할 수 있는 소규모의 독립적인 팀을 만들어서 제공 속도를 높이는 것을 목표로 수행됩니다. 느슨하게 결합된 마이크로 서비스 아키텍처의 결과로 서비스는 비즈니스 워크플로우를 구동하는 데이터 변경 및 주요 비즈니스 이벤트를 다른 마이크로 서비스에 알리는 이벤트를 내 보냅니다.

또한 서버리스 세계 안에서 function-as-a-service (FaaS)가 부상하고 있습니다. 전체 애플리케이션을 배포하는 대신 더 작은 기능이 배포 된 다음 메시지 기반 이벤트 또는 요청 / 응답 스타일 호출을 제공하는 API 게이트웨이를 통해 트리거 됩니다.

Kafka, RabbitMQ 또는 Amazon SNS / SQS와 같은 메시징 브로커는 종종 마이크로 서비스 이벤트를 유도하고 함수 기반 서비스 (function based service)를 트리거하는 데 사용됩니다. 이는 내부 메시징에 대한 유효한 솔루션이지만 외부화를 위해 설계되지 않았습니다. 이벤트를 외부화하는 경우 소비자가 WebHook, event streaming, 또는 어쩌면 일부 상황에서는 덜 효율적인 long-polling의 조합을 사용하여 이벤트를 소비하는 방법을 고려해야 합니다.

이유 5: 이벤트는 사물인터넷과 엣지 컴퓨팅을 위한 접착제 입니다.

집이나 사무실 주변에 스마트 기기가 있을 것입니다. 이러한 장치는 웹 또는 모바일 장치의 중요한 데이터 및 이벤트를 시각화하기 위해 종종 클라우드 서비스와 통신합니다. 공급 업체가 제공하는 클라우드 기반 API를 통해 IoT 서비스와 통합하면 타사 자동화 솔루션이 이러한 장치의 유용성을 확장 할 수 있으므로 이벤트 스트리밍의 이점을 얻을 수 있습니다.

일부 장치 통합 시나리오의 경우 클라우드 리소스에 대한 네트워크 연결이 보장되지 않거나 생성 된 데이터의 양이 클라우드로 전송되기 전에 평가 및 집계가 필요할 수 있습니다. 이를 '에지 컴퓨팅'이라고 하며, 특히 고대역폭을 항상 사용할 수 있지는 않은 제조 및 에너지 산업에서 수년 동안 일반적이었습니다.

이제 엣지 컴퓨팅이 차세대 IoT 장치의 일부로 등장 할 것이라는 신호가 있습니다. 에지 장치가 서로 통합되고 로컬 네트워크의 스마트 컨트롤러 장치와 통합하려면 이벤트 스트리밍이 필요합니다. IoT 용 API를 구축하는 경우 이벤트 스트리밍은 에지 커뮤니케이션 및 컴퓨테이션에 필수적 입니다.

여러분의 API 가 이벤트 구독(Event Subscriptions)을 제공해야 할까요?

API 이벤트는 일상적인 문제를 해결하기 위해 API를 사용할 때 API에 필요한 대화의 종류를 확장합니다. 우리는 팀이 API 이벤트를 추가하여 API 대화를 강화할 수 있는 방법을 고려하도록 권장합니다. 이벤트 지원이 없으면 API는 단순히 사용자가 요청 하기만을 기다리게 됩니다. 이벤트 지원이 추가됨으로써, 비로소 API는 다른 API 및 애플리케이션과 양방향 대화를 할 수 있습니다. 이를 통해 더 나은 사용자 경험을 제공하고 API 채택을 크게 확대하게 되어 소비자의 이탈을 줄입니다.