오늘날 많은 애플리케이션은 계산 중심(compute-intensive) 과는 다르게 데이터 중심(data-intensive) 적이다.
이러한 애플리케이션의 경우 CPU 성능은 애플리케이션을 제한하는 요소가 아니며, 더 큰 문제는 보통 데이터의 양, 데이터의 복잡도, 데이터의 변화 속도이다.
일반적으로 데이터 중심 애플리케이션은 공통으로 필요로 하는 기능을 제공하는 표준 구성 요소 (standard building block) 로 만든다. 예를 들어, 많은 어플리케이션은 다음을 필요로 한다.
- 구동 애플리케이션이나 다른 애플리케이션에서 나중에 다시 데이터를 찾을 수 있게 데이터를 저장 (데이터베이스)
- 읽기 속도 향상을 위해 값비싼 수행 결과를 기억(캐시)
- 사용자가 키워드로 데이터를 검색하거나 다양한 방법으로 필터링 할 수 있게 제공 (검색 색인)
- 비동기 처리를 위해 다른 프로세스로 메세지 보내기 (스트림 처리)
- 주기적으로 대량의 누적된 데이터를 분석(일괄 처리)
데이터 시스템에 대한 생각
왜 기존에 존재했던 툴에 대한 분류를 버리고 데이터 시스템이라는 포괄적인 용어로 새로 묶어야 할까?
- 분류간 경계가 흐려지고 있기 때문이다.
- 예를 들어, 메세지 큐로 사용하는 datastore 인 redis 가 있고, 데이터베이스처럼 durability 를 보장하는 메시지 큐인 Kafka 도 있다. ( 같은 큐이지만, 속성이 다르다. 카프카는 큐이면서도 데이터베이스라고 볼 수 있다.)
- 점점 더 많은 애플리케이션이 단일 도구로는 더 이상 데이터 처리와 저장 모두를 만족시킬 수 없는 과도하고 광범위한 요구사항을 갖고 있다.
- 대신 작업(work) 은 단일 도구에서 효율적으로 수행할 수 있는 task 로 나누고 다양한 도구들은 애플리케이션 코드를 이용해 서로 연결한다.
- 예를 들어, 메인 데이터베이스와 분리된 애플리케이션 관리 캐시 계층 (Memcached 나 다른 유사한 도구 ) 이나 Elasticsearch 나 Solr 같은 전문(full-text) 검색 서버의 경우 메인 데이터베이스의 동기화된 캐시나 색인을 유지하는 것은 보통 애플리케이션 코드의 책임이다. ( 아래 그림 참조 )
위 그림을 보면, primary database 에 데이터가 쓰여졌을때, 아래의 Application Code 에서 변화를 capture 해서 ES(Full-text indeX) 와 Memcached (In-memory cache) 에 업데이트 함을 볼 수 있다.
데이터 시스템이나 서비스를 설계할 때는 까다로운 문제가 많이 생긴다.
내부적으로 문제가 있더라도 데이터를 정확하고 완전하게 유지하려면 어떻게 해야 할까?
시스템의 일부 성능이 저하되더라도 클라이언트에 일관되게 좋은 성능을 어떻게 제공할 수 있을까?
부하 증가를 다루기 위해 어떻게 규모를 확장할까?
서비스를 위해 좋은 API 는 어떤 모습일까?
위와 같은 문제들의 고려가 필요하다.