24. 3-Tier 아키텍처

[개념]

• 개요
  정의: 애플리케이션을 3개의 논리 계층으로 나눈 아키텍처
  목적: 역할 분리, 유지보수 용이성, 보안성, 확장성 확보
  
  
• 각 계층 설명
  - Presentation Layer (프레젠테이션 계층)
     기능: 사용자 인터페이스(UI), 사용자 입력 처리
     기술 스택
      ㅇ클라이언트: HTML, CSS, JavaScript
      ㅇ서버: Nginx, Apache (웹서버)
     역할: 사용자의 요청을 Application Layer로 전달- Data Layer(Database) (데이터 계층)
     기능: 데이터 저장, 검색, 갱신, 삭제
     기술 스택
      ㅇ관계형 DB: Oracle, MySQL, PostgreSQL
      ㅇNoSQL: MongoDB, Redis 등
     역할: 영속적인 데이터 관리
  
  
• - Application Layer (애플리케이션 계층)
     기능: 비즈니스 로직 처리, 데이터 가공, 인증/권한 처리 등
     기술 스택
      ㅇJava (Spring, JEE), Python (Django), Node.js, .NET 등
      ㅇ서버: Tomcat, JBoss, WebLogic (WAS)
     역할: Presentation과 Data Layer 사이의 중개자
• Tier를 구분하는 기준?
  전체 서비스에서 역할(Role)을 기준으로 구분
  1-tier = 메인프레임 내 분리되지 못한 상태로 구성 → 개발 및 유지보수 어려움
  
  
  2-tier (Fat Client) = 클라이언트에 모든 로직 구성(브라우저 외 프로그램 설치 등), 서버엔 DB만 구성 → 프로그램 배포 어려움
  
  2-tier (Fat Server) = 내용 출력만을 담당하는 로직(브라우저), 서버에 business logic/DB 구성 → 많은 서버자원 요구 
  
  3-tier = 내용 출력 로직 - business logic 서버(미들웨어) - DB 구성 → 부하분산, 서비스 layer 분리에 따라 효율적 scale-in/out 설계 가능
  
  
  n-tier = 대규모 서비스 구성시 layer 추가 (예. KOS의 NEXA-ESB-PO-DB)
  
  미들웨어가 역할에 따라 WEB/WAS로 나뉘어지며 WEB을 Presentation으로 보아 WEB/WAS/DB를 3-tier로 칭하기도 함 
  
  
• WEB/WAS 분리 이유
  보안 : 외부 노출 계층(WEB)과 내부 로직(WAS)를 분리 (외부망 구축 필요시)
  로드 밸런싱 : WEB 계층 요청을 여러 WAS로 분산 가능
  확장성 : 각 계층의 수평확장 가능
  
  

 

• L4 스위치 이용하여 웹서버 이중화 및 부하분산
• 세션 클러스터링 적용 Redis?
• 와스서버 이중화
• DB 서버 이중화 (A-A) → 오라클 RAC 구성,
   → Shared Disk 구성
• 구성요소 (컴포넌트 이중화)
• 서버 nic.이중화
• (WIN)teaming/(LINUX)bonding 구성
• 서버 및 스토리지 HBA

[개념]

• 개요
  정의: 애플리케이션을 3개의 논리 계층으로 나눈 아키텍처
  목적: 역할 분리, 유지보수 용이성, 보안성, 확장성 확보
  
  
• 각 계층 설명
  - Presentation Layer (프레젠테이션 계층)
     기능: 사용자 인터페이스(UI), 사용자 입력 처리
     기술 스택
      ㅇ클라이언트: HTML, CSS, JavaScript
      ㅇ서버: Nginx, Apache (웹서버)
     역할: 사용자의 요청을 Application Layer로 전달- Data Layer(Database) (데이터 계층)
     기능: 데이터 저장, 검색, 갱신, 삭제
     기술 스택
      ㅇ관계형 DB: Oracle, MySQL, PostgreSQL
      ㅇNoSQL: MongoDB, Redis 등
     역할: 영속적인 데이터 관리
  
  
• - Application Layer (애플리케이션 계층)
     기능: 비즈니스 로직 처리, 데이터 가공, 인증/권한 처리 등
     기술 스택
      ㅇJava (Spring, JEE), Python (Django), Node.js, .NET 등
      ㅇ서버: Tomcat, JBoss, WebLogic (WAS)
     역할: Presentation과 Data Layer 사이의 중개자
• Tier를 구분하는 기준?
  전체 서비스에서 역할(Role)을 기준으로 구분
  1-tier = 메인프레임 내 분리되지 못한 상태로 구성 → 개발 및 유지보수 어려움
  
  
  2-tier (Fat Client) = 클라이언트에 모든 로직 구성(브라우저 외 프로그램 설치 등), 서버엔 DB만 구성 → 프로그램 배포 어려움
  
  2-tier (Fat Server) = 내용 출력만을 담당하는 로직(브라우저), 서버에 business logic/DB 구성 → 많은 서버자원 요구 
  
  3-tier = 내용 출력 로직 - business logic 서버(미들웨어) - DB 구성 → 부하분산, 서비스 layer 분리에 따라 효율적 scale-in/out 설계 가능
  
  
  n-tier = 대규모 서비스 구성시 layer 추가 (예. KOS의 NEXA-ESB-PO-DB)
  
  미들웨어가 역할에 따라 WEB/WAS로 나뉘어지며 WEB을 Presentation으로 보아 WEB/WAS/DB를 3-tier로 칭하기도 함 
  
  
• WEB/WAS 분리 이유
  보안 : 외부 노출 계층(WEB)과 내부 로직(WAS)를 분리 (외부망 구축 필요시)
  로드 밸런싱 : WEB 계층 요청을 여러 WAS로 분산 가능
  확장성 : 각 계층의 수평확장 가능
  
  

 

• L4 스위치 이용하여 웹서버 이중화 및 부하분산
• 세션 클러스터링 적용 Redis?
• 와스서버 이중화
• DB 서버 이중화 (A-A) → 오라클 RAC 구성,
   → Shared Disk 구성
• 구성요소 (컴포넌트 이중화)
• 서버 nic.이중화
• (WIN)teaming/(LINUX)bonding 구성
• 서버 및 스토리지 HBA

[개념]

• 개요
  정의: 애플리케이션을 3개의 논리 계층으로 나눈 아키텍처
  목적: 역할 분리, 유지보수 용이성, 보안성, 확장성 확보
  
  
• 각 계층 설명
  - Presentation Layer (프레젠테이션 계층)
     기능: 사용자 인터페이스(UI), 사용자 입력 처리
     기술 스택
      ㅇ클라이언트: HTML, CSS, JavaScript
      ㅇ서버: Nginx, Apache (웹서버)
     역할: 사용자의 요청을 Application Layer로 전달- Data Layer(Database) (데이터 계층)
     기능: 데이터 저장, 검색, 갱신, 삭제
     기술 스택
      ㅇ관계형 DB: Oracle, MySQL, PostgreSQL
      ㅇNoSQL: MongoDB, Redis 등
     역할: 영속적인 데이터 관리
  
  
• - Application Layer (애플리케이션 계층)
     기능: 비즈니스 로직 처리, 데이터 가공, 인증/권한 처리 등
     기술 스택
      ㅇJava (Spring, JEE), Python (Django), Node.js, .NET 등
      ㅇ서버: Tomcat, JBoss, WebLogic (WAS)
     역할: Presentation과 Data Layer 사이의 중개자
• Tier를 구분하는 기준?
  전체 서비스에서 역할(Role)을 기준으로 구분
  1-tier = 메인프레임 내 분리되지 못한 상태로 구성 → 개발 및 유지보수 어려움
  
  
  2-tier (Fat Client) = 클라이언트에 모든 로직 구성(브라우저 외 프로그램 설치 등), 서버엔 DB만 구성 → 프로그램 배포 어려움
  
  2-tier (Fat Server) = 내용 출력만을 담당하는 로직(브라우저), 서버에 business logic/DB 구성 → 많은 서버자원 요구 
  
  3-tier = 내용 출력 로직 - business logic 서버(미들웨어) - DB 구성 → 부하분산, 서비스 layer 분리에 따라 효율적 scale-in/out 설계 가능
  
  
  n-tier = 대규모 서비스 구성시 layer 추가 (예. KOS의 NEXA-ESB-PO-DB)
  
  미들웨어가 역할에 따라 WEB/WAS로 나뉘어지며 WEB을 Presentation으로 보아 WEB/WAS/DB를 3-tier로 칭하기도 함 
  
  
• WEB/WAS 분리 이유
  보안 : 외부 노출 계층(WEB)과 내부 로직(WAS)를 분리 (외부망 구축 필요시)
  로드 밸런싱 : WEB 계층 요청을 여러 WAS로 분산 가능
  확장성 : 각 계층의 수평확장 가능
  
  

 

• L4 스위치 이용하여 웹서버 이중화 및 부하분산
• 세션 클러스터링 적용 Redis?
• 와스서버 이중화
• DB 서버 이중화 (A-A) → 오라클 RAC 구성,
   → Shared Disk 구성
• 구성요소 (컴포넌트 이중화)
• 서버 nic.이중화
• (WIN)teaming/(LINUX)bonding 구성
• 서버 및 스토리지 HBA

[개념]

• 개요
  정의: 애플리케이션을 3개의 논리 계층으로 나눈 아키텍처
  목적: 역할 분리, 유지보수 용이성, 보안성, 확장성 확보
  
  
• 각 계층 설명
  - Presentation Layer (프레젠테이션 계층)
     기능: 사용자 인터페이스(UI), 사용자 입력 처리
     기술 스택
      ㅇ클라이언트: HTML, CSS, JavaScript
      ㅇ서버: Nginx, Apache (웹서버)
     역할: 사용자의 요청을 Application Layer로 전달- Data Layer(Database) (데이터 계층)
     기능: 데이터 저장, 검색, 갱신, 삭제
     기술 스택
      ㅇ관계형 DB: Oracle, MySQL, PostgreSQL
      ㅇNoSQL: MongoDB, Redis 등
     역할: 영속적인 데이터 관리
  
  
• - Application Layer (애플리케이션 계층)
     기능: 비즈니스 로직 처리, 데이터 가공, 인증/권한 처리 등
     기술 스택
      ㅇJava (Spring, JEE), Python (Django), Node.js, .NET 등
      ㅇ서버: Tomcat, JBoss, WebLogic (WAS)
     역할: Presentation과 Data Layer 사이의 중개자
• Tier를 구분하는 기준?
  전체 서비스에서 역할(Role)을 기준으로 구분
  1-tier = 메인프레임 내 분리되지 못한 상태로 구성 → 개발 및 유지보수 어려움
  
  
  2-tier (Fat Client) = 클라이언트에 모든 로직 구성(브라우저 외 프로그램 설치 등), 서버엔 DB만 구성 → 프로그램 배포 어려움
  
  2-tier (Fat Server) = 내용 출력만을 담당하는 로직(브라우저), 서버에 business logic/DB 구성 → 많은 서버자원 요구 
  
  3-tier = 내용 출력 로직 - business logic 서버(미들웨어) - DB 구성 → 부하분산, 서비스 layer 분리에 따라 효율적 scale-in/out 설계 가능
  
  
  n-tier = 대규모 서비스 구성시 layer 추가 (예. KOS의 NEXA-ESB-PO-DB)
  
  미들웨어가 역할에 따라 WEB/WAS로 나뉘어지며 WEB을 Presentation으로 보아 WEB/WAS/DB를 3-tier로 칭하기도 함 
  
  
• WEB/WAS 분리 이유
  보안 : 외부 노출 계층(WEB)과 내부 로직(WAS)를 분리 (외부망 구축 필요시)
  로드 밸런싱 : WEB 계층 요청을 여러 WAS로 분산 가능
  확장성 : 각 계층의 수평확장 가능
  
  

 

• L4 스위치 이용하여 웹서버 이중화 및 부하분산
• 세션 클러스터링 적용 Redis?
• 와스서버 이중화
• DB 서버 이중화 (A-A) → 오라클 RAC 구성,
   → Shared Disk 구성
• 구성요소 (컴포넌트 이중화)
• 서버 nic.이중화
• (WIN)teaming/(LINUX)bonding 구성
• 서버 및 스토리지 HBA

 

 

 

[문제1]

 

 

2티어(AP-DB) --> 3티어(WEB-WAS-DB) 구조로 변경 시 점검 항목 (미들웨어 관점)

답안)

• 변경 이전
•  변경 이전

  WEB, WAS 솔루션 선정

  WEB,WAS 연동 가능 솔루션, AP서버 벤더 종속적 요소 있는지, DBMS 종류에 따른 WAS 지원가능여부 검토

• 사외망
•  사외망

  - L4 switch target 변경

  - DNS 매핑 IP 변경

  - AP서버 정적리소스, 동적리소스 분리
    http://domain.com/x.jpg  x.css   x.js
    Proxy방식, mod_jk방식, 벤더 플러그인 방식 (ex. mod_wl.so)
    연동방식에 따른 상세설정 검토

  - WEB 모니터링 방식 검토 필요

  - WEB1/2 -> WAS1/2 타겟 설정

• 사내망
•  사내망

  - WEB-WAS / WAS-DB / 모니터링시스템-WAS / 타시스템-WAS 방화벽 해제

  - AP서버 정적리소스, 동적리소스 분리
   war 내 ip 하드코딩 여부 검토 필요?

  - 모니터링 시스템 타겟 변경, 연동방식 유지 또는 변경 재검토

  - WAS session clustering 검토
  내부/외부, 외부인경우 redis 등 솔루션 검토
  session object serializable 검토

  - WAS-DB connection pool AP/DBA 검토 및 설정 필요

• 그 외
•  그 외

  성능테스트(load,stress,spike,stability) / Failover 테스트

  1. Load 테스트 : 부하를 순차적으로 증가시키면서 시스템 리소스 기준 최적처리량 확인 테스트
  2. Stress 테스트 : 임계값 이상의 매우 많은 요청을 보냈을 때의 동작 확인 테스트
  3. Spike 테스트 : 평시대비 순간적으로 급증한 요청이 정상적으로 처리되는지에 대한 테스트
  4. Stability 테스트 / Soak 테스트 : 매우 긴 시간 동안 테스트를 진행하여 memory leak 등 시스템 리소스가 정상상태를 유지하는지 확인하는 테스트

   

  failover테스트는 절체간 서비스 지연 또는 session 유지등의 이슈가 없는지 확인

[문제2]

3티어(WEB/WAS/DB)에서 WAS서버 증설 시 점검 항목

답안)

• 리소스 측면
•  리소스 측면

  Heap / CPU 리소스 검토 후 scale-out / scale-up 검토

  - heap 특이사항X / CPU 높음 -> scale-out 우선검토
     WEB→WAS / WAS→DB 방화벽 해제

  - heap gc 잦음 / CPU 여유있음 -> scale-up 우선검토 (MEM 여유있어야함)
     여유MEM 확인

• 미들웨어 측면
•  미들웨어 측면

  - WEB connection 증설 검토

  - WAS datasource connection pool 증가에 따른 DB 영향도 검토

  - 배포 엔드포인트 추가, 방화벽 해제 검토

  - 서비스 운영측면 관리지침 수정 검토 (예. KOS DOM별 차단방식)

 

 

 

---

 

3-Tier (WEB/WAS) 아키텍처

3-Tier 아키텍처는 시스템을 세 개의 계층으로 분리하여 구성하는 방식입니다. 각 계층은 독립적인 역할을 수행하며, 시스템의 확장성, 유연성, 유지보수성을 향상시킵니다. 웹/WAS 구조는 이 3-Tier 아키텍처를 따르는 가장 대표적인 예시입니다.

1. 프레젠테이션 계층 (Presentation Tier)

• 구성요소: 웹 서버(Web Server)
• 역할: 클라이언트(사용자)의 요청을 최전선에서 처리합니다. 주로 HTML, CSS, JavaScript, 이미지와 같은 정적 콘텐츠를 제공하는 역할을 담당합니다.

2. 비즈니스 로직 계층 (Business Logic Tier)

• 구성요소: WAS(Web Application Server)
• 역할: 사용자 요청에 따라 동적 콘텐츠를 생성하고, 복잡한 비즈니스 로직을 처리합니다. 데이터베이스와의 연결을 관리하고, 트랜잭션 처리, 보안 등 핵심 기능을 수행합니다.

3. 데이터 계층 (Data Tier)

• 구성요소: 데이터베이스 서버(DB Server)
• 역할: WAS의 요청에 따라 데이터를 저장하거나 조회합니다. 웹 애플리케이션의 모든 데이터를 관리하는 역할을 담당합니다.

---

문제: 3-Tier 아키텍처의 역할 구분

다음은 3-Tier (WEB/WAS) 아키텍처에 대한 설명입니다. 주어진 그림을 참고하여 각 계층의 역할과 구성 요소에 대한 설명으로 옳지 않은 것을 고르시오.

1. **웹 서버(Web Server)**는 주로 정적 콘텐츠를 담당하며, 사용자의 요청을 WAS로 전달하는 역할을 수행한다.
2. **WAS(Web Application Server)**는 비즈니스 로직을 처리하고, 데이터베이스에 접근하여 데이터를 조작한다.
3. **데이터베이스 서버(DB Server)**는 웹 서버의 요청을 받아 데이터를 저장하고 관리한다.
4. 3-Tier 구조는 각 계층의 역할을 분리하여 시스템의 확장성과 유연성을 높인다.
5. 3-Tier 구조에서 WAS와 데이터베이스 서버는 주로 동적 콘텐츠 처리를 담당한다.

 

정답: 3. 데이터베이스 서버(DB Server)는 웹 서버의 요청을 받아 데이터를 저장하고 관리한다.

---

해설

3-Tier 아키텍처에서 각 계층은 독립적인 역할을 수행합니다. 데이터베이스 서버는 웹 서버와 직접 통신하지 않고, WAS(Web Application Server)의 요청을 받아 데이터를 처리합니다.

1. **웹 서버(Web Server)**는 사용자의 요청을 WAS로 전달하고, 정적인 콘텐츠를 처리하는 역할을 합니다. (옳은 설명)
2. **WAS(Web Application Server)**는 동적인 콘텐츠를 생성하기 위해 비즈니스 로직을 수행하고, 데이터베이스와 통신하여 데이터를 조작합니다. (옳은 설명)
3. **데이터베이스 서버(DB Server)**는 WAS의 요청에만 응답하며, 웹 서버와 직접 통신하지 않습니다. 따라서 웹 서버가 아닌 WAS의 요청을 받습니다. (틀린 설명)
4. 각 계층의 분리를 통해 웹 서버, WAS, DB 서버를 개별적으로 확장할 수 있어 시스템의 유연성과 확장성이 높아집니다. (옳은 설명)
5. WAS와 데이터베이스는 사용자의 요청에 따라 실시간으로 변화하는 동적 콘텐츠를 처리하는 데 필수적인 요소들입니다. (옳은 설명)