1. Introduction

• Replication : 데이터나 서비스의 복사본을 다수 만들는 것. 같은 데이터가 다수의 저장 장치에 저장되는 것을 data replication 이라고 함(wev site mirror, browser cache, DNS)

Replication	Duplication
한 쪽이 업데이트 되면 다른 한 쪽도 반드시 업데이트 되어야함. 똑같이 사용할 수 있는 저장소.	반드시 양쪽 저장소에 같은 데이터가 저장되어야하는 것은 아니다. (e.g.일주일에 한 번씩 백업)

• Why Replication?
  • Improve reliability (data sruvival, availability, confidence)
  • Improve performance (scalability)
    • 유저 수 증가에 따라 여러 개의 서버가 같은 데이터를 갖게함
    • 유저는 전 세계에 다양하게 있으므로 유저의 access time을 향상시키기 위함

• If Replication is so good, why not just use it?
  • 다수의 복사본(replica)이 있다는 것은 원본이 업데이트가 될 때 복사본도 업데이트 되어야한다.
  • Consistency Problem
    • 어떻게 업데이트 할 것인가?
    • 복사본이 수정되면 나머지 복사본과 다르게 된다.
    • consisteny를 유지하기 위해 정보가 변형되면 다른 복사본들에게도 정보가 전달되어야한다.
    • 언제 어떻게 정보를 전달할 것인가?
• Example
  • 웹페이지 업데이트
    • 브라우저 로컬 캐쉬: html, images
    • 서버에서 업데이트 한 내용이 로컬 캐쉬에 없다면 클라이언트는 업데이트 된 내용을 받지 못한다.
    • 예시 더 있음

1-1. Conditional HTTP GET

• 장점

object transmission delay가 없다.

link utilization을 낮출 수 있다.

• cache

HTTP request에서 복사본을 캐쉬한 날짜를 명시한다.

If-modified-since:<date>

• server
  • 응답에는 obejct가 아니라 cache가 가진 복사본과 비교한 결과를 가져온다.
    • HTTP/1.0 304 Not modified
    • HTTP/1.0 200 OK <data>

• 1-2. Foward Web Proxy

  • 클라이언트 근처에서(같은 라우터 내에 위치) 동작하는 웹 서버
  • response time과 access link traffic을 줄일 수 있다.

• 1-3. Reverse Web Proxy

  • 서버에 위치하고 있으며 데이터 서버의 현관문 역할을 한다.
  • performace optimization
    • 검색 결과 캐싱
    • 공통한 쿼리 캐싱
  • load balancing: 웹 서버를 골고루 분산
  • security: 웹서버에 직접적으로 도스 공격을 못하게함

• Scalability vs Overhead
  • 복사본을 클라이언트 근처에 둔다면 access time이 줄어든다.
  • 반면에 업데이트할 것이 더 많다면 오버헤드가 많이 든다. (주식같은 경우에는 서버 근처에 있어야함)
  • 네트워크 bandwidth을 고려했을 때 업데이트를 자주한다면 서버쪽에 relica를 두는 것이 좋다.

1-4. Tight Consistency

2. Data-centric consistency models

Tight Consistency

Sequential Consistency

Causal Consistency

3. Client-centric consistency models

4. Replica management

5. Consistency protocols