반응형

개요

  이 글의 목적

웹 사이트를 만드는데 있어서 기존의 개발 방법과 자바 환경에서의 개발 방법은 그 개념이 여러가지 면에서 많이 다르다. 물론, 자바를 이용해서도 종래의 개념처럼 코딩할 수 있지만, 이는 자바가 제공하는 많은 개념을 제대로 활용하지 못한 채 서버급 컴퓨터로 워드 프로세싱 정도의 작업만 하는 것과 다를 바 없다. 그러나, 아직은 자바 환경에서 서블릿과 JSP로 웹 사이트를 구축하는 노우하우가 많이 알려지지 않았고, 환경을 구축하는 방법도 쉬운 것만은 아니다. 그러나, 이미 많은 개발자들이 인식하고 있는 것처럼 앞으로 자바 환경을 중심으로 웹 사이트 개발의 주류가 형성될 것이고, 앞서가는 개발자라면 개념적으로 훌륭한 도구를 내 것으로 활용할 수 있어야 하는 만큼, 자바의 진보적인 개념을 제대로 이해하여 실제 개발할 수 있는 능력을 배양할 필요가 있다.

이 글은 필자가 작성한 실제 프로그램 코드 예를 통해 JSP로 웹 문서를 제작하는 구체적인 방법을 제시한다. 특히, beans의 사용법과 JSP의 include, forward 기능을 상세히 살펴볼 수 있으며, 계승과 예외 처리 등 객체지향 기법들이 JSP를 통한 웹 문서 개발에 어떤 식으로 적용되는지도 보여준다. JDBC를 활용하여 데이터베이스를 조작하는 방법과 데이터베이스 접속을 pool로 관리하는 방법도 다루고 있으므로, 가히 JSP를 통한 대부분의 테크닉을 집약했다고 할 수 있다. 회원 관리를 위한 로그인 시스템은 코드의 양은 그리 많지 않은데도 JSP의 독특한 기법들을 모두 활용할 수 있는 좋은 개발 예로서, 독자 여러분에게 많은 도움이 될 것이다.

  로그인 관리 프로그램이란?

근래에는 많은 웹 사이트가 회원제로 운영된다. 이를 위해 웹 사이트가 개발해야 할 일은 다음의 것들이 있다.

  • 회원의 정보를 저장하는 데이터베이스 구축

  • 아이디와 패스워드를 입력받고 이를 인증해 주는 과정

  • 클라이언트로부터 웹 문서 요청 시, 이 요청이 인증을 통과한 요청인지 아닌지를 알아내는 기능과 인증을 통과했다면 어떤 회원의 요청인지 구별하는 기능

  • 인증을 통과한 클라이언트로부터 일정한 시간동안 접속이 없다면 로그아웃하도록 하는 기능

  • 사이트 내에서 회원이 취하는 행위들에 대해 기록하는 기능

위와 같은 기능을 모두 포괄하되, 사용하기 쉽고, 웹 서버에 큰 부담을 주어서는 안 된다. 필자가 여기서 제시하는 프로그램은 위의 기능을 모두 충족하면서도 사용하기 간편하고, 웹 서버에도 거의 부담을 주지 않는다. 향후 J2EE 기반에서 EJB를 사용하면 더욱 견고하게 구현할 수 있지만, JSP만을 이용해서도 부족하지 않다. 기존의 웹 개발 방법으로 회원 관리 시스템을 구현해 본 개발자라면 자바의 강점을 충분히 느낄 수 있을 것이다.

준비 작업

  소프트웨어 설치

    데이터베이스 설치

데이터베이스를 설치한다. 필자는 postgreSQL에서 테스트하였으나, JDBC를 지원하는 데이터베이스라면 어떤 것도 괜찮다.

    JDK 설치

JDK는 1.2.2를 권장한다. Sun의 자바 홈페이지를 방문하면 구할 수 있다. 압축을 풀고, $JAVA_HOME/bin 디렉토리를 PATH에 추가하여 설치를 완료한다.

    Tomcat 설치

Tomcat의 최신 버전을 다운 받아 설치한다. 설치 방법은 WebDox의 Apache에서 Tomcat 사용하기에 자세히 설명되어 있으므로 참고한다. 주의할 점은 JDBC 드라이버가 $TOMCAT_HOME/bin/tomcat.sh 파일의 CLASSPATH에 잡혀야 하는 것이다.

  사전 학습

이 글은 JSP, Beans, JDBC의 실전 응용 예이므로 각각에 대한 기본적인 이해가 필요하다. WebDox에 관련 문서들이 있다.

    JSP

JSP 개념과 기본적인 사용 문법에 대한 이해를 위해서 WebDox의 JSP 맛보기를 읽어 본다.

    Beans

Beans가 없는 JSP는 생각할 수 없다. Beans를 사용하지 않는 JSP는 속빈 강정이고, 대포없는 전차이다. Beans에 대한 개념을 이해하기 위해 JSP에서 Beans 사용하기를 읽고 숙지한다.

    JDBC

본 예제는 사용자 정보와 접속 사용자의 아이디를 데이터베이스로 관리하므로 JDBC를 이용하여 데이터베이스를 조작하는 방법을 이해하고 있어야 한다. 역시 WebDox의 JDBC를 익히자를 읽어 본다.

프로그램 설치

  데이터베이스 설정 하기

테이블이 두 개 필요하다. 하나는 아이디와 비밀번호를 저장하고 있는 테이블이고 또 하나는 현재 접속한 사용자의 아이디를 저장하는 테이블이다. 전자는 id, password 이름을 갖는 필드가 존재하면 되고, 후자는 id 이름을 갖는 필드 하나만 갖는 테이블이여야 한다. 테이블 이름은 적절하게 만들도록 한다.

  WebDox's User Login Management(WULM: 움이라 읽는다)의 JSP 부분 다운 받기

wulmJsp.tar.gz를 다운받는다. 웹 서버의 루트 디렉토리에서 앞축을 푼다. userLog 디렉토리가 생기고 파일들이 그 안에 생길 것이다.

  WULM 클래스 부분 다운 받기

wulmClass.tar.gz를 다운 받는다. WEB-INF/classes 디렉토리 밑에서 압축을 푼다. userLog 디렉토리가 생기고 이 디렉토리 안에 WULM이 사용하는 클래스들이 있다. WEB-INF 디렉토리에는 CharacterSet.java가 생성된다.

  데이터베이스 이름, 테이블 이름 설정하기

WEB-INF/classes/userLog/Log.java 파일을 Emacs 등의 편집기로 열어 주석이 설명하는데로 데이터베이스 URL, 데이터베이스 사용자 이름, 데이터베이스 사용자 비밀번호와 앞에서 설정한 두 개 테이블 이름을 지정한다.

  컴파일하기

자바 소스를 모두 컴파일한다. 에러 없이 java 소스가 컴파일되어 class 파일들이 생기면 된다.

  테스트

loginTest.jsp를 브라우저를 통해 접속한다.

프로그램 설명

  WULM의 기능 개요

클라이언트가 웹 사이트에 방문하여 로그인하고 작업을 수행하다가 로그아웃하거나 더 이상의 문서 요청이 없게 되기까지의 과정을 생각해 보자.

회원제로 운영되는 사이트도 대개의 경우 비회원도 어느 정도는 사이트의 내용을 볼 수 있고 서비스를 받도록 하고 있다. 완전히 회원제로 운영되어 회원이 아닌 사람은 사이트의 어떤 내용도 들여다 볼 수 없다면, 회원으로 유도하기 쉽지 않기 때문이다. 따라서, 회원이 아이디와 비밀번호를 입력하는 로그인 화면은 꼭 로그인 화면으로의 링크를 누르지 않아도 회원만이 가능한 서비스인 경우는 자동적으로 로그인 과정을 거치도록 해 주는 편이 훨씬 지능적이다.

클라이언트가 비회원도 볼 수 있는 문서들을 보다가 회원만 가능한 문서로 접근 요청을 하게 되면, 우리의 회원 로그인 관리 시스템은 자동적으로 로그인 화면을 보여 주게 되고, 여기서 클라이언트는 아이디와 비밀번호를 입력해야 한다. 이 때, 당연히 회원의 아이디와 비밀번호가 유효한지를 확인해야 하고, 아이디와 비밀번호가 맞다면 이미 로그인했는지의 여부를 살펴야 한다.

복수 로그인을 가능하게 할 것인가는 사이트 운영 정책에 따라 결정되므로, 회원 로그인 관리 시스템은 복수 로그인이 되도록 설정했다면 복수 로그인을 지원해야 하고 그렇지 않다면 복수 로그인을 금하는 기능을 포함해야 할 것이다.

어쨌거나, 정상적으로 아이디와 비밀번호를 입력한 후에는 로그인 직전에 요청했던 문서로 자동적으로 돌아가 주어야 한다. 예를 들어, 특정 품목에 대해서는 회원만이 구입이 가능한 쇼핑몰이라면, 그 특정 품목을 눌렀을 때 회원 만이 가능한 서비스라는 메시지와 함께 로그인 화면을 사용자에게 보여 주고, 사용자가 입력한 아이디와 비밀번호가 유효하다면, 이제는 그 특정 품목을 살 수 있으므로 특정 품목 구입 화면으로 자동적으로 리턴해야 한다.

로그인을 거친 사용자(클라이언트)는 사이트에서 본인이 원하는 일을 하고 나서, 로그아웃을 할 것이다. 웹 사이트는 로그아웃을 명시적으로 할 수 있도록 로그아웃 메뉴를 갖추어야할 뿐만 아니라, 브라우저를 그냥 끄거나, 다른 사이트로 가 버리는 경우도 고려해야 한다. 이 경우들은 웹 사이트 입장에서 보면 더 이상의 문서 요청이 없는 것이고, 지정된 일정 시간 동안 추가적으로 웹 사이트에 접속하지 않는다면 자동으로 로그아웃이 되도록 해야 한다.

WULM은 위에서 나열한 플로우 상에 필요한 기능들을 모두 갖추고 있다. 이제 이 기능을 구현하기 위해 어떻게 코딩을 하였는지 살펴보자.

  WULM의 JSP 파일들

이 절에서는 WULM이 사용하는 jsp 파일들을 살펴보고 WULM의 전체적인 플로우를 이해해보자. Jsp 파일들은 여러가지 beans를 사용하는데 우선은 jsp 파일만을 통해 프로세스를 이해하고 다음 절에서 beans를 살펴본다.

    Include 부분

회원 관리가 필요한 문서, 즉, 회원만이 사용할 수 있는 페이지는 회원인지 아닌지를 체크하고 회원이 아니라면 로그인 과정을 거칠 수 있도록 해야 한다. 말하자면, 그 페이지에는 WULM을 포함해야 한다. WULM을 포함하는 방법은 간단히, 다음처럼 include를 사용하면 된다.



1   <%@ page import="java.util.Enumeration" 
2                         contentType="text/html; charset=EUC_KR" %>
3
4   <% String loginUrl = "/hello.jsp"; %>
5   <%@ include file="/userLog/log.jsp" %>
6
7   <html>
8
9   .....
10
11  </html>

여기서 <jsp:include>를 사용하지 않은 것에 유의하자. 인클루드 되는 log.jps 파일은 <jsp:forward> 기능을 사용하는데 필자가 테스트한 바로는 <jsp:include> 태그로 인클루드한 페이지가 <jsp:forward> 태그를 사용하면 에러가 났다. (<jsp:forward>로 forwading한 페이지는 <jsp:forward> 태그로 다시 다른 페이지로 forwarding할 수는 있다.)

첫번째 행에서 import 부분을 유의하자. 아래에서 인클루드하는 /login/log.jsp에서 Enumeration 클래스를 사용하므로 이 import 부분에 이 클래스를 명시해야 한다.

네번째 행의 loginUrl 인스턴스는 로그인 처리가 끝난 후 보여줄 페이지의 파일 이름이다. 주의할 점은, login 디렉토리를 기준으로한 상대 경로이거나, 웹 서버의 Document Root로부터의 절대경로여야 한다는 것이다. 이것은 로그인 과정을 처리하는 /login/loginProcess.jsp 페이지에서 loginUrl 값으로 forwarding하기 때문이다.

    /login/log.jsp

이제, log.jsp 파일이 무슨 일을 하는지 살펴보자. 소스는 다음과 같다.



1    <jsp:useBean id="myLogin" class="userLog.MyLogin" scope="session">
2        <jsp:forward page="/userLog/login.jsp">
3     	     <jsp:param name="loginUrl" value="<%= loginUrl %>"/>
4        </jsp:forward>
5    </jsp:useBean>
6
7    <%
8        if (!myLogin.isLoginStatus()) {
9    %>
10       <jsp:forward page="/userLog/login.jsp">
11           <jsp:param name="loginUrl" value="<%= loginUrl %>"/>
12       </jsp:forward>
13   <%
14       }
15   %>

1번부터 5번 행까지는 MyLogin 타입의 bean을 생성/선언한다. MyLogin은 개별 로그인 마다 생기는 session bean이다. 2번에서 4번 행까지는 이 MyLogin bean이 처음으로 생성될 때 수행되는 부분으로서, MyLogin bean이 아직 생성이 안 되었다면 로그인 절차를 밟지 않았음을 의미하므로 로그인 절차를 수행하도록 아이디와 비밀번호를 입력받는 /login/login.jsp 파일로 forwading한다.

7번부터 15번 까지는 이미 MyLogin bean이 생성되었다고 해도 사용자가 로그아웃 절차를 통해 로그아웃 한 경우를 처리해 준다. 이 경우는 이미 로그아웃을 했으므로 다시 로그인 절차를 밟아야 하기 때문에, MyLogin bean이 처음 생성되는 경우와 마찬가지로 login.jsp 파일로 forwarding한다.

3번, 11번 행은 로그인 절차를 밟은 후 보여주는 페이지를 bean의 속성으로 설정한다. log.jsp 파일은 <jsp:include> 태그를 이용하여 동적으로 포함되는 것이 아니라, <%@ include> 태그를 이용하여 정적으로 인클루드되므로, log.jsp 파일을 인클루드한 페이지에서 정의한 loginUrl 인스턴스를 바로 사용할 수 있다. 뿐만아니라, 상단에 <%@ page> 태그도 사용하지 않았다.

MyLogin bean에 대한 자세한 설명은 다음 절에서 설명한다.

    /login/login.jsp

log.jsp 파일은 로그인이 이미 되어 있다면 아무 일도 하지 않지만, 로그인이 아직 안 되어서 MyLogin bean이 생성이 안 되어 있다거나, 생성이 되어 있지만, 로그아웃 절차를 밟은 경우에는 login.jsp 파일로 forwading하는 역할을 수행한다. 이제, login.jsp 파일이 어떤 일을 하는지 살펴보자.



1    <%@ page import="CharacterSet,java.util.Enumeration" contentType="text/html; charset=EUC_KR" %>
2
3    <html>
4    <head>
5      <title>로그인</title>
6    </head>
7
8    <body>
9
10   <script language="javascript">
11   function checkLoginForm() {
12       if (document.loginForm.loginId.value == "" || document.loginForm.loginPassword.value == "") {
13           alert("아이디와 비밀번호를 입력하셔야 합니다.");
14           return false;
15       }
16       return true;	
17   }
18   </script>
19
20   <jsp:useBean id="myLogin" class="userLog.MyLogin" scope="session"/>
21
22   <form name="loginForm" method="post" action="/userLog/loginProcess.jsp" onSubmit="return checkLoginForm();">
23
24   <%
25       Enumeration p_pr = request.getParameterNames();
26       String p_name = "", p_value = "";
27       while (p_pr.hasMoreElements()) {
28           p_name = (String) p_pr.nextElement();
29           p_value = request.getParameter(p_name);
30   %>
31       <input type="hidden" name="<%= p_name %>" value="<%= p_value %>">
32   <%
33      }
34   %>
35
36   &nbsp;&nbsp;&nbsp;아이디 : <input type="text" name="loginId" maxlength="16" size="20"><br>
37   &nbsp;&nbsp;&nbsp;비밀번호 : <input type="password" name="loginPassword" maxlength="16" size="20"><br>
38   &nbsp;&nbsp;&nbsp;<input type="submit" value="로그인">
39
40   </form>
41   <br><br>
42
43   </body>
44   </html>

login.jsp는 사용자로부터 아이디와 비밀번호를 입력받는 페이지이다. 22번부터 40번 행까지는 HTML의 FORM을 사용해 사용자로부터 아이디와 비밀번호를 입력받도록 하고 이 내용을 loginProcess.jsp로 넘겨준다.

24번부터 34번 행까지는 log.jsp를 인클루드한 문서에 GET이나 POST로 전달된 파라미터 이름과 값들을 읽어서 hidden 타입으로 다시 설정하는 부분이다. 이를 통해 초기에 log.jsp를 인클루드한 페이지가 받은 POST나 GET 등을 통해 받은 파라미터 이름과 값들이 loginProcess.jsp로 전달되게 된다.

사용자가 이 페이지를 통해 아이디와 비밀번호를 입력받고 SUBMIT 버튼을 누르면 loginProcess.jsp 페이지가 호출된다. 다음으로는 loginProcess.jsp 파일을 살펴보자.

    login/loginProcess.jsp

loginProcess.jsp는 사용자로부터 입력받는 아이디와 패스워드를 확인하여 적절한 대응을 하여주는 페이지이다. 여기에는 Login 타입의 bean이 사용되는데 Login은 scope가 application인 bean으로서, 로그인한 사용자 리스트를 관리하는 역할을 한다. loginProcess.jsp 소스를 살펴보자.



1    <%@ page import="CharacterSet,java.util.Enumeration" contentType="text/html; charset=EUC_KR" isThreadSafe="false" %>
2
3    <% String loginUrl = CharacterSet.toKorean(request.getParameter("loginUrl")); %>
4    <jsp:useBean id="user" class="userLog.User" scope="page"/>
5    <jsp:setProperty name="user" property="*"/>
6    <% user.toKorean(); %>
7
8    <% 
9    boolean loginSuccess = false;
10
11   try {
12   %>
13       <jsp:useBean id="login" class="userLog.Login" scope="application"/>
14   <%
15        loginSuccess = login.login(user.getId(), user.getPassword());
16
17   } catch (userLog.UserAlreadyLoginException e) {
18   %>
19       <jsp:forward page="/userLog/userAlreadyLogin.jsp"/>
20   <%
21   } catch (userLog.PasswordNotCorrectException e) {
22   %>
23       <jsp:forward page="/userLog/passwordNotCorrect.jsp"/>
24   <%
25   } catch (userLog.NoSuchUserException e) {
26   %>
27       <jsp:forward page="/userLog/noSuchUser.jsp"/>
28   <%
29   }
30
31   if (loginSuccess) {
32   %>
33   <jsp:useBean id="myLogin" class="userLog.MyLogin" scope="session"/>
34   <%
35       myLogin.login(user.getId(), loginUrl);
36   %>
37   <html>
38   <head><title>성공적으로 로그인 되었습니다.</title>
39   </head>
40   <body>
41   <form name="afterLogin" action="<%= loginUrl %>" method=post>
42   <input type=hidden name="login" value="good">
43
44   <%
45       Enumeration pr = request.getParameterNames();
46
47       String name = "", value = "";
48       while (pr.hasMoreElements()) {
49           name = CharacterSet.toKorean((String) pr.nextElement());
50           value = CharacterSet.toKorean(request.getParameter(name));
51           if ("loginUrl".equals(name) || "loginId".equals(name) || "loginPassword".equals(name)) continue;
52   %>
53   <input type=hidden name="<%= name %>" value="<%= value %>">
54   <%
55       }
56   %>
57   </form>
58   <script language=javascript>
59   document.afterLogin.submit();
60   </script>
61   </body>
62   </html>
63   <%
64   } else {
64   %>
66   로그인 처리가 제대로 되지 않았습니다.
67   <%
68   }
69   %>

11번부터 29번 행까지는 Login bean을 통해 사용자의 로그인을 직접 처리한다. Login bean에는 login() 메쏘드가 정의되어 있는데, 이 메쏘드는 사용자 데이터베이스를 참조하여 인자로 전달 받은 아이디와 비밀번호를 검사한다. 또한, 이 아이디가 이미 로그인한 상태인지 아닌지도 살펴본다. login() 메쏘드는 결과에 따라 다음의 두 가지 예외를 던진다.

  • userLog.PasswordNotCorrectException : 비밀번호가 틀릴 때

  • userLog.NoSuchUserException : 그런 아이디가 존재하지 않을 때

15번 행의 login() 메쏘드에 login.jsp의 form에서 입력받은 아이디와 패스워드를 전달받기 위해 bean을 사용하였다. 4번부터 6번 행까지는 login.jsp의 form을 처리하는 User bean을 정의하고 값을 설정하는 부분이다. User bean은 다른 페이지에서는 사용할 이유가 없으므로 scope를 page로 지정했다. 3번과 6번 행을 주목해야 하는데, 현재 Tomcat은 GET이나 POST로 전달되는 값을 Cp1252로 인코딩하기 때문에 GET이나 POST로 전달되는 값을 beans나 request.getParameter() 메쏘드로 넘겨 받으면 한글이 깨진다. 따라서, GET 혹은 POST로 전달되는 값은 꼭 Cp1252를 EUC_KR로 변환해야 한다. 사용의 편의를 위해 필자는 CharacterSet이라는 클래스 내에 toKorean() 메쏘드를 static으로 정의하였다. 직접 CharacterSet 소스 코드를 살펴보기 바란다.

31번부터 63번 행까지는 입력한 예외가 발생하지 않고 성공적으로 로그인 한 경우에 MyLogin 타입의 session bean을 생성/선언하고 이 bean을 로그인 상태로 설정한다. 또, 이 session bean에 로그인 사용자의 아이디와 로그인한 url을 설정한다. 사용자의 아이디를 설정한 이유는 사용자가 다른 아이디로 로그인하는 경우를 고려한 것이고, url을 설정한 것은 사용자의 사이트 이용 이력을 데이터베이스화하는 것을 고려한 것이다.

37번 부터 62번 행까지는 번 행은 로그인 처리 후 사용자에게 적정한 페이지를 보여주는 작업이다. 이미 log.jsp를 인클루드할 때 loginUrl 인스턴스에 이 값을 설정하였다. 이 값은 이후 login.jsp를 거쳐 loginProcess.jsp까지 전달되어 41번 행에서 form의 action으로 설정된다. 그리고, 44번 행에서 52번 행까지가 우리가 계속 log.jsp, login.jsp을 거쳐 loginProcess.jsp로 넘긴 파라미터들의 이름과 값을 hidden 값으로 설정하는 부분이다.

1번 행을 주목하자. 한글을 제대로 사용하기 위해 EUC_KR로 문자셋을 설정하였고, isThreadSafe를 true로 설정하였다. 문자셋은 모든 jsp 문서마다 언제나 EUC_KR로 설정하여야 한글 사용에 문제가 없다. loginProcess.jsp는 Login bean을 통하여 로그인한 사용자의 아이디를 저장하고 있는 테이블를 참조하고 변경시킨다. 로그인은 동시에 여러 사람이 요청할 수 있으므로, 극단적인 경우에 같은 아이디로 두 사람 이상이 로그인 하게 되면 문제가 생길 수 있다. 따라서, loginProccess.jsp 문서는 한 순간에 오직 하나의 thread가 수행되어야 하고 이를 위해 isThreadSafe를 true로 설정하였다.

  WULM의 Beans

    Log Interface

WULM은 Login, MyLogin 두 개의 beans를 사용하는데, 모두 데이터베이스를 조작한다. 이 때, 데이터베이스 이름과 테이블 이름을 매번 지정하는 것이 번거로울 뿐만아니라, 향후 데이터베이스와 테이블의 이름이 바뀌게 되면 디버깅이 어렵다. 이를 위해, Log interface를 사용하여 한번에 관련 값들을 설정할 수 있도록 하였다. Log interface는 dbUrl, dbId, dbPassword, userTableName, currentUserTableName의 다섯 개 필드만을 정의하고 있고, 각각 데이터베이스 이름, 데이터베이스 사용자 이름, 데이터베이스 사용자 비밀번호, 로그인 아이디와 비밀번호를 저장하고 있는 테이블 이름, 현재 로그인한 아이디를 저장하는 테이블 이름을 명시한다.

    Login Bean

Login bean은 scope가 application으로서 로그인 가능 여부를 확인하고 가능하면 현재 로그인한 사용자 테이블에 아이디를 저장하는 일을 수행한다.

Login bean은 application bean이므로 Tomcat이 셧다운되기 전까지는 살아있다. 만일, Tomcat을 셧다운하면 모든 session bean이 소멸되므로 로그인한 사용자의 개별 bean은 없어지게 된다. 따라서, Tomcat을 셧다운하고 다시 시작한다는 것은 새로이 사용자 접속을 시작한다는 의미게 되며, 이를 제대로 수행하려면 기존의 사용자 로그인 정보는 삭제되어야 한다. Login bean은 생성자에서 이 작업을 수행한다. Login 생성자는 init() 메쏘드를 호출하고 init() 메쏘드는 로그인한 사용자의 아이디를 저장하고 있는 테이블의 모든 값을 삭제한다.

Login bean의 public 메쏘드는 login()이 중요하다. 다른 메쏘드들은 login 메쏘드가 사용하는 메쏘드들로서 private으로 정의되어 있다. login() 메쏘드는 인자로 아이디와 비밀번호를 넘겨 받고 맞는지 틀리는지를 확인하고, 이미 같은 아이디로 접속하였는지도 확인한다. 아이디가 존재하기 않거나, 비밀번호가 틀리거나, 이미 접속한 상태라면 적절한 예외를 던지며 이 예외를 이미 loginProcess.jsp를 설명하면서 언급하였다.

    MyLogin Bean

MyLogin bean은 개별 사용자가 로그인할 때마다 생성되는 session bean이다. loginProcess.jsp에서 로그인이 제대로 수행되었다면 MyLogin bean을 생성한다. MyLogin bean은 두 가지 경로를 통해 로그아웃을 수행한다.

우선 사용자가 직접 로그아웃을 한 경우가 있다. 사이트 내에 로그아웃 아이콘이 있고 사용자가 이것을 클릭함으로써 수행된다. 프로그램 코드를 통해 이미 생성된 bean을 없애는 방법은 없으므로, MyLogin bean의 loginStatus 필드를 false로 만들어서 로그아웃을 했음을 표시해 두고 deleteMeFromTable() 메쏘드를 통해 현재 로그인한 사용자의 아이디를 저장하고 있는 테이블에서 로그아웃하는 아이디를 삭제한다. 이 사용자가 bean이 타임아웃되기 전에 다시 로그인을 시도한다면 이 loginStatus 필드를 통해 로그아웃을 이미 했음을 알 수 있다. log.jsp 파일에서 loginStatus의 값을 넘겨주는 getLoginStatus() 메쏘드를 사용해 이를 적절히 수행한다.

다음으로, 사용자는 굳이 로그아웃을 통하지 않고 그냥 사이트를 떠나는 경우가 있다. 예를 들어, 브라우저를 그냥 종료시키거나, 다른 사이트로 이동한 후 다시 되돌아 오지 않는 경우들이 있다. 더 이상 웹 사이트에 접속하지 않는 사용자는 자동적으로 로그아웃 시켜야 하는데, 이를 위해 타임아웃 시간을 정해야 한다. Tomcat은 정해놓은 타임아웃 시간 동안 사용자의 접속이 더 이상 없다면 자동적으로 session bean을 소멸시키므로, 이를 이용하면 된다. MyLogin session bean이 소멸될 때 자동적으로 로그아웃 과정을 밟도록 하는 것이다. 클래스 인스턴스가 소멸될 때 클래스를 디자인한 사람이 특별히 어떤 일을 하고 싶다면 finalize() 메쏘드를 사용하면 된다. finalize 메쏘드는 클래스 인스턴스가 garbage collection 대상이 되면서 자동적으로 수행되는 메쏘드이다. WULM의 MyLogin bean은 finalize 메쏘드를 이용하여 session bean이 소멸될 때, 자동적으로 로그인한 사용자의 아이디를 저장하는 테이블에서 아이디를 삭제하도록 한다.

Tomcat에서 session bean의 타임아웃 시간은 $TOMCAT_HOME/conf/web.xml 파일의 <session-timeout> 태그 부분에서 설정할 수 있다.

    User Bean

User bean은 login.jsp 페이지에서 사용자가 입력한 아이디와 비밀번호를 처리하는 bean이다. JSP에서 Beans 사용하기를 참조하면 form의 데이터를 beans를 통해 제어하는 방법이 상세히 나와있다.

Form의 데이터를 처리하는데 유의할 점은 한글의 인코딩 문제이다. WULM이 사용하는 User bean의 소스를 보자.



package userLog;

import java.io.*;
import CharacterSet;

public class User {
    private String id;
    private String password;

    public void setLoginId(String str) {
	id = str;
    }

    public void setLoginPassword(String str) {
	password = str;
    }

    public String getId() {
	return id;
    }

    public String getPassword() {
	return password;
    }

    public void toKorean() {
	id = CharacterSet.toKorean(id);
    }
}

setXXX 메쏘드와 getXXX 메쏘드 외에 toKorean 메쏘드를 주목하자. toKorean 메쏘드는 필드인 id와 password를 Cp1252에서 EUC_KR로 바꾸어주는 일을 한다. 이는 GET이나 FORM을 통해 건네받은 값을 <jsp:setProperty>를 통해 설정한 후 바로 실행해야 한다. 일단, EUC_KR로 변환했다면 다시 이 메쏘드를 호출해서는 안된다. GET이나 POST를 통해 건네받는 데이터가 영문으로 구성된다면 이 작업은 필요가 없다.

마치며

프로그래밍은 실전 예를 통해 학습하면 많은 효과를 얻을 수 있다. 다른 사람의 소스를 보고 분석해 보는 것만으로도 실력이 쑥쑥 향상된다. JSP, Servlet등 자바 환경으로 웹 사이트를 만드는 것은 아직까지는 많이 알려지지 않아 많은 개발자들이 그 실제 예를 접할 기회가 별로 없다. 간혹 얻을 수 있는 예라고 하여도 JSP의 새로운 개념이나 자바의 진보적인 개념이 듬뿍 가미된 소스는 찾기 어렵다. 필자는, 독자 여러분에게 JSP가 다른 웹 사이트 개발 방법과 다른 점을 충분히 이해할 수 있도록 JSP의 개념과 자바의 특성이 가미된 WULM을 공개하였다. WULM은 소스를 바로 인스톨하여 자신의 웹 사이트에 적용시킬 수는 없고, 소스를 이해하고 이를 바탕으로 자신의 환경에 적절히 맞추어야 한다. 다음 버전의 소스와 글에서는 좀 더 customization이 쉽도록 개선하도록 하겠다.

반응형


Synergy는 가상 KVM 프로그램입니다. 얼기 설기 엮어진 KVM의 커넥터들을 정리할 필요 없이, 네트워크상에서 키보드, 마우스를 공유할 수 있습니다. 프로그램 하나만 있으면 마우스를 2개 가지고 다닐 필요도 없고, KVM 스위치를 뭉탱이로 가지고 다닐 필요도 없어집니다. 무엇보다 책상이 넓어집니다. :)

Synergy와 유사한 프로그램으로는 Multiplicity가 있습니다. 두 프로그램은 거의 유사한데 후자가 더 나은 성능을 보여줍니다. Multiplicity의 가장 큰 장점으로는 클립보드의 공유가 가능하다는 것인데 (Synergy도 지원하지만), 단순히 텍스트의 복사만이 아닌 파일까지 이동, 복사가 가능합니다. 마치 두대의 컴퓨터가 정말로 하나가 된듯한 느낌이 들 정도니까요. 하지만, Multiplicity는 상용프로그램이고 (과자를 구할 수는 있지만...) 한번 연결하기가 힘들정도로 말을 안듣는 경우도 가끔 있습니다. (Synergy가 Multiplicity보단 순한듯 -_-) 그래서 요즘은 Synergy를 애용합니다.


참~!! Synergy는 Window, Linux, Mac OS 종류를 가리지 않습니다. :)
 
Synergy는 여타 프로그램과 마찬가지로 Host와 Guest의 구조를 가지고 있습니다. Host는 말 그대로 Server의 역할을 하고, Guest는 Host에 연결되어 Host의 키보드와 마우스를 공유하는 방식입니다. Guest로 접속한 키보드, 마우스는 Host에서 사용은 할 수 없습니다. Host중심이니 말이죠.


0. 프로그램 설치
일단은 Synergy를 다운로드해서 설치하자. 다음 링크를 참조.

맥킨토시용 SynergyKM Download
Windows용 SynergyKM Download




1. 윈도우에서 서버 설정

- Use antoher computer's shared keyboard and mouse (client)

     : 이건 클라이언트에서 Host Name에 서버로 사용될 호스트 이름(즉 키보드와 마우스가 연결되어 있는

       컴퓨터의 이름)을 넣으면 된다.


  - Share this computer's keyboard and mouse (server)

     : 마우스와 키보드가 연결되어 있는 PC에서 서버로 세팅할때 선택하는 옵션이다.




윈도우 버전을 다운 받아서 설치하고, 시너지를 실행하면 다음과 같이 나타납니다.

그림1
그림1. Synergy 화면

서버로 사용할 것이기 때문에 "Share this computer's keyboard and mouse(server)" 항목을 선택하고, "Configure" 버튼을 클릭합니다. 여기서는, 각 시스템의 모니터 화면에 대한 설정을 합니다.

그림2
그림2. 화면(Screen Name) 설정

"+" 버튼을 클릭해서 화면 이름을 추가합니다. 노트북에서 윈도우를 쓰기 때문에 이름을 win으로 입력했습니다. 특별히 설정할 것은 없기 때문에, "win"만 입력하고, "OK" 버튼을 클릭하면 됩니다.

그림3
그림3. 화면 추가

같은 방법으로, 리눅스가 설치된 데스크톱에 대해서는 리눅스 시스템의 이름인 "caffe"를 부여했습니다. win과 caffe 이름을 추가한 후의 화면 목록은 다음과 같습니다.

그림4
그림4. 화면이 추가된 모습

이제는, 아래쪽의 "Links" 항목을 설정할 차례입니다. 다음 내용은 자신의 모니터 위치에 맞게 설정하시면 됩니다.

먼저, 내 노트북은 왼쪽에 있고, 리눅스에 연결된 모니터는 오른쪽에 있습니다. 따라서, 노트북에서 마우스를 화면 오른쪽 끝으로 이동하면 오른쪽에 있는 리눅스 모니터로 마우스 포인터가 이동하게 설정할 것이고, 반대로 리눅스에서 마우스 포인터를 왼쪽 끝으로 이동하면 다시 윈도우로 포인터가 이동하게 설정할 것입니다.

그림5
그림5. 화면 설정 모습

화면을 추가하고, "+" 버튼을 클릭해서 목록에 추가합니다. 두 가지 설정을 모두 추가한 후의 모습은 다음과 같습니다.

그림6
그림6. 두 화면의 관계를 설정

사람에 따라서는 좌우로 화면을 넘기는 것이 불편하게 여겨질 수도 있기 때문에 top, bottom을 선택해서 모니터 위로 넘겼을 때, 마우스 포인터를 이동하게 지정할 수도 있습니다. 설정이 끝났으면 "OK"를 클릭해서 이전 화면으로 이동합니다.

여기서는 "Advanced" 버튼을 클릭해서, 시스템의 이름을 설정합니다. 시너지는 윈도우 시스템의 NetBIOS 이름을 화면 이름으로 사용하는데, 대부분의 사용자는 NetBIOS 이름이 뭔지도 모르는 경우가 많기 때문에 화면 이름을 "win"으로 설정했었습니다. 여기서, 시스템의 이름을 설정합니다. 스크린의 이름과 같게 하는것이 헷갈리지 않습니다.

그림7
그림7. 고급 설정

그림8
그림8. 화면 이름 설정

[그림8]에서 화면 이름을 "win"으로 입력하면 됩니다. 포트는 24800이 기본값이며, 특별한 경우가 아니면 변경하지 않는 것이 좋습니다. 모두 끝났으면, 다시 "OK" 버튼을 클릭해서 이전화면으로 돌아갑니다.
(client 설정시에는 밑에 Interface 항목에 서버의 IP를 입력한다)

그림9
그림9. 자동 시작 설정

그림9에서 "AutoStart" 버튼을 클릭하면, 시너지의 시작을 설정할 수 있습니다. 그림10에서처럼, 왼쪽은 사용자가 시스템에 로그인했을 때, 자동시작하게 할 수 있으며, 오른쪽은 시스템이 부팅만 하면 시작하게 설정할 수 있습니다. 이 사항은 원하는 대로 선택하면 됩니다.

그림10
그림10. 시너지의 자동시작 설정

자동시작도 선택했으면 "Close" 버튼을 클릭해서 이전 화면으로 돌아옵니다.

그림11
그림11. 시너지 화면

[그림11]에서 "Test"나 "Start" 버튼을 누르면 시너지를 서버로 실행하게 되며, "Start"를 선택해서 서버로 시작합니다. 서버로 실행중이면, 트레이 아이콘에 시너지 아이콘이 생기며, 클라이언트와 연결되면 아이콘에 번개 모양이 생깁니다.

다음은 시너지를 클라이언트에서 설정해봅시다.
client 설정시 항목에는 서버의 Screen name을 넣고 advance에서
Interface항목에 서버의 IP를 넣으면 된다.
참고로, 윈도우-윈도우 시스템이라면 Host와 Guest모두 같은 방식으로 설치하면 됩니다.
Guest의 설정방법은 아래 리눅스와 같습니다.



2. 리눅스에서 시너지 클라이언트 설치하기

시너지를 설치하는 법은 쉽습니다. 먼저, 레드햇 사용자라면 RPM 패키지를 받아서 설치하면 되며, 저처럼 데비안을 사용하고 있다면 [apt-get install synergy]를 실행하면 됩니다. 설치가 끝났으면, /etc/hosts 파일을 편집하면 됩니다. 여기서는 caffe, win의 실제 IP를 설정했습니다.

192.168.0.22 caffe
192.168.0.24 win

hosts 파일의 설정에서 주의할 점이 있는데, 같은 IP에 여러 개의 이름을 할당하면 시너지는 첫번째만 인식한다는 점입니다. 즉, 다음과 같은 설정이 있다고 해봅시다.

192.168.0.22 coffee
192.168.0.22 caffe
192.168.0.24 win

이 경우엔, 192.168.0.22를 사용하는 시스템을 coffee로만 인식하고, caffe등은 무시되기 때문에 시너지로 연결되지 않습니다. 이것으로 시너지의 클라이언트 설정은 끝입니다. 이제, [synergyc win]으로 실행하면 됩니다. synergyc는 시너지 클라이언트이며, 서버의 이름을 인자로 전달하면 됩니다.

서버가 실행중일 때, 클라이언트를 실행했기 때문에 바로 연결될 것입니다. 시너지 클라이언트는 서버와 연결할 수 없을 때, 1, 3, 5, 15, 30초와 같이 간격을 늘려가면서 서버와의 연결을 시도하기 때문에 서버를 실행하고, 느긋하게(?) 기다리면 클라이언트와 연결된 시너지를 볼 수 있습니다.



3. 리눅스에서 시너지를 서버로 사용하기

리눅스에서 시너지를 서버로 사용하는 것은 권하지 않지만 (조금 불편하지요), 리눅스에서 시너지를 서버로 사용하고 싶다면 /etc/hosts 파일을 편집한 다음에 /etc/synergy.conf 파일을 편집하면 됩니다. 편집은 윈도우 버전에서 마우스 클릭으로 했던 것을 텍스트로 한다고 보면 됩니다. 윈도우의 설정과 같은 내용을 하면 다음과 같습니다.

section: screens
  caffe:
  win:
end

section: links
    caffe:
    left = win

     win:
     right = caffe
   end

screens 섹션에는 화면 이름을 추가해주고, links 섹션에는 caffe의 왼쪽을 윈도우로, win의 오른쪽을 caffe로 설정했습니다. 서버를 실행하기 위해서는 [synergys]만 실행하면 됩니다.

만약, 리눅스 시스템을 여러 사람이 공용으로 쓰는 환이라면 /etc/synergy.conf 대신에 /root/.synergy.conf와 같이 사용자 홈 디렉터리에서 설정하면 됩니다.



반응형
JVM GC와 메모리 튜닝




자바스터디 네트워크 [www.javastudy.co.kr]

조대협 [bcho_N_O_SPAM@j2eestudy.co.kr]




모든 Java Application은 JVM(Java Virtual Machine)위에서 동작한다.
이 JVM이 동작하는데 있어서, 메모리의 구조와 특히 GC는 Application의 응답시간과 성능에 밀접한 관계를 미친다. 이번 강좌에서는 JVM 의 메모리 구조와 GC 알고리즘 (JDK 1.4.X에 포함된 새로운 알고리즘 포함) 그리고, JVM의 메모리 튜닝을 통한 Application의 성능향상방법에 대해서 알아보도록 하자.


1.GC란 무엇인가?


GC는 Garbage Collection의 약자로 Java 언어의 중요한 특징중의 하나이다.
GC는 Java Application에서 사용하지 않는 메모리를 자동으로 수거하는 기능을 말한다.
예 전의 전통적인 언어 C등의 경우 malloc, free등을 이용해서 메모리를 할당하고, 일일이 그 메모리를 수거해줘야했다. 그러나 Java 언어에서는 GC 기술을 사용함에 따라서 개발자로 하여금 메모리 관리에서 부터 좀더 자유롭게 해주었다.


2.GC의 동작 방법은 어떻게 되는가?


1) JVM 메모리 영역

GC의 동작 방법을 이해하기 위해서는 Java의 메모리 구조를 먼저 이해할 필요가 있다.
일반적으로 Application에서 사용되는 객체는 오래 유지 되는 객체보다, 생성되고 얼마안있어서 사용되지 않는 경우가 많다. <그림 1 참조>


<그림 1. 메모리 foot print>


그래서 Java에서는 크게 두가지 영역으로 메모리를 나누는데 Young 영역과 Old 영역이 그것이다.
Young 영역은 생긴지 얼마 안된 객체들을 저장하는 장소이고, Old영역은 생성된지 오래된 객체를 저장하는 장소이다. 각 영역의 성격이 다른 만큼 GC의 방법도 다르다.
먼저 Java의 메모리 구조를 살펴보자.


<그림 2. Java 메모리 구조>


Java의 메모리 영역은 앞에서 이야기한 두 영역 (Young 영역,Old 영역)과 Perm 영역 이렇게 3가지로 영역으로 구성된다.


<표 1. Java 메모리 영역>



2) GC 알고리즘

그러면 이 메모리 영역을 JVM이 어떻게 관리하는지에 대해서 알아보자.
JVM 은 New/Young 영역과, Old영역 이 두영역에 대해서만 GC를 수행한다. Perm영역은 앞에서 설명했듯이 Code가 올라가는 부분이기 때문에, GC가 일어날 필요가 없다. Perm영역은 Code가 모두 Load되고 나면 거의 일정한 수치를 유지한다.


○ Minor GC
먼저 New/Young영역의 GC방법을 살펴보자 New/Young 영역의 GC를 Minor GC라고 부르는데, New/Young영역은 Eden과 Survivor라는 두가지 영역으로 또 나뉘어 진다. Eden영역은 Java 객체가 생성되자 마자 저장이 되는곳이다. 이렇게 생성된 객체는 Minor GC가 발생할때 Survivor 영역으로 이동된다.

Survivor 영역은 Survivor 1과 Suvivor2 영역 두 영역으로 나뉘어 지는데, Minor GC가 발생하면 Eden과 Survivor1에 Alive되어 있는 객체를 Suvivor2로 복사한다. 그리고 Alive되어 있지 않는 객체는 자연히 Suvivor1에 남아있게 되고, Survivor1과 Eden영역을 Clear한다. (결과적으로 Alive된 객체만 Survivor2로 이동한것이다.)
다음번 Minor GC가 발생하면 같은 원리로 Eden과 Survivor2영역에서 Alive되어 있는 객체를 Survivor1에 복사한다. 계속 이런 방법을 반복적으로 수행하면서 Minor GC를 수행한다.

이렇게 Minor GC를 수행하다가, Survivor영역에서 오래된 객체는 Old영역으로 옮기게 된다.

이 런 방식의 GC 알고리즘을 Copy & Scavenge라고 한다. 이 방법은 매우 속도가 빠르며 작은 크기의 메모리를 Collecting하는데 매우 효과적이다. Minor GC의 경우에는 자주 일어나기 때문에, GC에 소요되는 시간이 짧은 알고리즘이 적합하다.

이 내용을 그림을 보면서 살펴보도록 하자.


<그림 3-1. 1st Minor GC>


Eden에서 Alive된 객체를 Suvivor1으로 이동한다. Eden 영역을 Clear한다.


<그림 3-2. 2nd Minor GC>


Eden영역에 Alive된 객체와 Suvivor1영역에 Alive된 객체를 Survivor 2에 copy한다.
Eden영역과 Suvivor2영역을 clear한다.


<그림 3-3. 3rd Minor GC>


객체가 생성된 시간이 오래지나면 Eden과 Suvivor영역에 있는 오래된 객체들을 Old 영역으로 이동한다.


○ Full GC

Old 영역의 Garbage Collection을 Full GC라고 부르며, Full GC에 사용되는 알고리즘은 Mark & Compact라는 알고리즘을 이용한다. Mark & Compact 알고리즘은 전체 객체들의 reference를 쭉 따라가다면서 reference가 연결되지 않는 객체를 Mark한다. 이 작업이 끝나면 사용되지 않는 객체를 모두 Mark가 되고, 이 mark된 객체를 삭제한다.<그림 4 참고> (실제로는 compact라고 해서, mark된 객체로 생기는 부분을 unmark된 즉 사용하는 객체로 메꾸어 버리는 방법이다.)

Full GC는 매우 속도가 느리며, Full GC가 일어나는 도중에는 순간적으로 Java Application이 멈춰 버리기 때문에, Full GC가 일어나는 정도와 Full GC에 소요되는 시간은 Application의 성능과 안정성에 아주 큰 영향을 준다.


<그림 4. Full GC>




3. GC가 왜 중요한가?


Garbage Collection중에서 Minor GC의 경우 보통 0.5초 이내에 끝나기 때문에 큰문제가 되지 않는다. 그러나 Full GC의 경우 보통 수초가 소요가 되고, Full GC동안에는 Java Application이 멈춰버리기 때문에 문제가 될 수 있다.
예를 들어 게임 서버와 같은 Real Time Server를 구현을 했을때, Full GC가 일어나서 5초동안 시스템이 멈춘다고 생각해보자.
또 일반 WAS에서도 5~10초동안 멈추면, 멈추는동안의 사용자의 Request가 Queue에 저장되었다가 Full GC가 끝난후에 그 요청이 한꺼번에 들어오게 되면 과부하에 의한 여러 장애를 만들 수 있다..
그래서 원할한 서비스를 위해서는 GC를 어떻게 일어나게 하느냐가 시스템의 안정성과 성능에 큰 변수로 작용할 수 있다.


4. 다양한 GC 알고리즘


앞 에서 설명한 기본적인 GC방법 (Scavenge 와 Mark and compact)이외에 JVM에서는 좀더 다양한 GC 방법을 제공하고 그 동작방법이나 사용방법도 틀리다. 이번에는 다양한 GC 알고리즘에 대해서 알아보자. 현재 (JDK 1.4)까지 나와 있는 JVM의 GC방법은 크게 아래 4가지를 지원하고 있다.

- Default Collector
- Parallel GC for young generation (from JDK 1.4 )
- Concurrent GC for old generation (from JDK 1.4)
- Incremental GC (Train GC)

1) Default Collector
이 GC 방법은 앞에서 설명한 전통적인 GC방법으로 Minor GC에 Scavenge를, Full GC에 Mark & compact 알고리즘을 사용하는 방법이다. 이 알고리즘에는 이미 앞에서 설명했기 때문에 별도의 설명을 하지는 않는다.

JDK 1.4에서부터 새로 적용되는 GC방법은 Parallel GC와 Concurrent GC 두가지 방법이 있다. Parallel GC는 Minor GC를 좀더 빨리하게 하는 방법이고 (Throughput 위주) Concurrent GC는 Full GC시에 시스템의 멈춤(Pause)현상을 최소화하는 GC방법이다.

2) Parallel GC
JDK1.3까지 GC는 하나의 Thread에서 이루어진다. Java가 Multi Thread환경을 지원함에도 불구하고, 1 CPU에서는 동시에 하나의 Thread만을 수행할 수 밖에 없기때문에, 예전에는 하나의 CPU에서만 GC를 수행했지만, 근래에 들어서 하나의 CPU에서 동시에 여러개의 Thread를 실행할 수 있는 Hyper Threading기술이나, 여러개의 CPU를 동시에 장착한 HW의 보급으로 하나의 HW Box에서 동시에 여러개의 Thread를 수행할 수 있게 되었다.

JDK 1.4부터 지원되는 Parallel GC는 Minor GC를 동시에 여러개의 Thread를 이용해서 GC를 수행하는 방법으로 하나의 Thread를 이용하는것보다 훨씬 빨리 GC를 수행할 수 있다.


<그림 7. Parallel GC 개념도>


< 그림 7> 을 보자 왼쪽의 Default GC방법은 GC가 일어날때 Thread들이 작업을 멈추고, GC를 수행하는 thread만 gc를 수행한다. (그림에서 파란영역), Parallel GC에서는 여러 thread들이 gc를 수행이 가능하기 때문에, gc에 소요되는 시간이 낮아진다.

Parallel GC가 언제나 유익한것은 아니다. 앞에서도 말했듯이 1CPU에서는 동시에 여러개의 thread를 실행할 수 없기 때문에 오히혀 Parallel GC가 Default GC에 비해서 느리다. 2 CPU에서도 Multi thread에 대한 지원이나 계산등을 위해서 CPU Power가 사용되기 때문에, 최소한 4CPU의 256M 정도의 메모리를 가지고 있는 HW에서 Parallel GC가 유용하게 사용된다.

Parallel GC는 크게 두가지 종류의 옵션을 가지고 있는데,Low-pause 방식과 Throughput 방식의 GC방식이 있다.

Solaris 기준에서 Low-pause Parallel GC는 ?XX:+UseParNewGC 옵션을 사용한다. 이 모델은 Old 영역을 GC할때 다음에 설명할 Concurrent GC방법과 함께 사용할 수 있다. 이 방법은 GC가 일어날때 빨리 GC하는것이 아니라 GC가 발생할때 Application이 멈춰지는 현상(pause)를 최소화하는데 역점을 뒀다.

Throughput 방식의 Parallel GC는 ?XX:+UseParallelGC (Solaris 기준) 옵션을 이용하며 Old 영역을 GC할때는 Default GC (Mark and compact)방법만을 사용하도록 되어 있다.Minor GC가 발생했을때, 되도록이면 빨리 수행하도록 throughput에 역점을 두었다.

그외에도 ParallelGC를 수행할때 동시에 몇개의 Thread를 이용하여 Minor영역을 Parallel GC할지를 결정할 수 있는데, -XX:ParallelGCThreads= 옵션을 이용하여 Parallel GC에 사용되는 Thread의 수를 지정할 수 있다.

3) Concurrent GC

앞에서도 설명했듯이, Full GC즉 Old 영역을 GC하는 경우에는 그 시간이 길고 Application이 순간적으로 멈춰버리기 때문에, 시스템 운용에 문제가 된다.

그래서 JDK1.4부터 제공하는 Concurrent GC는 기존의 이런 Full GC의 단점을 보완하기 위해서 Full GC에 의해서 Application이 멈추어 지는 현상을 최소화 하기 위한 GC방법이다.
Full GC에 소요되는 작업을 Application을 멈추고 진행하는것이 아니라, 일부는 Application이 돌아가는 단계에서 수행하고, 최소한의 작업만을 Application이 멈췄을때 수행하는 방법으로 Application이 멈추는 시간을 최소화한다.


<그림 8. Concurrent GC 개념도>


그 림 8에서와 같이 Application이 수행중일때(붉은 라인) Full GC를 위한 작업을 수행한다. (Sweep,mark) Application을 멈추고 수행하는 작업은 일부분 (initial-mark, remark 작업)만을 수행하기 때문에, 기존 Default GC의 Mark & Sweep Collector에 비해서 Application이 멈추는 시간이 현저하게 줄어든다.

Solaris JVM에서는 -XX:+UseConcMarkSweepGC Parameter를 이용해 세팅한다.

4) Incremental GC (Train GC)

Incremental GC또는 Train GC라고도 불리는 GC방법은 JDK 1.3에서부터 지원된 GC방법이다. 앞에서 설명한 Concurrent GC와 비슷하게, 의도 자체는 Full GC에 의해서 Application이 멈추는 시간을 줄이고자 하는데 있다.

Incremental GC의 작동방법은 간단하다. Minor GC가 일어날때 마다 Old영역을 조금씩 GC를 해서 Full GC가 발생하는 횟수나 시간을 줄이는 방법이다.


<그림 9. Incremental GC 개념도>


그 림 9에서 보듯이. 왼쪽의 Default GC는 FullGC가 일어난후에나 Old 영역이 Clear된다. 그러나, 오른쪽의 Incremental GC를 보면 Minor GC가 일어난후에, Old 영역이 일부 Collect된것을 볼 수 있다.

Incremental GC를 사용하는 방법은 JVM 옵션에 ?Xinc 옵션을 사용하면 된다.
Incremental GC는 많은 자원을 소모하고, Minor GC를 자주일으키고, 그리고 Incremental GC를 사용한다고 Full GC가 없어지거나 그 횟수가 획기적으로 줄어드는 것은 아니다. 오히려 느려지는 경우가 많다. 필히 테스트 후에 사용하도록 하자.

※ Default GC이외의 알고리즘은 Application의 형태나 HW Spec(CPU수, Hyper threading 지원 여부), 그리고 JVM 버전(JDK 1.4.1이냐 1.4.2냐)에 따라서 차이가 매우 크다. 이론상으로는 실제로 성능이 좋아보일 수 있으나, 운영환경에서는 여러 요인으로 인해서 기대했던것만큼의 성능이 안나올 수 있기 때문에, 실환경에서 미리 충분한 테스트를 거쳐서 검증한후에 사용해야 한다.


5. GC 로그는 어떻게 수집과 분석


JVM에서는 GC 상황에 대한 로그를 남기기 위해서 옵션을 제공하고 있다.
Java 옵션에 ?verbosegc 라는 옵션을 주면되고 HP Unix의 경우 ?verbosegc ?Xverbosegc 옵션을 주면 좀더 자세한 GC정보를 얻을 수 있다. GC 정보는 stdout으로 출력이 되기 때문에 “>” redirection등을 이용해서 file에 저장해놓고 분석할 수 있다.

Example ) java ?verbosegc MyApplication

그럼 실제로 나온 GC로그를 어떻게 보는지를 알아보자.


<그림 5. 일반적인 GC 로그, Windows, Solaris>


<그림 5>는 GC로그 결과를 모아논 내용이다. (실제로는 Application의 stdout으로 출력되는 내용과 섞여서 출력된다.)
Minor GC는 ”[GC “로 표기되고, Full GC는 “[Full GC”로 표기된다.
그 다음값은 Heap size before GC인데,GC 전에 Heap 사용량 ( New/Young 영역 + Old 영역 + Perm 영역)의 크기를 나타낸다.

Heap size after GC는 GC가 발생한후에 Heap의 사용량이다. Minor GC가 발생했을때는 Eden과 Survivor 영역으 GC가 됨으로 Heap size after GC는 Old영역의 용량과 유사하다.(Minor GC에서 GC되지 않은 하나의 Survivor영역내의 Object들의 크기도 포함해야한다.)

Total Heap Size는 현재 JVM이 사용하는 Heap Memory양이다. 이 크기는 Java에서 ?ms와 ?mx 옵션으로 조정이 가능한데. 예를 들어 ?ms512m ?mx1024m로 해놓으면 Java Heap은 메모리 사용량에 따라서 512~1024m사이의 크기에서 적절하게 늘었다 줄었다한다. (이 늘어나는 기준과 줄어드는 기준은 (-XX:MaxHeapFreeRatio와 ?XX:MinHeapFreeRation를 이용해서 조정할 수 있으나 JVM vendor에 따라서 차이가 나기때문에 각 vendor별 JVM 메뉴얼을 참고하기 바란다.) Parameter에 대한 이야기는 추후에 좀더 자세히하도록 하자.

그 다음값은 GC에 소요된 시간이다.

< 그림 5>의 GC로그를 보면 Minor GC가 일어날때마다 약 20,000K 정도의 Collection이 일어난다. Minor GC는 Eden과 Suvivor영역 하나를 GC하는 것이기 때문에 New/Young 영역을 20,000Kbyte 정도로 생각할 수 있다.

Full GC때를 보면 약44,000Kbyte에서 1,749Kbyte로 GC가 되었음을 볼 수 있다. Old영역에 큰 데이타가 많지 않은 경우이다. Data를 많이 사용하는 Application의 경우 전체 Heap이 512이라고 가정할때, Full GC후에도 480M정도로 유지되는 경우가 있다. 이런 경우에는 실제로 Application에서 Memory를 많이 사용하고 있다고 판단할 수 있기 때문에 전체 Heap Size를 늘려줄 필요가 있다.

이렇게 수집된 GC로그는 다소 보기가 어렵기 때문에, 좀더 쉽게 분석할 수 있게 하기 위해서 GC로그를 awk 스크립트를 이용해서 정제하면 분석이 용이하다.


<표 2. gc.awk 스크립트>


이 스크립트를 작성한후에 Unix의 awk 명령을 이용해서

% awk ?f gc.awk GC로그파일명

을 쳐주면 아래<표 3>와 같이 정리된 형태로 GC 로그만 추출하여 보여준다.


<표 3. gc.awk 스크립트에 의해서 정재된 로그>


Minor와 Major는 각각 Minor GC와 Full GC가 일어날때 소요된 시간을 나타내며, Alive는 GC후에 남아있는 메모리양, 그리고 Freed는 GC에 의해서 collect된 메모리 양이다.

이 로그파일은 excel등을 이용하여 그래프등으로 변환해서 보면 좀더 다각적인 분석이 가능해진다.

※ JDK 1.4에서부터는 ?XX:+PrintGCDetails 옵션이 추가되어서 좀더 자세한 GC정보를 수집할 수 있다.


※ HP JVM의 GC Log 수집

HP JVM은 전체 heap 뿐 아니라 ?Xverbosegc 옵션을 통해서 Perm,Eden,Old등의 모든 영역에 대한 GC정보를 좀더 정확하게 수집할 수 있다.

Example ) java ?verbosegc ?Xverbosegc MyApplication ß (HP JVM Only)

HP JVM의 GC정보는 18개의 필드를 제공하는데 그 내용을 정리해보면 <표 4.>와 같다.

<GC : %1 %2 %3 %4 %5 %6 %7 %8 %9 %10 %11 %12 %13 %14 %15 %16 %17 %18>


<표 4. HP JVM GC 로그 필드별 의미>


이 로그를 직접 보면서 분석하기는 쉽지가 않다. 그래서, HP에서는 좀더 Visual한 환경에서 분석이 가능하도록 HPJtune이라는 툴을 제공한다. 다음 URL에서 다운로드 받을 수 있다.

http://www.hp.com/products1/unix/java/java2/hpjtune/index.html


<그림 6. HP Jtune을 이용해서 GC후 Old영역의 변화 추이를 모니터링하는 화면>




6. GC 관련 Parameter


GC 관련 설정값을 보기전에 앞서서 ?X와 ?XX 옵션에 대해서 먼저 언급하자. 이 옵션들은 표준 옵션이 아니라, 벤더별 JVM에서 따로 제공하는 옵션이기 때문에, 예고 없이 변경되거나 없어질 수 있기 때문에, 사용전에 미리 JVM 벤더 홈페이지를 통해서 검증한다음에 사용해야한다.

1) 전체 Heap Size 조정 옵션

전체 Heap size는 ?ms와 ?mx로 Heap 사이즈의 영역을 조정할 수 있다. 예를 들어 ?ms512m ?mx 1024m로 설정하면 JVM은 전체 Heap size를 application의 상황에 따라서 512m~1024m byte 사이에서 사용하게 된다. 그림2의 Total heap size

메모리가 모자를때는 heap을 늘리고, 남을때는 heap을 줄이는 heap growing과 shirinking 작업을 수행하는데, 메모리 변화량이 큰 애플리케이션이 아니라면 이 min heap size와 max heap size는 동일하게 설정하는 것이 좋다. 일반적으로 1GB까지의 Heap을 설정하는데에는 문제가 없으나, 1GB가 넘는 대용량 메모리를 설정하고자 할 경우에는 별도의 JVM 옵션이 필요한 경우가 있기때문에 미리 자료를 참고할 필요가 있다.

※ IBM AIX JVM의 경우
%export LDR_CNTRL=MAXDATA=0x10000000
%java -Xms1500m -Xmx1500m MyApplication

2) Perm size 조정 옵션

Perm Size는 앞에서도 설명했듯이, Java Application 자체(Java class etc..)가 로딩되는 영역이다. J2EE application의 경우에는 application 자체의 크기가 큰 편에 속하기 때문에, Default로 설정된 Perm Size로는 application class가 loading되기에 모자른 경우가 대부분이기 때문에, WAS start초기나, 가동 초기에 Out Of Memory 에러를 유발하는 경우가 많다.

PermSize는 -XX:MaxPermSize=128m 식으로 지정할 수 있다.
일반적으로 WAS에서 PermSize는 64~256m 사이가 적절하다.

3) New 영역과 Old 영역의 조정New 영역은 ?XX:NewRatio=2 에 의해서 조정이 된다.
NewRatio Old/New Size의 값이다. 전체 Heap Size가 768일때, NewRatio=2이면 New영역이 256m, Old 영역이 512m 로 설정이 된다.
JVM 1.4.X에서는 ?XX:NewSize=128m 옵션을 이용해서 직접 New 영역의 크기를 지정하는 것이 가능하다.

4) Survivor 영역 조정 옵션
-XX:SurvivorRatio=64 (eden/survivor 의 비율) :64이면 eden 이 128m일때, survivor영역은 2m가 된다.

5) -server와 ?client 옵션
JVM에는 일반적으로 server와 client 두가지 옵션을 제공한다.
결 론만 말하면 server 옵션은 WAS와 같은 Server환경에 최적화된 옵션이고, client옵션은 워드프로세서와 같은 client application에 최적화된 옵션이다. 그냥 언뜻 보기에는 단순한 옵션 하나로보일 수 있지만, 내부에서 돌아가는 hotspot compiler에 대한 최적화 방법과 메모리 구조자체가 아예 틀리다.

○ -server 옵션

server 용 application에 최적화된 옵션이다. Server application은 boot up 시간 보다는 user에 대한 response time이 중요하고, 많은 사용자가 동시에 사용하기 때문에 session등의 user data를 다루는게 일반적이다. 그래서 server 옵션으로 제공되는 hotspot compiler는 java application을 최적화 해서 빠른 response time을 내는데 집중되어 있다.

또한 메모리 모델 역시, 서버의 경우에는 특정 사용자가 서버 운영시간동안 계속 서버를 사용하는게 아니기 때문에 (Login하고, 사용한 후에는 Logout되기 때문에..) 사용자에 관련된 객체들이 오래 지속되는 경우가 드물다. 그래서 상대적으로 Old영역이 작고 New 영역이 크게 배정된다. <그림 7. 참조 >

○ -client 옵션

client application은 워드프로세서 처럼 혼자 사용하는 application이다. 그래서 client application은 response time보다는 빨리 기동되는데에 최적화가 되어 있다. 또한대부분의 client application을 구성하는 object는GUI Component와 같이 application이 종료될때까지 남아있는 object의 비중이 높기 때문에 상대적으로 Old 영역의 비율이 높다.


<그림 7. ?server와 ?client 옵션에 따른 JVM Old와 New영역>


이 두옵션은 가장 간단한 옵션이지만, JVM의 최적화에 아주 큰부분을 차지하고 있는 옵션이기 때문에, 반드시 Application의 성격에 맞춰서 적용하기 바란다.
(※ 참고로, SUN JVM은 default가 client, HPJVM는 default가 server로 세팅되어 있다.)

○ GC 방식에 대한 옵션

GC 방식에 대한 옵션은 앞에서도 설명했지만, 일반적인 GC방식이외에, Concurrent GC,Parallel GC,Inceremental GC와 같이 추가적인 GC Algorithm이 존재한다. 옵션과 내용은 앞장에서 설명한 “다양한 GC알고리즘” 을 참고하기 바란다.


7.JVM GC 튜닝


그러면 이제부터 지금까지 설명한 내용을 기반으로 실제로 JVM 튜닝을 어떻게 하는지 알아보도록 하자.

STEP 1. Application의 종류와 튜닝목표값을 결정한다.

JVM 튜닝을 하기위해서 가장 중요한것은 JVM 튜닝의 목표를 설정하는것이다. 메모리를 적게 쓰는것이 목표인지, GC 횟수를 줄이는것이 목표인지, GC에 소요되는시간이 목표인지, Application의 성능(Throughput or response time) 향상인지를 먼저 정의한후에. 그 목표치에 근접하도록 JVM Parameter를 조정하는것이 필요하다.

STEP 2. Heap size와 Perm size를 설정한다.

-ms 와 ?mx 옵션을 이용해서 Heap Size를 정한다. 일반적으로 server application인 경우에는 ms와 mx 사이즈를 같게 하는것이 Memory의 growing과 shrinking에 의한 불필요한 로드를 막을 수 있어서 권장할만하다.

ms와mx사이즈를 다르게 하는 경우는 Application의 시간대별 memory 사용량이 급격하게 변화가 있는 Application에 효과적이다.
PermSize 는 JVM vendor에 따라 다소 차이가 있으나 일반적으로 16m정도이다. Client application의 경우에는 문제가 없을 수 있지만, J2EE Server Application의 경우 64~128m 사이로 사용이 된다.

Heap Size와 Perm Size는 아래 과정을 통해서 적정 수치를 얻어가야한다.

STEP 3. 테스트 & 로그 분석.

JVM Option에 GC 로그를 수집하기 위한 ?verbosegc 옵션을 적용한다. (HP의 경우 ?Xverbosegc 옵션을 적용한다.)

LoadRunner 나 MS Strest(무료로 MS社의 홈페이지에서 다운로드 받을 수 있다.)와 같은 Strest Test툴을 통해서 Application에 Strest를 줘서. 그 log를 수집한다. 튜닝에서 있어서 가장 중요한것은 목표산정이지만, 그만큼이나 중요한것은 실제 Tuning한 Parameter가 Application에 어떤 영향을 주는지를 테스트하는 방법이 매우 중요하다. 그런 의미에서 적절한 Strest Tool의 선정과, Strest Test 시나리오는 정확한 Tuning을 위해서 매우 중요한 요인이다.

○ Perm size 조정
아래 그림8.은 HP JVM에서 ?Xverbosegc 옵션으로 수집한 GC log를 HP Jtune을 통해서 graph로 나타낸 그래프이다. 그림을 보면 Application이 startup되었을때 Perm 영역이 40m에서. 시간이 지난후에도 50m 이하로 유지되는것을 볼 수 있다. 특별하게 동적 classloading등이 수십m byte가 일어나지 않는등의 큰 변화요인이 없을때, 이 application의 적정 Perm 영역은 64m로 판단할 수 있다.


<그림 8. GC 결과중 Perm 영역 그래프>


○ GC Time 수행 시간 분석

다음은 GC에 걸린 시간을 분석해보자. 앞에 강좌 내용에서도 설명햇듯이. GC Tuning에서 중요한 부분중 하나가 GC에 소요되는 시간 특히 Full GC 시간이다.

지금부터 볼 Log는 모社의 물류 시스템의 WAS 시스템 GC Log이다. HP JVM을 사용하며, -server ?ms512m ?mx512m 옵션으로 기동되는 시스템이다.

그림 9를 보면 Peak 시간 (첫번째 동그라미) 14시간동안에 Full GC(동그란점)가 7번일어난것을 볼 수 있다. 각각에 걸린 시간은2.5~6sec 사이이다.
여기서 STEP 1.에서 설정한 AP Tuning의 목표치를 참고해야하는데.

Full GC가 길게 일어나서 Full GC에 수행되는 시간을 줄이고자 한다면 Old 영역을 줄이면 Full GC가 일어나는 횟수는 늘어나고, 반대로 Full GC가 일어나는 시간을 줄어들것이다.

반대로 Full GC가 일어나는 횟수가 많다면, Old 영역을 늘려주면 Full GC가 일어나는 횟수는 상대적으로 줄어들것이고 반대로 Full GC 수행시간이 늘어날 것이다.

특 히 Server Application의 경우Full GC가 일어날때는 JVM자체가 멈춰버리기 때문에, 그림 9의 instance는 14시간동안 총 7번 시스템이 멈추고, 그때마다 2.5~6sec가량 시스템이 response를 못하는 상태가 된것이다. 그래서 멈춘 시간이 고객이 납득할만한 시간인지를 판단해야 하고, 거기에 적절한 Tuning을 해야한다.

Server Application에서 Full GC를 적게일어나게하고, Full GC 시간을 양쪽다 줄이기 위해서는 Old영역을 적게한후에, 여러개의 Instance를 동시에 뛰어서 Load Balancing을 해주면, Load가 분산되기 때문에 Full GC가 일어나는 횟수가 줄어들테고, Old 영역을 줄였기 때문에, Full GC에 드는 시간도 줄어들것이다. 또한 각각의 FullGC가 일어나는동안 하나의 서버 instance가 멈춰져 있어도, Load Balancing이 되는 다른 서버가 response를 하고 있기때문에, Full GC로 인한 Application이 멈추는것에 의한 영향을 최소화할 수 있다.


<그림 9. GC 소요시간>


데이타에 따라서 GC Tuning을 진행한후에는 다시 Strest Test를 진행해서 응답시간과 TPS(Throughput Per Second)를 체크해서 어떤 변화를 주었는지를 반드시 체크해봐야한다.


<그림 10. GC후의 Old 영역>


그림 10은 GC후에 Old 영역의 메모리 변화량을 나타낸다.

금 요일 업무시간에 메모리 사용량이 올라가다가. 주말에가서 완만한 곡선을 그리는것을 볼 수 있다. 월요일 근무시간에 메모리 사용량이 매우 많고, 화요일에도 어느정도 메모리 사용량이 있는것을 볼 수 있다. 월요일에 메모리 사용량이 많은것을 볼때, 이 시스템의 사용자들이 월요일에 시스템 사용량이 많을 수 있다고 생각할 수 있고, 또는 다른 주의 로그를 분석해봤을때 이 주만 월요일 사용량이 많았다면, 특별한 요인이나 Application 변경등이 있었는지를 고려해봐야할것이다.

이 그래프만을 봤을때 Full GC가 일어난후에도 월요일 근무시간을 보면 Old 영역이 180M를 유지하고 있는것을 볼 수 있다. 이 시스템의 Full GC후의 Old영역은 80M~180M를 유지하는것을 볼 수 있다. 그래서 이 시스템은 최소 180M이상의 Old 영역을 필요로하는것으로 판단할 수 있다.

STEP 4. Parameter 변경.
STEP 3에서 구한 각 영역의 허용 범위를 기준으로 Old영역과 New 영역을 적절하게 조절한다.
PermSize와 New영역의 배분 (Eden,Survivor)영역등을 조정한다.
PermSize 는 대부분 Log에서 명확하게 나타나기 때문에, 크게 조정이 필요가 없고 New영역내의 Eden과 Survivor는 거의 조정하지 않는다. 가장 중요한것은 Old영역과 New 영역의 비율을 어떻게 조정하는가가 관건이다.

이 비율을 결정하면서, STEP1에서 세운 튜닝 목표에 따라서 JVM의 GC Algorithm을 적용한다. GC Algorithm을 결정하는 기본적인 판단 내용은 아래와 같다.



이렇게 Parameter를 변경하면서 테스트를 진행하고, 다시 변경하고 테스트를 진행하는 과정을 거쳐서 최적의 Parameter와 GC Algorithm을 찾아내는것이 JVM의 메모리 튜닝의 이상적인 절차이다.


지금까지 JVM의 메모리 구조와 GC 모델 그리고 GC 튜닝에 대해서 알아보았다.

정 리하자면 GC 튜닝은 Application의 구조나 성격 그리고, 사용자의 이용 Pattern에 따라서 크게 좌우 되기때문에, 얼마만큼의 Parameter를 많이 아느냐 보다는 얼마만큼의 테스트와 로그를 통해서 목표 값에 접근하느냐가 가장 중요하다.


출처 : http://www.j2eestudy.co.kr/lecture_data/lecture0401_1_1_index.html

+ Recent posts