시스템의 네트워크에 대한 전반적인 정보를 출력하고 설정을 수정할 수 있다. (참고로 Windows는 ifconfig 명령어 대신 ipconfig 명령어를 사용한다.) 명령어 입력하고 출력을 해보면 아래와 같은 정보가 출력된다.

$ ifconfig

eth0은 첫번째 이더넷 카드를 말하고 lo는 Loopback 주소이다.eth0는 공유기에서 할당받은 사설 네트워크 대역의 IP(192.168.0.0/16)을 받았고 lo는 Loopback 주소인 127.0.0.1을 받았다.

참고 : NIC이라고 불리는 Network Interface Card는 이더넷 카드보다 좀 더 포괄적인 개념이다. Wifi 동글도 일종의 NIC이라고 할 수 있고 이더넷 카드도 마찬가지이다.

ifconfig은 네트워크 환경정보를 출력하는 것 외에도 직접 설정을 조작하거나 네트워크 드라이버를 On/Off 할 수 있다고 했다.

그러나 ifconfig에서 진행한 설정 변경은 메모리 위에서만 저장되어 있기 때문에 서버가 재시작하면 원상복구된다. 이 설정을 계속 유지시키고싶다면 직접 네트워크를 설정하는 파일을 수정해야 한다.

네트워크 관련 파일들의 목록은 아래와 같다.

1. /etc/sysconfig/network : 네트워크 활성화 여부, Host명, 게이트웨이를 지정한다.
2. /etc/resolv.conf : DNS 서버의 주소가 저장되어 있다.
3. /etc/sysconfig/network-scripts : 네트워크 관련 명령어들이 저장되어 있는 디렉토리
4. init 스크립트(/etc/init.d/network) or Systemd 관리 서비스

그래도 하나 기억해야 할 것은 ifconfig up/down 명령어이다. 직접적으로 NIC을 끄고 켜는 명령어이다. 네트워크 설정을 바꾼 다음에 NIC도 재시작을 해야 설정이 적용이 되는 경우가 있어 이 명령어가 필요하다.

# 첫번째 이더넷 카드 사용 중지
$ ifconfig eth0 down
# 첫번째 이더넷 카드 사용 시작
$ ifconfig eth0 up

따라서 원격 접속 시에는 함부로 ifconfig down을 하면 원격 접속이 바로 끊길 수 있으니 주의해야 한다.

추가로 ifup과 ifdown(빌트인 명령어가 아닌 스크립트이다. /etc/sysconfig/network-scripts 디렉토리에서 찾을 수 있다.)도 비슷한 역할을 한다. 그렇다면 차이점이 궁금할 수도 있는데, 구글링하면 쉽게 찾을 수 있다. 레드햇 지식 베이스 : https://access.redhat.com/solutions/27166

링크를 들어가면 이미 요약이 되어 있지만 한번 더 요약 및 번역을 해보면 아래와 같이 요약을 할 수 있을 것이다.

• ifconfig과 ifup/down은 둘 다 NIC을 활성화/비활성화 시킬 수 있다. 다만 ifup/down은 스크립트이고 이 스크립트는 다시 안에서 'ip'라는 명령어를 사용한다.
• 둘 다 ioctl() 시스템콜을 사용하여 NIC을 제어한다. 그러나 ifconfig은 커널에 IFF_UP과 IFF_RUNNING Flag를, ifup/down은 단지 IFF_UP Flag를 던져준다고 한다.

  참고 : IFF_UP Flag와 차이는 있지만 IFF_RUNNING Flag는 크게 신경쓰지 않아도 될 듯하다. https://stackoverflow.com/questions/11679514/what-is-the-difference-between-iff-up-and-iff-running

• ifconfig은 IP나 고정 라우팅 설정까지 하지 않지만 ifup/down은 한다.

iwconfig

ifconfig이 이더넷을 포함한 모든 네트워크 환경 정보를 출력해주었다면 iwconfig은 무선랜 네트워크 환경을 출력해준다.

일단 실험하고 있는 WSL CentOS 7 리눅스 환경에는 iwconfig 명령 자체를 찾을 수 없고 다운로드 받아야 한다.

그러나 다운로드 받아도 데스크탑에 무선랜 장치가 없기 때문에 아무것도 뜨지 않을 것이다. 나중에 WiFi 동글 찾아서 꼽고 실험을 해봐야 할 것 같다.

책을 보니 ifconfig과는 다르게 sit0라는 특별한 인터페이스가 있다는 것을 볼 수 있는데 이는 무선 환경에서는 IPv4와 IPv6의 호환을 위해 사용하는 특수 목적의 가상장치를 이용하기 때문이라고 한다.

ip

위에서도 나왔지만 ipup/down 스크립트에서 사용되는 명령어이다. 라우팅과 디바이스 터널링에 대한 정보를 출력하고 조작할 수 있다.

route

커널의 라우팅 테이블을 출력하거나 수정할 수 있다.

$ route

위의 사진을 보면 직접 route 명령어를 쳐서 출력한 결과이다. 리스트의 가장 첫번째가 중요한데, 의미를 해석해보자면 Destination이 0.0.0.0인 패킷은 모두 192.168.25.1 GW(내가 쓰는 공유기)를 거친다는 것이다. Genmask는 패킷의 목적지 IP에 AND 연산을 통해 목적지 IP를 지정하는 역할을 한다.

tcpdump

네트워크 패킷을 실시간으로 출력, 옵션 없이 실행하면 모든 네트워크 패킷을 볼 수 있고, 옵션을 통해 port를 지정해줄 수도 있다.

netstat

ifconfig가 네트워크 인터페이스 환경에 대한 정보였다면 netstat은 네트워크 통계 정보라고 볼 수 있다. 주로 사용되고 있는 포트가 어떤 것이 있는지 확인하기 위해서 이 명령어를 사용한다.

$ netstat -lptu

netstat 명령어를 많이 사용해봤을 수도 있지만 netstat 명령어와 여러가지 옵션이 붙어 헷갈릴 때가 많다. 매뉴얼 페이지를 보고 간단하게 정리를 해보면 아래와 같다.

1. -l : Listening, 즉 사용되고 있는지 여부를 따진다.
2. -p : p는 program의 약자, Process의 PID와 이름을 보여준다.
3. -t : TCP
4. -u : UDP, 그러니까 옵션에 tu가 들어가 있는 것은 TCP와 UDP 포트 모두 보겠다는 것이다.

어젯밤, 친구에게로부터 과제 도움 요청을 받았다. 평소에 친구들 과제 도와주는 것을 좋아하던 터라 흔쾌히 도움을 주겠다고 했고, 들어본 적은 있지만 사용해본 적은 없는 R 언어와 Selenium이라는 프레임워크를 이용한 과제였기에 흥미로워 도움을 주는 것이 재미있을 것 같았다.

그리고 이 포스팅을 하면서 문제 해결을 했던 과정들을 남겨보려고 한다. 내가 R 언어로 쓰인 코드를 이번 과제를 도와주면서 처음 봤음에도 불구하고 문제 해결에 도움을 줄 수 있었던 이유는 아무래도 문과생인 친구보다는 컴퓨터 공학을 공부한 내가 문제가 되는 코드 한 줄을 찾는 과정과 노하우를 더 잘 알기 때문이다. (나도 초보 수준이긴 하지만,,)

학창시절, 친구들의 코딩 과제를 도와주면서 느낀 것이 있는데 코딩을 처음 해보는 친구들 중 처음부터 잘하는 친구들도 있긴 했지만 대부분은 자신이 작성한 코드에 문제가 생기면 어디서부터 문제가 시작되는 지를 잘 파악하지 못했다는 것이다. 그러다 보니 문제 해결을 위한 검색도 더 넓은 범위에서 시작하게 되어 해결에 오랜 시간이 걸리는 것 같다. 내가 이번 포스팅에서 강조하고 싶은 것은 문제의 시작점을 찾기 위해 문제가 발생된 영역을 점점 좁혀 나가는 방법이다. 비록 초보적인 수준이긴 하지만 코딩을 접한지 얼마되지 않은 사람들에게는 충분히 도움이 될 수 있을 것 같다.

문제 설명

필요 배경 지식

문제를 설명하기 전에 R 언어와 Selenium이 무엇인지에 대해서 먼저 설명이 필요할 것 같다. 내가 과제 도움 요청을 받기 전에도 R과 Selenium에 대해서 들어본 적은 있기 때문에 대충은 알고 있었다. 아래의 설명은 내가 아는 선까지만 얘기를 하고 자세한 설명과 정의는 WIKI백과를 이용하거나 검색을 하여 찾기를 바란다.

R 언어 : 주로 통계 및 데이터 분석에 자주 사용되는 언어, 스크립트 언어라 굳이 컴파일을 안해도되고 한줄한줄씩 실행해서 결과를 볼 수 있다.

Selenium : 웹페이지를 방문하여 웹페이지의 조작을 자동화 해주는 소프트웨어 프레임워크. 웹 페이지에서 데이터를 자동으로 수집하는(이것을 웹 크롤링이라고도 한다.) 프로그램을 만드는 데 사용될 수도 있고, 어떤 사람은 Selenium을 사용해 잔여백신을 자동으로 확인해주는 프로그램을 만든 것도 본 적이 있다.

문제 상황

친구가 하려던 과제는 R 언어와 Selenium을 활용해 Youtube 웹페이지를 방문하여 동영상의 제목, URL, 조회수, 댓글수 등의 데이터를 모아서 하나의 csv 파일에 쓰는 것이었다.

Code 분석

문제를 찾아달라는 코드는 아래와 같았다.

for(i in 1:length(trending_yt$URL)){
  remDr$navigate(trending_yt$URL[i])
  Sys.sleep(10)

  page <- remDr$getPageSource()[[1]]
  html <- read_html(page)

  channel <- html %>% html_node(xpath='//*[@id="text"]/a') %>% html_text()
  subscriber <- html %>% html_node(xpath='//*[@id="owner-sub-count"]') %>% html_text()
  view <- html %>% html_node(xpath='//*[@id="count"]/ytd-video-view-count-renderer/span[1]') %>% html_text()
  date <- html %>% html_node(xpath='//*[@id="info-strings"]/yt-formatted-string') %>% html_text()
  comment <- remDr$findElement(using = "xpath", '//*[@id="count"]/yt-formatted-string')$getElementText()[1][[1]]

  trending_yt$Channel[i] <- ifelse(str_detect(channel, "[[:alnum:]]"), channel, NA)
  trending_yt$Subscriber[i] <- ifelse(str_detect(subscriber, "[[:alnum:]]"), subscriber, NA)
  trending_yt$View[i] <- ifelse(str_detect(view, "[[:alnum:]]"), view, NA)
  trending_yt$Date[i] <- ifelse(str_detect(date, "[[:alnum:]]"), date, NA)
  trending_yt$Comment[i] <- ifelse(str_detect(comment, "[[:alnum:]]"), comment, NA)
}


trending_yt

write.csv(trending_yt, file="trending_yt.csv", row.names = F)

문제를 해결하기 전에 대략적인 코드 해석이 필요할 것으로 보인다.

• 1. remDr

  익숙하지 않은 코드에 당황하기도 했지만, 차근차근보면 remDr이라는 객체가 웹 페이지를 방문하고 데이터를 받아오는 역할을 하는 것을 알 수 있다. (검색해서 찾아보니 remDr은 remote Driver란 뜻이고 RSelenium 라이브러리에 포함이 되어있는 친구였다.)

• 2. Sys.sleep(10)

  처음보는 언어라도 sleep는 어느 언어에서든 의도적으로 지연을 주기 위해서 사용되므로 10초간 지연을 의도적으로 준 것이라고 해석할 수 있다. 아마도 Youtube에 웹 페이지 요청을 과도하게 빠르게 보내는 것을 방지하고 웹 크롤러가 블락 당하는 것을 방지하기 위해서 사용된 것으로 보인다. 추가로 for문 안에 이 sleep 함수가 존재하기 때문에 만약에 코드가 정상적으로 실행이 된다면 실행하는데 오랜 시간이 걸릴 것이다. 에러를 찾는데 힌트가 된 부분이기도 하다.

• 3. page, html

  remDr이란 객체의 getPageSource라는 함수를 통해서 page의 소스를 얻어온 부분이다. 그리고 얻어온 page 소스를 html로 읽어 html이라는 객체에 저장한다.

• 4. channel, subscriber, view, date, comment

  각 객체에는 위에서 얻은 html이란 객체에서 channel 정보, 구독자 정보, 조회수, 날짜, 댓글수를 찾아서 저장한 것이다. 아래에서 얘기하겠지만 문제가 생긴 부분은 일단 댓글수인 comment이다.

• 5. trending_yt

  4번까지 이해가 갔다면 trending_yt는 일종의 Dataframe이라고 할 수 있다. 그러니까 trending_yt$Channel[i]...로 시작하는 코드는 trending_yt의 Channel이라는 컬럼의 i번째 행에 channel이라는 객체(text)를 넣겠다는 의미이다.

• 6. write.csv

  마지막으로 trending_yt라는 Dataframe을 csv 파일에 쓴다.

문제 상황 설명

문제 상황에 대한 이야기는 2가지이다. 말해준 순서대로 얘기를 해보면

① 댓글수를 받아오는 부분(comment <- remDr$findElement...)이 어쩔 때는 실행이 되고 어쩔 때는 실행이 안된다.
② trending_yt라는 Dataframe을 csv 파일로 쓸 때, for문에서 trending_yt에 추가한 컬럼들은 제외가 되었다.

친구의 말로는 상황①이 언제는 되고 언제는 안된다고 하여 ②부터 진행을 하고 있다고 하여 나도 그 문제부터 해결하고자 시도해보았다.

문제 해결 과정

메신저로만 문제 상황을 잘 설명하는 것은 쉽지 않다. 게다가 에러 로그를 요구했더니 ①번 상황은 에러 메세지가 뜨지만 ②번 상황에서는 아무런 메세지가 뜨지 않는다고 한다.. 그래서 차라리 전체 실행 과정을 모두 보여달라고 했다. Google Meet를 활용하여 화면공유를 통해 실행과정을 볼 수 있었다. 친구가 말한대로 ①댓글수를 받아오는 부분에서 에러 메세지가 뜨기는 했으나 다음 코드를 계속 실행할 수 있었다.

여기서 이상한 점은 for문 안에는 Sys.sleep(10)이라는 함수가 사용되고 있는데 for문 실행이 굉장히 빨리 끝났다는 것이다. Dataframe의 행의 개수가 159개라는데, 그러면 실행하는데는 적어도 159x10초 이상, 대략 25분 이상이 걸려야 하는 것인데 그렇지 못했고 for문이 정상적으로 실행이 되지 않았다는 것을 예상할 수 있었다.

그래서 for문 안에서 에러 메세지를 출력했던 댓글수를 받아오는 부분을 지워보고 실행해보라고 했다.

예상했던 대로 댓글수를 받아오는 부분을 지우고 실행해보니 실행 시간 중 사담을 나누고 있을 정도로 오래 걸렸다.(한 30분? 걸렸던 것 같다.) 그리고 생성된 csv 파일에도 Comment 컬럼을 제외한 나머지 컬럼들이 정상적으로 write되어 저장이 되었다. 즉 write.csv 함수는 문제가 없다는 것을 알 수 있다. for문 같은 경우, for문 안에서 댓글수를 받아오는 부분에서 에러가 생기다보니 for문 전체가 실행이 안되었던 것이다.

그러면 문제를 좁힐 수가 있다. 위의 코드에서 아래의 댓글수를 받는 부분만 문제가 있는 것이라고 할 수 있다.

comment <- remDr$findElement(using = "xpath", '//*[@id="count"]/yt-formatted-string')$getElementText()[1][[1]]

확인해본 에러 메세지는 아래와 같다.

Selenium message:no such element: Unable to locate element: {"method":"xpath","selector":"//*[@id="count"]/yt-formatted-string"} (Session info: chrome=96.0.4664.93) For documentation on this error, please visit: https://www.seleniumhq.org/exceptions/no_such_element.html Build info: version: '4.0.0-alpha-2', revision: 'f148142cf8', time: '2019-07-01T21:30:10' System info: host: 'LAPTOP-NBG0LFLD', ip: '192.168.219.103', os.name: 'Windows 10', os.arch: 'amd64', os.version: '10.0', java.version: '1.8.0_311' Driver info: driver.version: unknown Error: Summary: NoSuchElement Detail: An element could not be located on the page using the given search parameters. class: org.openqa.selenium.NoSuchElementException Further Details: run errorDetails method

친절하게도 에러에 대한 문서화가 되어 있어 있다. https://www.seleniumhq.org/exceptions/no_such_element.html

페이지를 방문해보면 아래와 같이 문제의 원인에 대해서 설명해준다. "No Such Element"라는 에러를 마주했으니 그 부분을 보면 된다.

결국 element가 없어서 생긴 문제이며 해결 방안으로는 locator를 한번 더 확인해보라는 것이었다.

코드에 사용된 locator의 내용은 '//*[@id="count"]/yt-formatted-string'이다. 아래와 같이 개발자 도구(웹페이지에서 F12 키를 누르면 된다.)를 사용해서 locator를 확인할 수 있다. (xpath를 사용해서 Copy XPath 버튼을 클릭하면 클립보드에 복사가 된다.)

확인해본 결과 locator가 //*[@id="count"]/yt-formatted-string로 코드에 사용된 것과 같았다. 그러면 locator는 문제가 없다는 것을 알 수 있다.

힌트는 어떨 때는 잘 동작하다가 어떨 때는 또 에러 메세지를 출력한다는 것이다. 어떻게 보면 코드 문제라기 보다는 웹페이지의 소스가 유동적으로 변하다보니 생길 수 있는 문제라고 생각했다. 그러면 Locator의 내용이 유동적으로 바뀔 수도 있는 것이라고 예상할 수 있다.

그래서 직접 유튜브 웹페이지를 방문하여 Locator를 확인해보았다. 웹 페이지를 방문하자마자 F12 키를 입력하여 개발자 도구를 열고, Ctrl+F 키를 눌러 찾기를 한 다음에 XPath locator를 입력하였는데 XPath를 찾지 못하는 경우가 있었다.

그래서 개발자 도구를 이용해서 댓글수의 Locator를 다시 찾아보았다. 아래의 이미지 좌측 상단에 커서와 사각형 모양이 합쳐진 버튼을 사용하고 페이지에 커서를 옮겨 놓으면 소스에 관련된 Element가 어디있는지 찾아준다.

찾아서 다시 Locator를 확인해보니 //*[@id="count"]/yt-formatted-string로 똑같았다. 그래서 실수했나 하고 다른 유튜브 동영상 웹 페이지를 방문했는데, 여기서 문제 원인을 확실히 알게 되었다. 결론은 유튜브 동영상 웹페이지를 처음 방문하면 댓글에 대한 Element가 다 같이 로드되지 않기 때문이었다. 이것을 유튜브 페이지를 방문해보면서 스크롤 다운을 하니 아주 잠깐 동안 아래와 같은 Wait Icon이 뜨는 것을 보고 그 다음에 댓글이 나오는 것을 확인하고 알게 되었다.

그래서 내가 예상한 대로 코드 자체의 문제라기 보다는 웹 페이지 소스가 유동적으로 변하다보니 생긴 문제였고, 해결방안으로는 Selenium으로 스크롤 다운 동작을 한번 한 다음에 댓글수를 수집하는 코드를 실행하면 될 것이라고 해주었다.

친구가 내가 제시한 해결방안이 아니라 다른 방법(연관 동영상을 뜨지 않게 하는 방법, 연관 동영상이 뜨지 않으면 댓글수가 웹 페이지를 방문하자마자 나온다.)을 쓰기는 했지만 과제를 잘 처리할 수 있었고 문제의 원인을 확실하게 파악할 수 있었다.

Shell Script를 공부하다가 반복문이나 조건문 같은 제어문의 사용이 다른 언어에 비해 복잡하다는 것을 느꼈다. 그래서 공부를 해도 조금씩 헷갈리기에 한번 정리하여 글로 남겨보려고 이번 포스팅을 작성하였다.

주로 다른 언어 특성과 비교하면서 Shell Script에서 유념해야 할 부분에 대해서 정리를 해보았다.

아래에 C/C++과 Bash Shell script 비교 예시 코드를 가져왔고 두 코드 모두 변수 x에 대해서 x가 1보다 작다면 "ok"를 출력하는 코드이다.

// C/C++ 에서의 조건문
int x = 0;
if( x < 1 )
    cout<<"ok"<<endl;

# Bash Shell에서의 조건문
x=0
if [ $x -lt 1 ]
then
    echo "ok"
fi

분석

위의 코드를 보고 눈여겨 보아야 하는 점들을 아래에 기록을 해놓았다.

① if 다음에 오는 괄호

다른 언어에서와 달리 Shell Script에서는 if문의 첫번째 괄호에 반드시 띄어쓰기가 들어가야 한다. 띄어쓰기가 없으면 문법적으로 오류가 생기기 때문에 주의해야 한다. "if"라는 제어명령을 쓴 후에 띄어쓰기를 한번 하고 시작괄호를 넣고 그 다음 한번 더 띄어쓰기를 해주어야 한다.

if [ $x -lt 1 ] # 정상
if[ $x -lt 1 ] # 에러 
if [$x -lt 1 ] # 에러

② 부등호 표시 대신 -lt

영어에 익숙하신 분들은 직감적으로 "lt"가 "less than"을 의미한다는 것을 눈치챘을 것이다. 그래서 사람에 따라서 부등호 표시보다 이렇게 영어 소문자로 비교를 하는 것이 더 편할 수도 있다. 그리고 "작다"는 표현이 "-lt"이니까 "크다"는 표현은 "-gt" 라는 것을 유추해낼 수 있다. 아래는 모든 비교표현에 대해 정리한 표이다.

개인적으로 정수를 비교할 때는 영어로된 약자를 쓰기보다는 부등호를 사용하는 것이 편하다고 느낀다. 그러나 파일을 테스트할 때는 영어로된 약자를 사용하는 것이 직관적이다. 예를 들면 아래와 같다.

if [ -f /root/dir/file1 ] # /root/dir에 file1이라는 파일이 존재하는지 아닌지 확인
if [ -d /root/dir/dir1 ] # /root/dir에 존재하는 dir1이 디렉터리인지 아닌지 확인
# 그 외..

③ 영어 약자 대신 부등호를 쓰고 싶다면?

첫 번째 방법

다행히도 제어문에서 비교를 할 때 무조건 영어로된 비교 표현을 써야 하는 것은 아니다. Bash의 2점대 버전 이후로 더블 브라켓( "[[ ]]" )을 사용하면 C/C++에서 제어문을 사용할 때처럼 비교 표현 기호를 사용할 수 있다.

두 번째 방법

추가로 "let"이라는 쉘 빌트인 명령을 사용하는 방법도 있다. let 명령어는 산술 표현식을 평가하는 명령이며 소괄호 2개( "(( ))" )를 활용해서 사용할 수 있다. 아래는 man page에서 let 명령어에 대한 설명을 가져온 부분이다.

let 명령어 man page let arg [arg ...] Each arg is an arithmetic expression to be evaluated (see ARITHMETIC EVALUATION above). If the last arg evaluates to 0, let returns 1; 0 is returned otherwise.

그래서 아래의 조건문은 모두 같은 의미를 가진다.

if [ $x -lt 1 ] 
if [[ $x < 1 ]] # Bash version 2.x 이후부터 지원
if (( $x < 1 )) # let 명령어 활용

④ 표현식이 반환하는 값

C/C++에서는 아래의 표현식이 비교 결과에 따라서 Bool값의 true(1) 혹은 false(0)을 반환한다.

if( x < 1 )

그러나 Shell Script에서는 반대이다. Shell Script는 정수형 값을 이용하는데 0이면 true이고 그 이외의 숫자들은 false로 인식한다. 그리고 exit 값을 이용한다.

exit 값은 exit라는 명령어와 함께 사용된 아규먼트 값을 말한다. 누군가 작성해놓은 Shell Script를 보면 예외 처리를 하면서 exit 1, exit 3 이런식으로 사용된 것을 볼 수 있을텐데 여기서 1과 3이 exit 값이다. (예외 처리에서는 exit 명령어의 아규먼트로 0이 아닌 숫자를 이용한다. 그러니까 이 값을 통해 실행이 잘 되었는지 아닌지 확인할 수 있는 것이다.)

참고! exit 값은 Shell의 예약 변수로도 저장이 되어 있다. ?라는 변수에 exit 값이 저장되어 있으니 "echo $?"라고 명령어를 입력해 엔터를 누르면 확인할 수 있다. 이전 명령어가 정상적으로 실행되었다면 0을 출력하고 그렇지 못하다면 그 이외의 숫자를 출력할 것이다.

지금까지 예시로 들었던 if문에서도 exit 값을 반환하는 부분이 있다. "[ ]"와 "[[ ]]"는 "test"라는 쉘 빌트인 명령을 내부적으로 사용하여 exit 값을 반환하는 것이고 "(( ))"는 위에서 설명했듯이 "let"이라는 쉘 빌트인 명령을 사용한 것이다.

exit 값을 이용한다는 사실을 기억해야 하는 이유를 코드로 설명을 해보겠다. 이번에는 if문이 아니라 while문을 사용했는데 조건식을 사용하는 방법은 똑같다.

x=1
while [ $x ]
do
    echo $?
       sleep 5
done

x 변수에 0이 아닌 1을 대입했기 때문에 while문이 동작하지 않을 것이라고 생각할 수도 있지만 while문은 계속 반복하여 실행이 될 것이고 지속해서 0이 출력될 것이다.

그 이유는 일단 기본적으로 Shell Script에서 변수는 정수형이 아니라 문자열로 인식되어 저장된다. 그러니까 x에는 "1"이라는 문자열이 들어가 있는 상태인 것이다. 그리고 while문 옆에서 test라는 쉘 빌트인 명령을 사용하는데 아규먼트는 변수 x, 즉 문자열 "1"인 것이다. 그런데 test 명령어는 단순한 문자열 아규먼트에 대해서는 exit 값으로 0을 반환한다. 그러니까 while문이 반복해서 실행되는 것이다.

마찬가지로 아래의 코드도 반복문이 계속해서 실행된다.

while [ 1 ]
do
    echo $?
       sleep 5
done

다만 이는 대괄호 안의 값이 true로 인식되어서가 아니라 test 명령에 의한 exit값이 계속해서 0이기 때문이다. 그래서 대괄호 안의 값이 0이어도 계속 실행되기 때문에 Shell Script를 작성할 때 주의해야 한다.

요즘 Shell Script에 대해서 공부하고 있다. 연습이 필요해 Hadoop의 start-all.sh라는 스크립트를 분석해보면서 공부했던 내용도 리마인드하고 몰랐던 내용도 새로 알아보기 위해 시도해보았다.

start-all.sh라는 스크립트는 Hadoop Binary 파일 내에 포함되어 있으며, 클러스터 내에 존재하는 HDFS(Hadoop File System)의 Namenode와 Datanode는 물론 클러스터 매니저인 Yarn의 Resource Manager와 Node Manager를 같이 실행시켜 Hadoop 클러스터 운영을 시작하는 스크립트이다.

start-all.sh 파일은 $HADOOP_HOME_DIR/sbin에서 찾을 수 있다.

• start-all.sh

  #!/usr/bin/env bash
  

Licensed to the Apache Software Foundation (ASF) under one or more

contributor license agreements. See the NOTICE file distributed with

this work for additional information regarding copyright ownership.

The ASF licenses this file to You under the Apache License, Version 2.0

(the "License"); you may not use this file except in compliance with

the License. You may obtain a copy of the License at

#

http://www.apache.org/licenses/LICENSE-2.0

#

Unless required by applicable law or agreed to in writing, software

distributed under the License is distributed on an "AS IS" BASIS,

WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

See the License for the specific language governing permissions and

limitations under the License.

@description catch the ctrl-c

@audience private

@stability evolving

@replaceable no

function hadoop_abort_startall() { exit 1 }

let's locate libexec...

if [[ -n "${HADOOP_HOME}" ]]; then HADOOP_DEFAULT_LIBEXEC_DIR="${HADOOP_HOME}/libexec" else this="${BASH_SOURCE-$0}" bin=$(cd -P -- "$(dirname -- "${this}")" >/dev/null && pwd -P) HADOOP_DEFAULT_LIBEXEC_DIR="${bin}/../libexec" fi

HADOOP_LIBEXEC_DIR="${HADOOP_LIBEXEC_DIR:-$HADOOP_DEFAULT_LIBEXEC_DIR}"

shellcheck disable=SC2034

HADOOP_NEW_CONFIG=true if [[ -f "${HADOOP_LIBEXEC_DIR}/hadoop-config.sh" ]]; then . "${HADOOP_LIBEXEC_DIR}/hadoop-config.sh" else echo "ERROR: Cannot execute ${HADOOP_LIBEXEC_DIR}/hadoop-config.sh." 2>&1 exit 1 fi

if ! hadoop_privilege_check; then trap hadoop_abort_startall INT hadoop_error "WARNING: Attempting to start all Apache Hadoop daemons as ${USER} in 10 seconds." hadoop_error "WARNING: This is not a recommended production deployment configuration." hadoop_error "WARNING: Use CTRL-C to abort." sleep 10 trap - INT fi

start hdfs daemons if hdfs is present

if [[ -f "${HADOOP_HDFS_HOME}/sbin/start-dfs.sh" ]]; then "${HADOOP_HDFS_HOME}/sbin/start-dfs.sh" --config "${HADOOP_CONF_DIR}" fi

start yarn daemons if yarn is present

if [[ -f "${HADOOP_YARN_HOME}/sbin/start-yarn.sh" ]]; then "${HADOOP_YARN_HOME}/sbin/start-yarn.sh" --config "${HADOOP_CONF_DIR}" fi

```

1. Shebang

먼저 Shebang이란 스크립트 파일이 어떤 스크립트인지 알려주는 역할을 한다. (예를 들면 Python인지, Bash인지..)

추가! 정확히 말하면 스크립트를 실행할 인터프리터의 절대경로를 지정하는 것이다.

참고! '#!'인지 '!#'인지 헷갈려하는 사람이 있을 수도 있는데, 이름이 Shebang인 이유 자체가 '#(Hash 혹은 Number sign)'과 '!(Bang 혹은 exclamation mark)'인 것을 기억하면 된다.

스크립트 첫 라인부터 보이는 "#!/usr/bin/env bash"가 shebang이다. 그런데 책에서는 bash 스크립트를 작성할 때, "#!/bin/bash"로 shebang을 작성했는데, 여기서는 "#!/usr/bin/env bash"로 달랐다. 분명 bash 스크립트인 것은 같은 것이지만 무언가 차이가 있을 것이라고 생각하고 조사를 했더니 보통은 start-all.sh 파일에 붙은 shebang처럼 "#!/usr/bin/env bash" 형태를 많이 사용한다고 한다.

그 이유는 시스템마다 환경 구성이 다르기 때문이다. 나는 지금 CentOS 7 버전을 사용하고 있는데, Linux 배포판마다 인터프리터의 위치가 다를 수도 있을 것이다. 그러면 bash 인터프리터가 /bin 디렉토리에 존재하지 않을 수도 있고, 그렇게 되면 Shebang을 "#!/bin/bash"로 입력했을 때 인터프리터를 제대로 찾지 못할 수도 있는 것이다. 그래서 보통 "#!/usr/bin/env bash" 형태로 shebang을 입력하여 다양한 환경에서 스크립트가 실행될 수 있도록 한다.

참고! /usr/bin/env는 환경변수를 출력해주는 실행 가능한 프로그램이다. (env 명령어를 입력하면 /usr/bin/env가 실행되는 것이다.)

2. 함수

start-all.sh 파일 내에 함수는 하나 정의가 되어 있다. hadoop_abort_startall()이 그것인데, 함수 내용은 exit 1으로 내용은 딱히 없다. 다만 exit 0이 아니라 1이기 때문에 무언가 문제가 생겼을 때 사용되는 함수라는 것을 예상할 수 있다.

3. Locate libexec

첫 번째 if문을 보면 표현식 내에 -n 옵션과 $HADOOP_HOME이라는 변수가 있다. -n 옵션은 변수의 길이가 0이 아닐 때 True를 반환한다.(즉 $HADOOP_HOME 변수가 설정이 되어 있어야 조건문을 실행한다는 말이다.)

만약 $HADOOP_HOME 변수가 설정이 되어 있으면 HADOOP_DEFAULT_LIBEXEC_DIR라는 변수를 "$HADOOP_HOME/libexec"라고 설정한다.

그렇지 않으면 this라는 변수를 "${BASH_SOURCE-$0}"로 설정한다. 이 때 ${BASH_SOURCE-$0}은 변수 확장 변경자를 이용한 것으로 변수를 치환할 때, BASH_SOURCE가 설정되어 있지 않으면 $0로 치환되고 그렇지 않으면 BASH_SOURCE가 된다는 것이다.

그리고 bin 변수에는 $(cd -P -- "$(dirname -- "${this}")" >/dev/null && pwd -P)를 할당한다. cd와 pwd에 붙은 -P 옵션은 심볼릭 링크가 아닌 피지컬 링크를 사용한다는 의미이고, 리다이렉션을 통해 cd 명령의 출력값을 /dev/null로 보냈으니 출력하지 않겠다는 의미이다. 그리고 '&&'은 앞의 cd 명령어가 에러 없이 실행되었을 경우 뒤의 pwd 명령을 실행한다는 것이다.

마지막으로 HADOOP_DEFAULT_LIBEXEC_DIR 변수를 방금 전 설정한 bin 변수를 이용하여 할당하고 if문이 끝난다.

HADOOP_LIBEXEC_DIR 변수값은 변수 확장 변경자를 사용하여 HADOOP_LIBEXEC_DIR가 NULL이 아니라면 그대로 HADOOP_LIBEXEC_DIR 값을 가지고 그렇지 않으면 위의 if 조건문에서 설정된 HADOOP_DEFAULT_LIBEXEC_DIR값으로 치환된다.

4. start Hadoop & Yarn daemons

Hadoop과 Yarn Daemon들을 실행시키는 부분은 2개의 if문으로 구성되어 있다. 먼저 Hadoop Daemon을 실행시키는 if문을 보면 표현식 내에 -f 옵션이 들어가 있는데, 이는 file이 존재하고 보통의 파일이면 True를 반환한다.

if문 내에 기재된 파일은 ${HADOOP_HDFS_HOME}/sbin/start-dfs.sh이며 start-all.sh 파일과 같은 디렉토리에 존재하는 start-dfs.sh 파일이다. 그리고 함수의 내용은 그 파일을 실행하는 것이다.(--config 옵션으로 설정파일의 디렉토리도 설정된다.)

즉 start-all.sh는 그 자체로 Hadoop Daemon을 실행하도록 되어 있는것이 아니라 스크립트 파일이 또 다른 스크립트 파일(start-dfs.sh)을 실행시키는 것이다.

Yarn도 마찬가지이다. start-yarn.sh 파일이 있으면 그것을 실행한다.

11월 10일, LeetCode 오늘의 문제를 풀다가 느낀점을 기록하기 위해서 포스팅을 작성하였다. 결론을 먼저 말하면 한가지 접근 방법을 고집하지 말자는 것을 느꼈다. 코딩을 하다보면 몇번씩 이런 생각이 드는데 오늘은 기록을 하는 것이 좋겠다고 생각했다.

오늘의 문제는 "Best Time to Buy and Sell Stock II"이라는 문제인데, 일자별 주식 가격이 1차원 배열로 주어지고, 그것을 바탕으로 매매를 했을 때 얻을 수 있는 최대 수익을 구하는 문제였다. 추가적으로 주식은 한번에 한 주만 가지고 있을 수 있다는 조건이 있다. 무슨 얘기냐하면 어느날 주식을 하나 사서 갖고 있다면 이 주식을 팔지 않으면 주식을 살 수 없다는 말이다.

• 정확한 문제 설명은 LeetCode 페이지를 참고 https://leetcode.com/problems/best-time-to-buy-and-sell-stock-ii/

접근방법 ①

참고! 접근방법 ①은 Time Limit Exceeded가 떠서 통과가 안된다.

일단 코딩 문제를 풀 때, 나는 문제 설명을 읽고 그 다음 예시로 주어진 Case를 확인한 후에, 제한 사항을 확인한다.

문제를 보자마자, 가장 단순하게 모든 경우를 다 따져보는 것을 생각해보았다. 그러니까 첫날부터 주식을 사는 경우와 사지 않는 경우로 시작하는 것이다. 말로 설명하는 것보다 일종의 순서도로 나타내는 것이 편할 것 같아 그려보았다.

그림은 3일까지밖에 그리지 않았지만 일수가 늘어날 수록 경우의 수가 많아지는 것을 알 수 있을 것이다. 그래서 이 접근 방법을 생각한 후에 제한 사항을 보았다. 배열의 크기 제한이 30,000이기 때문에 모든 경우의 수는 2^30000-1가지인 것을 예상할 수 있고, 이 경우의 수를 모두 따져보는 것은 시간이 매우 오래 걸릴 것이고 당연히 정답이 아닐 것이다.

그래서 모든 경우를 따져보기보다는 따지지 않아도 되는 경우는 아예 브랜치를 잘라버렸다.(순서도가 Tree 모양을 띄고 있어서 이렇게 표현해보았다. 쉽게 말하면 더 따져볼 필요가 없는 경우는 후에 계산을 생략했다는 말이다.)

내가 생각한 더 이상 계산을 할 필요가 없어지는 때를 정리해보면 아래와 같았다.

• 1. 주식을 구매한 날의 가격보다 주식의 가격이 낮을 때는 판매를 할 이유가 없다. (daytobuy라는 변수를 활용했다.)
• 2. N일째까지의 최대 이익을 연산을 하면서 기록해놓는다. 그리고 N일째 이익을 계산할 때, 미리 기록해놓은 최대 이익보다 작으면 연산을 멈춘다.(이 때 주식을 갖고 있는지 아닌지 구분이 필요하여 함수의 파라미터로 check라는 Bool값을 사용하였다.)

class Solution {
private:
    vector<int> maximum; 
    int daytobuy;
public:
    void maxProfit(vector<int>& prices, int day, int profit, bool check /*hold stock(true) or not(false)*/ )
    {
        // 마지막 날까지 계산했을 때
        if(day == prices.size())
        {
            if(profit > maximum[day-1])
                maximum[day-1] = profit;
            return;
        }
        // 더 이상 연산이 필요 없을 때    
        if(profit < 0 && !check)
            return;
        if(profit < maximum[day] && !check)
            return;

        if(profit > maximum[day])
        {
            maximum[day] = profit;
        }

        if(check) // hold stock
        {
            maxProfit(prices, day+1, profit, check); // do nothing
            if(prices[daytobuy] < prices[day]){
                maxProfit(prices, day+1, profit+prices[day], !check); // sell
            }
        }
        else // not hold stock
        {
            maxProfit(prices, day+1, profit, check); // do nothing
            int prev = daytobuy;
            daytobuy=day;
            maxProfit(prices, day+1, profit-prices[day], !check); // buy
            daytobuy= prev;
        }
    }

    int maxProfit(vector<int>& prices) {
        int answer = 0;
        maximum = vector<int>(prices.size(), -10001);

        maxProfit(prices, 0, 0, 0);

        answer = maximum[prices.size() - 1];

        return answer;

    }
};

그래서 작성한 코드는 위와 같다. 주어진 테스트 케이스는 모두 통과를 하였고, 자체적으로 만든 테스트 케이스도 통과하여 제출을 했는데, 배열의 길이가 1,000개 정도가 넘어가자 'Time Limit Exceeded"가 떴다.

그래서 코드를 짠 후에도 1시간 정도, 브랜치를 더 자를 수 있는 아이디어가 있을까 고민해보았다.

접근방법 ②

결국 아이디어가 잘 생각이 나질 않았고, 떠올라도 연산 시간에 그렇게 크게 영향을 미칠 것 같지 않았다. 그래서 다른 사람들의 해결방법을 보기 위해서 Discuss 탭에 들어가서 다른 사람들의 풀이를 보았다.

풀이를 보자마자 '아 접근방법 ①로 풀면 안되는구나'라는 생각이 들었다. 왜냐하면 그래프를 보자마자 새로운 아이디어가 떠올랐기 때문이다.

위는 문제 풀이에 포함된 그래프이다.

그냥 나의 느낀점..

안타까운 것은 내가 문제를 보자마자 주어진 Input 값을 단순히 [1,7,2,3,6,7,6,7]과 같이 수열로만 볼 것이 아니라 머리속으로 그래프를 그려보았다면 한가지 방법을 고집하지 않았을 것이란 것이다.

코딩을 해보면서 많이 느끼지만 데이터를 다각적으로 볼 필요가 있고 그럴 수 있는 능력은 참 중요한 것 같다.

예전 같았으면 이런 상황에서 단순한 생각도 하지 못한 것에 대해 자괴감을 느꼈을 것이다. 하지만 코딩을 해보다 보니 생각의 전환을 하는 것은 생각보다 쉽지 않고 그런 능력은 하루 아침에 얻어지지 않는다. 다만 분명한 것은 아직 초보이긴하지만 컴퓨터를 처음 공부했을 때보다는 지금 코딩을 더 잘한다. 그러니까 지금처럼 조금씩이라도 코딩을 해보려고 지속적으로 노력하고 훈련한다면 분명 나아질 것이라고 믿는다.

그래프를 다시 보면 뭔가 느껴지는 것이 있을 것이다. 설명을 보지 않아도 A+B+C의 값이 D의 값과 같다는 것을 눈치챘다.

어렵게 바꿔 말해보면 주식 가격 배열(수열)의 어떤 구간 내의 수열이 단조증가하면 그 구간에서의 최대 수익은 수열의 모든 원소에 대해서 원소(주식 가격)와 그 다음 원소의 차이값의 합과 같다.

이를 코드로 옮기면 아래와 같다. Leetcode의 'archit91'란 사람의 코드를 인용했다.

class Solution {
public:
    int maxProfit(vector<int>& P) {
        int profit = 0;
        for(int i = 1; i < size(P); i++)
            if(P[i] > P[i-1])              // yesterday was valley, today is peak
                profit += P[i] - P[i-1];   // buy yesterday, sell today
        return profit;
    }
};

훨씬 짧은 코드로 Time Limit Exceeded 없이 모든 테스트 케이스가 통과되는 것을 확인할 수 있다.

리눅스 스터디를 진행하면서 실습용으로 리눅스 환경을 구성할 필요가 생겼다. 사실 나는 Windows를 이용해서 Windows의 WSL2를 사용해도 충분히 실습하는데는 문제가 없지만 이번 기회에 퍼블릭 클라우드 사용 연습도 해볼 겸 AWS를 이용하여 VPC를 생성하고 EC2로 CentOS 7 가상머신을 생성해보았다.

이전에 퍼블릭 클라우드를 아예 안다뤄본 것은 아니지만, 그 때는 VPC가 정확히 무엇인지도 모르고 그냥 튜토리얼만 따라했던 것 같다. 그래서 이번 포스팅에서는 단순히 튜토리얼만 제공하기보다는 VPC의 개념을 파악할 수 있도록 작성해볼 생각이다.

준비사항

*1. AWS 계정 2. VPC 학습 *

이 중에서 두 번째의 경우 유튜브에 올라온 강의(가상 데이터 센터 만들기 - VPC 기본 및 연결 옵션)를 추천한다.

위에 링크를 올린 강의가 친절하고 쉽게 설명되어 있기는 하지만 그래도 스스로 개념도 정리해보는 차원에서 전체구조를 한번 그려보면 아래와 같다.

먼저 용어 정리를 한번 해보면,

• 1. VPC : VPC는 Virtual Private Cloud를 의미한다. 즉 가상의 Private Cloud인데, 이렇게 적어놓으면 이해하기 힘드니까 의미를 설명해보겠다. 예전의 AWS의 인스턴스는 VPC 없이 하나의 네트워크 내부에서 제공이 되었다. 즉 이 말은 ①다른 고객들의 인스턴스들과 내가 사용하는 인스턴스가 분리가 되지 않았다는 뜻이다. 이 문제를 해결하기 위해 ②논리적으로 네트워크를 분리해서 내가 사용하는 인스턴스가 다른 고객들이 사용하는 인스턴스와 분리를 한 것이 VPC인 것이다.

• 2. Public & Private Subnet : 위의 그림에서 VPC 안에 Public Subnet이 있고, Private Subnet이 있는 것을 확인할 수 있는데, VPC 내부에서도 Subnetting을 통해 네트워크를 나눌 수 있다. 이 때 Public Subnet은 외부 인터넷과 연결이 가능한 Subnet이고 Private Subnet은 불가능하다. Private Subnet이 아예 외부 인터넷과 단절된 것은 아니다. NAT(Network Address Translation) 기술과 같은 VPC 내에 존재하는 Public Subnet을 이용해서 Private Subnet의 데이터를 외부 인터넷으로 전송할 수 있다.

• 3. Internet Gateway : Public Subnet은 외부 인터넷과 통신이 가능하다고 했는데, 이 때 Internet Gateway가 Public Subnet에서부터 생성된 데이터를 외부 인터넷으로 보내주고, 또 외부 인터넷에서 송신된 데이터를 Public Subnet으로 보내주는 역할을 한다.

• 4. EC2 Instance : EC2는 Elastic Compute Cloud를 의미한다. 클라우드라는 것을 처음 접해본 사람들은 Instance라는 용어가 헷갈릴 수 있는데, 객체지향프로그래밍의 객체라는 의미로 사용될 수도 있으나 클라우드에서는 CPU, Disk, Memory 등의 HW를 갖춘 하나의 서버라고 보는 것이 편할 것이다. 그러니까 인스턴스를 5개를 쓴다면 5개의 서버를 사용한다는 것이다.

AWS로 VPC & EC2 생성해보기

AWS Console 접속

먼저 AWS로 들어가서 로그인을 해서 AWS 관리 콘솔로 들어가면 위와 같은 화면이 보일 것이다. 나는 이 포스팅을 작성하기 전에 EC2와 VPC를 먼저 작성해보았기 때문에 최근 방문한 서비스로 EC2와 VPC가 뜨지만 처음 AWS를 사용하는 사람은 아닐 것이다. 그럴 때는 우측상단에 있는 서비스 버튼을 클릭해서 EC2와 VPC 서비스를 찾을 수 있고 또한 검색을 통해서도 찾을 수 있다.

VPC 생성

EC2를 생성하기 전에 먼저 네트워크를 구성하려고 하니 AWS 관리 콘솔에서 VPC 관리 콘솔을 찾아간다. VPC 관리 콘솔로 들어가면 위와 같은 화면을 볼 수 있다. 이 때 VPC 마법사 시작으로 자동으로 VPC를 구성할 수도 있지만 직접 VPC를 구성해보기 위해서 좌측에 보이는 가상 프라이빗 클라우드에서 VPC 버튼을 클릭한다.

VPC 버튼을 클릭하고 나면 페이지에 VPC 목록이 보일 것이다. 새로운 VPC를 구성할 것이기 때문에 우측 상단의 VPC 생성 버튼을 클릭한다.

VPC 생성 버튼을 누르고 나면, 새로운 VPC의 이름과 CIDR를 지정해줄 수 있다. 이름은 본인 선택에 따라서 정하면 되는데 나는 회색 글자로 표시된 예시 그대로 'my-vpc-01'을 그대로 사용했다.

여기서 헷갈리는 것은 CIDR일텐데 일단 CIDR의 정의부터 알고 시작을 하는 것이 좋을 것이다.

CIDR : Classless Inter-domain Routing의 약자로 말 그대로 Class없이 사용하는 네트워크 주소라고 할 수 있다. 예전에는 IP 주소에서 Class라는 개념을 사용했지만 IP 주소를 더 원활하게 할당하기 위해서 CIDR을 사용하게 되었다. CIDR을 사용하면 기존의 Class처럼 네트워크 주소와 호스트 주소의 길이를 Class에 따라 고정하지 않아도 되기 때문에 유연하게 IP 주소를 활용할 수 있다. 예를 들어 Class 방식에서는 네트워크 주소를 Class에 따라 8 bit, 16 bit, 24 bit로 사용했다면, CIDR에서는 172.16.0.0/12처럼 자유롭게 Subnet Mask의 길이('/' 문자 옆의 숫자, 12)를 지정해주어 네트워크 주소와 호스트 주소를 구분한다.

이전에 IP의 Class에 대해서 포스팅을 했었는데, 참고하길 바란다. (지금은 IP 주소에서 Class가 아닌 CIDR을 사용해서 언젠가 포스팅을 해야겠다고 생각하고는 있었는데, 이제야 올린다..)

CIDR를 사용할 때 한가지 더 알아야 할 것이 있다. RFC 1918 규약인데, Public IP와 Private IP를 헷갈리지 않기 위해서이다.

Private IP는 내부망에서 사용하고, Public IP는 인터넷에서 사용하는 것이다. 그러니까 하나의 Public IP는 전세계에서 유일한 값을 가진다.

CIDR를 사용할 때, RFC 1918 규약을 지켜야 하는데, 이는 위에서 언급한 Public IP와 Private IP를 헷갈리지 않기 위해서이다. RFC 1918에서는 내부망에서 사용하는 Private IP의 주소 범위를 정해놓았다. 주소 범위는 아래를 참고

CIDR에 대해서 감이 잡힌다면 이제 VPC의 IPv4 CIDR 블록을 잡아보겠다. AWS에서는 CIDR 블록의 넷마스크의 길이를 16~28로 제한하였다. 그러니까 이 범위 안의 넷마스크를 써야하는 것이다. 일단 나는 AWS EC2 인스턴스를 그렇게 많이 만들지 않을 것이다. 그러니까 VPC 내부의 Host 주소가 많을 필요가 없다. 그래서 그냥 AWS가 추천해준대로 10.0.0.0/24로 CIDR 블록을 설정해주었고 이렇게 하면 RFC 1918 규약도 지켰으며, Host 주소를 8 bit을 사용해서 VPC 내에서 Private IP는 2^8=256개를 사용할 수 있다.(사실 특수 용도 IP 때문에 256개보다는 적은 개수를 쓸 수 있다.)

CIDR 블록을 설정을 완료했으면 VPC 생성 버튼을 눌러 VPC 생성을 완료한다.

Subnet 생성

VPC를 생성했으니 이제 Subnet을 생성해야 한다. 이번 포스팅에서는 Public Subnet만을 생성해볼 것이다.

VPC를 생성했을 때처럼 VPC 대시보드(관리 콘솔에서 좌측에 보이는)의 가상 프라이빗 클라우드 항목 아래의 두번째에 서브넷 버튼이 있다. 그것을 클릭해서 서브넷 관리 페이지로 이동한다.

서브넷 관리 페이지도 VPC 관리 페이지와 UI가 비슷하다. 우측 상단의 서브넷 생성 버튼을 눌러 서브넷을 생성한다.

서브넷 생성 버튼을 눌러 이동하면 위와 같이 어떤 VPC 내에 서브넷을 만들 것인지 결정할 수 있다. 위에서 생성한 'my-vpc-01'을 선택한다.

VPC를 선택하면 위와 같이 서브넷 설정창이 뜬다. 서브넷 이름은 추천대로 'my-subnet-01'로 정해주었고 가용영역을 중간에 설명을 안했는데, 일단은 장애가 발생했을 때도 서비스가 지속 운영되기 위해 필요한 장치라고만 기억하고 넘어가고 'ap-northeast-2a'로 설정한다.

참고! 아시아 태평양, ap-northeast-2a가 뜨지 않는다면, 관리 콘솔 우측 상단의 지역이 서울인지 아니면 다른 지역인지 확인할 것. 만약 서울이 아니라 다른 지역이면 ap-northeast-2a가 뜨지 않고 다른 지역(Region)의 가용영역이 뜰 것이다.

그 다음 서브넷의 IPv4 CIDR 블록은 VPC에서 10.0.0.0/24로 CIDR 블록을 지정해주었으니 넷마스크가 24보다 작거나 같아야 한다. (VPC 내의 IP 주소 중 앞의 24 bit가 이미 고정이기 때문이다.) 나는 '10.0.0.0/26'으로 설정해주었다.

마지막으로 생성 버튼을 누르면 서브넷이 생성이 된다. 그리고 여기서는 Public Subnet으로 만들 것이기 때문에 Public IP가 필요하다.

생성된 서브넷을 클릭하고, 우측 상단의 작업 버튼을 눌러 '자동 할당 IP 설정 수정' 버튼을 누른다. 그 다음 퍼블릭 IPv4 주소 자동 할당 활성화를 체크한 뒤에 저장한다.

• (추가!) Subnet이 헷갈리는 사람을 위한 그림

아무래도 Subnet 형성을 할 때, 10.0.0.0/24니 10.0.0.0/26이니 계속 헷갈리게 숫자가 나와서 이해하기 어려운 사람들이 있을 것이라고 생각해서 그림을 준비해보았다.

32 bit 길이의 IPv4의 주소를 표로 나타내면 위와 같을 것이다. (특수목적의 주소를 제외하지는 않았다.)

이 포스팅에서 VPC를 생성할 때 CIDR 블록을 10.0.0.0/24로 설정하였다. 이 말은 즉 앞의 24 bit는 고정이어서 이진수로 나타낼 때, 0000 1010 0000 0000 0000 0000은 항상 똑같다는 말이다. 이를 표현한 그림은 아래와 같다. 그림을 보면 앞의 24 bit가 0000 1010 0000 0000 0000 0000 값을 가진 곳은 모두 파란색으로 칠해놓았다. 즉 이 부분이 VPC 내에서 사용하는 IP 주소라는 것이다.

그리고 Subnet을 생성할 때 CIDR 블록은 10.0.0.0/26으로 설정하였다. 똑같이 이 말은 앞의 26 bit가 고정이라는 것이다. 그러니까 0000 1010 0000 0000 0000 0000 + 00까지 항상 똑같다는 말이다. 그림으로 표현하면 위와 같이, 분홍색으로 칠한 부분이 생성한 Subnet에서 사용하는 IP 주소 영역이다. IP 주소의 26 bit가 모두 0000 1010 0000 0000 0000 0000 00으로 같은 것을 알 수 있다.

Internet Gateway 생성

이제 Public Subnet이 인터넷으로 연결되기 위한 Internet Gateway가 필요하다. 지금까지 해보았으면 알겠지만 Internet Gateway도 대시보드의 가상 프라이빗 클라우드 항목 아래에서 찾을 수 있다.

인터넷 게이트웨이 관리 페이지로 들어가서 우측 상단의 인터넷 게이트웨이 생성 버튼을 클릭하여 이름을 정해주면 인터넷 게이트웨이는 쉽게 생성된다.

생성이 되었으면 VPC와 연결해주어야 한다. 인터넷 게이트웨이를 생성한 직후 위 그림의 초록색 팝업 메세지에서도 VPC에 연결을 하라고 안내가 나오며, 작업 버튼을 클릭해서도 VPC 연결 항목을 골라서 VPC에 연결할 수 있다.

라우팅 테이블 작성

마지막으로 라우팅 테이블을 작성해주어야 한다. 라우팅 테이블을 수정하여 VPC 내의 데이터 패킷이 인터넷 게이트웨이로 향하는 경로를 만들어주어야 하는 것이다.

다시 서브넷 관리 콘솔로 들어와서 아까 생성한 서브넷을 클릭한 후 라우팅 테이블 항목을 클릭하면 라우팅 테이블 상태를 볼 수 있다. 지금은 10.0.0.0/24는 local로 향한다는 내용밖에 없다.

라우팅 테이블을 생성하려면 가상 프라이빗 클라우드 항목 아래의 라우팅 테이블을 클릭하여 라우팅 테이블 관리 페이지로 들어간다. 그 다음 라우팅 테이블 생성 버튼을 클릭하고 VPC 연결은 아까 만든 VPC에 연결하여 라우팅 테이블을 생성하면 된다. 라우팅 테이블을 생성한 뒤에 생성한 라우팅 테이블을 클릭하고 아래에서 라우팅 항목을 클릭하면 라우팅 테이블 정보가 표시된다. 이 때 오른쪽의 라우팅 편집 버튼을 눌러 라우팅 테이블을 수정한다. 좌측 하단의 라우팅 추가 버튼을 클릭하여 새 라우팅 정보를 입력한다. 대상 항목에는 0.0.0.0/0을 입력한다. (0.0.0.0/0은 외부 인터넷으로 향해야 하는 데이터 패킷을 의미) 그리고 그것들이 인터넷 게이트웨이를 거쳐야 외부 인터넷으로 향할 수 있기 때문에 두번째 대상 항목을 클릭하고 인터넷 게이트웨이 항목을 눌러 생성한 인터넷 게이트웨이를 선택해주고 변경사항을 저장해주면 된다.

마지막으로 '서브넷 연결 항목'을 클릭해 생성한 서브넷과 연결해주면 Public Subnet이 인터넷 게이트웨이를 통해 인터넷과 연결될 수 있는 VPC 환경이 만들어진다.

요즈음, 네트워크와 관련해서 궁금한 것이나 헷갈리는 것이 생기면 바로바로 왜 그런 것인지 생각하고 찾아보려는 노력을 하고 있다.

어제인가 생각 난 것인데, 지하철의 Wifi는 IP 주소를 어떻게 할당하는지가 궁금해졌다. 보통 Wifi는 192로 시작하는 Class C의 IP 주소를 사용하기 때문에 Host 파트인 8 bit로 IP 주소를 할당해야 한다.(브로드캐스팅용과 네트워크 주소 그 자체를 빼면 2^8 - 2 = 254개의 주소를 할당 할 수 있다.)

그런데 지하철에는 사람이 엄청 많은데 어떻게 Class C로 IP 주소를 사람들 모두에게 할당할 수 있는걸까? 그래서 지하철은 Class B를 써서 Host 파트를 더 늘리나 싶었지만, 오늘 아침 지하철에서 한번 IP 주소를 확인해보니 192로 시작하는 Class C의 주소였다. (다시 생각해보니까 지하철 한칸에 아무리 많아도 200명도 안될 것 같긴하다.)

진짜로 찾아보니 160명이 지하철 혼잡도 100%라고 한다. 그런데 출근길의 지하철 객차의 혼잡도가 200%가 넘을 때도 있다고 하는데, 이 말은 320명이 넘게 한 객차에 있다는 말이된다. 그렇다면 Class C로는 IP 주소를 다 할당하지 못할텐데 기회가 되면 실험을 해봐야겠다.

참고 : 지하철에는 맨끝 객차에 중계기(Repeater)가 있고 객차마다 Wifi 공유기가 설치되어 있다고 한다. (중계기는 약해진 신호를 받아 다시 강하게 전달해주는 역할을 함.)

사실 이런 고민들을 학창 시절, 컴퓨터 네트워크와 컴퓨터 통신 수업을 들을 때 했어야 했는데 그러지 않았던 것이 아쉽다. 그랬으면 공부할 때 이해도 더 잘되고 기억에도 오래 남을 수 있었을텐데..

네트워크 수업 때 IP 주소체계를 처음 들었을 때, 이해가 잘 되지 않았다. 지금 생각해보면 위와 같이 실생활에 적용해보면 쉽게 알 수 있었을 것이라는 생각이 든다.

IP 주소 체계

IP는 크게 IPv6와 IPv4 두가지로 나뉜다. IPv6는 IPv4의 고갈 문제 때문에 주소의 크기를 확장시킨 것이라고 짧게 설명을 마치겠다.

IPv4는 32 bit로 이루어져있으며 클래스로 구분을 한다. 클래스는 A,B,C,D,E 총 5개로 나뉘어진다. IPv4의 32 bit 중 가장 앞쪽에 1이 몇개인지에 따라 클래스를 구분할 수 있다. A Class는 맨 앞에 1이 0개, B는 1개, C는 2개 이런 방식이다. 아래에 IP 주소를 이진수로 표현해놓은 것에 볼드체를 해놓았다.

Class A

이진수 : 00000001.x.x.x

1을 넣은 이유는 Class A는 Network 파트가 8 bit까지인데, 모두가 0이면 특수한 용도의 주소로 사용되기 때문이다.

• 범위 : 1.0.0.0~126.255.255.255
• Network Part : 맨 앞 8 bit
• Host Part : 나머지 24 bit
• 할당 가능 IP 개수 : 2^24 - 2개

Class B

• 이진수 : 10000000.x.x.x
• 범위 : 128.0.0.0~191.255.255.255
• Network Part : 맨 앞 16 bit
• Host Part : 나머지 16 bit
• 할당 가능 IP 개수 : 2^16 - 2개

  Class C

• 이진수 : 11000000.x.x.x
• 범위 : 192.0.0.0~223.255.255.255
• Network Part : 맨 앞 24 bit
• Host Part : 나머지 8 bit
• 할당 가능 IP 개수 : 2^8 - 2개(254개)

  A, B, C Class까지가 일반적으로 사용되는 IP 주소 Class이다.

Class D

• 이진수 11100000.x.x.x
• 범위 : 224.0.0.0~239.255.255.255

멀티캐스팅 용도로 사용되는 Class이다.

Class E

• 이진수 11110000.x.x.x
• 범위 : 240.0.0.0~255.255.255.255

연구개발 목적으로 사용되는 Class이다.

Class 범위 계산

처음에는 범위도 외워야 하는 줄 알았다. 그러나 조금만 더 생각해보면 쉽게 계산할 수 있다는 것을 알 수 있다. 예를 들면 Class C의 경우 범위가 192.0.0.0~223.255.255.255인데, Class C의 경우 맨 앞의 비트가 110이어야 하고 111이 되면 안된다. 그렇기 때문에 Class C Network 파트의 최댓값은 이진수로 11011111로 223인것을 알 수 있다.

그러니까 Class C의 주소는 192.0.0.0~223.255.255.255의 범위를 가지는 것이고 다른 Class들도 마찬가지이다.

특수 목적 IPv4 주소

위의 A, B, C Class에서 할당 가능 IP 개수를 보면 Host 파트가 24, 16, 8 bit임에도 2^24개, 2^16개, 2^8개의 IP 주소를 할당할 수 없다. 이는 특수한 목적의 IPv4 주소가 따로 지정되어 있기 때문인데, Host 파트의 경우 전부 0이면 네트워크 주소 그 자체를 가리키고, 전부 1이면 그 네트워크 내에 모든 주소로 브로드캐스트를 하기 위한 용도로 사용된다.

특수 목적 IPv4 주소는 아래의 표와 같이 정리할 수 있다.

CIDR

이 포스팅에서 IPv4의 주소 체계를 이야기했고, Class가 어떻게 나누어지는지 설명하였다. 그러나 현재는 IP 주소를 Class로 나누지 않고 CIDR(Classless Inter-Domain Routing)이라는 기법을 사용한다. 이에 대해서는 AWS로 VPC라는 가상의 네트워크를 생성하면서 설명했으니 참고하길 바란다. https://velog.io/@halim_limha/AWS-VPC-EC2-%ED%8A%9C%ED%86%A0%EB%A6%AC%EC%96%BC

머리속에만 떠오르고 다른 사람들에게 설명하지 못하면 그것은 모르는 것이나 마찬가지라고 생각한다. 그래서 이번 글을 써보면서 DHCP가 무엇인지 다시 정리해보기로 했다.

DHCP란?

일단 DHCP는 Dynamic Host Configuration Protocol로 프로토콜의 한 종류이다. 프로토콜의 하나의 종류로, 호스트들의 IP를 자동으로 할당해주는 역할을 한다.

호스트들의 IP를 자동으로 할당해주는 역할을 왜 해야하는지 생각을 해보았다.

첫번째로 생각나는 것은 이 세상에는 수 많은 컴퓨터가 존재하는데, 그 컴퓨터마다 일일이 IP 주소를 직접 설정해주는 것은 굉장히 번거로운 일이라고 생각을 했다.

두번째로는 컴퓨터를 사용할 때, 가정에서 사용하는 PC 같은 경우는 켜져 있는 시간도 있지만 사용하지 않는 시간대도 분명히 있을 것이다. 이 때, 켜져있지도 않은 PC를 위해 IP 주소를 할당해놓는 것은 낭비일 것이라는 생각을 했다. 그래서 차라리 컴퓨터가 켜질 때, IP 주소를 할당받는게 좋지 않을까 하는 생각이다.

세번째는 첫번째 이유와 비슷한데, 만약에 사람이 직접 IP 주소를 할당받도록 한다면, 실수로 동시에 여러 Host에서 IP를 같이 써서 충돌이 일어날 수도 있겠다는 생각을 했다.

스스로 생각해본 DHCP를 사용하는 이유는 위와 같다. 실제로 인터넷에서도 확인해본 결과 비슷한 이유를 설명하고 있었다.

DHCP 동작 과정

조금만 더 생각해보면 DHCP 동작 과정도 기억해낼 수 있었을 것 같아 아쉬움이 남는다.

중요한 것은 IP 주소도 할당받지 못한 Host는 DHCP 서버가 어디에 있는지 알 수가 없다. 그렇기 때문에 Host가 속한 Subnet에 브로드캐스팅을 해야 한다.

참고 : IP를 할당받지 않았으니 IP를 이용하는 것이 아니고 물리적 주소인 MAC 주소를 사용하여 브로드캐스팅을 한다. (브로드캐스팅용 MAC 주소 : FF:FF:FF:FF:FF:FF)

연결 대상이 어디에 있는지 알 수가 없기 때문에 브로드 캐스팅을 하는 것을 생각해보면, TCP나 UDP 중 UDP가 적합한 것을 쉽게 유추할 수 있다. TCP는 연결을 한 뒤에 통신을 하지만 UDP는 연결 과정이 없기 때문에 더 빠르다.

다시 정리를 해보면 DHCP를 통해 IP를 할당받는 과정은 총 4단계로 설명할 수 있다.

1. DHCP Discover

Host가 DHCP 서버가 어디에 있는지 찾고 IP 할당을 요청하는 과정이다. 위에서 말했던대로 IP 할당 요청을 브로드캐스팅해서 DHCP 서버로 보낸다.

2. DHCP Offer

DHCP 서버가 발견되고 IP 할당 요청이 잘 도착하면 DHCP 서버에서는 Host에게 요청한 IP와 Host의 MAC 주소를 같이 보낸다.(DHCP Offer도 브로드캐스팅을 하기 때문에 MAC 주소도 같이 보내는 것으로 예상된다.)

3. DHCP Request

DHCP Offer를 통해서 IP를 할당받으면 그 IP를 사용하겠다고 DHCP 서버에 확정 메세지를 보내야 한다. 그것이 DHCP Request이다.

4. DHCP Ack

DHCP 서버에서 DHCP Request를 받으면 다시 ACK를 보내주어야 마무리가 된다. 이 때 ACK는 브로드캐스팅을 할 수도 있고 유니캐스트를 할 수도 있는데, 왜 굳이 브로드캐스팅까지 가능하게 했는지는 한번 고민을 해봐야 할 것 같다.

Stackoverflow에 비슷한 질문을 한 사람이 있어서 답변을 살펴보았고 아래의 RFC를 볼 수 있었다.

RFC2131 : https://www.ietf.org/rfc/rfc2131.txt

Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using uicast delivery. The IP destination address (in the IP header) is set to the DHCP 'yiaddr' address and the link-layer destination address is set to the DHCP 'chaddr' address. Unfortunately, some client implementations are unable to receive such unicast IP datagrams until the implementation has been configured with a valid IP address (leading to a deadlock in which the client's IP address cannot be delivered until the client has been configured with an IP address). A client that cannot receive unicast IP datagrams until its protocol software has been configured with an IP address SHOULD set the BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or DHCPREQUEST messages that client sends. The BROADCAST bit will provide a hint to the DHCP server and BOOTP relay agent to broadcast any messages to the client on the client's subnet. A client that can receive unicast IP datagrams before its protocol software has been configured SHOULD clear the BROADCAST bit to 0. The BOOTP clarifications document discusses the ramifications of the use of the BROADCAST bit

해석을 해보자면 몇몇의 Client는 IP 주소를 제대로 받기 전에 Unicast된 IP datagram을 받을 수 있도록 구현되지 않았기 때문이라고 할 수 있다.

그래서 이런 Client는 DHCP Discover와 Request 메세지를 보낼 때, DHCP Server가 미리 Client의 상태를 알고 브로드캐스팅할 수 있도록 flag bit를 1로 만들고 보낸다고 한다.

결론부터 말하면 Local 모드와 다른 점은 스냅샷 리포지토리를 ES의 Node들이 공유가 가능해야 한다는 것이다. 사실 처음 생각하기에도, 각 Node에 스냅샷 파일들을 모두 저장하고 각각의 Node가 자신의 Local Storage에서 스냅샷을 불러오는 것은 비효율적이라는 느낌이 들었다.

참고 : 혹시 몰라서 각 Node마다 똑같은 경로에 스냅샷 파일을 저장하고 테스트를 해봤지만 이렇게 하면 각 Node에서 스냅샷에 접근이 안된다고 에러가 뜬다..

해야할 일은 아래와 같다.

1. elasticsearch.yml 파일에 스냅샷 리포지토리 경로 설정 2. Shared File System 생성 3. Snapshot API를 활용하여 복구

스냅샷 리포지토리 경로 설정

elasticsearch.yml 파일에서 스냅샷 리포지토리의 경로를 설정해주어야 한다. 마지막에 사용할 스냅샷 API에도 리포지토리의 경로에 대한 내용이 들어가긴 하지만 elasticsearch.yml 파일에 스냅샷 리포지토리의 경로가 없으면 에러가 뜬다.

파라미터의 이름은 path.repo이다. 설정한적이 없다면 아마 이 파라미터를 발견할 수 없을 것인데, 새로 만들어주고 경로를 입력하면된다.

path.repo: [<Snapshot Repository 경로>, <Snapshot Repository 경로2>, ..]

나는 NFS(Network File System)에 스냅샷을 저장해서 테스트를 했기 때문에 공유된 Directory의 경로를 입력해주었다.

NFS 구성

NFS Server 측

Elasticsearch의 2개의 Node에 NFS을 구성해주었다. NFS Server는 Masternode가 있는 쪽에 설치해주었다.

먼저 apt를 update해주고

$ sudo apt update

nfs-kernel-server를 설치한다.

$ sudo apt install nfs-kernel-server

설치가 완료되었으면 nfs-server의 상태를 확인할 수 있다.

$ sudo systemctl status nfs-server

정상적으로 nfs-server가 구동되는 것을 확인한 후에 공유 용도로 쓸 Directory를 만들어 주었다. 권한과 소유권도 문제가 없도록 바꾸어주었다.

$ sudo chown nobody:nogroup <공유할 Directory>
$ sudo chmod -R 777 <공유할 Directory>

그 다음 공유할 Directory에 Client가 접근할 수 있도록 '/etc/exports' 파일을 수정해주어야 한다.

<공유할 디렉토리> <client-IP>(rw,sync,no_subtree_check)

여기서 rw는 read와 write를 허용한다는 의미이고, sync는 Disk에 파일이 쓰이기 전에 파일 접근을 막는 것을 의미한다.(허용하려면 async 옵션을 사용) 마지막으로 no_subtree_check는 subtree_check를 하지 않는다는 것을 뜻하는데 subtree_check는 NFS 서버가 Client로부터 접근되었을 때, 공유된 Directory에 접근되었는지를 확인하는 것이다.

참고 : subtree_check는 대부분의 사용사례에서 불필요하며 오히려 문제를 일으킬 가능성이 높다고 한다. https://www.linuxquestions.org/questions/linux-newbie-8/please-explain-me-subtree_check-814080/

/etc/exports 파일 수정이 완료되었으면 아래의 명령어를 입력해 Directory를 공유한다.

$ sudo exportfs -a

NFS Client

NFS Server가 구축이 되었으면 다른 서버에는 NFS Client가 있어야 한다.

nfs-kernel-server가 아닌 nfs-common으로 설치한다.

$ sudo apt update
$ sudo apt install nfs-common

설치가 완료되었으면 NFS Server를 원하는 Directory에 Mount한다.

$ sudo mount <nfs-server 주소>:<공유 Directory 경로> <Mount할 Directory 경로>

Mount까지 성공했으면 공유된 Directory에 파일을 하나 생성해보고 테스트를 할 수 있다.

Snapshot API

공유 파일 시스템이 만들어졌으니 이제 스냅샷을 복구할 수 있다.

PUT /_snapshot/my_fs_backup
{
  "type": "fs",
  "settings": {
    "location": "<공유 Directory Path>",       
    "compress": true
  }
}

공유 파일 시스템을 쓰기 때문에 "type"이 "fs"(file system)이다.

참고 : "type"을 url로 하면 url을 통해서 스냅샷을 받아올 수도 있다. 일단 테스트는 NFS를 사용했지만 만약에 실제로 Elasticsearch Cluster를 운영한다면 NFS에 스냅샷을 저장하는 것은 굉장히 번거로울 것이다.

성공하면 Response로 acknowledge가 true로 반환된다.

참고(ES Official Guide) : https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshots-register-repository.html

그래서 따로 플러그인을 설치할 필요없이 몇가지 작업을 해주면 ElasticSearch Cluster에 암호를 설정할 수 있고, User나 Role을 설정해서 User마다 Index, Cluster에 대한 접근 제한을 할 수 있다.

TLS 구성

먼저 Node마다 인증서가 필요하다. 다른 프로그램으로 인증서를 생성해도 되지만 ElasticSearch에서도 인증서를 만들어주는 기능이 있다. ElasticSearch의 bin 디렉토리가 있는 곳(/usr/share/elasticsearch)로 가서 아래의 명령어로 인증서를 생성한다.

bin/elasticsearch-certutil cert -out /etc/elasticsearch/elastic-certificates.p12 -pass ""

맨끝에 -pass "" 이 부분은 인증서의 비밀번호 설정이며 ""로 집어넣었기 때문에 비밀번호가 없는 것이다. -pass ""를 넣지않으면 인증서 비밀번호를 입력하라는 프롬프트가 뜬다.

참고 : Java version이 9 이전 버전이라면 인증서 생성을 할 수 없을 것이다. (인증서를 생성하는 알고리즘이 구현이 안되어 있는 것으로 추정) JDK를 업데이트하면 해결될 것이다.

Datanode에도 MasterNode에서 만든 인증서를 복사해서 같은 위치에 넣어주면 된다. SSH을 통한 통신으로 원격 서버에 인증서를 보내줄 수 있다.

$ scp <파일명(/etc/elasticsearch/elastic-certificates.p12)> <user@hostip>:<도착할 위치(/tmp)>

권한 문제 때문에 인증서가 도착할 원격 서버의 File Path는 /tmp로 하고 원격 서버에 SSH로 접속한 뒤에 Root User로 들어가 다시 /etc/elasticsearch directory로 옮겨주었다.

elasticsearch.yml 파일

인증서를 생성했으니 이제 elasticsearch.yml 파일도 TLS 통신을 하도록 설정을 해주어야 한다.

아래의 parameter들을 elasticsearch.yml 파일에 넣어주면 된다. xpack의 security 기능들을 사용하도록 설정한 것이다.

xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: elastic-certificates.p12

yml 파일을 수정했으면 ElasticSearch를 재시작한다.

$ sudo systemctl restart elasticsearch.service

그러나 위의 Parameter들을 추가하고, ElasticSearch를 재실행하면 아래와 같은 Error 메세지가 뜰 것이다.

Job for elasticsearch.service failed because the control process exited with error code. See "systemctl status elasticsearch.service" and "journalctl -xe" for details.

이유를 확인하려고 Log를 확인하였더니 원인은 Permission이었다.

참고 : Log는 /var/log/elasticsearch/<클러스터이름>.log를 확인하면 될 것이다. 위의 사진을 보면 인증서 파일만 Group에 권한이 없는 것을 확인할 수 있다. 다른 파일들과 권한을 같게 만들어주었다.

$ chmod g+rw elastic-certificates.p12

그리고 Elasticsearch를 재시작하면 정상적으로 작동할 것이다.

Cluster 비밀번호 설정

Master Node와 Data Node가 다시 실행되었으면, Cluster의 비밀번호를 설정해야 한다. 비밀번호 설정은 Master Node에서 한다.

아래의 명령어를 입력하면 랜덤한 비밀번호를 자동으로 설정해준다.

$ bin/elasticsearch-setup-passwords auto

parameter를 interactive로 하면 직접 비밀번호를 입력하여 설정할 수도 있다. Test에서는 interactive를 선택해서 비밀번호를 작성하였다.

$ bin/elasticsearch-setup-passwords interactive

이 명령어를 실행하면 elasticsearch만 아니라 Kibana나 logstash의 비밀번호도 설정하라는 프롬프트가 뜨는데 모두 동일한 비밀번호를 설정해주었다.

참고 : Cluster에 Datanode가 없거나 Masternode가 없는데 위의 명령어를 사용하면 에러가 뜰 것이다. 즉 Node간 연결이 이뤄지지 않았을 가능성이 있으니 확인해볼 것

비밀번호를 설정 후 elasticsearch에 접속을 시도하면 위와 같이 Username과 Password를 입력하라는 팝업창이 뜬다. (계정명은 elastic이다.)

Basic Auth

HTTP 인증 방식에는 여러가지가 있지만 일단 테스트에서는 가장 기본적인 Basic Auth를 사용해보았다. 보낼 때만 암호화를 하기 때문에 스니핑에 취약하다고 한다.

User 추가

ElasticSearch의 xpack을 사용하면 User와 Role을 부여해 User마다 Role을 부여해 접근 권한을 제한할 수 있다.

Elasticsearch의 REST API를 사용해서도 User와 Role을 추가할 수도 있지만, 아직 익숙하지 않아 Kibana를 이용해 GUI로 Test를 진행해보았다.

Kibana를 설치하고 elastic 계정으로 접속을 하면 왼쪽 하단에 톱니바퀴 모양의 아이콘이 보일텐데 그 아이콘을 클릭하면 Elasticsearch를 관리하는 옵션들이 나온다. 그리고 관리 항목 중 Security 항목의 Users를 클릭하면 User들의 목록을 볼 수 있고 User를 새로 만들어 줄 수도 있다. 테스트를 위해 test라는 user를 생성해보았다.

user를 생성했지만 아직 접근 권한을 제한할 Role을 만들지 않았기 때문에 user에 Role은 부여하지 않았다.

Role 부여

Role도 User와 같이 Security 항목에 위치해있다.

Roles를 클릭하고 Create Role을 클릭한 뒤에 test-role이라는 Role을 만들어주었다. 아래의 Add index privilege 버튼을 눌러 test-role을 nutch라는 index을 읽을 수만 있게 권한을 부여해주었다.

그 뒤에 아까 만들어준 test라는 user에 test-role을 부여해주었다.

User로 인증 후 검색

보안 기능을 활성화 했기 때문에 이제 ElasticSearch REST API를 이용하려면 Authorization header가 추가로 필요하다. Postman의 Authorization 항목을 보면 Header를 추가할 수 있다. 일단 index가 어떤 것이 있는지 확인하기 위해 elastic 계정으로 인증하여 Request를 보냈다.

보안 기능을 활성화해서 생긴 Index를 제외하면 직접 생성한 index는 nutch와 test 하나이다.

이 중에서 test index는 test user에게 읽을 수 있는 권한을 주지 않았기 때문에 결과를 받을 수 없을 것이다.

반면에 nutch index는 test라는 user에게 읽기 권한을 주었기 때문에 검색이 잘 된다.

Hadoop Install

wget을 이용하여 Hadoop 3.2.2 version을 설치한다.

$ sudo wget -P /usr/local/ https://downloads.apache.org/hadoop/common/hadoop-3.2.2/hadoop-3.2.2.tar.gz

Hadoop을 설치한 Directory로 이동하여 압축을 풀어준다.

$ sudo tar xzf hadoop-3.2.2.tar.gz

환경변수 설정

Ubuntu에서 Test를 진행했기 때문에 ~/.bashrc에 환경변수를 추가해주었다.

$ echo 'export HADOOP_HOME=/usr/local/hadoop-3.2.2' >> ~/.bashrc $ echo 'export PATH=&#36PATH:&#36HADOOP_HOME/bin:&#36HADOOP_HOME/sbin' >> ~/.bashrc

source 명령어로 환경변수를 바로 적용해줄 수 있다.

$ source ~/.bashrc

SSH 설치

Hadoop Node는 SSH를 이용하여 서로 통신을 하기 때문에 SSH Server를 설치해주어야 한다.

$ sudo apt install openssh-server

그리고 PDSH 기본통신을 RSH에서 SSH로 바꾸어주어야 한다. (이 부분은 아직 어떤 의미가 있는 것인지 정확히 파악이 되지 않았다.

echo 'export PDSH_RCMD_TYPE=ssh' >> ~/.bashrc

PDSH 참고 : https://linux.die.net/man/1/pdsh

위의 명령어를 실행한 뒤에 변경사항을 적용하고 싶으면 hadoop 환경변수를 등록 후 source 명령어를 이용했던 것처럼 똑같이 해주면 된다.

SSH를 설치했으면 Hadoop이 암호화된 통신을 하기 위해 RSA Key를 만들고 분배해주어야 한다.

# 마스터노드에서 실행할 것
$ ssh-keygen -t rsa
$ cp id_rsa.pub authorized_keys

# 모든 네임노드에서 실행할 것
# {namenode00} - 모든 네임노드에 적용해야함을 의미함
$ scp authorized_keys {namenode00}:~/.ssh/authorized_keys

# 모든 데이터노드에서 실행할 것
# {datenode00} - 모든 데이터노드에 적용해야함을 의미함

ssh {datanode00}
$ mkdir -p /home/hadoop/.ssh
$ scp authorized_keys {datanode00}:~/.ssh/authorized_keys

Hadoop 환경 설정

Hadoop 환경 설정을 해주기 위해서는 4개의 xml 파일이 필요하다. 아래에 직접 테스트할 때 이용했던 xml 파일 내용을 첨부하였다.

HOST IP Alias

Node의 Host IP 주소가 들어가야 하는 부분들은 직접 IP 주소를 입력하기보다는 /etc/hosts에서 IP에 alias를 만들어주어서 그 alias를 입력하였다.

예를 들면 xxx.xxx.xxx.xxx라는 IP 주소를 datanode01이라고 alias를 만들어주어 사용한 것을 확인할 수 있을 것이다.

HDFS용 스토리지

그리고 HDFS은 운영체제가 설치되어 있는 SSD가 아닌 HDD를 이용할 것이기 때문에 HDD를 리눅스 파일시스템으로 포맷을 하고 Mount를 해주었다.

# 스토리지 리스트 확인
sudo fdisk -l

# linux file system으로 포맷
sudo mkfs.ext4 /dev/sdb

# mount 할 디렉토리 생성
sudo mkdir /data

# mount
sudo mount /dev/sdb /data

# mount 된 폴더에 권한 부여
sudo chown -R hadoop:hadoop /data

아래의 xml 파일들을 잘 보면 mounting된 /data directory를 사용하는 것을 확인할 수 있을 것이다.

core-site.xml

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<!--
  Licensed under the Apache License, Version 2.0 (the "License");
  you may not use this file except in compliance with the License.
  You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License. See accompanying LICENSE file.
-->

<!-- Put site-specific property overrides in this file. -->

<configuration>
    <property>
        <name>fs.defaultFS</name>
        <value>hdfs://namenode01:9000</value>
    </property>
    <property>
        <name>hadoop.tmp.dir</name>
        <value>/home/data/hadoop/tmp</value>
    </property>
</configuration>

hdfs-site.xml

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<!--
  Licensed under the Apache License, Version 2.0 (the "License");
  you may not use this file except in compliance with the License.
  You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License. See accompanying LICENSE file.
-->

<!-- Put site-specific property overrides in this file. -->

<configuration>
    <property>
        <name>dfs.replication</name>
        <value>1</value>
    </property>
    <property>
        <name>dfs.namenode.name.dir</name>
        <value>/home/data/hadoop/dfs/name</value>
    </property>
    <property>
        <name>dfs.namenode.edits.dir</name>
        <value>/home/data/hadoop/dfs/edit</value>
    </property>    
    <property>
        <name>dfs.datanode.data.dir</name>
        <value>/home/data/hadoop/dfs/data</value>
    </property>
    <property>
        <name>dfs.namenode.secondary.http-address</name>
        <value>namenode02:9868</value>
    </property>
    <property>
        <name>dfs.namenode.checkpoint.dir</name>
        <value>/home/data/hadoop/dfs/checkpoint</value>
    </property>


</configuration>

mapred-site.xml

<?xml version="1.0"?>

<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>

<!--

 Licensed under the Apache License, Version 2.0 (the "License");

 you may not use this file except in compliance with the License.

 You may obtain a copy of the License at

  http://www.apache.org/licenses/LICENSE-2.0

 Unless required by applicable law or agreed to in writing, software

 distributed under the License is distributed on an "AS IS" BASIS,

 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

 See the License for the specific language governing permissions and

 limitations under the License. See accompanying LICENSE file.

-->

<!-- Put site-specific property overrides in this file. -->

<configuration>
        <property>
                <name>mapreduce.framework.name</name>
                <value>yarn</value>
        </property>
        <property>
                <name>yarn.app.mapreduce.am.resource.mb</name>
                <value>1228</value>
        </property>
        <property>
                <name>yarn.app.mapreduce.am.env</name>
                <value>HADOOP_MAPRED_HOME=/usr/local/hadoop-3.2.2</value>
        </property>
        <property>
                <name>mapreduce.map.env</name>
                <value>HADOOP_MAPRED_HOME=/usr/local/hadoop-3.2.2</value>
        </property>
        <property>
                <name>mapreduce.reduce.env</name>
                <value>HADOOP_MAPRED_HOME=/usr/local/hadoop-3.2.2</value>
        </property>
        <property>
                <name>mapreduce.application.classpath</name>
                <value>$HADOOP_MAPRED_HOME/share/hadoop/mapreduce/*,$HADOOP_MAPRED_HOME/share/hadoop/mapreduce/lib/*,$HADOOP_MAPRED_HOME/share/hadoop/common/*,$HADOOP_MAPRED_HOME/share/hadoop/common/lib/*,$HADOOP_MAPRED_HOME/share/hadoop/yarn/*,$HADOOP_MAPRED_HOME/share/hadoop/yarn/lib/*,$HADOOP_MAPRED_HOME/share/hadoop/hdfs/*,$HADOOP_MAPRED_HOME/share/hadoop/hdfs/lib/*</value>
        </property>
</configuration>

yarn-site.xml

yarn은 Hadoop Cluster의 Resource를 관리해주는 역할을 한다. 크게 ResourceManager와 NodeManager로 구성이 되어 있으며 Yarn에 대해서는 추후에 추가로 글을 더 작성해볼 예정이다. 일단 yarn-site.xml 파일에서 해주어야 할 것은 아래의 resourcemanager.hostname property에 namenode의 Host 주소와 nodemanager.hostname property에 datanode의 Host 주소를 입력하면 된다.(Datanode가 여러개라면 각 Datanode의 yarn-site.xml 파일의 nodemanager.hostname은 각자의 Host 주소를 입력하면 된다. 예를 들면 datanode01에는 datanode01의 host 주소를, datanode02에는 datanode02의 host 주소를 입력한다.)

<?xml version="1.0"?>
<!--
  Licensed under the Apache License, Version 2.0 (the "License");
  you may not use this file except in compliance with the License.
  You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License. See accompanying LICENSE file.
-->
<configuration>

<!-- Site specific YARN configuration properties -->
        <property>
                <name>yarn.resourcemanager.hostname</name>
                <value>namenode01</value>
        </property>
        <property>
                <name>yarn.nodemanager.hostname</name>
                <value>datanode01</value>
        </property>
        <property>
                <name>yarn.nodemanager.aux-services</name>
                <value>mapreduce_shuffle</value>
        </property>
        <property>
                <name>yarn.scheduler.capacity.maximum-am-resource-percent</name>
                <value>1</value>
        </property>
        <property>
                <name>yarn.nodemanager.resource.memory-mb</name>
                <value>4096</value>
        </property>
        <property>
                  <name>yarn.nodemanager.env-whitelist</name>
                  <value>JAVA_HOME,HADOOP_COMMON_HOME,HADOOP_HDFS_HOME,HADOOP_CONF_DIR,CLASSPATH_PERPEND_DISTCACHE,HADOOP_YARN_HOME,HADOOP_MAPRED_HOME</value>
        </property>
</configuration>

마지막으로 master와 workers file에 각각에 맞는 Node의 Host 주소를 입력해주면 된다. (namenode로 설정한 host의 IP는 master 파일에, datanode로 설정한 host의 IP는 workers 파일에 넣어주면 된다.)

Hadoop 실행

hadoop이 위치한 Directory로 이동한다. (직접 해본 Test에서는 /usr/local/hadoop-3.2.2에 위치)

그 뒤에 sbin directory에 있는 start-all.sh 스크립트를 실행하면 된다. sbin에 있는 shell script 파일을 확인해보면 stop-all.sh도 존재하는 것을 알 수 있을텐데 당연히 hadoop을 중지하는 script이다.

$ sbin/start-all.sh

ElasticSearch 설치

JDK 설치

아래의 명령어로 JDK의 Version을 확인할 수 있다. JDK가 없으면 Not Found 메세지가 뜸.

$ javac -version

만약에 설치가 안되어 있으면 아래의 apt install으로 JDK 설치할 수 있음. ES를 쓰는데 OpenJDK가 아닌 다른 것을 써도 될 것임.

$ sudo apt install openjdk-11-jdk

GPG 공개키

ElasticSearch는 GPG Key를 이용하여 무결성을 검증하기 때문에 GPG Key를 가져와야 한다. 아래의 명령어를 입력해 GPG Key를 받아올 수 있다.

$ wget -qO - https://artifacts.elastic.co./GPG-KEY-elasticsearch | sudo apt-key add -

OK가 뜨면 문제가 없음.

ElasticSearch Repository 등록

apt(Advanced Packaging Tool)에 Repository를 등록하면 apt를 이용하여 Elasticsearch를 설치할 수 있다.

직접 /etc/apt/sources.list.d Directory에서 만들어 주어도 되지만 아래의 명령어처럼 Shell Script를 실행하여 등록할 수도 있다.

$ sudo sh -c 'echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" > /etc/apt/sources.list.d/elastic-7.x.list'

elastic-7.x.list가 생긴 것을 확인할 수 있다.

ElasticSearch 설치

Repository를 등록했으니 이제 apt로 elasticsearch를 설치할 수 있다. 아래의 명령어를 실행해 Elasticsearch를 설치한다.

$ sudo apt update
$ sudo apt install elasticsearch

ElasticSearch 실행

ElasticSearch가 설치가 완료되었으면 실행할 수 있다. 참고로 이 Guide를 따라서 ES를 설치하면 /etc/elasticsearch Directory로 설치가 되었을 것이다.

아래의 명령어로 ES를 실행한다.

$ sudo systemctl start elasticsearch.service

참고로 부팅시 바로 실행하도록 설정할 수도 있다.

$ sudo systemctl enable elasticsearch.service

아래의 명령어로 ES instance의 상태를 확인할 수 있다.

$ sudo systemctl status elasticsearch.service

Service 내리는것은 아래의 명령어

$ sudo systemctl stop elasticsearch.service

Clustering 준비

ElasticSearch는 이미 Local에 설치가 되었다고 가정, ElasticSearch Cluster를 구성하려면 ElasticSearch의 환경설정 파일인 elasticsearch.yml 파일에 수정이 필요하다.

Local에 설치했다면 elasticsearch.yml 파일은 아래의 Directory에서 찾을 수 있다. /etc/elasticsearch

Cluster 설정을 따로 하지 않고 처음 yml 파일을 열면 path, data, path.logs 외에는 모두 주석으로 처리가 되어 있다.

주석을 지우고 바꿔야 할 항목은 아래와 같다.

● cluster.name (String) : 구성하려는 Cluster의 이름이다. Node들을 같은 Cluster에 넣기 위해서는 같은 Cluster name을 써야지 인식할 수 있다.

● node.name (String) : Node의 이름, 당연한 이야기이지만 같은 Cluster 내에 추가할 Node의 이름은 각기 다르게 설정해야 한다.

● node.master (bool) : true 혹은 false 값으로 이 ES instance를 master로 쓸지 아닌지 결정

● node.data (bool) : true 혹은 false 값으로 이 ES instance를 data node로 쓸지 아닌지 결정

● network.host (String) : Default로 ES는 Local에서만 접근이 가능하도록 설정이 되어 있다. 외부에서 접속 가능하도록 만들기 위해서는 network.host 값을 0.0.0.0으로 바꾸어주면 된다.

● discovery.seed_hosts(String List) : ES node가 시작했을 때, Cluster에 구성되기 위해 찾아가는 Host의 주소의 List, IP주소를 직접 입력해도 되고, DNS 주소가 있다면 DNS를 입력해도 된다.

● cluster.initial_master_nodes (String List) : Master Node가 될 수 있는 후보들의 List이다.

Clustering Test

Clustering 과정

2개의 각기 다른 Server를 이용하여 Test를 진행하였다. 위의 Clustering 준비 부분에서 언급한 Parameter들에게 각각 값을 설정해주었다.

Server 1 yml 파일

Server 2 yml 파일

2개의 yml 파일에서 확인할 수 있듯이 cluster의 이름은 ‘test-cluster’로 통일하였고 server 1의 node 이름은 node-1, server 2의 node 이름은 node-2이다.

network.host는 ES Instance가 외부로도 노출될 수 있도록 0.0.0.0으로 설정하였다.

node-1을 Master로 만들 것이기 때문에 node-1의 node.master를 true, node.data를 false로 설정해주었고 node-2는 그 반대로 설정하였다.

Test에서는 server 1의 IP주소는 192.168.156.145이므로 server 2의 discovery.seed_hosts에 이 주소를 추가시켜주었고 server 1의 discovery.seed_hosts는 반대로 server 2의 IP주소인 192.168.156.146을 추가시켜주었다. (host2는 원래 적혀있는 것이라 그냥 두었는데 이 Test에서는 의미가 없다. DNS Resolution 안됨.)

마지막으로 Cluster를 형성했을 때 node-1이 master가 되도록 양쪽 yml 파일 모두 cluster.initial_master_nodes를 [“node-1”]으로 설정해주었다.

참고: 모든 Node의 cluster.initial_master_nodes의 값은 같아야 한다.

yml 파일을 모두 설정을 완료하고 server 1의 ES instance와 server 2의 ES instance를 실행하였음.

Cluster가 구성되었는지 확인하는 방법은 Host에 request를 보내면 된다. Test에서는 Curl을 이용하였다.

먼저 server 2에 있는 node-2에 아래와 같은 Request를 보내보았다.

$ curl http://192.168.156.145:9200/_cluster/health?pretty

Node가 죽어 있다면 아래와 같은 메시지가 뜬다.

curl: (7) Failed to connect to 192.168.156.145 port 9200: Connection refused

Cluster 구성이 되었다면 아래와 같이 node의 개수가 2개인 것을 확인할 수 있을 것이다.

실제로 Master Node가 어떤 것인지 확인하기 위해서는 아래의 명령어를 활용했다.

$ curl http://192.168.156.146:9200/_cat/nodes?v

192.168.156.145의 IP주소를 가진 node-1의 Host가 Master인 것을 확인할 수 있다.

Test Issue

처음 Test를 진행했을 때는 모르고 cluster.initial_master_nodes의 값을 [“node-1”, “node-2”]로 설정해서 node-1, node-2 모두 Master Node가 될 수 있도록 하였다.

그렇게 하니 처음에는 Cluster가 잘 형성되었는데, 어느 순간 연결이 잠시 끊기면 원래의 Cluster로 다시 복구되지 않았다.

그래서 모니터링을 시도해서 변화를 지켜보았고, watch 명령어를 활용해 1초마다 Curl Request를 보내서 응답을 확인하였다.

$ watch -n 1 curl http://192.168.156.145:9200/_cat/nodes?v

Cluster가 잘 구성되어 있는 상태로 Master Node가 있는 Host에 Curl Request를 보내면 Cluster의 Node가 2개로 Clustering 된 것이 확인된다.

참고: Data Node에 Cluster API를 이용한 Request를 보내도 Cluster가 잘 구성되었다면 Master Node로 Routing되기 때문에 Data Node에 Request를 보내도 된다.

시간이 얼마 지나고 Cluster의 연결이 끊겨 Node가 분리되었고 각각의 Node가 각자의 Cluster에서 Master Node가 되었다. 정확히 얘기하면 떨어져 나간 node-2가 새로운 Cluster를 형성한 것이다.

이유를 찾고자 ES의 Log 파일을 뒤져보았다. elasticsearch.yml 파일에 log 파일의 Path가 명시되어 있으니 명시된 Directory로 가면된다. (/var/log/elasticsearch/)

필요한건 Cluster에 관련된 Log이기 때문에 처음에 cluster 이름으로 정했던 test-cluster.log 파일을 뒤져보았다.

아래의 Exception이 난 것을 확인했고..

Caused by: org.elasticsearch.cluster.coordination.CoordinationStateRejectedException: join validation on cluster state with a different cluster uuid LcitTe7KQFCEF8Ww_MuU_g than local cluster uuid sTdyHyX8SFSN5Mr5XH1E0A

이 Exception의 원인을 분석해보았는데 결과는 아래와 같다.

처음 Test에서는 node-1, node-2가 모두 Master Node가 될 수 있게 설정을 해놓았는데, Cluster 구성이 처음에는 잘 되었다가 연결이 어느 순간 끊기면 node-1, node-2가 각각의 Cluster를 새로 생성한다. 그런데 ES에서는 하나의 Cluster에 속해 있던 Datanode가 다른 Cluster로 편입되지 못하게 막아놓았고(Data Loss가 발생할 수 있기 때문에) 그렇기 때문에 각각의 서로 다른 Cluster를 형성해버린 node-1과 node-2가 다시 하나로 Clustering되지 못한 것이다. 이런 현상을 ‘Split Brain’이라고 부르기도 하는 것 같다.

그래서 Test를 node-1이 Master node, node-2가 Data node가 되도록 다시 했다. 제대로 다시 Test하기 위해서는 한가지 작업이 더 필요했는데, 각 Node의 data가 저장된 Directory를 지워서 등록된 Cluster에 대한 정보를 없애는 것이다.

Node의 Data가 저장될 파일 Path는 elasticsearch.yml 파일에서 확인할 수 있다. (/var/lib/elasticsearch)

nodes라는 Directory가 있는 것을 확인할 수 있는데 지운다.

$ sudo rm -rf nodes

읽어주셔서 감사합니다.

공부를 해보면서 Hadoop이라는 단어를 쓸 때 어떤 것을 지칭하는 지 확실히 해야 한다는 것을 느꼈음. 여러 문서를 읽어본 결과, 각각 문서에서 Hadoop이란 단어의 정확한 의미가 각자 다름.

예를들면..

Hadoop이란 단어를

1. Hadoop Ecosystem 전체를 지칭하는 경우
2. HDFS만을 지칭하는 경우
3. HDFS와 MapReduce 같은 분산처리 Framework만 포함하는 경우
4. 그 외

아무튼 Hadoop이란 용어를 쓸 때 헷갈리지 않게 하는 것이 좋을 것으로 보임. 아직 정리가 많이 되지 않아 많은 현재는 많은 내용을 올리지 않았지만 앞으로 Hadoop과 관련된 내용을 올릴 때는 헷갈리지 않게 Hadoop이라고 하면 1번의 의미로 사용하고 Hadoop Component를 지칭할 땐 그냥 그 Component의 이름을 사용할 것임. 예를 들면 HDFS을 지칭할 땐 그냥 HDFS라고 할 예정임.

Map/Reduce

위의 그림에서도 확인했겠지만 Map/Reduce는 Hadoop Ecosystem의 하나의 요소일 뿐 HDFS에 적용되어 있는 기술이 아님.

HDFS에 데이터가 어떻게 저장되는지 정확히 밝혀내지 못해 Map/Reduce가 어디서 사용되는지 헷갈렸는데, 지금까지 여러 문서를 본 결과를 적어보자면

HDFS은 말 그대로 Data를 저장하는 Distributed File System이며, Map/Reduce는 이러한 분산 환경에서의 처리를 수행하는 Framework 혹은 Programming Paradigm라고 할 수 있음.

그래서 잘보니까 ElasticSearch와 Hadoop의 연동을 돕는 ES-for-Hadoop이라는 Library도 ElasticSearch와 HDFS을 직접 연결하는 것이 아니라 HDFS 위에 있는 분산처리 Framework와 연동을 하는 것이었음.

ES-for-Hadoop Library는 Map/Reduce, Apache Spark, Pig, Hive, Storm과 같은 분산처리 Framework와의 연동을 지원함.

사실 이중에서 Map/Reduce는 실시간 데이터 분석 플랫폼을 만드는데는 적합하지 않다고 하는데, 이유는 일단 Map/Reduce를 코드로 구현하여 사용하는 것이 까다롭다고 함. 게다가 Map/Reduce는 Disk I/O 기반이라 느릴 수 밖에 없음.

그리고 ES-For-Hadoop의 사용사례를 검색해봐도 Map/Reduce를 사용한 사례는 거의 보지 못했고 Apache Spark가 가장 많이 보였음.

Lucene index는 여러개의 Segment로 이루어져있다고 하는데 실제로 File을 들여다보면 위와 같이 정리할 수 있음. (_X.에서 X는 Segment의 이름이다.)

왼쪽부터 시작하면 Lucene index는 실제로 여러 개의 Segment를 가질 수 있음. 그리고 Segment 외에도 존재하는 Segment들을 Referencing하기 위한 Segments_ file, Segments.gen file 그리고 여러개의 IndexWriter(Lucene 내에서 Index를 생성해주는 Class)가 Segment를 쓰는 것을 방지하기 위한 write.lock file이 있음.

Segment로 넘어가면, Segment는 실제로 하나의 file이 아니고 여러 개의 file로 이루어져있음. 그런데 Lucene에서는 Segment를 이루는 file들을 저장할 때 2가지 옵션을 제공하는데 하나는 Multifile 방식, 다른 하나는 Compound 방식임.

참고로 두가지 방식 모두가 갖는 File들도 존재함 _X.si file의 확장자 si는 Segment information을 나타내며, Segment의 Metadata()를 저장하고 있음. XD.del file은 Segment에서 삭제된 Document들에 대한 정보를 저장함.

Multifile 방식

다시 넘어가면, Multifile 방식은 이름 그대로 Segment를 저장할 때 여러개의 file을 쓰는 방식임. Index에는 Term vector, inverted index, stored field 등에 대한 정보가 들어가야 하는데, 이를 각 항목별로 file을 만들어 Segment를 저장하는 것임.

아래는 Multifile 방식을 사용할 때, 생성되는 File들의 목록임. 원리를 참고한 책은 Lucene 3.x 버전인데 2021년 최신 버전은 8.x 버전이라서 기본적인 원리는 책을 참고했고 Release note를 확인해서 바뀐 것이나 추가된 것도 명시하였음.

참고 Stored field는 Document를 indexing할 때 segment내에 저장된 field와 그에 따른 value. ES나 Solr 모두 Lucene을 사용하기 때문에 ES나 Solr을 이용해서 Indexing하고 Indexing된 Document를 다시 받아올 때 원본 Document를 받아오는 것이 아니라 Segment 내의 Stored field를 받아오는 것임. 물론 url 정보를 stored field로 하여 url을 받아온 뒤에 원본에 접근할 수도 있음.

위의 그림은 Lucene in action이라는 책에서 가져온 이미지, .frq, .prx file은 현재 버전에서는 각각 .doc, .pos file로 변경되었음.

Compound 방식

Multifile 방식은 Segment를 생성할 때, File을 너무 많이 생성한다는 단점이 있음. File의 수가 많아지면 그만큼 더 많은 Open File을 관리해야하는데 현대 OS에서는 Open File의 개수가 제한되어 있음. 그렇기 때문에 Multifile 방식을 계속 사용하다보면 갑자기 “Too many open files” IOException이 뜰 수가 있음. (특히 Segment Merging시에 하나의 Segment만 쓰는 것이 아니라 여러 개의 Segment를 사용하여 File Descriptor를 더 많이 소비함)

그래서 Multifile 방식은 잘쓰지 않고 Default로 설정된 방식 역시 Compound 방식임. Compound 방식은 위의 표에서 나타나 있는 _X.fnm, _X.fdx.. 등등의 파일을 모두 _X.cfs, _X.cfe 파일에 저장함.