YouTube 동영상


2016년 9월22일에 업로드된 동영상이다. C++ 랭귀지를 만든 Bjarne Stroustrup(베야네 스트로스트룹)이 C++의 과거와 미래에 대해 설명한다. 한번 들으면 좋은데 너무 길다 (1시간43분). 내용을 간단히 요약한다.


- C++ 성공은 운이 아니다. C++ 성공에는 분명한 이유가 있다.
+ 랭귀지 저자가 생각하는 C++
  - 하드웨어를 직접 다루는
  - 오버헤드가 전혀 없는
  - 산업계 현장에서 사용하는
  - 좋은 프로그래머에게 더욱 유용한 랭귀지

- 랭귀지는 조그만 변해도 짐스럽다(구현, 도구제작, 학습이 필요). 변화 방향을 신중하게 결정해야 한다.
+ C++ 변화 방향
  - zero-overhead
  - 메모리 leak 등이 없는 안전한 코드를 만들게 할 것이다
  - 가비지컬렉션 등으로 인한 성능저하는 없을 것이다 (피할 것이다)

+ C++17 출시 임박
  - 아직도 C++98에 머물고 있다면 C++11, C++14로 업그레이드하라.
  - 적어도 현재에 머물러 미래를 준비하라
+ 깃허브에 C++ core guideline 문서가 존재한다
  - 한국어 번역에 참여한 사람들에게 감사한다
- 우리가 매일 사용하는 SW를 보존하기 위해서라도 C++은 계속 발전해야 한다



(이상)

저작자 표시 비영리 변경 금지
신고
Posted by ingee
TAG C++만세

댓글을 달아 주세요

Docker Storage 이해

Dev & Ops 2016.12.16 10:25

2016.12.16 덧붙임

- 도커는 원래 Ubuntu에서 개발, Ubuntu의 파일 스토리지 시스템은 AUFS.
- Red Hat 계열 배포판 (RHEL, CentOS, ...)에는 AUFS가 존재하지 않음.
- Red Hat 계열 리눅스를 위해,
도커는 Device Mapper를 2번째 Storage Backend로 수용함.
- Red Hat 계열 리눅스에 도커를 설치하면,

  Device Mapper가 도커의 Storage Backend로 동작 (loop-lvm).
- 만약, 도커를 상용 수준으로 운영하려면,

  Device Mapper를 loop-lvm(디폴트)가 아닌 direct-lvm으로 설정/운영해야 함.

- 도커 스토리지가 충분한 공간 위에서 안정적으로 운영되지 못하면,

  사용하는 컨테이너 이미지의 종류가 다양해질수록

  또 실행중인 컨테이너의 수가 많아질수록 시스템이 정상동작하지 못할 가능성이 높아짐.



2016.01.29 원글

Q: 도커를 쓸 때 궁금했다
- 도커허브에서 가져온 도커 이미지는 어디에 저장되는 걸까?
- 도커 컨테이너 안에 write 하는 데이터는 어디에 저장되는 걸까?

A: 알고보니, <도커 스토리지>에 저장됐다
- <도커 이미지>는 layer 구조를 갖는다
- <도커 컨테이너>의 데이터는 CoW (Copy On Write) 정책에 따라 저장된다
+ RHEL/ CentOS/ Fedora 에서는 <도커 스토리지> 설정 작업이 필요하다 (Device Mappr)
  - 디폴트 스토리지는 loopback 장치
  - 안정적이지 않음
- Ubuntu는 도커 패키지 설치후 도커 스토리지 설정 없이 그냥 써도 좋다 (AUFS)

도커 스토리지 설정 스크립트 (@RHEL/ CentOS/ Fedora)
0. su
  $ su
1. volume이 정상적으로 준비되어 있는지 확인
  # fdisk -l
  - 사용하지 않는 /dev/vdc 장치 존재 확인
2. docker-storage-setup 설정 파일 수정
  # cat <<EOF > /etc/sysconfig/docker-storage-setup DEVS=/dev/vdc VG=docker-vg EOF
3. docker-storage-setup 명령 실행
  # docker-storage-setup
  ...
  Physical volume "/dev/vdc1" successfully created
  Volume group "docker-vg" successfully created
  Rounding up size to full physical extent 16.00 MiB
  Logical volume "docker-poolmeta" created.
  Logical volume "docker-pool" created.
  ...

Ref
- (추천!) Understand images, containers, and storage drivers
  https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/
- Docker and the Device Mapper storage driver
  https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/
- Comprehensive Overview of Storage Scalability in Docker
  http://developerblog.redhat.com/2014/09/30/overview-storage-scalability-docker/

(이상)

저작자 표시 비영리 변경 금지
신고
Posted by ingee
TAG docker

댓글을 달아 주세요

k8s vs swarm 비교 요약

비교항목 Kubernetes
Swarm
설치
△ (열위)
Docker 설치 후,
k8s 추가 설치 필요
O (우위)
Docker만 설치하면 끝

미세 조정
(fine control)
O (우위)
클러스터 미세 조정 가능
(pod, replica-set,
deployment, service 등
세밀하게 구분된 객체 제공)
△ (열위)
미세 조정 미흡
(service 객체만 제공)


성능
container
life-cycle 관리
O (동등)
deploy, scale, update
O (동등)
deploy, scale, update
container
rolling-update
O (우위)
7초
△ (열위)
117초
node fail 복구
△ (열위)
304초
O (우위)
21초
사용 소감
* Flexible
* 신뢰성이 높고 유연함
* 현시점에서 가장 적합한 선택
* Simple
* 리소스 사용량이 작고 빠름
* 특수 상황에 적합한 선택


솔루션 특징 요약
k8s
  * 주요 resource
    - pod 객체
      . 컨테이너 집합
      . k8s의 실행 단위 (스케줄링 단위)
    - deployment 객체
      . pod 배포를 담당하는 자원
      . pod 인스턴스 수를 관리하는 replica-set 자동 생성
      . pod 인스턴스에 대한 rolling-update 관리
    - service 객체
      . pod 집합을 고정된 end-point로 관리
  * declarative configuration
    - desired-state를 선언(declare)하면 k8s가 클러스터의 current-state를 desired-state로 맞추기 시작
    - kubectl edit 명령이 유용


swarm
  * 주요 resource
    - docker engine swarm mode에는 pod, replica-set 등의 객체가 없고, service 객체만 존재
    - service
      . service는 1개 이상의 container로 구성되며,
        service 생성시 옵션 파라미터를 사용하여 replica 갯수를 지정
  * imperative configuration
    - 클러스터 상태 변경 명령을 내리면 즉시 반응 (장점 아님)

공통점 & 차이점
  . k8s와 swarm 모두 master가 죽어도 pod/service/overlay-network의 동작/연결은 유지됨
  . k8s는 delarative configuration, swarm은 imperative configuration
    즉, admin이 컨테이너 인스턴스를 100개 -> 10개로 지정하는 명령을 내렸을 경우
    - k8s는 중간 상태인 100개를 건너뛰고 최종 상태인 10개에 도달하는 방식
    - swarm은 100개 상태를 거쳐 10개 상태에 도달하는 방식

성능 테스트 결과

테스트 종류 Kubernetes Swarm
Container
Life-cycle
Mgmt.
컨테이너 생성
- 컨테이너 생성 시간 측정
- master x1, node x3
10개 생성
2.3초
3:4:3
7.0초
4:3:3
50개 생성
11.6초
17:17:16
14.3초
17:16:17
100개 생성
27.8초
34:33:33
22.2초
33:33:34
200개 생성
83.2초
66:67:67
63.2초
66:67:66 (?)
200개 with 4 node
59.1초
50:50:50:50
41초
50:50:50:50
300개 with 4 node
실패
(자원 부족)
70초
75:75:75:75
Scaling:
- 1개 컨테이너를 100개로 scaling
- master x1, node x4
25.3초
25:25:25:25
26.4초
25:25:25:25
Rolling Update:
- 어플리케이션 중단 없이 컨테이너 이미지 교체
- 컨테이너 인스턴스 10개가 동작하는 상황
- master x1, node x4
7.1초
3:2:2:3
117초
Cluster
Mgmt.
node fail 대처:
- 4개 node가 동작중인 상황에서
- 1개 node를 power-off,
- 제거된 node에서 실행되던 컨테이너가
다른 node로 이동/복구되는 시간을 측정
304.8초
33:33:34
21초


k8s vs swarm 테스트 스크립트 비교

테스트 종류
Kubernetes 명령 스크립트
Swarm 명령 스크립트
컨테이너 생성
$ kubectl create -f deploy.yaml
$ docker service create
--name hello-nodejs
ingee/hello-nodejs:0.2
Scaling
$ kubectl scale
--replicas=10
deploy hello-nodejs
$ docker service update
--replicas 10
hello-nodejs
Rolling Update
$ kubectl set image
deploy hello-nodejs
hello-nodejs=ingee/hello-nodejs:0.2
$ docker service update
--images ingee/hello-nodejs:0.2
hello-nodejs


(이상)

저작자 표시 비영리 변경 금지
신고
Posted by ingee

댓글을 달아 주세요