10월까지 클라우드 네이티브 데이터 플랫폼을 구축하는 프로젝트에 참여하게 됐다. 어제 저녁 8시 쯤에 첫 모임을 했고 10시가 되어가는 시간에 마쳤다. 자기소개도 하고, 앞으로의 일정도 세우고, 프로젝트 관련 기술 세미나도 한 의미있는 시간이었다. 2시간이라고 믿을 수 없을 정도로 많은 것을 배우고, 설레었다. 분명 몸은 피곤했는데, 정신만은 그 어느때보다 맑았다.
첫 모임은 아이스브레이킹 - 진행 계획 수립 - 기술 세미나 순으로 진행 됐다. 옛날부터 데이터를 좋아해서 하둡 에코시스템 책도 읽고 관련 공부도 했지만, 여러모로 의문도 많았고 헷갈리는 부분도 많았다. 그런 애매한 부분이 예상치못하게 어제 두시간의 세미나에서 완전히 풀렸다. 앞으로 IT 세미나나 강연에 열정적으로 참여해야겠다고 생각하게 되는 시간이었다.
기술에 대한 고유 명사와 보통 명사(Object Storage; 객체 스토리지)
"Object Storage에서 Object는 어떤 의미일까요?"
하둡이라는 개념에 접근하기 위한 질문이었다. 요즘 클라우드에서는 다 객체 스토리지라고 하는데, 여기서 이 객체는 무슨 의미일까? 왜 객체 스토리지라고 할까?
나는 Object Oriented Program이 프로그래밍을 할 때 현실 세계의 개념을 객체로 추상화해서 사용하는 것처럼, 스토리지도 파일을 객체 단위로 다뤄서 Object Storage라고 하는 것 같다고 했다.
여기까지는 맞았다. 그러면 객체 단위로 다룬다는게 무슨 말일까? 답을 하지 못하고 있으니 멘토님이 힌트를 주셨다.
3GB를 저장할 수 있는 저장소가 두개 있어요. 4GB 파일을 어떻게 저장해야 할까요?
처음에 다른 분이 압축을 해서 저장하면 된다고 하셨다. 간단하고도 합리적이다. 하지만 그러면 이 객체라는 개념에 접근하지 못한다. 그래서 압축이 최대한으로 된 상태라는 조건을 추가하셨다. 나는 파일을 논리적인 단위로 나누어서 저장한다고 했다. 정답이었다.
이 나누어진 단위를 객체라고 부른다고 한다. 즉, 객체 스토리지에서의 '객체'는 파일(데이터)을 논리적으로 나눈 단위이다. 객체 스토리지는 원본 데이터를 조각내어 객체 단위로 관리하고, 이 객체에는 메타 정보가 포함되어 있다.
객체 지향 프로그래밍이나 객체 스토리지나 똑같은 '객체'라는 명사를 사용하지만, 그 둘의 의미는 다르다. 똑같은 의미로 생각하고 공부하면 그 기술을 이해하는 첫 단추를 잘못 끼우게 된다. 그러니 기술을 공부할 때는 보통 명사와 고유 명사를 명확히 구분해서 그 의미를 이해하자는 것이 결론이었다.
보통 명사/고유명사
1. 보통명사(common nouns)는 일반적인 사물의 이름을 가리킨다.
예) 하늘, 나무, 사랑, 희망 등.
2. 고유명사(Proper nouns)는 특정한 사람이나 사물의 이름을 가리킨다. 보통 인명, 지명, 천체의 이름, 군대의 이름, 신문 이름 등에 많이 쓰인다.
예) 안창호, 금강산, 신라, 한강, 독도 등.
출처: 한국 위키피디아 명사(품사) - 링크
그래서 이제 객체가 뭔지 알겠고, 객체 스토리지가 뭔지 알겠는데 왜 객체 스토리지를 사용하는 걸까? GCP에서 이와 관련한 글을 매우 잘 정리해뒀다.
오늘날 조직들은 전례 없이 많은 양의 데이터를 비용 효율적으로 저장하는 데 어려움을 겪고 있습니다. 대부분의 데이터는 구조화되지 않았으며 기존 데이터베이스에 저장하기에 적합하지 않습니다. 이메일, 동영상, 사진, 웹페이지, 오디오 파일, 센서 데이터, 기타 유형의 웹 콘텐츠는 모두 구조화되어 있지 않기 때문에 효율적이고 경제적인 관리 방법을 찾는 것이 문제가 되었습니다. Google Cloud 객체 스토리지는 이 문제에 대한 해결책으로 점점 더 주목받고 있습니다.
객체 스토리지는 계층적 파일 시스템의 걸림돌인 복잡성, 확장성, 비용 문제를 해결해 줍니다.
객체 스토리지는 구조화되지 않은 데이터의 대량 저장을 위한 데이터 스토리지 아키텍처로서, 각 데이터 조각을 하나의 객체로 개별 저장소에 보관하며 메타데이터와 고유 식별자를 함께 저장하므로 데이터 액세스와 검색이 용이합니다.
출처: GCP 객체 스토리지란? - 링크
파일의 유형과 관계없이 효율적이고 경제적인 방법으로 파일을 저장하고 관리할 수 있어서 사용한다. 객체 스토리지의 강점은 확장성이다. 필요 용량에 따라 규모를 늘려도 성능이 저하되지 않는다.
하둡 자체적으로 오브젝트 스토리지 사용을 지원하는 쪽으로 개선되고 있다. 하둡파일시스템(HDFS)이 아마존 S3 인터페이스를 제공하는 등 외부 연동 요구를 수용했다.
오브젝트 스토리지는 기본적으로 대규모 파일 저장용 스토리지다. 파일을 디렉토리로 관리하지 않고, 메타데이터를 활용해 관리한다.
파일시스템에 기반한 NAS는 디렉토리로 파일을 저장하는데, 파일 개수가 수억, 수십억개로 늘어나면서 성능 저하 이슈가 발생한다. 디렉토리 깊이가 깊거나, 파일 개수가 많아지면 쉽게 찾고 삭제하기 힘들다.
반면 오브젝트 스토리지는 개별 파일을 평면에 쫙 뿌려놓듯이 관리한다. 대신 개별 파일마다 유일무이한 인덱스 데이터를 갖고 해당하는 파일을 찾아낸다.
출처: 하둡의 빈틈 '오브젝트 스토리지'가 노린다 - 링크
클라우드 엔지니어의 능력을 판가름 하는 것이 얼마나 클라우드에 들어가는 돈을 줄이냐인 만큼 객체 스토리지의 부상은 필연적인게 아니었을까.
왜 하둡의 첫 번째 프로그래밍은 Word Count인가?
위에서 대용량의 파일을 객체로 나누어서 저장하고 관리하고, 그 장점이 싸고 빠르다는 것이라고 했다. 그것처럼 하둡은 이미 파일이 나누어져 저장되어 있기때문에 병렬 처리를 하기 위해 파일을 나눌 필요가 없다. 그게 장점이다.
하둡의 핵심 기술은 HDFS(Hadoop Distributed File System; 하둡 분산 파일 시스템 - 블록 구조의 파일 시스템)과 MapReduce(분산 처리 기술)다. 이를 사용해서 한번에 여러 디스크에서부터 데이터를 읽을 수 있다.
이런 하둡의 핵심 개념을 이해할 수 있도록 하는 문제가 Word Count다. 맵 리듀스, Word Count를 검색하면 나오는 그림이다.
이게 초면에는 낯설지만 검색 엔진을 생각해보면 쉽게 이해할 수 있다.
| index | content |
| 0 | 요즘 날씨가 왜 이럴까 |
| 1 | 날씨가 좋은 날에는 기분이 좋다 |
| 2 | 오늘 저녁은 뭐 먹을지 고민된다 |
| 3 | 오늘은 집에 가면 저녁 시간이다. |
검색 엔진이 웹에 있는 데이터를 크롤링 해왔고, 인덱스와 콘텐츠가 이렇게 있다고 해보자. 간단하게 이해하기 위해서 핵심 키워드만 뽑아서 계산한다고 생각해보자.
(0, 요즘)
(0, 날씨) (1, 날씨)
(1, 기분)
(2, 오늘) (3, 오늘)
(2, 저녁) (3, 저녁)
(2, 고민)
(3, 집)
(3, 시간)
이 상황에서 '오늘'을 검색하면 2번 글과 3번 글이 나올거고, 고민을 검색하면 2번 글이 나오게 된다. 그러면 '오늘 저녁'을 검색하면 어떤 결과가 나올까? 어떻게 검색해야 할까?
오늘 검색 결과와 저녁 검색 결과를 AND 연산(교집합) 하면 될 것 같다. 근데 그게 정말 '오늘 저녁'인지 '오늘은 배가 고파서 저녁을 ~'인지, 검색어와의 연관성이 얼마나 높은지 어떻게 계산을 할까? 위치 연산을 한다. '오늘'과 '저녁'의 위치를 뺀 값이 1이 나오면 붙어있다는걸 알 수있고, -1가 나오면 역배열이라는 것, 절대값이 커질 수록 점점 멀어진다는 것도 알 수있다.
이런 걸 만들 때 고려 사항이 뭘까? 백대의 서버가 있다고 할 때 처리 속도를 늦추는 가장 큰 원인이 네트워크라고 한다. 그래서 데이터가 있는 곳에 프로그램을 보내서, 거기서 처리를 하면 네트워크 IO가 발생하지 않게 되서 처리 속도가 매우 빨라지게 된다. 이런 컨셉을 가진 것이 Hadoop이다.
위의 예제를 맵-리듀스 과정에 매칭시켜보면
[맵]
(0, 요즘) (0, 날씨)
(1, 날씨)
(1, 기분)
(2, 오늘) (2, 저녁) (2, 고민)
(3, 오늘) (3, 집) (3, 저녁) (3, 시간)
[셔플]
(1, 요즘)
(1, 1, 날씨)
(1, 기분)
(1, 1, 오늘)
(1, 1, 저녁)
(1, 고민)
(1, 집)
(1, 시간)
[리듀스]
(1, 요즘)
(2, 날씨)
(1, 기분)
(2, 오늘)
(2, 저녁)
(1, 고민)
(1, 집)
(1, 시간)
[최종 결과]
(1, 요즘)
(2, 날씨)
(1, 기분)
(2, 오늘)
(2, 저녁)
(1, 고민)
(1, 집)
(1, 시간)
이렇게 된다.
그 외...
이걸 듣다가 궁금한 점이 생겨서 질문했다. RDB를 공부하다보면 인덱싱을 할 때 우선 맵이라는 개념에서 접근을 시작하지만, >, >=, <, <=와 같은 연산을 하기 위해서 결국에는 레드-블랙 트리를 사용하는 걸로 결론이 나는데, 왜 하둡에서는 이 맵을 사용하는 걸까? 얘도 크거나 작다라는 연산을 하지 않나? 라고 생각해서 멘토님에게 질문했다. 답변은 아래와 같다.
관계형 데이터베이스 같은 경우에는 풀 테이블 스캔을 하면 안된다. 인덱스를 해서 최소한의 데이터를 보고, 최소한의 데이터만 가지고 나오는게 미덕이다.
하둡은 그렇지 않고 무조건 풀 테이블 스캔을 하게 되어있다. 특정 컬럼이 무엇인 것들만 고르라고 하면, 아닌 것들은 리턴하지 않고 그런 것들만 리턴한다. >, <와 같은 연산도 이런 로직을 사용한다. 결과적으로 범용적으로 하는 용도가 아니라, 검색 엔진에 특화된게 하둡의 MapReduce였다.
그런데 그거를 일반적인 빅데이터 처리에 다 적용을 하다가 너무 어렵기도 하고(본래의 용도가 아니니), 내고장성같은 것들 때문에 MapReduce을 보조하는 기술들이 계속 나오면서 경우에 따라 다른 기술을 사용하게 됐다.(하둡 에코시스템이 점점 커지는 이유)
그래서 이런 단점을 보완하는 것이 Spark다. Spark는 검색엔진에 특화된 Hadoop을 대비해서 범용적인 용도로 사용할 수 있게 하고, 속도나 성능을 향상시켰다.(그래서 우리 팀은 스파크를 사용해서 프로젝트를 진행하기로 했다)
최근까지도, 앞으로도 한동안은 하둡이 온프레미스에서 가장 안전하고 저렴한 데이터 레이크 구축을 위한 파일 시스템이다. 하지만 앞으로 클라우드 환경에서는 저장소로 하둡이 아닌 오브젝트 스토리지로 전환되고 있고, 리소스 관리는 쿠버네티스로, 병렬 처리는 Spark로 변경될 거라고 한다.
주제 구상
이제 다음 모임인 금요일까지 주제를 구상해가야 한다. 나는 기존에 관심을 가지고 있던 금융 관련 주제를 생각했다. 실시간으로 데이터를 처리하는 기술을 사용할 수 있도록ㅋㅋㅋ 실시간으로 데이터가 쏟아져야 하니 금융쪽이 제일 좋을 것 같았다.
프로젝트 제안서 작성
주제를 제안하기 위해 필요한 내용을 생각해보니 위와 같은 형식이 나왔다. 프로젝트를 통해 개발하고 싶은 서비스와, 그와 유사한 서비스, 사용하게 될 기술, 데이터 파이프라인, 처리 방식, 역할 분담 정도가 기술적으로 꼭 필요한 내용일 것 같다. 그리고 앞으로 팀원들과 프로젝트를 진행할 수 있는 환경과 여건이 어떻게 되는지, 예산은 어느정도까지 사용할 수 있을지를 고민해봐야겠다.
