Designing Data-Intensive Applications - (2) Defining NonFunctional Requirements

O’Reilly Online LearningDesigning Data-Intensive Applications, 2nd Edition

Designing Data-Intensive Applications, 2nd Edition

Data is at the center of many challenges in system design today. Difficult issues such as scalability, consistency, reliability, efficiency, and maintainability need to be resolved.... - Selection from Designing Data-Intensive Applications, 2nd Edition [Book]

O’Reilly Online Learning

YouTubeDistributed Systems lecture series

Distributed Systems lecture series

Accompanying lecture notes: https://www.cl.cam.ac.uk/teaching/2122/ConcDisSys/dist-sys-notes.pdf These videos form an 8-lecture series on distributed systems...

YouTube

Chapter 2: Defining NonFunctional Requirements

The Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. - Alan Kay, in interview with Dr Dobb’s Journal (2012)

• functional requirements

• nonfunctional requirements → obvious things… fast, reliable, secure, legally compliant
• define and measure the performance of a system
• means for a service to be reliable
• allowing a system to be scalable
• making it easier to maintain a system in the long term

Case Study: Social Network Home Timelines

Representing Users, Posts, and Follows

SELECT posts.*, users.* FROM posts
  JOIN follows ON posts.sender_id = follows.followee_id
  JOIN users   ON posts.sender_id = users.id
  WHERE follows.follower_id = current_user
  ORDER BY posts.timestamp DESC
  LIMIT 1000

Materializing and Updating Timelines

1. 서버는 온라인 상태의 followers에게만 새로운 포스트를 전달한다.
• 대상자가 아닌 사람들은 연산하지 않는다.

2. precompute: 결과를 미리 연산한 뒤 이를 캐시에 저장해두어 유저가 요청할 때 빠르게 보여준다.
• 특정 이벤트 발생으로 포스트 생성 비율이 증가할 경우, 즉각적으로 타임라인에 전달하기 보다, enqueue 해두어 followers의 타임라인에 조금은 느리게 보여지더라도 캐시를 통해 전달하여 그 시간 간극을 줄일 수 있다.

• materialization ← Pre-computing
: precomputing and updating the results of a query

• materialization view ← cache
: the timeline cache

• materialization donwside
• 만약 많은 셀럽이 동시간에 포스트를 생성하면 많은 양의 작업을 수행해야 함
→ 그럼 셀럽이 동시간에 포스트를 쓰지 않게 하면 해결되지만 이는 현실적으로 어려움
• 해결 방법 중 하나로, celebrity 포스트와 ~celebrity 포스트를 분리해서 관리할 것.

Describing Performance

1. Response time (seconds): the elapsed time

2. Throughput: somethings per second

• 계속 요청이 쌓이게 된다면 retry storm 발생

• load가 줄어든다고 해도 시스템은 reboot 또는 reset 하지 않는 이상 여전히 over-loaded 상태
→ metastable failure

1. client-side resilience
• exponential backoff: client side에서 재시도를 랜덤한 시간 이후로 진행
• circuit breaker: 오류가 반환되거나 타임아웃되는 요청을 그만 보낼 것
• token bucket algorithm: 클라이언트가 요청을 보내는 속도를 제어(Rate Limiting)하는 알고리즘 / 버킷에 담긴 토큰만큼만 요청을 보낼 수 있게 하여 일시적인 트래픽 폭주를 제어

2. server-side protectino
• load shedding: 서버가 과부하 상태에 도달했음을 감지하면, 중요도가 낮은 요청을 선제적으로 거절하여 핵심 기능의 가용성을 유지하는 전략
• backpressure: send back response asking clients to slow down (ex. HTTP 429 Too Many Requests)

1. 사용자 관점 → response time

2. 운영/비용 관점 → throughput

3. 시스템 설계의 목표 ⇒ scalability

Latency and Response Time

1. service time
: 서버가 클라이언트의 요청을 처리하기 위해 실제 작업을 수행하는 시간
: 순수하게 연산이나 로직이 실행되는 시간만을 의미

2. queueing time
: 요청이 처리되기 전이나 후에 어딘가에서 기다리는 시간

3. latency
: 요청이 실제로 처리되지 않고 있는 모든 시간을 통칭
+) network latency: 요청과 응답이 네트워크 망을 통해 이동하는 시간

4. response time
: 클라이언트 입장에서 체감하는 전체 시간
→ 클라이언트가 요청을 보낸 시점부터 응답을 받을 때 까지 걸린 모든 지연 요소를 포함한 시간

Average, Median, and Percentiles

Use of Response Time Metrics

Reliability and Fault Tolerance

1. functional correctness: performs the function that the user expected

2. fault tolerance for users: can tolerate the user making mistakes

3. performance under load: good enough for the required use case

4. security & abuse prevention: prevents any authorized access and abuse

Fault Tolerance

• 많은 심각한 버그는 실제 장애 자체가 아니라 장애를 처리하는 코드가 제대로 작동하지 않기 때문에 발생
→ 장애 대응 로직을 지속적으로 훈련시키고 테스트함으로써, 실제 상황이 닥쳤을 대 시스템이 제대로 복구될 수 있다는 확신을 얻을 수 있음

Hardware and Software Faults

However, in a large-scale system, hardware faults happen often enough that they become part of normal system operation.

1. Redundancy 중복성을 추가하여 하드웨어의 불완전함을 보완
: cloud systems tend to focus less on the reliability of individual machines and instead aim to make services highly available by tolerating faulty nodes at the software level.
→ 전통적인 방식: 단일 장비 강화 ↔ 클라우드 방식: 소프트웨어적 대응
• Availability Zones 가용 영역을 사용함으로써 물리적으로 떨어진 곳에 자원을 배치해 동시에 고장날 확률을 줄임

2. Software Faults
: Correlation 때문에 하드웨어 결함보다 더 다루기가 어려움
• every node to fail at the same time in particular circumstances: 동시 다발적 발생
• Cascading failures

The problem of systematic faults in software has no quick solution.

1. 시스템의 가정과 상호작용을 깊이 고민하기

2. 철저한 테스트 및 프로세스 격리

3. 프로세스가 죽어도 다시 시작할 수 있게 설계 (Crash and restart)

4. 재시도 폭풍(Retry storms) 같은 피드백 루프 방지

5. 실제 운영 환경에서의 지속적인 측정과 모니터링

Humans and Reliability

Given a choice between more features and more testing, many organizations understandably choose features.

Scalability

• coping with growth

• add computing resources

• hit the limits

Understanding Load

1. load parameters examples
• 웹 서버: 초당 요청 수 (RPS)
• 데이터베이스: 읽기/쓰기 비율 (Read/Write Ratio)
• 채팅/메시징: 대화방의 동시 접속자 수
• 캐시: 히트율 (Cache Hit Ratio)

2. you can investigate what happens when the load increases
1. 성능 변화 측정 (자원 고정)
2. 자원 투입량 계산 (성능 고정)

Shared-Memory, Shared-Disk, and Shared-Nothing Architectures

1. Shared-Memory
: 모든 CPU가 모든 데이터에 빠르게 접근할 수 있어 프로그래밍이 매우 쉬움 ↔ 확장성의 한계가 명확

2. Shared-Disk
: 여러 대의 서버가 동일한 데이터를 바라보므로 관리가 비교적 수월 ↔ 디스크 저장소 자체가 Bottleneck

3. shared-nothing architecture / horizontal scaling or scaling out
: 각 노드(컴퓨터)가 자신만의 CPU, 메모리, 디스크를 가짐. 노드 간의 통신은 오직 네트워크를 통해서만 이뤄짐 → 하드웨어 수준에서는 아무것도 공유하지 않고, 모든 조정은 소프트웨어 계층에서 수행
• 장점
1. it has the potential to scale linearly
2. achieve greater fault tolerance
• 단점
1. requires explicit sharding
2. incurs all the complexity of distributed systems

Principles for Scalability

There is no such thing as a generic, one-size-fits-all scalable architecture (informally known as magic scaling sauce)

1. break a system into smaller components that can operate largely independently from one another
→ microservices, sharding, stream processing, shared-nothing-architectures

2. not to make things more complicated than necessary

Maintainability

Every system we create today will one day become a legacy system if it is valuable enough to survive for a long time.

1. Operability: keep system running smoothly

2. Simplicity: make it easy to understand

3. Evolvability: make it easy to make changes

Operability: Making Life Easy for Operations

1. 역설적인 숙련도 요구: 자동화로 해결할 수 없는 아주 복잡한 문제들만 남아 운영팀은 자동화 이전보다 훨씬 더 높은 수준의 문제 해결을 해야 함

2. 추적의 어려움: 사람이 수동으로 명령어를 입력하다 사고를 치면 뭘 잘못했는지 알기 쉬우나 자동화 시스템이 오작동하면 수많은 추상화 계층 속에서 어디가 망가졌는지 찾을 수 없음

• 모니터링 툴을 도입

• 디펜던시를 제거

• 이해를 위한 좋은 수준의 문서화 필요

• 관리자가 주도권을 잃어서는 안된다

• 예측 가능한 동작을 정의해서 의외성을 최소화 해야 한다.

Simplicity: Managing Complexity

1. essential complexity: 문제 자체에 내제된 복잡함 / 비즈니스 로직의 복잡함

2. accidental complexity: 도구, 언어, 인프라로 인해 발생한 복잡함

• 알 필요 없는 것의 격리 → 추상화를 통해 복잡한 내부 동작을 숨김

• 재사용성 → 비슷한 류의 문제에 적용

• 품질의 선순환 → 추상화된 컴포턴트를 하나 개선하면 그것을 사용하는 모든 곳에 혜택이 전파된다.

Evolvability: Making Change Easy

1. 조직적 차원 : agile → 기획이 변경되면 개발 방향을 틀 수 있는 유연함

2. 기술적 차원 : TDD, refactoring → 코드를 고쳐도 시스템이 깨지지 않는다는 확신

Summary

1. reliability 신뢰성
• fault vs. failure → 결함이 장애로 이어지지 않게 설계하는 것이 중요함

2. scalability 확장성
• load parameters를 정의하여 수직 확장 vs. 수평 확장 고려

3. maintainability 유지보수성
• operability: 운영 팀이 시스템을 원활하게 돌릴 수 있도록 모니터링 도구를 제공
• simplicity: 복잡도를 낮추기. 우연적 복잡도를 추상화로 제거하여 예측 가능한 동작을 만드는 것
• evolvability: 비즈니스 요구사항은 변함으로, 유연하게 설계하기