전통적 서버 아키텍처

컴퓨터의 진화

• 하나의 머신에 수동으로 작업을 등록하고 수동으로 결과를 확인
• 편의성보다는 단순히 계산을 하는 것이 목적이었기 때문에 사용성이 좋지 못함
• 이후 컴퓨터 크기가 작아지고, 명령어를 입력하는 방식이 발전함
• 폰 노이만 방식은 중앙처리방식, 메모리, 입/출력 방식으로 구성됨
  • 애니악을 통해 stored-program 구현이 가능해짐
• IBM x86 아키텍처 기반 위에서 assembly language, high level language가 비약적 발전

Remote Procedure Call

• RPC(Remote Procedure Call) - 컴퓨터 프로그램을 원격에서 호출할 수 있도록 하는 아이디어
• RPC의 구현으로 client-server 모델이 가능해짐

Database

• 컴퓨터의 계산능력이 검증된 후, 더 많은 데이터를 처리하고자 함
• client-server 구조 이후 물리적 위치의 제약이 사라짐
• 대용량 데이터 전문 처리장치를 개발하게 됨 → 데이터베이스

3-Tier Architecture

• Presentation Tier - client에게 UI 제공
• Logic Tier - high level language로 logic을 처리
• Data Tier - 데이터를 조회

WAS(Web Application Server)

• 서비스의 대부분의 요청은 정적 데이터에 대한 요청
• 정적 데이터에 대한 요청을 저장해두어 빠르게 처리
• processing이 필요한 데이터만 Application Server, Database까지 전달하여 처리하는 방식

WAS의 장점

• 정적인 데이터에 대한 빠른 응답시간
• 애플리케이션 서버의 부하 감소
• 데이터베이스의 부하 감소
• SoC, Seperate of Concern

단계적으로 RPC를 처리하는 방식으로 문제를 해결했지만, 단일 병목점이 생기는 경우 scale-up이 필요함

기존 방식의 한계

• 온라인 서비스 확장에 따라, 정해진 scale-up으로는 기하급수적으로 늘어나는 트래픽이나 데이터를 감당하기 어려움
• 하드웨어 성능의 증가(무어의 법칙) - 시간에 따라 선형적으로 증가
• 하드웨어 성능 증가 한계에 따른 소프트웨어를 이용한 처리 방식의 대두

분산 시스템이 필요한 이유

• scale-up보다는 처리 장치의 수를 늘리는 scale-out 전략을 생각
• 상태를 공유하지 않아야 함
• 상태를 공유한다면 자원을 많이 소모하거나, 불필요한 기술적 한계점이 발생

Load Balancer

• Application Server는 load balancer를 전처리 장치로 두면 상태 없이 scale-out 확장이 가능
• 데이터베이스는 대량의 데이터를 공유하기 때문에 쉽게 scale-out할 수 없음
• 데이터베이스를 중심으로 여러 대의 서버로 scale-out이 가능하면서, 상태와 데이터 공유가 가능해야하고,
• client가 사용하는 기능에 변화는 없는 소프트웨어가 필요

분산 시스템의 특징 - 1

기본 특징

• Concurrency
  • 자원은 공유하며, 리소스 내에서 동시에 여러가지 작업을 수행
  • 동시 실행 자원을 늘려 처리량을 늘릴 수 있음
  • 병렬처리와 다름
• No Global Clock
  • 시스템의 각 부분이 비동기식으로 동작
  • 어떤 한 부분의 상태 때문에 다른 곳이 영향을 받을 수는 있지만 Lock, Bottleneck이 걸리면 안됨
• Independent Failure
  • 시스템의 한 부분의 실패가 전체 시스템에 영향을 주면 안됨
  • 시스템이 다운될 수는 있지만 시스템 설계 차원에서 발생하면 안됨

분산 시스템의 고려 요소

Heterogeneity

• 서로 다른 시스템에서 사용 가능해야 함
• 서로 다른 시스템 사이에 정보와 자원 공유가 가능해야 함
• 운영체제, 하드웨어에 대한 임펙트가 크기 때문에, 운영체제나 하드웨어에 관계없이 일관된 개발을 해야 함
• Java, Scala, Golang 등을 주로 사용
• C, C++ 등 native library에 대한 의존도가 큰 언어로는 분산 시스템 개발이 어려움

Openess

• 서로 다른 요소 사이에 연결과 확장, 상호 운용이 가능해야 함
• 주요 인터페이스를 노출하고, 일관된 커뮤니케이션 방식을 사용
• 어떤 운영체제나 하드웨어에 대해서도 커뮤니케이션이 동일해야 함

Security

• 권한 제어, 접근 제어가 가능해야 함
• 주로 프로토콜을 이용해 구현
• 구성요소
  • Confidentially - 권한이 없으면 공개 불가
  • Integrity - 허가되지 않은 방법으로 변경 불가능
  • Availability - 권한이 있다면 접근이 가능해야 함

Scalability

• 시스템 자원이나 사용자에 따라 확장 가능해야 함
• scale-up이 아닌 scale-out이기 때문에 수평적 확장 방법을 사용
• 확장을 통해
  • 성능이 좋아지거나
  • 처리량이 많아지거나
  • 가용성(capacity)이 높아져야 한다

Scalability에서 고려할 점

• 물리적 리소스에 대한 비용 - 시스템 크기 증가에 따른 금전적 한계
• performance loss - resource양 증가에 따른 성능의 한계
• resource 한계 - IP는 resource 한계가 발생하여 IPv6 등의 해결책을 찾게 됨
• performance bottleneck

Failure Handling

장애/실패에 대한 대응을 자동으로 할 수 있어야 함

• Detecting failure - 문제를 감지
• Masking failure - 문제를 마스킹
• Tolerating failure - 문제를 복제해 놓음
• Recovery failure - 복제한 것을 복구시킴
• Redundancy

Concurrency

여러 client가 하나의 공유 자원에 접근하는 동시성 문제를 해결해야 함

• 보통 여러 개의 처리를 서로의 간섭없이 수행할 수 있어야 함
• 분산 환경에 있는 공유 자원은을 표현하는 대상은 상태를 정확히 표현해야함
  • 복제중인지, commit을 했는지 등 ...
• 동시성 환경에 안정하려면 consistent한 상태로 동기화되어야 함

Transparency

사용자로부터 내부에 있는 정보의 투명성을 달성해야 함

• Access transparency - 자원 위치에 관계없이 어디서든 동일한 방식으로 시스템에 접근이 가능
• Location transparency - 자원의 위치에 관계 없이 자원에 접근이 가능
• Concurrency transparency - 서로에 대한 간섭없이 공유 자원을 처리할 수 있어야 함
• Replication transparency - 시스템 하나에 장애가 발생해도 시스템에 다른 부분에 의해 값을 전달할 수 있음
• Failure transparency - 설계에 문제가 아닌 소프트웨어적 문제 등 재시도할 수 있는 문제에 대해서는 다시 시도하여 사용자에게 요청받은 결과를 전달하도록 함
• Mobility transparency - 특정 노드에 장애가 발생하여 자원이 다른 노드로 이동하더라도 client 입장에서는 동일하게 접근이 가능함
• Performance transparency - 로드가 일어났을 때, 성능 개선을 위해 시스템을 재구성할 수 있어야 함
• Scaling transparency - 시스템 구조에 관계없이 scale이 커질 수 있어야 함

분산 시스템의 특징 - 2

BASE Principle

BASE의 요소

• Basically Available - 전체가 이용불가능한 상태는 없음. 부분적 장애는 가능
  • data의 복사본을 만듬, 최대한 다른 노드에 저장되어야 함
  • 한 종류의 data를 여러 노드에 분산
• Soft State - 응답하는 데이터 상태는 inconsistency할 수 있음. 이것에 대한 책임은 사용자에게 있음
  • 사용자가 데이터를 조회할 때
  • 아직 update가 되지 않은 데이터가 조회될 수도 있음
• Eventually Consistent - 입력된 데이터는 약간의 지연이 있을 수 있지만, 언젠가는 저장, 조회됨
  • 데이터가 update된지 얼마 안된 경우에는 이전 data가 조회될 수도 있지만 시간이 지나면 결국 update됨

BASE의 특징

• RDBS의 ACID와 대비되는 개념
• Transcation은 ACID가 보장되어야 함
• BASE는 즉각적 일관성을 포기해야 함
• 데이터 저장, 조회의 지연이 있을 수 있음을 감안해야 함

CAP Theorem

CAP의 요소

• Consistency
  • 하나의 데이터가 반영되었을 때, 모두 동일한 결과를 보여주어야 함
  • 동일한 요청에 대해서는 동일한 응답을 함
  • 병렬 요청에 대해서도, 같은 결과를 제공
  • ACID는 트랜잭션이 완료되었을 때의 상태를 말하기 때문에 ACID의 C와는 차익 있음
• Availability
  • 어떤 상황에서도 기능이 이용 가능함
  • 분산 환경의 일부에 장애가 있어도 전체 시스템에는 문제가 없음
• Partition-Tolerance
  • 분산 시스템을 구성하는 노드의 장애가 발생해도, 각각의 부분 시스템은 정상 작동함

CAP의 지원

• Trade-off를 고려해, CA, AP를 가장 많이 사용
• Availability는 가장 중요하기 때문에 빠질 수 없음
• 참고 - CAP Theorem: You don't need CP, you don't want AP, and you can't have CA

CA

• 안정적으로 시스템이 운영되고 Consistency를 보장
• 부분만으로 이용할 수는 없음
• 데이터 정합성이 중요한 경우 사용
• ex)
  • 전통적 RDBMS
  • MongoDB
• 파티션이 발생하는 상황에서는 발생할 수 없음
• CA는 파티션이 필요하므로 분산시스템이 아님

AP

• 어떤 상황에서도 안정적으로 시스템이 운영됨
• 데이터의 정합성이 보장되지 않음
• 특정 시점에 Write 동기화 여부에 따라 데이터가 달라질 수 있음
• Eventual Consistency
  • Transactional 성격과는 맞지 않음
• ex)
  • Cassandra, HBase 등의 모던 분산 DB
  • Druid 등의 OLAP

CP

• 어떤 상황에서도 파티션에 대해 이용 가능하고 Consistency도 보장
• 파티션 상황에서 Consistency가 가능할 수 없기 때문에, 존재할 수 없음

CAP Theorem의 한계

완벽한 CP, 완벽한 AP 시스템은 존재할 수 없음

• 완벽한 CP
  • 완벽한 consistency를 갖는 분산 시스템에서는 하나의 트랜잭션이 다른 모든 노드에 복제된 후 완료될 수 있음
  • 가용성 뿐만 아니라 성능의 희생을 필요로 함
  • 하나의 노드라도 에러가 발생하면 트랜잭션이 무조건 실패하고, 노드가 늘어날수록 지연시간이 길어지게 됨
  • 이렇게 되는 경우 분산 시스템을 사용하는 의미가 없어짐

• 완벽한 AP

  • 완벽한 가용성을 갖는 시스템은 모든 노드가 어떤 상황에서도 응답할 수 있어야 함
  • 하나의 노드가 네트워크 파티션으로 고립된 경우
    • 데이터는 쓸모 없어짐 → 일관성이 깨지므로
    • 응답한다면 완벽한 가용성을 갖게 됨
    • 데이터가 일관성을 잃게 됨
  • 많은 분산 시스템은 AP쪽에 비중을 둠(trade-off임을 감안

PACELC Theorem

PACELC 이란?

• CAP 이론의 단점을 보완하기 위한 이론
• Partition은 무조건적으로 필요하고 Consistency와 Availability 중 하나를 선택해야 함
• PACELC은 정상상황이라는 축을 더함
• P(artition, 분할 상황)인 경우 A(Availability)와 C(Consistency)의 상충 관계와
• E(else, 정상 상황)인 경우 L(Latency)와 C(Consistency)의 상충 관계를 설명

Partition 상황

• Availability를 포기하고 장애로 상태로 변경, Consistency를 유지할 것인지
• Consistency를 포기하고 부분적 노드 그룹에만 HA를 유지할 것인지
• 주로 Consistency보다 Availability를 선택

Else 상황

• 모든 노드에 적용과정에서 Latency와 Consistency 간에 trade-off
• 주로 Consistency보다 Latency를 선택

Consistency를 선택한다면 분산 시스템이 아닌 RDBMS를 선택해야 함
→ 상황에 맞는 시스템을 잘 선택하기 위해서는 어떤 시스템이 있는지를 파악하고 있어야 함