이번 포스팅에서는 두 번째 데이터 파이프라인 구축 오프라인 수업시간에서 배운 내용을 정리하려고 한다.
가장 일반적으로 많이 쓰이는 방식으로, 실제 VM에 서버를 띄우고 해당 로그를 취득하거나 도커나 쿠버네티스에 컨테이너에서 서버를 띄우고 로그를 취득하는 경우에도 logstash의 input의 file 플러그인을 사용해서 로그 데이터를 땡겨온다.
VM이나 컨테이너의 특정 경로에 로그 데이터를 적재해주고, 시스템 자체로는 Log rotate라고 하는 방식으로 오늘 날짜 기준으로 로그를 쌓다가 날짜가 바뀌면, 다른이름으로 압축을 하거나 삭제를 해서 새로운 로그를 다시 쌓는 방식으로 한다. 이러한 작업에 logstash와 같은 agent를 통해서 밖으로 빼내는 작업을 하는데, 이때 input의 file 플러그인을 가장 많이 사용한다고 한다.
1 | FROM nginx |
1 | $docker build -t hyungi/test1 . |
(1) 우선 디렉토리 내에 NodeJS 프로젝트를 구성한다. (server.js 및 package.json)
(2) 이미지 생성을 위해 Dockerfile 작성한다.
1 | FROM node:12-alpine |
이번 포스팅에서는 내일 있을 데이터 파이프라인 구축 관련 수업에서 실습할 내용들에 대해 미리 실습을 해보고, 개념적인 부분을 좀 다져보려고 한다.
미리 실습을 해보면서 혼자서 해보는 과정에서 생기는 의문이나 질문거리를 좀 정리해서 내일 수업시간에 적극 질문해봐야겠다.
우선 이전 실습에서는 ubuntu로 EC2 인스턴스를 하나 생성하고, EC2 인스턴스 내에 logstash와 filebeat를 설치하였다. (logstash가 Java 기반이기 때문에 JDK도 설치를 해주었다)
그리고 샘플로 받은 logstash *.conf 파일을 받아서 간단한 로그 파일을 생성해보았다.
딱 여기까지 실습을 하고 마무리 하였는데, 추가적으로 하면 좋을 부분이 있었다. 버전이 바뀌더라도 일관되게 logstash 명령을 사용하기 위해서 ln -s로 압축을 해제한 폴더와 logstash 명령을 linking해주는 추가적인 작업을 하면 좋을 것 같았고, 어느 곳에서나 logstash 명령만으로 사용할 수 있도록 .profile 파일에 logstash의 bin 폴더의 경로와 관련된 환경변수를 선언해주는 것이 좋을 것 같다고 생각했다.
1 | $ln -s logstash-7.4.0 logstash |
위의 부분에 대해서도 미리 실습을 하면서 적용을 해 볼 것이다.
2주차 수업에서는 이미 생성된 로그파일을 input의 file 플러그인을 사용해서 읽어서 output의 file 플러그인으로 새로운 파일로 추출해낼 것이다. 그리고 filter 플러그인을 사용해서 읽어들인 로그 데이터를 정제(filter 플러그인)해서 내보내는 방법에 대해서도 실습을 하고, 최종적으로 filebeat와 logstash를 연동해보는 실습까지 해 볼 예정이다.
이번 포스팅에서는 docker 실습한 내용과 docker image를 만들고, 생성한 이미지를 docker hub에서 관리하고 배포하는 부분에 대해서 정리해보려고 한다.
1 | # local에서 생성한 index.html파일을 생성할 container 내의 index.html 파일로 -v 옵션으로 생성한다. |
-v 에서 $(pwd)를 통해 현재 위치 정보를 입력할 수 있다는 것을 배웠고, local에서 생성한 파일을 -v 옵션을 사용해서 container 내의 파일을 mapping 시킬 수 있다는 것도 다시 한 번 정리할 수 있었다.
1 | $ docker run --rm \ |
php 컨테이너에서 /app 하위에 hello.php 파일을 mapping 시키고, 실행시키고자 하는 service의 버전을 지정한 뒤에 바로 php 명령을 사용해서 mapping시킨 컨테이너 내의 php 파일을 실행시킬 수 있다.
이번 포스팅에서는 본격적으로 AWS SAA(Solutions Architect Associate) level에 맞는 파트에 대해서 학습을 시작할 것이다.
그 첫 시작으로 Private, Public, Elastic IP의 비교에 대한 내용을 학습할 것이다. 이전에 EC2 인스턴스를 생성한 뒤에 속성으로 간략하게 위의 3가지 종류의 IP에 대해서 살펴보았는데, EC2인스턴스를 중지 후 재 실행하게 되면, Public IP 주소가 새롭게 생성되기 때문에 고정 IP로 사용하려면 Elastic IP를 사용하면 되고, Elastic IP의 경우에는 실제 사용이 될 때가 아닌, 사용이 되지 않을때 요금이 부가된다는 내용이 기억에 남는다.
그럼 좀 더 세부적으로 이론을 배워보고 실습해봐야겠다.
Elastic IP 주소를 사용하는 것은 권장되지 않는다.안좋은 Architecture)random public IP를 사용하고, 해당 IP에 DNS 이름을 지정해서 사용하도록 한다. (DNS -> Route 53 - 훨씬 더 많은 제어가 가능하고, 확장 가능성도 크다)Load Balancer를 사용하고, public IP를 사용하지 않도록 하는 방법도 있다. (AWS에서 취할 수 있는 최상의 Pattern이다)EC2인스턴스에 SSH 연결을 하는 경우, 같은 네트워크에 있는 것이 아니기 때문에 Private IP를 사용할 수 없다. (단 VPN을 사용하는 경우 가능)
Private IP는 AWS의 내부 네트워크 통신을 위해 사용되며, 인터넷 연결을 위해서는 Public IP가 사용된다.
오직 Public IP를 사용해서 EC2 인스턴스에 SSH 연결을 할 수 있다.
이번 포스팅에서는 빅데이터 구축의 각 단계를 6V관점에서 살펴보고, 중요 개념과 사용되는 상세 기술에 대한 내용을 정리하려고 한다. 사이드 프로젝트를 진행하면서 중간에 개념을 한 번 정리하는 이유는 데이터 파이프라인 구축에 있어, 요즘 AWS EMR이라는 관리형 서비스를 사용해서 손쉽게 하둡의 에코 시스템을 사용(단 7분이면 하둡의 에코 시스템을 사용)하고, 직접 전반적인 서비스들을 통합해서 직접 프로젝트를 진행하지 않았기 때문에 뭔가 개념적으로 정리가 되지 않은 것 같다.
그래서 이번 기회에 빅데이터의 전반적인 개념에서부터 전체적인 하둡 에코 시스템을 구성하고 있는 서비스들을 활용해서 사이드 프로젝트를 진행해보고, 좀 더 체계적으로 개념과 응용적인 부분에 대해서 정리해보려고 한다.
이번 포스팅에서는 개인 프로젝트를 목적으로 구입한 라즈베리파이 4B 모델과 라즈베리파이 SENSE HAT 종합 센서 모듈에 대해 포스팅을 하려고 한다.
우선 라즈베리파이 모듈을 주문한 이유는 첫 번째 실시간으로 생성되는 데이터가 필요했다. 기존 CSV 포멧의 데이터와 같이 정적인 데이터의 경우에는 인터넷에서 많이 구할 수 있지만, 실시간 스트리밍 데이터의 경우에는 (물론 log관련 데이터를 뽑아주는 API 서비스가 있긴 하지만) 찾기가 어려웠다. 그래서 고민하던 도중에 한 번 직접 실시간으로 스트리밍해주는 데이터를 만들어보자고 결심했고, 이것이 계기가 되어 라즈베리파이와 종합센서 모듈을 구입하게 되었다.
이번 반도체 대란으로 인해, 좀 웃돈을 주고 구입을 하였지만, 뭔가 프로젝트의 일부이긴 하지만 일상의 약간의 변화를 줄 수 있는 것 같아 주문을 하게 되었고, 라즈베리파이의 파이가 파이썬과 연관이 많이 되어있어, 현재 자주 사용하고 있는 파이썬 언어로 코딩도 많이 해 볼 수 있을 것 같았다.
이번 포스팅에서는 도커에 대해 학습한 내용에 대해서 정리하려고 한다.
도커를 이해하기 위해서는 서버를 관리하는 것에서부터 시작해야 되는데, 서버관리는 내부적으로 매우 복잡하고, 각 각의 과정이 서로 종속되어있다.
전통적인 서버 관리 방식으로 비춰보면, 서버에 특정 서비스를 설치하고자 할 때, 환경적인 제약으로 인하여 예상하지 못한 문제가 발생하기도 하고, 지속적으로 바뀌는 서버 및 개발 환경으로 인해 지속적으로 기존의 서버를 다시 설정해야 되는 경우가 생겨서, 서버의 유연성이 많이 떨어진다.
위와같은 전통적인 서버 관리 방식에서의 환경적 제약으로 인한 설정 오류와 유연한 서버 환경 교체에 대한 솔루션으로 등장하게 된 것이 바로 도커(Docker)라는 친구이다.
Docker를 사용하면, 어떠한 서비스(프로그램)을 하나의 컨테이너로 만들어서 관리를 할 수 있다.
그리고 만들어진 컨테이너는 어떤 환경적인 제약도 없이 어디서든 돌아가게 된다.(AWS, AZURE, GOOGLE CLOUD, KT UCLOUD, NAVER CLOUD PLATFORM 등…)
Docker가 등장하기 전에는 서버내에서 각 각의 서비스가 다른 버전의 Package를 사용하는 경우, 버전 변경에 있어 어려움이 있었다. 그로인해 배포를 위한 전체 과정 중에 한 부분이라도 문제가 생기게 되면 서비스가 구동이 되지 않는 문제에 직면하기도 하고, 전통적인 서버관리의 방법에는 많은 문제가 있었다.
위의 전통적인 서버관리 방식에서 생겨나게 된 문제를 개선하기 위해서 가장 먼저 도입된 것이 바로 "서버배포를 위한 메뉴얼화(문서화)"였다. 하지만, 잘 정리된 문서를 보고 따라하더라도 제대로 동작하지않는 경우도 있었고, 문저 정리가 중간에 잘 안되는 경우도 많았다. 그리고 특정 OS를 타겟으로 작성된 문서의 경우, 다른 OS에서 예외가 발생하는 경우도 많이 생겼다.
이러한 문서관리에 문제가 많아 생겨나게 된 것이 바로 "상태관리 도구(CHEF, PUPPET LABS, ANSIBLE)"이다. 이 상태관리 도구는 각 서버 설정의 단계를 스크립트로 작성을 하고 관리를 하기 때문에 스크립트를 실행함으로써 마치 서버 관리자가 STEP BY STEP으로 명령어를 작성한 것과 같은 효과를 준다.
이렇게 코드로 관리함으로써 다른 관리자들과 협업도 가능하고, 버전관리도 가능하며, 코드이기 때문에 깃과 같은 저장소로 공유도 가능하다. 하지만 상태관리 도구를 사용함에 있어 러닝커브가 높다는 문제와 한 서버에 다른 버전의 동일 서비스를 설치할 때 문제가 있다는 것을 알게 되었다.
이번 포스팅에서는 5월 29일날 오프라인 강의로 수강하였던 데이터 파이프라인 구축과 관련된 수업내용에서 대해서 정리해보려고 한다. 3시간 동안의 수업을 듣고 나서 느끼고 배웠던 점이 많았기 때문에 기대 이상의 수업이었던 것 같다.
사실 이전에 인터넷 강의로 관련 강의를 수강하였기 때문에 데이터 파이프라인을 AWS 클라우드 환경에서 구축하는 부분에 대해서는 약간의 배경지식을 가진 상태였다.
그래서 아마 오늘 이 오프라인 수업 시간이 더욱 유익하게 느껴졌는지도 모른다. 이번 수업을 통해 기존에 내가 잘 못 알고 있던 기본 개념과 단편적으로만 알고 있던 데이터 파이프라인 컴포넌트들에 대해서 좀 더 구체적으로 알게 되었던 것 같다. 그리고 가장 좋았던 점은 앞으로 어떤식으로 추가적으로 학습을 하면 좋은지에 대해서 강사님이 방향 제시를 해주신 부분이 좋았다.
그러면 이번 포스팅에서는 배웠던 이론적인 부분과 내가 잘 못 알고 있었던 부분, 그리고 앞으로 추가적으로 학습할 내용에 대해서 정리를 해보겠다.
데이터 엔지니어링 분야는 FE/BE 분야와는 다르게 정확히 정해진 F/W가 없다. 다만 빅데이터 아키텍처가 존재하며, Lambda Architecture와 Kappa Architecture, 두 아키텍처가 있다. 이 두 아키텍처에 대해서는 아래에서 정리를 해보겠다.