소프트웨어: 가상화의 여행 (3) 프로세스 / 스레드

H/W, OS, Virtual Machine, Container 부터 Cloud 까지(3)

8 min readMay 6, 2021

🤔 이 글의 출발점

모든 S/W 는 세단계로 정의할 수 있습니다. Input 값과 Output 값, 그리고 Input 값을 원하는 Output 값으로 만들기 위한 알고리즘으로요!

이런식으로 여러 IT 기술들의 철학, 구성이 하나의 청사진(Blue Print)으로 수렴하는 경우가 많은 것 같습니다. 소프트웨어 시리즈 글은 컴퓨터를 공부하는 분들과 이런 인사이트를 공유하며 함께 생각해보고 싶어 작성했습니다. 그럼 이번 글도 고고띵~
(수정이 필요한 부분은 꼭 알려주시면 감사하겠습니다! 😊)

작업단위가 확장되는 과정 중심으로 보면 좋을 것 같다!![H/W]
- 프로세스와 스레드[Philosophy]
- SOA
- Hierarchical Design[서버 가상화]
- VM
- 컨테이너[마이크로서비스][확장 아키텍처][클라우드 서비스(Azure)]
- VM
- Docker, Container, Kubernetes
- Azure Service Fabric

H/W

프로세스와 스레드

프로그램: 어떤 작업을 위해 실행할 수 있는 파일
프로세스: 컴퓨터에서 연속적으로 실행되고 있는 컴퓨터 프로그램
→ 메모리에 올라와 실행되고 있는 프로그램의 인스턴스
→ 자신만의 Virtual Memory와 Machine State를 가지고 있음
스레드: 프로세스 내에서 실행되는 여러 흐름의 단위
→ 프로세스의 특정한 수행 경로
멀티 스레드를 지원하는 운영체제
→ Resource Allocation의 단위: 프로세스
→ Scheduling의 단위: 스레드
(스레드별로 State 관리, thread control block — 레지스터, Context)

Philosophy

SOA(Service Oriented Architecture)

현대적인 소프트웨어 또는 서비스 개발 패러다임 중 하나
→ 느슨하게 연결된 채, 필요에 따라 커뮤니케이션이 가능한 서비스의 집합

개발 패러다임의 변화
Procedural Oriented → Object Oriented → Component Oriented → Service Oriented
기존의 애플리케이션들의 기능들을 비즈니스적인 의미를 가지는 기능 단위로 묶어서
→ 표준화된 호출 인터페이스를 통해서 서비스라는 소프트웨어 컴포넌트 단위로 재 조합한 후
→ 이 서비스들을 서로 조합(Orchestration)하여 업무 기능을 구현한 애플리케이션을 만들어내는 소프트웨어 아키텍쳐
가트너의 보고서에 따르면 SOA 도입에 따른 비용 절감, 비즈니스 민첩성 제고, IT 환경 변황에 대한 대응력 향상등의 장점이 강조되고 있다.

Hierarchical Design

Complex한 Device를 General 하게 하려면 Hierarchical Design Philosophy를 적용 (ex. Network, I/O device, Memory)
Primitive 한 건 아래 Layer, 위 Layer는 더 큰 단위
각 Layer 는 독립적

VM

하드웨어 스택을 가상화
하이퍼바이저형 가상화 기술: 하나의 하이퍼 바이저 혹은 호스트 OS 위에 여러개의 가상 서버를 만들고, 그 안에 게스트 OS가 탑재된 형태

컨테이너

운영체제 수준에서의 가상화
→ 다수의 컨테이너를 OS 커널에서 직접 구동
컨테이너형 가상화 기술: 하나의 호스트 OS위에 독립된 가상 서버에 해당하는 컨테이너를 여러개 만드는 형태
“애플리케이션과 실행환경”을 “실제 구동환경”으로부터 추상화할 수 있는 논리 패키징 메커니즘을 제공
→ 개발자는 애플리케이션의 로직과 종속 항목에 집중
→ IT 운영팀은 특정 소프트웨어 버전, 개별 앱 구성과 관련한 세부 업무에 시간을 낭비하지 않고 배포 및 관리에 집중
VM과 비교했을 때 장점: 훨씬 작은 단위로 업무를 수행할 수 있음
그 밖의 장점: 다양한 구동환경과 일관성 있는 컨테이너 환경

[ 도커의 구현 기술 ]
도커는 리눅스에서 사용하는 여러 기술들을 응용해서 컨테이너 가상화 구현
→ 리눅스의 호스트 머신 상에서 동작하는 프로세스를 커널 기술을 사용하여 격리시킴
→ 프로세스를 포함한 컨테이너를 하나의 이미지로 만들어 또 다른 OS의 도커 환경에 이식할 수 있다.

Namespaces: 공간 분리&글로벌 리소스를 사용자 자신만 가지고 있는 것처럼 격리
Cgroups(control groups): cpu, cpuset, memory, device 등 그룹화된 리소스 제어
networking: 컨테이너와 호스트(veth), 컨테이너간의 통신(bridge, iptables) 등 컨테이너 안의 프로세스 동작 제어
security: 컨테이너의 프로세스 동작을 컨테이너 내부에만 제한하는 SELinux 등 컨테이넌 내부 프로세스들을 제어

마이크로서비스

등장배경: 비즈니스 특성상 추가되거나 변경이 필요한 시기를 예측하기 어렵다.
마이크로서비스: 독립해서 Deploy 할 수 있는 서비스 단위로 설계된 어플리케이션
“마이크로서비스”로의 변화
1) 컴포넌트: 라이브러리 형태 → 서비스 형태
2) 컴포넌트 상호작용: 인메모리 함수 호출 → 공개된 인터페이스
3) 서비스 인터페이스: 웹 서비스 → REST/HTTP
4) 데이터: 통합된 DB → 서비스 별로 독립된 DB
5) 변경 관리: 릴리즈할 때 변경사항 모아서 개선 → 점진적 개선
6) 장애 대응: 가용성 설계 → Design for failure
7) 인프라 환경: 하나의 프로세스로 여러개의 서비스 기동 → CI/CD
8) 거버넌스: 전체를 표준화한 기술 적용 → 서비스별로 선택
9) 조직: 전문화된 팀으로 분화 및 협력 → crosss functional 한 하나의 팀
10) 조직의 생명주기: 프로젝트의 생명주기 → 서비스의 생명주기

확장 아키텍처

마이크로서비스를 사용자에게 더 투명하게 제공하기 위해 고려해야할 것

Scale Up

기존 시스템에 더 많은 리소스를 추가
→ RAM을 추가하거나 가상 머신에 vCPU를 추가하는 작업
→ 시스템의 중단, 재구성, 인스턴스의 재시작이 필요
시스템의 기존 자원을 더 잘 활용: Concurrency 를 높임

Scale Out

Active Redundancy
→ 중복 시스템에서 모든 서비스는 능동적으로 운영
→ 애플리케이션의 중단 시간이 없음을 보장
Hot Standby(상시대기 서버)
→ 시스템이 다운될때까지 활성화되지 않다가 문제 발생시 전환
→ 신뢰성과 실패 처리를 최대한으로 보장
Read Replicas
→ 많은 읽기 작업에 의존하는 시스템의 응답은 데이터 베이스에 읽기 전용 복제본을 추가해 향상시킴
→ 메인 데이터베이스 노드와 계속해서 동기화
Blue-Green 배포
→ 프로덕션 애플리케이션의 중단시간은 없거나 최소 시간을 보장
장애 모니터링 및 재시작
→ 배포에 있어 중요한 컴포넌트(S/W, H/W)의 실패를 감지하고 조치
캐시
분리
→ 네트워크의 공유된 부분을 가능한 많이 활용하기 위해 컴포넌트 분리
→ 분리에 따라 추가적인 시스템의 구성으로 복잡성이 높아짐(자동화, 미들웨어 등으로 해결)
우아한 감소
→ 요청에 응답하고 타임아웃을 제공하지 못하는 것보다 시스템이 우아하게 저하된 동작을 하도록 해야함(애플리케이션 자체 구성이나 로드밸런서 이용)
데이터를 코드와 밀접하게 유지
→ 계산이 되는 곳에 데이터를 제공하므로 성능을 높임
SLA에 따른 설계
→ 애플리케이션이 사용자에게 제공하는 항목을 이해해야 함

클라우드 서비스(Azure)

Azure VM

공식 문서 보러가기

AzureAzure Kubernetes