이번글은 짧게쓸거야
길면 읽기 싫잔아 쓰는것도 힘든데다 ㅎ

일단 분산시스템을 쓰는 이유는 뭘까?
크게 두 가지 이유에서야

A. 사양을 높이는데는 한계가 있지만 데이터나 사용자 트래픽에는 한계가 없다.  그래서 여러대에서 처리해아만한다

B  모든 기계는 장애가 난다. 사양높은 한대가 절대 장애안나게 하는 것보다 사양 낮은 많은 기계들중 하나가 장애났을때 전체 서비스에 영향이 적게 만드는것이 현실성있다.

그럼 좋은 분산 시스템은 어떤걸까?

A. 여러대를 쓰는 이점을 가져가면서 사용자들은 한대를 쓸때랑 똑같은 사용자 경험을 주는거
Consistency나 synchronization에 관한 고민이 여기서 시작되는거야

B. 필요하면 언제든 새 기계를 갖다붙이면 붙이는만큼 시스템의 전체 처리량이 늘어나는거
linear scalibility 라고 하는거

C. 여러대의 기계가 노는 놈이나 혼자 일하는 놈없이 공평하게 일하는거.
Load distribution이고 이건 b랑 연결되지

D. 100대 중 1대가 장애나면 100분의 1만큼, 2대가 장애나면 100분의 2만큼만 전체서비스에 영향을 주는거에 그치는거
fault isolation 이라 그러고 spof 을 없애야 한다고 그래

E. D랑 이어지는데 장애가 발생해도 새로 기계를 갈아 넣으면 다시 100분의 100먄큼 작동하는거

그래서 분산 시스템에서 어려운 문제는 어떤 걸까?
사실 공유 상태가 없는 예를 들어 static한 웹페이지를 서비스하는 웹서버같은 것들은 고민해야할 문제가 b와 c야
그래서 앞에다가 로드밸런서같은걸 붙여주던가 하지
A, d, e는 정적인 웹페이지를 보여주는 웹서버 입장에선 b와 c가 되면은 딱히 고민안해도 되겠지

그런데 만일 공유되는 상태정보가 있는 dbms 같은거는 어떨까?
자기들끼리 입을 맞춰야겠지? Dbms 100대에 분산시켜 놓았는데 로드밸런서가 어느 dbms 인스턴스에다가 연결시키느냐에 따라 다른 값을 보여주면 그 시스템은 업무에 사용하기 힘들거야
그래서 이 입을 맞추는 문제 때문에 공유 상태가 있는 시스템들은 a와 d그리고 e가 어려운 문제가 돼

만일 무조건 다 입을 맞추게하면 그만큼 느려질거야
그리고 더 문제는 개중에 몇대가 장애나거나 통신이 안되거나 할때 어떻게 처리해야할지야

100대중에 10대랑 통신이 안되니까 방금한 write는 시스템에러라고 할까?
아니면은 나중에 입을 맞추지 하고 write를 받아줬는데 알고보니 그 10대가 장애가 아니라 자기들끼리 내부 네트워크에 문제가 있던 거였고 나머지 10대는 sync가 안맞은채로 서비스를 하고 있으면?

여기서 consistency 모델이니 cap이니 base니 하는 이론들이 나오고 하는데 또 글이 존나 길어져가지고

혹시 관심있는 형들 있으면 다음에 시간되면 다음글에 쓰던가 해볼게

- dc official App