화요일 점심,
죽어가던 냉장고 속 양파를 썰다가,
갑자기 허리가 뜨끔하면서 주저앉았다.
오랜만에 느끼는 척추 내려앉는 느낌이란...
와.... 3년 전 디스크 수술 이후 최대 위기였다.
엉금엉금 기어서 급하게 조퇴 버튼을 누르고,
내리 이틀을 더 침대에 누워만 있었다..... ㅠ
사실 조금은 좋았다.
에이블스쿨 하면서 살이 꽤 쪘는데 그래서인듯?
앞으로도 한 일주일은 오래 앉아있지 말라더라.
덕분에 내일 경영정보 시각화 시험도 못 간다.
시험장이 부산이거든.
뭐... 이왕 일어난 일은 어쩔 수 없고,
빠진 분량 복습이나 열심히 해야지.
디스크 환우분들 허리 관리 잘 합시다.
일단 교안 + 검색을 통해 화요일 오후 ~ 목요일 과정을 훑어본다.
다만 실습 부분은 해 봐야 알 수 있는 만큼, 이론 중심으로 정리해보자.
서버
- 서버 일반
IT 인프라로서의 서버란 일반적으로 말하는 웹 서버가 아니라,
하드웨어로서의 서버를 말한다.
이는 클라이언트의 요청에 따라 데이터를 제공하는 일련의 장치이다.
서버의 전통적인 구성은 아래와 같다.
| App | 사용자가 요구하는 기능을 직접 제공하는 소프트웨어. 데이터를 처리하고 요구 로직을 수행한다. 사용자에게 인터페이스를 제공한다. |
웹 서버 데이터베이스 애플리케이션 서버 이메일 서버 게임 서버 |
| OS | H/W와 App 간의 인터페이스 역할을 수행하는 소프트웨어. 서버의 자원을 관리하고 App 실행 환경을 제공한다. |
Window Linux Z/OS AIX |
| H/W | 하드웨어. 서버를 물리적으로 구성하는 장치 CPU, 메모리, 스토리지, 네트워크 인터페이스 등의 자원을 제공한다. |
메인프레임 UNIX* x86 |
* UNIX는 OS로 시작되었으나, 특정 하드웨어에서 실행되도록 설계된 탓에 여기선 하드웨어로 구분한다.
기본적으로는 S/W - H/W 통합 환경으로 보는 듯
※ 웹서비스 3 Tier 아키텍처 요소
웹 기반 서비스를 구축할 때,
App 계층에 반드시 필요한 소프트웨어 서버 3가지가 있다.
web, WAS, DBMS정처기에서 다 보던 얼굴들이구먼
- web : 클라이언트(브라우저)에게 요청을 받아서 정적 컨텐츠(html, jpeg)는 직접 처리,
동적 컨텐츠는 WAS에 전달한다.
- WAS : DB 조회를 포함한 동적 컨텐츠를 처리한다.
- DBMS : 데이터베이스를 운영하고 관리한다.
이것들을 하나의 서버에 몰아서 구성하는 것을 1 Tier 아키텍처라고 하며,
web을 분리하거나 DB를 분리해서 2 Tier 아키텍처를 구성하기도 한다.
하지만 계층 간 독립성이나 보안 측면에서는
이 세 서버를 물리적으로 분리하는 것이 효율적이다.
이 구성은 시간이 흐름에 따라 다양하게 분화되었고,
지금은 상황에 따라 3가지 아키텍처 중 하나를 선택하여 사용한다.
'일반'은 위에서 봤으니, '가상머신' 방식과 '컨테이너' 방식에 대해 알아보자.
- 가상머신 서버 아키텍처
가상머신 서버 아키텍처는 서버 가상화(Virtualization) 기법을 핵심으로 하는 구조를 말한다.
서버 가상화란 물리적 서버 하나를 여러 가상 서버로 분리하여 독립적으로 작동시키는 기술을 말한다.
이렇게 하면 물리적 서버에서 소위 '노는 자원'을 최소화할 수 있다.
이를 위해서는 하이퍼바이저(hypervisor)가 필요하다.
하이퍼바이저는 호스트 컴퓨터가 복수의 OS를 실행할 수 있게 만들어 주는 플랫폼이다.
현존하는 하이퍼바이저로는
VMware ESXi, MS Hyper-V, Linux KVM, IBM Power VM 등이 있다.
따라서 하이퍼바이저는 위와 같이 기존 서버 아키텍처의 OS 계층을 대체한다.
이 하이퍼바이저에 의해 다양한 OS가 부팅되며,
이에 따라 하나의 물리적 자원(H/S)을 공유하는 여러 App 실행이 가능해진다.
이렇게 하이퍼바이저가 나눈 OS와, 거기서 실행되는 App을 하나의 가상 머신(VM)으로 칭한다.
이때 각 VM 간의 네트워크는 하이퍼바이저 내의 가상 스위치에 의해 제어된다.
하이퍼바이저는 크게 두 유형으로 나뉜다.
Bare - Metal Hypervisor는 Native Hypervisor라고도 하는데,
위 그림처럼 하드웨어 바로 위에서 구동된다.
즉, 위에서 말한 'OS 계층을 대체하는' 하이퍼바이저는 여기에 속한다.
호스트의 OS가 따로 없기 때문에 성능이 더 잘 나오고,
안정성과 보안성 측면에서도 좋은 하이퍼바이저다.
단점으로는 호스트 OS가 없는 만큼 운영이나 관리가 까다롭고,
초기 설치와 설정이 복잡하다.
이 유형에 해당하는 것은 VMware ESXi, MS Hyper-V, IBM Power VM 등이 있다.
Hosted Hypervisor는 반대로 호스트 OS 위에서 구동된다.
각 VM을 관리하는 OS가 있기 때문에 설치와 설정이 간단하고,
따라서 기존 시스템 위에 가상 머신을 추가하기가 용이하다.
대신 OS가 하나 더 돌아가는 만큼 오버헤드가 커서 성능이 약간 떨어질 수 있고,
호스트 OS에 문제가 발생하면 가상 머신들에도 해당 문제가 발생하므로
보안 측면에서 비교적 취약한 편이다.
이 유형으로는 VMware Workspace, Oracle VirtualBox등이 있다.
※ 가상 머신 마이그레이션(Migration)
마이그레이션이란 가상머신을 하나의 호스트에서 다른 호스트로 이동시키는 것을 말한다.
호스트가 이동된다 = 물리적 서버가 바뀐다.
VM을 중단하고 옮기는 non-Live 마이그레이션과,
VM을 실행 중인 상태에서 옮기는 Live 마이그레이션으로 나뉜다.
- 컨테이너 서버 아키텍처
컨테이너는 OS 가상화 기술의 일종으로,
App 계층의 프로세스가 독립적인 환경에서 병렬 실행되도록 한다.
App을 독립적으로 실행시킨다는 점에서 가상머신과 비슷해 보이는데,
가상 머신 아키텍처에서는 각 VM에 OS가 포함되므로 필연적으로 무겁다.
하지만 컨테이너는 호스트의 OS(주로 리눅스)의 커널*을 공유하여 실행되므로
비교적 오버헤드가 낮다.
* 커널 : OS의 구성 요소 중 하나. OS가 하는 중요한 역할을 얘가 거의 다 담당한다.
다만 격리 단위가 머신이 아닌 프로세스인 탓에,
보안 강화를 요한다.
이런 컨테이너를 구동하고 관리해주는 tool을 컨테이너 엔진이라고 한다.
컨테이너 엔진의 종류로는 Docker, LXC, CRI-O 등이 있다.
스토리지
- 스토리지
스토리지(Storage)는 저장장치다.
게이머라면 익숙한 HDD, SSD같은 것들도 스토리지의 일종이다.
스토리지의 유형은 다음과 같다.
| Tape | 자기테이프 활용 저렴함 = 대용량 데이터 장기 보관에 적합 속도가 느림(랜덤 액세스 X) 내구성, 수명 ↑ |
| HDD | 디스크와 읽기/쓰기 헤드 활용 저렴함 = 대용량 데이터 장기 보관에 적합 랜덤 액세스 O, SSD보다는 느림 충격에 민감하여 내구성 낮음 |
| SSD | 플래시 메모리 활용 용량 대비 높은 비용 빠른 속도 내구성 우수 |
| NVMe | PCle 인터페이스 활용 가장 높은 비용 기존 SSD(SATA 인터페이스)보다도 월등히 빠름 |
| Cloud storage | 실물 저장장치가 사용자에게 불필요 |
쓰고 보니 난잡하다. 다시 정리.
| 유형 | 속도 | 비용 | 내구성 | 용도 |
| Tape | 느림 | 매우 저렴 | 높음 | 장기 백업, 아카이브 |
| HDD | 보통 | 저렴 | 낮음 | 일반 저장소(대용량) |
| SSD | 빠름 | 비쌈 | 높음 | OS, App 실행 |
| NVMe | 매우 빠름 | 매우 비쌈 | 높음 | 고성능 컴퓨팅, 데이터센터 |
| Cloud Storage | 인터넷 연결에 따름 | 종량제 | - | 원격 접근, 백업 |
편-안.
- 스토리지 아키텍처
한편, 스토리지를 구성하는 방식은 이렇게 나뉜다.
| DAS (Direct Attached Storage) |
서버와 저장 장치를 케이블로 직접 연결 | 장치 수 제한 다른 장치나 사용자에게 공유 불가 |
| NAS (Network Attached Storage) |
서버와 저장 장치를 LAN 네트워크로 연결 | 여러 서버가 각각 할당받은 용량을 사용 DAS보다 높은 확장성, 유연성 NFS, iSCSI 프로토콜 활용 |
| SAN (Storage Area Network) |
서버와 저장 장치를 광케이블(FC 케이블)로 연결 | 별도의 SAN Switch를 통해 노드 분산 |
- 스토리지 프로토콜
| 데이터 전송 방식 | 데이터 구조 | 속도 | 설치 비용 | 사례 | |
| FC (Fibre Channel) |
전용 채널 | 블록 | 매우 빠름 | 높음 | 고속 데이터센터 SAN |
| iSCSI (internet SCSI) |
TCP/IP 기반 | 블록 | 보통 | 낮음 | 중소규모 SAN 비용 절감 |
| FCoE (Fiber Cahnnel over Ethernet) |
이더넷 | 블록 | 빠름 | 중간 | 데이터센터 네트워크 통합 |
| NFS (Network File System) |
TCP/IP 기반 | 파일 | 보통 | 낮음 | 파일 공유 NAS |
IT 보안 기본
IT 보안은 크게 두 가지를 지킨다.
그것은 데이터와 시스템이다.
데이터는 서버, 네트워크, 스토리지에 대한 무단 접근을 방지함으로써,
시스템은 SW의 손상, 도난, 중단을 방지함으로써 보호할 수 있다.
보안의 유형은 다음과 같다. 정처기 내용이 참 많이 나온다.
| 네트워크 보안 | 네트워크 내부로의 무단 접근을 차단 |
| 인터넷 보안 | 브라우저에서 오가는 정보를 보호 웹 기반 App : 네트워크 보안 = 인터넷 보안 |
| 엔드포인트 보안 | 단말기에 대한 악성코드 방지 |
| 클라우드 보안 | 클라우드 아키텍처 내 데이터 보호 |
| 애플리케이션 보안 | 애플리케이션 내 데이터 및 코드의 도난/변질을 방지 |
- 방화벽
이것도 사실 게임 좀 해 본 사람은 많이 알 내용이다.
이름 그대로 출입을 제어하는 역할을 하며, 네트워크 트래픽이 대상이다.
신뢰할 수 없는 외부 네트워크와의 통로 사이에서 검문소 역할을 한다.
방화벽의 기능은 세 가지로, 접근통제, 로깅, 인증이다.
여기부터가 오늘 수업 내용.
서비스 요구사항 분석 및 인프라 설계
DX컨설턴트로서 프로젝트를 제안할 일이 생기는데,
이때 발주자(고객사)와 공급자(제안사) 간의 주요 프로세스는 다음과 같다.
자, 여기서 제안요청서(RFP)를 받았다고 가정해 보자.
RFP에서 IT 인프라 관련 내용에 대한 제안서를 작성하는 과정을 살펴보자.
제안서 작성의 주요 프로세스는 다음과 같다.
| 1. 제안 내용 분석 | 2. 제안서 작성 |
| ⅰ. 사업 이해 | ⅰ. 제안 스토리 구성 |
| ⅱ. 요구 사항 분석 | ⅱ. 제안서 작성 |
| ⅲ. 서비스 제안 도출 | ⅲ. 제출 |
그중에서 오늘은 요구사항 분석과 서비스 제안 도출 단계를 살펴본다.
- 요구사항 분석
'사업 이해'는 너무나 중요하지만 일반화할 수 없는 내용이니 우선 넘어가고,
'요구사항 분석'부터 살펴보자.
'요구사항 분석' 프로세스는 다음과 같다.
가상의 CASE를 예로 들어서 실행해 보자.
만약 자사의 보유 솔루션 현황이 다음과 같다고 하자.
• 음성 인식 및 실행/제어 솔루션 보유
• AI 통역 솔루션 보유
• IT 인프라 구성 및 유지보수 솔루션 보유
• 원격 알림/전파 솔루션 보유
• 로봇, 키오스크 등의 하드웨어 기술 보유
이때, 다음과 같은 고객사의 제안요청서가 있었다고 가정하자.
고객사 사업목적 및 사업목표
1. 사업 목적
○ 스마트 환경 도입을 통한 공항 이용의 효율성/편리성/안전성을 높일 수 있는 환경 구축
2. 사업 범위
○ 인적 서비스 대체 및 시설사용의 편의성 제공을 위한 스마트 환경 구축
○ 스마트 기기를 통한 음성 안내 환경 제공 및 위급사항 전파 가능 시스템 구성
○ 신규 사업 관련 비상 알람, 데이터 추출 등을 위한 관리 모니터링 환경 제공
3. 상세 요구사항
○ 사용자 서비스는 사용자가 음성명령을 통해 실행/제어 가능해야 한다.
○ 인적 통역 서비스를 대체할 디지털 통역 서비스를 제공해야 한다.
○ 서비스 운영관리를 위해 통합 관리 환경을 제공해야 한다.
- 공항 내 데이터센터에 서비스 인프라 환경 1개와 본사에 모니터링 인프라환경 1개 구성하여 총 2개의 환경을 각각 구분하여 시스템 구성도에 표시해야 한다.
- 공항 내 데이터 센터 내에는 서비스를 위한 서버를 배치하고, 모니터링 센터에는 모니터링을 위한 서버를 배치해야 한다.
○ 필요 시 본사(모니터링 인프라)에서 긴급정보 등 알림/전파가 가능해야 한다.
○ 공항 내 데이터 센터 서비스는 3Tier로 구성(WEB/WAS/DB)하여 제시해야 한다.
- Web. WAS, DB네트워크를 각각 별도 구성하고, WAS 와 DB는 Private 네트워크에 구성한다.
- 신규 서비스를 위한 IP 설정 정보를 별도로 작성 해야 한다.
○ 모든 인프라 (서버/네트워크/스토리지)는 이중화 하여 구성한다.
이 문서를 바탕으로 요구사항을 분석한다면, 다음과 같은 표를 작성하게 될 것이다.
| 요구사항 명칭 | 기능 및 해결 방법 | 솔루션 | |
| 1 | 사용자 서비스는 사용자가 음성 명령을 통해 실행/ 제어 가능해야 한다. | AI 스피커 배치 스마트폰 어플리케이션 설치 |
음성 인식 및 실행/제어 솔루션 |
| 2 | 인적 통역 서비스를 대체할 디지털 통역 서비스를 제공해야 한다. | AI 통역 도우미 로봇 배치 | AI 통역 솔루션 하드웨어 기술 |
| 3 | 서비스 운영관리를 위해 통합 관리 환경을 제공해야 한다. | 공항 내 인프라와 본사 인프라의 병렬 구성 프로세스 시스템 구성도 작성 |
IT 인프라 구성 및 유지보수 솔루션 |
| 4 | 필요 시 본사에서 긴급정보 등 알림/전파가 가능해야 한다. | 공항 내 통제실과의 핫라인 구축 직원용 웨어러블 기기 어플리케이션 설치 |
원격 알림/전파 솔루션 |
| 5 | 공항 내 데이터 센터 서비스는 3Tier로 구성하여 제시해야 한다. | - | IT 인프라 구성 및 유지보수 솔루션 |
| 6 | 모든 인프라는 이중화하여 구성한다. | 3Tier 구성 서버 이중화 네트워크 이중화 스토리지 이중화 |
IT 인프라 구성 및 유지보수 솔루션 |
아래는 강사님 ver.
- 서비스 제안 도출
그럼 이제 '서비스 제안 도출'로 넘어가 보자.
이때는 서비스 구성도와 인프라 구성도를 그리게 된다.
서비스 구성도는 말 그대로 서비스의 설계도를 만드는 단계로,
위의 표를 구체화하는 작업이라고 할 수 있다.
서비스 구성 패턴은 다양하게 만들 수 있다.
이를테면 Client - Logic - Backend의 3Tier로 나눈 구성도도 그릴 수 있고,
Peer-to-Peer 방식의 구성도를 그릴 수도 있겠지.
이번에는 '제공 서비스 - 프로세싱 - 세부 솔루션 - In/Output 수단'으로 이루어진 구성도를 그려 보자.
아래는 위 솔루션 중 1번의 서비스 구성도를 그린 것이다.
하나의 서비스마다 이렇게 그릴 수가 있겠다.
인프라 구성도는 위와 같이 서비스 구성도를 먼저 그린 후,
이를 적절히 꾸민 서비스 배치도를 기반으로 작성하게 된다.
위의 CASE에서 서비스 배치도는
'본사 데이터센터, 모니터링 센터, 사용자 환경'의 세 가지를 그려야 하겠지.
이에 따라 그린 인프라 구성도
수업 내내 복습하느라 정신 없는 실습이었다.
중간부터는 사실 못했지 뭐.
어쨌든 빠진 부분은 따로 연습하도록 하자.
나도 여러분도 화이팅.