2025. 1. 20. 09:09ㆍNetwork 공부
3계층 아키텍처는 애플리케이션을 3개의 독립적인 계층으로 나우어 설계하는 소프트웨어 아키텍처 패턴이다.
각 계층의 역할을 명확히 분리되어 있고, 우리가 대표적으로아는 Frontend, Backend 등이 여기에 포함된다.
1.Presentation Layer (프레젠테이션 계층):
- Frontend가 포함됩니다.
- 사용자가 상호작용하는 인터페이스(UI)를 담당하며, HTML, CSS, JavaScript 등을 사용합니다.
예: 웹 브라우저, 모바일 앱 UI.
2. Application Layer (애플리케이션 계층):
- Backend가 포함됩니다.
- 비즈니스 로직, 데이터 처리, API 제공 등을 담당합니다.
- 서버에서 실행되며, 다양한 프로그래밍 언어(예: Python, Java, Node.js)와 프레임워크를 사용합니다.
비즈니스 로직이 구현된 Layer 로 애플리케이션의 핵심적인 처리 부분을 담당한다.
데이터를 처리하거나 규칙을 적용하며, Presentaiton Layer 와 Data Layer 사이에서 데이터를 주고 받은 중간 역할을 한다.
ex) 주문 처리 로직, 결제 계산, WorkFlow 제어 등
https://idery-123.tistory.com/28
Business Logic / 데이터 처리 / API 제공
소프트웨어나 애플리케이션에서 특정 비즈니스 도멘인의 규칙과 요구사항을 구현한 부분을 의미한다.이는 비즈니스의 목적과 프로세스를 기반으로 데이터를 처리하고 의사결정을 내리는 논리
idery-123.tistory.com
3.Data Layer (데이터 계층):
- Database(DB)가 포함됩니다.
- 데이터를 저장하고 관리하며, SQL이나 NoSQL 데이터베이스를 사용합니다.
- 데이터베이스에 데이터를 저장하거나, 조회, 수정 그리고 삭제와 같은 작업을 수행한다.
예: MySQL, PostgreSQL, MongoDB.
**** 3 - tier Architecture 의 특징 및 활용하는 이유 *****
- 역할 분리
각 계층이 독립적으로 역할을 수행하므로 유지보수와 확장이 용이하다.
ex) 파트를 나누어서 먼저 Frontend 에서 구현한 후 Backend 에서 API 를 연결하는 등 역할 분리
- 독립적인 개발
역할 분리와 동일하게 파트를 나누어서 서로 독립적으로 동시에 개발할 수 있어 협업에 효율적인
- 확장성 및 유연성
특정 계층만 확장(스케일 업 또는 스케일 아웃) 할 수 있다.
ex) 트래픽 증가 시 프레젠테이션 계층만 확장
시스템의 한 계층을 다른 기술로 교체하거나 업그레이드 하기 쉬움
- 보안 강화
각 계층이 서로 분리되어 있어 데이터 보호 및 접근 제어가 더 쉽다.
- 표준화된 통신
각 계층은 HTTP, API 등을 통해 명확히 정의된 방식으로 통신하니 유지 보수에 용이함.
3-tier architecture와 관련된 다른 패턴
MVC(Model-View-Controller)
3 tier architecture와 유사하게 역할을 나누지만, 주로 애플리케이션 계층 내부에서의 설계 패턴입니다.
소프트웨어 디자인 패턴으로 애플리케이션을 세 가지 주요 컴포넌트 ( Model , View, Controller) 로 나누어 설계한다.
주로 UI 중심 애플리케이션 개발에서 사용된다.
이 패턴은 역할 분리를 통해 코드의 유지보수성과 확장성 을 높이는 것을 목적으로 한다.
- 구성 요소
Model
데이터 및 비즈니스 로직 처리
데이터베이스와의 상호작용, 데이터 상태 관리, 애플리케이션의 핵심 로직을 포함
역할:
데이터 저장 및 관리
데이터 처리 후 View 와 Controller 에게 제공
View
UI 담당
Model 에서 제공받은 데이터를 표시하고 사용자의 입력을 컨트롤러로 전달한다
역할:
데이터를 시각적으로 표현
사용자의 입력 인터페이스 제공
Controller
사용자 입력을 처리하고 Model 및 View 와 상호작용한다.
사용자의 요청을 Model 에 전달하고 결과를 View 에 반영함
역할:
사용자 요청(입력) 을 처리
Model 과 View 간의 중재 역할
MVC 동작 과정
1) 사용자가 UI(View)에서 입력(예: 버튼 클릭, 폼 제출)을 합니다.
2) Controller가 입력 이벤트를 처리하고 Model에 데이터를 요청하거나 명령을 전달합니다.
3) Model은 데이터를 처리한 후 결과를 반환합니다.
4) View는 Model에서 제공받은 데이터를 기반으로 UI를 업데이트합니다.
N - tier Architecture
소프트웨어를 다수의 Layer 으로 나누어 설계하는 아키텍쳐 패턴
3 tier architecture 가 가장일반적인 형태이다.
N-tier의 구성 요소
- Presentation Tier (프레젠테이션 계층):
사용자 인터페이스(UI)를 제공하며, 주로 Frontend가 위치.
예: HTML, CSS, JavaScript, 모바일 앱 UI.
- Application Tier (애플리케이션 계층):
비즈니스 로직과 데이터 처리를 담당하며, 주로 Backend가 위치.
API를 통해 Presentation Tier와 통신.
예: Python, Java, Node.js 기반 서버.
- Data Tier (데이터 계층):
데이터베이스와의 상호작용을 담당.
데이터를 저장, 검색, 관리하며, SQL이나 NoSQL 데이터베이스를 사용.
예: MySQL, PostgreSQL, MongoDB.
N-tier는 기본적으로 3계층으로 시작하며, 필요에 따라 더 많은 계층을 추가할 수 있습니다.
예: Service Layer, Integration Layer 등을 추가.
특징
- 각 계층은 독립적으로 설계되어야 하고, 다른 계층과는 정의된 인터페이스를 통해 통신한다
ex) 프로토콜, api 등등
- 한 계층의 변경이 다른 계층에 영향을 최소화한다.
장단점
장점:
확장성: 특정 계층만 확장(스케일 업/스케일 아웃) 가능.
보안: 각 계층에 별도의 보안 조치를 적용할 수 있음.
유지보수성: 계층 간 역할이 명확히 분리되어 코드 관리가 쉬움.
재사용성: 계층별로 독립적인 기능을 설계하면 재사용 가능.
단점:
시스템이 복잡해질수록 설계 및 구현 비용 증가.
계층 간 통신 오버헤드로 인해 성능 저하 가능.
잘못된 설계 시 병목현상이 발생할 수 있음.
위 세 가지는 모두 소프트웨어 구조화 및 설계에 대한 패턴이다.
다만, 각각의 적용 범위, 초점 그리고 구조적 차이에 있어서 뚜렷한 차이가 있다.
아래 그림과 같이 MVC 는 UI 에 집중하기 위해서 모든 계층이
Presentation Layer 에 속한다는 것을 알 수 있다.
그리고 나머지 둘은 애플리케이션 전체 아키텍쳐에 대한 아키텍쳐이다.
- 클라우드에서의 N - tier Architecture
클라우드 환경에서는 물리적인 인프라보다 더 많은 유연성과 확장성을 제공하기 때문에
N - Tier 아키텍쳐 설계가 중요하며, 이때 클라우드의 특성이 고려되어야 함.
각 계층의 클라우드 관점
1) Presentation Tier( ex: Frontend)
사용자 인터페이스를 제공하는 계층
AWS : AWS S3, CloudFront(정적 파일 제공), Elastic Load Balancer(ELB)
+ CDN(Content Delivery Network) 를 활용해 글로벌 사용자에게 빠른 응답 시간 제공
+ 서브리스 옵션(AWS Lambda) 로 Frontend 처리
2) Application Tier (ex: Backend)
비즈니스 로직을 처리하는 계층
AWS: EC2 (인스턴스), Lambda (서버리스), ECS/EKS (컨테이너)
+서버리스와 컨테이너 기반의 확장 가능성
+ Auto Scaling 같은 클라우드의 동적 확장 / 축소 기능
3) Data Tier (ex: Database)
데이터를 저장하고 관리하는 계층
AWS: RDS, DynamoDB (NoSQL), Aurora
+ 클라우드 관리형 데이터베이스의 성능과 가용성
+ 읽기 / 쓰기 분리, 데이터 복제, 분산형 데이터 베이스 설계플리케이션을 3개의 독립적인 계층으로 나우어 설계하는 소프트웨어 아키텍처 패턴이다.
각 계층의 역할을 명확히 분리되어 있고, 우리가 대표적으로아는 Frontend, Backend 등이 여기에 포함된다.
1.Presentation Layer (프레젠테이션 계층):
- Frontend가 포함됩니다.
- 사용자가 상호작용하는 인터페이스(UI)를 담당하며, HTML, CSS, JavaScript 등을 사용합니다.
예: 웹 브라우저, 모바일 앱 UI.
2. Application Layer (애플리케이션 계층):
- Backend가 포함됩니다.
- 비즈니스 로직, 데이터 처리, API 제공 등을 담당합니다.
- 서버에서 실행되며, 다양한 프로그래밍 언어(예: Python, Java, Node.js)와 프레임워크를 사용합니다.
3.Data Layer (데이터 계층):
- Database(DB)가 포함됩니다.
- 데이터를 저장하고 관리하며, SQL이나 NoSQL 데이터베이스를 사용합니다.
예: MySQL, PostgreSQL, MongoDB.
**** 3 - tier Architecture 의 특징 및 활용하는 이유 *****
- 역할 분리
각 계층이 독립적으로 역할을 수행하므로 유지보수와 확장이 용이하다.
ex) 파트를 나누어서 먼저 Frontend 에서 구현한 후 Backend 에서 API 를 연결하는 등 역할 분리
- 독립적인 개발
역할 분리와 동일하게 파트를 나누어서 서로 독립적으로 동시에 개발할 수 있어 협업에 효율적인
- 확장성 및 유연성
특정 계층만 확장(스케일 업 또는 스케일 아웃) 할 수 있다.
ex) 트래픽 증가 시 프레젠테이션 계층만 확장
시스템의 한 계층을 다른 기술로 교체하거나 업그레이드 하기 쉬움
- 보안 강화
각 계층이 서로 분리되어 있어 데이터 보호 및 접근 제어가 더 쉽다.
- 표준화된 통신
각 계층은 HTTP, API 등을 통해 명확히 정의된 방식으로 통신하니 유지 보수에 용이함.
3-tier architecture와 관련된 다른 패턴
MVC(Model-View-Controller)
3 tier architecture와 유사하게 역할을 나누지만, 주로 애플리케이션 계층 내부에서의 설계 패턴입니다.
소프트웨어 디자인 패턴으로 애플리케이션을 세 가지 주요 컴포넌트 ( Model , View, Controller) 로 나누어 설계한다.
주로 UI 중심 애플리케이션 개발에서 사용된다.
이 패턴은 역할 분리를 통해 코드의 유지보수성과 확장성 을 높이는 것을 목적으로 한다.
- 구성 요소
Model
데이터 및 비즈니스 로직 처리
데이터베이스와의 상호작용, 데이터 상태 관리, 애플리케이션의 핵심 로직을 포함
역할:
데이터 저장 및 관리
데이터 처리 후 View 와 Controller 에게 제공
View
UI 담당
Model 에서 제공받은 데이터를 표시하고 사용자의 입력을 컨트롤러로 전달한다
역할:
데이터를 시각적으로 표현
사용자의 입력 인터페이스 제공
Controller
사용자 입력을 처리하고 Model 및 View 와 상호작용한다.
사용자의 요청을 Model 에 전달하고 결과를 View 에 반영함
역할:
사용자 요청(입력) 을 처리
Model 과 View 간의 중재 역할
MVC 동작 과정
1) 사용자가 UI(View)에서 입력(예: 버튼 클릭, 폼 제출)을 합니다.
2) Controller가 입력 이벤트를 처리하고 Model에 데이터를 요청하거나 명령을 전달합니다.
3) Model은 데이터를 처리한 후 결과를 반환합니다.
4) View는 Model에서 제공받은 데이터를 기반으로 UI를 업데이트합니다.
N - tier Architecture
소프트웨어를 다수의 Layer 으로 나누어 설계하는 아키텍쳐 패턴
3 tier architecture 가 가장일반적인 형태이다.
N-tier의 구성 요소
- Presentation Tier (프레젠테이션 계층):
사용자 인터페이스(UI)를 제공하며, 주로 Frontend가 위치.
예: HTML, CSS, JavaScript, 모바일 앱 UI.
- Application Tier (애플리케이션 계층):
비즈니스 로직과 데이터 처리를 담당하며, 주로 Backend가 위치.
API를 통해 Presentation Tier와 통신.
예: Python, Java, Node.js 기반 서버.
- Data Tier (데이터 계층):
데이터베이스와의 상호작용을 담당.
데이터를 저장, 검색, 관리하며, SQL이나 NoSQL 데이터베이스를 사용.
예: MySQL, PostgreSQL, MongoDB.
N-tier는 기본적으로 3계층으로 시작하며, 필요에 따라 더 많은 계층을 추가할 수 있습니다.
예: Service Layer, Integration Layer 등을 추가.
특징
- 각 계층은 독립적으로 설계되어야 하고, 다른 계층과는 정의된 인터페이스를 통해 통신한다
ex) 프로토콜, api 등등
- 한 계층의 변경이 다른 계층에 영향을 최소화한다.
장단점
장점:
확장성: 특정 계층만 확장(스케일 업/스케일 아웃) 가능.
보안: 각 계층에 별도의 보안 조치를 적용할 수 있음.
유지보수성: 계층 간 역할이 명확히 분리되어 코드 관리가 쉬움.
재사용성: 계층별로 독립적인 기능을 설계하면 재사용 가능.
단점:
시스템이 복잡해질수록 설계 및 구현 비용 증가.
계층 간 통신 오버헤드로 인해 성능 저하 가능.
잘못된 설계 시 병목현상이 발생할 수 있음.
위 세 가지는 모두 소프트웨어 구조화 및 설계에 대한 패턴이다.
다만, 각각의 적용 범위, 초점 그리고 구조적 차이에 있어서 뚜렷한 차이가 있다.
아래 그림과 같이 MVC 는 UI 에 집중하기 위해서 모든 계층이
Presentation Layer 에 속한다는 것을 알 수 있다.
그리고 나머지 둘은 애플리케이션 전체 아키텍쳐에 대한 아키텍쳐이다.
- 클라우드에서의 N - tier Architecture
클라우드 환경에서는 물리적인 인프라보다 더 많은 유연성과 확장성을 제공하기 때문에
N - Tier 아키텍쳐 설계가 중요하며, 이때 클라우드의 특성이 고려되어야 함.
클라우드에서 N - Tier 아키텍처를 설계하고 운영하려면, 확장성, 고가용성, 보안, 비용 최적화와 같은 클라우드 고유 특성을 활용할 수 있어야 한다, 그리고 이에 바탕으로 네트워크 설계, 서버리스 아키텍처 그리고 관찰 가능성 등의 능력이 필요하다.
** 각 계층의 클라우드 관점
1) Presentation Tier( ex: Frontend)
사용자 인터페이스를 제공하는 계층
AWS : AWS S3, CloudFront(정적 파일 제공), Elastic Load Balancer(ELB)
+ CDN(Content Delivery Network) 를 활용해 글로벌 사용자에게 빠른 응답 시간 제공
+ 서브리스 옵션(AWS Lambda) 로 Frontend 처리
2) Application Tier (ex: Backend)
비즈니스 로직을 처리하는 계층
AWS: EC2 (인스턴스), Lambda (서버리스), ECS/EKS (컨테이너)
+서버리스와 컨테이너 기반의 확장 가능성
+ Auto Scaling 같은 클라우드의 동적 확장 / 축소 기능
3) Data Tier (ex: Database)
데이터를 저장하고 관리하는 계층
AWS: RDS, DynamoDB (NoSQL), Aurora
+ 클라우드 관리형 데이터베이스의 성능과 가용성
+ 읽기 / 쓰기 분리, 데이터 복제, 분산형 데이터 베이스 설계
4) Integration Tier , 통합계층 (Optional)
API Gateway 및 Messaging Service 를 통한 계층 간의 통합
AWS: API Gateway, EventBridge, SQS/SNS.
+ 비동기 처리와 Messaging Queue 의 활용
+ API 글로벌 베포와 성능 최적화
5) 기타 추가적인 개념
- 클라우드 네트워크 설계
VPC( Virtual Private Cloud)
AWS: VPC, Subnets, Internet Gateway, Nat Gateway
+ Public / Private Subnet 구분
+ 보안 그룹과 방화벽 규칙
+ VPC 피어링, Transit Gateway를 통한 네트워크 연결
- 고가용성과 확장성
로드 밸런싱 : AWS ELB
Auto Scaling: AWS Auto Scaling Groups
- 보안
AWS IAM
AWS Security Groups
+ 데이터 암호화
저장 중 암호화: KMS (Key Management Service ) 사용
전송 중 암호화: TLS / SSL 설정
- 클라우드 Native 기술
컨테이너와 오케스트레이션 : Kubernetes & Docker
서버리스 컨테이너( AWS Fargate)
- 관찰 가능성 (Observability)
클라우드에서는 애플리케이션 및 인프라 상태를 모니터링 하는 것이 필수적이다.
로그 수집 및 분석
AWS CloudWatch
분산 추적
AWS X - Ray
알림 및 이벤트
AWS SNS
- 비용 최적화
클라우드 사용량은 Pay as you go 방식이므로 비용 관리가 중요하다
비용 관리 도구
AWS Cost Explorer
예약 인스턴스, 스팟 인스턴스 등
'Network 공부' 카테고리의 다른 글
| Business Logic / Data Processing / Providing APIs (0) | 2025.01.28 |
|---|---|
| RAID ( Redundant Array of Inexpensive (Independent) Disk ) (0) | 2025.01.24 |
| FTP(File Transfer Protocol) / TFTP(Trivial File Transfer Protocol) / PXE(Perboot execution Environment) (0) | 2025.01.22 |
| NFS(Network File System) (0) | 2025.01.21 |
| Microservice Architecture (Service) (0) | 2025.01.21 |