행복한디벨로퍼

쉘 스크립트를 사용하다보면 스크립트 중간에 그 다음 로직으로 넘어가기전 특정 시간동안 멈추고 싶을 경우가 있다.

그럴 경우 다음과 같이 원하는 시간만큼 간편히 sleep 시킬 수 있다.

[ shell script 간편 sleep 포맷 ]

sleep .5 # Waits 0.5 second.

sleep 5  # Waits 5 seconds.

sleep 5s # Waits 5 seconds.

sleep 5m # Waits 5 minutes.

sleep 5h # Waits 5 hours.

sleep 5d # Waits 5 days.

데이터 엔지니어로 살아가기 198일째(실시간 타겟팅 모니터링 시스템)

기존에 실시간으로 스트림으로 처리되고 있는 관심사, 리타겟팅의 경우 실제로 데이터가 잘들어갔는지 확인 할 수 있는 방법이 없었다.

데이터저장소로 카산드라를 사용하고 있는데 카산드라에서는 mysql처럼 테이블의 데이터 count를 쿼리로 확인하기 힘들다.

따라서 실시간타겟팅들이 정상적으로 동작을 안하고 있는 경우에도 알아차리기 힘들다는 문제가 있었다.

매번 타 부서를 통해 '정상적으로 리타겟팅이 안되는 것 같다' 라는 요청이 오는 경우에 한해 확인해보고 있었고

심각한 경우 하루 이상 실시간 리타겟팅 데이터가 카산드라에 적재되지 않았던 적도 있었다...

이런 문제를 해결하고자 한 시간 단위로 실시간 타겟팅에서 사용하는 데이터를 hdfs에서 가져와 실제로 들어가있는지

샘플로 몇개만 추출해 확인하는 시스템을 만드는 작업을 하였다.

이번 작업을 하며 느낀점은 항상 어떤 시스템을 만들때 만들었다는 그 자체보다는 정상적으로 시스템이 돌아가고 있는지에 대한

모니터링이 잘 작동하고 문제 발생 시 이를 감지할 수 있는 장치가 마련되어있어야 한다는 것이다.

그렇지 않고서는 좋은 시스템이라고 절대 말할 수 없을 것 같다.

꾸준히 포스팅을 하고 싶은데 마음처럼 쉽지 않다. 아마 막상 쓰게 되면 잘써야한다는 심리적 부담감이 어느 정도 작용하는 듯도 하다.

앞으로는 간단하게라도 자주 내 발자취를 기록해 나가도록 해야겠다.

먼 후에 봤을 때 좋은 기억 추억이 될 수 있도록...

아 그리고 오늘 새롭게 안사실은 Hadoop Balancer말고 Disk Balancer가 따로 존재한다는 사실이다.

Hadoop Balancer는 데이터 노드들간의 블럭정도를 balancing해주는 역할을 하고 해당 데이터노드에서 디스크간 balancing을 해주는 역할은

별도의 disk balancer가 존재해 작업을 해준다는 것이다.

이 부분은 나중에 기회가 되면 포스팅을 하도록 하겠다.

특정 포트의 프로세스를 죽이고 싶을 때 사용

특정 포트를 사용하는 프로세스를 찾고 싶을 때

lsof (list open file)을 나타내며, 

시스템에서 열린 파일 목록을 알려주고 사용하는 프로세스, 디바이스 정보, 파일의 종류등 상세한 정보를 출력해준다.

lsof -n -i4TCP:8080(원하는 port)

lsof 명령이 안먹힌다면 netstat

netstat -anp | grep LISTEN | grep :포트번호

> tcp        0      0 0.0.0.0:8080                0.0.0.0:*                   LISTEN      2542/java 

뒤에 2542가 프로세스ID이다.

[ lsof 실행결과 ]

PID를 찾아서

kill -9 PID(6079)

생각보다 서버운영시 필요할때가 많기 때문에 되도록이면 외우도록 하자~!

스프링부트(springboot)로 카산드라 데이터 모니터링 하는 프로젝트 작업 중  java.lang.NoClassDefFoundError:org/springframework/data/cassandra/mapping/UserTypeResolver 과 같은 에러가 발생해 한참을 해맸다.

일단 해결은 pom.xml 의 <parent>부분의 버전을 수정하여 해결하였다.

버전의 1.5.6버전을 하위 dependency에서 사용하는 스프링부트 버전과 맞춰주니 해결되었다. (1.5.6-> 1.2.3)

버전이 맞지않으면 예상치 못한 예외가 발생한다. 디텍팅하기도 너무 힘들뿐도로 원인파악이 너무 힘들기 때문에 메이븐 설정을 다른 프로젝트 등에서 가져다 

사용 할때는 버전을 꼭 참고하여 사용하도록 하자. 무작정 사용하는 ctrl+c, ctrl+v는 재앙을 가져올지니...

리눅스(Linux) 페이지 캐시

카프카(KAFKA) 데이터 처리방식의 특화된 기능

1. KAFKA는 기존 메시징 시스템과는 달리 메시지를 메모리대신 파일 시스템에 쌓아두고 관리한다.

2. 디스크에 기반한 영속적인 저장 방식을 사용하지만 페이지 캐시를 활용하여 높은 처리량을 제공하는 인메모리 방식에 가깝다

3. 메모리에 별도의 캐시를 구현하지 않고 OS의 페이지 캐시에 위임하고 OS가 알아서 서버의 유휴 메모리를 페이지 캐시로 사용하여 앞으로 필요한 것으로 예상되는 메시지들을 미리 읽어들여(readahead)디스크 읽기 성능을 향상 시킨다.

4. Kafka 프로세스가 직접 캐시를 관리하지 않고 OS에 위임하기 때문에 프로세스를 재시작 하더라도 OS의 페이지 캐시는 그대로 남아있기 때문에 프로세스 재시작 후 캐시를 워밍업할 필요가 없다는 장점이 있다. 

5. 여러 consumer가 한 topic으로부터 여러 번에 걸쳐 메시지를 가져올 수 있다. 이러한 방식이 가능한 이유는 클라이언트가 해당 queue에서 어느 부분까지 데이터를 받아갔는지 위치를 알려주는 'offset'을 관리하기 때문이다.

6. 메시지를 메모리에 저장하지 않기 때문에 메시지가 JVM 객체로 변환되면서 크기가 커지는 것을 방지할 수 있고 JVM의 GC로 인한 성능 저하를 피할 수 있다.

데이터 엔지니어로 살아가기 182일째(nginx ssl인증서 교체) 

오늘의 주요 업무는 로그수집서버 (nginx 8대)들의 ssl 인증서 교체해주는 작업을 진행하였다.

로그수집서버 프로젝트를 로컬에 받아 인증서를 교체 후 알파에 먼저 테스트를 진행하였다.

예전 웹서버 개발할때 많이 하던 작업인데 오랜만에 하려니 가물가물하였다.

로컬에 알파 로그수집서버 ip와 호스트명을 박아놓고 확인하니 정상적으로 요청이 잘갔다.

보통 변경된 인증서의 정보가 잘못되거나 인증서의 비밀번호가 유효하지 않다면 nginx 재시작시 문제가 발생한다.

알파에서 테스트 완료후 리얼서버 8대 한대 한대 l4를 내리고 배포하는 작업을 진행하였다.

최근 custom targeting 작업을 진행하느라 정신없었는데 ssl인증서 작업이 끝나니 홀가분하다.

좀더 custom targeting작업에 집중할 수 있겠다:)

실패하는 것이 두려운 것이 아니라, 노력하지 않는 것이 두렵다.

사람들은 자신이 하고 싶은 일을 할 수 없는 수천 가지 이유를 찾고 있는데, 정작 그들에게는 그 일을 할 수 있는 한가지 이유만 있으면 된다.

미련한 자는 자기의 경험을 통해서만 알려고 하고, 지혜로운 자는 남의 경험도 자기의 경험으로 여긴다.

 동등하지 않은 관계를 동등하게 만드는 것은 사랑밖에 없다.

 아무도 보지 않는다고 생각하고 춤을 추어라.

 누구에게도 상처받지 않는 것처럼 사랑하라.

 아무도 듣지 않는다고 생각하고 노래를 불러라.

 마치 지상이 천국인 것처럼 살아라.

 인생의 가장 큰 영광은 결코 넘어지지 않는데 있는 것이 아니라, 넘어질 때마다 일어서는데 있다.