반응형
PART1.1 설계-분산 세계에서의 설계
해당 책에서 사용하는 용어
알아야 할 용어
|
|
- 대규모 시스템의 가시성
- 관리를 위해 시스템의 가시성 확보 필요
- 내부 상태를 조사하는 것(자기조사 - introspection)
- 전통적인 시스템에서는 한 사람의 기술자가 핵심 요소를 감시하거나, 경험에 근거하여 즉시 알아내는 것 이 가능했다.
- 하지만 대형 시스템에서는 불가 -> 시스템 상태를 말하는 로그 늘어남
- 내부 상태를 조사하는 것(자기조사 - introspection)
- 관리를 위해 시스템의 가시성 확보 필요
- 단순함의 중요성
- 시스템은 시간이 흐르면서 복잡하게 변화됨
- 처음부터 단순하게 시작하는 것이 필요
- 관리자의 심적 모델이 유용할 수 있도록
- 설계의 단순화는 운영시 보상 받는다.
- 시스템은 시간이 흐르면서 복잡하게 변화됨
- 조합 : 분산 시스템은 다수의 더 작은 시스템으로 구성
- 부하 분산기(load balancer)와 다수의 뒷단(backend) 복제
- heath check를 통한 분산 방식
- 일반적으로 round-robbin -> backend의 처리능력이 다를 수 있는 경우는?
- 비례식(porportional) round-robbin -> 처리능력이 많은 backend 선택
- 최소 부하(least loaded)
① 순진한 최소 부하 방식
- backend의 부하가 바로 나타나지 않는 경우는? CPU 사용량? 그럼 I/O 부하는?
- 후행 평균(trailing average)으로 측정한다면?
- 일시적인 급격한 부하 증가 반영이 안 됨
- 최악의 경우 : 하나씩 과부하 -> crash -> reboot -> 다시 과부하
- 느린 시작(slow start) : 최소 부하 방식의 개량, 같은 backend에게 연속해서 보내는 요청수 제한
- heath check를 통한 분산 방식
- 서버와 다수의 뒷단들
- 서버 -> 다수의 복제된 광고 검색
-> 다수의 복제된 이미지 검색
-> 다수의 복제된 웹 검색
-> 다수의 복제된 철자 검사 - backend 별로 고유의 role 존재
- 복제된 backend 별로 병렬 실행 -> 느슨한 결합 -> 정교한 잠복 지연 관리
- front와 backend는 상대적 개념
- 조합
- 산개(혹은 전개 fan out) - 하나의 질의에서 여러 개의 질의로, 질의는 backend들로 산개
- 집결(fan-in) - 산개된 질의의 결과를 취합
- 혼잡(밀집, congestion) 문제를 일으킬 위험
- 작은 질의에서 수많은 응답이 만들어질 수 있음 -> 네트워크 연결의 혼잡으로 서버가 과부하가 걸리는 결과로 이어질 수 있음 - 이에 따라 비상 대책(emergency measure) 구현 필요
- 서버 -> 다수의 복제된 광고 검색
- 서버 트리
- 또 다른 근본적인 조합 패턴
- root부터 시작하여 leaf(파편 : shard)에 도달하는 tree 형태 : 총체(corpus)
- 주된 장점 " 큰 자료 corpus를 병렬로 검색, 정렬 및 등급을 매기는 것도 병렬
- 잠복 지연으로 설계 가능
- 부모 서버는 잎 서버의 부하 분산
- 혼잡 문제 완화 도움
- 부하 분산기(load balancer)와 다수의 뒷단(backend) 복제
- 상태 분산
- 상태를 다루는 방법은 여러 가지
- 어떤 형태로든 복제와 파편화(sharding) 이용
-> 일관성, 가용성, 분리와 관련된 문제점을 일으킴 - 분산 컴퓨팅에서는 전체 상태를 여러 파편들로 나누어 분산 저장
- 하나의 파편을 여러 기계에 저장함으로써 오류에 강함
- 복제본을 늘림으로써 성능 향상 - 상태 갱신일 때는 모든 leaf를 갱신해야 되는 문제
- 어떤 형태로든 복제와 파편화(sharding) 이용
- 상태를 다루는 방법은 여러 가지
- CAP 원리
- CAP : Consistency(일관성), Availability(가용성), Partition resistance(분리 저항)
- 일관성과 가용성, 그리고 분리에 대한 저항을 모두 보장하는 분산 시스템은 구축하는 것이 불가능하다는 말
- 목적에 따라 선택
- 일관성
- 모든 노드가 같은 시점에 같은 데이터를 본다는 의미
- 일관성을 보장하지 않더라도 결과적 일관성을 보장할 수는 있다.
- 완벽한 일관성은 비즈니스에 따라 일관성이 중요하지 않을 수 도 있음
- 예로 SNS의 평점 등
- 가용성
- 모든 요청은 그 요청의 성공 또는 실패 여부에 관한 응답을 반드시 받게 된다.
- 시스템이 장애를 보고하는 능력을 갖추고 있냐는 의미
- 분리 저항
- 또는 분리 내구성
- 분리 : 예로 네트워크 연결이 끊겨서..
- 특별한 경우
- 패킷 소실 : 일시적인 분리로 간주
- 네트워크가 완전 먹통일 경우 - 임의의 메시지가 유실되거나 시스템 일부가 실패해도 시스템이 계속 가동함을 의미
- 복제본이 상태를 담고 있어야 하는 상황이라면 달성 어려울 듯
- 예로, 감독-일꾼 관계의 서버가 있다.
상태의 완전한 복제본을 가지고 있고, 전용 네트워크로 health check를 한다.
네트워크가 분리되면, 원래의 감독은 일을 하고 있을 수 있지만, 일꾼은 감지되지 않으므로
자신을 감독으로 격상, -> 두 개의 감독이 있는 상황이라 시스템 실패
=> 분리된 뇌(split brain)
- CAP 삼각형
- CA : 일관성(C), 가용성(A) 보장
- oracle이나 mysql, postgreSQL 같은 전통형 관계형 데이터 베이스
- ACID - Atomicity(원자성 : 트랜잭션은 전부 아님 전무)
- Isolation(격리성 : 동시적인 트랜잭션들은 직렬로 실행했을 때와 동일한 결과)
- Durability(내구성 : 완료된 트랜잭션은 충돌이나 기타 문제로 유실되지 않는다)
- Consistency(일관성 : 각 트랜잭션 이후 데이터베이스는 유효한 상태) - CP : 분리가 발생했을 때 기존 내용 혹은 새로운 내용을 사용자마다 다르게 제공하지 않고, 읽기 전용으로 전환하든지, 모든 요청에 응답하지 않음으로써 약한 일관성(C), 분리 저항(P) 보장
- HBase, Redis, Bigtable 등
- 흔히 NoSQL
- BASE라고 표현
- Basically Available Soft-state services with Eventual consistency
- 결과적 일관성을 갖춘, 기본적으로 가용인 약 상태 서비스 - AP : 일부 사용자가 예전 자료를 보더라도, 요청에 항상 응답할 수 있게 만드는 것
- Cassandra, Riak, Dynamo
- 인터넷처럼 신뢰성이 떨어지는 매체를 통해서 서로 통신하는 전 지구적 분산 네트워크에서 많이 사용
- CA : 일관성(C), 가용성(A) 보장
- 느슨히 결합된 시스템
- 고도의 가용성 제공, 장애 없이 -> 추상화 이용 -> loosely coupled 시스템
- 추상은 각 구성요소가 구현 세부를 숨기는 방식으로 정의된 인터페이스를 제공함을 뜻함
- 속도
- 시간을 가장 많이 잡는 요인
- 디스크 I/O
- 네트워크 I/O - 거리나 통신망에 의한..-> 통제할 수 없는.
- 시간을 가장 많이 잡는 요인
728x90
댓글