카우치베이스 동기화 게이트웨이 2.8 릴리스 는 엔터프라이즈급 클라우드-엣지 데이터 동기화를 지원한다고 발표했습니다. 새로운 동기화 게이트웨이 간 복제 기술은 분산된 클라우드 환경에서 클라우드와 엣지 데이터 센터 간에 엔터프라이즈급 확장성과 보안성을 갖춘 동기화를 통해 엣지 컴퓨팅 애플리케이션의 요구 사항을 충족할 수 있습니다.
이 글에서는 배포를 구성하는 방법에 대한 몇 가지 예시와 함께 기능에 대한 개요를 제공합니다. 자세한 내용은 문서 페이지.
첫째, 몇 가지 사용 사례 ...
사용 사례
애플리케이션이 고가용성 보장, 실시간 응답, 데이터 프라이버시 및 규제 준수, 방대한 양의 데이터 처리를 요구하면서 데이터 저장 및 처리를 앱과 가까운 곳에 분산하여 처리하는 분산 클라우드 배포의 중요성이 점점 더 커지고 있습니다. 이러한 컴퓨팅 패러다임을 "엣지 컴퓨팅"이라고 합니다. 이 블로그에서 자세한 내용을 확인할 수 있습니다. "카우치베이스로 엣지 컴퓨팅 솔루션 설계하기".
다음은 이러한 분산형 클라우드 아키텍처의 이점을 누릴 수 있는 앱의 몇 가지 예입니다.
- 리테일 :
대형 소매점은 인터넷이 중단되더라도 로컬 온프레미스 서버에서 서버를 실행하여 고객에게 계속 서비스를 제공할 수 있습니다. 비즈니스 다운타임 는 고객 경험에 해로울 뿐만 아니라 평판에도 장기적인 영향을 미칠 수 있습니다. 이 경우 앱의 고가용성 및 복원력 보장이 핵심 동인입니다. - 여행 :
크루즈선 승객은 선박이 며칠 또는 몇 달 동안 인터넷에 연결되지 않더라도 모든 선상 서비스를 이용할 수 있습니다. 이 경우 크루즈 내 데이터 센터는 항해 중에도 승객에게 서비스를 계속 제공합니다. 이는 앱의 고가용성 보장 및 복원력이 핵심 동인이 되는 또 다른 예입니다. - 호스피탈리티 :
호텔 숙박시설은 인터넷이 중단된 경우에도 게스트의 체크인을 보장할 수 있습니다. 호텔 내 PMS(숙박 시설 관리 시스템)는 게스트 경험이 손상되지 않도록 보장합니다. 이는 앱의 고가용성 보장 및 복원력이 핵심 동인이 되는 또 다른 예입니다. - 헬스케어 :
병원의 환자 모니터링 시스템은 환자 데이터를 로컬에서 처리하고 즉각적인 개선 조치를 취할 수 있습니다. 이 경우 실시간 데이터 처리와 데이터 개인정보 보호가 핵심 동인입니다. - IoT :
IoT 앱은 엣지 컴퓨팅 아키텍처의 핵심 동력입니다. 이 분야의 앱은 실시간으로 분석해야 하는 방대한 양의 데이터를 생성합니다. 이 모든 데이터를 백엔드 서버로 전송하면 서버뿐만 아니라 네트워크에도 많은 오버헤드가 발생합니다. 게다가 대부분의 데이터는 일반적으로 일시적인 경우가 많기 때문에 데이터를 처리하고 폐기하기 위해 원격 서버로 전송하는 것은 그다지 합리적이지 않습니다. IIoT 분야의 구체적인 예로, 공장은 예방적 유지보수를 위해 장비의 센서 데이터를 로컬에서 모니터링, 수집 및 분석할 수 있습니다. 집계된 데이터만 클라우드 데이터 센터로 전송됩니다. 이 경우 실시간 데이터 처리와 대역폭 사용량 감소로 인한 비용 절감이 주요 원동력입니다.
일반적인 클라우드-엣지 배포
Couchbase를 사용한 분산 클라우드 아키텍처의 일반적인 배포는 다음과 같습니다.
카우치베이스는 어떻게 사용되나요? 원격 클라우드 데이터센터에 Couchbase Server를 두고 모든 엣지 데이터센터의 데이터 저장 및 처리를 담당합니다. 그런 다음 각 엣지 데이터센터에 더 작은 크기의 Couchbase Server를 설치합니다. 엣지 데이터 센터의 서버 크기는 엣지에서 더 적은 수의 클라이언트에 서비스를 제공하기 때문에 클라우드 데이터 센터보다 훨씬 작을 것입니다. 엣지 로컬 데이터는 온프레미스 Couchbase 서버 클러스터에서 처리합니다.
그렇다면 데이터 이동은 어떨까요? 다시 말해, 클라우드와 엣지 간의 데이터는 어떻게 동기화 상태를 유지할 수 있을까요? 바로 여기에 동기화 게이트웨이 간 복제가 필요합니다. 이를 위해 클라우드와 엣지 데이터센터에 데이터 복제를 담당하는 Sync Gateway가 배포되어 있습니다. 그리고 동기화가 신뢰할 수 없는 인터넷을 통해 이루어지고 있다는 점을 고려해야 합니다. 따라서 데이터가 암호화되어 있는지, 데이터에 대한 승인된 액세스를 보장하기 위해 엄격한 보안 제어가 마련되어 있는지 확인해야 합니다. 또한 클라우드와 엣지에 서로 다른 액세스 제어 정책을 배포하여 손상된 엣지가 클라우드나 다른 엣지 데이터센터에 영향을 미치지 않도록 할 수 있습니다.
배포 구성 팁
복제가 초기화되거나 예약되는 동기화 게이트웨이 클러스터는 "활성 클러스터", 복제 대상인 원격 동기화 게이트웨이 클러스터는 "패시브 클러스터".
두 클러스터 간에 복제를 여러 개 구성할 경우, 하나의 클러스터를 모든 복제에 대한 활성 클러스터로 선택하는 것이 좋습니다. 이는 푸시, 풀 또는 푸시-풀 등 복제 방향에 관계없이 마찬가지입니다. 이 구성을 사용하면 복제를 배포, 관리 및 문제 해결이 더 간단해집니다.
특히 클라우드-엣지 간 동기화의 맥락에서는 엣지가 원격 클라우드 클러스터에 대한 복제를 시작하는 활성 클러스터가 될 것으로 예상합니다. 엣지 클러스터는 외부 네트워크를 통해 액세스할 수 없을 가능성이 높습니다.
동기화 기술의 속성
신뢰할 수 없는 네트워크 조건에서 신뢰할 수 없는 네트워크를 통해 대규모로 동기화를 처리하는 것은 쉬운 일이 아닙니다. 몇 가지 고려 사항이 있으며 다음은 동기화 게이트웨이 간 복제에 대한 개요입니다. 동기화 게이트웨이 간 복제에 대한 문서 자세한 내용
| 기능 | 동기화 게이트웨이 간 복제 |
|---|---|
| 확장성 | 엣지 데이터의 수는 10초에서 100초에서 1000초까지 다양합니다. 프로토콜은 해당 에지 수를 처리할 수 있도록 확장할 수 있습니다. |
| 보안 | 동기화는 본질적으로 신뢰할 수 없는 인터넷을 통해 이루어집니다. 모든 데이터는 TLS를 통해 암호화되며, 데이터에 대한 무단 액세스를 방지하기 위해 엄격한 액세스 제어가 마련되어 있습니다. 또한 클라우드와 엣지에 서로 다른 액세스 제어 정책을 배포할 수 있으며, 손상된 엣지가 클라우드나 다른 엣지 데이터센터에 영향을 미치지 않도록 보장할 수 있습니다. |
| 네트워크 복원력 | 프로토콜은 기하급수적 백오프 재시도 알고리즘을 구현합니다. 백오프 기간은 구성할 수 있습니다. |
| 효율성 | 네트워크 대역폭 사용량을 최적화하고 전송 비용을 줄이기 위해 프로토콜은 변경된 문서의 일부를 동기화하는 기능인 델타 동기화를 지원합니다. 이 동기화는 연속 모드와 원샷 온디맨드 모드 모두에서 작동할 수 있습니다. 따라서 앱은 데이터 동기화 시기를 제어할 수 있으며, 예를 들어 사용량이 많지 않은 시간대에 동기화하도록 선택할 수 있습니다. |
| 데이터 충돌 | 종합적인 충돌 해결 전략. 동기화 게이트웨이는 기본 제공 해결기로 자동 충돌 해결을 지원하며, 동기화 함수를 정의하는 방식과 유사하게 동기화 게이트웨이 구성 파일의 일부로 JS 함수를 정의하여 자체 충돌 해결기를 정의할 수 있습니다. |
| 운영 용이성 | 복제본의 고가용성, 동기화 게이트웨이 노드에서 복제본을 균일하게 자동 로드 밸런싱/분배, 원격 관리 및 관리를 위한 REST 인터페이스 제공 |
| 유연한 토폴로지 | 계층적. 계층 구조의 계층 수는 1보다 클 수 있습니다. 예를 들어 클라우드 데이터 센터는 다운스트림 데이터 센터와 통신할 수 있으며, 이 데이터 센터는 다시 더 많은 다운스트림 데이터 센터와 통신할 수 있습니다. |
샘플 구성
이 섹션에서는 일반적인 리플리케이터 구성의 몇 가지 예를 제공합니다.
복제 범위는 데이터베이스로 지정되며, 데이터베이스의 동기화 게이트웨이 구성 파일 로 설정하고 실행 중에 스케줄링하거나 _복제 엔드포인트를 설정할 수 있습니다.
기본적으로 모든 노드가 복제에 참여합니다. 이는 동기화 게이트웨이 노드 클러스터에 대해 구성된 복제가 모든 노드에 균일하게 분산된다는 것을 의미합니다. 동기화 게이트웨이 노드는 다음을 사용하여 복제에 참여하지 않도록 구성할 수 있습니다. sgreplicate_enabled 구성 옵션.
기본 충돌 해결 기능을 갖춘 풀 온리 원샷 복제
이 예제에서는 Id 목표물에서 원샷 당기기 채널에 속한 문서를 한 번만 가져오도록 설정되어 있습니다. 채널:스토어채널 에서 스토어 데이터베이스의 원격 엔드포인트. 문서가 로컬 내_로컬_스토어 데이터베이스에 저장합니다. 복제하는 사용자의 자격 증명은 다음을 통해 지정됩니다. 사용자 이름 그리고 비밀번호 매개변수.
복제는 처음에 중지된 상태이며 나중에 다음을 통해 시작할 수 있습니다. 복제 상태 엔드포인트. 충돌은 동기화 게이트웨이에서 다음을 사용하여 자동으로 처리됩니다. 사전 정의된 정책.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
curl -X PUT https://localhost:4985/내_로컬_스토어/_복제/pull-에서-대상-원샷 -H '수락: application/json' -H 'Authorization: 기본 ZGVtbzpwYXNzd29yZA==' -H '콘텐츠 유형: 애플리케이션/json' -d ' { "replication_id": "풀-프롬-타겟-원샷", "remote": "https://remote-sgw-cluster:4984/stores", "방향": "pull", "username":"store1", "비밀번호":"sdfhdgsfh676767", "연속": false, "filter":"동기화 게이트웨이/채널별", "쿼리_파라미터": { "채널":["채널:스토어채널"] }, "initial_state": "중지" }' |
즉시 사용 가능한 충돌 해결기를 통한 양방향 연속 복제
이 예제에서는 Id 푸시앤풀-위드-타겟-연속성 채널에 속한 문서를 지속적으로 푸시 및 풀링하도록 설정되어 있습니다. 채널:스토어채널 에서 스토어 데이터베이스의 원격 엔드포인트. 문서가 로컬 내_로컬_스토어 데이터베이스에 저장합니다. 복제하는 사용자의 자격 증명은 다음을 통해 지정됩니다. 사용자 이름 그리고 비밀번호 매개변수.
복제는 예약 시 자동으로 시작되며, 기본값은 다음과 같습니다. 초기 상태 플래그. 충돌이 발생하면 원격 쪽이 승자가 됩니다.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
curl -X PUT http://localhost:4985/내_로컬_스토어/_복제/푸시앤풀-와 함께-대상-연속 -H '수락: application/json' -H 'Authorization: 기본 ZGVtbzpwYXNzd29yZA==' -H '콘텐츠 유형: 애플리케이션/json' -d ' { "replication_id": "푸시앤풀-위드-타겟-연속", "remote": "https://remote-sgw-cluster:4984/stores", "방향": "pushAndPull", "username":"store1", "비밀번호":"sdfhdgsfh676767", "conflict_resolution_type": "remoteWins", "filter": "동기화 게이트웨이/채널별", "쿼리_파라미터": { "채널":["채널:스토어채널"] } }' |
사용자 지정 충돌 해결기를 사용한 양방향 연속 복제
이 예는 사용자 지정 충돌 해결기를 복제기와 연결한다는 점을 제외하면 이전 사례와 동일합니다. 이제 동기화 게이트웨이가 복제 중에 충돌을 감지할 때마다 충돌 해결기가 충돌하는 수정본과 함께 호출됩니다. 충돌 해결기는 전체 문서 본문과 메타데이터에 액세스하여 충돌을 해결하는 데 사용할 수 있습니다. 물론 충돌하는 리비전 중 하나를 반환하도록 선택하여 "LocalWins" 또는 "RemoteWins" 전략과 동일한 전략을 구현할 수도 있습니다.
참고로 리졸버에서 무슨 일이 일어나고 있는지 또는 정확성/효율성에 대한 세부 사항에 너무 집착하지 마세요. 자바스크립트에서 이 작업을 수행하는 더 좋은 방법이 있다고 확신합니다. 이것은 단지 개념을 보여주기 위한 것입니다.
|
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 |
curl -X PUT http://localhost:4985/내_로컬_스토어/_복제/푸시앤풀-와 함께-대상-연속 -H '수락: application/json' -H 'Authorization: 기본 ZGVtbzpwYXNzd29yZA==' -H '콘텐츠 유형: 애플리케이션/json' -d ' { "replication_id": "푸시앤풀-위드-타겟-연속", "remote": "https://remote-sgw-cluster:4984/stores", "방향": "pushAndPull", "username":"store1", "비밀번호":"sdfhdgsfh676767", "custom_conflict_resolver": "함수(충돌) { 함수(충돌) { 만약 ( (충돌.LocalDocument.type != null) && (충돌.RemoteDocument.type != null) && (충돌.LocalDocument.type == \"foo\")) { 반환 기본 정책(충돌); } else { var 원격 문서 = 충돌.RemoteDocument; var localDoc = 충돌.LocalDocument; var mergedDoc = 확장({}, localDoc, 원격 문서); 반환 mergedDoc; 함수 확장(대상) { var 출처 = [].slice.call(인수, 1); 출처.forEach(함수 (출처) { 에 대한 (var prop in 출처) { 대상[prop] = 출처[prop]; } }); 반환 대상; } } }", "filter": "동기화 게이트웨이/채널별", "쿼리_파라미터": { "채널":["채널:스토어채널"] } }' |
물론 다른 많은 구성 옵션 중에서 선택하여 애플리케이션 요구 사항에 맞게 맞춤 설정할 수 있습니다. 자세한 내용은 설명서를 참조하세요.
복제 모니터링
구성이 완료되고 실행되면 다음을 통해 모니터링할 수 있습니다. 복제 상태 엔드포인트를 추가했습니다. 2.8에서는 개발자 프리뷰 모드에서 새로운 메트릭 엔드포인트도 출시했습니다. 이 엔드포인트는 또한 통계를 Prometheus 형식으로 내보내므로 Prometheus로 모니터링하고 Grafana를 사용해 시각화하기가 매우 쉬워집니다. 이에 대한 자세한 내용은 곧 예정된 블로그.
'SG-복제'는 어떻게 되나요?
동기화 게이트웨이로 작업해 본 적이 있다면 아마도 SG-복제 를 사용하여 서로 다른 클러스터에 있는 동기화 게이트웨이 노드 간의 복제에 사용할 수 있습니다. 웹소켓 기반의 새 버전의 프로토콜은 처음부터 다시 설계되어 참여하는 동기화 게이트웨이 노드 간 복제의 자동 부하 분산, 고가용성(HA), 사용자 지정 충돌 해결기를 통한 내장형 자동 충돌 해결, 델타 동기화 지원, 확장성 및 성능의 대폭 개선 등 다양한 엔터프라이즈급 기능을 제공하도록 되어 있습니다.
'SG-Replicate'는 2.8에서도 계속 지원되지만 더 이상 사용되지 않으며 기존 앱은 새 버전의 동기화 게이트웨이 간 복제 기술로 마이그레이션해야 합니다.
다음 단계
카우치베이스 동기화 게이트웨이의 클라우드-엣지 동기화 솔루션은 안전하고 확장 가능하며 구성 및 관리가 쉽습니다. 동기화는 연결이 끊긴 환경에서 클라이언트가 서로 직접 통신할 수 있는 유일한 피어 투 피어 데이터베이스 동기화 솔루션입니다.
다음을 수행할 수 있습니다. 동기화 게이트웨이 다운로드 를 클릭하고 기능을 무료로 사용할 수 있습니다.
자세한 내용을 알아보려면 여기에서 자세한 정보를 확인할 수 있습니다.
– 데모로 비디오 연결하기: 동기화 게이트웨이 간 복제 사용
– 문서: 동기화 게이트웨이 간 복제
– 솔루션 페이지: 엣지 컴퓨팅
그리고 카우치베이스 포럼 는 질문이 있을 때 연락하기 좋은 곳입니다. 아래에 댓글을 남기거나 다음을 통해 언제든지 문의해 주세요. 트위터 또는 이메일 보내기
