서비스 설계의 원칙¶

서비스의 성공은 가용성, 속도, 확장성에 달려있다. “확장성 웹 아키텍처와 분산 시스템 설계”를 쓴 Kate Matsudaira도 이 세 가지 원칙을 강조한다.

가용성 (availability)

서비스는 항상 가능해야 한다. 장애발생시 90%의 고객은 경쟁사로 이동한다. 완벽한 시스템은 없지만, 장애시 복구는 신속해야 한다.

속도 (speed)

비즈니스에서 시간은 금이다. 느린 응답시간은 매출 감소다. 응답시간이 0.1초 지연되면 매출 1%가 감소한다. Amazon.com의 고객 47%는 웹페이지가 2초 안에 열리기를 원한다.

확장성 (scalability)

고객이 만명이든 백만명이든 서비스는 원활해야 한다. 크기를 키우고 유지하는 노력, 스토리지 확장 용이성, 트랜잭션 처리 여력도 확장성이다. 관리의 확장성도 빠질 수 없다. 진단, 문제 이해, 업데이트와 변경이 쉬워야 한다.

모든 원칙은 최소의 비용으로 지킬수록 효율적이다. 비용은 돈 뿐만이 아니라 시간, 노력, 훈련 등도 포함한다.

성공적인 서비스는 성장 한다. 더 많은 고객과 더 많은 컨텐츠를 감당해야 한다. 성장하면 할수록 원칙들은 더 지키기 어렵다. 어떻게 하면 이 원칙들을 쉽게 최소비용으로 지킬 수 있을까?

서비스의 성장¶

테스트나 파일럿 서비스는 한두대의 서버로 시작한다. 서비스가 조금씩 성장한다. 서버 수는 야금야금 늘어난다. 컨텐츠 갱신은 한 대씩 꼼꼼하게 해야 한다. 손발이 고생할 뿐, 아직까지는 관리에 큰 무리가 없다.

서비스가 성장하기 시작한다. 고객이 늘고, 쌓을 데이터가 점점 커진다. 서버들을 일일이 관리하는 것도 어려워진다. 데이터를 한 곳에 모을 고비용의 스토리지를 도입한다 (NAS, SAN, DAS 등). 고비용이지만 신뢰할 수 있을 것 같다. 컨텐츠 갱신이 쉬워졌다. 스토리지에 올린 컨텐츠는 서버들이 자동으로 가져 간다.

서비스가 가파르게 성장한다. 서버 대수를 늘렸더니 스토리지의 전송 부하가 커졌다. 더 빠른 스토리지는 굉장히 고비용이다. 도입이 망설여 진다. 투자할 가치가 있을까.

동기화 (synchronization) 솔루션을 검토한다. 서버에 데이터 전체를 준비시킬 수는 없다.스토리지에서 컨텐츠를 선별해야 한다. 정확하게 제어하려면 관리 기술이 필수다. 서버 몇 대의 동기화 관리는 쉽다. 그러나 서버와 파일 수가 늘어날 수록 힘들어진다. 갈수록 나빠진다. 커질수록 느려지고 어렵고 불안정하다.

컨텐츠는 계속 변화한다. 추가하고 삭제할 파일이 많아질 수록 동기화 시간은 길어진다. 서비스 규모가 커질 수록, 동기화 관리 시스템도 필연적으로 커지고 복잡해진다. 관리 시스템의 장애는 곧 전체 장애를 일으킨다.

컨텐츠를 빠르고 유연하게 전송할 수 있는 쉬운 방법이 필요하다.

서비스 확장성과 전송¶

계층화 (layering) 로 서비스를 모델링 하면 다음 그림과 같이 두 계층으로 나눌수 있다.

중심에 데이터를 관리하는 스토리지 (storage) 계층이 있다. 그 위에는 서비스 로직이 구현된 어플리케이션 (application) 계층이 있다. 어플리케이션 계층은 소규모 고객용 컨텐츠 전송도 처리할 수 있다. 초기에는 스토리지와 어플리케이션 계층만으로 서비스를 구성할 수 있다.

서비스가 성장하면서 처리비용은 변화한다. 초기에는 로직 개발이, 성장기에는 고객증가와 함께 데이터 관리가 가장 많은 비용을 차지한다. 서비스가 발전할 수록 가장 큰 고민은 컨텐츠 전송 이다. 폭발하는 대역폭을 어떻게 해결할 것인가? 컨텐츠 전송 은 서비스 증설 (Scale-out)의 큰 과제이다.

엣지 (edge) : 전송 계층¶

서비스가 성장할 수록, 전송에 대한 부담은 기하급수적으로 커진다. 쇼핑몰의 컨텐츠 개수는 많게는 수십 억 개에 이른다. 동영상 서비스의 컨텐츠는 TB에 이른지 오래다. 서비스의 증설에는 컨텐츠 전송의 확장성 (scalibility) 을 반드시 고려해야 한다.

엣지(edge)는 서비스의 가장 바깥, 최전방을 가리킨다. 엣지에서 고객은 속도와 가용성을 체험한다. 고객이 요청하는 컨텐츠는 무슨 일이 있어도 ‘반드시’ 전송해야 한다. 고객이 보는 화면에서 깨진 이미지, 심지어 접속불능은 매우 치명적이다. 엣지에서 컨텐츠 전송을 처리하면 어플리케이션과 스토리지의 전송부담은 줄어든다.

엣지의 확장이 쉽고 효율적이면 다른 고비용 계층을 증설할 필요가 없다. 스토리지와 어플리케이션의 증설은 고비용의 비효율적 선택이다.

그렇다면 STON 엣지 서버는 어떻게 컨텐츠 전송을 쉽고 빠르게 바꿀까?

엣지 서버의 동작 방식: 캐시(cache)¶

전송의 규모는 고객의 수와 컨텐츠 크기에 따라 커진다. 얼마나 많은 고객이 어떤 컨텐츠를 요청하는지는 엣지에서 가장 빨리 알 수 있다. 엣지로부터 Bottom-up의 처리흐름이 효율적이다. 따라서 엣지 서버는 고객의 요청에 따라 On-demand 로 동작하는 캐시(cache) 전송방식을 채택하였다. 관리 시스템도 필요없다. 구체적인 동작은 다음과 같다.

엣지 서버는 첫번째 컨텐츠 전송 요청을 받았을 때, 원본 계층으로부터 컨텐츠를 가져와 고객에게 전송한다. 이 컨텐츠를 엣지 서버 자신에게도 저장한다. 두번째 요청 및 그 이후부터는 저장했던 컨텐츠를 고객에게 즉시 전송한다. 저장된 컨텐츠는 미리 설정된 TTL (Time-To-Live) 시간만큼 유효하다.

엣지 서버는 이러한 방식으로 상당한 양의 컨텐츠 전송을 처리할 수 있다. 어플리케이션과 스토리지의 증설을 최소화하면서 빠른 대용량 전송을 처리한다. 성장하는 서비스라면 반드시 엣지를 고려해야 한다.

STON 엣지 서버는 무제약/무조건을 지향하는 소프트웨어다. 어떤 하드웨어에 설치되든 최대 성능을 발휘하도록 설계되었다.

CPU: Many-Core에 최적화되었다. Throughput은 코어개수에 비례한다.

Memory: Memory가 많을수록 빠르게 처리한다. Disk I/O를 절감한다.

Disk: I/O 를 균등 분산한다. 더 많은 데이터를 caching한다.

NIC: 4Gbps NIC Bonding 또는 10Gbps NIC의 Bandwidth를 보장한다.

STON 엣지 서버는 강력한 라이브 모니터링/로그 를 지원한다. 초 단위의 실시간 통계로 지금 당장 서비스 상태가 어떤지 확인할 수 있다. JSON, XML, SNMP 등의 여러 범용포맷으로 실시간 숫자를 제공한다.

STON은 관리자를 위한 쉬운 설정 을 제공한다. STON의 설계이념은 관리자를 위한 엣지 서버다. Web Management 페이지를 통해 직관적인 설정방법을 제공한다. 디테일한 설정을 원할 경우, 단 두 개의 XML 설정 파일로 쉽게 할 수 있다.

엣지 서버의 효과¶

엣지 서버의 효과는 다음과 같다.

1. 쉽고 편리한 서비스 가속
2. 서비스 원본을 외부로부터 보호 (Origin Shielding)
3. 서비스가 핵심적인 역할을 수행할 수 있도록 보조

엣지 서버의 효과는 다음 적용사례를 중심으로도 확인할 수 있다.

Game¶

전통적으로 게임 서비스는 엄청나게 많은 대역폭을 필요로 한다. “대작” 게임부터 간단한 캐주얼 게임까지 범주도 매우 다양하다. 특히 스마트폰 게임의 폭발적 성장과 전파속도는 서비스 형태를 더욱 다양하게 만들었다.

• 높은 대역폭 출력

  단일 서버로 높은 대역폭을 얻는 전통적인 방법은 1Gbps NIC를 본딩(Bonding)하는 것이다. 이를 통해 4Gbps 대역폭까지 얻을 수 있다. 최근 10Gbps NIC도 시장에 많이 보급되는 추세이다.

  STON 4Gbps NIC Bonding과 10Gbps NIC에서도 최대 대역폭을 보장한다.

• 사용자 대역폭 보장

  모든 사용자는 게임을 빨리 다운로드 받고 싶어한다. 광랜 사용자는 100Mbps의 속도가 얻어지지 않는다면 항의 전화를 걸 것이다. 모두들 빨리 게임을 시작하고 싶어한다. 서버는 물리적으로 대역폭이 꽉 차지 않는 이상 사용자마다의 최대 속도를 균일하게 보장해야 한다.

  STON 모든 사용자에게 최대 속도로 전송하는 것을 보장한다.

• 대용량 파일 처리

  설치파일이 4GB정도 하는 게임은 이제 대형게임으로도 분류되지도 않는다. 수십 GB는 되어야 “대작”이라는 단어를 달 수 있는 세상이다. 파일이 너무 크면 서버 메모리에 모두 Caching 할 수 없다. 최악의 상황은 파일의 크기가 너무 커서 사용자마다 다운로드 받는 위치가 제각각인 상황이다.

  STON Caching 파일크기 제한이 없다. Memory와 Disk의 적절한 Swap을 통해 언제나 고성능을 보장한다.

• Range 요청처리

  전송 파일이 대형화되는 추세에 따라 Grid Delivery기법의 P2P솔루션도 많이 사용되고 있다. 이런 솔루션의 특징은 파일을 잘게 조각 내어 주고 받기 때문에 서버에 엄청나게 많은 HTTP Range요청을 보낸다. 10GB파일을 만 명의 클라이언트가 서로 다른 Range로 요청하는 상황도 가능하다. 어느 부분을 요청하더라도 서비스는 즉시 가능해야한다. 하지만 원본서버에서는 반드시 원래 파일의 크기만큼만 데이터가 전송되어야 한다.

  STON Range요청에 최적화된 파일 시스템이 탑재되었다. 또한 멀티 다운로드를 통해 빠른 응답성을 보장한다. 원본서버로부터 1Bytes라도 불필요한 다운로드는 하지않는다.

쇼핑몰¶

쇼핑몰은 사이트 접근이 고객의 매출과 직결된다. 이제 전통적인 PC환경 뿐만 아니라 모바일쇼핑이 당연해졌다. 쇼핑환경이 다양해 지는 것 뿐만 아니라 무한히 늘어나는 파일을 관리하지 못한다면 서비스는 곤경에 처한다.

• 무한대의 작은 파일 “억! 단위를 넘어서는~”, “셀 수 없이 많은~”, “언제나 늘어나기만 하는~” 파일을 저장하기 위해서는 고가의 Storage가 필요하다. 하지만 경제성이 중요한 Edge서버에서는 그럴 수 없다. 크기가 1KB인 파일이 10억 개 존재하는 서비스도 있을 수 있다. 결론적으로 모든 파일을 Caching할 수 없다. 원본서버의 부하를 최소화하면서도 접근 빈도가 높은 파일을 항상 유지하는 방법이 필요하다.

  STON 메모리와 Disk 자원의 최대용량만큼 Caching한다. 모든 파일의 접근 빈도는 실시간으로 관리되며 LRU(Least Recently Used) 에 의해 오래된 파일 순으로 삭제된다.

• 많은 사용자

  쇼핑몰은 많은 사용자를 동시에 처리할 수 있어야 한다. 급작스러운 이벤트에 의해 사용자 접속이 폭발적으로 증가(=Burst)하기도 한다. Burst 시 서버는 스스로를 보호해야 하며 Burst 후에도 안정성을 유지해야 한다.

  STON CPU 확장성(Scalability. 자원의 증설에 따라 솔루션의 성능이 높아지는 것)을 보장한다. 탄력적인 HTTP Keep-Alive 처리와 소켓관리를 통해 Burst시에도 안정성을 보장한다.

• 반응성

  쾌적한 쇼핑환경이란 페이지가 빠르게 로딩되는 것을 의미한다. 사용자는 기다리지 않는다. 3초 안에 로딩되지 않으면 다른 사이트로 떠난다. 일반적으로 메인 페이지는 100개 내외의 파일로 이루어지며 물리적 환경을 고려하더라도 통상 1초 대에 페이지는 완벽하게 로딩되어야 한다.

  STON 실시간 파일 인덱싱을 통한 즉시 응답을 보장한다. 부드러운 파일교체를 통해 원본 종속성 없이 반응성을 극대화할 수 있다. 모든 HTTP 응답(First byte 응답, 트랜잭션 완료)에 대해 로그와 통계수치를 제공하여 성능저하 여부를 실시간으로 검출할 수 있다.

• 페이지 TTL

  대다수의 사용자의 이동 경로는 메인 페이지 -> 대형 카테고리 페이지 -> 소형 카테고리 -> 상세 페이지 순이다. 페이지마다 노출 빈도가 다를 뿐만 아니라 갱신 주기도 달라야 한다. 스마트한 페이지 Caching & 갱신 방법이 필요하다.

  STON URL마다 별도의 TTL을 부여할 수 있다. 또한 Purge, Expire, ExpireAfter, HardPurge 등 상황에 맞는 다양한 방식의 갱신 방법을 제공한다.

미디어¶

미디어 전용 프로토콜은 점차 설 자리를 잃어가고 있다. HTTP, MP4의 간단하지만 강력한 조합은 점차 세력을 넓혀가고 있다. 모바일의 가변적인 연결상태를 고려 한다면 HTTP 기반의 Streaming방식이 전송 표준이 될 것이다.

• 미디어 인식

  더 이상 파일을 Chunk로 인식해서는 안된다. 미디어 파일을 정확히 인식할 수 있어야만 대역폭 절감과 함께 다양한 부가기능을 연동할 수 있다. 서버가 파일 해석을 위해서 파일의 모든 부분을 필요로 한다면 사용자는 영상재생을 포기할 것이다.

  STON MP4, MP3, M4A, FLV 포맷을 지원한다. 다운로드와 동시에 HTTP Pseudo Streaming을 위해 필요한 영역을 우선적으로 Caching한다.

• 미디어 헤더 재배치

  헤더가 뒤에 있는 파일의 경우 HTTP Pseudo Streaming이 불가능하다. 이를 위해서는 전용 플레이어가 필요하지만 이는 사용자에게 짜증을 +10한다.

  STON MP4파일 인코딩 후 헤더가 뒤에 붙는다면 헤더를 앞으로 옮겨주는 작업을 추가적으로 수행해야 한다. STON은 자연스럽게 헤더를 앞으로 옮겨 서비스 한다.

• 대역폭 조절

  대부분의 영상을 끝까지 보는 사용자는 드물다. 그러므로 재생에 무리가 없도록 필요한 만큼만 대역폭을 사용하는 것이 효율적인 전송방법이다. 같은 영상이더라도 360p, 480p, 720p, 1080p처럼 Bitrate를 다양하게 서비스 한다.

  STON Bandwidth-Throttling을 통하여 미디어 파일의 전송 대역폭을 최적화할 수 있다.

• 구간추출

  미리보기/하이라이트/공유하기 등 파일 전체가 아닌 특정 구간만을 서비스하는 경우도 많다. 서비스하는 모든 파일에 대해 구간을 추출하는 것은 시간과 저장공간을 지나치게 낭비한다. 심지어 사용자마다 추출 구간이 다른 경우도 있다. 또한 Skip기능을 구간 재생으로 구현하는 플레이어도 존재한다.

  STON Trimming기능을 통해 구간을 추출하여 완전한 형태의 미디어 파일로 서비스한다.

뉴스 / 커뮤니티¶

아주 높은 충성도의 사용자층을 확보한 사이트는 흥미로운 점이 많다. 같은 관심사를 가지는 사용자들이 모이기 때문에 교류가 활발하며 페이지에 머무르는 시간도 매우 길다. 서비스 패턴이 제각각이라 서비스하기 꽤 까다롭다.

• 304 Not Modified

  사이트 충성도가 매우 높기 때문에 이미 대부분의 파일을 사용자 로컬에 저장하고 있다. 때문에 실제로 전송되는 파일보다 “변경확인” 비율이 압도적이다.

  STON 자주 접근되는 파일은 항상 메모리에 상주하도록 보장한다. “변경확인” 작업은 기다림 없이 즉시 처리된다.

• Bypass

  사용자에 특화된 페이지나 새로운 글, 리플 등 페이지는 항상 Caching할 수 없는 영역을 포함한다. 하지만 Domain을 별도로 나누지 않고 단일 도메인을 Reverse-Proxy에 위임하는 경우가 많다.

  STON 다양한 조건을 기반으로 바이패스 대상을 정교하게 분류한다. 또한 Origin Affinity, Private 기능을 이용해 로그인 세션을 유지할 수 있다.

• 불안한 원본

  중, 소형 기업 또는 개인이 운영하는 사이트들은 고가의 장비나 인프라, 인력을 운영하기 어렵다. 원본서버 장애 빈도가 상대적으로 높으며 이를 극복하기 위한 경제성은 매우 나쁘다.

  STON 원본서버 과부하 또는 장애를 판단하여 자동으로 배제/복구가 이루어진다. 원본서버 장애 시 TTL을 자동으로 연장시켜 원본서버 의존성을 최소화한다.

• 이미지 가공

  같은 이미지를 사용자 환경에 따라 다양하게 보여줄 필요가 있다. 검색 결과에서는 Thumbnail 이미지를, 뉴스 사이트에서는 “XX 뉴스” 같은 글씨를 워터마크로 표시해야한다. 같은 이미지를 보여지는 형태에 따라 매번 가공하는 것은 저장공간과 시간, 인력의 낭비다.

  STON dims 기능을 사용하면 원본서버에 단 하나의 이미지 만으로 원하시는 형태를 URL 호출만으로 생성할 수 있다.

파일기반 서버¶

Edge는 Reverse-Proxy구조에 기반한다. Reverse-Proxy의 핵심 개념은 원격서버에 있는 파일을 로컬에 복제/갱신/관리하는 것이다. 이미 검증된 STON을 서비스 서버와 연동할 수 있다면 Storage중앙 집중화 및 동기화 이슈를 제거할 수 있다. 뿐만 아니라 개발시간 단축과 서비스 신뢰도 향상의 두마리 토끼를 모두 잡을 수 있다.

• File I/O 지원

  전용 프로토콜이 필요하다면 해당 모듈에 종속적인 서버가 되어 버린다. 힘들게 연동했다 하더라도 성능이 떨어지면 무용지물이다. 모듈과 서버 사이의 중간 단계는 최소화되어야 한다.

  STON 표준 File I/O로 STON이 연동된다. 전용서버와 STON사이에는 Linux Kernel(VFS)만이 존재하여 고성능을 보장한다.

• Web Server 연동

  표준 Web 서버(Apache, Lighttpd, NginX)에 특화된 확장모듈이 설치된 경우 표준 Reverse-Proxy를 도입하기 힘들 수 있다. DB/WAS와 연동되는 파일 서비스 또는 과금/결제 서비스 같은 경우 쉽게 서비스를 확장하기 어렵다.

  STON Apache의 DocumentRoot를 STON으로 지정하면 Apache는 STON을 물리적 디스크로 인식한다. 더 설정할 것은 없다.

• Wowza 연동

  미디어서비스에서는 Wowza가 사실상의 표준이다. 하지만 Wowza의 HTTP Caching기능은 사용하기 번거로울 뿐만 아니라 빈약하다. 또한 점차 HTTP 이외의 “전용” 프로토콜은 사라지는 추세이다.

  STON 로컬 디스크로 Mount할 수 있을 뿐만 아니라 MP4헤더 변환, Trimming등 모든 기능을 사용할 수 있다.

• 리소스 제약

  Back-end에 존재하는 파일을 Front-End의 사용자에게 전달하는 서버라면 항상 파일 동기화가 문제된다. 게임서버, SNS서버 등 전용서버의 개발 이슈는 항상 존재한다. 이런 서버의 경우 중단 없이 장기간 운영 되야 하므로 메모리, 디스크 사용이 엄격하게 제한되어야 한다.

  STON 최대 메모리, 디스크 사용량을 제한할 수 있다. 또한 디스크로 Mount하여도 다른 모든 기능은 동일하게 동작하여 복합적인 서비스를 최소한의 솔루션으로 구성할 수 있다.

STON은 이러한 특성들을 적극 활용하는 다음 서비스들과 함께 성장하고 있다.

서버 구성¶

일반적으로 서버를 구성할 때는 CPU, 메모리, 디스크를 주로 고려한다. 10Gbps급의 높은 성능를 요구하는 서비스라면 각 구성요소가 서비스 특성을 만족해야 원하는 성능을 얻을 수 있다.

• CPU

  Quad 코어 이상을 권장한다. STON은 Many-Core에 대해 확장성(Scalability)를 가진다. 코어가 많으면 많을수록 초당 처리량은 증가한다. 단, 높은 처리량이 반드시 높은 트래픽을 의미하는 것은 아니다.

  

  클라이언트가 많을수록 많은 CPU는 힘이 된다.

  4KB인 파일을 약 26만번을 전송하는 것과 1GB파일을 한번 전송하는 것은 같은 대역폭을 사용한다. CPU선택의 가장 큰 기준은 얼마나 많은 동시접속을 처리하는가이다.

• 메모리

  Memory-Indexing 방식을 사용하므로 4GB이상을 권장한다. ( 메모리 구조 참조) 자주 접근되는 콘텐츠는 항상 메모리에 상주하지만 그렇지 않은 컨텐츠는 디스크에서 로딩한다. 따라서 컨텐츠가 많고 집중도가 낮다면(Long-tail) 디스크 부하 증가로 성능이 저하될 수 있다. 서비스되는 콘텐츠 개수와 상관없이 콘텐츠 크기가 커서 디스크 I/O 부하가 높다면 메모리를 증설하여 부하를 낮출 수 있다.

• 디스크

  OS를 포함하여 최소 3개 이상을 권장한다. 디스크 역시 많으면 많을수록 많은 콘텐츠를 캐싱할 수 있을뿐만 아니라 I/O부하도 분산된다.

  

  항상 OS와 STON은 콘텐츠와 별도의 디스크로 구성한다.

  일반적으로 OS가 설치된 디스크에 STON을 설치한다. 로그 역시 같은 디스크에 구성하는 것이 일반적이다. 로그는 서비스 상황을 실시간으로 기록하기 때문에 항상 Write부하가 발생한다.

  STON은 디스크를 RAID 0처럼 사용한다. 성능와 RAID의 상관여부는 고객 서비스 특성에 따라 달라진다. 하지만 파일 변경이 빈번하지 않고 콘텐츠의 크기가 물리적 메모리 크기보다 훨씬 큰 경우 RAID를 통한 Read속도 향상이 효과적일 수 있다.

OS 구성¶

가장 기본적인 형태로 설치한다. 표준 64bit Linux 배포판(Cent 6.2이상, Ubuntu 10.04이상) 이라면 정상동작한다. 패키지 의존성을 가지지 않는다.

설치¶

1. 최신버전의 STON을 다운로드 받는다.

   [root@localhost ~]# wget  http://foobar.com/ston/ston.2.0.0.rhel.2.6.32.x64.tar.gz
   --2014-06-17 13:29:14--  http://foobar.com/ston/ston.2.0.0.rhel.2.6.32.x64.tar.gz
   Resolving foobar.com... 192.168.0.14
   Connecting to foobar.com|192.168.0.14|:80... connected.
   HTTP request sent, awaiting response... 200 OK
   Length: 71340645 (68M) [application/x-gzip]
   Saving to: “ston.2.0.0.rhel.2.6.32.x64.tar.gz”
   
   100%[===============================================>] 71,340,645  42.9M/s   in 1.6s
   
   2014-06-17 13:29:15 (42.9 MB/s) - “ston.2.0.0.rhel.2.6.32.x64.tar.gz” saved [71340645/71340645]
   

2. 압축을 해지한다.

   [root@localhost ~]# tar -zxf ston.2.0.0.rhel.2.6.32.x64.tar.gz
   

3. 설치 스크립트를 실행한다.

   [root@localhost ~]# ./ston.2.0.0.rhel.2.6.32.x64.sh
   

4. 설치과정은 install.log에 기록된다. 로그를 통해 설치 중 발생하는 문제를 알 수 있다.

   #DownloadURL: http://foobar.com/ston/ston.2.0.0.rhel.2.6.32.x64.tar.gz
   #DownloadTime: 13 sec
   #Target: STON 2.0.0
   #Date: 2014.03.03 16:48:35
   Prepare for STON 2.0.0 install process
       Stopping STON...
           STON stopped
   [Copying files]
       `./fuse.conf' -> `/etc/fuse.conf'
       `./libfuse.so.2' -> `/usr/local/ston/libfuse.so.2'
       `./libtbbmalloc_proxy.so' -> `/usr/local/ston/libtbbmalloc_proxy.so'
       `./start-stop-daemon' -> `/usr/sbin/start-stop-daemon'
       `./libtbbmalloc_proxy.so.2' -> `/usr/local/ston/libtbbmalloc_proxy.so.2'
       `./libtbbmalloc.so' -> `/usr/local/ston/libtbbmalloc.so'
       `./libtbbmalloc.so.2' -> `/usr/local/ston/libtbbmalloc.so.2'
       `./libtbb.so' -> `/usr/local/ston/libtbb.so'
       `./libtbb.so.2' -> `/usr/local/ston/libtbb.so.2'
       `./stond' -> `/usr/local/ston/stond'
       `./stonx' -> `/usr/local/ston/stonx'
       `./stonr' -> `/usr/local/ston/stonr'
       `./stonu' -> `/usr/local/ston/stonu'
       `./stonapi' -> `/usr/local/ston/stonapi'
       `./server.xml.default' -> `/usr/local/ston/server.xml.default'
       `./vhosts.xml.default' -> `/usr/local/ston/vhosts.xml.default'
       `./ston_format.sh' -> `/usr/local/ston/ston_format.sh'
       `./ston_diskinfo.sh' -> `/usr/local/ston/ston_diskinfo.sh'
       `./wm.sh' -> `/usr/local/ston/wm.sh'
   [Exporting config files]
       #Export so directory
       /usr/local/ston/ to ld.so.conf
       #Export sysctl to /etc/sysctl.conf
       vm.swappiness=0
       vm.min_free_kbytes=524288
       #Export sudoers for WM
       Defaults    !requiretty
       winesoft ALL=NOPASSWD: /etc/init.d/ston stop, /etc/init.d/ston start, /bin/ps -ef
   [Configuring STON daemon script]
       STON deamon activate in run-level 2345.
   [Installing sub-packages]
       curl installed.
       libjpeg installed.
       libgomp installed.
       rrdtool installed.
   [Installing WM]
       Stopping WM...
       WM stopped
       `./wm.server_default.xml' -> `/usr/local/ston/wm/tmp/conf/server_default.xml'
       `./wm.vhost_default.xml' -> `/usr/local/ston/wm/tmp/conf/vhost_default.xml'
       WM configuration found. Current WM port : 8500
       PHP module for Legacy(CentOS 5.5) installed
       `./libphp5.so.5.5' -> `/usr/local/ston/wm/modules/libphp5.so'
       WM installation almost complete. Changing WM privileges.
   Installation successfully complete
   

라이선스 발급¶

신규 고객의 경우 다음 절차를 통해 라이선스를 발급한다.

• 신청양식 작성
• license@winesoft.co.kr 로 전송
• 확인절차 후 발급

라이선스 파일(license.xml)이 반드시 설치경로에 존재해야 STON이 정상적으로 구동된다.

업데이트¶

최신버전이 배포되면 stonu명령어로 업데이트할 수 있다.

./stonu 2.0.1

또는 13장. WM (Web Management) 의 최신버전 업데이트 를 통해 간편하게 업데이트를 진행할 수 있다.

실행하기¶

보통 기본경로에 STON을 설치한다.

/usr/local/ston/

다음 파일 중 하나라도 존재하지 않거나 XML문법에 맞지 않을 경우 실행되지 않는다.

• license.xml
• server.xml
• vhosts.xml

최초 설치시 모든 XML파일이 존재하지 않는다. 배포받은 라이센스파일을 설치 경로에 복사한다. 그리고 설치경로의 server.xml.default와 vhosts.xml.default를 복사 또는 수정하여 설정하길 바란다. *.default파일은 항상 최신패키지와 함께 배포된다.

Hello World¶

vhosts.xml 파일을 열어 다음과 같이 편집한다.

<Vhosts>
    <Vhost Name="www.example.com">
        <Origin>
            <Address>hello.winesoft.co.kr</Address>
        </Origin>
    </Vhost>
</Vhosts>

192.168.0.100        www.example.com

원본서버¶

가상호스트는 원본서버를 대신해 콘텐츠를 서비스하는 것이 목적이다. 서비스 형태에 맞게 다양한 원본서버는 다양하게 접근이 가능하다.

<Vhosts>
    <Vhost Name="www.example.com">
        <Origin>
            <Address>1.1.1.1</Address>
            <Address>1.1.1.2</Address>
        </Origin>
    </Vhost>
</Vhosts>

• <Address> 가상호스트가 콘텐츠를 복제 할 원본서버 주소. 개수제한은 없다. 주소가 2개 이상일 경우 Active/Active방식(Round-Robin)으로 선택된다. 원본서버 주소 포트가 80인 경우 생략할 수 있다.

예를 들어 다른 포트(8080)로 서비스되는 경우 1.1.1.1:8080과 같이 포트번호를 명시해야 한다. 주소는 {IP|Domain}{Port}{Path}형식으로 8가지 형식이 가능하다.

원본요청 기본 Header 중 Host헤더를 별도로 설정하지 않는한 표의 Host헤더를 전송한다.

<Vhosts>
    <Vhost Name="www.example.com">
        <Origin>
            <Address>origin.com:8888/account/dir</Address>
        </Origin>
    </Vhost>
</Vhosts>

예를 들어 위와같이 설정하면 원본으로 다음과 같이 요청한다.

GET / HTTP/1.1
Host: origin.com:8888

<Vhosts>
    <Vhost Name="www.example.com">
        <Origin>
            <Address>1.1.1.1</Address>
            <Address>1.1.1.2</Address>
            <Address2>1.1.1.3</Address2>
            <Address2>1.1.1.4</Address2>
        </Origin>
    </Vhost>
</Vhosts>

API 호출¶

HTTP기반의 API를 제공한다. API 호출권한은 관리자 설정 의 영향을 받는다. 허가되지 않았다면 곧바로 연결을 종료한다.

STON버전을 확인한다.

http://127.0.0.1:10040/version

같은 API를 Linux Shell에서 명령어로 수행한다.

./stonapi version

하드웨어 정보조회¶

하드웨어 정보를 조회한다.

http://127.0.0.1:10040/monitoring/hwinfo

결과는 JSON형식으로 제공된다.

{
   "version": "1.1.9",
   "method": "hwinfo",
   "status": "OK",
   "result":
   {
      "OS" : "Linux version 3.3.0 ...(생략)...",
      "STON" : "1.1.9",
      "CPU" :
      {
         "ProcCount": "4",
         "Model": "Intel(R) Xeon(R) CPU           E5606  @ 2.13GHz",
         "MHz": "1200.000",
         "Cache": "8192 KB"
      },
      "Memory" : "8 GB",
      "NIC" :
      [
         {
            "Dev" : "eth1",
            "Model" : "Intel Corporation 82574L Gigabit Network Connection",
            "IP" : "192.168.0.13",
            "MAC" : "00:25:90:36:f4:cb"
         }
      ],
      "Disk" :
      [
         {
            "Dev" : "sda",
            "Model" : "HP DG0146FAMWL (scsi)",
            "Total" : "238787584",
            "Usage" : "40181760"
         },
         {
            "Dev" : "sdb",
            "Model" : "HITACHI HUC103014CSS600 (scsi)",
            "Total" : "144706478080",
            "Usage" : "2101075968"
         },
         {
            "Dev" : "sdc",
            "Model" : "HITACHI HUC103014CSS600 (scsi)",
            "Total" : "144706478080",
            "Usage" : "2012160000"
         }
      ]
   }
}

재시작/종료¶

명령어를 통해 STON을 재시작/종료할 수 있다. 의도하지 않은 결과를 피하기 위해 웹 페이지를 통한 확인작업이 반드시 필요하도록 개발되었다.

http://127.0.0.1:10040/command/restart
http://127.0.0.1:10040/command/restart?key=JUSTDOIT       // 즉시 실행
http://127.0.0.1:10040/command/terminate
http://127.0.0.1:10040/command/terminate?key=JUSTDOIT       // 즉시 실행

Caching 초기화¶

서비스를 중단하며 캐싱된 모든 컨텐츠를 삭제한다. 설정된 모든 디스크를 포맷하며 작업이 완료되면 다시 서비스를 재개한다.

http://127.0.0.1:10040/command/cacheclear
http://127.0.0.1:10040/command/cacheclear?key=JUSTDOIT       // 즉시 실행

콘솔에서는 다음 명령어를 통해 전체 또는 하나의 가상호스트를 초기화한다.

./stonapi reset
./stonapi reset/ston.winesoft.co.kr

설정 Reload¶

설정 변경 후 관리자가 명확하게 API를 호출해야 한다. 시스템과 성능 관련설정을 제외한 대부분의 설정은 서비스 중단없이 즉시 적용된다.

http://127.0.0.1:10040/conf/reload

설정이 변경될 때마다 Info 로그 에 변경사항이 기록된다.

server.xml 전역설정¶

실행파일과 같은 경로에 존재하는 server.xml이 전역설정 파일이다. XML형식의 텍스트파일이다.

# server.xml

<Server>
    <Host> ... </Host>
    <Cache> ... </Cache>
    <VHostDefault> ... </VHostDefault>
</Server>

우선 전역설정의 구조와 간단한 기능위주로 설명한다. 15장. 접근제어 나 11장. SNMP 등 전역설정에 위치하지만 덩치가 큰 기능들에 대해서는 각 주제를 다루는 장에서 설명한다.

# server.xml - <Server>

<Host>
    <Name>stream_07</Name>
    <Admin>admin@example.com</Admin>
    <Manager Port="10040" HttpMethod="ON" Role="Admin" UploadMultipartName="confile">
        <Allow>192.168.1.1</Allow>
        <Allow Role="Admin">192.168.2.1-255</Allow>
        <Allow Role="User">192.168.3.0/24</Allow>
        <Allow Role="Looker">192.168.4.0/255.255.255.0</Allow>
    </Manager>
</Host>

# server.xml - <Server>

<Cache>
    <Storage DiskFailSec="60" DiskFailCount="10" OnCrash="hang">
        <Disk>/user/cache1</Disk>
        <Disk>/user/cache2</Disk>
        <Disk Quota="100">/user/cache3</Disk>
    </Storage>
</Cache>

# server.xml - <Server>

<Cache>
    <SystemMemoryRatio>100</SystemMemoryRatio>
    <ContentMemoryRatio>50</ContentMemoryRatio>
</Cache>

# server.xml - <Server>

<Cache>
    <Cleanup>
        <Time>02:00</Time>
        <Age>0</Age>
    </Cleanup>
    <Listen>0.0.0.0</Listen>
    <ConfigHistory>30</ConfigHistory>
</Cache>

http://127.0.0.1:10040/command/cleanup
http://127.0.0.1:10040/command/cleanup?age=10

# server.xml - <Server>

<VHostDefault>
    <Options> ... </Options>
    <OriginOptions> ... </OriginOptions>
    <Media> ... </Media>
    <Stats> ... </Stats>
    <Log> ... </Log>
</VHostDefault>

vhosts.xml 가상호스트 설정¶

실행파일과 같은 경로에 존재하는 vhosts.xml파일을 가상호스트 설정파일로 인식한다. 가상호스트 개수에 제한은 없다.

# vhosts.xml

<Vhosts>
    <Vhost Status="Active" Name="www.example.com"> ... </Vhost>
    <Vhost Status="Active" Name="img.example.com"> ... </Vhost>
    <Vhost Status="Active" Name="vod.example.com"> ... </Vhost>
</Vhosts>

# vhosts.xml - <Vhosts>

<Vhost Status="Active" Name="www.example.com">
    <Origin>
        <Address>10.10.10.10</Address>
    </Origin>
</Vhost>

GET / HTTP/1.1
Host: www.example.com

# vhosts.xml - <Vhosts>

<Vhost Name="example.com">
    <Alias>another.com</Alias>
    <Alias>*.sub.example.com</Alias>
</Vhost>

# vhosts.xml

<Vhosts>
    <Vhost Status="Active" Name="www.example.com"> ... </Vhost>
    <Vhost Status="Active" Name="img.example.com"> ... </Vhost>
    <Default>www.example.com</Default>
</Vhosts>

# vhosts.xml - <Vhosts>

<Vhost Name="www.example.com">
    <Listen>*:80</Listen>
</Vhost>

가상호스트 목록확인¶

가상호스트 목록을 조회한다.

http://127.0.0.1:10040/monitoring/vhostslist

결과는 JSON형식으로 제공된다.

{
   "version": "1.1.9",
   "method": "vhostslist",
   "status": "OK",
   "result": [ "www.example.com","www.foobar.com", "site1.com" ]
}

설정 확인¶

서비스 중인 설정파일을 확인한다. txt파일들은 가상호스트(vhost)를 명확하게 지정해주어야 한다.

http://127.0.0.1:10040/conf/server.xml
http://127.0.0.1:10040/conf/vhosts.xml
http://127.0.0.1:10040/conf/querystring.txt?vhost=www.example.com
http://127.0.0.1:10040/conf/bypass.txt?vhost=www.example.com
http://127.0.0.1:10040/conf/ttl.txt?vhost=www.example.com
http://127.0.0.1:10040/conf/expires.txt?vhost=www.example.com
http://127.0.0.1:10040/conf/acl.txt?vhost=www.example.com
http://127.0.0.1:10040/conf/headers.txt?vhost=www.example.com
http://127.0.0.1:10040/conf/throttling.txt?vhost=www.example.com
http://127.0.0.1:10040/conf/postbody.txt?vhost=www.example.com

설정 목록¶

백업된 설정목록을 열람한다.

http://127.0.0.1:10040/conf/latest
http://127.0.0.1:10040/conf/history

결과는 JSON 형식으로 제공된다. 빠르게 마지막 설정상태만 확인하고 싶은 경우는 /conf/latest를 사용할 것을 권장한다.

{
    "history" :
    [
        {
            "id" : "5",
            "conf-date" : "2013-11-06",
            "conf-time" : "15:26:37",
            "type" : "loaded",
            "size" : "16368",
            "hash" : "D62CA26F16FE7C66F81D215D8C52266AB70AA5C8",
            "ver": "1.2.8"
        },
        {
            "id" : "6",
            "conf-date" : "2013-11-07",
            "conf-time" : "07:02:21",
            "type" : "modified",
            "size" : "27544",
            "hash" : "F81D215D8C52266AB70AA5C8D62CA26F16FE7C66",
            "ver": "1.2.8"
        }
    ]
}

• id 설정의 고유 아이디 (Reload할때마다 +1)
• conf-date 설정 변경날짜
• conf-time 설정 변경시간
• type 설정이 반영된 형태 - loaded STON이 시작될 때 - modified 설정이 (관리자 또는 WM에 의해) 변경될 때 - uploaded 설정파일 API를 통해 업로드 되었을 때 - restored 설정파일이 API를 통해 복구되었을 때
• size 설정파일 크기
• hash 설정파일을 SHA-1으로 hash한 값

설정 복구¶

hash값 또는 id를 기준으로 원하는 시점의 설정으로 되돌린다. hash와 id가 모두 명시된 경우 hash값이 우선한다. 정상적으로 Rollback된 경우 200 OK, 실패한 경우 500 Internal Error로 응답한다.

http://127.0.0.1:10040/conf/restore?hash=...
http://127.0.0.1:10040/conf/restore?id=...

설정 다운로드¶

hash값 또는 id를 기준으로 원하는 시점의 설정을 다운로드 한다. Content-Type은 “application/x-compressed”로 명시된다. hash와 id가 모두 명시된 경우 hash값이 우선하며, 해당 시점의 설정이 존재하지 않는 경우 404 NOT FOUND로 응답한다.

http://127.0.0.1:10040/conf/download?hash=...
http://127.0.0.1:10040/conf/download?id=...

설정 업로드¶

설정파일을 HTTP Post방식(Multipart 지원)으로 업로드 한다.

http://127.0.0.1:10040/conf/upload

다음과 같이 주소, Content-Length, Content-Type(=”multipart/form-data”)이 명확하게 선언되어 있어야 한다.

POST /conf/upload
Content-Length: 16455
Content-Type: multipart/form-data; boundary=......

업로드가 완료되면 압축을 해지한 뒤 즉시 반영시킨다.

Multipart방식에서는 “confile”을 기본 이름으로 사용한다. 이 값은 <Manager> 의 UploadMultipartName 속성에서 설정할 수 있다.

<form enctype="multipart/form-data" action="http://127.0.0.1:10040/conf/upload" method="POST">
    <input name="confile" type="file" />
    <input type="submit" value="Upload" />
</form>

TTL (Time To Live)¶

TTL이란 저장된 콘텐츠의 유효시간이다. TTL을 길게 설정하면 원본서버의 부하는 줄어들지만 변경사항이 늦게 반영된다. 반대로 짧게 설정하면 너무 잦은 변경확인 요청으로 원본서버 부하가 높아진다. 운영의 묘미는 TTL을 적절히 설정하여 원본부하를 줄이는 것에 있다. TTL은 한번 설정되면 만료되기 전까지 바뀌지 않는다. 새로운 TTL은 파일이 만료되었을 때 적용된다. 관리자는 Purge , Expire , ExpireAfter , HardPurge 등의 API를 사용해 TTL을 변경할 수 있다.

# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>

<TTL>
    <Res2xx Ratio="20" Max="86400">1800</Res2xx>
    <NoCache Ratio="0" Max="5" MaxAge="0">5</NoCache>
    <Res3xx>300</Res3xx>
    <Res4xx>30</Res4xx>
    <Res5xx>30</Res5xx>
    <ConnectTimeout>3</ConnectTimeout>
    <ReceiveTimeout>3</ReceiveTimeout>
    <OriginBusy>3</OriginBusy>
</TTL>

# /svc/www.example.com/ttl.txt
# 구분자는 콤마(,)이며 시간 단위는 초이다.

*.jsp, 10
/,5
/index.html, 5
/script/*.js, 300
/image/ad.jpg, 1800

# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>

<TTL Priority="cc_nocache, custom, cc_maxage, rescode">
    ... (생략) ...
</TTL>

# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>

<TTLExtensionBy4xx>OFF</TTLExtensionBy4xx>
<TTLExtensionBy5xx>ON</TTLExtensionBy5xx>

갱신정책¶

TTL이 만료된 콘텐츠의 경우 원본서버에서 갱신여부를 확인한 뒤 서비스가 이루어진다.

변경확인 후 응답

1. TTL이 유효하다. 즉시 응답한다.
2. TTL이 만료되어 원본서버로 변경확인(If-Modified-Since)을 요청한다. 변경확인이 될때까지 클라이언트에게 응답하지 않는다.
3. 원본서버에서 응답이 오면 TTL을 연장하거나 콘텐츠를 변경(Swap)한다. 원본서버에서 확인이 되었으므로 클라이언트에게 응답한다.
4. 변경확인이 된 콘텐츠이므로 다음 TTL 만료시까지 즉시 응답한다.

고화질 동영상이나 게임처럼 상대적으로 반응성보다 전송속도가 중요한 서비스에서는 이런 방식이 큰 문제가 되지 않는다. 대용량 데이터의 경우 원본서버가 10초만에 갱신에 대한 응답을 한다고 하더라도 전송에 몇 분씩 소요되기 때문에 상대적으로 원본의 반응성이 크게 중요하지 않다. 오히려 접근 빈도가 높지 않은 콘텐츠이기 때문에 반드시 갱신확인이 이루어져야 한다.

하지만 쇼핑몰과 같은 경우 상황은 다르다. 웹 페이지는 빠르게 로딩되는 것이 무엇보다 중요하다. 1~2초 안에 클라이언트 화면구성이 모두 끝나야 한다. 전송속도보다 반응속도가 더 중요하다는 말이다.

이때 TTL이 만료되어 원본서버에게 갱신확인을 해야 한다면 매우 큰 지연이 발생할 수 있다. 보통의 쇼핑몰이 수백만개의 콘텐츠를 동시에 서비스 하는 것을 감안할 때 항상 원본서버로부터 갱신확인 작업이 발생하고 있다고 생각해야 한다. 자칫 원본서버 장애가 발생하거나 네트워크 장애가 발생한다면 최악이다.

우리가 원하는 것은 어떠한 원본서버의 장애나 지연으로부터 캐싱된 콘텐츠가 안전하게 전송되는 것이다.

장애가 두렵지 않다!

이런 차이점 때문에 백그라운드 콘텐츠 갱신기능이 개발되었다.

# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>

<RefreshExpired>ON</RefreshExpired>

• <RefreshExpired>
  • ON (기본) 변경확인 후 응답한다.
  • OFF 변경확인 응답을 기다리지 않고 응답한다. 새로운 콘텐츠의 다운로드가 완료되면 그때 변경(Swap)한다.

OFF 설정의 더 큰 이유는 콘텐츠가 대부분 자주 바뀌지 않기 때문이다.

변경에 민감하지 않다면 기다리지 않는다.

위 그림에서 원본서버와의 갱신작업이 모두 백그라운드로 이루어지기 때문에 캐싱된 콘텐츠는 기다림없이 즉시 클라이언트에게 서비스된다. 원본서버가 304 Not Modified 로 응답한다면 TTL만 연장된다. 파일이 갱신되어 원본서버에서 200 OK를 응답한 경우 해당 파일이 완전히 다운로드된 후에 파일이 부드럽게 교체된다. 콘텐츠가 바뀌어도 이전 콘텐츠(초록색)를 다운로드 받던 사용자들은 정상적으로 다운로드가 진행된다. 파일 교체 이후 접근된 사용자들(겨자색)은 바뀐 파일로 서비스 된다. 콘텐츠 갱신, 네트워크 장애, 원본서버 장애 등 어떠한 변수에도 콘텐츠 갱신은 백그라운드로 진행되기 때문에 실제 서비스에는 전혀 지연이 없다.

GET /logo.jpg HTTP/1.1
...
cache-control: no-cache 또는 cache-control:max-age=0
pragma: no-cache
...

# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>

<NoCacheRequestExpire>OFF</NoCacheRequestExpire>

Accept-Encoding 헤더¶

같은 URL에 대한 HTTP요청이라도 Accept-Encoding헤더의 존재 유무에 따라 다른 콘텐츠가 캐싱될 수 있다. 원본서버에 요청을 보내는 시점에 압축여부를 알 수 없다. 응답을 받았다고해도 압축여부를 매번 비교할 수도 없다.

원본서버가 어떤 응답을 줄지 알 수 없다.

# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>

<AcceptEncoding>ON</AcceptEncoding>

• <AcceptEncoding>
  • ON (기본) HTTP 클라이언트가 보내는 Accept-Encoding 헤더를 인식한다.
  • OFF HTTP 클라이언트가 보내는 Accept-Encoding 헤더를 무시한다.

원본서버에서 압축을 지원하지 않거나, 압축이 필요없는 대용량 파일의 경우 OFF 로 설정하는 것이 바람직하다.

대소문자 구분¶

원본서버의 대소문자 구분여부를 능동적으로 알 수 없다.

아마도 같은 콘텐츠이거나 404가 발생한다.

# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>

<CaseSensitive>ON</CaseSensitive>

• <CaseSensitive>
  • ON (기본) URL 대소문자를 구문한다.
  • OFF URL 대소문자를 구분하지 않는다. 모두 소문자로 처리된다.

QueryString 구분¶

QueryString에 의하여 동적으로 생성되는 콘텐츠가 아니라면 QueryString을 인식하는 것은 불필요하다. 아무 의미없는 Random값이나 항상 변하는 시간 값이 매번 붙는다면 원본에 엄청난 부하가 발생할 수 있다.

동적 콘텐츠가 아니라면 같은 콘텐츠일 가능성이 높다.

# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>

<ApplyQueryString Collective="OFF">ON</ApplyQueryString>

• <ApplyQueryString>
  • ON (기본) QueryString을 인식한다. 예외조건에 만족하면 QueryString이 무시된다.
  • OFF QueryString을 무시한다. 예외조건에 만족하면 QueryString을 인식한다.

QueryString-예외조건은 /svc/{가상호스트 이름}/querystring.txt에 설정한다.

# ./svc/www.example.com/querystring.txt

/private/personal.jsp?login=ok*
/image/ad.jpg

예외조건이 <ApplyQueryString> 설정에 따라 의미가 달라짐에 주의한다. 명확한 URL또는 패턴(*만 허용한다)으로 설정이 가능하다.

Collective 속성은 5장. Caching 무효화 API가 호출되었을 때 대상을 지정한다.

• Collective
  • OFF (기본) 파라미터 URL만을 대상으로 지정한다.
  • ON 파라미터 URL뿐만 아니라 URL에 QueryString이 존재하는 모든 컨텐츠를 대상으로 지정한다.

Collective 속성이 ON이고 파일이 많을수록 5장. Caching 무효화 에 CPU부하가 높아진다. 관련 파일을 검색하는 소요시간이 길어질 수 있어 예기치 않은 문제를 일으킬 수 있다. 가급적 QueryString까지 붙은 명확한 URL로 5장. Caching 무효화 API를 호출할 것을 권장한다.

Vary 헤더¶

Vary헤더를 인식하여 콘텐츠를 구분한다. 일반적으로 Vary헤더는 Cache서버의 성능을 급격히 떨어트리는 원흉이다.

# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>

<VaryHeader />

• <VaryHeader>

  원본서버가 응답한 Vary헤더 중 지원할 헤더목록을 설정한다. 구분자는 콤마(,)를 사용한다.

예를 들어 원본서버가 다음과 같이 Vary헤더를 보냈다고 하더라도 <VaryHeader> 가 설정되어 있지 않다면 무시한다.

Vary: Accept-Encoding, Accept, User-Agent

User-Agent를 제외한 Accept-Encoding과 Accept헤더만을 인식하도록 하려면 다음과 같이 설정한다.

# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>

<VaryHeader>Accept-Encoding, Accept</VaryHeader>

원본서버가 보낸 모든 Vary헤더를 인식하게 하려면 다음과 같이 설정한다.

# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>

<VaryHeader>*</VaryHeader>

POST 요청 캐싱¶

POST 요청을 Caching하도록 설정한다. POST 요청의 특성상 URL은 같지만 Body데이터가 다를 수 있다.

# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>

<PostRequest MaxContentLength="102400" BodySensitive="ON">OFF</PostRequest>

• <PostRequest>
  • OFF (기본) POST요청이 오면 세션을 종료한다.
  • ON POST요청을 Caching한다.

실제로 POST요청을 처리하는 대부분의 경우는 Body데이터를 Caching-Key로 사용한다. BodySensitive 속성과 예외조건을 통해 정교한 설정이 가능하다.

• BodySensitive

  • ON (기본) Body데이터까지 Caching-Key로 인식한다. 최대 길이는 MaxContentLength (기본: 102400 Bytes) 속성으로 제한한다. 예외조건에 만족하면 Body데이터를 무시한다.
  • OFF Body데이터는 무시한다. 예외조건에 만족하면 Body데이터를 인식한다.

POST요청 예외조건은 /svc/{가상호스트 이름}/postbody.txt에 설정한다.

# /svc/www.example.com/postbody.txt

/bigsale/*.php?nocache=*
/goods/search.php

예외조건이 BodySensitive 설정에 따라 의미가 달라짐에 주의한다. 명확한 URL 또는 패턴(*만 허용한다.)으로 설정이 가능하다.

이 설정은 GET/POST 바이패스 와 정책적으로 혼란스러울 수 있다. <BypassPostRequest> (기본: ON) 에 의해 POST요청이 캐싱되지 않을 수 있다. 따라서 POST요청을 캐싱하기 위해서는 <BypassPostRequest> 를 OFF 또는 예외조건을 설정해야 한다. 정리하면 우선순위는 다음과 같다.

• 바이패스 조건( GET/POST 바이패스 )에 만족할 경우 원본서버로 바이패스 한다.
• Content-Length헤더가 없다면 연결을 종료한다.
• PostRequest 가 ON 으로 설정되어 있고 Content-Length가 MaxContentLength 속성 값을 넘지 않는다면 캐싱모듈에 의해 처리된다.
• 이상의 시나리오에서 처리되지 않은 요청은 종료한다.

Purge¶

타겟 컨텐츠를 무효화시켜 원본서버로부터 컨텐츠를 다시 다운로드 받도록 한다. Purge후 최초 접근 시점에 원본서버로부터 컨텐츠를 다시 캐싱한다. 만약 원본서버에 장애가 발생하여 컨텐츠를 가져올 수 없다면 무효화된 컨텐츠를 다시 복원시켜 서비스에 장애가 없도록 처리한다. 이렇게 복원된 컨텐츠는 해당 시점으로부터 ConnectTimeout설정만큼 뒤에 갱신한다.

http://127.0.0.1:10040/command/purge?url=...

타겟 컨텐츠는 URL, 패턴으로 지정할 수 있을 뿐만 아니라 “|”(Vertical Bar)를 구분자를 사용하여 복수의 도메인에 복수의 타겟을 지정할 수 있다. 만약 도메인 이름이 생략되었다면 최근 사용된 도메인을 사용한다.

http://127.0.0.1:10040/command/purge?url=http://www.site1.com/image.jpg
http://127.0.0.1:10040/command/purge?url=www.site1.com/image.jpg
http://127.0.0.1:10040/command/purge?url=www.site1.com/image/bmp/
http://127.0.0.1:10040/command/purge?url=www.site1.com/image/*.bmp
http://127.0.0.1:10040/command/purge?url=www.site1.com/image1.jpg|/css/style.css|/script.js
http://127.0.0.1:10040/command/purge?url=www.site1.com/image1.jpg|www.site2.com/page/*.html

결과는 JSON형식으로 제공된다. 타겟 컨텐츠 개수/용량 및 처리시간(단위: ms)이 명시된다. 이미 Purge 된 컨텐츠는 다시 Purge되지 않는다.

{
    "version": "2.0.0",
    "method": "purge",
    "status": "OK",
    "result": { "Count": 24, "Size": 3747491, "Time": 12 }
}

<Purge2Expire> 를 통해 특정조건의 Purge를 Expire로 동작하도록 설정할 수 있다. 결과없는 응답에 대해서는 <ResCodeNoCtrlTarget> 로 HTTP 응답코드를 설정할 수 있다.

Expire¶

타겟 컨텐츠의 TTL을 즉시 만료시킨다. Expire후 최초 접근 시점에 원본서버로부터 변경여부를 확인한다. 변경되지 않았다면 TTL연장만 있을 뿐 컨텐츠 다운로드는 발생하지 않는다.

http://127.0.0.1:10040/command/expire?url=...

그 외의 모든 동작은 Purge 와 동일하다.

ExpireAfter¶

타겟 컨텐츠의 TTL만료 시간을 현재(API호출시점)로부터 입력된 시간(초)만큼 뒤에 설정한다. ExpireAfter로 만료시간을 앞당겨 컨텐츠를 더 빨리 갱신하거나, 반대로 만료시간을 늘려 원본서버 부하를 줄일 수 있다.

http://127.0.0.1:10040/command/expireafter?sec=86400&url=...

함수 호출규격은 Purge / Expire 와 유사하지만 sec파라미터(단위: 초)를 통해 TTL만료 시간을 지정할 수 있다. sec가 생략된다면 기본 값은 1일(86400초)로 설정되며 0을 입력할 경우 실패한다. 결과는 Purge / Expire 와 동일하지만 원본서버 장애여부와 상관없이 동작한다. 결과없는 응답에 대해서는 <ResCodeNoCtrlTarget> 로 HTTP 응답코드를 설정할 수 있다.

HardPurge¶

Purge / Expire / ExpireAfter 이상의 API는 원본서버 장애상황에서도 컨텐츠가 사라지지 않고 정상적으로 동작한다. 하지만 HardPurge는 컨텐츠의 완전한 삭제를 의미한다. HardPurge는 가장 강력한 삭제방법이지만 삭제한 컨텐츠는 원본서버에 장애가 발생해도 되살릴 수 없다. 결과없는 응답에 대해서는 <ResCodeNoCtrlTarget> 로 HTTP 응답코드를 설정할 수 있다.

http://127.0.0.1:10040/command/hardpurge?url=...

Purge 기본동작¶

Purge API가 호출될 때 컨텐츠 복구 여부를 선택한다.

# server.xml - <Server><Cache>

<Purge>Normal</Purge>

• <Purge>
  • Normal (기본) Purge 로 동작한다. (원본장애 시 복구 함)
  • Hard HardPurge 로 동작한다. (원본장애 시 복구하지 않음)

HTTP Method¶

무효화 API를 확장 HTTP Method로 호출할 수 있다.

PURGE /sample.dat HTTP/1.1
host: ston.winesoft.co.kr

HTTP Method는 기본적으로 Manager포트와 서비스(80)포트에서 동작한다. 서비스포트로 요청되는 HTTP Method의 관리자 설정 에서 설정한다.

POST 규격¶

무효화 API를 다음과 같이 POST로 호출할 수 있다.

POST /command/purge HTTP/1.1
Content-Length: 37

url=http://ston.winesoft.co.kr/sample.dat

세션관리¶

HTTP 클라이언트가 서버(STON)에 접속하면 HTTP 세션이 생성된다. 클라이언트는 HTTP 세션을 통해 서버에 저장된 여러 콘텐츠를 서비스 받는다. 요청부터 응답까지를 하나의 HTTP 트랜잭션 이라고 부른다. HTTP 세션은 여러 HTTP 트랜잭션을 순차적으로 처리한다.

# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>

<ConnectionHeader>keep-alive</ConnectionHeader>
<ClientKeepAliveSec>10</ClientKeepAliveSec>
<KeepAliveHeader Max="0">ON</KeepAliveHeader>

• <ConnectionHeader> (기본: keep-alive) 클라이언트에게 보내는 HTTP응답의 Connection헤더( keep-alive 또는 close )를 설정한다.

• <ClientKeepAliveSec> (기본: 10초) 클라이언트 세션과 아무런 통신이 없는 상태로 설정된 시간이 경과하면 세션을 종료한다. 시간을 너무 길게 설정하면 통신을 하지 않는 세션이 지나치게 많아진다. 너무 많은 세션을 유지하는 것만으로도 시스템엔 부하가 된다.

• <KeepAliveHeader>

  • ON (기본) HTTP응답에 Keep-Alive헤더를 명시한다. Max (기본: 0) 를 0보다 크게 설정하면 Keep-Alive헤더의 값으로 Max 값이 명시된다. 이후 HTTP 트랜잭션이 발생할때마다 1씩 차감된다.

  • OFF HTTP응답에 Keep-Alive헤더를 생략한다.

클라이언트 Cache-Control¶

클라이언트 Cache-Control과 관련된 설정을 다룬다.

# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>

<AgeHeader>OFF</AgeHeader>

# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>

<RefreshExpiresHeader Base="Access">OFF</RefreshExpiresHeader>

# /svc/www.exmaple.com/expires.txt
# 구분자는 콤마(,)이며 {조건},{시간},{기준} 순서로 표기한다.

$URL[/test.jpg], 86400
/test.jpg, 86400
*, 86400, access
/test/1.gif, 60 sec
/test/*.dat, 30 min, modification
$MIME[application/shockwave], 1 years
$MIME[application/octet-stream], 7 weeks, modification
$MIME[image/gif], 3600, modification

# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>

<ETagHeader>ON</ETagHeader>

기본응답 헤더¶

# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>

<OriginalHeader>OFF</OriginalHeader>

# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>

<ViaHeader>ON</ViaHeader>

# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>

<ServerHeader>ON</ServerHeader>

클라이언트 요청/응답 헤더 변경¶

클라이언트 HTTP요청과 응답을 특정 조건에 따라 변경한다.

# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>

<ModifyHeader FirstOnly="OFF">OFF</ModifyHeader>

• <ModifyHeader>
  • OFF (기본) 변경하지 않는다.
  • ON 헤더 변경조건에 따라 헤더를 변경한다.

헤더 변경시점을 정확히 이해하자.

• HTTP 요청헤더 변경시점

  클라이언트 HTTP 요청을 최초로 인식하는 시점에 헤더를 변경한다. 헤더가 변경되었다면 변경된 상태로 Cache 모듈에서 처리된다. 단, Host헤더와 URI는 변경할 수 없다.

• HTTP 응답헤더 변경시점

  클라이언트 응답 직전에 헤더를 변경한다. 단, Content-Length는 변경할 수 없다.

헤더 변경조건은 /svc/{가상호스트 이름}/headers.txt에 설정한다. 헤더는 멀티로 설정이 가능하므로 조건과 일치한다면 모든 변경설정이 순차적으로 모두 적용된다.

최초 조건에만 변경을 원할 경우 FirstOnly 속성을 ON 으로 설정한다. 서로 다른 조건이 같은 헤더를 변경하는 경우 set 에 의해 Last-Win이 되거나 명시적으로 put append 할 수 있다.

# /svc/www.example.com/headers.txt
# 구분자는 콤마(,)이다.

# 요청변경
# {Match}, {$REQ}, {Action(set|put|append|unset)} 순서로 표기한다.
$IP[192.168.1.1], $REQ[SOAPAction], unset
$IP[192.168.2.1-255], $REQ[accept-encoding: gzip], set
$IP[192.168.3.0/24], $REQ[cache-control: no-cache], append
$IP[192.168.4.0/255.255.255.0], $REQ[x-custom-header], unset
$IP[AP], $REQ[X-Forwarded-For], unset
$HEADER[user-agent: *IE6*], $REQ[accept-encoding], unset
$HEADER[via], $REQ[via], unset
$URL[/source/*.zip], $REQ[accept-encoding: deflate], set

# 응답변경
# {Match}, {$RES}, {Action(set|put|append|unset)}, {condition} 순서로 표기한다.
# {condition}은 특정 응답코드에 한하여 헤더를 변경할 수 있지만 필수는 아니다.
$IP[192.168.1.1], $RES[via: STON for CDN], set
$IP[192.168.2.1-255], $RES[X-Cache], unset, 200
$IP[192.168.3.0/24], $RES[cache-control: no-cache, private], append, 3xx
$IP[192.168.4.0/255.255.255.0], $RES[x-custom-header], unset
$HEADER[user-agent: *IE6*], $RES[vary], unset
$HEADER[x-custom-header], $RES[cache-control: no-cache, private], append, 5xx
$URL[/source/*], $RES[cache-control: no-cache], set, 404
/secure/*.dat, $RES[x-custom], unset, 200
/*.mp4, $RES[Access-Control-Allow-Origin: example1.com], set
/*.mp4, $RES[Access-Control-Allow-Origin: example2.com], put

{Match}는 IP, GeoIP, Header, URL 4가지로 설정이 가능하다.

• IP $IP[...]로 표기하며 IP, IP Range, Bitmask, Subnet 네 가지 형식을 지원한다.
• GeoIP $IP[...]로 표기하며 반드시 GeoIP 가 설정되어 있어야 한다. 국가코드는 ISO 3166-1 alpha-2 와 ISO 3166-1 alpha-3 를 지원한다.
• Header $HEADER[Key : Value]로 표기한다. Value는 명확한 표현과 패턴을 지원한다. Value가 생략된 경우에는 Key에 해당하는 헤더의 존재유무를 조건으로 판단한다.
• URL $URL[...]로 표기하며 생략이 가능하다. 명확한 표현과 패턴을 인식한다.

{$REQ}와 {$RES}는 헤더변경 방법을 설정한다. set put append 의 경우 {Key: Value}로 설정하며, Value가 입력되지 않은 경우 빈 값(“”)이 입력된다. unset 의 경우 {Key}만 입력한다.

{Action}은 set , put , append , unset 4가지로 설정이 가능하다.

• set 요청/응답 헤더에 설정되어 있는 Key와 Value를 헤더에 추가한다. 이미 같은 Key가 존재한다면 이전 값을 덮어쓴다.
• put ( set 과 유사하나) 같은 Key가 존재하면, 덮어쓰지 않고 새로운 라인으로 붙여 넣는다.
• append ( set 과 유사하나) 같은 Key가 존재하면, 기존의 Value와 설정된 Value사이에 Comma(,)로 구분하여 값을 결합한다.
• unset 요청/응답 헤더에 설정되어 있는 Key에 해당하는 헤더를 삭제한다.

{Condition}은 200이나 304같은 구체적인 응답 코드외에 2xx, 3xx, 4xx, 5xx처럼 응답코드 계열조건으로 설정한다. {Match}와 일치하더라도 {Condition}과 일치하지 않는다면 변경이 반영되지 않는다. {Condition}이 생략된 경우 응답코드를 검사하지 않는다.

압축¶

원본을 대신하여 컨텐츠를 압축하여 전송한다. Accept-Encoding 헤더 에 따라 컨텐츠를 구분하도록 설정되어 있어야 한다.

Accept-Encoding: gzip, deflate

비압축 파일을 실시간으로 압축하여 전송한다.

# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>

<Compression Method="gzip" Level="6" SourceSize="2-2048">OFF</Compression>

• <Compression>
  • OFF (기본) 압축 기능을 사용하지 않는다.
  • ON 압축 기능을 사용한다. 다음 속성을 지원한다.
    • Method (기본: gzip) 압축 방식을 지정한다. gzip만 지원된다.
    • Level (기본: 6) 압축 단계를 지정한다. 이 값은 Method 에 따라 달라진다. gzip은 1~9까지 지정이 가능하다. 숫자가 작을수록 빠르지만 압축률이 나쁘고, 클수록 느리지만 압축률이 좋다.
    • SourceSize (기본: 2-2048, 단위: KB) 원본 크기를 범위로 지정한다. 너무 작은 파일은 압축률이 떨어진다. 반대로 너무 큰 파일은 과도하게 CPU를 점유할 수 있다.

압축된 컨텐츠는 원본과 다른 컨텐츠로 인식/캐싱되며, 동일한 요청에 대해 다시 압축되지 않는다. 압축 대상은 /svc/{vhost}/compression.txt 에 지정한다. 정의된 순서대로 적용된다.

# /svc/www.example.com/compression.txt
# 구분자는 콤마( , ) 이다.
# {URL 조건}, {Method}, {Level} 순서로 표기한다.

/sample.css, no       // 압축하지 않는다.
*.css                 // *.css 조건에 대해 기본 Method와 Level로 압축한다.
*.htm, gzip           // *.htm 조건에 대해 gzip으로 압축한다. (기본 Level)
*.xml, , 9            // *.xml 조건에 대해 Level 9로 압축한다.*. (기본 Method)
*.js, gzip, 5         // *.js 조건에 대해 gzip (Level=5)으로 압축한다.

압축은 CPU자원을 많이 소모하는 기능이다. 다음은 파일 크기별 GZIP(Level: 9) 성능 테스트 결과이다.

• OS CentOS 6.3 (Linux version 2.6.32-279.el6.x86_64 (mockbuild@c6b9.bsys.dev.centos.org) (gcc version 4.4.6 20120305(Red Hat 4.4.6-4) (GCC) ) #1 SMP Fri Jun 22 12:19:21 UTC 2012)
• CPU Intel(R) Xeon(R) CPU E5-2603 0 @ 1.80GHz (8 processors)
• RAM 8GB
• HDD SAS 275GB X 5EA

<Compression> 이 활성화되어 있다면 원본 서버로 비압축 컨텐츠만을 요청한다. 비압축 컨텐츠란 원본 서버에 Accept-Encoding헤더를 명시하지 않고 보냈을 때의 응답을 의미한다. 만약 원본 서버가 비압축 컨텐츠 요청에 대해 Content-Encoding 헤더를 명시했다면 이미 압축된 것으로 간주하여 다시 압축하지 않는다.

장애감지와 복구¶

Caching과정 중 원본서버에 장애가 발생하면 자동배제한다. 다시 안정화됐다고 판단하면 서비스에 투입한다.

# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>

<ConnectTimeout>3</ConnectTimeout>
<ReceiveTimeout>10</ReceiveTimeout>
<Exclusion>3</Exclusion>
<Recovery Cycle="10" Uri="/" ResCode="0" Log="ON">5</Recovery>

• <ConnectTimeout> (기본: 3초)

  n초 이내에 원본서버와 접속이 이루어지지 않는 경우 접속실패로 간주한다.

• <ReceiveTimeout> (기본: 10초)

  정상적인 HTTP요청에도 불구하고 원본서버가 HTTP응답을 n초 동안 보내지 않는 경우 전송실패로 간주한다.

• <Exclusion> (기본: 3회)

  원본서버에서 연속적으로 n번 장애상황( <ConnectTimeout> 또는 <ReceiveTimeout> )이 발생하면 해당 서버를 유효 원본서버 목록에서 배제한다. 배제 전 정상적인 통신이 이루어진다면 이 값은 다시 0으로 초기화된다.

• <Recovery> (기본: 5회)

  Cycle 마다 Uri 로 요청하여 원본서버가 ResCode 로 연속적으로 n회 응답하면 해당 서버를 복구한다. 이 값을 0으로 설정하면 복구하지 않는다.

  • Cycle (기본: 10초) 일정시간(초)마다 시도한다.
  • Uri (기본: /) 요청을 보낼 Uri
  • ResCode (기본: 0) 정상응답으로 처리할 응답코드. 0인 경우 응답코드와 상관없이 응답이 오면 성공으로 간주한다. 200으로 설정하면 응답코드가 반드시 200이어야 정상응답으로 처리한다. 콤마(,)를 사용하여 유효한 응답코드를 멀티로 설정한다. 200, 206, 404로 설정하면 응답코드가 이 중 하나인 경우 정상응답으로 처리한다.
  • Log (기본: ON) 복구를 위해 사용된 HTTP Transaction을 Origin 로그 에 기록한다.

Health-Checker¶

장애감지와 복구 는 Caching 과정 중 발생하는 장애에 대응한다. <Recovery> 는 응답코드를 받는 즉시 HTTP Transaction을 종료한다. 하지만 Health-Checker는 HTTP Transaction이 성공함을 확인한다.

# vhosts.xml - <Vhosts><Vhost>

<Origin>
   <Address> ... </Address>
   <HealthChecker ResCode="0" Timeout="10" Cycle="10"
                  Exclusion="3" Recovery="5" Log="ON">/</HealthChecker>
   <HealthChecker ResCode="200, 404" Timeout="3" Cycle="5"
                  Exclusion="5" Recovery="20" Log="ON">/alive.html</HealthChecker>
</Origin>

• <HealthChecker> (기본: /)

  Health-Checker를 구성한다. 멀티로 구성이 가능하다. 값으로 Uri를 지정하며, XML예외 문자의 경우 CDATA를 사용한다.

  • ResCode (기본: 0) 올바른 응답코드 (콤마로 멀티 구성가능)
  • Timeout (기본: 10초) 소켓연결부터 HTTP Transaction이 완료될 때까지 유효시간
  • Cycle (기본: 10초) 실행주기
  • Exclusion (기본: 3회) 연속 n회 실패 시 해당서버 배제
  • Recovery (기본: 5회) 연속 n회 성공 시 해당서버 재투입
  • Log (기본: ON) HTTP Transaction을 Origin 로그 에 기록한다.

Health-Checker는 멀티로 구성할 수 있으며 클라이언트 요청과 상관없이 독립적으로 수행된다. 장애감지와 복구 나 다른 Health-Checker와도 정보를 공유하지 않고 자신만의 기준으로 배제와 투입을 결정한다.

원본주소 사용정책¶

원본주소(IP)는 다음 요소들에 의해 어떻게 사용될지 결정된다.

• 원본서버 주소 형식(IP 또는 Domain)과 보조주소
• 장애감지와 복구
• Health-Checker

서비스를 운영하다보면 원본주소가 배제/복구되는 일은 빈번하다. STON은 IP테이블을 기반으로 원본주소를 사용하며 origin-status API를 통해 정보를 제공한다.

원본주소를 IP로 설정한 경우 매우 간단하다.

• 설정변경 이외에 IP목록을 변화시키는 요인은 없다.
• TTL에 의해 IP주소가 만료되지 않는다.
• 장애/복구 모두 설정(IP주소)에 기반하여 동작한다.

원본주소를 Domain으로 설정하면 Resolving해서 IP를 얻어야 한다. ( DNS 로그 에 기록된다.) IP 목록은 동적으로 변경될 수 있으며 모든 IP는 TTL(Time To Live)동안만 유효하다.

• Domain은 주기적으로(1~10초) Resolving한다.
• Resolving결과를 통해 사용할 IP테이블을 구성한다.
• 모든 IP는 TTL만큼만 유효하며 TTL이 만료되면 사용하지 않는다.
• 같은 IP가 다시 Resolving되면 TTL을 갱신한다.
• IP테이블은 비어서는 안된다. (TTL이 만료되었더라도) 마지막 IP들은 삭제되지 않는다.

원본주소를 Domain으로 설정하여도 장애/복구는 IP기반으로 동작한다. 여기서 미묘한 점이 있다. DNS 클라이언트(=STON)는 Domain의 모든 IP 목록을 정확히 알 수 없다. 하지만 사용할 수 없는 IP들만으로 Domain을 구성할 경우 장애상태가 지속될 수 없다.

Domain주소 장애/복구 정책은 다음과 같다.

• (Domain에 대해) 알고 있는 모든 IP주소가 배제(Inactive)되면 해당 Domain주소가 배제된다.
• 신규 IP가 Resolving되더라도 Domain이 배제되어 있다면 IP주소는 처음부터 배제된다.
• 모든 IP가 TTL 만료되더라도 배제된 Domain상태는 풀리지 않는다.
• 배제된 Domain에 속한 IP주소가 하나라도 복구되어야 해당 Domain은 다시 활성화된다.

다소 복잡한 내용이므로 origin-status API를 통해 서비스 동작상태에 대해 이해도를 높이는 것이 좋다.

원본상태 모니터링¶

API를 통해 가상호스트의 원본상태를 모니터링한다.

http://127.0.0.1:10040/monitoring/origin       // 모든 가상호스트
http://127.0.0.1:10040/monitoring/origin?vhost=www.example.com

결과는 JSON형식으로 제공된다.

{
    "origin" :
    [
        {
            "VirtualHost" : "example.com",
            "Address" :
            [
                { "1.1.1.1" : "Active" },
                { "1.1.1.2" : "Active" }
            ],
            "Address2" : [  ],
            "ActiveIP" :
            [
                { "1.1.1.1" : 0 },
                { "1.1.1.2" : 0 }
            ] ,
            "InactiveIP" : [ ]
        },
        {
            "VirtualHost" : "foobar.com",
            "Address" :
            [
                { "origin.foobar.com" : "Active" }
            ],
            "Address2" : [  ],
            "ActiveIP" :
            [
                { "5.5.5.5" : 21 },
                { "5.5.5.6" : 60 },
                { "5.5.5.7" : 37 }
            ],
            "InactiveIP" :
            [
                { "5.5.5.8" : 10 },
                { "5.5.5.9" : 184 }
            ]
        }
    ]
}

• VirtualHost 가상호스트 이름
• Address 원본서버 . 설정주소가 사용중이라면 Active , (장애발생으로) 사용하고 있지 않다면 Inactive 로 표시된다.
• Address2 보조 원본주소 . 설정주소를 사용중이라면 Active , 사용하고 있지 않다면 Inactive 로 표시된다.
• ActiveIP 사용 중인 IP목록과 TTL. 원본서버를 IP로 설정하면 Address 와 동일한 IP에 TTL은 0으로 표시된다. Domain으로 설정하면 Resolving결과에 따른다. 다양한 IP와 TTL을 사용한다.
• InactiveIP 사용하지 않는 IP목록과 TTL. 사용하지 않더라도 복구 중이거나 HealthChecker에 의해 관리될 수 있다. 해당 주소는 TTL 동안 복구되지 않으면 삭제된다.

원본상태 초기화¶

API를 통해 가상호스트의 원본서버 배제/복구를 초기화한다. 또한 현재 사용 중인 세션을 재사용하지 않고 새롭게 연결을 생성한다.

http://127.0.0.1:10040/command/resetorigin       // 모든 가상호스트
http://127.0.0.1:10040/command/resetorigin?vhost=www.example.com

과부하 판단¶

처음 요청되는 콘텐츠는 항상 원본서버에 요청해야 한다. 하지만 이미 Caching된 콘텐츠라면 좀 더 유연하게 대처할 수 있다. 원본서버가 과부하 상태라고 판단되면 갱신을 늦추어 원본부하를 높이지 않는다.

# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>

<BusySessionCount>100</BusySessionCount>

• <BusySessionCount> (기본: 100개) 원본서버와 HTTP트랜잭션을 진행 중인 세션 수가 일정개수를 넘으면 과부하 상태로 판단한다. 과부하 상태에서 만료된 컨텐츠를 갱신하기 위해 원본서버로 접속하지 않도록 TTL을 TTL (Time To Live) 중 <OriginBusy> 만큼 연장한다. 무조건 원본서버로 요청이 가도록 하려면 이 값을 아주 크게 설정하면 된다.

원본 선택¶

원본서버 주소가 멀티(2개 이상)로 구성되어 있을 때 원본서버 선택정책을 설정한다.

# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>

<BalanceMode>RoundRobin</BalanceMode>

• <BalanceMode> (기본: RoundRobin)
  • RoundRobin (기본) 모든 원본서버가 균등하게 요청을 받도록 Round-Robin으로 동작한다. 연결된 Idle세션은 해당 서버로 요청이 필요할 때만 사용한다.
  • Session 재사용할 수 있는 세션이 있다면 우선 사용한다. 신규 세션이 필요하면 Round-Robin으로 할당한다.
  • Hash 컨텐츠를 Consistent Hashing 알고리즘에 따라 원본서버로 분산하여 요청한다. 서버가 선택되면 이미 연결된 세션을 재사용하며 없다면 신규로 접속한다.

세션 재사용¶

원본서버가 Keep-Alive를 지원한다면 연결된 세션은 항상 재사용된다. 하지만 세션을 재사용하여 보낸 요청에 대해 원본서버가 일방적으로 연결을 종료할 수 있다. 때문에 연결을 복구하느라 사용자 반응성이 늦어질 가능성이 있다. 특히 오랫동안 재사용하지 않은 세션의 경우 이러한 가능성은 더욱 높다. 이를 방지하기 위하여 n초 동안 재사용되지 않은 세션에 대해서 자동으로 연결을 종료하도록 설정한다.

# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>

<ReuseTimeout>60</ReuseTimeout>

• <ReuseTimeout> (기본: 60초) 일정 시간동안 사용되지 않은 원본세션은 종료한다. 0으로 설정하면 원본서버 세션을 재사용하지 않는다.

Range요청¶

한번에 다운로드 받는 컨텐츠 크기를 설정한다. 동영상처럼 앞 부분만이 주로 소비되는 컨텐츠의 경우 다운로드 크기를 제한하면 불필요한 원본 트래픽를 줄일 수 있다.

# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>

<PartSize>0</PartSize>

• <PartSize> (기본: 0 MB) 0보다 크면 클라이언트가 요청한 지점부터 설정크기(MB) 만큼 Range요청으로 다운로드 한다.

<PartSize> 를 사용하는 또 다른 이유는 디스크 공간을 절약하기 위함이다. 기본설정으로 STON은 원본크기의 파일을 디스크에 생성한다. 하지만 <PartSize> 가 0이 아니라면 다운로드 되는만큼만 파일을 분할하여 저장한다.

예를 들어 1시간짜리 영상(600MB)을 1분(10MB)만 시청한 경우에 디스크 공간을 10MB만 사용한다. 공간을 절약하는 장점은 있지만 파일이 분할되어 저장되기 때문에 디스크 부하가 조금 높아진다.

전체 Range 초기화¶

일반적으로 원본서버로부터 처음 파일을 다운로드 할 때나 갱신확인 할 때는 다음과 같이 단순한 형태의 GET 요청을 보낸다.

GET /file.dat HTTP/1.1

하지만 원본서버가 일반적인 GET요청에 대하여 항상 파일을 변조하도록 설정되어 있다면 원본파일 그대로를 Caching할 수 없어서 문제가 될 수 있다.

가장 대표적인 예는 Apache 웹서버가 mod_h.264_streaming같은 외부모듈과 같이 구동되는 경우이다. Apache 웹서버는 GET요청에 대해서 항상 mod_h.264_streaming모듈을 통해서 응답한다. 클라이언트(이 경우에는 STON)는 원본파일 그대로가 아닌 모듈에 의해 변조된 파일을 서비스 받는다.

mod_h.264_streaming모듈은 항상 원본을 변조한다.

Range요청을 사용하면 모듈을 우회하여 원본을 다운로드할 수 있다.

# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>

<FullRangeInit>OFF</FullRangeInit>

• <FullRangeInit>

  • OFF (기본) 일반적인 HTTP요청을 보낸다.

  • ON 0부터 시작하는 Range요청을 보낸다. Apache의 경우 Range헤더가 명시되면 모듈을 우회한다.

    GET /file.dat HTTP/1.1
    Range: bytes=0-
    

    최초로 파일 Caching할 때는 컨텐츠의 Range를 알지 못하므로 Full-Range(=0부터 시작하는)를 요청한다. 원본서버가 Range요청에 대해 정상적으로 응답(206 OK)하는지 반드시 확인해야 한다.

콘텐츠를 갱신할 때는 다음과 같이 If-Modified-Since 헤더가 같이 명시된다. 원본서버가 올바르게 304 Not Modified 로 응답해야 한다.

GET /file.dat HTTP/1.1
Range: bytes=0-
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

클라이언트 요청 유지¶

원본에 요청할 때 클라이언트가 보낸 요청을 유지하도록 설정한다.

# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>

<WholeClientRequest>OFF</WholeClientRequest>

• <WholeClientRequest>
  • OFF (기본) Caching-Key를 원본에 요청할 URL로 사용한다.
  • ON 클라이언트가 요청한 URL로 원본에 요청한다.

Hit Ratio를 높이기 위해 다음 설정들을 통해 Caching-Key를 결정한다.

• 대소문자 구분
• QueryString 구분
• POST 요청 캐싱

이에 따라 원본서버로 요청하는 URL과 Caching-Key가 다음과 같이 결정된다.

<WholeClientRequest> 를 ON 으로 설정하면 다음과 같이 Caching-Key와 상관없이 클라이언트가 보낸 URL을 그대로 원본에 보낸다.

POST 요청을 캐싱하는 경우 원본서버로 요청할 때 클라이언트가 보낸 POST요청의 Body데이터가 수정없이 전송된다.

원본요청 기본 Header¶

# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>

<Host />

# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>

<UserAgent>STON</UserAgent>

# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>

<XFFClientIPOnly>OFF</XFFClientIPOnly>

# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>

<OriginalETag>OFF</OriginalETag>

원본요청 URL변경¶

캐싱을 목적으로 원본으로 보내는 HTTP요청의 URL을 변경한다.

# vhosts.xml - <Vhosts><Vhost><OriginOptions>

<URLRewrite>
   <Pattern>/download/(.*)</Pattern>
   <Replace>/#1</Replace>
</URLRewrite>
// Pattern : /download/1.3.4
// Replace : /1.3.4

<URLRewrite>
   <Pattern>/img/(.*\.(jpg|png).*)</Pattern>
   <Replace>/#1/STON/composite/watermark1</Replace>
</URLRewrite>
// Pattern : /img/image.jpg?date=20140326
// Replace : /image.jpg?date=20140326/STON/composite/watermark1

handling_http_requests_url_rewrite 와 같은 표현을 사용하지만 가상호스트마다 독립적으로 설정하기 때문에 가상호스트명을 입력하지 않는다.

원본요청 헤더변경¶

원본으로 HTTP요청을 보낼 때 조건에 따라 HTTP 헤더를 변경한다.

# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>

<ModifyHeader FirstOnly="OFF">OFF</ModifyHeader>

• <ModifyHeader>
  • OFF (기본) 변경하지 않는다.
  • ON 헤더 변경조건에 따라 헤더를 변경한다.

헤더 변경시점은 HTTP 요청패킷이 완성되어 원본서버로 전송하기 직전에 수행된다. 단, Range헤더는 변조할 수 없다.

이 기능은 클라이언트 요청/응답 헤더 변경 의 하위 기능이다. 헤더변경에는 $ORGREQ 키워드를 사용한다.

# /svc/www.example.com/headers.txt

$URL[/*.mp4], $ORGREQ[x-media-type: video/mp4], set
$IP[1.1.1.1], $ORGREQ[user-agent: media_probe], put
*, $ORGREQ[If-Modified-Since], unset
*, $ORGREQ[If-None-Match], unset

No-Cache 요청 바이패스¶

클라이언트가 no-cache요청을 보냈다면 바이패스한다.

GET / HTTP/1.1
cache-control: no-cache 또는 cache-control:max-age=0
pragma: no-cache

# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>

<BypassNoCacheRequest>OFF</BypassNoCacheRequest>

• <BypassNoCacheRequest>
  • OFF (기본) Cache모듈이 처리한다.
  • ON 원본서버로 바이패스한다.

GET/POST 바이패스¶

바이패스가 GET/POST요청의 기본동작이 되도록 설정할 수 있다. GET과 POST의 용도가 다른만큼 기본동작이 다름에 유의한다.

# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>

<BypassPostRequest>ON</BypassPostRequest>
<BypassGetRequest>OFF</BypassGetRequest>

• <BypassPostRequest>
  • ON (기본) POST요청을 원본서버로 바이패스한다.
  • OFF POST요청을 STON이 처리한다.
• <BypassGetRequest>
  • OFF (기본) GET요청을 STON이 처리한다.
  • ON GET요청을 원본서버로 바이패스한다.

가상호스트 ACL 과 동일한 조건을 모두 지원한다. 바이패스 예외조건은 /svc/{가상호스트 이름}/bypass.txt 에 설정한다.

# /svc/www.example.com/bypass.txt
$IP[192.168.2.1-255]
/index.html

cache나 bypass조건을 명확하게 명시하지 않은 경우 기본설정과 반대로 동작한다. 예를 들어 <BypassGetRequest> 이 ON 이라면 예외조건은 Caching목록이 된다. 헷갈릴 여지가 많다면 2번째 파라미터를 사용하여 보다 분명하게 조건을 설정할 수 있다.

# /svc/www.winesoft.co.kr/bypass.txt

$HEADER[cookie: *ILLEGAL*], cache               // 항상 Caching처리
!HEADER[referer:]                               // 기본 설정에 따라 다름
!HEADER[referer] & !HEADER[user-agent], bypass  // 항상 바이패스
$URL[/source/public.zip]                        // 기본 설정에 따라 다름

정리하면 우선순위는 다음과 같다.

1. No-Cache 바이패스
2. bypass.txt에 bypass라고 명시된 경우
3. bypass.txt의 기본 설정

원본서버 고정¶

로그인 상태처럼 원본서버와 클라이언트가 반드시 1:1로 통신해야 하는 경우가 있다. GET/POST 바이패스 의 속성으로 원본서버를 고정시킬 수 있다.

# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>

<BypassPostRequest OriginAffinity="ON">...</BypassPostRequest>
<BypassGetRequest OriginAffinity="ON">...</BypassGetRequest>

• OriginAffinity

  • ON (기본) 클라이언트 요청이 항상 같은 서버로 바이패스되는 것을 보장한다. 단, 같은 소켓임을 보장하지는 않는다.

    바이패스해야 하는 원본서버와 연결된 모든 소켓이 끊어지는 상황이 발생할 수도 있다. 하지만 이런 경우에도 해당 서버로 새로운 소켓연결을 요청한다.

    

    항상 같은서버로 바이패스된다.

    바이패스하던 원본서버가 장애로 배제되거나 DNS에서 빠질 경우 새로운 서버로 바이패스된다.

  • OFF 클라이언트의 요청이 어느 서버로 바이패스되는지 보장할 수 없다.

    

    원본 선택 에 의해 따른다.

원본세션 고정¶

클라이언트 소켓마다 원본서버와 1:1로 바이패스 세션을 사용한다.

클라이언트가 원본세션을 소유한다.

GET/POST 바이패스 의 속성으로 원본세션을 고정시킬 수 있다.

# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>

<BypassPostRequest Private="OFF">...</BypassPostRequest>
<BypassGetRequest Private="OFF">...</BypassGetRequest>

• Private
  • ON 클라이언트 세션이 원본서버 전용세션을 사용하도록 동작한다. 항상 같은 서버로 요청이 바이패스 된다. 클라이언트와 원본서버 중 어느 한쪽이 세션을 종료되는 순간 상대방 세션 또한 종료됩니다.
  • OFF (기본) 전용세션을 사용하지 않는다.

원본서버가 사용자의 로그인 정보를 세션에 기반하여 유지하는 경우처럼 클라이언트의 요청이 반드시 같은 소켓으로 처리되야 하는 경우 유용하다.

# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>

<BypassConnectTimeout>5</BypassConnectTimeout>
<BypassReceiveTimeout>300</BypassReceiveTimeout>

바이패스 헤더¶

원본요청 기본 Header 설정의 바이패스 적용여부를 설정한다.

# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>

<UserAgent Bypass="OFF">...</UserAgent>
<Host Bypass="ON"/>
<XFFClientIPOnly Bypass="ON">...</XFFClientIPOnly>

• Bypass 속성
  • ON 설정된 헤더를 명시한다.
  • OFF 클라이언트가 보낸 관련헤더를 명시한다.

Port 바이패스¶

특정 TCP포트의 모든 패킷을 원본서버로 바이패스한다. 가상호스트 전용설정이다.

# vhosts.xml - <Vhosts>

<Vhost Name="www.example">
   <PortBypass>443</PortBypass>
   <PortBypass Dest=”1935”>1935</PortBypass>
</Vhost>

• <PortBypass> 지정된 포트로 입력된 모든 패킷을 원본서버의 같은 포트로 바이패스한다. Dest 속성으로 원본서버 포트를 설정한다.

예를 들어 443포트를 바이패스 한다면 클라이언트는 원본서버와 직접 SSL통신을 하는 효과를 가진다. 바이패스되는 포트는 절대 중복설정할 수 없다.

서비스 구성¶

별도의 IP 또는 포트를 지정하지 않는 경우 기본으로 바인딩되는 서비스 주소는 “*:443” 이다. 전역설정(server.xml)에 설정한다.

# server.xml - <Server>

<Https>
   <Cert>/usr/ssl/cert.pem</Cert>
   <Key>/usr/ssl/certkey.pem</Key>
   <CA>/usr/ssl/CA.pem</CA>
</Https>

<Https Listen="1.1.1.1:443">
   <Cert>/usr/ssl_ip_port/cert.pem</Cert>
   <Key>/usr/ssl_ip_port/certkey.pem</Key>
   <CA>/usr/ssl_ip_port/CA.pem</CA>
</Https>

<Https Listen="*:886">
   <Cert>/usr/ssl_port/cert.pem</Cert>
   <Key>/usr/ssl_port/certkey.pem</Key>
   <CA>/usr/ssl_port/CA.pem</CA>
</Https>

• <Https> HTTPS를 구성한다.
  • <Cert> 서버 인증서
  • <Key> 서버 인증서의 개인키. 암호화된 형식은 지원하지 않는다.
  • <CA> CA(Certificate Authority) 체인 인증서

같은 Port를 서비스하더라도 보다 명확한 표현이 우선한다.

예를 들어 위 예제처럼 NIC가 여러 개인 경우 1.1.1.1:443으로 들어온 클라이언트는 명시적 표현인 2번째(1.1.1.1:443) 인증서로 서비스되며 1.1.1.4:443으로 들어온 클라이언트는 일반적 표현인 1번째(생략 또는 *:443) 인증서로 서비스된다. 인증서파일을 같은 이름으로 덮어쓰기 하여도 Reload할 때 반영된다.

SSL/TLS 가속¶

CPU(AES-NI)를 통해 SSL/TLS를 가속한다. AES-NI를 지원하는 CPU인 경우 SSL/TLS에서 AES알고리즘을 우선적으로 사용하도록 동작한다. AES-NI가 인식된 경우 다음과 같이 Info.log에 기록된다.

AES-NI : ON (SSL/TLS accelerated)

관리자가 AES-NI 사용여부를 선택할 수 있다.

# server.xml - <Server><Cache>

<AES-NI>ON</AES-NI>

• <AES-NI> (기본: ON) AES-NI 사용여부를 선택한다.

CipherSuite 선택¶

지원하는 CipherSuites는 다음과 같다.

<Https> 의 CipherSuite 속성을 사용하면 사용할 CipherSuite를 설정할 수 있다.

# server.xml - <Server>

<Https CipherSuite="ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP">
   <Cert>/usr/ssl/cert.pem</Cert>
   <Key>/usr/ssl/certkey.pem</Key>
   <CA>/usr/ssl/CA.pem</CA>
</Https>

• CipherSuite Apache mod_ssl의 SSL CipherSuite표현 을 따른다.

Forward Secrecy 를 보장하면 더 높은 보안성을 얻을 수 있다. (아래 링크 참조)

• SSL Labs: Deploying Forward Secrecy
• SSL/TLS & Perfect Forward Secrecy
• Configuring Apache, Nginx, and OpenSSL for Forward Secrecy

기본적으로 FS(Forward Secrecy)를 보장하는 CipherSuite를 우선적으로 선택한다.

# server.xml - <Server>

<Https FS="ON"> ...  </Https>

• FS
  • ON (기본) Forward Secrecy를 보장하는 CipherSuite를 우선적으로 선택한다.
  • OFF ClientHello에 명시된 순서대로 선택한다.

FS 속성은 CipherSuite 속성보다 우선한다.

CipherSuite 조회¶

CipherSuite 설정결과를 조회한다. CipherSuite표현식은 OpenSSL 1.0.0E 를 준수한다.

http://127.0.0.1:10040/monitoring/ssl?ciphersuite=...

결과는 JSON형식으로 제공된다.

{
    "version": "2.0.0",
    "method": "ssl",
    "status": "OK",
    "result":
    [
        {
            "Name" : "AES128-SHA",
            "Ver" : "SSLv3",
            "Kx" : "RSA",
            "Au" : "RSA",
            "Enc" : "AES(128)",
            "Mac" : "SHA1"
        },
        {
            "Name" : "AES256-SHA",
            "Ver" : "SSLv3",
            "Kx" : "RSA",
            "Au" : "RSA",
            "Enc" : "AES(256)",
            "Mac" : "SHA1"
        }
    ]
}

멀티 Domain 구성¶

한 대의 서버에서 여러 서비스를 동시에 운영할 경우 SSL설정이 문제가 될 수 있다. 대부분의 Web/Cache서버들은 HTTP 요청의 Host헤더를 보고 어떤 가상호스트에서 서비스할 것인지 결정한다.

일반적 HTTPS통신

일반적으로 SSL은 클라이언트(Browser)가 자신이 접속하려는 서버 도메인명(winesoft.co.kr)을 인증서를 통해 확인하는 것으로 신원확인을 한다. 만약 인증서로 신원확인이 되지 않는다면(잘못된 인증서 또는 유효기간 만료 등) 다음과 같이 사용자에게 신뢰여부를 묻는다(아예 차단하는 경우도 있다). 신뢰는 클라이언트가 하는 것이므로 정상적인 신원확인이 안되어도 계속 진행하길 원한다면 SSL통신이 이루어진다.

사용자에게 판단을 맡긴다.

서버에서 SSL을 사용하는 가상호스트가 하나라면 문제가 되지 않는다. 하지만 여러 개의 가상호스트를 동시에 운영하는 서버에서는 문제가 될 수 있다. 왜냐하면 서버가 클라이언트에게 인증서를 전달할 때(“일반적 HTTPS통신”의 “2. 인증서 전달”) 클라이언트가 어떤 Host에 접속하려는지 알 수 없기 때문이다.

이 문제를 극복하는 대표적인 방법은 다음과 같다.

Multi Certificate¶

인증서의에 여러 도메인을 넣거나 Wildcard(i.e. *.winesoft.co.kr)를 명시하여 하나의 인증서로 여러 도메인의 신원을 확인시킬 수 있는 방법이다.

하나의 인증서로 여러 Domain을 인증한다.

서비스 주체가 같다면 효과적인 방법이지만 무관하다면 같은 인증서를 공유하는 것은 현실적으로 어렵다. 이 방법은 인증서만 교체하면 되는 것이므로 STON에서 별도로 설정하실 것은 없다 [ DigiCert 참고].

https://winesoft.co.kr:543/

# server.xml - <Server>

<Https> ..A사 인증서.. </Https>
<Https Listen="*:543"> ..B사 인증서.. </Https>
<Https Listen="*:544"> ..C사 인증서.. </Https>

# server.xml - <Server>

<Https Listen="10.10.10.10"> ..A사 인증서.. </Https>
<Https Listen="10.10.10.11"> ..B사 인증서.. </Https>
<Https Listen="10.10.10.12"> ..C사 인증서.. </Https>

# server.xml - <Server>

<Https Listen="eth0"> ... </Https>
<Https Listen="eth1"> ... </Https>
<Https Listen="eth2"> ... </Https>

프로토콜 구성¶

<Https> 마다 프로토콜을 구성한다.

# server.xml - <Server>

<Https TLS1.2="ON" TLS1.1="ON" TLS1.0="ON" SSL3.0="ON"> ...  </Https>

• TLS1.2 (기본: ON) TLS1.2를 사용한다.
• TLS1.1 (기본: ON) TLS1.1을 사용한다.
• TLS1.0 (기본: ON) TLS1.0을 사용한다.
• SSL3.0 (기본: ON) SSL3.0을 사용한다.

HSTS¶

HSTS(HTTP Strict Transport Security) 는 클라이언트 요청/응답 헤더 변경 를 이용해 손쉽게 구현이 가능하다.

# /svc/www.example.com/headers.txt

*, $RES[Strict-Transport-Security: max-age=31536000; includeSubDomains], set

Qualys SSL Server Test 에서는 HSTS가 적용된 사이트에 대해서만 A+등급을 부여한다.

STON v2.2부터는 A+를 받을 수 있다.

수집범위¶

통계수집 범위를 설정한다.

# server.xml - <Server><VHostDefault>
# vhosts.xml - <Vhosts><Vhost>

<Stats>
   <DirDepth>0</DirDepth>
   <DirDepthAccum>OFF</DirDepthAccum>
   <HttpsTraffic>OFF</HttpsTraffic>
   <ClientLocal>OFF</ClientLocal>
   <OriginLocal>OFF</OriginLocal>
</Stats>

• <DirDepth> (기본: 0)

  디렉토리별로 통계를 수집한다. 0으로 설정된 경우 모든 통계를 루트(/) 디렉토리로 수집한다. 1로 설정하면 통계는 첫 번째 Depth 디렉토리별로 수집된다.

• <DirDepthAccum>

  디렉토리별로 통계수집할 때 상위 디렉토리 통계 합산여부를 설정한다. <DirDepth> 이 0이라면 이 설정은 무시된다.

  • OFF (기본) 상위 디렉토리로 통계를 합산하지 않는다.
  • ON 상위 디렉토리로 통계를 합산한다.

  예를 들어, <DirDepth> 이 2이고 모든 디렉토리에 동일하게 10만큼의 트래픽이 발생하고 있다고 가정한다. <DirDepthAccum> 이 OFF 라면 좌측 그림처럼 트래픽이 발생하는 디렉토리별로 따로 통계가 수집된다. ON 이라면 우측 그림처럼 하위 디렉토리의 모든 통계가 부모 디렉토리로 누적된다.

  

  상위 디렉토리 누적통계

  예를 들어 /img 디렉토리는 하위 디렉토리의 트래픽과 자신의 트래픽을 더한 30을 통계 값으로 가지며 이 트래픽은 부모 디렉토리로 합산된다.

• <HttpsTraffic>

  • OFF (기본) HTTPS트래픽을 SSL통계로만 수집한다.
  • ON HTTPS트래픽을 SSL과 HTTP양쪽 통계에 같이 수집한다.

  기본적으로 SSL레이어를 통과하면 별도의 SSL 통계로 수집한다. HTTPS의 경우 상위 프로토콜에서 HTTP로 처리되기 때문에 보다 세세한 통계수집이 가능하다. 하지만 SSL통계와 HTTP통계 양쪽에 중복 통계수집이 되므로 HTTP통계만을 신뢰할 것을 권장한다.

• <ClientLocal>

  Loopback 클라이언트와 STON구간의 트래픽을 통계로 집계한다.

  • OFF (기본) 집계하지 않는다.
  • ON 집계한다.

• <OriginLocal>

  STON구간과 Loopback 원본서버 구간의 트래픽을 통계로 집계한다.

  • OFF (기본) 집계하지 않는다.
  • ON 집계한다.

호스트 종합통계¶

호스트 통계는 가장 상위 개념의 통계로 서비스하는 모든 가상호스트의 통계를 종합한다. 같은 통계를 JSON과 XML형식으로 제공한다.

{                                            <Host
  "Host":                                      Version="2.0.0"
  {                                            Name="localhost"
    "Version":"2.0.0",                         State="Healthy"
    "Name":"localhost",                        Uptime="155986"
    "State":"Healthy",                         OriginSession="32"
    "Uptime":155996,                           OriginActiveSession="20"
    "OriginSession":33,                        OriginInbound="1140741"
    "OriginActiveSession":20,                  OriginOutbound="10059"
    "OriginInbound":688177,                    OriginReqCount="42"
    "OriginOutbound":14184,                    OriginResTotalCount="42"
    "OriginReqCount":62,                       OriginResTotalTimeRes="5071"
    "OriginResTotalCount":62,                  OriginResTotalTimeComplete="10288"
    "OriginResTotalTimeRes":2375,              OriginRes2xxCount="19"
    "OriginResTotalTimeComplete":2509,         OriginRes2xxTimeRes="9989"
    "OriginRes2xxCount":54,                    OriginRes2xxTimeComplete="21521"
    "OriginRes2xxTimeRes":2327,                OriginRes3xxCount="23"
    "OriginRes2xxTimeComplete":2481,           OriginRes3xxTimeRes="1008"
    "OriginRes3xxCount":8,                     OriginRes3xxTimeComplete="1008"
    "OriginRes3xxTimeRes":2700,                OriginRes4xxCount="0"
    "OriginRes3xxTimeComplete":2700,           OriginRes4xxTimeRes="0"
    "OriginRes4xxCount":0,                     OriginRes4xxTimeComplete="0"
    "OriginRes4xxTimeRes":0,                   OriginRes5xxCount="0"
    "OriginRes4xxTimeComplete":0,              OriginRes5xxTimeRes="0"
    "OriginRes5xxCount":0,                     OriginRes5xxTimeComplete="0"
    "OriginRes5xxTimeRes":0,                   ClientSession="165"
    "OriginRes5xxTimeComplete":0,              ClientActiveSession="80"
    "ClientSession":155,                       ClientInbound="14792"
    "ClientActiveSession":80                   ClientOutbound="1981700"
    "ClientInbound":35748,                     ClientReqCount="64"
    "ClientOutbound":972906,                   ClientResTotalCount="64"
    "ClientReqCount":152,                      ClientResTotalTimeRes="5535"
    "ClientResTotalCount":152,                 ClientResTotalTimeComplete="6840"
    "ClientResTotalTimeRes":1411,              ClientRes2xxCount="44"
    "ClientResTotalTimeComplete":1479,         ClientRes2xxTimeRes="8050"
    "ClientRes2xxCount":93,                    ClientRes2xxTimeComplete="9943"
    "ClientRes2xxTimeRes":2305,                ClientRes3xxCount="20"
    "ClientRes2xxTimeComplete":2409,           ClientRes3xxTimeRes="5"
    "ClientRes3xxCount":59,                    ClientRes3xxTimeComplete="15"
    "ClientRes3xxTimeRes":3,                   ClientRes4xxCount="0"
    "ClientRes3xxTimeComplete":13,             ClientRes4xxTimeRes="0"
    "ClientRes4xxCount":0,                     ClientRes4xxTimeComplete="0"
    "ClientRes4xxTimeRes":0,                   ClientRes5xxCount="0"
    "ClientRes4xxTimeComplete":0,              ClientRes5xxTimeRes="0"
    "ClientRes5xxCount":0,                     ClientRes5xxTimeComplete="0"
    "ClientRes5xxTimeRes":0,                   RequestHitRatio="6923"
    "ClientRes5xxTimeComplete":0,              ByteHitRatio="4243">
    "RequestHitRatio":6387,                    <HttpCountSum
    "ByteHitRatio":2926,                         OriginReqCount="0"
    "HttpCountSum" :                             OriginResTotalCount="0"
    {                                            OriginRes2xxCount="0"
      "OriginReqCount" : 0,                      OriginRes3xxCount="0"
      "OriginResTotalCount" : 0,                 OriginRes4xxCount="0"
      "OriginRes2xxCount" : 0,                   OriginRes5xxCount="0"
      "OriginRes3xxCount" : 0,                   ClientReqCount="0"
      "OriginRes4xxCount" : 0,                   ClientResTotalCount="0"
      "OriginRes5xxCount" : 0,                   ClientRes2xxCount="0"
      "ClientReqCount" : 0,                      ClientRes3xxCount="0"
      "ClientResTotalCount" : 0,                 ClientRes4xxCount="0"
      "ClientRes2xxCount" : 0,                   ClientRes5xxCount="0"/>
      "ClientRes3xxCount" : 0,                 <HttpRequestHitSum
      "ClientRes4xxCount" : 0,                   TCP_NONE="0"
      "ClientRes5xxCount" : 0                    TCP_HIT="0"
    },                                           TCP_IMS_HIT="0"
    "HttpRequestHitSum" :                        TCP_REFRESH_HIT="0"
    {                                            TCP_REF_FAIL_HIT="0"
      "TCP_NONE" : 0,                            TCP_NEGATIVE_HIT="0"
      "TCP_HIT" : 0,                             TCP_REDIRECT_HIT="0"
      "TCP_IMS_HIT" : 0,                         TCP_MISS="0"
      "TCP_REFRESH_HIT" : 0,                     TCP_REFRESH_MISS="0"
      "TCP_REF_FAIL_HIT" : 0,                    TCP_CLIENT_REFRESH_MISS="0"
      "TCP_NEGATIVE_HIT" : 0,                    TCP_DENIED="0"
      "TCP_REDIRECT_HIT" : 0,                    TCP_ERROR="0"/>
      "TCP_MISS" : 0,                          <FileSystem>
      "TCP_REFRESH_MISS" : 0,                    <RequestHitRatio>0</RequestHitRatio>
      "TCP_CLIENT_REFRESH_MISS" : 0,             <ByteHitRatio>0</ByteHitRatio>
      "TCP_DENIED" : 0,                          <Outbound>0</Outbound>
      "TCP_ERROR" : 0                            <Session>0</Session>
    },                                         </FileSystem>
    "FileSystem":                              <System> ... </System>
    {                                          <VirtualHost> ... </VirtualHost>
      "RequestHitRatio":0,                     <VirtualHost> ... </VirtualHost>
      "ByteHitRatio":0,                        <VirtualHost> ... </VirtualHost>
      "Outbound":0,                            <View> ... </View>
      "Session":0                              <View> ... </View>
    },                                       </Host>
    "System":{ ... },
    "VirtualHost": [ ... ]
    "View": [ ... ]
  }
}

• Version STON 버전

• Name 호스트이름. 설정하지 않았다면 시스템 이름을 보여준다.

• State 서비스 상태. (Healthy=정상 서비스, Inactive=라이센스 비활성화, Emergency)

• Uptime (단위: 초) 서비스 실행시간

• OriginSession 원본세션 수

• OriginActiveSession 전송 중인 원본세션 수

• OriginInbound (단위: Bytes, 평균) 원본서버부터 받은 양

• OriginReqCount (평균) 원본서버로 보낸 요청횟수

• OriginOutbound (단위: Bytes, 평균) 원본서버로 보낸 양

• OriginResTotalCount (평균) 원본서버 응답횟수

• OriginResTotalTimeRes (단위: 0.01ms, 평균) 원본서버 응답시간 (HTTP요청 전송 ~ HTTP응답 첫 수신)

• OriginResTotalTimeComplete (단위: 0.01ms, 평균) 원본서버 HTTP 트랜잭션 완료시간 (HTTP요청 전송 ~ HTTP응답 완료)

• OriginRes2xxCount (평균) 원본서버 2xx응답횟수

• OriginRes2xxTimeRes (단위: 0.01ms, 평균) 원본서버 2xx응답시간

• OriginRes2xxTimeComplete (단위: 0.01ms, 평균) 원본서버 2xx 트랜잭션 완료시간

• OriginRes3xxCount (평균) 원본서버 3xx응답횟수

• OriginRes3xxTimeRes (단위: 0.01ms, 평균) 원본서버 3xx응답시간

• OriginRes3xxTimeComplete (단위: 0.01ms, 평균) 원본서버 3xx 트랜잭션 완료시간

• OriginRes4xxCount (평균) 원본서버 4xx응답횟수

• OriginRes4xxTimeRes (단위: 0.01ms, 평균) 원본서버 4xx응답시간

• OriginRes4xxTimeComplete (단위: 0.01ms, 평균) 원본서버 4xx 트랜잭션 완료시간

• OriginRes5xxCount (평균) 원본서버 5xx응답횟수

• OriginRes5xxTimeRes (단위: 0.01ms, 평균) 원본서버 5xx응답시간

• OriginRes5xxTimeComplete (단위: 0.01ms, 평균) 원본서버 5xx 트랜잭션 완료시간

• ClientSession 클라이언트 세션 수

• ClientActiveSession 전송 중인 클라이언트 세션 수

• ClientInbound (단위: Bytes, 평균) 클라이언트로부터 받은 양

• ClientOutbound (단위: Bytes, 평균) 클라이언트로에게 보낸 양

• ClientReqCount (평균) 클라이언트로 받은 요청횟수

• ClientResTotalCount (평균) 클라이언트 응답횟수

• ClientResTotalTimeRes (단위: 0.01ms, 평균) 클라이언트 응답시간 (HTTP요청 수신 ~ HTTP응답 전송)

• ClientResTotalTimeComplete (단위: 0.01ms, 평균) 클라이언트 HTTP 트랜잭션 완료시간 (HTTP요청 수신 ~ HTTP응답 완료)

• ClientRes2xxCount (평균) 클라이언트 2xx응답횟수

• ClientRes2xxTimeRes (단위: 0.01ms, 평균) 클라이언트 2xx응답시간

• ClientRes2xxTimeComplete (단위: 0.01ms, 평균) 클라이언트 2xx 트랜잭션 완료시간

• ClientRes3xxCount (평균) 클라이언트 3xx응답횟수

• ClientRes3xxTimeRes (단위: 0.01ms, 평균) 클라이언트 3xx응답시간

• ClientRes3xxTimeComplete (단위: 0.01ms, 평균) 클라이언트 3xx 트랜잭션 완료시간

• ClientRes4xxCount (평균) 클라이언트 4xx응답횟수

• ClientRes4xxTimeRes (단위: 0.01ms, 평균) 클라이언트 4xx응답시간

• ClientRes4xxTimeComplete (단위: 0.01ms, 평균) 클라이언트 4xx 트랜잭션 완료시간

• ClientRes5xxCount (평균) 클라이언트 5xx응답횟수

• ClientRes5xxTimeRes (단위: 0.01ms, 평균) 클라이언트 5xx응답시간

• ClientRes5xxTimeComplete (단위: 0.01ms, 평균) 클라이언트 5xx 트랜잭션 완료시간

• RequestHitRatio (단위: 0.01%, 평균) Hit율. 캐싱객체가 생성되어 있고 해당 객체가 초기화되어 있다면 Hit이다. 반대로 캐싱객체가 없거나 해당 객체가 원본서버로부터 초기화되지 않았다면 Hit로 치지 않는다. 응답코드와 Hit율은 관련이 없다.

  

  HTTP와 File I/O는 가상호스트를 공유한다.

  Apache를 통해 접근되는 File I/O의 RequestHitRatio는 0%이 된다. 하지만 HTTP Server의 경우 File I/O에 의해 캐싱된 파일을 접근하기 때문에 100%의 RequestHitRatio를 가진다. ByteHitRatio의 경우 원본 Inbound대비 Http outbound, File I/O outbound로 각각 계산된다.

• ByteHitRatio (단위: 0.01%, 평균) 원본서버 대비 클라이언트 전송률.

  (클라이언트 Outbound - 원본서버 Inbound) / 클라이언트 Outbound
  

  원본서버가 훨씬 빠른 속도를 가지고 있거나 클라이언트 세션이 금방 끊어진다면 음수가 된다.

• FileSystem 독립적인 FileSystem 통계로 다른 통계 수치에 취합되지 않는다.

  • RequestHitRatio (단위: 0.01%, 평균) File I/O를 통한 Hit율
  • ByteHitRatio (단위: 0.01%, 평균) 원본서버 대비 File I/O 전송률
  • Outbound (단위: Bytes, 평균) File I/O로 서비스한 데이터 크기
  • Session (평균) File I/O 진행 중인 Thread 수

System 통계¶

시스템 및 전역자원 통계를 JSON과 XML형식으로 제공한다.

"System":                                   <System>
{                                             <CPU
  "CPU":                                          Kernel="689"
  {                                               User="1316"
    "Kernel":689,                                 Idle="7993"
    "User":1316,                                  ProcKernel="570"
    "Idle":7993,                                  ProcUser="1216"
    "ProcKernel":570,                             Nice="0"
    "ProcUser":1216,                              IOWait="52"
    "Nice":0,                                     IRQ="10"
    "IOWait":52,                                  SoftIRQ="12"
    "IRQ":10,                                     Steal="0" />
    "SoftIRQ":12,                             <Mem Free="5914644" STON="9785800"/>
    "Steal":0                                 <Storage>
  },                                            <Disk
  "Mem":                                            Path="/cache1"
  {                                                 Status="Normal"
    "Free":5914644,                                 Read="23"
    "STON":9785800                                  ReadMerged="0"
  },                                                ReadSectors="344"
  "Storage":                                        ReadTime="117"
  {                                                 Write="24"
    "Disk":                                         WriteMerged="93"
    [                                               WriteSectors="936"
      {                                             WriteTime="256"
        "Path":"/cache1",                           IOProgress="0"
        "Status":"Normal",                          IOTime="173"
        "Read":23,                                  IOWeightedTime="373"/>
        "ReadMerged":0,                         <Disk
        "ReadSectors":344,                          Path="/cache2"
        "ReadTime":117,                             Status="Normal"
        "Write":24,                                 Read="27"
        "WriteMerged":93,                           ReadMerged="1"
        "WriteSectors":936,                         ReadSectors="488"
        "WriteTime":256,                            ReadTime="144"
        "IOProgress":0,                             Write="24"
        "IOTime":173,                               WriteMerged="86"
        "IOWeightedTime":373                        WriteSectors="880"
      },                                            WriteTime="254"
      {                                             IOProgress="0"
        "Path":"/cache2",                           IOTime="189"
        "Status":"Normal",                          IOWeightedTime="380"/>
        "Read":27,                            </Storage>
        "ReadMerged":1,                       <ServerSocket
        "ReadSectors":488,                          Total="42"
        "ReadTime":144,                             Established="2"
        "Write":24,                                 Accepted="1"
        "WriteMerged":86,                           Closed="0"/>
        "WriteSectors":880,                   <ClientSocket
        "WriteTime":254,                            Total="1"
        "IOProgress":0,                             Established="0"
        "IOTime":189,                               Connected="0"
        "IOWeightedTime":380                        Closed="0"/>
      }                                       <TCPSocket
    ]                                               Established="30"
  },                                                Timewait="2"
  "ServerSocket":                                   Orphan="0"
  {                                                 Alloc="0"
    "Total":42,                                     Mem="20"/>
    "Established":1,                          <EQ>0</EQ>
    "Accepted":0,                             <RQ>1000000</RQ>
    "Closed":0                                <WaitingFiles2Write>0</WaitingFiles2Write>
  },                                          <ServiceAccess Allow="60" Deny="2"/>
  "ClientSocket":                             <SystemLoadAverage Min1="0" Min5="0" Min15="0"/>
  {                                           <URLRewrite>57</URLRewrite>
    "Total":1,                              </System>
    "Established":0,
    "Connected":0,
    "Closed":0
  },
  "TCPSocket":
  {
    "Established":30,
    "Timewait":2,
    "Orphan":0,
    "Alloc":0,
    "Mem":20
  },
  "EQ":0,
  "RQ":1000000,
  "WaitingFiles2Write":0,
  "ServiceAccess":{"Allow":60, "Deny":2}
  "SystemLoadAverage":
  {
    "Min1":0,
    "Min5":0,
    "Min15":0
  },
  "URLRewrite":57
}

• CPU (단위: 0.01%) CPU사용량. 전체 CPU사용량은 Kernel + User로 계산해야 한다.
  • Kernel CPU(Kernel) 사용량
  • User CPU(User) 사용량
  • Idle 사용되지 않는 CPU량
  • ProcKernel STON이 사용하는 CPU(Kernel) 사용량
  • ProcUser STON이 사용하는 CPU(User) 사용량
  • Nice niced processes executing in user mode
  • IOWait waiting for I/O to complete
  • IRQ servicing interrupts
  • SoftIRQ servicing softirqs
  • Steal involuntary wait
• Mem (단위: Bytes) 메모리 사용량. - Free 시스템 Free 메모리 크기 - STON STON이 사용하는 메모리 크기
• Disk 디스크 성능지표
  • Path 디스크 경로
  • Status 디스크 상태 (Normal: 정상동작, Invalid: 장애로 배제됨, Unmounted: 관리자에 의해 Unmount됨)
  • Read 읽기 성공 횟수
  • ReadMerged 읽기가 병합된 횟수
  • ReadMerged 읽은 섹터 수
  • ReadTime (단위: ms) 읽기 소요시간
  • Write 쓰기 성공 횟수
  • WriteMerged 쓰기가 병합된 횟수
  • WriteSectors 써진 섹터 수
  • WriteTime (단위: ms) 쓰기 소요시간
  • IOProgress 진행 중인 IO개수
  • IOTime (단위: ms) IO 소요시간
  • IOWeightedTime (단위: ms) IO 소요시간(가중치 적용)
• ServerSocket 서버 소켓(클라이언트와 STON 구간) 정보
  • Total 전체 서버소켓 수
  • Established 연결된 상태의 서버소켓 수
  • Accepted 새롭게 연결된 서버소켓 수
  • Closed 연결이 종료된 서버소켓 수
• ClientSocket 클라이언트 소켓(STON과 원본서버 구간) 정보
  • Total 전체 클라이언트소켓 수
  • Established 연결된 상태의 클라이언트소켓 수
  • Connected 새롭게 연결된 클라이언트소켓 수
  • Closed 연결이 종료된 클라이언트소켓 수
• TCPSocket 시스템(OS)이 제공하는 TCP상태 정보
  • Established Established상태의 TCP 연결개수
  • Timewait TIME_WAIT 상태의 TCP 연결개수
  • Orphan 아직 file handle에 attach되지 않은 TCP 연결
  • Alloc 할당된 TCP 연결
  • Mem undocumented
• EQ STON Framework에서 아직 처리되지 않은 Event개수
• RQ 최근 서비스된 컨텐츠 참조 큐에 저장된 Event 개수
• WaitingFiles2Write 디스크에 쓰기 대기중인 파일개수
• ServiceAccess ServiceAccess에 의해 허가(Allow), 거부(Deny)된 소켓 수
• SystemLoadAverage System Load Average의 1분/5분/15분 평균
• URLRewrite URL전처리에 의해 변환이 성공한 횟수

가상호스트 통계¶

가상호스트별로 통계가 제공된다. 가상호스트 통계는 HTTP전송(디렉토리 별), URL바이패스, 포트바이패스, SSL로 구분된다.

"VirtualHost":                               <VirtualHost
[                                                Name="image.11st.co.kr"
  {                                              Uptime="155956"
    "Name":"image.11st.co.kr",                   OriginSession="12"
    "Uptime":155966,                             OriginActiveSession="6"
    "OriginSession":12,                          OriginInbound="106914"
    "OriginActiveSession":6,                     OriginOutbound="3238"
    "OriginInbound":169,                         OriginReqCount="42"
    "OriginOutbound":269,                        OriginResTotalCount="13"
    "OriginReqCount":62,                         OriginResTotalTimeRes="1553"
    "OriginResTotalCount":1,                     OriginResTotalTimeComplete="6630"
    "OriginResTotalTimeRes":3300,                OriginRes2xxCount="1"
    "OriginResTotalTimeComplete":3300,           OriginRes2xxTimeRes="3300"
    "OriginRes2xxCount":0,                       OriginRes2xxTimeComplete="69300"
    "OriginRes2xxTimeRes":0,                     OriginRes3xxCount="12"
    "OriginRes2xxTimeComplete":0,                OriginRes3xxTimeRes="1408"
    "OriginRes3xxCount":1,                       OriginRes3xxTimeComplete="1408"
    "OriginRes3xxTimeRes":3300,                  OriginRes4xxCount="0"
    "OriginRes3xxTimeComplete":3300,             OriginRes4xxTimeRes="0"
    "OriginRes4xxCount":0,                       OriginRes4xxTimeComplete="0"
    "OriginRes4xxTimeRes":0,                     OriginRes5xxCount="0"
    "OriginRes4xxTimeComplete":0,                OriginRes5xxTimeRes="0"
    "OriginRes5xxCount":0,                       OriginRes5xxTimeComplete="0"
    "OriginRes5xxTimeRes":0,                     ClientSession="30"
    "OriginRes5xxTimeComplete":0,                ClientActiveSession="12"
    "ClientSession":26,                          ClientInbound="4113"
    "ClientActiveSession":16,                    ClientOutbound="895937"
    "ClientInbound":13968,                       ClientReqCount="64"
    "ClientOutbound":110398,                     ClientResTotalCount="18"
    "ClientReqCount":152,                        ClientResTotalTimeRes="666"
    "ClientResTotalCount":52,                    ClientResTotalTimeComplete="4377"
    "ClientResTotalTimeRes":94,                  ClientRes2xxCount="10"
    "ClientResTotalTimeComplete":107,            ClientRes2xxTimeRes="1200"
    "ClientRes2xxCount":1,                       ClientRes2xxTimeComplete="7870"
    "ClientRes2xxTimeRes":4700,                  ClientRes3xxCount="8"
    "ClientRes2xxTimeComplete":4800,             ClientRes3xxTimeRes="0"
    "ClientRes3xxCount":51,                      ClientRes3xxTimeComplete="12"
    "ClientRes3xxTimeRes":3,                     ClientRes4xxCount="0"
    "ClientRes3xxTimeComplete":15,               ClientRes4xxTimeRes="0"
    "ClientRes4xxCount":0,                       ClientRes4xxTimeComplete="0"
    "ClientRes4xxTimeRes":0,                     ClientRes5xxCount="0"
    "ClientRes4xxTimeComplete":0,                ClientRes5xxTimeRes="0"
    "ClientRes5xxCount":0,                       ClientRes5xxTimeComplete="0"
    "ClientRes5xxTimeRes":0,                     RequestHitRatio="10000"
    "ClientRes5xxTimeComplete":0,                ByteHitRatio="8806">
    "RequestHitRatio":10000,                   <FileSystem>
    "ByteHitRatio":9984,                         <RequestHitRatio>0</RequestHitRatio>
    "FileSystem":                                <ByteHitRatio>0</ByteHitRatio>
    {                                            <Outbound>0</Outbound>
      "RequestHitRatio":0,                       <Session>0</Session>
      "ByteHitRatio":0,                        </FileSystem>
      "Outbound":0,                            <Memory>784786700</Memory>.
      "Session":0                              <SecuredMemory>0</SecuredMemory>.
    },                                         <Disk> ... </Disk>
    "Memory":785740769,                        <Session> ... </Session>
    "SecuredMemory":0,                         <Dims> ... </Dims>
    "Disk": { ... },                           <Compression> ... </Compression>
    "Session": { ... },                        <File Total="458278" Opened="15" Instance="458292"/>
    "Dims": { ... },                           <Cached> ... </Cached>
    "Compression": { ... },                    <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": { ... }

  },
  ...
]

• Memory (단위: Bytes) 메모리에 적재된 컨텐츠 양
• SecuredMemory (단위: Bytes) 메모리에서 삭제한 컨텐츠 양
• Disk 디스크 정보
• Session 세션 정보
• Dims DIMS변환 통계
• Compression 압축 통계
• FileTotal 전체파일 개수
• FileOpened 열려져 있는 로컬파일 개수
• FileInstance 캐싱파일 개수
• Cached 캐싱 정보
• CacheFileEvent 캐싱파일 이벤트
• WaitingFiles2Delete 삭제대기 중인 파일개수
• ClientHttpReqBypass 바이패스한 클라이언트 HTTP요청 횟수
• ClientHttpReqDenied HTTP요청이 차단된 횟수
• OriginTraffic 원본서버 트래픽 통계
• PortBypass 포트 바이패스 트래픽 통계
• ClientTraffic 클라이언트 트래픽 통계
• UrlBypass URL매칭 또는 <BypassNoCacheRequest> 를 통해 원본서버로변환 통계되는 HTTP트래픽 통계

"Disk":                                      <Disk>
{                                              <TotalSize>22003701435</TotalSize>
  "TotalSize":22004057982,                     <Create>1</Create>
  "Create":0,                                  <Open>10</Open>
  "Open":1,                                    <Delete>0</Delete>
  "Delete":0,                                  <ReadCount>9</ReadCount>
  "ReadCount":1,                               <ReadSize>735726</ReadSize>
  "ReadSize":104744,                           <WriteCount>1</WriteCount>
  "WriteCount":0,                              <WriteSize>157145</WriteSize>
  "WriteSize":0,                               <Distribution
  "Distribution":                                U1K="45725"
  {                                              U2K="192523"
    "U1K="45725,                                 U4K="137055"
    "U2K="192523,                                U8K="39740"
    "U4K="137055,                                U16K="13408"
    "U8K="39740,                                 U32K="12303"
    "U16K="13408,                                U64K="11462"
    "U32K="12303,                                U128K="2560"
    "U64K="11462,                                U256K="22"
    "U128K="2560,                                U512K="0"
    "U256K="22,                                  U1M="45725"
    "U512K="0,                                   U2M="192523"
    "U1M="45725,                                 U4M="137055"
    "U2M="192523,                                U8M="39740"
    "U4M="137055,                                U16M="13408"
    "U8M="39740,                                 U32M="12303"
    "U16M="13408,                                U64M="11462"
    "U32M="12303,                                U128M="2560"
    "U64M="11462,                                U256M="22"
    "U128M="2560,                                U512M="0"
    "U256M="22,                                  U1G="0"
    "U512M="0,                                   U2G="0"
    "U1G="0,                                     U4G="0"
    "U2G="0,                                     U8G="0"
    "U4G="0,                                     U16G="0"
    "U8G="0,                                     O16G="0" />
    "U16G":0,                                  </Disk>
    "O16G":0

  }
}

"Session":                                   <Session
{                                              Client="30"
  "Client":30,                                 ActiveClient="20"
  "ActiveClient":20,                           Origin="12"
  "Origin":12,                                 ActiveOrigin="7" />
  "ActiveOrigin":7
},

"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
},

"Compression":                             <Compression
{                                           Requests="30"
  "Requests": 30,                           Converted="29"
  "Converted": 29,                          Failed="1"
  "Failed": 1,                              AvgSrcSize="1457969"
  "AvgSrcSize": 1457969,                    AvgDestSize="598831"
  "AvgDestSize": 598831,                    AvgTime="34" />
  "AvgTime": 34
},

"OriginTraffic":                             <OriginTraffic>
{                                              <HttpReqCount Sum="600">2</HttpReqCount>
  "HttpReqCountSum":0,                         <HttpReqHeaderSize>3238</HttpReqHeaderSize>
  "HttpReqCount":0,                            <HttpReqBodySize>0</HttpReqBodySize>
  "HttpReqHeaderSize":269,                     <HttpResHeaderSize>2020</HttpResHeaderSize>
  "HttpReqBodySize":0,                         <HttpResBodySize>104894</HttpResBodySize>
  "HttpResHeaderSize":169,                     <Response>
  "HttpResBodySize":0,                           <ResTotal>
  "Response":                                      <Count Sum="8100">13</Count>
  {                                                <Completed Sum="8100">12</Completed>
    "ResTotal":                                    <TimeRes>1553</TimeRes>
    {                                              <TimeComplete>6630</TimeComplete>
      "CountSum":0,                              </ResTotal>
      "Count":1,                                 <Res2xx>
      "CompletedSum":0,                            <Count Sum="8100">1</Count>
      "Completed":1,                               <Completed Sum="8100">1</Completed>
      "TimeRes":3300,                              <TimeRes>3300</TimeRes>
      "TimeComplete":3300                          <TimeComplete>69300</TimeComplete>
    },                                           </Res2xx>
    "Res2xx":                                    <Res3xx>
    {                                              <Count Sum="8100">12</Count>
      "CountSum":0,                                <Completed Sum="8100">11</Completed>
      "Count":0,                                   <TimeRes>1408</TimeRes>
      "CompletedSum":0,                            <TimeComplete>1408</TimeComplete>
      "Completed":0,                             </Res3xx>
      "TimeRes":0,                               <Res4xx>
      "TimeComplete":0                             <Count Sum="8100">0</Count>
    },                                             <Completed Sum="8100">0</Completed>
    "Res3xx":                                      <TimeRes>0</TimeRes>
    {                                              <TimeComplete>0</TimeComplete>
      "CountSum":0,                              </Res4xx>
      "Count":1,                                 <Res5xx>
      "CompletedSum":0,                            <Count Sum="8100">0</Count>
      "Completed":1,                               <Completed Sum="8100">0</Completed>
      "TimeRes":3300,                              <TimeRes>0</TimeRes>
      "TimeComplete":3300                          <TimeComplete>0</TimeComplete>
    },                                           </Res5xx>
    "Res4xx":                                    <ConnectTimeout Sum="8100">0</ConnectTimeout>
    {                                            <ReceiveTimeout Sum="8100">0</ReceiveTimeout>
      "CountSum":0,                              <Close Sum="8100">0</Close>
      "Count":0,                               </Response>
      "CompletedSum":0,                        <Connect>
      "Completed":0,                             <Count>0</Count>
      "TimeRes":0,                               <AvgDNSQueryTime>0</AvgDNSQueryTime>
      "TimeComplete":0                           <AvgConnTime>0</AvgConnTime>
    },                                         </Connect>
    "Res5xx":                                </OriginTraffic>
    {
      "CountSum":0,
      "Count":0,
      "CompletedSum":0,
      "Completed":0,
      "TimeRes":0,
      "TimeComplete":0
    },
    "ConnectTimeoutSum":0,
    "ConnectTimeout":0,
    "ReceiveTimeoutSum":0,
    "ReceiveTimeout":0,
    "CloseSum":0,
    "Close":0
  },
  "Connect":
  {
    "Count":0,
    "AvgDNSQueryTime":0,
    "AvgConnTime":0
  }
},

"PortBypass":                                            <PortBypass SrcPort="1935" DestPost="1935">
[                                                          <Session>0</Session>
  {                                                        <Hit Established="0"
    "SrcPort":1935, "DestPort":1935, "Session":0,               ClientClosed="0"
    "Hit":                                                      OriginClosed="0"
    {                                                           OriginCT="0" />
      "Established":0, "ClientClosed":0,                   <ClientTraffic In="0" Out="0"/>
      "OriginClosed":0, "OriginCT":0                       <OriginTraffic In="0" Out="0"/>
    },                                                   </PortBypass>
    "ClientTraffic": { "In":0, "Out":0 },                <PortBypass SrcPort="1936" DestPost="1936">
    "OriginTraffic": { "In":0, "Out":0 }                   <Session>17</Session>
  },                                                       ...
  {                                                      </PortBypass>
    "SrcPort":1936, "DestPort":1936, "Session":17,
    ...
  }
],

"ClientTraffic":                             <ClientTraffics Depth="0" Accum="OFF" HttpsTraffic="OFF">
{                                              <TrafficCount>1</TrafficCount>
  "Depth":0,                                   <Traffic RequestHitRatio="0">
  "Accum":"OFF",                                 <Path>/</Path>
  "HttpsTraffic":"OFF",                          <HttpReqCount Sum="0">0</HttpReqCount>
  "TrafficCount":1,                              <HttpReqHeaderSize>4113</HttpReqHeaderSize>
  "Traffic":                                     <HttpReqBodySize>0</HttpReqBodySize>
  [                                              <HttpResHeaderSize>3066</HttpResHeaderSize>
    {                                            <HttpResBodySize>892871</HttpResBodySize>
      "RequestHitRatio" : 9984,                  <Response>
      "Path":"/",                                  <ResTotal>
      "HttpReqCountSum":0,                           <Count Sum="0">18</Count>
      "HttpReqCount":100,                            <Completed Sum="0">18</Completed>
      "HttpReqHeaderSize":13968,                     <TimeRes>666</TimeRes>
      "HttpReqBodySize":0,                           <TimeComplete>4377</TimeComplete>
      "HttpResHeaderSize":5654,                    </ResTotal>
      "HttpResBodySize":104744,                    <Res2xx>
      "Response":                                    <Count Sum="0">10</Count>
      {                                              <Completed Sum="0">10</Completed>
        "ResTotal":                                  <TimeRes>1200</TimeRes>
        {                                            <TimeComplete>7870</TimeComplete>
          "CountSum":0,                            </Res2xx>
          "Count":52,                              <Res3xx>
          "CompletedSum":0,                          <Count Sum="0">8</Count>
          "Completed":52,                            <Completed Sum="0">8</Completed>
          "TimeRes":94,                              <TimeRes>0</TimeRes>
          "TimeComplete":107                         <TimeComplete>12</TimeComplete>
        },                                         </Res3xx>
        "Res2xx":                                  <Res4xx>
        {                                            <Count Sum="0">0</Count>
          "CountSum":0,                              <Completed Sum="0">0</Completed>
          "Count":1,                                 <TimeRes>0</TimeRes>
          "CompletedSum":0,                          <TimeComplete>0</TimeComplete>
          "Completed":1,                           </Res4xx>
          "TimeRes":4700,                          <Res5xx>
          "TimeComplete":4800                        <Count Sum="0">0</Count>
        },                                           <Completed Sum="0">0</Completed>
        "Res3xx":                                    <TimeRes>0</TimeRes>
        {                                            <TimeComplete>0</TimeComplete>
          "CountSum":0,                            </Res5xx>
          "Count":51,                            </Response>
          "CompletedSum":0,                      <SSL RecvSize="0" SendSize="0"/>
          "Completed":51,                        <RequestHit
          "TimeRes":3,                             TCP_NONE="0"
          "TimeComplete":15                        TCP_HIT="0"
        },                                         TCP_IMS_HIT="0"
        "Res4xx":                                  TCP_REFRESH_HIT="0"
        {                                          TCP_REF_FAIL_HIT="0"
          "CountSum":0,                            TCP_NEGATIVE_HIT="0"
          "Count":0,                               TCP_REDIRECT_HIT="0"
          "CompletedSum":0,                        TCP_MISS="0"
          "Completed":0,                           TCP_REFRESH_MISS="0"
          "TimeRes":0,                             TCP_CLIENT_REFRESH_MISS="0"
          "TimeComplete":0                         TCP_DENIED="0"
        },                                         TCP_ERROR="0"/>
        "Res5xx":                                <RequestHitSum
        {                                          TCP_NONE="0"
          "CountSum":0,                            TCP_HIT="0"
          "Count":0,                               TCP_IMS_HIT="0"
          "CompletedSum":0,                        TCP_REFRESH_HIT="0"
          "Completed":0,                           TCP_REF_FAIL_HIT="0"
          "TimeRes":0,                             TCP_NEGATIVE_HIT="0"
          "TimeComplete":0                         TCP_REDIRECT_HIT="0"
        }                                          TCP_MISS="0"
      },                                           TCP_REFRESH_MISS="0"
      "SSL":                                       TCP_CLIENT_REFRESH_MISS="0"
      {                                            TCP_DENIED="0"
        "RecvSize":0,                              TCP_ERROR="0"/>
        "SendSize":0                           </Traffic>
      },                                       <FileSystem>
      "RequestHit":                              <GetAttr
      {                                            TimeRes="0"
        "TCP_NONE":0,                              FileCount="0"
        "TCP_HIT":0,                               DirCount="0"
        "TCP_IMS_HIT":0,                           FailCount="0">0</GetAttr>
        "TCP_REFRESH_HIT":0,                     <Open TimeRes="0">0</Open>
        "TCP_REF_FAIL_HIT":0,                    <Read
        "TCP_NEGATIVE_HIT":0,                      TimeRes="0"
        "TCP_REDIRECT_HIT":0,                      BufferSize="0"
        "TCP_MISS":0,                              BufferFilled="0">0</Read>
        "TCP_REFRESH_MISS":0,                    <RequestHit
        "TCP_CLIENT_REFRESH_MISS":0,               TCP_NONE="0"
        "TCP_DENIED":0,                            TCP_HIT="0"
        "TCP_ERROR":0                              TCP_IMS_HIT="0"
      },                                           TCP_REFRESH_HIT="0"
      "RequestHitSum":                             TCP_REF_FAIL_HIT="0"
      {                                            TCP_NEGATIVE_HIT="0"
        "TCP_NONE":0,                              TCP_REDIRECT_HIT="0"
        "TCP_HIT":0,                               TCP_MISS="0"
        "TCP_IMS_HIT":0,                           TCP_REFRESH_MISS="0"
        "TCP_REFRESH_HIT":0,                       TCP_CLIENT_REFRESH_MISS="0"
        "TCP_REF_FAIL_HIT":0,                      TCP_DENIED="0"
        "TCP_NEGATIVE_HIT":0,                      TCP_ERROR="0"/>
        "TCP_REDIRECT_HIT":0,                    <RequestHitSum
        "TCP_MISS":0,                              TCP_NONE="0"
        "TCP_REFRESH_MISS":0,                      TCP_HIT="0"
        "TCP_CLIENT_REFRESH_MISS":0,               TCP_IMS_HIT="0"
        "TCP_DENIED":0,                            TCP_REFRESH_HIT="0"
        "TCP_ERROR":0                              TCP_REF_FAIL_HIT="0"
      },                                           TCP_NEGATIVE_HIT="0"
      "FileSystem":                                TCP_REDIRECT_HIT="0"
      {                                            TCP_MISS="0"
        "GetAttr" :                                TCP_REFRESH_MISS="0"
        {                                          TCP_CLIENT_REFRESH_MISS="0"
          "TimeRes" : 0,                           TCP_DENIED="0"
          "FileCount" : 0,                         TCP_ERROR="0"/>
          "DirCount" : 0,                      </FileSystem>
          "FailCount" : 0,                   </ClientTraffics>
          "TotalCount" : 0
        },
        "Open" :
        {
          "TimeRes" : 0,
          "Count" : 0
        },
        "Read" :
        {
          "TimeRes" : 0,
          "BufferSize" : 0,
          "BufferFilled" : 0,
          "Count" : 0
        },
        "RequestHit":
        {
          "TCP_NONE":0,
          "TCP_HIT":0,
          "TCP_IMS_HIT":0,
          "TCP_REFRESH_HIT":0,
          "TCP_REF_FAIL_HIT":0,
          "TCP_NEGATIVE_HIT":0,
          "TCP_REDIRECT_HIT":0,
          "TCP_MISS":0,
          "TCP_REFRESH_MISS":0,
          "TCP_CLIENT_REFRESH_MISS":0,
          "TCP_DENIED":0,
          "TCP_ERROR":0
        },
        "RequestHitSum":
        {
          "TCP_NONE":0,
          "TCP_HIT":0,
          "TCP_IMS_HIT":0,
          "TCP_REFRESH_HIT":0,
          "TCP_REF_FAIL_HIT":0,
          "TCP_NEGATIVE_HIT":0,
          "TCP_REDIRECT_HIT":0,
          "TCP_MISS":0,
          "TCP_REFRESH_MISS":0,
          "TCP_CLIENT_REFRESH_MISS":0,
          "TCP_DENIED":0,
          "TCP_ERROR":0
        }
      }
    }
  ]
}

View¶

View는 가상호스트들을 하나로 묶어 통계를 추출하는 방식이다. Database에서 여러 Table을 마치 하나인 것처럼 다루는 View에서 따온 개념이다. 구성은 다음과 같이 아주 간단하다.

# vhosts.xml

<Vhosts>
  <Vhost> ... </Vhost>
  <Vhost> ... </Vhost>
  ... (생략) ...
  <View Name="SK">
    <Vhost>...</Vhost>
    <Vhost>...</Vhost>
  </View>
  <View Name="KT">
    <Vhost>...</Vhost>
    <Vhost>...</Vhost>
    <Vhost>...</Vhost>
  </View>
  <View Name="LG">
    <Vhost>...</Vhost>
    <Vhost>...</Vhost>
  </View>
</Vhosts>

존재하지 않는 가상호스트로 View를 구성해도 상관없다. View가 제공하는 통계는 다음과 같다.

-  Realtime XML/JSON
-  SNMP - cache(1.3.6.1.4.1.40001.1.4).10 ~ 12

이해를 돕기 위해 View가 필요한 예를 들어보자. 류헌진, 서장혼, 박지송은 각각 자신이 좋아하는 스포츠 커뮤니티 사이트를 운영하고 있다.

# vhosts.xml

<Vhosts>
  <Vhost Name="baseball.com"> ... </Vhost>
  <Vhost Name="basketball.com"> ... </Vhost>
  <Vhost Name="football.com"> ... </Vhost>
</Vhosts>

평소 친분이 있던 셋은 의기투합하여 스포츠 종합 커뮤니티 서비스를 오픈하기로 결정했다. 도메인도 서비스를 모두 아우를 수 있는 sports.com으로 정했다. 개발/운영팀이 해결해야하는 미션은 다음과 같다.

• 통합 서비스는 sports.com으로 한다.
• 기존 사용자를 위해 기존 도메인과 서비스는 그대로 유지한다.
• 개발팀은 통합한다. 운영팀은 통합한다.
• 대문(첫 페이지)만 신규 개발한다. 링크를 통해 기존 서비스를 이용한다.
• 예산이 없다. 사람이 없다. 시간이 없다. 정신이 없다.
• 이미 모든 구매절차가 끝났다.

이 모든 요구사항을 처리하는 현실적인 방법으로 개발팀은 다음과 같이 1번째 디렉토리에 기존 도메인을 명시하는 규칙을 사용하기로 결정했다.

# 기존 서비스
http://baseball.com/standing/list.html
http://basketball.com/stats/2014/view.html
http://football.com/player/messi.php

# 통합 서비스
http://sports.com/baseball/standing/list.html
http://sports.com/basketball/stats/2014/view.html
http://sports.com/football/player/messi.php

URL 전처리를 사용하면 간단히 설정할 수 있다.

# vhosts.xml

<Vhosts>
  <Vhost Name="baseball.com"> ... </Vhost>
  <Vhost Name="basketball.com"> ... </Vhost>
  <Vhost Name="football.com"> ... </Vhost>
  <URLRewrite>
    <Pattern>sports.com/(.*)/(.*)</Pattern>
    <Replace>#1.com/#2</Replace>
  </URLRewrite>
</Vhosts>

통합된 운영팀에서는 이제 각각의 서비스 뿐만 아니라 통합된 서비스(트래픽, 세션, 응답코드 등)에 대해서도 모니터링해야 한다. 대부분 SNMP에 익숙한 관리자들이며 통합된 지표를 얻기 위해 다음과 같이 View를 구성한다.

# vhosts.xml

<Vhosts>
   <Vhost Name="baseball.com"> ... </Vhost>
   <Vhost Name="basketball.com"> ... </Vhost>
   <Vhost Name="football.com"> ... </Vhost>
   <URLRewrite>
      <Pattern>sports.com/(.*)/(.*)</Pattern>
      <Replace>#1.com/#2</Replace>
   </URLRewrite>
   <View Name="sports.com">
      <Vhost>baseball.com</Vhost>
      <Vhost>basketball.com</Vhost>
      <Vhost>football.com</Vhost>
   </View>
</Vhosts>

이상의 예에서 알 수 있듯이 URL Rewrite와 View의 조합은 기존 사이트를 하나로 묶어 서비스할 때 효과적이다.

"View":                                  <View ...>
[                                           ...
  { ... },                               </View>
  { ... },                               <View> ... </View>
]                                        <View> ... </View>

가상호스트 목록조회¶

가상호스트 목록을 조회한다.

http://127.0.0.1:10040/monitoring/vhostslist

결과는 JSON형식으로 제공된다.

{
    "version": "2.0.0",
    "method": "vhostslist",
    "status": "OK",
    "result": [ "www.example.com","www.winesoft.com", "site1.com" ]
}

캐싱정보¶

캐싱하고 있는 파일상태를 모니터링한다. 일반적으로 파일은 URL로 구분되지만 같은 URL에 다른 옵션(i.e. Accept-Encoding등)이 존재하는 경우 여러 개의 파일이 존재할 수 있다.

http://127.0.0.1:10040/monitoring/fileinfo?url=example.com/sample.dat

결과는 JSON형식으로 제공된다. 다음은 /sample.dat파일의 정보를 열람한 결과이다.

{
    "version": "2.0.0",
    "method": "fileinfo",
    "status": "OK",
    "result":
    [
        {
            "URI": "/sample.dat",
            "Accept-Encoding": "N",
            "RefCount": 0,
            "Disk-Index": 0,
            "Size": 2100267,
            "FID": 24267,
            "LocalPath": "/cache1/example.com/000i/q3.bin",
            "File-Opened ": "N",
            "File-Updating": "-",
            "Downloader-Count": "0",
            "LastAccess": "[ 2012.09.03 14:29:50, -2 ]",
            "UpdateTime": "[ 2012.09.03 13:53:43, -2169 ]",
            "TTL-Left": "[ 2012.10.03 13:53:43, 2589831 ]",
            "ResponseCode": 200,
            "ContentType": "text/plain",
            "LastModifiedTime": "[ 2010.11.22 20:31:47, -56224685 ]",
            "ExpireTime": "[ 0, 0 ]",
            "CacheControl": "not-specified",
            "ETag": "502dd614:200c2b",
            "CustomTTL": 0,
            "NoMoreExist": "N",
            "LocalFileExist": "Y",
            "SmallFile": "N",
            "State": "Cached",
            "Deleted": "N",
            "AddedSize": "Y",
            "TransferEncoding": "N",
            "Compression": "-",
            "Purge": "N",
            "Ignore-IMS ": "N",
            "Redirect-Location ": "-",
            "Content-Disposition ": "-",
            "NoCache": "N"
        }
    ]
}

• URI 파일 URI
• Accept-Encoding (“Y” or “N”) Accept-Encoding을 지원한다면 “Y”
• RefCount 파일참조 카운트
• Size (Bytes) 파일크기
• Disk-Index (0부터 시작) 저장된 디스크 인덱스
• FID 파일 ID
• LocalPath 로컬 경로
• File-Opened (“Y” or “N”) 로컬파일을 열고 있다면 “Y”
• File-Updating 파일을 갱신 중이라면 갱신하는 객체의 포인터가 명시
• Downloader-Count 원본서버에서 이 파일을 다운로드 받는 현재 세션의 개수
• LastAccess (마지막 접근시간, 마지막 접근시간-현재시간) [ 2012.09.03 14:29:50, -2 ]의 의미는 2012.09.03 14:29:50에 접근됐으며 현재로부터 2초 전에 접근됐다는 의미이다.
• UpdateTime (갱신시간, 갱신시간-현재시간) 파일이 마지막으로 갱신된 시간. 304 Not Modified에도 시간은 갱신된다.
• TTL-Left (만료시간, 만료시간-현재시간) 컨텐츠 만료 예정시간. TTL이 남았다면 양수로, 만료됐다면 음수로 표기된다.
• ResponseCode 원본서버 응답코드
• ContentType MIME Type
• LastModifiedTime (Last Modified Time, Last Modified Time`` 현재시간) 원본서버가 보낸 Last Modified Time. 원본서버가 이 값을 보내지 않았다면 0으로 표시된다.
• ExpireTime (Expire Time, Expire Time`` 현재시간) 원본서버가 보낸 Expire Time. 원본서버가 이 값을 보내지 않았다면 0으로 표시된다.
• CacheControl (“no-cache” or “not-specified” or (정수)) 원본서버가 보낸 Cache-Contorl 값
• ETag STON이 생성한 ETag
• CustomTTL 커스텀 TTL. 설정되어 있지 않다면 0이다.
• NoMoreExist (“Y” or “N”) 파일을 파기예약되어 있다면 “Y”
• LocalFileExist (“Y” or “N”) 로컬에 파일이 존재하면 “Y” (200 OK가 아닌 파일들은 항상 “Y”)
• SmallFile (“Y” or “N”) 파일을 작은파일로 판단한다면 “Y” (개발적인 이유)
• State (“Not Init” or “Cached” or “Error”) 파일 상태
• Deleted (“Y” or “N”) 삭제되었다면 “Y” (개발적인 이유)
• AddedSize (“Y” or “N”) 크기가 통계에 반영되었다면 “Y” (개발적인 이유)
• TransferEncoding (“Y” or “N”) Transfer-Encoding을 지원한다면 “Y”
• Compression 압축방식
• Purge (“Y” or “N”) Purge됐다면 “Y”
• Ignore-IMS (“Y” or “N”) 갱신할 때 If-Modified-Since헤더를 보내지 않도록 설정되었다면 “Y”
• Redirect-Location Location 헤더 값
• Content-Disposition Content-Disposition 헤더 값
• NoCache (“Y” or “N”) 원본서버에서 no-cache응답을 줬다면 “Y”

Log Trace¶

기록되는 로그를 실시간으로 받아본다. Access, Origin, Monitoing로그는 가상호스트(vhost)를 지정해야 한다.

http://127.0.0.1:10040/monitoring/logtrace/info
http://127.0.0.1:10040/monitoring/logtrace/deny
http://127.0.0.1:10040/monitoring/logtrace/sys
http://127.0.0.1:10040/monitoring/logtrace/originerror
http://127.0.0.1:10040/monitoring/logtrace/access?vhost=www.site1.com
http://127.0.0.1:10040/monitoring/logtrace/origin?vhost=www.site1.com
http://127.0.0.1:10040/monitoring/logtrace/monitoring?vhost=www.site1.com

변수¶

설정이나 사용자의 의도에 의하여 변경될 수 있는 값을 [변수명]으로 명시한다. 예를 들어 디스크는 여러개가 존재할 수 있다. 이 경우 각 디스크를 가리키는 고유 번호가 필요하며 입력된 순서대로 1부터 할당된다. 이런 변수를 [diskIndex] 로 명시한다.

• [diskIndex]

  Storage에 설정된 디스크를 의미한다.

  # server.xml - <Server><Cache>
  
  <Storage>
     <Disk>/cache1</Disk>
     <Disk>/cache2</Disk>
     <Disk>/cache3</Disk>
  </Storage>
  

  위와 같이 3개의 디스크가 설정된 환경에서 /cache1의 [diskIndex] 는 1, /cache3의 [diskIndex] 는 3을 가진다. 예를 들어 /cache1의 전체용량에 해당하는 OID는 system.diskInfo.diskInfoTotalSize.1 (1.3.6.1.4.1.40001.1.2.18.1.3.1이 된다. 마지막 .1은 첫번째 디스크를 의미한다.

• [vhostIndex]

  가상호스트가 로딩될 때 자동으로 부여된다.

  # vhosts.xml
  
  <Vhosts>
     <Vhost Status="Active" Name="kim.com"> ... </Vhost>
     <Vhost Status="Active" Name="lee.com"> ... </Vhost>
     <Vhost Status="Active" Name="park.com" StaticIndex="10300"> ... </Vhost>
  </Vhosts>
  

  최초 위와 같이 3개의 가상호스트가 로딩되면 1부터 순차적으로 [vhostIndex] 가 부여된다. 이후 가상호스트는 [vhostIndex] 를 기억하며, 가상호스트가 삭제되더라도 [vhostIndex] 는 변하지 않는다. 가상호스트의 삭제와 추가가 동시에 발생할 경우 삭제가 먼저 동작하며, 신규 추가된 가상호스트는 비어있는 [vhostIndex] 를 부여 받는다.

  

  [vhostIndex] 의 동작방식

• [diskMin] , [vhostMin]

  시간(분)을 의미한다. 5는 5분의 평균을 의미하며 60은 60분의 평균을 의미한다. 이 값은 1(분)부터 60(분)까지 범위를 가지며 0은 실시간(1초) 데이터를 의미한다.

SNMP에서는 동적으로 값이 바뀔 수 있는 항목에 대하여 Table구조를 사용한다. 예를 들어 “디스크 전체크기”는 디스크의 개수에 따라 제공하는 데이터 개수가 달라지기 때문에 Table구조를 사용하여 표현해야 한다. STON은 모든 가상호스트에 대하여 “분”단위 통계를 제공한다. 그러므로 [vhostMin] . [vhostIndex] 라는 다소 난해한 표현을 제공한다.

이 표현은 가상호스트별로 원하는 “분” 단위의 통계를 볼 수 있다는 장점을 가지고 있지만 변수가 2개이므로 Table구조로 표현하기 어렵다는 단점이 있다. 이런 문제를 극복하기 위하여 [vhostMin] 의 기본값을 설정하여 SNMPWalk가 동작할 수 있도록 한다.

활성화¶

전역설정(server.xml)을 통해 SNMP동작방식과 ACL을 설정한다.

# server.xml - <Server><Host>

<SNMP Port="161" Status="Inactive">
   <Allow>192.168.5.1</Allow>
   <Allow>192.168.6.0/24</Allow>
</SNMP>

• <SNMP> 속성을 통해 SNMP의 동작방식을 설정한다.

  • Port (기본: 161) SNMP 서비스 포트
  • Status (기본: Inactive) SNMP를 활성화 하려면 이 값을 Active 로 설정한다.

• <Allow> SNMP접근을 허가할 IP주소를 설정한다.

  IP지정, IP범위지정, 비트마스크, 서브넷 이상 네 가지 형식을 지원한다. 접속한 소켓이 허가된 IP가 아니면 응답을 주지 않는다.

가상호스트/View 변수¶

SNMP를 통해 제공되는 가상호스트/View 개수와 기본시간(분)을 설정한다.

# server.xml - <Server><Host>

<SNMP VHostCount=0, VHostMin=5 ViewCount=0, ViewMin=5 />

• VHostCount (기본: 0) 0일 경우 존재하는 가상호스트까지만 응답을 한다. 0보다 큰 값일 경우 가상호스트 존재 유무에 상관없이 설정된 가상호스트까지 응답한다.
• ViewCount (기본: 0) View에 적용. ( VHostCount 와 동일)
• VHostMin (기본: 5분, 최대: 60분) [vhostMin] 값을 설정한다. 0~60까지의 값을 가진다. 0일 경우 실시간 데이터를 제공하하며 1~60사이인 경우 해당 분만큼의 평균값을 제공한다.
• ViewMin (기본: 0) View에 적용. ( VHostMin 와 동일)

예를 들어 3개의 가상호스트가 설정되어 있는 환경에서 SNMPWalk의 동작방식이 달라진다.

• VHostCount=0인 경우

  SNMPv2-SMI::enterprises.40001.1.4.2.1.2.1 = STRING: "web.winesoft.co.kr"
  SNMPv2-SMI::enterprises.40001.1.4.2.1.2.2 = STRING: "img.winesoft.co.kr"
  SNMPv2-SMI::enterprises.40001.1.4.2.1.2.3 = STRING: "vod.winesoft.co.kr"
  

• VHostCount=5 경우

  SNMPv2-SMI::enterprises.40001.1.4.2.1.2.1 = STRING: "web.winesoft.co.kr"
  SNMPv2-SMI::enterprises.40001.1.4.2.1.2.2 = STRING: "img.winesoft.co.kr"
  SNMPv2-SMI::enterprises.40001.1.4.2.1.2.3 = STRING: "vod.winesoft.co.kr"
  SNMPv2-SMI::enterprises.40001.1.4.2.1.2.4 = ""
  SNMPv2-SMI::enterprises.40001.1.4.2.1.2.5 = ""
  

# server.xml - <Server><Host>

<SNMP GlobalMin="5" DiskMin="5" ConfCount="10" />

Community¶

Community를 설정하여 허가된 OID에만 접근/차단되도록 설정한다.

# server.xml - <Server><Host>

<SNMP UnregisteredCommunity="Allow">
   <Community Name="example1" OID="Allow">
      <OID>1.3.6.1.4.1.40001.1.4.1</OID>
      <OID>1.3.6.1.4.1.40001.1.4.2</OID>
      <OID>1.3.6.1.4.1.40001.1.4.4</OID>
   </Community>
   <Community Name="example2" OID="Deny">
      <OID>1.3.6.1.4.1.40001.1.4.3.1.11.11.10.1-61</OID>
   </Community>
</SNMP>

<SNMP> 의 UnregisteredCommunity 를 “Deny”로 설정하면 등록되지 않은 Community 요청은 차단한다.

• <Community> Community를 설정한다.
  • Name Community 이름.
  • OID (기본: Allow) 하위 <OID> 태그의 값을 설정한다. 속성 값이 Allow 라면 하위 <OID> 목록만 접근 가능하다. 반대로 속성 값이 Deny 라면 하위 <OID>목록에는 접근이 불가능하다.

명시적인 OID(1.3.6.1.4.1.40001.1.4.4)와 범위OID(1.3.6.1.4.1.40001.1.4.3.1.11.11.10.1-61) 표현이 가능하다. OID를 허용/차단할 경우 하위 모든 OID에 대해 같은 규칙이 적용된다.

meta¶

OID = 1.3.6.1.4.1.40001.1.1

메타정보를 제공한다.

OID = 1.3.6.1.4.1.40001.1.1.10

system¶

OID = 1.3.6.1.4.1.40001.1.2

STON이 동작하는 시스템 정보를 제공한다. [sysMin] 변수는 0~60분까지의 값을 가지며 실시간 또는 원하는 시간만큼의 평균 값을 제공한다. SNMPWalk에서 [sysMin] 은 0으로 설정되며 현재 정보를 제공한다.

OID = 1.3.6.1.4.1.40001.1.2.18.1

OID = 1.3.6.1.4.1.40001.1.2.19.1

global¶

OID = 1.3.6.1.4.1.40001.1.3

STON의 모든 모듈이 공통적으로 사용하는 자원정보(소켓, 이벤트 등)를 제공한다.

• ServerSocket

  클라이언트 ~ STON구간. STON이 클라이언트의 요청을 처리할 용도로 사용하는 소켓

• ClientSocket

  STON ~ 원본서버구간. STON이 원본서버로 요청을 보내는 용도로 사용하는 소켓

cache¶

OID = 1.3.6.1.4.1.40001.1.4

캐시 서비스의 통계는 가상호스트별로 상세하게 수집/제공된다.

OID = 1.3.6.1.4.1.40001.1.4.1

OID = 1.3.6.1.4.1.40001.1.4.1.10

OID = 1.3.6.1.4.1.40001.1.4.1.11

OID = 1.3.6.1.4.1.40001.1.4.1.11.10

OID = 1.3.6.1.4.1.40001.1.4.1.11.11