State (상태)
웹이 점점 발전하면서 유저와 상호작용하는 요소, 보여지는 요소가 많아지게 되었다. 이런 요소 들은 유저가 보는 화면을 변화시킨다. 화면을 변화시키는 것들을 '상태'라고 정의 할 수 있다.
예를 들어서 랜딩 페이지 같은 정보성 웹페이지 인 경우에 '상태'라고 할 수 있는건 보여줄 정보 하나이다.
다음으로 깃헙 같은 경우에는 내 정보, 내 레포지토리 정보, star 수 등 다양한 정보들이 있는데 이들에 따라 유저에게 보여질 화면이 달라지기 때문에 이 들을 모두 '상태'라고 볼 수 있다.
더 복잡한 예시로, 피그마 같은 예시를 들 수 있다. 화면에 모든 점, 선, 면등 그래픽들은 모두 '상태'이다. 게다가 협업 기능은 나 이외의 다른 사람의 상태까지도 공유해야한다.
State & Data
상태는 모두 데이터다. 유저에 대한 정보, 유저 맞춤 정보 등 모두 어딘가 저장되어 있는 데이터이고 이 데이터는 곧 유저가 보는 화면의 상태가 된다. 보통 이 데이터라는 건 서버에 Single Source of Truth 로 저장된다. 어떤 웹사이트에 로그인을 했다면 그 사이트의 서버의 users 테이블에 하나의 행으로 저장될 것이다.
Data is too far
최근 웹은 복잡하다. 버튼은 셀 수 없을 만큼 많고, 한 화면에 보여주는 데이터도 많다. 시의성이 중요한 정보들도 많다. 이 상태들이 변경될 때 마다 데이터의 정합성을 위해 서버에 왔다 갔다 해야한다. 도큐먼트처럼 1분에 '다음페이지'만 받아오면 되는 경우에는 큰 문제가 되지 않는다. 하지만 노션같이 유저가 계속 데이터를 수정하는 경우라면 큰 문제가 된다. 페이지에서 특성같은 걸 설정할 때마다 로딩 해야 한다면 속이 뒤집어 질 것이다.
Optimistic Update
인스타그램 같은 소셜 미디어 사이트에서 좋아요를 누르는 것을 생각해보자. 좋아요를 누르면 서버에 가서 내가 그 포스트를 좋아요 했다는 정보를 저장하고, 그 포스트의 좋아요 숫자를 하나 올려준 다음, 현재 포스트의 좋아요를 가져와서 나한테 보여줘야 한다.
하지만 인스타그램은 0.001초 만에 애니메이션과 함께 좋아요가 눌리고 카운트가 올라간다.
이는 서버에 정보가 도달하기도 전에 클라이언트의 상태를 업데이트 하는 것으로 가능하다. 좋아요를 누른 데이터가 서버에 잘 기록되겠지 하고 클라이언트의 상태를 업데이트하는 것이다. 대부분의 경우에는 서버와의 통신이 성공할 것이기 때문에 이를 낙관적으로 성공이라고 판단하는 것이다.
물론 서버에 보낸 요청이 실패할 경우도 있기 때문에, 실패할 시 클라이언트의 상태를 롤백하는 것은 신경 써주어야한다.
Responsiveness Over Consistency
내가 좋아요를 눌렀는지 아닌지를 Optimistic 하게 보여주는 건 매우 합리적이다. 근데 내가 누를 때 다른 사람도 눌러서 좋아요가 1개 이상 늘었을 수도 있는데 이건 어떻게 처리하는 걸까.
이건 그냥 데이터 정합성을 약간 무시하는 것으로 간단하게 해결이 된다. 그 게시글이 인기 게시글이라면 내가 포스트를 보는 그 시간 동안 좋아요 개수가 안늘었을 리가 없다. 이건 그냥 그 소프트웨어의 정책이다. 빠른 응답을 위해서 약간의 데이터 정합성은 희생하는 것이다.
CAP theorem
분산 시스템 학문에는 CAP 이론이 있다. 이 이론은 분산 시스템을 구성할 때 C, A, P 중 최대 두개만 취할 수 있다는 이론이다.
C는 Consistency로 정합성이다. 어떤 노드에서 데이터를 읽던지 간에 같은 데이터를 읽어야한다.
A는 Availability로 어떤 노드가 죽더라도 모든 요청에 응답할 수 있는 가 이다.
P는 Partition-tolerance로 몇 노드의 네트워크 연결이 끊기는 경우에 동작할 수 있는가, 네트워크 연결 후에 다시 복구할 수 있는가 이다.
이 이론에 따르면 결국 CA, AP, CP 이렇게 세가지의 시스템이 가능하다.
CA
이론상은 분산 시스템이 CA를 택할 수 있지만, 네트워크 연결이 끊기면 동작하지 않는 시스템은 우리는 분산 시스템이라고 부르지 않기로 했다.
결국 분산 시스템이라면 P는 보장되어야한다.
AP
Availability Over Consistency
몇 노드의 네트워크 연결이 끊어졌을 때, 모든 노드가 그 값의 최신 상태에 대해서 동의하지 않았더라도 일단 연결되어 있는 노드의 값을 내려주는 것이다. 그렇기 때문에 끊어져있는 노드들 간에 최신 데이터는 일치하지 않을 수 있다. 하지만 사용자는 마치 최신의 데이터를 받는 것 처럼 서비스를 계속 이용할 수 있다.
대표적인 예시는 소셜미디어이다. 현실에서는 일어나지 않을 법한 일이지만, 유럽에 있는 인스타그램의 노드들과 아시아의 노들들의 네트워크 연결이 끊어져버렸다고 가정하자. 아시아에서 접근하는 유저들과 유럽에서 접근하는 유저가 보는 팔로우수, 좋아요 수 등은 이 장애기간동안 조금 달라도 괜찮다. 하지만 기능은 여전히 동작해야할 것 이다.
CP
Consistency Over Availability
네트워크 장애 상황에 최신 데이터에 대해서 확신을 할 수 없는 상황에서, 유저의 요청에 응답하지 않는 시스템이다.
예시는 보통 돈(거래)과 관련된 것들이다. 50%할인 하는 호텔 방이 하나 남은 상황에서 네트워크 단절이 일어났다고 하자. AP시스템에서는 둘 다 방이 있겠거니 하고 예약을 받아서 오버부킹을 받아버릴 가능성이 있다. CP 시스템은 이 데이터의 최신 상태에 대해서 확신할 수 없으니, 이에 대한 요청을 연기 시키거나 거부한다.
PACELC Theorem
CAP 이론은 사실 Partition에 대한 이론이다. 만약 Partition이 일어났다면 A나 C를 택해야한다는 것이다.
근데 사실 보통의 상황의 경우 Partition은 일어나지 않는다. 그런 상황에서 적용할 수 있는 이론이 PACELC 이론이다.
if (P) then (AC) else (LC)
즉, Partition인 경우에는 AC를 고려하고 아니면 LC를 고려하라는 뜻이다.
LC
Latency & Consistency
보통의 상황에서 시스템은 Latency와 Consistency를 trade off 한다. 거창하게 이론이지만 사실 이건 컴퓨터 공학 전반에 걸친 진리 같은 것이다.
Trade off를 생각한다는 것은 이 두가지 기준의 어느 정도로 타협을 본다는 것을 의미한다.
Latency는 느림에서 빠름의 정도를 직관적으로 알 수 있는데 Consistency는 어떤 정도를 가지는 지 직관적으로 알기는 힘들다.
Strong Consistency
강한 정합성은 이름만 들어도 감이 잡힌다. 그 어떤 노드로 접근하든 무조건 같은 데이터를 봐야한다. 즉 모든 노드가 같은 데이터를 가지고 있어야 가능한 Consistency이다.
은행을 생각해보면 될 것 같다.
Eventual Consistency
언젠가는 정합함 이라는 이름의 정합성이다. 어떤 변경점에 대해서 같은 시각 모든 클라이언트가 같은 값을 보지는 않지만, 동기화가 끝난 후엔 결국 같은 값을 보게 된다는 뜻이다.
따라서 소프트웨어의 특성에 따라서 Latency를 희생하면서 정합성을 챙길 것이냐 아니면 빠른 응답을 위해 정합성을 희생할 것이냐가 결정된다.
Top comments (0)