신뢰성

신뢰성은 믿고 맡긴 일이 틀어지지 않는다는 성질입니다. 그런데 무엇을 믿고 맡기느냐에 따라 뜻이 둘로 갈립니다. 운영에서는 시스템이 오랫동안 멈추지 않고 제 일을 하는 성질을 말합니다. 네트워크에서는 보낸 데이터가 빠짐없이 순서대로 도착하게 해 주는 성질을 말합니다.

쉽고 빠른 이해

무슨 일을 하는 물건인가 — 「이거 믿어도 되나」에 답하는 성질입니다. 서버가 한 달 동안 한 번도 안 죽었다면 운영의 뜻으로 신뢰성이 높습니다. 파일을 보냈는데 한 바이트도 안 빠지고 순서대로 왔다면 전송의 뜻으로 신뢰성이 있습니다.

왜 따로 챙기나 — 부품은 언젠가 고장 납니다. 네트워크는 데이터를 잃어버립니다. 그냥 두면 서비스가 수시로 멈춥니다. 받은 데이터에도 구멍이 납니다.

어떻게 도나

운영에서는 고장이 얼마나 자주 나는지 잽니다. 그 간격을 늘리려고 애씁니다
전송에서는 받는 쪽이 「잘 받았다」고 답하게 합니다
답이 안 오면 보내는 쪽이 같은 데이터를 다시 보냅니다

대가 — 운영에서는 고장을 줄이는 데 돈과 시간이 듭니다. 끝까지 올릴수록 값이 가파르게 뛰어오릅니다. 전송에서는 답을 기다리고 다시 보내느라 느려집니다. 그래서 음성 통화처럼 늦게 온 데이터가 쓸모없는 곳에서는 전송의 신뢰성을 일부러 포기하기도 합니다.

상세

이 절은 두 뜻을 표로 가른 뒤 하나씩 따라갑니다. 끝에서 두 뜻이 서로를 보장하지 않는 경우와 어느 뜻인지 가르는 단서를 모읍니다.

두 뜻

두 뜻은 믿는 대상이 다릅니다. 한쪽은 시간이 흐르는 동안 시스템 전체가 버티는지를 봅니다. 다른 쪽은 데이터 한 번 보내는 동안 그 데이터가 온전한지를 봅니다.

맥락	무엇을 믿나	틀어지는 모습	어떻게 지키나
시스템 운영	서비스가 멈추지 않고 제 일을 한다	서버가 죽는다 · 틀린 응답을 낸다	고장을 덜 나게 만들고, 나면 빨리 알아챈다
데이터 전송	보낸 바이트가 그대로 도착한다	빠진다 · 망가진다 · 두 번 온다 · 순서가 뒤바뀐다	받았다는 답을 받고, 안 오면 다시 보낸다

표의 두 줄은 서로를 대신하지 못합니다. 전송이 믿을 만해도 서버가 죽으면 서비스는 멈춥니다. 시스템이 오래 버텨도 그 안에서 데이터를 잃는 전송을 쓸 수 있습니다.

두 뜻이 섞이면 대화가 어긋납니다. 한 사람은 서버가 안 죽는 이야기를 합니다. 다른 사람은 데이터가 안 빠지는 이야기를 합니다.

시스템 운영에서 말하는 신뢰성

운영에서 말하는 신뢰성은 시스템이 정해진 조건에서 정해진 기간 동안 고장 없이 제 일을 해내는 성질입니다. 핵심은 「연속」입니다. 얼마나 오래 끊기지 않고 버티느냐를 봅니다.

엘리베이터로 생각해 볼 수 있습니다. 믿을 만한 엘리베이터는 몇 달이고 멈추지 않습니다. 고장 수리가 아무리 빨라도 매일 한 번씩 멈추는 엘리베이터는 믿고 타기 어렵습니다.

여기서 말하는 고장은 꺼지는 것만이 아닙니다. 켜져 있어도 틀린 값을 돌려주면 제 일을 못 한 것입니다. 장애는 이렇게 사용자가 기대한 결과를 못 받는 상태를 두루 가리킵니다.

신뢰성은 고장 사이의 간격으로 잽니다. 고장과 다음 고장 사이에 평균 얼마나 돌았는지를 MTBF(Mean Time Between Failures, 평균 고장 간격)라고 부릅니다. MTBF 가 길수록 신뢰성이 높습니다.

고장이 난 뒤 되살리는 데 걸리는 평균 시간은 MTTR(Mean Time To Repair, 평균 수리 시간)이라고 부릅니다. MTTR 은 고장이 얼마나 드문지가 아니라 고장 뒤에 얼마나 빨리 돌아오는지를 잽니다. 그래서 MTTR 은 신뢰성을 재는 값이 아닙니다.

stateDiagram-v2
    정상동작: 정상 동작
    고장: 고장
    정상동작 --> 고장: 평균 MTBF 만큼 돌다가 죽는다
    고장 --> 정상동작: 평균 MTTR 만큼 걸려 되살린다

그림에서 고장으로 가는 MTBF 화살표가 길수록 신뢰성이 높습니다. 정상으로 돌아오는 MTTR 화살표가 짧을수록 빨리 돌아옵니다. 두 값은 따로 움직입니다.

가용성은 전체 시간 가운데 시스템이 요청을 받아낼 수 있었던 시간의 비율입니다. 신뢰성은 한 번에 얼마나 오래 안 끊기느냐를 봅니다. 가용성은 모두 합쳐 얼마나 오래 떠 있었느냐를 봅니다. 그래서 둘은 같은 말이 아닙니다.

가용성은 두 값으로 이렇게 구합니다.

가용성 = MTBF ÷ (MTBF + MTTR)

말로 풀면 「돈 시간 ÷ (돈 시간 + 고치는 시간)」입니다. 고장이 잦아도 금방 돌아오면 가용성은 높게 나옵니다.

두 서버를 견주면 차이가 보입니다.

	서버 A	서버 B
멈추는 빈도	한 시간에 한 번	일 년에 한 번
한 번 멈추는 시간	1초	하루
신뢰성	낮다 · 자꾸 끊긴다	높다 · 좀처럼 안 끊긴다
가용성	높다 · 멈춘 시간 합이 짧다	A 보다 낮다 · 한 번이 길다

긴 결제 한 건이 도중에 끊기면 곤란한 서비스라면 A 가 더 아픕니다. 잠깐 끊겨도 다시 시도하면 되는 서비스라면 B 의 긴 공백이 더 아픕니다. 어느 값을 먼저 챙길지는 서비스가 정합니다.

신뢰성을 올리는 길은 크게 둘입니다. 부품 하나하나를 덜 고장 나게 만드는 길이 하나입니다. 같은 일을 하는 것을 여러 벌 두어 하나가 죽어도 전체는 버티게 하는 길이 다른 하나입니다. 이 길을 다중화라고 부릅니다.

다중화는 가용성도 함께 올립니다. 한 벌이 죽어도 남은 벌이 요청을 계속 받아 주기 때문입니다. 그래서 다중화로 요청을 끊기지 않게 받아 내는 구성을 고가용성 구성이라고 부릅니다.

어느 길이든 끝까지 올릴수록 값이 가파르게 비싸집니다. 그래서 실무에서는 「이만큼이면 된다」는 목표를 먼저 정합니다. 「한 달 동안 요청의 몇 퍼센트는 성공한다」 같은 목표입니다. 이런 목표를 서비스 수준 목표라고 부릅니다.

이런 목표를 세우고 지키는 일만 따로 맡는 직무도 있습니다. 그 직무가 사이트 신뢰성 엔지니어링입니다.

데이터 전송에서 말하는 신뢰성

네트워크는 데이터를 통째로 나르지 않습니다. 잘게 자른 덩어리에 주소를 붙여 따로따로 나릅니다. 이 덩어리를 패킷이라고 부릅니다.

네트워크는 이 패킷을 잃어버립니다. 도중의 장비가 바빠서 패킷을 버리기도 합니다. 전기 잡음에 비트가 뒤집히기도 합니다. 길이 여럿이면 늦게 출발한 패킷이 먼저 도착하기도 합니다.

전송에서 말하는 신뢰성은 이런 네트워크 위에서도 받는 프로그램이 보낸 바이트를 빠짐없이, 망가지지 않게, 한 번씩만, 보낸 순서대로 받게 해 주는 성질입니다. 이 약속을 해 주는 전송을 「신뢰성 있는 전송」이라고 부릅니다.

전송은 프로그램이 넘긴 바이트 흐름을 조각으로 잘라 패킷에 실어 보냅니다. 받는 쪽은 조각을 다시 이어 붙여 원래 흐름으로 되돌립니다. 아래에서 「조각」은 이렇게 잘린 한 덩이를 말합니다.

등기 우편을 떠올리면 됩니다. 받는 사람이 서명해야 배달이 끝납니다. 서명이 안 돌아오면 우체국이 다시 보냅니다.

이 약속은 장치 네 가지로 지킵니다. 넷은 각각 틀어지는 모습 하나씩을 막습니다.

장치	무엇을 막나	하는 일
체크섬	망가짐	내용으로 짧은 검산값을 만들어 같이 보내고, 받는 쪽이 다시 계산해 맞춰 본다
순서 번호	순서 뒤바뀜 · 두 번 옴	조각마다 번호를 붙여 받는 쪽이 줄 세우고 겹친 것을 버린다
확인 응답	빠짐을 모르고 지나감	받는 쪽이 「어디까지 받았다」고 답한다
재전송	빠짐	정해진 시간 안에 답이 없으면 보내는 쪽이 다시 보낸다

답을 얼마나 기다릴지 정한 시간을 타임아웃이라고 부릅니다. 아래 그림은 두 번째 조각이 사라졌을 때 이 장치들이 어떻게 맞물리는지를 보입니다.

sequenceDiagram
    participant 보내는쪽
    participant 받는쪽
    보내는쪽->>받는쪽: 1번 조각
    받는쪽-->>보내는쪽: 1번까지 받았다
    보내는쪽-x받는쪽: 2번 조각 · 도중에 사라진다
    Note over 보내는쪽: 타임아웃이 지나도 답이 없다
    보내는쪽->>받는쪽: 2번 조각을 다시 보낸다
    받는쪽-->>보내는쪽: 2번까지 받았다

보내는 쪽은 2번 조각이 사라졌다는 것을 직접 보지 못합니다. 답이 안 온다는 사실로 짐작할 뿐입니다. 그래서 조각은 멀쩡히 갔는데 답만 사라진 경우에도 다시 보냅니다. 받는 쪽은 순서 번호로 겹친 조각을 걸러 냅니다.

TCP(Transmission Control Protocol, 전송 제어 프로토콜)가 이 네 장치를 모두 갖춘 대표 프로토콜입니다. UDP(User Datagram Protocol, 사용자 데이터그램 프로토콜)는 체크섬만 두고 나머지를 맡지 않습니다.

UDP 처럼 받았는지 확인하지 않고 한 번 보내고 끝내는 방식을 최선 노력 전달이라고 부릅니다. 할 수 있는 만큼은 나릅니다. 못 날랐을 때는 책임지지 않습니다.

신뢰성이 필요한데 UDP 를 써야 한다면 그 위에서 장치를 직접 만들어 넣습니다. QUIC(퀵)이라는 전송 프로토콜은 UDP 위에서 순서 번호와 확인 응답과 재전송을 스스로 구현해 신뢰성 있는 전송을 줍니다.

신뢰성 있는 전송도 도착 자체를 약속하지는 못합니다. 케이블이 뽑히면 아무리 다시 보내도 닿지 않습니다. 그때는 끝내 연결을 끊고 보낸 프로그램에 실패를 알립니다. 약속하는 것은 「도착한 것은 온전하고 순서가 맞다, 못 보냈으면 알려 준다」까지입니다.

대가는 속도입니다. 답을 기다리고 다시 보내는 동안 뒤 조각도 줄 서서 기다립니다. 음성 통화나 게임처럼 늦게 온 데이터가 쓸모없는 응용은 이 대가를 피하려고 신뢰성 없는 전송을 고르기도 합니다.

두 뜻이 서로를 보장하지 않을 때

두 뜻은 이름이 같아서 한쪽이 다른 쪽을 채워 주는 것처럼 들립니다. 실은 한 요청 안에서도 따로 깨집니다.

주문 서버에 요청을 보낸다고 해 봅시다. TCP 연결 위라서 요청 바이트는 온전히 도착합니다. 전송의 신뢰성은 지켜졌습니다. 그런데 서버가 요청을 처리하던 중에 죽으면 주문은 안 들어갑니다. 운영의 신뢰성이 깨진 것입니다.

반대 방향도 있습니다. 주문은 처리됐는데 응답이 돌아오는 길에 연결이 끊기면 클라이언트는 결과를 모릅니다. 새 연결을 열어 다시 보내면 주문이 두 번 들어갈 수 있습니다.

전송이 이 중복을 못 거르는 까닭은 순서 번호에 있습니다. 순서 번호는 연결마다 새로 매깁니다. 새 연결은 앞 연결에서 무엇이 오갔는지 모릅니다. 그래서 전송이 걸러 주는 중복은 연결 하나 안의 것뿐입니다.

그래서 애플리케이션은 두 뜻을 따로 챙깁니다. 서버를 여러 벌 두어 운영의 신뢰성을 받칩니다. 같은 요청을 여러 번 받아도 결과가 한 번과 같게 만들어 재시도를 안전하게 합니다. 뒤쪽 성질을 멱등성이라고 부릅니다.

어느 뜻인지 가르는 단서

대화나 문서에서 「신뢰성」이 나오면 함께 붙은 낱말을 봅니다. 대개 그것만으로 어느 뜻인지 갈립니다.

함께 나오는 말	뜻
장애 · 가동 시간 · MTBF · 가용성 · 서비스 수준 목표	시스템 운영
신뢰성을 높인다 · 신뢰성 목표 · 신뢰성 엔지니어링	시스템 운영
신뢰성 있는 전송 · 신뢰성 없는 프로토콜	데이터 전송
재전송 · 확인 응답 · 순서 보장 · TCP 와 UDP	데이터 전송

「신뢰성 있는」·「신뢰성 없는」처럼 꾸미는 말로 붙으면 대개 전송의 뜻입니다. 「신뢰성을 올린다」처럼 크기를 말하면 대개 운영의 뜻입니다.

프로그램 사이에서 메시지를 맡아 두었다 넘겨 주는 메시지 큐에서도 「메시지를 신뢰성 있게 전달한다」고 말합니다. 전송의 뜻을 애플리케이션 사이로 넓힌 말입니다. 이 말만으로는 무엇을 약속하는지 모자라서 하나를 되물어 보는 편이 낫습니다. 잃지 않는 대신 두 번 올 수 있는지(최소 한 번 전달), 두 번 안 오는 대신 잃을 수 있는지(최대 한 번 전달)입니다.

상세

두 뜻

시스템 운영에서 말하는 신뢰성

데이터 전송에서 말하는 신뢰성

두 뜻이 서로를 보장하지 않을 때

어느 뜻인지 가르는 단서

관련 항목

운영 신뢰성과 나란히 재는 성질

운영 신뢰성을 재는 지표와 목표

운영 신뢰성을 받치는 구성과 직무

신뢰성 있는 전송을 이루는 장치

신뢰성을 두고 갈리는 전송 프로토콜

전송 신뢰성을 애플리케이션까지 넓히는 전달 보장