람다 아키텍처

람다 아키텍처(Lambda Architecture)는 실시간 분석을 지원하는 빅데이터(Big Data) 아키텍처이다. 대량의 데이터를 실시간으로 분석하기 어려워서 배치(batch)로 미리 만든 데이터와 실시간 데이터를 혼합해서 사용하는 방식이다.

개요

람다 아키텍처는 아파치 스톰 개발자인 나단 마즈(Nathan Marz)가 제안한 개념으로, 실시간 레이어와 배치 레이어를 결합하여 빅데이터의 실시간 분석을 지원하는 아키텍처를 의미한다. 예를 들면, 배치 분석을 통해 일자별로 통계를 생성하고, 당일 데이터는 별도의 실시간 통계를 유지한 다음, 이를 합쳐서 실시간 분석을 제공한다. 하둡(Hadoop) 기반으로 람다 아키텍처를 구현할 때에는 일반적으로 HDFS(Hadoop Distributed File System)에 적재된 데이터를 맵리듀스(Map Reduce)나 하이브(Hive)로 배치 분석하고, 스톰이나 스파크 같은 스트리밍 솔루션으로 실시간 집계를 수행한 뒤, 이를 H베이스(HBase)나 RDBMS(Relational DataBase Management System)에서 통합하여 실시간에 가까운 분석을 유지한다. 이와 같은 구성은 의도한 대로 실시간 빅데이터 분석을 지원하기는 하지만, ETL(Extraction, Transformation, Loading) 작업부터 시각화 단계에 이르기까지 독립적인 다수의 구성요소를 통합하여 개발해야 하므로 구축 및 운영에 있어서 많은 어려움이 있다. 인터넷에 연결되는 수십만 대의 사물인터넷(IOT) 센서 데이터를 실시간으로 분석할 때에는 더욱 어려움이 따른다. 실무에서는 센서 데이터에 포함된 식별자를 기준으로 원본 데이터에 다양한 메타데이터를 추가하여 분석을 수행하는 사례를 흔히 볼 수 있다. 예를 들면, 셋톱박스의 식별자를 연령, 지역, 상품명 등으로 맵핑하여 다양한 분석을 수행하게 된다. 가장 흔한 설계 오류는 아래와 같이 스트리밍 솔루션에서 로그가 수신될 때마다 RDBMS를 대상으로 매번 쿼리하는 구성이다. 아키텍처에서는 데이터베이스에 대한 메타데이터 쿼리가 네트워크 스택의 레이턴시를 포함하여 1밀리초 이내에 응답한다고 하더라도 1000TPS를 내기 어려운 구성이 된다. 일반적으로는 실시간 스트리밍 처리와 배치 분석이 별개의 솔루션으로 구성되는데, 이렇게 다수의 컴포넌트로 구성된 아키텍처에서 가장 큰 성능의 병목은 메모리에 있는 데이터를 바이너리로 직렬화하고 네트워크 I/O를 수행하는 연동 구간에 존재한다.

등장 배경

2002년 하둡의 아버지 더그커팅(Doug Cutting)이 루씬(lucene) 기반의 오픈소스 검색엔진인 너치(Nutch)를 위해 일하기 시작하면서 하둡의 역사가 시작됐다. 이후 2003년 검색엔진의 최적화에 주력했던 구글에서는 구글 파일 시스템(GFS)에 대한 백서를 발표하고 2004년에는 맵리듀스에 대한 백서를 발표한다. 2006년 더그커팅이 참여한 너치에서 파생된 하둡이 서브 프로젝트가 되고 2년 후 하둡은 아파치의 톱-레벨 프로젝트가 된다. 2008년 빅데이터 분석의 3대 업체 중 하나인 클라우데라(Cloudera)가 설립되고 더그커팅이 합류하고 2009년 상업목적의 하둡이 배포되게 된다. 이후에 하이브, 임팔라(Impala) 등 하둡을 기반으로 한 오픈소스 생태계가 확장되게 된다. 그러면서 하둡을 적용하는 사례가 늘어나고 빅데이터 처리 플랫폼에서의 디팩토(Defacto) 표준으로 자리 잡았다. 하둡이 빅데이터를 처리하는 분산처리 플랫폼으로서 적용되는 사례가 늘어나면서 하둡은 잘 작동하였지만, 실시간성의 처리구조는 아니었다. 오히려 배치 성의 성격을 갖는 프로세싱 구조라고 할 수 있다. 이러한 준 실시간성을 보완하여 실시간 처리를 하기 위한 하둡 오픈소스 생태계들도 발전하기 시작한다. 실시간성의 데이터를 처리하기 위해 스톰과 스파크의 실시간 처리를 위한 스파크 스트리밍(Spark Streaming), 삼자(Samza), 플링크(Flink)등의 처리 인프라와 실시간성의 데이터 수집을 위한 플룸(Flume)과 카프카(Kafka) 등의 다양한 처리 에코시스템이 발전한다. 하둡의 배치성/준 실시간성을 극복하기 위해 위의 여러 오픈소스 생태계를 조합하여 실시간 처리를 할 수 있는 개념들이 나타난다. 람다 아키텍처는 나단 마즈가 트위터에서의 분산프로세싱 경험을 바탕으로 스피드 레이어(Speed Layer), 배치 레이어(Batch Layer), 서빙 레이어(Serving Layer)로 3계층 구성된 실시간 처리 아키텍처이다.

업데이트

• 2013년 12월 10일 : 마이클 하우젠블라스(Michael Hausenblas)의 Why are we doing this and why are we doing this now?
• 2013년 12월 11일 : 나단 비낸스(Nathan Bihnens)의 하둡 및 스톰을 사용한 실시간 아키텍처
• 2013년 12월 24일 : 다중 언어 지속성이 마이클 하우젠블라스의 람다 아키텍처를 충족하는 경우
• 2013년 12월 25일 : 마이클 하우젠블라스의 정적 및 동적 데이터 통합 관리 문제
• 2013년 12월 25일 : 마이클 하우젠블라스가 만든 Lamb doop
• 2013년 12월 25일 : 마이클 하우젠블라스가 만든 Twitter Summing bird
• 2014년 1월 19일 : 페레 페레라(Pere Ferrera)의 Trident, 하둡 및 SploutSQL을 사용한 해시 태그의 실시간 분석을 위한 람다 아키텍처 예
• 2014년 1월 20일 : 람다 아키텍처 : 페레 페레라의 최첨단 제품
• 2014년 6월 22일 : 빌딩 숲 : 하비 로만(Javi Roman)이 지은 람다 건축 환경 구축 업체
• 2014년 6월 30일 : 마이클 하우젠블라스의 배치 구성 요소
• 2014년 6월 30일 : 마이클 하우젠블라스의 서비스 구성 요소
• 2014년 6월 30일 : 마이클 하우젠블라스의 속도 구성 요소
• 2014년 7월 01일 : 마이클 하우젠블라스가 쓴 나탄 마르쿠스의 빅데이터 책
• 2014년 7월 24일 : Deploop : 하비 로만의 람다 아키텍처 프로비저닝 도구
• 2014년 8월 27일 : RAD스택 : 드루이드 커미터스(Druid Committers)의 카프카, 스톰, 하둡, 드루이드(Druid)
• 2016년 7월 16일 : 아킴 니에르백(Achim Nierbeck)의 스파크, 카사안드라, 카프카 및 Akka와 함께 사물인터넷 데이터를 분석하기 위한 람다 아키텍처 예시
• 2017년 3월 25일 : 블라디미르 도로코프(Vladimir Dorokhov)가 마이크로소프트 애저(Azure) 클라우드에 람다 아키텍처를 적용했다.
• 2017년 4월 15일 : 나라얀 쿠마(Narayan Kuma)가 스파크, 스파크-스트리밍, 카산드라, 카프카, Twitter4j, Akka및 Akka-http를 사용하여 트위터의 트윗(tweet)을 분석하는 람다 아키텍처의 예를 보여줬다.

특징

대용량 데이터는 일반적으로 쿼리에 많은 시간이 소요된다. 데이터양에 따라 조회에 몇 시간이 걸릴 수 있다. 람다 아키텍처는 스피드 레이어와 배치 레이어의 조합으로 대용량 데이터에도 어느 정도의 실시간 분석을 지원해줄 수 있다. 데이터가 생성되면 데이터 저장소에 저장한다. 이 데이터는 배치로 일정 주기마다 배치 뷰를 만들어 낸다. 그리고 동일한 데이터를 실시간 데이터 처리를 통해 real-time 뷰를 만들다. 그리고 이 두 개를 혼합해 빠르고 실시간 데이터가 반영된 분석을 할 수 있다.

구성

• 배치 레이어

기존에 데이터처리를 위한 배치 프로세스이다. 데이터를 처리하는 단위(unit)로 데이터가 입력되면 해당 단위로 데이터 처리를 하게 된다. 입력되는 데이터는 마스터 데이터 세트라고 해서 저장되거나 읽기만 가능하고 변경은 안 되는 성질을 갖는다. 대용량 데이터를 집계할 때는 시간이 오래 걸리는데 조회를 요청할 때마다 데이터를 제공해주는 데 매번 몇 시간이 걸리는 서비스를 사용할 유저는 없을 것이다. 그래서 특정 시간마다 주기적으로 계산을 수행하는 배치를 이용하여 데이터를 미리 계산해 놓는 것이다. 배치 레이어의 저장소에서는 로우(raw) 데이터를 보관해놓는다. 이로 인해 배치 뷰의 데이터가 부정확할 때 복구가 가능해지고, 새로운 뷰를 제공하고자 할 때, 기존의 원본 데이터를 가지고 있어서 새로운 뷰의 통계 분석이 가능해진다. 특정 단위의 배치 프로세스이기 때문에 데이터의 정합성이나 충돌, 동시성, 이상 현상, 장애 등에 대해서 비교적 자유로운 특성을 갖는다. 일반적으로 사용하는 솔루션으로는 아파치 하둡이 있다.

• 스피드 레이어

배치 레이어를 사용하여 대용량 데이터 조회 속도의 문제를 해결했지만, 배치가 도는 간격 사이에 있는 데이터는 조회할 수 없다. 예를 들어서 배치가 매일 자정마다 동작한다면 당일 오후에는 해당 일자의 데이터를 확인할 수 없는 것처럼, 이런 문제를 해결하기 위해서 당일 데이터를 실시간으로 집계해서 별도의 테이블에 집계한다. 즉, 스피드 레이어의 역할은 배치 레이어에서 생기는 차이를 채우는 것이다. 배치 레이어가 특정 단위작업 이후에 들어오는 실시간 데이터를 처리하고 응답시간을 빠르게 유지하는 역할을 하는 레이어이다. 스트림으로 들어온 데이터를 처리하기 위한 큐나 버퍼 같은 구조를 사용하고 효율적 스트림 처리를 위한 증분 처리 방식을 사용한다. 배치프로세스가 완료된 시점에는 처리된 실시간 뷰는 삭제되게 된다. 사용하는 솔루션으로 아파치 스톰, SQL 스트림, 아파치 스파크 등이 있다.

• 서빙 레이어

배치 레이어 및 스피드 레이어의 출력을 저장한다. 클라이언트에서는 이 서빙 레이어에 미리 계산된 데이터를 조회하기 때문에 빠른 응답이 가능해진다.

각 레이어에서 사용되는 솔루션을 예를 들어 설명하면 이해가 잘된다. 배치 레이어인 하둡/HDFS, 하둡/맵리듀스는 데이터를 저장하고 맵리듀스로 데이터를 분석한다. 그리고 서빙 레이어는 H베이스로 맵리듀스로 분석한 데이터를 저장하는 NoSql이다. 스피드 레이어는 스트리밍 데이터를 처리하는 스톰을 사용하고, 빠른 데이터 처리가 필요하다는 뜻이다. 그리고 메모리 기반의 레디스(redis)를 사용한다. 즉 빠른 속도가 필요한 솔루션을 사용했다.

• 레이어별 적용 시스템 리스트

람다 아키텍처는 데이터를 처리하는 구조를 설명하기 때문에 레이어별 사용 시스템에 대한 정답이 없다. 아래는 사용 가능한 솔루션 리스트이다.

배치 레이어 컴포넌트

이름	사용언어	플랫폼	비고
Hadoop MapReduce	Java	Hadoop	Very low-level, not re-usable[^1]
Spark	Scala/Java/Python	Spark	In-memory
Hive	HiveQL/Java	Hadoop	-
Spark SQL	SQL/Scala/Java/Python	Spark	-
Pig	Pig Latin/Java	Hadoop	-
Sprok	Pig Latin/Java	Spark	-
Cascading/Scalding	Java/Scala	Hadoop	-
Cascalog	Clojure	Hadoop	-
Crunch/Scrunch	Java/Scala	Hadoop	-
Pangool	Java	Hadoop	-

서빙 레이어 컴포넌트

이름	사용언어
ElephantDB	Clojure
SploutSQL	Java
Voldemort	Java
HBase	Java
Druid	Java

스피드 레이어 컴포넌트

이름	사용언어	비고
Apache Storm	Clojure	Twitter
Apache Spark Streaming	Scala/Java/Python	AMPLab
Apache Samza	Scala/Java	Linkedln
Apache S4	Java	Yahoo!
Spring XD	Java	Pivotal

장점

3계층의 람다 아키텍처는 데이터의 정확성,일관성을 제공함과 동시에 최소의 지연으로 실시간적인 결과를 사용자에게 제공한다.

단점

스피드 레이어와 배치 레이어가 모두 똑같은 처리를 구현하고 있으므로 중복된 비지니스 로직 및 두 경로의 아키텍처 관리에 따른 복잡성이 발생한다. 이 때문에 람다 아키텍처를 단순화한 카파 아키텍처(Kappa architercutre)를 선택하기도 한다. 또, 배치처리와 실시간처리시의 개발언어나 오픈소스 인프라의 컨셉자체가 틀려 고려할 사항이 많고 이에 따라 기능이 중복되고 관리/유지보수에 많은 공수가 투입되며 복잡하다는 단점이 있다.

참고자료

• 〈차세대 람다 아키텍처〉, 《로그프레소》
• Saint Binary, 〈빅데이터의 실시간 처리와 람다/카파 아키텍처〉, 《티스토리》, 2018-10-10
• Gyrfalcon, 〈람다 아키텍쳐(Lambda Architecture) 정리〉, 《티스토리》, 2017-03-21
• James Lee, 〈람다 아키텍쳐(Lambda Architecture) 정리〉, 《티스토리》, 2018-11-25

같이 보기

• 빅데이터
• 배치
• 아파치
• 레이어
• 데이터베이스
• 사물인터넷
• 카파 아키텍처

이 람다 아키텍처 문서는 프로그래밍에 관한 토막글입니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 이 문서의 내용을 채워주세요.

개발 : 프로그래밍 □■⊕, 소프트웨어, 데이터, 솔루션, 보안, 하드웨어, 컴퓨터, 사무자동화, 인터넷, 모바일, 사물인터넷, 게임, 메타버스, 디자인 프로그래밍 언어 ASP • C 언어 • C++ • C# • CSS • D 언어 • HTML • HTML5 • JSP • PHP • R • XHTML • XML • XSLT • 고(Go) • 고급언어 • 기계어 • 델파이 • 러스트 • 루비 • 루아 • 리액트 • 리퀴디티 • 무브 • 미켈슨 • 베이직 • 브이비스크립트 • 비주얼 C++ • 비주얼베이직(VB) • 비주얼베이직닷넷(VB.NET) • 솔리디티 • 스몰토크 • 스위프트 언어 • 스칼라 • 스크립트 언어 • 알골 • 어셈블리 • 언리얼스크립트 • 얼랭 • 에이잭스(Ajax) • 엠에프씨(MFC) • 오브젝티브-C • 오브젝트 파스칼 • 오카멜 • 웹어셈블리(WASM) • 이와즘(eWASM) • 자바 • 자바스크립트 • 저급언어 • 제이슨(JSON) • 제이쿼리(jQuery) • 카멜 • 코볼 • 코틀린 • 콜드퓨전 • 타입스크립트 • 파스칼 • 파워스크립트 • 파이썬 • 펄(Perl) • 포트란 • 프로씨(Pro-C) • 피엘에스큐엘(PL/SQL) • 피엘원(PL/I) • 하스켈 개발방법론 CBD 개발방법론 • EA • 구조적 개발방법론 • 객체지향 개발방법론 • 라이브러리 • 람다 아키텍처 • 모듈 • 모듈화 • 벤치마킹 • 소프트웨어 개발방법론 • 스크럼 • 스프린트 • 아키텍처 • 아키텍트 • 애자일 • 웹개발방법론 • 정보공학 개발방법론 • 컴포넌트 • 테일러링 • 템플릿 • 폭포수 모델 • 프로젝트 • 프로토타입 • 피드백 코딩 EUC-KR • UTF-8 • 값 • 글루웨어 • 디버깅 • 디코딩 • 마크업 • 버그 • 부트스트랩 • 세이브포인트 • 소스코드 • 시큐어코딩 • 아스키 • 액티브엑스 • 오픈소스 • 유니코드 • 인코딩 • 재컴파일 • 주석 • 컴파일 • 컴퓨터 프로그램 • 코드 • 코딩 • 태그 • 테스트 • 테이블 • 텍스트 • 파싱 • 퍼블리싱 • 퓨니코드 • 하드코딩 • 하이퍼링크 • 하이퍼텍스트 프로그래밍 C 명령어 • 객체 • 객체지향 • 객체지향 프로그래밍 • 거짓 • 관계연산자 • 기본형 변수 • 널 • 논리 • 논리연산 • 논리연산자 • 다중상속 • 다형성 • 대입 • 대입문 • 대입연산자 • 더블 • 도스 명령어 • 디폴트 • 레지스터변수 • 루프 • 리눅스 명령어 • 리턴 • 메모리 주소 • 메소드 • 멤버 • 명령문 • 명령어 • 무한루프 • 문자 • 문자열 • 바이트 • 반복문 • 배열 • 변수 • 분기 • 분기문 • 불린 • 브레이크 • 비교연산자 • 비트연산자 • 산술연산자 • 상속 • 상수 • 생성자 • 선언 • 선언문 • 설정자 • 속성 • 스위치 • 스태틱 • 시프트연산자 • 실행 • 실행문 • 어노테이션 • 에코 • 역참조 • 연산 • 연산문 • 연산자 • 오버로딩 • 오버라이딩 • 외부변수 • 윈도우 명령어 • 유닉스 명령어 • 인스턴스 • 인스트럭션 • 인클루드 • 인터페이스 • 임포트 • 입력 • 입력문 • 입출력 • 입출력문 • 자료형(데이터 타입) • 자바 명령어 • 자바 예약어 • 자바 컬렉션 • 전역변수 • 접근자 • 접근제어자 • 정보은닉 • 정수형 • 정적변수 • 제어 • 제어문 • 제어자 • 조건 • 조건문 • 조건연산자 • 주소 • 증감연산자 • 지역변수 • 참 • 참조 • 참조변수 • 초기화 • 추상메소드 • 추상클래스 • 추상화 • 출력 • 출력문 • 캡슐화 • 케이스 • 클래스 • 파라미터(매개변수) • 파이널 • 패키지 • 퍼블릭 • 포인터 • 프라이빗 • 프로텍티드 • 필드(멤버변수) • 함수 • 환경변수 명령어 abstract • array • boolean • break • byte • case • char • continue • default • double • do while • echo • elif • else • else if • false • final • float • for • gosub • goto • if • if else • import • include • int • join • long • long long • null • print • printf • println • private • protected • public • return • scanf • short • stdio.h • static • string • switch • temp • then • true • unsigned • void • while 디자인패턴 구조패턴 • 동시성패턴 • 동시실행패턴 • 모델-뷰-컨트롤러 패턴 • 상태패턴 • 생성패턴 • 싱글톤패턴 • 아키텍처패턴 • 전략패턴 • 커맨드패턴 • 행동패턴 프로그래밍 인물 귀도 반 로썸 • 그레이스 머레이 호퍼 • 니클라우스 비르트 • 댄 브릭클린 • 더그 커팅 • 데니스 리치 • 리누스 토르발스 • 리처드 그린블라트 • 마거릿 해밀턴 • 마크 앤드리슨 • 빈트 서프 • 빌 게이츠 • 빌 조이 • 스티브 잡스 • 에이다 러브레이스 • 제임스 고슬링 • 척 벤턴 • 켄 톰슨 • 팀 패터슨 위키 : 자동차, 교통, 지역, 산업, 기업, 단체, 업무, 쇼핑, 블록체인, 암호화폐, 인공지능, 개발, 인물, 행사, 일반