맨위로가기

람다 아키텍처

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

람다 아키텍처는 배치 계층, 속도 계층, 서빙 계층을 활용하여 대량의 데이터를 처리하는 데이터 처리 아키텍처이다. 배치 계층은 모든 데이터를 처리하여 정확성을 높이고, 속도 계층은 실시간 데이터를 처리하여 대기 시간을 최소화하며, 서빙 계층은 두 계층의 출력을 저장하고 쿼리에 응답한다. 람다 아키텍처는 메타마켓츠, 야후, 넷플릭스 등에서 활용되었지만, 복잡성 및 코드 동기화 문제로 비판을 받기도 하며, 카파 아키텍처와 같은 대안이 제시되었다.

더 읽어볼만한 페이지

  • 데이터 처리 - 정렬
    정렬은 데이터를 특정 기준에 따라 순서대로 배열하는 과정으로, 검색 및 병합 알고리즘의 효율성을 높이고, 정의된 순서로 데이터 처리를 가능하게 하며, 오름차순과 내림차순으로 나뉘고, 컴퓨터 과학과 다양한 산업 분야에서 활용된다.
  • 데이터 처리 - 정렬 알고리즘
    정렬 알고리즘은 데이터를 효율적으로 구성하기 위해 원소들을 특정 순서로 재배열하는 알고리즘으로, 메모리 사용량, 안정성, 계산 복잡도 등 다양한 기준에 따라 분류되며 컴퓨터 과학에서 중요한 주제이다.
  • 빅 데이터 - 예측 분석
    예측 분석은 통계학, 기계 학습 등의 분석 기법을 활용하여 과거 및 현재 데이터를 토대로 미래의 사건이나 결과를 예측하는 방법론으로, 다양한 분야에서 의사 결정 지원 및 위험 관리 등에 활용되지만, 인간 행동의 복잡성으로 인한 예측 불가능성에 대한 비판도 존재한다.
  • 빅 데이터 - 데이터 분석
    데이터 분석은 원시 데이터를 수집하여 의사 결정을 돕는 유용한 정보로 변환하는 과정으로, 데이터 수집, 처리, 정제, 탐색적 분석, 모델링, 데이터 제품 개발, 결과 소통 등의 단계를 거치며, 효과적인 분석을 위해 사실과 의견을 구별하고 편향을 극복하는 것이 중요하다.
  • 자유 소프트웨어 프로젝트 - 줄리아 (프로그래밍 언어)
    줄리아는 2012년에 공개된 고수준 프로그래밍 언어로, 다중 디스패치, 동적 타입 시스템, C와 유사한 성능을 제공하며, 수치 계산, 과학 기술 계산 등에 활용된다.
  • 자유 소프트웨어 프로젝트 - 코틀린 (프로그래밍 언어)
    코틀린은 젯브레인즈에서 개발한 정적 타입 언어로, 자바 가상 머신에서 동작하며 자바와의 호환성을 갖고, 안드로이드 공식 지원 언어로 채택되어 다양한 분야에서 활용되고 있으며, 이름은 러시아의 코틀린 섬에서 유래되었다.
람다 아키텍처

2. 배치 계층 (Batch Layer)

배치 계층은 람다 아키텍처의 세 가지 핵심 요소 중 하나로, 전체 데이터 세트의 변경 불가능한 마스터 사본으로부터 데이터를 받아 처리하는 역할을 한다.[3] 이 계층은 대규모 데이터를 처리하기 위해 분산 처리 시스템을 사용하여 결과를 미리 계산한다.[3] 배치 계층의 목표는 사용 가능한 모든 데이터를 처리하여 뷰를 생성함으로써 완벽한 정확성을 추구하는 데 있다.[3]

2. 1. 특징

배치 레이어는 대량의 데이터를 처리하기 위해 분산 처리 시스템을 사용하여 결과를 미리 계산한다. 배치 레이어는 뷰를 만들 때 가용한 모든 데이터를 처리하여 완벽한 정확성을 추구한다. 즉, 전체 데이터 세트를 다시 계산하고 기존 뷰를 업데이트함으로써 오류를 수정할 수 있다. 결과는 보통 읽기 전용 데이터베이스에 저장되고, 업데이트 시에는 기존에 미리 계산된 뷰를 완전히 새로운 것으로 바꾼다.[3]

2014년까지는 아파치 하둡이 주요 배치 처리 시스템으로 여겨졌다.[5] 이후에는 스노우플레이크, 레드 시프트(Redshift), 시냅스(Synapse), 빅 쿼리(Big Query)와 같은 다른 관계형 데이터베이스도 이 역할을 수행하는 데 사용되고 있다.

2. 2. 활용 기술

배치 레이어는 대규모 데이터를 처리할 수 있는 분산 처리 시스템을 활용하여 결과를 미리 계산한다. 배치 레이어는 뷰를 생성할 때 가용한 모든 데이터를 처리하여 완벽한 정확성을 추구한다. 이는 전체 데이터 세트를 기반으로 다시 계산하고 기존 뷰를 업데이트함으로써 오류를 수정할 수 있음을 의미한다. 결과는 보통 읽기 전용 데이터베이스에 저장되며, 업데이트 시에는 기존에 미리 계산된 뷰를 완전히 대체한다.[3]

2014년까지는 아파치 하둡이 주요 배치 처리 시스템으로 여겨졌다.[5] 이후 스노우플레이크, 레드 시프트(Redshift), 시냅스(Synapse), 빅 쿼리(Big Query)와 같은 다른 관계형 데이터베이스도 이 역할을 수행하는 데 사용되고 있다.

3. 속도 계층 (Speed Layer)

속도 계층(Speed Layer)은 데이터를 실시간으로 처리하는 역할을 담당한다.[3] 이 계층의 주된 목표는 가장 최근 데이터에 대한 실시간 보기를 제공하여 데이터 처리의 대기 시간을 최소화하는 것이다. 배치 계층(Batch Layer)에서 데이터를 처리하는 데 시간이 걸리는 동안 발생하는 데이터 공백을 메우는 보완적인 역할을 수행한다.[3] 속도 계층에서 처리된 결과는 배치 계층의 결과만큼 완전하거나 정확하지 않을 수 있지만, 데이터 발생 즉시 활용 가능하다는 장점이 있다.[3] 이 계층에서 처리된 결과는 추후 배치 계층에서 동일한 데이터에 대한 처리 결과가 나오면 대체될 수 있다.[3]

3. 1. 특징

람다 아키텍처의 처리 및 제공 계층을 통한 데이터 흐름을 보여주는 다이어그램. 명명된 구성 요소의 예가 표시되어 있습니다.


스피드 레이어는 실시간으로 데이터를 처리하며 수정이나 완전성에 대한 요구 사항이 없다. 이 계층은 가장 최근 데이터에 대한 실시간 보기를 제공하여 대기 시간을 최소화하는 것을 목표로 하므로 처리량을 희생한다. 본질적으로, 스피드 레이어는 가장 최근 데이터를 기반으로 보기를 제공하는 배치 레이어의 지연으로 인해 발생하는 "격차"를 채우는 역할을 한다. 이 계층의 보기는 배치 레이어가 최종적으로 생성하는 것만큼 정확하거나 완전하지 않을 수 있지만, 데이터를 받은 직후에 거의 즉시 사용할 수 있으며, 동일한 데이터에 대한 배치 레이어의 보기가 사용 가능해지면 교체될 수 있다.[3]

이 계층에서 일반적으로 사용되는 스트림 처리 기술로는 아파치 카프카(Apache Kafka), 아마존 키네시스(Amazon Kinesis), 아파치 스톰(Apache Storm), SQLstream, 아파치 삼자(Apache Samza), 아파치 스파크(Apache Spark), 애저 스트림 분석(Azure Stream Analytics), 아파치 플링크(Apache Flink)가 있다. 출력은 일반적으로 빠른 NoSQL 데이터베이스,[6][7] 또는 커밋 로그에 저장된다.[8]

3. 2. 활용 기술



람다 아키텍처의 스피드 레이어는 실시간으로 데이터를 처리하는 데 특화되어 있으며, 수정이나 완전성에 대한 엄격한 요구 사항 없이 가장 최근 데이터에 대한 실시간 보기를 제공하는 것을 목표로 한다. 이를 통해 데이터 처리의 지연 시간을 최소화하지만, 처리량은 다소 희생될 수 있다. 스피드 레이어는 배치 레이어에서 처리되어 제공되기까지 시간이 걸리는 데이터의 공백을 메우는 역할을 한다. 이 계층에서 제공하는 데이터 보기는 배치 레이어의 결과만큼 완전하거나 정확하지 않을 수 있지만, 데이터가 발생하는 즉시 활용 가능하다는 장점이 있다. 추후 배치 레이어에서 동일한 데이터에 대한 처리 결과가 나오면 스피드 레이어의 결과는 대체될 수 있다.[3]

스피드 레이어에서는 다음과 같은 스트림 처리 기술들이 주로 활용된다.

스피드 레이어에서 처리된 결과는 일반적으로 빠른 응답 속도를 제공하는 NoSQL 데이터베이스[6][7]나 커밋 로그(Commit Log)에 저장된다.[8]

4. 서빙 계층 (Serving Layer)

서빙 계층은 람다 아키텍처를 구성하는 세 가지 계층 중 하나이다.[3] 배치 계층과 속도 계층에서 처리된 결과는 서빙 계층에 저장되며, 서빙 계층은 이 데이터를 사용하여 사전 계산된 뷰를 제공하거나 임시 쿼리에 응답하는 역할을 수행한다.

4. 1. 특징

람다 아키텍처와 아파치 드루이드 데이터 저장소를 보여주는 다이어그램


배치 계층과 속도 계층의 출력은 서빙 계층에 저장된다. 서빙 계층은 사전 계산된 뷰를 반환하거나, 처리된 데이터를 기반으로 뷰를 구축하여 임시 쿼리에 응답하는 역할이다.

서빙 계층에서 사용되는 기술 중에는 배치 계층과 속도 계층의 출력을 모두 처리하는 단일 플랫폼을 제공하는 아파치 드루이드, 아파치 피노, 클릭하우스, Tinybird 등이 있다.[9] 또한, 각 계층의 출력을 위한 전용 저장소를 사용하기도 한다. 속도 계층 출력을 위해서는 아파치 카산드라, 아파치 HBase, 애저 코스모스 DB, MongoDB, VoltDB, Elasticsearch 등이 사용될 수 있다. 배치 계층 출력을 위해서는 Elephant DB, 아파치 임팔라, SAP HANA, 아파치 하이브 등이 사용된다.[2][6]

4. 2. 활용 기술



배치 계층과 속도 계층의 출력은 서빙 계층에 저장된다. 서빙 계층은 이렇게 저장된 사전 계산된 뷰를 반환하거나, 처리된 데이터로부터 뷰를 구축하여 임시 쿼리에 응답하는 역할을 한다.

서빙 계층에서 사용되는 기술의 예시는 다음과 같다.

  • 통합 플랫폼 (배치 및 속도 계층 출력 모두 처리):
  • * 아파치 드루이드(Apache Druid)
  • * 아파치 피노(Apache Pinot)
  • * 클릭하우스(ClickHouse)
  • * [https://tinybird.co Tinybird][9]

5. 최적화

람다 아키텍처에서는 원시 데이터 집합을 최적화하고 쿼리 효율성을 개선하기 위해 다양한 기법이 사용된다. 주요 기법으로는 롤업 및 집계 기술이 있으며,[9] 계산 비용 절감을 위한 추정 기술도 활용된다.[10] 또한, 내결함성 확보와 효율성 증대를 위해 점진적 계산 알고리즘을 적용하고, 부분 계산이나 자원 사용 최적화를 통해 대기 시간을 줄이기도 한다.[3]

5. 1. 롤업 및 집계

원시 데이터를 최적화하고 쿼리 효율성을 개선하기 위해 다양한 롤업 및 집계 기술이 실행된다.[9] 계산 비용을 줄이기 위해 추정 기술도 사용된다.[10] 내결함성 확보를 위해서는 비용이 많이 드는 전체 재계산이 필요할 수 있다. 하지만 효율성을 높이기 위해 점진적 계산 알고리즘을 선택적으로 추가할 수 있으며, "부분 계산"이나 자원 사용 최적화 같은 기술은 대기 시간을 효과적으로 줄이는 데 도움이 될 수 있다.[3]

5. 2. 추정 기술

원시 데이터 집합을 최적화하고 쿼리 효율성을 개선하기 위해 다양한 롤업 및 집계 기술이 실행된다.[9] 이러한 기술들과 더불어, 계산 비용을 더욱 줄이기 위한 목적으로 추정 기술이 사용된다.[10]

5. 3. 점진적 계산

람다 아키텍처에서는 데이터 처리의 효율성을 높이기 위해 다양한 기법이 사용된다. 예를 들어, 원시 데이터 집합을 최적화하고 쿼리 효율성을 개선하기 위해 롤업이나 집계 기술이 활용되며,[9] 계산 비용을 줄이기 위해 추정 기술이 사용되기도 한다.[10]

하지만 내결함성을 확보하기 위해 전체 데이터를 다시 계산해야 하는 경우가 있는데, 이는 상당한 비용과 시간이 소요될 수 있다. 이러한 문제를 해결하고 효율성을 높이기 위해 점진적 계산 알고리즘을 선택적으로 도입할 수 있다. 점진적 계산은 변경된 부분만 계산하는 방식으로, 전체 재계산에 비해 계산 비용을 크게 줄일 수 있다. 또한, "부분 계산"이나 자원 사용 최적화 같은 기술과 함께 사용하면 대기 시간을 효과적으로 단축하는 데 도움이 된다.[3]

6. 활용 사례

람다 아키텍처는 빅데이터 처리 및 분석을 위해 다양한 기업에서 활용되고 있다. 대표적인 사례로 광고 분석 서비스를 제공하는 메타마켓츠[9], 광고 데이터 웨어하우스를 운영하는 야후[11], 그리고 자체적인 데이터 처리 파이프라인을 구축한 넷플릭스[12] 등이 있다. 이들 기업은 실시간 데이터 처리와 배치 처리의 장점을 결합하여 자사의 서비스 요구사항에 맞는 데이터 분석 시스템을 구축 및 운영하고 있다. 각 기업의 구체적인 활용 방식은 하위 섹션에서 더 자세히 설명한다.

6. 1. 메타마켓츠 (Metamarkets)

메타마켓츠(Metamarkets)는 프로그램 방식 광고 분야의 회사들을 위한 분석 서비스를 제공하며, 스트리밍 및 일괄 처리된 데이터를 저장하고 제공하기 위해 Druid를 사용하는 람다 아키텍처의 버전을 사용한다.[9]

야후(Yahoo)는 광고 데이터 웨어하우스에서 분석을 실행하기 위해 유사한 접근 방식을 취했으며, Apache Storm, Apache Hadoop, 그리고 Druid를 사용한다.[11]

넷플릭스(Netflix)의 Suro 프로젝트는 데이터를 위한 별도의 처리 경로를 가지고 있지만, 람다 아키텍처를 엄격하게 따르지는 않는다. 이는 경로가 서로 다른 목적을 제공하기 위한 것일 수 있으며, 반드시 동일한 유형의 보기를 제공하기 위한 것은 아니기 때문이다.[12] 그럼에도 불구하고, 전체적인 아이디어는 선택된 실시간 이벤트 데이터를 매우 낮은 지연 시간으로 쿼리할 수 있도록 하는 동시에, 전체 데이터 세트가 일괄 파이프라인을 통해 처리되도록 하는 것이다. 후자는 지연 시간에 덜 민감하고 맵-리듀스 유형의 처리를 필요로 하는 애플리케이션을 위한 것이다.

6. 2. 야후 (Yahoo)

야후(Yahoo)는 광고 데이터 웨어하우스에서 분석을 실행하기 위해 유사한 접근 방식을 취했으며, Apache Storm, Apache Hadoop, 그리고 Druid를 사용한다.[11]

6. 3. 넷플릭스 (Netflix)

넷플릭스의 Suro 프로젝트는 데이터를 위한 별도의 처리 경로를 가지고 있지만, 람다 아키텍처를 엄격하게 따르지는 않는다. 이는 각 경로가 서로 다른 목적을 위해 사용될 수 있으며, 반드시 동일한 유형의 결과를 제공하기 위한 것은 아니기 때문이다.[12] 그럼에도 불구하고, 전체적인 아이디어는 선택된 실시간 이벤트 데이터를 매우 낮은 지연 시간으로 쿼리할 수 있도록 하는 동시에, 전체 데이터 세트가 일괄 파이프라인을 통해 처리되도록 하는 것이다. 후자는 지연 시간에 덜 민감하고 맵리듀스 유형의 처리를 필요로 하는 애플리케이션을 위한 것이다.

7. 비판 및 대안

람다 아키텍처는 구조적인 복잡성과 코드 관리의 어려움 등으로 인해 비판을 받는다.[13] 이러한 문제점을 해결하기 위한 대안으로 Jay Kreps가 제안한 카파 아키텍처와 같은 순수 스트리밍 방식이 주목받고 있다.[13][14]

7. 1. 비판

람다 아키텍처에 대한 비판은 주로 그 구조의 본질적인 복잡성과 제한적인 영향력에 초점을 맞춘다. 배치 계층과 스트리밍(실시간) 계층은 각각 별도의 코드 베이스를 필요로 한다. 이 때문에 두 경로에서 처리된 데이터가 동일한 결과를 내도록 코드를 유지하고 동기화하는 작업이 요구된다. 반대로, 두 코드 베이스를 단일 프레임워크로 추상화하려는 시도는 배치 및 실시간 처리 생태계에서 제공하는 다양한 특수 도구들을 활용하기 어렵게 만드는 한계를 가진다.[13]

7. 2. 카파 아키텍처 (Kappa Architecture)

Jay Kreps는 단일 코드 베이스로 순수한 스트리밍 방식을 사용하기 위해 카파 아키텍처를 도입했다.[13] 순수한 스트리밍 방식을 채택하는 것의 장점에 대한 기술적인 논의에서, 아파치 삼자와 같은 유연한 스트리밍 프레임워크를 사용하면 지연 시간 없이 배치 처리와 동일한 이점을 얻을 수 있다는 점이 언급되었다.[14] 이러한 스트리밍 프레임워크는 임의로 큰 데이터 창을 수집하고 처리하고, 블로킹을 수용하며, 상태를 처리할 수 있게 한다.

참조

[1] 웹사이트 Nathan Marz on Storm, Immutability in the Lambda Architecture, Clojure http://www.infoq.com[...] 2014-04-06
[2] 간행물 A real-time architecture using Hadoop and Storm http://lambda-archit[...] 2013-12-11
[3] 서적 Big Data: Principles and best practices of scalable realtime data systems Manning Publications 2013
[4] 간행물 How to beat the CAP theorem http://nathanmarz.co[...] 2011-10-13
[5] 뉴스 Hadoop Sector will Have Annual Growth of 58% for 2013-2020 http://cloudtimes.or[...] Cloud Times 2014-05-28
[6] 간행물 The Lambda architecture: principles for architecting realtime Big Data systems http://jameskinley.t[...] 2014-08-26
[7] 간행물 Lambda Architecture: A state-of-the-art https://web.archive.[...] Datasalt 2014-01-17
[8] 간행물 Kafka and Events – Key/Value Pairs https://developer.co[...] Confluent 2022-10-06
[9] 간행물 Real-time Analytics with Open Source Technologies https://speakerdeck.[...] 2014-07-30
[10] 간행물 The Art of Approximating Distributions: Histograms and Quantiles at Scale https://metamarkets.[...] Metamarkets 2013-09-12
[11] 간행물 Interactive Analytics in Human Time http://www.slideshar[...] 2014-06-17
[12] 간행물 Announcing Suro: Backbone of Netflix's Data Pipeline http://techblog.netf[...] Netflix 2013-12-09
[13] 웹사이트 Questioning the Lambda Architecture https://www.oreilly.[...] Oreilly 2024-10-03
[14] 뉴스 Hacker News https://news.ycombin[...] 2014-08-20
[15] 웹사이트 Lambda vs Kappa Architecture https://www.interlin[...] 2024-08-01


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com