<온프레미스 아키텍처 - 하드웨어 구성도> [KT에이블스쿨] 2025.05.19(월)

2025.05.19 (월)

 

 

 

오늘은 지난주 금요일의 온프레미스 목표시스템 구성도에 이어

온프레미스 하드웨어 구성도에 대해 배웠습니다 ! 

 

오늘 근데 다시 몸이 안 좋아져서 중간에 병원을 가려

외출을 다녀오긴 했지만 열심히 교안 따라 복습해보겠습니다 ! 

 

가볼까요?

 

 

---

[온프레미스 아키텍처 - 하드웨어 구성도]

 

1. 하드웨어 구성도

○ 하드웨어 구성도 (Hardware Architecture Diagram)

  : 물리적/논리적 장비의 배치와 연결 방식을 시각적으로 표현한 도식

 

○ 하드웨어 구성도 중요성

  ① 시스템 이해도 향상

  ② 장애 대응 속도 개선

  ③ 확장/변경 용이

  ④ 팀 간 커뮤니케이션 원활화

 

○ 하드웨어 구성도 구성 요소

① 서버(Server)

  : 시스템 운영을 위한 CPU, 메모리, OS를 제공하는 장치

→ 대부분 개인용 컴퓨터보다 성능이 낮은 경우가 많음

 

② 스토리지(Storage)

  : 데이터 저장을 위한 저장장치로 SAN, NAS, DAS 등으로 구성

→ DB를 구성하면서도 안정성 및 백업 역할을 수행

 

③ 네트워크(Network)

  : 서버와 스토리지를 연결하여 데이터를 주고받는 장치의 집합 (스위치, 라우터 등)

→ 원활한 데이터 전송과 서비스 연속성 보장

 

1) 서버(Server)

○ 서버 종류 및 특징

① 물리 서버(Physical Server)

  : 물리적인 컴퓨터 1대로 구성된 서버

  → 안정적 성능, 보안성/신뢰도 높음, 초기 구축 비용과 공간, 전력 소모가 큼

  Ex) 금융권 핵심 서버, 대규모 연산이 필요한 HPC(고성능 컴퓨팅) 등

 

② 가상 서버(Virtual Server)

  : 물리 서버 위에 가상 머신(VM)을 이용하여 구성한 서버

   → 물리서버 하나 위에 여러 개 서버 구동가능, 테스트 환경에 유리

 

③ 컨테이너(Container)

  : VM보다 경량화된 가상화 기술(도커, 쿠버네티스 등)을 이용한 가상 서버

  → 빠른 시작과 종료, 자원 사용 효율이 좋음, 다만 호스트 커널에 의존을 많이 하여 커널 이슈에 영향이 큼

 

○ 서버 스펙 산정 대상

  → CPU(Core/vCPU), RAM, 스토리지(HDD/SSD), 운영체제(OS)

 

○ 서버 스펙 산정 기준

  → 동시 사용자 수, 트랜잭션 처리량, 데이터 처리량, 장애 복구 요구사항, 가상화/컨테이너 환경 고

 

2) 스토리지(Storage)

○ 스토리지 스펙 산정 기준

  → 저장해야 할 데이터의 종류와 특성, 데이터 증가율, 로그 저장 및 데이터 관리 여부, 백업 정책 및 장애 복구 구성 고려

 

○ 일반적인 스토리지 용량

① DB서버

  - 단순 게시판 서비스 : 1 ~ 2TB

  - 사용자가 많은 첨부 파일 포함 : 5 ~ 10TB

  - 대규모 데이터 분석, 트랜잭션 로그 보존 시 : 10TB 이상

 

② Web/WAS 서버 

  - 애플리케이션 로그 및 캐시 데이터 저장 : 500GB ~ 3TB

  - 사용자 세션 정보, 임시 파일 포함 시 추가 확보 필요

 

③ 모니터링 서버 

  - 지표 수집, 로그 저장 : 256GB ~ 1TB

  - 수집 항목과 기간에 따라 차이 발생

 

④ 미디어 서버 (파일/영상)

  - 이미지/문서 업로드 중심 서비스 : 1 ~ 5TB

  - 영상 중심 서비스 : 10 ~ 50TB 이상 확보

 

3) 네트워크(Network)

○ 네트워크 구분

① 외부망

  : 외부 인터넷과 연결된 네트워크 (유저가 접속하는 네트워크)

 

② 내부망

  : 시스템 내부 장비끼리만 연결된 네트워크 (유저 접속 불가)

  → 서버 간 통신, 내부 API호출, 스토리지 접근 등 

 

○ 네트워크 구성 요소

① 스위치(Switch)

  : 네트워크 내에서 장비를 상호 연결하는 장비

  → L2 스위치 (MAC 주소 기반), L3 스위치 (IP 주소 기반)

 

② 라우터(Router)

  : 서로 다른 네트워크를 연결해주는 장비, 목적지 네트워크까지 데이터가 잘 갈 수 있도록 경로 설정

 

③ 방화벽(Firewall)

  : 외부와 내부 네트워크 사이에서 허용된 데이터만 통과시키는 보안 정비 

  → IP 주소, 포트 번호, 프로토콜을 기준으로 접근 제어

 

③-2) 방화벽 + WAF(Web application Firewall)

  : 웹 애플리케이션에 대한 공격을 차단하는 보안 장비(웹 취약점 보호)

  → HTTP / HTTPS 트래픽을 분석해 공격 패턴 감지, SQL/XSS/파일 업로드 공격 등 애플리케이션 레벨 위협 차단

 

③-3) 방화벽 + IPS

  : 네트워크 침입을 실시간으로 탐지하고 차단하는 보안 장비 

  → 네트워크를 통과하는 트래픽을 실시간 분석, 공격 패턴/위험한 트래픽을 차단하거나 경고(DDoS 공격, 포트 스캔 등에 대응)

 

2. 하드웨어 연결 설계

○ 외부방과 내부망 구성 설계

  → 전체 흐름 : [ 외부망 - 라우터 - 방화벽 - 내부망 - 스위치 ]

    - 외부망 : 외부 네트워크

    - 라우터 : 공인망/사설망 간 경계 설정 및 라우팅

    - 방화벽 : 보안 정책에 따라 트래픽 필터링

    - 내부망 : 기업 내부 자산 보호용 사설 네트워크

    - 스위치 : 내부망 내 서버/장비 간 물리적 연결 분산

  → 특징

    ① 외부망과 내부망 사이에 다양한 보안 및 트래픽 제어 장비 배치

    ② 각 장비는 연결 단위마다 기능 분리 및 역할 책임 소유

    ③ 보안과 성능을 고려한 계층적 네트워크 분리, 물리적/논리적 안정성 확보

 

○ 외부망(External Network)

  : ISP(Internet Service Provider)를 통해 제공되는 공인 IP 기반 네트워크, 웹과의 연결을 위한 입구 역할

 

○ 라우터(Router)

  : 공인망/사설망 사이의 경계 장비, 서로 다른 네트워크 간 패킷 전달 및 경로 설정 수행

  → 단일 지점에서 트래픽을 통제하기 때문에, 장애 대응을 위해 이중화(Router Redundancy)를 고려

 

○ 방화벽(Firewall)

  : 외부 트래픽을 정책 기반으로 필터링, 네트워크 보안의 1차 관문

  → 포트/프로토콜 기반 접근 제어, IP 주소 필터링, 트래픽 로그 기록 및 알림

 

 * DMZ 영역이 필요할 경우, 이중 방화벽 구조로 확장 가능

 

○ 내부망(Internal Network)

  : 기업 또는 조직 내부에서만 사용하는 사설 네트워크

  → 방화벽 뒤쪽에 배치되어 외부 위협으로 부터 보호 (트래픽 접근은 방화벽 정책을 통과한 경우에만 허용)

  → 논리적 보안 격리 필요, 중요 자산은 추가 보안 장비를 사용해 별도 보호

  → 불필요한 외부 통신을 차단하고, 제로 트러스트 접근 원칙 적용 가능

 

○ 스위치(Switch)

  : 내부망 내 장비 간 연결을 담당하는 네트워크 장비 (MAC 주소 기반 트래픽 전달 → 데이터 충돌없이 빠른 통신 가능)

  → 사용하는 이유 : 하나의 내부망에 다양한 장비를 연결해야 하는 경우

  → 허브(Hub)와 달리 지능형 트래픽 분배 가능 (효율적, 보안성 Good)

  → 전원 지중화, 링크 백업 구조로 안정성 강화 필요

 

○ VLAN(Virtual LAN)

  : 물리적으로는 같은 스위치지만, 논리적으로는 서로 다른 네트워크처럼 동작하게 만드는 기술

  → 각 포트에 VLAN ID를 할당하여 하나의 스위치를 다수의 독립된 네트워크로 분리 

  → VLAN 간 기본적으로 통신 불가 (논리적 보안 분리와 유연한 구성 가능)

 

○ VLAN 동작 방식

  ① 스위치의 각 포트에 VLAN ID를 할당

  ② 동일 VLAN ID를 가진 장비끼리만 통신 가능

  ③ 서로 다른 VLAN 간 기본적 트래픽 전달 불가

  ④ VLAN 간 통신이 필요한 경우, Layer 3 스위치 또는 라우터를 통해 중계

 

○ VLAN 장점 

  : 보안성 강화, 트래픽 최적화, 유연한 네트워크 구성, 관리 편의성 향상

 

○ 서브네팅(Subnetting)

  : IP 네트워크를 작은 단위로 분할하여 각 구간을 독립된 네트워크처럼 운용하는 방식

  → 하나의 IP 대역을 여러 개의 서브넷으로 나눠 네트워크 관리 효율성 및 보안성 강화

 

○ 서브넷 마스크

  : IP 주소의 어느 구간이 네트워크 구간이고, 어느 부분이 호스트 식별용인지 정의

  Ex) 192.168.10.0/24 → 256개 IP 주소 사용 가능

 

○ VLAN + 서브네팅 결합 설계

  : VLAN은 노리적 네트워크 분리, 서브네팅은 IP 주소 기반 네트워크 분리 

  → 두 기술을 동시 사용하면, (트래픽 격리 + 주소 체계 정리 + 보안 정책 분리)를 동시에 구현 가능

      → 트래픽 경로와 접근 권한을 IP 단위로 제어 가능

  → VLAN 1개당 서브넷 1개를 매핑

 

○ 로드 밸런서(Load Balancer)

  : 여러 대의 서버 또는 장비에서 트래픽을 고르게 분산시켜 특정 서버에 부하가 집중되지 않도록 조절하는 장치

  → 클라이언트는 로드 밸런서를 통해 접속하며, 실제 처리 서버는 내부적으로 로드밸런서가 선택

  → 목적 : 서비스 안정성 확보, 성능 향상, 유지보수 유연성

  → 클라이언트 요청과 실제 서버 사이에 위치

 

○ 로드 밸런서 유형

① L4 로드 밸런서(전송 계층)

  : IP 주소/포트 번호를 기준으로 트래픽 분산

  → 게임 서버, API 라우팅

 

② L7 로드 밸런서(애플리케이션 계층)

  : HTTP/HTTPS 요청을 URL, 헤더, 쿠키 등 응용 정보 기반 분석

  → 웹 서비스, 마이크로서비스

 

○ 스토리지 구성 방식 

① DAS(Direct Attached Storage)

  : 서버에 직접 물리적으로 연겨로딘 저장장치

  → 하나의 서버에만 연결되어 동작 (내장형 HDD, 외장 스토리지, USB도 포함)

  → 장점 : 설치/구성 간단, 뛰어난 성능, 낮은 비용, 별도 네트워크 구성 불필요

  → 단점 : 하나 서버에 종속, 중앙 관리 불가, 가용성 낮음

 

② NAS(Network Attached Storage)

  : 네트워크에 연결되어 여러 장비가 동시에 접근 가능한 공유 스토리지 (네트워크를 통해 접근 가능)

  → 전용 운용체제(OS)를 갖춘 저장장치, SMB/NFS 등 파일 공유 프로토콜 사용

  → 장점 : 다중 접근 가능, 중앙 집중형 관리 가능, 확장성 우수

  → 단점 : 네트워크 품질에 성능 좌우, 파일 단위 처리만 가능

 

③ SAN(Storage Area Network)

  : 서버와 스토리지를 전용 고속 네트워크로 연결하여 데이터를 블록 단위로 전송하는 구조

  → NAS와의 차이 : 블록 단위 데이터 전송, 서버에서는 SAN 스토리지를 내장 디스크로 인식

  → 서버와 스토리지를 고속으로 직접 연결해야 하므로, 환경에 따라 다양한 전용 연결 방식을 사용함

       (Fibre Channel, iSCSl, InfiniBand)

  → 장점 : 성능, 확장성, 고가용성 

 

○ 데이터 백업 방식

  → 시스템 장애, 실수, 랜섬웨어 감염 등 에기치 못한 손실에 대한 복구 수단 필요

 

① 전체 백업 (Full Backup)

  : 백업 대상 데이터를 매번 전체 복사하는 방식 (모든 파일을 백업)

  → 복원 속도가 빠름, 백업 시간과 저장공간이 가장 많이 필요

 

② 증분 백업 (Incremental Backup)

  : 가장 최근 백업 이후 변경된 데이터만 백업하는 방식

  → 저장 공간이 절약되만, 복원 절차가 복잡하고, 모든 증분 세트 필요

 

③ 차등 백업 (Differential Backup)

  : 마지막 전체 백업 이후 변경된 데이터 전체를 매번 백업  (누적 백업 구조)

  → 백업 용량이 시간이 갈수록 증가, 복원 절차가 간단

 

○ 백업 방식 선택 기준

① RPO (Recovery Point Objective)

  : 얼마나 최신 데이터까지 복구할 수 있어야 하는가

  → RPO가 10분이면, 장애 시 10분 이내에 데이터 손실은 허용됨

 

② RTO (Recovery Time Objective)

  : 시스템이 얼마나 빨리 정상화되어야 하는가 

  → ex) RTO가 2시간이면 2시간 이내에 복구되어야 함

 

3. 확장성과 고가용성

 

○ 확장성

  : 서비스 수요 증가에 따라 시스템 용량 또는 처리 능력을 유연하게 확장할 수 있는 성질

  → 수평 확장 전제 : 현대 시스템은 수평 확장을 전제로 설계

  → 서버 분리 구성 : 유연한 대응을 위해 역할별 서버 분리 구성

  → 논리 자원 확보 : 물리 자원 외에도 VLAN 등 논리 자원 여유분도 확보

  → 다중 구성 : 중단없이 확장 가능을 위해

 

  ① 수평 확장 (Scale-out)

    : 서버, 스토리지, 네트워크 장비를 여러 대 추가

  ② 수직 확장 (Scale-up)

    : 기존 장비 사양(메모리, CPU)을 업그레이드 

 

○ 고가용성

  : 시스템에 장애가 발생해도 서비스가 중단되지 않도록 설계된 구성 방식

  → 온프레미스 환경에서는 서비스 운영 책임이 모두 내부에 있음

  → 이중화 구성(Redundancy) : 예비 자원을 확보해 장애 시 즉시 대체

  → 자동 장애 전환(Failover) : 장애 발생 시 대체 장비로 자동 전환

  → 백업과 복구 : 데이터를 복제해두고, 장애 발생 시 복제본을 활용해 복구

  → 장애 복구 자동화(RA, Recovery Automation) : 스크립트, 오케스트레이션을 통해 장애 감지부터 복원까지 일괄 처리

 

○ 단일 지점 장애(Single Point of Failure, SPOF) 

  : 시스템 구성 요소 중 한 지점이라도 장애가 발생하면 전체 서비스가 멈추는 현상

  → 이중화(Redundancy)를 통해 극복 가능

 

○ 이중화(Redundancy) 방식 

① Active-Standby 방식

  : 주 장비와 예비 장비로 구성, 장애 발생 시 예비 장비로 전환(Failover)

 

② Active-Active 방식

  : 두 장비가 동시에 운영되며 부하가 분산됨, 하나가 장애가 나도 나머지가 계속 처리

 

③ 클러스터 구성

  : 여러 노드가 동일 서비스를 제공하며 상태를 공유, 장애 시 클러스터 내부에서 자동으로 역할 전환

 

④ 경로 이중화

  : 장비 간 연결 경로를 두 개 이상 구성, 한 경로에서 장애가 발생해도 다른 경로로 우회

 

⑤ 데이터 복제

  : 주요 데이터를 실시간 또는 주기적으로 복제, 장애 시 복제본을 통해 신속한 복구 진행

 

○ 자동 장애 전환(Failover) 

  : 시스템 구성 요소에 장애가 발생했을 때, 예비 자원으로 자동 전환하여 서비스를 지속

  → 서비스 중단 없이 장애에 대응하려면 이중화와 같이 적용해둬야 함

  → 구성 요소 : (장애 감지 →  전환 로직 → 상태 동기화)

 

○ 장애 복구 자동화(Recovery Automation, RA)

  : 시스템 장애 발생 시 복구 절차 전반을 자동으로 수행하는 구조

  → 이중화와 자동 장애 전환과 별개로 근복적 서비스 복구 절차

  → 흐름 : (장애 감지 → 서비스 또는 자원 재시작 → 실패 시 대체 자원 배치 → 상태 점검 → 이상 없으면 서비스 유지)

  → 재시작이 무한으로 반복되며 오작동 가능성

 

4. 하드웨어 구성도 작성 실습

 

하드웨어 구성도

 

   → 스토리지(DB, NAS), Web 서버, WAS 서버, DB 서버, 모니터링 서버, 미디어 서버, 라우터, 방화벽, WAF 

   → 이중화 구성을 위해 전단에 로드 밸런서 위치

   → 보안을 위해 DMZ(Demilitarized Zone) 설정

   → 미디어 파일 전송을 위해 CDN(Content Delivery Network) 서버 도입 

   → 백업 서버를 별도로 구성

 

 

---

 

 

와 ... 정말정말 길고 길었던 하드웨어 리뷰가 끝났습니다.

이게 내가 못 따라간건지, 양이 많았던건지 

긴가민가 하는 생각이 들었었는데,

다 배우고 복습하는 지금 확실해졌습니다.

 

절대적으로도 이번 챕터가 양이 많네요..

 

배울 때도 힘들었지만 복습할 때도 매우 힘듭니다..

 

그래도 ! 

현재 미니 프로젝트를 마친 상태인데

강사님들이 알려주셨던 내용이..

이제서야 이해가 되고 적용할 수 있게 된 듯합니다..

(어디까지 보신겁니까 도대체..)

 

앞으로 진행될 네트워크 챕터가 걱정되긴 하지만,

이제 더 열심히 복습을 해보겠습니다 ! 

 

 

그럼 오늘도 수고하셨습니다 :D