안 쓰던 블로그

2, 3 Tier Architecture 발표 정리 본문

Network

2, 3 Tier Architecture 발표 정리

proqk 2017. 3. 14. 11:23
반응형

[2계층 구조2-tier architecture]

클라이언트-서버. 2개로 나눠짐

 

>설명

클라이언트와 서버같이 2개의 노드로 구성된 구조

2계층 구조에서는 서버는 데이터 저장 역할만 하고 클라이언트가 일함

 

>인터넷 기반 2계층 서비스

초기 인터넷 서비스가 2계층이었음(HTML 문서 전송 같은 단순한거)

 

>동작 방식

1. 서버에서 클라이언트 요청을 처리하는 프로세스 실행 (데몬)

2. 클라이언트에 서버 프로세스랑 통신하는 프로그램 설치 (파일질라 아웃룩)

3. 보통 TCP/IP 네트워크로 통신하고 전용 프로토콜로 데이터 송수신 (FTP, SMTP, POP3)

 

>인트라넷 2계층 구조

조직 내의 컴퓨터들 연결한 내부 네트워크

초기 2계층 구조에서 클라이언트는 데이터베이스 서버랑 직접 통신

오라클, 인포믹스, 사이베이스, MS-SQL

 

[N계층 구조N-tier architecture]

2계층 구조의 한계를 극복하기 위해 3개 이상의 노드를 네트워크 상에서 구성함

N계층이 2계층을 완전히 대체하는게 아니라서 FTP나 텔넷은 아직도 2계층임

 

[3계층 구조]

세 개로 나눠짐

1. 정보 계층: 데이터 계층(최하위 계층)

데이터 관리

 

2. 중간 계층: 어플리케이션 계층

비즈니스 로직(백엔드)과 프리젠테이션 로직(프론트엔드)을 구현

클라이언트-데이터 간 상호작용 제어

 

3. 클라이언트 계층: 최상위 계층

사용자 인터페이스 역할

중간 계층과 상호작용으로 요청 전달하고 데이터 조회

 

>2계층 구조의 한계와 대안

클라이언트의 성능 향상으로 다양한 처리를 할 수 있는데 데이터의 무결성을 관리하기 어려움

비즈니스 로직(백엔드)을 두기 어려움->서버가 데이터 저장밖에 안하니까 클라이언트끼리 직접 통신함

데이터 증가, 조직 거대화, 업무 복잡성 증가하면 클라이언트가 감당 못함

 

1차 대안.

비즈니스 처리를 전담하는 함수를 전부 DB서버 내에 포함해서 DB서버가 자료 보관 및 계산 전부 담당하게 만든다->서버 하드웨어 용량 증설의 물리적 한계

 

2차 대안.

클라이언트-데이터베이스 사이에 어플리케이션 서버를 설치함

추가 비용이 증가하지만 서버의 병목 현상이나 DB서버의 과부화 해결

 

[2계층vs3계층]

2계층: 클라이언트가 사용자 인터페이스와 데이터 가공, 편집 계산 등 비즈니스 처리 담당

3계층: 클라이언트는 사용자 인터페이스만 처리

 

2계층: 클라이언트가 직접 데이터베이스에 쿼리 전송

3계층: 어플리케이션 서버가 쿼리 요청, 쿼리 결과를 이용해 데이터 조작

 

2계층: 모든 클라이언트는 항상 데이터베이스랑 연결되기 때문에 클라이언트 수를 늘리는데 한계

3계층: 어플리케이션 서버가 데이터베이스 쿼리 수행하기 때문에 데이터베이스 쪽에서는 연결 수가 줄어들어 효율적인 운용 가능

반응형
Comments