2. Background

2.0 Background

Amazon 의 e-commerce platform

• 수백개의 서비스로 이루어져있다.

• 이 서비스들은 전세계의 여러 Data Center 에 위치한 수만대의 서버들로 이루어진 인프라 안에서 호스트된다.

RDBMS VS NOSQL

• 전통적으로 production system 들은 그들의 상태를 Relational Database 에 저장한다.

• 그러나, 사용 패턴들 중 더 많은 경우에 RDB 는 이상적인 솔루션 아니다.

• 이런 서비스들의 대부분이 Primary Key 로만 데이터를 저장하거나 회수하고, 그 이상의 복잡한 쿼리나 RDBMS가 제공하는 관리 기능은 필요로 하지 않는다.

• Inefficient solution by Expensive hardware, highly skilled personnel for its operation

2.1 System Assumptions and Requirements

Query Model

• simple read and write operations to a data item that is uniquely identified by a key.

ACID properties

• Dynamo targets applications that operate with weaker consistency (the “C” in ACID) if this results in high availability.

Efficiency

• The system needs to function on a commodity hardware infrastructure.

• 값싼 서버들에서도 오류없이 잘 동작해야한다.

• the storage system must be capable of meeting such stringent SLAs

Internal Service -> No security

• Dynamo is used only by Amazon’s internal services.

• to be non-hostile and there are no security related requirements such as authentication and authorization

2.2 Service Level Agreements (SLA)

Architecture of Amazon's platform

보통의 서비스들이 SLA 를 정하는 방법

• provide a response within 300ms for 99.9% of its requests for a peak client load of 500 requests per second.

Amazon 이 SLA 를 정하는 방법

• At Amazon we have found that these metrics are not good enough if the goal is to build a system where all customers have a good experience, rather than just the majority. 대다수가 좋은 경험을 하게 하는것이 아니라, ALL 모두가 좋은 경험을 할 수 있도록 한다.

• To address this issue, at Amazon, SLAs are expressed and measured at the 99.9th percentile of the distribution.

2.3 Design Considerations

⭐️ Conflict 이 났을때 '언제' 그리고 '누가' 해결할것인가

• An important design consideration is to decide when to perform the process of resolving update conflicts, i.e., whether conflicts should be resolved during reads or writes.

전통적인 방식

• Many traditional data stores execute conflict resolution during writes and keep the read complexity simple.

Dynamo 의 방식

• Dynamo targets the design space of an “always writeable” data store

• For instance, the shopping cart service must allow customers to add and remove items from their shopping cart even amidst network and server failures.

• the data store can only use simple policies, such as “last write wins”

• Conflict 에 대한 해결은 읽어가는 주체, 즉 '클라이언트' 단에서 한다. 여기서 클라이언트단은 아예 웹 프론트는 아니고, 최상단 웹서버 정도를 말한다.

Key Principles in the design

1. Incremental scalability

• Dynamo should be able to scale out one storage host (henceforth, referred to as “node”) at a time

2. Symmetry

• Every node in Dynamo should have the same set of responsibilities as its peers

3. Decentralization

• the design should favor decentralized peer-to-peer techniques over centralized control

4. Heterogeneity

• the work distribution must be proportional to the capabilities of the individual servers.

• This is essential in adding new nodes with higher capacity without having to upgrade all hosts at once.

• 'commodity' 와 관련이 깊다.