보물창고

Error creating AIR file: 305: ERROR, 10, http://ns.adobe.com/air/a...

2009-09-29T15:41:15Z

그동안 개발해오던 프로그램을 빌더에서 실행을 시키니

통 실행이 않된다.

아무런 메세지도 없이.

여기 저기 alert를 넣어서 디버깅 배보려고도 했지만 결코 메세지는 뜨지 않고

이유도 모른체 여기 저기 설정값 살펴보고

컴퓨터 부팅도 다시 해보지만 당췌 내가 만든 프로그램이 실행이 않된다.

혹시나 air파일로 만들어서 설치한후 실행하면 어찌 되나 싶어 export 하는데

Error creating AIR file: 305: ERROR, 10, http://ns.adobe.com/air/application/1.1

위와 같은 에러가 뜬다

아니 이게 모야....

그동안 잘 되던 것이었는데. 왜 갑자기 이러지.....

아무리 쳐다봐도 이유는 알수가 없다.

바로 검색 들어간다.

ㅎㅎ

나보다 먼저 이를 경험하신 분이 있더라. 멀리 외국에

Air가 1.5로 업데이트 된후 이것에 대한 부분을 반영을 해줘야 하는데 그것을 하지 않아 일어난 문제란다.

Air가 버젼업 됐다고 해서 내 프로그램에 뭔가 작업을 해줘야 한다는 것을 사실 상상도 않했었다.

그냥 없데이트 되면 그런가 보다. 좋다. 그렇게만 생각 했는데

그것에 대해 내 소스에도 반영을 해줘야 한단다.

air프로젝트마다 함께 만들어 지는 -app.xml파일 2번째 라인에

http://ns.adobe.com/air/application/1.1">

위와 같은 문장이 있다.

저기서 1.1을 Air버전에 맞게 바꿔줘야 한단다.

지금 버전이 1.5이니 1.5로.

이걸 몰라서 오랜 삽질끝에 애꿎은 컴터만 재부팅 시켰다.

불쌍한...

문상기는 각성하라!!! 각성하라!!! 각성하라!!!

tag : air, flex

[펌글]Servlet이란.

2009-09-17T14:03:38Z

1.Servlet이란?

Servlet이란?

Java Applet이 Web Server로부터 download받아 Client Browser의 JVM에서 수행되는 작은 Java 응용프로그램이라면,
Web Server상에서 CGI 요청을 처리하는 서버측 JVM에서 수행되는 Java 응용 프로그램을 Servlet이라고 한다.
Applet은 GUI를 지원하지만 Servlet은 서버측의 수행결과를 전달하는 역할 특성상 GUI를 지원하지 않는다.

Servlet의 장점

요청시 마다 새로운 Process를 생성하지 않는다.
서버의 Overhead를 줄일 수 있다.
각 요청을 thread로 동작시키기 때문에 좀더 효과적인 다중작업(multi-tasking)이 가능하다.
Servlet은 모든 요청에 대해 최초 한번의 Memory Loading을 한다.
Platform에 독립적이다.
보안모델을 사용할 수 있다.

Servlet Program 절차

프로그램의 Logic 및 입출력 화면을 설계한다.
Servlet API를 사용하기 위해 필요한 Package를 import한다.
javax.servlet.http.HttpServlet을 상속받아 class를 만든다.
doGet(), doPost(), service()등의 메소드를 적절히 Override한다.
Client에서 Servlet을 호출하면서 넘겨준 Parameter가 있다면 HttpServletRequest로부터 필요한 Parameter를 전달받는다.
결과를 Client에게 전달하기 위해 HttpServletResponse를 이용한다.

Servlet Container

Servlet Container의 역할

기본적으로 Servlet을 탑재, 인스턴스화 및 초기화 등 Servlet의 생명주기를 관리한다.
클라이언트로부터 요청받은 정보가 웹서버로 전달되면 이 정보를 인자로 doPost()나 doGet() 메소드를 호출, 배포서술자를 통해 해당 Servlet으로 요청(request)하고 돌려받은 응답(response)을 다시 웹서버로 전달해준다. (즉 Servlet과 Web Server간 정보 교환을 위한 일종의 Web Component이다.)

배포 서술자 (DD : Deployment Descriptor)

배포서술자(DD)란?

배포서술자는 웹에서 요청받은 해당 서블릿의 url주소를 통해 서블릿 이름을 체크, 해당 서블릿 클래스를 호출하기 위한 매핑 정보를 기록하는 역할을 한다.

배포서술자의 형식

Tomcat과 같은 웹 컨테이너에서는 웹에서 URL을 요청시 먼저 배포서술자가 있는지 여부를 체크한다.
이를 체크하는 설정파일의 이름은 web.xml이며 접근한 URL의 하위디렉토리명 WEB-INF로 생성되어있는 폴더의 위치한다.
배포서술자의 형식은 다음과 같다.

http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">


        서블릿 이름
        서블릿 클래스의 위치



        서블릿 이름
        해당 서블릿의 url 주소 이름

구현 방식은 간단하다. 웹에서 입력한 서블릿에 대한 url-pattern이 존재하면 해당 url-pattern의 서블릿 이름을 읽고 해당 서블릿을 servlet-class의 경로를 참조하여 불러들인다.

서버의 동작

JSP로 구성된 페이지 톰캣 서버의 동작은 다음과 같다.

먼저 서버를 동작시키면 server.xml의 파일의 환경설정을 읽어들인다.

이 환경 설정이 서버가 동작하는 동안 받아들인 요청을 처리할 대상과 선처리 리스너를 미리 인지하고 서버가 동작을 하게 된다.

처음 톰캣을 eclipse에 설치하고 서버를 추가하면 자동적으로 이 server.xml을 생성해주는데 생성된 server.xml파일의 주석은 이해를 돕기 위한 주석이니 삭제해도 무방하다.

이런 저런 주석을 다 정리하고 난 설정을 보자.

상당히 복잡해보이지만 실제 사용자가 설정을 해주는 부분은 ... 부분이다.

그 위에 있는 Listener 설정과 GlobalNamingResources설정은 기본 설정을 그대로 사용하면 된다.

서버를 하나의 서비스로 이해하고 설정을 해주는 부분인데 만약 서버가 추가가 된다면 를 이름을 다르게 주어 여러게 등록하면되며 이럴 경우 defaultHost를 바꿔주어야 할 것이다.

위의 경우

myhomepage.net의 80포트(설정을 하지 않았을 때의 기본 포트. 만약 80이 아닌 다른 포트로 설정을 하면 접속시 myhomepage:8080 등과 같이 포트선언을 해주어야 한다.)로 접속하면 톰캣 서버는 해당 접근에 대해서 어떤 서비스로의 접근인지 판단하여 위의 설정과 일치한 경우 해당 디렉토리를 찾아가게 된다.
찾아간 디렉토리에서 어떤 처리를 해주어야 할지 해당 디렉토리의 WEB-INF에 있는 web.xml을 읽어들여 해당 주소에 대한 요청을 처리한다.

container의 동작

위의 서버의 동작을 통해 호출된 container는 먼저 해당 선언된 디렉토리의 배포서술자(DD - Deployment Descripter)인 web.xml을 찾게 된다.

web.xml의 소스를 보자.

version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2eehttp://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
1. 1. MyServlet
  2. com.myHomepage.MyServlet
3. 1. MyServlet
  2. myservlet

웹에서 호출하게 되면

servlet-mapping element의 에 해당 접근 url 패턴과 일치하는 url이 있는지 확인
해당 url-pattern의 servlet-name을 확인
servlet element에서 해당 servlet-name의 class를 찾아서 호출하여 처리

과 같은 순서로 처리하게 된다.

초기화 파라미터

DD(web.xml) 파일에는 배포 서블릿 선언만 들어갈 수 있는 것이 아니다.

초기화 파라미터 값 또한 선언이 가능하며 이를 web.xml에서 해주는 이유는

해당 파일에 선언된 값을 프로젝트 전체에서 적용하여 쓸 수 있다는 이점이 있으며
해당 변수의 값이 변경 경되었을 때 클래스의 경우는 재 컴파일의 부담이 있으나 web.xml의 경우 서블릿 초기화만 해주면 된다.

먼저 web.xml에 아래와 같이 선언해준다.

        서블릿 이름
        서블릿 클래스의 위치


           변수명
            변수값

서블릿 코드에서 호출하여 사용하는방법은 아래와 같다.

out.println(getServletConfig().getInitParameter("변수명"));

위에서 사용한 init-param 초기화는 해당 파라미터 값이 설정된 servlet에서 사용이 되어지는 값이다.

만약 이 값을 특정 servlet이 아닌 전체 servlet이 모두 적용되고 싶다고 하면 이럴때는 init-param이 아닌 context-param을 선언해주면 된다.

주의할 점은 특정 서블릿의 파라미터값 초기화가 아니기 때문에 ~ 사이에 들어가지 않는다.

        서블릿 이름
        서블릿 클래스의 위치



        변수명
        변수값

서블릿 코드에서 호출하여 사용하는 방법은 아래와 같다.

out.println(getServletContext().getInitParameter("변수명"));

server에서 context init parameter와 servlet init parameter

web.xml에 초기화 parameter를 선언해주면 호출한 페이지에서는 해당 파라메터를 사용할 수 있다.

초기화 parameter는 2가지가 있다.

context init parameter
servlet init parameter

아까 보았던 web.xml을 보면 root element인 내에 이 존재하는데 이는 하나의 디렉터리에 어떤 url 패턴을 가지고 접근하는가에 따라 여러개의 servlet을 요청하게 되는 구조이다.

context init parameter는 이중 의 자식 node로 선언이 되며 해당 url-pattern으로 접근하는 모든 항목에 대하여 초기화 parameter를 선언하게 되며

servlet init parameter는 해당 호출된 servlet에 대해서만 초기화 parameter를 선언하게 되는 것이다.

이에 대한 예제를 보면

version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2eehttp://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
1. 1. 이름
  2. 값
1. 1. MyServlet
  2. com.myHomepage.MyServlet
  3. 1. 이름
    2. 값
3. 1. MyServlet
  2. myservlet

위와 같이 선언하게 된다.

선언된 초기값을 사용할 때는 해당 페이지에서

getServletContext().getInitParameter("이름"); //context init parameter
getServletConfig().getInitParameter("이름"); //servlet init parameter

위와 같이 호출한다.

이렇게 선언한 초기화 parameter는 변동이 불가능하며 따라서 setInitParameter() 같은 함수는 없다.

Listener

Javascript의 onClick, onSubmit, onMouserover과 같이 중간에 발생되는 현황을 알아채고 그에 대해 리액션을 해주는 Class

ServletContextListener

위의 내용을 통해 서블릿에 초기화 parameter를 지정하는 방법을 알아보았다.

그런데 이런 초기화 parameter가 지정되면 해당 초기화 parameter를 이용한 객체를 초기화 할 필요가 있을 경우가 있다.

초기화 값을 parameter만이 아닌 해당 값을 가진 객체를 선언하고 싶을 때 초기화 값이 생성된 것을 알아차리고 실행되는 클래스(리스너)가 필요하다.

이런 리스너를 지정하는 방법은 아래와 같다.

web.xml에 해당 리스너를 지정한다.
listener Class는 javax.servlet.SevletContextListener 인터페이스를 구현한다.
1. import javax.servlet.*;
2. public class ListenerClassName implements ServletContextListener {
  1. public void contextInitialized(ServletContextEvent event) {
    1. 원하는 객체를 만들고 설정함
  2. }
  3. public void contextDestroyed(ServletContextEvent event) {
    1. //컨텍스트 소멸은 서비스의 종료를 의미하므로 이부분은 아무런 개발이 필요치 않음.
  4. }
3. }
위에서 생성된 객체를 웹페이지에서 호출한 클래스에서 그냥 가져다 쓰면 된다.

servletContext와 servletContextListener를 사용하였다. 전체적인 흐름은

톰캣서버가 server.xml을 읽어들인 후 서버가 구동
사용자가 web상에서 해당 서버의 페이지 호출
해당 호출에 대해서 서버는 컨테이너를 호출
컨테이너는 배포서술자(web.xml)을 읽고 호출에 대한 처리값을 알아낸다.
1. context init parameter 선언
2. context listener를 호출 (context init parameter를 이용한 처리)
  1. contextInitialized() 메소드를 호출
3. 해당 servlet을 확인
  1. servlet init parameter를 선언
  2. 해당 서블릿 호출

속성의 부여와 그 범위에 대하여

xml을 공부해본사람들은 들어본 단어인데 어떤 객체에 대해서 속성이 존재한다.

Java에서 속성은 3개의 servlet API 객체에 설정해 놓는 객체를 말한다. (이를 binding 이라고 부른다.)

설정할 수 있는 객체는 아래와 같다.

ServletContext
HttpServletRequest (또는 ServletRequest)
HttpSession

해당 class 내에서 선언을 하면 되며 선언된 속성은 객체로 취급된다.

속성과 관련된 메소드는 다음과 같다.

getAttribute(String)
setAttribute(String, Object)
removeAttribute(String)
getAttributeNames()

대강의 예를 보면 아래와 같다.

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class AttributeTest extends HttpServlet {
1. public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
  1. response.setContentType("text/html");
  2. PrintWriter out = response.getWriter();
    
    out.println("test context attributes
    ");
    
    getServletContext().setAttribute("이름", "값");
    request.getSession().setAttribute("이름", "값");
  3. request.setAttribute().setAttribute("이름", "값");
2. }
}

위와 같이 해당 context나 session, request에 attribute를 설정할 수 있다.

이렇게 설정한 attribute는 해당 객체의 특징을 그대로 가지게 되는데

ServletContext 객체의 경우
1. 해당 Servlet 객체가 살아있는 동안 attribute값이 유지되며 만약 동일 Servlet을 각각 다른 스레드 통해 접근, 어느 한쪽이 attribute값을 변경하면 다른 쪽도 다음번 호출시 적용된다. (즉 thread에 대해 안전하지 못하다.)
2. 이는 컨테이너에서 받아들이는 접근마다 각각 thread를 생성하여 호출하는 Servlet은 아무리 thread가 많아도 Servlet의 인스턴스는 하나밖에 없기 때문이다.
Session 객체의 경우
1. 해당 세션으로 그 영역이 줄어들었지만 동일 사용자가 마찬가지로 동일 세션을 창을 여러개 띄우고 접근할 때는 attribute값은 안전하지 못하게 된다.
2. 이는 요청 thread가 많아도 해당 사용자에 대한 Session의 인스턴스는 하나밖에 없기 때문이다.

redirect와 dispatch

두 명령은 모두 페이지를 이동할 때 사용되는데 redirect는 클라이언트 상에서, dispatch는 서버 상에서 이동을 할 때 쓰이는 명령어이다.

dispatcher

설정할 수 있는 객체는 아래와 같다.

servletContext
servletRequest

해당 메소드는 아래와 같다.

forward(request, response)
include(request, response)

선언은 다음과 같다.

//context의 경우
RequestDispatcher view = getServletContext().getRequestDispatcher(url);
//request의 경우
RequestDispatcher view = request.getRequestDispatcher("보낼경로");
view.forword(request, response); 혹은 view.include(request, response);

session

HttpSession session = request.getSession();

위의 구문은 세션으르 가져오라는 명령도 되지만 만약 세션이 존재하지 않으면 해당 세션을 생성하고 가져오는 역할도 한다.

따라서 해당 세션이 새로 생성된 것인지 가져온것인지에 대한 구분하는 메소드가 있다.

session.isNew(); //true면 새로 만들어진 것, false면 이미 생성되어 있던 것

세션의 경우는 context나 servlet 객체에서는 설정할 수 없다.

위의 명령의 경우는 새로 생성된 것이건, 기존의 것이건 없으면 만들어서 가져오게 된다.

만약 결제 시스템과 같이 새로 생성이 필요없고 기존의 것만을 가져오려고 한다면 다음과 같이 재정의된 getSession() 메소드를 사용한다.

HttpSession session = request.getSession(false); //기존 세션이 없는 경우 null을 리턴한다.
if (session == null) {
1. 기존 세션이 없을 때 처리
} else {
1. 기존 세션이 있을 때 처리
}

HttpSession 메소드 목록

getCreationTime()	생성된 시간 리턴
getLastAccessedTime()	세션으로 들어온 마지막 요청시간 리턴
setMaxInactiveInterval()	해당 세션에 대한 요청과 요청 간의 최대 허용시간 (초단위)을 지정
getMaxInactiveInterval()	해당 세션에 대한 요청과 요청 간의 최대 허용시간
invalidate()	세션을 종료

세션에 대한 설정은 해당 web.xml에서 해준다.

1. 1. 15

만약 특정 세션 인스턴스만 타임아웃 값을 주고 싶다면

session.setMaxInactiveInterval(초);

주의 할 점은 invalidate나 setMaxInactiveInterval(0)으로 세션을 종료한 후에 세션에 대한 호출을 하면 오류가 난다.

cookie

쿠키 객체 생성

Cookie cookie = new Cookie("이름", 값);

쿠키 life time 설정

cookie.setMaxAge(30*60);

쿠키 생성

response.addCookie(cookie);

쿠키 읽기

Cookie[] cookies = request.getCookies();
for (int i = 0; i < cookies.length; i++){
1. Cookie cookie = cookies[i];
2. if (cookie.getName().equals("이름")) {
  1. String 이름 = cookie.getValue();
  2. out.println("Hello " + 이름);
  3. break;
3. }
}

TIP

요청받은 값의 인식

리턴받은 클래스에서 아래와 같은 형식으로 파라미터 값을 리턴 받을 수 있다.

String one = request.getParameter("파라미터 이름");

여러개의 리턴값인 경우(checkBox와 같은 파라미터 값)

String one = request.getParameterValues("파라미터 이름")[0];
String [] sizes = request.getParameterValues("파라미터 이름");

여러개의 리턴값을 일일이 모두 확인하고 싶다면 다음과 같이 호출한다.

String [] sizes = request.getParameterValues("sizes");
for (int x = 0 ; x < sizes.length ; x++ ) {
out.println("
sizes : " + sizes[x] );
}

출처 : http://leenuxx.egloos.com/996192

tag : java

[펌글] Clustering and Load Balancing in Tomcat 5, Part 2

2009-09-17T01:24:10Z

Tomcat 5에서의 클러스터링과

로드 밸런싱, Part 2

by Srini Penchikala
04/14/2004
번역 허태명

이 글은 톰캣 5 서버에서 클러스터링과 로드 밸런싱에 관한 시리즈의 두번째 파트이다. 파트 1에서 필자는 확장성과 고가용성을 위한 시스템을 디자인할 때 고려해야할 다양한 요소와 Large-scale J2EE 시스템 디자인의 개괄에 대해 얘기했다. 또한 클러스터링, 로드 밸런싱, 결함 허용, 세션 복제 능력에 대한 톰캣의 지원에 대해서도 논했다. 이번 파트에서 우리는 제시된 클러스터 설정의 아키텍쳐와 클러스터를 배치할 때(다수의 톰캣 서버 인스턴스를 운영함으로써)의 설치와 설정의 세세한 부분에 대해 다룰 것이다.

제시된 클러스터 설정

아래 목록은 제시된 톰캣 클러스터에서 필자가 달성하기 원하는 주 목적들이다:

클러스터는 고도의 확장성이 있어야 한다.
클러스터는 결함 허용을 지원해야 한다.
클러스터는 동적으로 설정가능해야 하며, 그것은 클러스터를 프로그램적(자바 코드의 변경)으로 보다는 선언적(설정 파일의 변경)으로 관리하기 쉬워야 한다는 것을 의미한다.
클러스터는 자동 클러스터 멤버 감지 기능을 제공해야만 한다.
세션 데이터를 위한 메모리 세션 상태 복제 기능을 갖고 있는 Fail-over와 로드 밸런싱 기능
플러그인/설정가능한 로드 밸런싱 정책
클러스터 멤버가 합류하거나 그룹에서 떠날 때 그룹 멤버쉽 공지 기능
멀티캐스트를 통한 메세지 전송의 손실이 없어야 한다.
클러스터링은 웹 어플리케이션과 서버에 잘 연계되어야 한다. 클러스터는 클라이언트와 서버 양쪽에 투명성을 제공해야 한다. 클라이언트 투명성은 클라이언트가 클러스터링된 서비스나 클러스터가 어떻게 설정됐는지 모른다는 의미이다. 클러스터는 각각의 서비스들 보다는 단일한 것으로써 확인되고 접근되어야 한다. 서버 투명성은 서버의 어플리케이션 코드는 그것이 클러스터 내에 있는지 몰라야 한다는 것을 의미한다. 어플리케이션 코드는 다른 클러스터 멤버와 통신할 수 없다.

클러스터링 환경을 설정하기 위해 4개의 톰캣 서버 인스턴스가 설치되었다. 톰캣은 로드 밸런싱과 클러스터링 양쪽의 요구사항을 위해 사용되었다. 클러스터 설정은 수직 확장 방법 (단일 머신에 다수의 톰캣 서버 인스턴스 운영)을 사용하였다. 1개의 서버 그룹과 2개의 복제본이 클러스터에 설정되었다.(서버 그룹은 어플리케이션 서버의 논리적 표시이다.) 복제본은 세션 복제를 최적화하기 위해 서버 그룹과 설정(웹 어플리케이션의 디렉토리 구조와 컨텐츠를 의미)을 완전히 똑같이 한다. 다음은 제시된 클러스터 설정의 주요 컴포넌트들이다:

로드 밸런서: 1개의 톰캣 인스턴스가 클러스터 노드들 사이에서 트래픽을 분배하기 위해 설정되었다. 이 인스턴스는 TC-LB라는 코드명을 갖는다.
클러스터링: 3개의 톰캣 서버 인스턴스가 클러스터의 일부로서 운영된다. 이 인스턴스들의 코드명은 TC01, TC02, TC03 이다.
세션 영속성: 메모리 세션 복제가 세션 영속성 메카니즘으로 선택되었다. 세션 객체가 변경될 때마다 세션 데이터는 3개의 모든 클러스터 멤버들에게 복사된다.
Fail-Over: 톰캣 설치본에 포함되어 있는 밸런서 어플리케이션은 fail-over를 다루도록 설계되지 않았다. 필자는 어떤 리퀘스트라도 서버에 포워딩하기전에 서버의 상태를 체크하는 ServerUtil이라는 유틸리티 클래스를 작성하였다. ServerUtil은 클러스터 노드의 상태를 검증하는 2개의 메소드를 가지고 있다. 첫번째 메소드에서는 특정 서버 인스턴스가 현재 돌아가고 있는지 아닌지 체크하기 위해 McastService를 사용한다. 두번째 메소드는 파라미터로써 전달된 웹 페이지 URL에 의거하여 URL 객체를 생성함으로써 클러스터 노드의 사용가능성을 검증한다. 이 클래스를 사용하기 위해 catalina-cluster.jar (%TOMCAT_HOME%/server/lib 디렉토리에 위치)와 commons-logging-api.jar (%TOMCAT_HOME%/bin 디렉토리에 위치) 파일이 클래스패쓰에 잡혀있는지 확인하라.

Figure 1의 어플리케이션 아키텍쳐 다이어그램은 클러스터의 주요 컴포넌트를 보여준다.

Figure 1. Tomcat cluster architecture diagram

톰캣 인스턴스의 설치 & 설정

Table 1. 톰캣 클러스터링을 설정하는데 사용된 머신의 하드웨어/소프트웨어 스펙

Processor	HP Pavilion Pentium III 800 MHz
Memory	512 MB RAM
Hard Disk	40 GB
Operating System	Windows 2000 server with Service Pack 4
JDK 버전	1.4.0_02 (주: 톰캣 클러스터링을 사용하기 위해서는 JDK 1.4 이상의 버전이 필요하다.)
Tomcat 버전	5.0.19
사용된 툴	Ant 1.6.1, Log4J, JMeter, JBuilder

클러스터 프레임워크의 주요 요소들

자바 클래스

```
BaseLoadBalancingRule
```
이 클래스는 커스텀 Rule 클래스에 일반적인 룰 로직을 캡슐화하기 위해 생성된 추상 클래스이다. 예제 웹 어플리케이션에서 사용된 커스텀 로드 밸런싱 룰은 이 베이스 클래스를 확장한 것이다.
```
RandomRedirectRule
```
이 클래스는 랜덤한 방법으로 사용가능한 서버에 웹 리퀘스트를 포워드하는 로직을 정의한다. 난수를 생성하기 위한 시드(seed)로 현재의 시스템 시간을 사용한다.
```
RoundRobinRule
```
이 클래스는 라운드 로빈 룰에 의거한 로드 밸런싱 룰을 정의한다. 리퀘스트가 올 때 이 클래스는 리퀘스트를 목록의 다음 멤버에게 포워딩한다. 다음 사용가능한 클러스터 멤버를 추적하고 매 새로운 리퀘스트마다 값을 하나씩 증가시키기 위해 정적 변수를 사용한다.
```
ServerUtil
```
이 클래스는 특정 클러스터 노드가 리퀘스트를 받을 수 있도록 사용가능한지 아닌지를 체크하기 위해 만들어진 유틸리티 클래스이다. 이 클래스는 클러스터 멤버가 그룹을 떠났는지 검사하기 위해 McastService (org.apache.catalina.cluster.mcast 패키지) 클래스를 사용한다.

이 자바 클래스들간의 관계가 Figure 2의 클래스 다이어그램에 나타나 있다.

Figure 2. Cluster application class diagram

설정 파일

```
server.xml
```
이 파일은 톰캣 서버 인스턴스의 클러스터링을 설정하기 위해 사용된다. 톰캣 설치본에 포함되어 있는 버전은 파일에 자세한 설정이 되어 있지만 주석처리되어 있다.
```
web.xml
```
이 설정 파일은 웹 어플리케이션 세션 데이터가 복제될 필요있다는 것을 규정하기 위해 사용된다.
```
rules.xml
```
이 파일은 커스텀 로드 밸런싱 룰을 정의하기 위해 사용된다. 이 파일은 우리가 클러스터 멤버 사이의 부하를 분배하기 위해 어떤 로드 밸런싱 룰을 사용하기 원하는지 규정하기 위해 사용하는 파일이다.

스크립트

```
test.jsp
```
서버 상태를 체크하기 위해 사용하는 간단한 테스트 JSP 스크립트이다. test.jsp 파일이 실행된 시스템 시간과 톰캣 인스턴스의 이름을 보여준다.
```
testLB.jsp
```
이 파일은 우리의 예제 웹 어플리케이션의 시작 페이지이다. HTML 리다이렉트를 사용하여 로드 밸런서 필터로 웹 리퀘스트를 포워딩한다.
```
sessiondata.jsp
```
이 스크립트는 어떤 1개의 클러스터 노드가 다운됐을 때 세션 데이터의 손실이 없다는 것을 검증하기 위해 사용된다. 세션의 자세한 정보와 또한 HTTP 세션 객체를 조작하는 HTML 필드를 보여준다.
```
build.xml
```
Ant 빌드 스크립트가 톰캣 인스턴스의 시작과 중지 작업을 자동화하기 위해 사용된다.(이 스크립트를 실행하기 위해 Ant 1.6.1 최신 버전이 사용됐다.) 톰캣 인스턴스가 성공적으로 구동되면, IP 주소와 포트 번호를 정함으로써 어떤 톰캣 인스턴스가 실행되는지 검증하기 위해 test.jsp를 호출할 수 있다. JSP 페이지는 현재 시스템 시간과 톰캣 인스턴스의 이름을 보여준다.(여러분은 자신의 환경에서 스크립트를 실행하기 위해 build.properties 파일에 정의된 톰캣 서버의 홈 디렉토리를 변경할 필요가 있다.)

톰캣 인스턴스를 시작하거나 중지시키는 빌드 스크립트의 몇 가지 타겟들:

특정 톰캣 인스턴스를 구동하기 위해 start.tomcat5x 타겟을 호출하라. (예: tomcat50)
특정 톰캣 인스턴스를 중지하기 위해 stop.tomcat5x 타겟을 호출하라.
실행되고 있는 모든 톰캣 인스턴스를 중지하기 위해 stop.alltomcats 타겟을 호출하라.

예제 코드

이 글에서 사용된 예제 코드는 tomcatclustering.zip에서 구할 수 있다. 톰캣 서버 인스턴스들을 설치한 후에(4개가 필요하다.), 톰캣 디렉토리에 zip 파일의 압축을 풀어라. 제공된 예제 코드는 로드 밸런싱 정책으로 RoundRobinRule 방식을 사용한다. 만약 랜덤 리다이렉트 정책을 사용하고 싶다면, "tomcat50/webapps/balancer/WEB-INF/config" 디렉토리에 위치한 rules.xml 파일을 변경하라. RoundRobinRule 룰 엘리먼트를 주석처리하고, RandomRedirectRule 룰 엘리먼트의 주석을 제거하라. 또한 클러스터의 톰캣 인스턴스를 3개가 아닌 2개로 사용하고 싶다면, 세번째 룰을 주석처리하고 maxServerInstances의 값을 3에서 2로 변경해라.

주 : 필자는 밸런서와 예제 웹 어플리케이션만 남기고 톰캣 설치본에 포함된 다른 모든 웹 어플리케이션(jsp-examples, 등등)은 제거했다.

HTTP Request 흐름

예제 클러스터 환경에서의 웹 리퀘스트의 흐름은 다음과 같다:

시작 페이지 호출 (http://localhost:8080/balancer/testLB.jsp).
JSP는 밸런서 필터로 리퀘스트를 리다이렉트 시킨다. (URL: http://localhost:8080/balancer/LoadBalancer).
로드 밸런서(TC-LB)로서 실행되는 톰캣 서버는 웹 리퀘스트를 인터셉트하고 설정 파일에 정의된 로드 밸런싱 알고리즘에 의거하여 다음 사용 가능한 클러스터 멤버(TC01, TC02, TC03)로 리다이렉트 시킨다.
선택된 클러스터 멤버의 JSP 스크립트 sessiondata.jsp("clusterapp" 웹 어플리케이션에 위치한)가 호출된다.
만약 세션이 변경되었다면 ClusterAppSessionListener에 있는 세션 리스너 메소드가 세션 변경 이벤트를 기록하기 위해 호출된다.
sessiondata.jsp는 웹 브라우저에 세션의 자세한 데이터를 보여준다.(세션 ID, 마지막 접근 시간, 등등)
랜덤하게 하나 또는 2개의 클러스터 노드를 중지시킨다.(Ant 스크립트의 "stop.tomcat5x" 타겟을 호출함으로써)
사용가능한 클러스터 멤버중의 하나로 리퀘스트 fail over가 발생하는지 살펴보기 위해 위의 단계 1부터 7까지 반복한다. 또한 데이터의 손실없이 클러스터 멤버로 세션 정보가 복사되었는지 체크해 본다.

Figure 3은 웹 리퀘스트 흐름을 시퀀스 다이어그램으로 보여준다.

Figure 3. Cluster application sequence diagram (큰 화면으로 보기 위해 그림을 클릭하시오)

클러스터 설정

"clusterapp"라고 불리는 예제 웹 어플리케이션은 클러스터 내에서 실행하기 위해 만들어졌다. 세션 복제를 최적화하기 위해 모든 인스턴스는 같은 디렉토리 구조와 컨텐츠를 가진다.

클러스터 내의 톰캣 서버 인스턴스는 세션을 전송하기 위해 IP 멀티캐스트를 사용하기 때문에, 우리는 IP 멀티캐스트가 클러스터가 설정된 머신에 사용가능한지 확인할 필요가 있다. 이것을 검증하기 위해, Tomcat: The Definitive Guide 책에서 제공하는 MulticastNode라는 예제 자바 프로그램을 실행하거나 또는 멀티캐스트 서버와 클라이언트 프로그램을 작성하는 법에 관해 자바 소프트 웹 사이트에서 구할 수 있는 예제 튜토리얼을 참조하라.

클러스터 노드가 시작될 때, 클러스터 내의 다른 멤버들은 새로운 멤버가 클러스터에 추가됐다는 로그 메세지를 서버 콘솔에 보여준다. 비슷하게, 클러스터 노드가 다운될 때, 나머지 멤버들은 클러스터에서 멤버가 제거됐다는 로그 메세지를 콘솔에 보여준다. Figure 4는 클러스터 노드가 클러스터에서 제거되거나 또는 새로운 멤버가 클러스터에 추가됐을 때, 톰캣 콘솔의 로그 메세지를 보여준다.

Figure 4. 클러스터에서 멤버가 추가되거나 제거됐을 때의 로그 메세지

톰캣 서버에서 클러스터링과 세션 복제를 사용하기 위해 아래의 절차를 따라라:

세션에 저장할 모든 객체는 java.io.Serializable 인터페이스를 구현해야 한다.
server.xml 파일의 Cluster 요소의 주석을 제거하라. Cluster 요소의 useDirtyFlag와 replicationMode는 빈도수와 세션 복제 메카니즘의 최적화를 위해 사용된다.
server.xml 파일의 Valve 요소의 주석을 제거함으로써 ReplicationValve를 활성화시켜라. 만약 세션이 웹 클라이언트에 의해 변경된다면 ReplicationValve는 HTTP 리퀘스트를 인터셉트하고 클러스터 멤버들 사이의 세션 데이터를 복제하기 위해 사용된다. Valve 요소는 세션을 변경할 수 없는 리퀘스트(HTML 페이지나 이미지 파일과 같은)를 걸러내기 위해 사용할 수 있는 "filter" 속성을 가지고 있다.
단일 머신에서 3개의 톰캣 인스턴스가 실행되고 있기 때문에, tcpListenPort 속성은 각 톰캣 인스턴스에 대해 유니크하게 설정된다. mcastXXX로 시작하는 속성들 (mcastAddr, mcastPort, mcastFrequency, mcastDropTime)은 클러스터 멤버쉽 IP 멀티캐스트 핑을 위한 것이고, tcpXXX로 시작하는 속성들(tcpThreadCount, tcpListenAddress, tcpListenPort, tcpSelectorTimeout)은 TCP 세션 복제를 위한 것이라는 것을 아는 것은 중요하다. (아래의 "클러스터링 설정 파라미터" 테이블은 클러스터링을 사용하기 위해 톰캣 서버 인스턴스들의 설정이 어떻게 다른지 보여준다.)
web.xml 메타 파일(clusterappWEB-INF 디렉토리에 위치)은 요소를 가져야 한다. 특정 웹 어플리케이션에 대해 세션 상태 복제를 하기 위해, distributable 요소는 어플리케이션을 위해 정의될 필요가 있다. 이것은 세션 복제를 필요로 하는 웹 어플리케이션이 하나 이상이라면, 모든 웹 어플리케이션의 web.xml 파일에 distributable 를 추가할 필요가 있다는 것을 의미한다. Tomcat: The Definitive Guide 책의 톰캣 클러스터링 챕터는 이 주제에 대해 매우 훌륭하게 설명하고 있다.

Table 2. 클러스터링 설정 파라미터

Configuration Parameter	Instance 1	Instance 2	Instance 3	Instance 4
Instance Type	Load Balancer	Cluster Node 1	Cluster Node 2	Cluster Node 3
Code name	TC-LB	TC01	TC02	TC03
Home Directory	c:/web/tomcat50	c:/web/tomcat51	c:/web/tomcat52	c:/web/tomcat53
Server Port	8005	9005	10005	11005
Connector	8080	9080	10080	11080
Coyote/JK2 AJP Connector	8009	9009	10009	11009
Cluster mcastAddr	228.0.0.4	228.0.0.4	228.0.0.4	228.0.0.4
Cluster mcastPort	45564	45564	45564	45564
tcpListenAddress	127.0.0.1	127.0.0.1	127.0.0.1	127.0.0.1
Cluster tcpListenPort	4000	4001	4002	4003

주: 모든 클러스터 멤버는 동일한 물리적 머신에서 실행되고 있기 때문에, 같은 IP 주소를 사용한다 (127.0.0.1).

톰캣 인스턴스를 시작하고 중지하기 위해 Ant 스크립트를 사용하지 않는다면, 테스트 머신에 CATALINA_HOME 환경 변수를 설정하지 말아라. 이 변수가 설정되면, 모든 인스턴스는 톰캣 인스턴스를 구동하기 위해 같은 디렉토리(CATALINA_HOME 변수에 정의된)를 사용하려고 할 것이다. 그러한 결과로, 오직 최초의 인스턴스만 성공적으로 구동되고 나머지 인스턴스들은 포트가 이미 사용되고 있다는 바인드 익셉션 메세지와 함께 구동에 실패할 것이다: "java.net.BindException: Address already in use: JVM_Bind:8080".

로드 밸런서 설정

필자는 웹 리퀘스트를 리다이렉트 시키기 위해 룰 API를 상속받은 두개의 간단한 커스텀 로드 밸런싱 룰을 작성했다.(RoundRobinRule과 RandomRedirect) 이 룰들은 라운드 로빈과 랜덤 리다이렉트와 같은 로드 밸런싱 알고리즘에 의거한다. 여러분들도 가중치 기반, 마지막 접속 시간 등과 같은 다른 요소들을 기반으로 하는 비슷한 커스텀 로드 밸런싱 룰을 작성할 수 있다. 톰캣 로드 밸런서는 파라미터 기반의 로드 밸런싱 룰을 예제로 제공한다. 이것은 HTTP 리퀘스트의 파라미터에 따라 웹 리퀘스트를 다른 URL로 리다이렉트 시킨다.

TC-LB 인스턴스는 클러스터 멤버로 사용하기 않기 때문에, TC-LB의 server.xml의 cluster와 valve 요소는 주석을 제거하지 말아라.

테스팅 설정

세선 영속성 테스팅

세션 영속성 테스팅에서 주 목적은 클러스터 멤버가 웹 리퀘스트 처리 도중 다운됐을 때 세션 데이터가 손실되지 않았다는 것을 검증하는 것이다. sessiondata.jsp 페이지는 세션의 자세한 정보를 보여주기 위해 사용됐다. 이 스크립트는 또한 세션 속성을 추가/변경/제거 하기 위한 HTML 텍스트 필드를 제공한다. HTTP 세션에 몇 가지 속성을 추가한 후에, 필자는 랜덤하게 클러스터 노드를 중지시키고 나머지 사용가능한 클러스터 멤버에서 세션 데이터를 체크했다.

부하 테스팅

부하 테스팅의 목적은 커스텀 로드 밸런싱 알고리즘을 연구하고, 특히 하나 또는 그 이상의 노드가 다운됐을 때 웹 리퀘스트가 얼마나 효율적으로 클러스터의 노드에 분배되는지 알아보는 것이다. JMeter 부하 테스팅 툴이 다수의 동시 접속 웹 유저를 시뮬레이트 하기 위해 사용됐다.

클러스터 설정에서 로드 밸런싱을 테스트하기 위한 절차:

로드 밸런서와 톰캣 서버의 클러스터 인스턴스들을 구동한다.
시작 JSP 스크립트를 구동한다. (testLB.jsp).
랜덤한 간격으로 하나 또는 그 이상의 서버를 중지시켜서 서버 다운을 시뮬레이트한다.
부하 분배 패턴을 체크한다.
절차 1부터 4를 100번 반복한다

모든 로그 메세지는 tomcat_cluster.log (tomcat50/webapps/balancer 디렉토리에 위치) 라고 불리는 텍스트 파일에 기록된다. 시퀀스 다이어그램(Figure 2)에서 보여준 모든 웹 객체에 대한 응답 시간이 Log4J 메세지를 사용하여 기록되었다. 경과시간(밀리세컨드) 자료들이 수집되고 테이블 3에 자료로 나타나 있다. 필자는 테스트동안 응답 시간을 수집하는데 Designing Performance Testing Metrics into Distributed J2EE Apps에 기술된 것과 비슷한 방법론을 따랐다.

다음 테이블은 각각 부하 테스팅 (RoundRobinRule을 사용)의 경과시간과 부하 분배율 (RandomRedirectRule을 사용) 보여준다.

Table 3. 부하 테스팅 경과시간

#	Scenario	testLB.jsp (ms)	RoundRobinRule (ms)	sessiondata.jsp (ms)	Total (ms)
1	3개의 모든 서버 인스턴스가 실행중	54	76	12	142
2	2개의 서버 인스턴스가 실행중 (TC02은 중지상태)	55	531	14	600
3	1개의 서버 인스턴스만 실행중 (TC01, TC02 중지상태)	56	1900	11	1967

주: 모든 경과시간은 100명의 동시접속 유저의 부하를 바탕으로한 평균값이다.

Table 4. 랜덤 LB 정책을 사용했을 때 부하 분배

#	Scenario	TC01 (%)	TC02 (%)	TC03 (%)
1	3개의 모든 서버 인스턴스가 실행중	30	46	24
2	2개의 서버 인스턴스가 실행중 (TC02은 중지상태)	56	0	44

주: 부하 분배율은 100명의 동시접속 유저의 부하를 바탕으로한 값이다.

결론

세션 영속성 테스팅에서, 세션 속성을 추가한 후에 클러스터 노드 중의 하나가 다운되고 세션 속성은 서버 다운때문에 손실되지 않았음을 검증했다. 텍스트 파일에 기록된 세션의 자세한 정보는 세션 속성의 상세값을 연구하기 위해 사용됐다.

부하 테스팅에서 하나 또는 2개의 서버 인스턴스가 중지되고 오직 하나의 톰캣 인스턴스만 실행중일 때, 응답 시간은 3개의 인스턴스가 모두 사용가능 했을 때에 비해 길어졌다. 중지된 인스턴스가 재시작됐을 때, 로드 밸런서는 자동적으로 서버가 다시 리퀘스트를 처리할 수 있도록 사용가능하다는 것을 알아냈고 다음 웹 리퀘스트를 리다이렉트 시켰다. 이것은 응답 시간을 현저하게 향상시켰다.

클러스터 멤버가 사용가능한지 알아보기 위해(ServerUtil 클래스를 사용하여) 필자가 사용한 메카니즘은 가장 빠른 방법은 아니다. 더욱 복잡하고 견고한 fail-over 테크닉들이 실세계의 시나리오에서 사용되어야 할 것이다.

제시된 클러스터 설정의 한계점 중의 하나는 단지 하나의 로드 밸런서만 제공한다는 것이다. 로드 밸런서 역할을 하는 톰캣 인스턴스가 다운된다면 어떤 일이 벌어지나? 어떤 클러스터 멤버에게도 리퀘스트를 포워딩할 방법이 없고, 그러한 결과로 이것을 소위 Single Point of Failure(SPoF)라고 한다. 이 문제에 대한 한가지 해결책은 만약 주 로드 밸런서가 다운된다면 그 역할을 이어받을 대기 로드 밸런서로서 두번째 톰캣 인스턴스를 가지고 있는 것이다. 전형적인 HA(High Availability) 옵션은 SPoF 상황을 방지하기 위해 2개의 로드 밸런서를 가지고 있는 것을 포함한다.

예제 클러스터 설정에서, 모든 톰캣 인스턴스(로드 밸런서를 포함해서)는 단일 컴퓨터에서 실행되도록 설정되었다. 더 좋은 디자인은 로드 밸런서를 클러스터 멤버로부터 분리된 머신에서 실행하는 것이다. 또한 수평 확장 방법론의 이점과 클러스터 성능을 향상시키기 위해 클러스터 노드를 1 머신당 2개로 제한하는 것이다.

HTTP 세션 복제는 J2EE 웹 어플리케이션 서버에서 값비싼 작업이다. 클러스터링된 J2EE 환경에서 세션 관리의 포함은 웹 어플리케이션이 제품 환경에 구현될 때까지 기다리는 것보다 프로젝트의 분석과 디자인 단계에서 고려되어야 한다. 어플리케이션 코드는 클러스터 환경을 염두에 두고 디자인되어야만 한다. 만약 클러스터링 환경을 포함하는 것이 디자인 단계에서 고려되지 않는다면, 클러스터 설정에서 작동하기 위해 코드는 아마도 완전히 재작성될 필요가 있을 수도 있고, 이것은 매우 값비싼 노력이 될 것이다.

만약 웹 어플리케이션이 객체 캐슁 메카니즘에 대한 어떤 종류의 지원이라도 한다면, 클러스터 환경에서의 객체의 캐슁은 어플리케이션 개발의 초기단계부터 고려되어야만 한다. 캐쉬된 데이터를 모든 클러스터 노드에서 동기화된 상태로 가지는 것은 웹 유저에게 정확하고 최신으로 갱신된 비지니스 데이터를 제공하기 위해 핵심적이기 때문에 이것은 매우 중요하다. 또 다른 중요한 고려사항은 클러스터 내의 만료된 세션 데이터를 제거하는 것이다.

J2EE 클러스터가 성공적으로 설정되고 실행되면, 확장성과 고가용성의 이점을 제공하기 위해 그 관리와 유지보수가 매우 중요해질 것이다. 클러스터에 많은 노드를 가지고 있으면, 유지보수는 클러스터가 실행되도록 유지하고 어플리케이션의 변경을 모든 클러스터 노드에 적용하도록 순환해야 한다. 이러한 서비스를 제공하는 한가지 방법은 정기적으로 서버의 사용가능성을 체크하고 클러스터의 노드 중 어떤 것이 다운되면 공지하는 모니터링 서비스를 구현하는 것이다. 이 서비스는 다운된 노드를 감지하고 그것을 액티브 노드 목록에서 제거해서 리퀘스트가 다운된 노드로 가지 않도록 정기적인 간격으로 노드를 체크해야 한다. 이 서비스는 변경이 일어날 때마다 클러스터 내의 모든 서버를 업데이트하고 동기화하는 능력을 포함해야 한다. 웹 어플리케이션에 대한 모든 리퀘스트는 로드 밸런싱 시스템을 통해야 하기 때문에, 시스템은 액티브 세션의 수, 어떤 인스턴스에 연결된 액티브 세션의 수, 응답 시간, 피크 부하 시간, 피크 부하 동안의 세션의 수, 최저 부하 동안의 세션의 수 등을 알 수 있다. 모든 기록 정보는 최적화 성능을 위해 전체 시스템의 세밀한 조정에 사용될 수 있다. 로드 밸런싱 정책과 클러스터 노드의 효율성을 평가하기 위한 기초로서 이러한 결과를 보여주는 리포트가 생성되야만 한다.

현재 클러스터와 로드 밸런서 설정에 필요로 하는 모든 설정은 설정 파일(server.xml과 rules.xml)을 조작함으로써 수동으로 이루어 졌다. 자카르타 그룹이 클러스터링과 로드 밸런싱 설정을 관리하기 위해 필요로 하는 설정의 변경을 수행할 수 있는 웹 기반의 클러스터 관리 GUI 툴을 제공한다면 매우 도움이 될 것이다.

참고 자료

Tomcat 5 Home Page
Clustering Home Page on Tomcat site
Load Balancer Home Page on Tomcat site
Tomcat: The Definitive Guide by Jason Brittain and Ian F. Darwin
Java Performance Tuning, 2nd Edition by Jack Shiraji
Creating Highly Available and Scalable Applications Using J2EE, The Middleware Company, EJB Essentials Training Class Material

Srini Penchikala는 Flagstar Bank의 정보 시스템 주제 관련 전문가이다.

[출처] [번역] Clustering and Load Balancing in Tomcat 5, Part 2|작성자 Thomas

tag : tomcat

[펌글] Clustering and Load Balancing in Tomcat 5, Part 1

2009-09-17T01:21:47Z

Tomcat 5에서의 클러스터링과 로드 밸런싱, Part 1

by Srini Penchikala
03/31/2004
번역 허태명

최신 버전의 톰캣 서블릿 컨테이너는 확장성 있고 견고한 웹 어플리케이션을 배치하는데 필수적인 클러스터링과 로드 밸런싱을 제공하고 있다. 이 글의 첫번째 파트에서는 클러스터링과 로드 밸런싱 기능에 관한 설치, 설정, 사용법, 확장에 관한 개괄적인 면을 살펴볼 것이다. 두번째 파트에서는 톰캣 서버에서 클러스터링 인스턴스를 설정하는데 관련된 절차를 보여주는 예제 웹 어플리케이션을 소개하고, 클러스터 환경에서 메모리 복제를 사용하는 세션 퍼시스턴스에 대해 살펴볼 것이다.

톰캣 5 서버는 룰 기반의 로드 밸런서 어플리케이션이 탑재되어 있다. 웹 리퀘 스트를 리다이렉트 시키기 위하여 라운드-로빈과 랜덤 알고리즘을 기반으로 두 개의 간단한 커스텀 로드 밸런싱 룰(룰 API를 상속받은)이 작성되었다. 클러스터 환경 에서 실행되는 예제 웹 어플리케이션의 퍼포먼스 벤치마크가 제공된다. 로드 밸런싱 메카니즘을 살펴보기 위해 다수의 웹 유저를 시뮬레이트해주는 로드 테스팅 툴인 JMeter가 사용되었다.

이 글은 톰캣 서블릿 컨테이너에서의 클러스터링 능력을 보여주는데 주로 촛점을 두고 있기 때문에, 여기서 EJB, JNDI, JMS 객체를 복제하는 J2EE 어플리케이션의 클러스터링에 관해서는 다루지 않을 것이다. EJB와 JMS 클러스터링을 위하여 "J2EE Clustering" 과 "J2EE Clustering with JBoss"을 참조하라

Large-Scale 시스템 디자인

엔터프라이즈 웹 포탈 어플리케이션은 웹 사이트를 방문하는 수 천명의 사용자에게 서비스하기 위해 웹 서비스의 확장성과 고가용성(High Availability : HA) 을 제공해야 한다. 확장성은 클러스터에 서버를 추가함으로써 늘어나는 사용자의 수를 지원하기 위한 시스템의 능력이다. 고가용성은 기본적으로 시스템에 잉여 자원을 제공하는 것이다. 만약 어떤 클러스터 멤버가 어떠한 이유로 실패한다면, 클러스터의 또 다른 멤버가 투명하게 웹 리퀘스트를 이어받을 수 있다. 클러스터 환경에 웹 포탈 어플 리케이션을 배치하는 것은 우리에게 웹 포탈 어플리케이션에서 요구하는 확장성, 신뢰성, 고가용성을 성취할 수 있는 능력을 준다. 기본적으로, 클러스터링의 주 목적은 시스템에서 1개의 문제점(Single Point of Failure : SPoF)때문에 발생하는 웹 사이트의 어떤 장애도 방지하도록 하는 것이다.

Large-scale 시스템 디자인은 엔터프라이즈 어플리케이션 환경에서 최소한의 다운 타임과 최대한의 확장성을 보증하는 미션-크리티컬한 서비스를 제공한다. 1개의 서버를 운영하는 것보다는 다수의 협력하는 서버를 운영해라. 확장성을 위해 당신은 클러스터 내에 추가적인 머신을 포함해야만 하고, 다운타임을 최소화하기 위해 당신은 클러스터의 모든 컴포넌트에 잉여 자원이 있는지 확인해야 한다. Large-scale 시스템의 주요한 요소는 로드 밸런싱, 결함 허용(fault tolerance), 세션 상태 영속성(session state persistence) 기능을 포함하는 클러스터링이다. 일반적으로 웹 어플리케이션에서 하드웨어 또는 소프트 웨어 기반의 로드 밸런서가 클러스터 내의 어플리케이션 서버 앞단에 위치한다. 이 로드 밸런서들은 웹 트래픽을 적당한 클러스터 멤버로 리다이렉팅 시키고 동시에 서버의 장애요소를 찾아내어 클러스터 노드 사이의 부하를 분배하기 위해 사용된다.

클러스터링

클러스터는 J2EE 어플리케이션에서 마치 하나의 엔터티인 것처럼 투명하게 운영되는 어플리케이션 서버들의 그룹으로 정의된다. 클러스터링은 두 가지 방법으로 구현될 수 있다: 수직 확장(Vertical Scaling) 과 수평 확장(Horizontal Scaling). 수직 확장은 1개의 머신에 운영되는 서버의 갯수를 증가시키는 것이고, 반면에 수평 확장은 클러스터 내에 머신의 갯수를 증가시키는 것이다. 오직 1대의 머신에 비해 클러스터 환경에 포함된 다수의 머신이 있기 때문에 수평 확장이 수직 확장보다 더 신뢰성이 있다. 수직 확장에서는 머신의 프로세싱 파워, CPU 사용과 JVM Heap 메모리의 설정이 얼마나 많은 서버 인스턴스가 한 대의 머신(또한 server-to-CPU ratio로도 알려져 있는)에서 운영될 수 있는지 결정하는 주요한 요소이다.

J2EE 클러스터 내에 있는 서버들은 보통 세가지 옵션 중에 한가지를 사용하여 설정된다. 독립적 접근방식에 있어서 각 어플리케이션 서버는 자신의 어플리케이션 파일들의 복사본을 가지고 자기 자신의 파일 시스템을 가지고 있다. 또 다른 접근법은 공유된 파일 시스템을 사용하는 것이다. 공유된 파일 시스템에서 클러스터는 모든 어플리케이션 서버가 어플리케이션 파일을 획득하기 위해 사용할 단일의 저장장치를 사용한다. 세번째 설정 접근방식은 관리 접근법이라고 불린다. 이 방식에서는 관리 서버가 어플리케이션의 컨텐츠에 관한 접근을 통제하고 적당한 어플리케이션 컨텐츠를 관리되는 서버로 "보내는데(pushing)" 책임이 있다. 관리 서버는 클러스터 내의 모든 서버가 어플리케이션을 사용가능하다는 것을 보장한다. 관리 서버는 또한 어플리케이션이 배치될 때 모든 서버를 업데이트하고 어플리케이션이 제거될 때 모든 서버의 어플리케이션을 제거한다.

클러스터링은 데이터베이스 티어를 포함하여 J2EE 어플리케이션의 다양한 티어에서 이뤄질 수 있다. 어떤 데이터베이스 벤더는 클라이언트(일반적으로 서블릿 컨테이너나 또는 어플리케이션 서버)가 데이터를 가져오기 위해 어떤 데이터베이스에 연결되어 있는지 알 필요가 없도록 클라이언트 투명성을 제공함으로써다수의 데이터베이스 사이에서 데이터 복제를 지원하는 클러스터링된 데이터베이스를 제공한다. JDBC 클러스터링의 예로는 오라클 9i의 Real Application Clusters (RAC)과 Clustered JDBC (C-JDBC)가 있다. RAC는 데이터베이스 커넥션의 fail over를 지원하고 투명하게 fail over된 데이터베이스 노드에 JDBC 커넥션과 데이터베이스 요청을 재연결한다. C-JDBC는 웹 어플리케이션이 JDBC 드라이버를 통해 투명하게 데이터베이스 클러스터에 접근하게 해주는 오픈 소스 데이터베이스 클러스터이다. C-JDBC 구현은 클러스터에서 데이터베이스 노드들 사이의 JDBC 커넥션을 로드 밸런싱할 뿐만 아니라, 보조 데이터베이스 서버로 fail over 처리를 해준다.

톰캣에서의 클러스터링

톰캣 이전 버전(버전 4.1)에서는 서드-파티의 JAR 파일을 사용하여 클러스터링을 할 수 있었다; 그것은 클러스터에서 다수의 톰켓 인스턴스를 운영하기 위하여 설치하고 설정하는 것이 쉽지 않았다. JavaGroups는 오픈 소스 서블릿 컨테이너(톰캣)과 어플리케이션 서버(JBoss)에 클러스터링 기능을 추가해주는 잘 알려진 대안이다. 그러나 톰캣 최신 버전에서 클러스터링은 주요 설치 패키지의 일부가 되었다. 이것은 서드-파티 클러스터링 구현을 톰캣 서버와 연동하기 위한 추가의 노력을 최소화해 준다.

전형적인 클러스터 환경에서 클러스터 내의 서버들은 협력하고 상태를 복제하기 위해 서로 통신을 해야 할 필요가 있다. 이러한 그룹 커뮤니케이션은 point-to-point RMI (TCP-IP) 또는 IP 멀티캐스트를 통하여 이루어 진다. 대부분의 J2EE 어플리케이션 서버들(JBoss, 오라클, 웹로직, 볼랜드와 같은)은 클러스터 내에서 다른 서버로 상태/업데이트/심장박동(heartbeats : 서버의 이상유무)을 전송하기 위하여 모두 IP 멀티캐스트 통신을 사용한다. 이제 톰캣에서 클러스터 멤버들 사이에 통신이 어떻게 이루어 지는지 살펴보자: 모든 클러스터 멤버는 멀티케스트 ping 메세지를 사용하여 서로 통신한다. 각 톰캣 인스턴스는 세션 복제를 위한 IP 주소와 TCP 리스너 포트를 전파하는 메세지를 전송할 것이다. 만약 한 인스턴스가 주어진 시간 단위안에 메세지를 받지 못하면, 그 인스턴스는 다운된 것으로 간주될 것이다.

클러스터링에서 또 다른 잘 알려진 개념은 farming이라고 불리는데, 웹 어플리케이션에서 cluster-wide hot deployment를 제공한다. 서버 farm에서 웹 어플리케이션은 클러스터 내의 오직 한 노드의 어플리케이션 WAR 파일을 복사함으로써 배치된다; farming은 전체 클러스터에서 웹 어플리케이션의 배치를 다룰 것이다. 유사하게 한 개의 클러스터 노드에서 WAR 파일을 제거하는 것은 클러스터의 모든 노드에서 웹 어플리케이션을 제거하게 할 것이다. 톰캣 클러스터링 문서에서는 톰캣의 다음 버전에서 farming 기능을 지원할 것을 언급하고 있다.

로드 밸런싱

로드 밸런싱(또한 high availability switch over으로 알려져 있는)은 서버 부하가 서버 클러스터 내에서 다른 노드들로 로드 밸런싱 정책에 의거하여 분배되도록 하는 메카니즘이다. 한 개의 서버에서 어플리케이션을 실행하기 보다는, 시스템은 어플리케이션 코드를 동적으로 선택한 서버 상에서 실행한다. 클라이언트가 서비스를 요청할 때, 협력하는 서버들 중의 하나(또는 그 이상)이 요청을 수행하도록 선택된다. 로드 밸런서는 클러스터 내에서 요청을 받아들이는 유일한 진입점으로서, 또 개별적인 웹 또는 어플리케이션 서버의 트래픽 관리자로서 역할을 수행한다.

두 가지 잘 알려진 클러스터에서 로드 밸런싱 방법은 DNS round robin과 하드웨어 로드 밸런싱이다. DNS round robin은 하나의 논리적인 이름을 제공하고 클러스터 내에서 노드들의 어떤 IP 주소를 돌려 받는다. 이 옵션은 비용이 많이 들지 않고, 단순하며 설정하기 쉽다. 하지만 DNS round robin은 서버에 어떤 유연성이나 고가용성도 제공하지 않는다. 반면에 하드웨어 로드 밸런싱은 가상 IP 어드레싱을 통해 DNS round robin의 한계점을 해결한다. 로드 밸런서는 클러스터를 위하여 하나의 IP 주소를 제공하고 그것은 클러스터 내의 각 머신에 매핑된다. 로드 밸런서는 각 요청을 받고 클러스터 내에서 다른 머신들에게 헤더를 다시 써준다. 만약 우리가 클러스터에서 어떤 머신을 제거한다면, 변화는 즉각적으로 나타난다. 하드웨어 로드 밸런싱의 장점은 서버의 유연성 고가용성이다; 단점은 매우 비용이 많이 들고 설정하기 복잡하다는 것이다.

로드 밸런싱을 수행하기 위해 부하를 분배하는 정책을 정의하는 알고리즘은 간단한 라운드 로빈 알고리즘에서 매우 복잡한 알고리즘까지 다양하다. 일반적으로 많이 쓰이는 알고리즘은 다음과 같은 것이 있다:

Round-robin
Random
Weight-based
Minimum load
Last access time
Programmatic parameter-based (로드 밸런서는 입력 인자에 따라 서버를 선택할 수 있다)

로드 밸런싱 알고리즘은 통계적 변수, 속도, 단순성에 영향을 미친다. 예를 들어, weight-based 알고리즘은 "Load Balancing Web Applications."을 참조하면 다른 알고리즘보다 더 긴 계산시간을 가지고 있다.

톰캣에서의 로드 밸런싱

이전 버전의 톰캣에서는 로드 밸런싱 기능이 제공되지 않았다. 아파치 웹서버와 톰캣 서블릿 컨테이너를 함께 연동하는 것은 웹 리퀘스트를 조절하고 로드 밸런싱을 하는 잘 알려진 방법이다. 아파치-톰캣 설정에서 Tomcat Worker로 불리는 톰캣 인스턴스가 로드 밸런싱을 구현하기 위해 설정된다.

톰캣 5는 세 가지 방법으로 로드 밸런싱을 제공한다: JK native connector의 사용, mod_proxy와 mod_rewrite를 아파치 2와 사용, 그리고 balancer 웹 어플리케이션의 사용이다. 이 글에서 우리는 클러스터 내에서 웹 리퀘스트를 다른 노드들로 리다이렉트 시키는 balancer 웹 어플리케이션을 사용하는 세번째 옵션을 설명하는데 중점을 둘 것이다. 로드 밸런서 어플리케이션은 클러스터 내의 다음 이용가능한 멤버로 웹 리퀘스트를 리다이렉트 시키는 서블릿 필터 메카니즘을 사용하는 룰 기반의 어플리케이션이다. 서블릿 필터는 서블릿 2.3 스펙에서 소개되었다. 이 필터는 웹 어플리케이션의 JAAS 인증, 암호화, 로깅, 감사(auditing), 데이터 압축, XML 컨텐츠를 변환하는 XSLT 필터 등과 같은 다양한 작업에 사용된다. 톰캣 밸런서 웹 사이트에 언급된 것과 같이, 밸런서 어플리케이션은 다른 견고한 로드 밸런싱 메카니즘을 대체하기 위해 디자인된 것은 아니다. 그보다 톰캣 밸런서 어플리케이션은 다수의 서버 사이에서 트래픽을 조절하는 단순하고 확장가능한 방법이다. 여러가지 룰을 사용하여 로드 밸런싱이 다양한 방법으로 어떻게 구현되는지 이해하기 위하여 밸런서 어플리케이션에 제공되는 샘플 자바 클래스를 살펴보라.

로드 밸런싱은 다양한 룰과 리다이렉션 URL을 포함하고 있는 룰 설정 파일(rules.xml이라고 불리는)을 생성함으로써 사용 가능해 진다. 밸런서 필터는 rules.xml 파일에 정의되어 있는 것과 같은 순서로 룰을 체크함으로써 리퀘스트를 어디로 리다이렉트할지 결정하기 위해 RuleChain을 체크한다. Rule이 기준에 맞으면, 필터는 검사를 중단하고 리퀘스트를 해당하는 룰에 정의된 URL로 리다이렉트시킨다.

결함 허용(Fault Tolerance)

결함 허용은 클러스터 내의 어떤 서버가 다운되면 가능한한 엔드 유저에게 투명하게 이용가능한 다른 서버로 fail over하기 위하여 계산을 허용하는 시스템의 능력이다. 이상적인 fail over 시나리오는 클러스터 서비스가 리퀘스트를 처리하기위해 서버 인스턴스가 더 이상 사용 불가능할 때를 감지하고 그 인스턴스에 대해 리퀘스트 보내는 것을 멈추는 것이다. 또한 정기적으로 클러스터 멤버가 다시 사용가능한지 알아보도록 점검하고, 그렇다면 자동적으로 그 멤버를 액티브 클러스터 노드 풀에 추가해야만 한다.

톰캣에서의 결함 허용

톰캣 5는 클러스터 멤버가 다운됐을 때를 감지하는 내장된 fail over 메카니즘은 제공하지 않는다. 그러나 희망적으로 톰캣의 다음 버전은 웹 리퀘스트에 대해 서비스할 준비가 되어 있는지 확인하기 위해 특정 클러스터 멤버가 이용가능한지 감지하는데 사용될 수 있는 fail over 기능을 제공할 것이다.

전형적으로 클러스터링 솔루션에서 제공되는 fail over 기능은 두 단계가 있다:

Request-level fail over: 만약 클러스터 내의 서버 중의 하나가 다운된다면, 그 이후의 모든 리퀘스트들은 클러스터 내의 나머지 다른 서버로 리다이렉트되야만 한다. 이것은 서버 상태를 추적하고 응답하지 않는 서버에 리퀘스트를 보내는 것을 피하기 위해 heartbeat 메카니즘을 사용하는 것을 포함한다. 우리의 클러스터 설정에서 로드 밸런서로서 사용되는 톰캣 인스턴스는 웹 리퀘스트를 클러스터 내의 다른 노드로 포워딩함으로써 Request-level fail over를 수행할 수 있다.
Session-level fail over: 웹 클라이언트는 HTTP 서버에 의해 유지되는 세션을 가질 수 있다. Session-level fail over에서 클러스터 내의 서버 중의 하나가 다운된다면, 클러스터 내의 다른 서버가 최소한의 연속성 손실만으로 최초의 서버에 의해 다뤄진 세션을 가지고 계속 작업을 수행할 수 있어야 한다. 이것은 클러스터 내에 서버간의 세션 데이터의 복제를 포함한다. 세션 복제 능력을 가지고 있는 톰캣 클러스터는 session-level fail over를 수행할 수 있다.

세선 상태 영속성(Session State Persistence)

Fail over와 로드 밸런싱은 클러스터 내에 다른 서버로 세션 상태가 복제될 수 있는 것을 필요로 한다. 세션 상태 복제는 클라이언트 세션이 최초 생성된 원래 서버가 다운됐을 때 클러스터 내의 다른 서버로부터 클라이언트의 세션 정보를 동일하게 얻을 수 있도록 한다. 상태는 시스템 상태이거나 어플리케이션 상태(어플리케이션 상태는 HTTP 세션에 저장된 객체나 데이터를 포함한다)일 수 있다. 세션 복제의 주 목적은 클러스터 멤버가 다운되거나 어플리케이션의 업데이트 또는 시스템 유지보수를 위해 멈췄을 때 세션의 세세한 사항까지 잃지 않도록 하는 것이다.

세션 영속성에 관한한, 클러스터링은 간단한 시나리오가 될 수 있다. 이 시나리오에서 클러스터 멤버는 다른 클러스터 멤버의 세션 상태에 관한 알고 있는 바가 전혀 없다. 그리고 유저 세션은 전적으로 로드 밸런서에 의해 선택된 한 서버에 존재한다. 이것은 세션 데이터가 웹 리퀘스트를 받은 클러스터 멤버에 존재하기 때문에 고착된(sticky) 세션(또한 session affinity이라고 알려져 있는)이라고 불린다.

반면에 클러스터는 세션 상태를 정기적으로 모든(하나 또는 두 개 권장) 백업 클러스터 멤버로 전달해서 각 클러스터 멤버가 다른 클러스터 멤버의 세션 상태를 완벽하게 알고 있도록 구현될 수 있다. 이러한 종류의 세션은 복제된(replicated) 세션으로 알려져 있다.

세션 영속성을 구현하는 세가지 방법이 있다:

Memory-to-memory replication
File System session persistence, 중앙집중화된 파일 시스템에 세션 정보가 read/write 된다.
Database session persistence, 세션 데이터가 JDBC 데이터 저장소에 저장된다.

메모리 세션 복제에서 HttpSession 내의 객체는 상태가 변할 때마다 개별적으로 백업 서버에 직렬화 된다. 반면에 데이터베이스 세션 영속성(Database session persistence)에서 세션에 저장된 객체는 객체들중 어느 하나의 상태가 변할 때 함께 직렬화 된다.

데이터베이스/파일 시스템 세션 영속성의 주요 단점은 대형 객체나 수많은 객체를 HttpSession에 저장할 때 확장성이 제한된다는 것이다. 유저가 HttpSession에 객체를 추가할 때마다, 세션 내의 모든 객체들은 직렬화되고 데이터베이스타 공유된 파일 시스템에 저장된다.

톰캣에서의 세션 복제

현재 버전의 톰캣 서버에서 세션 복제는 세션 상태를 all-to-all 복제하는 것이다. 이것은 모든 클러스터 멤버에게 항상 세션 속성들을 전달하는 것을 의미한다. 이 알고리즘은 클러스터가 작을 때 효율적이다. 대형 클러스터를 위해서 다음 톰캣 릴리즈에서는 하나 또는 아마도 두 개의 백업 서버에만 세션을 저장하는 주-보조 세션 복제 기능을 지원할 것이다.

톰캣에서 세션 복제 메카니즘은 세가지 종류가 있다:

톰캣 5(server/lib/catalina-cluster.jar)에 내장되어 있는 SimpleTcpCluster (org.apache.catalina.cluster.tcp 패키지)과 함께 메모리 복제에서의 사용.
공유된 데이터베이스(org.apache.catalina.session.JDBCStore)에 세션을 저장하는 세션 영속성의 사용.
공유된 파일 시스템(catalina-optional.jar의 일부인 org.apache.catalina.session.FileStore)에 세션 상태 저장하기

J2EE 클러스터를 구현하는데 있어서 고려해야 할 요소

J2EE 클러스터를 디자인할 때 고려해야할 요소는 많이 있다. 다음은 large-scale J2EE 시스템 디자인에서 고려해야할 요소들의 목록이다.(이 목록은 EJB 필수 트레이닝 문서 중 "Creating Highly Available and Scalable Applications Using J2EE"에서 가져왔다.)

클러스터링

어떤 종류의 클러스터가 구현되야만 하는가: 수직 확장 또는 수평 확장인가?
어떤 티어에서 클러스터링이 구현되야만 하는가: 웹서버, 서블릿을 위한 서블릿 컨테이너, JSP, HTTP 세션 객체; 또는 EJB, JMS, JNDI 객체를 위한 어플리케이션 서버 또는 데이터베이스 클러스터링?

로드 밸런싱

서버가 선택될 때(예, 활용성? : affinity): 매 리퀘스트마다, 매 트랜잭션마다, 또는 매 세션마다?
어떻게 서버가 선택되는가(예, 로드 밸런싱 정책): 무작위, 라운드-로빈(round-robin), 가중치 기반(weight-based), 가장 덜 부하가 걸린 서버(least loaded server), 또는 어플리케이션에 의해?
로드 밸런싱이 어디서 이루어 지는가: 한 곳 또는 여러 곳, 클라이언트 단 또는 서버 단?

결함 허용(Fault Tolerance)

어떻게 서버가 문제를 감지하는가?
fail over하고 다른 서버로 리퀘스트를 시도할 적당한 시간은 언제인가?
문제가 생긴 노드의 시스템과 어플리케이션의 상태는 어떻게 할 것인가?

세션 상태 영속성(Session State Persistence)

상태는 어떻게 통신되는가?
얼마나 자주 통신하는가?
객체의 상태는 어떻게 구체화(materialize)되는가?
상태 영속성 메카니즘은 효율적인가?
복제된 상태의 일관성이 있는가?
세션 상태를 복제하는데 있어서 어떤 네트웍 제한요소가 있는가?

제안된 클러스터 설정

아래 목록은 제안된 클러스터 환경에서 필자가 달성하기 원했던 주요한 목적이다:

클러스터는 고도의 확장성이 있어야 한다.
클러스터는 결함 허용이 가능해야 한다.
클러스터는 동적으로 설정이 가능해야 한다. 그것은 클러스터를 프로그램적으로(자바 코드를 변경) 보다는 선언적으로(설정 파일을 변경) 관리하기 쉽다는 것을 의미한다.
클러스터는 자동 클러스터 멤버 감지 기능을 제공해야 한다.
클러스터는 메모리 세션 상태 복제를 위해 fail over와 로드 밸런싱 기능을 가지고 있어야 한다.
클러스터는 플러그인 방식/설정하기 쉬운 로드 밸런싱 정책을 가지고 있어야 한다.
클러스터는 클러스터 멤버가 그룹에 합류하거나 떠날 때 그룹 멤버쉽 공지를 수행해야 한다.
멀티캐스트를 통하는 동안 메세지 전송의 손실이 없어야 한다.
클러스터링은 웹 어플리케이션과 서버에 함께 연동되어야 한다. 클라이언트와 서버 양쪽에 투명성을 제공해야 한다. 클라이언트 투명성은 클라이언트가 클러스터링된 서비스나 클러스터가 어떻게 설정되었는지 모르는 것을 의미한다. 클러스터는 각각의 서비스들로 보다는 한 개의 것으로서 확인되고 접속되어야 한다. 서버 투명성은 서버의 어플리케이션 코드가 클러스터 내에 있는지 모르는 것을 의미한다. 어플리케이션 코드는 다른 클러스터 멤버와 통신할 수 없다.

결론

이 글의 파트 2에서 우리는 이러한 목적을 달성하기 위해 클러스터를 배치하는 법(다수의 톰캣 서버 인스턴스를 운영함으로써)을 살펴볼 것이다. 또한 톰캣 5에서 클러스터 아키텍쳐와 세션 복제를 가능하게 하는 설정의 자세한 부분에 관하여 논할 것이다.

Srini Penchikala는 Flagstar Bank의 정보 시스템 주제 관련 전문가이다.

[출처] [번역] Clustering and Load Balancing in Tomcat 5, Part 1|작성자 Thomas

tag : tomcat

퍼온글:아파치와 톰캣을 활용한 대용량 웹서비스 운영

2009-09-17T00:12:18Z

[Open developerWorks]

아파치와 톰캣을 활용한 대용량 웹서비스 운영

장윤기 tingle@hanmail.net

직장 생활 8년 차의 개발자로, 초기엔 유닉스 C 프로그램을 했고 1999년부터 본격적으로 자바를 이용한 개발을 수행했다. 하이텔 자바동호회 활동을 시작으로 마이크로소프트웨어, 프로그램세계 등의 잡지에 자바 관련 각종 기고를 한바 있다. 최근엔 http://www.javamania.pe.kr/이라는 홈페이지를 통해 자신의 글들을 공유하고 있다.

난이도 : 초급
2006년 10월 17일

[오픈 디벨로퍼웍스]는 여러분이 직접 필자로 참가하는 코너입니다. 그 첫 번째로 장윤기님이 기고하신 아파치와 톰캣의 연동을 통해 대용량 웹서비스의 처리를 안정적으로 구현하는 방법을 가상의 예제와 함께 살펴봅니다.

웹 개발자에게 있어 톰캣은 JSP를 배우거나 간단한 테스트를 하는 정도의 웹 컨테이너로 생각하는 경우가 많다. 하지만 근래 들어 기업 및 대형 포탈에서 상용 서비스를 위한 웹 컨테이너로서 톰캣을 선택해, 성공적으로 적용한 사례들이 늘고 있다. 톰캣에서 안정적인 웹 서비스를 제공하기 위해서 지원하는 기능은 5가지가 있다. 아파치 웹서버와 연동, 로드밸런싱, 세션 클러스터링, 데이터베이스 처리, 모니터링 및 관리 등이 그것이다.
이 문서에서는 로드밸런싱과 세션 클러스터링 위주로 설명을 할 것이며, 다음에 기회가 된다면 다른 부분에 대해서도 자세히 알아보도록 하겠다.

아파치 웹 서버와 톰캣의 연동

일반적으로 정적인 페이지를 서비스할 때는 웹서버가 훨씬 더 좋은 성능을 발휘한다. 또한 이렇게 역할 분담을 함으로 톰캣에 가중되는 부하를 줄여주는 효과도 얻을 수 있다. 아파치웹서버와 톰캣을 연동하는 것을 일반적으로 ‘커넥터(Connector)'라고 부르며, 여기에는 WARP 커넥터, JK 커넥터 그리고 JK2 커넥터가 있다. 이중에서 WARP와 JK2는 공식 커넥터에서 제외되었고 현재 남아 있는 것은 JK 커넥터뿐이다. 그럼 먼저 JK 커넥터를 이용해서 아파치 웹서버와 톰캣을 연동해 보도록 하겠다.
아파치 웹사이트에서 바이너리 혹은 소스 코드를 다운로드 받도록 하자. 유닉스 혹은 리눅스는 mod_jk.so이며 윈도우용은 mod_jk.dll이다. 이 파일을 아파치 웹서버의 modules 디렉토리에 저장한다(주의, 아파치 웹서버를 컴파일해서 사용하는 경우는 컴파일시에 DSO 기능이 가능하도록 설정해줘야 한다). 저장을 한 후에 아파치 웹서버에 해당 모듈을 인식시켜야 하며 아파치 웹서버의 httpd.conf 파일에 다음 내용을 추가하도록 하자.

리스트 1. httpd.conf

        ...
LoadModule jk_module modules/mod_jk.so    # 모듈 추가
JkWorkersFile "conf/workers.properties"   # JK 설정 파일 위치 및 이름
 
JkLogFile "logs/mod_jk.log"               # JK에 대한 로그 파일 위치
JkLogLevel info                           # 로그 레벨 지정
JkLogStampFormat "[%a %b %d %H:%M:%S %Y]"   # 로그 시간 포맷 지정
JkRequestLogFormat "%w %V %T"             # 로그 내용 포맷
JkMount /* loadbalancer                   # URL 링크 -> 모든 요청을 톰캣으로 지정
JkMount /servlet/* loadbalancer           # URL 링크 -> servlet 요청을 톰캣으로 지정
...

위와 같은 설정을 하게 되면 아파치 웹서버로 들어온 모든 요청을 톰캣으로 재전송 하게 된다. 만일 JSP와 서블릿만 톰캣에서 서비스를 하고 나머지는 아파치 웹서버에서 서비스 하고자 한다면 다음과 같이 수정하면 된다.

  
JkMount /*.jsp loadbalancer                # URL 링크 -> *.jsp 요청을 톰캣으로 지정 
JkMount /servlet/* loadbalancer           # URL 링크 -> servlet 요청을 톰캣으로 지정

httpd.conf에는 위의 내용이 전부이다. 그럼 이제 workers.properties 파일을 작성해 보도록 하겠다. 이 파일이 실제 로드밸런싱을 위한 설정이 되겠다.

위로

라운드 로빈 방식의 로드밸런싱 설정

톰캣에서 제공하는 로드밸런싱은 정확히 톰캣 자체에서 제공하는 것이 아니라 아파치 웹서버와 연동되는 커넥터에 의해서 제공된다(로드밸런싱은 JK, JK2 커넥터에서만 제공된다). 현재는 라운드 로빈(Round Robin) 방식만이 제공되며 로드밸런싱에 대한 설정은 workers.properties 파일에서 정의하게 된다.

리스트 2. workers.properties

  
worker.list=tomcat1, tomcat2, loadbalancer
 
worker.tomcat1.type=ajp13
worker.tomcat1.host=localhost
worker.tomcat1.port=11009
worker.tomcat1.lbfactor=100
 
worker.tomcat2.type=ajp13
worker.tomcat2.host=localhost
worker.tomcat2.port=12009
worker.tomcat2.lbfactor=200
 
worker.loadbalancer.type=lb
worker.loadbalancer.balanced_workers=tomcat1,tomcat2

worker라는 개념은 톰캣의 프로세스로 보면 된다. 즉 worker를 설정하는 구성 요소는 JK 커넥터를 연결하는 방식(JK는 ajp13을 이용한다), 톰캣이 실행되어 있는 IP 혹은 도메인, ajp13 서비스 포트, 그리고 작업 할당량이다. 여기서 주의 깊게 볼 것이 작업 할당량인데 로드밸런싱 시에 lbfactor라는 작업량의 비율을 보고 라운드 로빈 방식의 서비스를 제공하게 된다. 여기서는 tomcat1과 tomcat2를 1대 2의 비율로 작업량을 할당한 것이다.
그럼 이제 남은 작업은 2개의 톰캣 프로세스를 실행시키는 것이다. 톰캣 프로세스를 여러 개 띄우는 방법은 2가지가 있다.

톰캣을 2개 설치해서 기동시킨다. 이때 포트 충돌을 피하기 위해 서버 포트, AJP13과 HTTP 1.1 커넥터 포트 2개를 충돌되지 않게 재정의 한다.
하나의 톰캣에 2개의 서비스를 정의하고 톰캣을 기동시킨다. 이때 AJP13과 HTTP1.1 커텍터 포트 2개를 충돌되지 않게 재정의 한다.

먼저 2개의 바이너리를 설치했다고 가정하면 각각의 톰캣은 다음과 같은 형태의 server.xml 파일로 적용해 준다.

리스트 3. server.xml

리스트 4. server.xml

리스트 3은 tomcat1의 환경 설정이고 리스트 4는 tomcat2의 환경 설정이다. 두 환경 설정의 차이는 3개의 포트번호와 태그의
jvmRoute 속성이다. 태그의 포트는 톰캣을 종료 시키는 작업을 할 때 사용하는 것이며 태그의 포트들은 아파치를
통하지 않고 직접 톰캣에 접속할 경우와 아파치와 연계하여 JK 커넥터와 연동할 때 사용하는 포트이다. 마지막으로 태그는 JK 커넥
터에서 로드밸런싱을 수행할 때 해당 값을 구분자로 활용하게 되는데 이 값을 반드시 다른 톰캣 프로세스와 다른 이름으로 지정해야 한다.
지금까지의 환경 설정은 하나의 아파치 웹서버와 두 개의 톰캣 간의 연계를 위한 것이며 톰캣은 동일한 하드웨어 장비에 설치되어 있다는
가정하에 적용한 것이다. 만일 각각의 톰캣이 서로 다른 하드웨어에 존재한다면 jvmRoute명만 다르게 하고 포트명은 동일해도 상관이 없다.
하지만 만일 하나의 장비에 4개의 톰캣 프로세스를 실행시키고 로드밸런싱을 하려고 한다면 어떻게 될까? 톰캣을 4번 설치하고 각각의 환경
설정 파일을 수정해 주어야 할까? 만일 필요한 환경 설정 내용이 변경된다면(예를 들어 JNDI Resource 정보) 모두 운영자가 환경 설정
파일을 수정해 주어야 할까? 다행히도 톰캣에서는 하나의 바이너리에 여러 개의 프로세스가 뜨도록 할 수 있다.

톰캣의 server.xml 태그는 다음과 같은 구조를 가지고 있다.

--> --> --> -->

여기서 Server 태그는 유일해야 하며 Server 태그 밑에는 여러 개의 태그가 올 수 있다. 여기서 말하는 태그가 바로
하나의 톰캣 프로세스가 된다. 만일 2개의 태그를 정의했다면 2개의 프로세스가 구동되는 것이다. 리스트 5는 이렇게 구현한 환경
설정 파일이다.
리스트 5. server.xml

리스트 5는 하나의 톰캣 바이너리를 통해 2개의 프로세스를 실행시키는 것이다. 이렇게 하면 환경 설정의 편리성을 가져올 수 있지만 특정 서비스만 실행하거나 종료 시키는 것은 아직 지원되지 않는다. 즉 모든 서비스가 동시에 실행되거나 혹은 동시에 종료되는 것을 의미한다. 이런 점을 잘 판단해서 두 가지 형태의 환경 설정 중 하나를 선택하면 되겠다.
지금까지는 로드밸런싱에 대해 알아보았다. 위의 환경설정을 가지고 테스트를 하다 보면 한가지 문제가 발생한다. 예를 들어 어떤 사용자가 tomcat1을 이용해서 쇼핑몰 서비스를 받고 있다가 tomcat1이 비정상 종료를 하게 되었다. 이때 사용자가 웹 페이지를 요청하게 되면 아파치 웹서버는 tomcat1이 종료된 것을 인지하고 그 이후부터 서비스를 tomcat2로 요청하게 된다. 하지만 tomcat1에 저장되어 있던 쇼핑바구니 정보 즉 세션 정보는 사라진 상태다. 즉, 서비스는 유지되지만 사용자는 다시 이유도 모르게 처음부터 쇼핑 항목들을 등록해야 하는 문제를 가지게 된다. 이제부터는 이런 문제를 해결할 수 있는 톰캣 프로세스 간의 세션 정보 공유에 대해서 알아보겠다.

위로

세션 클러스터링 설정

클러스터링은 톰캣 5.x 버전부터 지원이 되고 있지만 아직은 초기 단계이고 세션 클러스터링만이 제공되고 있는 수준이다. 기능이 많이 부족하긴 하지만 로드밸런싱과 더불어 사용할 경우에는 좀 더 안정적인 서비스를 제공할 수 있다. 작업을 해주어야 할 것은 다음과 같다.

server.xml에 태그 정의
웹 어플리케이션의 web.xml에 태그 추가

그럼 server.xml에 설정해 보자. 태그는 태그의 하위에 정의해 주면 된다. 즉 여러 개의 호스트(예를 들어 가상 호스트)
를 설정했다면 각각의 경우에 맞게 설정해 주어야 한다. 여기서는 tomcat1과 tomcat2가 동일한 하드웨어에 별도의 바이너리 형태로 설치되어
있다고 가정하고 진행하겠다.
리스트 6. server.xml

...
managerClassName="org.apache.catalina.cluster.session.DeltaManager"
expireSessionsOnShutdown="false"
useDirtyFlag="true">

className="org.apache.catalina.cluster.mcast.McastService"
mcastAddr="228.0.0.105"
mcastPort="45564"
mcastFrequency="500"
mcastDropTime="3000"/>

className="org.apache.catalina.cluster.tcp.ReplicationListener"
tcpListenAddress="auto"
tcpListenPort="4001"
tcpSelectorTimeout="100"
tcpThreadCount="6"/>

className="org.apache.catalina.cluster.tcp.ReplicationTransmitter"
replicationMode="pooled"/>

filter=".*\.gif;.*\.js;.*\.jpg;.*\.htm;.*\.html;.*\.txt;"/>

...

리스트 6은 tomcat1의 server.xml에 적용한 태그이다. 이 내용은 태그 사이에 위치하게 된다. 태그 사이에는
, , 라는 3개의 태그가 위치하는데 은 멤버 그룹을 정의하는 것으로 해당 값이 동일한 모든
톰캣 프로세스는 클러스터로 묶이게 된다. 는 클러스터 그룹에서 보내오는 메시지와 세션 정보 등을 받아오는 것이며 는
자신의 세션 정보 및 메시지를 전송하는 것이다.
위의 내용을 tomcat2의 server.xml에 Receiver 태그의 tcpListenPort 값을 4002로 변경해서 적용하도록 하자.

위로

웹 어플리케이션 작성을 통한 테스트

먼저 테스트를 위해서 간단한 웹 어플리케이션을 작성하도록 하겠다. 여기서 웹 어플리케이션 이름은 lbtest라고 하겠다.

리스트 7. index.jsp

<%@ page contentType="text/html; charset=euc-kr" %>

세션 JSP 테스트

세션 JSP 테스트

<%
Integer ival = (Integer)session.getAttribute("sessiontest.counter");

if(ival==null) {
ival = new Integer(1);
}
else {
ival = new Integer(ival.intValue() + 1);
}
session.setAttribute("sessiontest.counter", ival);
%>
당신은 이곳을 <%= ival %> 번 방문 했습니다.

여기를 클릭하세요.
여기

request 객체와 관련된 세션 데이터

요청된 세션 ID : <%= request.getRequestedSessionId() %>

쿠키로 부터 요청된 세션 ID 인가? : <%= request.isRequestedSessionIdFromCookie() %>

URL로부터 요청된 세션 ID 인가? : <%= request.isRequestedSessionIdFromURL() %>

유효한 세션 ID 인가? : <%= request.isRequestedSessionIdValid() %>

작성된 웹 애플리케이션을 tomcat1과 tomcat2에 배포한다. 이때 가장 중요한 것이 web.xml에 반드시 이라는 항목을 넣어
야 한다. 그럼 이제 테스트를 해보도록 하자. 먼저 아파치 웹서버, tomcat1, tomcat2를 차례로 실행시켜 보자.
그리고 http://ipaddress/lbtest/index.jsp 접속하여 세션 객체를 생성해보자.
결과 화면은 그림 1과 같다. 여기서 요청된 세션ID를 보면 뒤에 어떤 톰캣에 접속한 상태인지를 알 수 있다. 이 화면상에서는 tomcat2에 접속한
세션이다.
그럼 tomcat2를 강제로 종료시켜 보도록 하자. 종료 후 화면에 보이는 “여기”를 계속 눌러 보자. 분명히 tomcat2가 종료되었음에도 불구하고
세션 값이 유지되고 있음을 알 수 있다.
이젠 반대로 tomcat2를 다시 실행시킨 후에 tomcat1을 종료시켜 보도록 하자. 역시 마찬가지로 세션 정보가 유지되는 것을 확인할 수 있을 것
이다.

그림 1. 테스트 결과 화면

이상으로 톰캣을 이용한 로드밸런싱과 세션 클러스터링에 대해서 알아보았다. 일반적으로 로드밸런싱과 클러스터링은 성능 향상이라는 측면과 안정성 확보에 그 목적을 가지고 있다. 물론 고가의 상용 웹 어플리케이션 서버에 비하면 많이 부족하고 하드웨어를 이용한 로드밸런싱과 클러스터링에 비하면 안정성이 떨어질 수도 있지만 저렴한 비용으로 최대의 안정성과 성능을 얻고자 한다면 한번쯤 시도해 볼만한 좋은 기능이라고 할 수 있다. 아무쪼록 리눅스, 아파치, 톰캣 그리고 오픈소스를 통해 즐거운 웹 어플리케이션 개발 환경을 느껴보기 바란다.

출처 : Tong - exospace님의 JAVA통

tag : tomcat

톰켓을 사용하는데 필요한 20가지 Tips

2009-09-11T00:24:30Z

톰켓을 사용하는데 필요한 20가지 Tips

2007/08/24 23:26

http://blog.paran.com/pmang/21456729

1. jdk 1.5이상이면 아래 설정을 JAVA_OPTS안에 추가한다면 YourKit을 가지고 힙덤프를 분석할 수 있다.
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/logs/heapdump

2. Jasper 2 JSP Engine 지원을 위해 $CATALINA_BASE/conf/web.xml 설정 변경하라.
- development : false, genStringAsCharArray : true, modificationTestInterval : true, trimSpaces : true
- 자세한 건 여기를 참조하라.

3. 가용성 확보를 위해 Tomcat의 clustering/session replication을 사용하라.
- 사용방법은 여기를 참조하라.

4. error pages를 작성하여 적용하라.(web.xml)
-
      404
      /error/404.html

5. 어플리케이션에서 System.out과 System.err를 제거하고 Log4j를 사용하라.

6. application마다 같은 라이브러리는 WEB-INF/lib에서 CATALINA_HOME/shared/lib로 옮겨서 공유하라.
- 메모리를 절약할 수 있다.

7. memory parameters를 잘 활용하라.

8. 불필요한 어플리케이션을 제거하라.

9. Manager서버의 보안을 강화하라.
- CATALINA_HOME/conf/tomcat-users.xml

- CATALINA_HOME/conf/server.xml에 IP 블럭킹 기능도 유용하다.

10. server.xml을 최적화 하라.
- 서버 환경에 맞는 CATALINA_HOME/conf/server-original.xml, CATALINA_HOME/conf/server-minimal.xml 선택하여 server.xml로 변경하라.

11. 톰켓 업그레이드는 설치디렉토리를 분리하여 적용하라.

12. Tomcat 서버는 root로 띄우지 마라.
- 자세한 내용은 여기를 참조하라.

13. Precompile JSPs (at build time)
- 자세한 내용은 여기를 참조하라.

14. 디렉토리 보이는 걸 막아라.
- CATALINA_HOME/conf/web.xml

   default
   org.apache.catalina.servlets.DefaultServlet

   debug
   0


   listings
   false

   1

15. 듀얼 코어 CPU를 사용할 경우 쓰레드풀을 250개 이상 설정하라.

16. Tomcat MBeans이나 다양한 모니터링 도구를 활용하여 서버를 모니터링하라.
- 자세한 내용은 여기를 참조하라.

17. jdk1.5, 1.6이 성능이 좋다.

18. -server JVM option을 사용하라.

19. GZIP compression을 사용하라.
- compression='on'
compressableMimeType='text/html,text/xml,text/plain,application/xml'

- 자세한 건 여기를 참조하라.

20. Security Manager를 잘 사용하라.
- 자세한건 여기를 참조하라.

참고 자료 : http://www.digitalsanctum.com/2007/08/18/20-tips-for-using-tomcat-in-production/

tag : 자바, 톰켓

tomcat과 jrockit함께 사용하기.

2009-08-05T10:50:56Z

톰켓 5.5...

오랫동안 톰켓 5.5와 jre 1.5가 함께 해왔다.

그동안사용한 jre는 jdk에 함께 들어있는것을 사용해 오다

jrockit에 대한 소식을 전해 듣고

jrockit을 사용해 보기로 결정

하지만 톰켓과 jrockit을 어떻게 연결 시켜야 하는지를 몰라 한참을 해맸다.

컴퓨터에 설치된 java를 삭제하고 jrockit을 설치한후

톰켓을 다시 설치를 하는 과정에서 톰켓이 jre가 설치된 폴더에서 jvm을 못찾는다.

결국은 java sdk를 설치하고 톰켓을 설치하였고

우여 곡절끝에 시스템 트레이에 올려져 있는 톰켓설정을 화면에 띄우고

java탭안에 jvm세팅하는 곳이 있음을 발견하고 이곳을 수정하니

성공했다.

sun의 jre경우 자바홈안에 bin\client폴더 안에 jvm.dll파일이 들어 있으나

jrockit의 경우엔 bin\jrockit폴더안에 jvm.dll파일이 들어있으므로

이부분만 주의해서 수정하면 jrockit과 tomcat같이 잘 돌아간다.

tag : tomcat, jrockit

나의 아이를 위한 무엇 하나.

2009-04-21T13:50:58Z

지난주 금요일이었던가?

딸 수진이,이제5살,를 위해 그리고 집에 아이들 책들이 박스에 담긴체 있는것이 좀 있어 정리도 해야하고 해서 오래전부터 사야지 사야지 했던

책장과 옷장을 사러 갔었다. 다음날 그러니까 토요일 배송을 요청하고 계획에는 있긴했지만 그날 하려던것은 아니었는데 아무튼 급작스럽게

도배를 하기로해서 도배하기 위한 여러가지들 준비를 하고 저녁무렵 도배를 시작. 10시 넘어서 끝났던가.

어찌했든 그렇게 저렇게 해서 수진이 방이라고 도배를 하고 다음날 배달되어져 온 책장에 책 배치하고 찍은 사진들이다.

아이들을 키우기 시작한지 어느덧 4년하고 4개월째. 왠지 기분이 묘하다. 4년하고 4개월동안 아이들 키워왔음에도 오늘 이사진을 찍으면서

아니 배치된 책장과 옷장을 보면서 뭔가 가슴속에 묘한 감정이 생긴다.

무얼까...?

그 느낌에 공연히 별것아닌듯한 이 사진들을 찍어봤다. 왜 이소품들을 보면서 새삼 나에게 아이들이 있음이 더더욱 가슴 깊이 느껴지는 것일까?

그 느낌이 저 사진들속에도 담겨져 있으면 좋으련만.

방 하나를 이렇게 나의 아이를 위해 꾸미면서 느끼는 느낌과 드는 생각들.

msconfig에 서비스 목록에 대한 설명

2009-04-01T18:33:47Z

서비스란? 서비스는 일종의 프로그램으로 컴퓨터 기동시 실행되며, 운영체계를 기능적으로 돕기 위해 계속 실행되는 프로그램, 프로세스, 프로세스의 집합을 말한다. Windows NT/2K/XP를 설치하면 사용자의 요구를 충족하면서 유연성 있는 핵심 서비스 및 서비스 구성 집합이 제공된다(MS의 주장).

서비스의 설정을 변경하는 방법은? 서비스는 시작/제어판/관리도구/서비스를 클릭함으로서 설정 상태를 변경할 수 있다. 서비스는 MMC(Microsoft Management Console) 스냅인을 사용하며 다음과 같은 세가지 상태 중 하나로 설정할 수 있다.

자동: 부팅시 운영체제에 의해 자동으로 드라이버가 로드된 후 실행된다.

수동: 운영체제에 설치되어 있지만 다른 프로그램이나 응용프로그램이 해당 기능을 요청할 때에만 기동된다.

사용 안함. 운영체제에 설치되어 있지만 현재 사용하고 있지 않은 서비스이다.

1. Alerter

▷ 설명: 선택된 사용자와 컴퓨터에 관리용 경고 메시지를 전송합니다.

▷ 가이드: 홈과 프로를 사용하는 경우(하나의 컴퓨터에 동시에 여러 사용자의 접속이 가능한 서버가 아닌 경우), 사 용할 가능성이 전혀 없는 서비스이다.

▷ 초기값: 수동

▷ 권고: 사용안함

▷ 종속성 : Workstation

2. Application Layer Gateway Service

▷ 설명: 인터넷 연결 공유 및 인터넷 연결 방화벽에 대한 타사의 플러그인을 지원할 수 있도록 한다.

▷ 가이드: 인터넷에 접속하는데 인터넷 연결 공유 및 인터넷 연결 방화벽을 사용하는 경우 필요하다.

▷ 초기값: 수동

▷ 권고: 자동(ICS/ICF 사용시), 사용안함

▷ 확인: 시작/제어판/네트워크 연결/로칼영역/우측 마우스 버튼/고급 탭

3. Application Management

▷ 설명: 할당, 게시, 제거 같은 소프트웨어 설치 서비스를 제공한다.

▷ 가이드: 프로그램의 추가/삭제가 정상적이라면 수동으로 설정하기 바란다. 관리자의 경우 이 서비스를 중지하고 싶은 경우도 있을 것이다. 그러나 일반 사용자가 프로그램을 추가/제거 할 수 있도록 수동으로 둔다.

▷ 초기값: 수동

▷ 권고: 수동

4. Automatic Updates

▷ 설명: 중요한 Windows 업데이트를 다운로드하고 설치할 수 있도록 한다. 서비스를 사용할 수 없으면 Windows Update 웹 사이트에서 운영 체제를 수동으로 업데이트할 수 있다.

▷ 가이드: 일반적으로 Windows의 업데이트의 갱신주기가 길기 때문에 필자는 주로 수동으로 업데이트한다. Windows 업데이트 웹 사이트를 통한 수동 업데이트는 암호 서비스를 필요로 한다.

▷ 초기값: 자동

▷ 권고: 사용안함

▷ 확인: 시작/내 컴퓨터/우측 마우스 버튼/속성/자동 업데이트

5. Background Intelligent Transfer Service

▷ 설명: 유휴 상태인 네트워크 대역폭을 사용하여 데이터를 전송한다. 실제 HTTP/1.1 서버와 데이타를 비동기 전송하는데 사용된다.

▷ 가이드: 대부분의 사용자의 경우 이러한 특징을 거의 사용하지 않는다. 이 기능은 네트웍 사용율이 높은 네트웍에서만 유용하다.

▷ 초기값: 수동

▷ 권고: 사용안함

▷ 종속성 : Remote Procedure Call (RPC) , Workstation

6. ClipBook

▷ 설명: 정보를 저장(잘라내기/붙여넣기)하고, 이 정보를 다른 컴퓨터와 공유하는데 사용된다.

▷ 가이드: 다른 PC 상의 사용자가 클립북 서버에 저장된 정보를 볼 수 있도록 하려면 수동 또는 자동(불필요함)으로 설정한다. 그러나 여러명이 동시에 사용하는 컴퓨터가 아니라면 보안상 중지할 것을 권고한다. 아울러 비슷한 이유로 Network DDE와 Network DDM DSDM도 중지하는 것이 좋다.

▷ 초기값: 수동

▷ 권고: 사용안함

▷ 종속성 >Network DDE

7. COM+ Event System

▷ 설명: SENS(Supports System Event Notification Service)는 가입된 COM(Component Object Model) 구성 요소에 이벤트 자동 분산을 제공한다.

▷ 가이드: 이 서비스를 중지하면 이 서비스가 중지되었다는 "DCOM" 오류를 수신하게된다. 그러나 필자는 COM+를 사용하는 응용 프로그램이 무었인지 알 수 없었다. 수동으로 설정하면 많은 서비스들이 이 서비스에 보고를 수행하며, 따라서 항상 시작된다.

▷ 주의: System Event Notification 서비스를 사용하거나 "Optimize System" 옵션으로 BootVis를 기동하는 경우에 필요하다.

▷ 초기값: 수동

▷ 권고: 사용안함

▷ 종속성 /Remote Procedure Call (RPC)

8. COM+ System Application

▷ 설명: COM+ 기반의 구성 요소의 설정 및 추적을 관리한다.

▷ 주의: System Event Notification 서비스를 사용하는 경우 필요하다.

▷ 초기값: 수동

▷ 권고: 사용안함

▷ 종속성 /Remote Procedure Call (RPC)

9. Computer Browser

▷ 설명: 네트워크에 있는 모든 컴퓨터의 목록을 업데이트하고 관리하며, 이 목록을 브라우저로 지정된 컴퓨터에 제공한다.

▷ 주의: 단독으로 사용하는 컴퓨터의 경우, 불필요한 서비스이다.

▷ 초기값: 자동

▷ 권고: 사용안함

▷ 종속성 /Server /Workstation

10. Cryptographic Services

▷ 설명: Windows 파일의 서명을 확인하는 카탈로그 데이터베이스 서비스, 신뢰된 루트 인증 기관의 인증서를 컴퓨터에 추가 및 제거하는 보호된 루트 서비스, 컴퓨터 인증서를 얻는 키 서비스와 같은 관리 서비스를 제공한니다.

▷ 가이드: 이 서비스를 중지하면 모든 Windows 프로그램을 설치할 때 인증되지 않은 드라이버라는 메시지를 받게된다. 그 이외에 다른 문제점은 없다.

▷ 주의: 수동으로 Windows 업데이트를 사용하는 경우 필요하다. 필자의 경우, 업데이트할 때에만 이 서비스를 기동한다.

▷ 초기값: 자동

▷ 권고: 사용안함

▷ 종속성 /Remote Procedure Call (RPC)

11. DHCP Client

▷ 설명: IP 주소와 DNS 이름을 DHCP 서버에 등록하거나 DHCP 서버로부터 동적으로 IP 주소를 가져온다.

▷ 가이드: IPSEC을 실행하거나 인터넷 연결 공유 및 인터넷 연결 방화벽을 사용하는 경우 필요하다. 단독으로 사용하는 시스템이나 정적 IP를 사용하는 시스템에는 필요없다.

▷ 초기값: 자동

▷ 권고: 자동(필요시), 사용안함(인터넷 사용않할경우)

▷ 종속성 /AFD Networking Support Environment / NetBios over TCP/IP , TCP/IP Protocol Driver

12. Distributed Link Tracking Client

▷ 설명: 네트워크 도메인의 여러 컴퓨터나 일반 컴퓨터에서 NTFS 파일 간의 연결을 관리합니다.

▷ 가이드: NTFS 5.0으로 포맷된 공유 드라이브를 사용하는 2K/XP 네트웍의 경우 이 서비스를 사용하면 몇 가지 있점이있다(각각의 공유 드라이브의 상의 파일에대한 링크나 바로가기를 갱신, 수정하기때문에). 네트웍 공유 드라이브를 가지고 있는 경우에는 자동으로 설정하고, 필자의 경우처럼 네트웍 공유드라이브를 사용하지 않거나 NTFS 파일 시스템을 사용하지 않는 사용자는 사용안함으로 설정한다.

▷ 초기값: 자동

▷ 권고: 사용안함

▷ 종속성 /Remote Procedure Call (RPC)

13. Distributed Transaction Coordinator

▷ 설명: 데이터베이스, 메시지 대기열, 파일 시스템 등 여러 리소스 관리자를 스팬하는 트랜잭션을 조정한니다.

▷ 가이드: Message Queuing 서비스의 경우 이 서비스를 필요로 한다.

▷ 초기값: 수동

▷ 권고: 사용안함

▷ 종속성 /Remote Procedure Call (RPC) /Security Accounts Manager

14. DNS Client

▷ 설명: 이 컴퓨터에 대한 도메인 이름 시스템(DNS) 이름을 확인하고 캐시에 보관합니다.

▷ 가이드: 이 서비스를 중지해도 인터넷의 DNS 해석하는데에는 전혀 문제가 되지 않는다.

▷ 주의: IPSEC을 사용하는 경우 필요하다

▷ 초기값: 자동

▷ 권고: 사용안함

▷ 종속성 /TCP/IP Protocol Driver

15. Error Reporting Service

▷ 설명: 비표준 환경에서 실행하는 서비스와 응용 프로그램의 오류를 Microsoft에 보고한다.

▷ 가이드: 필자는 이러한 방식으로 보고서를 전송하는 것을 좋아하지않는다. 설사 MS의 주장대로 응용 프로그램의 오류와 관련된 정보만 전송된다고해도 메모리와 자원이 낭비되기때문이다.

▷ 초기값: 자동

▷ 권고: 사용안함

▷ 종속성 /Remote Procedure Call (RPC) / 확인: 시작/제어판/시스템/고급/오류 보고

16. Event Log

▷ 설명: 이벤트 뷰어에 있는 구성 요소와 Windows 기반의 프로그램에서 만든 이벤트 메시지를 기록하도록 설정한다. 중지할 수 없는 서비스이다.

▷ 가이드: 응용 프로그램의 문제점이나 보안, 시스템의 문제점을 파악할 때 아주 유용한 서비스이다.

▷ 주의: Windows Management Instrumentation 또한 이벤트 로그를 필요로 한다.

▷ 초기값: 자동

▷ 권고: 자동

17. Fast User Switching Compatibility

▷ 설명: 다중 사용자 환경에서 사용자 및 응용 프로그램을 관리한다.

▷ 가이드: 한 시스템에 여러 사용자가 사용하는 경우(필자는 여러명의 사용자가 사용하는 경우에도 이 서비스를 사용하지 않는다)를 제외하고 이 서비스를 실행할 필요는 아마 없을 것이다.

▷

▷ 초기값: 수동

▷ 권고: 사용안함

▷ 종속성 /Terminal Services

▷ 확인: 시작/제어판/사용자 계정/사용자 로그온 또는 로그오프 방법 변경

18. Fax Service

▷ 설명: 로컬 컴퓨터에서 팩스를 주고 받을 수 있도록한다. 기본적으로 설치되지않으며 필요시 Window XP CD로부터 설치할 수 있다.

▷ 가이드: 이 서비스는 팩스를 전송할 수 있는 하드웨어(팩스 모뎀)이 검출된 경우에 설치된다. Microsoft에 번들로 제공되는 소프트웨어중 상당수는 "무늬만" 제공된다. 팩스 서비스가 필요한 경우, 이 서비스를 사용하는 것보다 다른 회사의 전용 프로그램(WinFAX)을 사용하는 것이 낫다.

▷ 초기값: 자동

▷ 권고: 설치하지 않거나 사용안함

▷ 종속성 /Plug and Play /Print Spooler /Remote Procedure Call (RPC) /Telephony

19. FTP Publishing Service

▷ 설명: 로컬 컴퓨터에 FTP 서비스를 운영할 수 있도록한다. 기본적으로 설치되지않으며, Windows XP CD로부터 설치할 수 있다.

▷ 가이드: Microsoft에 번들로 제공되는 소프트웨어중 상당수는 "무늬만" 제공된다. 특히 IIS와 함께 제공되는 이 FTP 서비스는 10년전 Unix에서 제공되는 FTP 서비스보다 못한 기능과 성능을 제공한다. 이 FTP 서비스를 사용하기보다는 Serv-U나 War-FTPD와 같은 아주 우수한 FTP 서버 프로그램을 사용하기바란다.

▷ 초기값: 자동

▷ 권고: 설치하지 않거나 사용안함

▷ 종속성 /IIS Admin

20. Help and Support

▷ 설명: 이 컴퓨터에서 도움말 및 지원 센터를 실행할 수 있도록 한다.

▷ 가이드: 설사 이 서비스를 사용안함으로 설정해도 도움말 및 지원을 사용하면 서비스는 자동적으로 "자동"으로 변경된다. 따라서 어떠한 값으로 설정해도 무방하지만 시작/도움말 및 지원을 사용하기전까지 자원을 점유하지 않도록 수동으로 설정하는 것이 좋다.

▷ 초기값: 자동///////

▷ 권고: 수동

21. Human Interface Device Access

▷ 설명: 키보드와 원격 제어, 기타 멀티미디어 장치에서 사전에 정의된 버튼을 사용할 수 있도록 한다.

▷ 가이드: 필자는 이 서비스를 필요로하는 주변장치를 발견할 수 없었다. 기능 버튼을 가지고 있는 스캐너나 소리 조절, 플레이 컨트롤이 되는 키보드(절대 사용하지 않을 것을 권고한다)를 가지고 있으며, 문제가 발생하는 경우에만 자동으로 설정한다.

▷ 초기값: 수동

▷ 권고: 사용안함

22. IIS Admin

▷ 설명: 로칼 웹 서버, FTP 서버를 관리할 수 있도록 한다.

▷ 가이드: 기본적으로 설치되지 않으며 필요시 Windows XP CD로부터 설치할 수 있다. 로칼 웹 서버나 FTP 서버를 사용하는 경우에는 필요하다.

▷ 초기값: 자동

▷ 권고: 자동(설치한 경우)

23. IMAPI CD-Burning COM Service

▷ 설명: IMAPI COM 인터페이스를 사용하여 CD 굽기를 관리한다.

▷ 가이드: Windows XP 자체의 CD 굽기 기능에 사용된다. 수동으로 설정하는 경우 몇몇 소프트웨어와 함께 사용하면 자동으로 시작/중지된다. 사실 이러한 일을 할 수 있는 유일한 서비스이다. 만약 수동으로 설정하고, CD를 구울 수 없다면 자동으로 설정하기바란다. 그러나 필요할 때에만 사용되는 것이 보다 안전할 것이다. 참고로 Nero와 같은 별도의 CD 굽기 프로그램을 사용하는 경우에는 불필요한 서비스이다.

▷ 초기값: 수동

▷ 권고: 수동,사용안함(필요시)

24. Indexing Service

▷ 설명: 로컬 및 원격 컴퓨터에 있는 파일의 내용 및 속성을 인덱싱하며 쿼리 언어를 통해 파일을 빠르게 접근할 수 있도록한다.

▷ 가이드: Windows 2K/XP에서 가장 많은 리소스를 잡아먹는 서비스이다. IIS 서비스와 함께 기동하는 경우 어느정도의 성능 향샹을 기대할 수 있지만 그 이외의 경우에는 거의 불필요한 기능이다. 가급적 시작/제어판/프로그램 추가 삭제를 이용해서 이 기능을 제거하기 바란다.

▷ 초기값: 자동

▷ 권고: 사용안함 또는 제거

▷ 종속성 /Remote Procedure Call (RPC)

25. Internet Connection Firewall and Internet Connection Sharing

▷ 설명: 네트워크 주소 변환, 주소 지정, 이름 확인 및/또는 홈 네트워크나 소규모 네트워크의 침입을 방지하는 서비스를 제공한다.

▷ 가이드: 로컬 네트웍상의 컴퓨터들이 하나의 계정을 사용해서 인터넷에 접근하는데 사용된다. 이 서비스는 일반적으로 모뎀이 연결된 컴퓨터에 설치된다. 이러한 인터넷 공유/방화벽 기능을 사용하는 경우에는 자동, 그렇지 않은 경우에는 사용안함으로 설정한다.

▷ 초기값: 수동

▷ 권고: 자동(필요시), 사용안함

▷ 종속성 /Application Layer Gateway Service /Network Connections /Network Location Awareness

▷ Remote Access Connection Manager

26. IPSEC Services

▷ 설명: IP 보안 정책을 관리하고, ISAKMP/Oakley (IKE) 및 IP 보안 드라이버를 시작한다.

▷ 가이드: IPSEC을 사용하는 인터넷/네트웍에 접속된 경우 자동으로 설정한다. 대부분의 ISP에서 지원하지 않는 기능이며, 따라서 대부분의 사용자에 불필요한 기능이다. 다만 보안에 병적으로 집착하는 사람이라면 이 기능 사용해도 된다.

▷ 초기값: 자동

▷ 권고: 사용안함

▷ 종속성 /IPSEC driver/Remote Procedure Call (RPC) /TCP/IP Protocol Driver

27. Logical Disk Manager

▷ 설명: 새 하드 디스크 드라이브를 검색하고 모니터링하며 디스크 볼륨 정보를 로컬 디스크 관리자 관리 서비스로 보냅니다.

▷ 가이드: 동적으로 볼륨을 관리하는 디스크 관리 MMC를 기동할 때 필요하다. 따라서 하드 디스크의 착탈이 많은 경우가 아니라고 하더라도 가급적 자동으로 설정하기 바란다.

▷ 초기값: 자동

▷ 권고: 자동

▷ 종속성 /Plug and Play /Remote Procedure Call (RPC) / 확인: 시작/실행/diskmgmt.msc

28. Logical Disk Manager Administrative Service

▷ 설명: 하드 디스크와 볼륨을 구성한다.

▷ 가이드: 디스크 관리 MMC가 요청할 때만 기동될 수 있도록 수동으로 설정한다.

▷ 초기값: 수동

▷ 권고: 수동

▷ 종속성 /Logical Disk Manager /Plug and Play /Remote Procedure Call (RPC)

29. Message Queuing

▷ 설명: 각기 다른 시간에 실행되는 응용 프로그램들이 일시적으로 오프라인이 될 수 있는 혼합된 네트워크와 시스템을 통해 통신하도록 한다.

▷ 가이드: 기본적으로 설치되지 않으며 필요시 Windows XP CD로부터 설치가능하다. 몇몇 도메인에서 사용될 수 있지만 일반적인 사용자의 경우 불필요한 서비스이다.

▷ 초기값: 자동

▷ 권고: 설치하지 않거나 사용안함

Distributed Transaction Coordinator

Message Queuing access control

NT LM Security Support Provider

Reliable Multicast Protocol driver

Remote Procedure Call (RPC)

Server

▷ 종속성 /

30. Message Queuing Triggers

▷ 가이드: 기본적으로 설치되지 않는다. 필요시 Windows XP CD로부터 설치가능하며, 몇몇 도메인에서 사용될 수 있다.

▷ 주의: Message Queuing 서비스를 사용하는 경우에는 필요하다.

▷ 초기값: 자동

▷ 권고: 설치하지않거나 사용안함

▷ 종속성 /Message Queuing

31. Messenger

▷ 설명: 클라이언트와 서버 사이에 net send 및 경고 서비스 메시지를 전송한다.

▷ 가이드: 일반적인 사용자의 경우 불필요한 서비스이다. 그러나 몇몇 노트 프로그램(DKNotes와 같은)은 메시지 전송을 NET SEND를 이용한다. 따라서 이러한 프로그램을 사용하는 경우에는 자동으로 설정해야한다.MSN 메신저와는 무관하며, 중지해도 MSN 메신저 서비스를 받는데에는 어떠한 문제도 발생하지 않는다.

▷ 초기값: 자동

▷ 권고: 사용안함

▷ 종속성 /NetBIOS Interface/Plug and Play Remote Procedure Call (RPC) Workstation

32. MS Software Shadow Copy Provider

▷ 설명: 볼륨 섀도 복사본 서비스에 의해 만들어진 소프트웨어 기반 섀도 복사본을 관리한다.

▷ 가이드: Volume Shadow Copy 서비스와 함께 사용된다. Microsoft 백업 유틸리티를 사용할 생각이라면 수동으로 설정한다. 이 서비스를 중지하면 이 서비스가 중지되었다는 메시지가 이벤트 로그에 기록된다. 그러나 그이외의 다른 문제는 발견할 수 없었다.

▷ 초기값: 수동

▷ 권고: 사용안함

▷ 종속성 /Remote Procedure Call (RPC)

33. Net Login

▷ 설명: 도메인 제어기에 로그온하는데 사용된다.

▷ 가이드: 대부분의 사용자에게 불필요한 서비스이다.

▷ 초기값: 수동

▷ 권고: 사용안함

▷ 종속성 /Workstation

34. NetMeeting Remote Desktop Sharing

▷ 설명: 인증된 사용자가 넷미팅을 사용해서 원격으로 컴퓨터에 접근할 수 있도록 한다.

▷ 가이드: 이 서비스는 자신도 모르는 사이에 자신의 컴퓨터에 열려진 커다란 문을 다는 것과 같은 행위이다. 보안에대해 병적인 사람이라면 당연히 이 기능을 중지하고, 설사 그렇지 않은 사람이라도 가급적 이기능을 중지하는 것이 좋다. 만약 수동으로 설정하고서 넷미팅을 사용하는 경우라면 항상 자신의 컴퓨터에 누군가 웍격으로 접근할 수 있다는 것을 명심해야 한다.

▷ 초기값: 수동

▷ 권고: 사용안함

35. Network Connections

▷ 설명: 네트워크 및 전화 접속 연결 폴더에 있는 개체를 관리하여, LAN 및 원격 연결을 모두 볼 수 있게 한다.

▷ 가이드: 네트웍 관리에 필요한 서비스이다. 네트웍에 연결되어 있지 않거나 많은 수의 네트웍을 설정해야하는 경우가 아니라면 사용하지않는 것이 좋다. 이 기능을 중지하고, 인터넷 접속에 문제가 있는 경우 수동으로 설정하면 된다.

▷ 주의: 이 서비스를 중지하면 시작/제어판/네트웍 연결을 클릭해도 네트워크 설정 마법사, 새 연결 마법사, 로컬 영역 #(필자의 경우 넷기어)이 나타나지 않는다(서비스를 중지하고, 컴퓨터를 재 기동한 경우).

▷ 초기값: 수동

▷ 권고: 자동(필요시), 사용안함

▷ 종속성 /Remote Procedure Call (RPC)

36. Network DDE

▷ 설명: 동일한 컴퓨터나 다른 컴퓨터에서 실행되는 프로그램에대해 동적 데이타 교환(Dynamic Data Exchange: DDE)을 제공하는 경우 네트워크 전송 및 보안을 제공한다.

▷ 가이드: DDE 네트웍 접속(다소 오래된 프로그램을 제외하고 거의 필요가 없다)을 사용할 필요가 있는 경우 수동으로 설정한다. 그러나 원격 ClipBook을 사용하는 경우를 제외하고, 이 서비스가 사용되는 경우를 찾을 수 없었다.

▷ 초기값: 수동

▷ 권고: 사용안함

▷ 종속성 /Network DDE DSDM

37. Network DDE DSDM

▷ 설명: DDE 네트워크 공유를 관리한다. 이 서비스를 중지하면 DDE 네트웍 공유를 사용할 수 없다.

▷ 가이드: Network DDE를 수동으로 설정한 경우에는 수동으로 설정한다.

▷ 초기값: 수동

▷ 권고: 사용안함

▷ 종속성 /AFD Networking Support Environment/TCP/IP Protocol Driver/

38. NLA(Network Location Awareness)

▷ 설명: 네트워크 구성 및 위치 정보를 수집하고 저장하며, 이 정보가 변경되면 응용 프로그램에게 통지한다.

▷ 가이드: 인터넷 연결 공유 서비스를 서버에서 사용하는 경우에 자동으로 설정한다. 그렇지 않은 경우 사용안함으로 설정한다.

▷ 초기값: 수동

▷ 권고: 자동(ICS/ICF를 사용하는 경우), 사용안함

39. NT LM Security Support Provider

▷ 설명: 명명된 파이프를 통하지않는 원격 프로시저 호출(RPC) 프로그램에대한 보안을 제공한다.

▷ 가이드: Message Queuing이나 Telnet 서버를 기동하는 경우를 제외하고 거의 사용되지않는다.

▷ 초기값: 수동

▷ 권고: 사용안함(필요시)

40. Performance Logs and Alerts

▷ 설명: 이미 설정된 예약 매개 변수를 사용하여 로컬이나 원격 컴퓨터에서 성능 데이터를 수집한다.

▷ 가이드: 주기적으로 성능 데이타를 수집하고, 이 정보를 기록하거나 경고를 띄울 때 사용된다. 관리도구의 성능 프로그램으로 PC를 감시하도록 설정했다면 자동으로 설정한다. 수동으로 설정하면 어떠한 성능 기록이나 경고도 기록되지 않는다. 따라서 필요할 때 기동할 수 있도록 수동으로 설정한다.

▷ 초기값: 수동

▷ 권고: 수동

41. Plug and Play

▷ 설명: 사용자 입력 없이 컴퓨터에서 하드웨어 변경 내용을 인식하고 적용할 수 있도록한다.

▷ 가이드: PnP의 핵심이다. 이 서비스는 반드시 사용하기 바란다.

▷ 주의: UPnP는 PnP와 아무런 관련이 없다. UPnP는 TCP/IP 네트웍을 통해 장치(스캐너, 프린터등)에 접속하는데 사용된다. 예를들어 사운드 카드는 PnP이며, 따라서 PnP 서비스를 중지해서는 안된다.

▷ 초기값: 자동

▷ 권고: 자동

42. Portable Media Serial Number

▷ 설명: 컴퓨터에 연결된 이동성 음악 연주기의 등록번호를 복원하는데 사용된다.

▷ 가이드: 비록 컴퓨터에 외장형 음악 연주기가 있다고 해도 대부분의 시스템에서 특별한 문제가 없는한 사용안함으로 설정하는 것이 낫다. 외장형 연주기에 문제가 있는 경우에는 자동보다는 수동으로 설정한다.

▷ 초기값: 자동

▷ 권고: 사용안함

43. Print Spooler

▷ 설명: 나중에 인쇄하기 위해 파일을 메모리로 로드한다. 즉, 나중에 인쇄하기위해 인쇄업무를 대기열에 포함시킨다.

▷ 가이드: 이 서비스는 프린터를 가지고 있는 경우에 필요하다. 따라서 설치된 프린터가 있거나 프린터를 설치할 예정이라면 자동, 그렇지 않은 경우라면 사용안함으로 설정한다.

▷ 초기값: 자동

▷ 권고: 자동(필요시), 사용안함

▷ 종속성 /Remote Procedure Call (RPC)

44. Protected Storage

▷ 설명: 개인 키 같은 중요한 데이터를 보호된 저장소에 저장하며, 권한 없는 서비스나 프로세스 또는 사용자가 접근할 수 없게 한다.

▷ 가이드: 로컬 암호나 웹사이트의 정보(자동 완성)을 저장하는데 사용된다. 이 서비스는 기본적으로 자동으로 설정된다. 보안상의 이유때문에 필자는 이 서비스를 사용하지않을 것을 권고한다. 만약 이러한 정보를 저장하지 않는다면 이러한 정보를 훔치는 것은 훨씬 더 어렵기때문이다. 이 서비스를 중지하면 더 이상 암호를 저장할 수 없다. 즉, 매번 암호를 입력해야한다. 암호를 아웃룩이나 전화접속 네트웍에 저장하는 것이 더 편하다면 이 서비스를 자동으로 설정하기 바란다.

▷ 초기값: 자동

▷ 권고: 사용안함

▷ 종속성 /Remote Procedure Call (RPC)

45. QoS RSVP

▷ 설명: QoS를 인식하는 프로그램 및 제어 애플릿에게 네트워크 신호와 로컬 소통 설정 기능을 제공한다.

▷ 가이드: QoS RSVP(Quality of Service Resource ReServation Protocol)은 QoS 인식 프로세스가 활성화되었을 때 이들에게 필요한 네트웍 대역폭을 제공하기위해 대역폭을 예약하는데 사용된다. 기본적으로 약 20%의 대역을 예약주1하며, 이 서비스를 사용하지 않는 경우, 대역폭 효율이 20% 정도 증가한다. QoS 패킷 드라이버는 TCP/IP 접속시 기본적으로 설치된다. 이러한 응용 프로그램을 사용하는 경우에는 자동으로 설정한다. 그러나 자신의 네트웍에서 QoS가 사용되지 않는다면 이 드라이버를 삭제할 것을 권고한다.

▷ 초기값: 수동

▷ 권고: 사용안함

▷ 종속성 /AFD Networking Support Environment

Remote Procedure Call (RPC)

TCP/IP Protocol Driver

주1: 이 값은 다음 절차에 따라 쉽게 변경할 수 있다.

시작/실행/gpedit.msc를 입력하고 확인을 클릭한다.

좌측 패널에서 컴퓨터 구성/관리 템플릿/네트워크/QoS 패킷 스케줄러를 클릭한다.

우측 패널에서 예약 대역폭 제한을 두번 클릭한다.

예약 대역폭 제한 등록 정보에서 사용을 클릭하고, 대역폭 제한(%)를 변경한다.

확인을 클릭한다.

46. Remote Access Auto Connection Manager

▷ 설명: 프로그램이 원격 DNS 또는 NetBIOS 이름이나 주소를 참조할 때마다 원격 네트워크 연결을 하도록 한다.

▷ 가이드: 프로그램이 원격주소를 요청한때 자동적으로 네트웍에 접속한다. 이 서비스는 사용자의 인터넷 접속 형태(전화접속시)에따라 필요할 수도 있다. 따라서 이 서비스를 중지한 후, 문제가 발생하면 자동으로 설정하기 바란다.

▷ 초기값: 수동

▷ 권고: 사용안함(인터넷 접속에 필요없는 경우)

▷ 종속성 /Remote Access Connection Manager Telephony ,

47. Remote Access Connection Manager

▷ 설명: 네트웍 접속을 생성한다.

▷ 가이드: 이 서비스는 인터넷 연결 공유를 사용하는 경우에 필요하다. 이 서비스는 또한 사용자의 인터넷 접속 환경에따라 필요할 수도 있다. 이 서비스를 중지한 후, 문제가 발생한다면 자동으로 설정하기 바란다.

▷ 초기값: 수동

▷ 권고: 사용안함(인터넷 접속에 필요없는 경우)

▷ 종속성 /Telephony

48. Remote Desktop Help Session Manager

▷ 설명: 원격 지원 기능을 관리하고 제어한다.

▷ 가이드: 원격 지원 기능을 사용할 필요가 없는 경우 사용안함으로 설정한다. 이 서비스를 중지해도 원격 데스크톱을 사용하는데에는 어떠한 문제도 없다.

▷ 초기값: 수동

▷ 권고: 사용안함

▷ 종속성 /Remote Procedure Call (RPC)

▷ 확인: 시작/제어판/시스템/원격

49. Remote Procedure Call (RPC)

▷ 설명: 종점 매퍼 및 기타 RPC 서비스를 제공한다.

▷ 가이드: 이 서비스는 반드시 필요하다. 이 서비스는 대부분의 다른 서비스를 기동하는데 필요하다. 이 서비스는 서비스 MMC를 통해 중지할 수 없는 유일한 서비스이기도 하다.

▷ 초기값: 자동

▷ 권고: 자동

50. Remote Procedure Call (RPC) Locator

▷ 설명: RPC 이름 서비스 데이타베이스를 관리한다.

▷ 가이드: 필자는 이 서비스를 계속 기동할 이유를 찾지못했다. 이 서비스를 중지한 후, 네트웍 상의 어떤 것들에 문제가 발생할 수도 있다. 이 경우 수동으로 설정한다.

▷ 초기값: 수동

▷ 권고: 사용안함

▷ 종속성 /Workstation

51. Remote Registry Service

▷ 설명: 원격 사용자가 이 컴퓨터에서 레지스트리 설정을 변경할 수 있도록 한다.

▷ 가이드: 이 값을 자동으로 설정함으로서 원격 사용자가 지정된 레지스트리 경로주1의 항목을 변경할 수 있다. 그러나 몇몇 특수한 상황을 제외하고 이 것 역시 불필요한 서비스중 하나이며 필자가 가장 먼저 중지한 서비스이다. 보안에 집착하는 사람이라면 당연히 중지하기 바라며, 보안에 관심이 없는 사람이라도 중지하기바란다.

▷ 초기값: 자동

▷ 권고: 사용안함

주1: 레지스트리 경로는 다음 절차에 따라 변경할 수 있다.

▷ 시작/실행/secpol.msc을 입력하고 확인을 클릭한다.

▷ 좌측 패널에서 로컬정책/보안 옵션을 클릭한다.

▷ 우측 패널에서 네트워크 액세스: 원격으로 액세스할 수 있는 레지스트리 경로를 두번 클릭한다.

▷

52. Removable Storage

▷ 설명: 이동형 매체를 관리하는데 사용된다.

▷ 가이드: 테잎 백업 장치와 같은 장치(CD/DVD/Floppy는 해당되지 않는다.)를 가지고 있지않다면 이 서비스를 중지하기 바란다. 만약 이 서비스를 중지한 후, CD ROM/DVD 드라이버가 재미있게(또는 요상하게) 동작한다면 자동으로 설정하기 바란다. 일반적으로 이 필요없는 서비스이다.

▷ 초기값: 수동

▷ 권고: 사용안함

▷ 종속성 /Remote Procedure Call (RPC)

53. RIP Listener

▷ 설명: 다중 라우터를 갖는 네트웍에서 RIP(Routing Information Protocol) 메시지를 감지하고, 다른 라우터를 인식, IP 라우팅 테이블에 라우터를 추가할 수 있도록한다.

▷ 가이드: 기본적으로 설치되지않으며, 필요시 Windows XP CD로부터 설치할 수 있다. 이 서비스가 어떠한 서비스인지 알지 못한다면 이 서비스는 불필요한 서비스로 간주하면 된다.

▷ 초기값: 수동

▷ 권고: 설치하지 않거나 사용안함

▷ 종속성 /Remote Procedure Call (RPC)

54. Routing and Remote Access

▷ 설명: LAN이나 WAN 환경에 있는 사업체에 라우팅 서비스를 제공합니다.

▷ 가이드: 보안을 위해 사용안함으로 설정한다. 라우팅해야하는 다양한 네트웍을 사용하는 경우 자동으로 설정한다.

▷ 초기값: 수동

▷ 권고: 사용안함

▷ 종속성 /NetBIOSGroup , Remote Procedure Call (RPC)

55. Secondary Logon

▷ 설명: 다른 자격 증명으로 프로세스를 시작할 수 있도록 한다.

▷ 가이드: 이 것은 Windows XP의 RunAs 서비스이다. 이 서비스를 사용함으로서 응용 프로그램을 다른 사용자의 권한으로 기동할 수 있다. 이 컴퓨터에 로그온한 사람에게 특정 프로그램의 실행 권한(예: Windows 업데이트의 권한)을 주려고 하는 경우에 상당히 유용할 수 있다. 그러나 이 서비스를 사용함으로서 여러 보안헛점이 노출되며, 단독으로 사용하는 컴퓨터에서는 거의 필요없는 기능이다. 따라서 필자는 이 기능을 사용하지않을 것을 권고한다.

▷ 초기값: 자동

▷ 권고: 사용안함

56. Security Accounts Manager

▷ 설명: 로컬 사용자 계정에 대한 보안 정보를 저장한다.

▷ 가이드: Protected Storage처럼, 로컬 사용자의 보안 정보를 저장하는데 사용된다. 로컬 보안 정책을 사용해서 임의의 보안 설정을 변경하려면 자동으로 설정한다. 이 서비스는 IIS Admin 서비스를 기동할 때에도 필요하다.

▷ 초기값: 자동

▷ 권고: 사용안함

▷ 종속성 /Remote Procedure Call (RPC)

57. Server

▷ 설명: 이 컴퓨터에 대해 파일, 인쇄 및 명명된 파이프를 네트워크를 통해 공유할 수 있도록 지원한다.

▷ 가이드: 파일이나 프린터를 공유하는데 사용된다. 또는 Message Queuing 서비스를 기동하는데 필요하다. Workstation은 찾고자하는 파일을 가지고 있는 다름 컴퓨터에 접속하기위해 필요하며 로칼 컴퓨터와 파일을 네트웍을 통해 공유할 생각이 없다면 보안상 이 서비스를 중지하는 것이 낫다. 이 서비스를 중지한 후, 정상적으로 동작하지않는 것이있다면 자동으로 설정한다.

▷ 초기값: 자동

▷ 권고: 사용안함(필요시)

58. Shell Hardware Detection

▷ 설명: 메모리 카드와 같은 장치를 자동으로 인식/반응하는데 사용된다

▷ 가이드: 노트북의 도킹 스테이션의 문제를 경험했다면 자동으로 설정하기바란다.

▷ 초기값: 수동

▷ 권고: 사용안함(필요시)

▷ 종속성 /Remote Procedure Call (RPC)

59. Simple Mail Transport Protocol (SMTP)

▷ 설명: 로컬 컴퓨터에서 전자우편 서버로 운영할 수 있도록한다.

▷ 가이드: 기본적으로 설치되지않으며, 필요시 Windows XP CD로부터 설치할 수 있다. 그러나 필자는 MS가 번들로 제공하는 소프트웨어 보다 IPSwitch에서 나온 IMail을 사용할 것을 권고한다.

▷ 초기값: 자동

▷ 권고: 설치하지않거나 사용안함

▷ 종속성 /Event Log , IIS Admin

60. Simple TCP/IP Services

▷ 설명: 몇몇 오래된 UNIX 넷트웍 서비스를 지원한다.

▷ 가이드: 기본적으로 설치되지않으며, 필요시 Windows XP CD로부터 설치할 수 있다.

▷ 초기값: 수동

▷ 권고: 설치하지않거나 사용안함

▷ 종속성 /AFD Networking Support Environment

61. Smart Card

▷ 설명: 컴퓨터에서 스마트 카드를 액세스할 수 있도록 관리합니다.

▷ 가이드: 로컬이나 네트웍 상의 컴퓨터 인증을 위한 Smart Card 사용을 지원한다. Smart Card를 가지고 있지 않거나 Smart Card가 무었인지 모른다면 이 서비스를 기동할 필요가 없다.

▷ 초기값: 수동

▷ 권고: 사용안함

▷ 종속성 /Plug and Play

62. Smart Card Helper

▷ 설명: 플러그 앤 플레이를 지원하지 않는 레거시 스마트 카드를 지원하도록 설정합니다.

▷ 가이드: 이전 서비스와 비슷하지만 PnP를 지원하지 않는 스마트 카드를 지원할 수 있다는 차이가 있다. 로컬이나 네트웍 상의 컴퓨터 인증을 위한 Smart Card 사용을 지원한다. Smart Card를 가지고 있지 않거나 Smart Card가 무었인지 모른다면 이 서비스를 기동하 필요가 없다.

▷ 초기값: 수동

▷ 권고: 사용안함

▷ 종속성 /Plug and Play

63. SNMP Service

▷ 설명: 관리모드로서 SNMP를 사용하는 네트웍 장비의 사용을 지원한다.

▷ 가이드: 기본적으로 설치되지않으며, 필요시 Windows XP CD로부터 설치할 수 있다.

▷ 초기값: 수동

▷ 권고: 설치하지않거나 사용안함

▷ 종속성 /Event Log

64. SNMP Trap Service

▷ 설명: 관리모드로서 SNMP를 사용하는 네트웍 장비의 사용을 지원한다.

▷ 가이드: 기본적으로 설치되지않으며, 필요시 Windows XP CD로부터 설치할 수 있다.

▷ 초기값: 수동

▷ 권고: 설치하지않거나 사용안함

▷ 종속성 /Event Log

65. SSDP Discovery Service

▷ 설명: 홈 네트워크에 유니버설 플러그 앤 플레이 장치를 검색할 수 있도록 한다.

▷ 가이드: Universal Plug and Play 장치 호스트와 함께 사용된다. 네트웍상의 UPnP 장치를 검출/설정하는데 사용된다. 보안상의 이유와 사용자가 이러한 유형의 장치를 가지고있는지의 여부를 모르기때문에 이 서비스를 중지할 것을 권고한다. 이 서비스를 중지한 후, 외부 장치가 정상적으로 동작하지 않는다면 자동으로 설치하기바란다. 참고로 Microsoft의 XBOX 조차 이 서비스를 사용하지 않는다.

▷ 초기값: 수동

▷ 권고: 사용안함

66. System Event Notification

▷ 설명: COM+ Event System과 함께 사용된다. 이 서비스는 로그온과 종료와 같은 시스템 이벤트가 발생했을 때 이러한 서비스를 통지한다.

▷ 가이드: 일반 사용자의 경우 이러한 것에 주의를 기울일 사용자가 몇이나 될지 의문이다. 또한 필자는 이 서비스를 사용하는 어떠한 응용프로그램도 본적이 없다. 이 서비스를 중지하면 이벤트 로그에 중지되었음을 알리는 메시지가 기록되며, 그외에 다른 문제점은 발견할 수 없었다.

▷ 초기값: 자동

▷ 권고: 사용안함

▷ 종속성 COM+ Event System

67. System Restore Service

▷ 설명: 시스템의 복구 지점을 생성하고, 필요한 경우 해당 지점을 복구한다.

▷ 가이드: 이 서비스 역시 상당한 자원을 차지하는 또 하나의 서비스이다. 그러나 초보자의 경우 가급적 이 서비스를 기동할 것을 권고한다주1. 그러나 필자의 경우, 이 서비스를 이용하기보다는 새로 설치하는 것이 더 빠르고, 덜 번잡한 것 같다.

▷ 초기값: 자동

▷ 권고: 자동(초보자), 사용안함(숙련자)

▷ 종속성 /Remote Procedure Call (RPC)

주1: 시스템 복구 기능을 사용하는 경우에도 다음 절차에따라 가급적 OS 파티션(예: C 드라이브)에서만 사용하는 것이 좋다.

시작/제어판/시스템을 클릭한다.

시스템 복원 탭을 클릭한다.

OS 파티션을 제외한 드라이버를 클릭하고, 설정을 클릭한다.

드라이브 설정 창에서 이 드라이브에서 시스템 복원 사용 안 함을 체크하고, 확인을 클릭한다.

OS 파티션을 제외한 모든 드라이브에대해 4단계를 반복한다.

68. Task Scheduler

▷ 설명: 사용자가 컴퓨터에서 자동화된 작업을 구성하고 예약할 수 있도록 한다.

▷ 가이드: 이 서비스는 유지/관리, MS 백업, 자동 업데이트와 같은 것들을 작업예약하는데 사용된다. 필자는 이러한 것들을 모두 수동으로 한다. 따라서 이 서비스를 실행할 이유가 없다. 몇몇 프로그램(바이러스 검색기, 시스템 유지/보수 도구, 자동 패치/드라이버 검색기와같은)은 자동화된 기능을 사용하기위해 이 서비스를 필요로 할 수 있다.

▷ 주의: BootVis의 "optimize system"를 사용하기위해서는 Task Scheduler과 COM+ Event System 서비스가 필요하다. 이 것은 미리가져오기 기능을 Windows XP에 내장하기때문이다. 미리 가져오기는 단지 부팅시에만 사용된다. 부팅시 소모되는 추가적인 시간(몇초)에 관심이 없다면 이 프로그램을 사용할 이유가 없으며, Task Scheduler 역시 중지시키는 것이 낫다.

▷ 초기값: 자동

▷ 권고: 사용안함(BootVis를 사용하지 않는 경우)

▷ 종속성 /Remote Procedure Call (RPC)

69. TCP/IP NetBIOS Helper Service

▷ 설명: TCP/IP에서 NetBIOS(NetBT) 서비스 및 NetBIOS 이름 확인 지원을 사용할 수 있게 합니다.

▷ 가이드: NetBios over TCP/IP를 지원하기위해 필요한 서비스이다. 만약 NetBios를 사용하지 않는다면(WINS와 같은 서비스를 사용하지 않는다면) 이 기능을 중지하는 것이 낫다.

▷ 초기값: 자동

▷ 권고: 사용안함

▷ 종속성 /AFD Networking Support Environment / NetBios over TCP/IP

확인: 시작/시스템/네트워크 연결/로컬영역/우측 마우스 버튼/속성/인터넷 프로토콜/고급/WINS

70. TCP/IP Printer Server

▷ 설명: 로컬 UNIX 프린트 서버를 설정하는데 사용된다.

▷ 가이드: 기본적으로 설치되지 않으며 필요시 Windows XP CD로부터 설치할 수 있다. 만약 이 기능을 필요로하지 않는 경우, 설치하지않는 것이 낫다.

▷ 초기값: 자동

▷ 권고: 설치하지 않거나 사용안함: 이름

▷ 종속성 / Print Spooler / TCP/IP Protocol Driver

71. Telephony

▷ 설명: 로컬 컴퓨터 및 LAN을 통해 TAPI 서비스를 실행하는 서버에서, 전화 통신 장치 및 IP 기반 음성 연결을 제어하는 프로그램에게 TAPI(Telephony API) 지원을 제공한다.

▷ 가이드: 로컬 컴퓨터의 전화장치를 제어한다. 이 서비스는 전화접속 모멤을 통해 네트웍에 연결하는 경우 필요하다.

▷ 초기값: 수동

▷ 권고: 자동(전화접속 사용시), 사용안함

▷ 종속성 / Plug and Play / Remote Procedure Call (RPC)

72. Telnet

▷ 설명: 원격 사용자가 이 컴퓨터에 로그온하여 프로그램을 실행하고 UNIX 및 Windows 기반 컴퓨터를 포함한 다양한 TCP/IP 텔넷 클라이언트를 지원하도록 한다.

▷ 가이드: 텔넷 프로토콜을 통해 로컬 컴퓨터에 원격으로 로그인할 수 있다. 이 것이 전부다. Unix의 텔넷을 상상해서는 안된다. 이 것 역시 MS의 "무늬만" 같은 대표적인 서비스중 하나이다. 보안상 그리고 기능상 이 서비스는 중지하는 것이 낫다.

▷ 초기값: 수동

▷ 권고: 사용안함

▷ 종속성

▷ NT LM Security Support Provider

▷ Remote Procedure Call (RPC)

▷ TCP/IP Protocol Driver

73. Terminal Services

▷ 설명: 원격 컴퓨터의 데스크톱 디스플레이와 응용 프로그램에 연결할 수 있을 뿐만 아니라 여러 사용자가 한 컴퓨터에 대화형으로 연결할 수 있도록한다.

▷ 가이드: 빠른 사용자 전환, 원격 데스크탑 연결, 원격 지원을 사용하는 경우에 필요하며, 보안이 중요한 사람은 이 서비스는 중지하는 것이 낫다.

▷ 초기값: 수동

▷ 권고: 수동(필요시), 사용안함

▷ 종속성 /Remote Procedure Call (RPC)

74. Themes

▷ 설명: 새로운 XP 테마와 바탕화면의 색상을 출력하는데 사용된다.

▷ 가이드: XP의 외관 보다는 성능에 관심이 있다면 이 서비스를 중지하는 것이 낫다. 실제 이 서비스를 중지하면 상당량의 RAM을 절약할 수 있다.

▷ 초기값: 자동

▷ 권고: 사용안함

75. Uninterruptible Power Supply

▷ 설명: 컴퓨터에 연결되어 있는 무정전 전원 장치(UPS)를 관리한다.

▷ 가이드: 이 서비스가 왜 필요한지 알 수 없었다. USB를 통해 접속된 필자의 UPS는 이 서비스가 필요없었다. 그러나 Windows 업데이트는 이 서비스에대한 패치 또한 제공하고 있다.

▷ 초기값: 수동

▷ 권고: 사용안함

76. Universal Plug and Play Device Host

▷ 설명: 유니버설 플러그 앤 플레이 장치를 호스트하는 데 사용된다.

▷ 가이드: SSDP Discovery Service와 함께 사용되며, 네트웍 상의 UPnP 장치를 검출/설정한다. 보안상의 이유와 사용자가 이러한 유형의 장치를 가지고있는지의 여부를 모르기때문에 이 서비스를 중지할 것을 권고한다. 이 서비스를 중지한 후, 외부 장치가 정상적으로 동작하지 않는다면 자동으로 설치하기바란다. 참고로 Microsoft의 XBOX 조차 이 서비스를 사용하지 않는다.

▷ 초기값: 수동

▷ 권고: 사용안함

▷ 종속성 /SSDP Discovery Service

77. Upload Manager

▷ 설명: 네트워크상의 클라이언트와 서버 사이의 동기 및 비동기 파일 전송을 관리한다.

▷ 가이드: Background Intelligent Transfer Service와 마찬가지로 네트웍 상의 클라이언트/서버 사이의 파일 전송을 관리하는 서비스이다. 필자는 이 서비스의 필요성을 찾지 못했다. FTP를 사용하는 것이 편하다면 계속 FTP를 사용하기바란다.

▷ 초기값: 수동

▷ 권고: 사용안함

▷ 종속성 /Remote Procedure Call (RPC)

78. Volume Shadow Copy

▷ 설명: 백업과 기타 목적에 사용하는 볼륨 섀도 복사본을 관리하고 구현한다.

▷ 가이드: MS Software Shadow Copy Provider Service와 함께 사용된다. MS 백업은 이 서비스를 사용한다. 이 서비스를 중지하면 이벤트 로그에 중지되었음을 알리는 메시지가 기록되며, 그외에 다른 문제점은 발견할 수 없었다.

▷ 초기값: 수동

▷ 권고: 사용안함

▷ 종속성 /Remote Procedure Call (RPC)

79. WebClient

▷ 설명: Windows 기반의 프로그램에서 인터넷 기반의 파일을 작성, 액세스, 수정할 수 있도록한다.

▷ 가이드: 이 서비스를 실행할 이유를 발견할 수 없었다. 보안상 이 서비스를 중지할 것을 권고한다.

▷ 초기값: 수동

▷ 권고: 사용안함

▷ 종속성 /WebDav Client Redirector

80. Windows Audio

▷ 설명: Windows 기반 프로그램의 오디오 장치를 관리한다.

▷ 가이드: 음악을 듣기위해 필요한 서비스이다. 그러나 컴퓨터에 사운드 카드가 없는 경우 중지하기바란다.

▷ 초기값: 수동

▷ 권고: 자동, 사용안함(사운드 카드가 없는 경우)

▷

81. Windows Image Acquisition (WIA)

▷ 설명: 스캐너 및 카메라에 대한 이미지 인식 서비스를 제공한다.

▷ 가이드: 몇몇 스캐너와 카메라에서 사용된다. 이 서비스를 중지한 후, 스캐너와 카메라가 적당하게 동작하지 않는다면 자동으로 설정하기 바란다.

▷ 초기값: 수동

▷ 권고: 사용안함

▷ 종속성 /Remote Procedure Call (RPC)

82. Windows Installer

▷ 설명: .MSI 파일에 있는 지침에 따라 소프트웨어를 설치, 복구 또는 제거한다.

▷ 가이드: 설치할 프로그램이 있거나 RPC Service를 포함하는 오류가 발생한다면 자동이나 수동으로 설정한다. 이 서비스는 설치할 프로그램(주로 오피스 프로그램과 그와 유사한 프로그램)이 전혀없는 경우에만 중지할 수 있다.

▷ 초기값: 수동

▷ 권고: 수동

▷ 종속성 /Remote Procedure Call (RPC)

83. Windows Management Instrumentation

▷ 설명: 정보에 액세스하는 공용 인터페이스 및 개체 모델을 제공한다.

▷ 가이드: 이 서비스는 서비스 설정 화면에서 종속성 탭을 보기를 원하거나 부드럽게 이동하는 것을 원하는 경우 필요하다. 예상할 수 없는 일이 발생할 수도 있기때문에 필자는 이 서비스의 중지를 권하지 않는다.

▷ 초기값: 자동

▷ 권고: 자동

▷ 종속성 /Event Log . Remote Procedure Call (RPC)

84. Windows Management Instrumentation Driver Extension

▷ 설명: 드라이버에 관련된 시스템 관리 정보를 제공한다.

▷ 가이드: Windows Management Instrumentation에 반드시 필요한 것은 아니지만 수동으로 설정할 것을 권고한다.

▷ 초기값: 수동

▷ 권고: 수동

85. Windows Time

▷ 설명: 네트워크 상에서 모든 클라이언트 및 서버의 날짜 및 시간 동기화한다.

▷ 가이드: 인터넷 상의 시간 서버를 이용해서 컴퓨터의 시계를 자동으로 설정한다주1. 컴퓨터가 네트웍에 항상 연결되어 있다면 아주 좋은 생각이다. 그러나 그렇지 않다면 이벤트 로그에 "서버를 찾을 수 없읍니다"라는 메시지로 채워질 것이다. 시간 동기에 성공한 후, 이 서비스는 7일 동안 시간 동기를 시도하지 않는다. 즉, 이 동안 자원만 잡아먹게된다. 또한 작업 예약 서비스를 필요로 한다. 필자의 경우 컴퓨터의 시간 동기는 Internet Anywhere라는 프로그램으로 수동으로 설정한다.

▷ 초기값: 자동

▷ 권고 : 사용안함

주1: 국내 시간 서버는 time.kriss.re.kr에서 제공하고 있다.

86. Wireless Zero Configuration

▷ 설명: 802.11 어댑터에 대해 자동 구성을 공급한다.

▷ 가이드: 자동적으로 무선 네트웍 장치를 설정한다. 만약 사용중인 무선 네트웍 장치가 없다면 이 서비스를 중지하기 바란다.

▷ 초기값: 자동

▷ 권고: 사용안함

▷ 종속성 /NDIS Usermode I/O Protocol /

▷ Remote Procedure Call (RPC)

87. WMI Performance Adapter

▷ 설명: WMI HiPerf 공급자로부터 성능 라이브러리 정보를 제공한다.

▷ 가이드: 이 서비스를 사용하는 경우를 찾을 수 없었다.

▷ 초기값: 수동

▷ 권고: 사용안함

▷ 종속성 /Remote Procedure Call (RPC)

88. Workstation

▷ 설명: 클라이언트의 원격 서버 연결을 만들고 관리한다.

▷ 가이드: 로컬 컴퓨터에서 원격 컴퓨터로 접속하는데 사용된다. 예: 인터넷 접속, 파일 공유, 프린터 공유. 또한 많은 서비스가 Workstation 서비스에 의존한다. 자동으로 두기바란다.

▷ 초기값: 자동

▷ 권고: 자동

89. World Wide Web Publishing Service

▷ 설명: 로칼 컴퓨터에 웹 서비스를 제공하는데 사용된다.

▷ 가이드: 기본적으로 설치되지않으며, 필요시 Windows XP CD로부터 설치할 수 있다. 만약 웹 서버가 필요하지않은 경우 설치하지 말기 바란다.

▷ 초기값: 자동

▷ 권고: 설치하지 않거나 사용안함:

▷ 종속성 /IIS Admin

============================== EＮD　　＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

tag : windows

ArrayCollection을 XML로 변환하기 쉽게하기위한 XArrayCollection

2009-03-18T15:30:36Z

Tree때문에 속좀 썩다가 ArrayCollection을 XML로 변환하는 글이 있어 가져다 약간 수정하여 ArrayCollection을 확장한 클래스로 만들어 보았다.

앞으론 더이상 Tree문제로 속썩을일이 없기만을 바랄뿐.

package com.entech.lmsplus3.view.components{
import mx.collections.ArrayCollection;
import mx.utils.ObjectUtil;

public class XArrayCollection extends ArrayCollection{
  public function XArrayCollection(source:Array=null){
   super(source);
  }

  public function toXML(root:XML,parentId:String,childId:String):XML{
   var len:int=this.length;
   for(var i:int=0;i
   return root;
  }

  private function insertChild(xml:XML,child:Object,parentId:String,childId:String):void{
   var parent:XML=findParent(xml,child[parentId],childId);

   if(parent==null) parent=xml;
   parent.*+=object2XML(child,xml.localName().toString());
  }

  private function findParent(xml:XML,parentId:String,childId:String):XML{
   if(xml.@[childId]==parentId) return xml;

   var children:XMLList=xml.elements();
   var result:XML=null;

   for each(var x:XML in children){
    result=arguments.callee(x,parentId,childId);
    if(result!=null) return result;
   }

   return null;
  }

  private function object2XML(obj:Object,tagName:String="node"):XML{
   var xml:XML=new XML("<"+tagName+"/>");
   var o:Object=ObjectUtil.getClassInfo(obj);
   var prop:String;

   for(var i:int=0;i
    prop=o.properties[i].localName;
    xml.@[prop]=obj[prop];
   }
   return xml;
  }

}
}

참조한 곳 : JINHOKIM.com

tag : flex

identity관련

2009-03-17T18:40:53Z

현재 테이블의 identity 값 가져오기 : ident_current('테이블명')

identity가 자동증가로 설정되어 있는 테이블에 임의로 identity값을 넣으려면

set identity_insert 테이블이름 on

을 하고 원하는 값으로 insert 한뒤

다시 off해주면 된다.

tag : mssql

사진 합성 사이트

2009-03-14T12:47:27Z

괜찮은 사진 합성 사이트를 발견했다.

http://www.photofunia.com/

위 사이트에 방문해서 배경으로 할 사진 선택하고 내 사진 올려주면

아래와 같이 합성한 결과물을 얻을 수 있다.

괜찮은 배경이미지들이 많이 있는듯 하다.

사이트 하나더.

http://funphotobox.com/Default.aspx

이곳도 마찬가지.

멋지지 않은가..ㅎㅎ

tag : 사진

죽림정사에서 봉황정까지...

2009-02-27T00:58:16Z

계족 산행을 시작하면서 항상 용화사에서 봉황정으로만 다니다

코스를 한번 바꿔 보았다.

죽림정사에서 봉황정으로.

아직도 계족산에 있는 등산로들이 어디에서 시작 하는지 몰라. 섣불리 코스를 바꾸기 힘이 들었지만

오르고 또 오르다 보니 다른길에 대한 호기심이 가만 두지 않는다.

새로운 길만 보면 가보고 싶은마음에...

용화사로 오를때도 그랬지만 이곳 죽림정사쪽에서 산에 오르는 길도 시작부터 경사가 만만치 않다.

등산로 진입하기도 전에 벌서 숨이 턱까지 차오른다.

이곳 죽림정사에서 봉황정으로 오르는 등산로를 걷다보면 다른 코스에 비해 나무들이 별로 없고 키가 작은것을 볼수 있는데

그 이유가 등산로입구에 적혀져 있다.

한사람의 부주의로...

덕분이라고 하기엔 참 그러하지만 아무튼 나무가 그리 많지 않고 키가 작은 이유로 난 이 등산로가 맘에 든다.

봉황정까지 오르는 내내 시야가 탁트여 봉황정에 도착하는 동안 심심하지가 않다.

등산로가 능선을 타고 나있는지라 오르면서 좌우로 펼쳐지는 풍경을 감상하다보면 중간 중간 있는 경사 가파른 계단도

오를만 하다.

이쪽 등산로에 4곳은 가파른 경사가 있음에도 오를만 한것은

각각의 가파른 계단사이에 가파르지 않은 길이 있기 때문이다.

가파른 계단 하나 올라와 다음 계단에 가다 보면 어느새 숨을 골라지고

거기다 양쪽의 탁트인 경치 구경하다보면 다음 계단 오르는것이 그리 어렵지만은 않다.

마지막 봉황정에 오르는 계단

이역시 만만치는 않다..^^

집에서 계족 산을 바라다 볼때마다 항상 이능선을 바라보면서 꼭 가보고 싶었었지만

항상 등산로 시작이 어디인지 몰라 못 오르다 결국은 이렇게 올라본다.

몇일을 이 등산로로 올라와 보지만 올때마다 그 광경이 새롭다.

그리고 탁트인 시야가 너무도 좋다.

아직도 산불에 의한 흔적이 남아 있는것이 안타깝긴 하지만..

tag : 등산, 계족산

화창한 날씨 계족산 봉황정에서.

2009-02-17T15:19:14Z

비온뒤이라 그런지 날씨가 매우 화창하다

그동안 벼르고 벼르던 사진을 오늘에서야 찍어본다

처음 찍어본것인지라 좀 이상한가?^^

계족산 봉황정 올라갈때마다 시야가 깨긋하지 않아 못찍어 오던거 오늘 결국은 찍어봤다.

그동안 보이지 않던 저 멀리 노은동 월드컵 경기장까지 보인다.

그다지 깔끔하게 보이진 않지만.ㅜ.ㅜ

보인다는게 어디얌..ㅎ

담엔 더 잘 찍겠지..

tag : 사진

봄을 알리는 소리. 오래간만에 산행을..

2009-02-04T22:45:31Z

아주 오래간만에 산에 올랐다.

반팔티셔츠에 츄리닝 입고 시작한 산행

마치 봄인양 따뜻한 날씨에 아직 2월이 머무르고 있음을 잊어 버리게한다.

이렇게 가까이 있는 산을 왜 이제서야 방문을 했는지.

산도 내가 오래간만에 하는 산행임을 아는지 시작부터 기세 등등하다.

가파르게 시작된 입구. 몇발자욱 옮기지도 못하고 토해내는 거친 숨소리

산은 가만히 있는데 나만 힘들다.

오늘 내가 갈곳은 용화사를 지나 봉황정

1시간이면 갔다 오겠거니 하고 집을 나섰다.

몇년전인지 기억은 나지 않지만 와이프와 김밥싸들고 올랐었던 곳이다.

단지 그것밖에 생각나지 않는다

그당시에도 오늘처럼 힘이 들었었는지,휴일이었는지,애가 있었는지

아무것도 생각이 나질 않는다.

그져 참으로 오래간만에 간다는 생각 뿐이다.

가파른 입구로 나를 기죽인 산은 오르는 내내 역시 가파른 계단으로 나를 괴롭힌다.

봉황정까지 가는동안 몇번을 쉬었는지 모르겠다.

쉬면서 바라본 풍경이 그져 고마울 뿐이다.

단지 아쉬운것이 있다면 안개로 인해 많은것을 보지 못함이.

봉황정에서 바라본 대전시내.

차라리 파란 하늘이 멋스럽다.

멀리 바라다 보이는 계족산성.

탁트이게 바라다 보이는 대전 시내

아..탁 트이진 않았다. 안개 때문에

하지만 나중에 맑은날 내 카메라에 대전시내를 다 담아 보고 싶다.

간만에 산행을 마치고 내려오는길

내가 내려간다기 보단 산이 나를 내린다.

내일 또 가봐야지.

tag : 계족산