Is GreptimeDB suitable as a long-term storage solution for Prometheus? To find an answer to this question, I set up a simple configuration of GreptimeDB (v0.13) to investigate.

What is GreptimeDB?

GreptimeDB is an open-source cloud-native time series database that integrates metrics, logs, and events.

Each solution is the root of the next problem – Gerald M. Weinberg

I’ve been using Jsonnet for several years, and I think it would be good to summarize my experiences so far.

The good

The best thing about Jsonnet is that it’s a superset of JSON. As a data templating language for generating JSON, it provides many features of programming languages (variables, functions, arithmetic operations, conditionals). Since it can generate JSON, it can also generate YAML, which is why I use it with tanka to create Kubernetes manifests.

Cortex

Cortex, started by Tom Wilkie and Julius Volz (Prometheus’ co-founder) in 2016, has several interesting architectural features. As one of Prometheus’ long-term storage solutions, Cortex has been referenced by many time-series based storage architectures (tracing, log) since then (especially in the Grafana stack).

Kubernetes upgrades (especially EKS) are categorized into two types based on the Kubernetes architecture:

• Control plane upgrade (+ etcd)
• Node upgrade

Particularly when using cloud-managed Kubernetes like EKS, since AWS manages the control plane, you’ll mostly handle node upgrades directly (if you’re not using managed nodegroups).

Prometheus 101

I created a simple presentation about Prometheus. I uploaded it using sporto/hugo-remark: A theme for using remark.js with hugo, and I found that creating it in markdown rather than PowerPoint allowed me to focus more on the content. (But that doesn’t necessarily mean the content is better.)

For golang based HTTP/REST API documentation,I choose swagger. go-swagger has several features for swagger documentation. The go-swagger can generate swagger spec based code generation but I already have an REST API server. I use go-swagger with golang comment annotation for swagger spec generation.

For REST API development, Design first with writing spec and then generating codes from it is a good approach. goa is a famous tool for this style.

One of pleasures about coding is using good tools. Recently I use bumpversion, govvv and drone for version releasing.

bumpversion

bumpversion is automation for semantic versioning. Most of my projects have simple config file like below. (.bumpversion.cfg)

[bumpversion]
commit = True
tag = True
current_version = 0.8.4
parse = (?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)
serialize = 
	{major}.{minor}.{patch}
[bumpversion:file:VERSION]

Before release,I just run like below:

The Docker machine is a command tool created by the docker team to manage docker servers. It automatically creates hosts and installs docker engine on them and configures the docker client to talk.

If you install the docker machine tool,you can use it like below:

오랜만에 docker-korea meetup에서 About Docker Swarm이라는 이름으로 작은 발표를 했다.

장표는 매우 간단하게 구성하고 데모에서 많은 이야기를 하고 싶었는데. 프로젝터설정부터 힘들어서 준비했던것을 절반밖에 이야기하지 못한것 같다.

Docker Swarm은 다른 클러스텅 시스템과 다른 부분들이 있다. 가장 큰 다른 점은 Docker에서 만들었다는 것. 즉 coreos/fleet이 Distributed Init System을 표방하는 것과 비슷하게 Swarm은 Docker-native Clustering System을 이야기한다. ¹

Python을 사용하는 사람이라면, virtualenv을 잘 알것이다. 각 프로그램마다 각자의 파이썬 환경을 구성할수 있는 도구이다. (Py3에 기본으로 추가되어 있다)

go tool은 개인적으로 불만이 많은 도구이다. 특히 go get은 여러가지 기능의 부족으로 당황스러움을 느끼게 한다.

가령 go get은 scm(git,hg…)에서 직접 가져온다. 하지만 언제나 master branch의 최신을 가져온다. 즉 버져닝(versioning)에 대한 부분이 없다.

사내에서 Docker 사용에 대한 이야기가 나와서 간단하게 조사해보았다. 매력적인 프로젝트인것은 확실하지만, 기존에 chef나 opsworks로 구성되어 있는 부분도 있고 현재 시스템 구조상 docker으로 이전해서의 이득이 생각외로 크지 않다는 것이 중평.

docker의 장점은 대개 두가지로 이야기 할수 있겠다.

• Portability (이식성)
• Repeatability (반복성)

이식성(Portability)은 가장 크게 얻는 이점은 개발환경과 실제 프로덕션 환경의 차이를 설정변수 몇개로 축소할수 있다는 점이라고 생각한다. 여러 환경(개발,테스트,프로덕션)을 일치시키기 위한 별다른 노력을 할 필요 없다는 점이 가장 큰 매력으로 생각한다. 물론 자바와 비슷하게 한번 작성하면 어디서든 동작한다는 것이 여러 Host 환경에서 동작할 수 있다는 점도 무시할수는 없겠다.

읽어야 할 글들을 Kindle에 던지는데,뭘 킨들에 던졌는지 기록해 두면 좋을 것 같아서 적어본다.

Go’s power is in emergent behavior

• http://www.onebigfluke.com/2014/04/gos-power-is-in-emergent-behavior.html
• golang의 interface의 특징을 두가지 예(http.HandlerFunc,opaque type)을 가지고 설명. 저번에 있었던 gophercon에서 들은 내용에 대한 글.

Go Parallel 1,2

• https://software.intel.com/en-us/blogs/2013/06/18/go-parallel
• https://software.intel.com/en-us/blogs/2014/04/13/go-parallel-2
• 고루틴에 대한 예제와 함께 짧게 고루틴을 알수 있는 글.

Go: Best Practices for Production Environments

• http://peter.bourgon.org/go-in-production/

읽어야 할 글들을 Kindle에 던지는데,뭘 킨들에 던졌는지 기록해 두면 좋을 것 같아서 적어본다. 이번달은 읽은 글들이 많지가 않다. T_T

Go and Package Versioning

• http://zduck.com/2014/go-and-package-versioning/

“My dream is for go get to support a version number component in the import path. So github.com/jpoehls/gophermail would fetch the HEAD of the repository as it does today. github.com/jpoehls/gophermail#v1 would fetch the v1 branch or tag.”

읽어야 할 글들을 Kindle에 던지는데,뭘 킨들에 던졌는지 기록해 두면 좋을 것 같아서 적어본다.

Why Atom Can’t Replace Vim : Learning the lesson of vi

Atom이 Emacs의 확장가능성은 가질수 있지만, Vi의 조합가능성에 대해서는 배운 바가 없다는 글.

조합가능성에 대한 글로는 http://blog.dahlia.kr/post/78940164278 홍민희님의 글과 함께 보면 좋다.

아직 서비스에 사용이 가능할지는 미지수이지만, Python으로 구성한 REST API Server을 이번에 D언어로 프로토타이핑을 하게 되었다.

우선 사용한 라이브러리는 vibe.d와 Backend Server와의 통신을 위해 thrift이다.

vibe.d은 기본적으로 redis와 mongodb을 지원하지만, Thrift에 대한 지원은 없다.

vibed의 Writing native database drivers - and a new MySQL driver port 을 참고하여 TSocket을 vibe.d의 TCPConnection을 사용하도록 만들어서 사용했다.

크롬북을 샀다.

크롬북의 가장 큰 장점은 가격이다. $199에 이정도 노트북을 살수 있다는 것은 분명 매력적. 정말로 크롬 웹 브라우저만 있다. 흠…

• 좋지 않은 디스플레이 (흐릿한 디스플레이는 C720의 가장 큰 하드웨어 단점이다)
• 8시간 사용 가능한 배터리 (하스웰 기반 CPU이 주는 혜택. 8시간이상 되니까 핸드폰처럼 충전기를 가지고 다니지 않게 되었다)
• 내 아이폰과 같은 용량인 16기가 SSD.

나의 개발환경을 기본적으로 한쪽 화면에 터미널(들),또 다른 화면에는 웹 브라우저(들)뿐이다. 크롬OS는 개발자 모드로 shell을 사용할수 있으므로, 코딩하는게 크게 문제는 없다.

C++ for C Programmers 코세라 수업이 끝났다.

코세라 코스는 끝나고 인증서를 주는데 (물론 코세라 강의를 잘 들었다 정도의 의미이다.) 저번에 Function programming In Scala 다음으로 힘들었다.

강의 자체는 C++0x까지 있어서 C++ 언어를 한번 정리하는 점으로는 좋았다. 하지만 숙제는 C/C++ 지식만 가지고는 풀수가 없었는데. 특히 알고리즘 기반의 숙제는 C++ 학습만 생각하고 시작했던 나에게는 조금 당혹스러워 했었다고 해야 하나.

There are only two hard things in Computer Science: cache invalidation and naming things. – Phil Karlton

Chef을 써보면서, 요리에 관련된 메타포를 사용하여 Chef 구성요소들의 이름들을 잘 지었다는 생각이 든다. Chef을 구성하는 요소에 대한 설명을 간단히 몇개 적어 보자면:

• Chef : 요리사,Server Configuration Project
• Recipe : 요리법,어떤 작업을 할지 서술하는 목록
• Cookbook: 요리책,Recipe의 모음집.
• Knife : 칼 요리도구,Chef의 CLI 도구
• Node : 구성 작업할 서버
• Workstation : 작업장, Knife등의 도구를 통해 Chef에 작업을 하는 머신.
• Data bag : Chef Server에 JSON기반으로 저장되는 데이터
• Run list : Node에 작업할 목록(Cookbook의 Recipe나 다른 Role을 포함할수 있다)
• Attribute : 노드의 속성. Node와 Cookbook,Role,Environment에서 정의될수 있고,순서규칙에 따라 overide가 된다.
• Role : Run list와 Attribute을 가지는 설정

물론 모든 단어가 요리에 관련된 단어는 아니다. 좀더 명확하게 설명할수 있는 요소는 굳이 사용하지 않은 듯 하다.

@Outsider님의 기분전환용 프로젝트 Gittip-links에 영감을 받아서 나도 한번 만들어 봤다.

동기

Soundcloud에서 이런 저런 Podcast을 자주 듣는 편이다. 주로 크롬 웹 브라우저에서 듣는데. 보통 탭이 한두개가 아닌지라 Soundcloud에서 듣다가 음악이나 방송을 끄거나 하려면 종종 열려 있는 탭에서 찾아야 하는 점이 불편했다. 그래서 크롬 익스텐션으로 만들어서 쉽게 (혹은 빠르게) 재생/중지를 할수 있으면 좋지 않을까 싶었다.

REST API는 RPC(Remote Procedure Call) API와 다르게 기본적으로 절차적인 명령 호출의 목록으로 설계하는 것이 아니라고 생각된다.

REST(Representational State Transfer) API는 선언적인 방법으로 리소스(Resource)의 표현되는 상태를 변화(GET,POST,PUT,PATCH,DELETE…)시키는 인터페이스라고 할수 있다.

그리고 이러한 리소스의 상태에 따라 시스템이 동작하는 구조라고 생각한다.(직접 시스템의 동작을 명령하는 인터페이스를 가진 것이 아닌.)

예를 들어, Master Server와 Master의 지령을 받는 Worker Daemon가 있다고 하자.

Master가 특정 Task를 Worker에 요청을 하려고 하는데, 여러가지 이유로 Master가 Worker에 접속을 하는 구조가 아닌, Worker가 실행할때 Master에 접속 할수만 있다고 하자.

(특히 내부 IP만 가진 Worker라면 Master가 Worker에 접속을 할수가 없다.)

10gen의 Mongodb 온라인 수업중 하나인 M102: MongoDB for DBAs을 들었다.

개인적으로 MongoDB을 많이 좋아하지는 않지만(비슷한 것으로 RethinkDB가 더 맘에 든다.) 그래서 오히려 온라인 강의를 들어서 배우는게 어떨까 싶었다.

10gen(MongoDB 제작사)은 커뮤니티를 만드는 작업을 굉장히 잘한다는 생각이 든다. 이런 온라인 코스도 코세라만큼 구성 자체를 잘 되어 있는 편.

오랜만에 데브 페스트에 놀려 갔다. https://sites.google.com/site/2013devfestwkorea/home/aboutspeaker

구글인앱빌링 사용 모듈 구현사례

안드로이드 프로그래밍을 해본 경험이 없어서,잘 알지 못하는 분야이다. 구글의 인앱빌딩 지원을 버젼별로 상세히 설명되어있고,적어도 (나처럼 무경험자에게는) 어떻게 동작하는지 알수 있는 자리이었다.

나중에 안드로이드 프로그래밍을 한다면,그때 다시 한번 찾아 볼듯 하다.

Go Lang for Java Programmer

GoLang에 대한 기본적인 문법과 개념을 설명했다. 발표에 대한 연습을 많이 했다는 걸 느낄수 있었다.

REST API을 만드는 일이 많아졌다. REST API가 이미 널리 알려진 개념이지만,RESTful하다고 할수 있는 API은 어느정도는 주관적인 요소가 개입되는 것 같다.

이번에 설계를 하면서, Twitter나 Facebook의 API을 참고하긴 했지만, 각각의 스타일의 차이를 알수는 있어도 좋은 디자인 규칙에 대한 정보를 얻기가 힘들었다.

특히 리소스 모델링 부분이 어려운데, REST API Design Rulebook을 참고하여 구성하고 있다.

Disco을 잘 모르지만, 이번에 통계관련 계산에 한번 써봤다.

map/reduce

map/reduce는 map의 결과가 하나의 reduce에서 같은 key으로 모이는 것 보장한다.로직에 따라 다르겠지만. 전체 갯수을 얻는 것이 아니라면 reduce을 늘리는 것이 성능에 좋다. (당연한 이야기이지만)

combiner

Disco 문서에서는 보기 힘든데, Hadoop처럼 combiner을 만들 수 있다. combiner은 일종의 accumulator인데. 각 map마다 map의 결과를 받아서 reduce에 넘기기전에 buffer을 가진 function(combiner)을 만들 수 있는데. 대부분의 경우 combiner을 만드는 것이 속도나 메모리 사용에 좋을 것 같다.