finerss's world!

%%%%%

공백일경우 javascript는 trim 함수만들어서사용

<script type="text/javascript">

var s =  '     AAA BBB       CCC     ';
s = trim(s);

document.write('[' + s + ']' + '<br />');

document.write('<pre>[' + s + ']</pre><br />');

 


function trim(s) {
  s += ''; // 숫자라도 문자열로 변환
  return s.replace(/^\s*|\s*$/g, '');
}

</script>


%%%%%%
글자수 체크

function ChkByte(maxlength) {
  var objstr = document.getElementById("brightKey").value; // ÀÔ·ÂµÈ ¹®ÀÚ¿­À» ´ãÀ» º¯¼ö
  var objstrlen = objstr.length; // Àüü±æÀÌ

  // º¯¼öÃʱâÈ­
  var maxlen = maxlength; // Á¦ÇÑÇÒ ±ÛÀÚ¼ö ÃÖ´ëÅ©±â
  var i = 0; // for¹®¿¡ »ç¿ë
  var bytesize = 0; // ¹ÙÀÌƮũ±â
  var strlen = 0; // ÀÔ·ÂµÈ ¹®ÀÚ¿­ÀÇ Å©±â
  var onechar = ""; // char´ÜÀ§·Î ÃßÃâ½Ã ÇÊ¿äÇÑ º¯¼ö
  var objstr2 = ""; // Çã¿ëµÈ ±ÛÀÚ¼ö±îÁö¸¸ Æ÷ÇÔÇÑ ÃÖÁ¾¹®ÀÚ¿­
 
  // ÀÔ·ÂµÈ ¹®ÀÚ¿­ÀÇ ÃѹÙÀÌÆ®¼ö ±¸Çϱâ
  for(i=0; i< objstrlen; i++) {
   // ÇѱÛÀÚÃßÃâ
   onechar = objstr.charAt(i);
  
   if (escape(onechar).length > 4) {
    bytesize += 2;     // ÇѱÛÀ̸é 2¸¦ ´õÇÑ´Ù.
   } else { 
    bytesize++;      // ±×¹ÜÀÇ °æ¿ì´Â 1À» ´õÇÑ´Ù.
   }
  
   if(bytesize <= maxlen)  {   // Àüü Å©±â°¡ maxlen¸¦ ³ÑÁö¾ÊÀ¸¸é
    strlen = i + 1;     // 1¾¿ Áõ°¡
   }
  }
 
  // ÃѹÙÀÌÆ®¼ö°¡ Çã¿ëµÈ ¹®ÀÚ¿­ÀÇ ÃÖ´ë°ªÀ» ÃÊ°úÇϸé
  if(bytesize > maxlen) {
   alert( "Key°ªÀÌ À߸øµÇ¾ú½À´Ï´Ù. ´Ù½ÃÀÔ·Â ÇØÁÖ¼¼¿ä.");
   objstr2 = objstr.substr(0, "#");
   document.getElementById("brightKey").value = objstr2;
   document.getElementById("brightKey").focus();
   return true;
  }
 
  if(bytesize == 0){
   if(!confirm("Å°°ªÀÌ ÀԷµÇÁö ¾Ê¾Ò½À´Ï´Ù. °è¼Ó ÁøÇàÇϽðڽÀ´Ï±î?")){
    return true;
   }
  }

 }

'공부 > JavaScript' 카테고리의 다른 글

자바스크립트 총정리  (0) 2011.06.30
쿠키(cookie)  (0) 2011.06.29
체크박스 전체해지  (0) 2011.06.13

L4 로드밸런싱

공부/기타2011. 11. 8. 16:21

L4 로드밸런싱 설정 및 운용

2010/03/11 08:57 / 네트워크
사용자 삽입 이미지

한마디로 말하면,

L4의 핵심은 'IP, 포트, 세션' 을 기반으로한
로드 밸런싱(Load Balancing)이다!

라고 말하고 싶네요. L4에서 가장 중요한건 역시 4계층답게
포트(port)라는 생각이 드네요.

2계층의 MAC
3계층의 IP
그럼 4계층은 바로 포트 입니다.

그리고 이 포트와 맞물려 로드 밸런싱이라는 개념이 등장 합니다.

L4 스위치는 마치 포트와 로드밸런싱의 오묘한 조합이랄까요.

L4 스위치 = 포트 + 로드밸런싱(물론 IP,세션도 중요합니다)

L4스위치가 로드밸런싱을 수행하는 장비이기 때문에 L4스위치를
다른말로 로드 밸랜서(Load Balancer) 라고도 합니다.

로드밸런싱은, 동일한 역할을 수행하는 서버 그룹을 VIP를 통해 관리하며,
서버로 향하는 트래픽을 일단 VIP를 가진 L4스위치로 수신한 후
분배정책에 따라 적절한 서버에 분배해 주는 것을 말합니다.

VIP는 Virtual IP의 약자로, 서버그룹의 대표 IP라 할 수 있습니다.
이 VIP를 로드밸런싱을 수행하는 L4 스위치가 가지고 있습니다.
서버와 통신하고자 하는 클라이언트는 VIP를 향해 트래픽을 전송하고
L4스위치가 이 트래픽을 받아 적절한 서버에 로드밸런싱 해주는 것이
L4스위치의 역할입니다.

한마디로, L4 스위치는 부하분산 장비입니다.
요즘 웬만한 사이트는 서버 한 대로 사용자들의 트래픽을 감당하기
어렵기 떄문에 동일한 역할을 수행하는 서버를 여러 대 두어서 사용자들의
트래픽이 많아져도 유연하고 안정적으로 사이트를 운영하기 위해
L4스위치를 통한 로드밸런싱
을 하는걸로 알고 있습니다.

L4스위치, 즉 로드밸란서가 없어도 네트워크를 하는데 지장은 없습니다.
하지만 IT가 발전하고 트래픽이 과도해지면서 로드밸런서 없이는 안정적인
네트워크를 구성하는것이 불가피해지고 있다는 생각이 드네요.


이 그림에서 보는바와 같이,
클라이언트와 서버 사이에 로드밸란서가 위치하여 서버 2대에 대해
로드밸런싱을 수행합니다.
즉, 로드밸런서가 트래픽을 왼쪽 서버로 보낼 수도 있고, 오른쪽 서버에 보낼
수도 있습니다.


###################################################

그러면 L4를 왜 쓰느냐??

2가지 이유가 있습니다.

첫 번째 로드를 분산하기 위해서 입니다.(로드 발란싱)

예를 들어 한 서버에 웹 서비스(80)를 하는 서버가 있습니다.

그런데 서버에 부하 때문에 서버를 증설 해야 합니다.

하지만 서버를 분리 시키면 IP가 하나 더 필요하게 되고 IP가 늘어나면 기존 서비스와 IP가 달라지는 문제가 생깁니다.

이 때 사용하는 것이 L4장비의 VIP입니다.

예를 들어 기존에 사용하는 서버의 IP가 128.x.x.1이라고 합시다.

이 IP를 L4장비에 VIP로 할당합니다. 128.x.x.1 for 80 128.x.x.1 regarding 80

(VIP는 가상의 아이피를 말합니다.)

기존 서버에는 128.x.x.2 와 새로운 서버에는 128.x.x.3을 할당합니다.

(물론 기존 서버와 새로운 서버는 데이타가 동기되어 있어야 합니다.)

그리고 L4장비에 로드발란싱이 가능하게 세팅합니다.


그러면 이제 128.x.x.1로 요청하는 응답에 대해서 L4가 처리 하게됩니다. (대표IP로 서버여러대를 가지치기 할수 있다.)

L4는 로드발란싱 규칙에 따라서 기존 서버에서 응답하게 할 수도 있고 신규 서버에서 응답하게 할 수도 있습니다.


간단하게 L4에서 홀수 번째 요청은 기존 서버에서 짝수 번째 요청은 신규 서버에서 응답하게 설정 할 경우 요청에 대한 응답을 정확하게 반으로 나눌수 있습니다.


이렇게 한 서버의 요청건수를 줄여주어 실제로 한대의 서버가 처리해야 할 요청을 두대(여러 대)의 서버가 처리하게 되는 것을 로드 발란싱이라고 합니다.

알테온으로 설명 드리면, 웹서버 두대를 로드밸런싱 하려면 먼저

웹서버를 각각 real server 로 각각 ip를 등록합니다.
그리고 웹서버 즉 real server ip 두개 를 group1 에 소속시킵니다.
그리고 virtual ip (vip=대표ip)를 하나 등록해서 그 ip로 오는
패킷중에 http(80) 패킷에 대해서는 group1으로 보내면
설정된
matric(hash, 라운드로빈, least connection, weighted )값에 의해
로드밸런싱 되는것입니다. 대부분 hash 방식을 사용하죠...


이렇게 하면 128.x.x.1 for 80 은 오직 80 포트만을 받고, 다른 포트는 filtering 된다.. 쓸데없는 포트로 들어오는 공격을 막을수 있다.


그리고 L4의 두번째 기능으로 무결성을 위한 fail over기능입니다.


흔히 가장 안정적으로 서비스되는 서버는 일년에 다운타임(동작 불능시간)이 50분 미만인 서버라고 합니다.

(1년동안 50분 정도 다운되면 최고로 안정적인 서버가 되는 것입니다.)


서버역시 기계인 것이라 영원히 죽지 않는 서버는 존재하지 않습니다.

그러나 사람들은 좀더 서버가 안정적으로 동작하길 윈하게 되죠

아주 중요한 서버(예를 들면 정치 관련 홈페이지나 은행과 같은 금융 그리고 그 외 쇼핑몰등)의 경우 일년에 50분의 다운이라도 서비스에 큰 타격을 입을 수 있습니다.


예를 들어 128.x.x.1이라는 서버가 있습니다.

그러나 이 서버는 중요한 서버라 절대 서버에 장애가 있으면 안됩니다.

이럴경우 사용하는 장비가 L4입니다.


L4에 VIP를 이용해서 128.x.x.1이라는 IP를 할당합니다.

기존 서버의 IP를 128.x.x.2로 변경합니다.

새로운 서버에 128.x.x.3으로 할당합니다.(물론 기존 서버와 자료가 같도록 동기화 되어 있어야 합니다.)


L4에 fail over기능을 이용 할 경우

128.x.x.1로 오는 모든 요청에 대해서 L4는 128.x.x.2가 응답하게 합니다.

그리고 128.x.x.2에 장애가 있을 경우(서버가 다운될 경우)에는 128.x.x.3서버가 자동으로 응답하게 처리하게 됩니다.


이렇게 미리 동일한 서버를 준비해 놓고 L4를 이용해서 fail over로 연결하면 첫번째 서버(마스터)에 장애가 있을 경우라도 미리 준비해 놓은 서버(슬래이브)가 동작하게 되므로

실제로 서비스에는 문제가 없게되는 것입니다.


Alteon L4 스위치 기본 설정방법


- Real 서버가 2대이고 1개의 그룹으로 설정, vitural 서버는 1개 사용
- metric(분산알고리즘) 미설정 시 default는 leastconnection
- health 체크 미설정 시 default는 tcp, inter=2(매 2초마다 체크), retry=4(4번 실패 체크 시 down으로 정의)
- DAM(Direct Access Mode)가 default로 disable (Real IP를 통한 직접 서비스 안됨)
※ 즉, 여기서는 Real IP를 이용한 http(80번 포트) 접속 안됨
(하지만 Load Balance와 무관한 서비스는 각각 가능: ssh, 터미널 접속,... 등)

Main#
Main# /cfg/l3 ; 스위치 IP 설정...
(또는 Main# /cfg/ip)
Layer 3# if 1 ; 스위치 자체 IP 설정...
IP Interface 1# addr 1.2.3.4 ; IP address 할당
IP Interface 1# mask 255.255.255.0 ; subnet mask 할당 (필요시)
IP Interface 1# ena ; IP address 활성화

IP Interface 1# /cfg/l3/gw ; default gateway 설정...
Enter default gateway number: (1-255) 1 [Enter] ; gateway 번호 입력 (필요시)
Default gateway 1# addr 1.2.3.1 ; default gateway 할당
Default gateway 1# ena ; gateway 활성화

Default gateway 1# /cfg/slb/real 1 ; 첫번째 real 서버 설정...
Real server 1# rip 1.2.3.5 ; real 서버 IP address 할당
Real server 1# ena ; 첫번째 real 서버 활성화

Real server 1# /cfg/slb/real 2 ; 두번째 real 서버 설정...
Real server 2# rip 1.2.3.6 ; real 서버 IP address 할당
Real server 2# ena ; 두번째 real 서버 활성화

Real server 2# /cfg/slb/group 1 ; real 서버 그룹 설정...
Real server group1# add 1 ; 등록된 real 서버 1번을 그룹에 추가
Real server group1# add 2 ; 등록된 real 서버 2번을 그룹에 추가

Real server group1# /cfg/slb/virt 1 ; virtual 서버 설정...
Virtual server 1# vip 1.2.3.2 ; virtual 서버 IP address 할당
Virtual server 1# ena ; virtual 서버 활성화
Virtual server 1# service http ; http 서비스 설정...
Virtual server 1 http Service# group 1 ; http 서비스를 real 서버 그룹에 할당
(필요시 Virtual server 1 http Service# rport 8080 ; http 서비스를 real 서버의 8080 포트에 매핑)

Virtual server 1# /cfg/slb/port 1 ; L4의 물리적인 포트 1번 설정...
SLB port 1# server ena ; 포트 1번을 서버 포트로 할당
SLB port 1# /cfg/slb/port 2 ; L4의 물리적인 포트 2번 설정...
SLB port 2# server ena ; 포트 2번을 서버 포트로 할당

SLB port 8# /cfg/slb/port 8 ; L4의 물리적인 포트 8번 설정...
SLB port 8# client ena ; 포트 8번을 클라이언트 포트로 할당

SLB port 8# /cfg/slb ; SLB 설정...
Layer 4# on ; Server Load Balancing 모드 On
Layer 4# apply ; 변경된 설정값 적용
Layer 4# cur ; 현재 설정값 확인
Layer 4# save ; FLASH 메모리에 현재 설정내용 저장
Layer 4# /info/slb/dump ; SLB 정보 확인


------------------------------------------------------
| ㅁ1 ㅁ2 ㅁ3 ㅁ4 ㅁ3 ㅁ4 ㅁ5 ㅁ6 ㅁ5 ㅁ6 ㅁ7 ㅁ8 | --> Alteon L4 스위치
--+---+--------------------------------------+--------
| | |
| | |--> 클라이언트 포트 (외부 연결)
| |
| |--> 서버 포트 (서버 연결)
|
|
|--> 서버 포트 (서버 연결)

사용자 삽입 이미지

※ 설정 시 port 9번은 미사용


//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////



L4/L7 스위치 개요 (로드밸런서)

from 이유있는 코드 2010/02/01 14:05

스위치의 분류 :

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를 지원한다.



'공부 > 기타' 카테고리의 다른 글

토드 단축키  (0) 2012.01.04
Crontab 설정  (0) 2011.12.15
조인쿼리 정리  (0) 2011.06.13
OpenAPI OAuth  (0) 2011.06.13
ORA-00918: column ambiguously defined 원인 및 해결방법  (0) 2011.06.13

 

[ 웹 서버와 WAS(Web Application Server)의 정의 ]

웹서버와 WAS는 비슷한 개념이기 때문에 같이 또는 다르게 사용되는 단어 가운데 하나이다. 인터넷 확산 초기에는 웹서버라는 개념으로 통칭해서 사용했지만, 시간이 지남에 따라 WAS를 더 많이 사용하고 있다. 인터넷 사용자가 증가함에 따라, 각 웹 사이트는 보다 많은 사용자에게 원활한 서비스를 제공하기 위해 기능적인 layer를 나누게 되었고 여기서 웹서버와 WAS의 구분점이 생기게 된 것이다.

기능적으로만 본다면, 거의 대부분의 웹 서버가 웹 애플리케이션을 동작시킬 수 있겠지만 모두 웹 서버 혹은 WAS라고 부르는 것보다는 어떤 기능을 수행하는지에 따라, 즉 기능상의 분류를 통해 구분지어 사용해야 할 것이다.

구분

웹서버

WAS

설명

1. 웹브라우저(Web Client)에게 컨텐츠를 제공하는 서버이다. 즉 정적인 HTML이나 jpeg, gif같은 이미지를 HTTP 프로토콜을 통해 웹 브라우저에 제공한다.


2.
최근에는 웹서버에서도 내부 애플리케이션을 동작시킬 수 있는 컨테이너를 내장하고 있다.

서버단에서 애플리케이션을 동작할 수 있도록 지원한다. 일반적으로 컨테이너라는 용어로 쓰인다. 초창기에는 CGI, 그 이 후에는 Servlet, ASP, JSP, ASP, PHP등의 프로그램으로 사용되고 있다.

[ 웹 서버와 WAS(Web Application Server)의 구성에 따른 분류 ]

1. 기본적인 웹 사이트 구성

<그림 1>은 웹 사이트의 가장 기본적인 구성 환경이다. 모든 콘텐츠를 한 곳에 집중시켜 웹 서버와WAS의 역할을 동시에 수행한다. 사용자가 많지 않거나 트래픽이 적을 때 효율적이며 간단한 구조로 개발 및 테스트 시스템 구성시 활용의 가치가 높다.

장점 : 사용자 증가에 따라 스위치 장비를 통해 로드 밸런싱을 수행하고, 여러대의 WAS를 통해 지원이 가능하다. 필요시에 추가로 WAS를 증설하는 구조라고 볼 수 있다.

단점 : WAS가 정적인 데이터(HTML/Image)의 처리와 동적인 데이터(웹 애플리케이션)의 처리를 동시에 수행하기 때문에 최적화 측면에선 바람직하지 않다. 또한 정적데이터의 입출력 처리를 위해 웹 애플리케이션의 수행을 방해할 수 있고, 그 반대의 경우도 있다.

2. 웹 서버와 WAS로 구성된 환경


<그림 2>는 웹 서버와 WAS의 기능적 분류를 통해 효과적인 분산을 유도한 형태이다. 정적인 데이터는 구조적으로 앞에 존재하는 웹 서버에서 처리하고, 동적인 데이터는 뒷단의 WAS가 처리한다.

사용자의 요청에 대해서 정적 데이터인 HTML과 자바스크립트 파일, CSS, Image 등을 앞단의 웹 서버에 위치시켜 처리함으로써 WAS로 서비스 요청이 넘어가지 않게 한다.

또한 웹 애플리케이션 서비스를 위치적으로 뒤편에 존재하는 WAS에 넘겨줌으로써 WAS는 웹 애플이케이션의 수행이 집중할 수 있다.

웹 서버 단에서 처리할 것과 WAS에게 넘겨질 것을 처리하는 방식은 웹 서버 단의 Configuration을 통해 처리할 수 있다. 특정 확장자나 디렉토리 업무를 WAS로 넘길지 여부는 웹 서버 단에서 처리한다.


3. 특정기능에 대한 서버를 별도로 두고 있는 환경


점점 화려해지는 UI를 자랑하는 페이지들이 많아짐에 따라 이미지의 비중이 증가하고, 이런 이미지들이 전체 네트워크 비중의 상당부분을 차지한다. 따라서 이미지 서버를 따로 구성해 네트워크 비중도 줄이면서 웹 서버와 WAS를 좀 더 효과적으로 사용할 수 있는 구조라 할 수 있다.

또는 특정 콘텐츠에만 집중적인 요청을 받는 경우도 있다. 예를 들어, 대학 입시 때 경쟁률 조회는 상당히 많은 사용자에 의해 조회가 되고, Reload 또한 빈번하게 일어나므로 특정시간 간격으로 HTML을 생성하고, 페이지를 특정 서버에 위치시켜 적절하게 부하를 분산시켜 해결이 가능하다.

장점 : 다양한 환경에 대한 대처가 빠름

단점 : 구조를 정확하게 이해하지 않았을 경우에는 개발 및 테스트에 많은 시간이 쓰임

4. WAS단을 Logic으로 구분하여 구성

<그림 4><그림 2>의 변경된 형태이다. WAS단의 프로그램이 많은 비중을 차지하는 경우, Presentation Logic을 담당하는 프로그램과 Business Logic을 담당하는 프로그램을 구분하는 구성이다. 이런 구성은 특정 로직 부분의 부하에 따라 적절한 대응을 할 수 있으나 구조가 복잡해지는 단점이 있다.

[ WAS 관련 용어 정의 ]

1. 자바 서블릿(Java Servlet)

자바를 사용하여 웹페이지를 동적으로 생성하는 서버측 프로그램 혹은 그 사양을 말하며, 흔히 서블릿이라고 한다.

자바 서블릿은 Java EE사양의 일부분으로, 주로 이 기능을 이용하여 쇼핑몰이나 온라인 뱅킹 등의 다양한 웹 시스템이 구현되고 있다.

비슷한 기술로는 펄 등을 이용한 CGI, PHP를 아파치 웹 서버 프로세스에서 동작하게 하는 mod_php, 마이크로소프트사의 IIS에서 동작하는 ASP 등이 있다. CGI는 요청이 있을 때마다 새로운 프로세스가 생성되어 응답하는 데 비해, 자바 서블릿은 외부 요청마다 프로세스보다 가벼운 쓰레드로써 응답하므로 보다 가볍다. 또한 자바 서블릿은 자바로 구현되므로 다양한 플랫폼에서 동작한다.

2. 엔터프라이즈 자바빈즈(Enterprise JavaBeans, EJB)

EJB는 기업환경의 시스템을 구현하기 위한 서버측 컴포넌트 모델이다. , EJB는 애플리케이션의 업무 로직을 가지고 있는 서버 애플리케이션이다. EJB사양은 Java EE의 자바 API중 하나로, 주로 웹 시스템에서 JSP는 화면 로직을 처리하고, EJB는 업무 로직을 처리한다.

EJB의 종류는 세션 빈(Session Bean), 엔티티 빈(Entity Bean), 메시지 구동 빈(Message-driven Bean)이 있다.

3. 자바 메시지 서비스(Java Message Service, JMS)

JMS는 자바 프로그램이 네트워크를 통해 데이터를 송수신하는 자바 API이다.

4. 자바 가상 머신(Java Virtual Machine, JVM)

JVM자바 바이트코드를 수행할 수 있는 환경이다. 자바 바이트코드는 주로 자바를 컴파일하여 생성하지만, 다른 언어의 컴파일러에서도 생성할 수 있다. 자바 가상 머신은 자바 플랫폼의 기반을 이루며 다양한 하드웨어 기반 플랫폼에 포팅된다. JVM자바 플랫폼의 주요한 부분이며 마이크로소프트 윈도(95/98/NT), 리눅스, 유닉스, 오에스 등 대부분의 운영체제는 물론, 인터넷 익스플로러와 넷스케이프 등과 같은 웹 브라우저 등 여러 가지 플랫폼에 설치되어 사용될 수 있으며,휴대전화나 가전기기에도 설치할 수 있다. 따라서 자바 플랫폼은 여러 플랫폼을 지원하여 미들웨어로서의 역할과 플랫폼 스스로의 역할을 동시에 수행할 수 있다. 사용자는 자바 바이트코드로 컴파일된 자바 프로그램을 실행시키기 위해서 이 자바 가상머신을 이용하면 된다.

원 개발사인 썬 마이크로시스템즈에서 자바 가상 머신의 기준이 되는 표준판(Java SE) 과 표준판을 핸드폰이나 PDA 등 임베디드 기기용인 축소판(Java ME) 으로 구분하여 가상 머신을 배포하고 있다. 기업판(Java EE)의 경우에는 표준판의 자바 가상 머신을 기반으로 확장된 라이브러리 집합을 정의한 것이기 때문에 자바 가상 머신의 종류로 분류하기 애매하다. 마이크로시스템즈에서 제공하는 자바 가상 머신 말고도 각 운영체제 개발사가 제공하는 자바 가상 머신이 있으며, GNUGCJ아파치 소프트웨어 재단(ASF: Apache Software Foundation)하모니(Harmony)와 같은 오픈 소스 자바 가상 머신도 존재한다. 이러한 공개 소프트웨어 단체의 움직임에 따라 썬 마이크로시스템즈에서도 자사의 자바 가상 머신 및 개발 도구 킷을 오픈 소스 정책에 맞추어 공개한 상황이다.

5. 힙 메모리(heap memory)

프로그램을 사용할 수 있는 자유 메모리. 프로그램 실행 시에 함수로 보내는 데이터 등을 일시적으로 보관해 두는 소량의 메모리와 필요시 언제나 사용할 수 있는 대량의 메모리가 있다. 이때, 소량의 메모리를스택이라 하고 대량의 메모리를이라 한다. 이 없어지면 메모리 부족으로이상 종료하게 된다.

6. 자바 서버 페이지(JavaServer Pages, JSP)

HTML내에 자바 코드를 삽입하여 서버에서 동적으로 웹 페이지를 생성하여 브라우저에 돌려주는 언어이다. Java EE 스펙 중 일부로 애플리케이션 서버에서 동작한다. 자바 서버 페이지는 실행시에는 자바 서블릿으로 변환된 후 실행되므로 서블릿과 거의 유사하다고 볼 수 있다. 하지만,서블릿과는 HTML 표준에 따라 작성되므로 웹 디자인하기에 편리하다. 이와 비슷한 구조인 것인 PHP, ASP, ASP.NET 등도 있다. 아파치 스트럿츠자카르타 프로젝트JSTL 등의 JSP 태그 라이브러리를 사용하는 경우에는 자바 코딩없이 태그만으로 간략히 기술이 가능하므로 생산성을 높일 수 있다.

클라이언트에서 서비스가 요청되면, JSP의 실행을 요구하고, JSP 애플리케이션 서버의 서블릿 컨테이너에서 서블릿 원시코드로 변환된다. 그 후에 서블릿 원시코드는 바로 컴파일된 후 실행되어 결과를 HTML 형태로 클라이언트에 돌려준다.

7. Java Database Connectivity(JDBC)

자바에서 데이터베이스에 접속할 수 있도록 하는 자바 API이다. JDBC는 데이터베이스에서 자료를 쿼리하거나 업데이트하는 방법을 제공한다. JDBC Java로 작성된 프로그램을, 일반 데이터베이스에 연결하기 위한 응용프로그램 인터페이스 규격입니다. 이 응용프로그램 인터페이스는 데이터베이스 관리 시스템에 넘겨질 SQL 형태의 데이터베이스 접근요구 문장을, 각 시스템에 맞도록 바꾸어준다. API는 동적으로 올바른 Java 패키지를 로드하고, JDBC 드라이버 매니저에 등록하기 위한 메커니즘을 제공합니다. 드라이버 매니저가, JDBC connection을 생성하기 위한 connection factory로서 사용됩니다.

8. Java Management eXtensions(JMX)

응용 프로그램 소프트웨어/객체/장치 (프린터 등) 및 서비스 지향 네트워크 등을 감시 관리를 위한 도구를 제공하기 위한 자바 API이다. 이러한 리소스는 MBean(Managed Bean)이라는 객체로 표현된다.

9. Java Naming and Directory Interface(JNDI)

디렉터리 서비스에서 제공하는 데이터 및 객체를 발견(discover)하고 참고(lookup)하기 위한 자바 API이다.

'공부 > 용어' 카테고리의 다른 글

트랜젝션이란  (0) 2011.12.13