Time-Series 데이터베이스가 존재한다. InfluxDB, Prometheus 등이 대표적인데 Time-Series 데이터베이스의 특징에 대해서 정리 본다.
High-speed data ingest: ‘고속 데이터 수집’ 으로 번역된다. IoT 사용 사례나 시장 분석 데이터와 같이 꾸준히 고속으로 도착하는 연속된 혹은 한꺼번에 밀려드는 대량의 데이터를 처리해야 한다. 대부분의 솔루션들은 데이터를 24시간 365일 처리하도록 되어 있다.
Immutable data: ‘변경될 수 없는 데이터’ 로 번역된다. Immutable 은 프로그래밍에서도 자주 언급되는 단어다. 데이터베이스에 한번 Insert가 되면 데이터 포인트는 데이터가 만료(expire) 되거나 삭제(delete) 되기전까지 그 어떠한 변경도 일어나지 않는다. 이런 데이터는 전통적으로 timestamp 와 아주 적은 데이터 포인트를 가지는 로그 데이터들이다.
Unstructured labels: Time-series 데이터는 일반적으로 많은 소스들에 의해서 오랜 기간 동안 지속적으로 생산되어진다. 예를들어, Iot 경우에, 모든 센서들은 time-series 데이터의 소스다. 이런 상황에서, 시리즈의 각 데이터 포인트들은 소스 정보와 라벨로 다른 센서의 측정치들을 저장한다. 모든 소스들의 데이터 라벨들은 같은 구조나 순서들을 보장하지 않는다.
Diminishing value over time: ‘시간이 지남에 따라 가치가 낮아진다’ 정도로 번역할 수 있겠다. 적절한 시간 범위를 가진 집계된 요약 데이터만이 미래에 연관성이 있을 수 있다. 1년 후에, 대부분의 사용자들은 마이크로초 단위의 범위에 저장된 모든 데이터 포인트를 필요로하지 않을 것이다. 오직 수분, 수시간, 몇일동안 집계되어지고 정형화된 데이터만이 필요로하게 된다.
Queries are aggregated by time intervals: time-series 데이터에 기반한 차트는 확대/축소를 가능하게 한다. 이건 시간 간격에 의해서 그들이 데이터를 수집함으로써 그렇게 할 수 있다. 전통적으로, time-series 데이터 쿼리는 집계들이다. 이것은 데이터베이스 시스템으로부터 개별적인 레코드들을 검색하는 것과 대비된다.
CentOS 8 로 넘어오면서 기본 패키지 매니지먼트로 dnf 가 되었다. 여전히 yum 을 지원하지만 앞으로는 dnf 로 쭉 간다고 하니 이참에 배워보자고 생각하지만….
겁나 빡치는게, 이제 그만 바꿨으면 한다. 뭔 yum 정도로도 충분히 잘 쓰고 있고 괜찮다고 싶다. 무슨 겁나 가볍네, 더 빠르네 어케 좋네… 응 yum 도 그렇게 느리고 그렇게 무겁지도 않아! 도대체 뭘 할때마다 갈아 엎고 이걸 새로 배우라고 하니.. 뭐 어쩌것나.. 그렇게 하겠다는데, 닥치고 배워야지!
dnf
햐.. 쓰기도 귀찮다… “DNF is the next upcoming major version of YUM, a package manager for RPM-based Linux distributions” 이렇게 맨 페이지에 설명이 나온다.
쿠버네티스(Kubernetes) 처음 접하면 개념 잡기를 해야 한다. 쿠버네티스를 잘 사용하기 위한 사용법을 익히는것도 중요하지만 개념을 이해하고 나면 외워서 문제해결을 하는 것이 아닌 응용력이 생겨 예기치 않은 장애를 겪을때에 힘을 발휘한다.
개인적으로 쿠버네티스의 개념을 이해하는데 약간의 혼란이 있었다. 개념을 설명하는 용어와 실제 작업을 할때에 사용하는 단어, 명령어들이 다 틀리게 사용되고 있는데서 오는 것이였다.
Master/Worker
다들 알다시피 쿠버네티스는 Master Node와 Work Node 로 구성된다. 대부분 Work Node 가 Master Node 보다 훨씬 많고 대부분의 서비스들이 여기에 배포되어진다.
Node 라는 단어를 빼버리고 단순히 Master/Worker 라고도 하지만 그냥 Master/Node 라고 하기도 하는 모양이다. 하지만 정확하게는 Master Node, Worker Node 라고 불린다.
또, Master Node 를 Controller 라고도 한다. Master 의 역활이 Worker Node 를 모니터링, 감시를 하고 각종 명령어을 Master 가 받아서 처리한다. 이 Master Node 는 거대한 Controller 서버 역할이라고 보면 된다.
kubectl – ResTful API
Master 가 거대한 Controller 서버라면 클라이언트를 이용해서 이 서버에 명령을 보내면 될 것이다. 이 클라이언트가 바로 kubectl 이라는 커맨드가 수행한다. 서버-클라이언트 구조상 서버는 1대지만 클라이언트는 여러대 일 수 있다. 실제로 kubectl 은 단일한 명령어로서 도커(Docker), 컨테이너(Container) 등도 필요없이 동작한다. 그래서 클라이언트는 어느 머신이든지 다 설치/사용이 가능하다.
kubectl 은 클라이언트, Master Node 는 Controller 서버다. 이 둘이 명령어를 주고 받는 방법이 바로 RESTFul API 통신 방법이다.
ResTful API 는 HTTP 를 이요해 URI 에 자원(Resources) 을 명시하고 메소드(Method) 를 이용해 CRUD 연산을 수행한다.
쿠버네티스(Kubernetes) 에서 중요한 것이 바로 자원이다. ResTful API 를 이용해 어떤 작업을 명령할때에 반드시 대상이 필요한데, 이것이 바로 자원이다.
Object, Resource, Kind
쿠버네티스(Kubernetes) 에서 개념을 설명할때에 오브젝트(Object) 라는 말을 쓴다. 오브젝트라고하면 쿠버네티스를 구성요소쯤으로 이해하면 된다. 예를들어 Pods, Service, Volume, Namespace 등은 쿠버네티스의 기본 오브젝트라고 불린다.
문제는 이러한 오브젝트들이 때로는 자원(Resource), 때로는 종류(Kind) 로 불린다.
자원 ResTful API 관점에서 실체적인 존재로서 호출하는 오브젝트들이다. 실제로 kubectl 커맨드를 사용할때에는 ‘오브젝트를 명시한다’ 하지 않고 ‘자원을 명시한다’라고 한다. ResTful API 개념을 차용했기 때문에 ‘자원을 명시한다’라고 해야 맞다.
kubectl 은 Kubernetes Client 이다. 이 명령어는 HTTP 통신을 기반으로 Kubernetes Controller 와 RestFul API 통신을 요청하고 결과를 받아 사용자에게 출력하게 하는 역할을 한다.
HTTP RESTFUL API 통신을 한다는 말을 듣는 순간 직감했겠지만 인터넷만 된다면 kubectl 은 어느 컴퓨터에서든 실행이 가능하다. 처음 Kubernetes 설치문서들을 보면 대부분 Master Node 에서 실행되도록 설정을 하는데, 여기서는 다른 컴퓨터에서 kubectl 만 설치해서 Kubernetes Controller 와 연결하는 방법에 대해서 살펴보도록 할 것이다.
설치환경
설치 환경은 Mint Linux 19.2 – XFCE4 환경에서 진행했다. kubectl 를 실행하는 환경는 다양하겠지만 제일 편한 것으로는 Unix 환경일 것이다. Mac OS X, Linux 가 가장 적합한데, 필자는 Mint Linux 19.2 – XFCE4 데스크탑을 사용하고 있음으로해서 이 환경에서 진행하게 됐다.
Mint Linux 19.2 는 Ubuntu 기반이기 때문에 Ubuntu 에서 설치, 설정 모두 동일하다고 생각하면 된다.
kubectl 설치하기
Mint Linux 19/2 에서 설치하는 방법은 Ubuntu 에서 설치하기와 동일하다. 단, 여기서는 kubectl 패키지만 설치하면 된다. root 계정으로 다음과 같이 한다.
Kubernetes 를 설치할때에 Cgroup driver 를 systemd 로 추천하고 있다. 그래서 Kubernetes 만 systemd 로 드라이버를 교체하면 docker 와 통신이 되지 않는다. 이것을 위해서 Docker 에서도 드라이버를 systemd 로 교체해 준다.
1
2
3
4
5
6
7
8
9
10
11
12
]# cat > /etc/docker/daemon.json <<EOF
{
"exec-opts":["native.cgroupdriver=systemd"],
"log-driver":"json-file",
"log-opts":{
"max-size":"100m"
},
"storage-driver":"overlay2"
}
EOF
]# systemctl daemon-reload
]# systemctl restart docker
다음과 같이 확인 가능하다.
1
2
3
4
]$docker info
Logging Driver:json-file
Cgroup Driver:systemd
Plugins:
Kubernetes 설치
Ubuntu 18.04
Ubuntu 18.04 에서는 다음과 같이 Kubernetes 패키지 저장소를 추가 한다.
Ubuntu 18.04 를 설치하면 ethernet 인터페이스 이름이 과거 eth0 가 아닌 ens3 과 같이 나온다. 하지만 아직도 많은 프로그램들이 기본적으로 eth0 를 기본으로 찾기도 한다. eth0 변경하는 방법에 대해 다룬다.
GRUB 파라메터 수정
다음과 같이 Grub 에 파라메터를 추가 한다. Grub 에 파라메터는 /etc/default/grub 파일에서 다음과 같이 추가할 수 있다.
1
GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"
수정된 사항이 Grub 에 반영하기 위해서 업데이트를 수행한다.
1
]# update-grub2
여기서 중요한 것이 바로 재부팅을 하면 안된다. 특히나 DHCP 환경에서는 다음의 단계를 수행한 후에 재부팅을 해야 한다.
netplan 수정
netplan 은 Ubuntu 17.04 에서 소개된 기능으로 네트워크 인터페이스 관련 작업을 해준다. 이 프로그램은 /etc/netplan/*.yml 파일을 참조하는데, Ubuntu 18.04 의 경우에 /etc/netplan/01-netcfg.yaml 파일을 참조 한다.
1
2
3
4
5
6
network:
version:2
renderer:networkd
ethernets:
eth0:
dhcp4:yes
eth0 부분이 수정한 것이다. 이렇게 수정을 다 했으면 다음과 같이 명령어를 수행해 준다.
1
]# netplan generate
이렇게 한 후에 재부팅을 하면 DHCP 환경에서 문제 없이 eth0 인터페이스 이름으로 네트워크가 정상 동작한다.
Trac 을 사용하다보면 Ticket 을 삭제하고 싶을때가 있다. Ticket 삭제 플러그인이 존재하지만 Ticket 이란게 자주 삭제를 하는 것이 아니여서 굳이 이것을 설치해서 사용해야할 만큼은 아닌듯 한데, 그런데도 잘못된 Ticket 을 삭제해야한다면 다음과 같이 하면 된다.