개발자가 데이터 스프레드라는 용어를 들으면 TCO, ROI 등과 같은 비즈니스 용어처럼 들릴 수 있습니다. 이 모든 용어는 분석가나 관리자의 영역을 벗어난 개발자에게는 현실적인 용어입니다. 그래서 오늘은 개발자를 위한 데이터 스프롤의 현실에 대해 말씀드리고자 합니다. 그리고 그것이 우리 업무에 어떤 영향을 미치는지.
데이터 스프롤은 엄청난 양의 데이터가 다양한 데이터 저장소에 저장되어 있다는 것으로 요약할 수 있습니다. 게다가 개발자는 이러한 데이터 저장소가 서로 상호 작용하도록 만들어야 합니다. 물론 많으면 많을수록 좋겠죠?
일반적으로 더 높은 금융 비용과 관련이 있습니다:
-
- 인프라
- 라이선스
- 통합
- 교육
- 운영
- 지원 비용
여러 인터페이스가 있는 별도의 플랫폼은 다음과 같은 이유로 골칫거리가 될 수 있습니다:
-
- 독립적인 배포 및 관리
- 다양한 데이터 모델 및 프로그래밍 인터페이스
- 여러 제품 간 통합
- 다양한 공급업체의 티켓 지원
이로 인해 더 많은 시간과 노력, 비용이 필요합니다:
-
- 라이선스 및 계약
- 개발자 및 운영자를 위한 교육
- 지원
- 데이터베이스에 API 또는 커넥터 구축
- 인프라 구매
이렇게 보면 다소 암울해 보이지만 많은 기업이 일상적으로 직면하는 과제입니다. 다양한 데이터 워크로드뿐만 아니라 클라우드 애플리케이션에서도 마찬가지입니다.
구체적인 예를 살펴보겠습니다. 문서 데이터베이스의 CRUD, 캐싱 저장소의 캐시, 전체 텍스트 검색 엔진의 검색을 사용하는 애플리케이션을 만들었습니다. (GitHub 소스)
이 스키마를 살펴보면 기본적으로 보이는 모든 화살표는 개발자가 생각하고 코딩해야 하는 서로 다른 시스템 간의 상호작용으로 간주할 수 있습니다.
여기서는 이벤트 스트리밍을 사용하여 캐시 및 검색 데이터베이스를 자동으로 동기화하고 있습니다. 즉, 8개의 상호작용과 4개의 데이터 저장소를 학습하고 관리해야 합니다. 모든 스토어가 스트리밍 서비스와 연결되어 있고 올바른 업데이트를 받도록 해야 하므로 스트리밍 서비스, 검색, 캐시 및 데이터 스토어를 관리해야 합니다. 또한 캐시를 CRUD 서비스와 통합해야 합니다(다른 서비스와 통합하는 것이 가장 이상적이지만 여기서는 간단하게 설명하겠습니다). 요컨대, 해야 할 일이 많습니다.
스트리밍 서비스를 없애고 다른 서비스를 수동으로 업데이트하면 이러한 상호작용을 제한할 수 있습니다. 이렇게 하면 라이선스, 운영할 것, 학습할 것, 통합할 것이 하나 줄어듭니다. 여전히 이상적이지는 않지만 다음과 같이 보일 수 있습니다:
8개와 4개가 아닌 6개와 3개의 데이터 저장소로 조금 더 간단해졌습니다. 하지만 여전히 상호작용이 많고 스트리밍 통합의 일부는 수동으로 수행해야 합니다. 반면 이전에는 기존 서비스 간의 기존 커넥터를 학습하고 사용할 수 있었습니다. 이를 위해 작성된 Java/Spring Boot 샘플 코드를 간단히 살펴보겠습니다.
개발자가 데이터 저장소로 수행할 수 있는 작업을 나타내는 4가지 인터페이스가 있습니다. CRUD, 캐시, 쿼리 및 검색입니다.
|
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 |
public 인터페이스 CRUD { 저장된 파일 문서 읽기(문자열 id); void create(문자열 id, 저장된 파일 문서 doc); void 업데이트(문자열 id, 저장된 파일 문서 doc); void 업서트(문자열 id, 저장된 파일 문서 doc); void 삭제(문자열 id); } public 인터페이스 캐시 { void 쓰기인캐시(저장된 파일 문서 doc); 저장된 파일 문서 readFromCache(문자열 id); void 터치(문자열 id); void evict(문자열 id); } public 인터페이스 쿼리 { 목록<지도<문자열, 개체>> 쿼리(문자열 where절); 목록<지도<문자열, 개체>> findAll(); } public 인터페이스 검색 { 목록<지도<문자열, 개체>> 검색(문자열 용어); void 색인(저장된 파일 문서 doc); void 삭제(문자열 id); } |
이 글에서 모든 코드를 보여드리지는 않고 흥미로운 부분 몇 가지만 보여드리겠습니다.
CRUD 서비스에 검색 및 캐시 서비스에 대한 링크가 있는 구성입니다. 단순화된 버전에서는 어떤 모습인지 살펴봅시다. 캐시 및 검색 서비스를 필요한 대로 가져와야 합니다. 그러면 모든 메서드가 영향을 받습니다. Read는 먼저 캐시를 쿼리하고, 캐시에서 객체가 마지막으로 발견된 시간을 업데이트하거나 데이터베이스에서 객체를 가져와 캐시에 삽입해야 합니다. 그런 다음 새로 생성, 업데이트 또는 삭제된 데이터가 캐시 또는 검색 데이터 저장소 인덱스로 전파되어야 하므로 생성, 업데이트 및 삭제 메서드는 모두 캐시 및 검색에 영향을 줍니다.
|
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 49 50 51 52 53 54 55 56 |
서비스 public 클래스 MongoCRUD 구현 CRUD { 비공개 몽고컬렉션<StoredFileDocument> 컬렉션; 비공개 캐시 캐시; 비공개 검색 검색; public MongoCRUD(몽고컬렉션<StoredFileDocument> 컬렉션, 캐시 캐시, 검색 검색) { 이.컬렉션 = 컬렉션; 이.캐시 = 캐시; 이.검색 = 검색; } 오버라이드 public 저장된 파일 문서 읽기(문자열 id) { 저장된 파일 문서 doc = 캐시.readFromCache(id); 만약 (doc == null) { 시스템.out.println(id); doc = 컬렉션.찾기(eq("fileId", id)).먼저(); 캐시.쓰기인캐시(doc); } else { 캐시.터치(id); } 반환 doc; } 오버라이드 public void create(문자열 id, 저장된 파일 문서 doc) { doc.setFileId(id); 컬렉션.insertOne(doc); 캐시.쓰기인캐시(doc); 검색.색인(doc); } 오버라이드 public void 업데이트(문자열 id, 저장된 파일 문서 doc) { 컬렉션.findOneAndReplace(eq("fileId", id), doc); 캐시.터치(id); 검색.색인(doc); } 오버라이드 public void 업서트(문자열 id, 저장된 파일 문서 doc) { 찾기 및 바꾸기 옵션 옵션 = new 찾기 및 바꾸기 옵션().업서트(true); 컬렉션.findOneAndReplace(eq("fileId", id), doc, 옵션); 캐시.터치(id); 검색.색인(doc); } 오버라이드 public void 삭제(문자열 id) { 컬렉션.deleteOne(eq("fileId", id)); 캐시.evict(id); 검색.삭제(id); } } |
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 |
서비스 프로필("couchbase") public 클래스 CouchbaseCRUD 구현 CRUD { 비공개 컬렉션 컬렉션; public CouchbaseCRUD(컬렉션 컬렉션) { 이.컬렉션 = 컬렉션; } 오버라이드 public 저장된 파일 문서 읽기(문자열 id) { GetResult res = 컬렉션.get(id); 반환 res.contentAs(저장된 파일 문서.클래스); } 오버라이드 public void create(문자열 id, 저장된 파일 문서 doc) { MutationResult res = 컬렉션.삽입(id, doc); } 오버라이드 public void 업데이트(문자열 id, 저장된 파일 문서 doc) { MutationResult res = 컬렉션.대체(id, doc); } 오버라이드 public void 업서트(문자열 id, 저장된 파일 문서 doc) { MutationResult res = 컬렉션.업서트(id, doc); } 오버라이드 public void 삭제(문자열 id) { MutationResult res = 컬렉션.제거(id); } } |
캐시 및 검색 서비스에 대한 종속성이 필요하지 않은 이유는 Couchbase에 이미 캐시와 검색 엔진이 통합되어 있기 때문입니다. 캐시 인터페이스를 구현할 필요도 없고, 검색 인터페이스에서 삭제 및 색인 방법을 구현할 필요도 없습니다. 모든 것이 자동화되고 통합되어 있습니다.
보통 제가 누군가에게 이를 설명하면, 모든 것을 다 하려면 절충점을 찾아야 하기 때문에 얼마나 나쁠지에 대한 대화가 이어집니다. 모든 데이터 플랫폼, 다중 모델, 다중 워크로드에 대해 이야기하고 싶어도 모든 데이터 플랫폼이 동일하게 만들어지거나 적어도 동일한 아키텍처를 염두에 두고 만들어지지는 않습니다.
Couchbase는 서로 다른 워크로드를 담당하는 여러 개의 서로 다른 데이터베이스로 볼 수 있으며, 내부 스트리밍 서비스를 통해 모두 통합됩니다. 이렇게 하면 Couchbase의 모든 부분이 자동으로 최신 상태로 유지되고 모든 부분이 자체 데이터 워크로드에 특화될 수 있습니다. 결국, 3개의 상호작용과 1개의 데이터 저장소를 갖게 됩니다.
이 정도면 이미 상당히 좋은 일이지만, 한 가지 더 있습니다. 저희 서비스는 쿼리 언어 SQL++에 통합되어 있습니다. 예를 들어 보겠습니다. 각 문서에 대한 다양한 권한이 있는 문서 트리를 보유한 CMS가 있고, 특정 권한 집합을 가진 연결된 사용자로 검색을 실행하려는 하위 문서에서 이러한 권한을 상속할 수 있습니다. 외부 검색 엔진을 사용하는 경우 일반적으로 다음과 같은 일이 발생합니다:
-
- 검색 엔진에 검색 쿼리 실행
- 모든 문서 콘텐츠가 색인되는 것은 아니므로 반환된 문서의 식별자를 수집합니다.
- 쿼리를 실행하여 전체 문서를 가져오기
- 쿼리 서비스가 JOIN을 지원하지 않는 경우 다른 쿼리를 실행하여 상속된 권한을 가져오고 문서를 필터링하세요.
더 복잡하게 만들고 싶다면(그리고 더 현실적으로 만들고 싶다면) 각 단계에 사용자 지정 캐싱 로직을 추가할 수도 있습니다. 하지만 이미 충분히 복잡합니다.
Couchbase는 모든 작업을 한 번에 처리할 수 있습니다. 하나의 SQL++ 쿼리로 검색하고, 원하는 필드를 선택하고, 다른 문서에 조인하여 사용 권한을 정렬할 수 있습니다. 아주 간단합니다. Couchbase는 잘 통합된 데이터 플랫폼이기 때문에 쿼리 언어를 통해 그 모든 기능을 활용할 수 있습니다. 관심이 있으시다면 다른 포스팅에서 자세한 내용을 소개해 드릴 수도 있습니다.
마무리
오늘 배운 것은 무엇일까요? 잘 설계된 데이터 플랫폼을 사용하면 많은 시간, 비용, 노력, 골칫거리를 절약할 수 있습니다. 결국 고려해야 할 사항이 줄어들고, 작성해야 할 코드가 줄어들어 유지 관리할 코드가 줄어들고, 프로덕션 환경으로 더 빨리 출시할 수 있기 때문입니다. 또한 라이선스, 교육, 규정 준수 등 관리자, 분석가, 상사, 상사의 상사가 신경 쓰는 모든 사항을 간소화하고 비용을 절감할 수 있습니다!
- 레드몽크와의 대담을 시청하세요: 데이터 스프롤이란 무엇인가요? 플랫폼을 활용하여 데이터 스프롤을 해결하는 방법
- 내 코드를 확인하세요. 데이터 스프롤 예제
- 방법에 대해 자세히 알아보기 카우치베이스 서비스 는 원활하고 간편하게 개발할 수 있도록 설계되었습니다.
- 사용해보십시오. 카우치베이스 카펠라 DBaaS 테스트하기
