DBMS/오라클]프로시저 대신 패키지를 써야 하는 이유

출처 : http://mt1716.egloos.com/9176977

프로 시저 대신 패키지를 써야 하는 이유

오라클 패키지의 마법을 풀어봅시다 - 프로시저 대신 패키지를 써야 하는 이유

Advanced Oracle 2007/07/29 02:00

많은 오라클 전문가들이 프로시저대신 패키지를 사용할 것을 권장한다. 특히 패키지를 만든 오라클 사람들이...

하지만, 왜 그럴까? 많은 사람들이 이 사실을 모르고, 심지어 프로시저를 사용하면 되는데 패키지가 무슨 필요? 라며 잘못된 견해를 전파한다.

프로시저가 아닌패키지를 사용해야 하는 이유는, 결론부터 말하면 패키지의 향상된 의존성(Dependency)관리때문이다.

아래 간단한 패키지와 프로시저가 있다. 이 둘의 기능(하는 일)은 완전히 동일하다. 다만 하나는 패키지로 구현되어 있고, 다른 하나의 프로시저로 구현되어 있을 뿐이다.

-- 패키지

create or replace package pkgtest as
procedure pkgtest_proc(v_id int);
end pkgtest;
/

create or replace package body pkgtest as
procedure pkgtest_proc(v_id int)
is
v_name varchar2(1);
begin
select name into v_name from pkgtest_table;
end;
end pkgtest;
/

-- 프로시저

create or replace procedure nopkg_proc(v_id int)
is
v_name varchar2(1);
begin
select name into v_name from pkgtest_table;
end;
/

여기서 주목해야 할 것은 pkgtest 패키지와 nopkg_proc 프로시저가 모두 pkgtest_table에 대해 의존성(Dependency)를 가지고 있다는 사실이다. 여기에서 간혹 심각한 문제가 발생한다.

Pkgtest_table에 대해 DDL을 수행하게 되면 이 테이블을 참조하고 있는 모든 객체에 대해 무효화(Invalidation)가 수행된다.아래 스크립트를 보자

-- pkgtest_table에 대해 의존성을 가지는 패키지와 프로시저가 Valid 상태이다.

SQL> select object_name,object_type, status
from dba_objects where object_name in ('PKGTEST', 'NOPKG_PROC');

OBJECT_NAM OBJECT_TYPE STATUS
---------- -------------------- --------------
NOPKG_PROCPROCEDURE VALID
PKGTEST PACKAGE VALID
PKGTEST PACKAGE BODYVALID

-- Pkgtest_table에 대해 Alter를 수행하면?

SQL> alter table pkgtest_table add name2 varchar(1);

OBJECT_NAMOBJECT_TYPE STATUS
------------------------------ --------------
NOPKG_PROCPROCEDURE INVALID
PKGTEST PACKAGE VALID
PKGTESTPACKAGE BODYINVALID

위의 결과에서 다음과 같은 재밌는 사실을 발견할 수 있다.

• NOPKG_PROC 프로시저는 기대했던 대로 INVALID 상태가 되었음을 알 수 있다.
• PKGTEST 패키지는 좀 특이한다.
  • PKGTEST 패키지 바디(body)기대했던 대로 INVALID 상태가 되었음을 알 수 있다.
  • 반면 PKGTEST 패키지 자체는 놀랍게도 여전히 VALID 상태이다.

패 키지의 이러한 특징을 가리켜 흔히 "패키지는 의존성 체인을 깬다"라는 표현을 사용한다. 위의 예를 들면 pkgtest_table이 변경됨으로써 pkgtest 패키지가 무효화될 위기임에도 불구하고 중간에 패키지 바디라는 중간 객체만이 무효화되고 패키지 자체는 무효화되지 않는다.

이 패키지의 특정, 즉 의존성 체인을 깨는 특징이 왜 그렇게 중요할까? 그 이유는 하드 파싱과 관련이 있다.

만일 수십 개의 프로시저가 이 pkgtest_table에 대해 의존성을 가지는 상태에서 운영상의 이유로 pkgtest_table을 Alter했다고 가정해보자. 이 수십 개의 프로시저가 모두 INVALID 상태가 될 것이고, 따라서 이 프로시저들을 수행하는 모든 쿼리는 재컴파일이 이루어져 한다. 붐~! 아마 library cache pin이라는 이름의 대기 현상의 증가하면서 자칫 시스템 장애를 불러일으킬 수 있다.

하지만 프로시저가 아닌 패키지로 되어 있었다면? 다행히 패키지 자체는 여전히 VALID 상태이이 때문에 이 패키지들을 사용하는 모든 쿼리 또한 재사용이 가능하 다. 실행 시점에 패키지 바디만 리컴파일해주면 된다. 옙!! 여러분은 방금 시스템 장애로부터 사장님을 구한 셈이다.

이것을 증명하기 위해 pkgtest_table을 Alter한 후, 다음과 같이 패키지와 프로시저의 수행 결과를 SQL Trace를 이용해 분석해보자.

-- 패키지를 참고하는 쿼리 문장은 하드 파싱을 수행하지 않는다.(즉, Library cache Miss가 발생하지 않으며 리컴파일또한 수행하지 않는다)

BEGIN pkgtest.pkgtest_proc(1); END;

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.01 0.01 0 0 1 1
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 2 0.01 0.01 0 0 1 1

Misses in library cache during parse: 0 <-- 여기를 주목하세요!!Optimizer mode: ALL_ROWS
Parsing user id: 55

-- 하지만 프리시저를 사용하는 하드파싱을 수행한다.(즉, Library cache miss가 발생하고 리컴파일을 수행한다)
BEGIN nopkg_proc(1); END;

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.01 0.01 0 0 1 0
Execute 1 0.00 0.00 0 0 0 1
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 2 0.01 0.01 0 0 1 1

Misses in library cache during parse: 1 <-- 여기를 주목. 모든 악의 근원!!!Optimizer mode: ALL_ROWS
Parsing user id: 55

왜 오라클이 굳이 패키지라는 복잡한 개념을 구현했는지 이해가 되는가? 프로그래밍의 간편함과 더불어 쿼리 재사용성 증가라는 탁월한 효과를 얻을 수 있기 때문이다.

이제 입질이 슬슬 오는가...?

PS)

SQL Server 2005 에서는 Statement Level의 Recompile을 지원함으로써 오라클의 패키지와 동일한 효과를 제공한다. 자세한 내용은 나중에...

하드파싱(리컴파일)에 의한 library cache pin 대기 현상에 대해서는 아래 필자의 책 참고~~

펜슬 툴을 이용한 이미지 오려내기

 1. 포토샵의 우측하단의 레이어가 있는 부분에서 Path를 선택한후 path를 하나 생성한다.

2. 펜슬 툴을 사용하여 원하는 부분의 이미지를 선택한다.

   이때 곡선 부분을 선택시에는 원하는 지점을 펜슬로 선택후 드래그를 하면서 원하는 곡선을 찾는다.

   그 후에 alt키를 누른 상태로 가운데 점을 눌러 진행방향으로의 작업을 계속 할 수 있게 한다.

3. 이미지를 다 선택한후 CTRL키를 누른 상태로 생성된 path를 마우스로 선택한다.

4. 원하는 크기의 캔버스를 생성하고, 오려낸 이미지를 선택후 생성된 캔버스로 이동하면 새로운 이미지가

생성된다.

특정 크기로 이미지 자르기

포토샵에서 특정한 크기로 이미지를 잘라야 하는 경우에 사용.

1. marquee tool 을 선택한다. (왼쪽에 툴 박스에서 보면 점선으로 이루어진 사각형)

2. 메뉴 바 밑에있는 Toolbar의 우측 부분에 style 이 있다.

3. style클릭 -> fixed size선택

4. 자르기를 원하는 크기의 가로/세로를 입력한다. (width : 가로 크기, height:세로크기)

5. 그 후에 화면에 있는 이미지를 클릭한다.

6. 화면에 점선 모양으로 입력한 크기의 사각형이 보인다.

7. 자르길 원하는 부분에 사각형을 옮겨 놓는다.

8. 이미지 메뉴 클릭

9. crop 선택

10. "File" 메뉴를 선택 -> "Save as for web"-> .gif 형식으로 이미지 저장한다.

이미지의 밝기 및 선명도 조절

포토샵에서 이미지의 선명도 및 밝기를 조절하기 위한 방법을 소개한다.

         

예를 들어 원본이미지가 어두워서 사물이나 인물의 분간이 어려운 경우에



1. 포토샵 메뉴중 image -> adjustments-> levels...

    에서 화면에 나타난 그래프를 이용하여 밝기 및 선명도등의 조절이 가능



2. 포토샵 메뉴중 image -> adjustments-> Brightness/Contrast...

    에서 화면에서 밝기및 선명도 조정이 가능



3. 포토샵 메뉴중 image -> adjustments-> Hues/Saturations...

    에서 화면에서 밝기및 선명도 조정이 가능

배경의 색상 복사하여 이전이미지 변경하기

 배경과 글씨가 있는 임의의 이미지 파일이 있는데 이 이미지를 변경하고자 하는 경우에 배경은 그대로 두고

글씨를 없앤 후 원하는 글씨로 변경하려고 할때 사용할 수 있는 간단한 팁입니다.



 1. 사각형 오려내기 툴을 선택

 2. 원하는 배경색상의 일정부분을 선택

 3. 선택툴을 선택(화살표와 x표가 같이 있는 모양)

 4. Alt+shift 키를 누르고 마우스 포인터로 선택된 부분을 원하는 위치에 옮긴다.

 5. 글씨가 지워질때까지 4번작업을 반복하면 글씨가 지원집니다.
         

Network] 오픈소스 트레픽 테스트 툴] 시즈(Siege) 사용하기

많은 웹개발자들과 서버 관리자들이 가장 두려워하는 것은 엄청난 트래픽 때문에 웹사이트가 다운되는 사태다. 트래픽 폭주의 원인은 DoS 공격 등 여러가지가 있지만 분명한 것은 더이상 웹사이트를 사용할 수 없도록 만든다는 사실이다.

이런 필요 때문에 등장한 것이 바로 부하 테스트 툴이다. 사이트가 어떤 트래픽 수준에서 다운되는 지를 테스트하는 소프트웨어로, 이미 좋은 툴들이 많이 출시돼 있다. ‘WAPT’라는 상용 소프트웨어는 Builder.com에 서 리뷰하기도 했다. 필자는 무료로 사용할 수 있는 오픈소스 툴을 선호하는데, 오픈소스 부하 테스트 툴 가운데 가장 널리 사용되며 꾸준히 업데이트되는 소프트웨어로는, 이름과도 잘 어울리는 ‘시즈(Siege, 포위공격)’가 있다.

시즈의 특징
‘시 즈’라는 이름은 이 툴의 모든 것을 말한다. 서버를 에워싸 서버가 어떤 이유로 문제를 일으켰는지를 보여주는 것이다. 유닉스 기반의 명령행 기반 툴인 시즈는 GNU GPL 오픈소스 라이선스를 따르기 때문에 사용, 수정, 배포가 모두 무료다.

시즈는 단일 URL의 부하 테스트는 물론 많은 URL을 메모리로 불러들여 사용자가 설정한 시뮬레이션 유저만큼의 부하를 동시에 테스트할 수 있다. 또한 기록된 총히트수와 전송된 바이트수, 반응시간, 병행성(Concurrency), 리턴 상태 등을 보여주며, HTTP 1.0/1.1 프로토콜, GET/POST 디렉티브, 쿠키, 트랜잭션 로깅, 기본적인 인증 등을 지원한다.

1. 다운로드와설치

시 즈 최신버전은 Builder.com 다운로드 사이트에 서 받을 수 있다. 설치는 GNU 오토콘프(autoconf)를 사용해 유닉스 애플리케이션용 컴파일 절차를 따른다. 표준 ANSI C 컴파일러(대부분의 기본 *nix 인스톨의 일부)를 지원하는 최근의 리눅스 시스템이나 다른 *nix 시스템 환경이라면 설치는 매우 간단하다. 먼저 다운로드한 파일의 tar 압축을 다음과 같이 해제한다.

$ tar xvzf siege-latest.tar.gz

이제 다음과 같이 설정한다(디폴트 설정을 추천한다).

$ ./configure

설정에 대한 도움말은 -help 서픽스(suffix)를 이용하면 된다. 필자가 개인적으로 추가한 것은 SSL 지원으로, ‘-with-ssl=/usr/local/ssl’ 서픽스를 통하면 된다. 여기까지 마쳤으면 이제 남은 것은 다음과 같이 컴파일해 설치하는 것이다.

$ make $ make install

2. 실행하기

시 즈는 웹서버를 테스트하는 다양한 옵션을 제공한다. 가장 간편한 실행 방법은 단일 URL 테스트다. 이것은 특정 페이지가 대량 트래픽에 어떻게 반응하는지를 잘 보여준다. 이때 중요한 옵션 두 가지가 동시 접속자수(-c 옵션, 디폴트는 10)와, 반복 쿼리수 혹은 시간으로 표현되는 테스트 기간(-t)이다. 예를 들어 25명이 동시에 1분간 접속하는 환경이라면 다음과 같이 실행하면 된다

$ siege -c25 -t1M www.example.com

이밖에도 딜레이를 설정하는 -v와 -d 옵션을 자주 사용하는데 기본값은 0 이다

3. 분석결과

여기까지 실행했다면 시즈는 당신의 코드와 서버가 대량 트래픽에 어떻게 반응했는지를 알려준다. 다음은 위의 명령을 실행했을 때의 결과 화면이다.

** Siege 2.59 ** Preparing 25 concurrent users for battle. The server is now under siege... Lifting the server siege... done. Transactions: 406 hits Availability: 99.75 % Elapsed time: 59.66 secs Data transferred: 10340918 bytes Response time: 2.36 secs Transaction rate: 6.81 trans/sec Throughput: 173330.84 bytes/sec Concurrency: 16.07 Successful transactions: 412 Failed transactions: 1

가용성(Availability)은 가장 중요한 요소인데 이것이 100%에 미달했다는 것은 사용자 중의 일부가 사이트에 접속하지 못했다는 것을 의미한다. 따라서 위의 실행결과는 문제가 된다. 1분에 25명이 접속했을 때 가용성이 99.75%에 불과했기 때문이다.

병행성 (Concurrency)은 각 트랜잭션 처리 시간을 경과시간으로 나눈 것이다(이때 트랜잭션이란 모든 인증시도를 포함한 서버의 히트수다). 이를 통해 평균 동시 접속 수준을 알 수 있는데, 병행성이 높을수록 서버가 어려움에 봉착했음을 암시한다. 그 이유는 새로운 트래픽 처리를 위해 소켓을 열어야 하는 상황에서, 서버가 한 트랜잭션을 완료하는데 걸리는 시간이 길면 길수록, 동시에 처리해야 할 트래픽이 많아져 서버 성능이 떨어지기 때문이다.

4. 고급기능

필자가 시즈 초기버전을 사용했을 때는, 서버에 준 부하에 성공과 실패가 서로 뒤섞여 있었다. 단순히 동시 접속자와 테스트 시간을 늘려 결과를 살펴보는 정도였다. 그러나 시즈 최신버전에는 봄바드먼트(Bombardment)라는 툴이 포함돼 있어, 명령어 옵션으로 클라이언트 숫자를 증가시킬 수 있다. 그러나 봄바드먼트(Bombardment)는 버보스(verbose) 출력이나 로깅 기능 등 시즈가 기본적으로 지원하는 사용자 옵션이 없어 제대로 실행되지 않는 단점이 있다.

적당한 회귀 테스팅도 단일 URL 이상에서만 가능하다. 시즈는 과거에 ‘스카우트(Scout)’라는 툴을 이용해, 특정 도메인에서 URL들을 추출한 후 이를 시즈 테스트 목록에 포함시키는 기능을 지원했었다. 현재 스카우트는 더 이상 업데이트되지 않지만 이전 버전은 다운로드해 사용할 수는 있다.

시즈 최신 버전에는 스카우트 대신 새로운 테스팅용 URL 추출기인 ‘스프록시(Sproxy)’가 포함돼 있다. 그러나 필자는 개인적으로 스카우트에 더 후한 점수를 주고 싶다. 스프록시는 옵션을 사용자 브라우저 프록시로 설정하면, 사용자가 방문한 모드 사이트의 링크를 테스트 목록에 추가하기 때문이다. 유일한 추가 옵션은 수동으로 모든 URL을 입력하는 것이다.

시즈는 사이트내에 존재하는 모든 GET/POST, 인증, 쿠키에 대한 부하 테스트를 할 수 있으며, 사용자는 단지 URL을 입력하거나 스프록시나 스카우트 등의 툴을 이용하면 된다. 다수 URL에 -i 옵션을 사용하면 동시 쓰레드 방식으로 URL을 난수화해 보다 실제에 가까운 테스트도 할 수 있다.

5. 가용성가 방응시간 개선방법

시즈는 URL 부하를 테스트하는 간단한 툴일 뿐이다. 따라서 가용성과 반응시간 등을 개선하기 위해서는 이를 결정하는 두 가지 요소, 즉 네트워크적인 요인과 웹 개발자에 의해 좌우되는 웹페이지의 요소들을 살펴봐야 한다.

먼저 네트워크 측면을 보면 호스트 웹서버의 대역폭(처리 능력)과 메모리가 가장 중요하다. 로드 밸런스 환경이라면 호스트 웹서버 대신 서버가 된다. 웹페이지 부분에서는 코드를 효율적으로 개발하는 만큼, 이론적으로는 파일 크기가 작아지기 때문에, 네트워크 자원의 낭비도 줄일 수 있다.

6. 참고사이트

시즈를 받을 수 있는 홈페이지 - http://Builder.com

Network] MRTG를 이용한 트래픽사용량 분석하기

MRTG를 이용한 트래픽사용량 분석하기

 
1. 서버트래픽분석 개론

MRTG에서 서버트래픽을 모니터링하기위해서는 cfg파일을 만들어야한다.

cfg파일을 만드는 방법은 두가기가 있다.

• 첫째, cfgmaker로 만드는 방법
• 둘째, 가장유사한 cfg파일 복사후 수정하는 방법

위의 두가지 방법모두 실무에서 사용되고 있는 방법이다.

굳이 구분해 본다면 첫 번째의 경우에는 MRTG서버를 처음구축한후에 이미 사용중인 cfg파일이 존재하지 않으므로 환경파일생성툴인 cfgmaker를 이용하여 생성하는 방법이다.

즉, MRTG 서버구축초기에 많이 사용되는 방법이며 이방법으로 생성된 cfg파일을 살펴보면 불필요한 내용이 많이 추가되어 있음을 알 수 있다.

두 번째 방법은 MRTG서버를 어느정도 사용하다 보면 생성된 cfg파일이 여러개 존재하게 된다.

새로운 서버의 트래픽사용량이나 자원들(CPU, DISK, MEMORY)의 사용량을 모니터링하기위해서는 새로운 cfg파일이 필요하게 된다.

이때에 이미 사용중인 cfg파일중 가장 유사한 파일을 복사한 후 그 내용을 조금만 수정해 주면 사용이 가능하다.

필자의 경험에 의한다면 MRTG를 처음 사용하는 분이라면 첫 번째 방법을 사용하고, MRTG를 사용중인 분이라면 두 번째 방법으로 cfg파일을 생성하는 것이 일반적이지 않나 생각한다.

다만 여기에서는 앞서 cfgmaker로 환경파일(cfg)을 생성하는 방법에 대해서 배웠으므로 그 사용법을 다시 언급한다는 것은 무의미하므로 두 번째의 방법으로 이미 cfg파일을 생성했다는 가정하에게 설명을 계속진행해 나갈 것이다.

뒤에 나오는 DISK, CPU, MEMORY의 사용량분석의 경우에도 모두 동일하게 적용이 된다.

2. Configuration file 만들기

현재 실습중인 대상장비는 리눅스 서버이다.

이 리눅스서버의 트래픽을 분석하기 위한 cfg파일을 직접 만들어서 보여주고 있다.

물론, 필자가 제시한 cfg파일 포맷을 그대로 사용할 경우에는 수정할 사항들이 있다.

그럼, cfg파일내의 각 항목들에 사용하는 옵션들에 대한 자세한 설명과 함께 수정사항들도 알아보도록 하자.

3. cfg파일 분석

WorkDir

MRTG실행 결과후에 생성되는 웹페이지구성파일들(*.html, *.png, *.log, *.old)이 생성될 위치이다.

이 위치의 디렉토리가 존재하지 않는다면 MRTG실행시 에러가 발생하게된다.

WorkDir에서 지정한 디렉토리가 존재하지 않는다며 반드시 생성을 한후에 실행을 해야한다.

또한 이 디렉토리의 퍼미션(permission) 은 반드시 웹서버 프로세스(대부분 nobody)가 읽을 수 있는 퍼미션이어야한다.

실행이 정상적으로 되었다면 후에 결과페이지를 볼 경우에 이 페이지를 로딩하여 보게된다.

즉, 현재 서버의 IP Address가 192.168.0.5라면 이 개인별 홈페이지를 로딩되도록 아파치의 httpd.conf파일에서 아래와 같은 설정이 되어 있어야한다.

기본셋팅은 www가 아니라 public_html이지만 필자는 www로 변경하여사용을 하였다.

이렇게 설정을 하였다면 웹브라우즈의 주소창에서 확인이 가능하게된다.

http://192.168.0.5/~mrtg

혹은 이 서버에 개별적인 도메인이 www.superuser.co.kr 이라고 가정한다면 웹브라우즈에서 다음과 같이 결과를 확인할 수도 있다.

http://www.superuser.co.kr/~mrtg

만약 아파치의 httpd.conf에서 가상호스트 설정을 하여 여러개의 독립도메인이 가능하도록 다음과 같은 설정이 되어있다면 독립적인 도메인의 호출또한 가능하게된다.

이렇게 설정이 되어 있다면 다음과 같은 URL로도 결과를 확인할 수 있다.

http://traffic.superuser.co.kr

물론 얼마든지 다른 URL을 이용하여 다양한 로딩방법이 가능하지만 대부분 필자가 소개한 이런 방법등을 통해서 로딩을 하게된다.

참고로 이 결과페이지를 위와 같은 방법으로 웹브라우즈를 통해서 확인할 때에는 대부분 ID와 패스워드로 암호인증을 하여 로그인하여 사용하게 하는 것이 일반적인다.

이 방법에 대해서는 뒤에 이어서 설명되는 "결과페이지 로딩시 암호인증걸기"편을 보기 바란다.

Language

결과출력시 사용할 언어를 지정한다.

MRTG문서를 보면 지원가능한 언어로 danish, french, english, dutch, brazilian, russian, spanish, greek, italian등이 지원되는 것으로 되어있지만 위의 예처럼 korean으로 설정하면 한국어로 결과페이지를 볼 수가 있다.

Refresh

결과페이지를 몇초(second)에 한번씩 재로딩(expire)시킬 것인가를 지정한다.

단위는 초이므로 위의 예처럼 300을 주면 5분마다 웹브라우즈가 재로딩을 하게된다.

만약 이 옵션을 사용하지 않는다면 기본값으로 300이 지정되며  5분마다 재로딩을 하게된다.

너무 작은 값을 주면 불필요하게 서버부하를 줄 수 있으므로 모니터링의 사용빈도등을 고려하여 적당한 값을 주도록 한다.

WithPeak

MRTG는 원래 대상장비의 모니터링된 송수신값의 평균값만으로 그래프를 그리게 되는데 이 옵션을 사용하게되면 daily, weekly, monthly, yearly의 그래프에서 5분주기의 평균값뿐만아니라 최대전송량까지도 함께 표시가된다.

위의 예처럼 일(day),주 (week),월(month),년(year) 4가지의 그래프중에서 원하는 그래프의 첫문자로 지정하면 된다.

Options

기본적으로 MRTG는 Byte for Second단위, bit 단위에 8을 곱한 단위즉 Byte단위를 사용하여 그래프를 그린다.

하지만 Options에서 bits를 사용하게되면 8을 곱하지 않고 bps(bits per second)를 사용하게 된다.

기본값은 byte단위임에 주의하자.

기본적으로 MRTG는 왼쪽에서부터 오른쪽으로 그래프를 그리게 된다.

즉, 오른쪽 그래프일수록 예전값이 된다는 것이다.

하지만 growright를 사용하게되면 오른쪽가장자리부터 그래프가 그려지기 시작하여 왼쪽으로 갈수록 이전그래프가 되도록 한다.

기본적으로 이 두가지 옵션을 같이 사용하는 경우가 많다.

이외에도 Options에서 지정할 수 있는 값들은 여러 가지가 있는데 "MRTG Configuration File Format편"에서 자세히 살펴보도록 할 것이다.

Traget

미리 말씀드리는데 cfg파일 설정중에서 가장 중요한 옵션이므로 정확한 이해가 요구되는 키워드이다.

먼저 Target에서 지정하는 것은 대상장비의 IP 주소나 도메인주소, 대상포트번호, community name, 장비이름(lable명)등이 있다.

Target이란 옵션의 용도는 한마디로 MRTG를 통해서 모니터링할 대상장비의 설정이라고 할 수 있다.

참고로 MRTG제작회사에서 배포한 MRTG문서의 원문에서는 Target에 대해서 다음과 같이 알리고 있다.

"The Target keyword you tell mrtg what it should monitor"

[ns.kebia.net_2]

이는 대상장비의 이름이라고 할 수 있다.

즉, 다른 장비들(내의 포트들)을 구분하기위한 방법이며 mrtg실행결과 생성되는 웹페이지의 파일들이 이 이름으로 생성이된다.

즉, ns.kebia.net_2.html, ns.kebia.net_2.png등과 같이 생성이 되며 따라서 웹페이지를 볼 때에도 이 이름으로 불러봐야한다.

즉, http://traffic.superuser.co.kr/ns.kebia.net_2.html로 웹브라우즈에서 볼러보면 되는 것이다.

2

대상장비(스위치, 라우터등)의 포트번호이다.

즉 라우터나 스위치에서는 하나의 포터만이 있는 것이 아니라 여러개의 포트(4, 8, 16, 24등 다양함)들이 존재하며 MRTG에서는 주로 이 포트들을 대상으로 모니터링을 하게된다.

여기서 public 앞에 붙은 번호는 라우터나 스위치의 모니터링대상 포트이다.

public

이것은 community name이다.

community name이란 SNMP의 일반적인 보안을 위해서 사용하는 인증암호와 같은 것으로 기본값으로 public을 갖는다.

하지만 보안을 위해서는 다른 값으로 설정할 것을 권한다.

대부분 MRTG의 실행에서 에러가 발생하는 원인이 이 community name이 정확하지 않아서 발생하는 에러이다.

ns.kebia.net

이것은 대상장비의 도메인이거나 ip address이면 된다.

즉, 모니터링하고자 하는 대상을 정확히 구분하기 위하여 대상장비의 ip 또는 도메인을 정확히 입력하면 된다.

우선 여기서는 Target이란 옵션에 대해서 정확히 이해를 하고 넘어가는 것만을 목표로 삼자.

앞으로 수도없이 나올 cfg파일내에서 Target이란 옵션은 반드시 들어가게 될 것이므로.....

Target옵션에을 설정하는 방법에는 다양한 방법이 있으며 이에 대한 설명을 "MRTG Configuration File Format"에서 하게 될 것이므로 이쯤에서 넘어가기로 하자.

SetEnv

환경변수할당의 일종으로서 외부프로그램이나 스크립트등에서 call 되었을 경우에 넘겨줄 변수와 값들을 설정한 것이다.

이 예는 cfgmaker로 cfg파일을 생성했을 경우에 자동생성된 것이며, 이외에도 다음과 같은 설정이 가능하다.

즉, 위와 같이 cfg파일에 설정이 되어있었을 경우에 외부프로그램이나 스크립트에서 EMAIL값이나 HOST, URL등의 값을 요구했을 때 각각 할당된 값을 넘겨주게 되는 것이다.

이런 외부환경변수 설정은 MRTG를 이용하여 자체적으로 사용하거나 응용프로그램을 개발시에도 주로 참조가 된다.

MaxBytes

대상장비또는 해당포트(라우터나 스위치의경우)의 최대전송가능 byte수를 지정한다.

즉, 해당포트가 전송가능한 초당 byte수를 지정하면 된다.

만약, 지정한 수치보다 높은 값이 리턴되어 오면 MRTG는 이값은 무시해버린다.

Title

mrtg실행결과 생성되는 html파일의 <title> 제목</title> 부분에 들어가는 "제목"이다.

즉, 웹브라우즈의 맨위에 나타나는 제목부분에 나타나는 부분이란 의미이다.

주의 할 것은 바로 뒤에 설명되는 PageTop에서 맨 처음나타나는 부분과 Title부분을 혼돈해서는 안된다.

PageTop은 단지 웹페이지의 최상단에 나타낼 내용임을 주지하기 바란다.

PageTop

mrtg실행결과 생성되는 html파일의 최상단에 출력될 내용이다.

몇 개의 라인으로 구성할 수도 있으며 뒤따르는 모든 라인또한 최상단에 이어서 출력되며, 라인과 라인을 구분할 때에는 "\n"을 사용하면 된다.

참고로 위의 결과 생성되는 MRTG 샘플을 보이면 다음과 같다.

위의 예를 보는 바와 같이 PageTop이하의 내용들이 결과 웹페이지내에서 최상단에 출력됨을 알 수 있다 .

따라서 PageTop에 주로 들어가는 내용들은 MRTG로 분석된 결과페이지들의 제목이나 간략한 설명등이 들어가게 된다.

즉, 현재 보고 있는 페이지의 대상장비나 대상네트웍에 대한 간략한 소개나 구분정도로 해두면 된다.

MRTG에는 이외에도 다양한 옵션들이 많이 있다.

이들 다양한 옵션에 대해서는 "MRTG Configuration File Format"을 보기 바란다.

4. mrtg 초기실행하기

자, 이제 MRTG의 cfg에 관련된 설정들이 모두 끝이났다.

이제 해야할 것은 mrtg를 실행을 시켜서 정상적으로 실행이되는가를 확인하는 작업니다.

물론 mrtg는 cron에 등록되어 자동적으로 주어진 주기(일반적으로는 5분에 1회)에 한번씩 실행이 된다 .

하지만, 아직 cron에 등록되기전이므로 지금까지 만든 cfg파일로 mrtg를 실행시켜보자.

처음 실행은 /usr/local/mrtg/bin/에 있는 실행파일인 mrtg를 이용해서 실행토록 하자.

• 실행파일 : /usr/local/mrtg/bin/mrtg (가능한 절대경로를 사용하는 것이 에러를 줄이는 지름길이 된다.)
• 환경파일 : /home/mrtg/conf/kebia_1.cfg (지금까지 고생해서 만든 cfg파일)
• 실행방법 : /usr/local/mrtg/bin/mrtg /home/mrtg/conf/kebia_1.cfg (쉘프롬프트에서 실행)

아래 실행예를 보기 바란다.

위의 예와 같이 똑같은 명령을 모두 3회를 실행시켰는데 처음실행과 두 번째 실행에서 각각 이상한 경고메시지(WARNING)가 발생을 했다.

그리고 세 번째 실행에서는 경고(WARNING) 가 발생하지를 않았다.

개론부분에서 자세히 설명드린 바와같이 MRTG는 각각 실행한 값들의 비교계산한 값들로 그 수치를 얻어내는데, 처음실행과 두 번째 실행에서는 비교값들이 존재하지 않아서 발생한 메시지이므로 이는 처음실행시에 당연히 발생하는 경고로 걱정할 것은 못된다.

세 번째 실행에서는 에러가 발생하지 않았다는 것은 비교할 값들이 존재하므로 정상적인 mrtg 실행수치를 얻어냈다는 것을 의미한다.

자, 그럼 실행결과 생성된 결과 파일들을 보도록 하자.

cfg파일내에서 WorkDir의 값을 /home/mrtg/www/kebia_1로 주었으므로 이 위치로 가서 "ls -l"을 한 결과를 보이고 있는 것이다.

유의해서 볼 것 몇가지만 언급하자.

먼저 html파일의 이름(ns.kebia.net_2)이 cfg파일의 Target부분의 "[ ]"에서 지정된 것임을 확인하자.

그리고, 생성된 파일들의 종류를 보면 html, log, old과 같은 파일들임도 확인토록하자.

앞서 설명을 드렸지만, 이제 생성된 결과를 웹브라우즈에서 불러보면 되며 이때에 불러볼 파일명도한 html파일명(ns.kebia.net_2.html)임도 함께 확인토록 하자.

5. 결과확인 및 분석하기

이제 온전한 결과페이지를 확인해 보자.

정상적인 결과페이지가 생성이 되었다면 아래와 같을 것이다  여기 페이지에  ip address 192.168.0.5로 바꿀것..

결과페이지로 생성된 4개의 결과페이지를 간단히 설명하면 다음과 같다.

일간그래프

   - 5분단위 평균값을 기준으로 하여 생성된 그래프

주간그래프

   - 30분 단위 평균값을 기준으로 하여 생성된 그래프

월간그래프

  - 2시간 단위 평균값을 기준으로 하여 생성된 그래프

년간그래프

  - 일일 단위 평균값을 기준으로 하여 생성된 그래프

그래프에서의 파란색

   - 대상장비에서 외부로 송신된(빠져나간) 트래픽량을 나타냄.

그래프에서의 초록색

   - 외부네트웍에서 대상장비로 수신(들어온) 트래픽량을 나타냄.

6. 결과페이지 로딩시 암호인증걸기

여기까지 해서 mrtg의 설정작업이 마무리되었다.

하지만, 이제 정기적인 mrtg실행을 위한 cron작업과 트래픽정보는 보안사항이므로 관계자외에는 보게해서는 안되므로 mrtg 실행결과 생성되는 웹페이지에 암호인증설정을 해야한다.

암호인증설정하는 방법은 여러 가지가 있지만 여기서는 아파치(Apache)제공 유틸리티인 htpasswd를 이용토록 할 것이다.

이책의 뒷부분에 가면 실무프로젝트를 다루었으며 좀더 강화된 보안을 위한 암호인증을 위해 mysql과 php로 웹프로그래밍을 하여 인증하는 방법에 대해서 소개하고 있으므로 참조바란다.

먼저, htpasswd로 암호인증을 위해서는 다음과 같은 것이 필요하다.

• .htaccess파일생성
• htpasswd 유틸리티위치확인
• htpasswd 로 .htpasswd파일 생성하는 방법

.htaccess파일만들기

mrtg실행결과 생성되는 웹페이지파일들이 존재하는 디렉토리(/home/mrtg/www/)에서 다음과 같은 내용을 가진 .htaccess파일을 생성해준다.

주의할 것은 .htaccess파일이 점(.)으로 시작한다는 것이다.

위의 내용을 간단히 설명하면 다음과 같다.

• AuthName : 트래픽분석 관리자페이지의 적당한 제목을 임의대로 적는다.
• AuthType : 인증타입은 일반적으로 Basic으로 한다
• AuthUserFile : ID와 암호가 존재할 위치와파일명
• AuthGroupFile : 그룹으로 인증확인을 할경우에 그룹인증파일명을 적는다.
• <Limit> ~ </Limit> : require valid-user 인증이 유효한 사용자만 접근가능토록한 설정

위와 같이 적당한 .htaccess파일을 만들었으면 이제 .htpasswd파일을 만들어줄 차례이다.

먼저 htpasswd라는 유틸리티가 어디에 존재하나를 확인한다.

확인하는 방법은 "which htpasswd"로 하거나 또는 "find / -name htpasswd -print"로 찾아볼 수도 있다.

대부분은 아파치 설치디렉토리 아래의 bin 디렉토리(/usr/local/apache/bin)에 존재하고 있다.

아래와 같이 htpasswd를 처음 실행할 때에는 반드시 -c (create option)을 사용해야 .htpasswd라는 파일이 만들어 진다.

.htpasswd 파일을 생성한 후에 cat 명령어로 정상적으로 ID와 패스워드가 생성이 되었는가를 확인한 것이다.

이제 웹브라우즈를 통해서 이 페이지를 다시 불러보자.

앞에서와는 달리 ID와 패스워드를 입력하라는 창이 뜨게 된다.

이 창에 좀전에 생성했던 ID와 패스워드를 입력해주면 정상적인 접근이 가능하게 된다.

7.cron에 mrtg주기적인 실행 설정하기

 여기까지 오느라 정말 고생이 많았으리라 생각이 된다.

하지만 이제 MRTG의 실행이 모두 정상적으로 이루어 졌으므로 이제 남은 것은 주기적으로(일반적으로 5분간격) MRTG를 실행시키는 작업만이 남아있을 뿐이다.

따라서 모든 cfg파일이 들어있는 mrtg스크립트파일 mrtg.sh 파일을 아래와 같이 만들어서 이 파일을 cron에 등록하기만 하면 된다.

mrtg.sh파일의 내용

이미 설명을 드렸지만 확인하는 의미에서 말씀드린다면 이파일의 위치는 /home/mrtg/bin/mrtg.sh 파일이다.

이제 이 파일을 root의 crontab에 등록을 할 것이다.

crontab이란 주기적으로 어떤 프로그램을 실행시키기 위해서 등록을하는 cron테이블이다.

crontab에 등록을 하기 위해서는 "crontab -e"란 명령어를 아래와 같이 입력하면 현재 사용중인 사용자의 cron설정을 할 수가 있다.

MRTG의 cron은 root로 설정하거나 mrtg계정의 cron에 등록하나 둘중 하나에 하면 된다.

아래와 같이 "crontab -e"를 하게되면 vi모드와 같이 입력을 할 수 있다.

위의 cron설정은 매 5분마다 /home/mrtg/bin/mrtg.sh 스크립트를 실행하게한 설정이다.

이제 crontab에 등록된 내용을 확인해보도록 하자.

확인은 아래의 예와 같이 "crontab -l"을 하면 현재 사용중인 계정의 crontab등록상황을 보여주게 된다 .

 이제 5분마다 mrtg.sh파일에 등록되어 있는 mrtg가 실행이 되어 cfg파일에 설정되어 있는 WorkDir 디렉토리에 mrtg의 결과인 웹파일들을 저장하게된다.