여러 java 데몬을 띄워 테스트를 진행하던 중, 자바 데몬에서 특정 포트(40000)를 리스닝하기 위해 실행 중에 아래와 같은 에러가 발생하고 종료되었다.

java.net.BindException: Address already in use

netstat으로 보면, 40000으로 분명 리스닝하는 포트가 없었다. 하지만, TIME_WAIT 클라이언트 포트가 있었다. 즉, 

 curl로 es schema를 생성하면서 40000번 포트를 사용했다. 

따라서, curl이 사용한 클라이언트 포트와 리스닝하려는 자바 데몬간의 충돌이 발생했다.

그렇다면, centos 6.7 기준으로 보면, curl이 사용한 포트 범위는 어떨까? sysctl 로 확인하면 클라이언트에서 사용할 수 있는 포트 범위는 32768부터 60999이다. 

따라서, 리스닝하는 포트를 쓰려면 32767 이전 포트를 사용하는 게 가장 안전하다.

ssh를 사용하여 리모트 파일이 존재하는 지 확인하려면, 다음과 같다.

고급스럽게 사용하려면, ssh와 stat을 사용한다.

나는 Redis에 대해 많이 모르는 것 같다. 공부 많이 해야 할 것 같다.

이 책은 나처럼 Redis와 Redis 3를 좀 더 알고 싶은 사람들에게 추천한다. 몰랐던 내용을 아는 기쁨.

http://www.acornpub.co.kr/book/redis-essentials

http://www.yes24.com/24/goods/30503660

역자 소개

프로그래밍을 시작하면서 캐시 솔루션에 대해 많은 고민을 했다. 캐시는 사용할 데이터를 웹 애플리케이션 내부 메모리에 저장하면 성능을 개선할 수 있지만, 데이터 양이 너무 많다면 메모리 이슈가 발생하기 때문이다. 특히 자바의 경우는 JVM 튜닝이 필수적이었다. 웹서비스가 성장하면서 캐시 솔루션이 많이 등장하기 시작했다. 때마침 LiveJournal에서 개발되고 페이스북에서 사용한 멤캐시드(memcached)와 함께 레디스를 캐시 솔루션으로 사용할 기회가 생겼고, 캐시 솔루션에 대한 다양하게 활용해 볼 수 있었다. 현재 웹 애플리케이션은 캐시 아키텍처 덕분에 간결해지고 성능이 더욱 좋아지고 있다. 여러 프로젝트에서 레디스를 사용해봤지만, 이 책을 통해 레디스에 대한 충분히 이해함으로써 시야를 많이 넓힐 수 있었다. 기존에 사용하던 레디스 타입뿐 아니라 다양한 타입을 제대로 이해하고 활용할 수 있게 됐고, 트웸프록시(Twemproxy), 레디스 센티널(Redis Sentinel), 레디스 클러스터(Redis Cluster)의 장점과 단점을 더욱 세밀하게 알 수 있었다.
이 책을 통해 레디스 클러스터를 실전 배치에서 사용하게 됐다.
레디스를 처음 접하는 분, 레디스를 속속들이 알고 싶은 분, 레디스 3에 대해 제대로 알고 싶은 분, 다양한 언어의 레디스 클라이언트를 알고 싶은 분들에게 이 책을 추천한다.

(오타 수정)

==== 2017.7.25 덧 붙임.

현재 에이콘 출판사 홈페이지에서 Redis 핵심정리 책은

2017년 초반에 15위정도 하다가  주간 베스트 5위까지 올라갔다. 

꼭 이 책을 번역을 해야 한다고 주장했었는데, 출판 결과가 잘 나와서 기쁘다..

jvm(일반 애플리케이션)이 실행 중인 서버에서 slab memory가 끊임없이 늘어나는 현상이 발견되었다.

* slab 메모리가 있는지 확인하기 위해 다음 링크를 참조하면 쉽게 slab 메모리 정보를 구할 수 있다. (/proc/meminfo에서 Slab 영역을 얻는다)

http://atomitech.jp/hinemos/blog/?cat=12

#!/bin/bash

total=`cat /proc/meminfo | grep MemTotal | awk '{print $2}'`
free=`cat /proc/meminfo | grep MemFree | awk '{print $2}'`
buff=`cat /proc/meminfo | grep Buffers | awk '{print $2}'`
cache=`cat /proc/meminfo | grep ^Cached | awk '{print $2}'`
slab=`cat /proc/meminfo | grep Slab | awk '{print $2}'`
used=`echo "scale=2; ($total - $free - $buff - $cache - $slab) * 100 / $total" | bc`
echo "used,$used"

참고로 jvm 메모리 상태를 확인하며 gc 여부를 확인했지만 특별히 변경 내역은 없었다.

$ jstat -gc 프로세스-id 1 1

 S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT

 0.0   2048.0  0.0   2048.0 2383872.0 624640.0 1808384.0  1099923.5  61056.0 60410.3 7296.0 7135.3  32873  338.821   3      0.999  339.821

jvm은 이슈가 아닌 것 같고, vmstat으로 메모리 상태를 확인했다. 

각 필드의 항목 내용은 Num  Total   Size  Pages이다. 확실히 개수와 용량이 늘긴 늘었다

(vmstat 참고 : https://www.thomas-krenn.com/en/wiki/Linux_Performance_Measurements_using_vmstat#vmstat_-m)

다른 장비에서 동일한 명령어를 실행해서 동일하게 메모리를 확인했다. 

확실히 inode 캐시 값이 너무 커졌다. 이를 정리하기 위해 운영 체제의 vfs_cache_pressure를 사용해야 했다.

jvm이 통신하면서 임시로 메모리 공간(pagecache)을 사용한 것 같은데, 정리가 안되면서 커진 것 같았다.  캐시 데이터는 centos 내부적으로 slab 메모리로 관리된다. inode가 커널의 slab 메모리에서 관리되기 때문에 inode와 slab 메모리가 상당히 커진 것 같았다. 

vfs_cache_pressure는 pagecache를 반환하려는 값이 저장되어 있다. 기본값은 100이다. 위의 문서에 설명되어 있듯이 0이면, 메모리 반환을 하지 않고, 1000을 설정하면 계속 free공간으로 메모리를 반환하려 한다.

나는 아래와 같이 값을 큰 값을 주어 자연스럽게 slab 메모리가 빨리 정리되게 했다. 

문제는 전혀 발생하지 않았고, slab 메모리를 깔끔히 정리되었다. 

이 외에 다른 방법이 있다고 한다. 

참고로 hbase에서는 이슈가 있었다고 하니. 부하가 높은 상황에서는 조심히 사용할 필요는 있을 것 같다. 

https://brunch.co.kr/@alden/14

특정 git hash를 얻어와서, 지금까지의 history를 한 번에 보고 싶다면 git log 와 ..를 활용할 수 있다. 

git log #{from}..#{to} 이런 느낌으로 실행하면 된다.

git log ${git_hash}..HEAD

git log를 보면 좀 산만하게 보인다. 이를 pretty format을 사용한 다음, 적절한 format 양식을 다음처럼 사용하면 한 줄씩 git log를 볼 수 있다.

git hash를 얻는 부분이다. 

 yte

길게 보려면 rev-parse를 쓸 수 있다.

$ git rev-parse master

0effa0fcc670fc999ee979e95be931decba13114

긴 hash라서 짧은 hash를 이용하려면 아래와 같이 사용할 수 있다. 1byte째부터 7byte까지가 short hash이다. 

$ git rev-parse --short master

0effa0f

$ git log -1 --pretty=format:%h

0effa0f

$ git describe --always

0effa0f

BBC에서 BBC 홈페이지를 어떻게 만들었는지 간단하게 소개한 내용이 있다.

http://www.bbc.co.uk/blogs/internet/entries/47a96d23-ae04-444e-808f-678e6809765d

여기에서 주목할 내용은 Continuous Delivery를 위해 Acceptance test 용으로 mocha라는 툴을 썼다고 나온다.

http://mochajs.org/

https://github.com/mochajs/mocha

star가 10,000개가 넘을 정도로 인기가 좋다. 기회가 된다면 써봐야지..

describe('Array', function() {
  describe('#indexOf()', function() {
    it('should return -1 when the value is not present', function() {
      [1,2,3].indexOf(5).should.equal(-1);
      [1,2,3].indexOf(0).should.equal(-1);
    });
  }); 

내 나이 40 살에 2 번째 번역 책을 내놓았다.

책을 번역하겠다고 말하기 전에, 공부 삼아서 책을 번역한 후, 출판사에 문을 두드렸다. 다행히 좋은 기회를 얻었고 좋은 책의 번역자가 될 수 있었다. 

책에 오타가 많긴 했지만, 

회사에서 elasticsearch를 사용하면서 겪은 어려움에 비하면 아무 것도 아니었다. 

elasticsearch는 기존 nosql과 다른 검색용 nosql이었고, 안정적이고, 훌륭한 서버인 것 같고, elasticsearch 소스는 매우 깔끔한 편이라서 보기도 좋았다. 생동력 있는 nosql이라 앞으로 큰 기대가 된다. 

이 책은 너무 elasticsearch api에 대한 깊은 내용보다는 전체적인 개발/운영 관점으로 설명한 책이라서 내게 딱 맞는 책이었다. 

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

http://www.acornpub.co.kr/book/elasticsearch-2e

http://www.yes24.com/24/goods/24301881?scode=032&OzSrank=1

요즘 출시되는 애플리케이션의 주요 요구사항 중 하나는 검색 기능이다. 이런 검색 요구사항을 만족시키는 많은 솔루션을 상업용 제품이나 오픈소스 세계에서 찾을 수 있다. 검색에 많이 쓰이는 라이브러리 중 하나는 아파치 루씬(Apache Lucene)이다. 아파치 솔라(Apache Solr), 인덱스탱크(Indextank), 일래스틱서치 같은 많은 검색 솔루션은 루씬 라이브러리를 기반으로 만들어졌다.

일래스틱서치는 클라우드와 분산 컴퓨팅에 사용할 수 있게 개발됐다. Compass(http://www.compass-project.org) 개발자로 유명한 셰이 바논(Shay Banon)은 일래스틱서치의 주요 개발자며, 2010년 3월에 일래스틱서치의 첫 번째 버전을 배포했다.

일래스틱서치의 주목적은 검색 엔진이 되는 것이며, 일래스틱서치를 데이터 저장소로 사용할 수 있고, 집계를 사용해 분석 엔진으로 활용할 수 있다.

일래스틱서치에는 JSON/REST 기능, 맵(Map)/리듀스(Reduce) 접근 방식의 네이티브 분산 처리 기능, 쉬운 설치 기능, 플러그인 확장 기능 같은 획기적인 기능이 많다. 언급한 기능의 상세한 정보와 그 밖의 일래스틱서치 기능을 이 책에서 살펴볼 것이다.

일래스틱서치 이전에는 아파치 솔라가 일래스틱서치의 일부 기능을 제공했었다. 그러나 아파치 솔라는 클라우드에서 동작하도록 설계되지 않았으며, JSON/REST API는 지원하지 않았다. 최근 몇 년 동안, 2012년에 SlorCloud가 출시되면서 이 상황이 조금 변했다. 일래스틱서치와 아파치 솔라 제품을 완벽히 비교하고 싶은 사용자는 라팔 쿡(Rafał Kuć)이 쓴 글(http://blog.sematext.com/2012/08/23/solr-vs-elasticsearch-part-1-overview/)을 읽으면 도움이 될 것이다.

일래스틱서치는 계속 진화하는 제품이며, 일래스틱서치 회사(일래스틱서치의 상업성 지원을 제공하는 셰이 바논이 설립한 회사) 는 새로운 기능을 가진 일래스틱서치를 배포하고, 일래스틱서치 사용자는 플러그인(깃허브GitHub에서 주로 내려받을 수 있다)을 배포한다.

2012년에 설립된 일래스틱서치 회사는 총 1억 4백만 불의 자금을 조달했다. 일래스틱서치 회사의 공동 창업자이자 CEO인 스티븐 슈르만(Steven Schuurman)이 일래스틱서치의 성공을 다음과 같이 잘 표현하고 있다.

"이렇게 짧은 시간에 투자자로부터 이런 지원을 받았다는 것이 믿기지 않습니다. 이것은 우리가 하고 있는 일의 중요성을 보여줍니다. 비즈니스는 사람과 기계가 만든 데이터를 계속해서 생성하고 있으며, 비즈니스가 새로운 데이터 중심의 프로젝트에서 시작하든, 현재 비즈니스에서 하둡 또는 그 밖의 빅 데이터 투자를 활용해 시도하든, 이 자산에서 가치를 얻을 수 있는 비즈니스가 전략적 목표가 됩니다."

일래스틱서치는 검색 제품 중 괄목할 만한 실적을 내고 있으며, 5천만 개의 장소를 색인하는 포스퀘어(Foursquare)와 온라인 음악 배포 플랫폼인 SoundCloud, StumbleUpon과 천 4백만 회원을 가진 기업 소셜 네트워크 Xing 같은 고객에게 도움을 주고 있다. 또한 20테라바이트 데이터와 13억 개의 파일을 검색하는 깃허브, 로글리(Loggly)에도 도움을 주고 있다. 로글리 로그파일을 빨리 분석하기 위해, 데이터 클러스터를 색인할 수 있는 키/값 저장소로 일래스틱서치를 사용한다.

나는 일래스틱서치야말로 시장에서 나온 검색 솔루션 중 가장 강력하고, 사용하기 쉽다고 생각한다. 이 책에서 제시한 많은 예제를 통해 독자가 일래스틱서치를 관리할 수 있는 지식, 열정, 모범 사례를 전달하고자 노력했다.

deview 2014 발표 후..

http://deview.kr/2014/session?seq=15

페이지가 그리 많지 않아 번역 진행이 쉽지 않았지만, 결국 부사장님이 허락해주셨다. 

내 나이 39살 ㅎㅎ

-----------

첫 번째 번역 책 : Ansible 설정 관리 

http://www.acornpub.co.kr/book/ansible

http://www.yes24.com/24/goods/17833244?scode=032&OzSrank=1

저는 네이버에서 백엔드 플랫폼을 개발하고 운영하는 업무를 했습니다. 그중 빌드/배포 서버 개발을 담당하면서 많은 것을 배우고 경험할 수 있었습니다. 자동화에 대한 고민들과 개발자들이 좀 더 효과적으로(편하게) 업무할 수 있는 방법에 대해 특히 많이 생각했던 것 같습니다. 현재 데브옵스(Devops)가 하는 비슷한 고민들이기도 합니다.
일반적인 웹/모바일 서비스 회사의 서버는 리눅스를 사용합니다. 리눅스가 설치된 서버에 들어가 라이브러리나 데이터베이스를 설치하고, 설정을 배포합니다. 운영하다가 하드웨어 문제(하드디스크, 전원 장비, CPU, 메모리)나 소프트웨어 이슈(리눅스 배포판 업그레이드)가 발생했을 때, 다시 설치하고 설정을 배포하려면 기존과 동일하게 작업해야 합니다. 자주 하는 작업은 아니지만, 매우 중요한 일입니다. 이런 작업이 자동화될 수 있도록 지원하는 것이 바로 배포 툴입니다. 과거에는 각 회사에서 담당 개발자의 취향에 맞게 개발되고 운영했지만, 현재 배포 툴이 점차 오픈소스로 바뀌면서 (각 상황에 맞게 최적화되어) 널리 사용되고 있습니다. 퍼펫(Puppet), 셰프(Chef), 앤시블(Ansible)이 대표적인 배포 툴입니다.
앤시블은 애플리케이션과 라이브러리를 쉽게 배포할 수 있는 자동화 툴입니다. 배포나 업데이트를 하기 위해 매번 서버에 접속해서 스크립트를 배포할 필요가 없습니다. 배포 스크립트 작성 없이 사용자 정의 설정만으로 에이전트(Agent) 없는 리모트 환경에서 SSH를 이용해 서버에 접근해서 작업할 수 있습니다.
현재 앤시블은 다른 툴과 달리 가장 빠른 추세로 확산되고 있습니다. 이렇게 단기간에 많이 사용되는 이유와 강점에 대한 제 생각은 다음과 같습니다.

■ 사용하기 쉽고, 간단해서 빠른 습득과 적용이 가능합니다. 이미 알려진 표준을 활용해 쉽게 사용할 수 있고, 유지보수 및 인수인계가 간단하고 쉽습니다.
■ 멀티 플랫폼을 지원합니다. 맥(Mac)/리눅스(Linux)/윈도우(Window)를 지원하며, 테스트 환경(Vagrant)에서도 사용할 수 있습니다.
■ 에이전트(Agent) 기반이 아닌 SSH 기반으로 스크립트 배포 없이 관리 서버에서 실행할 수 있습니다.
■ 멱등성(idempotence)(여러 번 적용하더라도 결과는 동일함)이 보장되는 모듈을 지원합니다.
■ 순차 실행뿐 아니라 병렬 실행을 지원해 좀 더 빠른 처리가 가능합니다.
■ 앞으로도 개발 가능성이 높고 개발자의 참여도가 높은 오픈소스 도구입니다. 앤시블 내부는 JSON으로 통신하며, 파이썬(Python)뿐 아니라 다른 언어에서도 호환되어 개발할 수 있습니다.

레드햇, 버라이즌, 애틀라시안, 트위터, 베리사인, EA, 에버노트, 나사(NASA), 고프로, 랙스페이스, 주니퍼 등 유수의 IT 기업들이 도입했으며, 1,000명이 넘는 개발자들이 앤시블 오픈소스에 공헌하고 있습니다.
국내에서 처음으로 앤시블 관련 서적을 번역하고 알릴 수 있어 영광입니다. 모쪼록 이 책이 앤시블을 활용하고자 하는 분들께 시원한 해결책을 제시하고, 하시는 업무에 실질적인 도움이 되기를 바랍니다.