왜 락프리인가?

전통적인 동시성 제어 방법인 뮤텍스나 세마포어는 여러 문제점을 가지고 있다:

• 성능 저하: 락 경합(lock contention)으로 인한 대기 시간

• 데드락: 여러 스레드가 서로의 락을 기다리는 상황

• 우선순위 역전: 낮은 우선순위 스레드가 높은 우선순위 스레드를 블로킹

• 컨텍스트 스위칭: 락 대기 중 발생하는 오버헤드

락프리 알고리즘은 이러한 문제들을 아토믹한 연산을 통해 해결한다.

락프리 스택

락프리 스택은 선두 요소에 대한 push와 pop 조작만 가진 리스트로 구성된다. 가장 대표적인 구현은 Treiber 스택이다.

참고 자료: 위키피디아-Treiber 스택

Treiber 스택

Treiber 스택은 락프리 스택 알고리즘의 하나로 여러 스레드가 동시에 접근해도 락 없이 안전하게 동작하는 스택이다.

한 문장으로 아이디어를 요약하자면 이렇다.

내가 작업을 시작했을 때의 상태가 그대로라면 내 작업을 진행한다. 누군가가 중간에 이를 바꿔 상태가 바뀌었다면 처음부터 다시 시도한다.

use std::ptr::null_mut;
use std::sync::atomic::{AtomicPtr, Ordering};

/// Lock-free 스택의 노드 구조체
/// 
/// 단일 연결 리스트의 노드로, 각 노드는 다음 노드에 대한 원자적 포인터와
/// 실제 데이터를 포함한다.
/// 
/// # Type Parameters
/// * `T` - 스택에 저장될 데이터의 타입
struct Node<T> {
    /// 다음 노드를 가리키는 원자적 포인터
    /// AtomicPtr을 사용하여 동시성 환경에서 안전한 포인터 조작을 보장
    next: AtomicPtr<Node<T>>,
    /// 노드가 저장하는 실제 데이터
    data: T,
}

/// Lock-free 스택 구현
/// 
/// Treiber 스택 알고리즘을 사용한 락프리 스택 알고리즘
/// 여러 스레드가 동시에 push/pop 작업을 수행 가능

pub struct LockFreeStack<T> {
    /// 스택의 최상단 노드를 가리키는 아토믹 포인터
    head: AtomicPtr<Node<T>>,
}

impl<T> LockFreeStack<T> {
    /// 새로운 빈 스택을 생성
    /// 
    /// # Returns
    /// 빈 lock-free 스택 인스턴스
    pub fn new() -> Self {
        LockFreeStack {
            head: AtomicPtr::new(null_mut()),
        }
    }

    /// 스택에 새로운 요소를 추가
    /// 
    /// # Arguments
    /// * `v` - 추가할 데이터
    /// 
    /// # Algorithm
    /// 1. 새 노드를 생성
    /// 2. CAS(Compare-And-Swap) 루프를 통해 head 업데이트 시도
    /// 3. 성공할 때까지 재시도
    /// 
    /// # 동작 과정
    /// 1. 현재 head를 읽음
    /// 2. 새 노드의 next를 현재 head로 설정
    /// 3. CAS로 head를 새 노드로 아토믹하게 교체
    /// 4. 다른 스레드가 먼저 변경했다면 1부터 재시도
    pub fn push(&self, v: T) {
        let node = Box::new(Node {
            next: AtomicPtr::new(null_mut()),
            data: v,
        });

        // Box를 raw 포인터로 변환
        // 이 시점부터 메모리 관리는 수동으로 해야 함
        let ptr = Box::into_raw(node);

        // CAS 루프: head가 변경되지 않을 때까지 반복
        loop {
            // 현재 head 읽기
            // Acquire: 이 읽기 이후의 모든 메모리 연산이 이 읽기 이후에 발생하도록 보장
            let head = self.head.load(Ordering::Acquire);

            // 새 노드의 next를 현재 head로 설정
            unsafe {
                (*ptr).next.store(head, Ordering::Release);
            }

            // CAS: head가 여전히 같은 값이면 ptr로 교체
            // compare_exchange_weak는 spurious failure를 허용하여 성능 향상
            match self.head.compare_exchange_weak(
                head,
                ptr,
                Ordering::Release,  // 성공 시: 다른 스레드가 새 head를 볼 수 있도록 Release
                Ordering::Acquire   // 실패 시: 다른 스레드의 변경사항을 읽기 위해 Acquire
            ) {
                Ok(_) => break,     // 성공: 루프 종료
                Err(_) => continue, // 실패: 재시도
            }
        }
    }

    /// 스택에서 최상단 요소를 제거하고 반환
    /// 
    /// # Returns
    /// * `Some(T)` - 스택이 비어있지 않은 경우 최상단 요소
    /// * `None` - 스택이 비어있는 경우
    /// 
    /// # Algorithm
    /// 1. 현재 head 읽기
    /// 2. head가 null이면 None 반환
    /// 3. CAS를 통해 head를 다음 노드로 업데이트 시도
    /// 4. 성공할 때까지 재시도
    /// 
    /// # 주의사항
    /// pop 연산 중 다른 스레드의 간섭으로 인해 
    /// 여러 번의 재시도가 필요할 수 있음
    pub fn pop(&self) -> Option<T> {
        loop {
            // 현재 head 읽기
            let head = self.head.load(Ordering::Acquire);

            // 스택이 비어있는지 확인
            if head == null_mut() {
                return None;
            }

            // head의 다음 노드 읽기
            // 여기서 ABA 문제가 발생할 수 있음 (아래 설명 참조)
            let next = unsafe { (*head).next.load(Ordering::Acquire) };

            // CAS: head를 next로 교체 시도
            match self.head.compare_exchange_weak(
                head,
                next,
                Ordering::Release,  // 성공 시: 메모리 순서 보장
                Ordering::Acquire   // 실패 시: 다른 스레드의 변경사항 읽기
            ) {
                Ok(_) => {
                    // 성공: 이전 head 노드를 Box로 변환하여 자동 메모리 해제
                    let boxed_node = unsafe { Box::from_raw(head) };
                    return Some(boxed_node.data);
                }
                Err(_) => continue, // 실패: 재시도
            }
        }
    }
}

/// 스택이 drop될 때 모든 노드의 메모리를 해제
impl<T> Drop for LockFreeStack<T> {
    fn drop(&mut self) {
        // 모든 노드를 순회하며 메모리 해제
        // drop 시점에는 다른 스레드가 접근하지 않으므로 Relaxed 순서 사용
        let mut current = self.head.load(Ordering::Relaxed);

        while current != null_mut() {
            let node = unsafe { Box::from_raw(current) };
            current = node.next.load(Ordering::Relaxed);
            // node는 스코프를 벗어나면서 자동으로 drop됨
        }
    }
}

/// Send trait 구현: T가 Send면 LockFreeStack<T>도 Send
/// 
/// 다른 스레드로 안전하게 전송 가능함을 나타냄
unsafe impl<T: Send> Send for LockFreeStack<T> {}

/// Sync trait 구현: T가 Send면 LockFreeStack<T>는 Sync
/// 
/// 여러 스레드에서 동시에 참조 가능함
/// T가 Send여야 하는 이유: pop()이 T를 다른 스레드로 이동시킬 수 있기 때문
unsafe impl<T: Send> Sync for LockFreeStack<T> {}

#[cfg(test)]
mod tests {
    use super::*;
    use std::sync::Arc;
    use std::thread;

    #[test]
    fn test_single_thread() {
        let stack = LockFreeStack::new();

        // Push 테스트
        stack.push(1);
        stack.push(2);
        stack.push(3);

        // Pop 테스트 (LIFO 순서)
        assert_eq!(stack.pop(), Some(3));
        assert_eq!(stack.pop(), Some(2));
        assert_eq!(stack.pop(), Some(1));
        assert_eq!(stack.pop(), None);
    }

    #[test]
    fn test_concurrent_operations() {
        let stack = Arc::new(LockFreeStack::new());
        let num_threads = 4;
        let operations_per_thread = 1000;

        // 여러 스레드에서 동시에 push/pop 수행
        let mut handles = vec![];

        for i in 0..num_threads {
            let stack_clone = Arc::clone(&stack);
            let handle = thread::spawn(move || {
                for j in 0..operations_per_thread {
                    stack_clone.push(i * operations_per_thread + j);
                    stack_clone.pop();
                }
            });
            handles.push(handle);
        }

        // 모든 스레드 종료 대기
        for handle in handles {
            handle.join().unwrap();
        }
    }
}

메모리 순서

Rust의 원자적 연산에서 사용되는 메모리 순서는 다음과 같다:

• Relaxed: 가장 약한 순서 보장. 단일 원자적 변수에 대한 순서만 보장

• Acquire: 이 연산 이후의 모든 메모리 연산이 이 연산 이후에 발생하도록 보장

• Release: 이 연산 이전의 모든 메모리 연산이 이 연산 이전에 발생하도록 보장

• AcqRel: Acquire와 Release의 조합

• SeqCst: 가장 강한 순서 보장. 모든 스레드에서 동일한 순서를 관찰

락프리 스택에서는 주로 Acquire/Release 쌍을 사용하여 데이터 경쟁을 방지한다.

락프리에서의 문제점

ABA 문제

락프리 스택은 대부분의 경우 문제가 없으나 특정한 조건에서 ABA 문제가 발생할 수 있다.

ABA 문제는 다음과 같은 예로 설명될 수 있는데

그림에서는 2개의 스레드가 락프리 스택에 push와 pop을 수행하고 있다.

초기 락프리 스택에는 3개의 데이터가 존재하고 각 노드의 주소를 A, B, C라고 하자.

시각 0: 스레드 1은 head의 주소 A와 A의 다음 노드 주소인 B를 기억한다.

시각 1: 스레드 2가 2번의 pop 조작을 수행한다. 그러면 노드 A와 B는 스택에서 제거되고 메모리는 비게(free) 된다.

시각 2: 스레드 2가 새로운 데이터를 push한다. 이때 프리 영역이 된 노드 A가 재사용되면 스택은 A→C라는 상태가 된다.

시각 3: 스레드 1이 pop 조작 이후 CAS 조작을 수행하면 head는 외관상 바뀌지 않지만 해제된 노드B를 이용해 업데이트를 수행하게 된다.

락프리 스택에서는 CAS 조작에 따라 head가 업데이트되지 않았음을 확인한 이후에 데이터의 push와 pop이 이루어지는데, 메모리 영역이 재사용되면 문제가 발생한다.

head가 외관상 바뀌지 않지만 의미적으로는 다른 연산이 수행되었을 수 있는 것이다. 이처럼 ABA문제는 A가 실제로는 중도에 다른 상태(B)로 바뀌었음에도 처음과 끝은 A이므로 처음과 연산 종료 후 결과를 통해서는 업데이트 여부를 제대로 파악할 수 없다는 문제이다.

ABA 문제가 발생하는 이유

ABA 문제가 발생하는 이유는 업데이트 유무가 CAS 처리에 의한 값 비교로 수행되기 때문이다. 값 비교로 작업이 수행되기 때문에 해당 메모리에 어떤 쓰기 작업이 있었는지는 검증하는 과정이 없었다.

그렇다면 문제는 간단해진다. 메모리의 쓰기 작업을 감지할 수 있도록 하면 된다. 이는 Load-Link/Store-Conditional 명령을 이용하면 구현할 수 있다.

ABA 문제 해결 방법

ABA 문제를 해결하는 방법은 여러 가지가 있는데 LL/SC (Load-Link/Store-Conditional): 하드웨어 수준에서 메모리 변경 감지하는 등의 방법이 존재한다.

멀티스레드에서 참조에 대한 문제

락프리 구조는 멀티스레드에서 데이터 삭제에 대한 문제를 일으키기도 한다. 아래 예시는 멀티스레드 참조에 관한 문제를 그림으로 보여준다.

초기 상태에서 리스트는 A→B→C로 연결되어 있다.

시각 0: 스레드 1이 선두 노드를 참조했다고 가정하자.

시각 1: 스레드 2가 pop조작을 수행하고, 선두 노드를 파기한다. 그런데 이때 스레드 1의 참조 x가 댕글링 포인터가 되어버린다.

물론 러스트의 경우 소유권 규칙에 따라 위와 같은 작동을 하는 코드가 컴파일러 선에서 막히기 때문에 실제로 작동될 일은 없으나 가비지 컬렉션(GC)가 없는 언어의 경우 문제가 될 수 있다.

락프리의 분류

락프리는 원래 뮤텍스와 같은 구조들(즉, 락을 말한다)에 의존하지 않는다는 의미로 넓게 사용되었으나 락프리의 정의를 더 좁게 가져가자면

락프리 분류 더 알아보기

배타 락프리 (Obstruction-Free)

• 가장 약한 진행 보장

• 다른 스레드가 없을 때만 진행 보장

• 실용적이지 않아 잘 사용되지 않음

락프리 (Lock-Free)

• 시스템 전체적으로 항상 적어도 하나의 스레드는 진행

• 개별 스레드는 starvation 가능

• 실용적이면서도 구현 가능한 수준

웨이트 프리 (Wait-Free)

• 가장 강한 진행 보장

• 모든 스레드가 유한한 단계 내에 완료

• 구현이 매우 어렵고 성능 오버헤드가 큼

배타 락프리, 웨이트 프리와 구분되어 부르는 락프리는 라이브락이 발생하지 않는, 락에 의존하지 않는 구조로 정의할 수 있겠다.

가장 보편적으로 락프리라 함은 배타 락을 사용하지 않는 구조, 즉 배타 락프리에 더 가깝다고 할 수 있다.

동시성 프로그래밍에서 공유 자원에 대한 안전한 접근은 항상 중요한 과제다. 전통적으로 뮤텍스 락과 같은 비관적 락(Negative Lock) 방식을 사용해왔다. 이 방식은 크리티컬 섹션에 진입하기 전에 반드시 락을 획득해야 하며, 락을 얻지 못하면 코드 실행 자체가 블록된다.

하지만 이와는 다른 접근 방식이 있다. 바로 낙관적 락(Optimistic Lock) 방식인데, 이는 "일단 실행하고 나중에 검증하자"는 철학을 가지고 있다.

낙관적 접근: 트랜잭셔널 메모리

소프트웨어 트랜잭셔널 메모리(Software Transactional Memory, STM)는 이러한 낙관적 접근을 구현한 대표적인 기술이다. STM은 크리티컬 섹션의 코드를 투기적으로 실행한 후, 실행 과정에서 다른 스레드와의 경합이 감지되지 않았을 때만 그 결과를 메모리에 실제로 커밋한다. 마치 데이터베이스의 트랜잭션처럼 작동하는 것이다.

이러한 방식은 락을 기다리는 시간을 줄이고, 데드락 가능성을 원천적으로 차단할 수 있다는 장점이 있다.

하드웨어와 소프트웨어 구현

트랜잭셔널 메모리는 구현 방식에 따라 두 가지로 나뉜다.

• Hardware Transactional Memory (HTM): CPU 레벨에서 직접 지원하는 방식

• Software Transactional Memory (STM): 소프트웨어적으로 구현하는 방식

HTM은 성능면에서 우수하지만 하드웨어 지원이 필요하다는 제약이 있다. 반면 STM은 순수하게 소프트웨어로 구현되어 범용성이 높으며, 실제로 Haskell이나 Clojure 같은 함수형 언어에서 핵심 동시성 메커니즘으로 채택되고 있다.

TL2: 실용적인 STM 구현

STM을 실제로 구현하는 방법은 여러 가지가 있지만, 그 중에서도 Transaction Locking II (TL2) 알고리즘은 성능과 구현 복잡도 사이의 균형을 잘 맞춘 대표적인 방법이다.

그런고로 이 글에서는 STM의 특징을 좀 더 알아보고, TL2의 구현에 대해 설명할 것이다.

STM의 특징

STM은 뮤텍스와 같은 비관적 락과는 성질이 다르다. STM은 중요한 특징 네 가지를 가지고 있는데

1. 트랜잭션 중의 코드가 2회 이상 실행될 가능성이 있다.

   • 경합이 발견된 후에는 트랜잭션을 재시도하므로 2회 이상 실행될 수 있다.

2. 트랜잭션 중에 부작용이 있는 코드는 실행하지 않는다.

   • 트랜잭션이 여러 번 발생하면 그에 따라 특정 코드가 여러 번 실행될 수 있어 의도치 않은 결과를 만들 수 있는데,

3. 데드락이 발생하지 않는다.

   • 경합이 감지되면 쓰고, 그렇지 않으면 재시도하기 때문에 식사하는 철학자와 같은 문제를 해결할 수 있다.

4. 여러 트랜잭션 처리를 합성할 수 있다.

   • STM에서는 임의의 트랜잭션 처리를 임의로 조합해 실행 가능하다.

   • 뮤텍스에서는 데드락, 락프리에서는 전용 데이터 구조 문제 때문에 임의로 조합하기 어렵지만, STM에서는 어떤 조작도 임의로 조합 가능하다.

TL2 알고리즘

TL2의 타입은 아래와 같다.

코드

러스트로 구현된 TL2 알고리즘은 다음과 같다.

tl2.rs:

// TL2.rs - TL2 (Transactional Locking 2) 알고리즘 구현
use std::cell::UnsafeCell;
use std::collections::HashMap;
use std::collections::HashSet;
use std::sync::atomic::{AtomicU64, Ordering, fence};

// ===== 상수 정의 =====
// 스트라이프 크기: 메모리를 8바이트 단위로 관리
const STRIPE_SIZE: usize = 8; 

// 전체 메모리 크기: 512바이트
const MEM_SIZE: usize = 512; 

// ===== 메모리 구조체 정의 =====
pub struct Memory {
    mem: Vec<u8>,             // 실제 데이터를 저장하는 메모리 영역
    lock_ver: Vec<AtomicU64>, // 각 스트라이프의 락과 버전을 저장 (최상위 비트: 락, 나머지: 버전)
    global_clock: AtomicU64,  // 전역 버전 클락 (모든 트랜잭션이 공유하는 논리적 시간)
    shift_size: u32,          // 주소를 스트라이프 인덱스로 변환하기 위한 시프트 크기
}

impl Memory {
    pub fn new() -> Self {
        // 메모리 영역을 0으로 초기화
        let mem = [0].repeat(MEM_SIZE);

        // 스트라이프 크기는 2의 거듭제곱이어야 함 (8 = 2^3)
        // trailing_zeros()는 2진수에서 끝에서부터 0의 개수를 반환 (8 = 1000₂ → 3)
        let shift = STRIPE_SIZE.trailing_zeros(); 

        // 각 스트라이프에 대한 락/버전 정보를 초기화
        // 스트라이프 개수 = MEM_SIZE / STRIPE_SIZE = 512 / 8 = 64개
        let mut lock_ver = Vec::new();
        for _ in 0..MEM_SIZE >> shift {  // 64개의 스트라이프
            lock_ver.push(AtomicU64::new(0));  // 초기값: 락 해제 상태, 버전 0
        }

        Memory {
            mem,
            lock_ver,
            global_clock: AtomicU64::new(0),  // 전역 클락을 0으로 초기화
            shift_size: shift,
        }
    }

    // 전역 버전 클락을 1 증가시키고 이전 값을 반환
    // AcqRel 순서를 사용하여 메모리 순서 보장
    fn inc_global_clock(&mut self) -> u64 {
        self.global_clock.fetch_add(1, Ordering::AcqRel)
    }

    // 지정된 주소의 현재 버전을 반환
    // 최상위 비트(락 비트)를 제거하고 순수 버전만 반환
    fn get_addr_ver(&self, addr: usize) -> u64 {
        let idx = addr >> self.shift_size;  // 주소를 스트라이프 인덱스로 변환
        let n = self.lock_ver[idx].load(Ordering::Relaxed);
        n & !(1 << 63)  // 최상위 비트를 0으로 마스킹하여 버전만 추출
    }

    // 지정된 주소가 락되어 있지 않고 버전이 rv 이하인지 확인
    // TL2의 핵심: 락 비트와 버전을 동시에 확인
    fn test_not_modify(&self, addr: usize, rv: u64) -> bool {
        let idx = addr >> self.shift_size;
        let n = self.lock_ver[idx].load(Ordering::Relaxed);
        // 락이 걸려있으면 최상위 비트가 1이므로 n > rv가 됨
        // 락이 없어도 버전이 rv보다 크면 n > rv가 됨
        n <= rv
    }

    // 지정된 주소의 락을 원자적으로 획득 시도
    // fetch_update를 사용하여 compare-and-swap 연산 수행
    fn lock_addr(&mut self, addr: usize) -> bool {
        let idx = addr >> self.shift_size;
        match self.lock_ver[idx].fetch_update(
            Ordering::Relaxed, // 쓰기 시의 메모리 순서
            Ordering::Relaxed, // 읽기 시의 메모리 순서
            |val| {
                // 현재 값의 최상위 비트(락 비트) 확인
                let lock_bit = val & (1 << 63);
                if lock_bit == 0 { 
                    // 락이 해제되어 있으면 락 비트를 설정
                    Some(val | (1 << 63)) 
                } else { 
                    // 이미 락이 걸려있으면 실패
                    None 
                }
            },
        ) {
            Ok(_) => true,   // 락 획득 성공
            Err(_) => false, // 락 획득 실패
        }
    }

    // 지정된 주소의 락을 해제
    // fetch_and를 사용하여 최상위 비트만 0으로 설정
    fn unlock_addr(&mut self, addr: usize) {
        let idx = addr >> self.shift_size;
        self.lock_ver[idx].fetch_and(!(1 << 63), Ordering::Relaxed);
    }
}

// ===== 읽기 전용 트랜잭션 구조체 =====
pub struct ReadTrans<'a> {
    read_ver: u64,   // 이 트랜잭션의 읽기 버전 (시작 시점의 전역 클락)
    is_abort: bool,  // 충돌 감지 시 true로 설정
    mem: &'a Memory, // 메모리에 대한 불변 참조
}

impl<'a> ReadTrans<'a> {
    fn new(mem: &'a Memory) -> Self {
        ReadTrans {
            is_abort: false,
            // 트랜잭션 시작 시점의 전역 클락을 읽어서 일관된 스냅샷 확보
            read_ver: mem.global_clock.load(Ordering::Acquire),
            mem,
        }
    }

    // 메모리에서 데이터 읽기 (낙관적 읽기)
    // Double-checked locking 패턴 사용
    pub fn load(&mut self, addr: usize) -> Option<[u8; STRIPE_SIZE]> {
        // 이미 충돌이 감지된 경우 즉시 중단
        if self.is_abort {
            return None;
        }

        // 주소가 스트라이프 경계에 정렬되어 있는지 확인
        assert_eq!(addr & (STRIPE_SIZE - 1), 0);

        // 첫 번째 검사: 메모리가 락되어 있지 않고 읽기 버전 이하인지 확인
        if !self.mem.test_not_modify(addr, self.read_ver) {
            self.is_abort = true;
            return None;
        }

        // 메모리 펜스: 위의 검사 후 실제 읽기 전에 순서 보장
        fence(Ordering::Acquire);

        // 실제 메모리 데이터 복사
        let mut mem = [0; STRIPE_SIZE];
        for (dst, src) in mem
            .iter_mut()
            .zip(self.mem.mem[addr..addr + STRIPE_SIZE].iter())
        {
            *dst = *src;
        }

        // 강한 메모리 펜스: 읽기 완료 후 두 번째 검사 전에 순서 보장
        fence(Ordering::SeqCst);

        // 두 번째 검사: 읽기 도중 다른 트랜잭션이 수정했는지 확인
        if !self.mem.test_not_modify(addr, self.read_ver) {
            self.is_abort = true;
            return None;
        }

        Some(mem)
    }
}

// ===== 쓰기 트랜잭션 구조체 =====
pub struct WriteTrans<'a> {
    read_ver: u64,                                // 읽기 버전 (트랜잭션 시작 시점)
    read_set: HashSet<usize>,                     // 읽은 주소들의 집합
    write_set: HashMap<usize, [u8; STRIPE_SIZE]>, // 쓸 주소와 값들의 맵
    locked: Vec<usize>,                           // 락을 획득한 주소들의 리스트
    is_abort: bool,                               // 충돌 감지 플래그
    mem: &'a mut Memory,                          // 메모리에 대한 가변 참조
}

// 트랜잭션이 소멸될 때 자동으로 모든 락 해제
impl<'a> Drop for WriteTrans<'a> {
    fn drop(&mut self) {
        // 획득한 모든 락을 해제하여 데드락 방지
        for addr in self.locked.iter() {
            self.mem.unlock_addr(*addr);
        }
    }
}

impl<'a> WriteTrans<'a> {
    fn new(mem: &'a mut Memory) -> Self {
        WriteTrans {
            read_set: HashSet::new(),
            write_set: HashMap::new(),
            locked: Vec::new(),
            is_abort: false,
            // 트랜잭션 시작 시점의 전역 클락 획득
            read_ver: mem.global_clock.load(Ordering::Acquire),
            mem,
        }
    }

    // 메모리에 쓰기 (지연된 쓰기 - write-set에 저장만)
    pub fn store(&mut self, addr: usize, val: [u8; STRIPE_SIZE]) {
        // 주소 정렬 확인
        assert_eq!(addr & (STRIPE_SIZE - 1), 0);
        // write-set에 추가 (실제 메모리 쓰기는 커밋 시에)
        self.write_set.insert(addr, val);
    }

    // 메모리에서 읽기 (write-set 우선 확인)
    pub fn load(&mut self, addr: usize) -> Option<[u8; STRIPE_SIZE]> {
        // 충돌 감지 시 즉시 중단
        if self.is_abort {
            return None;
        }

        // 주소 정렬 확인
        assert_eq!(addr & (STRIPE_SIZE - 1), 0);

        // read-set에 주소 추가 (커밋 시 검증용)
        self.read_set.insert(addr);

        // write-set에 있는 경우 해당 값을 반환 (자신이 쓴 값 읽기)
        if let Some(m) = self.write_set.get(&addr) {
            return Some(*m);
        }

        // write-set에 없는 경우 실제 메모리에서 읽기 (ReadTrans와 동일한 로직)
        if !self.mem.test_not_modify(addr, self.read_ver) {
            self.is_abort = true;
            return None;
        }

        fence(Ordering::Acquire);

        let mut mem = [0; STRIPE_SIZE];
        for (dst, src) in mem
            .iter_mut()
            .zip(self.mem.mem[addr..addr + STRIPE_SIZE].iter())
        {
            *dst = *src;
        }

        fence(Ordering::SeqCst);

        if !self.mem.test_not_modify(addr, self.read_ver) {
            self.is_abort = true;
            return None;
        }

        Some(mem)
    }

    // write-set의 모든 주소에 대해 락 획득 시도
    // 모든 락을 획득할 수 있어야만 true 반환 (all-or-nothing)
    fn lock_write_set(&mut self) -> bool {
        for (addr, _) in self.write_set.iter() {
            if self.mem.lock_addr(*addr) {
                // 락 획득 성공 시 locked 리스트에 추가
                self.locked.push(*addr);
            } else {
                // 하나라도 락 획득 실패 시 즉시 false 반환
                // Drop trait에 의해 기존 락들은 자동 해제됨
                return false;
            }
        }
        true
    }

    // read-set의 모든 주소에 대해 검증 수행
    // 읽었던 데이터가 여전히 유효한지 확인
    fn validate_read_set(&self) -> bool {
        for addr in self.read_set.iter() {
            if self.write_set.contains_key(addr) {
                // write-set에 있는 주소는 자신이 락을 가지고 있음
                // 버전만 검사 (다른 트랜잭션이 중간에 수정했는지)
                let ver = self.mem.get_addr_ver(*addr);
                if ver > self.read_ver {
                    return false;
                }
            } else {
                // write-set에 없는 주소는 락과 버전 모두 검사
                if !self.mem.test_not_modify(*addr, self.read_ver) {
                    return false;
                }
            }
        }
        true
    }

    // 트랜잭션 커밋: 모든 쓰기를 실제 메모리에 반영
    fn commit(&mut self, ver: u64) {
        // 1. write-set의 모든 데이터를 실제 메모리에 복사
        for (addr, val) in self.write_set.iter() {
            let addr = *addr as usize;
            for (dst, src) in self.mem.mem[addr..addr + STRIPE_SIZE].iter_mut().zip(val) {
                *dst = *src;
            }
        }

        // 2. 메모리 펜스로 쓰기 완료 보장
        fence(Ordering::Release);

        // 3. 모든 주소의 락 해제 및 새 버전으로 업데이트
        for (addr, _) in self.write_set.iter() {
            let idx = addr >> self.mem.shift_size;
            // 락 비트를 0으로, 버전을 새 버전으로 설정
            self.mem.lock_ver[idx].store(ver, Ordering::Relaxed);
        }

        // 4. locked 리스트 초기화 (Drop에서 중복 해제 방지)
        self.locked.clear();
    }
}

// ===== STM 결과 타입 =====
pub enum STMResult<T> {
    Ok(T),    // 성공
    Retry,    // 재시도 필요 (충돌 감지)
    Abort,    // 중단 (취소)
}

// ===== 메인 STM 구조체 =====
pub struct STM {
    mem: UnsafeCell<Memory>, // 내부 가변성을 위한 UnsafeCell 사용
}

// 스레드 간 공유를 위한 안전성 마커
unsafe impl Sync for STM {}
unsafe impl Send for STM {}

impl STM {
    pub fn new() -> Self {
        STM {
            mem: UnsafeCell::new(Memory::new()),
        }
    }

    // 읽기 전용 트랜잭션 실행
    pub fn read_transaction<F, R>(&self, f: F) -> Option<R>
    where
        F: Fn(&mut ReadTrans) -> STMResult<R>,
    {
        loop {
            // 1. 새로운 읽기 트랜잭션 생성 (현재 전역 클락으로 스냅샷)
            let mut tr = ReadTrans::new(unsafe { &*self.mem.get() });

            // 2. 사용자 함수 실행 (투기적 실행)
            match f(&mut tr) {
                STMResult::Abort => return None,
                STMResult::Retry => {
                    if tr.is_abort {
                        continue; // 충돌 감지 시 재시도
                    }
                    return None; // 사용자가 명시적으로 재시도 요청
                }
                STMResult::Ok(val) => {
                    if tr.is_abort {
                        continue; // 충돌 감지 시 재시도
                    } else {
                        return Some(val); // 성공적으로 완료
                    }
                }
            }
        }
    }

    // 읽기-쓰기 트랜잭션 실행 (TL2의 핵심 로직)
    pub fn write_transaction<F, R>(&self, f: F) -> Option<R>
    where
        F: Fn(&mut WriteTrans) -> STMResult<R>,
    {
        loop {
            // 1. 새로운 쓰기 트랜잭션 생성
            let mut tr = WriteTrans::new(unsafe { &mut *self.mem.get() });

            // 2. 사용자 함수 실행 (투기적 실행 단계)
            let result;
            match f(&mut tr) {
                STMResult::Abort => return None,
                STMResult::Retry => {
                    if tr.is_abort {
                        continue; // 충돌 감지 시 재시도
                    }
                    return None;
                }
                STMResult::Ok(val) => {
                    if tr.is_abort {
                        continue; // 투기적 실행 중 충돌 감지
                    }
                    result = val;
                }
            }

            // 3. write-set의 모든 주소에 대해 락 획득 시도
            if !tr.lock_write_set() {
                continue; // 락 획득 실패 시 재시도
            }

            // 4. 전역 클락 증가 및 새 버전 번호 할당
            let ver = 1 + tr.mem.inc_global_clock();

            // 5. read-set 검증
            // 조건1: read_ver + 1 == ver (다른 트랜잭션이 커밋하지 않음)
            // 조건2: validate_read_set() 성공 (읽었던 데이터가 여전히 유효)
            if tr.read_ver + 1 != ver && !tr.validate_read_set() {
                continue; // 검증 실패 시 재시도
            }

            // 6. 커밋 수행 및 락 해제
            tr.commit(ver);

            return Some(result); // 성공적으로 완료
        }
    }
}

// ===== 편의성을 위한 매크로 =====

// 메모리 읽기용 매크로 - 실패 시 자동으로 Retry 반환
#[macro_export]
macro_rules! load {
    ($t:ident, $a:expr) => {
        if let Some(v) = ($t).load($a) {
            v
        } else {
            return tl2::STMResult::Retry;
        }
    };
}

// 메모리 쓰기용 매크로 - 단순히 store 호출
#[macro_export]
macro_rules! store {
    ($t:ident, $a:expr, $v:expr) => {
        $t.store($a, $v)
    };
}

main.rs:

// main.rs - TL2 STM을 사용한 식사하는 철학자 문제 해결
use std::sync::Arc;
use std::{thread, time};
mod tl2;

// ===== 상수 정의 =====
const NUM_PHILOSOPHERS: usize = 8; // 철학자 및 포크의 개수

// ===== 철학자 스레드 함수 =====
fn philosopher(stm: Arc<tl2::STM>, n: usize) {
    // 각 철학자는 고유한 번호 n을 가지며, 왼쪽과 오른쪽 포크를 사용

    // 포크의 메모리 주소 계산
    // 각 포크는 8바이트씩 할당되므로 8 * n 주소에 위치
    let left = 8 * n; // 철학자 n의 왼쪽 포크 주소
    let right = 8 * ((n + 1) % NUM_PHILOSOPHERS); // 오른쪽 포크 주소 (원형 배치)

    // 각 철학자는 500,000번 반복하여 식사 시도
    for _ in 0..500000 {
        // ===== 포크 획득 단계 =====
        // 양쪽 포크를 모두 들 수 있을 때까지 반복 시도
        while !stm
            .write_transaction(|tr| {
                // 트랜잭션 내에서 양쪽 포크의 상태를 확인
                let mut f1 = load!(tr, left); // 왼쪽 포크 읽기 (매크로 사용)
                let mut f2 = load!(tr, right); // 오른쪽 포크 읽기

                // 포크 상태 확인: 0 = 사용 가능, 1 = 사용 중
                if f1[0] == 0 && f2[0] == 0 {
                    // 양쪽 포크가 모두 비어있는 경우

                    // 포크를 사용 중으로 표시 (1로 설정)
                    f1[0] = 1;
                    f2[0] = 1;

                    // 메모리에 변경사항 저장 (write-set에 추가)
                    store!(tr, left, f1);
                    store!(tr, right, f2);

                    // 포크 획득 성공을 반환
                    tl2::STMResult::Ok(true)
                } else {
                    // 하나라도 사용 중인 경우 획득 실패
                    tl2::STMResult::Ok(false)
                }
            })
            .unwrap()
        // Option을 언래핑 (None은 트랜잭션 중단을 의미)
        {
            // while 루프: false가 반환되면 계속 시도
            // 다른 철학자가 포크를 사용 중이면 대기
        }

        // ===== 식사 시뮬레이션 =====
        // 실제로는 여기서 철학자가 생각하고 식사하는 시간을 시뮬레이션할 수 있음
        // 현재 구현에서는 즉시 포크를 내려놓음

        // ===== 포크 반납 단계 =====
        // 식사 완료 후 양쪽 포크를 모두 내려놓음
        stm.write_transaction(|tr| {
            // 현재 포크 상태를 읽어옴
            let mut f1 = load!(tr, left);
            let mut f2 = load!(tr, right);

            // 포크를 사용 가능 상태로 변경 (0으로 설정)
            f1[0] = 0;
            f2[0] = 0;

            // 메모리에 변경사항 저장
            store!(tr, left, f1);
            store!(tr, right, f2);

            // 반환값은 사용하지 않으므로 ()
            tl2::STMResult::Ok(())
        });

        // 포크 반납은 항상 성공해야 하므로 unwrap() 사용
        // (철학자는 자신이 가진 포크만 내려놓으므로 충돌 없음)
    }
}

// ===== 관측자 스레드 함수 =====
// 시스템의 일관성을 지속적으로 모니터링
fn observer(stm: Arc<tl2::STM>) {
    // 10,000번 반복하여 상태 관측
    for _ in 0..10000 {
        // ===== 현재 포크 상태 스냅샷 획득 =====
        // 읽기 전용 트랜잭션으로 모든 포크의 일관된 상태를 읽음
        let chopsticks = stm
            .read_transaction(|tr| {
                let mut v = [0; NUM_PHILOSOPHERS];

                // 모든 포크의 상태를 순차적으로 읽기
                for i in 0..NUM_PHILOSOPHERS {
                    v[i] = load!(tr, 8 * i)[0]; // i번째 포크의 상태
                }

                tl2::STMResult::Ok(v)
            })
            .unwrap(); // 읽기 트랜잭션은 항상 성공해야 함

        // 현재 포크 상태를 출력 (디버깅 및 모니터링용)
        println!("{:?}", chopsticks);

        // ===== 일관성 검사 =====
        // 불변식: 사용 중인 포크의 총 개수는 항상 짝수여야 함
        // 이유: 각 철학자는 항상 2개의 포크를 동시에 사용하므로
        let mut n = 0;
        for c in &chopsticks {
            if *c == 1 {
                // 사용 중인 포크 개수 세기
                n += 1;
            }
        }

        // 홀수 개의 포크가 사용 중이면 일관성 위반
        if n & 1 != 0 {
            // n % 2 != 0과 동일
            panic!("inconsistent: {} forks in use", n);
        }

        // 100마이크로초 대기 (관측 주기 조절)
        let us = time::Duration::from_micros(100);
        thread::sleep(us);
    }
}

// ===== 메인 함수 =====
fn main() {
    // STM 인스턴스 생성 (Arc로 래핑하여 스레드 간 공유)
    let stm = Arc::new(tl2::STM::new());
    let mut v = Vec::new();

    println!("Starting {} philosophers...", NUM_PHILOSOPHERS);

    // ===== 철학자 스레드들 생성 및 시작 =====
    for i in 0..NUM_PHILOSOPHERS {
        let s = stm.clone(); // STM 참조 복제 (Arc의 참조 카운트 증가)

        // 각 철학자를 별도 스레드에서 실행
        let th = std::thread::spawn(move || philosopher(s, i));
        v.push(th); // 스레드 핸들 저장 (나중에 join하기 위해)
    }

    // ===== 관측자 스레드 생성 및 시작 =====
    let obs_stm = stm.clone();
    let obs = std::thread::spawn(move || observer(obs_stm));

    println!("All threads started. Monitoring for inconsistencies...");

    // ===== 모든 철학자 스레드 완료 대기 =====
    for th in v {
        th.join().unwrap(); // 각 철학자 스레드가 완료될 때까지 대기
    }

    println!("All philosophers finished eating.");

    // ===== 관측자 스레드 완료 대기 =====
    obs.join().unwrap();

    println!("Program completed successfully - no inconsistencies detected!");
}

Memory

Memory 타입에는 트랜잭션을 수행할 기본 함수를 정의한다. TL2는 512 바이트 메모리를 스트라이프(8바이트 구역) 라는 단위로 64개로 나누어 관리한다.

여기서 각 스트라이프의 락/버전 정보느 64비트로 구성되는데 최상위 비트에 락 상태를 기입하고 나머지 63비트에 버전 번호를 기입한다. 이 구조로 인해 단일 아토믹 연산으로 락 상태와 버전을 동시에 확인할 수 있다.

fn test_not_modify(&self, addr: usize, read_version: u64) -> bool {
    let current_value = self.lock_ver[addr >> 3].load(Ordering::Relaxed);
    current_value <= read_version
}

위의 함수와 같이 락이 걸려있으면 최상위 비트 값이 1이 되어 매우 커지므로 current_value > read_version이 되어 수정이 감지된다.

ReadTrans

읽기는 다음 코드와 같이 작동한다.

pub fn load(&mut self, addr: usize) -> Option<[u8; STRIPE_SIZE]> {
    // 1. 첫 번째 일관성 검사
    if !self.mem.test_not_modify(addr, self.read_ver) {
        self.is_abort = true;
        return None;
    }

    fence(Ordering::Acquire);

    // 2. 실제 메모리 읽기
    let mut data = [0; STRIPE_SIZE];
    data.copy_from_slice(&self.mem.mem[addr..addr + STRIPE_SIZE]);

    fence(Ordering::SeqCst);

    // 3. 두 번째 일관성 검사
    if !self.mem.test_not_modify(addr, self.read_ver) {
        self.is_abort = true;
        return None;
    }

    Some(data)
}

1. 첫 번쨰 검사: 읽기 전에 메모리가 락X, 버전이 read_ver 이하인지 확인

2. 메모리 읽기: 실제 데이터를 복사, 메모리 펜스로 순서 보장

3. 두 번째 검사: 읽기 과정에서 다른 트랜잭션이 수정되었는지 확인 이 방식으로 락 없이도 일관된 읽기를 보장한. 다른 트랜잭션이 중간에 수정했다면 두 번째 검사에서 감지되어 재시도한다.

WriteTrans

WriteTrans는 읽기-쓰기 트랜잭션을 처리하는 가장 복잡한 구조체다. 지연된 쓰기와 2단계 커밋 프로토콜을 구현한다.

지연된 쓰기

pub fn store(&mut self, addr: usize, val: [u8; STRIPE_SIZE]) {
    self.write_set.insert(addr, val);
}

store 연산은 실제 메모리에 즉시 쓰지 않고 write_set에만 저장한다. 실제 쓰기는 트랜잭션이 성공적으로 커밋될 때까지 지연된다. 이렇게 하면 중간에 충돌이 발생해도 실제 메모리는 변경되지 않아 롤백이 간단하다.

Read-Your-Write 의미

pub fn load(&mut self, addr: usize) -> Option<[u8; STRIPE_SIZE]> {
    self.read_set.insert(addr);

    // write-set에 있으면 해당 값 반환
    if let Some(data) = self.write_set.get(&addr) {
        return Some(*data);
    }

    // 없으면 실제 메모리에서 읽기 (ReadTrans와 동일)
    // ...
}

트랜잭션 내에서 자신이 쓴 값을 읽을 때는 write_set의 값을 반환한다. 이를 통해 트랜잭션 내에서 일관된 메모리 뷰를 제공한다. 동시에 읽은 주소는 read_set에 기록하여 나중에 검증할 때 사용한다.

STM

STM 구조체는 전체 트랜잭션 시스템의 진입점이다. TL2의 핵심인 5단계 커밋 프로토콜을 구현한다.

5단계 커밋 프로토콜

pub fn write_transaction<F, R>(&self, f: F) -> Option<R> {
    loop {
        // 1단계: 투기적 실행
        let mut tr = WriteTrans::new(unsafe { &mut *self.mem.get() });
        let result = match f(&mut tr) {
            STMResult::Ok(val) if !tr.is_abort => val,
            _ => continue,
        };

        // 2단계: 락 획득
        if !tr.lock_write_set() { continue; }

        // 3단계: 전역 클락 증가
        let ver = 1 + tr.mem.inc_global_clock();

        // 4단계: read-set 검증
        if tr.read_ver + 1 != ver && !tr.validate_read_set() {
            continue;
        }

        // 5단계: 커밋
        tr.commit(ver);
        return Some(result);
    }
}

1단계 - 투기적 실행: 사용자 코드를 실행하여 read_set과 write_set을 구성한다. 실제 메모리는 수정하지 않고 시뮬레이션만 한다.

2단계 - 락 획득: write_set의 모든 주소에 대해 락을 획득한다. All-or-Nothing 원칙으로 하나라도 실패하면 모든 락을 해제하고 재시도한다.

fn lock_write_set(&mut self) -> bool {
    for (addr, _) in self.write_set.iter() {
        if self.mem.lock_addr(*addr) {
            self.locked.push(*addr);
        } else {
            return false;  // 하나라도 실패하면 전체 실패
        }
    }
    true
}

3단계 - 전역 클락 증가: 전역 클락을 원자적으로 증가시켜 새로운 버전 번호를 할당한다. 이 버전 번호는 이 트랜잭션의 커밋 시간을 나타낸다.

4단계 - read-set 검증: 가장 중요한 최적화가 포함된 단계다.

if tr.read_ver + 1 != ver && !tr.validate_read_set()

이 조건의 핵심은 빠른 경로(Fast Path)다. 만약 tr.read_ver + 1 == ver라면 이 트랜잭션이 시작된 이후 다른 트랜잭션이 커밋하지 않았다는 의미이므로, 복잡한 read_set 검증을 생략할 수 있다.

그렇지 않다면 세밀한 검증을 수행한다:

fn validate_read_set(&self) -> bool {
    for addr in self.read_set.iter() {
        if self.write_set.contains_key(addr) {
            // 자신이 락을 가진 주소: 버전만 확인
            let current_ver = self.mem.get_addr_ver(*addr);
            if current_ver > self.read_ver { return false; }
        } else {
            // 다른 주소: 락과 버전 모두 확인
            if !self.mem.test_not_modify(*addr, self.read_ver) {
                return false;
            }
        }
    }
    true
}

자신이 락을 가진 주소와 그렇지 않은 주소를 다르게 처리한다. 자신이 락을 가진 경우 다른 트랜잭션이 수정할 수 없으므로 버전만 확인하면 된다.

5단계 - 커밋: 실제 메모리에 쓰기를 수행하고 락을 해제한다.

fn commit(&mut self, ver: u64) {
    // 1. 실제 메모리에 쓰기
    for (addr, val) in self.write_set.iter() {
        self.mem.mem[*addr..*addr + STRIPE_SIZE].copy_from_slice(val);
    }

    fence(Ordering::Release);

    // 2. 락 해제 및 버전 업데이트
    for (addr, _) in self.write_set.iter() {
        let idx = addr >> self.mem.shift_size;
        self.mem.lock_ver[idx].store(ver, Ordering::Relaxed);
    }
}

메모리 쓰기 완료 후 락 비트를 0으로, 버전을 새 버전으로 원자적으로 설정한다.

TL2의 핵심 특성

데드락 방지

TL2는 구조적으로 데드락이 불가능하다. 전통적인 락에서는 스레드 A가 락 X를 가지고 락 Y를 기다리고, 스레드 B가 락 Y를 가지고 락 X를 기다리는 상황이 발생할 수 있다.

하지만 TL2에서는 All-or-Nothing 락 획득 방식으로 부분적 락 획득 상태가 존재하지 않는다. 필요한 모든 락을 획득할 수 없으면 기존 락들을 모두 해제하고 처음부터 재시도한다.

ABA 문제 해결

단순한 락 확인만으로는 ABA 문제가 발생할 수 있다. 값이 A에서 B로 변경된 후 다시 A로 돌아왔을 때, 값만 보면 변화가 없는 것처럼 보인다. TL2는 버전 번호를 통해 이를 해결한다. 값이 같아도 버전이 증가했다면 변경이 감지된다.

높은 동시성

읽기 트랜잭션은 락을 사용하지 않아 여러 읽기가 동시에 실행될 수 있다. 쓰기 트랜잭션도 커밋 단계에서만 락을 보유하므로 락 경합이 최소화된다.

식사하는 철학자 문제에서의 동작

철학자 문제에서 TL2의 동작을 구체적으로 보면, 각 철학자가 두 포크를 동시에 잡으려 할 때:

1. 투기적 실행: 두 포크 상태를 확인하고 둘 다 비어있으면 사용 중으로 설정하는 계획을 세운다.

2. 락 획득: 두 포크에 대한 편집권을 얻으려 시도한다. 하나라도 실패하면 포기하고 재시도한다.

3. 검증: 포크 상태를 읽었을 때와 지금이 일치하는지 확인한다.

4. 커밋: 성공하면 실제로 포크 상태를 변경하고 편집권을 반납한다.

이 과정을 통해 데드락 없이 안전하게 동시성 문제를 해결할 수 있다.

여기서는 공평한 배타 제어에 대해 설명한다.

먼저 컨텐션(contention) 이라는 개념을 이해할 필요가 있다. 컨텐션이란 여러 스레드가 동시에 같은 락을 획득하려고 경쟁하는 상황을 말한다. 컨텐션이 높을수록 스레드들이 락을 기다리는 시간이 길어지고 성능이 저하된다.

이러한 컨텐션 상황은 시스템 아키텍처에 따라 더욱 복잡해질 수 있다. 특히 비균일 메모리 접근(Non-Uniform Memory Access, NUMA) 와 같은 환경에서는 메모리와 CPU의 위치에 따라 메모리에 대한 접근 속도가 다르다. 예를 들어, CPU가 자신과 가까운 메모리에 접근할 때는 빠르지만, 원격 노드의 메모리에 접근할 때는 상대적으로 느리다.

이런 접근 속도의 차이는 락을 획득하는 난이도에도 영향을 미친다. 락이 저장된 메모리 위치와 가까운 CPU에서 실행되는 스레드는 락을 더 빨리 획득할 수 있는 반면, 원격 노드의 스레드는 상대적으로 불리한 위치에 있게 된다. 결과적으로 특정 스레드가 락을 반복적으로 획득하는 편향이 발생할 수 있다.

이러한 문제를 해결하기 위해 공평한 락(fair lock) 이 필요하다. 컨텐션이 높은 환경에서 공평한 락은 모든 스레드가 순서대로 락을 획득할 수 있도록 보장함으로써, NUMA로 인한 불균형을 완화하고 시스템의 예측 가능성을 높이며 기아 현상을 방지하는 데 도움이 된다.

약한 공평성을 보장하는 락

약한 공평성을 보장하는 배타 제어 알고리즘은 다음과 같이 동작한다.

1. 락을 우선적으로 획득할 수 있는 스레드가 설정됨

2. 우선 스레드는 순서대로 바뀜

예를 들면 스레드 1이 우선 스레드로 설정되면 스레드 1은 반드시 락을 획득한다. 락이 해제되면 다음 스레드가 우선 스레드가 되도록 설정된다. 다음 스레드가 스레드 2라고 하자. 그런데 여기서 스레드 2가 락 획득을 시도하지 않으면 어떻게 될까? 나머지 스레드들이 락 획득을 경합하고 다음 스레드 3을 우선 스레드로 설정한다.

약한 공평성을 보장하는 알고리즘을 코드로 구현하면 다음과 같다.

use std::cell::UnsafeCell;
// use std::ops::{Deref, DerefMut};
use std::sync::atomic::{AtomicBool, AtomicUsize, Ordering, fence};

// 스레드 최대 수를 사전에 결정
pub const NUM_LOCK: usize = 8;

//NUM_LOCK의 여분을 구하는 비트마스크
const MASK: usize = NUM_LOCK - 1;

// fair lock 구조체
pub struct FairLock<T> {
    // n번째 스레드가 락을 획득하려고 시행중인지 나타내는 벡터
    waiting: Vec<AtomicBool>,
    // 스핀락을 위한 변수
    lock: AtomicBool,
    // 락 획득을 우선해야 하는 스레드를 나타내는 변수
    turn: AtomicUsize,
    // 보호 대상 데이터
    data: UnsafeCell<T>,
}

// 락 자동 해제 및 보호 대상 데이터로의 접근을 수행하기 위한 타입
pub struct FairLockGuard<'a, T> {
    fair_lock: &'a FairLock<T>,
    idx: usize,
}

그리고 다음 코드로 초기화와 락을 수행할 수 있다.

impl<T> FairLock<T> {
    pub fn new(v: T) -> Self {
        let mut vec = Vec::new();
        for _ in 0..NUM_LOCK {
            vec.push(AtomicBool::new(false));
        }
        FairLock {
            waiting: vec,
            lock: AtomicBool::new(false),
            turn: AtomicUsize::new(0),
            data: UnsafeCell::new(v),
        }
    }

    // 락 함수
    pub fn lock(&self, idx: usize) -> FairLockGuard<T> {
        // idx가 최대 수 미만인지
        assert!(idx < NUM_LOCK);

        // 자신의 스레드를 락 획득 시행 중으로 설정
        self.waiting[idx].store(true, Ordering::Relaxed);
        loop {
            // 다른 스레드가 false를 설정한 경우면 락 획득
            if !self.waiting[idx].load(Ordering::Relaxed) {
                break;
            }
            // 공유 변수를 이용해 락 획득 테스트
            if !self.lock.load(Ordering::Relaxed) {
                if let Ok(_) = self.lock.compare_exchange_weak(
                    false,
                    true,
                    Ordering::Relaxed,
                    Ordering::Relaxed,
                ) {
                    break; // 락 획득 성공
                }
            }
        }
        fence(Ordering::Acquire);

        FairLockGuard {
            fair_lock: self,
            idx,
        }
    }

다음은 언락을 구현한 코드이다.

impl<'a, T> Drop for FairLockGuard<'a, T> {
    fn drop(&mut self) {
        let fl = self.fair_lock; // fair_lock 참조 획득
        // 자신의 스레드를 락 획득 시도 중이 아닌 상태로 설정
        fl.waiting[self.idx].store(false, Ordering::Relaxed);

        // 현재 우선 스레드가 자신이면 다음 스레드로 넘김
        let turn = fl.turn.load(Ordering::Relaxed);
        let next_turn = if turn == self.idx {
            (turn + 1) & MASK // 다음 스레드로 넘김
        } else {
            turn // 현재 스레드가 아니면 그대로 유지
        };

        if fl.waiting[next].load(Ordering::Relaxed) {
            // 다음 우선 스레드가 락 획득 중이면 전달
            fl.turn.store(next_turn, Ordering::Relaxed);
            fl.waiting[next].store(true, Ordering::Release);
        } else {
            // 다음 우선 스레드가 락 획득 중이 아니면
            // 그 다음 스레드를 우선 스레드로 설정하고 락 해제
            fl.turn.store((next + 1) & MASK, Ordering::Relaxed);
            fl.lock.store(false, Ordering::Release);
        }
    }
}

까지가 락 획득 및 해제 알고리즘이다.

다음은 FairLock과 FairLockGaurd 타입에서 구현해야 할 트레이트다.

// FairLock 타입은 스레드 사이에서 공유 가능하도록 설정
unsafe impl<T> Sync for FairLock<T> {}
unsafe impl<T> Send for FairLock<T> {}

// 보호 대상 데이터의 이뮤터블 참조 제외
impl<'a, T> Deref for FairLockGuard<'a, T> {
    type Target = T;

    fn deref(&self) -> &Self::Target {
        unsafe { &*self.fair_lock.data.get() }
    }
}

// 보호 대상 데이터의 뮤터블 참조 제외
impl<'a, T> DerefMut for FairLockGuard<'a, T> {
    fn deref_mut(&mut self) -> &mut Self::Target {
        unsafe { &mut *self.fair_lock.data.get() }
    }
}

Sync를 통해 스레드 사이에서 데이터를 공유할 수 있게 되었고, Send를 통해 스레드에서 소유권을 송수신할 수 있게 되었다.

공평한 락을 이용하는 예는 다음과 같다.

const NUM_LOOP: usize = 1000;
const NUM_THREADS: usize = 4;

fn main() {
    let lock = Arc::new(FairLock::new(0));
    let mut v = Vec::new();

    for i in 0..NUM_THREADS {
        let lock0 = lock.clone();
        let t = std::thread::spawn(move || {
            for _ in 0..NUM_LOOP {
                // * -> _, NUM*LOOP -> NUM_LOOP
                // 스레드 번호를 전달
                let mut data = lock0.lock(i);
                *data += 1;
            }
        });
        v.push(t);
    }

    for t in v {
        t.join().unwrap();
    }

    println!(
        "Count = {} (expected = {})",
        *lock.lock(0), // FairLockGuard를 사용하여 락을 획득하고 데이터에 접근
        NUM_THREADS * NUM_LOOP
    );
}

티켓락

약한 공평성을 보장하는 락은 유한 횟수 안에서 반드시 락을 획득한다. 그런데 반드시 락을 획득하는 것은 아니어도 경합을 줄이는 알고리즘도 존재하는데 티켓락도 그 중 하나이다.

티켓락의 구현은 다음과 같다.

use std::cell::UnsafeCell;
use std::ops::{Deref, DerefMut};
use std::sync::atomic::{AtomicUsize, Ordering, fence};

// 티켓락 타입
pub struct TicketLock<T> {
    ticket: AtomicUsize, // 티켓
    turn: AtomicUsize,   // 실행 가능한 티켓
    data: UnsafeCell<T>,
}

// 락 해제, 보호 대상 데이터 접근
pub struct TicketLockGaurd<'a, T> {
    lock: &'a TicketLock<T>,
}

impl<T> TicketLock<T> {
    pub fn new(v: T) -> Self {
        TicketLock {
            ticket: AtomicUsize::new(0),
            turn: AtomicUsize::new(0),
            data: UnsafeCell::new(v),
        }
    }
    pub fn lock(&self) -> TicketLockGaurd<T> {
        // 티켓 획득
        let t = self.ticket.fetch_add(1, Ordering::SeqCst);
        // 소유권 티켓의 순서가 될 때까지 스핀
        while self.turn.load(Ordering::Relaxed) != t {}
        fence(Ordering::Acquire);
        TicketLockGaurd { lock: self }
    }
}

// 락 획득 후 자동으로 해제된다.
impl<'a, T> Drop for TicketLockGuard<'a, T> {
    fn drop(&mut self) {
        // 다음 티켓 실행 가능하도록 설정
        self.ticket_lock.turn.fetch_add(1, Ordering::Release);
    }
}

정리하자면 티켓락은 ticket과 turn이라는 2개 공유 변수가 있는데, ticket은 다음 티켓의 번호를 기억하는 변수이고, turn은 현재 실행이 허가된 티켓 번호다.

구현된 티켓 락의 함수에서, ticket획득 시 스핀을 수행하지 않는 것을 볼 수 있다. 이것이 컨텐션을 줄이는 역할을 한다.

MCS 락

티켓락에서는 아토믹 명령으로 접근하는 변수와 스핀 도중 접근하는 변수가 같았다. 그런데 메모리에 아토믹하게 접근하면 해당 메모리의 CPU 캐시가 배타적으로 설정되므로 대기 스레드의 해당 메모리를 읽을 떄 오버헤드가 발생할 가능성이 있다.

MCS락에서는 CAS 명령으로 큐의 가장 마지막에 스레드용 노드를 추가하고 스핀으로 감시할 변수는 별도로 준비한다. 즉, CAS에서 접근하는 변수는 아토믹하게 업데이트하지만 스핀으로 접근하는 변수는 일반적인 메모리 접근 명령을 이용한다.

CAS가 MCS에서 갖는 의미

MCS락에서 CAS는 두 가지 중요한 역할을 한다.

1. swap 연산: self.last.swap(ptr, Ordering::Relaxed)를 통해 자신을 큐의 마지막에 아토믹하게 추가한다. 이때 이전 마지막 노드의 포인터를 받아온다.

2. compare_exchange 연산: 락을 해제할 때 self.mcs_lock.last.compare_exchange(...)를 사용한다. 이는 "현재 자신이 마지막 노드인가?"를 확인하고, 맞다면 큐를 비우는 작업을 아토믹하게 수행한다.

핵심은 이런 CAS 연산은 큐 구조를 변경할 때만 사용하고, 각 스레드가 대기할 때는 자신의 locked 변수만 감시한다는 점이다. 이렇게 해서 캐시 경합을 최소화한다.

구현하자면 다음과 같은데

mcs.rs:

use std::cell::UnsafeCell;
use std::ops::{Deref, DerefMut};
use std::ptr::null_mut;
use std::sync::atomic::{AtomicBool, AtomicPtr, Ordering, fence};

pub struct MCSLock<T> {
    // ❶
    last: AtomicPtr<MCSNode<T>>, // 큐의 맨 마지막
    data: UnsafeCell<T>,         // 보호 대상 데이터
}

pub struct MCSNode<T> {
    // ❷
    next: AtomicPtr<MCSNode<T>>, // 다음 노드
    locked: AtomicBool,          // true이면 록 획득 중
}

pub struct MCSLockGuard<'a, T> {
    node: &'a mut MCSNode<T>, // 자신의 스레드 노드
    mcs_lock: &'a MCSLock<T>, // 큐의 가장 마지막과 보호 대상 데이터로의 참조
}

// 스레드끼리의 데이터 공유, 및 채널을 이용한 송수신 가능 설정
unsafe impl<T> Sync for MCSLock<T> {}
unsafe impl<T> Send for MCSLock<T> {}

impl<T> MCSNode<T> {
    pub fn new() -> Self {
        MCSNode {
            // MCSNodeの初期化
            next: AtomicPtr::new(null_mut()),
            locked: AtomicBool::new(false),
        }
    }
}

// 보호 대상 데이터의 이뮤터블한 참조 제외
impl<'a, T> Deref for MCSLockGuard<'a, T> {
    type Target = T;

    fn deref(&self) -> &Self::Target {
        unsafe { &*self.mcs_lock.data.get() }
    }
}

// 보호 대상 데이터의 뮤터블한 참조 제외
impl<'a, T> DerefMut for MCSLockGuard<'a, T> {
    fn deref_mut(&mut self) -> &mut Self::Target {
        unsafe { &mut *self.mcs_lock.data.get() }
    }
}

impl<T> MCSLock<T> {
    pub fn new(v: T) -> Self {
        MCSLock {
            last: AtomicPtr::new(null_mut()),
            data: UnsafeCell::new(v),
        }
    }

    pub fn lock<'a>(&'a self, node: &'a mut MCSNode<T>) -> MCSLockGuard<T> {
        // 자기 스레드용 노드를 초기화 ❶
        node.next = AtomicPtr::new(null_mut());
        node.locked = AtomicBool::new(false);

        let guard = MCSLockGuard {
            node,
            mcs_lock: self,
        };

        // 자신을 큐의 맨 마지막으로 한다 ❷
        let ptr = guard.node as *mut MCSNode<T>;
        let prev = self.last.swap(ptr, Ordering::Relaxed);

        // 맨 마지막이 null이면 나무도 록을 획득하려 하지 않는 것이므로 록을 획득
        // null이 아닌 경우에는 자신을 큐의 맨 끝에 추가
        if prev != null_mut() {
            // ❸
            // 록 획득 중이라고 설정
            guard.node.locked.store(true, Ordering::Relaxed); // ❹

            // 자신을 큐의 맨 끝에 추가 ❺
            let prev = unsafe { &*prev };
            prev.next.store(ptr, Ordering::Relaxed);

            // 다른 스레드로부터 false로 설정될 때까지 스핀 >❻
            while guard.node.locked.load(Ordering::Relaxed) {}
        }

        fence(Ordering::Acquire);
        guard
    }
}

impl<'a, T> Drop for MCSLockGuard<'a, T> {
    fn drop(&mut self) {
        // 자신의 다음 노트가 null이고 자신이 맨 끝의 노드이면 , 맨 끝을 null로 설정한다 ❶
        if self.node.next.load(Ordering::Relaxed) == null_mut() {
            let ptr = self.node as *mut MCSNode<T>;
            if let Ok(_) = self.mcs_lock.last.compare_exchange(
                // ❷
                ptr,
                null_mut(),
                Ordering::Release,
                Ordering::Relaxed,
            ) {
                return;
            }
        }

        // 자신의 다음 스레드가 lock 함수 실행 중이므로, 종료될 떄까지 대기한다 ❸
        while self.node.next.load(Ordering::Relaxed) == null_mut() {}

        // 자신의 다음 스레드를 실행 가능하게 설정 ❹
        let next = unsafe { &mut *self.node.next.load(Ordering::Relaxed) };
        next.locked.store(false, Ordering::Release);
    }
}

lock 함수의 동작 과정

1. 노드 초기화 (❶): 각 스레드는 자신의 노드를 깨끗한 상태로 만든다.

2. CAS로 큐에 추가 (❷): swap 연산으로 자신을 큐의 마지막에 원자적으로 추가한다. 이전 마지막 노드의 포인터를 받아온다.

3. 대기 여부 결정 (❸): 이전 노드가 있으면 대기해야 한다.

4. 대기 상태 설정 (❹): 자신의 locked를 true로 설정한다.

5. 큐 연결 (❺): 이전 노드의 next가 자신을 가리키게 한다.

6. 스핀 대기 (❻): 자신의 locked가 false가 될 때까지 대기한다. 여기서는 CAS가 아닌 일반 load를 사용한다!

drop 함수의 동작 과정

1. 마지막 노드 확인 (❶): 다음 노드가 없으면 자신이 마지막일 가능성이 있다.

2. CAS로 큐 비우기 (❷): compare_exchange로 "자신이 여전히 마지막이면 큐를 비운다"를 원자적으로 수행한다. 이게 실패하면 새로운 노드가 추가되는 중이란 뜻이다.

3. 다음 노드 대기 (❸): 다음 노드가 아직 큐 연결을 완료하지 않았다면 대기한다.

4. 다음 노드 깨우기 (❹): 다음 노드의 locked를 false로 설정해서 실행 가능하게 한다.

main.rs:

use std::sync::Arc;

const NUM_LOOP: usize = 100000;
const NUM_THREADS: usize = 4;

mod mcs;

fn main() {
    let n = Arc::new(mcs::MCSLock::new(0));
    let mut v = Vec::new();

    for _ in 0..NUM_THREADS {
        let n0 = n.clone();
        let t = std::thread::spawn(move || {
            // 노드를 작성하고 록
            let mut node = mcs::MCSNode::new();
            for _ in 0..NUM_LOOP {
                let mut r = n0.lock(&mut node);
                *r += 1;
            }
        });

        v.push(t);
    }

    for t in v {
        t.join().unwrap();
    }

    // 노드를 작성하고 록
    let mut node = mcs::MCSNode::new();
    let r = n.lock(&mut node);
    println!("COUNT = {} (expected = {})", *r, NUM_LOOP * NUM_THREADS);
}

정리

공평한 배타 제어는 컨텐션이 높은 환경에서 모든 스레드가 균등하게 락을 획득할 수 있도록 보장하는 방법이다. 특히 NUMA 같은 환경에서는 메모리 접근 속도 차이로 인한 불균형이 발생할 수 있는데, 공평한 락은 이런 문제를 완화한다.

약한 공평성을 보장하는 락은 우선 스레드를 순서대로 지정해서 공평성을 제공한다. 티켓락은 티켓 번호를 발급받고 자신의 차례를 기다리는 방식으로 동작하며, 티켓 획득 시 스핀을 수행하지 않아 컨텐션을 줄인다.

MCS락은 더 나아가 캐시 경합 문제까지 해결한다. 핵심은 CAS 연산을 큐 구조 변경에만 사용하고, 각 스레드가 대기할 때는 자신만의 변수를 감시하는 것이다. 이렇게 해서 아토믹 연산으로 인한 캐시 무효화를 최소화하고, 많은 스레드가 경쟁하는 환경에서도 좋은 성능을 유지할 수 있다.

결과적으로 이 세 가지 락은 각각 다른 수준의 공평성과 성능 특성을 제공한다. 시스템의 요구사항과 환경에 따라 적절한 락을 선택하는 것이 중요하다.

1. Intro

이 글은 NDSS 2025에서 발표된 KernelSnitch 논문을 소개이다. 이 연구는 커널의 평범한 데이터 구조체들이 가진 본질적인 특성이 어떻게 심각한 보안 취약점이 되는지를 보여준다.

핵심은 이러하다: "데이터 구조체의 크기에 따른 접근 시간 차이를 이용해 커널의 비밀 정보를 유출할 수 있다"

여기서는 커널 힙 포인터 유출에 집중해서 설명한다. 이 공격이 성공하면 KASLR을 우회하고 더 심각한 커널 익스플로잇의 발판이 될 수 있다.

2. 공격 대상 자료구조와 취약성 분석

Hash Table - Futex를 중심으로 먼저 가장 중요한 공격 대상인 futex 해시 테이블을 살펴보자.

2. 1 Futex(fast userspace mutex)란?

• 유저 공간의 빠른 동기화 매커니즘

• 대부분의 경우 커널 호출 없이 사용자 공간에서 처리.

아래와 같이 커널에 구현되어있다.

// kernel/futex/futex.h
struct futex_hash_bucket {
    atomic_t waiters;
    spinlock_t lock;
    struct plist_head chain;
} ____cacheline_aligned_in_smp;

// kernel/futex/core.c
static struct {
    struct futex_hash_bucket *queues;
    unsigned long            hashmask;
} __futex_data __read_mostly __aligned(2*sizeof(long));
#define futex_queues   (__futex_data.queues)
#define futex_hashmask (__futex_data.hashmask)

2.2 왜 취약한가?

// kernel/futex/core.c
// line 443~452
struct futex_q *futex_top_waiter(struct futex_hash_bucket *hb, union futex_key *key)
{
    struct futex_q *this;
    // 리스트의 모든 요소를 순회하는 매크로
    plist_for_each_entry(this, &hb->chain, list) {
        if (futex_match(&this->key, key))
            return this;
    }
    return NULL;
}

futex의 futex_top_waiter함수를 보면 리스트의 요소 개수에 따라 실행 명령어의 수가 달라질 수 있다는 것을 알 수 있다.

Case1: Empty Bucket

1. plist_for_each_entry 시작
2. 리스트가 비어있음 확인 (head->next == head)
3. 즉시 루프 종료
4. NULL 반환
실행 명령어: ~10개

Case2: 5 elements

1. plist_for_each_entry 시작
2. 첫 번째 요소 접근
   - this 포인터 로드
   - futex_match 호출 (key 비교)
   - 일치하지 않음 → 계속
3. 두 번째 요소 접근
   - 동일한 과정 반복
4. ... 5번째까지 반복
5. NULL 반환
실행 명령어: 10 + (8 × 5) = 50개

와 같다. 결과적으로 요소의 개수에 따라 실행 시간에 차이가 발생할 것임을 알 수 있다.

이 실행 시간 차이가 공격의 시작점이 된다.

2.3 사이클 측정하기

futex_wake의 코드를 살펴보면 다음과 같다.

// kernel/futex/waitwake.c
int futex_wake(u32 __user *uaddr, unsigned int flags, int nr_wake, u32 bitset) {
...
    plist_for_each_entry_safe(this, next, &hb->chain, list) {
        if (futex_match (&this->key, &key)) {
            if (this->pi_state || this->rt_waiter) {
                ret = -EINVAL;
                break;
            }

            /* Check if one of the bits is set in both bitsets */
            if (!(this->bitset & bitset))
                continue;

            this->wake(&wake_q, this);
            if (++ret >= nr_wake)
                break;
        }
    }

futex_wake는 전체 리스트를 순회하고, 특별한 권한 없이도 호출 가능하므로 좋은 실행 시간 측정 도구가 될 수 있다.

2.4 공격하기(커널 주소 유출)

공격의 목표는 mm_struct의 커널 주소이다. mm_struct는 프로세스의 메모리 관리 정보를 담고 있고, 이 주소를 알면 KASLR을 우회할 수 있다.

공격은 두 단계로 이루어지는데,

1. 해시 충돌 감지 (같은 버킷에 들어가는 주소들 수집)

2. 역해싱으로 커널 주소 추정 (수집한 정보로 mm_struct 주소 계산) 의 과정으로 진행된다.

2.4.1 Futex 해시 함수의 실제 위치와 동작

실제 커널 코드에서 해시 함수는 다음과 같다.

// kernel/futex/core.c
struct futex_hash_bucket *futex_hash(union futex_key *key)
{
    // key 전체를 해시값으로 변환하고
    u32 hash = jhash2((u32 *)key, offsetof(typeof(*key), both.offset) / 4,
              key->both.offset);
    // 해시값을 버킷 번호로 변환한다.
    return &futex_queues[hash & futex_hashmask];
}

여기서 공격의 첫 단계로 해시 충돌을 일으킨다.

2.4.2 비둘기집 원리로 증명되는 해시 충돌

// kernel/futex/core.c
// line 55. 56
#define futex_queues   (__futex_data.queues)
#define futex_hashmask (__futex_data.hashmask)

가능한 futex_queues는 CPU 개수에 종속적으로 결정된다.

따라서 비둘기집의 원리를 적용하면

• 가능한 사용자 주소: $2^{48}$ 개

• 버킷 수: 256 ~ 4096개(시스템에 따라)

가능한 사용자 주소 수 > 버킷 수에 따라 같은 버킷을 사용하는 서로 다른 사용자 주소의 존재성이 증명된다.

futex 해시 테이블은 uaddr(유저 주소)와 mm_struct을 이용하여 해시값을 생성하므로, 서로 다른 uaddr에 대해 같은 mm_struct를 사용했을 때 해시 충돌이 발생하는 조합을 찾는다.

여기서 해시 충돌의 발생 조합을 찾는 과정에서 논문이 제시하는 KernelSnitch가 사용된다. 이를 통해 직접 커널 내부를 보지 않고도 해시 충돌 조합을 구할 수 있다.

3. KernelSnitch의 원리

KernelSnitch는 캐시 사이드 채널을 이용해 커널 데이터 구조의 메모리 접근 여부를 사용자 공간에서 추론하는 도구다. 즉 커널이 특정 주소를 읽거나 썼는지를 CPU 캐시 상태를 통해 간접적으로 관찰할 수 있게 해준다.

기본 아이디어: Flush+Reload로,

공격자는 다음과 같은 과정을 통해 커널의 접근 여부를 관찰할 수 있다.

1. 특정 구조체 필드가 위치한 주소를 clflush 명령어로 캐시에서 제거한다.

2. 해당 구조체를 접근하도록 커널을 유도한다. (예: futex 호출)

3. 다시 사용자 공간에서 해당 주소를 읽고 접근 시간을 측정한다.

   • 캐시 접근이면 빠르게 로드됨 → 커널이 접근한 것

   • 메모리 접근이면 느리게 로드됨 → 커널이 접근하지 않은 것

이와 같은 방법으로 커널 내부 구조체에 대한 접근 여부를 사용자 공간에서 추론할 수 있다.

구체적으로는 다음과 같다.

① 해시 충돌 탐지 시 Occupancy 측정 (Section: B. Kernel Heap Pointer Leak)

해당 공격에서 시간 측정은 다음과 같은 "간접적인 occupancy(버킷의 리스트 길이)" 측정 도구로 사용된다.

인용:

A low occupancy level, such as for the user identifier uaddrY, indicates a different hash bucket.
Conversely, a higher occupancy level, e.g., uaddrZ, means that the values futex_hash(uaddrA, mmA)
and futex_hash(uaddrZ, mmA) match.

의미:

• 공격자가 uaddrA로 채운 버킷과 uaddrZ를 조합하여 충돌 여부를 확인한다.

• 이때, 커널이 리스트를 몇 개 순회하는지를 futex_wake() 같은 인터페이스로 호출하고,
  호출 시간이 오래 걸리는지로 충돌 여부를 추론한다.

• 즉, "같은 버킷이라면 요소가 많아지고 시간이 길어진다" 는 점을 이용하는 것이다.

요약:

• 더 오래 걸리면 → 같은 해시 버킷 → 충돌 발생

• 짧게 끝나면 → 다른 버킷 → 충돌 아님

② Flush+Reload로 구조체 필드 접근 여부 측정 (Section: KernelSnitch architecture)

공격자는 구조체의 특정 필드를 대상으로 다음과 같은 흐름을 수행한다:

인용:

We clflush a field of a kernel structure, invoke the syscall that may access it,
and then reload the same memory to measure access time.

의미:

• clflush → 커널 구조체 필드를 CPU 캐시에서 제거한다.

• 시스템콜 유도 (futex_wake() 등) → 커널이 해당 필드를 접근하면 다시 캐시에 올라간다.

• 사용자 공간에서 해당 주소를 다시 읽고 접근 시간 측정:

  • 캐시에 올라가 있으면 → 빠르게 읽힘 → 커널이 접근했다는 뜻

  • 메모리 접근이면 → 느리게 읽힘 → 접근하지 않은 것

요약:

• 접근 시간 짧음 → 캐시에 있음 → 커널이 접근함

• 접근 시간 김 → 메모리 접근 → 커널이 접근하지 않음

4. 역계산

다시 본론으로 돌아와서 해시 충돌에 대한 충분한 정보를 얻었으므로 역계산을 통해 mm_struct를 알아낼 차례다.

해시 함수는 단방향 함수이므로 역계산을 하는 것은 어려워보이나, 위 과정으로부터 해시 함수의 알고리즘(jhash2)를 알고 있고 많은 사용자주소-버킷번호의 매핑을 수집했고, 해시 함수의 입력이 사용자 주소와 mm_struct 주소의 조합이라는 것도 알고 있다.

먼저 수집된 충돌 데이터를 정리한다. 예를 들어 주소 0x1000이 버킷 42로, 주소 0x3000도 버킷 42로 매핑되었다면, 이 두 주소는 같은 mm_struct와 조합될 때 같은 해시값을 만든다는 의미이다. 이런 식으로 10만 개의 충돌 데이터를 버킷별로 그룹화하면, 각 버킷에는 수백 개의 주소가 모인다.

다음으로 mm_struct가 위치할 수 있는 주소 공간을 이해해야 한다. x86_64 리눅스에서 커널 힙은 Direct Physical Mapping(DPM) 영역을 통해 접근되는데, 이 영역은 0xffff888000000000부터 0xffffc87fffffffff까지이다.

하지만 mm_struct는 아무 주소에나 할당되지 않는다. 슬랩 할당자의 규칙에 따라 8페이지(32KB) 단위로 정렬된 슬랩에 할당되며, 각 슬랩에는 23개의 mm_struct 객체가 들어간다.

이러한 제약 조건들을 활용하면 검색 공간을 2^46에서 2^35.5로 대폭 줄일 수 있다.

이제 실제 역계산을 수행한다. 가능한 모든 슬랩 베이스 주소를 순회하면서, 각 슬랩 내의 23개 위치에 대해 mm_struct 후보 주소를 생성한다. 각 후보 주소에 대해, 우리가 수집한 모든 충돌 패턴이 설명되는지 검증한다. 예를 들어 버킷 42에 속한 모든 주소들이 이 mm_struct 후보와 조합될 때 정말로 버킷 42로 해싱되는지 확인하는 것이다.

검증 과정은 매우 단순하다. 후보 mm_struct 주소와 사용자 주소로 futex_key를 재현하고, jhash2 함수로 해시값을 계산한 뒤, futex_hashmask와 AND 연산하여 버킷 번호를 구한다. 이 버킷 번호가 우리가 관찰한 버킷 번호와 일치하는지 확인한다. 모든 충돌 패턴이 일치하는 mm_struct 주소를 찾으면, 그것이 바로 우리가 찾던 커널의 정보다.

Cross-Cache Reuse로 공격 확장

위 과정을 통해 mm_struct의 주소를 얻었다. 그럼 이제 Cross-Cache Reuse를 통해 더 위험한 공격을 수행할 수 있다. 이는 커널의 메모리 관리 메커니즘을 악용하는 기법이다.

리눅스 커널은 효율적인 메모리 관리를 위해 슬랩 할당자(SLUB)을 사용하는데 슬랩 할당자는 같은 크기와 타입의 객체들을 미리 할당된 메모리 슬랩에서 관리한다. 예를 들면 mm_struct 전용 캐시같은 것이다. Cross-Cache Reuse의 핵심은 한 캐시에서 해제된 메모리를 다른 캐시에서 재할당받는 것이다.

이를 수행하려면, 먼저 유출된 mm_struct에서 슬랩 정보를 추출한다. mm_struct를 32KB(8 페이지)로 정렬하면 슬랩 베이스 주소를 얻을 수 있다. 이 슬랩에는 23개의 mm_struct 객체가 들어있는데, 우리의 목표는 이 슬랩 전체를 해제하는 것이다.

슬랩을 해제하는 방법은 여러 가지가 있는데 가장 직접적인 방법으로 해당 슬랩의 모든 mm_struct를 사용하는 프로세스들을 종료시키는 것이 있다.

슬랩이 해제되면 이제 같은 크기의 객체로 재할당받아야 한다. 그런데 여기서 중요한 것은 mm_struct와 같은 할당자 캐시를 사용하는 객체를 선택하는 것이다. msg_msg가 같은 할당자 캐시를 사용하기 때문에, 이를 할당한다.

이제 msg_msg의 주소도 알아냈으며, 이를 제어할 수 있다. msg_msg를 통해 use-after-free를 트리거하거나 임의 메모리 읽기/쓰기를 수행하거나 궁극적으로는 권한 상승을 달성할 수 있다.

협조적/비협조적 멀티태스크

선점: 프로세스와의 협조 없이 수행하는 컨택스트 스위칭이라고는 하나, 결국 뺏어오는 게 가능하냐의 문제다.

협조적 멀티태스크(비선점형, cooperative): 각각의 프로세스가 자발적으로 컨택스트 스위칭을 수행하는 멀티태스크 방식.

장점: 멀티태스크 매커니즘을 구현하기 쉽다.

단점: 프로세스가 자발적으로 컨텍스트 스위칭을 해야하는데, 만약 버그가 발생하여 프로세스가 무한 루프에 빠지거나 정지하게 되면 그 프로세스는 계산 리소스를 점유하게 된다.

비협조적 멀티태스크(선점형, preemptive): 프로세스와 협조 없이 외부적인 작동에 따라 컨택스트 스위칭을 수행하는 멀티태스크 방식

장점: 비선점형에서 나타날 수 있었던 무한 루프나 블로킹 함수와 관련된 문제가 일어나지 않는다.

단점: 처리 시스템 구현이 어려울 수 있고, 공평성을 확보하기 위해 빈번하게 컨택스트 스위칭을 수행하게 되면 비선점형에 비해 다소 오버헤드가 있을 수 있겠다.

여기서 공평성이란 무엇인가? 공평성은 두 가지 정의가 있는데

약한 공평성: 어떤 실행 환경이 약한 공평성을 만족한다 <=> 어떤 프로세스가 특정 시각 이후 실행 가능한 대기 상태가 되었을 때 그 프로세스가 실행된다.

강한 공평성: 어떤 실행 환경이 강한 공평성을 만족한다. <=> 어떤 프로세스가 특정 시각 이후 실행 가능한 대기 상대와 실행 불가능한 대기 상태의 전이를 무한히 반복할 때 최종적으로 그 프로세스는 실행된다.

풀어서 설명하면 약한 공평성은 어떤 프로세스가 계속해서 실행 가능한 상태에 있다면 언젠가는 실행된다, 강한 공평성은 보다 강한 조건으로 단순히 언젠가 실행되는 것이 아니라 지속적으로 공정한 실행 기회를 보장받는다고 해석할 수 있다.

그린 스레드

그린 스레드란 유저랜드의 소프트웨어가 독자적으로 제공한 스레드 매커니즘을 뜻한다. 그러니까 OS가 아닌 런타임 라이브러리나 VM에 의해 스케줄링되는 스레드라고 할 수 있다. 반대되는 개념으로 네이티브 스레드가 있다.

액터 모델

액터 모델이란 동시성 프로그래밍을 위한 수학적 모델인데, 액터라는 독립적인 계산 단위라는 개념이 존재하고, 액터는 각자의 상태와 행동을 가진다.

액터 모델은 비동기, 동시성 처리를 가능하게 하는 모델인데, 객체 지향에서 모든 것은 객체다 라고 생각하는 것처럼 액터 모델에선 모든 것을 액터로 취급한다.

각 액터는 메시지 큐를 가지고 있고 이를 경유하여 데이터를 송수신한다.

좀 더 자세히 알아보자면

액터는 다음 세 가지 요소로 구성된다.

• Behavior

• State

• Mailbox

액터 간에는 메시지를 주고 받을 수 있고, 독립적인 메모리 공간을 갖는다. 액터는 다른 액터에게 메시지를 보내는 방법으로만 영향을 미칠 수 있기 때문에, 스레드에서 공통으로 접근하는 값이 변경되어 다른 스레드에 영향을 미칠 수 있는 것과 대비된다.

메시지 처리의 과정을 살펴보면,

1. Main문에서 액터를 지정해 메시지를 보내면

2. 해당 액터의 수신함에 메시지가 들어가고

3. 수신한 액터는 이벤트가 발생해

4. 받은 순서대로 메시지를 확인한다.

5. 그리고 액터는 수신한 메시지에 따라 행동을 결정하여 실행한다.

여기서 상태(State)는 액터 자신만 변경 가능하다. 그리고 메시지를 수신받은 액터가 취할 수 있는 행동은

• 자신의 상태 변경

• 자식 액터 생성 및 제거

• 다른 액터에 메시지 전송 등이 있다.

액터 간의 상호작용을 나타낸 그림인데, 결과적으로 말하고자 하는 것은

1. 메모리를 공유하지 않고

2. 메시지로만 상호작용하기 때문에 동시성 처리에서 비교적 덜 머리아프게(?) 문제를 해결할 수 있다는 것이다.

참고자료

아주 잘 정리된 블로그

관련 논문

의사 각성의 정의는 다음과 같다.

의사 각성: 특정한 조건이 만족될 때까지 대기 중이어야 하는 프로세스가 해당 조건이 만족되지 않았음에도 실행 상태로 변경되는 것

의사 각성은 어떤 경우에 일어나는가?

다음 코드는 의사 각성을 일으키는 C 코드 예시이다.

#include <pthread.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>

pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t cond = PTHREAD_COND_INITIALIZER;

// 시그널 핸들러: 시그널 번호 표시
void handler(int sig) { printf("recieved signal %d\n", sig); }

int main(int argc, char *argv[]) {
  // 프로세스 ID 취득, 표시.
  pid_t pid = getpid();
  printf("pid: %d\n", pid);

  // SIGUSR1 시그널 핸들러 등록
  signal(SIGUSR1, handler);

  // wait처리, 그러나 notify하는 스레드가 없음.
  // 영원히 대기?
  pthread_mutex_lock(&mutex);
  if (pthread_cond_wait(&cond, &mutex) != 0) {
    perror("pthread_cond_wait");
    exit(EXIT_FAILURE);
  }
  printf("spurious wake up\n");
  pthread_mutex_unlock(&mutex);

  return 0;
}

이 코드는 영원히 대기해야할 것 같지만 SIGUSR1 시그널이 송신되고 프로그램이 종료될 수 있다.

이유는

pthread_mutex_lock(&mutex);
  if (pthread_cond_wait(&cond, &mutex) != 0) {
    perror("pthread_cond_wait");
    exit(EXIT_FAILURE);
  }

여기서 pthread_cond_wait()는 pthread_cond_signal()이나 pthread_cond_broadcast() 때문에만 돌아오는 함수가 아니기 때문이다.

POSIX 규격에서 조건 변수를 기다리던 스레드는 아무 이유 없이 깨어날 수 있다고 허용하고 있다.

Spurious wakeups from the _pthread_cond_timedwait_() or _pthread_cond_wait_() functions may occur.

POSIX.1-2017

리눅스에서는 내부적으로 futex라는 시스템 콜을 이용하는데 커널 버전 2.6.22 이전에서는 futex에 의해 의사 각성이 발생했지만 이후 버전에는 발생하지 않는다.

정확히는 커널이 2.6.22 이후 안정화되어 내부 race로 인한 spurious wakeup은 줄어든 게 사실이지만 POSIX 규격상 spurious wakeup의 가능성을 명시하고 있는 것이 표준이기 때문에 완전히 배제된 개념은 아니라고 보는 게 옳다고 본다.

시그널

시그널이란 특정한 사건이 발생했다고 프로세스에게 알려주기 위해 UNIX 시스템에서 사용하는 알림 매커니즘이다. 일반적으로 시그널과 멀티스레드는 궁합이 맞지 않다고 알려져 있는데, 어떤 타이밍에서 시그널 핸들러가 호출되는지 알 수 없기 때문이다.

아래 코드는 시그널 핸들러를 사용할 때 데드락이 발생하는 전형적인 시그널 락 데드락 문제이다.

void handler(int sig) {
  pthread_mutex_lock(&mutex); // 데드락
  // 무언가 처리하기
  pthread_mutex_unlock(&mutex);
}

int main(int argc, char *argv[]) {
  pthread_mutex_lock(&mutex);
  // 이 시점에서 시그널 발생
  // handler()진입
  // handler 안에서 또 다시 pthread_mutex_lock(&mutex)
  pthread_mutex_unlock(&mutex);
  return 0;
}

위 코드는 어떤 스레드가 뮤텍스를 가진 상태에서 다시 락을 요청하게 되어 블록되는 상황이다.

위와 같은 상태에 빠지는 것을 방지하기 위해 시그널을 수신하는 전용 스레드를 이용할 수 있다.

#include <pthread.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
sigset_t set;

void *handler(void *arg) {
  pthread_detach(pthread_self());

  int sig;
  for (;;) {
    if (sigwait(&set, &sig) != 0) {
      perror("sigwait");
      exit(1);
    }
    printf("Received signal %d\n", sig);
    pthread_mutex_lock(&mutex);
    // Simulate some work
    pthread_mutex_unlock(&mutex);
  }
  return NULL;
}

void *worker(void *arg) {
  for (int i = 0; i < 10; i++) {
    pthread_mutex_lock(&mutex);
    // Simulate some work
    sleep(1);
    pthread_mutex_unlock(&mutex);
    sleep(1);
  }
  return NULL;
}

int main(int argc, char *argv[]) {
  pid_t pid = getpid();
  printf("pid: %d\n", pid);
  // SIGSUR1 시그널을 블록으로 설정
  sigemptyset(&set);
  sigaddset(&set, SIGUSR1);
  if (pthread_sigmask(SIG_BLOCK, &set, NULL) != 0) {
    perror("pthread_sigmask");
    exit(1);
  }

  pthread_t th, wth;
  pthread_create(&th, NULL, handler, NULL);
  pthread_create(&wth, NULL, worker, NULL);
  pthread_join(wth, NULL);

  return 0;
}

중요한 것은 pthread_sigmask 함수에서 시그널을 블록하는 것과 시그널 수신용 스레드를 준비해 sigwait함수에서 동기로 시그널을 수신하는 것이다. 이러면 어떤 타이밍에 시그널이 발생해도 데드락 상태가 되지 않는다.

어떤 시그널을 블록으로 설정하면 해당 시그널이 프로세스에 송신되어도 시그널 핸들러가 실행되지 않는다.

러스트에서는 signal_hook이라는 크레이트가 있으며 시그널을 다룰 때는 이 크레이트를 사용할 것을 권장한다.

use libc::SIGUSR1;
use signal_hook::iterator::Signals;
use std::sync::{Arc, Mutex};
use std::{error::Error, process, thread, time::Duration};

fn main() -> Result<(), Box<dyn Error>> {
    println!("pid: {}", process::id());

    // 수신 대상 시그널인 SIGUSR1지정하여 SIGNALS 타입 생성
    let signals = Signals::new([SIGUSR1])?;
    let signals = Arc::new(Mutex::new(signals));
    let worker_signals = Arc::clone(&signals);
    let handle = thread::spawn(move || {
        let mut signals = worker_signals.lock().unwrap();
        for sig in signals.forever() {
            println!("received signal: {:?}", sig);
        }
    });

    thread::sleep(Duration::from_secs(10));
    // 종료 직전 스레드 join
    handle.join().ok();
    Ok(())
}

위와 같이 시그널 수신 스레드를 작성할 수 있다. 시그널을 수신한 것을 여러 스레드에 알리고 싶을 때는 crossbeam-channel 크레이트를 이용할 수 있다.

crossbeac-channel

메모리 배리어

현대적인 CPU에서는 반드시 기계어 명령 순에 따라서만 처리를 수행하지는 않는다. 이러한 실행을 아웃 오브 오더 실행이라고 한다. 아웃 오브 오더 실행을 하는 이유는 파이프라인 처리 시 단위 시간당 실행 명령 수(instructions-per-second, IPC) 를 높이기 위해서이다.

예를 들면 메모리상에만 존재하는 주소 A와 캐시 라인상에 존재하는 주소 B가 있고 read A, read B순으로 기계어가 있을 때, 반드시 A->B순으로 읽는 것이 효율적이지는 않다. 이러한 경우에 아웃 오브 오더 실행은 IPC 향상에 기여할 수 있다.

아웃 오브 오더 실행은 IPC 향상에 도움이 되기도 하지만 몇 가지 문제를 발생시킬 수 있다. 이 파트의 제목이기도 한 메모리 배리어(메모리 펜스) 는 아웃 오브 오더 실행에 관한 여러 문제에서 시스템을 보호하기 위한 처리이다.

위 그림에서, 프로세스 A와 B는 공유 변수에 접근하기 위해 락을 획득하고 락 획득 중에 공유 변수를 증가한다고 가정한다. 그러나 A의 write(v+1)작업이 끝나기 이전 B가 이를 읽어오기 때문에 최종 결괏값으로 2를 기대했으나 1이 도출되는 상황이 된다. 그러나 실제로는 메모리 배리어 명령에 의해 메모리 읽기 쓰기 순서가 보증되기 때문에 위와 같은 일은 벌어지지 않는다.

AArch64의 메모리 배리어 명령 중 일부를 소개하자면 아래 사진과 같다.

이 중 dmb는

• dmb:

  • dmb sy: 이 명령어를 기준으로 앞의 모든 load/store가 완료되기 전에는 이후의 load/store가 시작되지 않음

  • dmb st: 이 명령 이전의 store과 이후의 store간의 순서만 보장하고, load는 관여하지 않음.

  • dmb ld: 이 명령 이전의 load와 이후의 load간의 순서만 보장.

그림으로는

와 같다.

메모리 오더링(memory ordering) 은 메모리 읽기 쓰기를 수행하는 순서를 말하고 기계어 순서와 다르게 실행되는 것을 리오더링이라 부른다. 리오더링이 발생하는 명령 순서는 읽기 쓰기 순서나 CPU 아키텍처에 따라 달라진다.

러스트 아토믹

러스트 언어에도 아토믹 변수를 다루는 라이브러리인 std::sync::atomic이 존재한다. 러스트에서는 아토믹 변수를 읽고 쓸 떄 메모리 배리어의 방법을 지정해야 하고 이 때 Ordering타입을 이용한다.

러스트에서의 Ordering은 아래 표와 같다.

러스트에서 뮤텍스는

• 보호 대상 데이터에는 락 후에만 접근 가능

• 락 해제는 자동으로 되는 특성이 있었다.

따라서 러스트의 아토믹 변수를 이용한 스핀락을 구현하면 아래와 같다.

use std::ops::{Deref, DerefMut};
use std::sync::Arc;
use std::sync::atomic::{AtomicBool, Ordering};

const NUM_THREADS: usize = 4;
const NUM_LOOP: usize = 100_000;

// 스핀락 구조체 정의
struct SpinLock<T> {
    locked: AtomicBool,
    data: UnsafeCell<T>,
}

// 락 가드 구조체
struct SpinLockGuard<'a, T> {
    spin_lock: &'a SpinLock<T>,
}

impl<T> SpinLock<T> {
    fn new(data: T) -> Self {
        SpinLock {
            locked: AtomicBool::new(false),
            data: UnsafeCell::new(data),
        }
    }

// 락 함수
    fn lock(&self) -> SpinLockGuard<T> {
        loop {
            // 빠른 경합 회피용 빠른 스핀
            while self.locked.load(Ordering::Relaxed) {
                std::hint::spin_loop(); // CPU friendly spin
            }
            if self
                .locked
                .compare_exchange_weak(false, true, Ordering::Acquire, Ordering::Relaxed)
                .is_ok()
            {
                break;
            }
        }
        SpinLockGuard { spin_lock: self }
    }

    fn unlock(&self) {
        self.locked.store(false, Ordering::Release);
    }
}

// unsafe marker: SpinLock<T>는 T가 Send일 때만 Send/Sync 가능
unsafe impl<T: Send> Send for SpinLock<T> {}
unsafe impl<T: Send> Sync for SpinLock<T> {}

// SpinLockGuard는 Deref/DerefMut 제공
impl<'a, T> Deref for SpinLockGuard<'a, T> {
    type Target = T;
    fn deref(&self) -> &Self::Target {
        unsafe { &*self.spin_lock.data.get() }
    }
}

impl<'a, T> DerefMut for SpinLockGuard<'a, T> {
    fn deref_mut(&mut self) -> &mut Self::Target {
        unsafe { &mut *self.spin_lock.data.get() }
    }
}

// Drop 구현으로 unlock
impl<'a, T> Drop for SpinLockGuard<'a, T> {
    fn drop(&mut self) {
        self.spin_lock.unlock();
    }
}

fn main() {
    let lock = Arc::new(SpinLock::new(0));
    let mut handles = Vec::new();

    for _ in 0..NUM_THREADS {
        let lock_clone = Arc::clone(&lock);
        let handle = std::thread::spawn(move || {
            for _ in 0..NUM_LOOP {
                let mut data = lock_clone.lock();
                *data += 1;
            }
        });
        handles.push(handle);
    }

    for handle in handles {
        handle.join().unwrap();
    }

    let result = lock.lock();
    println!("Final result: {}", *result);
}

UnsafeCell 사용 없이 구현하면 위와 같다.

배리어 동기

배리어 동기란 공유 변수를 증가시키다 공유 변수가 어떤 일정한 수에 도달하면 배리어를 벗어나 처리를 수행하는 방식이다.

이러한 배리어 동기를 사용하면 진행 순서를 보장할 수 있는데 예컨대 스레드 A가 스레드 B보다 먼저 넘어가면 안 된다고 가정하자. 이러한 경우에 A가 포함된 모든 1단계 스레드가 배리어에 도달해야만 다음 단계(B 포함)를 실행할 수 있게 되므로 진행 순서를 보장할 수 있다.

스핀락 기반 배리어 동기

다음 코드는 스핀락 기반의 배리어 동기를 보여주는데,

// 공유 변수에 대한 포인터 cnt와 최댓값 max
void barrier(volatile int *cnt, int max) {
    __sync_fetch_and_add(cnt, 1); // 공유 변수를 아토믹하게 증가
    while (*cnt < max); // cnt가 가리키는 값이 max가 될때까지 대기
}

배리어 동기를 이용하는 코드의 예시는 다음과 같다.

volatile int num = 0; //공유변수

void *worker(void *arg) { // 스레드용 함수
    barrier(&num, 10); // 배리어 동기 실행. 모든 스레드가 배리어에 도달하기 전까지 5행 처리 X
    // 무언가 처?리
    return NULL;
}

int main(int argc, char *argv[]) {
    // 스레드 생성
    pthread_t th[10];
    for (int i = 0; i < 10; i++) {
        if (pthread_create(&th[i], NULL, worker, NULL) != 0) {
            perror("pthread_create"); return -1;
        }
    }
    // join
    return 0;
}

Pthreads를 이용한 배리어 동기

스핀락을 이용한 배리어 동기에서는 대기 중에 루프 처리를 수행해야 하므로 CPU 리소스를 낭비할 여지가 있다. Pthreads의 조건 변수를 이용해서 이를 완화하는 방법에 대해 알아보자.

이것은 다음 코드로 구현될 수 있는데

#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>

pthread_mutex_t barrier_mut = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t barrier_cond = PTHREAD_COND_INITIALIZER;

void barrier(volatile int *cnt, int max) {
    if (pthread_mutex_lock(&barrier_mut) != 0) {
        perror("pthread_mutex_lock"); exit(-1);
    }
    (*cnt)++; // 락 획득 후 공유변수 증가

    if (*cnt == max) { 
        // *cnt와 max가 같으면 스레드 모두 실행
        if (pthread_cond_broadcast(&barrier_cond) != 0) {
            perror("pthread_cond_broadcast"); exit(-1);    
        }
    } else {
        do { // 값이 같지 않으면 대기
            if (pthread_cond_wait(&barrier_cond, &barrier_mut) != 0) {
                perror("pthread_cond_wait"); exit(-1);
            } 
        } while (*cnt < max);
    }
    if (pthread_mutex_unlock(&barrier_mut) != 0) {
        perror("pthread_mutex_unlock"); exit(-1);
    }
}

러스트 배리어 동기

use std::sync::{Arc, Barrier}; // 배리어 동기
use std::thread;

fn main() {
    // 스레드 핸들러 저장
    let mut v = Vec::new();
    // 10 스레드만큼의 배리어 동기를 Arc로 감싸기
    let barrier = Arc::new(Barrier::new(10));
    // 스레드 실행
    for _ in 0..10 {
        let b = barrier.clone();
        let th = thread::spawn(move || {
            b.wait(); // 배리어 동기 대기
            println!("finished barrier");
        });
        v.push(th);
    }
    for th in v {
        th.join().unwrap();
    }
}

실행 결과는 다음과 같다.

   Compiling barrier v0.1.0 (/home/max/coding/concurrent/barrier)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.17s
     Running `target/debug/barrier`
finished barrier
finished barrier
finished barrier
finished barrier
finished barrier
finished barrier
finished barrier
finished barrier
finished barrier

Readers-Writers 락

레이스 컨디션이 발생하는 원인은 쓰기 처리 때문이므로 쓰기만 배타적으로 수행하면 문제가 발생하지 않는다.

뮤텍스와 세마포어에서는 프로세스에 특별한 역할을 설정하지 않았다. 사실 쓰기만 문제가 되는데 읽기까지 제한을 하는 것은 비효율적으로 보일 수 있다. 따라서 쓰기와 읽기를 구분하고, 읽기끼리는 병렬성을 허용하되 쓰기 때는 제한하는 방식을 제안할 수 있는데 그것이 Readers-Writers락이다.

Readers-Writer락(RW 락) 에서는 읽기만 수행하는 프로세스(reader)와 쓰기만 수행하는 프로세스(wrtier)로 분류하고 다음 제약을 만족하도록 한다.

• 락을 획득 중인 reader는 같은 시각에 다수 존재할 수 있다.

• 락을 획득 중인 writer는 같은 시각에 1개만 존재할 수 있다.

• reader와 writer는 같은 시각에 락 획득 상태가 될 수 없다.

스핀락 기반 RW락

스핀락 기반의 RW락 알고리즘은 다음과 같이 구현될 수 있다. Reader용 락 획득과 반환 함수, Writer용 락 획득과 반환 함수는 별도의 인터페이스로 구현되어 있으니 실제 이용할 때는 공유 리소스의 읽기만 수행할지 쓰기만 수행할지 적절하게 판단해서 이용해야 한다.

// reader용 락 획득 함수
void rwlock_read_acquire(int *rcnt, volatile int *wcnt) {
    for (;;) {
        while (*wcnt); //writer가 있으면 대기
        __sync_fetch_and_add(rcnt, 1);
        if (*wcnt == 0) // writer가 없으면 락 획득
            break;
        __sync_fetch_and_sub(rcnt, 1);
    }
}

// reader용 락 반환 함수
void rwlock_read_release(int *rcnt) {
    __sync_fetch_and_sub(rcnt, 1);
}

// writer용 락 획득 함수
void rwlock_write_acquire(bool *lock, volatile int *rcnt, int *wcnt) {
    __sync_fetch_and_add(wcnt, 1);
    while (*rcnt); // reader가 있으면 대기
    spinlock_acquire(lock);
}

// writer용 락 반환 함수
void rwlock_write_release(bbol *lock, int *wcnt) {
    spinlock_release(lock);
    __sync_fetch_and_sub(wcnt, 1);
}

활용은 C에서는

int rcnt = 0;
int wcnt = 0;
bool lock = false;

void reader() {
    for (;;) {
        rwlock_read_acquire(&rcnt, &wcnt);
        //크리티컬 섹션
        rwlock_read_release(&rcnt);
    }
}
void writer () {
    for (;;) {
        rwlock_write_acquire(&lock, &rcnt, &wcnt);
        // 크리티컬 섹션
        rwlock_write_release(&lock, &wcnt);
    }
}

러스트에서는

use std::sync::RwLock;

fn main() {
    let lock = RwLock::new(10);
    {
        let v1 = lock.read().unwrap();
        let v2 = lock.read().unwrap();
        println!("v1: {}, v2: {}", *v1, *v2);
    }
    {
        let mut v = lock.write().unwrap();
        *v = 7;
        println!("v: {}", *v);
    }
}

실행 속도

Read가 대부분인 경우 뮤텍스보다 RW락을 사용하는 것이 실행 속도를 향상시키는 데 도움이 될 것이다. Read에 대해 병렬성을 허용하기 위한 것이 RW락이므로, 당연한 결과이다.

동시성 프로그래밍 특유의 버그와 문제점

동시성 프로그래밍도 특유의 버그와 문제점이 있다. 대표적으로 데드락, 라이브락, 기아(starvation) 등 문제가 발생한다.

데드락

동시성 프로그래밍 특유의 비유에 대해 식사하는 철학자 문제라는 비유가 있다. 원본은 포크지만 젓가락이 더 올바른 비유에 가까울 듯하니 젓가락으로 비유하겠다. 철학자가 원탁에 둘러앉아 있는데 철학자 사이에 젓가락이 하나씩 놓여있고, 젓가락 두 개가 있어야 식사를 할 수 있다.

위의 그림과 같은 상황에서, 철학자들은 다음 알고리즘을 따르는데,

1. 왼쪽 젓가락이 사용 가능할 때까지 기다렸다가 사용 가능해지면 젓가락을 든다.

2. 오른쪽에 대해서도 마찬가지로 사용 가능해지면 젓가락을 든다.

3. 식사를 한다.

4. 젓가락을 다시 내려놓는다.

5. 1로 돌아간다.

만약에 모든 철학자가 동시에 자신의 왼편에 놓인 젓가락을 집어든다고 치자. 모든 철학자가 젓가락 하나만을 가지고 있기 때문에 모두 식사할 수 없는데, 위 알고리즘에 따르면 모든 철학자들이 오른쪽이 사용 가능해질 때까지 대기하고 있지만, 모두가 식사를 하고 젓가락을 내려놓을 수 없으니 모두가 오른쪽을 대기하는 상태로 멈춰버리고, 모두가 식사를 하지 못한다.

이처럼 자원이 비는 것을 기다리며 더 이상 처리가 진행되지 않는 상태를 데드락이라고 한다.

위의 철학자 문제를 코드로 구현해보자면 아래와 같다.

use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
    let c0 = Arc::new(Mutex::new(()));
    let c1 = Arc::new(Mutex::new(()));

    let c0_p0 = c0.clone();
    let c1_p0 = c1.clone();

    //철학자0
    let p0 = thread::spawn(move || {
        for _ in 0..1000 {
            let _lock0 = c0_p0.lock().unwrap();
            let _lock1 = c1_p0.lock().unwrap();
            // 철학자가 밥을 먹는 코드
            println!("Philosopher 0 is eating");
        }
    });

    let p1 = thread::spawn(move || {
        for _ in 0..1000 {
            let _lock1 = c1.lock().unwrap();
            let _lock0 = c0.lock().unwrap();
            // 철학자가 밥을 먹는 코드
            println!("Philosopher 1 is eating");
        }
    });
    p0.join().unwrap();
    p1.join().unwrap();
}

이 코드는 마지막까지 실행될 수도 있지만 데드락이 발생해 더 이상 실행되지 않기도 한다.

특히 RW락은 데드락을 주의해야 하는데, 아래 코드처럼 데드락을 발생시킬 수 있다.

use std::sync::{Arc, RwLock};
use std::thread;

fn main() {
    let val = Arc::new(RwLock::new(true));

    let t = thread::spawn(move || {
        let flag = val.read().unwrap(); //read락 획득
        if *flag {
            *val.write().unwrap() = false; // write락 획득
            println!("flag is true");
        }
    });
    t.join().unwrap();
}

read락을 획득한 상태로 write락을 획득하게 되기 때문에 데드락 상태가 된다.

이를 해결하기 위해 다음과 같이 제시될 수 있다.

use std::sync::{Arc, RwLock};
use std::thread;

fn main() {
    let val = Arc::new(RwLock::new(true));

    let t = thread::spawn(move || {
        let flag = *val.read().unwrap(); // 읽기 락 drop
        if flag {
            *val.write().unwrap() = false; // 쓰기 락 가능
            println!("flag is true");
        }
    });
    t.join().unwrap();
}

이 코드는 데드락이 발생하지 않는다.

첫 번째 코드의 작동 원리를 알아보자면 이렇다. val.read()는 RwLockReadGuard를 생성하고 flag가 그것을 소유하게 된다. if *flag는 단순히 참조할 뿐, flag의 수명은 줄이지 않는다. 따라서 읽기 락이 유지된 상태로 쓰기 락을 시도하게 된다.

두 번째 코드에서 val.read()는 RwLockReadGuard를 반환하지만 이 값을 *로 역참조해 복사한다. 이 복사는 소유권의 이동이 아니라 스칼라 타입의 복사(Copy)라서 flag는 read_guard없이도 존재할 수 있다. 그리고 읽기 락은 곧바로 drop되기 때문에 쓰기 락을 안전하게 획득할 수 있다.

라이브락과 starvation

식사하는 철학자 문제를 수정해서 다음과 같이 알고리즘을 변경한다고 치자.

1. 왼쪽 젓가락이 사용 가능할 때까지 기다렸다가 사용 가능해지면 젓가락을 든다.

2. 오른쪽에 대해서도 마찬가지로 사용 가능해지면 젓가락을 들지만, 어느정도 기다려도 들 수 있는 상태가 되지 않으면 왼쪽 젓가락을 내려놓고 단계1로 되돌아간다.

3. 식사를 한다.

4. 젓가락을 다시 내려놓는다.

5. 1로 돌아간다.

이 고쳐진 알고리즘은 잘 작동할 것 같지만 마찬가지로 두 명의 철학자가 왼쪽 젓가락을 동시에 들고 있다가 내려놓고 동시에 드는 상황이 일어나면 이 상황이 반복되어 처리가 진행되지 않는다.

이렇게 리소스를 획득하는 처리는 수행하지만 다음 리소스를 획득하지 못해 이후의 처리를 하지 못하게 되는 상태를 라이브락이라고 한다.

라이브락이 되는 스테이트 머신은 다음과 같이 정의할 수 있다.

스테이트 머신에서 라이브락이 발생할 가능성이 있다 <=> 특정한 리소스를 획득하는 상태에는 도달하지만 그 외의 상태에는 절대 도달하지 못하는 무한 전이 사례가 존재한다.

그리고 굶주림(기아, starvation) 이란 특정 프로세스만 리소스 획득 상태로 전이하지 못하는 상태에 있는 것을 말한다. 이 또한 스테이트 머신을 정의하면

스테이트 머신에서 굶주림이 발생할 가능성이 있다 <=> 어떤 프로세스가 존재하고, 항상 리소스를 요청 가능한 상태에 도달하지만 실제 리소스를 획득하고 진행하는 상태로는 결코 도달하지 못하는 무한 루프를 가진다..

은행원 알고리즘

데드락을 회피하기 위한 알고리즘으로 다익스트라가 고안한 은행원 알고리즘이 있다. 예를 들자면 다음과 같다.

은행원은 2000만원의 자본을 가지고 있고 기업 A와 기업 B는 각각 1500만원, 2000만원의 자금이 필요하다. 은행원은 먼저 기업 A에 1500만원을 대출해주고, A는 이 돈으로 사업을 하고 다시 1500만원을 상환한다. 그 후 은행원은 B에 2000만원을 대출해주고 B는 사업 후 2000만원을 상환한다.

단 여기에 다음과 같은 제약이 존재하는데

• 기업은 자금을 대출하는 즉시 사용

• 기업은 필요한 금액을 대출받으면 반드시 전액 상환

• 기업은 전액 대출받기 전까지 사업할 수 없다.

• 이자는 존재하지 않는다.

• 은행은 보유 자금 이상 대출할 수 없다.

이 상황에서 아래 그림과 같은 상황을 가정하자.

이 경우 데드락이 발생한다. 둘 모두 사업할 수 없고 상환할 수도 없다.

위 두 사례에서 알 수 있는 것은 은행원의 자본과 각 기업이 필요로 하는 자본의 금액을 미리 알고 있다면 시뮬레이션을 통해 어떻게 대출을 해주면 데드락이 되는지 예측 가능하다. 따라서 은행원 알고리즘에서는 데드락이 발생하는 상태로 전이하는지 시뮬레이션을 통해 판정함으로써 데드락을 회피한다.

조금 더 부연설명하자면 은행은 한 기업이 요구하는 자금의 전액 정도는 가지고 있어야 한다. 즉 위 그림에서 은행원이 전체 1000만원을 가지고 있다면 성공적으로 대출해줄 수 없을 것이다. 그러나 위에서는 2000만원을 보유하고 있어 순서를 적절히 규정해주면 모두에게 돈을 빌려줄 수 있다.

이를 정리하면 은행원 알고리즘에서 상태는 두 가지가 있다.

안전상태: 시스템 교착을 일으키지 않고 각 프로세스가 요구한 양만큼 자원을 할당해줄 수 있는 안전 순서열이 존재하는 상태 불안전상태: 프로세스가 요구한 양만큼 자원 할당이 불가해 안전순서열이 존재하지 않는 상태

은행원 알고리즘은 결과적으로 자원의 할당 허용 여부를 결정하기 전에 미리 결정된 모든 자원의 최대 가능한 할당량을 시뮬레이션하여 안전 여부를 검사하고, 대기중인 모든 활동의 교착 상태 가능성을 조사하여 안전 상태 여부를 검사한다.

코드로는 다음과 같다.

main.rs:

use std::sync::{Arc, Mutex};

struct Resource<const NRES: usize, const NTH: usize> {
    available: [usize; NRES],         // 이용 가능한 리소스
    allocation: [[usize; NRES]; NTH], // 스레드 i가 확보 중인 리소스
    max: [[usize; NRES]; NTH],        // 스레드 i가 필요로 하는 리소스의 최댓값
}

impl<const NRES: usize, const NTH: usize> Resource<NRES, NTH> {
    fn new(available: [usize; NRES], max: [[usize; NRES]; NTH]) -> Self {
        Resource {
            available,
            allocation: [[0; NRES]; NTH],
            max,
        }
    }

    // 현재 상태가 데드록을 발생시키지 않는가 확인
    fn is_safe(&self) -> bool {
        let mut finish = [false; NTH]; // 스레드 i는 리소스 획득과 반환에 성공했는가?
        let mut work = self.available.clone(); // 이용 가능한 리소스의 시뮬레이션값

        loop {
            // 모든 스레드 i와 리소스 j에 대해,
            // finish[i] == false && work[j] >= (self.max[i][j] - self.allocation[i][j])
            // 을 만족하는 스레드를 찾는다.
            let mut found = false;
            let mut num_true = 0;
            for (i, alc) in self.allocation.iter().enumerate() {
                if finish[i] {
                    num_true += 1;
                    continue;
                }

                // need[j] = self.max[i][j] - self.allocation[i][j] 를 계산하고, 
                // 모든 리소스 j에 대해, work[j] >= need[j] 인가를 판정한다.
                let need = self.max[i].iter().zip(alc).map(|(m, a)| m - a);
                let is_avail = work.iter().zip(need).all(|(w, n)| *w >= n);
                if is_avail {
                    // 스레드 i가 리소스 확보 가능
                    found = true;
                    finish[i] = true;
                    for (w, a) in work.iter_mut().zip(alc) {
                        *w += *a // 스레드 i가 현재 확보하고 있는 리소스를 반환
                    }
                    break;
                }
            }

            if num_true == NTH {
                // 모든 스레드가 리소스 확보 가능하면 안전함
                return true;
            }

            if !found {
                // 스레드가 리소스를 확보할 수 없음
                break;
            }
        }

        false
    }

    // id번 째의 스레드가 resource를 하나 얻음
    fn take(&mut self, id: usize, resource: usize) -> bool {
        // 스레드 번호, 리소스 번호 검사
        if id >= NTH || resource >= NRES || self.available[resource] == 0 {
            return false;
        }

        // 리소스 확보를 시험해 본다
        self.allocation[id][resource] += 1;
        self.available[resource] -= 1;

        if self.is_safe() {
            true // 리소스 확보 성공
        } else {
            // 리소스 확보에 실패했으므로 상태 원복
            self.allocation[id][resource] -= 1;
            self.available[resource] += 1;
            false
        }
    }

    // id번 째의 스레드가 resource를 하나 반환
    fn release(&mut self, id: usize, resource: usize) {
        // 스레드 번호, 리소스 번호를 검사
        if id >= NTH || resource >= NRES || self.allocation[id][resource] == 0 {
            return;
        }

        self.allocation[id][resource] -= 1;
        self.available[resource] += 1;
    }
}

#[derive(Clone)]
pub struct Banker<const NRES: usize, const NTH: usize> {
    resource: Arc<Mutex<Resource<NRES, NTH>>>,
}

impl<const NRES: usize, const NTH: usize> Banker<NRES, NTH> {
    pub fn new(available: [usize; NRES], max: [[usize; NRES]; NTH]) -> Self {
        Banker {
            resource: Arc::new(Mutex::new(Resource::new(available, max))),
        }
    }

    pub fn take(&self, id: usize, resource: usize) -> bool {
        let mut r = self.resource.lock().unwrap();
        r.take(id, resource)
    }

    pub fn release(&self, id: usize, resource: usize) {
        let mut r = self.resource.lock().unwrap();
        r.release(id, resource)
    }
}

main.rs

mod banker;

use banker::Banker;
use std::thread;

const NUM_LOOP: usize = 100000;

fn main() {
    // 이용 가능한 젓가락의 수, 철학자가 이용하는 포크 최대 수 설정
    let banker = Banker::<2, 2>::new([1, 1], [[1, 1], [1, 1]]);
    let banker0 = banker.clone();

    let philosopher0 = thread::spawn(move || {
        for _ in 0..NUM_LOOP {
            // 젓가락 0과 1을 확보
            while !banker0.take(0, 0) {}
            while !banker0.take(0, 1) {}

            println!("0: eating");

            // 젓가락 0과 1을 반환
            banker0.release(0, 0);
            banker0.release(0, 1);
        }
    });

    let philosopher1 = thread::spawn(move || {
        for _ in 0..NUM_LOOP {
            // 젓가락 1과 0을 확보
            while !banker.take(1, 1) {}
            while !banker.take(1, 0) {}

            println!("1: eating");

            // 젓가락 1과 0을 반환
            banker.release(1, 1);
            banker.release(1, 0);
        }
    });

    philosopher0.join().unwrap();
    philosopher1.join().unwrap();
}

재귀락

재귀락이란 락을 획득한 상태에서 프로세스가 그 락을 해제하기 전에 다시 그 락을 획득하는 것을 말한다.

재귀락이 발생하면 어떻게 되는가? 는 알고리즘의 구현에 따라 다르다. 단순한 뮤텍스 구현에 대해 재귀락을 수행하면 데드락 상태가 되겠지만 재귀락을 수행해도 처리를 계속할 수 있는 락이 존재하고 이를 재진입 가능한(reentrant) 락이라고 한다. 다시 정리하자만 재귀락을 수행해도 데드락 상태에 빠지지 않고 처리를 계속할 수 있는 락이다.

C언어에서 재진입 가능한 뮤텍스를 구현하면 다음과 같다.

#include <assert.h>
#include <pthread.h>
#include <stdbool.h>
#include <stdio.h>
#include <stdlib.h>

// 재진입 가능한 뮤텍스용 타입 ❶
struct reent_lock {
    bool lock; // 록용 공유 변수
    int id;    // 현재 록을 획득 중인 스레드 ID, 0이 아니면 록 획득중임
    int cnt;   // 재귀 록 카운트
};

// 재귀 록 획득 함수
void reentlock_acquire(struct reent_lock *lock, int id) {
    // 록 획득 중이고 자신이 획득 중인지 판정 ❷
    if (lock->lock && lock->id == id) {
        // 자신이 획등 중이면 카운트를 증가
        lock->cnt++;
    } else {
        // 어떤 스레드도 혹을 획득하지 않았거나,
        // 다른 스레드가 록 획득 중이면 록 획득
        spinlock_acquire(&lock->lock);
        // 록윽 획득하면 자신의 스레드 ID를 설정하고
        // 마운트를 인크리먼트
        lock->id = id;
        lock->cnt++;
    }
}

// 재귀 록 해제 함수
void reentlock_release(struct reent_lock *lock) {
    // 카운트를 디크리먼트하고,
    // 해당 카운트가 0이 되면 록 해제 ❸
    lock->cnt--;
    if (lock->cnt == 0) {
        lock->id = 0;
        spinlock_release(&lock->lock);
    }
}

// 활용 예시
struct reent_lock lock_var; // 록용 공유 변수

// n회 재귀적으로 호출해 록을 거는 테스트 함수
void reent_lock_test(int id, int n) {
    if (n == 0)
        return;

    // 재귀 록
    reentlock_acquire(&lock_var, id);
    reent_lock_test(id, n - 1);
    reentlock_release(&lock_var);
}

// 스레드용 함수
void *thread_func(void *arg) {
    int id = (int)arg;
    assert(id != 0);
    for (int i = 0; i < 10000; i++) {
        reent_lock_test(id, 10);
    }
    return NULL;
}

int main(int argc, char *argv[]) {
    pthread_t v[NUM_THREADS];
    for (int i = 0; i < NUM_THREADS; i++) {
        pthread_create(&v[i], NULL, thread_func, (void *)(i + 1));
    }
    for (int i = 0; i < NUM_THREADS; i++) {
        pthread_join(v[i], NULL);
    }
    return 0;
}

C와는 달리 러스트에서는 재귀락을 수행하는 코드는 의도적으로 작성하지 않으면 거의 일어나지 않는 것으로 보인다. 락용 변수와 리소스가 강하게 결합되어 있기 때문이다.

아래와 같이 재귀락을 수행하는 코드를 짤 수 있기는 하나, 일반적이지 않다.

use std::sync::{Arc, Mutex};

fn main() {
    // 뮤텍스를 Arc로 작성하고 클론
    let lock0 = Arc::new(Mutex::new(0)); // ❶
    // Arc의 클론은 참조 카운터를 증가하기만 한다
    let lock1 = lock0.clone(); // ❷

    let a = lock0.lock().unwrap();
    let b = lock1.lock().unwrap(); // 데드록 ❸
    println!("{}", a);
    println!("{}", b);
}

레이스 컨디션(race condition)

레이스 컨디션은 한국어로는 경합 상태라고 불리며 여러 프로세스가 동시에 공유하는 자원에 접근함에 따라 일어나는 예상치 않은 이상이나 상태를 의미한다.

레이스 컨디션의 예로 아래 그림을 들 수 있다. 아래 그림은 공유 메모리상의 변수를 여러 프로세스가 증가시키는 상황을 나타낸다,

프로세스 B가 2를 쓰는 시점까지는 문제가 없어 보이나, A 프로세스가 2를 읽어온 이후 A가 이를 다시 쓰기 전에 B가 공유 변수를 읽어와버린다. 결과적으로 B가 3이 아닌 2를 읽어오게 되고 기댓값인 4 대신 3을 내놓는다.

이처럼 동시성 프로그래밍에서 예기치 못한 결함에 빠지는 것을 레이스 컨디션이라고 한다. 그리고 레이스 컨디션을 일으키는 프로그램 코드 부분을 크리티컬 섹션이라고 하는데, 레이스 컨디션을 방지하기 위해서는 크리티컬 섹션을 보호하는 장치들이 필요할 것이다.

아토믹 처리

아토믹 처리란 더 이상 나눌 수 없는 단일한 작업 단위를 의미한다. 즉, 다른 쓰레드나 프로세스가 끼어들 수 없다는 것이다. 현대 컴퓨터상의 동기 처리 대부분은 이러한 아토믹 명령에 의존하고 있다.

Compare and Swap

Compare and Swap은 동기 처리 기능의 하나인 세마포어, 락프리, 웨이트프리한 데이터 구조를 구현하기 위해 이용하는 처리다. 줄여서 CAS라고 한다.

다음 코드를 통해 CAS의 의미를 파악해볼 수 있다.

bool compare_and_swap(uint64_t *p, uint64_t val, uint64_t newval)
{
    if (*p != val) {
    // *p의 값이 val과 다르면 false를 반환
        return false;    
    }
    // *p의 값이 val과 같으면 *p에 newval을 대입하고 true를 반환
    *p = newval;
    return true;
}

어셈블리에서도 같은 작업이 가능한데 기본적으로는 레지스터의 값을 비교하고 비교 결과를 통해 특정 라벨로 점프하는 로직이다. C코드는 이러한 작업을 사람이 읽기 쉬운 변수들로 구현하였으나 레지스터 단위에서 이 작업들이 일어나는 것이 다를 뿐 근본적으로 큰 차이는 없다.

    cmpq %rsi, (%rdi)
    jne LBB0_1
    movq %rdx, (%rdi)
    movl $1, %eax
    retq
LBB0_1:
    xorl %eax, %eax
    retq

위에서 rdi, rsi, rdx가 함수의 첫번째, 두번째, 세번째 인수로 이용된다. 즉 각각이 p, val, newval에 해당한다.

그런데 위의 C함수는 아토믹하지 않다! 이유는 *p != val검사와 *p = newval 사이에 다른 쓰레드가 끼어들 수 있기 때문이다. 따라서 여전히 레이스 컨디션이 발생할 여지가 있다.

그래서 gcc와 같은 컴파일러에서 이와 같은 조작을 아토믹으로 처리하기 위해 내장 함수 __sync_bool_compare_and_swap을 제공한다.

bool compare_and_swap(uint64_t *p, uint64_t val, uint64_t newval) 
{
    return __sync_bool_compare_and_swap(p, val, newval);
}

__sync_bool_compare_and_swap함수의 의미와 인수는 compare_and_swap함수와 완전히 동일하다. 이 함수는 다음 어셈블리 코드로 변환되는데

movq %rsi, %rax
xorl %ecx, %ecx
lock cmpxchgq %rdx, (%rdi)
sete %cl
movl %ecx, %eax
retq

두 번째 인수를 의미하는 rsi 레지스터의 값을 rax로 복사하고 ecx 레지스터 값을 0으로 초기화한다. 여기서 이제 차이가 발생하는데 cmpxchgq명령을 통해 아토믹하게 비교 및 교환된다.

cmpxchgq 명령은 다음 코드로 의미를 표현할 수 있는데

if (%rax == (%rdi)) {
    (%rdi) = %rdx
    ZF = 1
} else {
    %rax = (%rdi)
    ZF = 0
}

즉 rax 레지스터의 값과 rdi레지스터가 가리키는 메모리상의 값을 비교하고 같으면 rdi에 rdx의 값을 대입하고 ZF플래그를 1로 만든다. 만약 값이 다르면 rax에 rdi의 값을 대입하고 ZF플래그를 0으로 설정한다. 그러니까 의미 자체는 compare_and_swap함수와 같다는 건데 이것이 아토믹하게 일어날 뿐이다.

위의 로직이 하나의 시퀀스로 묶여 실행되고 중단되지 않는다. 그런데 멀티코어 환경에서 cmpxchgq만 쓰면 코어 간 레이스 컨디션은 보장되지 않을 수 있는데 lock 프리픽스를 붙여서 아토믹을 보장할 수 있다.

참고로 cmpxchgq에서 마지막 q의 의미는 명령어의 오퍼랜드 크기, 그러니까 64바이트를 의미하는 것이므로 위의 로직은 엄밀히는 cmpxchg를 설명한다고 보는 게 더 적절하겠다.

Test and Set

Test and Set은 TAS로 줄일 수 있다. 이는 코드로

bool test_and_set(bool *p) {
    if (*p) {
        return true;
    } else {
        *p = true;
        return false;
    }
}

즉 포인터 p가 가리키는 값이 true면 그대로 true를 반환하고 false를 가르키면 p가 가리키는 메모리의 값을 true로 설정하고 false를 반환한다.

아까 CAS처럼 이 자체로는 아토믹하게 실행되지 않는다. 또 gcc같은 C컴파일러에서는 내장 함수 __sync_lock_test_and_set을 제공해서 아토믹하게 작동할 수 있게 하는데, 이 함수는 아까와는 다르게 위의 test_and_set함수와 작동 원리가 다르다.

type __sync_lock_test_and_set(type *p, type val) {
    type tmp = *p;
    *p = val;
    return tmp;
}

아까와는 다르게 포인터 p에 더해 val이 두 번째 인자로 들어오고, tmp에 *p를 저장, *p에는 두 번째 인자인 val의 값을 넣어주고, 최종적으로 초기 *p의 값이 저장되었던 tmp가 반환된다.

이때 이 함수는 두번째 인수 val에 1(true)를 지정함으로써 TAS함수처럼 작동하게 된다.

따라서 __sync_lock_test_and_set을 이용해 아토믹으로 구현이 가능하다.

bool test_and_set(volatile bool *p) {
    return __sync_lock_test_and_set(p, 1);
}

Load-Link/Store-Conditional

x86-64와 x86에서는 lock명령 접두사를 사용해 메모리에 읽고 쓰기를 배타적으로 수행하도록 했다. 그 외 ARM, RISC-V 등에서는 Load-Link/Store-Conditional 명령을 이용해 아토믹 처리를 구현했다. 둘은 줄여서 LL과 SC라고 한다.

자세히 알아보자면, LL은 메모리를 배타적으로 읽도록 지정하는 명령어이고, SC명령어는 메모리 쓰기를 수행하는 명령어이다. LL명령어로 지정한 메모리로의 쓰기는 다른 CPU가 수행하지 않는 경우에만 쓰기가 성공한다.

뮤텍스

뮤텍스(Mutex) 는 MUTual EXecution의 약어로 배타 실행(Exclusive Execution)이라고도 하는 동기 처리 방법이다. 위에서 크리티컬 섹션은 레이스 컨디션이 발생할 수 있는 코드 영역이라고 했다. 뮤텍스는 이러한 크리티컬 섹션을 실행할 수 있는 프로세스 수를 최대 1개로 제한한다.

뮤텍스의 원리는 플래그를 이용해 크리티컬 섹션에서 실행될 프로세스를 제한하는 방식인데, 아래 코드와 같이 동작한다.

bool lock = false; // 공유 변수 정의

void some_func() {
retry: 
    if (!lock) { // 이미 다른 프로세스가 크리티컬 섹션 실행중인지?
        lock = true; // 사용중이다
    } else {
        goto retry;
    }
    lock = false; // 이제 사용중이 아님. 종료
}

언뜻 보기에 이 함수는 배타적 실행을 성공시킬 수 있을 것 같지만 잘 동작하지 않는 경우가 발생한다.

이러한 상황이다.

lock을 true로 바꾸기 전에 프로세스가 들어와 lock을 false로 인식하여 레이스 컨디션이 발생하게 되는 상황이다.

따라서 이를 방지하려면

bool lock = false;

void some_func() {
retry: 
    if (!test_and_set(&lock)) { // 락 획득
        // 크리티컬 섹션
    } else {
        goto retry;
    }
    tas_release(&lock); // 락 해제
}

그것을 위해 TAS를 이용해 아토믹하게 검사와 값 변경을 수행하는 것이다. 그렇다면 중간에 다른 프로세스가 끼어드는 것을 방지할 수 있다.

스핀락

위에서는 락을 얻을 때까지 루프를 반복했다. 이렇게 리소스가 비는 것을 기다리며 확인하는 락 획득 방법을 스핀락이라고 한다.

전형적으로 스핀락용 API는 락 획득용과 락 해제용 함수 두 가지가 제공되고

void spinlock acquire(bool *lock) {
    while (test_and_set(lock));
}

void spinlock_release(bool *lock) {
    tas_release(lock);
}

일반적으로 아토믹 명령은 실행 속도상의 패널티가 있어 호출 전에 검사를 하고 나는 방식을 추가하면 조금 더 효율적이다.

void spinlock_acquire(volatile bool *lock) {
    for (;;) {
        while (*lock);
        if (!test_and_set(lock))
            break;
    }
}

void spinlock_release(bool *lock) {
    tas_release(lock);
}

Pthreads의 뮤텍스

C의 Pthreads에서도 뮤텍스를 이용할 수 있다. 일반적으로는 이렇게 직접 구현하는 것보다 라이브러리에서 제공하는 뮤텍스를 이용하는 것이 바람직하다.

#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>

pthread_mutex_t mut = PTHREAD_MUTEX_INITIALIZER;

void* some_func(void *arg) {
    if (pthread_mutex_lock(&mut) != 0) {
        perror("pthread_mutex_lock"); exit(-1);
    }
    // 크리티컬 섹션

    if (pthread_mutex_unlock(&mut) != 0) {
        perror("pthread_mutex_unlock"); exit(-1);
    }
    return NULL;
}

int main(int argc, char *argv[]) {
    //스레드 생성
    pthread_t th1, th2;
    if (pthread_create(&th1, NULL, some_func, NULL) != 0) {
        perror("pthread_create"); return -1;
    }
    // 스레드 종료 대기
    if (pthread_join(th1, NULL) != 0) {
        perror("pthread_join"); return -1;
    }
    if (pthread_join(th2, NULL) != 0) {
        perror("pthread_join"); return -1;
    }
    // 뮤텍스 객체 릴리즈
    if (pthread_mutex_destroy(&mut) != 0) {
        perror("pthread_mutex_destroy"); return -1;
    }
    return 0;
}

세마포어

뮤텍스에서는 락을 최대 1개 프로세스까지 획득할 수 있었다. 그렇다면 1개보다 많은 프로세스가 동시에 락을 획득하려면 어떻게 해야하는가? 세마포어를 쓰면 된다.

세마포어에서는 최대 N개 프로세스까지 동시에 락을 획득할 수 있는데, 여기서 N은 프로그램 실행 전에 임의로 결정할 수 있는 값이다.

그런고로 뮤텍스는 N이 1인 세마포어인 것으로, 세마포어는 일반화한 뮤텍스로도 볼 수 있겠다.

코드로 구현하면 아래와 같다.

#define NUM 4 // N

// 다수의 프로세스가 락을 획득했는지 알아야 하므로 int타입
void semaphore_acquire(volatile int *cnt) {
    for (;;) {
    // 공유 변숫값이 최댓값 NUM 이상이면 스핀하며 대기
        while (*cnt >= NUM);
        __sync_fetch_and_add(cnt, 1);
        // NULL 이하인지 검사하여 그렇다면 루프 벗어나기
        if (*cnt <= NUM) 
            break;
            __sync_fetch_and_sub(cnt, 1);
    }
}

void semapthore_release(int *cnt) {
    __sync_fetch_and_sub(cnt, 1);
}

세마포어는 물리적인 계산 리소스 이용에 제한을 적용하고 싶은 경우 등에 이용할 수 있다.

POSIX 세마포어

POSIX 규격을 따르는 세마포어 인터페이스이다. 표준적인 구현으로 볼 수 있다. POSIX 세마포어에서는 이름 있는 세마포어와 이름 없는 세마포어가 있는데, 이름 있는 세마포어는 슬래시로 시작해 널 문자열로 끝나는 문자열로 식별된다. 또한 이름 있는 세마포어는 파일로 공유 리소스를 지정할 수 있고, sem_open으로 생성과 열기, sem_close와 sem_unlink로 닫기와 파기를 수행한다.

조건 변수

조건 변수는 스레드 간의 동기화를 위한 도구로, 특정 조건이 만족될 때까지 스레드를 잠들게 했다가, 조건이 충족되면 스레드를 깨워 다시 실행하게 만드는 구조이다. 교차로에서 신호등같은 역할을 하는 것이다.

뮤텍스만 사용하게 되면 플래그가 true가 되었는지 반복해서 검사해야하기 때문에 Busy-Waiting 상태가 되는데, CPU 사용 면에서 비효율적이라고 할 수 있다. 확인하기 위해 CPU를 계속해서 깨워야하기 때문이다.

이를 위해 조건변수를 사용하게 된다.

Rust에서의 구현

러스트에서는 기본적인 동기 처리 라이브러리를 표준 라이브러리로 제공하는데, 아래와 같이 구현된다고 할 수 있다.

뮤텍스

아래 코드는 러스트에서 뮤텍스의 활용 예제를 나타낸다.

use std::sync::{Arc, Mutex}; //여기서 Arc는 참조 카운트 기반 스마트 포인터.
use std::thread; // 표준 스레드 생성 기능

fn some_func(lock: Arc<Mutex<u64>>) {
    loop {
        let mut val = lock.lock().unwrap(); // 락 획득
        *val += 1; // 값 증가
        println!("{}", *val); // 출력
    }
}

fn main() {
    let lock0 = Arc::new(Mutex::new(0)); 
    let lock1 = lock0.clone(); // Arc 복제(참조 카운트 증가)
    let th0 = thread::spawn(move || {
        some_func(lock0); // 첫 스레드 실행
    });
    let th1 = thread::spawn(move || {
        some_func(lock1); // 두 번째 스레드 실행
    });
    th0.join().unwrap();
    th1.join().unwrap();
}

러스트에서는 뮤텍스용 변수는 보호 대상 데이터를 보존하도록 되어 있어 접근하려면 반드시 lock을 해야한다.

C언어에서 보호 대상 데이터는 락을 하지 않아도 접근할 수 있는데, 그런 코드는 레이스 컨디션이 될 가능성이 있다.

자세히 설명하자면 러스트에서는

• Mutex<T> 자페가 T에 대한 소유권을 가지고 있다.

• 따라서 T에 직접 접근하려면 lock()을 통해 MutexGuard<T>를 획득해야 한다.

• 결론적으로 락 없이는 접근 불가가 된다.

그러나 C에서는 뮤텍스와 보호 대상 데이터를 따로 관리하므로 락 없이 접근하는 케이스가 생길 수 있고, 이 경우 레이스 컨디션이 된다.

한마디로 러스트에서는 락과 데이터를 결합해서 락을 통한 접근만 가능하고 타입에도 이를 강제하고 있으므로 safe하다.

조건 변수

use std::sync::{Arc, Mutex, Condvar}; //조건변수
use std::thread;

fn child(id: u64, p: Arc<(Mutex<bool>, Condvar)>) {
    // 대기 스레드용 함수 정의
    let &(ref lock, ref cvar) = &*p;
    // Arc 타입 내부에 포함된 뮤텍스와 조건변수를 꺼내기
    let mut started = lock.lock().unwrap();
    while !*started {
        // 시작 신호가 오기 전까지 대기
        started = cvar.wait(started).unwrap();
    }
    println!("Child thread {} started", id);
}

fn parent(p: Arc<(Mutex<bool>, Condvar)>) {
    // 시작 신호를 보내는 함수 정의
    let &(ref lock, ref cvar) = &*p;
    // 락을 한 뒤 공유 변숫값을 true로 설정하고 알림
    let mut started = lock.lock().unwrap();
    *started = true;
    cvar.notify_all();
    println!("Parent thread notified all children");
}

fn main() {
    let pair = Arc::new((Mutex::new(false), Condvar::new()));
    let pair0 = Arc::clone(&pair);
    let pair1 = Arc::clone(&pair);
    let pair2 = Arc::clone(&pair);

    let c0 = thread::spawn(move || {
        child(0, pair0);
    });
    let c1 = thread::spawn(move || {
        child(1, pair1);
    });
    let p = thread::spawn(move || {
        parent(pair2);
    });

    c0.join().unwrap();
    c1.join().unwrap();
    p.join().unwrap();
}

깃허브 액션 워크플로우를 통해 자동으로 도커 이미지를 빌드하고 컨테이너를 실행하는 형태의 자동 배포도 가능하다.

name: Deploy to Remote Server

on:
  push:
    branches:
      - main

permissions:
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Setup SSH Key
        run: |
          echo "${{ secrets.SSH_KEY }}" | base64 -d > key.pem
          chmod 600 key.pem

      - name: Pull and Restart on Server
        run: |
          ssh -i key.pem -p ${{ secrets.SSH_PORT }} -o StrictHostKeyChecking=no ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }} << 'EOF'
            cd ${{ secrets.REMOTE_DIR }}
            echo "[INFO] Pulling latest changes..."
            git pull origin main
            echo "[INFO] Stopping old container..."
            docker stop discord-bot-toko || true
            docker rm discord-bot-toko || true
            echo "[INFO] Rebuilding image..."
            docker build -t discord-bot-toko .
            echo "[INFO] Starting container..."
            docker run -d --name discord-bot-toko --env-file .env --rm discord-bot-toko
          EOF

위 코드의 경우 실제로는 배포상 문제가 있었으나, 위와 같은 식으로 push가 있는 경우 도커 이미지를 빌드하고 도커 컨테이너를 재실행하는 디자인으로 작성되었다.

테스트 만들기

러스트에서도 테스트들을 만들 수 있다.

name: Audit

on:
  schedule:
    - cron: "0 0 * * 0" # Every Sunday at midnight
  workflow_dispatch: # Manual trigger

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # Toolchain installation
      - name: Install Rust
        uses: actions-rs/toolchain@v1
        with:
          toolchain: stable

      # cargo-audit
      - name: Install cargo-audit
        run: cargo install --locked cargo-audit

      # check known vulnerabilities
      - name: Run cargo-audit
        working-directory: vulncat
        run: cargo audit

위와 같은 식으로 알려진 취약점에 대한 테스트도 작성할 수 있다. 위의 경우 일요일 자정 또는 수동 트리거에 의해 작동시킬 수 있다.

배포

release를 이용해 자동으로 태그를 달고 배포하는 용도로도 사용 가능하다.

name: Release

on:
  push:
    tags:
      - "v*.*.*"

jobs:
  release:
    runs-on: ubuntu-latest

    defaults:
      run:
        working-directory: vulncat/model

    steps:
      - uses: actions/checkout@v4
      - name: Install Rust
        uses: actions-rs/toolchain@v1
        with:
          toolchain: stable

      - name: Run full build & tests
        run: |
          cargo build --release
          cargo test

      - name: Create GitHub Release
        uses: actions/create-release@v1
        id: create
        with:
          tag_name: ${{ github.ref_name }}
          release_name: Release ${{ github.ref_name }}
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      - name: Upload trained model
        uses: actions/upload-release-asset@v1
        with:
          upload_url: ${{ steps.create.outputs.upload_url }}
          asset_path: models/autoencoder.bin
          asset_name: autoencoder.bin
          asset_content_type: application/octet-stream

린터 적용

파이썬 프로젝트의 경우 github action 웹에서 간단하게 pylint를 적용할 수 있다. 다만 기본 설정을 그대로 적용할 경우 파이린트 점수가 10점 이상이여야 테스트 성공이 나오나, 만약 머지를 막아놓은 경우 파이린트 10점이 꽤 강한 제한으로 느껴질 수 있다.

이러한 경우에

name: Pylint

on: [push]

permissions:
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: ["3.13"]
    steps:
    - uses: actions/checkout@v4
    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v3
      with:
        python-version: ${{ matrix.python-version }}
    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        pip install pylint
    - name: Analysing the code with pylint
      run: |
        pylint $(git ls-files '*.py') --fail-under=7.5

아래 이렇게 점수를 설정해줘서 테스트의 강도를 조절할 수 있는데

pylint $(git ls-files '*.py') --fail-under=7.5인 경우 7.5 이상에서 테스트가 통과하게 된다.

우선 ETL은 약자인데 무엇의 약자이냐면

ETL:

• Extract

• Transform

• Load 의 약자이다.

그래서 ETL 파이프라인이 뭐냐고 하면, ETL 파이프라인은 데이터 파이프라인의 일부이다.

그럼 다시 데이터 파이프라인이란 무엇인가? 데이터 파이프라인이란 다양한 데이터 소스에서 원시 데이터를 수집하고 변환한 다음 분석을 위해 데이터 레이크나 데이터 웨어하우스같은 데이터 저장소로 이식하는 방법이다.

ETL Pipeline

Astro cli

Astro cli는 Airflow 세팅을 위한 일종의 프레임워크라고 보면 될 듯하다. 이 툴을 이용해서 초기화하면 웹 프레임워크 (리액트나 뷰처럼) 테스트부터 세팅에 필요한 기초적인 디렉토리 구조와 일부 코드들이 제공된다.

리눅스 환경에서 설치했으므로

curl -sSL install.astronomer.io | sudo bash -s

와 같이 설치해주었다.

설치 후에 초기화를 위해

  ~/coding/MLOps_study/week9 on   main ?2 ──────  max-env at  21:19:21 ─╮
❯ astro dev init                                                             ─╯
Initialized empty Astro project in /home/max/coding/MLOps_study/week9

astro dev init 을 진행해준다.

이를 진행해주면

위 사진과 같은 디렉토리 구조가 형성된다.

참고하는 강의(Complete MLOps Bootcamp With 10+ End to End ML Projects)에서 강사는

여담

API -> Transformation(python code) -> (JSON 포맷) -> LOAD -> DB 의 파이프라인을 소개하고 있고 본 강의에서는 DB를 컨테이너애서 사용하고자 하나, 한 가지 덧붙이자면 실제 DB를 운영하고자 한다면 도커 컨테이너는 그닥 좋은 선택은 아니다.

파이프라인을 테스트하는 용도로는 괜찮으나 도커 컨테이너는 기본적으로 데이터를 지속시키고 안정적으로 유지하기보단 분리된 환경의 프로그램을 틀을 이용해 빠르게 찍어내고 운영할 수 있는 것에 가깝다.

애초에 바인드 마운트를 쓰지 않는 이상 컨테이너가 삭제되면 데이터는 날아가고, --rm 옵션을 붙였다면 컨테이너는 중지되기만 해도 날아가는 가변적인 것이니...게다가 로컬에 의존하게 되는 바인드 마운트를 테스트 밖의 범위에서 쓰는 것도 바람직하지 않으니 실 운영에서는 DB서버를 컨테이너가 아닌 따로 두는 것을 권장하는 편이며, 현재도 그렇게 하고 있다. (성능 이슈도 있고)

그러나 학습이나 테스트용으로 여러가지 애플리케이션의 상호작용을 테스트하고자 한다면 컨테이너와 도커 컴포즈는 꽤 괜찮은 선택이다.

Airflow Hooks

Airflow에서 Hook이란 커스텀하게 로직을 구현하거나 외부 시스템의 푸시 작업 흐름을 만들 때 사용하는 것이다. Webhook에서의 hook과 의미적으로 크게 다르지는 않아보인다.

강의에서는 Postgres 접근을 위한 훅을 사용하는데 Mysql에서도 가능하다.

따로 더 말할 것은 없고 그냥 쉽게 접근하게 해주는 무언가라서

from airflow.providers.postgres.hooks.postgres import PostgresHook

이 친구를 잘 써주면 되는것이다.

파이프라인

파이프라인을 요약하자면

1. 테이블이 없으면 만들고

2. API로 데이터를 추출해오고(추출 파이프라인, 여기서는 NASA API 사용)

3. 필요한 정보로 적절히 변환해주고

4. DB로 적재해준다.(여기서는 적재 공간으로 컨테이너에서 구르는 postgres 사용)

5. 그리고 데이터를 검증해주고

6. 마지막으로 태스크 의존성을 검증하는 과정이다.

코드로 본다면

from airflow import DAG
from airflow.providers.http.operators.http import SimpleHttpOperator
from airflow.decorators import task
from airflow.providers.postgres.hooks.postgres import PostgresHook
from airflow.utils.dates import days_ago
import json


## Define the DAG
with DAG(
    dag_id='nasa_apod_postgres',
    start_date=days_ago(1),
    schedule_interval='@daily',
    catchup=False

) as dag:

    ## step 1: Create the table if it doesnt exists

    @task
    def create_table():
        ## initialize the Postgreshook
        postgres_hook=PostgresHook(postgres_conn_id="my_postgres_connection")

        ## SQL query to create the table
        create_table_query="""
        CREATE TABLE IF NOT EXISTS apod_data (
            id SERIAL PRIMARY KEY,
            title VARCHAR(255),
            explanation TEXT,
            url TEXT,
            date DATE,
            media_type VARCHAR(50)
        );


        """
        ## Execute the table creation query
        postgres_hook.run(create_table_query)


    ## Step 2: Extract the NASA API Data(APOD)-Astronomy Picture of the Day[Extract pipeline]
    ## https://api.nasa.gov/planetary/apod?api_key=7BbRvxo8uuzas9U3ho1RwHQQCkZIZtJojRIr293q
    extract_apod=SimpleHttpOperator(
        task_id='extract_apod',
        http_conn_id='nasa_api',  ## Connection ID Defined In Airflow For NASA API
        endpoint='planetary/apod', ## NASA API enpoint for APOD
        method='GET',
        data={"api_key":"{{ conn.nasa_api.extra_dejson.api_key}}"}, ## USe the API Key from the connection
        response_filter=lambda response:response.json(), ## Convert response to json
    )



    ## Step 3: Transform the data(Pick the information that i need to save)
    @task
    def transform_apod_data(response):
        apod_data={
            'title': response.get('title', ''),
            'explanation': response.get('explanation', ''),
            'url': response.get('url', ''),
            'date': response.get('date', ''),
            'media_type': response.get('media_type', '')

        }
        return apod_data


    ## step 4:  Load the data into Postgres SQL
    @task
    def load_data_to_postgres(apod_data):
        ## Initialize the PostgresHook
        postgres_hook=PostgresHook(postgres_conn_id='my_postgres_connection')

        ## Define the SQL Insert Query

        insert_query = """
        INSERT INTO apod_data (title, explanation, url, date, media_type)
        VALUES (%s, %s, %s, %s, %s);
        """

        ## Execute the SQL Query

        postgres_hook.run(insert_query,parameters=(
            apod_data['title'],
            apod_data['explanation'],
            apod_data['url'],
            apod_data['date'],
            apod_data['media_type']


        ))



    ## step 5: Verify the data DBViewer


    ## step 6: Define the task dependencies
    ## Extract
    create_table() >> extract_apod  ## Ensure the table is create befor extraction
    api_response=extract_apod.output
    ## Transform
    transformed_data=transform_apod_data(api_response)
    ## Load
    load_data_to_postgres(transformed_data)

이러한 상황이다.

이 코드는 astro cli를 이용해 구축해준 디렉토리에서 dags/etl.py에 위치하도록 두면 된다.

이 과정도 마찬가지로 AWS EC2에 배포할 수 있다.

프로세스

동시성과 병렬성 개념 이전에 프로세스란 무엇인가? 이 책에서 프로세스란 특정 시간에 일부만 존재하는(시간적인 넓이를 갖는) 개념 으로 소개하고 있다.

프로세스는 4가지 상태를 가질 수 있는데:

• 실행 전 상태: 계산 실행 전의 상태. 실행 상태로 전이 가능

• 실행 상태: 계산 실행중의 상태. 대기 또는 계산 종료 상태로 전이 가능

• 대기 상태: 계산을 일시적으로 정지한 상태. 실행 상태로 전이 가능

• 종료 상태: 계산을 종료한 상태

프로세스는 실행 이후에 실행 상태와 대기 상태 간을 전이하다가 종료될 수 있는데, 계속 실행되지 않고 대기 상태로 전이하게 되는 이유로 아래 세 가지가 있다.

1. 데이터 도착을 기다리는 상황. 연산을 수행할 데이터가 아직 도착하지 않았다면 계산을 수행할 수 없다.

2. 계산 리소스를 기다리는 상황. 계산에 필요한 리소스가 현재 충분하지 않은 경우 리소스가 반환되어 계산이 가능해지는 상황을 기다려야 한다.

3. 타이머 등에 의해 자발적으로 대기 상태로 진입하는 경우. 이 경우 데이터와 리소스가 충분함에도 계산 조건(예: 시간)을 만족하지 않으면 대기 상태를 유지한다.

동시성

동시성이란 2개 이상의 프로세스가 동시에 계산을 진행하는 상태를 의미한다.

위 그림에서 $t_{0}$ 에서 $t_{1}$ 까지를 계산 중 상태 라고 정의한다.

계산 중 상태는 실행 상태 + 대기 상태, 즉 프로세스가 실행 시작 이후 종료되기까지의 시간이다.

따라서 이 계산 중인 시간이 겹치는 상황에서 동시에 실행되고 있다고 말할 수 있다. (개인적으로 실행과 계산 중의 개념이 다르기 때문에 동시에 실행한다는 표현이 헷갈릴 수 있다고 생각한다.)

책의 정의에선 동시를 아래와 같이 설명하고 있다.

동시: 시각 $t$에서 여러 프로세스 $p_{0} ... p_{n}$이 계산 중인 상태에 있을 때 프로세스 $p_{0} ... p_{n}$ 이 동시에 실행되고 있다고 한다.

따라서 위 그림에서 프로세스 A와 B는 $(t_{0}, t_{1})$에 동시에 실행되고 있는 것이다.

병렬성

동시성 프로그래밍 책에서 병렬성은 같은 시각에서 여러 프로세스가 동시에 계산을 실행하는 상태를 의미한다고 정의한다.

동시성과의 차이가 있다면 병렬성은 실행 상태가 겹치는 순간만을 포함한다. 대기 상태가 겹치거나, 하나가 실행 상태, 다른 하나가 대기 상태에 있는 것과 같은 상황은 포함되지 않는다.

병렬성에는 크게 세 가지 종류가 있는데

• 태스크 병렬성

• 데이터 병렬성

• 인스트럭션 레벨 병렬성 이 있다.

태스크 병렬성

앞에서 본 그림은 태스크 병렬성이다. 태스크 병렬성은 여러 태스크(프로세스)가 동시에 실행되는 것을 의미한다.

데이터 병렬성

데이터를 여러 개로 나눠서 병렬로 처리하는 방법이다.

이건 연산기가 한 개인 경우에서 수행되는 계산의 상황인데, 연산기가 4개라면 각각의 덧셈을 각각의 연산기에서 수행해서 더 빠르게 연산할 수 있다. 이를 벡터 연산 이라 한다.

이러한 벡터 연산은 CPU가 제공하는 벡터 연산 명령으로도 구현될 수 있지만 아까의 연산기 4개를 4개의 스레드로 실행해도 구현할 수 있다.

그런데 이것처럼 계산량이 적은 문제는 오히려 스레드를 생성하는 데에 들어가는 오버헤드로 인해 더 느려질 수 있다. (항상 좋은 것이 아니다!)

응답 속도와 처리량

계산속도에는

1. 응답 속도

2. 처리량 이라는 두 가지 척도로 계산할 수 있다. 정리하자면

응답 속도: 정의: 계산 시작부터 마칠 때까지의 시간 척도: CPU 클록 수, 소비 CPU 인스트럭션 수 -> 시간으로 표현 가능

처리량: 정의: 단위 시간당 실행 가능한 계산량

암달의 법칙

암달의 법칙이란 일부 처리의 병렬화가 전체적으로 고속화에 어느 정도 영향을 미치는지 예측하는 법칙이다.

수식으로는 1(1−P)+PN

로 나타낸다. (P: 전체 프로그램 중 병렬화 가능한 처리의 비율, N: 병렬화 수)

이 식은 병렬화를 위한 오버헤드가 없는 상태에서의 성능 향상률을 나타낸다.

이제 병렬화에 사용되는 오버헤드를 고려한다면

1H+(1−P)+PN 가 될 것이다.( H: 오버헤드의 응답 속도와 순차 실행했을 때 응답 속도의 비율)

이것을 산술적으로 계산하는 게 중요하다기보다는 병렬화 수를 바꿨을 때 얼마나 성능이 향상되는지를 확인할 수 있다는 것이다.

그래프로는

이렇게 나온다.

눈에 띄는 것은 P = 1.0 즉 전체 병렬화 가능한 처리인 경우 병렬화 수 N일 때 N만큼 빨라진다.

그러나 병렬화 불가능한 처리가 있는 경우 고속화 자체는 될지언정 그 배율이 작아진다는 것이다. 한마디로 늘린만큼 좋아지진 않는다.

인스트럭션 레벨 병렬성

인스트럭션 레벨 병렬성이란 CPU의 명령어 레벨에서의 병렬화이다.

주로 하드웨어나 컴파일러가 이것을 수행하게 되고 프로그래머가 여기까지 고려하는 것은 루프 전개나 데이터 프리패치 이외에는 흔치 않다.

그러나 대체로 컴파일러가 최적화를 수행하는 경우가 대부분이므로 컴파일러 설계가 아닌 이상 자주 볼 일은 많지 않다.

그런 이유로 파이프라인 처리 개념을 위주로 다루고 넘어가자.

파이프라인 처리

CPU의 명령 실행은 다음 5가지로 나눌 수 있다.

• 명령 읽기(IF)

• 명령 해석(ID)

• 실행(EX)

• 메모리 엑세스(MEM)

• 쓰기(WB)

11011(2+3 계산 후 addr[1]과 a 레지스터에 결과를 저장) 수행의 과정을 각각의 과정으로 나눠보면 위와 같이 시각화할 수 있다.

1. IF로 메모리상의 명령을 읽어 버킷에 명령을 저장한다.

2. ID: 버킷 내 명령을 해석한다.

3. 2+3이 계산되고 5로 치환된다.

4. 메모리 엑세스: addr[1]에 결과가 쓰인다.

5. 쓰기: a 레지스터에 결과가 쓰인다.

의 과정인 것이다.

위는 간소화한 설명이지만 실제 파이프라인 처리에서도 각 클록에서 처리를 실행하는 단계 이외에는 아무것도 수행하지 않는다. 자기가 일하는 시간 외에는 놀고 있는 것이다. 이들을 놀지 않게 두려면 여러 인스트럭션을 병렬로 주면 되는 것이다.

이상적인 상황에서 단순 계산을 하자면 처리량은 파이프라인 수의 배율만큼(위에서는 5개니 5배만큼.) 향상되겠지만 현실에서는 데이터 의존 관계 등의 조건으로 인해 5배까지는 향상되지 않는 경우가 대부분이다.

이렇게 데이터 의존 관계 등으로 인스트럭션 레벨에서 병렬 실행할 수 없는 상태를 파이프라인 해저드라고 한다.

따라서 컴파일러를 만들어야한다면 이러한 파이프라인 해저드까지 처리를 해야하는 것이다. 그러나 컴파일러를 여기서 만들지는 않으므로...

파이프라인 해저드의 종류

3가지 종류가 있는데:

구조 해저드 하드웨어적으로 병렬 실행할 수 없는 명령을 실행했을 때 발생한다. 예를 들어 하드웨어적으로 동시에 메모리 접근을 할 수 없다면 구조 해저드가 된다.

데이터 해저드 위에서 말한 데이터 의존 관계에 의해 병렬 실행이 불가능할 때의 이야기이다. 명령 1의 연산 결과를 명령 2가 사용하는 경우 데이터 해저드이다.

제어 해저드 조건 분기가 있을 때 발생한다. 명령 1이 조건 분기이고 이 조건에 따라 명령2의 실행 여부가 결정되는 상황이라면 제어 해저드이다.

동시 처리와 병렬 처리의 필요성

동시 처리와 병렬 처리가 왜 필요하냐는 내용에 대해서이다.

먼저

병렬 처리와 성능 향상

병렬 처리는 성능 향상을 위해 필요하다. 그런데 아까 알아본 3가지 병렬성 중 데이터 병렬성과 인스트럭션 병렬성은 컴파일러나 하드웨어 차원에서 수행된다. 그래서 여기서 주로 다루는 것은 태스크 병렬성 처리이다.

결과적으로는 소프트웨어 차원에서도 병렬성(적어도 태스크 병렬성)은 의식해야된다는 내용인데, 하드웨어 기술의 한계로 소프트웨어에서도 이것을 의식해야한다는 것이다.

동시 처리의 필요성과 계산 경로 수 급증

동시 처리는 효율적인 계산 리소스 활용, 공평성, 편리성이 필요성이라고 할 수 있다.

효율적인 계산 리소스 활용: IO 대기 상태 중 다른 일 가능 공평성: 여러 작업을 한 쪽에 치우치지 않고 동시 작업 가능(예: 노래 들으면서 웹서핑하기)

그런데 동시 처리가 무조건 좋은 것은 아니다. 동시 처리는 복잡하다.

이유는 동시 처리의 계산 경로가 순차적으로 수행할 때보다 크게 늘어나기 때문이다. 동시 처리 시 계산 조합 수는 $n!$ 이 된다.

C

책에서는 어셈블리를 다루지만 내용이 매우 간단하고 약소한 관계로 C 위주로 설명한다.

Pthreads

C언어에서는 기본 라이브러리에 스레드를 다루는 기능이 제공되지 않아서 외부 라이브러리가 필요하다. Pthreads란 POSIX 표준 인터페이스를 갖춘 스레드 라이브러리를 총칭한다고 한다.

//Pthreads를 사용하기 위해 pthreads.h를 읽어야한다.
#include <pthread.h> 
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#define NUM_THREADS 10 // 생성할 스레드 수

// 스레드용 함수
void *thread_func(void *arg) { 
    int id = (int)arg; 
    for (int i = 0; i < 5; i++) { 
        printf("id = %d, i = %d\n", id, i);
        sleep(1);
    }

    return "finished!"; // 반환값
}

int main(int argc, char *argv[]) {
    // 스레드용 핸들러 저장 배열.
    pthread_t v[NUM_THREADS]; 
    // 스레드 생성 
    for (int i = 0; i < NUM_THREADS; i++) {
        if (pthread_create(&v[i], NULL, thread_func, (void *)i) != 0) {
            perror("pthread_create");
            return -1;
        }
    }

    // 스레드 종료 대기 
    for (int i = 0; i < NUM_THREADS; i++) {
        char *ptr;
        if (pthread_join(v[i], (void **)&ptr) == 0) {
            printf("msg = %s\n", ptr);
        } else {
            perror("pthread_join");
            return -1;
        }
    }

    return 0;
}

디태치 스레드

앞에서는 스레드 종료를 pthread_join 함수에서 기다렸는데 이것으로 종료하지 않으면 메모리 누출이 된다.

그런데 스레드 종료 시 자동으로 스레드용 리소스를 해제하는 방법도 있는데 이것을 디태치 스레드라고 한다.

두 가지 방법으로 스레드를 디태치 스레드로 만들 수 있는데

1. pthread_create 함수 호출 시 어트리뷰트로 지정

2. pthread_detach함수 호출

#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

// 스레드용 함수
void *thread_func(void *arg) {
    for (int i = 0; i < 5; i++) {
        printf("i = %d\n", i);
        sleep(1);
    }
    return NULL;
}

int main(int argc, char *argv[]) {
    // 어트리뷰트 초기화 
    pthread_attr_t attr;
    if (pthread_attr_init(&attr) != 0) {
        perror("pthread_attr_init");
        return -1;
    }

    // 디태치 스레드로 설정 
    if (pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED) != 0) {
        perror("pthread_attr_setdetachstate");
        return -1;
    }

    // 어트리뷰터를 지정해 스레드 생성
    pthread_t th;
    if (pthread_create(&th, &attr, thread_func, NULL) != 0) {
        perror("pthread_join");
        return -1;
    }

    // 어트리뷰트 파기
    if (pthread_attr_destroy(&attr) != 0) {
        perror("pthread_attr_destroy");
        return -1;
    }

    sleep(7);

    return 0;
}

volatile 수식자

volatile 수식자를 이용하면 컴파일러의 최적화를 억제한 메모리 접근을 구현할 수 있다.

최적화를 왜 억제하냐 하겠지만 컴파일러가 느린 메모리 접근을 억제하기 위해 레지스터에 복사해서 값을 이용하는 작업이 메모리 값 감시 시에는 장애가 될 수도 있다.

사용법은 간단하다.

void wait_while_0(int *p) {
    while (*p == 0) {}
}

에서 int *p 앞에 volatile만 붙여주면 된다.

void wait_while_0(volatile int *p) {
    while (*p == 0) {}
}

이런 식이다.

스택 메모리와 힙 메모리

이 부분은 러스츠 소유권 이해하기에서 가져왔다.

스택

스택은 후입선출(last in first out)방식으로 값을 처리한다. 입출구가 하나인 통처럼 맨 꼭대기에서 무언가를 집어넣고 꺼내는 것은 가능하지만 중간과 아래에 있는 것은 바로 건드릴 수 없다. 스택에 저장될 데이터는 모두 명확하고 크기가 정해져 있어야 한다. 컴파일 타임에 크기를 알 수 없거나 크기가 변할 수 있는 데이터는 힙에 저장되어야 한다.

함수를 호출하면 호출한 함수에 넘겨준 값과 해당 함수의 로컬 변수들이 스택에 들어가고, 이 데이터들은 함수가 종료될 때 팝된다.

힙

데이터에 힙을 넣을 때 절차는 다음과 같다.

1. 저장할 공간이 있는지 운영체제에 물어보고

2. 메모리 할당자가 힙 영역 내에서 빈 지점을 찾는다.

3. 아까 발견한 빈 지점을 사용 중이라고 표시하고

4. 그 지점을 가리키는 포인터를 반환한다.

이 전체 과정을 힙 공간 할당이라고 한다.

레스토랑에 비유하자면

1. 레스토랑에 방문하는 인원수를 수용할 좌석이 있는지 묻는다.

2. 직원은 빈 테이블을 찾아서

3. 테이블이 사용 중임으로 상태를 바꾸고(비유가 이상하긴 한데 다른 손님이 들어왔을 때 여전히 빈 테이블이라고 하지는 않을테니까...)

4. 손님에게 테이블 위치를 안내할 것이다.

라고 할 수 있다.

힙 영역은 포인터가 가리키는 곳을 찾아가는 과정 때문에 느려진다. 힙에 있는 데이터들은 붙어 있는 것이 아니라 이곳 저곳에 떨어져 있는데 이렇게 되면 프로세서가 돌아다니면서 데이터들을 처리해야하기 때문에 느리다.

Why Docker container?

ML 프로젝트들을 하다보면 특정 라이브러리에 의존하게 되는 경우가 많은데, 배포하려는 경우 환경도 라이브러리 버전, 운영체제 및 기타 환경들을 똑같이 맞춰주지 않으면 프로그램이 정상적으로 동작하지 않는다. 이러한 문제점을 해결하기 위해 가상머신들을 쓰곤 했고 아직도 가상머신이 많이 쓰이고 있다.

그러나 가상머신도 문제점들이 존재하는데...그러나 공통적으로는 가상머신이 너무 무겁기 때문에 일어나는 일들이다. 가상머신은 무겁기 때문에

1. 옮기기 어렵고

2. 그 자체로 리소스의 낭비가 있다고 볼 수 있다.

환경 분리를 하면서도 이것을 더 가볍게 쓰기 위해 나온 기술이 도커 컨테이너라고 할 수 있겠다.

도커에서 사용하는 컨테이너라는 개념은 실제 컨테이너와 거의 유사하다. 다만 물건이 아니라 애플리케이션을 담고 있을 뿐이다. 그런데 이 컨테이너 안에는 실제 컴퓨터처럼 호스트명, IP 주소, 디스크 드라이브도 들어있고 호스트 머신의 것들과 다르다.

이건 도커가 호스트명과 IP 주소, 파일 시스템까지 가상 리소스를 만들어 컨테이너에 넣어두었기 때문이다.

Container vs VM

컨테이너와 가상 머신의 차이점은 간단하다. 가상 머신은 호스트 머신의 운영체제를 공유하지 않고 별도의 운영체제를 필요로 한다. 그러나 컨테이너는 호스트 머신의 운영체제를 사용한다.

예를 들어 가상머신 A와 B가 있다고 할 때 A와 B는 별도의 운영체제를 필요로 하기 때문에 호스트 머신까지 합해 운영체제가 총 3개 필요하다.

그러나 컨테이너는 호스트 머신의 운영체제만으로 충분하다.(적어도 리눅스 머신에서는)

운영체제는 그 자체로 무거운 프로그램이다. 운영체제가 중복 설치된다는 점이 리소스 측면에서는 전혀 바람직한 상황은 아니다. 컨테이너는 서로 다른 호스트명 IP주소 디스크 드라이브를 가지는 환경들을 생성하면서도 운영체제는 공유하는 방식을 사용한다. 따라서 필요한 리소스가 확연하게 줄어들게 된다.

그래서 컨테이너는 실행도 빠르고 같은 호스트 컴퓨터에도 가상머신보다 더 많은 수를 올릴 수 있다. 일반적으로 5배 더 많이 올릴 수 있다고 한다. 리소스에서 운영체제가 차지하는 비율이 높을수록 수가 더 차이날 것으로 볼 수 있다.

Docker Image vs Docker container

실제로 애플리케이션이 구동되는 공간은 컨테이너이고, 이미지는 컨테이너를 찍어내기 위한 틀이다.

이 둘의 관계는 클래스-인스턴스와도 꽤나 비슷하다. 클래스는 인스턴스를 찍어낼 수 있지만 인스턴스를 생성하지 않고서는 그 자체로 기능을 수행하는 것은 아니다.

마찬가지로 이미지로 컨테이너들을 찍어낼 수 있지만 이미지만으로는 애플리케이션을 돌릴 수 없다.

이미지는 그야말로 컨테이너를 찍어내기 위한 틀이기 때문에 공유가 가능하다. 이런 공유는 도커 허브에서 이루어진다.

아래에서 조금 더 설명하겠지만 실제로 구조가 틀로 무언가를 찍어내는 그런 느낌은 사실 아니기는 하다....

도커 이미지 좀 더 알아보기

이미지의 구조

도커 이미지는 레이어로 구성된다. 도커는 매번 명령을 캐싱해두었다가 이미지를 다시 빌드할 때 캐싱된 결과를 가져와서 사용한다.

이미지를 빌드할 때 도커는 명령문들을 실행하면서 데이터를 독립적으로 저장하게 되는데, 이 저장된 데이터들이 레이어이다. 이런 환경 정보에 대한 레이어들은 읽기 전용이라 임의로 변경할 수 없다.

그리고 도커 컨테이너가 실행되면 읽기 전용 레이어들을 순서대로 쌓은 다음 마지막에 쓰기 가능한 레이어를 추가하는데, 컨테이너에서 발생한 일들은 이 쓰기 가능한 마지막 레이어에 기록되게 된다.

그림으로는 이러한 식인 것이다.

도커파일 더 효율적으로 작성하기

도커 이미지가 레이어로 저장된다는 것을 알아야 하는 이유가 있는데

한줄요약하자면 도커가 레이어인지 뭔지 그런 걸 가지고 있어서 데이터가 캐싱되니까 매번 명령을 처음부터 실행하는 것이 아니라는 건데, 이걸 알면 도커파일을 더 효율적으로 작성할 수 있다는 거다.

예를 들자면 js앱을 만들고 있는데 app/ 디렉토리의 코드에 뭔갈 변경했기 때문에 이미지를 다시 빌드하고자 하는 상황이다. 그런데 도커파일이

FROM node

WORKDIR /app

COPY . /app

RUN npm install

EXPOSE 80

CMD ["node", "server.js"]

이렇게 되어있다고 에러가 나거나 큰 일이 벌어지는 건 아니지만 의존성에 변화가 없다면 COPY . /app부터 코드의 변화로 변경사항이 생기게 되는데 이러면 의존성을 다시 설치하느라 느리다.

FROM node

WORKDIR /app

COPY package.json /app

RUN npm install

COPY . /app

EXPOSE 80

CMD ["node", "server.js"]

그러니까 이렇게 짜는 것이 더 낫다는 것이다. 의존성은 상대적으로 변화 가능성이 적고 설치 자체도 매우 오래걸리므로 코드 카피를 뒤에 두고, 의존성은 캐싱된 결과 쓰자는 것이다. 그러면 대체로 더 효율적으로 만들 수 있다.

도커 명령어

명령어는....일단 이 글에서는 자세하게 다룰 마음이 없다. 일단 help치면 다 나오기도 하고...어차피 구글링의 영역이니. 도커를 공부하면서도 매번 잊어먹기 때문에 항상 찾아보고 있다. 이것은 잘 정리된 블로그를 참고하길 바란다.

내 블로그로 말하자면 https://maximizemaxwell.com/docker-images-container#heading-14 를 참고하길 바란다...

도커 컴포즈

도커 컴포즈는 여러 개의 컨테이너로 구성된 애플리케이션을 단일 도커 엔진 호스트에서 실행하기 위한 도구이다.

여러 개의 컨테이너를 굴리다보면 이걸 명령어를 일일히 쳐서 하기가 상당히 번거로운데, 명령어에 붙는 그런 부가적인 옵션을 한 파일에 몰아넣은 녀석을 docker-compose.yaml라고 하는 것이다.

도커 컴포즈 파일 설계하기

오버라이드 파일을 이용한 도커 컴포즈 설계에 대해 소개하는 내용을 조금 갖고 왔다.

여러 가지 설정으로 애플리케이션을 실행하고 싶을 수 있는데 대부분의 경우 컴포즈 파일을 여러 개 둔다고 한다. 그런데 컴포즈 파일을 각각 작성하게 된다면 대부분의 내용이 사실상 중복인데, 수정 시 이 부분이 누락된다거나 하면 문제가 생기므로 유지 보수 측면에서 좋지 않다고 하는 것이다.

도커 컴포즈는 여러 파일을 합쳐 컴포즈 파일을 구성할 수 있는데, 나중에 지정된 파일의 내용이 이전 파일의 내용을 덮어쓰기(오버라이드)한다.

그렇다면

• docker-compose.yaml: services(기본 컴포즈 파일. 공통적 정의)

• docker-compose-dev.yaml: services, networks(개발 환경용)

• docker-compose-test.yaml: services, networks, volumes(테스트용)

• docker-compose-uat.yaml: 사용자 인수 테스트 대상

해당 파일에 각각 기능에 필요한 것만 추가하고

docker container rm -f $(docker container ls -aq)

docker-compose -f ./numbers/docker-compose.yml -f ./numbers/docker-compose-dev.yml -p numbers-dev up -d
//개발 환경용

docker-compose -f ./numbers/docker-compose.yml -f ./numbers/docker-compose-test.yml -p numbers-test up -d
//테스트 환경용

docker-compose -f ./numbers/docker-compose.yml -f ./numbers/docker-compose-uat.yml -p numbers-uat up -d
//인수 테스트 환경용

이런 식으로 각각의 환경을 만들 수 있겠다는 내용이다.

여기서는 MLFLOW, Dagshub, DVC를 이용해 모델을 트랙킹하는 것을 실제로 진행하는 과정을 보여준다. 우선 결론부터

├── data
│   ├── processed
│   │   └── data.csv
│   └── raw
│       ├── data.csv
│       └── data.csv.dvc
├── dvc.lock
├── dvc.yaml
├── models
│   └── model.pkl
├── params.yaml
├── README.md
├── requirements.txt
└── src
    ├── evaluate.py
    ├── __init__.py
    ├── preprocess.py
    └── train.py

6 directories, 13 files

이러한 디렉토리 구조의 프로그램을 작성하고 이를 관리한다.

우선 params.yaml에 preprocess 관련 데이터셋과 train의 데이터셋과 파라미터를 집어넣는다.

결과적으로

preprocess:
  input: data/raw/data.csv
  output: data/processed/data.csv

train:
  data: data/raw/data.csv
  model: models/model.pkl
  random_state: 42
  n_estimators: 100
  max_depth: 5

이러한 형태를 바탕으로 하고, 이 yaml 파일을 읽어와서 이후의 전처리와 학습에 사용하게 된다.

따라서 preprocess.py 파일에서

import pandas as pd
import sys
import yaml
import os

## Load parameters from param.yaml

params=yaml.safe_load(open("params.yaml"))['preprocess']

def preprocess(input_path,output_path):
    data=pd.read_csv(input_path)

    os.makedirs(os.path.dirname(output_path),exist_ok=True)
    data.to_csv(output_path,header=None,index=False)
    print(f"Preprocesses data saved to {output_path}")

if __name__=="__main__":
    preprocess(params["input"],params["output"])

이러한 식으로 yaml을 읽어와서 전처리하게 된다. 이 파일을 실행하면 처음의 전체 디렉토리 구조에서 봤던 preprocessed/data.csv가 생성된다.

데이터의 전처리가 끝났다면 다음은 모델 차례다.

모델은 train과 evaluate 두 과정으로 진행되는데

train.py는

import os
import pickle
from urllib.parse import urlparse

import dagshub
import mlflow
import pandas as pd
import yaml
from mlflow.models import infer_signature
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import accuracy_score, classification_report, confusion_matrix
from sklearn.model_selection import GridSearchCV, train_test_split

# Initialize dagshub integration
dagshub.init(repo_owner="maximizemaxwell", repo_name="MLOps-pipeline", mlflow=True)


def hyperparameter_tuning(X_train, y_train, param_grid):
    rf = RandomForestClassifier()
    grid_search = GridSearchCV(
        estimator=rf, param_grid=param_grid, cv=3, n_jobs=-1, verbose=2
    )
    grid_search.fit(X_train, y_train)
    return grid_search


def train(data_path: str, model_path: str):
    # Load data
    data = pd.read_csv(data_path, header=None)
    X = data.iloc[:, :-1]
    y = data.iloc[:, -1]

    # Set MLflow URI (redundant with dagshub.init, can skip if you trust dagshub setup)
    mlflow.set_tracking_uri("https://dagshub.com/maximizemaxwell/MLOps-pipeline.mlflow")

    with mlflow.start_run():
        # Train-test split
        X_train, X_test, y_train, y_test = train_test_split(
            X, y, test_size=0.2, random_state=42
        )
        signature = infer_signature(X_train, y_train)

        # Define hyperparameter grid
        param_grid = {
            "n_estimators": [100, 200],
            "max_depth": [5, 10, None],
            "min_samples_split": [2, 5],
            "min_samples_leaf": [1, 2],
        }

        # Hyperparameter tuning
        grid_search = hyperparameter_tuning(X_train, y_train, param_grid)
        best_model = grid_search.best_estimator_

        # Evaluation
        y_pred = best_model.predict(X_test)
        accuracy = accuracy_score(y_test, y_pred)
        print(f"Accuracy: {accuracy}")

        # Logging metrics and parameters
        mlflow.log_metric("accuracy", accuracy)
        for key, val in grid_search.best_params_.items():
            mlflow.log_param(key, val)

        # Log confusion matrix and classification report as artifacts
        os.makedirs("artifacts", exist_ok=True)
        with open("artifacts/confusion_matrix.txt", "w") as f:
            f.write(str(confusion_matrix(y_test, y_pred)))
        with open("artifacts/classification_report.txt", "w") as f:
            f.write(classification_report(y_test, y_pred))

        mlflow.log_artifact("artifacts/confusion_matrix.txt")
        mlflow.log_artifact("artifacts/classification_report.txt")

        # Model logging
        if urlparse(mlflow.get_tracking_uri()).scheme != "file":
            mlflow.sklearn.log_model(
                best_model, "model", registered_model_name="Best_Model"
            )
        else:
            mlflow.sklearn.log_model(best_model, "model", signature=signature)

        # Save locally
        os.makedirs(os.path.dirname(model_path), exist_ok=True)
        with open(model_path, "wb") as f:
            pickle.dump(best_model, f)
        print(f"Model saved to {model_path}")


if __name__ == "__main__":
    params = yaml.safe_load(open("../params.yaml"))["train"]
    train(params["data"], params["model"])

과 같은 식으로 구성하였다. 참고한 유데미 강의의 코드와 dagshub연동 부분이 다르고 경로의 차이가 조금 있다.

이 코드를 실행하게 되면 models/디렉토리에 pkl 파일이 생성됨을 볼 수 있다.

코드를 실행하면

...
[CV] END max_depth=None, min_samples_leaf=1, min_samples_split=2, n_estimators=200; total time=   1.2s
[CV] END max_depth=None, min_samples_leaf=2, min_samples_split=2, n_estimators=200; total time=   0.7s
[CV] END max_depth=None, min_samples_leaf=2, min_samples_split=5, n_estimators=200; total time=   0.5s
[CV] END max_depth=None, min_samples_leaf=2, min_samples_split=5, n_estimators=200; total time=   0.6s
[CV] END max_depth=None, min_samples_leaf=2, min_samples_split=5, n_estimators=200; total time=   0.5s
Accuracy: 0.7532467532467533

이런 식으로 Accuracy가 출력되는데, 돌아가서 dagshub의 experiment에 가보면

이런 식으로 똑같이 기록된다.

그러면 다음으로 evaluate.py는

import os
import pickle
from urllib.parse import urlparse

import dagshub
import mlflow
import pandas as pd
import yaml
from sklearn.metrics import accuracy_score

# Initialize dagshub integration
dagshub.init(repo_owner="maximizemaxwell", repo_name="MLOps-pipeline", mlflow=True)
# Get absolute path to params.yaml (in project root)
params_path = os.path.join(os.path.dirname(__file__), "..", "params.yaml")
params = yaml.safe_load(open(params_path))["train"]

# Full data/model path
data_path = os.path.join(os.path.dirname(__file__), "..", params["data"])
model_path = os.path.join(os.path.dirname(__file__), "..", params["model"])


def evaluate(data_path, model_path):
    # Column names (based on PIMA dataset)
    cols = [
        "Pregnancies",
        "Glucose",
        "BloodPressure",
        "SkinThickness",
        "Insulin",
        "BMI",
        "DiabetesPedigreeFunction",
        "Age",
        "Outcome",
    ]
    data = pd.read_csv(data_path, names=cols, header=None)
    X = data.drop(columns=["Outcome"])
    y = data["Outcome"]

    # Use your own DagsHub tracking URI
    mlflow.set_tracking_uri("https://dagshub.com/maximizemaxwell/MLOps-pipeline.mlflow")

    model = pickle.load(open(model_path, "rb"))

    predictions = model.predict(X)
    accuracy = accuracy_score(y, predictions)

    # Log to MLflow
    mlflow.log_metric("eval_accuracy", accuracy)
    print(f"Model accuracy: {accuracy:.4f}")


if __name__ == "__main__":
    evaluate(data_path, model_path)

이런 식으로 쓸 수 있겠고,

  warnings.warn(
Model accuracy: 0.9505
🏃 View run clumsy-goose-362 at: https://dagshub.com/maximizemaxwell/MLOps-pipeline.mlflow/#/experiments/0/runs/ddc3b5707ec448ec8c465d41a0956487
🧪 View experiment at: https://dagshub.com/maximizemaxwell/MLOps-pipeline.mlflow/#/experiments/0

실행결과를 확인할 수 있다.

다시 dagshub으로 돌아가서

evaluate 실험도 여기서 accuracy를 확인할 수 있다.

MLFLOW with AWS

지금까지는 실험 추적과 버전 관리를 dagshub에 올렸으나, aws 클라우드에 데이터사이언스 프로젝트를 호스팅하여 똑같이 실험과정을 진행하고 싶을 수 있다.

실험 추적은 S3 버킷에 기록되고, 이것은 다시 aws EC2 인스턴스로 들어간다. 따라서 아래와 같은 app.py를 작성할 수 있다.

import os
import sys

import pandas as pd
import numpy as np
from sklearn.metrics import mean_squared_error, mean_absolute_error, r2_score
from sklearn.model_selection import train_test_split
from sklearn.linear_model import ElasticNet
from urllib.parse import urlparse
import mlflow
from mlflow.models.signature import infer_signature
import mlflow.sklearn 

import logging

import os

os.environ["MLFLOW_TRACKING_URI"]="http://ec2-54-158-152-207.compute-1.amazonaws.com:5000/"

logging.basicConfig(level=logging.WARN)
logger = logging.getLogger(__name__)

def eval_metrics(actual,pred):
    rmse=np.sqrt(mean_squared_error(actual,pred))
    mae=mean_absolute_error(actual,pred)
    r2=r2_score(actual,pred)
    return rmse,mae,r2


if __name__=="__main__":

    ## Data Ingestion-Reading the dataset-- wine quality dataset

    csv_url=(
        "https://raw.githubusercontent.com/mlflow/mlflow/master/tests/datasets/winequality-red.csv"
    )


    try:
        data=pd.read_csv(csv_url,sep=";")
    except Exception as e:
        logger.exception("Unable to download the data")

    # Split the data in train and test

    train,test=train_test_split(data)

    train_x = train.drop(["quality"], axis=1)
    test_x = test.drop(["quality"], axis=1)
    train_y = train[["quality"]]
    test_y = test[["quality"]]

    alpha = float(sys.argv[1]) if len(sys.argv) > 1 else 0.5
    l1_ratio = float(sys.argv[2]) if len(sys.argv) > 2 else 0.5

    with mlflow.start_run():
        lr=ElasticNet(alpha=alpha,l1_ratio=l1_ratio,random_state=42)
        lr.fit(train_x,train_y)

        predicted_qualities = lr.predict(test_x)
        (rmse, mae, r2) = eval_metrics(test_y, predicted_qualities)

        print("Elasticnet model (alpha={:f}, l1_ratio={:f}):".format(alpha, l1_ratio))
        print("  RMSE: %s" % rmse)
        print("  MAE: %s" % mae)
        print("  R2: %s" % r2)

        mlflow.log_param("alpha", alpha)
        mlflow.log_param("l1_ratio", l1_ratio)
        mlflow.log_metric("rmse", rmse)
        mlflow.log_metric("r2", r2)
        mlflow.log_metric("mae", mae)


        ## For the remote server AWS we need to do the setup

        remote_server_uri="http://ec2-54-158-152-207.compute-1.amazonaws.com:5000/"
        mlflow.set_tracking_uri(remote_server_uri)

        tracking_url_type_store = urlparse(mlflow.get_tracking_uri()).scheme


        if tracking_url_type_store!="file":
            mlflow.sklearn.log_model(
                lr,"model",registered_model_name="ElasticnetWineModel"
            )
        else:
            mlflow.sklearn.log_model(lr,"model")

컨테이너가 충돌하는 이슈로 프로그램이 crashed될 수 있다. 이런 경우에 새 컨테이너를 다시 실행해야 하는데, 큰 애플리케이션에서 이런 작업은 상당히 불편하다. 그리고 트래픽이 많은 경우 하나의 기능을 수행하는 컨테이너를 하나만 쓰는 것이 아니라 컨테이너의 수를 조정하고 컨테이너들에 트래픽을 분산시킬 필요가 있다.

What is Kubernetes?

위에서 언급한 문제들은 aws의 auto-scaling, load-balancer등을 이용해 자동으로 처리할 수 있었다. 이러한 설정들을 적용하면 aws내에서는 문제를 해결할 수 있으나, 다른 클라우드 서비스에서는 작동하지 않을 수 있다. 예컨대 Google Cloud같은 곳에서는 또 다른 설정을 적용해야 할 수 있다.

물론 특정 클라우드 서비스만 사용하겠다면 큰 문제가 없을 수 있지만, 클라우드 플랫폼에 종속되지 않고 자동 배포를 도와줄 오픈소스 시스템이 있다. 이게 쿠버네티스이다.

쿠버네티스도 자동 배포, 스케일링, 로드 밸런싱, 관리에 필요한 기능들이 존재한다.

아까 클라우드 플랫폼과 쿠버네티스를 비교했지만 쿠버네티스는 클라우드 플랫폼들의 대체재가 아니다. 자동 배포와 관리에 필요한 기능들과 개념들이 모여있는 오픈 소스 프로그램일 뿐이지, 클라우드 프로바이더는 따로 제공되어야 한다. 다만 aws든 다른 클라우드 플랫폼이든, 온프레미스 환경이든 쿠버네티스라는 공통적 시스템을 이용하여 관리할 수 있다는 데 의의가 있다.

쿠버네티스는 도커의 대체재도 아니다. 쿠버네티스를 사용해 도커를 관리하고 자동 배포할 수 있는 것이다. 그래서 요약하자면 쿠버네티스는 여러 머신에서 사용할 수 있는 docker-compose같은 개념이라고 볼 수 있는 것이다.

Kubernetes 아키텍처

포드(Pod)

쿠버네티스는 여러 가지 개념과 구성 요소로 되어있는데, 우선 포드라는 게 있다. 포드는 하나 또는 그 이상의 애플리케이션 컨테이너들의 그룹을 나타내는 쿠버네티스의 추상적 개념이다. 쿠버네티스 세계에서는 이 포드가 최소 단위가 된다. 포드는 컨테이너의 자원들을 공유할 수 있는데,

• 공유 스토리지(ex: 볼륨)

• 네트워킹(ex: 클러스터 IP 주소)

• 컨테이너가 동작하는 방식에 대한 정보(ex: 컨테이너 이미지 버전, 사용할 특정 포트) 와 같은 자원들을 공유할 수 있다고 한다.

워커 노드(Workder Node)

포드에서 컨테이너 그룹을 나타냈다. 그럼 이 컨테이너들은 어디에서 실제로 실행되는가? 이에 대한 대답이 워커 노드라고 할 수 있다. 이렇게 보면 워커 노드는 일종의 인스턴스와 같은 개념이라고 할 수 있다.

프록시(Proxy)

또 다른 구성 요소로 프록시가 있다. 이는 워커 노드의 포드 네트워크 트래픽의 제어를 설정하는 도구이다. 그러니까, 프록시는 포드가 인터넷에 연결할 수 있는지의 여부와 외부에서 컨테이너를 어떻게 접근할 수 있는지와 같은 세팅을 제어할 수 있게 해준다고 보면 된다.

마스터 노드(Master Node)

쿠버네티스는 트래픽에 따라 컨테이너의 수를 조정한다. 트래픽에 따라 포드와 컨테이너를 만들고 실행 가능한 워커 노드에서 실행시키는 작업을 해야한다. 반대로 필요하지 않은 경우에는 줄이고 교체하는 작업도 필요하다.

이런 작업은 마스터 노드에 의해 이루어진다. 정확히는 마스터 노드가 호출하는 컨트롤 플레인(Control Plane)에 일어난다.

이런 작업을 마스터 노드와 컨트롤 플레인이 수행한다면 개발자는 뭘 하는가?

개발자는 원하는 종료 상태를 설정하면 쿠버네티스가 이를 고려하여 관리한다.

여기서 컨트롤 플레인이 실제로 무엇이냐 하면 마스터 노드에서 실행하는 다양한 서비스와 도구 모음이라고 할 수 있다.

클러스터(Cluster)

이렇게 마스터 노드와 컨트롤 플레인, 워커 노드들과 포드들이 구성된 단위를 클러스터라고 한다. AWS에서 설명하기론 컨테이너화된 애플리케이션을 실행하는 컴퓨팅 노드 또는 작업자 머신이라고 표현하고 있다.

위는 AWS에서 클러스터 연결에 대해 표현하고 있는 그림이다.

Node 좀 더 살펴보기

DVC는 Data Version Control의 약자로 모델이나 데이터 버전 관리에 사용되는 툴이다.

설치는

pip install dvc

로 진행하고

git과 마찬가지로

dvc init

을 통해 dvc가 버전을 관리할 수 있도록 한다.

dvc init을 진행해주면 .dvc 디렉토리가 생기고 tmp, .gitignore, config 등의 파일과 디렉토리가 생기는 것을 확인할 수 있다.

dvc의 사용법은 git과 거의 같은데

dvc add 'data/data.txt'

을 통해 추적할 파일을 추가할 수 있다. 그런데 dvc add를 수행해주게 되면 .dvc파일이 생성되게 되는데, 위의 경우 data/data.txt.dvc가 생성된다.

내부를 열어보면

outs:
- md5: 0b1ebceb88b6324cafbda936c7500e37
  size: 6
  hash: md5
  path: data.txt

와 같이 생겼다. md5는 해시 키인데, 이 해시 값은 특정 데이터에 매핑된다. 그러니까, 데이터를 변경하고 다시 dvc를 통해 .dvc 파일을 생성해주면 이 해시 값은 변경된다.

이 해시 값들은 루트 디렉토리에 있는 .dvc/cache 안에서도 찾아볼 수 있다.

data/data.txt 파일의 내용을 변경한 후 다시 dvc add 커맨드를 입력해보았다. 그 결과

outs:
- md5: cf1044dbd9d6a2055b7a1f0356a31399
  size: 31
  hash: md5
  path: data.txt

파일이 변경되었기 때문에 해시 값이 달라진 것을 볼 수 있다. 이렇게 달라지는 해시 값들을 기반으로 파일을 트랙킹하고 있다고 볼 수 있다.

Flask

Flask 시작하기

flask를 돌리기 위해 우선 flask를 설치해주어야한다.

from flask import Flask

app = Flask(__name__)


@app.route("/")
def welcome():
    return "Welcome to this Flask course"


@app.route("/index")
def welcome_index():
    return "Welcome to this index page"


if __name__ == "__main__":
    app.run()

위 형식의 코드를 돌리면 웹브라우저에서 코드에 적어준 메시지들을 확인할 수 있다.

app.run() 부분에 app.run(debug=True) 옵션으로 설정해주면 서버 재시작 없이도 변경사항을 바로바로 반영할 수 있다.

GET vs POST

Flask에서도 당연하겠지만 GET & POST를 이용해 클라이언트로부터 데이터를 받는데 둘의 차이점을 써보자면 아래와 같다.

GET: 주로 데이터 조회를 위해 사용 POST: 주로 데이터 생성, 변경, 삭제 등의 요청에 사용

Jinja2 템플릿 엔진

Jinja2는 Flask 패키지에 내장된 템플릿 엔진이다. 동적 웹 페이지를 구성할 때 서버에서 곧바로 웹페이지 로딩과 동시에 변수 값을 할당해준다. 아래 문법에 따라 HTML 문서 상에서 반복문, 조건문을 사용 가능하다.

작성법:

{{ }} expressions to print output in html
{%...%} conditions, for loops
{#..#} this is for comments

Dynamic URL

웹페이지를 이동할 때 다음 페이지의 URL을 url_for() 함수에 넣어서 전달하거나 route 함수명을 넣어서 해당 route가 가지는 url 주소를 가져올 수 있다.

따라서 URL을 하드코딩하는 대신 url_for에 함수 이름을 전달해서 정확한 URL을 얻을 수도 있는 것이다.

@app.route('/submit',methods=['POST','GET'])
def submit():
    total_score=0
    if request.method=='POST':
        science=float(request.form['science'])
        maths=float(request.form['maths'])
        c=float(request.form['c'])
        data_science=float(request.form['datascience'])

        total_score=(science+maths+c+data_science)/4
    else:
        return render_template('getresult.html')
    return redirect(url_for('successres',score=total_score))