데이터 센터 간 복제 - Amazon AWS를 위한 단계별 가이드

Couchbase Server 2.0의 가장 흥미로운 새 기능 중 하나는 XDCR(교차 데이터 센터 복제)의 추가입니다. 이 기능을 사용하면 여러 데이터 센터에서 운영하여 애플리케이션의 안정성을 높이고 사용자의 실제 위치에 더 가까운 곳에 데이터를 저장하여 사용자의 성능을 향상시킬 수 있습니다.

데이터 센터 간 복제를 시작하는 방법은 간단합니다. Amazon EC2 에서 테스트 드라이브를 할 수 있는 좋은 장소를 제공합니다.

인프라

먼저, 서로 다른 지역에 2개의 Couchbase 클러스터가 필요합니다. 저는 미국 동부(북부 버지니아) 및 미국 서부(북부 캘리포니아) 지역을 사용하기로 선택했습니다. 각 지역에 표준 Amazon Linux AMI를 실행하는 서버(m1.large) 2대를 프로비저닝했습니다. 서버가 프로비저닝되면 다음을 수행해야 합니다. 카우치베이스 서버 2.0 베타 설치 를 설정합니다.

중요: 각 서버에서 수행해야 하는 중요한 변경 사항이 하나 있습니다. 기본적으로 카우치베이스 서버는 서버 로컬 IP 주소를 식별하고 이를 모든 클러스터 통신에 사용합니다. 이는 지역 내에서는 잘 작동하지만 인터넷에서는 작동하지 않습니다. 이 문제를 해결하기 위해 각 서버에 대해 Amazon에서 제공하는 공용 DNS 이름을 명시적으로 사용하도록 Couchbase를 구성합니다. 이렇게 하면 클러스터 내 통신의 경우 내부 IP 주소로, 클러스터 간 통신의 경우 공용 IP 주소로 올바르게 확인됩니다.

1. 서버 중지
   sudo /etc/init.d/couchbase-server stop
2. 옵트/카우치베이스/빈/카우치베이스 서버 파일을 편집합니다.
3. 시작 섹션에서 마지막 줄을 찾습니다.
4. 줄 끝에 "를 추가합니다.
   ...
5. 바로 뒤에 다음과 같은 새 줄을 추가합니다:
   -이름 ns_1@
6. 아래의 파일을 삭제합니다:
   • /옵트/카우치베이스/변/라이브/카우치베이스/데이터/*
   • /옵트/카우치베이스/변/라이브/카우치베이스/메네시아/*
   • /opt/couchbase/var/lib/couchbase/config/config.dat
7. 서버 시작
   sudo /etc/init.d/couchbase-server 시작

서버가 공개 DNS 이름으로 제대로 구성되었는지 확인하는 좋은 방법은 Couchbase 서버 UI의 서버 탭을 살펴보는 것입니다. 서버가 DNS 이름과 함께 나열되어 있어야 하며, 개인 IP 주소가 표시되면 이전 단계를 다시 확인하세요.

샘플 데이터 세트 로드

복제할 몇 가지 문서를 확보하기 위해 맥주 샘플 데이터 세트를 동부 해안 클러스터에 로드하겠습니다.

젊은 문서, 서쪽으로 이동

이스트 코스트 클러스터에서 웨스트 코스트 클러스터로의 단방향 복제부터 시작하겠습니다. 이스트 코스트 클러스터의 XDCR 탭으로 이동합니다. "클러스터 참조 만들기" 버튼을 누릅니다. IP/호스트 이름 필드에 원격 클러스터에 있는 서버 중 하나의 공용 DNS 이름을 사용해야 합니다.

이제 "복제 만들기" 버튼을 누릅니다. "기본" 버킷인 "WestSide" 클러스터를 선택하고 원격 클러스터에 "기본"을 입력합니다.

상태 열에 "시작 중"이라고 계속 표시되므로 놀라지 마세요. 이는 정상입니다. 이 시점에서 이스트 코스트 클러스터의 모든 문서가 웨스트 코스트 클러스터로 복제됩니다.

이제 '데이터 버킷' 탭으로 이동해 보겠습니다. "기본" 버킷을 클릭합니다. 아래쪽으로 스크롤하여 "나가는 복제"라고 표시된 섹션을 펼칩니다.

처음에는 변경사항 대기열이 높고 확인된 문서와 복제된 문서가 0입니다. 복제가 진행됨에 따라 변경사항 대기열은 0으로 줄어들고 확인된 문서와 복제된 문서는 총 문서 수에 따라 정해집니다. 다음은 문서 복제가 완료된 후의 모습입니다(참고: XDCR 복제는 연속적이며, 지금까지 모든 변경사항 복제가 완료되었지만 계속 실행되어 향후 변경사항을 전송합니다).

카우치베이스 서버 UI에서 웨스트 코스트 클러스터를 살펴보겠습니다.

기본 버킷의 문서 수가 동부 지역 클러스터의 값과 일치합니다. 데이터 센터 간 복제가 작동 중입니다!

귀국 여행

많은 사용 사례에서 양방향 복제가 필요하므로 서쪽 해안에서 동쪽 해안으로 다시 복제를 설정해 보겠습니다. 단계는 이전과 동일하며 클러스터 및 DNS 이름만 변경됩니다. 다시 말하지만, Amazon 서버의 공개 DNS 이름을 사용해야 합니다.

양방향 복제가 작동하는지 테스트하려면 이쪽의 데이터를 변경해야 합니다.

CouchConf SF 프레젠테이션이 끝난 후, @PabstBlueRibbon으로부터 맥주 샘플 데이터 세트의 업데이트가 필요하다는 트윗을 받았습니다.

이제 이 문제를 해결해 보겠습니다. 데이터 집합에서 이 값은 현재 0입니다. ID 110fa43a2e로 문서를 편집하여 12로 변경하겠습니다.

변경 사항을 저장한 후 서부 해안 클러스터의 버킷 통계를 보면 변경 사항이 복제되는 것을 볼 수 있습니다.
변경사항 대기열이 잠시 1로 올라간 것을 보면 문서 1개가 복제된 것을 알 수 있습니다. 모든 문서를 확인했지만 변경된 문서 하나만 복제했다는 점도 주목할 가치가 있는데, 이는 XDCR이 수정본을 확인하고 필요한 데이터만 복제하고 있음을 보여줍니다.

이제 이스트 코스트 클러스터에 문서를 로드하여 작동하는지 확인해 보겠습니다.

성공했습니다. 아이부가 두 클러스터 모두에서 12라는 값을 표시하고 있습니다!

모범 사례

여기서는 예제를 단순하게 만들려고 노력했지만, 프로덕션에 적용하기 전에 고려해야 할 두 가지 문제가 있습니다.

서버 이름

여기 예제에서는 EC2 인스턴스 공용 DNS 이름을 직접 사용했습니다. Amazon 인스턴스 IP 주소(및 관련 공용 DNS 이름)가 변경될 수 있으므로 프로덕션 환경에서는 이 방법을 사용하지 않는 것이 좋습니다. 다음 두 가지 옵션 중 하나를 사용하는 것이 좋습니다:

• 타사 동적 DNS 서비스를 사용합니다. 서버의 IP 주소가 변경될 때마다 서버의 공개 DNS 이름을 가리키는 CNAME 레코드를 업데이트합니다. Amazon 내부와 외부에서 모두 올바른 주소로 확인해야 하므로 이 CNAME 레코드가 공개 DNS 이름을 가리키는 것이 중요합니다.
• 사용 Amazon Elastic IP 주소. (사용 시) 추가 비용이 들지 않지만 아마존에 추가 비용을 요청해야 할 수도 있습니다.

데이터 보안

XDCR로 전송되는 데이터는 암호화되지 않은 상태로 전송되며, Amazon 지역 간에 복제할 때 이는 공용 인터넷을 전송한다는 의미입니다.

• XDCR을 사용하여 서로 다른 클러스터를 연결할 수 있습니다. 가용성 영역 공용 인터넷을 통해 전송하지 않습니다. 이 방법은 신뢰성이 높지는 않지만 잠재적인 보안 문제를 피할 수 있습니다.
• 다음을 사용할 수 있습니다. 타사 VPN 서비스 를 사용하여 Amazon 지역 간 데이터를 터널링할 수 있습니다.

자세한 정보

이 튜토리얼을 통해 AWS에서 몇 분 만에 XDCR을 실행할 수 있는 방법을 알아보셨기를 바랍니다. Couchbase XDCR에 대한 자세한 내용은 다음을 참조하세요:

• 참석하려면 등록하세요. 10월 17일 XDCR 웨비나