[Docker] 시스템과 인프라 기초 지식

1. 시스템 기반의 기초 지식

1) 기능 요구 사항

시스템의 기능으로서 요구되는 사항을 뜻한다. 시스템이나 소프트웨어에서 무엇을 할 수 있는지를 모아놓은 것이다.

2) 비기능 요구 사항

기능 요구 사항 외의 모든 요구 사항으로, 시스템의 성능이나 신뢰성, 확장성, 운용성, 보안 등과 같은 요구 사항이다. 이 요구 사항을 충족하기 위해서는 프로그래밍 지식뿐만 아닌 시스템 기반에 관한 지식이 필요하다.

3) 하드웨어

하드웨어는 시스템 기반을 구성하는 물리적인 요소로 서버 장비나 데이터를 저장하기 위한 스토리지, 전원 장치 등이 있다.

• CPU
• 메모리
• 스토리지

4) 네트워크

네트워크는 시스템 이용자가 원격지에서 액세스 할 수 있도록 서버들을 연결하기 위한 요구 사항이다. 라우터, 스위치, 방화벽 등과 같은 네트워크 장비나 그것들을 연결하기 위한 케이블 배선 등도 관리한다.

• MAC 주소 (물리/이더넷) : 네트워크 부품에 물리적으로 할당되는 48비트 주소이다. (앞 24비트는 제조업체 식별번호)
• IP 주소

 

통신을 할 때는 반드시 상대가 필요하며, 자신과 상대가 서로 이해할 수 있도록 말하기 위해서는 약속이 필요하다. 이러한 약속을 통신 프로토콜이라고 지칭하며 시스템에서 주로 사용하는 통신으로는 웹, 메일 송수신, 파일 전송, SSH, 등이 있다. 이러한 통신 프로토콜을 7개의 계층으로 나누어 정의하는 OSI 참조 모델이 있다.

• 7) 응용 계층 : HTTP나 메일 전송을 하는 SMTP 등과 같은 애플리케이션에 특화된 프로토콜을 정의
• 6) 표현 계층 : 데이터의 저장 형식이나 압축, 문자 인코딩 같은 데이터 표현 형식을 규정
• 5) 세션 계층 : 커넥션 확립 타이밍이나 데이터 전송 타이밍을 규정 (Request, Response)
• 4) 전송 계층 : 데이터 전송을 제어를 규정 (TCP, UDP)
• 3) 네트워크 계층 : 네트워크 간에 통신을 하기 위한 규정 (IP 주소)
• 2) 데이터 링크 계층 : 동일한 네트워크 안에 있는 노드 간의 통신을 규정 (MAC 주소)
• 1) 물리 계층 : 통신 장비의 물리적 및 전기적 특성을 규정 (케이블)

 

시스템을 가동시킬 때 가장 주의해야 하는 점은 보안이다. 보안을 확보하기 위해서는 불필요한 통신을 차단하는 것이며, 이 역할은 방화벽이 제어해준다.

• 패킷 필터형 : 통과하는 패킷을 포트 번화나 IP 주소를 바탕으로 필터링하는 방법 (ACL)
• 애플리케이션 게이트웨이형 : 패킷이 아닌 애플리케이션 프로토콜 레벨에서 외부와의 통신을 대체 제어하는 방법 (프록시 서버)

5) 운영 체제

운영체제는 하드웨어나 네트워크 장비를 제어하기 위한 기본 소프트웨어로, 하드웨어의 리소스나 프로세스를 관리한다. 대표적으로 클라이언트 OS에는 Windows와 MacOS가 있다. 서버 OS의 경우, Windows Server, Unix, Linux 등이 있다. 서버 OS는 시스템을 고속 및 안정적으로 가동시키기 위해 필요한 기능으로 특화되어있다.

 

Linux 커널은 OS의 코어가 되는 부분을 뜻한다. 메모리 관리, 파일 시스템, 프로세스 관리, 디바이스 제어 등 하드웨어나 애플리케이션 소프트웨어를 제어하기 위한 기본적인 기능을 가진 소프트웨어이다. Linux 커널은 하드웨어를 디바이스 드라이버라는 소프트웨어로 제어하고, 여러 프로세스에 PID 식별자를 붙여 관리를 한다. 프로그램 및 데이터를 메모리에 효율적으로 할당하는 역할을 가지고 있으며, 실행이 끝난 프로세스가 사용하던 메모리 영역을 해제하는 역할도 수행한다. 메모리에는 용량의 제한이 있기에 메모리의 물리적인 용량을 초과하는 프로그램 및 데이터를 전개할 경우 하드디스크와 같은 보조기억장치에 가상 메모리 영역(swap)을 만들어 일을 수행한다.

 

Linux 커널의 중요한 기능인 파일 시스템은 하드디스크, USB, CD, DVD 등과 같은 데이터에 액세스하기 위한 장치이다. 이때 Linux 커널은 VFS(Virtual File System) 장치를 이용하여 데이터에 접근한다.

• NFS - /mount
• ext4 - /bin, /home
• ISO-9660 - /cdrom

Linux 디렉토리	설명
/bin	기본 커맨드
/boot	OS 시작에 필요한 파일
/dev	디바이스 파일
/etc	설정 파일
/home	사용자 홈 디렉토리
/lib	공유 라이브러리
/mnt	파일 시스템의 마운트 포인트용 디렉토리
/media	CD/DVD-ROM의 마운트 포인트
/opt	애플리케이션 소프트웨어 패키지
/proc	커널이나 프로세스에 관한 정보
/root	특권 사용자용 홈 디렉토리
/sbin	시스템 관리용 마운트
/srv	시스템 고유의 데이터
/tmp	임시 디렉토리
/usr	각종 프로그램이나 커널 소스를 놓아두는 디렉토리
/var	로그나 메일 등 가변적인 파일을 놓아두는 디렉토리

Linux 보안의 경우 계정에 대한 권한 설정, 네트워크 필터링을 사용한 보안 설정(iptables NAT), SElinux(Security- Enhanced Linux)이 있다. (SElinux는 Linux 커널에 강제 액세스 제어 기능을 추가한 기능)

 

※ Linux 배포판은 Linux 커널과 함께 각종 커맨드, 라이브러리, 애플리케이션이 포함한 패키지이다. (Debian, Red Hat, Slackware 등)

6) 시스템 이용 형태

시스템 이용 형태	설명
온프레미스 (On-premises)	지금까지 기업에서 많이 채택되어 온 형태로, 자사에서 데이터센터를 보유하고 시스템 구축부터 운용까지 모두 수행하는 형태이다. 즉, 기업내에서 직접 서버, 네트워크 장비, OS, 등 모든 시스템 기반의 구성 요소들을 기업에 맞게 구축하는 형태이다.
퍼블릭 클라우드 (Public Cloud)	인터넷을 경우하여 불특정 다수에게 제공되는 클라우드 서비스이다. 기업 내에서 데이터센터를 보유하지 않기 때문에 서버, 네트워크, 등 인프라와 관련된 초기 투자가 필요 없다. 서비스에 따라 IaaS/PaaS/SaaS 등으로 나뉜다.
프라이빗 클라우드 (Private Cloud)	특정 기업 그룹에게만 제공되는 클라우드 서비스이다. 퍼블릭 클라우드는 불특정 다수에 대해 제공되는 데 반해 프라이빗 클라우드는 이용자를 한정할 수 있기에 보안 및 독자적인 기능과 서비스를 추가하기 쉽다.

7) 클라우드에 적합한 경우 vs 온프레미스가 적합한 경우

일반적으로 클라우드가 적합한 시스템으로는 크게 3가지로 나눌 수 있다.

• 트래픽의 변동이 많은 시스템
• 재해 대책으로 해외에 백업을 구축하고 싶은 시스템
• 서비스를 빨리 제공하고 싶은 시스템

 

온프레스 환경이 적합한 환경도 크게 3가지로 나눌 수 있다.

• 높은 가용성이 요구되는 시스템
• 기밀성이 높은 데이터를 다루는 시스템
• 범용적이지 않은 디바이스나 특수한 플랫폼에서만 움직이는 특수한 요구사항이 있는 시스템 (ex. 의료 시스템)

8) 시스템 기반의 구축/운용 흐름

1. 시스템 구축 계획 및 요구사항 정의 단계

• 시스템 구축 범위 선정
• 인프라 요구 사항 정의
• 예산 책정
• 프로젝트 체계화
• 기존 시스템과의 연계
• 시스템 마이그레이션 계획

 

2. 인프라 설계 단계

• 인프라 아키텍처 설계
• 네트워크 토폴로지 설계
• 서비스/장비 선택, 조달
• 서비스/OS, 미들 웨어 선택
• 시스템 운용 설계
• 시스템 마이그레이션 설계

 

3. 인프라 구축 단계

• 네트워크 부설
• 서버 설치
• OS 설정
• 미들웨어 설정
• 애플리케이션 및 라이브러리 설치
• 네트워크 확인, 부하 테스트, 운용 테스트
• 시스템 릴리스 및 마이그레이션

※ 인프라 구축 단계의 경우, 퍼블릭 클라우드에서는 필요 없는 경우가 많다.

 

4. 운용 단계

애플리케이션 개발 공정과는 다르게 운용 단계가 가장 중요하다. 애플리케이션의 경우 제품 환경에 대한 시스템 릴리스 후에는 버그의 수정이나 추가 기능의 개발이 메인이 되어서 개발 인원도 줄어들지만, 인프라의 경우는 릴리스 감시나 보안 대책을 위한 버전 업그레이드, 시스템에 장애가 발생한 경우의 복구 작업 등 많은 업무가 남는다. 따라서 유지보수 기간을 줄이고 시스템을 안정적으로 가동시키기 위한 중요한 단계이다.

• 서버 프로세스, 네트워크, 리소스, 배치 Job 모니터링
• 데이터 백업 및 정기 유지 보수
• OS, 미들웨어 버전 업그레이드
• 애플리케이션 버전 업그레이드
• 시스템 장애 시 대응
• 사용자 서포트(헬프 데스크)

 

 

 

2. 미들웨어 기초 지식

1) 웹 서버, 웹 애플리케이션 서버

웹 서버는 클라이언트의 브라우저가 보내온 HTTP 요청을 받아 웹 콘텐츠(HTML, CSS, 등)를 응답으로 반환하거나 다른 서버사이드 프로그램의 호출하는 기능을 가진 서버이다. (Apache, Nginx)

2) 데이터베이스 서버

데이터베이스 서버는 시스템이 생성하는 데이터를 관리하기 위한 미들웨어이다. 대표적으로는 MySQL, PostgreSQL, Oracle 데이터베이스가 있다. NoSQL의 경우 관계형 데이터베이스와는 다르게 병렬분산처리나 유연한 스키마 설정 등이 특징으로, KVS(Key-Value Store) 혹은 도큐먼트 지향 데이터베이스, XML 데이터베이스 등이 있다. 다수의 사용자 액세스를 처리할 필요가 있는 온라인 시스템 등에서 널리 이용하고 있다. (Redis, MongoDB)

3) 시스템 감시 툴

시스템이 릴리스되면 인프라 운용 관리 업무가 시작되는데, 이 때 서버나 장비의 상태를 안정적으로 가동하기 위해 감시해야한다. 대표적으로는 Zabbix, Datadog, Mackerel 툴이 있다.

 

 

 

3. 인프라 구성 관리 기초 지식

1) 인프라 구성 관리

인프라 구성 관리는 인프라를 구성하는 하드웨어, 네트워크 OS 미들웨어, 애플리케이션의 구성 정보를 관리하고 적절한 상태로 유지하는 작업을 뜻한다. 온프레미스 환경에서는 장비뿐만 아닌 OS나 미들웨어 제조업체의 유지보수 기간도 있기에 버전업이나 실제 운용 시의 트래픽에 맞춰 퍼포먼스 튜닝이 필요하다.

 

반면 클라우드의 경우에는 다양한 분산 기술로 인해 인프라 구축에서 물리적인 제약이 없어졌으며 서버나 네트워크를 구축하거나 손쉽게 파기할 수 있는 환경을 갖추었다. 이처럼 한번 구축한 인프라는 변경하지 않고 파기한 후 새롭게 구축하면 되기에 부하가 컸던 인프라의 변경 이력을 관리할 필요가 없어진다.

2) 코드를 사용한 구성 관리

만약 여러 대의 서버를 한 대 씩 수작업으로 설정하여 관리하는 것은 비효율적이다. 이러한 번거로운 작업을 해결하기 위해서, 프로그램 코드에 적혀 있는 내용대로 자동으로 설정을 해주는 장치를 도입하여 그 프로그램을 누가 실행해도 똑같은 상태의 인프라 환경을 구축할 수 있는 환경을 도입할 수 있도록 한다. 도커에서는 Dockerfile로 인프라 구성 정보를 기술한다.

3) 인프라 구성 관리 툴

인프라 구성 관리를 자동으로 관리하는 툴은 네트워크나 OS를 포함하는 서버의 구성을 자동으로 구축 및 관리하는 것부터 OS나 미들웨어의 정의 파일을 자동으로 작성하는 것, 여러 서버에 대해 애플리케이션 일괄 배포나 통합 관리를 하는 툴까지 다양하다.

 

OS의 시작(설치 및 설정)을 자동화하는 툴로는 Red Hat 계열 Linux 배포판에서 이용할 수 있는 'KickStart'나 로컬 PC에 가상 환경을 만들 기 위한 'Vagrant'가 있다. OS나 미들웨어의 설정(설치 및 버전 관리)을 자동화하는 툴은 Unix 계열 OS의 '/etc' 하위에 있는 OS나 미들웨어 설정 파일이나 OS의 방화벽 기능의 설정 등 보안과 관련된 설정을 자동화해준다. 대표적으로 Chef사가 제공하는 오픈소스 Ruby에 의한 인프라 구성 관리 툴인 'Chef'나 'Ansible'이 있다. 대규모 시스템 환경에서의 여러 서버의 관리를 자동화하는 툴로는 'Kubernetes'가 컨테이너 가상 환경에 있어서 여러 컨테이너를 통합 관리하는 툴이 있다. Kubernetes는 도커의 이미지 캐릭터인 컨테이너를 실은 고래의 키를 잡듯이 여러 컨테이너를 효율적으로 관리할 수 있다.

3) 지속적 인티그레이션/딜리버리

애플리케이션의 코드를 추가 및 수정할 때마다 테스트를 실행하고 확실하게 작동하는 코드를 유지하는 방법을 지속적 인티그레이션이라고 한다. 소프트웨어의 품질 향상을 목적으로 고안된 개발 프로세스로 단위 테스트를 자동화하기 위한 Jenkins와 같은 툴을 사용한다. 그리고 인프라 구성에 관한 부분을 코드로 관리한다면 동일한 환경에서 여러 개발자들이 일을 하는데 편리해진다.

 

애플리케이션 개발에서 사용자가 원하는 니즈를 모두 한번에 수용하여 배포하는 것은 힘들기 때문에 이용자의 요구에 따른 기능을 추가할 때마다 애플리케이션을 제품 환경에 배포하고 시스템 이용자의 피드백에 기초하여 그 다음에 개발할 기능을 결정하는 애자일형 개발 스타일이 생겼다. 즉, 개발 범위를 작게하기 때문에 지속적 딜리버리라고 한다.

 

버전업의 경우에는 엔지니어에게 있어서 가장 큰 이벤트 중 하나이다. 따라서 일반적으로 사용자에게 미치는 영향이 적은 시간에 버전업을 수행하지만 애플리케이션을 테스트 환경에 도입하는 절차와 제품환경에 도입하는 절차가 동떨어지면서 문제가 발생한다. 이러한 문제는 코드로 관리하여 인프라 환경도 포함한 테스트가 끝난 애플리케이션 실행 환경을 그대로 제품 환경에 전개할 수 있다면 더욱 안전하게 버전업을 실시할 수 있다. 클라우드 환경의 배포일 경우 블루 그린 디플로이먼트 방법을 사용한다. 현재 작동하고 있는 시스템(블루)와 버전업 후의 시스템(그린)을 동시에 작동시킨 상태에서 시스템을 전환하여 버전업 후 시스템의 애플리케이션에 문제가 있ㅇ면 바로 현행 시스템으로 되돌리는 방법이 있다.

---

[참고] 완벽한 IT 인프라 구축을 위한 Docker (2판)