[3티어 방식의 장점]
1. 보안측면에서 유리해 진다.
제대로 된 2티어 방식에서는 보안을 위해서, 해당 DB에서 사용자마다 DB 접속 계정을 만들고 DB 객체(Table, 저장프록)
참조에 대한 권한을 일일이 설정해야 하지만, 이렇게 하면 너무 사용자 관리가 복잡해지고, 프로그램 변경도 어렵게 된다.
이 때문에 2티어에서 주로 많이 취하는 방식은, DB에 커넥션할 때 admin(MSSQL인 경우 sa계정) 계정으로 접속하고,
사용자 정보 테이블을 DB에 만들어 두고 단순히 계정과 암호를 보관하는 용도로 사용한다.
이렇게 함으로 인해서 프로그램은 편해질지 몰라도, 실행 파일 내부에 admin 계정에 대한 정보가 고스란히 존재하여,
해커들이 쉽게 admin 계정을 알 수 있게 된다. 특히 폼에 놓여진 데이타베이스 연결 콤포넌트 속성 일부로
admin 계정 정보를 저장했다면, 정말 치명적이다. 해커들은 아주 쉽사리 폼에 대한 정보를 얻을 수 있기 때문이다.
3티어 방식은 DB 연결에 대한 어떤 정보도 클라이언트 보관한 필요가 없다. 따라서 보안 측면에서 훨씬 좋다.
2티어는 성격상 외부에서의 DB연결을 허용해야 하지만, 3티어는 DB 직접 연결을 허용하지 않는다.
2. 3티어 대용량 서비스에서 2티어에 비해서 유리하다.
이는, 2티어 방식에서는 한 사용자당 한 커넥션을 가져야 하며, 그 사용자가 프로그램을 종료하기 전까지는
그 커넥션을 계속 가지고 있어야 하기 때문이다. 반면 3티어에서는 대부분 connectless 방식을 취한다.
즉 웹서버 같이 서비스 요청/응답 후 즉시 연결을 차단하는 방식을 사용하기 때문에, 커넥션 수가 제한될 때 월등히 유리하다.
DB 커넥션은 대부분의 RDB에서는 별도로 부과되는 라이센스 비용이기 때문에, 적은 수의 커넥션으로
많은 사용자들에게 서비스할 수 있다는 점은 경비적으로 3티어가 2티어에 비해서 좋은 점이다.
물론 2티어에서도 순수 코딩으로 3 티어같이 connectionless방식을 구현할 수도 있을 것이다. 그러나 이렇게 할 경우 잦은 connect,
disconnect는 프로그램 속도를 느리게 하고, 서버에 도리어 부담을 줄 수도 있다. 반면 3티어는 커넥션 풀링 등의 개념을 사용하여
이런 부담을 줄일 수 있다.
3. 클라이언트 배포가 단순해 진다.
3티어 방식에서 클라이언트는 실행파일만 배포하면 될 뿐, ADO, ODBC, BDE같은 DB 연결 라이브러리 설치가 전혀 필요없다.
이는 어플 서버만 디비에 직접 연결할 뿐, 클라이언트는 DB 가 무엇인지 전혀 알 필요가 없기 때문이다.
2티어의 경우 클라이언트가 100대이고, 연결방식이 BDE라고 가정했을 때,
이 100대에 대해서 BDE를 업데이트해야할 필요성이 발생했다면, 얼마나 끔직한 일인가?
BDE 업데이트를 하려면 단순 파일들의 덮어쓰기 말고도 레지스트리 정보도 수정해 줘야 하므로,
자동 업데이트 프로그램을 만들기도 쉽지 않다.
그러나 3티어에서는 클라이언트 실행 파일만 자동 업데이트하는 로직을 구현해 주면 된다. 대부분의 경우 이는 매우 쉽다.
4. SQL 문장이 클라이언트 프로그램에 있을 필요가 없다.
3티어 방식에서 DB에 요청을 하는 것은 어플 서버만 담당하므로, 클라이언트는 전혀 SQL문장을 사용할 필요가 없다.
3항에서 언급했듯이 클라이언트는 어플 서버하고만 통신할 뿐, 디비 서버와는 전혀 통신하지 않는다.
따라서 모든 요청은 어플 서버에 대한 원격 함수 호출만 존재할 뿐, 어플 서버 쪽으로
직접 SQL 문을 날리는 경우는 보안적인 이유로 지극히 제한된다.
보통 2티어인 경우, 클라이언트 프로그램 내부에 수많은 SQL문들이 존재하고 이를 디비 서버로 전송할 것이다.
실행 파일 내부에 SQL 문이 존재한다는 것은, 해킹과 크랙의 가능성을 높여주고, 디비 구조를 추정해볼 수 있는 힌트가 된다.
5. 다중 DB 사용이 용이하다.
기존 프로그램이 MS SQL 서버를 사용해서 만들었다고 가정하자. 이를 오라클에서도 동작할 수 있도록 변경하려면,
2티어 방식에서는 클라이언트 모든 프로그램을 수정해야 할 것이다. 3티어는 어플 서버 쪽으로 모든 SQL 문이 집중되어 있으므로,
비교적 디비 전환이 슆다(물론 거저 먹기씩으로 아주 간단하다는 말은 절대 아니다).
오라클, MSSQL은 각자 자기만의 특수한 SQL구문이 있을 수가 있는데, 각 디비마다 이런 최적화를 어플 서버에 집중할 수 있으므로,
특정 디비에 대한 고유한 기능을 살리면서, 클라이언트에는 별다른 영향을 주지 않게 할 수 있다.
이와 비슷한 경우로, 실제 테이블의 필드명이 CUST_NO이지만, 클라이언트에서는 CustID라는 필드명을 사용하고 싶을때도
마찬가지다. 어플 서버가 실제 필드명과 클라이언트 필드명을 매핑하는 역할을 할 수 있다.
회사 PPT 자료 만들때 쓴던건데 생각나서 올려봅니다~ 참고하세요~
좋은 내용입니다.
근데 2티어가 왜 커넥션을 물고 가야하는지 이해가 안되네요.
오라클의 transaction scope 이 session 별로 이루어 지기 때문에, 오라클에서만 해당 하는 내용일듯..
--------------------------------------------------------------------------------------------------
대용량 DB의 경우를 예를들어봅시다..
우선
클라이언트 1대가 접속을 한다면 커넥션이 1개가 생깁니다.
클라이언트 10000대가 접속을 한다면 커넥션이 10000개가 생기죠..
connection 을 시작할 경우 절차를 생각해봅시다..
'DB 서버 너 살았니????" (ping을 날립니다)
"나 살았어~~~~~~ 접속해~~~" (request 합니다)
"나한테 남은 물약이 있니?" (쿼리를 수행합니다)
"물약 5개 남았어"
"나 물약1개 먹을께"
"OK 물약이제 4개 남았어"
" 수고했어 안녕~~~"
---------------------7번 데이터를 주고받았습니다.
이를 connectionless 방식으로 생각해보겠습니다.
-- connection
'DB 서버 너 살았니????"
"나 살았어~~~~~~ 접속해~~~"
"나한테 남은 물약이 있니?"
"물약 5개 남았어"
" 수고했어 안녕~~~"
-- disconnection
-- connection
'DB 서버 너 살았니????"
"나 살았어~~~~~~ 접속해~~~"
"나 물약1개 먹을께"
"OK 물약이제 4개 남았어"
" 수고했어 안녕~~~"
-- disconnection
-------------10번 데이터를 주고받았습니다.
이는 클라이언트 1대의 경우 7번과 10번이 나옵니다
이를 10000대의 클라이언트라고 생각하면 답은 나옵니다..
2티어에서는 connection방식이든 connectionless 방식이든
connection 연결된 수는 10000개가 생길수 밖에 없으니깐요~
--------------------------------------------------------------------------------------------------
제 의미 전달이 잘못된 듯하네요.
위의 오라클은 transaction comit 단위가 session 이라 어쩔 수 없다지만,
mssql 경우 이미 커넥션 풀을 지원해 주고 있기 때문이란 뜻이에요.
connection string 을 기준으로, 커넥션 풀을 관리한다고 알고 있는데;;
--------------------------------------------------------------------------------------------------
2tear의 경우 client에서 바로 DB connetion을 할 것입니다.
문제는 이 connection을 dispose을 하더라도 DB서버와 클라이언트는 항상 connetion을 하나를 물고있습니다.
즉, 클라이언트의 수가 늘어날수록 DB서버의 connection수는 증가한다고 생각하시면될 것입니다.
실제로 간단한 테이블 만들어서 클라이언트에서 그 테이블의 자료을 처음에 가지고오고 dispose()를 하면...
보통
using(DBconnection)
{
}
이렇게 사용하시겠죠?
DB에서는 그 테이블이 포함된 DB가 삭제가 안될것입니다. 프로그램 종료전까지 말입니다.
3tear의 경우 실제 DB와 connection부분이 서버에서 이루어지기 때문에 DB는 단지 해당 서버와 connection을
물고 있으면 되는 것입니다.
--------------------------------------------------------------------------------------------------
또 답변을 달게 되는군요 -_-
생각하길 커넥션을 여는 만큼 커넥션이 열린다고 생각하기 쉽지만,
그것인 닷넷개체이든 DBMS 내부적이든 커넥션 풀을 관리하고 있습니다.
내가 커넥션을 연다고 열리는 것이 아니라, 이 내부적인 커넥션 풀이 모든 것을 관리하지요..
실제로 커넥션을 닫아도, 일정 시간 커넥션은 열려있게 되고, 이것또한 커넥션 풀이 관리를 하지요..
무한적 늘어나날 수 있는 커넥션을, 풀로 관리를 한다는 겁니다.
여기서 제가 오라클 얘길 했는데,
오라클은 트랜잭션의 커밋을 위해 세션 단위로 커밋을 하기 됩니다.
즉, 2tier 라면 반드시, 1인 1커넥션이 있어야 트랜잭션 스콥에 포함이 됩니다.
사용하는 디비가 오라클이라면 1클라이언트 : 1커넥션이 성립이 되지만,,
MSSQL 이라면 반드시 그렇지 않다라는 거죠 -_-;;
이해 되셨는지 ...
--------------------------------------------------------------------------------------------------
SQL DB가 connection 풀을 지원하지만 확실히 2tear 와 3tear에서의 차이는 있습니다.
전 그점을 이야기 하고 싶었던 겁니다.
2tear에서 클라이언트에 직접 connection을 열면 각 클라이언트마다 SQL DB에서 각각의 프로세서 ID를 부여 하고
있다는 것을 확인 하실수 있을 겁니다.
다른 예로 한 클라이언트에서 같은 connection string으로 여러개의 동일프그램을 실행 시켜 확인해보면
각각의 프로세서 ID을 부여하고 있고 close() or dispose()을 하여도 여전히 서로 물고 있다가 일정시간 더이상
작업이 없으면 프로세서를 해당 프로세서를 해제합니다.
하지만 3tear의 경우 클라이언트가 아닌 서버에서 DB와 connection을 연결하기 때문에 이와 같이 행동하지 앖습니다.
결론은 2tear 와 3tear에서 physical tear상황마다 틀리지만 logical tear로는 3tear로 가는것이 맞다는 것이
저의 의견입니다.
물론 이외도 보완상이라던지 관리 및 scalability등도 3tear의 장점이죠 ^^
--------------------------------------------------------------------------------------------------
하하하.. 그렇군요.
하지만 요즘은 3-tier 로 많이 구축이 되긴 하지만, 일부에서는 3~4 tier 가 아닌,,
터미널이나 콘솔형태의 서버를 많이 구축 하기도 한답니다.
바로, 서버의 비용적인 측면도 있겠지만, 분산 시스템에서 유지/보수가 과거의 터미널이나 콘솔 형태보다
몇 배 많이 들어가게 된다는 점입니다.
그리고, 클라이언트에게 권한을 할당하는 방식이 아닌, 서버가 모든 권한을 가짐으로써 보안 문제에도 예전 터미널 방식이 훨씬 유리하겠죠.
당연히 3-tier 로 가야 한다는 발상은 요즘 시대에 조금 위험한 듯 합니다^^
어찌되었건 제가 하고 싶었던 얘기는 커넥션에 대한 얘기인데, 약간 본질이 흐려진 것 같네요.
출처 : http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=18&MAEULNO=8&no=1582&page=3
1. 보안측면에서 유리해 진다.
제대로 된 2티어 방식에서는 보안을 위해서, 해당 DB에서 사용자마다 DB 접속 계정을 만들고 DB 객체(Table, 저장프록)
참조에 대한 권한을 일일이 설정해야 하지만, 이렇게 하면 너무 사용자 관리가 복잡해지고, 프로그램 변경도 어렵게 된다.
이 때문에 2티어에서 주로 많이 취하는 방식은, DB에 커넥션할 때 admin(MSSQL인 경우 sa계정) 계정으로 접속하고,
사용자 정보 테이블을 DB에 만들어 두고 단순히 계정과 암호를 보관하는 용도로 사용한다.
이렇게 함으로 인해서 프로그램은 편해질지 몰라도, 실행 파일 내부에 admin 계정에 대한 정보가 고스란히 존재하여,
해커들이 쉽게 admin 계정을 알 수 있게 된다. 특히 폼에 놓여진 데이타베이스 연결 콤포넌트 속성 일부로
admin 계정 정보를 저장했다면, 정말 치명적이다. 해커들은 아주 쉽사리 폼에 대한 정보를 얻을 수 있기 때문이다.
3티어 방식은 DB 연결에 대한 어떤 정보도 클라이언트 보관한 필요가 없다. 따라서 보안 측면에서 훨씬 좋다.
2티어는 성격상 외부에서의 DB연결을 허용해야 하지만, 3티어는 DB 직접 연결을 허용하지 않는다.
2. 3티어 대용량 서비스에서 2티어에 비해서 유리하다.
이는, 2티어 방식에서는 한 사용자당 한 커넥션을 가져야 하며, 그 사용자가 프로그램을 종료하기 전까지는
그 커넥션을 계속 가지고 있어야 하기 때문이다. 반면 3티어에서는 대부분 connectless 방식을 취한다.
즉 웹서버 같이 서비스 요청/응답 후 즉시 연결을 차단하는 방식을 사용하기 때문에, 커넥션 수가 제한될 때 월등히 유리하다.
DB 커넥션은 대부분의 RDB에서는 별도로 부과되는 라이센스 비용이기 때문에, 적은 수의 커넥션으로
많은 사용자들에게 서비스할 수 있다는 점은 경비적으로 3티어가 2티어에 비해서 좋은 점이다.
물론 2티어에서도 순수 코딩으로 3 티어같이 connectionless방식을 구현할 수도 있을 것이다. 그러나 이렇게 할 경우 잦은 connect,
disconnect는 프로그램 속도를 느리게 하고, 서버에 도리어 부담을 줄 수도 있다. 반면 3티어는 커넥션 풀링 등의 개념을 사용하여
이런 부담을 줄일 수 있다.
3. 클라이언트 배포가 단순해 진다.
3티어 방식에서 클라이언트는 실행파일만 배포하면 될 뿐, ADO, ODBC, BDE같은 DB 연결 라이브러리 설치가 전혀 필요없다.
이는 어플 서버만 디비에 직접 연결할 뿐, 클라이언트는 DB 가 무엇인지 전혀 알 필요가 없기 때문이다.
2티어의 경우 클라이언트가 100대이고, 연결방식이 BDE라고 가정했을 때,
이 100대에 대해서 BDE를 업데이트해야할 필요성이 발생했다면, 얼마나 끔직한 일인가?
BDE 업데이트를 하려면 단순 파일들의 덮어쓰기 말고도 레지스트리 정보도 수정해 줘야 하므로,
자동 업데이트 프로그램을 만들기도 쉽지 않다.
그러나 3티어에서는 클라이언트 실행 파일만 자동 업데이트하는 로직을 구현해 주면 된다. 대부분의 경우 이는 매우 쉽다.
4. SQL 문장이 클라이언트 프로그램에 있을 필요가 없다.
3티어 방식에서 DB에 요청을 하는 것은 어플 서버만 담당하므로, 클라이언트는 전혀 SQL문장을 사용할 필요가 없다.
3항에서 언급했듯이 클라이언트는 어플 서버하고만 통신할 뿐, 디비 서버와는 전혀 통신하지 않는다.
따라서 모든 요청은 어플 서버에 대한 원격 함수 호출만 존재할 뿐, 어플 서버 쪽으로
직접 SQL 문을 날리는 경우는 보안적인 이유로 지극히 제한된다.
보통 2티어인 경우, 클라이언트 프로그램 내부에 수많은 SQL문들이 존재하고 이를 디비 서버로 전송할 것이다.
실행 파일 내부에 SQL 문이 존재한다는 것은, 해킹과 크랙의 가능성을 높여주고, 디비 구조를 추정해볼 수 있는 힌트가 된다.
5. 다중 DB 사용이 용이하다.
기존 프로그램이 MS SQL 서버를 사용해서 만들었다고 가정하자. 이를 오라클에서도 동작할 수 있도록 변경하려면,
2티어 방식에서는 클라이언트 모든 프로그램을 수정해야 할 것이다. 3티어는 어플 서버 쪽으로 모든 SQL 문이 집중되어 있으므로,
비교적 디비 전환이 슆다(물론 거저 먹기씩으로 아주 간단하다는 말은 절대 아니다).
오라클, MSSQL은 각자 자기만의 특수한 SQL구문이 있을 수가 있는데, 각 디비마다 이런 최적화를 어플 서버에 집중할 수 있으므로,
특정 디비에 대한 고유한 기능을 살리면서, 클라이언트에는 별다른 영향을 주지 않게 할 수 있다.
이와 비슷한 경우로, 실제 테이블의 필드명이 CUST_NO이지만, 클라이언트에서는 CustID라는 필드명을 사용하고 싶을때도
마찬가지다. 어플 서버가 실제 필드명과 클라이언트 필드명을 매핑하는 역할을 할 수 있다.
회사 PPT 자료 만들때 쓴던건데 생각나서 올려봅니다~ 참고하세요~
아래의 리플들...
좋은 내용입니다.
근데 2티어가 왜 커넥션을 물고 가야하는지 이해가 안되네요.
오라클의 transaction scope 이 session 별로 이루어 지기 때문에, 오라클에서만 해당 하는 내용일듯..
--------------------------------------------------------------------------------------------------
대용량 DB의 경우를 예를들어봅시다..
우선
클라이언트 1대가 접속을 한다면 커넥션이 1개가 생깁니다.
클라이언트 10000대가 접속을 한다면 커넥션이 10000개가 생기죠..
connection 을 시작할 경우 절차를 생각해봅시다..
'DB 서버 너 살았니????" (ping을 날립니다)
"나 살았어~~~~~~ 접속해~~~" (request 합니다)
"나한테 남은 물약이 있니?" (쿼리를 수행합니다)
"물약 5개 남았어"
"나 물약1개 먹을께"
"OK 물약이제 4개 남았어"
" 수고했어 안녕~~~"
---------------------7번 데이터를 주고받았습니다.
이를 connectionless 방식으로 생각해보겠습니다.
-- connection
'DB 서버 너 살았니????"
"나 살았어~~~~~~ 접속해~~~"
"나한테 남은 물약이 있니?"
"물약 5개 남았어"
" 수고했어 안녕~~~"
-- disconnection
-- connection
'DB 서버 너 살았니????"
"나 살았어~~~~~~ 접속해~~~"
"나 물약1개 먹을께"
"OK 물약이제 4개 남았어"
" 수고했어 안녕~~~"
-- disconnection
-------------10번 데이터를 주고받았습니다.
이는 클라이언트 1대의 경우 7번과 10번이 나옵니다
이를 10000대의 클라이언트라고 생각하면 답은 나옵니다..
2티어에서는 connection방식이든 connectionless 방식이든
connection 연결된 수는 10000개가 생길수 밖에 없으니깐요~
--------------------------------------------------------------------------------------------------
제 의미 전달이 잘못된 듯하네요.
위의 오라클은 transaction comit 단위가 session 이라 어쩔 수 없다지만,
mssql 경우 이미 커넥션 풀을 지원해 주고 있기 때문이란 뜻이에요.
connection string 을 기준으로, 커넥션 풀을 관리한다고 알고 있는데;;
--------------------------------------------------------------------------------------------------
2tear의 경우 client에서 바로 DB connetion을 할 것입니다.
문제는 이 connection을 dispose을 하더라도 DB서버와 클라이언트는 항상 connetion을 하나를 물고있습니다.
즉, 클라이언트의 수가 늘어날수록 DB서버의 connection수는 증가한다고 생각하시면될 것입니다.
실제로 간단한 테이블 만들어서 클라이언트에서 그 테이블의 자료을 처음에 가지고오고 dispose()를 하면...
보통
using(DBconnection)
{
}
이렇게 사용하시겠죠?
DB에서는 그 테이블이 포함된 DB가 삭제가 안될것입니다. 프로그램 종료전까지 말입니다.
3tear의 경우 실제 DB와 connection부분이 서버에서 이루어지기 때문에 DB는 단지 해당 서버와 connection을
물고 있으면 되는 것입니다.
--------------------------------------------------------------------------------------------------
또 답변을 달게 되는군요 -_-
생각하길 커넥션을 여는 만큼 커넥션이 열린다고 생각하기 쉽지만,
그것인 닷넷개체이든 DBMS 내부적이든 커넥션 풀을 관리하고 있습니다.
내가 커넥션을 연다고 열리는 것이 아니라, 이 내부적인 커넥션 풀이 모든 것을 관리하지요..
실제로 커넥션을 닫아도, 일정 시간 커넥션은 열려있게 되고, 이것또한 커넥션 풀이 관리를 하지요..
무한적 늘어나날 수 있는 커넥션을, 풀로 관리를 한다는 겁니다.
여기서 제가 오라클 얘길 했는데,
오라클은 트랜잭션의 커밋을 위해 세션 단위로 커밋을 하기 됩니다.
즉, 2tier 라면 반드시, 1인 1커넥션이 있어야 트랜잭션 스콥에 포함이 됩니다.
사용하는 디비가 오라클이라면 1클라이언트 : 1커넥션이 성립이 되지만,,
MSSQL 이라면 반드시 그렇지 않다라는 거죠 -_-;;
이해 되셨는지 ...
--------------------------------------------------------------------------------------------------
SQL DB가 connection 풀을 지원하지만 확실히 2tear 와 3tear에서의 차이는 있습니다.
전 그점을 이야기 하고 싶었던 겁니다.
2tear에서 클라이언트에 직접 connection을 열면 각 클라이언트마다 SQL DB에서 각각의 프로세서 ID를 부여 하고
있다는 것을 확인 하실수 있을 겁니다.
다른 예로 한 클라이언트에서 같은 connection string으로 여러개의 동일프그램을 실행 시켜 확인해보면
각각의 프로세서 ID을 부여하고 있고 close() or dispose()을 하여도 여전히 서로 물고 있다가 일정시간 더이상
작업이 없으면 프로세서를 해당 프로세서를 해제합니다.
하지만 3tear의 경우 클라이언트가 아닌 서버에서 DB와 connection을 연결하기 때문에 이와 같이 행동하지 앖습니다.
결론은 2tear 와 3tear에서 physical tear상황마다 틀리지만 logical tear로는 3tear로 가는것이 맞다는 것이
저의 의견입니다.
물론 이외도 보완상이라던지 관리 및 scalability등도 3tear의 장점이죠 ^^
--------------------------------------------------------------------------------------------------
하하하.. 그렇군요.
하지만 요즘은 3-tier 로 많이 구축이 되긴 하지만, 일부에서는 3~4 tier 가 아닌,,
터미널이나 콘솔형태의 서버를 많이 구축 하기도 한답니다.
바로, 서버의 비용적인 측면도 있겠지만, 분산 시스템에서 유지/보수가 과거의 터미널이나 콘솔 형태보다
몇 배 많이 들어가게 된다는 점입니다.
그리고, 클라이언트에게 권한을 할당하는 방식이 아닌, 서버가 모든 권한을 가짐으로써 보안 문제에도 예전 터미널 방식이 훨씬 유리하겠죠.
당연히 3-tier 로 가야 한다는 발상은 요즘 시대에 조금 위험한 듯 합니다^^
어찌되었건 제가 하고 싶었던 얘기는 커넥션에 대한 얘기인데, 약간 본질이 흐려진 것 같네요.
출처 : http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=18&MAEULNO=8&no=1582&page=3
