전체 글 (8) 썸네일형 리스트형 분산시스템(Distributed System) - 6 - 3(Replica Consistency) Eventual Consistency 앞서 공부한 Linearizability는 많은 repilca가 존재하여도 하나인 거처럼 동작하도록 보장하기 때문에 분산 시스템에서 엄청 좋은 consistency 모델이다. 하지만 이러한 시스템을 만들기 위해서는 그만한 비용이 들기 때문에 모든 application에서 적합한 방법은 아니다. (사실 모든 것이 이렇다고 본다 소프트웨어 개발은 항상 trade off인 거 같다 이것을 잘하기 위해 공부를 해야 하는 것 같고) performance 측면에서는 Linearizable 한 모델은 너무 많은 메시지를 주고받아야 하고 그로 인하여 latency가 증가한다 그리고 scalability측면에서는 순서를 위해서는 하나의 리더를 통해야 하는데 리더는 병목이 될 수 있다. availability 한 측면에서.. 분산시스템(Distributed System) - 6 - 2(Replica Consistency) Linearizability 여러 노드들로부터 concurrent 하게 데이터를 이용하고 업데이트를 할 때 어떻게 노드가 up-to-date인 상태를 보는 것을 보장할 수 있을까? Linearizability 란 여러 노드에서 동시에 발생한 여러 사건 들을 하나의 시간축에 넣는 것?이라고 이해를 했다. 아래 그림의 상태는 linearizable하지 않은 상태이다. 클라이언트 A가 노드 A에 t1이란 시간에 set을 했다. 그리고 직후에 클라이언트 B와 C가 데이터를 읽으려고 시도하는데 노드 A를 포함하여 요청을 보낸 클라이언트 2는 클라이언트A가 수정한 값을 볼 수 있지만, 더 늦게 요청을 보낸 클라이언트 C는 받지 못하는 상황이다. 이것이 linearizable 하다고 하려면 client2가 변경된 새로운 값인 v2를 받은 이후에.. 분산시스템(Distributed System) - 6 - 1(Replica Consistency)Two-phase commit Two-phase commit(2PC)는 여러 노드 사이에서 atomic commitment를 보장하는 가장 대중적인 알고리즘이다. 클라이언트에서 트랜잭션을 시작하면 다른 replica들도 참여를 하고 commit 할 준비가 되면 coordinator에게 요청을 보낸다. (coordinator는 2pc를 관리하는 역할을 하는데 시스템에 따라 클라이언트의 일부로 존재하는 경우도 있다.) 요청을 받은 coordinator는 prepare메시지를 트랜잭션에 참여하고 있는 모든 replica들에게 보낸다. 그리고 replica들은 commit이 가능한지 여부를 보낸다. 이것이 첫 번째 phase이다. 이때 commit은 하지않지만 coordinator에서 OK요청이 오면 무조건 commit을 하는 것을 보장해야.. 분산시스템(Distributed System) - 5(Consensus) 앞선 포스트에서 분산시스템에서 메시지의 순서를 보장하기 위해 FIFO-total-order-broadcast를 이용하였다. 위의 알고리즘을 이용하게 되면 리더에서 순서를 정하고 메시지를 분배해줄 리더의 존재가 필요했고 SPOF의 문제가 생기게 되었다. 이 문제를 해결한다면 Fault-tolerant total order broadcast가 되고 state machine replication에 적용하여 fault-tolerance한 분산시스템을 만들 수 있게 된다. 간단하게 생각하면 replication에서 처럼 리더도 여러개를 두고 하나가 죽는다면 다른 리더를 세우는 방식을 하면 된다. 그럼 이 리더들의 싱크를 어떻게 맞추고 이중에 어떤 노드를 리더로 세울까? 리더를 선출하는 것을 Consensus라하는.. 분산시스템(Distributed System) - 4(Replication) Replication이란 fault tolerance한 분산시스템을 만들기 위해 데이터의 카피를 여러 노드에 복사해서 관리하는 것이다. 하나의 노드가 죽거나 문제가 생기더라도 다른 노드에 같은 데이터를 가지고 있기 때문에 시스템은 중단이나 문제없이 계속 실행이 될 수 있다. 하지만 데이터는 계속 변화가 있을 것이고 이를 모든 replica에 적용을 하고 유지하는 것은 쉽지 않다. 이번 강의에서는 latency 등은 고려하지 않고 순수하게 여러 노드에서 데이터를 일정하게 유지하려면 어떻게 해볼까를 다루고 있다. 왜 어려울까? 여러 노드에서 데이터를 관리한다는것은 모든 노드의 데이터 싱크를 맞추어야 한다는 것과 같은 말이다. 클라이언트에서 데이터 변경 또는 읽는 요청을 보낼 때 어떤 각 노드의 데이터가 다르.. 분산시스템(Distributed System) - 3(Broadcast) Broadcast는 그룹 통신이다. 하나의 노드에서 메시지를 발송한다면 그룹안에 모든 노드들은 메시지를 받는다. 그리고 reliable하다 죽지않은 노드에게는 메시지 누락없이 전송된다. 그룹에 속한노드는 고정될수도 있고 다이나믹하게 변할수도있지만 노드의 추가 및 제거에는 정해진 원칙(mechanism)을 가질것이다. 그룹내의 하나의 노드가 죽어도 나머지는 계속 돌아간다. 메시지의 latency에 대하여 제한을 두지 않는다. broadcast를 하기 위해 unicast인 네트워크에서 broadcast를 하기 위해 위의 그림처럼 인터넷과 어플리케이션 사이에 미들웨어로 구현을 할것이다. 먼저 어떻게 모든 노드에게 메시지를 보낼것인다에 대해서 생각해보자 첫번째(eager reliable broadcast) 단순.. 분산시스템(Distributed System) - 2(Logical Clocks) logical time 이란 위의 설명과 같이 이벤트가 일어난 순서대로 부여된 시간이다. 여러 노드에서 발생하는 이벤트들의 순서를 보장하기 위해 사용된다. 왜 필요할까? 각 노드들은 각자의 시간을 가질 수 있다. 하지만 이 시간들은 모두 오차를 가질 것이다. 중앙에서 시간을 받아온다 하더라고 물리적인 거리와 네트워크의 오류 등 여러 변수들이 존재하고 하나의 시스템 안에 있는 노드들이 오차를 가지지 않는 시간을 가진다는 것은 불가능하다. 여기서 보면 m1은 m2보다 먼저 전달이 되어야한다. 하지만 userB에서 m1을 받고 m2를 보내는 시간을 t2라 하자 그리고 최초로 m1이 userA에서 발생한 시간을 t1이라 하자. 그림이나 이미 메시지의 순서를 아는 우리가 보기에는 t1이 t2보다 빨라야 한다. 하.. 분산시스템(Distributed System) - 1(시작) 요즘 MSA다 대용량 분산처리다 스케일이 커지고 좀 더 안정적인 서버를 만들기 위해 분산시스템으로 설계되었다고 한다. 대표적인 예로 쿠버네티스의 etcd이다. 쿠버네티스가 기본이 되어버린 요즘 필요할 때마다 검색하며 yaml을 작성하여 사용은 하지만 어떻게 그렇게 많은 컨테이너들을 관리하고 있는지 궁금하면서 신기하기도 하고 재미있어 보여서 공부를 시작해보았다. Martin Kleppmann가 Cambridge에서 강의한 내용을 가지고 공부를 하면서 이해한것을 바탕으로 정리를 해보려 한다. 아직 부족해서 누구에게 알려주기보다는 정리를 하면서 정리를 하고 시간이 지나 기억이 나지 않을 때 들춰보기 위해 하는 것이라 잘못된 부분이나 내용이 추가되었으면 하는 부분이 있다면 댓글로 알려주시면 감사합니다. http.. 이전 1 다음
