2015.02.25 17:58

MS-SQL 실행계획 Nested Join Merge Join 문제 해결 



문제: 

운영계서버와 테스트서버의 쿼리 속도가 다르다. 실제 0.5 초도 안걸리는 쿼리인데, 운영계서버에서 5초이상 걸리는 문제가 발생하였다.


확인사항:

1. 버전의 문제로 소스가 운영계와 테스트 소스가 다른가?   같음

2. 쿼리의 문제인가?  맞음. 운영계가 5초이상 걸리는 문제 발생

3. 실행계획 비교.  운영계에서 nested join 발생. 


수정사항:

nested join 을 hint 를 통해 merge join 으로 변경   ->  해결 ( 테스트서버의 실행계획과 같음)


완벽한 방법인가?

hint 는 테이블의 조인방법과 조인순서를 결정한다고 한다.

hint 의 단점이 있을까? 아직은 단점이 무엇인지 잘 모르겠다.


알아두기

hint 는 merge join 을 사용 했는데 merge join 은 두테이블을 정렬한 다음에 두 집합을 병합(merge) 하면서 조인을 수행하는 것인데, 여기서 병합알고리즘을 사용한다.

두테이블을 정렬해서 사용한다면, union 을 통해  각 테이블을 조회 한 뒤에  조인하는 방식으로 사용 하면 병합과 같은 효과를 낼 수 있다.


추가내용

옵티마이저는 데이터에 양, index 에 달라질 수 있다.  두 서버의 데이터를 동일하게 맞추고, Index 도 맞췄는데 옵티마이저가 다르게 동작 했다. 이런...또 어떤 경우에 달라지는지 찾아보자.

*MS-SQL 에서는 EXEC SP_HELPINDEX 테이블명을 통해 index 를 볼 수 있다.

 hint 는 옵티마이저 업그레이드시에 hint 를 따라 가기 때문에 문제가 될 가능성이 있다. 쿼리 수정으로 하는게 좋음.




참조

-- join 설명 http://302.pe.kr/137

-- union 으로 변경  http://otep.tistory.com/70

-- 옵티마이저 공부 http://wiki.gurubee.net/pages/viewpage.action?pageId=26744562





저작자 표시
신고

'프로그래밍 > DB_MSSQL' 카테고리의 다른 글

[MS-SQL] 실행계획 Nested Join Merge Join 문제해결  (0) 2015.02.25
[MSSQL] LEFT OUTER JOIN 예제  (0) 2014.02.13
[SQL] dateadd 문법  (0) 2014.02.10
Posted by hoonihoon85 hoonihoon
2014.07.14 11:00




1. HTTP 기본 구조(HTTP 1.0 이하)




파란 테두리: 첫 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정

빨간 테두리: 두 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정



위 그림(Wire Shake 예제)에서와 같이 HTTP는 기본적으로 Connection-Less 방식을 가진다. 즉 맷어진 Socket 연결은 유지되지 않고 매번 끊어지며다시 생성 되는 구조이다.



웹 서버 상세 처리 과정:

http://mohwaproject.tistory.com/entry/%EC%A0%95%EC%A0%81%EB%8F%99%EC%A0%81-%ED%8E%98%EC%9D%B4%EC%A7%80-%EC%9B%B9-%EC%84%9C%EB%B2%84-%EC%B2%98%EB%A6%AC-%EA%B3%BC%EC%A0%95







2. Keep-Alive(HTTP 1.1 이상) 기능 이란?


위 HTTP 기본 구조를 바탕으로 맷어진 Socket 연결이 종료된 시점(HTTP Response 이후)부터 웹 서버에 정의된 Keep-Alive Timeout 까지 기존 연결(Socket)을 유지하는 기능.


즉, 정의된 시간(Keep-Alive Timeout) 내에 새로운 HTTP 요청이 발생한다면? 맷어진 Socket 연결을 지속적으로 유지할 수 있다.(앞서 말한바와 같이 지속적인 연결은 유지되나 정의된 Keep-Alive Timeout  시간은 정확히 지켜지지 않는다.(보통 정의된 시간보다 Socket 연결이 일찍 끊어진다.)



IIS 테스트 결과 정의된 시간의 50% 이상 일찍 끊어진다.(120초 / 2)







3. IIS(6 / 7) Keep-Alive 설정 방법



- IIS 6


1. Keep-Alive 활성화 설정 및 Keep-Alive Timeout 정의


연결 시간 제한은 기본 120초를 갖는다.






- IIS 7:


1. Keep-Alive 활성화 설정












2. Keep-Alive Timeout 정의


연결 시간 제한은 기본 120초를 갖는다.












4. 웹 서버 HTTP Connection 변화




- Keep-Alive 비활성화 시:


1. 아래 예제와 같이 맷어진 HTTP Connection(Socket 연결)은 유지되지 않고 바로 끊어진다.(Current Connection 0.000)


2. Response-Header Field인 Connection 값으로 "close" 를 응답한다.








- Keep-Alive 활성화 시:


1. 아래 예제에서와 같이 맷어진 HTTP Connection(Socket 연결)은 유지된다.(Current Connection 1.000)


지속적인 연결은 유지되나 정의된 Keep-Alive Timeout(120초)  시간은 정확히 지켜지지 않는다.(보통 정의된 시간보다 Socket 연결이 일찍 끊어진다)


2. Response-Header Field인 Connection 필드는 존재하지 않는다.(IIS 기준)










5.  Wire Shake를 통해 본 Keep-Alive 처리 과정



파란 테두리: 첫 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정

빨간 테두리: 두 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정(Keep-Alive 활성화 시 HTTP 기본 구조와 달리 TCP 세션 수립과정 중 일부가 생략 되었다는걸 볼 수 있다.)







Keep-Alive 처리 과정


1. HTTP Session(논리적 연결) 생성




2. 정의된 Keep-Alive Timeout 내에 새로운 HTTP 요청이 발생할 경우, 새로운 Socket을 재 생성하는 것이 아닌 활성화 된 Keep-Alive 기능을 통해 유지된 Socket 연결 Request하게 된다.


즉, Socket 연결에 필요한 모든 비용이 감소하게 되며, 그에 따라 전체적인 성능도 좋아지게 된다.




3. 클라이언트(브라우저)와 웹 서버는 HTTP Request 및 Response를 수행한다.




4. 정의된 Keep-Alive Timeout 동안 맷어진 Socket 연결은 지속적으로 유지된다.




5. HTTP Session Close


- 클라이언트(사용자) 접속 종료 시 서버에 적재된 HTTP Session은 소멸된다.






Keep Alive Timeout(연결 유지 시간) 종료 시 처리 과정



파란 테두리: 첫 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정


빨간 테두리: 두 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정(Keep-Alive 활성화 시 HTTP 기본 구조와 달리 TCP 세션 수립과정 중 일부가 생략 되었다는걸 볼 수 있다.)


주황 테두리Socket(TCP) 연결 및  HTTP Request/Response 처리 과정(정의된 Keep-Alive Timeout(연결 유지 시간) 종료 시  첫 번째 요청과 같이 TCP 세션 수립과정 이 다시 발생하게 된다.)


출저: http://mohwaproject.tistory.com/entry/Wire-Shake%EB%A5%BC-%ED%86%B5%ED%95%B4-%EB%B3%B8-KeepAlive-%EC%B2%98%EB%A6%AC-%EA%B3%BC%EC%A0%95



TCP 세션 수립 과정



이번 포스트에서는 SSL 동작 방식에 앞서 패킷 교환 방식의 기본인 TCP 3 Way Handshake에 대해서 알아보도록 하겠습니다.



TCP 3 Way Handshake의 정의:


송신 측과 수신 측이 서로 교환할 패킷을 위해 총 3개의 패킷을 주고받으며, 서로에 대한 전송을 보장하는 세션을 수립하는 

과정입니다.




아래는 TCP 3 Way Handshake 과정을 대략적으로 도식화 한 그림 입니다.












TCP 3 Way Handshake 에 대한 상세 과정은 아래와 같습니다.






송신 측 호스트(211.254.99.210(클라이언트))

수신 측 호스트(203.242.213.203(웹서버))



1. 송신 측은 수신 측과의 통신을 원하고 있음을 알리는 신호로 TCP 헤더의 SYN(Synchoronize) Flag를 활성화(1)하고, 패킷에 일련번호(S/N(seq = 0))를 붙어 상대방에게 알려줍니다.


2. 이때 수신 측은 송신 측 SYN(Synchoronize)Flag 신호에 대한 응답 패킷 생성에 들어가기 위해, ACK(Acknowledgement)Flag를 on 시키고, 송신 측 일련번호(S/N(seq = 0))에 1을 더한 응답(A/N(ack = 1))값과 

자신의 일련번호(S/N(seq = 0))를 발송합니다. 또한, 이 과정은 송/수신 측의 양방향 세션이 수립되었음을 의미합니다.


3. 송신 측은 수신 측에게 두 번째 패킷(ack 및 일련번호(S/N(seq = 1) == (수신 측에게 받은 ack = 1 값))에 대한 응답을 주며, 이때부터 양 방향 패킷 교환이 시작되는 것입니다.






아래는 송/수신 간에 패킷 교환이 이루어지는 과정입니다.




송/수신간에 세션 수립(TCP 3 Way Handshake) 과정이 끝난 후 송신 측이 수신 측에게 GET요청을 보내고 있으며, 그에 따른 응답 메시지가 전송되고 있습니다.






위와 마찬가지로 송신 측의 GET 요청에 대한 응답 메시지가 전송됩니다.






페이지의 구성요소(js, css, img 등)이 요청됩니다.






웹서버가 클라이언트에게 HTML 응답 패킷을 전송합니다.




출저

http://mohwaproject.tistory.com/entry/TCP-3-Way-HandshakeTCP-%EC%84%B8%EC%85%98-%EC%88%98%EB%A6%BD


저작자 표시
신고
Posted by hoonihoon85 hoonihoon
2014.07.14 10:44

들어 가면서

HTTP는 아시다 시피 connection less 방식으로 연결을 매번 끊고 새로 생성하는 구조입니다. 이는 network 비용측면에서 많은 비용을 소비하는 구조입니다.( 최초 연결하기 위한 준비과정을 의미함 ) 그래서 HTTP 1.1부터는 Keep-Alive라는 기능을 지원합니다.


Keep Alive란?

Keep Alive란 연결된 socket에 IN/OUT의 access가 마지막으로 종료된 시점부터 정의된 시간까지 access가 없더라도 대기하는 구조입니다. 즉 정의된 시간내에 access가 이루어진다면 계속 연결된 상태를 유지할 수 있다는 것 이죠.


HTTP 下에서 Keep Alive란?

HTTP는 앞서 설명드린 것과 같이 connection less방식이라 매번 socket(port)를 열어야 하고 이는 비용적인 측면에서 비효율적인 구조입니다. 해서 keep Alive time out내에 client에서 request를 재 요청하면 socket(port)를 새로 여는 것이 아니라 이미 열려 있는 socket(port)에 전송하는 구조가 됩니다.


예를 들면 image를 4개를 보여주는 구조에서 client는 동시에 2개의 image만 얻어 올수 있고 1개의 image는 얻는데 2초 걸리고 port를 여는데 1초가 걸린다고 가정.



keep alive : false 

처음 server에 2개의 port를 열고 image를 얻고 client socket의 닫고 ( 3초 ) 

다시 server에 2개의 port를 열고 image를 얻고 client socket을 닫음 ( 3초 ) 

총 6초가 걸림.

keep alive : true 

처음 server에 2개의 port를 열고 image를 얻고 ( 3초 ) 

다시 첫번째 요청에서 열어 둔 2개의 port에 2개의 image를 얻음 ( 2초 ) 

keep alive time out이 되었을 때 client의 socet이 닫히거나 browser가 더 이상 얻어 올 것이 없으면 자동으로 닫어 버림. 

총 5초가 걸림.



Keep Alive를 그럼 어떻게 쓸수 있는가?

딱, 잘라서 말하면 개발자 영역에서 할 부분은 전혀 없습니다.


client(browser)는 http 1.1을 준수하고 이해 할수 있다고 request에 Connection: Keep-Alive를 넣어서 Server에 전송 

즉 client는 http 1.1 spec을 구현하고.. 

server도 http 1.1 spec을 구현하고 keep alive 기능을 활성화하고 keep alive time out을 설정

참고

client에서 keep alive code를 보내고 server도 kepp alive 기능을 제공할 경우.


$ telnet pungjoo.com 80

Trying 121.124.124.74...

Connected to pungjoo.com.

Escape character is '^]'.

GET / HTTP/1.1

Host: pungjoo.com

Connection: Keep-Alive

HTTP/1.1 302 Moved Temporarily

Date: Tue, 15 Jan 2008 01:32:45 GMT

Set-Cookie: JSESSIONID=91569ADEF9D501B8071BD59D0DC04E82; Path=/

Location: http://pungjoo.com/servlet/com.pungjoo.blog2005.Action

Content-Type: text/html;charset=EUC-KR

Content-Length: 0

Keep-Alive: timeout=5, max=100

Connection: Keep-Alive


Connection to pungjoo.com closed by foreign host.


위에 Connection to pungjoo.com closed by foreign host. 메시지가 바로 나오는 것이 아니라 5초 후에 나오게 됩니다.

즉 server/client의 구간은 지속됨을 알수 있습니다.



$ telnet pungjoo.com 80

Trying 121.124.124.74...

Connected topungjoo.com.

Escape character is '^]'.

GET / HTTP/1.1

Host: pungjoo.com

Connection: Keep-Alive

HTTP/1.1 302 Moved Temporarily

Date: Tue, 15 Jan 2008 01:36:26 GMT

Set-Cookie: JSESSIONID=2B3EE2FE56868BD9588A7B55C405974B; Path=/

Location: http://pungjoo.com/servlet/com.pungjoo.blog2005.Action

Content-Type: text/html;charset=EUC-KR

Content-Length: 0

Keep-Alive: timeout=5, max=100

Connection: Keep-Alive


GET / HTTP/1.1

Host: pungjoo.com

Connection: Keep-Alive


HTTP/1.1 302 Moved Temporarily

Date: Tue, 15 Jan 2008 01:36:35 GMT

Set-Cookie: JSESSIONID=E4E3D9B9CFE3693DC5AFC3D6ABDE5564; Path=/

Location: http://pungjoo.com/servlet/com.pungjoo.blog2005.Action

Content-Type: text/html;charset=EUC-KR

Content-Length: 0

Keep-Alive: timeout=5, max=99

Connection: Keep-Alive


Connection to pungjoo.com closed by foreign host.



위 예제를 보시면 알겠지만 telnet(연결)은 한번 사용했고 GET method를 2번 날렸습니다. 즉 이렇게 할수 있는 이유는 keep alive 기능때문에 가능한 것 입니다.


참고로 보면 Keep-Alive: timeout=5, max=99 부분에서 max가 감소를 하는 것을 볼수 있는데 이는 최초 연결된 port에 대해서 100회 request를 받겠다는 의미입니다.


HTTP1.0으로 해 보겠습니다. 즉 keep alive 기능이 없음.


$ telnet pungjoo.com 80

Trying 121.124.124.74...

Connected to pungjoo.com.

Escape character is '^]'.

GET / HTTP/1.0

Host: pungjoo.com

HTTP/1.1 302 Moved Temporarily

Date: Tue, 15 Jan 2008 01:33:56 GMT

Set-Cookie: JSESSIONID=B4329BFEDB1363BB90FCFA9568DDBF0B; Path=/

Location: http://pungjoo.com/servlet/com.pungjoo.blog2005.Action

Content-Type: text/html;charset=EUC-KR

Content-Length: 0

Connection: close


Connection to pungjoo.com closed by foreign host.


이번 경우는 response가 날라 오고 바로 'Connection to pungjoo.com closed by foreign host.'로 나와 버립니다. 즉 바로 server/client에서 끊어 버립니다.




출저: http://pungjoo.tistory.com/2

저작자 표시
신고
Posted by hoonihoon85 hoonihoon
2014.05.19 10:20

1. L4는 IP,포트,세션을 기반으로한 로드밸런싱이다.


2.  L4 스위치는 부하분산 장비이며,  L4 스위치를  로드밸런서 라고 한다. (Load Balancer)

    동일한 역할을 수행하는 서버 그룹을 VIP를 통해 관리하며, 서버로 향하는 트래픽을 일단 VIP를 가진 L4 스위치로 수신한뒤

    분배 정책에 따라 적절한 서버에 분배해 주는 것을 말한다.

    VIP는 Virtual IP 의 약자로, 서버 그룹의 대표 IP라 할 수 있습니다. 이 VIP를 로드밸런싱을 수행하는 L4 스위치가 있습니다.

    서버와 통신하고자 하는 클라이언트는 VIP를 향해 트래픽을 전송하고 L4 스위치가 이 트래픽을 받아 적절한 서버에 로드밸런싱 해주는 것이 L4 스위치의 역할 입니다.


3. 보통 서버 한대로 사용자의 트래픽을 감당하기 어렵기 때문에 동일한 역할을 수행하는

서버를 여러 대 두어서 사용자들의 트래픽이 많아져도 유연하고 안정적으로 사이트를 

운영하기 위해 L4 스위치를 통한 로드밸런싱을 한다.


4. 장점


1) 서버 이용률과 네트워크 대역폭의 효율이 증가 한다.

 - 사용자 세션 트래픽이 서버 풀에 있는 현재 가용한 서버들 중에서 부하가 적은 서버를 통해 처리 됩니다. 그러므로, 하나의 서버에 트래픽이 집중되는 것을 막아주고 서버의 트래픽처리 지연으로 인해 발생할 수 있는 대역폭의 낭비도 줄일 수 있습니다.


2) 사용자에게 신뢰성 있는 서비스를 제공할 수 있습니다.

- 하나의 서버에 문제가 발생하더라도 나머지 서버들에 의해 어플리케이션과 데이터로 접속할수 있습니다.


3) 서비스의 범용성을 높일 수 있습니다.

- 사용자가 늘어나고 서버들의 처리 용량이 부족하게 되는경우, 기존 서비스에 영향을 주지 않고 새로운 서버를 서버풀에 추가 할 수 있습니다. 





참고:

http://blog.naver.com/dltlahs007?Redirect=Log&logNo=100037040202

http://finerss.tistory.com/40



정리 제일 잘된거 펌!  http://finerss.tistory.com/40


한마디로 말하면,

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

 


저작자 표시
신고
Posted by hoonihoon85 hoonihoon
2014.04.24 11:49



[using 문 사용 예]



DB 를 사용하기 위해서  Connection 객체를 생성하고 

open() 하여 DB 데이터를 읽거나 쓰고 나서 close() 하는 게 정상 적인 방법이다.


Using 문을 사용하면  using 문 종료 후에 리소스들을 쉽게 되돌려 준다. 그러므로 db 를 close() 할 필요가 없다.


using 문 사용 예


using (SqlConnection conn= new SqlConnection("databsesName"))
{  

conn.Open();

 

return (new xxDao()).getXXX(conn, param1, param2); }


using 문 사용하지 않은 예 

try {

SqlConnection conn= new SqlConnection("databsesName"); conn.Open(); } finally { conn.Close(); }


using 문에서 여러 인스턴스를 선언 할 수 있다.


using (Font font3 = new Font("Arial", 10.0f),
            font4 = new Font("Arial", 10.0f))
{
    // Use font3 and font4.
}


저작자 표시
신고
Posted by hoonihoon85 hoonihoon
2014.02.28 11:42

기본 사용예제


Now()   :  2014-02-28 오전 10:53:53

Date()   :  2014-02-28

Time()   :  오후 4:48:49


FormatDateTime(Now(), 0)  :  2014-02-28 오전 10:53:53

FormatDateTime(Now(), 1)  :  2014년 2월 28월 금요일

FormatDateTime(Now(), 2)  :  2014-02-28

FormatDateTime(Now(), 3)  :  오후 4:48:49

FormatDateTime(Now(), 4)  :  16:48


** YYYY-MM-DD HH24:MI:SS (오라클 기준)
FormatDateTime(Now(), 2) ==> 2009-07-09
FormatDateTime(Now(), 4) ==> 16:48
Right(Now(), 3)                 ==> :49
====> 2009-07-09 16:48:49


Left(Date(), 4)     : 2009 (년)

Mid(Date(), 6,2)  :     07 (월)

Int(Mid(Date(), 6, 2))  :  7 (월)


실전


(1) 시간과 분을 분리 하기 

oneDateTime = FormatDateTime(Time(), 4)

SpliteTimes = Split(OneDateTime, ":")

SplitTimes(0) : 25시간중의 시간을 나타낸다.

SplitTimes(1) : 분의 값을 나타 낸다.


(2) 쇼핑몰_해당기간에 혜택주기


1) 우선 현재 시간을 구한다.

date_now = replace(date(), "-", "") & right("0"&hour(now),2)


replace(date(), "-", "")  :  20140228

right("0"&hour(now),2)  :          011


if 201402200 <= date_now and date_now <= 2014030724 then

    이벤트

end if

저작자 표시
신고
Posted by hoonihoon85 hoonihoon
2014.02.26 10:36

DLL 이란?


DLL이란 라이브러리를 말한다. 그럼 라이브러리란 함수,데이터, 타입등의 여러가지 프로그래밍 요소들의 집합이다. 보통 LIB로 표현된다. 


자주사용되는 부분이 있다고 치자. 예를들면, 아이디 체크라든지, 이미지의 로딩이라던지, 그런 비슷한 부분을 프로그램을 한다


고 치면, 같은 부분을 여러번 소스를 작성하면 나중에 수정하기에 힘들뿐더러 당장 타이핑할때 손가락의 마비가 올수도 있다. 또한 여러번 작성함으로써 버그가 숨을 공간을 남긴다. 


이러한 부분을 따로 DLL로 만들어 놓으면, 한번 코딩으로 여러군데서 동시에 쓰일수 있다. 


또한 이렇게 만들어 놓은 좋은 DLL이 있다면, 새로운 프로그램을 빌드할때나, 실행할때 DLL의 도움을 받아 쉽게 작성할수 있으리라.

 
Unix나 Linux를 한사람들도 Dll이나, Lib 등은 알것이다. M$에서 만든것이 아니고, 여기에서 차용해 왔다고 그러더라. 

간단히 요약하자. 

* DLL은 자주사용되는 함수및 변수, 데이터의 프로그래밍 요소의 집합이다.
* 실행이나, 컴파일시 같이 빌드하면 해당 프로그램내에서 간편히 사용할수 있다.


DLL은 두가지 링크의 형태로써 프로그램과 연관을 맺는다. 

정적링크 : 


 Lib로 빌드된다. 프로그램 빌드시에 같이 빌드가 되면서 해당 프로그램의 일부가 된다. 현실적으로는 속도가 동적링


크보다는 빠르다만, 크기가 커진다. 여러 프로그램이 같은 Lib를 쓴다면, 점점더 많은 메모리가 필요하다. 절대 공유하지 않는


다. 이미 프로그램의 일부로써 다른 프로그램과는 다른 영역에 존재한다. 프로그램 빌드시에 해당 함수및 변수, 데이타들이 프


로그램에 포함되기 때문에 프로그램의 실행시 Lib의 필요가 없다. (없어도 실행가능하다) 

동적링크 :


 DLL로 빌드된다.(그렇다고, Lib가 없다는건 아니다.) 프로그램의 빌드시에는 DLL안의 함수선언만 있으면 충분하다. 현실적으


로는 속도가 정적링크보다는 느리다고 할수 있지만, 크기가 커지는 것은 아니며, 여러 프로그램이 같은 DLL을 쓴다고 하더래도 


DLL이 그 수만큼 메모리에 적재되는 것은 아니며, 공유해서 쓰게 된다. 타 프로그램도 읽을수 있는 메모리 공간에 따로 할당이 


된다. 프로그램 빌드시에는 해당 함수에 대한 선언만이 존재할뿐이어서 실제 코드가 링크된 DLL파일이 없는이상 프로그램이 실


행되지 않는다.



레지스트리란?


‘레지스트리’는 윈도우 운영체제의 실행, 또는 각종 윈도우용 응용프로그램의 실행에 필요한 설정


값들을 한데 모아 놓은 데이터베이스입니다.

 

레지스트리는 윈도우OS 만의 고유한 정보저장 체계이며, 레지스트리 내의 각 위치마다 어떤 정보가

 

어떤 형식으로 저장되어야 하는지의 규칙이 정해져 있습니다.

 

저장된 레지스트리 정보는 OS나 프로그램에 의해 읽혀지고 수정되면서 다양하게 활용됩니다. 윈도우

 

의 각 계정 별로 바탕화면을 다르게 설정하거나, MP3 확장자를 실행할 때 사용자 별로 기본 음악플

 

레이어를 다르게 정할 수 있는 것도 모두 레지스트리의 특정 위치에 이러한 규칙을 지정하는 값들이

 

존재하기 때문입니다.

 

레지스트리라는 표준화된 정보저장소가 존재함으로 인해 대부분의 윈도우용 응용프로그램들이 더 효

 

율적이고 간결한 구조를 가질 수 있습니다. 다만 레지스트리에 대한 의존도가 그 만큼 높기 때문에

 

레지스트리를 잘못 변경하거나 삭제하게 되면 필요한 정보를 얻지 못한 프로그램이 실행되지 않거나

 

비정상적으로 동작할 수 있습니다.

 

 

예를 하나 들면 어느 사용자가 A’ PC에 설치된 사진편집 프로그램의 폴더를 찾아 폴더 내용을 그대

 

로 복사해서 B’ PC로 옮긴다면, 복사된 사진편집 프로그램은 제대로 실행되지 않습니다.

 

이는 정상적인 설치과정을 거치지 않고 사진편집 프로그램 폴더의 파일만 복사를 했기 때문에 A’

 

PC에 세팅된 레지스트리 정보가 B’ PC에 정상적으로 세팅되지 못했기 때문입니다.

 

레지스트리에는 사용자 설정과 각 하드웨어, 소프트웨어의 설정 값이 저장되기도 하지만 시스템과

 

애플리케이션의 동작 기록 및 사용자의 윈도우 사용기록을 남김으로 시스템운영에 필요한 로그의 기

 

능을 하기도 합니다.

 


등록된 DLL 보기


레지스트리 편집기는 열기.  실행창에서 regedit 를 입력.


아래 레지스트리 경로에서 레지스트리에 등록된 DLL의 목록을 볼 수 있다.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs



참고:

http://blog.daum.net/kiswiz/13

http://alyac.altools.co.kr/SecurityCenter/Issue/CommonSenseView.aspx?id=58

저작자 표시
신고
Posted by hoonihoon85 hoonihoon
2014.02.18 15:57

str = "1234 5678 91021 3568"

isNa = Instr(str,"l3568")
Response.Write isNa


지정한 문자열이 있으면 몇번째에 있는지 숫자를 반환하고, 없으면 0 을 반환


저작자 표시
신고
Posted by hoonihoon85 hoonihoon
2014.02.17 15:05

Null 값일 때다른 값으로 바꿔주는 함수로  oracle에서는 nvl()함수를 사용하고,
MS-SQL
에서는
  isnull()함수를 사용하면 됩니다.


예)


NVL(SUM(mileage),0) as mileage

저작자 표시
신고

'프로그래밍 > DB_ORACLE' 카테고리의 다른 글

오라클 nvl  (0) 2014.02.17
Oracle DISTINCT, GROUP BY  (1) 2014.02.07
Oracle DECODE 함수  (0) 2014.02.06
Posted by hoonihoon85 hoonihoon
2014.02.13 14:56

SELECT *

FROM Orders order by CustomerID


OrderIDCustomerIDEmployeeIDOrderDateShipperID
10308271996-09-183
10365331996-11-272
10355461996-11-151
10383481996-12-163
10278581996-08-122


SELECT *

FROM Customers


CustomerIDCustomerNameContactNameAddressCityPostalCodeCountry
1Alfreds FutterkisteMaria AndersObere Str. 57Berlin12209Germany
2Ana Trujillo Emparedados y heladosAna TrujilloAvda. de la Constituci� 2222M�ico D.F.05021Mexico
3Antonio Moreno Taquer�Antonio MorenoMataderos 2312M�ico D.F.05023Mexico
4Around the HornThomas Hardy120 Hanover Sq.LondonWA1 1DPUK



두개를 LEFT OUTER JOIN 하게 되면


SELECT *

FROM Customers a

LEFT JOIN Orders b

ON a.CustomerID=b.CustomerID

ORDER BY Customers.CustomerName;


CustomerIDCustomerNameContactNameAddressCityPostalCodeCountryOrderIDEmployeeIDOrderDateShipperID
1Alfreds FutterkisteMaria AndersObere Str. 57Berlin12209Germanynullnullnullnull
2Ana Trujillo Emparedados y heladosAna TrujilloAvda. de la Constituci� 2222M�ico D.F.05021Mexico1030871996-09-183
3Antonio Moreno Taquer�Antonio MorenoMataderos 2312M�ico D.F.05023Mexico1036531996-11-272


결과에서 보면  LEFT OUTER JOIN 은 


ON CustomerID 를 기준으로 Orders 테이블과 일치하는 레코드가 없으면, Orders 테이블의 모든 컬럼이 담긴 row에 NULL을 넣는다


저작자 표시
신고

'프로그래밍 > DB_MSSQL' 카테고리의 다른 글

[MS-SQL] 실행계획 Nested Join Merge Join 문제해결  (0) 2015.02.25
[MSSQL] LEFT OUTER JOIN 예제  (0) 2014.02.13
[SQL] dateadd 문법  (0) 2014.02.10
Posted by hoonihoon85 hoonihoon