분류

2020년 7월 25일 토요일

tacx vertex smart roller 즈위프트 연동, 블루투스 오류해결까지.

개요 

최근 자덕질에 빠져있습니다. 못난 목수가 장비 탓을 하는 현상이 발생하고 있습니다. 따라서 장비를 요모조모 업그레이드 하는 중 입니다. 7월은 중국산 trust 카본 로드 프레임부터 이런저런 장비를 질렀는데 그 중 첫 번째 도착한 탁스 버텍스 스마트 롤러가 3일이나 속을 썩힌 관계로 해당 내용을 자세히 정리해보겠습니다. 

1. 구매

유로존 제품임에도 불구하고 국내 구매를 했습니다. 여러 루트를 통해 가격을 알아봤으나, 배송비를 포함하면 약 60만원이 되지만 현재 국내에서 39만원에 판매하고 있습니다. 

n 쇼핑 사이트 최저가

유로존에서 구매 시 455$ 가량에 판매되고 있으며, 배송비를 포함하면 500$ 약 60만원에 관세가 부과 될 예정이라 현재로서는 국내 구매가 쌉니다. 

2. 외형

가. 박스 포장과 부속 구성

박스 외부
일단 박스 포장은 내부 스티로폼이 견고하게 버텨주는 구조로 되어있어서 파손에 대한 염려는 없습니다. 

박스 내 스티로폼 포장된 스탠드 약 54cm

블루투스 모터 약 30cm(가속과 저항을 담당)

tacx 트레이닝 앱 1개월 쿠폰과 설명서

앞바퀴 받침

저항모터 체결 장치(약10cm)와 전용 QR(약 19cm)

3. 제품설치 


조립 방법은 동영상을 보면 간단하기에 알아듣기 힘든 한 부분만 이야기 하자면 딱 한 부분이 있습니다. 바로 본인의 바퀴 사이즈를 알아야 한다는 것. 

휠 사이즈 별 홈.
지원되는 휠 사이즈가 3가지 유형으로 되어있습니다. 로드의 경우 2번에 맞추면 되지만.. 다른 자전거는 확인이 필요합니다. 타이어의 휠 부분만 줄자로 재어보면 간단히 확인할 수 있습니다. 

또한 전원선이 약 1.5m 밖에 되지 않기에 제품의 설치 위치 근처에 반드시 콘센트나 연장선이 있어야 합니다. 

조립완료 약 63cm
설치 크기는 약 2m가량이 필요합니다.  정확히는 세로 170cm 폭 63cm 이었습니다. 무난하게 타고내리기 위해서는 폭 1m가량이 필요합니다. 

4.ANT+없이 zwift연동 및 블루투스 오류 해결

즈위프트를 다운로드해서 설치하는 것은 위 링크를 클릭해서 설치만 하면 되니 전혀 어렵지 않습니다. 그냥 다음 버튼만 누르세요. 용량이 크지도 않고 어렵지도 않습니다. 

설치 완료 후 실행하면 업데이트 진행 이후 아래와 같은 화면이 나옵니다. 

windows 에서 발생하는 블루투스 오류
bluethooth 마크가 노란색 ! 느낌표가 있는데요. 이 상태는 2가지의 오류가 있을 경우 입니다. 하나는 블루투스 버전이 4.0 이하이거나. 블루투스가 없는 경우. 입니다. 혹은 WINDOWS10 1903버전 이하인 경우 입니다. 

이럴 경우 가장 쉬운 해결하는 방법은 캠패니언 앱을 선택해서 연동하는 것 입니다. 일단 PC의  ZWIFT와 휴대폰의 캠패니언 앱을 모두 실행해야 합니다. 그러면 연결된 디바이스 상단의 설정 마크를 누릅니다. 
캠패니언 앱 미실행시

캠패니언 앱이 실행되면 아래쪽 버튼이 활성화 되고 선택하면 앱을 통해 디바이스를 검색할 수 있습니다. 
캠패니언 앱을 통해 연결된 경우 
캠패니언 앱을 통해 스마트 롤러에 연결 된 경우 위 화면과 같이 왼쪽 위 블루투스 그림이 휴대폰 안에 블루투스 그림이 됩니다. 개인적으로는 이렇게 연결 할 경우 제 휴대폰에선 자주 스마트 트레이너가 연동되지 않으며, 트레이너의 반응이 늦는 경우가 매우 많습니다. 즉 불편했습니다. (중국 샤오미 폰이라 그럴지 모릅니다. ) 

그래서 저는 오류를 해결하기로 마음먹었습니다. 

인터넷에는 ant+동글을 사서 쓰라는 의견이 가장 많습니다. 하지만 추가 금액이 약 7만 원 들어가므로 무료로 해결하는 방안을 마련하였습니다. 

가. 블루투스 버전 오류 해결 

블루투스 오류의 경우 우선 아래 화면에 진입해야 합니다. 윈도우 시작 버튼을 누른 다음 '컴퓨터 관리' 혹은 'compmgmt.msc'를 입력합니다. 
컴퓨터관리 화면
컴퓨터 관리 화면에 진입하면 왼쪽 탭의 장치 관리자를 누릅니다. 그러면 보시는 바와 같이 오른쪽에 장치가 나타나는데 블루투스의 유무와 버전 정보를 확인할 수 있습니다. 

bluetooth -> bluetooth Adapter 더블 클릭 -> 고급 순으로 클릭을 진행하면 펌웨어 버전 정보를 확인할 수 있습니다. 

이중 LMP정보를 기준으로 블루투스 버전을 확인할 수 있습니다. 

zwift 블루투스 호환 버전표
LMP 버전 블루투스 버전
LMP 9.x Bluetooth 5.0
LMP 8.x Bluetooth 4.2
LMP 7.x Bluetooth 4.1
LMP 6.x Bluetooth 4.0
LMP 5.x Bluetooth 3.0 + HS
LMP 4.x Bluetooth 2.1 + EDR
LMP 3.x Bluetooth 2.0 + EDR
LMP 2.x Bluetooth 1.2
LMP 1.x Bluetooth 1.1
LMP 0.x Bluetooth 1.0b

블루투스 버전이 4.0 이하이거나, 블루투스 장치가 없다면 신규 구매를 해야 합니다. 

넥스트 531WBT 

저는 사전에 블루투스와 와이파이가 겸용되는 동글을 구매하였으며 해당 버전이 4.2 이상이기에 문제없이 연결할 수 있었습니다. 

나. WINDOWS 버전 문제 

WINDOWS 버전이 1903 이하인 경우 동일한 증상이 나타납니다. 윈도우를 업데이트 받으면 해결되며 윈도우 시작 버튼과 설정 버튼을 누르면 바로 업데이트 화면이 보이기에 쉽게 해결할 수 있습니다. 

윈도우즈 버전 확인은 시작버튼 -> 설정 -> 시스템 -> 정보 순으로 들어가면 아래와 같은 화면을 확인할 수 있습니다. 
윈도우 버전 정보 확인

그러나 크랙을 통해 WINDOWS 10을 설치해서 버전 업그레이드를 못한다면 라이센스를 구매하는 것을 권장합니다. 현재 국내법이 없기에 OEM 라이선스를 유로존 법률에 따라 구매, 설치할 수 있습니다. 

윈도우를 크랙으로 깔았을 경우 아래 링크를 따라 윈도우를 구매 후 재설치 해 주세요 


다. 불완전 연결 

불완전 연결은 아래와 같이 파워소스와 케이던스만 연결되고 트레이너는 연결이 안되는 상태가 되는 것을 말합니다. 이렇게 되는 케이스는 3가지가 있습니다. 차례대로 해결 방법을 알려드리겠습니다. 
불완전 연결

1) 휴대폰으로 연결 한 경우 

휴대폰을 통해 연결할 경우 자주 발생하는 연결 상태이며, PC를 통해 연결했을 경우에도 발생합니다. 위 사진과 같이 파워소스와 케이던스는 연결 되지만 스마트 트레이너는 연결 안 되는 상태 입니다. 여러번 사용해본 결과 원래 파워소스와 케이던스만 연결되고 스마트 트레이너는 그 이후 20초가량 지나야 연결 됩니다. 

2) 블루투스 연결을 잘못 한 경우 

PC연결의 경우 '가'와 '나' 항을 모두 해결하면 기본적으로는 되지만 이후에도 안 되는 경우가 발생할 수 있습니다.  ZWIFT가 아니라 WINDOWS 에 스마트 트레이너를 연결한 경우 입니다. 
WINDOWS 의 블루투스 연결 화면
혹시 위와 같은 화면을 통해 스마트 트레이너를  WINDOWS와 직접 연결해줬다면 연결을 해제하시기 바랍니다. 

3) 펌웨어 버전 오류 

탁스에서는 스마트 트레이너의 출고 시 펌웨어가 모두 업데이트 되어 출고된다고 공지하고 있지만 제가 갖고 있던 트레이너의 경우 펌웨어가 이전 버전이라 모든 기능이 정상적이지만 PC연결 시 트레이너만 연결이 안되는 증상이 있었습니다.

그래서 혹시나 해서 펌웨어 업데이트 법을 살펴봤습니다. 그리고 해결되었습니다. 

방법은 어렵지 않습니다. 다음과 같습니다. 
탁스 업데이트 도구
플레이스토어나 앱스토어에서 TACX UTILITY를 받아서 실행하세요.
 
업데이트 메뉴
트레이너 업데이트 매뉴에 들어가면 위와 같이 현재 버전과 최종버전이 나옵니다. 현재 버전은 0.0.0 (공장 초기 출고상태 2015년 이전 제품인 것 같습니다.) 

화면 가운데 Cancelled 라는 부분이 Update Now 라고 원래 쓰여 있는데 실수로 눌렀다가 캡처를 위해 취소했더니 저렇게 나옵니다. 앱을 종료 후 다시 실행시키면 됩니다. 해당 버튼을 눌러서 업데이트를 실행하면 정상적으로 연결할 수 있습니다. 약 5분 소요됩니다.
zwift+win10+탁스 보텍스 스마트롤러+블루투스 연결 성공

파워소스나 케이던스 아무거나 먼저 연결하면 나머지는 따라서 됩니다. 트레이너가 가장 늦으니 10초 기다려주세요. 이게 휴대폰보다 몇 배 더 안정적이고, 트레이너의 반응도 매우 부드럽고 원활합니다. 

이상입니다. 
기나긴 글 읽어주셔서 감사합니다. 
누군가에게 도움이 되었으면 좋겠군요. 

연관된 글이 있습니다. 
tacx vertex smart roller 즈위프트 연동, 블루투스 오류해결까지.

2020년 7월 17일 금요일

초저가 액션캠 eken h9 사용기와 설정정보.

개요 

짭프로 라고 불리는 EKEN H9 를 지난4월 구매했습니다. 용도는 자전거용 블랙박스로 구매했는데, 회사 업무가 바쁜 관계로 이래저래 한번도 써보지도 못하고 벌써 3달이 지나서 이제야 글을 씁니다. 

처음 살 때 걱정했던 것들. 기본적으로 딸려오는 패키지에 자전거 마운트가 있긴 하지만 부실해 보인다.  정도였고, 실제로 9시간을 촬영할 수 있는 성능을 발휘하는지 의문이었습니다. 

그럼에도 불구하고 구매하게 된 이유는 역시 가격입니다. 단돈 4만원에 액션캠과 악세사리류가 제법 딸려오는 것이 매력이죠. 그중 가장 기본적으로 필요했던 녀석은 자전거 타는 중 비가 오는 경우가 종종 있으니 방수캡은 제게 필수지만.. 나머지 옵션들은 계륵같이 느껴집니다. 

알리에서 판매하는 EKEN H9의 기본 구성품

4k는 솔직히 필요하지 않습니다. 이렇게 조그만 카메라에서 4K화질로 촬영한다면 몇 분 촬영하지 못할게 당연하니까요. 크기가 클수록 그리고 더 많이 화면을 저장할수록 배터리가 빨리 다니까. 블랙박스로 활용할 수 있는 시간이 줄어듭니다. 

실제로 배터리 완충 이후 1080P 60FPS로 사용해보니 약 2시간 만에 배터리가 종료되어 더 촬영이 되지 않았습니다. 전 구간을 이상 없이 촬영하기 위해선 설정을 좀 해야 할 것 같습니다. 

가민 마운트에 역으로 장착

게다가 역으로 장착해야 하니 이 부분에 대한 설정도 해야겠습니다. 

1. 외형 및 기능

일단 이 문서를 만드는 이유는 제가 사자마자 설정 메뉴얼을 버렸기에 직접 하다 보니 어디서 찾기가 힘들어서입니다. 


각 위치별 사진 
위치별 기능으로는 
정면 : 전원  및 모드버튼 
뒷면 : 스크린 
상부 : 촬영 및 설정 화면에서 선택버튼 
하부 : 배터리 삽입구
오른쪽 : 데이터, 전원, 리모콘 인터페이스 
왼쪽 : 상하 버튼으로 구성되어 있습니다. 

다음은 각 버튼별 설명입니다. 


가. 정면 

정면은 렌즈와 전원 버튼이 붙어있습니다. 
전원버튼은 4가지 모드로 구성되어있습니다. 
1) 처음 3초간 누르면 전원 켜짐과 동영상 모드 
2) 버튼을 한 번 더 누르면 사진 촬영 모드 (단일)
3) 버튼을 2번 누르면 사진 연속 촬영 모드 
4) 전원 버튼을 3번 누르면 저장된 사진 , 동영상 보기 모드 (왼쪽 방향키로 조절)
5) 전원 버튼을 4번 누르면 설정 모드 

나. 상부 

동그란 버튼은 각종 촬영의 시작과 종료 그리고 설정화면에서의 선택 기능을 합니다. 

다. 왼쪽 

일반 촬영모드에서는 위쪽 버튼을 누르면 동영상, 사진을 선택할 수 있는 화면, 그리고 아래쪽 버튼을 누르면 와이파이 연결 기능이 나옵니다. 와이파이는 폰으로 직접 연결되는 형태입니다. 


  
플레이 스토어를 통한 ez-icam 다운  
ez-icam 연결 화면 
휴대폰에서 ez-icam 어플을 다운로드 받을 경우 위와 같은 기능을 확인할 수 있습니다. wifi를 연결해 리모콘처럼 사용할 수 있고, 약간의 카메라 관련 설정을 수행할 수 있습니다. 하지만 와이파이를 사용하면 배터리 수명이 약 10%정도 더 줄어듭니다. 

2. 설정 

전원버튼을 3초 눌러 전원을 켜고 전원버튼을 다시 4번 더 누르면 설정 마크가 뜹니다. 
환경설정 화면
이 상태에서 상단의 촬영 버튼을 누르면 설정 모드에 들어가게 됩니다. 

설정화면 진입

1) 언어설정 

아래로 오른쪽의 하단 내리기 버튼을 9번 더 누르면 Language 설정이 나옵니다. 
이때 상단 촬영 버튼을 한번 누르고 위로 2번 올리면 한국어 설정이 나옵니다. 

2) 상하반전

eken h9의 경우 상하 반전이 지원되어 가민 마운트 하단에 역으로 장착할 수 있습니다. 
설정화면에서 위로가기 버튼을 7회 누르면 회전 180이 있습니다. 단점은 이걸 누르면 화면은 반전되나 버튼 위아래는 반전되지 않기에 잘못 누를 경우가 증가합니다. 설정을 모두 한 후 마지막에 적용 하세요. 

3) 노출 설정 

노출 설정이 자동으로 되면 좋겠지만 그렇지 않은 제품입니다. 따라서 촬영 환경에 따라 노출을 설정해줘야 합니다. 개인적으로는 노출은 0.7정도를 추천합니다. 

전체 노출은 -2.0, -1.7, -1.3, -1.0, -0.7, -0.3 0 0.3, 0.7, 1.0, 1.3, 1.7, 2.0 으로 이루어져있습니다. 

그중 .0에 해당하는 사진을 5장 같은 환경에서 비교해보았습니다. 
비가 내릴랑 말랑 흐린 날. 
노출 -2.0

노출 -1.0

노출 0

노출 1.0

노출 2.0
app에서는 이런 설정이 설정되지 않는 것이 아쉽습니다. (일부 해상도와 화이트벨런스 조절만 됩니다. )

3. 동영상 촬영

액션캠인만큼 동영상 촬영이 메인이라 생각되어 동영상 촬영을 진행해보았습니다. 
초기에 촬영을 몇 회 진행해 보았는데 모두 버렸습니다. 

첫 번째 제공되는 방수 커버가 유격이 상당히 있어 뒷면에 스폰지를 일부 테이핑해서 진동을 잡도록 하였습니다. 

처음 방수커버에 넣으신 후 위아래로 흔들어보면 상당히 많이 흔들리는 것을 알 수 있을 겁니다.

삼성 128GB 클래스 10으로 촬영하였습니다. 
노출은 +0.7 로 세팅하였습니다. 
촬영 설정은 1080p 30fps 입니다.  
초기 1080P 60FPS로 촬영하였을 경우 배터리가 2시간 만에 종료되어 프레임을 낮췄습니다. 그럼에도 불구하고 2시간 촬영이 최대입니다. 
음 4k는 해보진 않았지만 촬영 자체는 대체로 2시간이면 종료되는 것 같습니다. 해상도에 영향을 받지 않는 것 같습니다. 

따라서 장시간 라이딩이 예정되면 2시간당 배터리 1.2개 정도 사용된다고 보면 됩니다. 

촬영분 중 시간에 따라 4개를 올려보겠습니다. 

1) 1080P 30FPS 촬영

가. 주간촬영 



나. 해질녘



다. 야간 조명 없는 도로


라. 야간 조명있는 도로 


뭐 1080p로 찍은 것에 30fps인 것을 감안하면 제법 나쁘지 않은 정도입니다. 자전거용 블박으로 쓰기에 크게 나쁘진 않은 것 같습니다. 하지만 액티비티를 촬영해서 기념으로 남기기엔 무언가 좀 부족한 것 같기도 합니다. 

2) 4K 촬영

4K 촬영을 실제로 해보니 제법 괜찮습니다. 
배터리 라이프는 1시간 20분 가량 되며 화질이 엄청 깨끗하게 찍힙니다. 
게다가 다른 촬영 모드와 달리 화면을 멈추거나 캡처 했을 때 주변 역시 깨끗하게 찍힙니다. 단점은 제 컴퓨터가 4K화면을 지원하지 않습니다. 그리고 유투브가 아닌 블로거에 올릴 수 있는 방법이 없네요; 일단 업로드 하려면 저화질로 해야 하는데, 여러 문제가 있어 차라리 캡처를 올리기로 했습니다. (10초만 해도 100MB가 넘어서 올라가질 않습니다. )
단점은 제 컴퓨터가 워낙 낡아서 ; (7년된...) 4K 동영상을 플레이 할 경우 프레임 건너뛰기가 엄청 심합니다. ; 

그럼에도 불구하고 4K 촬영은 제법 감동입니다. 컴퓨터를 바꿔야 할 판입니다. ㅎㅎ;;;  심지어 1080P 60FPS도 감당이 안되는군요... 

2021.05. 추가
약 1년간 사용하다보니 종종 생기는 문제점이 확신이 되었습니다. 바로 촬영한 동영상의 개수가 종종 사라진다는 것이죠. 원인은 알 수 없습니다. SD 카드는 삼성 128GB EVO를 사용했을 경우에도, 32GB PRO 를 사용 했을 때도, 샌디스크 제품을 사용했을 때도 사라집니다. 

사라진 파일은 photo폴더에 들어가있습니다. ; 프로그램 오류로 저장소가 오락가락 하는 것 같습니다. 


이상입니다. 읽어주셔서 감사합니다. 

2020년 7월 8일 수요일

Linux(Centos)로 분리된 2개의 망 연결하기 (routing설정)

1. 개요 
회사에서 사용하는 공유기를 통해 Hadoop 서버에 연결하여 사용하는 중입니다. 최근 하둡 시스템의 네트워킹 성능 향상을 위해 광랜 망을 구성하였는데 광 단자로만 이루어진 스위치를 사용하다보니 기존 UTF 기반의 network을 연결할 수 없게 되었습니다. 

이를 해결하고자 네트워크 본딩, NAT나 브릿지를 설정하려고 하던 중 그냥 라우팅만으로 해결할 수 있을 것 같아 해당 방법을 실행 해 보았습니다. 

시스템의 구성은 이렇습니다. 
1GB 망 192.168.0.X 대역
100G 망 192.168.1.X 대역 

네트워크 구성(클릭하면 커집니다.) 

2개의 Lan 카드가 물리적으로 장착되어 있고 사용자는 ip time 공유기를 통해 192.168.0.x 대역의 서버에 접속할 수밖에 없습니다. 광랜망을 통해 하둡 서버를 통신하게 하기 위해서 IP대역이 분리되었는데 분리된 망으로 서버를 구성할 경우 접속을 할 수 없었습니다. 

2. NETWORK 연결 
일단 원하는 목표는 단순합니다. 192.168.0.X 대역에서 192.168.1.X 대역에 접속만 할 수 있으면 됩니다. 뭐 인터넷망과 내부 사설망 연결하는 다른 방식과 크게 다르지 않습니다. 
이렇게 말이죠. 
2개의 사설망을 iptable을 이용해 통합.

복잡하게 이런 저런 일들을 하는 것 보다 단순한 게 좋습니다. 경로에 해당하는 IP TIME과 데이터노드 102번에 대한 설정을 진행하겠습니다. 

가. 공유기 설정 
IP TIME 공유기를 통해 192.168.1.X 대역의 라우팅을 192.168.1.102 서버에 설정합니다.
꼭 102가 아니어도 됩니다. Linux 서버 중 광랜과 통신할 수 있는 1.101, 2, 3, 4 모두 가능합니다. 

우선 위 그림과 같이 IP TIME관리자 페이지에 접속하여 
고급설정 -> NAT/라우터 관리 -> 라우팅 테이블 관리를 통해 
192.168.1.0을 입력하고 MASK 24 GATEWAY를 라우터로 사용할 서버로 설정합니다. 
끝자리를 0으로 설정하는 이유는 0은 실제로 존재하지 않는 IP입니다. 0을 입력하면 해당 대역 전체를 사용하겠다는 의미로 라우터가 받아드립니다. 

따라서 192.168.1.X 대역에 대한 호출은 모두 102번으로 가게 되는 겁니다. 

결과 확인을 위해 사용자 pc를 열어서 ping -t 192.168.1.102를 해놓았었습니다. 라우팅 테이블이 적용됨과 동시에 102에서의 응답을 받을 수 있습니다. 
하지만 102를 제외한 나머지 101, 103, 104 서버는 여전히 통신이 불가능합니다. 


나. CentOS설정
이제 192.168.0.0 대역에서 오는 192.168.1.0 요청을 192.168.1.1로 보내게 하면 되는 것 같습니다. 

switch나 공유기에서 하는 라우팅 테이블 설정이 리눅스, windows모두 가능합니다. 저희 시스템은 Linux 기반이기 때문에 리눅스에서 했습니다. 

1) routing 확인 
먼저 route 명령을 쳐서 routing table을 확인합니다. 
기본 구성된 route 테이블 
192.168.1.102에 패킷 테스트가 바로 성공해서 의아했는데 기본 gateway가 0.0.0.0으로 둘 다 공유되어 있어서 가능했나봅니다. 
--------------------------------------------------------------------------------
우선 위 사진의 "기본 구성된 route 테이블" 처럼 라우팅 테이블이 구성되어 있다면 network 카드 2개에서 발생하는 모든 패킷이 공유되는 것으로 보입니다. 따라서 라우팅 테이블은 손댈 필요가 없습니다. 

없을 경우 아래 정보를 입력합니다. 
routing 테이블에 네트워크 각각 ip영역에 대한 인터페이스 정보를 추가합니다. 
# route add -net 192.168.0.0/24 gw 192.168.0.1 enp4s0
# route add -net 192.168.1.0/24 gw 192.168.1.1 enp1s0
--------------------------------------------------------------------------------

다음은 IP 포워딩 설정합니다. 
우선 기본 포워딩을 지워주고 
# iptables -P FORWARD DROP

다음은 각 랜카드에 포워딩 허용설정을 해줍니다. 
# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -A FORWARD -o enp1s0 -j ACCEPT
# iptables -A FORWARD -o enp4s0 -j ACCEPT


다음은 192.168.1. 대역에 가상ip로 접속 가능하게 허용을 해줍니다. 
# iptables -t nat -A POSTROUTING -o enp1s0  -j MASQUERADE


# 기타 centos 8.4의 경우 masquerade 설정이 firewalld 에도 존재하므로 다음 커맨드를  

# firewall-cmd --add-masquerade

3. 완료

위 설정이 다 끝나면 기본적으로 192.168.1.101~4 모두 통신이 돼야 합니다. 사용자 pc에서 ping 테스트를 모두 마친 후 정상이라면 이제 iptable 내용을 저장해야합니다.  현재 커맨드를 통해 적용된 규칙은 재부팅되면 날아가게 됩니다. 

iptables-services를 설치하면 시스템 종료 이후에도 설정 값을 유지할 수 있습니다. 다음 순서에 따라 진행하세요 


1) 방화벽 비활성화 
# systemctl disable firewalld

2) iptable 서비스 설치 
# yum install iptables-services

3) ip테이블 서비스 활성화 
# systemctl enable iptables

4) 규칙 저장 
# service iptables save

규칙은 위 과정에서 이미 다 설정이 되었으므로 별도로 작업하지 않아도 됩니다. 
위 4단계 작업을 수행했으면 해당 서버를 재부팅 된 이후에는 사용자 커맨드 환경에서 간단한 명령을 통해 network이 정상적으로 연결되었는지 확인할 수 있습니다. 
linux 콘솔이라면 traceroute  192.168.1.x
windows 콘솔이라면 tracert 192.168.1.x
명령을 통해 다음과 같은 화면을 확인하실 수 있습니다. 


###############################################################
2020.10.26 echo 1 > /proc/sys/net/ipv4/ip_forward 저장 오류 발생 
ip forward 허용 설정이 풀리는 현상이 갑자기 발생하였습니다. 
해당 설정을 영구저장 하기 위한 파일은 
/etc/sysctl.conf 파일입니다. 
해당 파일에 아래 한줄을 추가하면 재부팅 이후에도 정상 적용 됩니다. 
net.ipv4.ip_forward = 1 
###############################################################
이상입니다. 긴 글 읽느라 수고 많으셨습니다. 
읽어주셔서 감사합니다. 

2020년 3월 29일 일요일

빅알자 6.시계열 DB를 알아봅시다.

1. 개요 

시계열DB는 영문으로 "Time Series DataBase" 시간을 기반으로 삼은 빅데이터 처리 시스템을 이야기 합니다. 과거 빅데이터를 처리할 만큼의 하드웨어 인프라가 잘 갖춰지지 않았던 시절 센서 데이터를 실시간으로 처리하기 위한 기반으로 만들어졌다고 봄이 옳습니다. 실제로 시계열 DB가 강조하는 대부분의 기능은 실시간으로 데이터를 저장하고, 시각화 한다는 것을 무척 강조하고 있습니다.


2. 시계열 DB 시장점유율

일단 데이터베이스 마켓 순위를 보면 시계열 DB는 전체 순위에 들지 못합니다.

https://db-engines.com/의 자료 인용
https://db-engines.com/ 사이트에서 조사한 전체 시스템에서 RDB가 압도적인 우위를 차지하고 있으며 시계열 DB는 RDB(Relational DBMS)의 1/5 정도밖에 되지 않습니다. 그렇다고 해서 시계열DB가 나쁘거나 한건 아닙니다.

https://db-engines.com/의 자료 인용
지난 2년간의 추세를 보면 압도적인 증가 추세를 보이고 있습니다.

왜 이런 현상이 일어나는지는 지난번에 소개해드린 글을 보면 알 수 있습니다.
5.빅데이터 처리 성능. 네트워크 전략

간단히 얘기하면, 물리적으로 엄청난 양의 데이터가 지속적으로 생겨나기 때문에 구세대의 저장장치에 저장했다가 데이터 분석을 위해 꺼내는 데만 해도 수주가 걸릴 만큼 거대하기 때문이죠. 현재 대부분의 데이터베이스 처리 시스템 인프라는 기껏 해야 10Gb/s 속도의 스위치 그리고 hdd 베이스의 저장 장치를 사용하고 있습니다.

서버용 scsi 드라이브라 하더라도 개별 저장소의 I/O 최대 속도는 250MB/s에 불과하고 분산 처리된 파일을 네트워크로 공유하더라도 초당 1.5GB/s에 불과한데 쌓여있는 데이터는 PetaByte이기 때문입니다. 네트워크 속도 최대로 데이터를 추출 하더라도 1PetaByte를 추출하는데 걸리는 시간은 약 9일입니다. 물론 단순계산입니다. 대부분의 데이터 처리 시스템은 데이터 입출력이 항상 일어나고 있기 때문에 I/O부하를 생각한다면 예상 시간은 약 5~9배가 됩니다.

이런 지연 때문에 데이터를 인출하는 것 자체가 어려워지자 이러한 데이터를 분석하기 위해서 시계열 DB는 가장 데이터에 접근하기 좋은 방법을 채택했습니다. 바로 시간을 기준으로 데이터를 분산 처리하고 해당 파티션만 메모리에 올려 분석을 쉽게 만든 것이죠.

3. 시계열 DB의 데이터 저장 구조  

뭐 대부분 유사한 형태를 취하기에 알아본 중 가장 간결하게 구조를 보여주는 DB 설명서는 "Apache druid" 였습니다.
드루이드 에서는 시간의 분할 단위를 chunk '청크'라고 표현 합니다. chunk는 같은 시간 범위 내에 존재하는 데이터이고, 이 시간 범위 내에서 데이터는 RDBMS의 파티션과 같은 구조로 다시 분할됩니다. (청크를 폴더, Segment를 파일로 생각하면 이해가 쉽습니다.)
https://druid.apache.org/인용 드루이드의 SEGMENT 분할 
뭐 이런 구조로 데이터를 분할하는 것은 드루이드만의 기술은 아닐 겁니다. 분명 다른 시계열 DB도 같은 형태를 취하겠죠. 이러한 형태로 데이터를 분할해 저장하면 생기는 이점은 쿼리를 수행할 때 쿼리에 시간을 제약조건으로 사용하여 메모리에 로드할 파일의 양 자체를 줄일 수 있기 때문입니다.

RDB의 파티셔닝과 유사하지만, 다른 점은 RDB에선 파티셔닝을 255개 혹은 1024개, 서브파티션을 포함해서 만여 개를 만들 수 있지만, 관리자가 사전에 생성을 해줘야 하는 점이 다릅니다. RDB에서도 최근에는 빅데이터 처리를 위해 자동 파티셔닝을 지원하는 DB가 있습니다. 그 이야기는 다음에 하겠습니다.

과거에는 빅데이터 처리에 SPARK같은 IN MEMORY 프로세스를 중심으로 처리하는 프로세스를 많이 생각했었습니다. 하지만 엄청난 데이터 량을 메모리에 올리기 위한 처리에서 발생하는 I/O 문제 그리고 MEMORY 용량의 한계 때문에 최근 In memory는 유효하지 못한 전략이 되어가고 있죠. petabyte를 메모리를 적재할 수 있는 시스템이 없기 때문 입니다.

데이터 인출 개념 
시계열 분할 데이터는 개념적으로 보면 위 그림과 같은 처리가 가능합니다.

데이터를 인출할 때 데이터 노드에 간단한 필터 처리를 거쳐 쿼리에 만족하는 데이터만 네임드 노드로 전송한다. 이럴 경우 10Gb/s의 네트워크로도 충분히 차 한 잔 마실 시간에 petabyte급 데이터를 필요 기간 만큼 조회할 수 있을 것 입니다.

드루이드의 파티션 분할 단위는 500MB인데 이를 disk에서 로드 할 경우 3초가 걸립니다. 왜 이렇게 분산파일을 크게 가져가는지 생각해보면 이렇습니다. 파일이 너무 작은 단위로 분산 될 경우 하나의 disk에 같은 시간 파티션이 여러 건 들어있을 수 있으므로, 이럴 경우 동시에 여러 파티션을 불러오면 DISK ARM 점유에 의한 지연이 발생하기도 합니다.
DISK 구조 
DISK ARM 지연이란 위 그림과 같이 생겨먹은 DISK 구조 때문에 발생합니다. DISK는 원판 형태로 되어있고, 회전하는 원판의 특정 영역을 ARM이라는 녀석이 읽어오는데 한 DISK에서 여러 SEGMENT를 동시에 읽어버릴 경우 ARM이 동시에 3파일을 읽으려 ARM을 바쁘게 움직이기만 하고 실제로는 순차적으로 읽는 것 보다 지연되는 현상이 발생하게 되는 것이죠. 따라서 DISK I/O가 가지는 읽기 속도가 160MB/s라고 해도 50MB 파일 3개의 파일을 동시에 읽어오면 1초에 끝나지 않고 지연이 발생해서 1.5초 혹은 3초가 되기도 합니다.

드루이드에서 파티셔닝 크기가 500MB인 이유는 이런 저런 계산 끝에 최적 값을 찾은 것 이라고 한번 믿어보겠습니다. 혹은 SSD를 기준으로 읽기 쓰기 속도를 맞춘 것 일 수 있습니다.

오늘은 여기까지 써야겠습니다. 다음에 또 뵙죠. 읽어주셔서 감사합니다.

빅데이터 개념잡기 '빅알자'는 여러 페이지로 이루어질 것 입니다.

2020년 3월 8일 일요일

빅알자 5.빅데이터 처리 성능. 네트워크 전략

개요 

빅데이터 처리에 스토리지와 네트워크 전략이 필요한 이유는 어디까지나 빅데이터를 쌓아두던 기존 관점이 아닌 활용하기 위해 다양한 분석이 필요해지는 시점에서 하드웨어 성능이 따라주지 못하는 현상을 가장 많이 보고 있기 때문입니다.

빅데이터의 초기 수집에는 일반 PC급의 성능으로 충분히 모든 일을 진행할 수 있습니다. 예를 들어 초당 1회씩 시그널을 보내는 장비가 10만개 있다 하더라도 하둡 클러스터 5개정도면 저장하는데 지장도 없고, 카프카 멀티큐도 1개면됩니다.

하지만 Petabyte 급의 성능은 다릅니다. 일반적인 시스템 구성에서 하둡 클러스터를 아무리 늘린다 한들 성능이 나오지 않습니다.

http://sortbenchmark.org/
위 사이트를 확인해보면 빅데이터의 정렬 성능을 밴치마크 해놓은 자료를 볼 수 있습니다.

그중 눈에 띄는 것은

Tencent Sort
Apache Spark
Hadoop
이 세 가지인데요 각각의 하드웨어 성능에 대해 이야기 해보겠습니다.

1. 정렬 성능 이란 ? 

정렬 성능은 특정 기간의 데이터 혹은 전체 기간의 데이터를 기준으로 데이터의 순위를 매기는 프로세스 입니다. 즉 전체 데이터를 메모리에 올려 순서를 매긴 후 결과를 제공하는 일입니다.

따라서 적절한 정렬 메모리가 확보되지 못한다면 기존 시스템에서 성능 문제가 발생하곤 했습니다. 그런데 빅데이터? 에서의 적절한 성능은 어느 정도 일까요?

Petabyte는 현존하는 어느 컴퓨팅 시스템에서도 한 번에 메모리에 올릴 수 없을 만큼 거대한 양 입니다. 이것이 분할되어 있다 하더라도 문제는 여전히 나아지지 않습니다.

일반적인 PC의 메모리는 많아봐야 32GB 일 것이고, 클러스터를 10대 한다고 해도 320GB, 클러스터를 100대 한다면 32TB, Petabyte에는 도저히 미치지 못합니다. 따라서 연산할 수 없는 데이터는 디스크에 메모리를 내렸다가 다시 올리는 SWAP 이라는 행위를 반복하면서 정렬을 할 수 밖에 없습니다. 디스크 입출력이 반복되면서 IO 부하가 발생하고, 이 때문에 다른 프로세스를 처리하지 못하는 상황이 발생합니다.

그래서 스토리지 전략과 네트워크 전략이 필요합니다.

2. 필요한 장비의 속도

Petabyte를 1초 만에 처리하는 시스템은 현재 어디에도 없습니다. 있다면 자랑하려고 sortbenchmark.org에 등록했을 것 입니다. 검증된 결과를 기준으로 시스템의 도입 여부를 결정하기 때문에 팔기 위해서라도 등록을 하게 됩니다.

탐구해볼 시스템의 성능은 아래와 같습니다.

Tencent Sort(2016) 성능 비고
성능 44.8TB/min
cpu 2 OpenPOWER 10-core POWER8 2.926 GH
memory  512 GB
disk 1.2TB NVMe SSD 1 TB: 3,500/1,000 MB/s
8 TB: 3,500/2,600 MB/s
network 100Gb Mellanox ConnectX4-EN 12 GB/s
병렬 nodes 512
Apache Spark(2014) 성능 비고
성능 4.7TB/min
cpu 2.5Ghz Intel Xeon E5-2670 v2
memory  244GB 
disk 8x800 GB SSD 1,750/1,750 MB/s
network 25 Gbps (3GB/s) 3GB/s
병렬 nodes 207 
Hadoop(2013) 성능 비고
성능 1.42TB/min
cpu 2 2.3Ghz hexcore Xeon E5-2630
memory  64GB 
disk 12x3TB disks 120  MB/s
network 10 Gb/s 1.2GB/s
병렬 nodes 2100

성능에 대한 해석을 해보자면 비고를 보시면 간단합니다. Disk와 network 속도에 의해 좌우되는 것이 명확하게 보입니다.

맨 밑에 하둡이 야후 시스템입니다. 딱 봐도 노드만 늘리면 되겠지 하고 만든 것 같습니다. 2013년 이니 그럴 만 합니다.

네트워크 성능을 보면 1.2GB/s와 3GB/s의 성능 차는 정확하게 3배가 납니다. 즉 병렬 노드의 네트워크 성능이 데이터 크기를 따라가지 못하고 있다고 생각하시면 됩니다.

그리고 1등인 tencent 의 경우 네트워크는 물론 디스크까지 성능을 잘 끌어주고 있습니다. 2016년도 당시 최고 시스템이라고 봐도 과언이 아닙니다. Mellanox 스위치의 경우 현재 200Gb/s를 지원해주는 것으로 알고 있습니다. 약 3200 만원입니다.

spark는 아마존 EC2를 사용한 환경입니다. 아마존의 스펙 중 네트워크 부분은 클라우드이기 때문에 처리속도를 저 정도로 해둔 것 같습니다.

1위인 tencent 시스템과 spark의 성능 차를 보면 좀 더 명확히 보입니다. 디스크의 읽기 쓰기 속도가 받쳐준 이후는 네트워크 속도가 성능을 좌우하게 됩니다.

즉. 기술이 어쩌고, 인 메모리 프로세스가 어쩌고 이야기하기 전에 하드웨어의 성능이 제대로 갖춰지지 않으면 Petabyte처리는 무슨 기술을 써도 느려터지게 쓴다는 말입니다. 2013년 하둡 클러스터 환경을 가지고 Petabyte를 처리하는 것은 드루이드 할애비가 와도 안 될 일입니다.

3. 왜 이런 현상이 나타나느냐? 

뭐 지난번에도 언급했지만 연산이라는 것은 메모리에 올리고 전송하고 저장하는 일의 반복이기 때문입니다.
클러스터 노드가 있는 환경의 처리 순서는 대략 이렇습니다.

1. 마스터가 슬레이브에 데이터 요청
2. 슬레이브가 데이터 파일을 로드, 전송
3. 마스터가 메모리에 데이터를 로드, 초과 데이터는 디스크에 메모리 형태로 저장
4. 현재 메모리를 정렬하고 결과를 디스크 저장
5. 디스크에서 정렬되지 않은 메모리 데이터 로드

4번 5번을 디스크 스왑이라고 하며 이 부분 때문에 디스크의 속도가 빠른 것이 중요합니다. 솔직히 메모리 속도까지 올라와줬으면 좋겠지만.. PCI-E5가 나와야 한다고 합니다.

그리고 네트워크 성능은 디스크가 500MB/s이상을 내며 단일 노드 라면 10Gb/s로 충분하지만 다중 노드라면 100Gb/s 이상의 속도는 나와야 합니다.

스위치는 개별 노드에 100Gb/s 속도를 내는 것 같이 이야기를 결론적으로 마스터가 받아드릴 수 있는 데이터 량은 스위치 최대 속도 단일라인과 다른 게 없습니다. 따라서 마스터 장비의 네트워크는 다중화 되어야 하며 이런 전체적인 조화를 만들어내야 Petabyte 데이터의 분석은 비로소 가능해집니다.

이상 네트워크 전략은 이 정도로 마치겠습니다. 
읽어주셔서 감사합니다. 

빅데이터 개념잡기 '빅알자'는 여러 페이지로 이루어질 것 입니다.

2020년 2월 23일 일요일

빅알자 4.빅데이터 처리 성능. 스토리지 전략

빅데이터나 데이터나 시스템의 처리 성능은 대게 같은 곳에서 시작합니다. 처음은 컴퓨팅 파워. 즉 하드웨어 관점입니다. 이번엔 스토리지 전략에 대해 이야기해보겠습니다. 빅데이터를 저장만 하는 측면에서는 필요가 없고, 분석하고자 하는 시스템에서 필요한 이야기 입니다.

1. 하드웨어 성능 

흔히 컴퓨팅 파워라고 하는 것은 하드웨어의 어떤 부분에서 어떤 성능이 나오느냐를 평가하는 각 부분의 지표가 있지만 데이터 관점에서의 성능은 어떤 속도로 데이터를 읽어드리고, 처리하고 기록하느냐의 관점입니다.

즉, 조회 성능, 정렬 및 그룹화 성능, 기록성능 등이 있겠지요. 뭐 트랜잭션 처리 성능을 평가하기도 합니다.

컴퓨터 구성품 중 속도에 영향을 미치는 항목

그리고 이러한 성능들의 근원은 cpu, disk, memory, bus, network의 5가지 장비의 성능에 기인합니다. 이러한 성능들은 각각의 단위를 갖고 있고, 그 단위 중 일부는 주파수로 공개되고 있어 용량으로 환산할 수 없기에 공개된 기록을 기반으로 각각의 속도에 대해 알아보겠습니다.

데이터 전송 속도 비교

가) 하드웨어의 현재 공개된 최고 쓰기 속도 

장치 초당 읽기/쓰기 속도
CPU 2344.8GB/s
SSD 1.25GB/s
MEMORY(MCDRAM) 460GB/s
BUS 460GB/s
NETWORK 12GB/s

위 표에서 가장 주요하게 봐야 할 점은 SSD 즉 데이터 저장소의 속도가 가장 늦다는 것 입니다. (보편적으로는 500MB/s밖에 나오지 않습니다. ) 가장 속도가 늦는 장치가 데이터를 저장하고 있으니, 보편적인 데이터의 조회 속도는 저장소의 최저 속도가 기준이 될 수밖에 없습니다. 데이터가 메모리에 적재되지 않는 이상 조회도 연산도 할 수 없습니다. 

과거의 RDBMS에서는 이 문제를 해결하고자 메모리를 비대화 시켜 자주 쓰는 데이터는 메모리에 올려놓고, 찾아서 쓰는 방식을 선택했습니다. (HDD 120mb/s가 최고이던 시절) 그리고 스토리지 전략을 통해서 한 번에 여러 노드에서 데이터를 읽는 프로세스를 생각해냈습니다. 이 전략은 지금도 유효합니다. 

2. 스토리지 전략


앞서 설명했던 스토리지 전략의 하나인 RAID입니다. 여러 개의 디스크를 묶어 하나의 디스크처럼 사용할 수 있게 하는 기술이며, 파일 하나를 각각의 디스크에 여러 조각으로 분산시켜 각각의 디스크에서 병렬로 읽게 만들어 읽기 성능을 비약적으로 향상시키는 장치입니다. 

각각의 DISK에서는 500MB/s의 작은 속도밖에 내지 못하지만, 저장 파일을 각 노드에 분산하고, 병렬로 읽고, 결합하여 디스크 하나에서 읽는 속도보다 수배의 속도가 나옵니다.

정확한 원리를 바탕으로 구성된 스토리지 클러스터는 데이터 접근 성능을 크게 향상 시켜 빅데이터의 원활한 처리의 밑거름이 될 것입니다. 

3. 왜 스토리지 전략이 중요한가? 

물론 메모리에 주요 데이터를 올려서 처리하는 메모리 기반 프로세스는 언제고 필요한 전략입니다. 디스크는 메모리를 따라잡을 수 없으니까요. 하지만 스토리지 전략이 가장 기초가 돼야 하는 이유는 메모리를 아무리 늘렸다 한들 빅데이터 전체를 커버 할 수는 없기 때문입니다. 

예를 들자면 이런 겁니다. 가령 센서를 통해서 데이터가 주기적으로 발생한다고 칩시다. 

장치 ID와 특정 값을 발생시키는 태그유형 예 

이 센서 데이터가 1초마다 발생 시 일일 발생 건수는 86,400건 CSV 파일로 치면 약 2MB 매우 작은 양이지만, 연간으로 치면 750MB. 단일 SSD에서 1초에 조회할 수 있는 용량을 넘어버립니다. 그리고 이런 센서는 공장 하나에 수백~ 수천 개가 있기 때문에 연간 누적 데이터양은 100GB를 초월하게 되지요. 저희는 1000개가 넘어서 약 12Tera의 데이터가 쌓입니다. 

100개만 있다고 해도 71GB의 용량을 갖게 됩니다. 이 데이터에 대한 연간 집계를 내려면 데이터를 메모리에 올리는 것도 단일 SSD에서는 142초가 걸리게 되며, 메모리 용량이 충분치 않을 경우 MEMORY와 DISK의 SWAP이 일어나면서 속도는 더 지연되게 됩니다.

하지만 레이드를 통한 분산저장이 되어있을 경우 위 그림과 같이 4GB를 초당 로드한다면 17초로 8.2배의 로드 속도 향상이 발생합니다. SWAP은 동일하게 일어나더라도 읽고 쓰는 속도가 커버할 수 있는 크기가 되죠. 그리고 속도는 더욱 향상될 수 있습니다.

그리고 이 구성을 클러스터 형태로 더 크게 구성할 경우 소수점 이하의 시간 내에 로드가 가능해집니다.

최근 빅데이터 플랫폼 테스트베드의 기준이 되어가고 있는 아마존 AWS의 경우 이러한 처리들이 이미 되어있기에 실제 하드웨어를 구매하지 않고도 표준화 된 성능 테스트를 수행할 수 있기 때문입니다.

저장만 하는 관점에서는 전혀 필요 없지만, 분석이 필요한 시점에는 가장 필요한 프로세스가 됩니다. 

이상 스토리지 전략은 이 정도로 마치겠습니다. 
읽어주셔서 감사합니다. 

빅데이터 개념잡기 '빅알자'는 여러 페이지로 이루어질 것 입니다.