gnuykob_sw

[출처: 실무로 배우는 빅데이터 기술, 김강원 저]

1. 플럼 Flume

1) 플럼

- 빅데이터를 수집할 때 다양한 수집 요구사항들을 해결하기 위한 기능으로 구성된 소프트웨어

- 통신 프로토콜, 메시지 포맷, 발생 주기, 데이터 크기 등 데이터를 수집할 때 고려해야 할 것들을 쉽게 해결할 수 있는 기능과 아키텍처 제공

2) 주요 구성요소

- Source : 다양한 원천 시스템의 데이터를 수집하기 위해 Avro, Thrift, JMS, Spool Dir, Kafka 등 컴포넌트 제공 / 수집한 데이터 Channel로 전달

- Channel : Source와 Sink 연결 / 데이터를 버퍼링하는 컴포넌트로 메모리, 파일, 데이터베이스를 채널의 저장소로 활용

- Sink : 수집한 데이터를 Channel로부터 전달받아 최종 목적지에 저장하기 위한 기능 / HDFS, Hive, Logger, Avro, ElasticSearch, Thrift 등 제공

- Interceptor : Source와 Channel 사이에서 데이터 필터링 및 가공하는 컴포넌트 / Timestamp, Host, Regex Filtering 등 기본 제공 + 필요 시 사용자 정의 Interceptor 추가

- Agent : Source → (Interceptor) → Channel → Sink 컴포넌트 순으로 구성된 작업 단위 / 독립된 인스턴스로 생성

3) 플럼 아키텍처

- 플럼 메커니즘 : Source, Channel, Sink 만을 활용하는 매우 단순하고 직관적인 구조

- Source에서 데이터 로드, Channel에서 데이터 임시 저장, Sink를 통해 목적지에 최종 적재

3-1) 유형 1

- 가장 단순한 플럼 에이전트 구성

- 원천 데이터를 특별한 처리 없이 단순 수집/적재

3-2) 유형 2

- Interceptor를 추가해 데이터 가공

- 데이터의 특성에 따라 Channel에서 다수의 Sink 컴포넌트로 라우팅이 필요할 때 구성

* 데이터 통신에서의 라우팅: 네트워크상에서 주소를 이용하여 목적지까지 메시지를 전달하는 방법을 체계적으로 결정하는 경로선택 과정

- 한 개의 플럼 에이전트 안에서 두 개 이상의 S-C-S 컴포넌트 구성 및 관리도 가능

3-3) 유형 3

- 플럼 에이전트에서 수집한 데이터를 에이전트 2, 3에 전송할 때 로드밸런싱, 복제, 페일오버 등의 기능을 선택적으로 수행 가능

- 수집해야 할 원천 시스템은 한 곳이지만, 높은 성능과 안정성이 필요할 때 주로 사용

* 로드밸런싱(부하분산): 서버가 처리해야 할 업무 혹은 요청을 여러 대의 서버로 나누어 처리하는 것. 한 대의 서버로 부하가 집중되지 않도록 트래픽을 관리해 각각의 서버가 최적의 퍼포먼스를 보일 수 있도록 하는 것이 목적

* 페일오버(장애 극복 기능): 컴퓨터 서버, 시스템, 네트워크 등에서 이상이 생겼을 때 예비 시스템으로 자동전환되는 기능. 시스템 설계에서 높은 가용성과 신뢰성이 요구되는 경우 페일오버 기능을 탑재하는 것이 일반적 

3-4) 유형 4

- 수집해야 할 원천 시스템이 다양하고, 대규모의 데이터가 유입될 때

- 에이전트 1, 2, 3, 4에서 수집한 데이터를 에이전트 5에서 집계하고, 이때 에이전트 6으로 이중화해서 성능과 안정성 보장

4) 활용 방안

- 스마트카에서 발생하는 로그 직접 수집하는 역할. 로그 유형에 따라 두 가지 에이전트 구성할 것

4-1) 100대의 스마트카 상태 정보 로그파일

- 로그 시뮬레이터를 통해 매일 생성됨

- 생성된 상태 정보 파일을 플럼 에이전트가 일 단위로 수집해서 하둡에 적재, 이후 대규모 배치 분석에 활용

4-2) 스마트카 운전자 100명의 운행 정보 실시간 기록

- 로그 시뮬레이터에 의해 운행 정보 실시간 로그 파일 생성됨

- 로그 발생과 동시에 플럼 에이전트가 수집해서 kafka에 전송

2. 카프카 Kafka

1) 카프카

- Message Oriented Middleware (MOM) 소프트웨어 중 하나

- 대규모로 발생하는 메시지성 데이터를 비동기 방식으로 중계

- 원천 시스템으로부터 대규모 트랜잭션 데이터가 발생했을 때, 중간에 데이터를 버퍼링하면서 타깃 시스템에 안정적으로 전송해주는 중간 시스템

2) 주요 구성요소

- Broker : 카프카의 서비스 인스턴스. 다수의 Broker를 클러스터로 구성하고 Topic이 생성되는 물리적 서버

- Topic : Broker에서 데이터의 발행/소비 처리를 위한 저장소

- Provider : Broker의 특정 Topic에 데이터를 전송(발행)하는 역할. 카프카 라이브러리를 통해 구현

- Consumer : Broker의 특정 Topic에서 데이터를 수신(소비)하는 역할. 카프카 라이브러리를 통해 구현

3) 카프카 아키텍처

- 클러스터 방식에 따라 세가지 아키텍처 구성 가능, 반드시 주키퍼 이용

3-1) 유형 1 - 싱글 브로커 / 싱글 노드

- 1대의 카프카 서버와 1개의 Broker만 구성한 아키텍처

- 대량의 발행 / 소비 요건이 없고, 업무 도메인이 단순할 때 이용

3-2) 유형 2 - 멀티 브로커 / 싱글 노드

- 1대의 카프카 서버에 2개의 Broker를 구성한 아키텍처

- 물리적인 카프카 서버가 1대이므로 대량의 발행 / 소비 요건에는 사용 어려움

- 하지만, 업무 도메인이 복잡해서 메시지 처리를 분리 관리해야 할 때 이용

3-3) 유형 3 - 멀티 브로커 / 멀티 노드

- 2대 이상의 카프카 서버로 멀티 브로커 구성

- 대규모 발행 / 소비 데이터 처리에 적합

- 물리적으로 나눠진 브로커 간의 데이터 복제가 가능해 안정성이 높음

- 업무 도메인별 메시지 그룹을 분류할 수 있어 복잡한 메시지 송/수신에 적합

4) 활용 방안

- 플럼이 실시간 데이터를 수집해 카프카 Topic에 전달하면, 카프카는 받은 데이터를 Topic에 임시로 저장하고 있다가 Consumer 프로그램이 작동해 Topic에서 데이터 가져감

- 카프카 활용 목적 : 플럼이 아주 빠르게 발생하는 데이터를 실시간으로 수집하게 되면, 이를 최종 목적지에 전달하기 전 중간에서 안정적인 버퍼링 처리가 필요

- 카프카를 거치지 않고 바로 타깃 저장소인 HBase에 전송 → HBase에 장애가 발생하면 플럼의 Channel에 전송하지 못한 데이터들이 빠르게 쌓여 곧바로 플럼의 장애로도 이어짐 → 데이터 유실 발생

- HBase에 장에가 발생해도 카프카에서 데이터를 저장해 놓았다가 HBase가 복구되면 곧바로 재처리 가능

+ 플럼이 수집한 데이터를 카프카의 토픽에 비동기로 전송함으로써 수집 속도가 빨라짐

* 비동기 방식: 동시에 일어나지 않을 수 있음 (요청을 보냈을 때 응답 상태와 상관없이 다음 동작을 수행 할 수 있음) 

  → 자원을 효율적으로 이용할 수 있음

3. 수집 파일럿 실행 1단계 - 수집 아키텍처

1) 수집 요구사항

- 차량의 다양한 장치로부터 발생하는 로그 파일 수집해서 기능별 상태 점검

- 운전자의 운행 정보가 담긴 로그를 실시간으로 수집해서 주행 패턴 분석

2) 수집 아키텍처

2-1) 로그 시뮬레이터

- 스마트카의 상태 정보와 운전자의 운행 정보 로그를 가상으로 만드는 자바 로그 발생기

- 스마트카 상태 정보 : 100대 스마트카 장치들의 상태 정보를 3초 간격으로 발생 시킴, 1일 100MB 로그 파일 생성

- 운전자 운행 정보 : 100명의 스마트카 운전자들의 운행 정보 실시간으로 발생 시킴, 하나의 운행 정보 로그는 4KB 미만, 동시에 최대 400KB 용량으로 실시간 데이터 발생

2-2) 플럼 에이전트1

- 대용량 로그 파일을 주기적으로 수집해서 표준 입출력 로거로 보여주는 레이어

- 스마트카 상태 정보를 기록한 로그 파일을 일별로 수집하기 위한 배치성 플럼 에이전트

- SpoolDir Source : 약속된 로그 발생 디렉터리를 모니터링하다가 정의된 로그 파일 발생 시 해당 파일의 내용을 읽어서 수집하는 기능 제공

- Memory Channel : SpoolDir Source로부터 수집된 데이터를 메모리 Channel에 중간 적재. 버퍼링 기능을 제공하며 , Sink와 연결되어 트랜잭션 처리 지원함

- Logger Sink : Channel로부터 읽어들인 데이터를 플럼의 표준 로그 파일로 출력

2-3) 플럼 에이전트2

- 실시간으로 발생하는 로그를 라인 단위로 수집해 카프카의 Topic에 전송하는 레이어

- 스마트카 운전자의 운행 정보 실시간으로 수집하기 위한 실시간성 플럼 에이전트

- Exec-Tail Source : 로그가 쌓이고 있는 파일에 Tail 파이프라인을 이용해 실시간으로 데이터를 수집하는 기능

- Memory Channel : Exec-Tail Source로부터 수집한 데이터를 메모리 Channel에 버퍼링 처리를 하면서 임시 적재

- Kafka Sink : Channel로부터 읽어들인 데이터를 카프카 Broker의 특정 토픽에 비동기 방식으로 전송하는 Provider 역할 수행

2-4) 기타

- 플럼이 수집한 로그 데이터 임시 출력 및 저장

- Flume Stdout : 플럼의 Logger-Sink를 통해 표준 출력 로그가 출력됨

- Kafka Topic : 플럼의 Kafka-Sink는 수집된 실시간 로그를 임시 적재함

[출처: 실무로 배우는 빅데이터 기술, 김강원 저]

1. 클라우데라 매니저(CM) 설치

- CM : 빅데이터 에코시스템을 쉽게 설치하고 관리해주는 빅데이터 시스템 자동화 도구

- 빅데이터 소프트웨어에 대한 프로비저닝, 매니지먼트, 모니터링 수행

  - 프로비저닝 : 하둡 에코시스템 편리하게 설치, 삭제, 수정 관리

  - 매니지먼트 : 설치한 에코시스템의 설정 변경 및 최적화 지원

  - 모니터링 : 하드웨어의 리소스 및 설치 컴포넌트의 상태 모니터링 / 대시보드

2. 가상머신 서버 설치

- 원래는 명령어를 이용하여 CM을 설치해야 하지만, 현재 CM 정책이 수정되어 책에 나와있는 명령어로 설치가 안됨

- 저자님의 깃허브에서 가상머신 2개 이미지 파일을 받을 수 있음

https://drive.google.com/file/d/1oLikMIC6bzt0jNV0n49YNOM0foNPXDZh/view?usp=sharing 

- 기존에 설치했던 서버들을 지우고, 이 이미지 파일로 서버를 설치하면 됨

3. 파일럿 pc 운영체제 호스트 파일 수정

- 메모장 관리자 권한으로 실행

- [파일] - [열기] 에서 C:\Windows\System32\drivers\etc 로 이동 후 hosts 파일 열기

- 가상머신에 설치한 리눅스 서버의 IP/도메인명 정보 입력 후 저장 (server01, server02만 입력)

4. 크롬으로 CM 접속

http://server01.hadoop.com:7180 

- 기동하는데 시간이 조금 걸리기 때문에 접속이 바로 안되더라도 여러 번 새로고침

- 사용자 이름, 암호 모두 admin

- CM 첫화면

- 우선은 HDFS, YARN, ZooKeeper 만 설치

- CM 홈화면

- 각 서버의 리소스(CPU,  메모리, 디스크, I/O 등)와 설치된 SW 모니터링하며 현재 상태값 보여줌

- 각 소프트웨어가 불량으로 표시되어도, 정지 상태가 아니라면 진행에 문제 없음 -> 리소스 절약

5. HDFS 구성 변경

1) HDFS 복제 계수 설정

- 하둡에서 원본 파일을 저장하면 안정성을 위해 2개의 복제본 추가로 생성해 총 3개의 파일 만들어짐

- 파일럿 프로젝트에서는 2개로도 충분하기 때문에 2개로 변경

- 복제 계수를 늘리면 여러 데이터노드에 파일이 분산 저장되어 분석 작업시 성능 극대화 

2) HDFS 접근 권한 해제

- 하둡 파일시스템에 대한 접근 권한 해제

- 테스트 환경을 고려한 설정. 실제 플젝에서는 계정별로 접근 권한 분리하여 적용

3) HDFS 블록 크기 변경

- 128MB -> 64MB 

- 파일럿 프로젝트에서 수집/적재하는 파일의 최대 크기는 110MB

- 하둡은 기본 블록 크기보다 작은 파일 처리시 효율성 떨어짐

6. YARN 구성 변경

- YARN 스케줄러와 리소스매니저 메모리 크기 설정

- 1-> 1.5 GiB

2) YARN 스케줄러 변경

- 하둡에서 job이 실행될 때 YARN의 스케줄러가 분산 데이터노드의 리소스를 고려해 잡 스케줄링

- FairScheduler -> FIFOScheduler

- Fair가 더 개선된 스케줄이지만, 개인의 pc로 이용하기에는 리소스 경합이 발생해 병목 현상 발생

* 병목 현상: 두 구성 요소의 최대 성능의 차이로 인해 한 구성 요소가 다른 하드웨어의 잠재 성능을 제한하는 것

7. 클러스터 재시작

- 설정들 최종 반영하기 위해 클러스터 재시작

- 홈에서 [Cluster 1] - [작업] - [재시작]

8. HDFS 예제 실습

- 저자님 깃허브에서 예제소스 폴더 다운로드 (제가 올려도 되는건지 모르겠어서 링크는 생략하겠습니다)

1) Filezilla로 샘플 txt 파일 -> server02 /home/bigdata 로 전송

* HDFS 명령어

https://hadoop.apache.org/docs/r3.1.2/hadoop-project-dist/hadoop-common/FileSystemShell.html

hdfs dfs [GENERIC_OPTIONS] [COMMAND_OPTIONS]

# cat : 파일 읽어서 보여줌 (리눅스 cat과 동일)
hdfs dfs -cat [경로]

# count : 폴더, 파일, 파일 사이즈
hdfs dfs -count [경로]

# ls : 디렉터리 내부 파일
hdfs dfs -ls [디렉터리]

# mkdir : 특정 path에 디렉터리 생성
hdfs dfs -mkdir (-p) [path]

# cp : 파일 복사
hdfs dfs -cp [소스 경로] [복사 경로]

2) 파일 저장 및 확인

cd /home/bigdata
hdfs dfs -put Sample.txt /tmp

- Sample.txt 파일이 HDFS의 /tmp 디렉터리로 저장됨

hdfs dfs -ls /tmp

- 파일 목록에 Sample.txt 존재

3) 파일 내용 보기

hdfs dfs -cat /tmp/Sample.txt

4) 저장한 파일 상태 확인

hdfs dfs -stat '%b %o %r %u %n' /tmp/Sample.txt

- 파일 크기, 파일 블록 크기, 복제 수, 소유자명, 파일명 정보 보여줌

5) 파일 이름 바꾸기

hdfs dfs -mv /tmp/Sample.txt /tmp/Sample2.txt

- Sample.txt -> Sample2.txt로 변경

6) 파일 시스템 상태 검사

hdfs fsck /

- 전체 크기, 디렉터리 수, 파일 수, 노트 수 등 파일 시스템의 전체 상태 보여줌

hdfs dfsadmin -report

- 하둡 파일시스템의 기본 정보 및 통계 보여줌

* HDFS 파일의 비정상 상태

- HDFS 점검 명령을 실행할 때 파일 시스템에 문제가 발생할 경우 "CORRUPT FILES", "MISSING BLOCKS", "MISSING SIZE", "CORRUPT BLOCKS" 등의 항목에 숫자가 표기됨

- 이 같은 상태가 지속되면 하둡은 물론 HBase, 하이브 등에 부분적인 문제 발생 가능

- HDFS는 비정상적인 파일 블록 발견한 경우 다른 노드에 복구하려고 시도, 사용자가 직접 삭제/이동 명령 조치할 수 있음

# 강제로 안전모드 해제
hdfs dfsadmin -safemode leave

# 손상된 파일 강제로 삭제
hdfs fsck / -delete

# 손상된 파일을 /lost + found 디렉터리로 이동
hdfs fsck / -move

9. 주키퍼 클라이언트 명령을 이용한 설치 확인

1) zookeeper-client 실행

zookeeper-client

2) 주키퍼 z노드 등록/조회/삭제

create /pilot-pjt bigdata
ls /
get /pilot-pjt
delete /pilot-pjt

- bigdata를 담고 있는 pilot-pjt 라는 znode 생성, 조회, 삭제

** zookeeper와 znode

- zookeeper : 분산 어플리케이션을 구성하기 쉽게 도와주는 시스템 (znode로 구성된 분산 데이터 모델을 지원하는 시스템)

- z노드 : 클러스터를 구성하고 있는 각각의 서버

- 주키퍼는 데이터를 디렉터리 구조로 관리하며, key-value 스토리지처럼 key로 접근 가능

- 디렉터리 구조의 각 데이터 노드가 znode

# 참고 사이트

https://engkimbs.tistory.com/660

10. 스마트카 로그 시뮬레이터 설치

1) server02에 작업 폴더 생성

cd /home
mkdir -p /home/pilot-pjt/working/car-batch-log
mkdir /home/pilot-pjt/working/driver-realtime-log
chmod 777 -R /home/pilot-pjt

2) 자바 컴파일, 실행 환경 변경 (1.7 -> 1.8)

rm /usr/bin/java
rm /usr/bin/javac
ln -s /usr/java/jdk1.8.0_181-cloudera/bin/javac /usr/bin/javac
ln -s /usr/java/jdk1.8.0_181-cloudera/bin/java /usr/bin/java

java -version

- 1.8.0_181 확인

3) 자바로 만들어진 스마트카 로그 시뮬레이터 프로그램 server02에 업로드

- 파일질라 이용

- bigdata.smartcar.loggen-1.0.jar 파일을 /home/pilot-pjt/working에 업로드

# 저 파일을 열어서 코드를 보고싶었는데 일단 찾은 방법들이 전부 맥으로는 실행이 안돼서 다음에 시도해보겠음 ,,

4) 스마트카 로그 시뮬레이터 실행

- bigdata.smartcar.loggen-1.0.jar 파일에 두 개의 메인 자바프로그램이 있음

- 1. 스마트카 운전자의 운행 정보를 실시간으로 발생시키는 DriverLogMain.java

- 2. 스마트카의 상태 정보를 주기적으로 발생시키는 CarLoginMain.java

- DriverLogMain.java 먼저 실행

cd /home/pilot-pjt/working
java -cp bigdata.smartcar.loggen-1.0.jar com.wikibook.bigdata.smartcar.loggen.DriverLogMain 20160101 10

* java -cp [경로] [클래스 이름]  (현재 열려 있는 명령 창에서만 유효)

- cp (classpath) : JVM이 프로그램을 실행할 때 클래스 파일을 찾는 데 기준이 되는 파일 경로, JVM의 매개 변수

- 자바에서 외부 라이브러리 파일이나 jar 파일 포함하여 컴파일하기 위해서는 classpath 이용

- bigdata.smartcar.loggen-1.0.jar : 포함하고자 하는 라이브러리나 jar 파일 (필요한 클래스 파일들)

- com.wikibook.bigdata.smartcar.loggen.DriverLogMain : 컴파일 할 파일

- 시뮬레이터 작동 확인

cd /home/pilot-pjt/working/driver-realtime-log
tail -f SmartCarDriverInfo.log

- 데이터 형식 정의

- CarLogMain.java 실행

cd /home/pilot-pjt/working
java -cp bigdata.smartcar.loggen-1.0.jar com.wikibook.bigdata.smartcar.loggen.CarLogMain 20160101 10

* 코드 설명

- 첫번째 매개 변수: 실행 날짜 

- 두번째 매개 변수: 스마트카 대 수

-> 2016년 1월 1일 기준으로 10대의 스마트카에 대한 로그 파일인 SmartCarStatusInfo_20160101.txt 생성됨

- 시뮬레이터 작동 확인

cd /home/pilot-pjt/working/SmartCar
tail -f SmartCarStatusInfo_20160101.txt

- 데이터 형식 정의

[출처: 실무로 배우는 빅데이터 기술, 김강원 저]

1. 설치해야 할 응용프로그램

- JAVA (Java SE 8u-)

- 이클립스

- Oracle Virtual Box

- PuTTY (SSH 접속 프로그램)

- FileZilla (FTP 접속 프로그램)

- Chrome

2. 리눅스 가상머신 환경 구성

1) CentOS 설치

2) 첫번째 리눅스 가상머신 - Server01

- 메모리 2048MB

- 가상 하드 드라이브 동적 할당 30~40GB

- OS: CentOS

3) 고정 IP, 네트워크 설정

vi /etc/sysconfig/network-scripts/ifcfg-eth0

# vi: 문서 편집 환경
# " i " 를 눌러서 입력모드 -> 수정
# " : "를 눌러서 명령모드
# 명령모드 진입 후 wq 를 눌러서 저장 후 종료

- 노란색으로 칠한 두번째 줄은 Server01 가상머신의 MAC 주소로, 가상머신 - [설정] - [네트워크] - [어댑터 2]로 이동해서 나온 MAC 주소 값을 두글자씩 잘라서 " : "로 연결하여 입력하면 됨

* /etc/sysconfig/network-scripts 

  - IP에 대한 설정 스크립트 등 있음 

  - 안에 있는 ifcfg-* 파일 수정하여 IP 변경 (+ GATEWAY, NETMASK, DNS 등 관리)

  - /ifcfg-eth0 : 리눅스 이더넷 카드(네트워크 인터페이스 컨트롤러) 0번 설정 파일

* DEVICE : 네트워크 인터페이스의 종류

* HWADDR : MAC 주소

* ONBOOT : 부팅시 자동 활성 여부

* BOOTPROTO : ip 할당 방식

  - static : 아이피 지정

  - dhcp : 동적 아이피

* IPADDR : IP 주소

* NETMASK : 서브넷 마스크 주소

* GATEWAY : 게이트웨이 주소

* NETWORK : 네트워크 주소

# 리눅스 vi 편집기 명령어 모음 참고

https://velog.io/@zeesoo/Linux-vi-%ED%8E%B8%EC%A7%91%EA%B8%B0-%EC%82%AC%EC%9A%A9%EB%B2%95-%EB%B0%8F-%EB%AA%85%EB%A0%B9%EC%96%B4

vi /etc/udev/rules.d/70-persistent-net.rules

- CentOS 리눅스가 기본값으로 설정한 네트워크 룰 삭제하여 향후 발생할 수 있는 네트워크 충돌 방지

- 위의 파일로 들어가서 자동으로 입력되어 있는 값 전부 삭제 또는 주석 처리 (#)

- 이후 앞서 설정한 고정 IP인 '192.168.56.101'을 할당받기 위해 가상머신 재시작

4) 네트워크 서비스에 고정 IP 인식

service network restart

- restart 명령을 실행한 후, 특별한 오류가 발생하지 않으면 고정 IP 설정이 완료된 것

5) Server01 고정 IP 확인

ifconfig eth0

6) SSH 접속을 위한 패키지 설정

* yum : 패키지 관리 명령어

* yum <옵션> <명령어> <패키지명>

* 패키지 설치, 업데이트, 삭제, 패키지 목록 확인 등

yum install openssh*        // OpenSSH 설치
service sshd restart
chkconfig sshd on
reboot

# reboot 완료 후
service network restart

3. 원격 SSH 접속 프로그램인 PuTTY로 Server01("192.168.56.101") 접속

4. Server01 호스트 정보 수정

vi /etc/hosts

# 수정 전

# 수정 후

- Server01 뿐만 아니라 앞으로 만들 Server02, Server03 IP 및 호스트 정보 설정

- 모두 소문자로 작성

- Server01 HOSTNAME 설정

vi /etc/sysconfig/network

* 리눅스 로그인 했을 때 [root@server01 ~]#

  - root는 사용자 계정

  - server01 이 현재 네트워크의 이름 (호스트명)

  - ~ 는 현재 사용자가 위치한 곳

- 서비스 명령으로 네트워크 설정 재시작

service network restart

5. Server01 방화벽 및 기타 커널 매개변수 설정

1) config 파일에서 SELINUX를 "SELINUX=disabled"로 수정

* config 파일 : 설정 파일

* SELinux :  관리자가 시스템 액세스 권한을 효과적으로 제어할 수 있게 하는 리눅스 시스템용 보안 아키텍처

  - 시스템 애플리케이션, 프로세스, 파일에 대한 액세스 제어 정의

  - 파일을 여는 프로세스와 같은 엑세스를 명시적으로 허용하는 SELinux 정책 규칙이 없으면 액세스 거부됨

vi /etc/selinux/config

2) iptables 중지 명령

* iptables : 리눅스에서 방화벽을 설정하는 도구 (패킷필터링 도구)

* 광범위한 프로토콜 상태 추적, 패킷 어플리케이션 계층검사, 속도 제한, 필터링 정책 명시 매커니즘 제공

service iptables stop

# iptables 중지 명령 오류 해결 참고 사이트 (첫번째 답변)

http://daplus.net/networking-centos-7%EC%97%90%EC%84%9C-iptables%EB%A5%BC-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%82%AC%EC%9A%A9%ED%95%A0-%EC%88%98-%EC%9E%88%EC%8A%B5%EB%8B%88%EA%B9%8C-%EB%8B%AB%EC%9D%80/

3) iptables 자동 시작 중지 명령

chkconfig iptables off

4) ip6tables 자동 시작 중지 명령

* ip6tables : IPv6 체계에서 사용

 chkconfig ip6tables off

5) vm swappiness 사용 제어 설정

* sysctl : (시스템의 /proc/sys 디렉토리 밑에 있는) 커널 변수 값을 제어하여 시스템 최적화

* 일반적으로 커널 매개변수 변경: /proc 디렉토리 밑 항목 vi 편집기 이용하여 변경 / echo 명령 이용

* -w variable=value 옵션: 변수에 값 설정

sysctl -w vm.swappiness=100

6) sysctl.conf 파일에서 "vm.swappiness=100" 설정 추가

* vm.swappiness : 리눅스 커널 속성 중 하나로 스왑메모리 활용 수준 조절

* Swap 메모리 : 실제 메모리 램이 가득 찼지만 더 많은 메모리가 필요할 때, 디스크 공간을 이용하여 부족한 메모리를 대체할 수 있는 공간 (실제 디스크 공간을 메모리처럼 사용하는 개념 -> 가상 메모리라고 할 수 있음)

* 리눅스에서 Swap : 실제 메모리에 올라와 있는 메모리 블록들 중 당장 쓰이지 않는 것을 디스크에 저장하고, 이를 통해 가용 메모리 영역 늘림

vi /etc/sysctl.conf

7) rc.local 파일에서 아래 명령어 추가

* rc.local 파일 : 부팅시 자동실행 명령어 스크립트를 수행하며, 일반적으로 서버 부팅시마다 매번 자동 실행되기 ㄹ원하는 명령어를 넣음

# transparent_hugepage 설명

https://hoing.io/archives/809

vi /etc/rc.local

# 서비스 생성 및 등록 -> transparnet huge page 비활성화
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

8) limits.conf 파일에서 아래의 파일 디스크립터 설정 추가

* limits.conf 파일 : 서버 리소스 관리 - 서버 다운 예방

  <domain> <type> <item> <value> 로 추가 입력

* <domain> : 제한할 대상 작성 (*, user명, 그룹명(@)) 

* <type>

  - soft : 새로운 프로그램을 생성하면 기본으로 적용되는 한도 (이 용량 넘으면 경고 메시지)

  - hard : 최대로 늘릴 수 있는 한도 (어떠한 일이 있어도 이 용량을 넘을 수 없음)

  - 통상적으로 soft와 hard 1:1로 맞추어 설정

* <item>

  - nproc (number of processes) : 최대 프로세스 개수 (KB)

  - nofile (number of open files) : 한 번에 열 수 있는 최대 파일 수 

  - 리눅스에서는 모든 개체를 파일로 보기에 nproc을 높이면 nofile도 같이 올려줄 것

* <value> : 제한하고자 하는 설정값

vi /etc/security/limits.conf

root soft nofile 65536
root hard nofile 65536
*    soft nofile 65536
*    hard nofile 65536
root soft nproc 32768
root hard nproc 32768
*    soft nproc 32768
*    hard nproc 32768

# 서버 리부팅
reboot

- 5번 과정 명령어 모음

6. 가상머신 복제

1) 복제 대상인 Server01 전원 끄고, 복제 작업이 완료될 때까지 시작하지 않음

2) Server01 우클릭하여 "복제" 클릭

3) 이름은 "Server02"로, "모든 네트워크 카드의 MAC 주소 초기화" 체크

7. Server02 설정 수정

1) MAC 주소, 고정 IP 수정

vi /etc/sysconfig/network-scripts/ifcfg-eth0

- 노란색으로 칠해져 있는 부분 (MAC 주소, IP 주소) 수정

2) 리눅스가 자동으로 설정한 Server01 네트워크 룰 삭제

vi /etc/udev/rules.d/70-persistent-net.rules

- 쓰여있는 내용 전부 주석 처리 / 삭제

3) Server02 종료 후 다시 시작 -> 새로운 네트워크 정보 할당

4) Server02 호스트 정보 수정

vi /etc/hosts

5) Server02 호스트명 수정

vi /etc/sysconfig/network

6) 네트워크 설정 정보 재시작 및 운영체제 리부트

service network restart
reboot

7) 네트워크 설정 반영 확인

ifconfig eth0
hostname

8. Server03 복제 (고사양 파일럿 아키텍처)

- Server02 복제와 같은 순서로 진행

9. 가상머신 CPU와 메모리 리소스 설정 최적화

- 고사양 파일럿 아키텍처 (CPU: i5 이상, 메모리: 16GB)

- Server01, Server02: 5120MB, Server03: 3072MB

10. 고정 IP 주소로 PuTTY 접속환경 구성

- Host name과 Saved Sessions을 적고 Save로 저장해둠

[출처: 실무로 배우는 빅데이터 기술, 김강원 저]

1. 요구사항 파악

1) 차량의 다양한 장치로부터 발생하는 로그 파일을 수집해서 기능별 상태를 점검한다.

2) 운전자의 운행 정보가 담긴 로그를 실시간으로 수집해서 주행 패턴을 분석한다.

2. 데이터셋 살펴보기

1) 스마트카 상태 정보 데이터

- 스마트카의 각종 센서로부터 발생하는 차량의 상태 정보 데이터셋

- 요구사항 1과 관련, 로그 시뮬레이터를 통해 생성됨

2) 스마트카 운전자 운행 데이터

- 스마트카 운전자의 운전 패턴/ 운행 정보가 담긴 데이터셋

- 요구사항 2와 관련, 로그 시뮬레이터를 통해 생성됨

3) 스마트카 마스터 데이터

- 스마트카 운전자의 프로파일 정보가 담긴 데이터셋

- 요구사항 1, 2와 관련된 분석 데이터셋을 만들 때 활용, 이미 만들어진 샘플 파일 이용

4) 스마트카 물품 구매 이력 데이터

- 스마트카 운전자가 차량 내의 스마트 스크린을 통해 쇼핑몰에서 구입한 차량 물품 구매 목록 데이터셋

- 요구사항 1, 2와 관련된 분석 데이터셋을 만들 때 활용, 이미 만들어진 샘플 파일 이용

3. 파일럿 프로젝트 소프트웨어 아키텍처

- 하둡을 중심으로 앞쪽을 수집/적재 (전처리) 영역, 뒤쪽을 탐색/분석 (후처리) 영역

1) 수집 레이어

- Flume: 차량의 로그 수집

- Storm: 실시간 로그 이벤트 처리

- Kafka: 플럼과 스톰 사이에서 데이터의 안정적인 수집을 위해 버퍼링, 트랜잭션 처리

2) 적재 레이어

- Hadoop, HBase, Redis

- 대용량 로그파일: 플럼 -> 하둡

- 실시간 데이터: 플럼 -> 카프카 -> 스톰 -> HBase/Redis

- 스톰을 통해 실시간 이벤트 분석 -> 결과에 따라 HBase와 레디스로 나누어 적재

3) 처리/탐색 레이어

- 하이브: 하둡에 적재된 데이터 정제/변형/통합/분리/탐색 등의 작업 수행, 데이터를 정형화된 구조로 정규화해 데이터마트 생성

- 스쿱: 가공/분석된 데이터 외부로 제공 + 분석/응용 단계에서도 사용

- 우지: 길고 복잡한 처리/탐색 프로세스를 우지의 워크플로로 구성해 복잡도 낮추고 자동화

4) 분석/응용 레이어

- 임팔라, 제플린: 스마트카 상태 점검과 운전자 운행 패턴 빠르게 분석

- 머하웃, 스파크ML: 스마트카 데이터 분석을 위한 군집, 분류/예측, 추천 등

- R: 통계 분석

- 텐서플로: 딥러닝 모델 생성

- 플라스크: 서비스 API 제공

4. 하드웨어 아키텍처

5. Cloudera Manager (CM)

- 빅데이터 자동화 관리 툴

- 하둡을 포함한 에코시스템 17개 편리하게 설치 및 관리