회사에서 다른 팀의 outage report를 둘러 보던 중 Range Request 라는 키워드가 눈에 띄었다. 
정확히 어떤 종류의 요청인지 모르겠어서 Range Request 에 대해 찾아보면서 정리!

 

HTTP Range Request란?

  • 서버 -> 클라이언트로 HTTP 메세지의 일부만 전송할 수 있도록 허용하는 기술
  • 대용량 미디어 또는 파일 다운로드 도중 일시 정지, 다시 시작 기능, Pagination 기능 등에 유용히 사용됨
  • 클라이언트가 Range 헤더를 통해 특정 리소스의 일부분만 요청하면 서버가 그 부분만 리턴하는 방식으로 동작
    • e.g test.zip 파일을 100byte ~ 200byte 부분만 다운로드하는 경우 등
  • 해당 서버가 Range Request 지원 시, HTTP Header에 Accept-Ranges: Bytes 와 같은 설정 존재
  • HTTP 응답 헤더 내 Accept-Ranges 설정이 없거나, Accept-Ranges: none 으로 설정되어 있는 경우 해당 기능 지원하지 않음
#HTTP request header
GET /test.zip HTTP/1.1
Range: bytes=100-200
...

References

  • https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests
저작자표시 비영리

테스트용 Jenkins 를 구성하다보면 Production 환경의 Jenkins plugins들을 동일하게 설치하고 싶은 경우가 있다.

적게는 몇십 개부터 몇백 개까지 존재하는 plugins들을 일일이 따라 설치하거나 굉장한 중노동일것이다..

 

이때 유용하게 사용할 수 있는게 Rsync

 

Rsync를 활용해 Production 환경의 Jenkins plugins를  테스트용 Jenkins 서버에 copy 해보았다.

테스트 한 내역 설명에 앞서 Rsync 에 대해 먼저 짚어본다.

 

Rsync란?

  • Remote Synchronization의 약어로 서로 다른 서버간에 파일들을 효율적으로 전송&동기화 시켜주는 utility
  • 파일들의 timestamp와 수정 시간 등을 비교하며 synchronizing 수행
  • delta encoding이라는 알고리즘을 사용하여 네트워크 사용량을 최소화함
  • Package 관리 시스템들이 software repositories와 mirror sites를 synchronizing 하는 데 주로 사용하는 utility
  • 파일 및 디렉토리의 소유자, 권한 정보 등도 복사됨
  • SCP(Secure Copy)보다 속도가 빠름

Jenkins 를 구성하면 ${JENKINS_HOME}/plugins 디렉토리에 plugins 파일들이 위치하게 된다

아래와 같이 plugins 디렉토리 내 plugin 파일들 확인이 가능하다. (jenkins 처음 설치 시, recommended plugins만 설치한상태)

[irteamsu@hyewon-dev001-infraops-jp2v-dev .jenkins]$ cd plugins/
[irteamsu@hyewon-dev001-infraops-jp2v-dev plugins]$ ls -al
total 83576
drwxr-xr-x 78 irteamsu irteamsu     8192 Sep  7 17:42 .
drwxr-xr-x 13 irteamsu irteamsu     4096 Oct 12 15:47 ..
drwxr-xr-x  7 irteamsu irteamsu      124 Sep  4 16:20 ace-editor
-rw-r--r--  1 irteamsu irteamsu  4279042 Sep  4 16:20 ace-editor.jpi
drwxr-xr-x  4 irteamsu irteamsu       56 Sep  4 16:20 ant
drwxr-xr-x  4 irteamsu irteamsu       56 Sep  4 16:20 antisamy-markup-formatter
-rw-r--r--  1 irteamsu irteamsu  2858119 Sep  4 16:20 antisamy-markup-formatter.jpi
-rw-r--r--  1 irteamsu irteamsu    82963 Sep  4 16:20 ant.jpi
drwxr-xr-x  4 irteamsu irteamsu       56 Sep  4 16:20 apache-httpcomponents-client-4-api
-rw-r--r--  1 irteamsu irteamsu  1761975 Sep  4 16:20 apache-httpcomponents-client-4-api.jpi
drwxr-xr-x  4 irteamsu irteamsu       56 Sep  4 16:20 bouncycastle-api
-rw-r--r--  1 irteamsu irteamsu  4885133 Sep  4 16:20 bouncycastle-api.jpi
drwxr-xr-x  5 irteamsu irteamsu       70 Sep  4 16:21 branch-api
......

현재는 확장자가 .jpi 인 파일들만 확인되지만 Jenkins 를 운영하다보면 .hpi 확장자의 파일들도 종종 볼 수 있다.

본 내용 설명에 앞서 .jpi vs .hpi 파일을 잠깐 비교해 본다(나도 작업하면서 늘 궁금했지만 이제서야 찾아본다 ㅎㅎ..)

.hpi vs .jpi ?

  • .hpi는 Jenkins가 Hudson이 었을 때 legacy 확장자 (h came from Hudson)
  • .jpi는 Jenkins가 플러그인 설치 시, 생성되는 파일 확장자 (j came from Jenkins)
  • 동일한 플러그인에 대해 .hpi, .jpi 파일이 둘 다 존재하는 경우, .jpi를 우선 인식하여 적용함

 

자 그럼 이제 production Jenkins의 plugins를 내 test 서버의 Jenkins로 동기화하기 위한 shell 스크립트를 짜본다

  • copy_jenkins_plugins_to_test.sh
#!/usr/bin/env bash

set -eu

TARGET_HOST=hyewon-dev001-dev
TARGET_DIR=/home/www/jenkins/.jenkins/plugins

RSYNC_USER=$(whoami)
RSYNC_CMD=/usr/bin/rsync
RSYNC_OPTS="-avzh --delete"

RSYNC_EXCLUDE="--exclude=jobs/"
RSYNC_EXCLUDE="${RSYNC_EXCLUDE} --exclude=config-history/jobs/"
RSYNC_EXCLUDE="${RSYNC_EXCLUDE} --exclude=nodes/"

${RSYNC_CMD} ${RSYNC_OPTS} ${RSYNC_EXCLUDE} -e ssh ${TARGET_DIR}/ ${RSYNC_USER}@${TARGET_HOST}:${TARGET_DIR}

# Restart Jenkins(TARGET_HOST)
token='eqAY62UwzGK9Cl.n_sE27pTcLnYIWu/dR2T974X0'
body='{ "restartTask":{ "apache":"do nothing", "tomcat":"restart with clean working directory" }, "restartPlan":{ "numberOfConcurrentRestart":1 } }'
curl -vvv -XPOST -H "Authorization: Bearer ${token}" -H "Content-Type: application/json" -d "${body}" http://${deployment_system}/rDLgUpP2tJ/projects/jenkins-master-dev:test/restarts

 

저작자표시 비영리

[Oracle Developer Meetup 6th 참석 후기]


1) 일시: 2018.05.19

2) 장소: 아셈타워 15층 오라클

3) 주제: Kafka 제대로 이해하기

           - Kafka, 데이터 플랫폼의 최강자

4) 강연자: 고승범 (카카오 시스템셀 인프라팀 근무中) 





지원했던 프로젝트가 빅데이터 관련 프로젝트라 대용량 로그 데이터 수집 및 처리를 위해 Kafka를 사용했었다.

당시에는 개발환경 및 웹 프로젝트 구성 지원만해도 만만치않아, Kafka에 대해 따로 알아볼 여유가 없었는데

우연히 Kafka 관련 기초 세미나가 열린다해서 가봤당!


Kafka 에 대한 내용 뿐만아니라, 최신 IT 트렌드들을 공유하는 자리는 어떨까 하는 궁금증도 많았다.

어떤 사람들이 어떤 관심사를 가지고 모이는지도 궁금했구, 다른 사람들은 무슨일을 하고있나도 궁금했다

이제 막 도입해보려 온 사람들이 대부분이었지만, 벌써 Kafka를 도입해서 운영하고 있는 회사들도 생각보다 많았다.


이벤트로 Kafka 관련 책도 받았당!!!




#Kafka란?

Kafka란 대용량 메시지를 수집하고 실시간으로 처리하는 오픈소스 소프트웨어로, 2001년 LinkedIn이 개발하여

2011년 초 오픈소스 프로젝트(Apache Kafka) 로 전환되었다.


Kafka는 높은 데이터 처리량, 고 성능 분산 스트리밍 기능으로 빅데이터, 머신러닝, 블록체인 구현 시

자주 사용되는 기술로 떠오르고 있다.





#분산 스트리밍 플랫폼?

 - 메세지 큐 처리와 비슷하게 스트리밍 형태의 데이터를 publish 하고 subscribe 하는 시스템

 - 스트리밍 데이터 실시간 처리



#Kafka 언제 사용하면 좋을지?

  - 시스템 간에 안정적인 실시간 스트리밍 데이터 처리 파이프라인을 구축하고자 할 때

  - 데이터를 실시간으로 변형하거나, 반응해야 하는 실시간 스트리밍 어플리케이션 구축 시

  - 대용량 실시간 로그처리에 특화된 아키텍처 설계를 지녀 기존 메시징 시스템보다 우수한 성능의

    로그처리 시스템 구축하고자 할 때 유용


   >> 기존 메시징 시스템(ActiveMQ, RabbitMQ 등) 대비 차이점은 뭐지?

        Kafka가 좋다좋다 하는데, 기존 메시징 시스템도 써본 적이 없어..장점이 추상적으로 와닿는다.

        일단 기존 메시징 시스템 대비 Kafka가 갖는 장점은 아래와 같다고 한다.

     

        (1) 분산 시스템을 기본으로 설계되어, 기존 메시징 시스템에 비해 분산 및 복제 구성이 용이함

        (2) JMS API나 AMQP 프로토콜을 사용하지 않고, 단순히 메세지 헤더를 지닌 TCP 기반의 프로토콜을

            사용하여, 오버헤드 감소

        (3) 기존 메세징 시스템은 기본적으로 메시지를 메모리에 저장하지만, Kafka는 메시지를 파일 시스템에 저장함

            --> 별도의 설정을 하지 않아도 데이터의 영속성이 보장됨

            --> 기존 메세징 시스템은 처리되지 않은 메시지 수가 많을 수록 시스템 성능이 현저히 감소하나,

                 Kafka는 이에 영향 받지 않음. 실시간 처리뿐만 아니라 주기적인 배치 작업에 사용할 데이터를

                 쌓아두는데도 용이함

            --> 처리된 메시지를 바로 삭제하지 않고 파일 시스템에 보관후 설정한 유효기간이 지나면 삭제.

        

         (4) 기존 메시징 시스템은 Push 방식(broker가 consumer에게 메시지 push) 이지만, Kafka는 consumer가

              직접 메시지를 가지고 가는 Pull 방식으로 동작함. Consumer는 자신의 처리능력만큼만 pull 해오기 때문에

              최적의 성능을 낼 수 있음 (broker의 메시지 관리 부담 경감)

            --> 강연하셨던 고승범님도 이부분을 많이 강조하셨었다. 운영하다보면 consumer 쪽에 에러가 발생한 경우가 있는데

                 기존 메시징 시스템은 push 방식이다보니, 장애가 발생한 consumer에도 메시지를 push하고, 그 결과

                 리턴값도 에러가 발생하여 broker까지 consumer의 장애에 영향을 받을 수 있는 위험이 있었다.

                 Kafka 사용 시, pull 방식으로 동작하여, 문제가 있는 consumer는 subscribe 작업을 하지 않아

                 메시징 시스템에는 영향을 주지 않게된다.




#Kafka 기본 구성요소 및 동작 프로세스

  1) 구성요소

     : Producer(Publish 담당), Consumer (Subscribe 담당)

 

 


  2) 기본 프로세스 모델

     : Publish - Subscribe 모델을 기반으로 동작함

     : producer가 특정 topic의 메세지를 생성하여 broker에게 전달

     : broker가 전달받은 메세지를 topic 별로 분류하여 관리 (broker는 cluster로 구성됨)

     : 해당 topic을 subscribe하는 consumer가 메세지를 가져가 처리



동작 프로세스는 이해가 되는데, 실제로 내가 직접 사용해보고 동작 프로세스 정리하는게 나을 것 같다

동작 프로세스 외에 가장 궁금했던 건,

메시징 시스템을 사용해본 적이 없어..강연듣고나서도 이걸 어디에 활용할 수 있는거지~?? 하는 생각이 가장 많이 들었다.

끝나고 알아보니 아래와 같은 사용 예들이 있었다.


#Kafka 사용 케이스?

  (1) Kakao - 전사 리소스 모니터링 시스템(KEMI)

  첫 번째 세션을 강의하셨던 고승범 엔지니어가 일하고 있는 Kakao에서는 '전사 리소스 모니터링 시스템(KEMI)'에

  Kafka를 활용하고 있다. 서버, 컨테이너와 같은 리소스의 데이터를 수집하여 보여주고, 설정한 임계치에 따라

  알림을 보내주고, 수집한 로그를 대시보드 형태로 보여주거나 실시간 알림을 보내도록 구성되어있다 한다..

 

  구성도를 보는데 Kakao의 서비스 규모가 느껴진다...... ㅎㅎ

  ** 참고: http://tech.kakao.com/tags/kafka/



 



  (2) Kakao - 카카오 실시간 추천 시스템(RUBICS)

      루빅스는 카카오 사용자 반응을 실시간으로 분석하여 콘텐츠를 추천하는 실시간 추천시스템

      (다음뉴스, 카카오채널 등에 사용중)

      특히, 뉴스 콘텐츠는 다른 데이터에 비해 생명주기가 짧아 최대한 실시간으로 빠르게 수집/처리하여

      추천 랭킹에 반영해야하는 요구사항을 갖고있었다고 한다. 대용량의 사용자 피드백 메시지를

      안전하게 저장하기 위해 Apache Kafka를 사용.



   (3) Naver - 실시간 데이터 분석 플랫폼

       네이버 TV 연예 서비스에 사용되는 실시간 데이터 분석 플랫폼.

       사용자가 콘텐츠를 소비하면, 해당 콘텐츠 정보가 데이터로 변환되어

       Spring과 Kafka producer로 전송. 메시지 시스템 Kafka가 메시지 처리, 데이터 소비는

       Storm 클러스터에 배포된 토폴로지가 담당. 분석된 데이터 결과 저장은 nBase-ARC(네이버에서 사용하는 분산저장플랫폼) 가 담당.

     

       ** 참고: https://d2.naver.com/helloworld/7731491







사용 사례들을 살펴보니 활용성이 좀 와닿는다. 기술은 정말 무궁무진~~~

나도 저걸 활용할데가 있을까?_?


담번에는 한번 사용해보고 정리해봐야겠다


여러모로 생각도 많이 해보고, 동기부여가 된 재밌는 시간이었다!

후기끝~!!





저작자표시 비영리

+ Recent posts

티스토리툴바