Scalable Web Architecture

And

Distributed Systems

The Architecture of Open Source Applications

Volume 2

일반적인서비스

Request

Response

ServerClient

대규모시스템설계시고려사항

Availability

Reliability Scalability

Cost Manageability

Performance

Trade-off !!!!

GOALS

- services

- redundancy

- partitions

- handling failure

Example: Image Hosting

Application

Image Hosting Application

Architecture• 저장될이미지의개수에제한이없다. 따라서저장공간의확장성에대해서도고려해야한다

• 이미지보기나다운로드를요청할때응답시간이빨라야한다.

• 사용자가이미지를업로드하고난후, 해당이미지는항상시스템에저장되어있어야한다. (데이터에대한신뢰성)

• 시스템을운용하기쉬워야한다(관리성)

• 이미지호스팅서비스자체의이익율이높지않기때문에, 시스템은비용효율적으로운용될필요가있다.

• 제공하는기능을두가지로한정한다upload(write) 와 query(read)

• Problem 1‘Write'가 'Read'에영향을미친다.

이두가지기능은공유자원을경쟁적으로사용하고있기때문에

다운로드와업로드의속도가똑같다고가정해도 ‘Write'가 'Read'에영향을미친다.

(실제로는다운로드속도와업로드속도비율은 3:1 정도다)

'읽기'는캐시의도움을받을수있지만 '쓰기' 요청은결과적으로디스크까지도달해야하기때문이

다.

• Problem 2디자인관점에서의문제임. 웹서버는동시커넥션수에상한선이있다는것이다.(아파치의경우디폴트 500개)

읽기는비동기일수있기때문에 gzip 압축이나 chunked transfer encoding을

이용하여성능을최적화할수있다. 쓰기의경우에는업로드동안연결을열어놓은상태로유지해야

한다.

만약 1MB를업로드하는것이 1초이상걸린다면서버는고작 500개의동시적인쓰기만처리할수

있을뿐이다.

Services

위문제를해결하기위하여읽기서비스와쓰기서비스를분리한다.

읽기와쓰기를각각독립적으로확장할수있게 한다.

읽기와쓰기를각각의서비스로분리하는것은좋은방법이다.

(보통사용자들은쓰기보다는읽기를더많이한다)

Service-Oriented

Architecture

Services

Flickr(플리커)에서는읽기/쓰기성능문제를해결하기위해서로다른샤드에

사용자를분산시킨다.

각각의샤드는샤드에할당된사용자만처리하고사용자가증가하면이를처

리할수있는샤드를클러스터에추가하는것이다.

Problem !!!!!!!!

그러나언제나오류는발생할수있다.

Redundancy

시스템을이중화하는것은 single point of failure 을없애고,

장애발생시에도백업하게할수있거나시스템이계속동작할수있게한다.

서비스를이중화할때중요한것은 Shared Nothing 아키텍처를만드는것이다.

중요한것은시스템의 single point of failure 를없애고장애에좀더잘대처할수있

게된다.

Problem !!!!!!!!

하나의서버에서감당할수없는많은데이터가있을수

있다.

또는연산을위해많은컴퓨팅자원이필요하게되어성

능이떨어지게되는경우가있을수있다.

Partitions

우리는두가지를선택할수있다.

하나는수직적확장이고, 다른하나는수평적확장

이다.

Partitions- To scale vertically

각각의서버에더많은자원을추가하는것을말한다.

많은데이터를처리하기위해서버에하드디스크나더빠른 CPU나큰용량의메모리를

추가하는게 이에해당한다. 즉, 수직적확장은각자원의처리능력을향상시키는것을

말한다.

- To scale horizontally

데이터가많을경우에는부분데이터를저장할수있는노드를추가하는것이다.

수평적확장의장점을모두취하기위해서는시스템아키텍처의고유한설계

원칙들을따라야한다.

수평적확장을하는가장보편적인방법은서비스를파티션이나샤드단위

로

분할하는것이다

Problem !!!!!!!!

- data locality (데이터로컬리티)연산하려는데이터가가까이위치해있을수록시스템의성능은향상된다.

따라서필요한데이터를여러서버에분산시키는것은로컬에있지않을수

있는데이터를얻기위해비용이높은네트워크를이용한읽기가발생할수

있어잠재적인성능문제가발생할수있다.

- inconsistency (비정합성)공유된자원으로부터읽기와쓰기를하는서로다른서비스가있다고가정할때.

어떠한데이터가업데이트되려할때, 읽기요청이업데이트요청보다먼저발생했다면해

당데이터는비정합성상태가된다.

예를들어어떤클라이언트가어떤이미지이름을 Dog에서 Gizmo로바꾸는업데이트요청

을보냈고,

동시에다른클라이언트가해당이미지를읽고있다면경합조건이발생한다.

fault tolerance and

monitoring reference

• http://katemats.com/distributed-systems-basics-

handling-failure-fault-tolerance-and-monitoring/

The Building Blocks of Fast and

Scalable Data Access

LAMP stack

applications

간단한형태의웹애플리케이션을많은사용자가사용하게되면두가지기술적

인문제에

직면하게된다.

1. 애플리케이션서버에대한데이터액세스를확장성있게하는것이고,

2. 데이터베이스에대한데이터액세스를확장성있게하는것이다.

수테라바이트크기의데이터가있다고가정해보자.

그리고우리는사용자가원하는(랜덤한) 데이터에접근할수있도록하고싶다.

수테라바이트크기의데이터를메모리에올리는것은매우높은비용이필요하

기때문에

모든데이터를메모리에저장하지않으면서도빠른액세스가가능하도록하는

것은어렵다.

여기서성능에가장영향을미치는것은디스크 I/O다.

그러나쉽게하기위한다양한방법이있다.

- Caches (Global Cache, Distributed Cache)

- Proxies

- Indexes

- Load Balancers

GOALS

Caches ?

최근에요청받은데이터는다시요청받을확률이높다는지역성의원리(locality of reference)에기반한방법이다.

캐시란매우짧은시간동안유지되는메모리와같은것이다.

캐시는아키텍처의모든단계에위치할수있지만, 프런트엔드와가까운곳에

위치하는

경우가많다. 왜냐하면보통캐시는서비스의백엔드까지가는시간적인비

용을줄이기위해서사용하는경우가많기때문이다.

Caches

Insert a cache on your request layer node

매번요청은서비스로보내지고, 요청노드에데이터가존재하면그노드는빠

르게

로컬에서캐싱된데이터를보낸다.

만약캐시에데이터가없다면요청노드는디스크에서데이터를질의할것이

다.

Caches

Multiple caches

만약로드밸런서가임의로요청을분산시키면, 같은요청이다른노드로가게될

수도있다. 즉, 캐시미스가증가하게될것이다.

캐시미스를줄이면서여러개의캐시를사용하기위해사용하는방법이

글로벌캐시와분산캐시다.

Global Cache 1

All the nodes use the same single cache space.요청노드에서각각의요청은로컬에캐시를가지고있는것과같은방법으로글로벌캐시에데이터를

질의한다.

데이터노드는오직캐시에만데이터를질의하고, 글로벌캐시는요청받은데이터를자기자신에서찾

을수없을때,

캐시스스로가저장공간에데이터를질의하여요청노드에데이터를전달하도록하는방식이다.

이런아키텍처는특정한상황에서는매우유용하다

(특화된하드웨어를써서글로벌캐시를빠르게만들거나, 캐시가필요한데이터의양이고정된일정량

일때)

글로벌캐시에는두가지의일반적인방식이있다.

Global Cache 2

요청노드가글로벌캐시에서데이터를질의하여데이터가없음을확인하였을때는

직접스토리지에질의하여데이터를가져오는방식이다.

큰크기의파일제공을위하여캐시를사용하는경우에, 낮은캐시히트가발생하면전반적인캐시미스가

증가하게된다.

이경우에는자주사용되는데이터만캐시에위치하게하는것이도움이된다.

Distributed Cache

각각의노드가캐시데이터를갖는방식이다.

Distributed Cache• 일반적으로분산캐시는 consistent hashing 함수를사용한다.

• 해시함수를이용해데이터위치파악할수있다.

• 각각의노드는각각의조그마한캐시를가지고있다

• 요청이들어오면원본저장공간으로요청을보내기전에다른노드에요청을보낸다.

분산캐시의이런점때문에요청풀에노드를추가하면전체캐시크기를증가시킬수있다.

Distributed Cache• 분산캐시의단점장애가발생한노드를처리하는방법이필요하다.

다른노드에여러개의복제본을가지는방법으로해결하기도한다.

• 캐시의장점올바르게만구현되어있다면시스템을더욱빠르게만들수있다캐시를이용해더욱더많은요청을이전보다더빠르게처리하게할수도있다.

그러나캐시시스템에는값비싼메모리와같은추가적인저장공간을유지하기위한비용문제가항상따른다.

OpenSource Cache

로컬캐시나분산캐시두가지모드로동작가능하다.

Distributed Cache

reference

• http://www.slideshare.net/guoqing75/4069180-

caching-performance-lessons-from-facebook

• https://www.facebook.com/note.php?note_id=39391

378919

Proxies

Proxies

프락시는요청을필터링, 로깅, 변환(헤더에속성더하고/빼고, 암호화/복호화, 압

축)하는데사용하고여러서버에서오는요청을받아정리하여, 전체시스템관점

에서요청트래픽을최적화시키는데도도움이된다.

Proxies

Collapsed Forwarding

데이터액세스를빠르게하기위하여프락시가제공하는방법중의하나로

같거나비슷한요청들을모아단하나의요청을만들어내는것을말한다.

요청을그룹화하는데드는시간때문에각각의요청에는더많은레이턴시가발생할

수도있다.

그러나부하가높은상황에서는성능이향상될것이다.

Proxies

프락시를사용하는다른방법으로는공간적으로가까운데이터에대한요청을묶어주는것이있다.

이러한전략은요청의데이터로컬리티를최대화하여, 요청지연을줄일수있다.

수많은요청이 B의일부분을요청(B:partB1, B:partB2) -> 프락시는 bigB 를요청한다.

이러한방식은클라이언트가수테라바이트크기데이터의일부분을랜덤하게요청할때요청시간을단

축시킬수있다.

프락시는여러번의요청을한번에처리하기때문에높은로드상황이나캐시사용이제한적인상황에서

특히유용하다.

Open Source Proxies

Indexes

빠른데이터액세스를위해서인덱싱전략을사용하는것은굉장히잘알려져있는방법이

다.

데이터크기가수테라바이트지만전달해야할데이터크기가작을때는(예를들어 1KB정

도), 데이터액세스를최적화하기위해인덱스는필수적이다.

인덱스는목차와같이데이터가어디에위치하는지알려주는역할을한다.

Indexes

BerkeleyDB와트리형태의데이터구조는이러한정렬된리스트를저장하고

색인을사용하는이상적이고보편적인방법이라할수있다.

때때로맵의형태를가진여러개의레이어로이루어진인덱스도있다.

Load Balancers

로드밸런서는어떤아키텍처에서든중요하다.

로드밸런서는서비스요청을여러노드에게분배하는일을한다.

로드밸런서의주목적은동시에오는수많은커넥션을처리하고해당커

넥션이

요청노드중의하나로전달될수있게하는것이다.

또한노드를추가하는것만으로서비스가확장성을가질수있도록한다.

Open Source Load

Balancers

로드밸런서에서서비스요청을처리하는방법에는다양한알고리즘이있다.

( 랜덤, 라운드로빈, CPU나메모리사용률등과같은특정범주에따라노드를선택하는등의방법이있다)

로드밸런서는소프트웨어로구현될수도있고하드웨어제품이될수도있다.

Multiple Load Balancers

프락시처럼어떤로드밸런서는요청의종류를파악하고해당요청을처리

할수

있는노드에전달하는기능을가지고있다

(기술적으로이러한형태를리버스프락시라고부른다).

Queue

시스템이확장성있도록설계하려면쓰기에대한고려또한필요하다.

데이터가여러곳에분산된서버나인덱스에쓰여야하고당시의시스템부하상태가

높다면쓰기연산은매우오랜시간이걸리게된다.

이럴때시스템의성능과가용성을얻기위해서사용하는보편적인방법은큐를사용하

는것이다.

Queue

하나의서버가들어오는클라이언트의모든요청을처리하는작은시스템이라도데이

터양이

적다면별문제없이작동할수있다.

하지만하나의서버가자신이해결할수있는요청보다더많은요청을받게되면, 각클

라이언트는다른클라이언트의요청이끝나기전까지기다려야한다.

이러한종류의동기적인행동은클라이언트의성능을심각하게저하시킨다.

Queue

이러한문제를효과적으로풀기위해서는클라이언트의요청과서비스를처리하기위해서처리되는일

사이에

추상화가필요하다.

클라이언트가큐로작업요청을보내고난다음에는그결과를기다릴필요가없다. 대신큐에요청이잘

쌓였다는

응답(acknowledgement)만받는다.

큐의장점은클라이언트가비동기방식으로동작할수있게한다는데에있다.

클라이언트의요청과그것에대한응답사이에전략적추상화를제공하는것이다.

OR

reference

• http://helloworld.naver.com/hell

oworld/206816

• http://www.aosabook.org/en/dis

tsys.html