So my name is David Shepherd. This is Jonathan Indig. Um, we are software engineers at Netflix, and today we're going to talk about a system that we work on built on Clojure and Datomic.

Uh, and we hope to give you some insight into how this system makes use of Datomic in particular and how it has empowered the project's success over the last decade.

So, uh, we'll talk a little bit about kind of what it is, um, what we built, how it's evolved over the last 10 years, uh, and then Jonathan's going to talk about how stability has been important to us as an organization and contrast that um, with how instability uh, affects us.

So, what do we build? Um, so this is not actually the first time we've introduced the system.

Our dear friend and colleague Matt Bostonbrook gave a talk at the Conj almost 10 years ago to the day uh, introducing this system.

Uh, Do or Do Not, There Is No Try. Uh, this was a system for uh, uh, for building data pipelines.

Um, and if you've not seen this talk, I highly recommend you go watch it. Many of the core ideas that went into how we think about data pipelines, um, how we model them, are are still very much alive and well today.

We've made many advancements over the last 10 years, but this the still core ideas are still true um, to this day.

Um, so what is it? So, uh, it's for building data pipelines.

Um, and it's it's really for data scientists and researchers to define uh, data, in particular ML uh, ML training pipelines.

Um, so we give them a simple Python API. No tomatoes, please. We got to meet them where they're at.

Um, but it essentially allows them to define these pure Python functions. They can decorate them. They compose these functions together.

Uh, and we essentially take that call graph on the right and we translate it into EDN. We turn the date math into Clojure expressions that we can evaluate in SCI and that resultant payload is basically what we use to compute the underlying um the underlying DAG.

So we can take that example and run those, right?

These run in distributed uh in a distributed way on separate um instances. Um, now that's all well and good. Many orchestration systems can do this.

It's not particularly interesting, but um the the the feature that sort of sets Dagobah apart is that we have a very um robust model to track data provenance, right?

So we know the code and data that flows through every single one of these steps.

And so we can actually do structural sharing uh like you you would do with persistent like Clojure does with persistent data structures.

We do that for um data pipelines. So in the example above, you can make a structural change to the pipeline to sort of edit let's say the depth in which you wanted to recurse.

Uh and we can work out the part of the pipeline that actually we can totally reuse and skip and memoize and we only have to compute the necessary delta to materialize the sort of new result that this researcher wants.

Um, needless to say this is a huge productivity boost for researchers in Netflix.

Um, two researchers working on the same pipeline will automatically share the common components.

They're not restarting from scratch. You know, these jobs, you know, they're not trivial things doing simple math in Python.

These are like Spark jobs processing hundreds of terabytes of data, taking hours or days to run. Um, and so not having to do them is a big win, not just for time, but money saved for Netflix.

So, um, this system is currently responsible for orchestrating all personalization ML data prep and model training at Netflix.

Um, uh, we have no dedicated Datomic or Clojure support team. Uh, I mean, you're you're looking at them, basically.

Um, we we do, however, pay for an enterprise Datomic support contract. Um, this is extremely critical infrastructure for Netflix and we are we do not want to go it alone, right?

We take all the resources we can, uh, and we have fantastic partners, um, helping us do it.

So, in the beginning, um, Dagob was built to support a single ML team, right, from its genesis, right? Um, so early days, the architecture was quite simple, right?

It was deployed essentially as a monolith in an HA way using Zookeeper to sort of manage leadership state. Um, and this one one deployment would manage all aspects of the application: handling API requests, launching jobs on underlying compute systems, updating state and persisting that into um, and we deployed Datomic on-prem backed by a Cassandra cluster, um, with a sort of shared Memcached deployment as well.

Um, now there's a couple interesting properties of the the state machine that we maintain. Um, it's actually written as a forward inference rules engine, not too different from like Clara rules.

Um, our rules are structured around essentially a Datomic query to a pure function that produces transaction data.

We run those rules with the result onto a database and run that recursively until we reach a new stable state and say, given this novelty here, here's what we must persist, and we write that down.

Um, now these rules query against what we consider currently active work. So we need to look at what is currently transient in state.

So we don't want to be considering, you know, finished executions from days or weeks ago.

We just want to be looking at the current state of now. And the way we do that is we actually aggressively retract inactive entities for performance.

So our uh asserted true database is basically what is currently running and what is retracted is sort of done in the past per se.

So most API queries to look at history are actually looking at a history data database in Datomic. Um, an example of one of these rules might be, find all newly failed jobs and cancel their dependents.

Um, now needless to say, the system has evolved a bit in the last 10 years.

Um, that architecture worked well, right, to understand how to model the domain, um, you know, and to serve that one team, but now it's used by dozens of teams training thousands of models.

Uh, and Netflix as a business has changed a lot in the last 10 years and so we've needed to evolve the application to keep up with these sort of evolving needs.

Um, and you know, as with most monoliths, we had a lot of new heterogeneous processes, right, all contending for resources in a single VM.

Um, several of these benefited from horizontal scaling, um, and so we knew we needed to start splitting the system into smaller deployable units to sort of, you know, access more compute and to also improve sort of overall efficiency of the system.

Um, but we still wanted to share the same codebase and component system.

I think Netflix is known for going microservices, but we were a small team. We didn't need to go full-on to have totally independent teams of microservices.

We wanted one shared codebase, and we just needed to be able to deploy the app in different what we called stacks.

So the first piece we wanted to tackle was the easiest, right? We needed to sort of build our muscle in understanding how to sort of split things out, um, in this deployment architecture with Datomic.

Um, and so we didn't want to have to solve additional sort of distributed systems problems.

We just wanted to understand the mechanics of doing the separation and understand whether our understanding of the performance we would get was actually true.

Um, so the first one we tackled was a component called the reporter. Um, its job is basically to run long historical queries to emit information to a time series database central to Netflix.

We use it for like dashboarding and alerting. Um, and it was basically running these sort of standard queries on a regular period.

But these queries were creating increasing CPU pressure as the usage was going up. Uh, it was also reducing cache coherence, right?

So you have these rules running against things that have happened seconds or hours ago competing with cache space from things that are looking from a week ago.

And so, uh, it was a relatively simple split, right? We deployed it in a similar HA way.

Um, and it basically had no need to talk back to the direct application, right? So it was a fairly straightforward split uh, and it could function as a standalone peer, uh, and and query Datomic directly.

Um, but we needed to make sure that read load was decoupled from write load.

This was the fundamental assumption we wanted to verify. Right? With most databases you need to spin up like read replicas, otherwise you're still competing with resources on your kind of primary write master.

Um, but because these queries are so regular and the peer has a built-in object cache, the cache miss rate on this is 0.0013%.

So virtually no queries are actually touching head-on storage, right?

So this effectively functions as a total island and that we can scale totally independently from the rest of our application.

We just don't have to think about it, right? Which is fantastic, right? It was a very straightforward approach, and we got exactly the result we had hoped for.

Um, so that gave us confidence to sort of move on to the next portion that we wanted to actually horizontally scale, and the obvious thing there is like all your read APIs, right?

These are all stateless queries. They don't update any state.

We can serve those and scale as needed, right? So the API component as it were. Um, but you know, it wasn't as regular.

It wasn't homogeneous queries. There's lots of heterogeneous things. Users want to see their graphs that are currently running.

They want to run timeline queries to understand the state of things from weeks or months ago. Uh, and so it wasn't obvious that necessarily we'd get the same sort of uh performance trade-off that we would with splitting out the reporter.

Um, but it was still had these same problems, right?

We were getting CPU pressure and memory cache coherence problems for the exact same reasons. Um, so here, right, we had to spin up a horizontally scalable pool of API instances, but now we had to mediate our read and write traffic, right?

So we would still forward writes to our main application and then just handle the reads directly from within the API instances.

And so in this case, right, we still need to verify, okay, is our read still truly decoupled from our write load because these queries look very different than a very standard, fixed query running on a cadence.

And even in this scenario with different queries from all the different customers spread across all these instances, the cache miss rate is still 0.02%, right?

And so again, we're in a scenario where we can scale this horizontally and we effectively see no—we can totally isolate or buffer the load that would otherwise hit the shared resource, almost like in the power strip, um, that's shared with the critical write path.

But we had a new problem to solve, which is now read-after-write consistency, right?

Because reads are now happening on separate instances from where writes are happening. And our clients, we don't want to expose this internal detail and say, hey, you write this thing and you might not see the result right there's a slight lag between a write goes through and every peer sees it.

But Datomic has two lovely primitives to address this problem. The first is the basis T value you get from transacting.

something it's just a simple number, so it's easy to pass around in an HTTP header or in the response body. Uh, and then you can call `desync`, right?

You pass this T value in on any peer you want, and you are guaranteed to get a database at least up to date with that value.

So we can just synchronize the API instance that forwarded it. It can run all its resolvers against the state of the world that's guaranteed to have seen that write.

And we can forward the basis down to the client. So all subsequent reads to different peers will still see the result of that write.

Uh, and doing this is basically just a plumbing job, right? It's not like a hard distributed system.

We just have to pass the information around and it just works. Um, so the next scaling challenge was a little bit more interesting and this had to do, I had mentioned that we have to aggressively retract things that are no longer active and we had to do this in a sort of an atomic way.

As soon as a graph is inactive, we would atomically retract the whole piece. Um, now these transactions were occasionally getting kind of large.

Um, and some detail on this, our graphs are actually modeled as nested component entities. So you'd have like a root, it would have component entity relationships with its dependencies and that would sort of occur recursively.

Uh, and this was convenient because you could simply retract the root and the whole sort of connected graph would get retracted with it.

Um, but we were seeing that retracting these single graphs in one shot was starting to occupy a transactor for multiple seconds.

Um, and the reason is these graphs were getting a little bit big.

Um, so this here is a representation of the DAG necessary to compute one uh one retraining of a messaging model. This is a model that predicts um uh the best sort of message content, whether or not to send it on your your iOS device or as an email or something like this.

Um, except this isn't the whole thing. Um, I had to sort of do some collapsing to fit it on the slide.

It actually looks something like this. And we were trying to retract multiple of these in a single transaction because a shared upstream failure might affect multiple of these in one shot and we were trying to retract it all at once.

Needless to say, this is not a great thing on any OLAP database to transact something that large, but we were doing it.

Um, and we needed to fix it because those long long latencies were not great, right?

We needed to sort of address that. Um, so we did as we did before.

Um, we split up this archiver onto its own stack so we could isolate the sort of resources it needed. Um, but we also needed to move to tombstones, right?

Instead of retracting directly. Um, because when you retract in Datomic, you're actually retracting all of its attributes sort of separately, right?

Um, and so instead of retracting the entity, we just mark a tombstone boolean.

Um, but the beauty of Datomic is schema is very flexible. So it's very easy to just add this new attribute and all the different entities in which we need to do this.

We can just tack it on. Oh, and we can index it too.

Um, but now we need to sort of exclude these tombstones. Whereas before these entities were sort of um, excluded because they were no longer true.

Um, they were true but had this separate bit that we needed to sort of exclude.

A Decade on Datomic - Davis Shepherd & Jonathan Indig (Netflix)

Clojure (https://clojure.org) is a robust, practical, and fast programming language with a set of useful features that together form a simple, coherent, and powerful tool.

ClojureTV brings together talks and presentations from the community, major Clojure conferences, and Cognitect (https://cognitect.com).  Here you can find Clojure/conj, Clojure/west and EuroClojure talks, as well as custom video tutorials and presentations from Rich Hickey and the Cognitect team.

ClojureTV

Netflix의 Dagobah 시스템은 10년 동안 Datomic과 Clojure를 사용하여 ML 훈련 파이프라인을 구축했으며, Datomic의 유연한 스키마, 트랜잭션 보고 대기열, def-filter와 같은 기능을 활용하여 지속적으로 확장하고 진화했습니다.

Datomic과 Clojure 스택의 높은 안정성 덕분에 Dagobah 시스템은 지난 10년간 Python, Scala, Spark 등 주변 생태계의 잦은 변경 및 대규모 마이그레이션에도 불구하고 코어 코드 변경 없이 원활하게 업그레이드할 수 있었습니다.

Dagobah는 PII 데이터 처리와 같은 새로운 비즈니스 요구사항에 대응하기 위해 신뢰할 수 없는 사용자 코드 평가 구성 요소를 고권한 모니터 구성 요소와 분리해야 했으며, 이때 Datomic의 트랜잭션 T 값과 TX 보고 대기열을 활용하여 복잡한 분산 시스템 문제인 읽기-쓰기 일관성과 상태 동기화를 효율적으로 해결했습니다.

Datomic과 Clojure: Netflix에서의 10년

Netflix의 소프트웨어 엔지니어인 데이비드 셰퍼드와 조나단 인디그는 Clojure와 Datomic으로 구축된 시스템, 특히 Datomic이 **지난 10년간 프로젝트 성공에 어떻게 기여했는지**에 대한 통찰력을 공유했습니다. 이 시스템은 데이터 파이프라인 구축을 위한 것이며, 특히 데이터 과학자와 연구자들이 ML 훈련 파이프라인을 정의하는 데 사용됩니다.

이 시스템은 연구원들에게 간단한 Python API를 제공하여 순수한 Python 함수를 정의하고 구성할 수 있도록 하며, 이는 Clojure 표현식으로 변환됩니다. **Dagobah의 핵심 특징은 데이터 출처를 추적하는 강력한 모델**로, 코드와 데이터를 단계별로 추적하고 Clojure의 영구 데이터 구조처럼 구조적 공유를 가능하게 합니다.

이러한 접근 방식은 Netflix 연구원들의 생산성을 크게 향상시킵니다. 같은 파이프라인에서 작업하는 연구원들은 공통 구성 요소를 자동으로 공유하여 수백 테라바이트의 데이터를 처리하는 **시간과 비용을 절감**합니다. 이 시스템은 현재 Netflix의 모든 개인화 ML 데이터 준비 및 모델 학습을 오케스트레이션합니다.

이 시스템은 전담 Datomic 또는 Clojure 지원 팀 없이 운영되지만, Netflix는 엔터프라이즈 Datomic 지원 계약을 체결하여 **핵심 인프라의 안정성을 확보**하고 있습니다. 초기 Dagobah는 단일 ML 팀을 지원하는 간단한 모놀리식 아키텍처로, Zookeeper로 리더십을 관리하고 Cassandra 클러스터에서 Datomic을 배포했습니다.

이 시스템의 상태 머신은 Datomic 쿼리를 중심으로 순방향 추론 규칙 엔진으로 작성되었으며, **현재 활성 상태의 작업만 고려하고 비활성 엔터티는 성능을 위해 적극적으로 회수**합니다. 이 모델은 과거 데이터를 Datomic의 기록 데이터베이스에서 조회할 수 있도록 합니다.

모놀리스에서 분산 아키텍처로의 진화

지난 10년 동안 시스템은 크게 진화했습니다. 초기 아키텍처는 단일 ML 팀에는 적합했지만, 이제는 수십 개의 팀이 수천 개의 모델을 훈련하는 데 사용됩니다. Netflix 비즈니스 환경의 변화에 발맞춰, **애플리케이션은 진화하는 요구 사항을 충족하기 위해 발전해야 했습니다.**

모놀리식 구조의 단일 VM에서 리소스 경쟁이 심화되면서, 시스템을 더 작은 배포 가능한 단위로 분할하여 **수평적 확장을 통해 전반적인 효율성을 개선**할 필요가 있었습니다. Netflix는 마이크로서비스로 유명하지만, 팀은 여전히 공유 코드베이스와 컴포넌트 시스템을 원했습니다.

첫 번째 분할 대상은 '리포터' 컴포넌트였습니다. 이 컴포넌트는 Netflix의 핵심 시계열 데이터베이스에 정보를 내보내기 위해 긴 과거 쿼리를 실행합니다. 이러한 쿼리는 CPU 압력을 증가시키고 캐시 일관성을 감소시켰습니다. 리포터를 독립적으로 배포하여 **읽기 부하를 쓰기 부하와 분리**하는 데 성공했습니다.

리포터 분할은 **매우 낮은 캐시 미스율(0.0013%)을 달성하여** 효과적으로 저장소를 건드리지 않고도 애플리케이션의 나머지 부분과 완전히 독립적으로 확장될 수 있었습니다. 이 성공은 다음 단계인 읽기 API 분할에 대한 자신감을 주었습니다.

모든 읽기 API는 상태 비저장 쿼리로, 필요에 따라 서비스되고 확장될 수 있는 'API 컴포넌트'로 분리되었습니다. 하지만 이들은 리포터처럼 동질적이지 않고 이질적인 쿼리가 많아 성능 트레이드오프가 불분명했습니다. 그럼에도 불구하고, **CPU 압박과 메모리 캐시 일관성 문제가 여전히 발생**했습니다.

이를 해결하기 위해 수평적으로 확장 가능한 API 인스턴스 풀을 가동했습니다. 쓰기 작업은 기본 애플리케이션으로 전달하고 읽기 작업은 API 인스턴스 내에서 직접 처리했습니다. 이러한 시나리오에서도 **캐시 미스율은 여전히 0.02%에 불과하여** 읽기 및 쓰기 트래픽을 효율적으로 조정할 수 있었습니다.

그러나 이 분리된 아키텍처는 **'읽기 후 쓰기 일관성'이라는 새로운 문제**를 야기했습니다. Datomic은 이 문제 해결을 위해 두 가지 강력한 기본 기능을 제공합니다. 첫째, 트랜잭션에서 얻는 기준 T 값을 HTTP 헤더나 응답 본문에 전달할 수 있습니다. 둘째, 'desync' 기능을 사용하여 원하는 T 값까지 최신 상태인 데이터베이스를 얻을 수 있습니다.

이러한 기능을 통해 클라이언트는 쓰기가 완료된 후에도 **항상 최신 상태의 데이터를 조회할 수 있도록 보장**할 수 있습니다. 이는 복잡한 분산 시스템 작업이 아니라 정보를 전달하는 기본적인 배관 작업에 해당합니다.

대규모 트랜잭션 및 데이터 회수 문제 해결

다음 확장 문제는 더 이상 활성화되지 않은 항목을 **원자적으로 회수해야 하는 필요성**과 관련이 있었습니다. 그래프가 비활성화되는 즉시 전체 조각을 원자적으로 회수했는데, 이러한 트랜잭션의 크기가 때때로 너무 커져 트랜잭션 처리기가 몇 초 동안 점유되는 문제가 발생했습니다.

이는 그래프가 중첩된 컴포넌트 엔터티로 모델링되어 루트를 회수하면 연결된 전체 그래프가 함께 회수되는 편리함 때문이었습니다. 하지만 메시징 모델 재학습 DAG와 같이 **매우 큰 그래프를 한 번에 트랜잭션하는 것은 OLAP 데이터베이스에 부담**이 되었습니다.

이 문제를 해결하기 위해 '아카이버'를 자체 스택으로 분리하여 필요한 리소스를 격리했습니다. 또한, 직접 철회하는 대신 **'묘비(tombstone)' 부울을 표시**하도록 전환했습니다. Datomic의 유연한 스키마 덕분에 이 새로운 속성을 쉽게 추가하고 인덱싱할 수 있었습니다.

이제 시스템은 묘비가 표시된 엔터티를 제외해야 했습니다. Datomic은 이를 위해 **`def filter`라는 강력한 도구를 제공**하여 모든 묘비 엔터티를 쿼리하고 간단히 필터링할 수 있었습니다. 이 쿼리는 인덱스 속성을 사용하는 간단한 비트 조회이므로 매우 효율적이었습니다.

더 나아가, 비동기적으로 철회하되 더 작은 덩어리로 나누기 위해, 그래프를 가져와서 위상 정렬하고 잎에서 뿌리 순으로 철회하는 방법을 구현했습니다. Datomic의 엔터티 API와 일반 Clojure 코드를 사용하여 **50만 개의 노드를 가진 그래프도 1초 안에 위상 정렬**할 수 있었으며, 이는 수동 최적화 없이도 뛰어난 성능을 보였습니다.

Netflix 광고 사업 진출과 보안 강화

가장 최근의 진화는 Netflix가 광고 사업에 진출하면서 PII 데이터를 처리해야 했고, 이로 인해 **보안에 대한 요구 사항이 높아진 것**과 관련이 있습니다. '모니터'라는 컴포넌트는 작업 시작, 이메일 전송, 취소, 알림 전송 등 모든 부수 효과를 처리하는 부분입니다.

모니터는 Netflix 생태계에서 광범위한 권한을 가지고 있었고, 다른 시스템을 대신하여 많은 작업을 수행해야 했습니다. 동시에, 이 시스템은 사용자 코드를 평가하는데, 보안 연구원들에게는 신뢰할 수 없는 코드입니다. 따라서 **신뢰할 수 없는 사용자 코드 평가를 높은 액세스 권한이 필요한 컴포넌트로부터 격리**해야 했습니다.

이것은 양방향 통신이 필요한 첫 번째 사례였기 때문에 가장 복잡한 분리였습니다. 모니터는 업데이트를 위해 풀 작업을 해야 하지만, 이 업데이트는 상태 변경을 알리거나 취소 작업을 실행하기 위해 기본 애플리케이션 스택으로 다시 흘러 들어가야 했습니다. 또한, **모니터의 초기 상태 동기화 문제가 발생**했습니다.

Datomic의 `desync` 기능을 활용하여 모니터가 AWS API와 동기화하고, 대기열이 비워지기를 기다린 다음 동기화를 호출하여 **모든 미결 이벤트가 처리된 최신 상태로 깨끗하게 시작**할 수 있도록 했습니다. 또한, `TX 보고서 대기열`을 활용하여 시스템을 통해 흐르는 모든 트랜잭션의 스트림을 얻어 내부 상태 업데이트 로직을 유지할 수 있었습니다.

Clojure 생태계의 안정성 및 기여

데이비드 셰퍼드는 기존 아키텍처가 **강력한 컴포넌트 및 프로토콜 경계, 그리고 상태 변경에 대한 순수 함수적 접근 방식**으로 구축되어 있었기에 이러한 분리가 용이했다고 강조했습니다. Datomic은 데이터베이스를 값으로 취급할 수 있게 하여 다음 상태를 계산하는 것이 강력하게 테스트 가능한 순수 함수가 되도록 했습니다.

Core.async도 큰 역할을 했습니다. 많은 컴포넌트가 core.async를 통해 통신했기 때문에 그 사이에 SQS 대기열을 넣어도 인식하지 못했습니다. Datomic과 Clojure의 도구들은 **분산 시스템의 핵심 문제를 해결하는 데 필요한 모든 기본 요소**를 제공하여 재발명 없이 효율적으로 문제를 해결할 수 있었습니다.

현재 이 시스템은 **매일 약 10만 건의 실행**을 처리하며, 이는 시간당 또는 매일 재학습되는 수천 개의 모델을 지원합니다. 애플리케이션 자체는 5개의 스택에 걸쳐 약 40개의 피어로 구성되어 있으며, 데이터베이스는 약 20테라바이트에 150억 개의 데이터톰을 가지고 있습니다.

조나단 인디그는 Clojure 생태계가 **유난히 안정적**이며, 이는 Clojure 및 Datomic 팀과 커뮤니티의 노력 덕분이라고 강조했습니다. 그는 다른 생태계에서 소프트웨어 오류가 조직에 얼마나 큰 혼란을 초래했는지 실제 사례와 비교하며 이 안정성의 중요성을 설명했습니다.

지난 10년간 Dagobah 주변의 생태계, 즉 데이터 엔지니어링 및 ML 코드, 내부 런타임, 엔터프라이즈 도구는 **상당히 많이 변화했습니다.** Hive에서 Iceberg로, Pig 등에서 Spark로, Mesos에서 YARN으로, Scala Spark에서 PySpark로, Gradle에서 Bazel로의 전환 등 다양한 기술 변화와 버전 업그레이드가 있었습니다.

이러한 변화는 **대부분 마이그레이션을 포함했으며, 플랫폼 팀으로서 막대한 시간과 노력을 필요로** 했습니다. 예를 들어, Hive에서 Iceberg로의 마이그레이션은 2년 반, Python 2에서 3으로의 마이그레이션은 1년 반, Spark 1에서 2, 2에서 3으로의 마이그레이션은 각각 약 1년이 걸렸습니다.

반면, Clojure는 지난 10년간 7번의 버전 업그레이드가 있었지만, **소스 코드를 변경할 필요가 없었습니다.** 모든 업데이트는 빌드 파일에서 버전 문자열을 올리고 CI를 실행하는 것만큼 간단했습니다. Datomic도 유사하게 안정적인 업그레이드를 경험했습니다.

몇몇 예외는 있었지만, 대부분은 쉽게 해결되거나 우회할 수 있었습니다. 이러한 **Clojure와 Datomic 코어의 놀라운 안정성**은 Netflix 팀이 비즈니스에 중요한 문제 해결에 집중할 수 있도록 해주었습니다.

데이비드와 조나단은 Dagobah 프로젝트의 성공에 기여한 수많은 엔지니어들과 Clojure 오픈 소스 커뮤니티에 감사를 표했습니다. **Component, Lacinia, Conformity, Claypoole, SEI, Schema, Rolling Stones, Ring, CL 등** 세계 최고 수준의 안정적인 도구들이 문제 해결을 가능하게 했습니다.

또한, 비동기 프로파일, Criterium은 애플리케이션 속도 개선에, Hiccup과 FIP는 데이터 표현에, **Nippy는 놀라운 직렬화 라이브러리로 해싱에 광범위하게 사용**되었습니다. Clojure for the Brave and True는 새로운 사람들을 온보딩하는 데 중요한 리소스 역할을 했습니다.

발표자들은 이 프로젝트를 통해 받은 가장 좋아하는 칭찬을 공유하며, 그것이 전체 커뮤니티에 빚지고 있다고 생각했습니다. 그 칭찬은 바로 **"멋진 일자리가 많지만 저는 제 일이 정말 좋습니다."**라는 것이었습니다.

그들이 멋진 문제들을 해결할 수 있는 이유는 **방해받지 않는 도구를 사용할 수 있기 때문**입니다. 이 도구들은 예측 가능한 속성을 가지고 있고, 훌륭한 의미를 지니며, 고장 나지 않습니다. 이를 통해 팀은 비즈니스에 중요하고 매혹적인 문제 해결에 집중할 수 있습니다.

마지막으로, 그들은 전체 커뮤니티, Datomic 팀, 그리고 Rich에게 **Netflix에서 가장 멋진 직업을 가질 수 있도록 해주어서 감사하다**는 말을 전했습니다.

Netflix의 'Dagobah' 시스템은 Datomic을 어떻게 활용하여 데이터 파이프라인의 데이터 출처를 추적하고 구조적 공유를 구현하나요?

Datomic의 `desync` 및 TX 보고서 대기열 기능은 Netflix가 'Dagobah' 시스템을 마이크로서비스 아키텍처로 확장하면서 발생한 읽기-쓰기 일관성 및 변경 알림 문제를 어떻게 해결하는 데 기여했나요?

Netflix의 'Dagobah' 시스템이 지난 10년간 Clojure 및 Datomic 스택의 안정성을 유지하면서도, 다른 데이터 엔지니어링 및 ML 생태계 기술 스택에서 겪었던 잦은 마이그레이션 및 버전 업그레이드 문제와 어떤 차이가 있었나요?

'Dagobah' 시스템에서 더 이상 활성화되지 않은 그래프를 회수하는 과정에서 발생한 대규모 트랜잭션 지연 문제를 Datomic의 유연한 스키마, `def filter` 기능 및 엔터티 API를 통한 위상 정렬이 어떻게 효율적으로 해결했는지 설명해주세요.

발표자들이 Clojure 커뮤니티와 Datomic 팀에 감사를 표하며 언급한 '방해받지 않는 도구'가 무엇을 의미하며, 이것이 Netflix 엔지니어들이 '멋진 문제'를 해결하는 데 어떻게 도움이 되었나요?

제 이름은 데이비드 셰퍼드입니다. 이쪽은 조나단 인디그입니다. 저희는 넷플릭스에서 소프트웨어 엔지니어로 일하고 있으며, 오늘은 클로저와 데이토믹으로 구축된 시스템에 대해 이야기하려고 합니다.

특히 이 시스템이 데이토믹을 어떻게 활용하고 지난 10년 동안 프로젝트의 성공을 어떻게 이끌었는지에 대한 통찰력을 얻으실 수 있기를 바랍니다.

그래서 이 시스템이 무엇인지, 우리가 무엇을 구축했는지, 지난 10년 동안 어떻게 발전해 왔는지에 대해 간략하게 이야기하고, 조나단이 조직으로서 안정성이 우리에게 얼마나 중요한지, 그리고 불안정성이 우리에게 어떤 영향을 미치는지 대조적으로 설명할 것입니다.

그래서, 우리는 무엇을 만들까요? 음, 사실 이 시스템을 처음 소개하는 것은 아닙니다.

저희의 소중한 친구이자 동료인 맷 보스턴브룩이 거의 10년 전 Conj에서 이 시스템을 소개하는 강연을 했습니다.

해내거나, 해내지 않거나, 시도란 없다. 이것은 데이터 파이프라인 구축을 위한 시스템이었습니다.

이 강연을 아직 보지 못하셨다면 꼭 시청하시기를 추천합니다. 데이터 파이프라인에 대한 우리의 생각, 모델링 방식에 대한 많은 핵심 아이디어가 오늘날에도 여전히 살아 있습니다.

지난 10년 동안 많은 발전이 있었지만, 여전히 핵심 아이디어는 오늘날에도 유효합니다.

그래서, 그것은 무엇일까요? 음, 데이터 파이프라인 구축을 위한 것입니다.

특히 데이터 과학자와 연구자들이 데이터, 특히 ML 훈련 파이프라인을 정의하기 위한 것입니다.

그래서 우리는 그들에게 간단한 Python API를 제공합니다. 악플은 삼가 주세요. 그들이 있는 곳에서 만나야 합니다.

기본적으로 그들이 순수한 Python 함수를 정의할 수 있도록 합니다. 그들은 그것들을 데코레이트하고, 이 함수들을 함께 구성합니다.

그리고 우리는 기본적으로 오른쪽의 호출 그래프를 가져와서 EDN으로 변환합니다. 우리는 날짜 계산을 SCI에서 평가할 수 있는 Clojure 표현식으로 바꾸고, 그 결과 페이로드는 기본적으로 기본 DAG를 계산하는 데 사용하는 것입니다.

그래서 우리는 그 예제를 가져와서 실행할 수 있습니다, 그렇죠?

이것들은 분산된 방식으로 별도의 인스턴스에서 실행됩니다. 음, 그것은 다 좋습니다. 많은 오케스트레이션 시스템이 이 작업을 수행할 수 있습니다.

특별히 흥미로운 건 아니지만, Dagobah의 특징은 데이터 출처를 추적하는 매우 강력한 모델이 있다는 겁니다.

그래서 우리는 이러한 각 단계를 거치는 코드와 데이터를 알고 있습니다.

그래서 Clojure가 영구 데이터 구조로 하는 것처럼 구조적 공유를 할 수 있습니다.

데이터 파이프라인에서도 그렇게 합니다. 위의 예에서 파이프라인에 구조적 변경을 가하여 재귀하려는 깊이를 편집할 수 있습니다.

그리고 실제로 완전히 재사용하고 건너뛰고 메모할 수 있는 파이프라인 부분을 파악하고, 이 연구원이 원하는 새로운 결과를 구체화하는 데 필요한 델타만 계산하면 됩니다.

말할 필요도 없이, 이는 Netflix 연구원들의 생산성을 크게 향상시킵니다.

같은 파이프라인에서 작업하는 두 명의 연구원은 공통 구성 요소를 자동으로 공유합니다.

처음부터 다시 시작하지 않습니다. 아시다시피, 이러한 작업은 Python에서 간단한 수학을 수행하는 사소한 작업이 아닙니다.

이러한 작업은 수백 테라바이트의 데이터를 처리하고 실행하는 데 몇 시간 또는 며칠이 걸리는 Spark 작업과 같습니다. 따라서 이러한 작업을 수행하지 않아도 된다는 것은 시간뿐만 아니라 Netflix의 비용 절감에도 큰 이점입니다.

따라서 이 시스템은 현재 Netflix의 모든 개인화 ML 데이터 준비 및 모델 학습을 오케스트레이션하는 역할을 합니다.

우리는 전담 Datomic 또는 Clojure 지원 팀이 없습니다. 음, 기본적으로 여러분이 보고 있는 게 전부입니다.

하지만 엔터프라이즈 Datomic 지원 계약에 대한 비용을 지불합니다. 이는 Netflix의 매우 중요한 인프라이며 우리는 혼자서는 진행하고 싶지 않습니다.

우리는 가능한 모든 리소스를 활용하고 있으며, 훌륭한 파트너들이 우리를 돕고 있습니다.

초기에 Dagob는 단일 ML 팀을 지원하기 위해 구축되었습니다. 초기에는 아키텍처가 매우 간단했습니다.

이것은 기본적으로 Zookeeper를 사용하여 리더십 상태를 관리하는 HA 방식으로 모놀리스로 배포되었습니다. 음, 이 하나의 배포는 API 요청 처리, 기본 컴퓨팅 시스템에서 작업 시작, 상태 업데이트, 지속 등 애플리케이션의 모든 측면을 관리합니다. 그리고 저희는 Cassandra 클러스터에서 지원하는 온프레미스에 Datomic을 배포했고, 일종의 공유 Memcached 배포도 했습니다.

그리고 S3에 백업을 실행합니다.

음, 저희가 유지 관리하는 상태 머신에는 몇 가지 흥미로운 속성이 있습니다. 음, 실제로는 Clara 규칙과 크게 다르지 않은 순방향 추론 규칙 엔진으로 작성되었습니다.

음, 저희 규칙은 기본적으로 트랜잭션 데이터를 생성하는 순수 함수에 대한 Datomic 쿼리를 중심으로 구성됩니다.

저희는 해당 규칙을 결과와 함께 데이터베이스에서 실행하고 새로운 안정 상태에 도달할 때까지 재귀적으로 실행합니다. 그리고 여기에 새로운 기능이 있으므로 유지해야 할 사항을 기록합니다.

음, 이러한 규칙은 현재 활성 상태로 간주되는 작업에 대해 쿼리합니다. 따라서 현재 상태에서 과도한 부분을 살펴봐야 합니다.

따라서 며칠 또는 몇 주 전의 완료된 실행은 고려하고 싶지 않습니다.

저희는 현재 상태만 보고 싶습니다. 그리고 저희가 그렇게 하는 방법은 성능을 위해 비활성 엔터티를 적극적으로 회수하는 것입니다.

따라서 저희의 어설션된 true 데이터베이스는 기본적으로 현재 실행 중인 항목이고 회수된 항목은 과거에 완료된 항목입니다.

따라서 기록을 보기 위한 대부분의 API 쿼리는 실제로 Datomic의 기록 데이터베이스를 보고 있습니다. 음, 이러한 규칙의 한 예는 새로 실패한 모든 작업을 찾고 종속성을 취소하는 것일 수 있습니다.

음, 말할 필요도 없이 시스템은 지난 10년 동안 약간 진화했습니다.

음, 해당 아키텍처는 도메인을 모델링하는 방법을 이해하고 해당 팀에 서비스를 제공하는 데 적합했지만 지금은 수천 개의 모델을 교육하는 수십 개의 팀에서 사용하고 있습니다.

어, 그리고 Netflix는 지난 10년 동안 비즈니스로서 많은 변화를 겪었고 이러한 진화하는 요구 사항을 따라잡기 위해 애플리케이션을 발전시켜야 했습니다.

음, 아시다시피 대부분의 모놀리스와 마찬가지로 단일 VM에서 리소스를 놓고 경쟁하는 많은 새로운 이기종 프로세스가 있었습니다.

어, 이 중 몇 가지는 수평적 확장의 이점을 얻었고, 그래서 우리는 시스템을 더 작은 배포 가능한 단위로 분할하여 더 많은 컴퓨팅에 액세스하고 시스템의 전반적인 효율성을 개선해야 한다는 것을 알았습니다.

하지만 우리는 여전히 동일한 코드베이스와 컴포넌트 시스템을 공유하고 싶었습니다.

Netflix는 마이크로서비스로 유명하지만, 우리는 작은 팀이었습니다. 완전히 독립적인 마이크로서비스 팀을 가질 필요는 없었습니다.

우리는 하나의 공유 코드베이스를 원했고, 앱을 스택이라고 부르는 다른 곳에 배포할 수 있어야 했습니다.

그래서 우리가 먼저 해결하고 싶었던 것은 가장 쉬운 것이었습니다. Datomic을 사용하여 이러한 배포 아키텍처에서 무언가를 분할하는 방법을 이해하는 근육을 키워야 했습니다.

그래서 추가적인 분산 시스템 문제를 해결하고 싶지 않았습니다.

우리는 분리 메커니즘을 이해하고 우리가 얻을 성능에 대한 이해가 실제로 사실인지 확인하고 싶었습니다.

그래서 우리가 먼저 다룬 것은 리포터라는 컴포넌트였습니다. 이 컴포넌트의 역할은 기본적으로 Netflix의 핵심인 시계열 데이터베이스에 정보를 내보내기 위해 긴 과거 쿼리를 실행하는 것입니다.

A Decade on Datomic - Davis Shepherd & Jonathan Indig (Netflix)

스크립트