기회가 되어 스노우플레이크, SAP 에 관하여 키워드를 들었습니다.
평소에도 아키텍처에 대해서 고민을 하다보면 늘 DB에서 병목이 발생해 어떻게 하면 쓰기 부하 같은 문제를 잘 해결할 수 있을까에 관해 고민했습니다. Primary, Secondary 를 나눠 이러한 문제를 해결하려 시도할 수 있고 appendOnly로 데이터를 다뤄 이런 문제를 해결하려는 방법도 보았습니다.
이번에 SAP 와 스노우플레이크가 협력을 하게 되었는데 데이터의 복제 없이 양방향으로 데이터를 공유하며 엔터프라이즈급 AI 구축을 돕는다고 한다. (출시는 26년도 상반기)
제로카피라면 사실 아파치 카프카 같은 기술에서도 사용되는 최적화 접근법이긴한데 이러한 행보가 흥미로워 조금 정리를 해보려합니다.
SAP란 이름부터 생소할 수 있습니다. ERP 시스템을 만드는 독일의 회사입니다.
ERP는 기업내 자원을 관리하는 프로그램으로 '직원 급여 데이터', '제품 재고 정보', '고객 주문 내역', '회계 장부' 등이 SAP 안에 저장됩니다.
그래서 급여, 재고, 주문 데이터 같은건 SAP 데이터라고 볼 수 있습니다. 그외 엑셀 파일, 이메일, 웹사이트 로그 같은건 비SAP 데이터라 할 수 있습니다.
기업에서의 업무를 수행하려면 단순히 SAP 데이터 뿐만 아니라 비SAP 데이터 또한 필요로 합니다.
그래서 SAP과 Snowflake 가 협약을 맺어 만들 SAP Snowflake 가 하는 일은 다음과 같습니다.
간단하게 정리하자면 SAP, 비 SAP 데이터들을 복제 없이 실시간으로 관리하여 한정된 범위 내에서 일관성을 지키고 보안적인 부분을 향상시킬 수 있습니다. 이렇게 데이터가 최소한의 범위에서 지켜지니 총소유비용(TCO, 데이터 복제, 저장 등 비용) 또한 절감이 가능합니다.
복제가 필요없이 실시간적으로 사용하니 ETL 같은 데이터 처리 없이 바로 사용이 가능할 것으로 기대할 수 있습니다.
대단한 일을 하는 것으로 보이는데 그중에서도 가장 눈에 들어오는건 제로카피입니다.
옛날 학부 시절에 폰 노이만 구조를 공부하면 복사는 반드시 일어날 수 밖에 없겠구나라고 생각을 하며 자랐는데 이런 저에게 제로카피란 키워드는 너무나도 강렬하게 다가옵니다.
일단 2차 저장장치 -> 메모리 -> 캐시 이러한 흐름에서의 복사는 일어날 수 밖에 없습니다. 여기서 언급되는 카피는 SAP, 비SAP 데이터를 저장하는 장치들 사이에서 발생하는 복사이다.
SAP 데이터를 다루는 장치에서 비SAP 데이터를 이용하기 위해 ETL 같은 과정 등을 통해 저장을 하지 않고 네트워크 통신 등을 통해 필요한 데이터를 가져와서 처리하는 것입니다. (Data Federation)
캐시를 고려할 때 고려해야하는 장, 단점과도 일맥상통한 부분이 있네요. 그래도 신뢰할 수 있는 단일지점을 가진다는건 꽤 흥미롭습니다.
SAP Snowflake 만 아니라 Snowflake 내부에서도 제로카피 메커니즘이 있다하는데 따로 정리를 해봐야겠습니다.