Contents Creator

What is Telemetry

Docker, KVM, AWS, Azure

텔레메트리 분류

ingest(데이터 받기) > Store(저장) > Analysis(분석) > Present(보여줌)

1. ingest 

: Prometheus for Metric

: fluentd for logging (또는 Apache Flume)

2. Store

  :  TSDB for Metric

Prometheus

• simple
• has its own SQL (PROMQL) : easy for use
• no clustering or high availability

OpenTSDB • powerful

• clustering and high availability
• complicated ( based on hbase, Hadoop)

: key/value for logging

Elastic Search (많이 씀)

• simple, support scale-out
• support GUI (kibana)
• fast, realtime support
• DSL based search

 

3. Analysis : it’s not quite simple

Message queue: kafka

- 관리 부분을 발신/수신자에게 부담해버림

- 카프카 내부에선 큐만 관리 -> 빠를 수 밖에 없음

 

 

 

<여러 회사들의 예시>

Metric integration: kakao’s kemi stats

logging integration case: kemi log

Kakao’s case

brew로 

https://gist.github.com/jungbin-kim/d0c8a41d3c72ebdace3c4d5acaa017e4

도커 설치법

도커허브에서 이미지 검색하는방법

Docker search — 

Ex) docker search centos

도커허브에서 이미지를 다운로드하는 방법

Docker pull —

Ex) docker pull centos (:lastest)

도커 이미지 목록 모기

Docker images 

도커에 태그 달기 (하드링크랑 같음)

Docker tag [이미지A: 이전 tag] [이미지A: 바꿀tag]

Docker tag centos:latest centos:ver7

도커 이미지 삭제

Docker rmi 이미지이름:태그

이미지 업로드 할려면

이미지 이르은 “아아디/리포지토리:태그” 형식으로 사용해야함

e) docker pull

@도커 실행하기 (run은 이미지 안만

Docker run —name

docker run --name hello hello-world

@현재 도커 상태보기 

Docker ps 

(-a) 종료된 리스트도 보여줌

@도커 오브젝트(이미지/컨테이너/네트워크/ 볼륨) 를 더 자세하게봄

Docker inspect 이름

<— 잘몰라도됨—> 차피 docker run으로 끝남

@docker create (-it 입출력 가능하게 하는 옵션) --name 이미지 이름

Docker create 이름 : 이름 지정해줘라/ 안하면 랜덤으로 생겨버림

@create start/stop

Docker start -ia 컨테이너이름  (create -it로 만들었으면 -ia 붙이기)

Ctrl + p + q 컨테이너 안에서 빠져나오기

@컨테이너 만들고 시작하기 / 이미지가 없으면 해당이미지를 다운까지 받음

Docker run (=pull + create + start)

Docker run (-it 입출력이 필요하면)— name [컨테이너이름] [이미지이름]

(-d) 백그라운드 

Ex) docker run -itd —name c1 centos 

@컨테이너 삭제

Docker rm

(-f) 강제삭제 : 실행중이어도 삭제가능

@컨테이너 접근 (백그라운드에 있는 경우에 효력이 발생)

Docker attach [컨테이너이름]

@컨테이너에서 어플리케이션 실행 - 실행하고 바로 빠져나와버림

Docker exec [컨테이너이름] [명령어]

Ex) ddocker exec c1 ip addr

@컨테이너내의 실행중인 프로세스 확인

Docker top [컨테이너이름]

@컨테이너 새이름

Docker rename 이름 새이름 

@컨테이너 일시정지/ 다시시작

Docker pause/unpause [컨테이너이름]

@컨테이너 복사 

Docker cp [option][컨테이너이름]:

@컨테이너 변경사항 추적

Docker diff c1

@컨테이너  이미지 커밋저장

Docker commit [컨테이너이름] [적당한이름]

@컨테이너 이미지 아카이브 파일로 저장

Docker save [옵션] [

@컨테이너 복원/로드

Docker load

작업공간을 나누기 위해 일반적인 가상화를 진행하게 되면

자원 낭비가 심하다.

운영체가 필요해서 작업공간 분리를 위해 집안에 집을 만드는 꼴이 됨

도커의 같은 경우 

1. 운영체제를 따로 만들필요가 없다 - 자원을 아낄 수 있다.

2. 이식성이 좋다 - 각 컨테이너끼리 독립된 동작 환경을 구성한다

3. 상호운용성 - On-Premise 환경뿐 아니라 구글, 아마존, IBM등 다양한 벤더의 시세틈 및 클라우드 환경을 지원한다. ->

다양한 DevOps 오픈소스 SW와 연계가 가능하다.

도커의 주요 기능

1. 이미지 생성 및 관리

- 이미지는 컨테이너를 구동하기 위한 데이터

- 도커 명령어로 이미지 관리 가능

2. 이미지 공유

- 이미지 저장소 (레지스트리)에서 검색, 다운로드, 업로드 가능

- git으로 이미지 버전관리 가능

3. 컨테이너 동작

- 컨테이너 단위의 서버를 구동

- 운영체제 없이 구동

- 속도와 효율이 좋음

도커 동작을 위하여 사용되는 기술

1. 네임 스페이스

- 컨테이너라는 독립된 환경을 만들고

2. 그룹제어

- 도커의 각 컨테이너는 호스트의 리소스를 공유하여 사용된다. 이에 따라 자원이 불균형하게 할당되거나, 필요한 자원을 할당받지 못할 경우

Cgroup은 프로세스 또는 쓰레드를 그룹화하여 관리함.

이를 통해서 서로 다른 컨테이너에 영향을 막아주는 역할도 가능

3. 가상 브릿지와 가상 NIC (랜카드)

- 도커에서 생성한 컨테이너는 각각 가상의 NIC(Network Interface Card) 가 할당.

컨테이너의 네트워크를 Brigde로 기본설정을 할 경우 NIC는 docker0라는 가상 브릿지에 연결되어 컨테이너 끼리, 또는 호스트를 통해 외부 네트워크로 연결.

위의 호스트의 eth0는 물리적은 NIC를 말하며, docker0는 eth0와 연결된 가상의 브릿지 네트워크.

veth* (Virtual Ethernet은 컨테이너 별로 생성된 호스트의 가상의 NIC이며, 이는 컨테이너 eth0와 연결굄

4. 계층 파일 시스템

- 도커에서 기존 이미지에 추가작업을 하는 경우 변경된 부분만 복제 (COW방식 : Copy on Write)

- 도커의 이미지에는 운영체제와 미들웨어를 포함하고 있어서 생성할때 마다 기존 방식이라면 복사할때마다 자원 낭비가 발생하기 때문에  

그래서 변경된 것만 복제

- 도커 이미지 관리에 사용되는 파일 시스템 또는 라이브러리

Btrfs(B-Tree File System)

AUFS(Advanced multi-layered Unification File System)

Device Mappaer

OverlaysFS

[학습 목표]

가상화 기술 개념

가상화 기술의 종류와 개념

컨테이너 기술에 대한 개념

<Server virtualizations>

Container Technology

- 18년도부터 컨테이너 개념이 들어오기 시작 

앱을 돌릴때 필요한 라이브러리, 어플리케이션 자체를 이미지와해서 만들것을 name space와 cgroup을 통해서 시작하는것을 컨테이너라고 생각하면됨

도커가 나오면서 컨테이너가 널리 사용됨

특히 구글에서 컨테이너 관리로 썻던 쿠버네티스가 그런 계기가있음

실행에 필요한것들을 이미지에 다 담고 (이미지는 어디든 갈 수 있음) 도커에 넣고 실행하면 컨테이너가 생성

컨테이너 안에 들어가면 로컬에서 쓰던 기분 (어? 쉘인가?)

도커 이미지 : 실행에 필요한것을 다 담음

컨테이너 : 그 이미지를 분리시킨다음 runC 상태로 돌아가서 그 안에 있던 (이미지) 에플리케이션이 독립된 단위로 실행됨

VM : 은 하이퍼바이져가 들어가 있음  (하이퍼바이저 : 가상화를 해주는 장치 또는 칩)

Container : VM에 필요하던 오버헤드가 없음 

이것만 알아둬라

Container 는 Nacespace/Cgroup의 집합 그럼 나는 어떻게 네트워크를 그 안에서 조절할 것이냐 ? 또는 안에서 조절할 부분 or 밖에서 조절할 부분을 구분할 것인가?

• 서버가상화

시스템 자원을 공유(pool & share)함으로써 전체적인 시스템의 활용도를 증대시킬 수 있고, 자동화 기술과 함께 적용함으로써 시스템 사용자의 서비스 수준을 보다 향상시켜 줄 수 있다.

하이퍼바이저 : 가상화를 해주는 장치 또는 칩

<서버 가상화 기술>

• 호스트 OS 가상화 vs 하이퍼바이저 가상화

 

• 가상화유형

 – 전 가상화 (full-virtualization)

시스템 전체를 완전히 가상화 하여 시스템의 Bios부터 CPU, Memory, I/O 등을 완전히 에뮬레이션 하여 가상화 하는 방법

장점	단점
• 하드웨어를 완전히 가상화 하기 때문에 Guest OS에 아무런 수정없이 Windows, Linux까지 다양 한 OS를 이용할 수 있다. • 가상머신의 유지보수가 쉽다.	• 전 가상화를 실현하기 위해 CPU의 VT(Virtualization Technology)를 이용하므로 성 능의 저하가 발생한다는 단점이 있다.

 

 

– 반 가상화 (para-virtualization)

하드웨어 전체를 가상화 하는 대신에 가상화가 적용된 리눅스 커널을 시스템 부팅 시 적용하는 것으로 모든 장치를 가상화 하는 것은 아님

 

장점	단점
• 가상머신이 직접 하드웨어를 제어하는 것이 아니 라 하이퍼바이저에게 의뢰, 하이퍼바이저가 제어 를 하기에 높은 성능을 유지할 수 있다.	• 반 가상화를 실현하기 위해서는 가상머신 OS의 커널 일부분을 수정해야 한다. • 가상머신 유지보수가 어렵다. (가상머신 비밀번 호 분실 시 복구 불가능)

 

요즘에는 반가상화 전가상화 사이에 차이가 크게 사라짐 

 

• KVM

• –  Kernel-based Virtual Machine의 약자
• –  http://www.linux-kvm.org
• –  오픈 소스 소프트웨어
• –  x86 서버 기반의 전 가상화 솔루션 (Using Intel VT or AMD-V)
• –  게스트 운영체제의 수정이 필요 없음
• –  Using QEMU
  • QEMU 는 가상화 에뮬레이터
  • 게스트 OS의 I/O를 QEMU를 통해 제공한다.
• –  VM이 새로운 프로세스와 QEMU 프로세스를 이용하여 실행된다는 단점이 있음 (오버헤드 발생)
• –  ESX Server, Xen Server 등과 같이 전용 하이퍼바이저가 아닌 Linux 자체를 호스트 OS로 이용
• –  RHEV (RedHat Enterprise Virtualization) 솔루션의 기반

• KVM 아키텍처

 

 

• Xen

서버 가상화 기술

• –  캠브리지 대학교의 연구 프로젝트로 개발
• –  http://www.xen.org
• –  오픈 소스 소프트웨어
• –  x86 서버 기반의 반 가상화 솔루션 (Paravirtualizing VMM-Virtual Machine Monitor)
• –  게스트 운영체제의 수정이 필요함
• –  전 가상화에 비해 처리에 대한 오버헤드가 적다.

• 하드웨어 기술(Intel VT or AMD-V)이 발전함에 따라 성능 차이가 줄어들고 있음

• –  x86 서버 기반의 전 가상화 솔루션(Intel VT or AMD-V)에서는 HVM(Hardware Virtual Machine)을 구현할 수 있다.
  • 반가상화/전가상화모두구현가능
• –  Citrix Xen Server 솔루션의 기반

• Xen 아키텍처

[학습 목표]

Cloud Computing 개념

서비스와 마이크로 서비스의 개념과 차이점

IaaS, PaaS, Saas 특징

초록색이 많을 수 록 돈이 많이 듬 -> 그래서 최대한 돈을 아낄려고 하이브리드 형태로 사용

# On-Premises / (레거시) 물리적 - 가상화 안됨

- 규모가 있는 기업에서 사용하는 방식

- 자체적으로 데이터센터와 서버실 구축하여 운영

# 퍼블릭 클라우드 (AWS) / 클라우드 (가상화)

- 초기투자 필요없음

- 인터넷을 통해 불특정 다수에게 돈주고 빌려줌

# 프라이빗 클라우드 

-특정 대상을 지정해서 서비스를 제공하는 클라우드 서비스

- 단일 기업, 계열사 등에만 지원

AWS와 같은 Cloud Service Provider 업체에서는 다음과 같은 서비스 유형을 제공함

# IaaS

- Infrastructure as a Service

- Server, OS, Network, Storage 등을 제공

- 필요로 하는 자원의 규모와 성능 등에 의해 비용 발생

# PaaS

- Platform as a Service

- 소프트웨어 개발 및 운영 환경을 제공

- 인프라에 대한 관리 부담을 질여 개발에 집중하도록 함

# SaaS

- Software as a Service

- 클라우드 벤더가 제공하는 시스템 및 스프트웨어를 직접 사용 (한컴 독스)

- 인프라, 소프트웨어 구축 시간이 없거나 매우 짧음

클라우드 서비스가 좋은 이유

# 초기 투자 없음 

  장비를 빌려쓰기 때문에 장비 구매, 설치 불 필요

# 트래픽 변동이 가능

  요구량에 조절이 가능해서 트래픽 예측이 힘들때 좋음 

# 복구가 빠름

  무 중단 또는 재해 복구가 빠름

  이중화, 백업 구성이 가능

# 빅데이터 처리에 유용

   많은 데이터를 직접 가지고 있을 필요없음

# 웹/모바일앱 등 백엔드로 이용가능

  백엔드를 클라우드를 이용하여 구축가능

서비스란 결국 웹, 어플리케이션, 디비 서버를 연결해서 사용자가 사용할 수 있게 해주는걸 의미함

[Micro Service?]

쉽게 말해 점점 작게 세분화

-

클라우드 컴퓨팅이 뭐냐?

: 어떤 서비스를 해준다? -> 클라우드다

IT service 보다는 Product 라는 말이 맞음

-> 하나의 제품으로 보는게 맞다 : 제품은 어떤 목적성을 띔, 필요한 니즈를 채움

Engineering?

일정 생산 목적에 따라 유기적인 체계로 구성하는 활동  -> 클라우드 제품을 설명하기 위해 필요한 개념

Technology?

way of saving cost or creating product -> 기술과 이윤!

----------------------------------------------------------------------------------------------------------------------

[클라우드 컴퓨팅]

유틸리티 컴퓨팅 아키텍처의 새로운 패러다임

소수의 컴퓨팅 자원을 다수의 컴퓨팅 자원처럼 사용

사용자 중심의 아키텍처

클라우드 컴퓨팅 아키텍처는 그리드 컴퓨팅 기반(유틸리티 컴퓨팅과의 차이점)

[그리드 컴퓨팅]

분산 컴퓨팅 아키텍처의 하나

다수의 컴퓨팅 자원을 하나의 컴퓨팅 자원처럼 사용

컴퓨팅 중심의 아키텍처

분산 파일 시스템/ 스토리지는 오히려 그리드 컴퓨팅 아키텍처

그리드 컴퓨팅 아키텔처는 서비스 아키텍처가 아님

표준화에 실패 -> 클라우드 컴퓨팅에 뺏김

- 사용하고 있는 서비스는 열어보면 이렇게 다양한 분산 시스템을 필요로 함 (내부에 있음) 

AWS가 처음 나올때 아마존에서 장비 사용율을 보니 5%로도 안됨 그래서 서버를 빌려주기 시작하면서 나옴

[클라우드 컴퓨팅이란?]

- Cloud Computing as Utility Computing 

@유틸리티 컴퓨팅에서 유래

@ 기본 운영방식

   - 가상화로 구성되어 있다. <서버 가상화, 스토리지 가상화>

  -  전기 사용요금과 같이 사용한 만큼 요금을 내라 

@ HP, IBM, SUN 등 하드웨어 제조 회사가 유틸리티 컴퓨팅 주도 / 반면 클라우드 컴퓨팅은 AMS,Google, MS 클라우드 밴더라고 부름

@ IaaS 중심의 클라우드 컴퓨팅

  - 미래에는 경쟁력이 없다 (가격으로 승부하기 때문)

  - 한국적인 클라우드 컴퓨팅은 없다

  - 보안 문제와 응답 시간만 같다면 누구나 값 싼 서비스를 선택하게 된다.

@ 항상 Global Computation을 생각하자

--Only Cloud Computing

@ 기업에서 사용하는 컴퓨팅 자원을 표준화 해 그 자원을 가상 환경으로 제공하는 방식

@ Iaas,Paas, SaaS가 기본임

@ 원가가 저렴해야 한다

 - 밴더에 독립적이어야 한다

 - 표준화가 되어 있어야 한다

@ 자동화가 되어 있어야 함

---Cloud Computing is.

@ IT as a Service 

 -Infrastructure as a Service 

 - Platform as a Service

 - Software as a Service

@ Cloud Computing is not virtualization.

@ Dynamic set of Connected Computers

 - Computers are PC, Server, Mainframe, Sensor, Phone...

 - Connect is a internet environment

 - Dynamic is on-demand or at runtime or near real-time

 - Set is cluster. is not grid

@ have to be automated and stardized (자동화 및 표준화!!)