[Erlang] OTP: Let It Crash

Let It Crash는 Erlang을 상징하는 표어다.

Erlang은 멀티프로세스 기반의 동시성 구조를 기반으로 높은 가용성을 추구하는데, Erlang의 가용성 지향 방식은 유지나 처리량 최적화보단 빠른 복구에 있다는 것이 특별한 점이다.

이런 지향점 덕분에 느리지만 안정적인 시스템을 설계하는 데에 용이하고, 실제로도 통신 분야에 한해서는 꽤 지배적으로 사용되고 있다. 그거 말고는 전멸이긴 하다만...

특징

기본적인 지향점/원리는 다음과 같다.

1. 로직에 뭔가 오류가 발생하면, 복잡하게 오류처리를 하지 않고 그냥 그 프로세스를 죽여버린다.

2. 프로세스가 죽으면, 최상위 supervisor 프로세스가 그걸 탐지해서 프로세스를 다시 실행한다.

이를 통해 가용성 문제를 비교적 쉽고 단순하게 풀겠다는 것이다.
실제로 Erlang은 언어 자체에서 복잡한 방어적 코드 작성을 권장하지 않는다. 그냥 죽여버리라는 것이다.

코드로 예를 들어보자면, 대부분의 언어에서는 다음과 같은 지루하고 현학적인 예외처리가 수반된다.

try {
    // 수많은 예외 처리 코드
    result = risky_operation();
    if (result == null) {
        handle_null();
    }
    if (result < 0) {
        handle_negative();
    }
    // ... 더 많은 조건 검사
} catch (SomeException e) {
    // 복구 시도
} catch (AnotherException e) {
    // 다른 복구 시도
} finally {
    // 정리 작업
}

Erlang에서는 이걸 좀 더 단순하게 푼다.

execute_task(Type, Args) ->
    % 예외 처리 없음 - crash하면 Supervisor가 재시작
    [H | T] = get_list(Type, Args),  % 비어있으면 crash
    Result = 100 div Args,            % 0이면 crash
    {ok, Result}.

%% Supervisor가 자동으로 재시작
supervise(Worker) ->
    monitor(Worker),
    receive
        {'DOWN', ...} -> start_new_worker()
    end.

코드 수준에서는 좀 더 간결해지고, 신경쓸 부분이 적어지긴 한다.

게다가 Erlang은 언어 자체에서 멀티노드 분산 구성을 지원하기도 한다.
여러개의 장비들에서 워커 프로세스를 병렬로 실행하고 감독할 수 있는 것이다.

이런 단순성과 높은 가용성 보장 덕에, 부분적인 실패를 허용하고 전체 시스템 수준의 다운타임을 극도로 억제할 수 있다는 장점이 있다. 그래서 매우 높은 가용성을 유지해야하는 산업에서는 은근히 애용되고 있다.

문제

그렇다고 이게 장점만 있을까? 그러면 모든 시스템이 OTP의 방법론을 수용해서 사용했을 것이다.

이건 어떻게 보면 게으른 방법론이다.
단순한 하드웨어 수준의 일시적 장애고, 재시작해서 해결이 되는 문제라면 Erlang의 방법론도 효과적일 수 있다.

하지만 재시작만으로 해결되지 않는 영구적인 문제거나, 본질적인 해결이 요구되는 문제라면 이 방법은 역효과를 일으킬 수 있다. 진짜로 오류 처리를 해서 명확한 처리를 해야하는 지점도 많이 존재한다.
게다가 디버깅에 용이하지도 않고, 프로세스 재시작에서 발생하는 성능 낭비도 있다.

사실 무엇보다 Erlang이 외면받은 가장 큰 이유는, 저열한 연산 성능도 있다. 내가 예전에 실험해보기로 단순한 처리 성능은 메이저한 언어 중에서 독보적으로 느렸다.

개념의 확장

Let It Crash라는 개념 자체는 어떻게 보면 여타 분산시스템들의 지향성과도 크게 다르지 않다.

쿠버네티스는 stateless한 구조를 지향하며, 서버가 언제든 다운될 것이라 가정하고 서버를 재시작할 준비를 한다. 쿠버의 마스터 노드가 supervisor의 역할을 하는 셈이다. 가벼운 프로세스가 아닌 컨테이너 수준에서 이뤄지는 복구라는 것이 다른 점이지만, 핵심 접근법은 비스무리하다.
Erlang은 이를 언어 수준에서 지원할 뿐이다.

꼭 Erlang이 아니어도 되고, Erlang을 쓴다고 해서 견고한 프로그램이 나오는 건 아니다.

참조
https://wiki.c2.com/?LetItCrash
https://stackoverflow.com/questions/4393197/erlangs-let-it-crash-philosophy-applicable-elsewhere