완벽한 IT인프라 구축을 위한 Docker.md

서평

• 최근에 클라우드가 부상하면서 도커와 쿠버네티스에 대한 수요가 증가하여 호기심이 생겼고 데이터엔지니어 업무르 하는데 있어서 인프라 기초 지식이 필요로 하여 책을 읽게 되었습니다.
• 시스템과 인프라의 기초 지식, 클라우드와 온프레미스의 차이점이 무엇인지 특징들은 무엇인지, 컨테이너 기술과 운용 관리하는 법에 대해, 도커를 직접 실습을 하면서 산출물을 확인할 수 있는게 매력적이였습니다.
• Docker 환경에서 동일 호스트상에 Docker를 설치하고, 그 위에서 몇 개의 컨테이너를 가동시켜 서버를 작동, 이미지의 작성이나 컨테이너의 시작 등은 호스트 머신에 설치된 Docker가 수행하고, 여러 개의 Docker를 일원 관리할 때는 Docker Compose를 사용하여 애플리케이션의 실행 환경을 구축하면서 도커 컨테이너의 전반적인 틀을 다룰 수 있어서 좋았습니다.
• 다양한 전문가들이 시스템 릴리스 후에도 리소스 감시나 데이터의 백업, 장애 감시, 복구 대응 등 사용자가 쾌적하게 시스템을 이용할 수 있도록 시스템을 운용하는 업무를 하고 있다면 이 책을 읽고 인프라에 대한 전체적인 구성에 대해 배우며 도커와 쿠버네티스가 왜 요즘 뜨고있는지에 대해 다시한번 생각을 할 수 있는 기회가 되는거 같습니다.

시스템과 인프라 기초 지식

시스템 기반의 기초 지식

• 시스템 기반
  • 애플리케이션을 가동시키기 위해 필요한 하드웨어나 OS/미들웨어 등과 같은 인프라
• 도커 : 애플리케이션 실행 환경을 작성 및 관리하기 위한 플랫폼
• 시스템 기반의 구성 요소
  • 기능 요구사항(fuctional requirement)
    • 시스템의 기능으로서 요구되는 사항
    • 시스템이나 소프트웨어에서 무엇을 할 수 있는지를 모아놓은 것
  • 비기능 요구사항(non-functional requirement)
    • 시스템의 성능이나 신뢰성, 확장성, 운용성, 보안 등과 같은 요구사항
  • 하드웨어
    • 시스템 기반을 구성하는 물리적인 요소로서 서버 장비 본체나 데이터를 저장하기 우히ㅏㄴ 스토리지, 전원장치
  • 네트워크
    • 시스템 이용자가 원격지에서 액세스할 수 있도록 서버들을 연결하기 위한 요구사항
  • OS(운영체제)
    • 하드웨어나 네트워크 장비를 제어하기 위한 기본 소프트웨어로, 하드웨어의 리소스나 프로세스를 관리함
  • 미들웨어
    • 서버 OS 상에서 서버가 특정 역할을 다하기 위한 기능을 갖고 있는 소프트웨어
• 클라우드와 온프레미스
  • 온프레미스(on-premises)
    • 자사에서 데이터센터를 보유하고 시스템 구축부터운용까지 모두 수행하는 형태
    • 시스템 기반의 구성 요소인 서버나 네트워크 장비를 모두 자사에서 직접 조달하여 시스템 요구사항에 맞춰 인프라를 구축하고 자사(또는 관련 시스템 자회사 등)에서 운용
    • 하드웨어뿐만 아니라 OS나 미들웨어도 모두 자사에서 구입하며, 라이선스 관리나 버전업도 자사에서 함
    • 초기 시스템 투자에 드는 비용 부담이 크며, 시스템 가동 후의 운용에 드는 비용도 시스템 이용량과 상관없이 일정 금액을 부담해야함
  • 퍼블릭 클라우드(public cloud)
    • 인터넷을 경유하여 불특정 다수에게 제공하는 클라우드 서비스
  • 프라이븟 클라우드(private cloud)
    • 특정 기업 그룹에게만 제공되는 클라우드 서비스
• 클라우드가 적합한 케이스
  • 트래픽의 변동이 많은 시스템
    • 사이징(sizing) : 트래픽 양에 따라 시스템 기반의 서버 사양이나 네트워크 대역을 가늠하는 설계
    • 오토스케일 : 시스템 부하에 맞춰 동적으로 서버 사양이나 스토리지 용량을 쉽게 증설시킬 수 있음, 시스템 사용량이 적을 때는 사양을 낮춤으로써 쓸데없는 시스템 투자를 줄임
  • 재해 대책으로 해외에 백업을 구축하고 싶은 시스템
    • 업무 연속성 계획
      • 재해와 같은 리스크가 발생했을 때 기간 업무를 중단하지 않거나 기간 업무가 중단된 경우라도 목표로 하는 복구 기간 안에 중요한 기능을 재개시켜, 사업 중단이 야기하는 리스크를 최소한으로 하기 위해 미리 준비해 두는 계획을 업무 연속성 계획(BCP)라고 함
  • 서비스를 빨리 제공하고 싶은 시스템
• 온프레미스가 적합한 케이스
  • 높은 가용성이 요구되는 시스템
  • 기밀성이 높은 데이터를 다루는 시스템
  • 특수항 요구사항이 있는 시스템

하드웨어와 네트워크 기초 지식

• 서버 장비
  • CPU
    • 프로그램의 설계나 처리 등을 수행하는 전자회로 부품
    • GPU(Graphics Processing Unit) : 화상 처리를 여러 개의 코어로 동시 및 병렬로 처리할 수 있는 프로세서
  • 메모리
    • CPU가 직접 액세스할 수 있는 기억장치를 메모리(주기억장치)
  • 스토리지
    • 데이터베이스에 기록하는 데이터 등과 같은 영구적인 데이터를 저장하는 디바이스, 보조 기억장치
• 네트워크 주소
  • MAC 주소(물리 주소/이더넷 주소)
    • 네트워크 인터페이스 카드나 무선 LAN 칩과 같은 네트워크 부품에 물리적으로 할당되는 48비트 주소
  • IP 주소
    • 인터넷이나 인트라넷과 같은 네트워크에 연결된 컴퓨터나 네트워크 장비에 할당되는 식별 번호
• OSI 참조 모델과 통신 프로토콜
  • 통신 프로토콜 : 서로 어떤 약속으로 통신을 할지를 정한 규약
• 방화벽
  • 패킷 필터형
  • 애플리케이션 게이트웨이형

OS(Linux) 기초 지식

• 하드웨어나 네트워크를 제어하는 것이 OS의 역할
• Linux
  • 보안에 뛰어나며 안정적으로 작동된다는 특징을 갖고 있기 때문에 각종 서버에서 널리 이용됨
  • Linux 커널
    • OS의 코어가 되는 부분
    • 메모리 관리, 파일 시스템, 프로세스 관리, 디바이스 제어 등 OS로서 하드웨어나 애플리케이션 소프트웨어를 제어하기 위해 기본적 기능을 갖고 있는 소프트웨어
    • 하드웨어(CPU/메모리/디스크/입출력 장치 등)를 디바이스 드라이버라는 소프트웨어를 이용하여 제어함
  • Linux 배포판
    • Linux는 Linux배포판이라는 형태로 패키지화되어 배포됨
    • Linux 커널과 함께 각종 커맨드, 라이브러리, 애플리케이션이 포함됨
  • 주요 디렉토리

    이름	설명
    /bin	ls커맨드나 cp 커맨드와 같은 기본 커맨드를 저장하는 디렉토리, 특권 사용자, 일반사용자 모두 이용하는 명령들이 배치되어 있음
    /boot	Linux 커널 등 OS의 시작에 필요한 파일을 배치하는 디렉토리, Linux 커널의 정체는 vmlinuz라는 이름의 파일
    /dev	하드디스크,키보드,디바이스 파일을 저장하는 디렉토리
    /etc	OS나 애플리케이션이 작동하는 데 필요한 설정 파일이 저장되어 있는 디렉토리
    /home	일반 사용자의 홈 디렉토리, 시스템 이용자가 자유롭게 사용할 수 있는 디렉토리, 독자적인 쉘 설정 파일 등도 여기에 배치할 수 있음
    /proc	커널이나 프로세스에 관한 정보가 저장되어 있는 디렉토리
    /tmp	일시적으로 사용하는 파일 등을 저장하는 임시 디렉토리
    /usr	각종 프로그램이나 커널 소스가 저장되는 디렉토리
    /var	시스템의 가동과 함께 변화하는 파일을 놓아두는 디렉토리

미들웨어 기초 지식

• 미들웨어
  • OS와 업무 처리를 수행하는 애플리케이션 사이에 들어가는 소프트웨어
  • OS가 갖고 있는 기능을 확장한 것, 애플리케이션에서 사용하는 공통 기능을 제공하는 것, 각종 서버 기능을 제공하는 것 등 목적과용도에 따라 폭넓은 종류가 이용됨
• 웹 서버 / 웹 애플리케이션 서버
  • Apache HTTP Server
    • 오픈소스 웹 서버, 소규모 웹 사이트부터 대규모 업무 시스템까지 폭넓게 이용됨
  • Internet InformationServices
    • Microsoft가 제공하는 웹 서버,업무 시스템 등에서 주로 이용되고 있으며, GUI 관리 툴로 설정이나 관리를 할 수 있음
  • Nginx(엔진엑스)
    • 오픈소스 웹 서버, 소비 메모리가 적으며 리버스 프록시 기능과 로드밸런서 기능도 갖고 있는 것이 특징
• 데이터베이스 서버
  • NoSQL
    • 병렬분산처리나 유연한 스키마 설정 등이 특징으로 주요 방식으로는 KVS(Key-Value 스토어)나 도규먼트 지향 데이터베이스(도규먼트 데이터베이스), XML 데이터베이스 등이 존재
    • 대량의 데이터 축적이나 병렬처리가에 뛰어나기 때문에 다수의 사용자 액세스를 처리할 필요가 있는 온라인 시스템 등에서 널리 이용됨
      • Redis
        • 메모리상에서 KVS를 구축할 수 있는 OSS의 NoSQL, 메인 메모리상에 KVS를 구축하여 애플리케이션에서 데이터의 저장과 읽기를 할 수 있음, 메모리상의 데이터는 정기적으로 백업되지만 데이터가 갱신될때마다 기록되는 것은 아니기 때문에 예상치 못한 전원 차단이 있으면 데이터가 손실되는 경우도 있음
      • MongoDB
        • 도규먼트라는 구조적 데이터를 콜렉션으로 관리하는 OSS의 NoSQL, 도규먼트에는 복잡한 계층 구조를 가지게 할 수 있어서 그러한 구조에 포함되는 필드를 지정하는 쿼리나 인덱스의 생성이 가능
      • Apache Cassandra
        • 하나의 Key에 대해 여러 개의 칼럼을 가지고, 관계형 테이블에 가까운 데이터 구조를 갖고 있는 OSS의 NoSQL
• 시스템 감시 툴
  • Zabbix(자빅스)
    • Zabbix SIA가 개발한 통합운용 관리 툴. 다양한 서버의 상태를 감시및 추적하기 위한 오픈소스 소프트웨어
  • Datadog
    • Datadog가 개발한 서버 통합감시용 SaaS, Mackerel과 마찬가지로 통합감시 서버를 도입할 필요 없이 웹 브라우저에서 통합감시를 할 수 있는 서비스.클라우드 및 온프레미스가 혼재한 환경도 손쉽게 감시할 수 있는 것이 특징
  • Mackerel(매커럴)
    • Hatena가 개발한 서버 통합감시용 SaaS. 통합감시 서버를 도입할 필요 없이 웹 브라우저에서 통합감시할 수 있는 서비스. 클라우드상의 서버 감시와 친화성이 높으며, 감시 대상인 서버에 에이전트를 설치하기만 하면 간편히 감시

인프라 구성 관리 기초 지식

• 인프라구성 관리
  • 인프라를 구성하는 하드웨어, 네트워크, OS, 미들웨어, 애플리케이션의 구성정보를 관리하고 적절한 상태로 유지하는 작업
• 지속적인티그레이션(Continuous Integration)
  • 애플리케이션의 코드를 추가 및 수정할 때마다 테스트를 실행하고 확실하게 작동하는 코드를 유지하는방법
  • 소프트웨어의 품질향상을 목적으로 고안된 개발 프로세스
  • 단위 테스트
    • 소프트웨어의 특정 부품에 대해 사양서에 정해진 대로 작동하는지를 확인하는 테스트
• 지속적 딜리버리
  • 폭포형 애플리케이션 개발
    • 요건 정의 -> 설계 -> 코딩 -> 테스트라는 프로세스를 거쳐 애플리케이션의 개발을 끝낸 후에 제품 환경에 애플리케이션을 배포(deploy)하여 서비스를 릴리스함
    • 기능을 추가할 때마다 애플리케이션을제품 환경에 배포하고, 시스템 이용자의 피드백에 기초하여 그 다음에 개발할 기능을 결정한다는 애자일형 개발 스타일
    • 블루 그린 디플로이먼트
      • 클라우드 환경에 대한 배포
      • 현재 작동하고 있는 시스템(블루)과 버전업 후의 시스템(그린)을 동시에 작동시킨 상태에서 시스템을 전환하여, 만일 버전업 후 시스템의 애플리케이션에 문제가 있으면 바로 현행 시스템을 되돌린다

컨테이너 기술과 Docker의 개요

컨테이너 기술의 개요

• 컨테이너
  • 호스트 OS상에 논리적인 구획(컨테이너)를 만들고, 애플리케이션을 작동시키기 위해 필요한 라이브러리나 애플리케이션 등을 하나로 모아, 마치 별도의 서버인 것처럼 사용할수 있게 만든 것
  • 호스트 OS의 리소스를 논리적으로분리시키고, 여러 개의 컨테이너가 공유하여 사용함
  • 컨테이너는 오버헤드가 적기 때문에 가볍고 고속으로 작동한다는 것이 특징
• 호스트형 서버가상화
  • 하드웨어 상에 베이스가 되는 호스트 OS를 설치하고, 호스트OS에 가상화 소프트웨어를 설치한 후, 이 가상화 소프트웨어 상에서 게스트 OS를 작동시키는 기술
  • 호스트 OS 상에서 다른 게스트 OS를 움직이고 있기 때문에 오버헤드가 커짐
    • 오버헤드 : 가상화를 수행하기 위해 필요한 CPU 자원, 디스크 용량, 메모리 사용량 등
• 하이퍼바이저형 서버 가상화
  • 하드웨어 상에 가상화를 전문으로 수행하는 소프트웨어인 하이퍼바이저를 배치하고 하드웨어와 가상환경을 제어함

도커의 개요

• 도커
  • 애플리케이션의 실행에 필요한 환경을 하나의이미지로 모아두고, 그 이미지를 사용하여 다양한 환경에서 애플리케이션 실행 환경을 구축 및 운용하기 위한 오픈소스 플랫폼
  • 스테이징 환경 : 지속적 딜리버리가 일어나는 시스템 개발에서 개발한 애플리케이션을 제품 환경에 전개하기 직전에 확인하는 테스트 환경
  • 웹 시스템 개발 시 애플리케이션을 제품 환경에서가동시키기 위해 필요한 요소
    • 애플리케이션의 실행 모듈(프로그램 본체)
    • 미들웨어나 라이브러리군
    • OS/네트워크 등과 같은 인프라 환경 설정
  • 애플리케이션의 실행에 필요한 모든 파일 및 디렉토리들을 컨테이너로서 모아버리는것
  • 이식성 : 한 번 만들면 어디서든지 움직이는 소프트웨어의 특성
• 도커의 기능
  • 도커 이미지를 만드는 기술(Build)
    • 애플리케이션의 실행에 필요한 프로그램 본체, 라이브러리, 미들웨어, OS나 네트워크 설정 등을 하나로 모아서 Docker 이미지를 만듬
    • Docker 이밎는 실행 환경에서 움직이는 컨테이너 바탕이 됨
  • 도커 이미지를 공유하는 기능(Ship)
    • 도커 이미지는 도커 리지스트리에서 공유
  • 도커 컨테이너를 작동시키는 기능(Run)
    • 도커는 리눅스 상에서 컨테이너 단위로 서버 기능을 작동
    • 도커 이미지만 있으면 도커가 설치된 환경이라면어디서든지 컨테이너를 작동시킬 수 있음
    • 도커 이미지를 가지고 여러개의 컨테이너를 가동시킬 수 있음
• 도커 에디션
  • Docker Community Edition(CE)
    • 도커 컨테이너에서 작동하는 애플리케이션을 구축 및 테스트, 실행하기 위한 툴을 중심으로 멀티호스트 환경에서 환경 구축을 하는 툴들이 제공됨
  • Docker Enterprise Edition(EE)
    • 도커 사가 지원하고 상용 이용에 적합한 에디션
• 도커 컴포넌트
  • Docker Engine(도커의 핵심기능)
    • 도커 이미지를 생성하고 컨테이너를 기동시키기 위한 도커의 핵심 기능
  • Docker Registry(이미지 공개 및 공유)
    • 컨테이너의 바탕이 되는 도커 이미지를 공개 및 공유하기 위한 레지스트리 기능
  • Docker Compose(컨테이너 일원 관리)
    • 여러 개의 컨테이너 구성 정보를 코드로 정의하고, 명령을 실행함으로써 애플리케이션의 실행환경을 구성하는 컨테이너들을 일원 관리하기 위한 툴
  • Docker Machine(Docker 실행 환경 구축)
    • 로컬 호스트용인 VirtualBox를 비롯하여 Amazon Web Services EC2나 Microsoft Azure와 같은 클라우드 환경에 Docker의 실행 환경을 명령으로 자동 생성하기 위한 툴
  • Docker Swarm(클러스터 관리)
    • 여러 Docker 호스트를 클러스터화하기 위한 툴
    • 클러스터를 관리하거나 API를 제공하는 역할은 Manager가, Docker 컨테이너를 실행하는 역할은 Node가 담당, 오픈소스인 Kubernetes도 이용할 수 있음

도커의 작동 구조

• namespace : 컨테이너를 구획화하는 장치
  • 도커는 컨테이너라는 독립된 환경을 만들고, 그 컨테이너를 구획화하여 애플리케이션의 실행 환경을 만듬
  • PID namespace
    • PID : 리눅스에서 각 프로세스에 할당된 고유한 ID
  • Network namespace
    • 네트워크 디바이스 , IP주소, 포트 번호, 라우팅 테이블, 필터링 테이블 등과 같은 네트워크 리소스를 격리된 namespace마다 독립적으로 가질 수 있음
  • UID namespace
    • UID(사용자 ID), GID(그룹 ID)를 namespace별로 독립적으로 가질 수 있음
  • Mount namespace
    • 리눅스에서 파일 시스템을 사용하기 위해서는 마운트가 필요
  • UTS namespace
    • namespace별로 호스트명이나 도메인명을 독자적으로 가질 수 있음
  • IPC namespace
    • 프로세스 간의 통신(IPC) 오브젝트를 namespace별로 독립적으로 가질 수 있음
• cgroups : 릴리스 관리 장치

Dockerfile

• 베이스가 되는 이미지에 각종 미들웨어를 설치 및 설정하고, 개발한 애플리케이션의 실행 모듈을 전개하기 위한 애플리케이션의 실행 기반의 모든 구성 정보를 기술
• 인프라 구성을 기술한 파일
• Docker 상에서 작동시킬 컨테이너의 구성 정보를 기술하기 우히ㅏㄴ 파일
• Docker build 명령은 Dockerfile에 기술된 구성 정보를 바탕으로 Docker 이미지를 작성
• 패키지 관리 시스템
  • 애플리케이션 설치 시에 발생하는 의존 관계를 모아서 관리하는 시스템
    • 의존관계 : 어떤 애플리케이션을 작동시키기 위해 다른 애플리케이션이 필요해지는 관계
  • YUM(Yellowdog Updater Modified)
    • CentOS나 Fedora와 같은 Red Hat 계열 디스트리뷰션에서 이용하는 패키지 관리 시스템
    • yum 명령을 사용하여 리포지토리에서 패키지를 다운로드하여, 애플리케이션의 설치, 설치 해제, 업데이트 등을 수행
  • API(Advanced Packaging Tool)
    • Debian이나 Ubuntu와 같은 Debian 계열 디스트리뷰션에서 이용하는 패키지 관리 시스템
    • 리포지토리로부터 패키지를 다운로드하여, 애플리케이션의 설치, 설치 해제, 업데이트 등을 수행
    • 패키지의 의존 관계를 모아서 관리

Docker 이미지 공개

• Automated Build
  • Docker Hub에는 버전 관리 툴인 Github 및 Bitbucket과 연결하여 Dockerfile로부터 Docker 이미지를 자동으로 생성하는 기능
  • Github 또는 Bitbucket에서 관리되는 Dockerfile을 바탕으로 Docker 이미지를 자동으로 빌드하는 기능
    • Bitbucket
      • Atlassian이 제공하는 버전 관리를 위한 리포지토리 서비스
    • git
      • 프로그램의 소스코드 등의 변경 이력을 기록 및 추적하기 위한 분산형 버전 관리 시스템
    • GitHub
      • Git을 이용하여 인터넷상에 프로그램 코드 등을 저장 및 공개할 수 있는 웹 서비스
  • 라즈베리 파이 : arm 프로세스를 탑재한 싱글보드 컴퓨터

여러 컨테이너의 운용 관리

웹 3계층 시스템 아키텍처

• 인프라 아키텍처
  • 애플리케이션을 가동시키려면 여러 개의 서버에 기능과 역할을 분할하여 인프라의 전체 구성을정함
  • 대규모 웹 시스템의 경우 몇 개의 서브 시스템/기능으로 나누어 시스템을 개발하는 경우가 많기 때문에 애플리케이션 개발 기술 및 플랫폼 기술에 정통한 IT 아키텍트를 중심으로 인프라의 처리 방식을 결정함
• 프론트 서버
  • 클라이언트의 웹 브라우저가 보낸 HTTP 요청을받아, HTTP 응답을 반환하는 서버 기능을 가짐, 이 서버의 기능을 웹 프론트 서버, 웹서버
  • 요청의 처리가 메인 업무이므로 부하가 높은 경우는 스케일러블하게 처리 대수를 늘리고, 로드밸런서 등과 같은 기기를 사용하여 부하분산을 함
• 애플리케이션 서버
  • 애플리케이션 서버는 업무 처리를 실행하는 서버
• 데이터 베이스 서버
  • 영구 데이터를 관리하기 위한 서버
  • RDBMS(Relational Database Management System)
    • 애플리케이션의 처리 실행에서 발생하는 영구 데이터는 RDBMS 기능을 갖고 있는 미들웨어에서 관리됨
    • 오픈소스인 MySQL이나 PostgreSQL, Oracle의 Oracle Database 등
  • NoSQL
    • 병렬분산처리나 유연한 스키마 설정 등이 특징이며, 주요 방식으로는 KVS(Key-value 스토어)나 도규먼트 지향 데이터베이스(도규먼트 데이터베이스) 등이 있음
• Docker Compose
  • 여러 컨테이너를 모아서 관리하기 위한 툴
  • docker-compose.yml라는 파일에 컨테이너의 구성 정보를 정의함으로써 동일 호스트상의 여러 컨테이너를 일괄적으로 관리함
  • Compose 정의 파일은 웹 애플리케이션의 의존관계(데이터베이스, 큐, 캐시, 애플리케이션 등)를 모아서 설정할 수 있음
  • docker-compose 명령을 실행하면 여러 개의 컨테이너를 모아서 시작하거나 정지할 수 있음
  • 컨테이너의 구성 정보를 YAML 형식의 파일로 관리할 수 있으므로 지속적 디플로이나 지속적 인티그레이션 프로세스에 있어서 자동 테스트를 할 때의 환경 구축에도 그대로 이용할 수 있음
  • YAML
    • 구조화된 데이터를 표현하기 위한 데이터 포맷, Python과 같이 들여쓰기로 데이터의 계층 구조를 나타냄

멀티호스트 환경에서 도커 실행 환경 구축

멀티호스트 환경에서 컨테이너 관리의 개요

• 멀티 호스트 환경
  • 웹 시스템의 실행 환경은 웹 서버, 프록시 서버, 데이터 스토어 등 역할이 다른 여러 개의 서버기능이 연계되어 작동함, 제품 환경에서 이용자에게 서비스를 제공할 때는 여러 개의 물리서버나 여러 개의 가상 머신(VM)으로 구성된 멀티호스트 환경으로 서비스를 제공하는 것이 일반적
• 가용성
  • 시스템이 계속해서 가동될 수 있는 능력
  • 서버의 오류나 하드웨어의 고장 등이 발생해도 다른 정상적인 서버나 하드웨어가 대신해서 처리를 계속 함
• 확장성
  • 고부하로 인한 시스템 다운을 피하기 위해 여러 대의 컴퓨터를 클러스터화하여 처리를 분산시킴으로써 높은 처리 성능을 얻을 수 있음
  • 오토스케일 기능이 제공되는 경우도 존재
• 도커 머신
  • 호스트 머신/클라우드/가상 환경 등에 도커의 실행 환경을 만들 수 있는 커맨드라인 툴
• scp
  • Secure Copy Protocol : SSH의 기능을 사용하여 파일을 전송하기 위한 명령, 인증 정보와 데이터를 암호화하여 네트워크로 전송함

클라우드를 사용한 도커 실행 환경 구축

클라우드 환경에서도커 오케스트레이션하기

• 분산 환경에서 컨테이너 운용 관리
  • 컨테이너의 시작 및 정지와 같은 조작뿐만 아니라 호스트 간의 네트워크 연결이나 스토리지 관리, 컨테이너를 어떤 호스트에서 가동시킬지와 같은 스케줄링 기능이 필요, 컨테이너가 정상적으로 작동하고 있는지 아닌지를 감시할 장치도 필요
  • Kubernetes
    • 오픈소스 컨테이너 오케스트레이션 툴
    • 제공하는 기능도 풍부하고 개발 속도도 빠르며, 대규모 시스템에서의 도입 실적도 풍부하여 컨테이너 오케스트레이션 툴의 실질적 스탠다드
  • Docker Engine(Swarm 모드)
    • Docke에는 클러스터링 기능을 제공하는 Swarm 모드
    • Swarm 모드를 사용하여 여러 개의 컨테이너를 멀티호스트 환경에서 작동시키고, 그 컨테이너들을 모아서 하나의 명령으로 조작함
  • Apache Mesos, Marathon
    • 오픈소스 클러스터 오케스트레이션 툴
    • 몇 백부터 몇 천대의 호스트를 갖고 있는 대규모 클러스터도 지원할 수 있도록 설계됨
    • 여러 호스트의 CPU나 메모리, 디스크를 추상화하여하나의 리소스 풀로서 다룰 수 있는 것이특징
    • Marathon : 별도의 컨테이너 관리용 프레임워크, 장기간 걸쳐 계속 작동하는 애플리케이션의 실행이나 모니터링가능
• 퍼블릭 클라우드가 제공하는 매니지드 서비스
  • 클라우드의 가상 머신 인스턴스로 구축할 때는 하드웨어 관리에서 해방되지만, 인프라 환경 구축과 더불어컨테이너 오케스트레이션 툴, 감시 툴의 사용법이나 시스템 운용 및 장애 대응 등 여러 분야에 걸친인프라 기술에 관한 지식이필요
  • Amazon EC2 Container Service
  • Amazon ECS
    • Amazon Web Services의 가상 머신 기능을제공하는 Amazon EC2를 사용한 Docker 컨테이너 관리 서비스
    • AMazon EC에서는 태스크 정의라고 하는 JSON 템플릿을 사용하여 환경을 정의
    • Docker의 리포지토리와 이미지, 메모리나 CPU 등과 같은하드웨어 요구사항, 데이터 볼륨의 스토리지, 컨테이너 간 연결 등을 정의, CPU나 메모리와 같은리소스 가용성 요구사항을 바탕으로 클러스터 전체에 컨테이너를 배치하는 스케줄러를 갖춤
    • 컨테이너에 장애가 발생했을 때도 자동으로 복구됨
    • Amazon EC2의 부하분산 기능인 Elastic Load Balancing(ELB)을 사용하여 트래픽을 컨테이너 전체로 분산
    • AWS의 감시 서비스인 Amazon CloudWatch와 연계하여 CPU나 메모리 사용의 평균값과 합계량을 감시할 수 있음
    • 컨테이너나 클러스터의 스케일을 확장 또는 축소할 때 CloudWatch 알람을 설정하여 경고가능
  • Azure Container Service(AKS)
    • Microsoft Azure의 컨테이너매니지드 서비스, 컨테이너 오케스트레이션 툴로 Kubernetes를 지원하고 있는것이 특징
  • Google Kubernetes Engine(GKE)
    • Googel이 제공하는 Google Cloud Platform의 컨테이너 매니지드 서비스
  • Amazon Batch : 과학기술계산을 위한 분산 배치 처리 실행 서비스
    • 풀매니지드형 분산 배치 처리 실행 서비스인 Amazon Batch
    • 대규모의 구조해석이나 유체 해석 등과 같이 지금까지 슈퍼컴퓨터에서 수행하던 과학기술계산을 클라우드상의 리소스를 사용하여 수행하기 위한 서비스
    • AWS의 매니지듸형 Docker 컨테이너 레지스트리인 Amazon Ec2 Container Registry(ECR)에 이미지를 저장하고, ECS 클러스터로 전개하여 실행함
    • 과학기술계산과 같은 HPC(high performance computing)
• Kubernetes
  • 여러 개의 호스트를 하나로 묶어 Docker를 이용하기 위한 오케스트레이션 툴로, 분산 환경에서 마치 한 대의 컴퓨터 처럼 투과적으로 커테이너에 액세스 할 수 있음, 시스템 이용자로부터 오는 부하의 급증에 대해서도 유연하게 스케일하는 장치나 여러 개의 컨테이너를 효율적으로 통합 관리하는 장치도 있음
  • 기능
    • 여러 서버들에서의 컨테이너 관리
    • 컨테이너 간 네트워크 관리
    • 컨테이너의 부하분산
    • 컨테이너의 감시
    • 무정지로 업데이트
  • 서버 구성
    • 마스터 서버(kubernetes Master)
      • Kubernetes 클러스터 안의 컨테이너를 조작하기 위한 서버
      • API Server : 쿠버네티스의 리소스 정보를 관리하기 위한 프론트엔드 REST API
      • Scheduler : Pod를 어떤 노드에서 작동시킬지를 제어하는 백엔드 컴포넌트
      • Controller Manager : 쿠버네티스 클러스터의 상태를 항상 감시하는 백엔드 컴포넌트
    • 백엔드 데이터베이스(etcd)
      • etcd라 부르는 분산 키 밸류 스토어(KVS)를 사용하여 클러스터의 구성 정보를 관리함
      • 클러스터 구성을 유지 관리하는 KVS
    • 노드
      • Docker 컨테이너를 작동시키는 서버
      • Kubelet
        • Docker 컨테이너를 실행하거나 스토리지를 마운트하는 기능을 갖음
        • 클러스터의 구성 정보를 YAML 또는 .JSON 형식의 정의 파일로 관리함(매니페스트-manifest파일)
  • 애플리케이션 구성 관리
    • Pod(포드)
      • 쿠버네티스에서는 여러 개의 컨테이너를 모아서 Pod로 관리함
    • ReplicaSet(리플리카 셋)
      • 쿠버네티스 클러스터 상에서 미리 지정된 Pod를 작성하여 실행시켜 두는 장치
      • Pod가 필요한 수만큼 실행시킨 상태를 클라우드 안에 항상 만들어 두는역할을 함
    • Deployment(디플로이먼트, 전개)
      • Pod와 ReplicaSet을모은 것으로, ReplicaSet의 이력을 관리하는 것
  • 네트워크 관리(Service)
    • Load Balancer는 Service에 대응하는 IP 주소 + 포트 번호에 액세스하면 여러Pod에 대한 레이어 4 레벨의부하분산이 일어남

클라우드를 사용한 Docker 실행 환경의 운용 관리

시스템 운용의 기초 지식

• 시스템 릴리스 후에도 리소스 감시나 데이터의 백업, 장애 감시, 복구 대응 등 사용자가 쾌적하게 시스템을 이용할 수 있도록 시스템을 운용
• 가용성 관리
  • 콜드 스탠바이 방식
    • 구성이나 설정이 똑같은 서버나 네트워크 기기를 미리 백업 기기로서 마련해 두고, 실제 환경과 가까운 장소에 설치하여 전원을 꺼 둠
    • 만일 실제 환경에서 작동하는 기기에 장애가 발생하면 백업 기기에 전원을 넣고, 실제 환경의 기기와 통째로 교체함
    • 전원을 꺼 둔 채로 대기시키기 때문에 콜드 스탠바이라 부름
    • 실제 환경 기기와 백업 기기는 완전히 똑같이 설정해놔야함
  • 핫 스탠바이 방식
    • 동일한 구성의 서버를 2대 동시에 가동시키고, 만일 메인 서버에서 장애가 발생했을 때는 대기중인 다른 서버가 대신 처리를 이어받는 구성을 핫 스탠바이
    • 장애가 발생한 서버나 네트워크 기기를 시스템에서 자동으로 떼어내고 예비 기기로 전환하는 것을 페일오버(failover)
  • 헬스 체크
    • 장애 시에 신속하게 전환을 하기 위해 액티브 기기에서 장애가 발생한 것을 감지하는 장치를 헬스 체크
  • 로드 밸런싱(load balancing)
    • 다중화 구성을 하면 시스템의 가용성은 향상되지만 대기 서버를 이용하지 않고 그저 보유만 해두는 것은 낭비
    • 시스템의 가용성 향상과 처리 속도 향상을 동시에 수행하는 기술 요소로 부하분산이 존재
      • 부하분산 : 서버의 처리를 여러 기기로 나눔으로써 특정 기기에 부하가 집중되는 것을 막을 수 있음
    • 로드 밸런싱은 로드 밸런서라는 전용 기기를 사용하여 알고리즘에 기초하여 요청의 처리를 분산시킴
    • 요청을 균등하게 할당하는 알고리즘(라운드 로빈)이나 요청의 내용별로 할당처를 정하는 알고리즘 등 다양한 알고리즘 존재
    • 단일 장애점(SPOF)이 되어 있기 때문에 다중화해 두어야 시스템 가용성을 향상시킬 수 있음
      • SPOF : 한 장소에 장애가 발생하면 시스템을 이용할 수 없게 되는 부분
  • 재해 복구 시스템(Disaster Recovery System)
    • 자연 재해 등으로 피해를 입은 시스템을 복구 및 수리하는 것
    • 메인이 되는 데이터센터와는 다른 원격지에 백업 사이트를 두고 운용 관리를 함
    • RTO(Recovery Time Objective)
      • 재해 등으로 기업 시스템이 정지된 이후로 서비스를 복구할 때까지 필요한 경과 시간을 말함
    • RPO(Recovery Point Objective)
      • 재해 등으로 시스템이 정지되었을 때 어떤 시점까지 거슬러 올라가서 데이터를 복구시킬지에 대한 지표
• 수용성 관리
  • 시스템이 제공하는 서비스의 수요를 예측, 감시, 평가하고, 수요를 만족시키기 위해 필요한 최적의 시스템 리소스를 제공할 수 있도록 관리하는 것
  • 클라우드를 사용한 시스템에서는 이용한 리소스의 양과 시간에 따라 요금이 부과되므로 필요한 리소스를 시스템의 부하에 따라 동적으로 변경
  • 시스템을 운용하면 다양한 데이터가 발생하고 축적됨
  • 데이터는 프로그램이 종료되어도 스토리지와 같은 기억장치에 저장됨 -> 영구데이터, 시스템의 가동 시간에 따라 증가 및 변경되어 간다는 특징
  • 데이터의 백업과 복구
  • 로그 수집
    • 시스템 로그나 애플리케이션 로그는 각 서버상에 저장하는 경우도 있지만 분산 환경에서는 전용 로그 수집 서버 또는 로그 집약 서비스를 사용하는 것이 일반적
    • Unix 계열 OS의 경우 syslog라는 데몬을 사용하여 커널이나 애플리케이션의 로그를 관리함
    • 로그 수집용 미들웨어로는 Treasure Data가 개발하는 오픈소스의 Fluentd가 유명함
  • SLA
    • 시스템 레벨 관리 : 시스템이 제공자와 이용자 사이에 미리 서비스 레벨을 규정하고, 이 서비스 레벨을 유지 관리하는 것을 말함, 미리 규정하는 서비스 레벨을 SLA(Service Level Agreement)라고 함
• 시스템 감시
  • 시스템 운용의 큰 목적으로 시스템을 안정적으로 가동시키는 것
  • 시스템을 구성하는 서버들과 네트워크 기기의 상태를 항시 감시하고 적절히 관리함
  • 머신의 활동 감시
  • 서비스의 가동 감시
  • 서버/네트워크의 리소스 감시
  • 잡 감시
    • 업무 시스템은 영업시간 중의 온라인 처리뿐만 아니라 집계 처리, 장표 인쇄 처리 등과 같은 배치 처리 등도 병행하여 수행함
    • 감시 툴은 시스템의 감시대상인 서버나 기기의 상태를 감시하고, 미리 설정한 한계 값을 초과한 경우에 정해진 액션을 실행하는 기능을 갖음
    • 서버의 상태를 그래프나 맵 등으로 가시화하는 GUI도 제공하며, 시스템 장애 시에 관리자에게 메일을 송신하는 경고 기능도 갖고있음
  • 장애 대응
    • 오류의 원인을 제거하고 시스템을 정상 상태로 되돌리는 것
  • 퍼포먼스 튜닝
    • 시스템의 처리 중 병목이 일어나는 장소를 찾아내고 최적의 작동이 되도록 각종 파라미터를 조정하는 작업
    • 처리 속도의 계측, 처리를 실행하는 시간을 측정함으로써 어디가 병목이 되는지를 판단 할 수 있음