DAY 4 - NETWORK2(3-Tier Architecture)
3- Tier Architecture
3 Tier Architecture란 Presentation Layer와 Business Logic Layer, Data Access Layer의 각각 Layer 들을 3개의 Tier로 각각 분리 시켜 둔 것을 의미한다.
Layer 란 논리적인 구분인 것이고, Tier는 물리적인 구분이다.
Presentation Layer는 웹 브라우저, 데스크탑 어플리케이션 같은 것으로, 웹 Presentation layer에 사용되는 언어는 HTML과 CSS, Javascript라고 보면 된다.
Business logic Layer는 Prestation layer에서 입력된 데이터를 처리하는 layer이다. 웹으로 보면 Python, Java, PHP 같은 언어가 이 Layer에 해당되는 언어이다.
Data Access Layer의 경우, 데이터가 저장 및 관리되는 Layer이다. 언어로는 RDBMS로 MySQL, Oracle, PostgreSQL 등이 있고, NoSQL로 MongoDB, Cassandra, CouchDB등이 있다.
1 Tier Architecture의 경우, 한 장비에 3개의 Layer가 존재하는 것이고,
2Tier Architecture는 Client Tier와 Data Tier로 나뉘어 Client Tier에는 Presentation Layer와 Business Logic Layer가, Data Tier에는 Data Acees layer와 DB가 위치한다.
3 Tier Architecture의 경우 Client Tier에는 Presentation Layer가, Application Tier에는 Business Logic layer가, Data Tier에는 Data Access Layer가 위치한다.
Tier로 Layer로 나누면, Tier로 덜 나눈 만큼 개발이 불편해지지만(Tier간 접근 로직 추가 필요), 각 티어의 재사용이 보다 편리하여 재사용 측면에서 좋고, 성능적으로 더 뛰어나고, 컴퓨팅 자원 활용도 효율적으로 사용이 가능하며, 유지보수도 용이하다. 또한 확장에도 3Tier가 유리하다. 2 Tier 일 때, Scale out을 진행하게 되면, 중복된 DB가 있는 장비가 추가되는 것이고, 두 장비간 동일한 DB를 유지하기 위해 동기화 작업이 계속적으로 이뤄져야 한다. 3 Tier로 나누면 Application tier에서 부하를 조절하면서 Data Tier 접근하는 좀 더 효율적인 아키텍처를 구성 할 수 있다.
성능의 문제로 서버가 늘어나야 될 수도 있다. 이때 2 tier라면 각 서버에 DB가 있어야하는데,,,
서버가 늘어나면 늘어날 수록, DB가 중복적으로 필요한 단점도 있고, 이 중복적인 DB들이 서로 동일해야 된다는 점도 문제가 된다. 그래서 DB를 하나의 tier로 따로 분리해서 섭근하게 된다면, 하나의 DB 서버로만 충분하고, 중복으로 인한 자원 낭비, 일치시키기 위한 노력 등이 없어지게 된다.
그렇다고, 3 Tier보다 많이 나누는 것은 긍정적인 효과를 더 기대하기 어렵고, 오히려 성능 저하 및 더 많은 비용을 초래하기 때문에 3 Tier가 최대로 많은 Tier로 봐도 무방하다.
3 Tier로 봤을때,
Client Tier는 FrontEnd, Application Tier는 Middleware 혹은 BackEnd, Data Tier는 BackEnd로 구분 지을 수 있다.