fault-tolerance

6 개의 포스트

cloudflare4분 읽기큐레이션 요약

Meerkat 소개 - 글로벌 합의에 대한 실험

Cloudflare는 330곳이 넘는 글로벌 데이터센터에서 동일한 컨트롤 플레인 상태를 강한 일관성으로 읽고 수정할 수 있는 합의 서비스를 개발하고 있다. 기존 Raft는 리더 장애와 타임아웃 때문에 광역 네트워크에서 쓰기 가용성이 중단될 수 있어, Cloudflare는 모든 복제본이 쓰기에 참여하고 타임아웃으로 진행이 멈추지 않는 QuePaxa 기반의 Meerkat을 만들었다. Meerkat은 아직 실험 단계이며, 우선 데이터베이스 리더십이나 리소스 배치처럼 작은 규모의 내부 컨트롤 플레인 상태를 관리하는 데 사용될 예정이다. ## 글로벌 컨트롤 플레인 데이터의 필요성 - Cloudflare의 여러 서비스는 전 세계 데이터센터에 분산된 머신에서 동일한 제어 상태를 읽고 수정해야 한다. - 대표적인 컨트롤 플레인 데이터는 다음과 같다. - AI 모델 인스턴스 등 리소스의 배치 정보 - 데이터베이스에서 쓰기를 수행할 수 있는 머신을 나타내는 리더십 정보 - 네트워크 단절, 데이터센터 장애, 서버 중단, 큐 포화, 케이블 절단 등 인터넷 환경의 불확실성에도 시스템이 동작해야 한다. - 따라서 다음 두 조건을 동시에 만족하는 데이터 시스템이 필요하다. - 여러 클라이언트가 서로 모순되지 않는 상태를 읽는 강한 일관성 - 일부 머신이나 네트워크 링크가 실패해도 읽기와 쓰기가 가능한 장애 내성 ## 선형화 가능성으로 대표되는 강한 일관성 - 일관성 모델은 동시 읽기와 쓰기에서 시스템이 허용하는 동작 범위를 정의한다. - 약한 일관성에서는 여러 노드에 도착한 쓰기 순서가 재배열될 수 있다. - 더 강한 모델에서는 쓰기 순서는 유지되더라도 읽기가 서로 다른 시점의 값을 볼 수 있다. - 가장 강한 모델인 **선형화 가능성(linearizability)** 은 실제 시간 순서에 맞춰 연산이 실행된 것처럼 보이게 한다. - 어떤 쓰기가 완료된 뒤의 읽기는 반드시 그 쓰기 결과를 볼 수 있다. - 프로그래머는 분산 저장소를 단일 스레드 머신의 메모리처럼 추론할 수 있다. - Meerkat 위에 구축되는 키-값 저장소는 선형화 가능성뿐 아니라 직렬성(serializability)도 제공할 예정이며, 직렬성에 대한 자세한 내용은 후속 글에서 다룬다. ## 요구되는 장애 내성 - 시스템은 전체 머신 수가 `2f + 1`일 때 최대 `f`개의 장애를 감당하는 것을 목표로 한다. - 다음 조건이 유지되면 어느 데이터센터의 클라이언트에서도 읽기와 쓰기가 가능해야 한다. - 전체 머신의 과반수가 살아 있고 서로 통신할 수 있다. - 클라이언트가 과반수의 활성 머신과 연결된 머신 하나에 접속할 수 있다. - 이 조건은 단일 머신 장애나 하나의 네트워크 링크 성능 저하만으로 전체 시스템의 가용성이 떨어지지 않아야 함을 의미한다. - 시스템은 다음과 같은 장애에서도 올바른 상태를 유지해야 한다. - 머신 충돌 및 재시작 - 네트워크 장애와 지연 - 데이터센터 장애 - 네트워크 품질 저하 - 한편 공격자가 악의적으로 잘못된 메시지를 보내는 **비잔틴 장애**는 Raft와 마찬가지로 처리 대상에서 제외한다. - 안전성의 핵심은 최신 상태를 가진 두 머신이 서로 다른 세계를 인식하지 않도록 하는 것이다. 예를 들어 한 머신이 `key1=1`, 다른 머신이 `key1=2`라고 판단하는 상황을 허용하지 않는다. ## Raft가 광역 네트워크에서 겪는 한계 - Raft는 한 번에 하나의 리더만 쓰기를 수행할 수 있도록 한다. - 리더가 충돌하거나 네트워크 지연으로 사실상 접근 불가능해지면 다음 과정이 필요하다. - 다른 복제본이 리더의 실패를 타임아웃으로 감지 - 새로운 리더 선출 - 새 리더가 활동을 시작할 때까지 쓰기 중단 - 인터넷 전반에 걸친 Cloudflare 네트워크에서는 지연 시간이 일정하지 않기 때문에 타임아웃 값을 적절히 설정하기 어렵다. - 타임아웃이 너무 짧으면 정상적인 지연을 장애로 오인하고, 너무 길면 실제 장애 이후 복구가 늦어진다. - Cloudflare는 리더를 사용할 수 없어 합의 기반 시스템이 중단된 여러 장애를 경험했으며, 이것이 새로운 합의 서비스 개발의 배경이 되었다. ## QuePaxa 기반 Meerkat - Meerkat은 EPFL 연구진이 2023년에 발표한 합의 알고리즘 **QuePaxa**를 기반으로 한다. - Raft와 달리 QuePaxa에서는 모든 복제본이 항상 쓰기를 수행할 수 있다. - 특정 리더가 장애를 일으켰을 때 새 리더 선출을 기다리느라 전체 진행이 멈추지 않는다. - 타임아웃 때문에 합의 진행이 중단되지 않는 특성은 지연이 불규칙한 광역 네트워크에 적합하다. - Meerkat은 합의 로그를 제공하고, 그 위에 다음과 같은 애플리케이션을 구축한다. - 트랜잭션 키-값 저장소 - 분산 임대(lease) 및 잠금 시스템 - 데이터베이스 리더십 관리 - Cloudflare는 이를 글로벌 규모에서 산업적으로 배포하는 최초의 QuePaxa 사례가 될 것으로 보고 있다. ## 현재 개발 단계와 적용 범위 - Meerkat은 아직 개발 중인 실험적인 서비스다. - 초기에는 대규모 사용자 데이터가 아니라 작은 컨트롤 플레인 상태를 관리하는 데 집중한다. - 즉시 외부 공개 서비스로 제공하지 않고 Cloudflare 내부 전용으로 운영할 계획이다. - 이번 글은 Meerkat의 배경과 요구사항을 소개하고, 이후 합의 로그와 그 위에 구축되는 저장소 및 리스 시스템에 관한 후속 글의 기반을 마련한다. Meerkat의 핵심 설계 방향은 리더 장애와 고정된 타임아웃에 의존하지 않는 합의를 통해, 글로벌 네트워크에서도 선형화 가능한 데이터와 높은 쓰기 가용성을 함께 확보하는 것이다. 다만 실제 운영에서는 과반수 연결 조건과 비잔틴 장애를 처리하지 않는다는 한계를 함께 고려해야 한다.

원문 읽기(새 탭에서 열림)
toss6분 읽기큐레이션 요약

Spark Connect on Kubernetes #1: 견고한 Spark Connect 만들기

토스증권은 여러 사용자가 안정적으로 사용할 수 있는 Production급 Spark Connect를 Kubernetes에서 운영하고 있습니다. Spark Connect는 Driver를 애플리케이션마다 실행하는 대신 장기 실행 서버로 분리해 가벼운 클라이언트와 빠른 세션 생성을 제공하지만, 여러 세션이 하나의 SparkContext를 공유하면서 장애 전파와 리소스 경합 문제가 발생합니다. 이를 해결하기 위해 글로벌 장애 카운터를 사실상 비활성화하고, 결과 크기를 제한하며, 여러 Replica로 Driver와 SparkContext를 분리하는 전략을 사용합니다. ## Classic Spark의 구조와 Spark Connect의 등장 - Spark는 작업을 계획·지휘하는 **Driver**와 실제 연산을 수행하는 **Executor**로 구성됩니다. - Classic Spark의 배포 방식은 다음과 같습니다. - **Client mode**: 클라이언트 프로세스가 Driver 역할을 수행합니다. - **Cluster mode**: 작업 제출 시 클러스터에 Driver가 생성되고 작업 종료 후 사라집니다. - 두 방식 모두 애플리케이션마다 Driver가 하나씩 생성되고, 애플리케이션의 수명과 함께 종료됩니다. - Spark Connect는 Spark 3.4부터 도입됐으며, 4.0에서는 기존 Dataset/DataFrame API와 거의 동등한 수준에 도달했습니다. - 글의 구현과 설정은 Spark 4.1을 기준으로 합니다. ## Spark Connect의 동작 방식 - Spark Connect에서는 Driver를 애플리케이션별 프로세스가 아니라 **미리 실행해 둔 서버**로 운영합니다. - 클라이언트는 Spark 라이브러리와 JVM을 직접 포함하지 않는 Thin Client입니다. - 클라이언트의 DataFrame·SQL 연산은 다음 과정으로 처리됩니다. - 연산을 Unresolved Logical Plan으로 변환 - Protocol Buffer로 인코딩 - gRPC를 통해 서버로 전송 - 서버가 분석, 최적화, 스케줄링, 실행 수행 - 결과를 Arrow 기반으로 클라이언트에 스트리밍 - 구조적으로는 JDBC 클라이언트가 데이터베이스 서버에 질의하는 모델과 유사합니다. ## Spark Connect의 장점 - 클라이언트에 무거운 Spark 의존성이나 JVM이 없어도 됩니다. - Python, SQL, 노트북, BI 도구 등 다양한 클라이언트가 같은 서버에 접속할 수 있습니다. - Driver가 이미 실행 중이므로 매번 프로세스를 생성하고 리소스를 협상할 필요가 없습니다. - 클라이언트가 종료되거나 네트워크가 끊겨도 서버에서 실행 중인 작업은 보호할 수 있습니다. - 반면 하나의 장기 실행 서버에 여러 사용자가 접속하면서, Spark의 기존 “애플리케이션 하나에 워크로드 하나”라는 전제가 깨집니다. ## 공유 Driver가 만드는 단일 장애점 - 여러 세션이 하나의 SparkContext와 Driver JVM을 공유합니다. - Driver가 장애를 일으키면 해당 서버의 모든 세션, 실행 중인 Job, 캐시가 함께 사라집니다. - `spark.executor.maxNumFailures`는 Executor 실패를 애플리케이션 전체 단위로 누적합니다. - 기본 임계값은 `max(3, 2 × executor 수)`입니다. - 임계값을 초과하면 `stopApplication()`이 호출되고, 결과적으로 `sys.exit(11)`로 서버 전체가 종료됩니다. - 이 카운터는 다음 이유로 멀티세션 환경에서 위험합니다. - 개별 쿼리의 Task 실패가 아니라 Executor 실패를 전역적으로 집계합니다. - 시간이 지나도 실패 기록이 계속 누적됩니다. - 서로 다른 사용자의 실패가 합산됩니다. - 문제가 없는 세션도 장애를 함께 겪게 됩니다. ## 세션 격리와 리소스 경합의 한계 - `newSession()`은 SQL 네임스페이스 등 세션 상태만 분리합니다. - CPU, 메모리, Executor, Task 슬롯은 모든 세션이 공유합니다. - 한 사용자가 대규모 Job을 제출하면 다른 사용자의 쿼리 응답도 느려질 수 있습니다. - 기본 FIFO 스케줄링에서는 먼저 제출된 작업이 우선하며, 선점이 없어 이미 실행 중인 Task를 중단할 수 없습니다. - Fair Scheduler를 사용해도 Task 슬롯을 배분하는 순서만 조정할 뿐, 사용자별 CPU·메모리 격리는 제공하지 않습니다. - Spark Connect에서는 `spark.scheduler.pool`이 기본적으로 제대로 전파되지 않아 모든 쿼리가 Default Pool에 들어갑니다. - Classic Spark에서는 `setLocalProperty()`가 Driver 스레드에 직접 적용됩니다. - Spark Connect에서는 클라이언트와 Driver가 분리되어 서버의 요청 처리 스레드에 값을 별도로 설정해야 합니다. - 토스증권은 서버 스레드에 사용자별 Pool을 직접 설정하는 방식으로 이 문제를 보완했습니다. - 사용자별 Pool을 적용하려면 먼저 요청의 사용자를 식별해야 하며, 인증·인가와 연결됩니다. - 궁극적인 CPU·메모리 격리는 Spark 스케줄러가 아니라 Spark 외부의 리소스 관리 계층에서 해결해야 합니다. ## 고정된 서버 스케일 문제 - Spark Connect 서버는 이미지, Driver·Executor 리소스, Spark 설정이 고정된 상태로 실행됩니다. - Dynamic Resource Allocation으로 Executor 수는 조절할 수 있지만, 서버 자체의 기본 스펙은 실행 중 바뀌지 않습니다. - 서버를 필요에 따라 생성·교체하거나 팀 단위로 격리하는 문제는 후속 글에서 다룹니다. ## 글로벌 장애 카운터 비활성화 - 서버 전체를 종료시키는 Executor 실패 경로를 차단하기 위해 다음과 같이 설정합니다. - `spark.executor.maxNumFailures`: 사실상 무한대로 설정해 글로벌 종료 조건을 비활성화 - `spark.executor.failuresValidityInterval`: 오래된 실패 기록을 주기적으로 제거 - `spark.task.maxFailures`: 동일 Task의 반복 실패를 제한 - `spark.stage.maxConsecutiveAttempts`: Shuffle Fetch 실패로 Stage가 반복 실행되는 상황을 제한 - `task.maxFailures`는 OOM이나 예외처럼 동일 Task가 반복 실패하는 경우를 담당합니다. - `stage.maxConsecutiveAttempts`는 Shuffle Fetch 실패로 Stage 전체가 반복되는 경우를 담당합니다. - 이 방식으로 문제가 있는 쿼리만 실패시키고 서버와 다른 사용자의 세션은 유지할 수 있습니다. - 다만 실패 허용 횟수를 지나치게 낮추면 일시적인 장애에도 정상 쿼리가 실패할 수 있으므로 워크로드에 맞춰 여유를 둬야 합니다. ## Driver 메모리 보호와 결과 크기 제한 - Spark Connect에서는 쿼리 결과가 Driver를 거쳐 클라이언트로 스트리밍됩니다. - 사용자가 대규모 테이블을 `collect`하면 Driver 메모리가 고갈될 수 있습니다. - `spark.driver.maxResultSize`는 한 액션에서 반환되는 Task 결과의 누적 크기를 제한합니다. - 제한을 초과하면 Driver가 결과를 모두 가져오기 전에 Job을 중단하므로, 대규모 결과가 Driver 메모리에 유입되는 것을 막을 수 있습니다. - 기본값인 1GB는 애플리케이션 하나만 실행하는 환경의 값이므로, 여러 세션이 동시에 결과를 가져가는 멀티세션 서버에서는 더 보수적으로 설정해야 합니다. - 이 설정만으로 Driver OOM이나 노드 장애까지 막을 수는 없습니다. ## 여러 Replica를 통한 장애 영향 축소 - Driver 자체의 OOM이나 노드 소실처럼 설정으로 막을 수 없는 장애에 대비해 Spark Connect 서버를 여러 Replica로 구성합니다. - 각 Replica는 독립적인 다음 요소를 갖습니다. - SparkContext - Driver - Executor - 한 Replica가 장애로 종료되어도 장애 범위가 해당 Replica에 한정되고, 다른 Replica가 새로운 세션 요청을 처리할 수 있습니다. - 단일 서버의 장애가 Spark Connect 전체로 확산되는 구조를 여러 독립 실행 단위로 나누는 것이 핵심입니다. ## 실용적인 운영 방향 - 멀티세션 Spark Connect에서는 전역 장애 카운터를 그대로 두지 말고, Task·Stage·Job 단위의 실패 제한으로 문제 쿼리를 격리하는 것이 안전합니다. - `spark.driver.maxResultSize`를 동시 세션 수와 쿼리 특성에 맞게 보수적으로 설정해야 합니다. - 스케줄러 Pool만으로는 CPU·메모리 격리가 불가능하므로, 강한 격리가 필요하면 Replica나 Kubernetes 리소스 정책을 활용해야 합니다. - 단일 Driver를 그대로 공유하기보다 여러 Replica를 운영해 장애의 영향 범위를 줄이는 것이 Production 환경에 적합합니다.

원문 읽기(새 탭에서 열림)
meta4분 읽기큐레이션 요약

불은 꺼지고 시스템은 켜진다: 즉각적인 정전 대비 태세 검증

Meta는 데이터센터의 무경고 전력 상실에 대비하기 위해 **Instantaneous PowerLoss Storm**이라는 새로운 재해 대응 테스트 체계를 도입했다. 기존 시스템에 방어 심층화 전략을 적용하고, 지역 전체의 전원을 실제로 차단하는 단계적 검증을 통해 서비스·데이터·시설의 복원력을 확인했다. 목표는 한 지역 전체의 전력 상실을 개별 장애 도메인 손실만큼 안정적으로 처리하는 것이다. ## 무경고 재해에 대비한 새로운 테스트 패러다임 - 기존의 허리케인, 산불, 전력·네트워크 장애 대응책은 사전 경보가 있을 때 효과적이다. - 그러나 순간적인 전력 상실처럼 전혀 예고되지 않는 재해는 기존 전략만으로 대응하기 어렵다. - Instantaneous PowerLoss Storm은 Meta의 기존 Disaster Readiness(재해 대비) “Storm” 프로그램에 추가된 최종 방어선이다. - 알려진 위험뿐 아니라 새롭게 등장하거나 아직 발견되지 않은 위험까지 검증 대상으로 삼는다. ## 데이터센터 전 계층에 적용한 방어 심층화 - 전력 상실 내성을 데이터센터의 전체 스택에 내장했다. - 기계·전기 설비 - 서버 랙 - 스토리지와 컴퓨트 - Twine 컨테이너 오케스트레이터 - 랙 전원이 끊겨도 배터리와 Power Loss Siren(PLS)을 이용해 메모리 데이터를 보존할 수 있도록 했다. - Twine 서비스 간에는 지역 전체에서 동작하는 비동기 신호 체계인 Unavailability Event(UE)를 구축했다. - 기존 기능은 단일 데이터센터의 장애 도메인에서 검증되어 있었지만, 여러 데이터센터가 연결된 지역 전체 장애에서는 다음 문제가 추가로 발생했다. - 장애 규모가 일반 장애 도메인보다 약 50~60배 큼 - 서비스 복제본 배치 문제 - 수백만 개 서비스의 동시 재시작과 자동 발견 - 전원이 꺼진 지역을 스스로 부팅해야 하는 문제 ## 전체 지역 부팅과 순환 의존성 문제 - Twine의 Scheduler, Allocator, Broker, Zelos 같은 제어 플레인 서비스는 다른 서비스를 시작하기 위한 필수 구성요소다. - 전체 지역이 동시에 부팅될 때 제어 플레인 서비스끼리 서로를 필요로 하는 순환 의존성, 즉 “ouroboros” 문제가 발생할 수 있다. - 이를 해결하기 위해: - 핵심 시작 의존성을 식별했다. - CI/CD에서 Belljar 테스트를 지속적으로 실행해 의존성 문제를 조기에 발견했다. - 예기치 않은 순환 의존성을 끊을 수 있도록 Twine recovery kit을 제공했다. - 이 복구 키트는 Twine 자체를 구동하는 서비스에 대한 “jumpstart” 역할을 한다. - Belljar, Twrko, recovery kit을 함께 사용해 지역 전체 부팅 시 발생할 수 있는 순환 의존성 위험을 줄였다. ## 제어 플레인을 종료시키는 ‘부메랑’ 문제 - UE는 서비스 종료와 복구를 조정하는 신호지만, 이 신호를 생성·전달하는 제어 플레인 자체가 UE에 의해 종료될 수 있었다. - 그러면 일부 서비스가 종료 신호를 받지 못한 채 고아 상태로 남을 수 있다. - 특정 서비스를 UE 전달 대상에서 제외하는 복잡한 방식 대신, 전력 관련 UE를 제어 플레인 서비스가 무시하도록 설계했다. - 단순한 예외 처리로 시스템 복잡도와 유지보수 부담을 낮췄다. ## 신뢰성과 개발 속도 사이의 절충 - 순간 장애에 완벽히 대응하려는 설계는 과도한 엔지니어링이나 정상 운영 중 오탐 위험을 만들 수 있다. - 따라서 반드시 방지해야 할 영향과 감수할 수 있는 영향을 구분했다. - 반드시 방지해야 하는 영향: - 스토리지·데이터베이스 데이터 손실 - 데이터센터 기계·전기 설비의 영구 손상 - 단일 지역을 넘어 지속되는 광범위한 장애 - 허용 가능한 영향: - 일시적인 서비스 오류 - 사전에 정한 한도 내의 랙 장애 - 서비스 라우팅 테이블의 제한된 최신성 저하 - 지역 장애 감지의 일시적인 지연 - 사후 복구가 어렵거나 합리적인 MTTR 내에 완화할 수 없는 문제를 허용 범위 밖으로 정의했다. ## 단계적 검증으로 위험과 폭발 반경 축소 - 전원을 직접 차단하는 테스트는 큰 위험을 동반하므로 점진적인 검증 방식을 택했다. - 검증 단계는 다음과 같다. - 신규·사전 운영 지역에서 의존성 등 독립적인 문제를 먼저 테스트 - 운영 지역을 복제한 shadow 지역에서 실험 - 가장 작고 새로운 운영 지역에서 실제 전력 차단 수행 - 이후 스토리지, AI, 데이터 웨어하우스가 위치한 대규모 운영 지역까지 확대 - 최종 단계의 전력 차단 훈련을 Instantaneous PowerLoss Storm이라고 명명했다. ## 실제 Storm 실행 방식 - 전체 지역에 전력 공급 장애를 주입해 즉시 전원을 차단한다. - 실제 장애처럼 보이도록 테스트 전에 선제적인 보호 조치를 최소화했다. - 현실적인 사고 상황의 MTTR을 반영한 뒤, 영향을 받은 지역을 전역 컨트롤러와 스케줄러에서 격리하는 “drain” 조치를 수행했다. - 반복적인 훈련을 통해 인프라와 엔지니어가 지역 전체 장애를 개별 장애 도메인 장애처럼 처리하도록 개선하고 있다. ## 실용적인 결론 대규모 인프라의 무경고 장애 대비에는 단일 복구 기능보다 시설부터 오케스트레이터까지 이어지는 방어 심층화가 중요하다. 특히 전체 시스템 부팅 시의 순환 의존성과 제어 플레인 보호를 사전에 검증하고, 작은 환경에서 시작해 실제 운영 지역으로 단계적으로 확대하는 방식이 안전성과 개발 속도를 함께 확보하는 현실적인 접근이다.

원문 읽기(새 탭에서 열림)
aws원문

Amazon SageMaker HyperPod에서 (새 탭에서 열림)

Amazon SageMaker HyperPod은 대규모 AI 모델 학습의 효율성을 극대화하기 위해 '체크포인트리스(Checkpointless) 학습'과 '엘라스틱(Elastic) 학습' 기능을 새롭게 출시했습니다. 이 기술들은 하드웨어 장애 발생 시 복구 시간을 획기적으로 단축하고 클러스터 자원 활용도를 자동 최적화하여 전체 개발 주기를 대폭 앞당깁니다. 이를 통해 엔지니어는 인프라 관리 부담에서 벗어나 모델 성능 고도화와 시장 출시 속도 향상에 더욱 집중할 수 있습니다. ### 체크포인트리스 학습을 통한 중단 없는 상태 복구 기존의 체크포인트 기반 복구는 작업 종료, 재시작, 네트워크 설정, 체크포인트 검색 및 로드 등 복잡한 단계를 거치느라 최대 1시간 이상의 다운타임이 발생하곤 했습니다. 체크포인트리스 학습은 이러한 병목 현상을 해결하기 위해 다음과 같은 기술적 요소를 도입했습니다. * **피어 투 피어(P2P) 상태 복제**: 모델의 상태를 클러스터 내의 건강한 노드(Peer)에 실시간으로 복제하여 저장하며, 장애 발생 시 체크포인트를 불러오는 대신 이웃 노드로부터 즉시 상태를 복구합니다. * **복구 시간 단축**: 전통적인 방식 대비 복구 시간을 분 단위로 줄였으며, 내부 테스트 결과 2,000개 이상의 GPU 환경에서도 다운타임을 80% 이상 감소시키는 성과를 보였습니다. * **4가지 핵심 구성 요소**: 집합 통신 초기화 최적화, 캐싱이 가능한 메모리 매핑 데이터 로딩, 프로세스 내 복구(In-process recovery), 그리고 P2P 상태 복제 기술이 유기적으로 결합되어 작동합니다. * **검증된 확장성**: 수만 개의 가속기를 활용한 Amazon Nova 모델 학습에 이미 성공적으로 적용되어 대규모 환경에서의 안정성을 입증했습니다. ### 자원 활용을 극대화하는 엘라스틱 학습 엘라스틱 학습은 클러스터의 가용 자원 상태에 따라 학습 워크로드의 규모를 유연하게 조절하는 기능입니다. 인프라의 가변적인 상황에 맞춰 학습 효율을 최대로 끌어올립니다. * **자동 확장 및 축소**: 클러스터 내에 유휴 자원이 발생하면 학습 규모를 자동으로 확장하고, 추론 서비스와 같은 고우선순위 작업이 몰릴 때는 자원을 즉시 반납하며 축소합니다. * **운영 효율성**: 매주 수동으로 인프라 설정을 변경하던 엔지니어링 시간을 절약할 수 있으며, 클러스터 활용도를 높여 전체 학습 완료 시간을 단축합니다. * **우선순위 기반 할당**: 비즈니스 요구사항에 따라 자원을 재배치함으로써 고비용의 컴퓨팅 자원을 낭비 없이 사용할 수 있도록 지원합니다. ### 실용적인 권장 사항 수천 개의 GPU를 사용하는 초거대 모델 학습 환경에서는 하드웨어 장애가 빈번하게 발생할 수밖에 없습니다. 인프라 장애로 인한 학습 중단 리스크를 최소화하고 싶은 팀은 SageMaker HyperPod의 체크포인트리스 학습을 도입하여 복구 골든타임을 확보할 것을 권장합니다. 특히 가변적인 인프라 환경에서 비용 효율성을 중시한다면 엘라스틱 학습 기능을 활성화하여 클러스터 유휴 자원을 100% 활용하는 전략이 유효할 것입니다.

google원문

다채로운 양자의 미래 (새 탭에서 열림)

구글 퀀텀 AI 팀은 초전도 큐비트 플랫폼에서 양자 오류 정정을 위한 '컬러 코드(Color Codes)'를 성공적으로 구현하며 차세대 양자 컴퓨팅의 가능성을 제시했습니다. 이번 연구는 기존에 널리 사용되던 표면 코드(Surface Code)보다 더 적은 물리적 자원으로도 효율적인 오류 정정이 가능함을 실험적으로 입증한 결과입니다. 특히 시스템 규모가 커질수록 논리 오류율이 감소하는 경향을 확인했으며, 이는 결함 허용(Fault-tolerant) 양자 컴퓨터 구축을 위한 중요한 이정표가 될 것입니다. **컬러 코드의 기하학적 효율성과 자원 절감** * 표면 코드가 사각형 격자 구조를 사용하는 것과 달리, 컬러 코드는 삼각형 형태의 육각형 타일링 기하학을 채택하여 논리 큐비트를 구성합니다. * 동일한 '코드 거리(오류를 감지하고 수정할 수 있는 최소 오류 수)'를 유지하면서도 표면 코드보다 훨씬 적은 수의 물리 큐비트만으로 논리 큐비트를 생성할 수 있다는 강점이 있습니다. * 물리적 회로의 깊이가 깊어지고 디코딩 알고리즘이 복잡해지는 기술적 난제가 있었으나, 구글의 최신 'Willow' 칩과 고도화된 디코딩 기술을 통해 오류 정정 임계값 이하의 성능을 달성했습니다. **거리 확장을 통한 오류 억제 성능 입증** * 실험에서 코드 거리 3과 거리 5의 컬러 코드를 비교한 결과, 거리가 증가함에 따라 논리 오류율이 1.56배 억제되는 것을 확인했습니다. * 이는 물리 큐비트를 추가하여 코드 거리를 늘릴수록 더 완벽에 가까운 논리 큐비트를 만들 수 있다는 원리를 실험적으로 증명한 것입니다. * 비록 표면 코드에서 달성한 2.31배의 억제율보다는 아직 낮지만, 시스템 규모가 커질수록 컬러 코드의 기하학적 이점이 더 큰 효율성을 발휘할 것으로 기대됩니다. **논리 연산 속도의 획기적인 향상** * 컬러 코드의 가장 큰 장점 중 하나는 단일 큐비트 논리 연산 속도가 표면 코드에 비해 비약적으로 빠르다는 점입니다. * 예를 들어 양자 연산의 핵심인 '하다마르(Hadamard)' 게이트의 경우, 표면 코드에서는 수천 나노초가 소요되는 반면 컬러 코드에서는 단 20ns 만에 수행이 가능하여 약 1,000배 빠른 속도를 보여줍니다. * 연산 속도가 빨라지면 전체 알고리즘 실행에 필요한 오류 정정 사이클 횟수가 줄어들어, 결과적으로 물리적 자원 요구량을 더욱 낮추는 선순환 구조를 만듭니다. **임의 상태 주입 및 확장성** * 양자 알고리즘 구현에 필수적인 '마법 상태(Magic state)' 또는 T-상태를 생성하기 위해 임의의 큐비트 회전을 논리 큐비트에 주입하는 과정을 성공적으로 시연했습니다. * 논리적 무작위 벤치마킹(Logical Randomized Benchmarking)을 통해 다양한 단일 큐비트 논리 연산의 정확도를 검증했습니다. 이번 연구는 컬러 코드가 자원 효율성과 연산 속도 측면에서 표면 코드의 강력한 대안이 될 수 있음을 보여줍니다. 미래의 대규모 양자 컴퓨터 아키텍처를 설계할 때, 더 적은 큐비트로 더 빠른 연산을 수행할 수 있는 컬러 코드는 실용적인 결함 허용 양자 컴퓨팅 시대를 앞당기는 핵심 기술이 될 것으로 보입니다.

datadog원문

Datadog에서 고신뢰성 데이터 파이프라인 구축하기 (새 탭에서 열림)

데이터독(Datadog)은 매일 수조 건의 데이터를 처리하며 시스템의 신뢰성을 '정해진 시간 내에 정확한 결과물을 출력할 확률'로 정의합니다. 이들은 파이프라인의 장애를 완전히 막는 대신, 장애가 발생하더라도 데이터 전달 기한을 지킬 수 있도록 결함 허용(Fault Tolerance)과 빠른 복구에 초점을 맞춘 아키텍처를 구축했습니다. 특히 개별 작업 단위로 클러스터를 분리하고 장시간 실행되는 작업을 작게 쪼개는 전략을 통해 대규모 데이터 처리의 안정성을 확보하고 있습니다. ### 작업 격리를 위한 개별 클러스터 아키텍처 * 하나의 거대한 공유 클러스터를 사용하는 대신, 각 데이터 파이프라인 작업마다 독립적인 전용 클러스터를 할당하여 운영합니다. * 작업 간 리소스 경쟁을 원천 차단하여 특정 작업의 부하가 다른 파이프라인에 영향을 주지 않으며, 클러스터별 상태를 명확히 파악할 수 있어 모니터링이 용이합니다. * 작업의 특성에 따라 CPU 최적화 인스턴스나 메모리 최적화 인스턴스를 선택하는 등 하드웨어를 유연하게 튜닝할 수 있습니다. * 새로운 버전의 Hadoop이나 Spark를 도입할 때 전체 시스템을 중단할 필요 없이, 특정 클러스터부터 점진적으로 업그레이드하며 버그나 호환성을 테스트할 수 있습니다. ### 스팟 인스턴스 활용과 실패를 고려한 설계 * 비용 절감을 위해 AWS 스팟 인스턴스를 적극 활용하며, 이는 클러스터가 언제든 중단될 수 있다는 전제하에 파이프라인을 설계하도록 강제하는 '카오스 엔지니어링'의 효과를 줍니다. * 단일 작업의 실행 시간이 길어질수록 실패 시 손실되는 작업량과 복구 시간이 늘어나므로, 이를 방지하기 위해 작업을 수직적·수평적으로 세분화합니다. * **수직적 분할:** 데이터 변환 과정을 여러 단계의 작업으로 나누고, 단계 사이의 중간 데이터를 S3에 저장(Checkpointing)하여 실패 시 처음부터 다시 시작하지 않고 중간 지점부터 재개할 수 있게 합니다. * **수평적 분할:** 입력 데이터를 샤드(Shard) 단위로 파티셔닝하여 여러 작업이 병렬로 처리하게 함으로써 개별 작업의 규모를 작게 유지합니다. ### 롤업(Rollup) 파이프라인의 최적화 사례 * 과거 14시간 이상 소요되던 단일 메트릭 집계 작업을 '집계' 단계와 '커스텀 포맷 저장' 단계로 분리하여 관리합니다. * 첫 번째 집계 작업의 결과물을 S3에 Parquet 파일로 저장함으로써, 두 번째 단계에서 장애가 발생하더라도 집계 과정을 다시 반복할 필요가 없습니다. * Kafka 파티션 구조를 기반으로 데이터를 샤딩하여, 데이터 규모가 급증하거나 특정 샤드에 문제가 발생했을 때 해당 부분만 격리하여 리소스를 집중 투입하거나 빠르게 복구할 수 있습니다. * 이러한 구조는 작업 시작 오버헤드나 S3 쓰기 비용을 발생시키지만, 장애 복구 시간을 단축하고 전체 시스템의 데이터 가용성을 보장하는 데 결정적인 역할을 합니다. 대규모 데이터 시스템에서 신뢰성은 시스템이 절대 중단되지 않는 것이 아니라, 중단되었을 때 얼마나 빠르게 복구되어 사용자에게 제때 데이터를 전달하느냐에 달려 있습니다. 이를 위해 파이프라인을 최대한 작고 독립적인 단위로 쪼개고 중간 상태를 유지하는 설계는 복잡한 데이터 환경에서 필수적인 전략입니다.