간단하지만 강력한 이벤트:
이벤트 를 사용하면 작은 스크립트로도 해결하기 어려운 문제를 극복할 수 있습니다.
카우치베이스와 이벤트에 모두 익숙하다면 간단한 개요를 건너뛰고 다음 단계로 넘어가세요. 예제.
개요:
먼저, 기본 사항을 살펴보겠습니다. 이벤트 수명 주기.
아래 단계는 이벤트 함수를 작성하고 사용하는 것이 얼마나 쉬운지 보여줍니다.
- 카우치베이스 서버의 UI를 통해 이벤트 함수를 추가(또는 가져오기)합니다.
- 데이터 소스, 스크래치패드 버킷, 바인딩을 할당하여 문서를 조작하거나 외부와 소통할 수 있습니다.
- 수신된 변이를 처리하기 위해 자바스크립트 코드를 구현합니다.
- 새 함수를 저장하고 "배포"를 누르세요.
이제 전체 클러스터에서 데이터 세트의 변이에 실시간으로 응답하는 분산 함수가 생겼습니다.
Eventing 서비스는 인프라가 필요 없는 플랫폼을 제공하여, 데이터 저장소나 서비스 클라이언트의 일회성 급증 또는 월별 증가 등 비즈니스 성장에 따라 이벤트 함수를 확장할 수 있으며, 자바스크립트 기반 이벤트 함수가 강력하고 안정적인 병렬 분산 방식으로 실행된다는 사실에 대한 걱정 없이 사용할 수 있습니다. 카우치베이스 이벤트에 대해 더 자세히 알아보려면 이벤트 개요 문서에서 확인할 수 있습니다.
아래 이 글의 예시는 경우에 따라 이벤트가 애플리케이션의 움직이는 부분을 '확보'하는 데 필요한 한 방울의 기름과 같은 역할을 할 수 있음을 보여줍니다.
주문에 따라 구축한 데이터베이스를 카우치베이스화하세요:
저는 Couchbase 클러스터를 확장 가능한 상호 운용 가능한 "마이크로 서비스"의 집합이라고 생각합니다. 이러한 서비스는 특정 운영 및 비즈니스 요구 사항을 충족하도록 함께 연결하고 규모를 조정할 수 있습니다.
카우치베이스는 6개의 주요 서비스에서 리소스 간섭을 최소화하면서 다차원 확장(MDS)을 제공합니다. 또한 각 카우치베이스 서비스는 노드를 추가하는 것만으로 독립적으로 확장할 수 있습니다. 이를 통해 고객은 당면한 작업에 대해 가능한 가장 낮은 TCO로 이상적인 멀티노드 클러스터를 만들 수 있습니다.
- 데이터 노드를 쉽게 확장하여 단일 및 다중 레코드 조회를 위한 대규모의 JSON 인식 KV 작업을 매우 빠르게 제공할 수 있습니다. 제가 방금 "단일 및 다중 레코드 조회의 경우 매우 빠릅니다."네, 그랬어요. 하지만 이 점을 강조하고 싶어요.
- 쿼리 노드는 쉽게 확장하여 인덱스를 제공할 수 있으며, 기본적으로 JSON 문서와 함께 작동하는 SQL 개선 사항인 N1QL도 제공하므로 프로그래머는 새로운 사고 방식을 배울 필요 없이 빠르게 시작하고 실행할 수 있습니다.
- 인덱스 노드는 쉽게 확장하여 일부 또는 모든 N1QL 쿼리의 속도를 높일 수 있는 유연한 인덱스를 제공합니다.
- 검색 노드는 언어 인식 검색, 결과 점수 매기기, 빠른 FTS 기반 인덱스 등 자연어 쿼리 기능을 위한 전체 텍스트 검색을 제공하도록 쉽게 확장할 수 있습니다,
- 분석 노드는 병렬 데이터 관리 기능으로 쉽게 확장되어 대규모 데이터 세트에서 대규모 임시 조인, 집합, 집계 및 그룹화 작업과 같은 복잡한 쿼리를 효율적으로 실행할 수 있습니다.
- Eventing 서비스는 개발자가 데이터 변경(또는 변이)을 처리하고 실시간으로 대응하는 데 사용할 수 있는 컴퓨팅 패러다임을 제공하기 위해 쉽게 확장할 수 있습니다.
모든 제품 라인과 마찬가지로 Couchbase 쿼리, 검색, 이벤트, 분석의 최신 서비스에는 몇 가지 사마귀가 있지만 전체적으로 보면 전체 바구니는 통합된 제품군 또는 수많은 문제를 해결할 수 있는 원스톱 상점을 제공합니다. 통합 제품에 관심이 없고 FTS만 사용하려는 경우라면 Elasticsearch 사용을 고려할 수도 있지만, FTS 결과를 N1QL(JSON용 SQL)과 통합해야 하는 경우라면 그냥 Couchbase로 시작하는 것이 훨씬 더 나을 수도 있습니다.
오늘은 1) 데이터 노드가 제공하는 기본 KV 서비스 2) 이벤트 서비스, 이 두 가지 서비스만 활용하겠습니다. 몇 가지 작은 자바스크립트 함수를 통해 이벤트 서비스를 활용하여 규모에 따른 몇 가지 어려운 문제를 어떻게 극복할 수 있는지 살펴보겠습니다.
전제 조건 / 이벤트에 대해 알아보기:
이 글에서는 최신 GA 버전, 즉 Couchbase 버전 6.5.1을 사용합니다.
그러나 카우치베이스 또는 이벤트 서비스에 익숙하지 않은 경우 시작하기와 이벤트 예시를 구체적으로 참조하세요:
- 의 지침에 따라 작동하는 Couchbase 6.5.1 서버를 설정합니다. 여기서 시작하세요!
- 의 지침에 따라 기본 이벤트 기능을 배포하는 방법을 이해합니다. 데이터 강화 예를 들어 '사례 2'에서는 '소스' 버킷 하나만 사용합니다.
이벤트를 통한 데이터 보강:
일반적인 고객 문제
라이브 프로덕션 시스템에는 수십억 개의 문서가 저장되어 있습니다. 기존 데이터를 보강해야 하는 새로운 비즈니스 요구 사항이 발생했습니다. 이러한 추가 데이터 요구 사항은 전체 문서 세트에 영향을 미칩니다. 운영상의 영향은 오래된 데이터 또는 과거 데이터와 새로운 데이터 또는 변화하는 데이터를 모두 포함합니다. 비즈니스는 프로덕션 시스템을 중단 없이 계속 가동하고 새로운 실시간 데이터에 지속적으로 대응해야 합니다.
다소 인위적인 예제 애플리케이션으로 GeoIP 조회 서비스를 생각해 보겠습니다. 이 유틸리티는 IPV4 주소 범위별로 국가를 조회할 수 있는 데이터 세트가 필요합니다. 초기 구현에서는 다음과 같이 레코드를 저장했습니다:
|
1 2 3 4 5 6 |
{ "type": "IP_COUNTRY_MAP", "country": "RU", "ip_start": "7.12.60.1", "ip_end": "7.62.60.9" } |
몇 달 후 새로운 비즈니스 요구 사항이 변경됩니다. 엔지니어링 팀은 새로운 필드를 추가하여 JSON 문서를 보강해야 했습니다. 기존 IPV4 주소 두 개에 대한 숫자 표현을 포함해야 했습니다.
|
1 2 3 4 5 6 7 8 |
{ "type": "IP_COUNTRY_MAP", "country": "RU", "ip_end": "7.62.60.9", "ip_start": "7.12.60.1", "IP_NUM_START": 118242305, "IP_NUM_END": 121519113 } |
구조 이벤트
최소한의 리소스로 문제를 해결하기 위해 14줄의 간단한 자바스크립트(주석 2개 포함) 이벤트 함수를 작성하고 배포할 수 있습니다.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
함수 온업데이트(doc, 메타) { 만약 (doc.유형 !== "IP_COUNTRY_MAP" ) 반환; doc["IP_NUM_START"] = GET_NUMIP_FIRST_3_OCTETS(doc["ip_start"]); doc["IP_NUM_END"] = GET_NUMIP_FIRST_3_OCTETS(doc["ip_end"]); // src는 설정에서 소스 버킷의 버킷 별칭입니다. src[메타.id]=doc; } 함수 GET_NUMIP_FIRST_3_OCTETS(IP) { 만약 (!IP) 반환 0; var 부품 = IP.분할('.'); // IP 번호 = A x (256*256*256) + B x (256*256) + C x 256 + D 반환 = (부품[0]*(256*256*256)) + (부품[1]*(256*256)) + (부품[2]*256) + parseInt(부품[3]); } |
위의 함수를 "피드 경계"를 "모든 문서"로 설정하여 배포하면 모든 유형의 문서가 처리됩니다: "ip_country_map" 유형의 모든 문서가 처리되고 보강됩니다.
이벤트 함수는 모든 새로운 삽입 또는 업데이트(또는 변이)에 실시간으로 반응하여 새로운 항목을 보강하고, "ip_start_num" 또는 "ip_end_num"이 적절한 "숫자" 표현으로 변경되면 기존 항목도 업데이트하는 '배포'된 상태로 유지됩니다.
문서가 보강되었기 때문에(이전 필드는 여전히 존재) 기존 프로덕션 애플리케이션은 계속 작동합니다. 모든 신규 또는 변경된 데이터는 실시간으로 새 스키마로 업데이트됩니다. GeoIP 애플리케이션 구성 요소는 이 간단한 이벤트 기능을 통해 분리되어 한 번에 하나씩 업그레이드할 수 있습니다.
모든 프로덕션 컴포넌트가 업데이트되면 이벤트 함수를 배포 해제하고 폐기할 수 있습니다.
이벤트 발생을 통한 오래된 데이터 제거:
일반적인 고객 문제
라이브 프로덕션 시스템에는 70억 개가 넘는 문서가 저장되어 있습니다. 모든 문서에는 자동 만료(또는 TTL )를 설정합니다. 프로덕션 환경은 지속적으로 새로운 데이터를 수신하고 오래된 데이터를 지속적으로 만료합니다.
운영상의 실수로 20억 개의 문서가 만료되지 않은 채로 생성되었습니다.
고객은 더 이상 유용하지 않은 활성(0이 아닌 TTL)이 없는 데이터를 선별하고 제거하기 위해 N1QL을 활용하는 대규모 인덱스를 생성할 리소스가 없거나 리소스 비용을 지불하고 싶지 않았습니다.
구조 이벤트
6줄의 간단한 자바스크립트(이 중 2줄은 코멘트) 이벤트 함수를 배포하여 최소한의 리소스로 문제를 해결했습니다.
|
1 2 3 4 5 6 |
함수 온업데이트(doc, 메타) { 만약 (메타.만료 !== 0) 반환; // TTL 또는 만료가 0인 모든 항목 삭제 // src는 설정에서 소스 버킷의 버킷 별칭으로, 삭제합니다. 삭제 src[메타.id]; } |
위의 함수를 '피드 경계'를 '모든 문서'로 설정한 상태에서 배포하면 소스 버킷에 있는 전체 문서가 스캔되었습니다. TTL이 0이 아닌 모든 문서(만료일이 없다는 의미)는 무시되었습니다. TTL이 0보다 큰 일치하는 문서만 삭제됩니다.
소스 버킷이 정리되면 이벤트 기능은 관리 도구로 사용되었기 때문에 배포가 취소되었습니다.
자바스크립트에서 만료 !== 0 테스트를 대체하여 필요한 목적에 따라 데이터를 필터링할 수 있습니다.
아래에서 우리가 무엇을 하고 있는지 짐작하기는 꽤 쉽습니다:
|
1 2 3 4 5 6 |
함수 온업데이트(doc, 메타) { 만약 (!(doc.유형 === "customer"&& doc.활성 === false)) 반환 // 고객을 버킷 aias arc에 아카이브하고 버킷 별칭 src에서 제거합니다. arc[메타.id] = doc; 삭제 src[메타.id]; } |
실제로 위의 내용을 쉽게 업데이트하여 고객뿐만 아니라 주문, 반품 및 배송 주소와 같은 기타 관련 정보도 계단식 아카이브를 수행하고 삭제할 수 있습니다. 다음 예시를 참조하세요. 캐스케이드 삭제 이벤트 문서에서 확인할 수 있습니다.
Eventing을 통해 민감한 데이터 제거:
일반적인 고객 문제
프로덕션 환경에서 온프레미스로 Couchbase를 실행 중인 한 회사는 고객 프로필 정보(1억 5천만 건 이상)를 공유해야 했습니다. 이 회사의 비즈니스 파트너도 클라우드 제공업체인 AWS에서 Couchbase를 실행하고 있었습니다.
다음과 같은 일반적인 프로필 레코드가 있다고 가정해 보겠습니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 |
{ "type": "마스터_프로필", "first_name": "Peter", "last_name": "Chang", "id": 80927079070, "기본_프로필": { "partner_id": 80980221, "서비스": [ { "음악": true }, { "라디오": true }, { "video": false } ] }, "민감한_프로필": { "ssn": "111-11-1111", "credit_card": { "숫자": "3333-333-3333-3333", "만료": "01/09", "ccv": "111" } }, "주소": { "home": { "street": "4032 켄우드 드라이브", "city": "Boston", "zip": "02102" }, "청구": { "street": "541 브롱크스 스트리트", "city": "Boston", "zip": "02102" } }, "전화": { "home": "800-555-9201", "일": "877-123-8811", "cell": "878-234-8171" }, "locale": "en_US", "시간대": -7, "gender": "M" } |
프로필에는 사용자 기본 설정 및 결제 방법에 대한 민감한 데이터가 포함되어 있기 때문에 전체 프로필을 공유할 수 없었습니다. 다음과 같이 제한된 하위 집합만 공유해야 했습니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
{ "type": "공유_프로필", "first_name": "Peter", "id": 80927079070, "기본_프로필": { "partner_id": 80980221, "서비스": [ { "음악": true }, { "라디오": true }, { "video": false } ] }, "시간대": -7 } |
고객은 초기화 실패 시 몇 시간이 걸리고 느린 배치 프로세스(업데이트 반영에 몇 시간 소요)와 프로필 정보 실시간 동기화만 제공하는 미들웨어 SPARK 솔루션을 교체하고자 했습니다.
구조 이벤트
9줄의 간단한 자바스크립트(이 중 3줄은 주석) 이벤트 함수를 배포하여 최소한의 리소스로 문제를 해결했습니다.
|
1 2 3 4 5 6 7 8 9 |
함수 온업데이트(doc, 메타) { // 프로필 문서만 처리 만약 (doc.유형 !== "마스터_프로필") 반환; // aws_bkt는 다음을 통해 AWS에 복제할 대상 버킷의 버킷 별칭입니다. // XCDR. AWS용 버킷에 최소한의(민감하지 않은) 프로필 문서를 작성합니다. aws_bkt["공유_프로필::"+doc.id] = { "type": "공유_프로필", "first_name": doc.first_name, "id": doc.id, "기본_프로필": doc.기본_프로필, "시간대": doc.시간대 }; } |
위의 함수를 "피드 경계"를 "모든 것"으로 설정하여 배포하면 소스 버킷에 있는 전체 문서 세트와 모든 유형의 문서가 스캔되었습니다: "마스터_프로필" 유형의 모든 문서가 처리되고 민감한 정보가 없는 각 프로필의 하위 문서만 공유 대상 버킷에 복사되었습니다.
이벤트 함수는 항상 배포되어 모든 사용자 프로필 변경(또는 변이)에 실시간으로 반응하고 모든 변이를 AWS 대상 버킷으로 전달합니다.
이 사용 사례에서는 최종 버킷 대 버킷 동기화가 Couchbase를 통해 수행됩니다. XCDR 기능을 사용하면 민감한 데이터가 온프레미스 클러스터를 벗어나지 않으며 AWS로 전송되지도 않습니다.
리소스
- 다운로드: 카우치베이스 서버 6.5.1 다운로드
참조
- 카우치베이스 이벤트 문서:
https://docs.couchbase.com/server/current/eventing/eventing-overview.html - 카우치베이스 서버 6.5의 새로운 기능:
https://docs.couchbase.com/server/6.5/introduction/whats-new.html - 이벤트에 대한 카우치베이스 블로그:
https://www.couchbase.com/blog/tag/eventing/
