반응형

출처 : http://www.ibm.com/developerworks/kr/library/opendw/20061017/

웹 개발자에게 있어 톰캣은 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 

<Server port="11005" shutdown="SHUTDOWN"> <!-- 톰캣 프로세스를 관리하는 포트 --> <Service name="Catalina"> <Connector port="11080"/> <!-- 아파치를 통하지 않고 직접 접속하고자 할때의 포트 --> <Connector port="11009" protocol="AJP/1.3"/> <!-- 아파치와 연동하기 위한 포트 --> <!-- jvmRoute 명 JK 커넥터에서 톰캣 프로세스를 구분하는데 사용. 프로세스 별로 다르게 적용해야 함 --> <Engine jvmRoute="tomcat1" name="Catalina" defaultHost="localhost"> <Host name="localhost" appBase="webapps"/> </Engine> </Service> </Server>



리스트 4. server.xml 

<Server port="12005" shutdown="SHUTDOWN"> <!-- 톰캣 프로세스를 관리하는 포트 --> <Service name="Catalina"> <Connector port="12080"/> <!-- 아파치를 통하지 않고 직접 접속하고자 할때의 포트 --> <Connector port="12009" protocol="AJP/1.3"/> <!-- 아파치와 연동하기 위한 포트 --> <!-- jvmRoute 명 JK 커넥터에서 톰캣 프로세스를 구분하는데 사용. 프로세스 별로 다르게 적용해야 함 --> <Engine jvmRoute="tomcat2" name="Catalina" defaultHost="localhost"> <Host name="localhost" appBase="webapps"/> </Engine> </Service> </Server>


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

<Server> --> <Service> --> <Engine> --> <Host> --> <Context>


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

리스트 5. server.xml 

<Server port="8005" shutdown="SHUTDOWN"> <!-- Service 1 --> <Service name="Catalina1"> <Connector port="11080"/> <Connector port="11009" protocol="AJP/1.3"/> <Engine jvmRoute="tomcat1" name="Catalina" defaultHost="localhost"> <Host name="localhost" appBase="webapps"/> </Engine> </Service> <!-- Service 1 --> <Service name="Catalina2"> <Connector port="12080"/> <Connector port="12009" protocol="AJP/1.3"/> <Engine jvmRoute="tomcat2" name="Catalina" defaultHost="localhost"> <Host name="localhost" appBase="webapps"/> </Engine> </Service> </Server>


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







세션 클러스터링 설정

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

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

리스트 6. server.xml 

... <Cluster className="org.apache.catalina.cluster.tcp.SimpleTcpCluster" managerClassName="org.apache.catalina.cluster.session.DeltaManager" expireSessionsOnShutdown="false" useDirtyFlag="true"> <Membership className="org.apache.catalina.cluster.mcast.McastService" mcastAddr="228.0.0.105" mcastPort="45564" mcastFrequency="500" mcastDropTime="3000"/> <Receiver className="org.apache.catalina.cluster.tcp.ReplicationListener" tcpListenAddress="auto" tcpListenPort="4001" tcpSelectorTimeout="100" tcpThreadCount="6"/> <Sender className="org.apache.catalina.cluster.tcp.ReplicationTransmitter" replicationMode="pooled"/> <Valve className="org.apache.catalina.cluster.tcp.ReplicationValve" filter=".*\.gif;.*\.js;.*\.jpg;.*\.htm;.*\.html;.*\.txt;"/> </Cluster> ...


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




위로



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

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

리스트 7. index.jsp 

<%@ page contentType="text/html; charset=euc-kr" %> <HTML> <HEAD> <TITLE>세션 JSP 테스트</TITLE> <link rel="stylesheet" type="text/css" href="http://s1.daumcdn.net/cfs.tistory/v/111130102906/blog/style/menubar.css"/><style type="text/css">.tt_article_useless_p_margin p {padding-top:0 !important;padding-bottom:0 !important;margin-top:0 !important;margin-bottom:0 !important;}</style></HEAD> <BODY> <h1>세션 JSP 테스트</h1> <% 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); %> 당신은 이곳을 <b> <%= ival %> </b>번 방문 했습니다.<p> 여기를 클릭하세요. <a href="index.jsp">여기</a> <p> <h3>request 객체와 관련된 세션 데이터</h3> 요청된 세션 ID : <%= request.getRequestedSessionId() %><br /> 쿠키로 부터 요청된 세션 ID 인가? : <%= request.isRequestedSessionIdFromCookie() %><br /> URL로부터 요청된 세션 ID 인가? : <%= request.isRequestedSessionIdFromURL() %><br /> 유효한 세션 ID 인가? : <%= request.isRequestedSessionIdValid() %><br /> </BODY> </HTML>


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



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




위로



참고 자료
The Apache Tomcat Connector: http://tomcat.apache.org/connectors-doc/ 
Clustering/Session Replication HOW-TO: http://tomcat.apache.org/tomcat-5.5-doc/cluster-howto.html 

반응형

'Reference > 스크랩' 카테고리의 다른 글

[스크랩] L4/L7 스위치 개요 (로드밸런서)  (0) 2014.06.18
ajaxplorer 사용법  (0) 2013.07.07
[스크랩]ajaxplorer  (1) 2013.07.04
HTTP 에러 정리  (0) 2013.03.11
루씬 개요  (0) 2013.01.07
블로그 이미지

cocy

조금은 가볍게! 시작은 새롭게!

,
반응형

스위치의 분류 :

L2 : OSI 레이어 2에 속하는 MAC 어드레스를 참조하여 스위칭하는 장비


L3 : OSI 레이어 3에 속하는 IP주소를 참조하여 스위칭하는 장비


L4 : OSI 레이어 3~4에 속하는 IP 주소 및 TCP/UDP 포트 정보를 참조하여 스위칭하는 장비


L7 : OSI 레이어 3~7에 속하는 IP 주소, TCP/UDP 포트 정보 및 패킷 내용까지 참조하여 스위칭함





L4/L7 스위치의 용도 :


일반적으로 서버들의 로드밸런싱을 위해 사용됨


복수개의 웹서버가 있을 때, 임의의 웹서버에 접속을 시도하면, 스위치가 각 서버의 부하를 고려하여


적당한 서버와 연결시켜준다.


설정에 따라 순차적 연결 또는 접속이 가장 적은 서버에 연결하는 방식 등이 있다.



L4 스위치 :


Layer 4에서 패킷을 확인하고 세션을 관리하며, 로드밸런싱을 제공하는 스위치

TCP/UDP 패킷 정보를 분석해서 해당 패킷이 사용하는 서비스 종류 별로 처리(HTTP, FTP, SMTP...)

세션관리, 서버/방화벽 로드밸런싱, 네트워크 서비스 품질 보장


 
 
L7 스위치 :

L4 스위치의 서비스 단위 로드밸런싱을 극복하기 위해 포트 + 데이터 페이로드 패턴을 이용한 패킷 스위치

(e-mail 내용/제목, URL ...)

connection pooling(시스템 부하 감소), Traffic Compression (컨텐츠 압축 전송), 보안 기능


 
L4 vs L7 :
 
공통점 : 스위치로 들어온 패킷을 적절한 목적지로 전송해줌 (불필요한 패킷은 drop시킴)

차이점 : 
 
  기능과 역할은 동일하나 패킷을 분석하는 인텔리전스가 다름

  L7은 보안 기능 강화

  (DOS/SYN 공격 방어, CodeRed/Nimda 등 감염 패킷 필터링, 네트워크 자원 독점 방지 등)

L7 스위치에 대한 오해 :
 
  L7 스위치는 레이어 7 계층을 위한 스위치이다.

     : 기본적으로 L2, L3 및 부분적으로 L4 스위치를 지원한다. 레이어5 세션 계층 위주이다.

  L7 스위치는 URL 기반 스위치다.

     : L7 스위치 기능에 대한 일부분을 말한 것이다.

  L7 스위치는 모든 TCP/UDP 포트(0-65535)에 대한 인지가 가능하다.

     : 알려진 일반 포트에 대한 세션처리는 가능하지만, 순간적으로 사용하는 임시 포트는 제한적이다.

 
sticky session :
 
L4 스위치를 통해 분배된 서비스 세션은 하나의 연결 요청에 1~n 중에 한 대의 서버에 분배된다.
 
여러 번 시도해도 그 때마다 1~n 중에 한 대에 분배되므로, 같은 서버에 접속될 확률은 1/n이 된다.
 
그러나 처음에 접속했던 서버와 같은 서버에 계속 연결시킬 수 있다.
 
바로  sticky 옵션이다.
 
(일반적인 상태)
사용자A -> L4 -> 1번서버
사용자A -> L4 -> 3번서버

(sticky 상태)
사용자A -> L4 -> 1번서버
사용자A -> L4 -> 1번서버

기존 사용자의 세션 상태를 timeout 시간 내에는 계속 유지시켜주는 것이 sticky session이다.

timeout 시간은 60분 이내로 조절 가능하다.
 
 
sticky session의 문제점 :

L4 스위치의 가장 큰 목적(?)인 로드밸런싱이 제대로 동작하지 않을 수 있다.
 
개별 사용자가 사용할 경우에는 세션 timeout이 있으므로 어느 정도 로드밸런싱을 충족시킨다.
 
하지만 프록시서버를 사용하는 경우 문제가 된다.
 
예를 들어 회사에서 외부로 나가는 경우 각 PC의 IP가 아니라 프록시서버의 IP를 달고 나간다.
 
여러 사람이 timeout 시간 내에 접속하는 경우, 계속해서 한 서버에만 로드가 집중된다.
 
(외부에서 보기에는 동일한 사람으로 보이므로)


대안 :

SSL이나 기타 다른 보안모듈을 이용해서 인증된 특정 사용자에 대해서 Cookie/DB에 기록 후
 
해당 사용자에 대해서만 세션을 유지하도록 한다. (단점 : performance 저하 및 기타 cost)
 
그래서 L7 스위치를 사용한다.

 
< L7 스위칭 방식 >

URL 스위칭 :

URL 주소에서 특정 String을 검사하고, 검색된 문자열을 기준으로 부하를 분산시키는 방식이다.
 
http://www.test.com/test.html 이라는 주소로 사용자들이 웹페이지를 요청한다.
 
해당 페이지는 이미지가 빈번히 변경되고, 이미지 크기도 크다. (전체적으로 로딩이 느리다)
 
이런 경우, client의 http request 내용에 html이 들어가면, 메인 웹서버로 전송하고..
 
해당 request에 jpg 등의 이미지를 요청하는 경우 이미지 웹서버로 분산할 수 있다.
 

Cookie 스위칭 :
 
Http header의 cookie 값에 따른 특정 String을 기준으로 부하를 분산하는 방식이다.
 
Cookie 값 필드를 보고 설정된 분류 기준에 따라 어느 서버로 보낼지 결정한다.


 
Content 스위칭 :
 
legacy한 L7 스위칭은 URL/Cookie 스위칭을 사용했으나,
 
최근 L7 스위칭은 Content 스위칭 방식을 이용한다.
 
기존에는 제한적인 기능, 즉 호스트네임, URL, Cookie 를 기준으로 로드밸런싱을 하였으나,
 
L7 content 스위칭은 추가적인 기능을 지원한다.
 
  Http header 의 모든 필드를 기반으로 한다.
 
  XML content를 기반으로 한다.
 
  XML tags 나 multiple Http header를 기준으로 복잡한 로드밸런싱을 구현한다.
 
  Cookie 와 http header의 insertion과 deletion을 포함한 contents-rewrite 기능을 지원한다.
 
  alternate한 url이나 도메인의 redirecting request를 지원한다.

출처 : http://freeism.web-bi.net/tc/657



------------------------------------------------------------------------------------------


L4장비 로드 밸런싱 알고리즘


1. Hashing algorithm

 

Hashing (hash) 알고리즘에서는 새로은 연결(TCP/UDP)시 각 클라이언트에 대해 hashing key를 가지고 경로를 지정한다. Hashing key는 클라이언트의 IP + port 혹은 IP 주소만으로 결정된다.

 

장점 : 메모리를 적게 사용하고 요구 절차가 간단.

 

2. Round-robin algorithm

 

Round-robin 알고리즘은 round-robin 방식으로 경로를 지정한다. 모든 클라이언트는 동일하게 취급되며 실 서버 혹은 경로는 같은 처리량을 보유해야 한다. SLB에 많이 사용되며 만약 각기 다른 처리 능력을 가진 서버가 있을 경우 weigted round-robin 알고리즘이 더 효율적이다.

 

 

3. Weighted round-robin algorithm

 

Weighted round-robin 알고리즘은 서로 다른 처리 능력을 가진 서버가 있을 경우 사용한다. 가중치를 주어 많이 처리할 수 있는 서버로 많은 트래픽을 할당한다.

 

 

4. Least connection algorithm

 

이 알고리즘은 연결 수가 가장 적은 서버에 네트워크 연결방향을 정한다. 동적인 분산 알고리즘으로 각 서버에 대한 현재 연결 수를 동적으로 카운트할 수 있다.  동적으로 변하는 요청에 대한 부하를 분산시킬 수 있다.

 

5. Weighted least-connectin algorithm

 

이 알고르짐은 서버의 처리 능력을 고려하여 가중치를 부여하면서 least-connection scheduling을 적용하여 트래픽을 고루게 분산시키는 방법이다. 



--------------------------------------------------------------------------------------------


L4장비 사용( 로드밸런싱 사용 알고리즘 확인 필요)

1. 웹서버와 세션 유지시간 일치후 사용(sticky 옵션)

- 적절한 로드밸런싱이 이루어지지 않을 수 있음

> 단체에서 프록시 서버를 이용하는경우

- 라운드 로빈방식 보다는 hash방식에 적합

2. 세션 서버 사용

- 별도의 서버 필요(Redis, infinispan)

> 리소스 오버헤드

- 혹은 세션 클러스터링 설정(WAS, 라운드 로빈방식) 필요


3. 쿠키사용 

> 보안 이슈, 암호화 필요

> 부분 정보 쿠키 사용시 매번 api호출 오버헤드 발생

> 일부 쿠키 지원안하는 브라우저 사용유저 발생 가능성

반응형

'Reference > 스크랩' 카테고리의 다른 글

[스크랩] Apache - Tomcat 로드 밸런싱, 세션 클러스터링  (0) 2014.06.18
ajaxplorer 사용법  (0) 2013.07.07
[스크랩]ajaxplorer  (1) 2013.07.04
HTTP 에러 정리  (0) 2013.03.11
루씬 개요  (0) 2013.01.07
블로그 이미지

cocy

조금은 가볍게! 시작은 새롭게!

,
반응형

AjaxPlorer 의 사용법을 알아보도록 하겠습니다.

 

1. 화면 구성

 

전체적인 화면은 아래와 같이 되어 있습니다.

 

 

이걸 부분적으로 나눠보면 아래와 같이 되어 있습니다.

[상단]

 

메뉴를 가르키는 항목은 상단에 있습니다.

이 항목들은 아래 리스트에서 마우스 오른쪽를 누르면 나타납니다.

 

 

 

[폴더]

 

웹하드에 구성된 폴더를 볼 수 있습니다.

 

 

 

[정보 창]

 

웹하드에서 폴더 및 파일에 대한 정보를 볼 수 있습니다.

 

 

 

[파일 리스트 창]

 

파일을 업로드 하면 아래와 같이 리스트 창에 나타납니다.

처음엔 휴지통이 있지만, 파일을 생성하거나 올린 파일에 대해서 정보를 볼 수 있습니다.

 

 

 

2. 폴더 생성

 

파일을 올리기 위한 폴더를 생성을 해봅니다.

메뉴에서 3번째에 있는 새 폴더(N)를 선택해줍니다.

 

 

 

아래와 같이 '자료'라는 방을 생성해보도록 합니다.

 

 

 

파일 리스트 창에 폴더가 생성되었습니다.

요즘 서버에선 UTF-8을 잘 지원해줘서 그런지 한글 폴더명이 깨지지 않고 잘 나타납니다.

 

 

 

3. 업로드

 

이번엔 업로드를 테스트해 볼 차례입니다.

 

메뉴 항목의 업로드 메뉴를 선택합니다.

 

 

또는 리스트 창에서 마우스 오른쪽 버튼을 눌러서 업로드를 눌러줍니다.

웹 기반으로 만들어져서 그런지 마우스 오른쪽에서 쉽게 메뉴를 지원하도록 설정해놓은거 같습니다.

 

 

 

아래와 같이 업로드 창이 뜹니다.

왼쪽 위에 있는 [당신의 컴퓨터 탐색] 버튼을 눌러줍니다.

 

 

 

테스트로 'data.zip' 파일을 선택하도록 하였습니다.

 

 

 

업로드 하려는 데이터가 보입니다.

 

 

 

[전송] 버튼을 누르면 업로드가 진행됩니다.

아래 [옵션]에서 업로드 하자마자 바로 전송하게도 설정을 할 수 있습니다.

 

그리고 더 간단하게 마우스로 파일을 끌어다 놓으면 업로드가 활성화 됩니다.

오른쪽 아래 DROP FILES HERE 라는 메시지가 드래그로 쉽게 올릴 수 있음을 알려줍니다.

 

 

 

파일이 업로드가 되면 리스트에 나타나고 왼쪽 폴더 창과 정보 창에 파일에 대한 내용을 보여줍니다.

 

 

 

4. 다운로드

 

업로드를 했으니 다운르도를 해보도록 하겠습니다.

파일을 선택하면 상단 메뉴 창에 다운로드 버튼이 새로 생깁니다.

 

 

 

또는 파일 선택 후, 마우스 오른쪽 버튼을 눌러서 다운로드를 선택합니다.

다운로드 외에 압축을 풀거나 복사, 붙여넣기 같은 메뉴도 지원합니다.

 

 

다운로드를 누르면 일반 파일을 받는 것 처럼 다운로드를 시작합니다.

 

5. 파일 삭제

 

파일 삭제 역시 상단의 메뉴를 사용해보거나 마우스 오른쪽 버튼을 눌러서 삭제를 할 수 있습니다.

 

 

 

삭제를 하고 나면 목록에서 파일이 사라지고 리스트 아래 휴지통으로 이동되었다고 뜹니다.

파일을 완전 삭제하고 싶으면 휴지통에서 파일을 지워주면 됩니다.

 

 

반응형

'Reference > 스크랩' 카테고리의 다른 글

[스크랩] Apache - Tomcat 로드 밸런싱, 세션 클러스터링  (0) 2014.06.18
[스크랩] L4/L7 스위치 개요 (로드밸런서)  (0) 2014.06.18
[스크랩]ajaxplorer  (1) 2013.07.04
HTTP 에러 정리  (0) 2013.03.11
루씬 개요  (0) 2013.01.07
블로그 이미지

cocy

조금은 가볍게! 시작은 새롭게!

,
반응형

윈도우 탐색기 형태의 웹하드
 - 사용자 계정 부여 및 권한 설정
 - 한국어 지원(옵션 조정)
 - 별도 프로그램 없시 사용가능


 * 설치 환경 :  php 5.2.11 이상 설치된 환경

제품 다운로드 : http://www.ajaxplorer.info/
ajaxplorer-core-2.6 다운로드 : ajaxplorer-core-3.1.1.zip

  -> 접속 후 첫 로그인 후 admin 계정의 암호를 필히 변경하여 주셔야 합니다.

ajax1.JPG  
ajax2.JPG  

우측 상단의 계정이름 옆 단추를 선택하여 환경 및 암호를 변경 합니다.

ajax3.JPG  


사용하여 보니 접속 및 동작이 php 환경의 한계 때문에 어려움이 있으나, 무료와 사용 제약의 강점때문에 무료웹하드 프로그램으로 추천합니다.


제품 설치 후 수정 사항

1.php.ini의 설정


max_execution_time = 14400 ( 시간 초과 되지 않게 설정을 변경)
max_input_time = 14400 ( 시간 초과 되지 않게 설정을 변경)
memory_limit = 128M  ( 업로드 용량에 따라 크게 설정)
upload_tmp_dir = "D:"(하드 공간이 충분 한 곳으로 변경)
post_max_size =2000M( 최대 업로드 용량설정 값보다 작게 설정합니다)
upload_max_filesize = 2048M( 1개 파일당 최대 2G로 설정했습니다)

2.conf.php의 설정

 
Ajaxplorer를 다양하게 사용하기 위해서는 /server/conf/conf.php를 수정하여야 합니다.

 1. $default_language="en" (한국어로 변경을 위해서는 'kr'로 해주시고 웹하드 접속후 세팅에서도 한국어로 변경)
 2. $upload_max_number=0; (최대 업로드 가능한 파일의 수를 지정할 수 있습니다.)
 3. $upload_max_size_per_file=0; (한개의 파일당 최고의 크기를 지정할 수 있습니다.)
 4. $upload_max_size_total=0; (모든 파일의 최고 크기를 지정할 수 있습니다.)
 5. $webmaster_email="webmaster@yourdomain.com" (최고 관리자 아이디를 지정할 수 있습니다.)
 6. $user_https=false; (https환경을 사용하는 경우 지정, IE에서는 버그가 있을 수 있다고 합니다.)
 7. $max_caracteres=50; (디렉토리 또는 파일의 이름을 최대 50자까지 지정가능하도록 셋팅가능)


반응형

'Reference > 스크랩' 카테고리의 다른 글

[스크랩] L4/L7 스위치 개요 (로드밸런서)  (0) 2014.06.18
ajaxplorer 사용법  (0) 2013.07.07
HTTP 에러 정리  (0) 2013.03.11
루씬 개요  (0) 2013.01.07
[스크랩] 웹표준화 관련 Tip  (0) 2012.11.27
블로그 이미지

cocy

조금은 가볍게! 시작은 새롭게!

,
반응형

HTTP 에러 정리

cgi프로그래밍 후 테스트하거나 웹서핑중 종종 브라우저에 뜻하지 않는 메시지를 접하곤 합니다. 가장 많이 볼 수 있는 것들이 404 Not found나 403 Forbidden 등이 있습니다. 이들은 서버에서 보내는 사용자의 요구에 대한 응답입니다. 이러한 것들은 HTTP/1.0의 STATUS CODE라고 합니다. 즉, 이들 메시지만 잘 해독해도 많은 도움이 됩니다. 아래는 그 메시지의 설명입니다.

code : 200

reason field : OK       

의미 : 클라이언트의 request가 성공적으로 수행됐다. request처리결과로 클라이언트에게 전달되는 정보는 사용된 method에 따라서 달라진다.

reason field : GET

의미 : request가 지정한 자원이 response메세지로 전달 된다. 
                 
reason field : HEAD

의미 : response메세지에는 요청된 자원에 관한 정보를 나타내는 header만이 포함된다. 
                 
reason field : POST

의미 : 지정된 동작의 수행결과를 포함하거나 결과를 설명하는 엔터티가 전달된다. 
                

code : 201

reason field : Created

의미 : request가 처리되었고 그 결과로 새로운 자원이 생성되었다. 생성된 새로운 자원을 나타내는 URI 값이 response메시지로 전달된다. 서버가 이와 같은 status code(상태코드)를 클라이언트에게 전달하기 위해서는 새로운 자원을 먼저 생성시켜야 한다. response메시지를 전달 할때까지 새로운 자원이 생성되지 못하면 status code 202(Accepted)를 보내야 한다. POST method만이 서버에 새로운 자원을 생성시킬 수 있다. 
                 
code : 202

reason field : Accepted

의미 : request가 수락되었으나 response메시지를 전달할 때까지 그 프로세싱이 완료되지 못했으며 또한 언제까지 request의 수행결과를 사용자가 볼 수 있을지를 확실히 판단할 수 없다. 이와 같은 status code는 request가 수락된 것(accepted)만을 나타낼뿐 궁극적으로 그 request가 처리될 것이라는 보장 할 수 없을 때 사용된다. status code 202는 Web  브라우저와 같이 서버의 처리결과를 전달받을 때까지 계속 기다리게 되는 클라이언트를 위한 것은 아니다. WEb브라우저와는 다른 일종의 batch프로세서(하루에 한번정도 실행되는)의 request를 서버가 받아들일 수 있도록 하기위한 것이다. 
                 
code : 204

reason field : No Content

의미 : 서버가 request를 처리했지만 클라이언트에게 전달할 새로운 정보가 없다. 이 status code를 전달받는 Web브라우저는 현재 디스플레이 중인 내용을 변경시키지 않아야 한다. 이 code를 정의한 주된 목적은 현재 디스플레이 중인 문서의 내용을 변경시키지 않으면서 CGI스크립트 등에 입력을 전달할 수 있도록 하기 위해서이다. 
                 
code : 300

reason field : Multiple

의미 : HTTP/1.0을 사용하는 경우에는 이 code가 직접적으로 사용되지는 않는다. 다만, 3xx클래스에 속하는 status code의 디폴트값으로 사용된다. 그 의미는 301, 302, 304만이 HTTP/1.0에 정의되어 있으므로 그 외의 status code값을 전달받는 경우에는 300으로 간주한다는 의미가 되는 것이다. 
                 
code :301

reason field :  Moved

의미 : 요청된 자원의 URI값이 완전히 변경되었으므로 앞으로는 새로운 URI값을 사용하여야 한다. 새로운 URI값은 Location(위치)헤더를 통해서 클라이언트에게 전달된다. 또한 HEAD method를 제외한 모든 경우에 response메시지의 entity(실재) body를 통해서 새로운 URI의 하이퍼링크를 포함 하는 짧은 메시지를 전달해 주어야 한다. Web브라우저는 POST method를 사용한 request의 결과로 301 status code를 전달받는 경우에는 자동으로 새로운 URI에 접속해서는 안된다. 반드시, 사용자의확인을 거쳐야 한다. 
                 
code :302

reason field : Moved

의미 : 요청된 자원의 URI값이 임시로 변경되었다. 따라서 추후  Temporarily(임시폴더)에도 현재의 URI값을 계속 사용하여야 한다. 새로운 URI값은 Location헤더를 통해서 클라이언트에게 전달된다. 또, HEAD method를 제외한 모든 경우에 response메시지의  entity body를 통해서 새로운 URI의 하이퍼링크를 포함하는 짧은 메시지를 전달해 주어야 한다. Web브라우저는 POST method를 사용한 response의 결과로 302 status code를 전달받는 경우에는 자동으로  새로운 URI에 접속을 해서는 안된다. 반드시 사용자의 확인을 거쳐야 한다. 
                  
code : 304

reason field : Not

의미 : conditional GET method가 사용된 경우에 전달된다. Modified  request를 처리한 결과 If-Modified-Since헤더에 지정된 날짜/시간 이래로 지정된 문서가 변경된 사실이 없는 경우 서버는 이 status code로 응답해야 한다. 이때, entity body는 전송되지 않는다. reseponse메시지로 전달되는 헤더들은 주로 cache와 관련된 정보를 포함하게 된다. cache manager(대개의 경우는 Web브라우저 자체에 그 기능이 포함된다)는 304 response에 포함된 헤더의 값을 cache된 entity들에 반영할 수 있도록 하여야 한다. 
                 
code : 400

reason field : Bad Request

의미 : request메시지의 syntax(체계, 배열)가 잘못되어서 서버가 request를 처리할 수 없다. 재접속을 하는 경우에 클라이언트는 반드시 올바른 request메시지를 사용해야 한다. 
                  
code : 401

reason field : Unauthorized 
의미 : request가 user quthentication을 필요로 한다는 것을 클라이언트에게 알려주기 위해서 사용된다. WWW-Authenticate(인증하다, 증명하다)헤더를 통해서 요청된 자원에 적용되는 challenge를 전달한다. 401 response를 받은 클라이언트는 적절한 Authorization credentials(위임장)를 포함하는 Authorization헤더와 함께 다시 request메시지를 전송한다. request메시지에 그와 같은 Authorization credentials이 포함된 경우에 401 status code가 전달되면 user authentication이 실패한 것을 나타낸다. 
                 
code : 403

reason field : Forbidden

의미 : 서버가 request의 처리를 거절하는 것을 나타낸다. 이와 같은 응답을 받은 경우에는

동일한 request를 반복하지 말아야 한다. 왜냐하면 무조건 request가 거절되는 것이기 때문이다. 403 status code는 request를 거절하는 이유를 명시적으로 밝히고 싶지 않거나 적절한 status code가 없을때 사용된다. 
                  
code : 404

reason field : Not Found

의미 : Request-URI에 해당하는 자원을 찾을 수 없을 경우에 사용된다.

그런 상태가 일시적인 것인지 아니면 언제나 그렇게 되는지를 나타내는 어떤 정보도 전달되지 않는다. 이런 상태를 클라이언트에게 알리고 싶지 않은 경우에는 403 code를 대신 사용해도 된다. 
                  
code : 500

reason field : Interna

의미 : 서버프로그램에서 예기치 않은 오류가 발생하여서 request Srever Error  를 처리할 수 없다. 
                  
code : 501

reason field : Not

의미 : request를 처리하기 위해서는 필요한 기능을 서버가 갖추고 Implemented(충족시키다)있지 못하다. 
                  
code : 502

reason field : Bad

의미 : gateway나 proxy로 동작하는 서버가 사용하는 것으로 자신 Gateway의 위쪽에 있는 서버로 부터  잘못된 response메시지를 전송 받았다는 것을 나타낸다. 
                  
code : 503

reason field : Service

의미 : 과부하나 서버 maintenance(유지, 보존) 때문에 서버가 잠시동안 request Unavailable(요청불가능)를 처리해 줄 수 없는 상태에 있다.


반응형

'Reference > 스크랩' 카테고리의 다른 글

[스크랩] L4/L7 스위치 개요 (로드밸런서)  (0) 2014.06.18
ajaxplorer 사용법  (0) 2013.07.07
[스크랩]ajaxplorer  (1) 2013.07.04
루씬 개요  (0) 2013.01.07
[스크랩] 웹표준화 관련 Tip  (0) 2012.11.27
블로그 이미지

cocy

조금은 가볍게! 시작은 새롭게!

,
반응형

1.   개  요

  검색 엔진 개발에 앞서 검색 엔진의 작동원리 및 Open Source인 Lucene의 기능을 검토하여 적용 가능성 여부와 기능을 파악하고 앞으로의 개발 방향에 대하여 정리한다.

 

2.   검색 엔진의 작동 원리

1)   Crawler의 정보 수집

-       스파이더(spider) 혹은 크롤러(crawler)라고 불리는 로봇이 웹에 있는 웹 페이지를 방문해서 모든 내용을 읽어온다. 이 때 그 페이지만 방문하고 마는 것이 아니라 그 페이지에 링크되어 있는 또 다른 페이지를 차례대로 방문한다.

사용자 삽입 이미지




-       DB에 수집해온 그대로 저장하는 것이 아니라 검색에 적합하도록 일정한 가공을 거친다. DB에 저장되는 내용에는 문서의 제목, 본문, 링크 그리고 문서가 웹에서 차지하는 중요도 등이 있다.

 

2)   수집한 문서 가공과 색인 작업

-       검색엔진에서 가장 중요한 부분으로써 좋은 검색엔진을 만들기 위해 핵심이 되는 부분이다.

-       한글문서를 색인하고자 할 경우 얼마나 좋은 형태소 분석기를 가지고 있느냐가 색인 DB의 품질을 결정하게 된다.

-       먼저 수집된 문서를 적절하게 형태소 분석을 통하여 단어로 쪼갠다.

-       검색어의 빈도수와 위치(제목, 본문)등을 고려하여 중요도를 계산하여 이를 반영한다.

 

3)   정보 검색기

-       사용자가 입력한 검색어를 색인기에 넣어 색인어를 추출하고 그것을 사용하여 검색을 한다.

사용자 삽입 이미지




3. Lucene

사용자 삽입 이미지

1)   Lucene 소개

-       아파치 최상위 Project중에 하나로 http://lucene.apache.org에서 접할 수 있다.

-       Lucene은 강력한 기능뿐만 아니라 간단하기 때문에 IT업계에서 많이 사용된다.

-       루씬은 확장 가능한 고성능 정보검색(IR, Information Retrieval) 라이브러리이다. 루씬은 소프트웨어 프로그램에 색인과 검색 기능을 간단하게 추가할 수 있도록 지원한다.

-       루씬을 사용할 때 검색에 대한 전문적인 지식을 반드시 알 필요는 없다. 꼭 필요한 몇 가지 기본 클래스들을 사용하는 방법만 익히면 색인과 검색 기능을 직접 추가할 수 있다.

-       루씬은 독립 프로그램이 아닌 단순한 소프트웨어 라이브러리이다.

-       루씬은 프로그램에 텍스트 색인과 검색 기능을 추가할 수 있도록 지원한다.

 

2)   Doug Cutting(루씬의 창시자)이 제시한 lucene의 인덱싱과 검색을 적용 가능한 사례들

-       이메일 검색 : 저장된 메시지를 검색할 수 있고 새로 도착한 메시지를 색인에 추가할 수 있는 이메일 어플리 케이션

-       온라인 문서 검색 : 온라인 문서 또는 저장된 출판물을 검색할 수 있는 CD기반이나 웹 기반 또는 어플리케이션에 포함된 문서 판독기

-       웹 페이지 검색 : 사용자가 방문한 모든 웹 페이지를 색인화하기 위해 개인 검색 엔진을 만들 수 있는 웹 브라우저 또는 프록시 서버.

-       내용 검색 : 저장된 문서에서 특정 내용을 검색할 수 있는 애플리케이션.

-       버전 관리 및 컨텐트 관리 : 문서나 문서 버전을 색인화해서 쉽게 검색할 수 있는 문서 관리 시스템.

-       뉴스 및 유선(wire) 서비스 : 뉴스가 도착했을 때 기사를 색인할 수 있는 뉴스 서버나 릴레이 서버.

☞ Lucene을 사용하여 개발할 수 있다는 의미임. 각각에 대한 전용 라이브러리를 지원한다는 의미가 아님.


 

3)   Lucene을 사용했을 때의 모형도

 

사용자 삽입 이미지

-       빨간 점선을 기준으로 아래 부분이 루씬으로 할 수 있는 일들이고 위의 부분이 별도로 구연해야 할 부분이다.

 

4)   Lucene의 기능

-      색인을 저장할 수 있는 곳

n RAMDirectory : 컴퓨터의 메인 메모리를 색인 장소로 사용

n FSDirectory : 디스크의 파일 시스템에 색인을 저장 (가장 많이 사용)

n JDBCDirectory : DB를 색인 저장소로 사용하는 방법. 일반적으로 지원하지는 않지만 별도의 루씬 샌드박스라는 것을 통해 지원한다.

-      색인 기능 지원

-      검색 기능 지원

-       다양한 나라의 Full Text분석기(Analyzer) 지원(한글x)

-       Hadoop을 분산 파일 시스템으로 사용할 수 있음. (Nutch에서 사용중, Yahoo에서도 사용)

5)   Lucene은 Full Text 검색 엔진

-       실전에서는 단순한 문자열을 색인하는 것 보다는 다양한 문서를 색인화 하고 검색하는 작업이 더 빈번 할 것이다.

-       루씬을 이용해서 임의의 바이너리 파일을 직접 색인하고 검색할 수 없으며, 모두 문자열 형태로 변경된 이후에야 루씬으로 색인하고 검색할 수 있다.

-       XML, PDF, HTML, MS WORD와 같이 다양한 문서들을 색인화 하기 위해서는 각각의 문서를 Lucene의 Analyzer가 이해할 수 있도록 해석(parse)해서 텍스트로 추출해 내는 과정이 필요하다.

사용자 삽입 이미지

-       Parser를 지원하는 사이트

XML

Dom, Sax, JDom,

Piccolo (http://piccolo.sourceforge.net)

Apache Disester (http://jakarta.apache.org/commons/digester/)

PDF

PDFBox (http://www.pdfbox.org), IndexFiles (lucene built-in) ,

LucenePDFDocument (lucene built-in)

Xpdf (http://www.foolabs.com/xpdf)

JPedal (http://www.jpedal.org)

Etymon PJ( http://www.etymon.com)

Html

Jtidy (http://jtidy.sourceforge.net ), 
NekoHTML (
http://people.apache.org/~andyc/neko/doc/index.html)

HTMLParser( http://htmlparser.sourceforge.net)

MS Word

POI (http://jakarta.apache.org/poi )

Text Extractors( http://textmining.org )

Antiword ( http://www.winfield.demon.nl)

OpenOffice SDK ( http://www.openoffice.org )

 

6)   사용 가능한 언어

-       원래 자바로 만들어진 루씬은 펄(Perl)에서 시작해 파이썬(Python), C++와 닷넷(.NET)등의 언어로 포팅돼있고, 루비(Ruby)로 포팅하기 위한 작업도 진행중이다.

-       루씬은 서로 다른 언어간에도 색인 데이터를 100% 호환해서 사용할 수 있도록 설계되어있다.

 

4.   Nutch

1)   Nutch 소개

-       광고로 뒤덮인 인터넷 검색 사이트에서 상업적인 요소를 배제하고 검색 그 자체로의 검색을 구성하고자 진행된 오픈 소스 인터넷 웹 검색엔진 프로젝트

-       루씬을 이용하여 색인과 검색을 한다.

-       너치는 수 억개 이상의 웹페이지를 긁어 모아 색인하고 검색해볼 수 있게 해준다.

-       너치 시스템은 웹에 존재하는 문서(대략 10억에서 100억 개 정도)를 처리할 수 있도록 만들어졌고, 물론 문서가 아주 많기 때문에 1대보다는 여러 대의 서버에서 색인과 검색을 동시에 가동해야 한다.

 

2)   Nutch의 검색 구조

-       웹 서버가 사용자의 검색 요청을 받는다.

-       질의 핸들러가 검색어를 가공해서 다수의 색인 검색 서버로 전달한다.

-       질의 핸들러가 넘긴 검색어에 대해 여러 개의 색인 서버에서 결과가 나오는데 이 결과를 가장 점수가 높은 순서로 정렬한다.

-       만약 1~2초가 지난 후에 결과를 알려주지 않는 새인 서버가 있다면 결과에 포함하지 않고 무시한다. (사용자가 느끼기에2초안에 결과가 나오도록 보장)

3)   Nutch테스트

사용자 삽입 이미지
사용자 삽입 이미지


-       Crawling : http://www.hufs.ac.kr

-       검색어 : hufs



5.   Lucene으로 할 수 있는 일

-       내용을 검색하는 모든 분야에 Lucene을 적용할 수 있다.(우리는 Text와 Analyzer를 Lucene에 제시하면 Lucene이Index를 구성해 준다. Lucene의 api를 사용해서 검색할 수 있다)

-       대표적으로 Desktop 검색, E-mail 검색, 웹 페이지 검색

-       문제점 : 내용을 단어로 쪼개는 방법을 구현 해야함(형태소 분석기). 간단한 형태소 분석기는 “루씬 인 액션” 책에서 소스를 공개하고 있음. 하지만 고급 형태소 분석기는 국어에 대한 이해를 기반으로 구현하는 것이 매우 어렵다고 한다.

 

6.   결론

-       Lucene은 Full Text를 검색하는데 효율적이다.

-       Full-Text(Contents)와 text를 단어로 쪼개는 방법(Analyzer)을 제시하면 알아서 Index를 구성해 주고 그것으로 빠른 검색 결과를 얻을 수 있다.

-       그러므로 내용검색을 위해서는 Lucene을 사용하면 효율적이지만 단지 Exact Match 검색을 한다면 Lucene은 불필요하다.


출처 - http://cherrykyun.tistory.com/148

반응형

'Reference > 스크랩' 카테고리의 다른 글

[스크랩] L4/L7 스위치 개요 (로드밸런서)  (0) 2014.06.18
ajaxplorer 사용법  (0) 2013.07.07
[스크랩]ajaxplorer  (1) 2013.07.04
HTTP 에러 정리  (0) 2013.03.11
[스크랩] 웹표준화 관련 Tip  (0) 2012.11.27
블로그 이미지

cocy

조금은 가볍게! 시작은 새롭게!

,
반응형

1.     웹표준화 관련 Tip

1-1.        단위를 넣어라


상당히 자주 발견되는 잘못된 코딩의 예입니다.

자바스크립트로 width 또는 height 값을 변경할때

IE에서는 단위를 적지 않아도 자동으로 px로 인식하지만

다른 브라우저에서는 단위를 적지 않을 경우 원하는 화면을 얻을수 없습니다.

width나 height, padding, margin 값과 같이 수치를 입력하는 css 속성값에는 

반드시 단위(px, pt, %, em 등)를 넣어주세요.

1-2.        document.all은 버려라


IE식 DOM스크립팅의 대표주자 바로 

document.all과

document.regForm.userId 와 같은 DOM 접근 방법입니다.

name속성값에 기반한 document.regForm.userId과 같은 DOM접근이나

document.all[objectID] 과 같은 DOM 접근방식은 IE에서만 동작을 보장합니다.

이제 document.getElementById(objectId)를 사용해주세요.


1-3.        올바른 주석 사용하기


HTML에서의 주석 넣기

<!------ 주석 ------> (X)

<!--주석--> (X)

<!-- 주석 --> (O)

HTML에서 주석을 넣을때 정확한 구분을 위해 과도하게 하이픈(-)을 넣는 것을 종종 발견합니다.

하이픈은 딱 2개만 넣으세요.

코멘트을 시작하는 "<!"와 내용을 시작하는 "--" 사이에는 빈 공간이 허용되지 않습니다. 

그리고 주석의 양옆에는 안전하게 빈 공간을 넣어주세요.

CSS 주석 넣기

<!-- css 주석 --> (X)

/*css주석*/ (X)

/* css 주석 */ (O)

CSS는 HTML과 주석을 넣는 방법이 다릅니다.


CSS의 주석도 HTML처럼 <!-- --> 이렇게 넣으시면 안됩니다.


그리고 CSS도 안전한 주석처리를 위해


주석 내용 양 옆에 빈공간을 넣어주세요.


1-4.        inline 엘리먼트와 block 엘리먼트를 구분하자. 

<tr>은 block엘리먼트가 아닙니다.


HTML엘리먼트는 크게 inline엘리먼트와 block 엘리먼트로 나뉩니다.

<span>, <strong>, <em> 과 같이 줄바뀜이 일어나지 않는 엘리먼트를 inline엘리먼트라 하고

<div>, <h1>, <p>와 같이 줄바뀜이 일어나는 엘리먼트를 block 엘리먼트라고 합니다.

block 엘리먼트와 inline 엘리먼트는 css 로 변경이 가능합니다.

보통 inline으로 취급되는 <span> 태그도 css에서 display:block 으로 설정하면

block 엘리먼트와 같이 표현됩니다.

그렇기 때문에 개발자는 

엘리먼트를 숨겼다가 다시 보이기를 할때

inline 엘리먼트인지, block 엘리먼트인지 알아야 합니다.

display:none 되어 있는 엘리먼트를 무조건 block 으로 보이게 한다면

퍼블리셔에 의해 inline으로 설정된 엘리먼트가 block 엘리먼트로 취급되는 경우

레이아웃이 무너지는 현상을 발견할 수도 있습니다.

block엘리먼트인지 inline 엘리먼트인지 신경쓰지 않고

자바스크립트 스크립팅을 하는 가장 좋은 방법은

display 값에 아래와 같이 빈 값을 넣는 것입니다.

document.getElementById('elementId').style.display = '';

이 경우 display 속성값이 기본값으로 세팅이 되기 때문에


css에서 선언된 원래의 display 값으로 되돌아가게 됩니다.


그리고 하나 더.

DB에서 데이터를 불러와 뿌려주는 데이터테이블 형식에서

display:none 되어 숨겨있는 <tr>을 사용자 액션에 따라 보이게 할때

documet.getElementById('tr_id').style.display = 'block';


이렇게 사용하는 경우가 많습니다.


IE에서는 tr엘리먼트의 display 속성값을 block으로 하여도 원하는 화면을 얻을 수 있겠지만

그 외의 브라우저에서는 테이블이 깨져나오는것을 발견하게 될것입니다.

<tr>엘리먼트는 정확히 얘기하자면 고유의 display 속성이 table-row 입니다.


그렇기 때문에 display 값을 "table-row"로 해야하나 IE에서 이 또한 문제가 발생하므로


display 값에 다음과 같이 빈값을 넣어 스크립트를 작성해야 합니다.

documet.getElementById('tr_id').style.display = '';

이렇게 함으로써 display 값이 선언된 CSS의 default 값으로 세팅이 됩니다.

 

1-5.        파일 저장시 문서의 BOM을 제거하여 저장하기

 



에디트 플러스 3버전대에서는 도구 → 기본설정에 BOM 설정부분이 있고


이클립스나 비주얼스튜디오를 비롯한 다른 에디터들에서도


도구 → 속성, 파일 → 속성, 파일 → 옵션, 옵션 → 설정, 설정 → 옵션


메뉴에 BOM 제거 설정 부분이 있습니다.


BOM이 포함되어 파일이 저장될 경우


문서의 가장 앞에 다른 문자가 있는 것으로 인식이 되어


스크립트 에러가 발생하거나, HTML문서 최상단에 선언한 doctype이 제대로 인식되지 않아


quirks모드 (비표준모드)로 렌더링을 할 수도 있습니다.



파일 저장시에는 BOM을 제거 하여 저장하세요.


1-6.        IE전용 이벤트, 속성, 메소드 사용을 피해라

 


innerText  → innerHTML


getElementsByClassName() → getElementById()


selectNode(), selectSingleNode() → getElementsByTagName()



DATE 객체에서 getYear() → getFullYear() 



이벤트 onmouseleave → onmouseout



javascript에서 event 객체를 받을 경우 마우스포인터의 x, y값을 가져오기 위해서 e.x, e.y 대신 e.clientX, e.clientY 프로퍼티를 사용



javascript로 검색어와 같은 기능에서 한글을 비롯한 특수문자를 get형식으로 보낼때는 



escape()함수가 아닌 encodeURIComponent() 함수를 사용


1-7.        removeNode 사용하지말것!

 

ð  removeNode (X) -> removechild (O)

적용예)

Var p2 = document.getElement/byId(id + ‘_b’);

P2.parentNode.removeChild(p2);

 

1-8.        더블클릭시 one클릭이벤트가 동시 발생할경우(safari, ie9.0 에서 발생).

var timerID = null;

function LayerSingleClick(obj)

{

If(Browser.safari || Browser.mac || Browser.ie9)

{

//one 클릭시 실행할 코드

}

else

{

if (timerID === null)

{

timerID = setTimeout (eventProcessor, 200,obj);

EnableCancelButton (true);

}

else

{

CancelTimer();

}

}

}

 

 

function eventProcessor(obj)

{

if(timerID)

{

//one 클릭시 실행할 코드

CancelTimer();

}

}

                    

function CancelTimer ()

{

clearTimeout (timerID);

timerID = null;

EnableCancelButton (false);

}

 

1-9.        insertBefore 가 되지 않을 때…

 

X)

Function Run()

{

 

Var frm = CreateForm();

Frm = AddHidden(frm,”m”,”model”);

Document.insertBefore(frm);

Frm.submit();

}

          

           위 예제가 동작되지 않는 이유는 바로 insertBefore 에 있다.

           Var insertedElement = parentElement.insertBefore(newElement, referenceElement);

           DOM 의 insertBefore  인자는 두개.

           두번째 인자는 추가될 위치를 명시할 때 사용되는데

           이 두번째 인자가 빠졌기 때문에 동작되지 않는다.

           또 하나 웹표준화와 더불어 Form 객체는 body아래에 존재해야 하기 때문에

           Form 객체를 document 하위가 아닌 document.body 아래에 넣어야 한다.

           결국 다음과 같이 수정하면 된다.

O)

Document.body.insertBefore(frm,null);

 

 

2.     최적화

a.     javascript(JQuery포함) 코드는 </body>태그 앞에 둔다.

최근의 최적화 기술은 자바스크립트가 페이지의 끝부분에서 브라우저에 의해 로드되는 경우 페이지의 로드가 더 빨라진다고 말하고 있다.

즉, 웹 페이지의 밑부분에 자바스크립트 코드를 둔다면 브라우져가 자바스크립트를 로드하기에 앞서 스크립트 앞에 있는 모든 것들을 로드한다는 것이다.

일반적으로 대부분의 브라우저는 자바스크립트 엔진이 웹 페이지에 있는 자바스크립트를 컴파일할 때까지 다른 모든 로딩 처리를 중단하기 때문에 이는 더욱 효과적이다.

웹 페이지 문서의 상단에 자바스크립트를 둔다면 일종의 병목현상이 생길 수 있다.

 

b.     기능상 중복된 함수 및 변수 는 하나로 통일한다.

예) 웹표준화 작업시 불가피하게 브라우져별로 분기처리를 해야할때가 있다.

그때마다 개발자마다 분기처리하는 방법들이 다르게 되면

차후에 유지보수 및 가독성,생산성이 떨어진다.

 

//브라우저 체크

/* 공통스크립트 아래 전역변수를 포함한다. */

var Browser = {

    a: navigator.userAgent.toLowerCase()

}

var Browser = {

ie: /*cc_otrue || @*/false,

ie6: Browser.a.indexOf(‘msie 6’) != -1,

ie7: Browser.a.indexOf(‘msie 7’) != -1,

ie8: Browser.a.indexOf(‘msie 8’) != -1,

ie9: Browser.a.indexOf(‘msie 9’) != -1,

opera: !!window.opera,

safari: Browser.a.indexOf(‘safari’) != -1,

safari3: Browser.a.indexOf(‘applewebkit/5’) != -1,

mac: Browser.a.indexOf(‘mac’) != -1,

chrome: Browser.a.indexOf(‘chrome’) != -1,

firefox: Browser.a.indexOf(‘firefox’) != -1

}

 

/* 실제 브라우저 체크시 사용예 */

 

If(Browser.safari || Browser.mac || Browser.ie9)

{

  Dwidth += 7;

  Dheight += 7;

}

 

/* 기존 브라우져 체크방법 */

           // 브라우저를식별하는부분

방법1.

var IE4  = (document.all && !document.getElementById) ? true : false;

var NS4 = (document.layers) ? true : false;

var IE5  = (document.all && document.getElementById) ? true : false;

var N6  = (document.getElementById && !document.all) ? true : false;

 

                     if (document.all)

                     {                              

                                e.cellSpacing = "0";

                     }

                     else

                     {                              

                                e.setAttribute("cellspacing", "0");

                  }

방법2.

               if (/MSIE/.test(navigator.userAgent)) {

               if(navigator.appVersion.indexOf('MSIE 8.0')> -1) {

               window.opener='Self';

               window.open('','_parent','');

               window.close();

               } else if (navigator.appVersion.indexOf('MSIE 7.0')> -1 ) {

               window.open('','_self').close();

               } else {

               window.opener = self;

               self.close();

            }}

 

                    

3.     운영관련

A.     마스터페이지 사용하기.

ð  공통포함파일(스타일시트나 스크립트 등등)을 마스터페이지에 포함시킴으로서 유지보수 및

가독성이 높아 생산성이 높아진다.

4.     웹보안관련 Tip

A.     get -> post 방식으로 변경.

ð  get방식으로 URL에 정보를 담아서 보낼경우 정보가 노출이 되므로

보안에 취약하며, 보내는 정보의 크기가 1024바이트로 제한된다.

물론 POST 방식의 장점이 많다고 해서

무조건 POST 방식을 써야 하는 것은 아니다. GET 방식이 POST 방식에 비해 간편하게 쓸 수 있기 때문에 보편적으로 GET 방식과 POST 방식을 적절히 혼용해서 사용한다.

B.      Get방식을 Post방식으로 변경하기.

ð  Get 방식

<a href=”boardlist.aspx?boardidx=23&page=3&searchfiled=title&….”> 제목…</a>

 

ð  post 방식

<a href=”javascript:void(0)” onclick=” javascript:listview(23,3,’title’);”>제목…</a>

<script>

Function listview(idx,pnum,title)

Var f = document.getElementbyId(“formId”);        //

f.target = “_self”;

f.action = “boardlist.aspx”;

f.submit();

</script>

 

<form id=””formId” method=”post”>

</form>

 

5.     Jquery 코딩 tip

A.     복잡한 셀렉터를 사용할 때는  가급적 JQuery의 기본 메서드를 사용한다.

ð  길고 복잡한 셀렉터는 결과를 반환하는 데 그만큼 오래 걸릴 것이다. 아래 두 방법을 비교해 보면..

JQuery('div a:not([href^=http://]), p a:not([href^=http://])');

JQuery('div, p').find('a').not('[href^=http://]');

두번째 방법은 첫 번째 방법보다 짧고 읽기 쉽다. 더불어, Firefox와 Safari에서 테스트 해 보면 두 번째 방법이 첫 번째 방법보다 빠르다.

          

 

B.      컨텍스트를 지정한다.

ð  결론부터 말하면 컨텍스트를 지정하면 가독성과 처리속도에 도움이 된다.

다음은 한 가지 예인데, 폼이 전송되기에 앞서 폼 안에 있는 모든 input 필드를 선택하는 것이다.

JQuery('form'),bind('submit', function() {

var allinputs = JQuery('input', this);

// 지금 'allinputs'로 작업을 할 것이다.

});

this가 두번째 매개변수로 전달되고 있다는 점에 주목하자. 처리기 내에서 this는 폼요소를 의미한다.

그렇기에, 이를 컨텍스트로서 지정한다면 JQuery 는 그 폼안에 존재하는 input 요소들만 반환할 것이다.

만약 두 번째 매개변수를 지정하지 않는다면 문서에 존재하는 모든 input 요소가 반환될 것이다.

예) JQuery('p', '#content'); = JQuery('#content p');

 

**컨텍스트: JQuery가 셀렉터 식에 의해 매치되는 요소를 찾을 장소를 말한다.

 

C.      자식 요소를 찾기 위해서는 children() 메서드를 사용한다.

var anchors = JQuery('a');

// 앵커요소의 모든 지계 자식들을 가져올 수 있는 3가지 방법

// #1

anchors.children();

// #2

JQuery('> *', anchors);

// #3

anchors.find('> *');

사실 이 외에도 상당히 많은 방법이 존재한다! 하지만 위의 상황에서는 첫 번째 방법이 가장 빠르다.

[출처] 2011년 4월 8일 오후 3시 9분|작성자 erick74

반응형

'Reference > 스크랩' 카테고리의 다른 글

[스크랩] L4/L7 스위치 개요 (로드밸런서)  (0) 2014.06.18
ajaxplorer 사용법  (0) 2013.07.07
[스크랩]ajaxplorer  (1) 2013.07.04
HTTP 에러 정리  (0) 2013.03.11
루씬 개요  (0) 2013.01.07
블로그 이미지

cocy

조금은 가볍게! 시작은 새롭게!

,