스위치의 분류 :

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호출 오버헤드 발생

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

Oracle 컬럼 암호화 (Transparent Data Encryption)

Oracle10g Release 2에서는 데이터의 암호화를 위하여 
Transparent Data Encryption (이하 TDE) 라는 기능을 제공한다.

이 기능의 특징은

1. 테이블의 컬럼별로 데이터를 암호화 할 수 있다.
2. 인덱스도 암호화 할 수 있으며, 인덱스에 암호화 하더라도 성능의 큰 저하는 없다
(Oracle에서는 Insert시 1.6배, Select시 1.4배의 저하가 생긴다고 함..수치 확인필요)
3. pl-sql로 암호화/복호화의 DDL을 재정의, 혹은 정의 할 필요가 없다.
4. 물리적인 데이터파일(dbf확장자 파일)의 도난에 안전하다.
5. 동일 Wallet으로 Data Dump의 import, export도 가능하다.
6. AES128, AES192, AES256, 3DE168(168비트 Triple DES알고리즘)로 암호화 가능.
7. Salt라는 기능으로 같은 값의 데이터를 다른 암호화된 데이터로 저장 가능.
8. 기존 테이블에 ALTER TABLE 테이블명 MODIFY (컬럼명 ENCRYPT)로 
   암호화 가능

이정도가 될 것 같다. 장점을 우선으로 나열했다.

구현 방법은

1. %ORA_HOME%\admin\SID 밑에 wallet이라는 폴더를 만든다
(디폴트로 해당 폴더가 생성되지 않는다. wallet을 저장하는 디폴트 폴더가 저기.)

2. ALTER SYSTEM권한이 있는 계정으로 로그인한다.
(SYSDBA계정으로 GRANT해도 되고, SYSDBA계정으로 로그인해도 됨)

3. ALTER SYSTEM SET ENCRYPTION KEY AUTHENTICATED BY "비밀번호"; 입력
(비밀번호는 반드시 더블쿼테이션으로..)
(AUTHENTICATED 대신 IDENTIFIED로 해도 됐었던 기억이...)
※ 이때 wallet을 자동 생성 할 수 없다는 에러가 발생할 때
 → 1번의 폴더 생성확인 해 볼 것. 
     비밀번호를 영어대소문자, 숫자, 특수문자를 포함하는 8자리 이상으로 지정 해 볼 것.

4. 1번의 폴더에 물리적 wallet파일이 생성되었는지 확인

5. 4번으로 생성된 wallet이 자동으로 open되나, open되었는지 확인 (에러 확인)
(ALTER SYSTEM SET ENCRYPTION WALLET OPEN AUTHENTICRYPTED BY "비밀번호"; 여기서 비밀번호는 생성시의 비밀번호)
※ WALLET 닫기
→ ALTER SYSTEM SET ENCRYPTION WALLET CLOSE;

6. 테이블 생성 (컬럼 정의 시, 암호화 할 컬럼 맨 마지막에 ENCRYPT 정의)
ex) CREATE TABLE encryptedTable (col1 varchar2(10) ENCRYPT);
Primary key에 대해서는 SALT로 컬럼을 생성 할 수 없다.(ENCRYPT는 SALT가 기본)
그럴때는
CREATE TABLE encryptedTable (col1 varchar2(10) ENCRYPT NO SALT);

7. 기존 테이블을 수정 할 경우
ALTER TABLE 테이블명 MODIFY (컬럼명 ENCRPYT);

이것으로 기본 설정은 끝.

Tip!
1. 컬럼에 암호화 설정시, 암호화 방식을 설정 할 수 있다. (기본 AES192)
ex) ALTER TABLE 테이블명 MODIFY (컬럼명 ENCRYPT USING '방식');

2. 암호화된 컬럼의 암호화 설정 제거
ex) ALTER TABLE 테이블명 MODIFY (컬럼명 DECRYPT);

이제 평상시 대로 INSERT, UPDATE, DELETE, SELECT를 하면 된다.
쿼리의 결과로는 복호화되기 전의 암호화 된 데이터의 확인이 불가능하다.
WALLET을 CLOSE하고 DDL을 날리면 WALLET이 CLOSE되어 있다는 에러 발생.

※ TDE의 단점 
정당한 방법으로 로그인 한 유저에 대해서는 암호화 정책이 해당되지 않는다.