분산시스템의 이해

분산시스템의 이해

컴퓨터의 진화

Process on machine

폰노이만 아키텍처 : 폰노이만 수학자가 제시한 컴퓨터 아이디어(구조) ⇒ 지금까지 사용

RPC(Remote Procedure Call)

: 원격으로 어떠한 작업을 호출

• 인터넷이 발전함에 따라 현시점의 작업 명령과 어울리는 작업
• 컴퓨터에 직접 사람이 앞에 앉아 있어야하는 물리적인 제약이 없으면 더 많은 사람들이 많은 일을 빠르게 처리할 수 있을 것임.
• RPC가 등장하게 되었냐면 인터넷을 통해서 한 대의 컴퓨터에 A,B,C가 물리적이아닌 원격으로 접속해서 명령을 내리면 어떨까해서 ⇒ 훨씬 더 작업 속도가 빨라질 것.
• 따라서 컴퓨터 프로그램을 원격에서 호출할 수 있도록 하자는 아이디어가 RPC!

Database

• 더 많은 데이터 처리가 대두됨.
• RPC 덕분에 서버 클라이언트 모델이 가능해짐에 따라 서버에 대한 물리적인 위치의 제약이 사라짐
• 데이터를 처리하기 위한 project 시작
• 1970년대 RDBMS가 만들어졌고 1980년대 SQL의 표준 정립과 함께 IBM DB2가 사용 데이터베이스 문을 열게됨.
• client → (request) → server (클라이언트가 요청한 내용 처리 + 데이터 관리(파일형태로))
• 과거에는 server가 파일들(데이터)을 다 관리했지만 파일에 써져있는 데이터를 관리하기에 시간과 비용이 많이 들음
• 그래서 데이터만 전문적으로 관리할 수 있는 DB서버(RDBMS)를 만들어 SQL로 request함.
• Client →(request) → Server → (request = SQL/ORM) → DB서버
• ORM 이란? 브릿지라고도 하며, 객체지향 프로그래밍 언어(OOP)로 되어 있는 class를 보고 ORM이 SQL로 만들어준다.
  • 클래스를 객체화해서 Transform을 한다 : 데이터베이스의 데이터를 보내기위함.
  • OOP로 되어 있는 걸 class들을 ORM이 SQL로 변환시켜줌
  • 등장 배경 : 개발자는 개발, SQL 잘하는 사람은 SQL! 각자 잘하던 언어를 사용하기 위해 생겨남 그래서 ORM은 웹개발자에게 필요한 언어임.

3-Trier Architecture : 데이터를 관리하기 위한 서버 (웹서버에서 분리함)

Remote Call이 가능해지고, 데이터의 전문 처리 시스템인 Database가 가능해짐으로 3 Tier Architecture가 온라인(웹) 서비스 구현의 하나의 패턴이 되었음.

• presentation Tier: client(기능적없음, 서버가 보내준 화면과 기능), server가 제공하고 있는 어떠한 화면 (Client)
• Logic Tier : 화면으로부터 client가 요청하게 되면 그 내용을 처리하게 되는 단계 (Server)
  • Server는 presentation Tier(Client)에게 Responce를 줌
• Database Tier : 데이터베이스가 없기 때문에 따로 띄어놈
  • Result Set을 Logic tier(Server)에게 전달

⇒ 3-Trier Architecture 로 인해 효율 높임

Web_Was_DB

• 90%이상이 정적인 데이터(변하지 않는 데이터)에 대한 요청이었음. 그래서 정적인 데이터에대한 요청은 응답을 저장해두고 빠르게 처리하고,

기존 방식의 한계

• 온라인 서비스가 확장되면서 컴퓨터의 형태와 동작이 정해진 상태에서 scale_up 방식으로는 기하급수적으로 늘어나는 트래픽이나 데이터를 감당하기 힘들었음
• 따라서 서비스의 원활한 공급을 위해 문제를 해결하는 방식이 하드웨어에서 소프트웨어로 넘어오게 됨.

분산시스템이 필요한 이유

• scale_up : 수직적 처리(장치 한 개를 크게, 메모리 더 끼고, ssd 더 좋은것 !)
• scale_out : 수평적 처리(저렴한 컴퓨터를 여러대) : 원격 처리 장치의 수를 늘리는 전략
  • scale_out 툴 : 하둡, 스파크, 카프카
• 소프트웨어 개발자들은 scale_up보다는 원격 처리 장치의 수를 늘리는 scale_out 전략을 생각하게됨.
• 이때, scale out을 하려면 상태를 공유하지 않아야함.
• 공유하게 되면 자원이 많이 소모 & 불필요한 기술적 한계 지점이 발생하며 복잡해짐. (A컴퓨터 - B컴퓨터 - C컴퓨터)
• ex) 나랑 같은 일을 처리하는 상황에서 다른 컴퓨터는 어떤지에 대한 상태!
• 그럼 어떡하나? Master 컴퓨터로 A,B,C 컴퓨터 관리 ! 내상태를 Master한테만 주면 됨. Master ↑ ↑ ↑ A B C ⇒ 구성이 간결해짐, 만약 너무 많이 연결하면 Master가 힘들어질 수 있는데 여기서 Master도 분할됨(feat. HDFS - 분산처리시스)
• A(Worker), B(Worker), … ,

분산시스템의 특징

기본 특징

• Concurrency : 자원은 공유하면서 리소스내에서 동시에 여러가지 작업을 수행
• No Global Clock : 비동기식으로 동작 (작업보내고 내가 할 것 진행하는 것) & 어떠 한 부분의 상태 때문에 다른 곳에 Lock, Bottleneck이 걸리면 안됨.
• Independent Failure : 시스템의 한 부분의 실패가 전체 시스템에 영향(장애)을 주면 안됨.

분산시스템의 고려요소

• Heterogeneity : 서로 다른 시스템에 설치 가능. OS, HW 관계없이 일관된 개발을 하기 위한 언어를 선택 (JAVA, Scala, Golang, Python 등)
• Openess : 서로 다른 요소 사이의 연결과 확장, 상호 운용이 가능해야함.
• Security : 권한 제어, 접근제어 등이 가능해야함
• Scalability : 시스템 자원이나 사용자 수에 따라서 확장 가능해야 함. 주로 수평적 확장 방법 사용!
• Failure Handling (실패 제어) : 장애/실패에 대한 대응 가능해야함. (자동화된 방식으로)
• Concurrency (동시성) : 여러 클라이언트가 하나의 공유 자원에 접근
• Transparency (투명성) : 사용자로부터 내부에 있는 정보를 보이지 않게 하고 접근/위치/동시성/ 실패/이동성/성능/확작성 투명성에 대해 달성해야함

⇒ 이 모든 것을 제대로 달성한 것이 “Hadoop”. hadoop 위에서?? 돌아가는 Hive, Spark

BASE Principle

: 분산처리시스템을 도입해야하는 실무자에게 도움이 되는 이론

BASE의 요소

• Basiccally Available - 부분적인 장애를 허용하되, 전체적인 장애를 허용하지는 않음. 즉 Partition(부분)의 장애만 허용
  • 데이터 replica(복제본)를 만든다. 만들어진 replica는 다른 기기에 있는 것이 좋다.
  • 한 종류의 data를 여러 노드에 분산한다. 즉, 데이터의 부분집합을 물리적인 다른 위치에 분산한다.
    A.csv
    ↙ ↓ ↘
    |A-1| |A-2| |A-3| : 여러 컴퓨터에 분산해서 저장함.
    |A-3| |A-1| |A-2| : 복제하여 각각 다른 컴퓨터에 집어넣음
    IF. 가운데가 한개가 죽어도 A-1, A-2, A-3는 전부 존재.
    BUT. 두개가 죽으면 안됨. 하지만 현실은 100대 2000대 만대 단위까지 있기때문에 괜찮음.
• Soft State - 응답하는 데이터(또는 집합의) 상태는 inconsistency(비일관성)할 수 있음. 이것에 대한 책임(감안)은 사용자에게 있음.
  ex. 어떠한 값을 update했는데 select할 때는 update하기 전의 내용이 추출! 왜? 처리중이라..
• Eventually Consistent - 입력된 데이터는 약간의 지연이 있을수는 있지만, 결국에는 언젠가는 저장, 조회가 됨.

BASE의 특징

• RDB의 ACID와 대비되는 개념임. RDBMS와 같은 Transaction 처리가 필요하다면 ACID가 보장되어야함. 모두 immediate consistency(즉시적인 일관성)를 포기하면서 가지는 특성임.

CAP Theorem

BASE를 기반으로해서 분산처리시스템을 도입하려고 할 때 필요한 3가지 이론을 CAP라고 함!

C, A, P로 대표되는 특징 중 분산시스템에서는 3가지를 모두 지원할 수는 없고 한 가지는 포기해야 실제 HW/Software로 구현이 가능하다는 딜레마 존재.

• Consistency(일관성)
  • 분산된 환경이라도 모든 동일한 요청에 대한 응답 데이터는 항상 똑같다.
  • 동시에 여러개의 병렬 요청에도, 같은 결과를 제공함.
  • ⇒ 정리해보면, 데이터를 조회했을 때 누구나 같은 데이터를 받아야함!
  • BUT, 즉각적이라는 건 없음. 일관성이 있게 데이터를 주긴할 건데 얼마나 걸릴 지는 모름.
• Availability(가용성)
  • 어떠한 상황에도, 기능이 이용 가능함.
  • 분산 환경의 일부에 장애가 있어도, 전체엔 문제가 없어야함.
• Partition-Tolerance(분할내성)
  • 분산 시스템을 구성하는 노드간 통신의 문제가 발생해도, 각각의 부분 시스템은 정상적으로 동작함. (A-1데이터와 A-3 데이터를 가져오는데 통신의 문제가 없지만 A-2는 가져오는데 매우 오래걸림.)

하나의 분산 시스템으로 C,A,P 모두를 완벽히 지원할 수 없음.

보통 Trade-off를 고려해 CA, AP를 가장 많이 선택한다. 왜? IT 시스템에서 장애가 나면 안되기 때문에 Availability는 빠질 수 없는 가장 중요한 요소로 판단하기 때문.

CA

어떠한 상황에서도 안정적으로 시스템은 운영됨 왜? 뭐때문에? A때문에

• Consistency도 보장

단, 부분만으로 이용할 수는 없음. 즉, 모든 데이터가 무결하게 들고와야하기 때문에 문제가 있는 데이터 처리는 이루어지지 않을 수 있음. 그래서 데이터 정합성이 중요한 경우 선택하게 됨.

그래서 분산시스템에서 거의 선택하지 않음.

예시. 전통적인 RDBMS, MongoDB

AP

거의 분산처리 시스템에서 선택함. ⇒ 어떤 상황에서도 안정적인 시스템이 운영함.

• 데이터와 상관없이 안정적인 응답을 받을 수 있음.

단, 데이터의 정합성에 대한 보장은 불가능 (즉, 내가 조회하는 결과물과 다른 사람이 조회하는 결과물이 다를 수 있음)

하지만, 시간이 충분히 주어지면 언젠가 결과적으로 Consistency(일관성)이 보장이됨.

예시. Cassandra, HBase 등의 모던 분산 DB , Druid 등의 OLAP(Online Analytical Processing) System

CP

어떤 상황에서도 파티션에 대해서 이용가능하고, Consistency도 보장됨. 파티션 상황에서 Consistency가 가능할 수 없기 때문에, 이런 시스템은 존재할 수 없음.

A가 빠져서 망가지면 끝.. (복제세트도 없는 것) A-2 데이터가 없어지면 A-1, A-3만 남아버려 C, P 다 깨짐. ⇒ 이런 시스템은 애초에 존재 불가.

CAP Theorem의 한계

현실적으로 완벽한 CP, AP 시스템은 존재할 수 없음.

IF 그런 시스템이 있다면,

• 완벽한 CP 시스템 : 완벽한 일관성을 갖는 분산 시스템에서는 하나의 트랜잭션이 모든 노드에 복제된 후에 완료될 수 있음. 이는 가용성 뿐만 아니라 성능의 희생을 필요로 하게됨.
  (왜? 데이터가 완벽하게 전부다 복제가 되고 사용가능할 상태가 될 때까지 대기해야함. 만약 하나의 노드가 문제가 생기면 트랜잭션은 무조건 실패하게 됨, 노드가 늘어날 수록 지연시간은 길어짐. ⇒ 분산시스템을 쓸 이유가 없어짐)
• 완벽한 AP 시스템 : 완벽한 가용성을 갖는 시스템은 모든 노드가 어떤 상황에서라도 응답할 수 있어야함. 만약 하나의 노드가 네트워크 파티션으로 인해 고립되었다면? 고립된 데이터 쓸모없어지지만 어땠든 응답한다면 완벽한 가용성을 갖게됨. 하지만 운 나쁘게 이 노드와 연결된 사용자는 문제를 인지하지 못하고 계속해서 요청을 보낼 것임. 장애 상황에서 부분적인 데이터만 받을 수 있다면 이 시스템을 상용시스템에서 사용할 수 있을까?

그래서 일반적으로 구현할 때 완벽한 CP시스템과 완벽한 AP시스템 사이에서 어느정도까지를 볼 건지 선택해서 구현! (AP 와 CP 사이에서 요구사항에 맞는 균형점을 찾아야 함. (분산시스템에서 파티션은 일어난다고 가정하고))

• 일관성을 신경을 더 쓸건지, 고가용성을 신경을 더 쓸건지 선택 ⇒ 비즈니스 로직에 따라 다름.
  • 일관성 많으면 모든 데이터가 완벽히 처리될 때까지 시간이 오래걸림
  • 정확성이 많으면 정합성이 완벽하지 않은 상황의 데이터만 받아볼 수 있음( 데이터가 조회는 됐는데 텅빈데이터 받아볼 수 있음)
• 단, 많은 분산 데이터베이스는 AP 쪽에 비중을 둡니다