들어가며
올 해 하반기에 람다 아키텍처를 도입한 프로젝트를 인수인계 받았다.
람다 아키텍처를 이해하기 위하여 공부한 내용, 그리고 서비스를 진행하며 느낀 점(고통)을 정리하였다.
목차
- 람다 아키텍처가 무엇이며, 왜 필요한가
- 람다 아키텍처의 구성은?
- 프로젝트를 진행하며 느낀 점
람다 아키텍처란 무엇이며, 왜 필요한가
무엇이죠?
아래의 특징을 가진 빅 데이터 아키텍처다.
- 배치 및 스트림 처리 방법을 모두 활용하여 많은 양의 데이터를 처리
- 실시간 분석을 지원
Lambda라는 이름이 붙은 이유는 Lambda calculus(람다 미적분) 에서 파생되었다고 한다.
-> 람다의 모양이 입구가 2개이고, 출구가 1개인 모양에서 람다 아키텍쳐의 개념과 비슷하다고 하여 붙여진 이름이라고 합니다. (2019.04 수정)
그래서 이 녀석이 왜 필요하죠?
대용량 데이터는 일반적으로 쿼리에 많은 시간이 소요된다. (데이터양에 따라 조회에 몇 시간이 걸릴 수도 있다.)
람다 아키텍쳐는 스피드 레이어 + 배치 레이어의 조합으로 이런 대용량 데이터에도 어느 정도의 실시간 분석을 지원해줄 수 있다.
람다 아키텍쳐의 구성은?
람다 아키텍쳐의 조감도 (이미지 출처)
Batch Layer
위에서 대용량 데이터를 집계할 때는 시간이 오래 걸린다고 언급하였다.
조회를 요청할 때마다 데이터를 제공해주는 데 매번 몇 시간이 걸리는 서비스를 사용할 유저는 없을 것이다.
조회에 걸리는 시간을 어떻게 최소화할 수 있을까?
배치(batch, 특정 시간마다 주기적으로 계산을 수행하는 것)를 이용하여 데이터를 미리 계산 해 놓으면 된다.
배치 레이어의 저장소에서는 raw 데이터를 보관해놓는다.
이로 인해 아래와 같은 이점을 취할 수 있다.
- 배치 뷰의 데이터가 부정확 할 때 복구가 가능
- 새로운 뷰를 제공하고자 할 때, 기존의 원본 데이터를 가지고 있음으로써 새로운 뷰의 통계 분석이 가능
이 레이어 에서 일반적으로 사용하는 솔루션으로는 Apache Hadoop 이 있다.
Speed Layer
배치 레이어를 사용하여 대용량 데이터 조회 속도의 이슈를 해결했지만, 배치가 도는 간격의 사이에 있는 데이터는 조회할 수 없다.
예를 들어서 배치가 매일 자정마다 동작한다면 당일 오후에는 해당 일자의 데이터를 확인할 수 없을 것이다.
이런 문제를 해결하기 위해서 당일 데이터를 실시간으로 집계해서 별도의 테이블에 집계한다.
즉, 스피드 레이어의 역할은 배치 레이어에서 생기는 갭을 채우는 것이다.
스피드 레이어에서는 아래의 솔루션들을 고려할 수 있다.
Serving Layer
배치 레이어 및 스피드 레이어의 출력을 저장한다.
클라이언트에서는 이 서빙 레이어에 미리 계산된 데이터를 조회하기 때문에 빠른 응답이 가능하다.
솔루션 조합에 관하여
람다 아키텍쳐는 특정 솔루션에 종속적이지 않다.
데이터의 처리 기법을 소개하는 레퍼런스 아키텍쳐로 이해하면 될 것이다.
운영하는 서비스의 특성을 고려하여 솔루션을 선택 & 조합하자.
아래 그림은 Kafka, Apache Hadoop, Voldemort, Twitter Storm, Cassandra로 구현한 람다 아키텍처의 조감도이다. (이미지 출처)
단점
스피드 레이어와 배치 레이어가 모두 똑같은 처리를 구현하고 있으므로 중복된 비즈니스 로직 및 두 경로의 아키텍쳐 관리에 따른 복잡성이 발생한다.
이 때문에 람다 아키텍쳐를 단순화한 '카파 아키텍쳐(Kappa architercutre)'를 선택하기도 한다.
이에 대한 자세한 내용은 MS문서에 자세히 설명되어 있으므로 링크로 대체한다.
프로젝트를 진행하며 느낀 점
(개인적으로 느낀 점을 서술하므로 건너뛰셔도 됩니다.)
디버깅의 고통, 그리고 해방
2개월 정도 전에 람다 아키텍쳐를 도입한 프로젝트를 인수인계 받았다. (정확히는 Batch Layer - Serving Layer 사이의 Job)
오류 확인 요청을 받거나 기능을 추가로 구현할 때 나를 괴롭게 했던 것은 바로 테스트 비용이 너무 크다는 것이다.
이슈가 발생하면 보통 문의는 이렇게 들어온다. "화면에서 데이터가 제대로 나오지 않아요. 확인해주세요."
그러면 데이터 파이프라인 중 어느 부분에 문제가 발생했는지 파악하고 해당 부분을 수정해야 하는데, 쿼리에 걸리는 시간이 길다 보니 이게 꽤 귀찮은(지루한) 작업이었다.
추가 기능을 개발할 때에도 마찬가지 이유로 고통스러웠다.
내가 제대로 개발하고 있는 게 맞는지 수시로 피드백을 받아야 하는데, 이 피드백이 너무 오래 걸리기 때문이다.
이런 막노동의 고통에서 해방되기 위해 고민했고, 아래와 같은 방법을 시도했다.
- 비즈니스 로직과 외부 의존성(쿼리 포함)을 분리함
- 배치 레이어에서 데이터를 가져오는 부분 비즈니스 로직, 그리고 DB에 Insert 하는 부분을 분리
- 즉, 외부와의 연결고리를 할 수 있는 한 최대한 느슨하게 변경
- 비즈니스 로직에 테스트 코드 작성
- 외부 서비스 API 조회 부분에 테스트 코드 작성 (외부 서비스의 문제면 바로 확인할 수 있다. 실제로 이런 경우가 잦았다.)
- 테스트 시 DB에 영향을 받지 않도록 처리
결과적으로 이러한 작업을 통하여 피드백을 훨씬 빠르게 받을 수 있었고, 개발과 디버깅에 걸리는 시간을 많이 감소시킬 수 있었다.
댓글 영역