algo expert

[yeomko22]

Client Sever Architecture

• 웹 서비스에서 클라이언트는 웹 브라우저이다.
• 도메인 이름을 입력하면 DNS 서버에 요청을 보내어 해당 도메인 네임의 IP 주소를 얻어온다.
• 이 IP 주소로 서버에 요청을 보내는 것이다.
• dig 명령어를 통해서 도메인 이름에 해당하는 ip 주소를 알 수 있다.

  
  $ dig algoexprt.io

; <<>> DiG 9.10.6 <<>> algoexpert.io ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62516 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;algoexpert.io. IN A

;; ANSWER SECTION: algoexpert.io. 3600 IN A 35.202.194.70

;; Query time: 61 msec ;; SERVER: 61.41.153.2#53(61.41.153.2) ;; WHEN: Wed Jun 23 16:41:00 KST 2021 ;; MSG SIZE rcvd: 58

- 서버는 특정 포트에서 요청이 들어오기를 기다린다. 포트는 65535개를 사용 가능하다.

~~~bash
# 로컬 영역에서 TCP나 UDP 통신을 수신하기 위해 포트를 개방
$ nc -l 8021

# 로컬 컴퓨터의 8021 포트로 접속, TCP 통신을 수행
$ nc 127.0.0.1 8021

[yeomko22]

Network Protocol

IP

• Internet Protocl
• IP 패킷의 형태로 데이터를 전송한다.
• 헤더와 데이터로 구성된다.
• 헤더는 패킷에 대한 중요한 정보를 담고 있다.
  • 출발지 ip와 도착지 ip
  • 전체 패킷의 크기
  • 프로토콜 버전 (ipv4인지 ipv6인지)
• 데이터 섹션에는 실제로 전달하고자 하는 데이터가 담기게 된다.
• 데이터 섹션은 그렇게 크지 않아서 하나의 요청을 처리하기 위해선 여러개의 패킷을 보내야만 한다.
• 그런데 여러개의 IP 패킷들을 보내게 되면 제대로 패킷들이 도착했는지, 순서가 꼬이진 않았는 지에 대한 보장이 없어지게 된다.
• 그래서 TCP가 등장하게 되었다.

TCP

• transmission control protocol
• 패킷 순서를 보장, 전송을 보장, 패킷 corruption 감지
• TCP도 헤더를 갖는다.
• TCP는 통신을 하기 전에 먼저 커넥션을 맺으며, 이 때 handshake라는 과정을 거친다.
• 커넥션을 맺을 때는 3 way handshake 끊을 때는 4 way handshake를 거친다.

HTTP

• TCP 위에 만들어진 프로토콜이다.
• request, response 패러다임을 가져왔다.
• http는 메서드가 있다.
  • Get: read
  • PUT: update
  • DELETE: delete
  • POST: create

[yeomko22]

Storage

Database

• 데이터를 기록(record)하고 읽어오는(read) 프로그램
• 통신을 통해서 다른 애플리케이션들에게 데이터를 제공하는 역할
• 데이터를 메모리에만 저장할 시엔 프로세스가 죽을 경우 날아간다.
• 이를 방지하기 위해 디스크 공간에 저장을 해주어야 한다. 그리고 이를 persistent storage라고 부른다.

[yeomko22]

Latency & Throughput

• latency는 시스템이 특정 작업을 수행하기까지 걸리는 시간을 의미한다.
• throughput은 주어진 시간동안 처리할 수 있는 작업양을 의미한다. (QPS, RPS)
• 서버의 성능을 얘기할 때는 두가지 지표를 모두 고려해야한다.

SLA / SLO

• SLA: service level agreement, 서비스 제공자와 고객 사이의 시스템 가용량에 대한 합의이다. 이를 지키지 못할 시, 고객에게 어떻게 보상을 해줄지 등을 담고 있다. 보장해주는 각각의 수준을 SLO라 부른다.
• SLO: service level objective, 서비스 제공자에 의해 제공되는 보장 수준이다. SLA는 SLO들로 구성된다고 보는 것이 맞다.
• 클라우드 사업자들은 명확한 SLA를 가지고 있다.

Nines

• 2 nines: 87.7 hour / year
• 3 nines: 8.8 hour / year
• 4 nines: 52.6 minutes / year
• 5nines: 5.3 minutes / year
• 6 nines: 31 sec / year

Redundancy

• single point failure를 피하기 위해서 여분을 쟁여놓는 것
• passive redundacy: 시스템을 구성하는 서버들 중 하나가 죽더라도 나머지의 부하가 증가할 뿐 당장 무슨 일이 벌어지진 않는다.
• active redundacy: 시스템을 구성하는 서버들 중 하나가 죽으면 그 서버의 역할을 대신하기 위해서 재설정이 필요하다. 리더 일렉션의 경우가 그러함.

[yeomko22]

Caching

• 연산이 큰 작업을 다시 수행하는 것을 막아준다.
• latency를 줄여준다.
• 원래 데이터가 있던 곳으로부터 꺼내어 와서 저장한다.

• client가 서버로부터 전송받은 데이터를 캐시에 저장할 수 있다. 주로 서버로부터 전달받은 정적 페이지가 그러하다.
• 서버 역시 데이터로부터 전달받은 데이터를 캐시에 저장할 수 있다.
• 하드웨어 레벨에서도 CPU 캐쉬 등이 활용된다.

• 여러대의 애플리케이션 서버가 데이터베이스를 찌르는 경우, 같은 작업을 여러 서버들이 요청할 수 있다. 이 때 데이터 베이스가 결과를 캐싱해놓았다면 동일한 요청에 대해서 추가 연산 없이 결과를 리턴할 수 있다. 이는 데이터 베이스 부하를 크게 줄여준다.

캐싱 예시

• 디비 캐싱
• 클라이언트 캐싱
• algoexpert 경우 사용자가 코드 수정 없이 다시 실행을 하면 미리 캐싱해놓은 결과를 리턴해준다.

write through cache

• 디비에 데이터를 쓸 경우 캐쉬와 디비에 동시에 쓴다.
• 그 데이터에 대한 수정 작업을 서버가 수신할 경우, 캐쉬에 먼저 업데이트하고 디비에 쓰기 작업을 한다.

write back cache

• 디비에 데이터를 쓸 경우 캐쉬에만 써버린다. 디비와 싱크가 안맞게 된다.
• 서버는 비동기적으로 디비와 캐쉬 사이의 싱크를 맞춘다. 일정 시간 (ex. 5분) 디비와 캐쉬 간의 싱크를 맞춰주는 것!
• 만일 서버 캐쉬에서 데이터를 잃는다면 유실된다.

cache stale

• 캐쉬는 적절히 업데이트가 되지 않으면 staleness를 잃어버린다.

• 그래서 redis와 같은 in memory DB를 두어서 분산 캐쉬를 유지한다.

• 

• 그러므로 요구사항을 명확히 파악해야한다. 유투브 조회수가 살짝 다르다 해서 크게 중요하지 않다. 그러나 은행 잔고가 다를 경우에는 큰일이 난다. 즉, 요구사항에 따라서 캐쉬를 적용하여 실시간 성을 약간 포기하고 운영 상의 이점을 취할 수 있다.

Eviction Policy

• 어드 데이터를 캐쉬에서 내릴 것인가
• LRU(least recently used), LFU(least frequently used), FIFO

CDN

• content delivery network
• 컨텐츠를 해당 지역에 가까운 서버로 미리 옮겨놓는 것
• cloudflar와 google cloud CDN이 유명

[yeomko22]

Load Balancer

• 서버로 요청을 주는 클라이언트의 수가 많아지면 단일 서버로는 한계가 있다. 즉, 서버를 확장해야 한다.
• 로드 밸런서는 다수의 클라이언트와 다수의 서버 사이에 위치한다. 그리고 트래픽을 수신하여 다수의 서버에 나누어 주는 일종의 "reverse proxy" 역할을 수행한다.

Hardware / Software load balancer

• hardware loadbalancer는 장비의 제약이 있고, 가격이 비싸다.
• software loadbalancer는 장비 제약이 없고 선택의 자유가 있는다.

Server Selection Strategy

• round-robin
• random selection
• performanced based selection: 각 서버에 health check를 수행, 가용 리소스의 여유가 있는 서버로 트래픽을 내려보내준다.
• IP based routing: cache 활용률을 높여준다.

Nginx

• reverse proxy load balancer로 인기가 많다.

[yeomko22]

Distributed Hash Table (DHT)

• 입력으로 들어오는 데이터를 해싱하고, 이를 특정 노드값으로 매핑하는 해싱기법
• 여기서 버킷 크기는 서버 노드의 개수이다.
• 이렇게 하면 동일한 요청에 대해 동일한 노드를 매핑할 수 있으며, 이 때 서버 노드의 캐쉬 히트율을 높일 수 있다.
• 그런데 서버 노드는 추가될 수도, 제거될 수도 있다. 이는 버킷의 개수가 늘거나 줄어든다는 의미이다. 단순 해쉬 함수를 사용할 경우, 버킷의 개수가 조정되면 기존의 요청들이 전부 새로운 노드에 매핑되어 캐쉬를 활용할 수 없는 상황이 발생한다.

Rendezvous Hashing

• hightest random weight hashing 이라고도 불린다.
• distributed hash table이 갖고 있는 문제를 해결한다.
• 먼저 클라이언트 셋 {c1, c2, ..., cn}과 서버 셋 {s1, s2, ..., sm}이 있다고 하자
• 특정 해쉬 함수 h에 대해서 wij = h(cisj)를 계산한다. 즉, 모든 쌍을 해쉬 함수에 넣어서 스코어 값을 구한다.
• 이 스코어 값이 가장 큰 서버에 클라이언트를 할당한다.
• 서버가 추가될 경우, 해당 서버에 대해서 스코어 값을 새로구하고, 가장 클 경우 클라이언트를 매핑하면 된다. 반대로 서버가 삭제될 경우, 그 서버에 매핑되었던 클라이언트들은 두번째로 스코어 값이 큰 서버로 매핑되면 된다. 즉, 기존의 매핑을 최대한 유지하면서 서버의 추가, 삭제에 대응할 수 있다.

Consistent Hashing

• consistent hashing은 k=1인 rendezvous hashing의 특수한 경우이다.
• 서버가 추가되거나 제거되어 해시 테이블의 크기가 변하는 상황에서 평균적으로 K/n의 키만 재매핑 하면된다. (n: 노드 개수, K: item 개수) 즉, 특정 노드에 매핑되었던 아이템들만 리매핑을 하면 된다.

[yeomko22]

KV store

• DynamoDB, ETCE, zookeeper, redis, etc
• disk에 직접 쓰는 솔루션도 있고, 메모리에 쓰는 솔루션도 있다.
• redis가 대표적인 in-memory KV storage이다.
• strong consistency 혹은 eventual consistency를 지원한다.

[yeomko22]

Specialized Storage Paradigm

Blob Store

• binary large object으 줄임말
• unstructured data를 지칭한다. 비디오, 이미지, 대용량 텍스트 파일 등이 해당
• 테이블 형식으로 저장하면 안된다. 개별 파일의 용량이 크고 개수가 많을 수 있다.
• Google Cloud Stroage, Amazon S3 등이 여기에 해당한다.

TIme Series DB

• 시간에 따라서 달라지는 데이터를 저장, 시스템 모니터링 지표 등
• InfluxDB, Prometheus가 대표적

Graph DB

• graph 데이터 구조를 저장한다. graph 데이터 모델에 기반해서 데이터를 저장한다.
• 복잡한 관계를 가진 데이터에 적합하다. SNS 관계 데이터 등이 여기에 해당한다.
• neo4j

[yeomko22]

Replication and Sharding

Replication

• main DB가 죽을 경우를 대비해서 복사본을 만들어 놓을 수 있다.
• mainDB가 read/write 연산을 수행하고 이를 replica에 반영할 수 있다. 이를 동기 혹은 비동기 방식으로 수행한다.
• mainDB가 죽을 경우 replica가 이 역할을 대신 수행한다.

Sharding

• 단일 DB의 부하가 너무 많아 지면 샤딩을 통해 수평 확장을 할 수 있다.
• 동일한 스키마의 데이터를 여러 서버들에 나누어 저장하고, 읽고 쓰는 작업을 수행한다.