그림으로 공부하는 IT 인프라 구조 [아키텍처, 물리서버, 3계층 시스템, 기본이론]

[1장] 인프라 아키텍처를 살펴보자

아키텍처 종류

• 집약형 아키텍처: 하나의 컴퓨터(메인 프레임, 호스트, 범용장비)로 시스템 구성
• 분할형 아키텍처: 여러 컴퓨터로 시스템 구성
  • 수직분할: 각각의 서버가 전혀 다른 역할을 함. (ex. 웹서버 - AP서버 - DB서버)
  • 수평분할: 각각의 서버가 같은 일을 함. 
    • 단순 수평분할형: 이를테면 사용자 ID기준으로 서버 분할 (ex. sharding, partitioning)
    • 공유형: 소마 백엔드와 같은 형태
  • 지리분할: 고가용성을 위함
    • 스탠바이형: 액티브-스탠바이 구성. 고장 시 failover.
    • 재해대책형: 예를들어 목동 IDC, 안양 IDC 구분한 것

 

 

---

[2장] 서버를 열어보자

물리서버, CPU, 메모리, 버스..

I/O장치

스토리지(저장소): HDD가 많이 탑재돼 있는 하드웨어. I/O의 서브시스템이라고도 불림. 내부에 CPU, 캐시, 기타등등 존재하여 HDD외에도 많은 기능 탑재.

• SAN: 대형 스토리지와 연결할 때는 Fibre Channel이라는 케이블을 사용해서 SAN(storage area network)라는 네트워크를 경유. 서버 시스템 포트에 FC포트가 없기 때문에 PCI(외부연결제어 버스) 슬롯에 HBA라는 카드를 삽입하고 HBA의 FC포트를 활용함.
• NAS, network attached storage: HBA대신 NIC, SAN스위치대신 네트워크 스위치. NFS 프로토콜 사요

 

네트워크 인터페이스: 서버와 외부장비를 연결하기 위한 외부 접속용 인터페이스. (ex. LAN어댑터, SAN어댑터)

 

 

 

---

[3장] 3계층형 시스템을 살펴보자

3계층형 시스템, 프로세스/스레드, 커널, 웹데이터 흐름 

 

장치드라이버: 커널의 역할 중 하나. 디스크나 NIC등의 물리장치용 인터페이스 제공.

 

AP서버가 DB서버에 접속하려면 드라이버가 필요하다. 커널의 장치 드라이버와 비슷하다. 드라이버 뒷단에 있는 것이 DB로 가는 인터페이스로, 해당 DB를 은폐하는 역할을 한다.

 

시스템에 어느 정도의 요청이 올지는 실제 요청이 오기 전까지는 알 수 없다. 이것이 IT인프라에서 성능 문제가 발생하는 이유 중 하나.

{TODO: 8장에서 소개하는 성능 관점의 설명을 읽을 때 이 본질을 염두)

 

가상화

OS도 하드웨어를 의식하지 않고 애플리케이션을 실행할 수 있게 한다는 점에서 가상화 기술 중 하나.

 

가상머신

각 게스트가 각각 커널공간을 가진다.

하이퍼바이저: VM을 생성하고 구동하는 SW

• 호스트 OS형
  • 윈도우나 리눅스 등의 호스트 OS상에 가상화 SW(하이퍼바이저)를 설치해서 이용. (ex. VMware Server, MS Virtual Server, Oracle VirtualBox)

• 하이퍼바이저형
  • 하드웨어상에서 직접 가상화 소프트웨어를 실행하고 그 위에 가상머신을 동작시킴. (ex. KVM, Hper-V, Xen, vSphere)
  • 호스트 OS를 거치지 않으므로 성능 우수함.
  • 완전가상화 구조: (Redhat KVM)
    • pros: 물리 머신상에서 동작하는 OS나 드라이버를 그대로 게스트로 이용할 수 있음
    • cons: 물리 머신상에서 동작하는 OS나 드라이버를 소프트웨어로 에뮬레이션하기 때문에 성능이 저하됨
  • 준가상화 구조: 실존하는 하드웨어를 에뮬레이션하는 것이 아니라, 가상환경용 가상 하드웨어를 소프트웨어적으로 에뮬레이션한다. 

컨테이너

리소스가 격리된 프로세스. 독립된 file system, CPU/메모리/GPU, 프로세스 공간. 각 컨테이너가 커널 공간을 공유한다. 

 

프로세스가 OS의 루트 디렉터리 아래에 있는 특정 계층에 접근하지 못하도록 하는 기능인 chroot가 컨테이너 기술의 시발점.

 

컨테이너 vs VM

컨테이너와 VM 둘 다 얄팍하게 사용해본 결과, 컨테이너가 VM의 상위호환격인 기술인 것 같은데 왜 아직도 VM을 쓰는거지? 라는 의문이 들어서 각각 언제 쓰는지, 활용성 면에서 비교해봤다.

 

https://www.vmware.com/topics/glossary/content/vms-vs-containers.html

https://www.docker.com/blog/vm-or-containers/

https://www.redhat.com/ko/topics/virtualization/what-is-a-hypervisor

https://www.redhat.com/ko/topics/containers/containers-vs-vms

 

위 내용을 대충 가져다 보자면,

 

 VM은 조직이 서버를 더 확보하고 제한된 업무량을 효율적으로 활용하도록 해서 infrastructure문제를 해결한다. 반면, 컨테이너는 devOps를 발전시키고, microservice를 가능케하며, portability를 증가시키고 자원 활용을 더 잘하도록 해서 application 문제를 해결한다.

 

도커의 핵심은 애플리케이션을 빠르고 유연하게 전달하는 것이다.

 

이상적으로, 컨테이너 기반 애플리케이션은 stateless microservice로서 전달돼야 한다. 반면에 vm은 monolithic model에 더 적합하다.

 

컨테이너는 경우에 따라 하이퍼바이저의 대안으로 여겨지기도 하지만, 컨테이너와 가상화는 각기 다른 요구 사항을 충족하므로 확실히 그렇다고 할 수는 없습니다.

 

VM은 시스템의 나머지 부분과 분리된 환경을 제공하므로 VM 내에서 어떤 대상이 실행되든 호스트 하드웨어에서 실행되는 다른 대상을 방해하지 않습니다. VM은 분리되어 있기 때문에 VM이 손상되더라도 전체 시스템에는 영향을 미치지 않습니다. 

 

기존 IT 아키텍처(모놀리식 및 레거시)는 워크로드의 모든 측면을 하나의 큰 파일 형식으로 분할할 수 없기 때문에 주로 VM과 같은 대규모 환경 내에서 전체 유닛으로 패키징해야 합니다. 

 

컨테이너는 다음 용도에 가장 적합합니다.

• 클라우드 네이티브 애플리케이션 빌드
• 마이크로서비스 패키징
• DevOps 또는 CI/CD 프랙티스 촉진
• 동일한 OS를 공유하는 다양한 IT 설치 공간에서 확장 가능한 IT 프로젝트로 전환

VM은 모놀리식 워크로드 패키징에 사용되는 기존 방식(현재도 이렇게 패키징되고 있음)인 단일 컨테이너보다 훨씬 더 많은 작업을 실행할 수 있습니다. 하지만 이처럼 확장된 기능으로 인해 OS, 애플리케이션, 라이브러리에 의존하게 되어 VM의 이식성이 크게 저하됩니다. 컨테이너와 비교해 VM은 다음 용도에 가장 적합합니다.

• 기존, 레거시 및 모놀리식 워크로드 수용
• 위험한 개발 사이클 분리
• 인프라 리소스(예: 네트워크, 서버, 데이터) 프로비저닝
• 다른 OS에서 또 다른 OS 실행(예: Linux에서 Unix 실행)

 

{TODO: 밑줄친 부분 외에 container로 대체불가한 VM만의 쓰임이 있는지?)

 

 

---

[4장] 인프라를 지탱하는 기본 이론

직렬/병렬, 동기/비동기, stateful/stateless, 가변길이/고정길이, 자료구조..

 

배타적 제어 Exclusive Control

 

Latch(spin-lock): 짧은 시간 동안만 lock을 유지. 반복문사용하여 대기. 상황에 따라 스핀할지 슬립할지 판단하는 adaptive-lock방식도 존재. 슬립하면 context switch 발생하므로 극히 단시간 락에선 스핀락 사용함. (ex. DBMS에서 사용)

 

BKL(Big Kernel Lock): 리눅스 커널은 BKL이라는 하나의 스핀락으로 유지됨. 동시에 하나의 CPU만 커널 코드 실행 가능. 병목 지점이 되기 쉽다.

 

 

 

---

TIPS

엣지 컴퓨팅: 지리적으로 가까운 위치에 있는 서버로 처리를 분산하고, 처리결과만 중앙으로 보내는 아키텍처

 

SSD의 연결규격: 

• SATA(Serial ATA)
• SAS(Serial SCSI)
• NVMe(NVM Express, 최신)

SSH는 stateful 프로토콜, HTTP는 stateless 프로토콜.