<Building Scalable Web Architecture 관련 자료. 1> 의 내용을 정리했다. 자세한 내용은 <Building Scalable Web Architecture 관련 자료. 1> 을 참고하자.
큰 규모의 웹 시스템(large-scale Web system)의 디자인할 때 고려할 점
- Availability
- Performance : fast response, low latency 가 중요.
- Reliability
- Scalability
- Manageability : 쉽고 빠르게 운용할 수 있게 해 주는 것.
- Cost
Availability
분산시스템에서 높은 가용성(high availability) 를 위해서는 아래 사항이 필요하다.- key component 의 중복성에 대한 조심스러운 고려
- 시스템 일부의 실패에 대한 빠른 회복
- 문제가 발생했을 때 우아한 저하(graceful degradation)
Read/Write 속도
읽기 쓰기 속도는 보통 읽기가 빠르다. 그리고 network 의 속도도 대부분의 network 가 upload 속도보다 download 속도가 약 3배정도 빠르게 디자인되어 있다. 그리고 db 에서도 write 속도보다는 읽기의 속도가 더 빠르다.어떤 object 에 대해 read 는 비동기적(asynchronous)으로 가능하고, gzip 압축, chucked transfer encoding 등을 사용해서 network 의 latency 도 줄일 수 있다.
wirte operation 들은 이런 것들이 안되기 때문에 server 에서 가능한 최대 동시 접속수(upper limit)를 쉽게 써버리게 된다.
그리고 비동기로 할 수 없기 때문에 write 는 upload 하는 동안에 계속 connection 을 열어놔야 한다.
해결방법
이런 병목현상에 대한 처리에 대한 방법중 하나는 read 와 write 에 대한 처리를 서버를 각각 두는 것이다. 이러면, 확장하기도 좋고, 문제가 발생했을 때의 원인을 찾기도 편하다.flickr 에서는 각 shard 마다 read/write 을 모두 처리하고, 한 shard 에서 처리할 수 있는 user 의 limit 을 정해 놓았다. 이렇게 해서 user 의 수에 따라 scale 을 넓혀 나가게 된다. 그리고 문제가 발생해도 특정 부분만 사용을 못하기 때문에 다른 shard 를 사용하면 된다. (마치 web 같은 구조다. )
Redundancy
중복해서 구성해 놓으면 문제가 발생했을 때 다른 부분을 이용하고, 문제가 발생한 부분을 제외시켜서 사용할 수 있다.그리고 문제가 발생할 때 복구하기도 좋다.
memory access 는 disk 에서 읽는 것보다 sequential read 에서는 6배 빠르고, random read 에서는 100,000 배 빠르다.(see The Pathologies of Big Data) 하지만 모든 자료를 memory 에 올려놓는 것은 매우 비용이 많이 든다.
Read data efficiently
read 의 효율을 높이는 다른 방법으로는 아래와 같은 것들이 있다.- Cache
- proxy
- index
- load balancer
Write data efficiently
- Queue
Building Scalable Web Architecture 관련 자료
- Building Scalable Web Architecture and Distributed Systems By Kate Matsudaira, December 31, 2012, Dr Dobb
- how to build scalable production Internet services and how not to build them
http://lethargy.org/~jesus/misc/Scalable%20Ti.pdf - Building Scalable Web Sites: Tidbits from the sites that made it work, Gabe Rudy
- Facebook Performance Caching
- Scaling memcached at Facebook
댓글 없음:
댓글 쓰기