Facebook Joinc 그룹
Joinc QA 사이트
Tweet
joinc는 Firefox와 chrome에서 테스트 했습니다. IE에서는 테이블이 깨지거나 이미지가 보이지 않을 수 있습니다. 특히 구글 Docs이미지의 경우 엑박처리될 수 있습니다.
Tweet
joinc는 Firefox와 chrome에서 테스트 했습니다. IE에서는 테이블이 깨지거나 이미지가 보이지 않을 수 있습니다. 특히 구글 Docs이미지의 경우 엑박처리될 수 있습니다.
1 소개
QOS와 관련된 내용들을 다룬다. 개론적인 내용은 인터넷을 통해 어렵지 않게 찾아볼 수 있으나, 기술적인 내용은 찾아보기 힘든것 같다. QOS에 대한 기술적인 내용까지 다루려고 한다. 다음과 같은 내용들을 주로 다루게 될 것이다.
- SMS(시스템 관리)
- NMS(네트워크 관리)
- SMS, NMS를 위한 각종 툴
- Traffic control을 위한 기술적인 내용
- 보안
- QOS
- EcoSystem
- 주요 웹서비스 애플리케이션에 대한 품질 모니터링
2 QOS 소개
서비스의 품질을 향상시키기 위한 방법을 뜻한다. 일반적으로 QOS는 IP에서 서비스별 flow 흐름을 제어하는 것으로 알려지고 있다. 여기에서의 QOS는 인터넷 서비스 혹은 인터넷 플랫폼에서의 QOS를 의미한다.
3 인터넷 서비스를 위한 QOS
인터넷 서비스에서의 QOS는 이미 오래전부터 시행해오고 있었다. 서비스를 이루는 서버들의 SMS(시스템 정보), NMS(네트워크 정보)등을 이용해서, 서비스가 원할히 운영될 수 있더록 정보를 수집하는 것이 주요한 일이었다.
넓은 의미로 보자면, 시스템/네트워크 보안, 트래픽 관리까지를 아우르고, 여기에서 얻은 정보로 서비스에 대한 의사결정까지 가능한 정보를 주는 것을 QOS라 할 수 있겠지만 포탈 수준에서 이루어지는 대규모의 인터넷 서비스를 제외하고는 관리정보만 주는게 일반적이였다.
4 인터넷 플랫폼을 위한 QOS
4.1 인터넷 플랫폼의 등장
그러다가 web2.0(:12)이 등장하게 된다. web2.0은 팀 오라일리-O'Reilly-에 의해서 소개된 개념으로, 차세대 웹환경을 기술하고 있다. 이러한 요소들 중 하나가 인터넷 서비스에서 인터넷 플랫폼으로의 전환이다.
기존의 인터넷 서비스는 시스템위에서 작동이 되었다. 이 시스템은 회사가 전적으로 제어가능했으며, 서비스를 위한 소프트웨어, 데이터, 인터넷 자원 등을 포함하고 있었다. 인터넷 서비스는 기본적으로 독립된 하나의 점포로써의 기능을 수행했다. 포탈이라는 좀더 큰규모의 서비스가 이루어지기도 했지만, 포탈 역시 CP로 불리우는 인터넷 서비스 제공업자를 하나의 도메인에 모은 것에 지나지 않았다. 혹은 다른 서비스로 보내는 역할을 하는게 포탈 이었다.
오라일리는 인터넷 서비스의 단계를 지나서 인터넷 플랫폼의 시대가 올 것으로 예상을 했으며, 실제 적중 했다. 이제 인터넷 기업은 서비스를 제공하는 대신에, 플랫폼을 제공하게 되었다. 플랫폼을 이루는 요소는 다음과 같다.
- 가상 파일 시스템
- 거대 정보
- 분산 처리 시스템
- 검색 엔진
인터넷 플랫폼의 개념은 간단해 보이지만, 웹환경을 혁신 시켰다. google, eBay, Amazon 등, 현재 인터넷을 이끌어가는 기업들은 모두 인터넷 플랫폼을 제공하고 있다. Amazon의 경우에는 사용자 정보, 도서정보, 추천정보, 결재 시스템, 배송시스템과 이들의 정보를 처리하기 위한 정보처리 시스템으로 이루어진 플랫폼을 제공하고, 일반유저가 플랫폼의 자원에 접근할 수 있도록 Open API를 제공했다.
이제 인터넷 사용자는 사용자인 동시에, 서비스 제공자가 될 수 있다. 사용자는 아무런 자원없이도 Amazon의 방대한 데이터를 이용해서 간단하게 자신의 사이트에 온라인 서점을 개설할 수 있게 되었다. 일종의 온라인 분점이 생겨난 것이다. 이 온라인 분점에서 생겨난 이익은 Amazon과 나눠 가지게 된다. 실제 Amazon이 벌어들이는 금액의 거의 60%정도를 이들 서비스 분점에서 벌어들이고 있다. eBay 역시 Amazon과 마찬가지로 누구나 경매 서비스를 할 수 있도록 하고 있으며, google는 자신의 검색엔진과 색인정보, 데이터 처리기술에 접근할 수 있는 API를 유저에게 제공함으로써, 애드센스와 같은 광고서비스가 가능하도록 하고 있다.
4.2 QOS의 재조명
인터넷 플랫폼은 그 복잡성 때문에, 인터넷 서비스와는 다른 수준의 QOS를 요구하고 있다. 실제 인터넷 플랫폼에서의 QOS 문제는 서비스때와는 달리 심각해질 수 있기 때문이다.
구글의 경우 Ajax Search API를 이용해서, 누구든지 간단하게 자신만의 검색서비스를 구축할 수 있도록 하고 있다. 만약 검색플랫폼에 문제가 생겨서, 서비스 호출에 제대로 반응하지 못하면 어떤일이 벌어지게 될까. 실제 이런일이 벌어졌었는데, 거의 하루 동안 구글검색창을 달고 있던 페이지 자체가 로딩안되는 사건이 있었다. 필자역시 이런일을 겪었었고, 어쩔 수 없이 구글 검색창을 주석처리해서 서비스했던 적이있다.
구글의 경우에는 이런류의 Open 검색시장에서 독점적인 데다가 초기라서 유저가 그나마 눈감아 줬었지만, 만약 경쟁체제에 놓여있었다면 회사의 이미지, 신뢰도, 영향력에서 엄청난 비용을 지불해야 했었을 것이다.
인터넷 서비스였다면, 그냥 2중화 시키면 끝이다. 최악의 경우에라도 한 10분정도 서비스 중지시키고 리붓시키면 되며, 문제는 서비스 영역으로 방문하는 유저에게만 인지할 수 있었을 것이다.
이때문에 QOS의 중요성과 활용범위가 재조명되고 있다.
5 EcoSystem
지금까지의 인터넷 플렛폼 에서의 QOS의 필요성에 대해서 간단히 언급해 보았다. 여기에서는 Eco System과 함께 좀더 폭넓게 다루어보도록 하겠다.
5.1 EcoSystem에 대해서
EcoSystem 은 생태계를 의미한다. 생태계는 크게 3가지 요소로 이루어진다.
- 토양 : 생태계에 필요한 양분을 제공한다.
- 객체 : 식물, 동물등 토양의 에너지를 이용해서 살아나가는 객체
- 먹이사슬 : 에너지가 이동하는 순환과정
또한 생태계에 대한 많은 연구가 진행되고 있기도 하다. 최근들어 이러한 생태계에 대한 고찰을 컴퓨팅 환경에도 적용시키려는 시도가 이루어지고 있다. 사실은 꽤 오래전부터 진행되고 있었으나, EcoSystem을 적용시킬 만큼 컴퓨팅 환경이 복잡하지는 않았기 때문에, 그리 부각 되지 않았었다.
그러다가 지구규모의 네트워크와 지구규모의 데어터를 다루어야 하는 Web2.0 시대가 되면서, 네트워크 컴퓨팅 환경에서의 EcoSystem이 주목받게 되었다.
5.2 플랫폼에서의 Eco System
Web2.0으로 넘어오면서 플랫폼을 가지느냐 그렇지 않느냐가 기업생존에 중요한 요인이 되면서, 플랫폼을 관리해야할 필요성을 가지게 된다.
플랫폼에서의 Eco System도 생태계와 매우 비슷한 요소들로 구성된다. - 이하 Eco System은 플랫폼에서의 Eco System -
- Data
EcoSystem의 양분으로 토양의 역할을 한다. 건강하고 다양한 EcoSystem을 만들기 위해서는 토양이라고 할 수 있는, 양질의 데이터가 충분히 존재하고 있어야 한다. 각 포탈들이 양질의 데이터를 확보하기 위해서 기를 쓰는 이유이기도 하다.
- Service
Data를 양분으로 해서 Service가 만들어진다. 기존 웹서비스 시대의 서비스와 틀린점이라면, 기업이 자신의 서비스를 직접제어했었다면 플랫폼 기반에서는 User Service와 기업이 만든 Service와의 차이점이 없다는 것이다. 일반 유저도 MashUp, OpenAPI, OpenID 등을 이용해서 Data를 직접 Access해서 Service를 만들 수 있다.
- flow
EcoSystem에서 Data와 Service의 이동은 flow를 통해서 이루어진다. traffic이다. 생태계관점에서 보자면 먹이사슬을 위한 에너지의 순환이 가능하도록 해주는 요소다.
5.3 EcoSystem 과 QOS
EcoSystem이 만들어지는 최종 목적은 신뢰성, 견고함을 가진 양질의 서비스를 제공하기 위함이다. QoS는 튼튼하고 다양한 EcoSystem을 만드는게 그 목적이라고 할 수 있다.
EcoSystem은 자체적으로 복잡성을 가지고 있다. 이러한 복잡성을 관리하고 예측하는 것은 매우 힘든일이 될 수 있다. 어떤 Mashup 서비스를 만든다고 가정을 해보자. 이 서비스가 추가되었을때, 생태계(EcoSystem)에 끼치는 영향을 예측할 수 있어야 한다. 추가된 서비스로 인하여 EcoSystem에 무리가 온다면, 다른 서비스들의 품질까지 떨어질 수 있을 것이다. 또한 EcoSystem이 건전하게 운용되기 위해서는 위험징후를 미리 판단해서, 위험요소를 없애야 할 것이다.
QOS는 Eco System의 복잡성을 관리하고, 예측하며, 위험징후를 찾아내어서 양질의 서비스가 가능하도록 하는 복합적인 프로세스다.
6 QOS의 관리 요소
EcoSystem의 관점에서 QOS를 위해서는 다음과 같은 관리 요소가 있을 것이다.
내가 다룰 수 있는 범위를 초과하기 때문에, 윈도우즈 환경은 고려하지 않도록 하겠다. 리눅스 환경을 기준으로 설명을 할 것이다.
- System health
EcoSystem을 이루는 객체는 Service다. 일차적으로 이들 서비스의 health가 관리될 필요가 있다. 자연 생태계관리에 있어서 가장 우선시 되는 것 중에 하나가 계를 이루는 동/식물의 건강을 체크하는 것과 마찬가지다.
이러한 행위는 SMS차원에서 기존에도 행해지고 있다. 이것을 Eco System에 맞도록 최적화/확장 시켜야 할 것이다.
- flow (traffic)
Eco System에 새로운 서비스가 추가되면, System 전체에 크건 작건간에 변화를 가져오게 된다. 이러한 변화는 서비스들간의 에너지의 흐름 즉 traffic의 변화로 나타난다.
간단히 생각하자면 NMS라고 볼 수도 있지만, 주로 SNMP에 의존하는 NMS와는 차원이 다르다.
서비스들간의 트래픽 흐름, 서비스의 트래픽 변화 추이, 트래픽의 변화에 따른 연결시간, 응답시간의 변화, 분산시스템이 작동중이다라면, 트래픽이 제대로 분산되고 있는지 등등의 한단계 높은 정보들이 필요로 된다.
- 보안
생태계를 위협할 수 있는 여러 요소들이 있다. 가능하면 문제가 발생하기 전에, 징후를 감지해 낼 수 있는 시스템이 구축되어 있어야 한다. 문제가 발생했다면, 문제원인을 최대한 빨리 찾아내어서, 해결할 수 있어야 한다.
- Client와 웹서버 간의 응답시간, 응답성공률, 가동율, 트래픽의 갑작스런 증감
- 웹서버와 검색시스템 간의 응답시간, 응답성공률
- 검색시스템 내에서의 트래픽 흐름
- 분산검색 시스템이라면, 제대로 분산이 이루어지고 있는지
- 시간지연이 발생한다면 어느 부분에서 발생하는지
- 분산검색 시스템이라면, 제대로 분산이 이루어지고 있는지
- 각 장비들의 상태 : CPU, MEMORY, PROCESS, Disk Usage, Disk IO, Interface In/Out Error, Drop, Cols...
- Client의 Traffic 증감에 따른 검색시스템의 변화
- 가장 기본은 웹서버와 검색시스템이 작동하고 있는지 확인하는 것이다.
- Traffic 분석을 통한 확인
- 서비스 체크 프로그램을 이용한 확인 : 예전부터 간단하게 사용되었던 방법이다. 체크 프로그램을 탑재한 별도의 프로그램을 둔다음 해당 서비스에 직접 연결해서 결과를 확인하는 방법이다. 실제 유저입장에서의 서비스 상황을 확인할 수는 없지만, 간단하게 사용할 수 있다.
- 위의 2가지 방법을 함께 사용할 수 있을 것이다.
- Traffic 분석을 통한 확인
7 기술적인 측면
과거에는 강력한 몇대의 컴퓨터와 이들의 파워를 가능한 끌어낼 수 있는 운영체제가 함께 움직이는 경우가 많았다. 하지만 플랫폼기반의 EcoSystem 에서는 비교적 저렴하고 덜 강력한 다수의 컴퓨터를 이용해서 컴퓨팅 환경을 만들어나가야 한다. 많은 수의 덜 강력한 컴퓨터를 운영해야 한다면, 어느정도의 신뢰성을 가진 저렴하고 유연한 운영체제로 통일하는게 여러모로 도움이 된다. 관리해야될 컴퓨터도 많은데다가 플랫폼의 특성상 다양한 실험과 시도가 가능해야 한다. 여기에 비싼 비용을 지불해야 하며, 거기에 유연하지 못한 운영체제와 프로그램으로 구성을 하려고 했다가는 경직된 플랫폼 환경이 될 수 있다.
플랫폼 환경으로 넘어가면서 Linux운영체제를 포함한 공개소프트웨어의 위상이 크게 높아질 것으로 생각된다. Web2.0은 오픈소스를 위한 세계 참고.
7.1 시스템 Health 체크
QoS의 가장 기본이 될 것이다. EcoSystem을 이루고 있는 최소단위가 시스템이기 때문이다. 이 분야는 SMS영역으로, 꽤나 오랜역사를 가지고 있다. 그런 관계로 상당히 많은 자료들과 활용가능한 믿음직한공개 라이브러리와 프로그램들이 존재한다.
아마 가장 널리 사용되는 프로그램은 SNMP프로토콜을 사용하는 net-snmp와 같은 공개 소프트웨어일 것이다. 오랜 역사를 가졌고, 견고한 프로그램이긴 하지만 공개 프로젝트 산물들이 그렇듯이, 범용성을 강조하다 보니 지나치게 무거우며, 소스의 양이 방대하다는 단점을 가진다. 공개소프트웨어이기 때문에, 쉽게 유지보수 할 수 있을 거라고 생각할 수 있지만 절대로 그렇지 않다. Agent의 기능을 SNMP에 전적으로 맡긴다고 하더라도, Manager를 만드는 것은 결코 쉬운일이 아니다. 여기에 플랫폼의 특수성에 의한 새로운 요구사항이 생기면, 익숙하지도 않은 방대한 양의 소스를 학습해야 하는 문제도 발생한다.
그럴바에는 어느정도의 능력을 가진 개발자를 확보해서 별도의 SMS를 만드는게 더 낳다는게 개인적인 생각이다.
리눅스 시스템의 경우 proc 파일시스템에서 워낙에 방대한 시스템 데이터를 제공하는 관계로, 리눅스 시스템에 대한 어느정도의 이해를 가지고 있다면 의외로 쉽게 SMS 시스템을 개발할 수 있다.
proc 파일시스템을 이용한 리눅스 시스템 분석은 다음의 문서들을 참고하기 바란다. net-snmp로 얻을 수 있는 이상의 정보를 얻을 수 있을 것이다.
이름 | 제목 | 변경일 | 크기 | |
 | Proc filesystem를 이용한 시스템 정보 수집
| 2007/01/29 16:08 | 33994 | |
| ps 프로그램 만들기
| 2007/01/09 11:46 | 23324 | |
| sms 프로그램 만들기 프로젝트
| 2008/07/02 20:43 | 25614 | |
| netstate 정보 얻어오기
| 2010/01/25 13:39 | 7743 | |
| Proc 파일시스템 프로그래밍
| 2007/01/09 11:46 | 26602 | |
| 프로세스 검사하기
| 2007/01/09 11:46 | 15655 |
7.2 Traffic 분석
역시 SNMP 응용 프로그램으로 처리할 수 있을 거라고 생각할 수 있을 것이다. 그러나 SNMP는 전체 트래픽의 대략적인 상황만 보여줄 수 있을 뿐으로, EcoSystem 내에서의 각 객체(서비스)간의 흐름을 보여줄수는 없다. 예를 들자면 다음과 같은 것들이다.
yundream은 이중 패킷을 직접 Capture 해서 분석하는 방법에 대해서 알아볼 것이다.
- 다양한 서비스들에 대한 연결시간과 응답시간
- 서비스별 트래픽의 양 (bps/pps)
- 서비스별 연결 성공률및 응답성공률
- 분산시스템이라면, 분산시스템이 이용하는 서비스들의 트래픽이 제대로 분산되고 있는지
- 새로운 MashUp 서비스가 추가되었다. 서비스 추가에 따른 트래픽 유입량, 트래픽 유입 도메인영역, EcoSystem에 미치는 영향
- 여기에 위의 정보들의 추이를 확인할 수 있어야 한다.
- 트래픽에 대한 분석이 되면, DOS, DDOS, half connection, WARM 공격과 같은 위험징후도 사전에 감지할 수 있을 것이다.
- collision 분석 - 패킷의 크기가 작아서, 실제 트래픽양은 얼마되지 않지만 계속적인 collision이 발생 -
yundream은 이중 패킷을 직접 Capture 해서 분석하는 방법에 대해서 알아볼 것이다.
패킷 캡춰 라이브러리로는 유명한 libpcap이 있다. libpcap은 tcpdump와 같은 간단한 트래픽 분석도구에서 부터, snort와 같은 거대한 공개소프트웨어와 상용 IDS에서 사용하는 효율적인 패킷 캡춰 라이브러리다. 이 라이브러리를 이용해서 패킷을 캡춰한다음에, 분석하기 좋게 효과적으로 정규화 시켜서 DB에 저장할 수 있다면, 위의 예로든 모든 일들이 가능한 트래픽 분석 프로그램을 만들 수 있을 것이다.
이러한 트래픽 분석 프로그램을 만드는 것은, 그 자체가 커다란 프로젝트 이므로 여기에서는 아이디어와 가능성만을 제시하도록 하겠다. 아래는 libpcap을 이용해서 트래픽을 분석하는 방법을 담고 있는 문서들이다.
- libpcap을 이용한 프로그래밍
- libpcap을 이용한 Port Scaning 검사툴
- libpcap을 이용한 DOS 공격 검사툴
- 네트워크 트래픽 분석을 통한 connection time 얻어오기
- Mirror Port
대부분의 Switch들이 Mirror Port 기능을 지원한다. 이 기능을 이용하면, 특정 포트의 트래픽을 다른 포트로 보낼 수 있다. 간단하게 사용할 수 있지만 VLAN으로 구성되어 있는 환경에 적용하기 힘들며, 제품에 따라서 Layer7 까지를 커버하기 힘들다는 문제점이 있다. 여기에 Switch 자체의 성능을 떨어트릴수 있다는 결정적인 문제점을 가지니다.
- Network Tap
7.3 보안
8 표준 관리도구
이름 | 제목 | 변경일 | 크기 | |
| TCP/IP 관리 툴
| 2007/08/10 21:38 | 4679 |
9 모니터링 툴
이름 | 제목 | 변경일 | 크기 | |
| zenoss + wiki + ticket 을 이용한 시스템 및 이력관리 시스템
| 2008/01/14 19:57 | 7973 | |
| 공개 시스템 모니터링 툴 zabbix
| 2007/07/26 11:13 | 2362 | |
 | Enterprise Management System - Zenoss
| 2007/08/16 22:14 | 103 |
10 DB 관리 / 애플리케이션
이름 | 제목 | 변경일 | 크기 | |
| Mysql 품질 관리 - Alive 체크
| 2007/07/23 09:38 | 4570 | |
| Mysql 품질관리 : Admin 정보
| 2007/08/10 18:44 | 5445 | |
| Mysql Query 실행하기
| 2007/08/16 21:31 | 65 |
11 시스템 관리
이름 | 제목 | 변경일 | 크기 | |
| QOS - CPU 사용율 모니터링
| 2007/07/24 00:12 | 8133 | |
| 디스크 사용량 모니터링
| 2007/07/25 22:54 | 64 | |
| Google Disk Failure Experience
| 2008/07/08 00:05 | 96 | |
| 시스템 최적화를 위한 리눅스 커널 인자 변경하기
| 2007/08/16 22:32 | 104 | |
| 시스템 관리 포인트 : 데이터는 도처에 널려있다.
| 2008/03/10 15:22 | 3811 | |
| 시스템 모니터링
| 2007/07/25 22:57 | 56 |