Skip to content

Commit

Permalink
1
Browse files Browse the repository at this point in the history 
1
  • Loading branch information
@winesoft
winesoft committed Apr 15, 2015
1 parent cd00a78 commit c8706ed
Show file tree
Hide file tree
Showing 8 changed files with 245 additions and 48 deletions.
75 changes: 69 additions & 6 deletions admin/adv_topics.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -3,9 +3,14 @@
14장. 최적화와 그 밖의 것들
****************************

이 장에서는 최적화와 그 밖의 잡다한 주제에 관해 다룬다.
서비스 최적화는 곧 메모리 최적화를 의미한다.
메모리 기본설정은 다음과 같다.
이 장에서는 최적화와 그 밖의 잡다하지만 깊이 있는 주제에 대해 다룬다.
최적화는 고성능(High Performance)을 위한 방법이며 이는 우리가 추구하는 가장 큰 가치다.
엔터프라이즈 환경에서의 고성능은 주어진 하드웨어 자원을 최대한 활용하는 것을 의미하기도 한다.

그 중 메모리는 모든 설계 및 정책을 결정하는 가장 중요한 자원이다.
특히 인덱싱(요청된 URL을 빠르게 찾는 것)에 대해서는 반드시 이해해야 한다.
왜냐하면 서비스 품질을 결정짓는 것은 인덱싱이기 때문이다.
앞으로 설명할 모든 내용은 다음 표 "물리 메모리 크기에 따른 기본설정"와 관련이 있다.

============= ============== =============== ============= ========
Physical RAM System Free Contents Caching Count Sockets
Expand All @@ -20,11 +25,69 @@ Physical RAM System Free Contents Caching Count Sockets
128GB 51.20GB 38.05GB 45,390,095 20,000
============= ============== =============== ============= ========

STON은 Memory-Indexing을 사용하므로 물리 메모리가 감소할 경우(i.e. 16GB -> 8GB) 오래된 순서대로 파일을 삭제한다.



.. toctree::
:maxdepth: 2



.. _adv_topics_indexing:

인덱싱
====================================

인덱싱 모드를 설명하기에 앞서 Hot콘텐츠와 Cold콘텐츠의 개념을 이해해야 한다.

.. figure:: img/indexing_hot_cold.png
:align: center

원본으로부터 캐싱한 콘텐츠는 로컬 디스크에 저장된다.
해당 콘텐츠가 접근될 때마다 매번 디스크에서 읽어 전송하면 당연히 성능이 저하된다.
따라서 자주 접근되는 콘텐츠를 메모리에 적재해 놓으면 고성능을 얻을 수 있다.
이렇게 메모리에 적재된 콘텐츠를 Hot, 디스크에만 위치한 콘텐츠를 Cold라고 부른다.

인덱싱은 Hot과 Cold콘텐츠를 찾는 방식을 의미하며 이는 성능과 직결된다.
기본은 메모리 인덱싱이다. ::

# server.xml - <Server><Cache>
<Indexing>Memory</Indexing>

메모리 인덱싱에서는 Cold가 존재하지 않는다.
모든 파일에 대한 정보는 메모리에 적재되기 때문에 메모리 없는 경우 원본서버에서 신규로 다운로드 한다.
그 만큼 고성능과 빠른 서비스 품질을 얻을 수 있다.
하지만 메모리 저장공간의 한계로 인해 캐싱 개수에 한계가 있다.
그 한계는 앞선 표의 Caching Count에서 명시한다.

디스크 인덱싱은 Hot에 없는 경우 원본으로 가기 전에 Cold에서 콘텐츠를 찾는다. ::

# server.xml - <Server><Cache>
<Indexing>Disk</Indexing>
이 방식은 메모리 제한을 받지 않기 때문에 Caching Count에 제한이 없다.
Hot 콘텐츠의 경우 빠른 품질을 보장하지만, Cold의 경우 디스크를 사용하기 때문에 높은 성능을 기대하긴 어렵다.
간단히 정리하면 Hot은 메모리 속도, Cold는 디스크 속도에 수렴한다.

디스크 인덱싱을 사용할 경우 SSD를 사용할 것을 강력히 권장한다.
인덱싱은 STON이 설치된 디스크에서만 수행된다.
STON은 일반적으로 OS와 같은 디스크에 설치되기 때문에 OS디스크만 SSD로 사용해도 고성능을 기대할 수 있다.

.. note::

SSD의 수명은 접근 빈도보다 Write되는 양에 의해 결정된다.
Intel이나 Samsung등에서 공급하는 SSD의 경우 최소 600TB의 Write수명을 보장한다.
이를 단순히 계산해보면 하루에 20GB씩 Write할 경우 10년 정도의 수명을 예측할 수 있다.
STON에서의 Write의 99%는 Log다.
이런 관점에서 Log를 SSD가 아닌 다른 디스크(SAS나 SATA등)에 기록하도록 하면 내구성을 보장할 수 있다.


.. warning::

인덱싱은 동적으로 변경할 수 없을 뿐만 아니라 변경하여도 안정성이 보장되지 않는다.
그러므로 모드를 변경한 뒤 :ref:`getting-started-reset` 를 진행해야 안전하게 서비스할 수 있다.



.. _adv_topics_mem:
Expand Down Expand Up @@ -232,7 +295,7 @@ Keep-Alive시간을 길게 줄수록 소켓의 재사용성은 좋아지지만
이 수치를 3~4만 정도로 설정하는 것이 좋다.
이로 인해 얻을 수 있는 효과는 다음과 같다.

- 별다른 Network 구성(i.e. L4 세션조절 등)이 필요 없다.
- 별다른 Network 구성(e.g. L4 세션조절 등)이 필요 없다.
- 불필요한(원본 부하로 처리될 수 없는) 클라이언트 요청을 방지한다.
- 서비스의 신뢰성을 높인다. 서비스 Burst 이후 재시작 등 점검 작업이 필요 없다.

Expand Down
4 changes: 2 additions & 2 deletions admin/caching_policy.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -28,6 +28,8 @@ HTTP의 여러 기능에 따라 같은 URL이라고 하더라도 콘텐츠가



.. _caching-policy-ttl:

TTL (Time To Live)
====================================

Expand All @@ -40,8 +42,6 @@ TTL은 한번 설정되면 만료되기 전까지 바뀌지 않는다.
관리자는 :ref:`api-cmd-purge` , :ref:`api-cmd-expire` , :ref:`api-cmd-expireafter` , :ref:`api-cmd-hardpurge` 등의 API를 사용해 TTL을 변경할 수 있다.


.. _caching-policy-ttl:

기본 TTL
---------------------

Expand Down
63 changes: 44 additions & 19 deletions admin/caching_purge.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -6,40 +6,37 @@
이 장에서는 Caching된 콘텐츠를 무효화하는 방법에 대해 설명한다.
업계용어로 Purge로 통칭하지만 다양한 상황과 환경으로 인해 세분화된 API가 필요하다.

보통 콘텐츠는 :ref:`ttl-time-to-live` 에 기반한 갱신주기를 가진다.
하지만 명백히 콘텐츠가 변경되었고 관리자가 이를 즉시 반영하고 싶을 경우 :ref:`ttl-time-to-live` 이 만료될 때까지 기다릴 필요는 없다.
원본으로부터 캐싱된 콘텐츠는 :ref:`caching-policy-ttl` 에 기반한 갱신주기를 가진다.
하지만 명백히 콘텐츠가 변경되었고 관리자가 이를 즉시 반영하고 싶을 경우 :ref:`caching-policy-ttl` 이 만료될 때까지 기다릴 필요는 없다.
`Purge`_ / `Expire`_ / `HardPurge`_ 등을 사용하면 즉시 콘텐츠를 무효화시킬 수 있다.

무효화 API는 단순히 브라우저에 의해 호출되는 경우도 있지만 자동화되어 있는 경우가 많다.
가령 FTP를 통한 파일 업로드가 끝나면 즉시 `Purge`_ 를 호출하는 식이다.
관리자는 다음과 같이 몇가지 정책에 대해 설정할 수 있다. ::
관리자는 다음과 같이 몇가지 동작방식에 대해 설정할 수 있다. ::

# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<Purge2Expire>NONE</Purge2Expire>
<RootPurgeExpire>ON</RootPurgeExpire>
<ResCodeNoCtrlTarget>200</ResCodeNoCtrlTarget>
<ResCodeNoCtrlTarget>200</ResCodeNoCtrlTarget>

- ``<Purge2Expire> (기본: NONE)``

`Purge`_ 요청을 설정에 따라 `Expire`_ 로 처리한다.
예를 들어 루트 디렉토리(/)를 `Purge`_ 하는 경우 의도하지 않게 많은 컨텐츠가
예를 들어 특정 패턴(*.jpg)를 `Purge`_ 하는 경우 의도하지 않게 많은 컨텐츠가
삭제되어 원본에 과도한 부하를 발생시킬 수 있다.
이런 경우 `Expire`_ 로 처리하도록 설정하면 과도한 원본부하를 방지할 수 있다.
- ``NONE`` `Expire`_ 로 처리하지 않는다.
- ``ROOT`` 도메인 루트 디렉토리(/) `Purge`_ 를 `Expire`_ 로 처리한다.
- ``DIR`` 모든 디렉토리 `Purge`_ 를 `Expire`_ 로 처리한다.
- ``ROOT`` 도메인 전체(/*)에 대한 `Purge`_ 를 `Expire`_ 로 처리한다.
- ``PATTERN`` 모든 패턴 `Purge`_ 를 `Expire`_ 로 처리한다.
- ``MULTIPLE`` 모든 디렉토리와 패턴 `Purge`_ 를 `Expire`_ 로 처리한다.
- ``ALL`` 모든 `Purge`_ 를 `Expire`_ 로 처리한다.
- ``<RootPurgeExpire> (기본: ON)``

루트(/) 디렉토리에 대한 의도하지 않은 `Purge`_ / `Expire`_ 는 과도한 원본서버
부하를 발생시킬 수 있다.
이 설정을 통하여 루트 디렉토리에 대한 `Purge`_ / `Expire`_ 를 차단할 수 있다.
전체 콘텐츠에 대한 의도하지 않은 `Purge`_ / `Expire`_ 는 과도한 원본서버 부하를 발생시킬 수 있다.
이 설정을 통하여 전체 콘텐츠에 대한 `Purge`_ / `Expire`_ 를 차단할 수 있다.
이 설정은 ``<Purge2Expire>`` 보다 우선한다.

- ``ON`` `Purge`_ / `Expire`_ 를 허용한다.
Expand All @@ -53,15 +50,43 @@
HTTP 응답코드를 설정한다.


.. warning:
대상 지정은 URL, 패턴 2가지로 표현한다. ::

명확한 URL 외에 패턴이나 디렉토리도 무효화가 가능하다.
하지만 작업을 수행하기 전까지 대상개수를 명확히 알 수 없다.
이는 자칫 관리자의 의도와 다르게 너무 많은 대상을 지정할 수 있다.
이는 실제로 CPU자원을 너무 많이 소모하게 되어 시스템 전체에 부담을 줄 수 있다.
example.com/logo.jpg // URL
example.com/img/ // URL
example.com/img/*.jpg // 패턴
example.com/img/* // 패턴
그러므로 실 서비스 중에는 명확한 URL만을 사용할 것을 강력히 권장한다.
패턴이나 디렉토리 표현은 서비스 OFF상태에서 관리용도로 사용하기 위함이다.
명확한 URL 외에 패턴(*.jpg)으로 무효화가 가능하다.
하지만 작업을 수행하기 전까지 대상개수를 명확히 알 수 없다.
이는 자칫 관리자의 의도와 다르게 너무 많은 대상을 지정할 수 있다.
이는 실제로 CPU자원을 너무 많이 소모하게 되어 시스템 전체에 부담을 줄 수 있다.
그러므로 실 서비스 중에는 명확한 URL만을 사용할 것을 강력히 권장한다.
패턴표현은 서비스에서 배제된 상태에서 관리용도로 사용하기 위함이다.


.. note::

보안적인 이유로 example.com/files/ 같은 특정 디렉토리에 대한 접근은 403 FORBIDDEN등으로 차단된다.
하지만 루트 디렉토리는 예외를 가진다.
예를 들어 사용자가 example.com에 접근하면 브라우저는 루트 디렉토리(/)를 요청한다. ::
GET / HTTP/1.1
Host: example.com
이에 대해 웹서버는 관리자가 설정한 기본 페이지(아마도 index.html 또는 index.htm)로 응답한다.
분명 웹 서비스 구성에서 루트 디렉토리(/)는 디렉토리가 아닌 페이지로 동작한다.

하지만 Cache서버는 루트 디렉토리(/)에 접근했더니 200 OK 페이지가 왔다고 이해한다.
심지어 원본서버가 어떤 페이지를 응답했는지 알지 못한다.
간단히 정리하면 Cache서버의 관점에서는 디렉토리 표현도 URL의 한 종류일 뿐이다. ::
example.com/img/ // example.com 가상호스트의 /img/ 에 접근한 결과 페이지
example.com/ // example.com 가상호스트의 기본 페이지(/)
example.com/img/* // example.com 가상호스트의 /img 디렉토리와 그 하위 페이지
example.com/* // example.com 가상호스트의 모든 콘텐츠


.. toctree::
Expand All @@ -81,7 +106,7 @@ Purge후 최초 접근 시점에 원본서버로부터 컨텐츠를 다시 캐

http://127.0.0.1:10040/command/purge?url=...
타겟 컨텐츠는 URL, 디렉토리, 패턴으로 지정할 수 있을 뿐만 아니라 "|"(Vertical Bar)를
타겟 컨텐츠는 URL, 패턴으로 지정할 수 있을 뿐만 아니라 "|"(Vertical Bar)를
구분자를 사용하여 복수의 도메인에 복수의 타겟을 지정할 수 있다.
만약 도메인 이름이 생략되었다면 최근 사용된 도메인을 사용한다. ::
Expand Down
Binary file modified admin/img/Thumbs.db
View file
Binary file not shown.
Binary file added admin/img/indexing_hot_cold.png
View file
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
64 changes: 45 additions & 19 deletions admin/monitoring_stats.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -500,24 +500,25 @@ System 통계
"Outbound":0, <Memory>784786700</Memory>
"Session":0 <SecuredMemory>0</SecuredMemory>
}, <Disk> ... </Disk>
"Memory":785740769, <Session> ... </Session>
"SecuredMemory":0, <File Total="458278" Opened="15" Instance="458292"/>
"Disk": { ... }, <Cached> ... </Cached>
"Session": { ... }, <CacheFileEvent> ... </CacheFileEvent>
"FileTotal":458308, <WaitingFiles2Delete>1087593</WaitingFiles2Delete>
"FileOpened":15, <ClientHttpReqBypass Sum="8100">27</ClientHttpReqBypass>
"FileInstance":458320, <ClientHttpReqDenied Sum="400">1</ClientHttpReqDenied>
"Cached": { ... }, <OriginTraffic> ... </OriginTraffic>
"CacheFileEvent": { ... }, <PortBypass> ... </PortBypass>
"WaitingFiles2Delete":1087595, <ClientTraffic> ... </ClientTraffic>
"ClientHttpReqBypassSum":8100, <UrlBypass> ... </UrlBypass>
"ClientHttpReqBypass":27, </VirtualHost>
"ClientHttpReqDeniedSum":400, <VirtualHost> ... </VirtualHost>
"ClientHttpReqDenied":1, <VirtualHost> ... </VirtualHost>
"OriginTraffic": { ... }, <VirtualHost> ... </VirtualHost>
"PortBypass": { ... },
"ClientTraffic": { ... },
"UrlBypass": { ... },
"Memory":785740769, <Session> ... </Session>
"SecuredMemory":0, <Dims> ... </Dims>
"Disk": { ... }, <File Total="458278" Opened="15" Instance="458292"/>
"Session": { ... }, <Cached> ... </Cached>
"Dims": { ... }, <CacheFileEvent> ... </CacheFileEvent>
"FileTotal":458308, <WaitingFiles2Delete>1087593</WaitingFiles2Delete>
"FileOpened":15, <CacheFileEvent Create=\"%u\" Swap=\"%u\" Erase=\"%u\" Purge=\"%u\" Expire=\"%u\" />
"FileInstance":458320, <ClientHttpReqBypass Sum="8100">27</ClientHttpReqBypass>
"Cached": { ... }, <ClientHttpReqDenied Sum="400">1</ClientHttpReqDenied>
"CacheFileEvent": { ... }, <OriginTraffic> ... </OriginTraffic>
"WaitingFiles2Delete":1087595, <PortBypass> ... </PortBypass>
"ClientHttpReqBypassSum":8100, <ClientTraffic> ... </ClientTraffic>
"ClientHttpReqBypass":27, <UrlBypass> ... </UrlBypass>
"ClientHttpReqDeniedSum":400, </VirtualHost>
"ClientHttpReqDenied":1, <VirtualHost> ... </VirtualHost>
"OriginTraffic": { ... }, <VirtualHost> ... </VirtualHost>
"PortBypass": { ... }, <VirtualHost> ... </VirtualHost>
"ClientTraffic": { ... },
"UrlBypass": { ... }
},
...
]
Expand All @@ -530,6 +531,7 @@ System 통계
- ``SecuredMemory (단위: Bytes)`` 메모리에서 삭제한 컨텐츠 양
- ``Disk`` 디스크 정보
- ``Session`` 세션 정보
- ``Dims`` DIMS변환 통계
- ``FileTotal`` 전체파일 개수
- ``FileOpened`` 열려져 있는 로컬파일 개수
- ``FileInstance`` 캐싱파일 개수
Expand All @@ -541,7 +543,7 @@ System 통계
- ``OriginTraffic`` 원본서버 트래픽 통계
- ``PortBypass`` 포트 바이패스 트래픽 통계
- ``ClientTraffic`` 클라이언트 트래픽 통계
- ``UrlBypass`` URL매칭 또는 ``<BypassNoCacheRequest>`` 를 통해 원본서버로 바이패스되는 HTTP트래픽 통계
- ``UrlBypass`` URL매칭 또는 ``<BypassNoCacheRequest>`` 를 통해 원본서버로변환 통계되는 HTTP트래픽 통계

.. note::

Expand Down Expand Up @@ -656,6 +658,30 @@ System 통계



DIMS 통계
------------------------------

DIMS의 성능지표를 제공한다. ::

"Dims": <Dims
{ Requests="30"
"Requests": 30, Converted="29"
"Converted": 29, Failed="1"
"Failed": 1, AvgSrcSize="1457969"
"AvgSrcSize": 1457969, AvgDestSize="598831"
"AvgDestSize": 598831, AvgTime="34" />
"AvgTime": 34
},
- ``Requests`` 변환요청 횟수
- ``Converted`` 변환성공 횟수
- ``Failed`` 변환실패 횟수
- ``AvgSrcSize (단위: Bytes)`` 원본 이미지의 평균 크기
- ``AvgDestSize (단위: Bytes)`` 변환된 이미지의 평균 크기
- ``AvgTime (단위: ms)`` 변환 소요시간



원본 통계
------------------------------

Expand Down

0 comments on commit c8706ed

Please sign in to comment.