“NoSQL부터 FaaS까지” 현대적인 데이터 아키텍처를 위한 7가지 핵심 기술

5. 컨테이너 오케스트레이션
정적 하드웨어 파티션 대신 컨테이너는 각각 하나의 자체적인 운영체제인 것으로 보인다. 가상머신과 달리, 컨테이너들은 정적인 컴퓨트 및 메모리 파티션이 필요가 없다. 이 때문에 관리자는 메모리의 정확한 양에 관계 없이 많은 컨테이너를 서버에 실행할 수 있다. 쿠버네티스(Kubernetes)와 같은 컨테이너 오케스트레이션 툴이 있으면 컨테이너를 실행하고, 없애고, 이동시키고, 다른 곳에서 다시 실행하는 것이 아주 쉬워진다.

MapR-DB나 MongoDB같은 도큐먼트 데이터베이스 등 새로운 인프라 요소와 MapR-ES 또는 아파치 카프카(Apache Kafka)와 같은 이벤트 스트리밍 플랫폼, 쿠버네티스와 같은 오케스트레이션 툴, 그리고 도커 컨테이너에서 소프트웨어를 제작, 디플로이 하기 위한 데브옵스 프로세스 등을 모두 갖추고 나면, 컨테이너에 배치할 것에 대한 질문으로 넘어 가야 한다. 마이크로서비스가 중요해지는 것이 바로 이 지점이다.

6. 마이크로서비스
사실 마이크로서비스의 개념 자체는 그다지 새로운 것은 아니다. 다만 옛날과 다른 점이라면 NoSQL 데이터베이스, 이벤트 스트리밍, 컨테이너 오케스트레이션 등 마이크로서비스를 가능하게 하는 기술이 수천 개의 마이크로서비스를 생성하며 확장할 수 있다는 것이다. 데이트 스토리지, 이벤트 스트리밍, 그리고 인프라 오케스트레이션에 대한 이러한 새로운 접근이 없었다면 대규모 마이크로서비스 배치는 불가능했을 것이다.

마이크로서비스의 핵심은 민첩성의 실현이다. ‘마이크로’가 붙은 이름에서도 알 수 있듯이 마이크로서비스는 대개 단일 기능, 혹은 소수의 기능들만으로 구성된다. 그리고 이러한 기능 유닛이 더 작고 집중되어 있을수록 서비스를 생성, 테스트, 배치하기가 쉽다. 이들 서비스는 작은 기능으로 분리되지 않으면 마이크로서비스가 약속하는 민첩성을 구현할 수 없다.

마이크로서비스는 소규모 작업만을 담고 있으며 다른 마이크로서비스와는 분리되어 있기 때문에 각 서비스를 대체 또는 업그레이드하는 데 장애물이 거의 없다. 예전 모델에서는 RPC같은 긴밀한 결합에 의지했기 때문에 모든 커넥션을 끊고 나중에 이를 다시 복원했어야만 했다. 수동 설정으로 인한 에러가 자주 발생했기 때문에 로드 밸런싱 역시 큰 문제였다.

7. FaaS(Function as a service)
마이크로서비스가 업계를 장악하면서 이제 서버리스 컴퓨트, 보다 정확히는 FaaS가 부상하고 잇다. FaaS는 가벼운 프레임워크 덕분에 마이크로서비스를 쉽게 생성할 수 있다. 코드는 쉼(shim)이나 사이드카(sidecare)와 같은 경량화된 프레임워크에 캡슐화하고, 이를 컨테이너에 빌드한 후, 온디맨드 방식으로 실행하고 로드밸런싱도 자동으로 이루어진다. FaaS는 개발자가 거의 전적으로 기능에만 집중할 수 있게 해 주기 때문에 마이크로서비스를 선택한다면 FaaS는 당연한 선택이 된다.

FaaS에서 트리거가 되는 이벤트는 아주 중요한 요소이다. 트리거 없이는 작업을 수행할 때에만 기능을 적용하거나 자원을 사용할 수 없기 때문이다. FaaS가 가치 있는 진짜 이유는 기능들을 자동으로 적용해 주기 때문이다. 누군가가 사용자의 프로파일을 읽을 때마다 감사 이벤트가 발생한다고 생각해 보라. 어쩌면 특정 종류의 기록만을 필터링할 수도 있다. 완전한 커스터마이징이 가능하며 선택적인 비즈니스 기능이 될 수 있을 것이다. FaaS와 같은 배치 모델이 있다면 이와 같은 워크플로우를 실행하는 것은 아주 간단한 일이 된다.

서비스 트리거링의 비법은 다름 아닌 이벤트 스트림 속의 이벤트이다. 특정 부류의 이벤트가 다른 이벤트보다 더 트리거로 자주 활용되지만, 한편으로는 어떤 이벤트라도 사용자가 원하면 트리거로 기능할 수 있다. 트리거가 되는 이벤트는 문서 업데이트일 수도 있고, 새로운 문서에 대한 OCR 프로세스일 수도 있으며, OCR 프로세스로부터 얻은 텍스트를 NoSQL 데이터베이스에 추가하는 것일 수도 있다. 또한 이미지가 업로드될 대마다 머신러닝 프레임워크를 통해 이미지 식별 및 스코어링을 진행할 수도 있다. 즉 그 어떤 근본적 한계도 존재하지 않는다. 트리거 이벤트를 정의하고, 어떠한 사건이 일어나고, 그러나 이벤트가 기능을 촉발하고, 그리고 그 기능이 주어진 임무를 완수하는 것이다.

FaaS는 마이크로서비스 도입의 다음 단계가 될 것이다. 그렇지만 FaaS에 접근할 때 고려해야 할 중요한 요소가 하나 더 있다. 그것은 바로 업체 종속성(Vendor Lock-in) 문제다. FaaS는 특정 스토리지 메커니즘, 하드웨어 인프라, 그리고 오케스트레이션을 감추는데, 이 모든 것은 개발자의 입장에선 당연히 좋은 일이다.

그렇지만 이로 인해 FaaS 오퍼링은 업계 역사상 가장 높은 업체 종속성의 사례가 되었다. API가 표준화되어 있지 않기 때문에 퍼블릭 클라우드 내에서 기존 FaaS 서비스를 떠나 이전한다는 것은 거의 불가능하다. 그러려면 지금까지 해 온 작업을 거의 다 버리다시피 해야 한다. 보다 체계적인 방식으로 FaaS에 접근한다면, 예컨대 통합 데이터 플랫폼에서 이벤트를 이용한다면, 클라우드 서비스 업체 간 이전이 보다 쉬워 질 것이다.  editor@itword.co.kr