11월, 2018의 게시물 표시

(AWS) ElasticBeansTalk 로 도커 컨테이너 배포하기

1. Single Container인 경우 Dockerfile 을 생성하여 이미지를 사용자 지정하고 Docker 컨테이너를 Elastic Beanstalk에 배포합니다. Dockerrun.aws.json  파일을 생성하여 기존 Docker 이미지에서 Elastic Beanstalk으로 Docker 컨테이너를 배포합니다. 애플리케이션 파일, 모든 애플리케이션 파일 종속성,  Dockerfile  및  Dockerrun.aws.json  파일이 포함된  .zip 파일을 만듭니다.  Dockerfile  또는  Dockerrun.aws.json  파일만 사용하여 애플리케이션을 배포하는 경우 파일을 .zip 파일로 압축할 필요가 없습니다. 2. MultiContainer인 경우 docker-compose.yml 을 Dockerrun.aws.json 으로 변경한다. 이를 쉽게해주는 pip 라이브러리가 존재한다. (https://container-transform.readthedocs.io/en/latest/) ElasticbeansTalk 생성시 멀티 컨테이너로 옵션을 변경하여 생성한다. 그후 생성한 Dockerrun.aws.json파일을 업로드 한다. 업로드가 되더라도, 로그를 보게되면 에러로그가 있을 수 있다. 이는 외부에서 도커 컨테이너로 접속시 아이피 주소를 인식하지 못하는 경우이다. 이를 위해 다음과 같이 변경한다. localhost:9092 -> 생성한 (url):(port번호) (외부 접속시) 참고 사이트 : https://rmoff.net/2018/08/02/kafka-listeners-explained

(Docker) Docker compose 에서 ports와 expose의 차이

둘다 포트를 명시하지만 차이점이 존재한다. 만약 호스트(즉, 컨테이너 밖인 로컬)에서 해당 컨테이너로 접속하기 위해서는 ports에 해당값을 명시한다. Expose는 컨테이너 간의 포트를 바라볼때 사용한다.

(kafka) 장애 복구 정리

이미지
1. WAS -> Kafka (연결불가능) 이 경우 Producer(소셜엔진) 에서 카프카로 데이터 전송시 exception이 발생 이 exception을 소셜엔진엔서 callback을 이용해 실패로그로 저장하던지 MongoDB에 저장하여 실패 데이터를 기록 이와 같은 케이스는 다음과 같은 방법으로 실패를 처리할 수 있다 1) retries 옵션에 적당한 값을 설정해 실패 시 재시도 (엄청난 지연 발생가능) 2) 전송 실패시 발생하는 Exception을 catch에 큐에저장 후 다시 재전송 실패가 지속되면 카프카 문제로 판단해 실패로그를 저장 혹은 MongoDB 에 해당 데이터 저장 참고 : http://readme.skplanet.com/?p=13042 Scenario 1 - Fire-and-forget with a failed node and partition leader fail-over (acks=0) 이 케이스는 프로듀서에서 acknowledgements를 받지 않는다. 즉, 전송만 계속하는 것으로 만약 현재 카프카 호스트의 Leader 가 다운된다면 가정) 약 10만개 메시지 전송 중, 3만개 메시지 전송 중, 카프카 leader가 down되었을 때 새로운 leader를 선출하게된다. 이 텀동안 데이터 유실이 발생 약 6700여개 메시지 전송 실패 Scenario 2 - Acks=1 with a failed node and partition leader fail-over ack0=1인 경우, Leader노드가 fail된 경우. 이 케이스 또한 데이터 유실이 발생한다. 그러나 acks=0 인 경우보다 데이터 유실 발생이 더 적다. 테스트) 10만 메시지를 한개의 Producer에서 전송했을 때, 3만번쨰에서 Leader가 죽고, 새로운 Leader 가 선출되었을때, 약 5개의 데이터 손실 발생, 약 9만개 메시지는 Producer 에 응답함 Sc

(Kafka) 카프카 스트림즈 아키텍처

이미지
카프카 스트림즈에 들어오는 데이터는 카프카 토픽 메시지이다. 스트림과 카프카 토픽의 관계는 다음과 같다. 각 스트림 파티션은 카프카의 토픽 파티션에 저장된 정렬된 메시지이다. 스트림 데이터 레코드는 카프카 해당 토픽의 메시지(키+값)이다. 데이터 레코드의 키를 통해 다음 스트림(=카프카 토픽) 으로 전달된다. 카프카 스트림즈는 입력 스트림의 파티션 개수만큼 태스크를 생성한다. 각 태스크에는 입력 스트림(즉 카프카 토픽) 파티션들이 할당되고, 이것은 한번 정해지면 입력 토픽의 파티션에 변화가 생기지 않는 한 변하지 않는다. 각 입력스트림으로 부터 할당받은 태스크 파티션은  변화하지 않는다. 머신이 중지되더라도, 해당 태스크가 재시작해야한다.  카프카 스트림즈는 사용자가 스레드의 개수를 지정할 수 있게 해주며, 1개의 스레드는 1개이상의 태스크를 처리할 수 있습니다. 다음 그림은 1개의 스레드에서 2개의 스트림 태스크가 수행되는 모습을 보여준다.

(Kafka) 카프카 스트림즈란?

이미지
카프카 스트림즈는 카프카에 저장된 데이터를 처리하고 분석하기 위해 개발된 클라이언트 라이브러리이다. 카프카 스트림즈는 이벤트 시간 과 처리 시간 을 분리해서 다루고 다양한 시간 간격 옵션을 지원하기에 실시간 분석을 간단하지만 효율적으로 진행할 수 있습니다. 카프카 스트림즈는 스파크 스트림이나 스톰과 같이 스트림 처리를 하는 프로세서들이 서로 연결되어 형상, 즉, 토폴로지를 만들어서 처리하는 API 이다.  스트림 : 끈임없이 전달되는 데이터 세트를 의미한다. 스트림에 기록하는 단위는 키-값 형태이다.  스트림 처리 애플리케이션 : 카프카 스트림 클라이언트를 사용하는 애플리케이션으로, 하나 이상의 프로세서 토폴로지에서 처리되는 로직을 의미한다. 프로세서 토폴로지는 스트림 프로세서가 서로 연결된 그래프를 의미한다. 스트림 프로세서 : 프로세서 토폴로지를 이루는 하나의 노드를 말하며, 노드들은 프로세서 형상에 의해 연결된 하나의 입력 스트림으로부터 데이터를 받아서 변환한 다음 다시 연결된 프로세서에 보내는 역할을 한다.