Using OnDeploy in Couchbase Eventing to Gate Mutations With Pre-Flight Setup

문제: “무국적”이 “설정이 필요 없음”을 의미하지는 않습니다.”

카우치베이스 이벤트는 돌연변이에 반응하고, 작업을 수행하고, 종료하는 단기 실행형 상태 저장소 없는 람다처럼 의도적으로 구축되었습니다. 이 모델은 이벤트 함수에 다음이 필요할 때까지는 깔끔합니다. 일회성 첫 번째 돌연변이를 안전하게 처리할 수 있습니다.

과거에는 개발자가 OnUpdate 내에서 “첫 번째 변이 워밍업'을 수행하여 이 문제를 해결했는데, 주로 CAS 안전 쓰기 또는 카운터를 사용하여 하나의 스레드만 공유 상태를 로드하도록 했습니다. 이러한 접근 방식은 효과가 있을 수 있지만 전제 조건을 설정하기 위해 변이에 의존해야 하며 설정 문제를 코드 경로의 가장 중요한 부분인 변이 처리로 밀어 넣습니다.

그렇기 때문에 이벤트에 무변형 초기화 개념, 즉 초기 변이 없이 실행하고 실제 작업이 시작되기 전에 함수를 준비할 수 있는 명시적 설정 단계가 필요했습니다.

아이디어: 비행 전 체크리스트

OnDeploy 를 실행하는 새로운 이벤트 핸들러입니다. 한 번 이벤트 함수인 경우:

배포또는
재개됨 (일시 중지된 후)

그리고 중요한 것은, 돌연변이가 처리되기 전에 실행됩니다..

이벤트 기능을 항공기처럼 생각하면 됩니다:

온업데이트 / OnDelete 는 항공편 운영입니다.
OnDeploy는 비행 전 점검입니다.
비행 전 점검이 실패한 경우, 비행기가 활주로를 벗어나지 않는 경우.

이러한 “게이트키퍼” 행동이 핵심입니다: 만약 OnDeploy 실패하면 함수는 이전 상태로 되돌아갑니다. - “잘못 구성된 로직이 실행되는” 시나리오로부터 사용자를 보호합니다.

작동 방식: OnDeploy(action)

정의하는 경우 OnDeploy 핸들러를 사용하면 이벤트 발생 함수 코드에 있는 액션 인수입니다.

function OnDeploy(action) {
  // your setup code
}

function OnDeploy(action) {

// your setup code

}

Where:

action.reason 중 하나입니다:
- “deploy”새로운 이벤트 함수 배포
- “resume”일시 중지 후 재개
action.delay 입니다:
- 0 on “deploy”
- 의 유효 일시 중지 기간(밀리초)입니다. “resume”

두 가지 중요한 안전 레일

시간 초과: OnDeploy 구성된 기간 내에 완료되어야 합니다. OnDeploy 시간 초과 (기본값: 60초). 시간 초과를 초과하면 함수 배포를 진행할 수 없습니다.
빠른 의미론: 만약 OnDeploy 는 오류를 발생시키거나 실패합니다, 돌연변이 처리되지 않음 함수는 이전 상태로 유지됩니다.

이것이 중요한 이유

OnDeploy는 단순히 “있으면 좋은 기능”이 아닙니다. 이벤트 함수를 설계하는 방식이 바뀌는 것입니다:

정확성 우선: 쓰기 로직이 실행되기 전에 전제 조건이 있는지 확인합니다.
전문 용어가 줄어듭니다: 다음에서 스레드 조정 해킹을 제거합니다. 온업데이트.
첫 번째 수정에 걸리는 시간 단축: 스레드당 캐시를 한 번만 웜 캐시합니다.

측면	온디플로이 없이	OnDeploy 사용
초기화	온업데이트(인종에 따라 다름)에서	한 번, 돌연변이 전
스레드 조정	필수	필요 없음
설치 보증	최선의 노력	장애 없는 빠른 보장
배포 안전성	조용한 장애 발생 가능	설정에 실패하면 차단됨

사용 사례

불완전한 데이터에 대한 변형을 허용하려면 먼저 조회 테이블(가격, 환율, 구성)이 필요합니다.
반복 작업(하루에 한 번, 한 시간에 한 번)을 원하지만 단지 변이를 “가짜'로 만들기 위해 타이머.
잘못된 쓰기를 조용히 생성하는 것보다 배포를 차단하는 것이 더 낫기 때문에 전제 조건이 누락된 경우 함수 실행을 거부하는 것이 좋습니다.

예 1: 조회 테이블을 한 번 워밍업한 다음 매일 새로 고침 예약하기

시나리오

장 마감 주가로 문서를 보강합니다. 가격은 외부 REST API에서 매일 가져오고, KV 문서에 저장되며, 이후 모든 변경에 사용됩니다.
OnDeploy를 사용하면 워밍업을 할 수 있습니다. 한 번, 를 사용하여 돌연변이가 처리되기 전에 보장됩니다.

코드

// Timer Callback: refresh prices daily
function RefreshPricesCallback(context) {
    log("Refreshing stock prices from API");
    var response = curl("GET", stock_api_binding, {path: '/api/eod-prices'});
    cache_bucket["lookup::eod_prices"] = response.body;
    
    // Re-schedule for tomorrow
    var tomorrow = new Date();
    tomorrow.setSeconds(tomorrow.getSeconds() + 86400); // 24 hours
    createTimer(RefreshPricesCallback, tomorrow, "refresh_prices", {});
}

// OnDeploy: initialize price cache once
function OnDeploy(action) {
    log("OnDeploy: reason=" + action.reason);
    
    // Fetch initial prices from external API
    var response = curl("GET", stock_api_binding, {path: '/api/eod-prices'});
    cache_bucket["lookup::eod_prices"] = response.body;
    
    // Schedule daily refresh timer
    var tomorrow = new Date();
    tomorrow.setSeconds(tomorrow.getSeconds() + 86400);
    createTimer(RefreshPricesCallback, tomorrow, "refresh_prices", {});
    
    log("Price cache initialized and refresh timer scheduled");
}

// OnUpdate: enrich documents with cached prices
function OnUpdate(doc, meta) {
    var prices = cache_bucket["lookup::eod_prices"];
    
    doc.stockPrice = prices[doc.symbol];
    doc.enrichedAt = new Date().toISOString();
    
    dst_bucket[meta.id] = doc;
}

// Timer Callback: refresh prices daily

function RefreshPricesCallback(context) {

log("Refreshing stock prices from API");

var response = curl("GET", stock_api_binding, {path: '/api/eod-prices'});

cache_bucket["lookup::eod_prices"] = response.body;

// Re-schedule for tomorrow

var tomorrow = new Date();

tomorrow.setSeconds(tomorrow.getSeconds() + 86400); // 24 hours

createTimer(RefreshPricesCallback, tomorrow, "refresh_prices", {});

}

// OnDeploy: initialize price cache once

function OnDeploy(action) {

log("OnDeploy: reason=" + action.reason);

// Fetch initial prices from external API

var response = curl("GET", stock_api_binding, {path: '/api/eod-prices'});

cache_bucket["lookup::eod_prices"] = response.body;

// Schedule daily refresh timer

var tomorrow = new Date();

tomorrow.setSeconds(tomorrow.getSeconds() + 86400);

createTimer(RefreshPricesCallback, tomorrow, "refresh_prices", {});

log("Price cache initialized and refresh timer scheduled");

}

// OnUpdate: enrich documents with cached prices

function OnUpdate(doc, meta) {

var prices = cache_bucket["lookup::eod_prices"];

doc.stockPrice = prices[doc.symbol];

doc.enrichedAt = new Date().toISOString();

dst_bucket[meta.id] = doc;

}

이 로직의 장점은 다음과 같습니다:

“첫 번째 돌연변이가 설정을 한다”는 놀라움은 없습니다.
내부 교차 스레드 복잡성 없음 온업데이트.
모든 돌연변이는 전제 조건이 갖춰진 상태에서 시작됩니다.

예 2: OnDeploy를 사용하여 배포와 다시 시작을 다르게 처리하기

시나리오

때로는 “업무 일정'이 아니라 다음과 같은 일을 해야 할 때도 있습니다. 기능을 안전하게 시작(또는 안전하게 다시 시작).

예를 들어 이벤트 함수는 다음에 따라 달라질 수 있습니다:

외부 데이터(최초 배포 시 cURL 바인딩을 통해 가져올 수 있음) 및
구성(일시 중지 후 다시 로드해야 함)을 저장합니다.

이는 다음을 수행할 수 있기 때문에 OnDeploy에 매우 적합합니다. 라이프사이클에 따른 브랜치 동작 기능이 준비되었는지 확인합니다. 전에 모든 돌연변이를 처리합니다.

코드

function OnDeploy(action) {
  log('OnDeploy triggered. Reason:', action.reason);
  switch (action.reason) {
    case 'deploy':
      // First-time deployment: fetch initial data needed by the function.
      log('Bootstrapping: Performing first-time setup...');
      bootstrap_external_data();
      break;
    case 'resume':
      // Function was paused and resumed: refresh any cached settings.
      log('Configuration changed. Reloading settings...');
      reload_config_from_bucket();
      break;
  }
}

function OnDeploy(action) {

log('OnDeploy triggered. Reason:', action.reason);

switch (action.reason) {

case 'deploy':

// First-time deployment: fetch initial data needed by the function.

log('Bootstrapping: Performing first-time setup...');

bootstrap_external_data();

break;

case 'resume':

// Function was paused and resumed: refresh any cached settings.

log('Configuration changed. Reloading settings...');

reload_config_from_bucket();

break;

}

이 패턴은 라이프사이클 로직을 명확하고 깔끔하게 유지합니다:

배포 는 일회성 부트스트랩 작업을 수행하는 순간이 됩니다.
이력서 는 일시 중지 후 구성을 조정/새로 고치는 순간이 됩니다(action.delay 일시 중지된 시간을 알려줍니다).
변이 핸들러는 전제 조건이 이미 충족되었다고 가정할 수 있으므로 비즈니스 로직에 집중할 수 있습니다.

디자인 지침: 무엇을 not 온디플로이에서 수행할 작업

OnDeploy는 강력하지만 의도적으로 제약이 있습니다:

보관 짧은 그리고 결정론적.
배포를 지연시킬 수 있는 장기 실행 루프를 피하세요.
전제 조건의 유효성을 검사하고, 공유 상태를 초기화하고, 작업을 예약한 다음 종료하는 등 인프라 코드처럼 취급하세요.

결론

OnDeploy는 단일 변이가 처리되기 전에 전제 조건이 충족되는지 확인하는 기능으로 Couchbase Eventing에 근본적인 변화를 가져왔습니다. 이제 초기화 로직을 여러 변이 핸들러에 분산하거나 경쟁이 치열한 워밍업 해킹에 의존하는 대신, 한 번만 실행되고 문제가 발생하면 빠르게 실패하는 명시적인 단일 사전 검사 기능을 사용할 수 있습니다.

결과는? 코드가 더 깔끔해지고, 배포가 더 안전해지며, 이벤트 함수가 항상 정상 상태로 시작된다는 확신을 가질 수 있습니다.

사용해 볼 준비가 되셨나요? OnDeploy는 Couchbase Server 8.0 이상에서 사용할 수 있습니다. 아래 설명서를 확인하여 시작하고 기존 이벤트 함수 중 이 패턴을 활용할 수 있는 것이 무엇인지 생각해 보세요.

참조

히렌 바바스카르, 소프트웨어 엔지니어

이 문서 공유하기

Platform

Self-Managed

Services

Capabilities

Why Couchbase?

Migrate to Capella

By Use Case

By Industry

By Application Need

Popular Docs

By Developer Role

Quickstart

Resource Center

About

Partnerships

Our Services

Partners: Register a Deal

Ready to register a deal with Couchbase?

Marriott

카우치베이스 이벤트에서 온디플로이를 사용하여 비행 전 설정으로 돌연변이를 게이트하기

문제: “무국적”이 “설정이 필요 없음”을 의미하지는 않습니다.”

아이디어: 비행 전 체크리스트

두 가지 중요한 안전 레일

이것이 중요한 이유

사용 사례

예 1: 조회 테이블을 한 번 워밍업한 다음 매일 새로 고침 예약하기

시나리오

코드

예 2: OnDeploy를 사용하여 배포와 다시 시작을 다르게 처리하기

시나리오

코드

디자인 지침: 무엇을 not 온디플로이에서 수행할 작업

결론

참조

받은 편지함에서 카우치베이스 블로그 업데이트 받기

작성자

게시자 히렌 바바스카르

댓글 남기기 응답 취소

카우치베이스 카펠라를 시작할 준비가 되셨나요?

구축 시작

카펠라 무료 사용

연락하기