Hi everyone, I'm Fabian, and I'm a member of the technical staff at OpenAI on their applied observability team. I'm super excited to be here and share with you how we're using open-source technology to process logs at scale and some of the interesting things that we've found.

So, it's only been three years since the original ChatGPT release, and I think it's fair to say that AI has already completely changed the way that we work and the way that we access information.

With GPT-5, the model is not just generating text. It's seeing and creating images, writing and running code, and orchestrating increasingly complex tool chains.

And each step up in capability doesn't just mean more compute. It means more Kubernetes clusters, more user traffic, and orders of magnitude more telemetry to keep it all running and ensure that we're successful in our mission to make AGI beneficial to all of humanity.

Our role on applied observability is to make sure that every engineer at OpenAI has the tools that they need to prevent SEs hopefully before they happen, but also to effectively fight them when they do.

And that means ingesting absolutely massive amounts of telemetry and making it fast, queriable, and actionable at scale.

So to set the scene for you, I'm first going to share with you the high-level architecture of what our logging solution looks like.

Then I'll share the unique challenges that we're trying to meet and how those business problems force us to look for performance wins.

And lastly, I'll share the Eureka moment that saved us a ton of compute and what I think is the most important thing to take away from this experience.

So the ingestion pipeline starts with Fluent Bit.

We run Fluent Bit on every Kubernetes node in our fleet, and it's responsible for ingesting log files, performing any sampling, enriching those logs with metadata that comes from Kubernetes, formatting them into the right schema, and then routing them to the appropriate data stores that those logs can be queried.

In the aggregate, we emit just shy of 10 petabytes of logs per day using this architecture.

And since Fluent Bit runs on every node, its performance is critical. A Fluent Bit process that exceeds its CPU quota and gets throttled could end up losing logs or worse, it could degrade the performance of a different application.

So, we'd prefer it to just use as little CPU as possible to get the job done.

So, if you follow the news, I'm sure you've heard about our absolutely insatiable appetite for GPUs.

But what gets talked about less is that we also need a lot of CPUs, too. We know we need more capacity to meet our ambitious goals, but not all the capacity that we ask for can ever be acquired.

So, this necessitates us to optimize our compute as well as horizontally scale it. So if we can return a CPU to every node, then maybe that's one more microservice that we can fit into a given host.

So we call this the DaemonSet problem, and it makes it super hard for us to justify creating a new one because then any resources that it requires slightly reduces the resources that every node in our fleet contributes back to the cluster.

Um, ideally we'd have just far fewer DaemonSets in our environment and the ones that we do have would use far fewer resources.

So through this lens, we set out to optimize Fluent Bit and make it just as lean as possible.

And luckily, there's pretty great tooling these days for figuring out where CPU cycles are going. Um, Perf is Perf is a powerful tool for doing these kinds of investigations, and it works with any language, and I like to start these investigations with a hypothesis.

So my hypothesis going in was that Fluent Bit would probably be spending most of its time doing expensive string processing because we do all that enrichment, filtering, uh, log processing inside of Lua, and maybe that would cause a bunch of load as Fluent Bit had to do all those computations, memory allocations, that kind of thing.

But let's let's see what the report says.

This is the output of the Perf report command, and my theory was totally wrong. If you look at the symbol that's highlighted, consuming about 35% of this thread's time, it's called `fstat64`, which is used to return information about a file's various properties, such as including size.

And this is a super surprising result that really didn't match my expectations going in. In essence, this is saying that the biggest use of Fluent Bit's CPU time is spent figuring out how large log files are before reading them.

So there's two places that use `fstat` in the tail plugin. The first is in the periodic refresh interval, which we've configured to run a stat on every file every 5 seconds.

And that's frequent, but if we only have a few dozen pods per node, it's just it's never going to be high enough in frequency to justify that 35% of CPU time.

Um, so something else has to be driving it. And the second place that stats will happen is via inotify.

Uh, it's enabled by default and it reduces Fluent Bit's need to do that periodic uh, stat-based polling since the kernel will just let us know when a file has been written to.

And so this PR, it's a one-liner. We just we turn inotify off and let's see what happens.

Uh, rolled this out to a single test cluster and the results speak for themselves.

We have a new load pattern here that uses about half as much CPU while doing exactly the same work. But why why is this happening?

This is actually a really surprising result. We have to think about it from Fluent Bit's perspective. It's not just enough to know that a write has happened.

We also have to know how much data has been written. And this information is useful because we have to feed it back into our state tracking database regarding like where we are reading in the file.

So in response to the inotify event, Fluent Bit will issue that fstat call immediately that retrieves that information and then immediately read the file's content for new data.

And if a process is continually emitting new logs line by line, then Fluent Bit is going to race that and continue to run stat for every time that that write happens.

And that's going to burn a ton of unnecessary compute, as it was in our environment. So, we rolled out this change to all of production, and the results held up pretty nicely.

It actually ended up returning about 30,000 CPU cores worth of capacity back to the Kubernetes cluster.

And this is a result that's going to just continue to compound over time as we bring more compute online.

Not all these hosts are busy at the same time or have the same services deployed with the same logging characteristics. But across the board, the result is that 50% drop in CPU to our heaviest loaded Fluent Bit pods.

And at the time we rolled it out, about 30,000 CPU cores at peak.

This was one of a series of performance enhancements that we've made to try to improve our use of Fluent Bit over time.

Although this was probably the most effective in terms of lines written to payoff. We're working to propose a patch upstream so that you can specify like a minimum interval or something like that and see the same kind of results in your environments, maybe without having to disable `inotify` too.

So, as an industry, in the last decade, I think we've gotten much better at building highly scalable distributed systems, and that's definitely a good thing.

At OpenAI, we've been able to leverage that knowledge and the incredible open source ecosystem to reach a level of scale that in the past would have maybe required a decade to prepare for and had involved a lot more proprietary software.

It's a testament to the power of open source that when ChatGPT took off, we were able to meet that moment.

Open source software gives all of us the ability to focus on our core business problems and not worry so much about the other stuff.

Still, just because our community's gotten so good at scaling things horizontally doesn't mean that there's not value in breaking out your profiler of choice and seeing what's really happening under the hood and on your hardware.

Sometimes you might just find something surprising. And truthfully, doing it these days is easier than ever.

You don't need to be a C programmer to ask Chat to help you run Perf for the first time, to get the command line arguments right, or even to interpret the results.

You just need 15 minutes, root, and a little bit of patience. So my closing message is this.

If you're into this kind of thing, if you think this is cool, take a few minutes out of your day and profile some of the open source software that you use at your company under load, and let's see if we can find anything else surprising and work to make open software or open source software a little bit better for everybody.

Keynote: How One Line of Code Freed 30,000 CPU Cores: Deep-Diving Fluent Bit at Petabyte... F. Ponce

To provide educational and informative content on cloud native computing, which uses an open source software stack to deploy applications as microservices, packaging each part into its own container, and dynamically orchestrating those containers to optimize resource utilization. Educational content on CNCF projects, like Kubernetes and Prometheus, will also be provided.

CNCF [Cloud Native Computing Foundation]

OpenAI는 AGI 사명 완수를 위해 대규모 로그 처리 솔루션으로 Fluent Bit을 활용하며, 하루 10페타바이트에 가까운 로그를 처리한다.

Fluent Bit 성능 최적화 과정에서 'fstat64' 호출이 CPU 시간의 35%를 차지하는 것을 발견했고, `inotify`를 비활성화하는 단 한 줄의 코드 변경으로 30,000개의 CPU 코어 용량을 절약하고 가장 부하가 큰 Fluent Bit 파드에서 CPU 사용량을 50% 감소시켰다.

오픈소스 소프트웨어는 대규모 시스템 구축에 필수적이지만, 프로파일링을 통해 내부 동작을 분석하면 예상치 못한 최적화 기회를 발견하고 오픈소스 커뮤니티에 기여할 수 있다.

소개: OpenAI의 관측팀과 대규모 로그 처리

OpenAI의 응용 관측 팀에서 기술 스태프를 맡고 있는 파비안은 **오픈 소스 기술을 활용하여 대규모 로그를 처리하는 방법에 대한 경험을 공유**합니다. ChatGPT 출시 이후 AI는 업무 방식과 정보 접근 방식을 변화시켰으며, GPT-5와 같은 모델은 텍스트 생성뿐만 아니라 이미지 생성, 코드 작성 및 실행, 복잡한 도구 체인 오케스트레이션 등 더 많은 기능을 수행합니다. 이러한 기능 향상은 컴퓨팅 리소스, Kubernetes 클러스터, 사용자 트래픽, 그리고 AGI를 인류에게 유익하게 만들기 위한 방대한 양의 원격 측정 데이터를 필요로 합니다.

응용 관측 팀의 역할은 OpenAI의 모든 엔지니어가 **시스템 오류(SE)를 예방하고 발생 시 효과적으로 대응할 수 있도록 도구를 제공**하는 것입니다. 이를 위해 방대한 양의 원격 측정 데이터를 수집하고, 대규모로 빠르고 쿼리 가능하며 실행 가능하게 만드는 데 집중하고 있습니다. 이 발표에서는 로깅 솔루션 아키텍처, 직면한 과제, 그리고 엄청난 컴퓨팅 자원을 절약한 경험을 공유할 예정입니다.

OpenAI의 로그 수집 파이프라인은 Fluent Bit에서 시작됩니다. Fluent Bit는 모든 Kubernetes 노드에서 실행되며, **로그 파일 수집, 샘플링, Kubernetes 메타데이터로 로그 보강, 스키마 포맷팅, 그리고 적절한 데이터 저장소로 로그 라우팅**을 담당합니다. 이 아키텍처를 통해 OpenAI는 하루에 약 10페타바이트에 가까운 로그를 내보냅니다. Fluent Bit는 모든 노드에서 실행되므로 성능이 매우 중요하며, CPU 할당량을 초과하면 로그 손실이나 다른 애플리케이션의 성능 저하로 이어질 수 있습니다.

OpenAI는 GPU뿐만 아니라 **많은 CPU를 필요로 하지만, 필요한 모든 용량을 항상 확보할 수 있는 것은 아닙니다.** 따라서 컴퓨팅 리소스를 수평적으로 확장할 뿐만 아니라 최적화해야 합니다. Fluent Bit와 같은 데몬 세트는 모든 노드에서 실행되므로 리소스 사용량이 적어야 합니다. 데몬 세트가 더 적은 리소스를 사용하면, 주어진 호스트에 더 많은 마이크로서비스를 탑재할 수 있어 컴퓨팅 자원을 효율적으로 사용할 수 있습니다.

Fluent Bit를 최적화하기 위해 Perf와 같은 도구를 사용하여 CPU 주기가 어디로 가는지 분석했습니다. 초기 가설은 Fluent Bit가 비싼 문자열 처리에 많은 시간을 소비할 것이라는 것이었습니다. OpenAI는 모든 개선, 필터링, 로그 처리를 Lua 내부에서 수행하며, 이 과정에서 많은 부하가 발생할 수 있다고 생각했기 때문입니다. 하지만 Perf 보고서는 **가설이 완전히 틀렸음을 보여주었습니다.**

Perf 보고서에 따르면, Fluent Bit 스레드 시간의 약 35%가 **'fstat64'라는 시스템 호출에 소비되고 있었습니다.** fstat64는 파일의 크기 등 다양한 속성에 대한 정보를 반환하는 데 사용됩니다. 이는 Fluent Bit CPU 시간의 가장 큰 용도가 로그 파일을 읽기 전에 로그 파일의 크기를 파악하는 데 사용된다는 것을 의미하며, 예상치 못한 결과였습니다. Fluent Bit의 테일 플러그인에서 fstat은 주기적인 새로 고침 간격(5초마다)과 `inotify`를 통해 두 군데에서 사용됩니다. 주기적인 새로 고침은 빈번하지만 CPU 시간의 35%를 차지할 만큼은 아니었으므로, `inotify`가 문제의 원인일 것이라고 추정했습니다.

획기적인 코드 한 줄: 30,000 CPU 코어 절약

문제 해결을 위해 **`inotify`를 끄는 한 줄짜리 코드를 배포**했습니다. 단일 테스트 클러스터에 이 코드를 배포한 결과, 동일한 작업을 수행하면서도 CPU 사용량이 약 절반으로 줄어드는 뚜렷한 결과를 얻었습니다. `inotify`가 활성화되어 있을 때 Fluent Bit는 쓰기가 발생했음을 알게 되면 즉시 `fstat` 호출을 실행하여 파일 크기 정보를 검색하고 새 데이터를 읽습니다. 로그가 줄 단위로 계속 내보내지면 Fluent Bit는 경쟁적으로 처리하며 쓰기 발생 시마다 계속 `stat`을 실행하여 불필요한 컴퓨팅을 엄청나게 소모하게 됩니다.

이 변경 사항을 모든 프로덕션 환경에 배포한 결과, **Kubernetes 클러스터에 약 30,000개의 CPU 코어 용량을 되돌려주는 놀라운 결과**를 가져왔습니다. 이는 컴퓨팅 리소스를 더 많이 온라인으로 가져올수록 시간이 지남에 따라 계속 증가할 결과입니다. 비록 모든 호스트가 동시에 사용 중이거나 동일한 로깅 특성을 가진 것은 아니지만, 가장 많이 로드된 Fluent Bit 포드에서 CPU가 50% 감소했습니다. 이 최적화는 Fluent Bit 사용을 개선하기 위해 수행된 일련의 작업 중 가장 효과적인 개선 사항 중 하나였으며, OpenAI는 `inotify`를 비활성화하지 않고도 유사한 결과를 얻을 수 있도록 이 패치를 업스트림으로 제안하고 있습니다.

오픈 소스의 힘과 프로파일링의 중요성

지난 10년간 업계는 확장 가능한 분산 시스템 구축에 능숙해졌습니다. OpenAI는 **오픈 소스 생태계를 활용하여 과거에는 훨씬 더 많은 독점 소프트웨어와 10년이 걸렸을 규모에 도달**할 수 있었습니다. ChatGPT가 출시되었을 때 OpenAI가 그 순간을 충족할 수 있었던 것은 오픈 소스의 힘을 증명하는 것입니다. 오픈 소스 소프트웨어는 기업이 핵심 비즈니스 문제에 집중하고 다른 문제에 대해 크게 걱정하지 않을 수 있도록 해줍니다.

커뮤니티가 수평적 확장에 능숙해졌다고 해서 **프로파일러를 분석하고 하드웨어에서 실제로 무슨 일이 일어나고 있는지 확인하는 가치가 사라지는 것은 아닙니다.** 때로는 놀라운 것을 발견할 수 있으며, 요즘에는 Chat GPT에 Perf 실행이나 결과 해석을 요청하는 등 프로파일링이 그 어느 때보다 쉬워졌습니다. 발표자는 회사에서 사용하는 오픈 소스 소프트웨어를 프로파일링하여 더 많은 것을 찾아내고 모두에게 더 나은 소프트웨어를 만들 것을 권장하며 발표를 마무리합니다.

OpenAI의 응용 관측 팀은 어떤 역할을 하며, Fluent Bit을 사용하여 로그를 처리하는 방식의 주요 특징은 무엇인가요?

Fluent Bit 성능 최적화가 필요했던 주요 비즈니스 문제와 데몬 세트 문제가 Fluent Bit 최적화에 어떤 영향을 미쳤나요?

Fluent Bit에서 `fstat64` 호출이 CPU 시간의 상당 부분을 차지했던 원인은 무엇이며, 이 문제를 해결하기 위해 어떤 한 줄의 코드 변경이 이루어졌나요?

inotify 비활성화가 Fluent Bit의 CPU 사용량에 어떤 영향을 미쳤고, 이로 인해 OpenAI는 얼마나 많은 컴퓨팅 자원을 절약할 수 있었나요?

발표자가 오픈 소스 소프트웨어의 프로파일링을 통해 성능을 최적화하는 것의 중요성을 강조하는 이유는 무엇이며, 이러한 접근 방식이 커뮤니티에 어떤 이점을 제공한다고 보나요?

안녕하세요, 저는 파비안이고 OpenAI의 응용 관측 팀에서 기술 스태프를 맡고 있습니다. 이렇게 여러분과 함께 오픈 소스 기술을 사용하여 대규모로 로그를 처리하는 방법과 흥미로운 점들을 공유하게 되어 매우 기쁩니다.

ChatGPT가 처음 출시된 지 3년밖에 되지 않았지만, AI가 이미 우리가 일하는 방식과 정보에 접근하는 방식을 완전히 바꿔놓았다고 해도 과언이 아니라고 생각합니다.

GPT-5를 통해 모델은 단순히 텍스트를 생성하는 데 그치지 않고 이미지를 보고 생성하고, 코드를 작성하고 실행하며, 점점 더 복잡한 도구 체인을 오케스트레이션합니다.

그리고 각 단계별 기능 향상은 더 많은 컴퓨팅 자원만을 의미하는 것이 아닙니다. 이는 더 많은 Kubernetes 클러스터, 더 많은 사용자 트래픽, 그리고 AGI를 모든 인류에게 유익하게 만들겠다는 우리의 사명을 성공적으로 수행하기 위해 필요한 엄청난 양의 원격 측정 데이터를 의미합니다.

응용 관측 팀으로서 우리의 역할은 OpenAI의 모든 엔지니어가 SE를 예방하는 데 필요한 도구를 갖추도록 하는 것입니다. 바라건대 SE가 발생하기 전에 예방하고, 발생 시 효과적으로 대응할 수 있도록 돕는 것입니다.

이는 엄청난 양의 원격 측정 데이터를 수집하고, 대규모로 빠르고 쿼리 가능하며 실행 가능하게 만드는 것을 의미합니다.

상황을 설명하기 위해 먼저 로깅 솔루션의 대략적인 아키텍처를 공유하겠습니다.

다음으로 우리가 해결하고자 하는 고유한 과제와 이러한 비즈니스 문제가 어떻게 성능 향상을 모색하도록 강요하는지 공유하겠습니다.

마지막으로 엄청난 양의 컴퓨팅 자원을 절약해 준 유레카 순간과 이 경험에서 가장 중요한 교훈을 공유하겠습니다.

수집 파이프라인은 Fluent Bit에서 시작됩니다.

우리는 모든 Kubernetes 노드에서 Fluent Bit를 실행하며, 로그 파일 수집, 샘플링 수행, Kubernetes에서 가져온 메타데이터로 로그 보강, 올바른 스키마로 포맷, 해당 로그를 쿼리할 수 있는 적절한 데이터 저장소로 라우팅하는 역할을 담당합니다.

전체적으로 이 아키텍처를 사용하여 하루에 10페타바이트에 가까운 로그를 내보냅니다.

Fluent Bit는 모든 노드에서 실행되므로 성능이 매우 중요합니다. CPU 할당량을 초과하여 제한되는 Fluent Bit 프로세스는 로그를 잃거나 더 나쁜 경우 다른 애플리케이션의 성능을 저하시킬 수 있습니다.

따라서 작업을 완료하는 데 가능한 한 적은 CPU를 사용하는 것이 좋습니다.

그래서 뉴스를 보신다면, 저희가 GPU에 대해 엄청나게 왕성한 식욕을 가지고 있다는 것을 분명히 들어보셨을 겁니다.

하지만 간과되는 점은 저희에게도 많은 CPU가 필요하다는 것입니다. 저희는 야심찬 목표를 달성하기 위해 더 많은 용량이 필요하다는 것을 알고 있지만, 저희가 요구하는 모든 용량을 항상 확보할 수 있는 것은 아닙니다.

따라서 컴퓨팅을 수평적으로 확장할 뿐만 아니라 최적화해야 합니다. 모든 노드에 CPU를 반환할 수 있다면 주어진 호스트에 더 많은 마이크로서비스를 탑재할 수 있을 겁니다.

그래서 저희는 이것을 데몬 세트 문제라고 부르는데, 새로운 데몬 세트를 만드는 것을 정당화하기가 매우 어렵습니다. 왜냐하면 데몬 세트에 필요한 리소스는 저희 플릿의 모든 노드가 클러스터에 다시 제공하는 리소스를 약간 줄이기 때문입니다.

음, 이상적으로는 저희 환경에 데몬 세트가 훨씬 적고, 저희가 가지고 있는 데몬 세트가 훨씬 적은 리소스를 사용해야 합니다.

그래서 이러한 관점에서 Fluent Bit를 최적화하여 최대한 간결하게 만들기로 했습니다.

다행히 요즘에는 CPU 주기가 어디로 가는지 파악할 수 있는 훌륭한 도구가 있습니다. 음, Perf는 이러한 종류의 조사를 수행하는 데 유용한 도구이며 모든 언어에서 작동하며 저는 가설로 이러한 조사를 시작하는 것을 좋아합니다.

그래서 제 가설은 Fluent Bit가 아마도 대부분의 시간을 비싼 문자열 처리에 소비할 것이라는 것이었습니다. 왜냐하면 저희는 모든 개선, 필터링, 로그 처리를 Lua 내부에서 수행하고, Fluent Bit가 모든 계산, 메모리 할당 등을 수행해야 하기 때문에 많은 부하가 발생할 수 있기 때문입니다.

하지만 보고서에서 무엇이라고 하는지 봅시다.

이것은 Perf 보고서 명령의 출력이며, 제 이론은 완전히 틀렸습니다. 강조 표시된 기호를 보면 이 스레드 시간의 약 35%를 소비하고 있는데, 이것은 파일의 크기를 포함한 다양한 속성에 대한 정보를 반환하는 데 사용되는 'fstat64'라고 합니다.

그리고 이것은 제 예상과는 전혀 다른 매우 놀라운 결과입니다. 본질적으로 이것은 Fluent Bit CPU 시간의 가장 큰 용도가 로그 파일을 읽기 전에 로그 파일의 크기를 파악하는 데 사용된다는 것을 의미합니다.

테일 플러그인에서 'fstat'을 사용하는 곳은 두 군데가 있습니다. 첫 번째는 주기적인 새로 고침 간격으로, 모든 파일에 대해 5초마다 stat을 실행하도록 구성했습니다.

자주 발생하긴 하지만 노드당 포드가 몇십 개밖에 없다면 CPU 시간의 35%를 할애할 만큼 빈도가 높지 않을 겁니다.

음, 다른 원인이 있을 겁니다. 두 번째로 통계가 발생하는 곳은 inotify를 통해서입니다.

어, 기본적으로 활성화되어 있으며 커널에서 파일이 작성되었음을 알려주기 때문에 Fluent Bit이 주기적으로 통계 기반 폴링을 수행할 필요성을 줄여줍니다.

따라서 inotify와 관련이 있어야 합니다.

그래서 이 PR은 한 줄짜리 코드입니다. inotify를 끄고 무슨 일이 일어나는지 봅시다.

어, 이 코드를 단일 테스트 클러스터에 배포했는데 결과가 뚜렷하게 나타났습니다.

여기서 새로운 로드 패턴은 정확히 동일한 작업을 수행하면서 CPU를 약 절반 정도 사용합니다. 하지만 왜 이런 일이 발생하는 걸까요?

이것은 실제로 매우 놀라운 결과입니다. Fluent Bit의 관점에서 생각해 봐야 합니다. 쓰기가 발생했다는 것을 아는 것만으로는 충분하지 않습니다.

얼마나 많은 데이터가 쓰여졌는지도 알아야 합니다. 이 정보는 파일에서 어디를 읽고 있는지와 관련하여 상태 추적 데이터베이스에 다시 피드해야 하기 때문에 유용합니다.

따라서 inotify 이벤트에 대한 응답으로 Fluent Bit은 해당 정보를 검색하는 fstat 호출을 즉시 실행한 다음 새 데이터에 대한 파일 내용을 즉시 읽습니다.

프로세스가 새 로그를 줄 단위로 계속 내보내고 있다면 Fluent Bit은 이를 경쟁적으로 처리하고 쓰기가 발생할 때마다 계속 stat을 실행합니다.

그리고 그것은 우리 환경에서처럼 불필요한 컴퓨팅을 엄청나게 소모할 것입니다. 그래서 이 변경 사항을 모든 프로덕션 환경에 배포했고 결과는 꽤 좋았습니다.

실제로 Kubernetes 클러스터에 약 30,000개의 CPU 코어 용량을 되돌려주는 결과를 가져왔습니다.

그리고 이것은 더 많은 컴퓨팅을 온라인으로 가져올수록 시간이 지남에 따라 계속 증가할 결과입니다.

이러한 호스트가 모두 동시에 사용 중이거나 동일한 로깅 특성으로 배포된 동일한 서비스를 가지고 있는 것은 아닙니다. 그러나 전반적으로 가장 많이 로드된 Fluent Bit 포드에서 CPU가 50% 감소하는 결과를 얻었습니다.

그리고 배포 당시 피크 시 약 30,000개의 CPU 코어를 확보했습니다.

이것은 Fluent Bit 사용을 시간이 지남에 따라 개선하기 위해 수행한 일련의 성능 향상 중 하나였습니다.

이것이 아마도 지불할 라인 측면에서 가장 효과적이었을 것입니다. 최소 간격 등을 지정하여 사용자 환경에서 동일한 종류의 결과를 볼 수 있도록 패치를 업스트림으로 제안하고 있습니다. `inotify`를 비활성화하지 않고도 가능할 수도 있습니다.

지난 10년 동안 업계는 확장성이 뛰어난 분산 시스템을 구축하는 데 훨씬 능숙해졌고, 이는 분명 좋은 일이라고 생각합니다.

OpenAI에서는 이러한 지식과 놀라운 오픈 소스 생태계를 활용하여 과거에는 준비하는 데 10년이 걸리고 훨씬 더 많은 독점 소프트웨어가 필요했을 규모에 도달할 수 있었습니다.

ChatGPT가 출시되었을 때 우리가 그 순간을 충족할 수 있었던 것은 오픈 소스의 힘을 입증하는 것입니다.

오픈 소스 소프트웨어는 우리 모두에게 핵심 비즈니스 문제에 집중하고 다른 문제에 대해 크게 걱정하지 않을 수 있는 능력을 제공합니다.

그럼에도 불구하고 우리 커뮤니티가 수평적으로 확장하는 데 능숙해졌다고 해서 선택한 프로파일러를 분석하고 내부적으로, 하드웨어에서 실제로 무슨 일이 일어나고 있는지 확인하는 데 가치가 없는 것은 아닙니다.

때로는 놀라운 것을 발견할 수도 있습니다. 솔직히 요즘에는 그 어느 때보다 쉽습니다.

Chat에 Perf를 처음 실행하도록 요청하거나 명령줄 인수를 올바르게 가져오거나 결과를 해석하기 위해 C 프로그래머가 될 필요는 없습니다.

15분, 루트 및 약간의 인내심만 있으면 됩니다. 제 마지막 메시지는 이것입니다.

이런 종류의 일에 관심이 있다면, 이것이 멋지다고 생각한다면 하루 중 몇 분을 내어 회사에서 로드 시 사용하는 오픈 소스 소프트웨어를 프로파일링하고 놀라운 것을 더 찾아내어 오픈 소스 소프트웨어를 모든 사람에게 조금 더 나은 소프트웨어로 만들 수 있는지 봅시다.

발표자는 OpenAI의 응용 관측 팀에서 일하고 있으며, 대규모 로그 처리 방법에 대해 공유할 예정이다.

ChatGPT 출시 이후 AI는 업무 방식과 정보 접근 방식을 변화시켰다.

GPT 모델은 텍스트 생성 외에 이미지 처리, 코드 작성, 복잡한 도구 오케스트레이션 등 다양한 기능을 수행한다.

기능 향상은 더 많은 컴퓨팅 자원, Kubernetes 클러스터, 사용자 트래픽, 원격 측정 데이터를 필요로 한다.

응용 관측 팀의 역할은 OpenAI 엔지니어들이 SE를 예방하고 효과적으로 대응할 수 있도록 도구를 제공하는 것이다.

이는 엄청난 양의 원격 측정 데이터를 수집하고, 빠르고 쿼리 가능하며 실행 가능하게 만드는 것을 의미한다.

로깅 아키텍처 및 Fluent Bit의 중요성

발표자는 로깅 솔루션의 아키텍처, 직면한 과제, 성능 향상 필요성에 대해 설명할 것이다.

데이터 수집 파이프라인은 Fluent Bit에서 시작된다.

Fluent Bit는 모든 Kubernetes 노드에서 실행되며 로그 수집, 샘플링, 메타데이터 보강, 포맷팅, 라우팅 등의 역할을 담당한다.

이 아키텍처를 통해 하루에 약 10페타바이트의 로그가 내보내진다.

Fluent Bit가 모든 노드에서 실행되므로 성능이 중요하며, CPU 할당량 초과 시 로그 손실이나 다른 애플리케이션 성능 저하를 초래할 수 있다.

OpenAI는 GPU 외에 많은 CPU도 필요하지만, 모든 용량을 항상 확보할 수는 없다.

컴퓨팅 자원을 수평적으로 확장할 뿐만 아니라 최적화해야 한다. CPU를 절약하면 호스트에 더 많은 마이크로서비스를 탑재할 수 있다.

데몬 세트는 모든 노드의 리소스를 감소시키므로 새로운 데몬 세트를 만드는 것이 어렵다.

Fluent Bit를 최적화하여 최대한 간결하게 만들기로 결정했다.

Perf와 같은 도구를 사용하여 CPU 주기가 어디로 가는지 파악할 수 있다.

발표자는 Fluent Bit가 문자열 처리에 대부분의 시간을 소비할 것이라고 가설을 세웠다.

Perf 보고서 결과, 가설과 달리 CPU 시간의 약 35%가 'fstat64' 호출에 사용되었다. 이는 로그 파일 크기를 파악하는 데 사용되는 함수이다.

이는 Fluent Bit CPU 시간의 가장 큰 부분이 로그 파일 크기를 파악하는 데 사용된다는 것을 의미한다.

테일 플러그인에서 'fstat'은 주기적인 새로 고침 간격(5초마다)과 inotify를 통해 사용된다.

inotify는 커널에서 파일 쓰기 이벤트를 알려주어 주기적인 폴링 필요성을 줄여준다.

inotify를 끄는 한 줄 코드 변경을 테스트 클러스터에 배포했다.

결과, CPU 사용량이 약 절반으로 줄었다.

inotify 이벤트에 대한 응답으로 Fluent Bit는 fstat 호출을 실행하여 쓰인 데이터의 양을 파악한 후 파일을 읽는다.

새 로그가 줄 단위로 계속 내보내질 때마다 Fluent Bit는 경쟁적으로 처리하며 계속 stat을 실행하여 불필요한 컴퓨팅을 소모한다.

이 변경 사항을 모든 프로덕션 환경에 배포한 결과, Kubernetes 클러스터에 약 30,000개의 CPU 코어 용량을 돌려주었다.

가장 많이 로드된 Fluent Bit 포드에서 CPU가 50% 감소했으며, 피크 시 약 30,000개의 CPU 코어를 확보했다.

이는 Fluent Bit 개선을 위한 일련의 노력 중 가장 효과적인 변화였다.

사용자 환경에서도 동일한 결과를 얻을 수 있도록 inotify를 비활성화하지 않고 최소 간격 등을 지정하는 패치를 업스트림으로 제안하고 있다.

결론 및 오픈 소스 기여의 중요성

지난 10년간 업계는 확장 가능한 분산 시스템 구축에 능숙해졌고, OpenAI는 오픈 소스 생태계를 활용하여 대규모 확장에 성공했다.

오픈 소스 소프트웨어는 핵심 비즈니스 문제에 집중할 수 있도록 돕는다.

분산 시스템 확장에 능숙해졌지만, 프로파일러를 분석하고 하드웨어에서 무슨 일이 일어나는지 확인하는 것은 여전히 가치가 있다.

Perf를 실행하고 결과를 해석하는 것이 이전보다 훨씬 쉬워졌다.

하루 중 몇 분을 할애하여 회사에서 사용하는 오픈 소스 소프트웨어를 프로파일링하고 개선하여 모두에게 더 나은 소프트웨어를 만들 것을 권장한다.

Keynote: How One Line of Code Freed 30,000 CPU Cores: Deep-Diving Fluent Bit at Petabyte... F. Ponce

스크립트