이번 포스팅에서는 Kafka의 Consumer Lag를 모니터링할 때 필수적으로 사용되는 Burrow에 대해서 정리해보려고 한다.

이번 포트폴리오에 추가 할 사이드 프로젝트로 Kafka를 활용해서 Kafka cluster를 구성하고, Kafka-client 라이브러리를 활용하여 Python으로 Producer 및 Consumer를 구성하였다. Consumer에서는 ELK 스택의 docker 컨테이너를 연결하여, Producer로부터 유입된 로그 데이터를 Logstash를 통해 Elasticsearch에 저자을 하고, 저장된 로그 데이터를 Kibana를 통해서 시각화하였다.

Kafka consumer는 kafka-client 라이브러리를 활용해서 Java, Python등의 언어로 개발을 할 수 있는데, 생성한 KafkaConsumer 객체를 통해 현재 lag 정보를 가져올 수 있다.

만약 lag을 실시간으로 모니터링하고 싶은 경우에는 Elasticsearch나 influxdb와 같은 곳으로 Consumer lag metric 정보를 보낸 뒤에 Grafana 대시모드를 통해서 실시간으로 시각화하여 확인 할 수 있다.

하지만 Consumer 단위에서 lag을 모니터링하는 것은 아주 위험하고, 운영요소가 많이 들어간다는 문제가 있다. 그 이유는 Consumer logic 단에서 lag을 수집하는 것은 Consumer 상태에 dependency가 걸리기 때문이다.
만약에 Consumer가 비정상적으로 종료되게 된다면, 더 이상 Consumer는 lag 정보를 보낼 수 없기 때문에 더 이상 lag을 측정할 수 없는 문제가 발생한다.

그리고 차후에 추가적으로 consumer가 개발될 때 마다 해당 consumer에 lag 정보를 특정 저장소에 저장할 수 있도록 로직을 개발해야되기 때문에 공수가 많이 든다.

만약에 consumer lag을 수집할 수 없는 consumer라면, lag을 모니터링 할 수 없기 때문에 까다로워진다.

이러한 이유로 인해 linkedIn에서는 Apache kafka와 함께 Kafka consumer lag을 효과적으로 모니터링 할 수 있도록 Burrow를 개발하였다.

Burrow는 오픈 소스 프로젝트로, Go 언어로 개발이 되었으며, 현재 깃허브에 올라가 있다. 이 Burrow는 Kafka와는 독립적인 consumer의 lag을 모니터링하기 위한 애플리케이션이다.

Burrow의 특징

Multi-Kafka cluster를 지원한다.

Kafka를 사용하는 기업에서는 보통 2개 이상의 Kafka cluster를 구성해서 사용하는데, 여러 개의 Kafka 클러스터를 구성하더라도 한 개의 Burrow만으로 모든 카프카 클러스터에 붙은 consumer의 lag을 모두 모니터링 할 수 있다.

이번 포스팅에서는 여섯 번째 데이터 파이프라인 구축 오프라인 수업시간에서 배운 내용을 정리하려고 한다.

이번 여섯 번째 수업을 마지막으로 데이터 파이프라인 구축과 관련한 데이터 엔지니어링 수업이 마무리되었다. 이번 수업을 통해 정말 많은 것들을 배울 수 있었다. 특히 이전에는 클라우드 플랫폼을 활용해서 데이터 파이프라인을 구축하는 것이 전부라고 생각했었지만, 이번 수업을 듣고나서 관리 및 운영의 관점에서 클라우드 플랫폼에서 제공하는 서비스들의 근간이 되는 오픈 소스 프로젝트의 세부 동작원리에 대해서 이해하는 것이 더 중요하다는 것을 배웠다. 그리고 클라우드 플랫폼을 활용해서 데이터 파이프라인을 처음 구축했을때 그 다음 스탭으로 어떤 식으로 공부를 이어나갈지 감을 잡지 못했었는데, 이번 총 6번의 수업동안 (6주간 진행)앞으로 어떻게 더 공부를 해야되는지, 그리고 새로운 기술스택이 나왔을때 어떤식으로 학습을 이어나가야 되는지에 대해서 알게 되었다.
이번 마지막 수업을 마무리하며 강사님이 어느 데이터 파이프라인 구축에 있어, 어느 파이프라인 구성이 정답이고 그런 건 없다고 하셨다. 그리고 수업을 들으면서 느낀 것은 정말 하나의 파이프라인을 구성할때에도 많은 것들을 고려해야하며, 파이프라인의 각 구성 요소들의 특징들을 제대로 이해하고 있어야 비로소 효율적인 파이프라인을 구축할 수 있다는 것을 배웠다. 아무튼 이번 수업을 통해 좀 더 데이터 엔지니어의 업무 중 하나인 데이터 파이프라인 구축에 대해서 좀 더 심도있게 배울 수 있었던 것 같다.

매주 한 번 강남역에 가서 세 시간씩 하루도 빠지지 않고 수업에 참여하고, 배운 내용을 블로그에 하나도 빠뜨리지 않고 기록하였다. 이런 나에게 칭찬을 하며, 마지막 수업시간에 배운 내용을 정리해보려고 한다.

ElasticSearch

ES를 NoSQL DB와 같은 저장소로써 사용을 하면서 저장된 데이터를 검색하는 용도로 사용된다. 그리고 주로 모니터링이나 로깅과 같은 용도로 많이 사용된다. 메트릭 같은 것을 JSON에 같이 담아서 Kibana를 통해서 그래프로 그려주면, 프로메테우스와 같은 TS DB와 같은 성능은 내지 못하지만, 대시보드로 충분히 그려서 활용할 수 있다. 데이터가 적은 경우에는 앞에서 설명한 것과 같이 ElasticSearch에 저장된 데이터를 Kibana를 활용해서 시각화를 해줄 수 있지만, 이러한 메트릭 값들이 많아지면, TS(Time Series) 전용으로 담아두는 TS DB를 생성해서 관리한다.
이처럼 ES는 검색엔진이지만, 다양한 용도로 사용이 되고 있다.

이번 포스팅에서는 다섯 번째 데이터 파이프라인 구축 오프라인 수업시간에서 배운 내용을 정리하려고 한다.

Flink

우선 실습에 앞서 간단하게 Flink에 대해서 정리를 해보자. Flink는 분산 데이터 처리 프레임워크 (Processing unbounded data)로, Kafka와 같은 MQ에 Flink를 붙여서 처리를 할 수 있다. 이외에도 MQ에 Kinesis Firehose를 붙이고, Lambda를 붙여서 custom한 형태의 데이터로 추출을 할 수도 있고, 데이터를 암호화하거나 특정 format(Parquet, ORC)으로 변환을 해서 추출을 할 수도 있다.
또 Logstash를 붙여서 데이터를 간단하게 처리해서 넘겨줄 수 있다. (whitelist / filter plugin을 통해 처리) 커스텀하게 데이터를 모아주거나 분석을 하는 경우, 예를들어 GPS 신호를 계속 보내서 사용자들이 이 데이터를 1분동안 aggregation해서 어느 지역에 사람이 많은지 분석하는 작업은 logstash로 분석을 하는 것이 불가능하다. 그리고 각 각의 logstash로 나눠서 분산처리를 하는 것은 가능하지만, 각 각의 logstash가 서로 데이터를 공유하지는 못하기 때문에(클러스터 내의 노드로써 존재하지 않기 때문에) 복잡한 스트림 처리나 프로세싱, 분석이 필요할때 Flink를 사용한다.

그리고 Flink, Storm을 개발할때에는 DAG를 많이 사용한다. Kafka에서 받아온 실시간 데이터를 키별로 분류를 하는 작업에서도 사용이 될 수 있는데, 게임 데이터를 분석한다고 가정했을때 각 캐릭터의 직업에 따라 분류를 해서 각 직업별로 행동 패턴을 분석하고자 할때 각 각의 Dataflow를 머릿속으로 구조화시킨 다음에 붙여주는 작업을 해야한다.
source operator(Kafka) -> keyBy operator -> aggregation operator -> HDFS sink Flink와 같은 데이터 플로우 프로그래밍이 필요한 어플리케이션은 operator와 같은 요소를 하나 하나 개발을 한 다음에 연결을 해주는 방식으로 개발을 하게 된다.

DB ETL작업을 할때 DB에서 주기적으로 데이터를 select해서 Flink내부에서 처리를 하고자 할 때에도 source operator를 사용한다. (Flink 외부에서 데이터를 긁어오는 부분을 source operator)

중간에서 데이터를 변환해주는 부분을 Transformation Operator라고 한다. 그리고 처리 결과를 밖으로 빼내는 부분을 Sink Operator라고 한다.

• Flink parallelism

  실제 flink로 어플리케이션을 개발하게 되면, 수십개의 TM가 생성이 된다.
  개발을 할때 각 각의 operator의 갯수를 parallism을 통해 정의할 수 있다.
  Kafka(3) -> Map(10) -> Sink(3) => 16개의 operator가 TM의 각 각의 노드에 분산이 되어 처리된다. 이와같은 특징으로, Fluentd와 logstash와 같은 agent 기반의 데이터 파이프라인과 비교되어 사용된다.

이번 포스팅에서는 네 번째 데이터 파이프라인 구축 오프라인 수업시간에서 배운 내용을 정리하려고 한다.

Kafka 실습환경 구축 및 Single consumer 실습

이전에 Kafka를 실습했을때는 생성한 EC2 인스턴스에 apache kafka 압축파일을 다운받고, 압축을 풀고, zookeeper와 kafka server를 시작하고, Topic을 partitions와 replication-factor 옵션의 값을 1로 생성하고 bootstrap-server 옵션은 localhost의 9092번 포트로해서 설정하였다. (kafka server: 9092, zookeeper: 2181) 이때 실습을 했을때는 세부 옵션에서 partitions이 뭔지 replication-factor가 뭔지 구체적으로 알지 못했었는데, 이제는 ISR 그룹이 뭔지 partition과 replication-factor이 뭔지 이해를 한 상태이기 때문에 좀 더 체계적으로 실습을 할 수 있는 것 같다.

그리고 이번 실습에서는 zookeeper와 kafka server를 하나의 터미널에서 명령어로 일일이 실행시키지 않고, zookeeper와 kafka host server, producer, consumer를 각각의 container로 구동을 시키기 때문에 구조적으로 좀 더 확장성 있는 것 같다. (docker image를 이용해서 컨테이너 서비스로 구동시키기 때문에 좀 더 빠르게 환경 구성을 할 수 있는 것 같다. 이래서 컨테이너로 서버를 띄우고 관리하는 것 같다.)

이번 포스팅에서는 내일 있을 데이터 파이프라인 구축 관련 수업에서 실습할 내용들에 대해 미리 실습을 해보고, 개념적인 부분을 좀 다져보려고 한다.
내일 수업에서는 Apache Kafka를 실습하는데, Kafka cluster의 각 Broker와 Zookeeper, Producer와 Consumer를 전부 Docker container로 띄우고 관리한다. 이미 Docker에 대해 공부했고, Kubernetes에 대해서 추가적으로 공부를 하는 중이라 이번 수업을 통해 Kafka의 각 구성요소들을 Docker container에 띄워서 관리하면 많은 도움이 될 것 같다.
그리고 여지까지 했던 실습들과 비교했을때 상대적으로 구조가 복잡하기 때문에 미리 Kafka의 개념적인 내용을 머릿속에 그리면서 실습하게 될 전체적인 구조에 대해서 파악하고 가야 할 필요성을 느꼈다.

이번 포스팅에서는 세 번째 데이터 파이프라인 구축 오프라인 수업시간에서 배운 내용을 정리하려고 한다. 참고로 첫 번째와 두 번째 수업때도 너무 유익한 내용들이 많았는데, 이번 시간이 정말 너무 유익하고 좋았다.
아마도 이전에 인터넷 강의로 수강을 했을 때 아쉬웠던 부분이 많았는데, 이번에 개별적으로 현직자 분께 오프라인으로 직접 수업을 들으니, 궁금했던 부분이 많이 해소되기도 했고, 강사님이 수업에 필요한 여러 자료나 실제 회사에서 업무했을 때 필요한 부분에 대해 설명을 잘 해주셔서 그런 것 같다.

이번 포스팅에서는 EC2 인스턴스의 전반적인 스토리지 옵션들에 대해서 알아본다. 스토리지 옵션에는 EBS, EC2 Instance store가 있으며, 각 각의 세부적인 특징에 대해서 알아본다.

EBS(Elastic Block Storage)

EBS는 EC2 인스턴스가 실행중인 동안 연결이 가능한 네트워크 드라이브이다. EBS 볼륨을 사용하면, 인스턴스가 종료된 후에도 데이터를 지속적으로 유지할 수 있다. 인스턴스를 재생성하고, 이전에 사용한 EBS 볼륨을 마운트하면, 데이터를 다시 받을 수 있다.

이전에 CCP자격시험을 준비할때에는 하나의 EBS는 하나의 EC2 인스턴스에만 마운트 할 수 있다고 배웠다. 그리고 하나의 인스턴스에는 다중 EBS 볼륨의 연결이 가능하다.

EBS는 특정 가용 영역에 제한되서 사용할 수 있다. 따라서 EC2 인스턴스가 생성된 AZ과 EBS의 AZ를 매칭시켜줘야 한다. 단, EBS를 snapshot해주게 되면, 다른 AZ 영역의 EC2 인스턴스에 연결해줄 수 있다.
(Free tier에서는 매달 30GB의 EBS 스토리지 를 범용 SSD나 마그네틱 유형으로 제공)

이번 포스팅에서는 두 번째 데이터 파이프라인 구축 오프라인 수업시간에서 배운 내용을 정리하려고 한다.

2주차 첫 번째 실습) logstash의 input/output의 file 플러그인 활용

가장 일반적으로 많이 쓰이는 방식으로, 실제 VM에 서버를 띄우고 해당 로그를 취득하거나 도커나 쿠버네티스에 컨테이너에서 서버를 띄우고 로그를 취득하는 경우에도 logstash의 input의 file 플러그인을 사용해서 로그 데이터를 땡겨온다.

VM이나 컨테이너의 특정 경로에 로그 데이터를 적재해주고, 시스템 자체로는 Log rotate라고 하는 방식으로 오늘 날짜 기준으로 로그를 쌓다가 날짜가 바뀌면, 다른이름으로 압축을 하거나 삭제를 해서 새로운 로그를 다시 쌓는 방식으로 한다. 이러한 작업에 logstash와 같은 agent를 통해서 밖으로 빼내는 작업을 하는데, 이때 input의 file 플러그인을 가장 많이 사용한다고 한다.

이번 포스팅에서는 내일 있을 데이터 파이프라인 구축 관련 수업에서 실습할 내용들에 대해 미리 실습을 해보고, 개념적인 부분을 좀 다져보려고 한다.
미리 실습을 해보면서 혼자서 해보는 과정에서 생기는 의문이나 질문거리를 좀 정리해서 내일 수업시간에 적극 질문해봐야겠다.

이전 수업 실습내용

우선 이전 실습에서는 ubuntu로 EC2 인스턴스를 하나 생성하고, EC2 인스턴스 내에 logstash와 filebeat를 설치하였다. (logstash가 Java 기반이기 때문에 JDK도 설치를 해주었다)

그리고 샘플로 받은 logstash *.conf 파일을 받아서 간단한 로그 파일을 생성해보았다.

딱 여기까지 실습을 하고 마무리 하였는데, 추가적으로 하면 좋을 부분이 있었다. 버전이 바뀌더라도 일관되게 logstash 명령을 사용하기 위해서 ln -s로 압축을 해제한 폴더와 logstash 명령을 linking해주는 추가적인 작업을 하면 좋을 것 같았고, 어느 곳에서나 logstash 명령만으로 사용할 수 있도록 .profile 파일에 logstash의 bin 폴더의 경로와 관련된 환경변수를 선언해주는 것이 좋을 것 같다고 생각했다.

1
2
3
4
5
6
7

$ln -s logstash-7.4.0 logstash

$vi ~/.profile
# export LS_HOME=/home/ubuntu/logstash
# PATH=$PATH:$LS_HOME/bin

$source ~/.bash_profile

위의 부분에 대해서도 미리 실습을 하면서 적용을 해 볼 것이다.

다음 시간 실습내용

2주차 수업에서는 이미 생성된 로그파일을 input의 file 플러그인을 사용해서 읽어서 output의 file 플러그인으로 새로운 파일로 추출해낼 것이다. 그리고 filter 플러그인을 사용해서 읽어들인 로그 데이터를 정제(filter 플러그인)해서 내보내는 방법에 대해서도 실습을 하고, 최종적으로 filebeat와 logstash를 연동해보는 실습까지 해 볼 예정이다.

이번 포스팅에서는 본격적으로 AWS SAA(Solutions Architect Associate) level에 맞는 파트에 대해서 학습을 시작할 것이다.

그 첫 시작으로 Private, Public, Elastic IP의 비교에 대한 내용을 학습할 것이다. 이전에 EC2 인스턴스를 생성한 뒤에 속성으로 간략하게 위의 3가지 종류의 IP에 대해서 살펴보았는데, EC2인스턴스를 중지 후 재 실행하게 되면, Public IP 주소가 새롭게 생성되기 때문에 고정 IP로 사용하려면 Elastic IP를 사용하면 되고, Elastic IP의 경우에는 실제 사용이 될 때가 아닌, 사용이 되지 않을때 요금이 부가된다는 내용이 기억에 남는다.

그럼 좀 더 세부적으로 이론을 배워보고 실습해봐야겠다.

Private & Public & Elastic IP

• Elastic IPs는 인스턴스의 고정된 Public IP를 위해 필요하다.
• Elastic IP Address는 가지고 있는데, 사용하지 않으면 과금이 된다.
• 빠르게 계정 내 다른 인스턴스로 주소를 매핑함으로써 인스턴스나 소프트웨어의 실패를 마스킹 할 수 있게 도와준다.
• 계정당 5개의 Elastic IP를 가질 수 있다. (필요에 따라 AWS 요청하여 갯수 확장 가능)
• 종합적으로 살펴보면, Elastic IP 주소를 사용하는 것은 권장되지 않는다.
  -> Elastic IP 주소를 사용하는 Architecture는 안좋은 구조적 결점으로써 언급되기도 한다.(안좋은 Architecture)
• 대신 random public IP를 사용하고, 해당 IP에 DNS 이름을 지정해서 사용하도록 한다. (DNS -> Route 53 - 훨씬 더 많은 제어가 가능하고, 확장 가능성도 크다)
• 또는 Load Balancer를 사용하고, public IP를 사용하지 않도록 하는 방법도 있다. (AWS에서 취할 수 있는 최상의 Pattern이다)

Private IP and Public IP in AWS EC2

EC2인스턴스에 SSH 연결을 하는 경우, 같은 네트워크에 있는 것이 아니기 때문에 Private IP를 사용할 수 없다. (단 VPN을 사용하는 경우 가능)
Private IP는 AWS의 내부 네트워크 통신을 위해 사용되며, 인터넷 연결을 위해서는 Public IP가 사용된다.
오직 Public IP를 사용해서 EC2 인스턴스에 SSH 연결을 할 수 있다.