헤링의 일상

2023.11.14 - 부동산 주요 지표

Paulss — Tue, 14 Nov 2023 21:52:00 +0900

한국부동산원 https://www.reb.or.kr/r-one/cm/cntnts/cntntsView.do?mi=10116&cntntsId=1407

KB부동산 https://data.kbland.kr/kbstats/wmh?tIdx=HT11&tsIdx=hai

주택구매력지수(HAI) = (중위가구소득 ÷ 대출 상환 가능 소득) ×100 HAI가 100보다 클수록 큰 무리 없이 주택을 구입할 수 있다는 것을 나타내며, HAI가 상승하면 중위가구의 주택 구매력이 증가한다는 것을 의미합니다.

낙찰가율(매각가율) = (매각가/감정가)*100 낙찰가율은 매각가율과 같은 뜻이며 법원 경매 통계자료에서는 매각가율이라는 단어를 사용하고 있다.

부동산 시장 전망의 대표적인 선행지표. 낙찰가율이 100%를 넘어서면 미래의 부동산 시장을 긍정적으로 전망하고 있다는 뜻이다. 반대로 낙찰가율이 100% 아래로 떨어지면 부동산 시장을 부정적으로 전망하고 있다는 뜻이다.

낙찰률(매각률) = (매각건수/경매건수)*100

통계정보 확인 (서울남부지방법원 기준)

'22.11~23.10	ㅌ
'21.11~22.10
'20.11~21.10
'19.11~20.10
'18.11~19.10	~
17.11~18.10

[HADOOP] HDFS 아카이브 (HAR)

Paulss — Tue, 19 Jan 2021 22:15:18 +0900

개요

Hadoop에서는 과거 버전부터 Hadoop Archive(이하 HAR) 기능을 제공한다. 이는 우리가 일반적으로 사용하는 파일의 압축과 비슷한 개념인데, 우리가 일반적으로 파일시스템에서 압축(archive)를 하는 이유는 (1)여러개의 파일을 하나의 묶음으로 관리하기 위해서나, (2)다양한 압축 방법을 통해 파일의 용량을 줄이기 위함이다.

그러나 HDFS에서 아카이브는 HDFS 상에 있는 다수의 파일을 더 적은 수의 파일로 관리하기 위한 목적이다. 이는 HDFS의 구조적인 한계에서부터 비롯된 것인데, HDFS 상에서 관리될 수 있는 최대 파일의 개수가 약 3억 5천만개이기 때문이다. 따라서 HDFS 상에서 파일의 개수를 줄일 수 있는 방법이 고안되어야 했고 이것이 바로 HAR이다.

사용법

압축

hadoop archive -archiveName <NAME>.har -p <parent path> [-r <replication factor>]<src> <dest>

추가로 사용할 만한 options
-Dhar.partfile.size
-Dmapred.queue.name

압축해제

hdfs dfs -cp har://<harfile-path> hdfs://<dest> -- 순차작업
hadoop distcp har://<harfile-path> hdfs://<dest> -- 병렬작업

예제

예제1

hadoop archive -archiveName 10.82.49.65_logs_2018.har -p /interface/weblog/10.82.49.65/2018 /archive/weblog

위 예제는 가상의 webserver 10.82.49.65의 로그가 /interface/weblog/10.82.49.65 하위에 저장된다고 가정하고, 2018년의 모든 로그를 아카이브 하는 것이다. 압축대상은 /inerface/weblog/10.82.49.65/2018 하위의 모든 파일들이 해당되며, 아카이브에 대한 결과로 /archive/weblog/10.82.49.65_logs_2018.har 파일이 생긴다.

아래와 같이 실제로 아카이브된 파일을 확인할 수 있다.

hdfs dfs -ls /archive/weblog/10.82.49.65_logs_2018.har

/archive/weblog/10.82.49.65_logs_2018.har/_SUCCESS
/archive/weblog/10.82.49.65_logs_2018.har/_index
/archive/weblog/10.82.49.65_logs_2018.har/_masterindex
/archive/weblog/10.82.49.65_logs_2018.har/part-0
/archive/weblog/10.82.49.65_logs_2018.har/part-1
/archive/weblog/10.82.49.65_logs_2018.har/part-2
...

_SUCCESS 는 단순히 작업에 대한 결과를 나타내며, _index와 _masterindex는 압축 이전의 파일 시스템의 경로값과 압축 데이터 간의 맵핑정보를 가지고 있다. 당연한 이야기겠지만 어떠한 데이터라도 유실되면 기존의 파일들을 복구할 수 없다.

만약에 실제로 압축된 원본의 파일목록을 보고 싶을때는 아래와 같이 조회할 수 있다.

hdfs dfs -ls har:///archive/weblog/10.82.49.65_logs_2018.har

예제2

만약에 다수의 폴더/파일을 지정하고자 할때는 아래와 같이 소스 경로를 입력하면 된다.

hadoop archive -archiveName 10.82.49.65_logs_2018-20.har -p /interface/weblog/10.82.49.65 2018 2019 2020 /archive/weblog

위에서는 예제1과 다르게 /interface/weblog/10.82.49.65 하위의 2018, 2019, 2020 폴더 모두를 아카이브하여 /archive/weblog/10.82.49.65_logs_2018-20.har 로 저장한다.

예제3

위에 예제에서 만들어진 part-0, part-2 파일들은 기본적으로 2GB 단위로 생성이 된다. 이는 HadoopArchives.java 소스를 확인해 보면 partSize가 2 * 1024 * 1024 * 1024l 로 설정되어 있기 때문에 옵션을 통해 변경할 수 있다. 이 값이 중요한 또 다른 이유는 이 값을 기반으로 mapreduce 작업의 mapper 개수를 설정하기 때문이다. mapper의 개수는 아카이브 하고자하는 전체 파일 크기를 partSize로 나눈 수로 설정한다(totalSize/partSize). 아래와 같이 partSize를 설정할 수 있다.

hardoop archive -archiveName 10.82.49.65_logs_2018.har -p interface/weblog/10.82.49.65/2018 archive/weblog -Dhar.partfile.size=104857600

위의 예제는 예제1과 내용이 동일하나 뒤에 -Dhar.partfile.size=104857600(100MB)로 설정하여 partSize를 2GB에서 100MB로 줄였다. 이렇게 설정하게 되면 더 많은 mapper를 사용할 것이기 때문에 아카이브 작업이 더 빠르게 수행될 것이지만 결과적으로 더 많은 파일이 생성될 것이기 때문에 아카이브로 인한 파일 감소 효과는 줄어들 것이다. 따라서 각 환경에 맞게 설정해야 한다.

하둡 federation과 같이 하둡 아카이브(HAR)는 HDFS의 구조상의 한계를 극복하기 위한 방법으로 유용하게 사용될 수 있다. HAR는 특히 작은 용량을 가지고 있는 다수의 파일을 큰 하나의 파일로 구성하기 좋다. 다만, 아카이브의 목적이 우리가 흔히 생각하는 압축과는 다르게 파일의 용량을 줄이기 위한 점이 아니라는 것을 알고 있어야 한다. 만약 저장 용량의 부족이 발생하는 경우 오래된 데이터에 대한 Erasure coding 적용 또는 replica factor 변경을 검토해야 한다.

참고 : hadoop/HadoopArchives.java at trunk · apache/hadoop · GitHub

apache/hadoop

Apache Hadoop. Contribute to apache/hadoop development by creating an account on GitHub.

github.com

[책리뷰]1등의 습관, 일로 부터 나를 지키기 위한 방법

Paulss — Sun, 10 Jan 2021 02:23:11 +0900

집 앞에 집 앞에 상권이 살아나면서 대형 중고서점이 들어섰다. 코로나가 심해지기 전에는 그곳에서 노트북을 펴 놓고 책을 읽기도 하였는데 사회적 거리두기로 인해 노트북과 책을 기대 놓았던 책상은 여러가지 굿즈를 펼쳐 놓는 진열대로 변신했다. 코로나로 인한 우울증에 더해 2020년은 내겐 고난의 연속이었다. 가까스로 사용한 연차를 활용해 답답한 마음을 달래기 위해 중고서점 한 구석에 앉아 책을 읽기 시작했다.

이틀간의 기웃거림 끝에 "1등의 습관" 이라는 노란 책을 집어 들었다. 서점의 스테디 셀러로 분류된 진열대에 놓여 있던 노란 책인데, 개인적인 생각으로는 책 제목이 꽤나 재수없는 반열에 올라있기 있었기 때문에 몇번이고 지나쳤던 책이었다. 이러한 책에 대한 편견이 나쁘다는 것을 다시 한번 깨달았지만, 그러한 편협함을 만들어준 것도 비슷한 부류의 책이었기에 그런 생각을 하지 않았나 싶다.

저자인 '찰스 두히그'는 습관의 힘이라는 책으로 이미 유명인 반열에 오른 작가였다. 그는 자신이 이야기하고자 하는 것을 다양한 사례를 통해 전달하는 것에 능통한데, 이 책에서도 자신의 장점을 적극 활용하였다. 이러한 사례는 꽤나 극적인 영화를 보거나, 스포츠 뉴스를 보는 것 같이 꽤나 자극을 주었다. 이 책에서 잘못된 것은 "1등의 습관" 이라는 책 제목 뿐이라고 생각한다.

자기방어일 수도 있지만 나이가 들면서 점점 1등과는 멀어지는 삶을 사는 것 같다. 어렸을 때는 무엇이든 될 수 있다는 생각과 내가 제일이라는 생각을 가지고 살았던것 같은데, 사회를 나와 여러 사람들과 불가피한 경쟁을 펼치면서 자의식에서도 절대적으로도 1등과는 멀어졌다. 그리고 정서적으로도 1등이 주는 긍정적인 점보다 그것을 이루기 위해 포기해야 하는 이면에 더 집중하게 되었다.

이런 나였기에 "1등의 습관"은 꽤나 거슬리는 책의 제목이였다. 그래서 이 책을 잡았을때는 눈에 닿았던 거의 모든 책들을 손에 쥐었다 놓은 뒤였다. 하지만 목차를 한번, 책의 내용을 한번 보고난 뒤 별 다른 생각 없이 계산대로 향했다.

이 책 뒤에는 "끝도 없이 쏟아지는 일로부터 나를 지키고 더 놀라운 성공을 이루기 위해 꼭 알아야 할 8가지의 자기혁명" 이라는 구문이 써있다. 이 책을 골랐던.. 그리고 다 읽고 느끼는 내 감상은 여기에 있다. '끝도 없이 쏟아지는 일로부터 나를 지키고'. 그 방법을 알려주는 책이라고 생각한다.

이 책에는 여덟가지의 생각하는 방법이 있다. 길을 잃거나 어떻게 해야 할지 모르는 어른을 위해, 다양한 사례를 들어 조언을 해주고 있다.

의욕을 잃어버린 사람들에게, 최고의 팀에서 일 하고 싶은 사람들에게, 늘 시간에 쫓기는 사람들에게, 실행을 잘 못하는 사람들에게, 조직에서 내 사람을 만들고 싶은 사람들에게, 불확실한 미래 때문에 불안한 사람들에게, 창의성이 부족하다고 느끼는 사람들에게, 정보를 어떻게 활용할지 모르는 사람들에게

만병통치약이 없듯이 모든 사람들에게 8가지 모두가 와닿지 않을 수 있다. 나 또한 그랬다. 하지만 자신의 마음에 공허함을 채울 수 있는 하나의 퍼즐을 찾을 수 있을 것이란 생각이 든다. 이 책을 일에 지친 어린 어른들에게 추천한다. 지금의 당신의 아픔과 방황은 그대의 잘못이 아니다. 이 책을 읽고, 아니면 다른 무엇이든 지금 느끼는 불안과 답답함을 벗어날 수 있기를 바란다.

[NiFi] FlowFile 이란? - 어떻게 memory/disk 에서 처리되는가?

Paulss — Sun, 11 Oct 2020 02:15:46 +0900

FlowFile은 NiFi에서 처리되는 기본적인 단위이다. FlowFile은 처리하고자 하는 데이터와 그 데이터를 처리할 때 필요한 속성 값을 가리키고 있다. FlowFile은 실제 데이이것은 데이터와 속성 값을 가지고 있으며, NiFi Processor에서 데이터 처리를 위해서 사용한다.

FlowFile의 구성 요소

Processor 에서 생성/수정하는 FlowFile들은 Processor가 어떻게 FlowFile을 처리하냐에 따라서 properties와 event에 대한 정보가 달라진다. 또한 FlowFile의 처리를 위해 반드시 필요한 property 값들도 있기 때문에 flow를 구성할 때 서로 호환되는 process간에 연결을 하거나, 각 processor에 맞는 값들을 맞춰주기 위한 작업을 별도로 수행해야 한다.

FlowFile이라는 단어가 우리가 일반적으로 생각하는 파일과 같이 disk에 저장되는 것이라고 생각하게 만들지만, 사실 그런 파일이라기 보다 객체에 가까운 의미로 생각된다. FlowFile이 저장되는 주요한 위치는 두 곳인데, WAL(Write-Ahead-Log)가 저장되는 FlowFile Repository와 HashMap 형태로 저장되는 memory영역이다.

Map에 의해서 참조되는 Memory상의 객체들은 flow에서 사용되는 FlowFile(processor에서 사용되는 값과, connection queue에 저장되어 있는)과 같다. FlowFile 객체들은 memory상에 존재하기 때문에 Processor들은 ProcessSession을 통해 connection queue로부터 flow file을 가져와서 처리하게 된다.

FlowFile의 변경이 생기는 경우 변경사항들은 FlowFile Repository의 WAL(write ahead log) 형태로 Disk에 저장되고 memory에 있는 object들은 WAL 이 정상적으로 쓰여진 후에 그 변경사항에 따라서 수정이 된다. 이러한 방법은 시스템이 빠르게 FlowFile들을 처리할 수 있게하면서 변경사항의 이력을 보여주고 commit시에 어떻게 처리될 것인지 추적할 수 있게 된다. 이렇게 WAL파일을 먼저 쓰는 것은 일반적인 DB에서 일관성 및 지속성이 고려되는 시스템에서 일반적으로 적용되는 방법이다.

여기에 추가로 FlowFile 'swapping' 이라는 개념도 존재한다. 이것은 많은 FlowFile들이 connectionQueue에 있을 때 nifi.queue.swap.threshold 값을 넘을때 발생한다. 가장 낮은 우선순위를 갖고 있는 FlowFile들은 직렬화되어서 swap file로 disk에 쓰이게 된다. 10000개 단위로 쓰인다. 이렇게 swap file로 떨어진 FlowFile들은 memory의 hash map에서 제거되고, memory에서 다시 swap 할 FlowFile들의 대기열을 구성한다. FlowFile이 disk로 swap 되면 Flowfile repository에 알림이 전송되고 Swap File 목록이 유지되게 된다. 시스템이 checkpoint 때 snapshot을 생성하면 swap out 된 파일들이 포함하게 된다. swap file들은 다시 swap in 되고 FlowFile들이 hash map 뒤에 붙게 된다. 이러한 swapping 기술로 시스템의 메모리 제한과 관계없이 NiFi는 수백만 개의 FlowFile에 대해서 빠르게 처리할 수 있게 되는 것이다.

이러한 방식으로 FlowFile이 구성되었기 때문에, FlowFile은 중간에 문제가 발생하거나 flow를 재현해야 하는 일이 생기는 경우 flow에 변화가 없다면 재실행 후 동일한 결과를 얻을 수 있다. 그리고 모든 데이터들에 대해서 memory 상에서 유지하고 있지 않기 때문에, 처리 데이터에 대한 OS영역의 리소스 제한에도 잘 동작할 수 있다. (merge 작업 수행 시 많은 FlowFile들의 content를 모두 memory에 올려야 함으로 OS 영역 메모리를 고려해야 한다). 추가적으로 실제 WAL, snapshot, swap file들이 disk 상에 저장되기 때문에 각 repository에 대한 충분한 공간을 확보하는 것이 중요하다.

[NiFi] NiFi는 어떻게 데이터를 저장하나? (NiFi Repository)

Paulss — Wed, 7 Oct 2020 01:28:26 +0900

nifi.apache.org/docs/nifi-docs/html/nifi-in-depth.html#repositories

Apache NiFi In Depth

Utilizing the copy-on-write, pass-by-reference, and immutability concepts in conjunction with the three repositories, NiFi is a fast, efficient, and robust enterprise dataflow platform. This document has covered specific implementations of pluggable interf

nifi.apache.org

NiFi에는 3가지 저장소Repository가 존재한다. 각각의 저장소는 OS/Host 레벨의 파일시스템에 저장이 되고, 특정한 데이터들을 저장하게 된다. FlowFile 에 대한 이해가 바탕이 되어야지만 이러한 저장소들의 역할들에 대해 완벽히 이해할 수 있다.

NiFi Repository 종류

항상 나오는 NiFi 아키텍쳐. 하나의 JVM안에 WebServer, FlowController, Repository가 있다. 각 Repository는 local storage에 저장된다.

1. FlowFile Repository : 현재 Flow 안에 존재하는 FlowFiles들에 대한 메타 정보들을 가지고 있음
2. Content Repository : 현재/과거 FlowFiles 에 대한 데이터(contenets)를 가지고 있음
3. Provenance Repository : FlowFiles들에 대한 이력정보를 가지고 있음

FlowFile Repository

NiFi에서 처리되고 있는 flowfile들은 Hash Map 형태로 JVM 메모리에 존재하게 된다. (nifi.apache.org/docs/nifi-docs/html/nifi-in-depth.html#DeeperView). 메모리에서 처리하는 것은 빠르고 효율적임이지만, 장애 발생 시 데이터에 대한 지속성을 보장하지 않아 데이터 손실을 가져온다. (durability 를 보장할 수 없다). 이러한 문제를 해결하기 위해서 FlowFile Repository는 현재 시스템에서 처리되고 있는 FlowFile의 메타정보/데이터에 대한 WAL(Write-Ahead Log)역할을 수행한다. FlowFile의 메타 정보는 FlowFile과 관련된 모든 속성들을 가지고 있는데, 실제 FlowFile에 데이터의 위치(실제 데이터는 Content Repository에 존재), FlowFile의 상태(어떤 connection/queue에 존재하는지) 등을 포함한다. WAL과 같은 기능을 제공함으로써 FlowFile Repository를 통해 시스템 장애로 인한 지속성을 제공하게 된다.

FlowFile이 NiFi의 여러 Processor를 통해 처리됨에 따라 WAL과 동일하게 변경사항들이 FlowFile Repository에 저장이 되고 트랜잭션이 처리가된다. (WAL 저장 후 트랜잭션 처리, 이슈 발생 시 WAL 을 이용한 데이터 복구 수행). 이렇게 생성되는 로그(WAL)은 변경사항들에 대한 순차적인 모음임으로 NiFi는 이를 통해서 Repository가 check-point 될 때 생성되는 snapshot을 기준으로 로그에 기록된 작업을 수행하여 장애 시점의 FlowFile을 복구할 수 있게된다.

FlowFile Snapshot은 시스템에 의해서 주기적으로 생성되는데 nifi.properteis 파일을 통해서 checkpoint에 대한 설정을 할 수 있다. checkpoint 시점에 시스템은 FlowFile의 HashMap을 직렬화 하여 새로운 생성하는데, 이는 *.partial 확장자를 갖는 파일로 생성된다. checkpoint 작업이 완료되면 오래된 snapshot 파일은 삭제되고 *.partial 파일이 snapshot으로 이름이 변경된다.

Content Repository

Content Repository는 단순하게 시스템에 존재하는 모든 FlowFile들에 대한 데이터(content)를 저장하고 있는 로컬 스토리지라고 생각하면 되는데, 실제 FlowFiles에 대한 데이터를 저장하기 때문에 위에서 언급한 3개의 저장소 중에 가장 큰 저장 공간을 사용하게 된다. 이 저장소는 처리 속도 극대화/thread 처리에 대한 안정성을 위해 불변성immutability과 copy-on-write 패러다임을 사용한다. Content Repository의 핵심 디자인은 Flowfile에 대한 데이터를 disk에 유지하면서 JVM 메모리에서 요청할 때만 read only로 적재하게 된다. 이러한 구조는 처리하고자 하는 object의 크기의 크기와 상관 없이 처리할 수 있게 되는데, 모든 데이터를 memory에 올리기 위한 pub/sub 이 필요하지 않기 때문이다. 결과적으로 매우 큰 object에 대해서 splitting, aggregating, transforming 작업을 수행할 때 메모리 사용량과 무관하게 처리할 수 있게 된다. (대신에 content repository에 대한 disk I/O 성능이 더 중요해질 것으로 생각된다.)

NiFi는 사용하지 않는 FlowFile에 대한 데이터는 GC를 통해 JVM heap에서 제거하는 작업을 수행하며, 이를 위해 별도의 GC collection 프로세스가 존재하며, 사용하지 않는 content를 분석하기 위한 thread가 별도로 존재한다. ( Deeper View: Deletion After Checkpointing" section) 이러한 작업들을 통해 FlowFile의 contents 가 더이상 필요하지 않다고 판단되면 삭제되거나 아카이빙된다. 아카이빙archiving 관련 설정은 nifi.properties에서 활성화 시킬 수 있다. archiving처리된 content는 Content Repository에 정의된 life-cycle(age)만큼 존재하다가 삭제가 되거나, Content Repository가 너무 많은 데이터를 사용하고 있다고 할 때에는 바로 삭제가 될 것이다. ("nifi.content.repository.archive.max.retention.period", "nifi.content.repository.archive.max.usage.percentage")

Provenance Repository

Provenance Repository는 FlowFile에 대한 이력 정보를 위한 저장소이다. 이력정보는 각 데이터에 대한 Data Lineage를 제공하기 위해서 사용된다. FlowFile에 대한 이벤트가 발생할 때마다 새로운 provenance event(기원 이벤트..) 가 생성된다. Provenance event 또한 FlowFile의 특정 시점의 정보를 보여주는 snapshot로 생각할 수도 있다. provenance event가 생성되면 FlowFile의 모든 속성값과 content를 가리키는 포인터, FlowFile의 상태 정보에 대한 집계정보가 Provenance Repository의 하나의 위치에 저장이 된다. 이러한 provenance event(=snapshot)은 변경되지 않으며 nifi.properties 에 명시된 일정이 지난 후에 삭제된다.

FlowFile의 모든 속성들과 content 포인터는 Provenance Repository에 저장되기 때문에 DataFlow Manager는 단순히 lineage를 보는 것이 아니라 데이터에 대한 처리이력을 확인할 수 있다. 이를 통해 특정 시점의 데이터를 확인할 수 있을 뿐 아니라 어떠한 위치에서든 다시 실행할 수 있다. 일반적으로 usecase는 데이터를 전송 받는 시스템(down-stream system)이 데이터를 받지 못한 경우인데, 목적 시스템에 데이터가 전송 될때 정확히 데이터가 어떠한 모습인지 파일이름은 무엇인지, URL은 무엇인지 확인이 가능하다. 또는 전송 이벤트가 다시 실행될 수 있어 목적시스템에서 데이터를 받게 처리할 수 있다. 만약 데이터가 원하는데로 처리되지 않았다면, flow를 수정한 뒤에 다시 데이터를 수정된 flow로 흘리는것도 가능하다.

Provenance Repository를 통해서 특정 시점의 FlowFile의 데이터를 확인 가능하지만, Content Repository에 대한 데이터를 복사하는 것은 아니다. 단지 FlowFile의 content에 대한 포인터를 복사하여 가지고 있는 것이다. 따라서 Provenance event에서 참조값을 가지고 있는 상태에서 content가 삭제될 수도 있다. 이런 경우에는 앞서 말했던 특정 시점의 FlowFile의 데이터를 본다던가 FlowFile을 재처리하는 작업들이 수행 불가능하게된다. 하지만 사용자는 FlowFile에 대한 lineage 자체는 조회가 가능함으로 데이터가 처리된 프로세스들은 확인할 수 있다. 예를들어, 이 경우 사용자는 실제 데이터는 확인하지 못하지만 데이터가 사용한 고유 식별자 및 파일 명과 같은 데이터는 확인할 수 있음으로 그것의 목적 시스템으로의 전송여부를 확인할 수 있다. 또한 다른 FlowFile에 대한 메타 정보는 가지고 있음으로 속성값을 통한 디버깅 작업을 수행할 수도 있다.

참고. Provenance event는 FlowFile의 snapshot과 같은 역할을 하기 때문에 현재 flow에 존재하는 FlowFile에 대한 변경은 provenance event를 나중에 재수행할 때 영향을 끼치게 된다. (FlowFile의 데이터가 같다고 하더라도 flow가 변경되면 당연히 처리 결과가 달라짐을 인지하고 있어야 한다)

대략적인 NiFi에 대한 이해를 돕기 위해 NiFi에 존재하는 저장소를 확인해 보았다. 이를 통해 실제로 FlowFile에 대한 이해가 더 넓어진 것 같은 느낌이 든다. 각 Repository에서 수행되는 NiFi 메커니즘에 대해서 더 깊게 확인해 볼 필요가 있을 것으로 보인다.

[Ozone]Apache Ozone 벤치마킹 자료 (by cloudera)

Paulss — Sun, 26 Apr 2020 23:04:44 +0900

Apache ozone 벤치마킹 자료 (by cloudera)

다양한 산업군의 기업들이 데이터 분석을 통한 높은 수준의 비즈니스 서비스를 제공하기 위해
가지고 있는 모든 데이터를 하나의 저장소에 모으려는 노력을 하고 있다.
(+ 물론 아직까지 남들이 하니까 일단 모으고 보자는 곳들도 존재한다 ~ ___ ~)

일반적으로 주위에서 데이터의 양과 일상적으로 처리해야 할 데이터가 많지 않은 기업들은 CSP의 서비스를 사용하고 있으며, 데이터가 많으며 지속적인 처리작업이 이루어지거나 개인정보 및 국가에서 관리하는 기술 민감정보를 가지고 있는 기업들은 on-premise에 자체적인 data lake를 구축하는 추세이다.

이때 쉽게 그리고 싸게 생각할 수 있는 것이 범용장비 여러대로 구성할 수 있는 하둡 기반의 Data lake 일 것이다. 하둡은 오픈소스 기반이면서 범용적으로 사용하고 이미 전 세계적으로 검증된 아키텍쳐이기 때문에 큰 어려움 없이 도입할 수 있다. 하지만 아래 글과 같이 크기가 작은 파일들을 다수 저장할 때에는 HDFS(Hadoop distribuded File System)의 구조적 한계에 부딪치게 된다.(약 3억5천만개의 파일까지 저장할 수 있다)

이러한 문제로 다수의 하둡 클러스터를 복수개로 구성 (Hadoop federation)할 수 있긴 하지만 관리적인 어려움이 발생하기 때문에 이를 극복하기 위해 object storage 아키텍쳐를 채택한 ozone이라는 프로젝트가 tech preview 상태로 개발중이고 빠른 속도로 진행중이다. 또한 apache ozone을 사용하게 되면 storage 자원과 compute 자원을 나누어 구성할 수 있기 때문에 클라우드 환경(아마도 private cloud)에서 작업 부하에 따라 동적으로 노드 관리를 할 수 있다.

이러한 상황에서 하둡 배포판을 제공하는 세계적인 벤더인 cloudera에서 apache ozone을 기존 HDFS와 비교의 벤치마크 테스트를 진행했기에 그 내용을 짧게 보았다. 테스트의 과정은 매우 험난했을 것으로 보이나(계획, 구성 그리고 최적화가지..) 결과는 생각보다 간단하다. 본문은 아래와 같다

- Apache Hadoop Ozone은 HDFS의 주소체계의 확장성 한계를 극복하기 위해서 고안되었다.
HDFS 같은 경우 작은 파일들이 많이 존재하는 경우 그 파일들을 관리 하기 파일 시스템 오브젝트(meta data, inode 등) 이 비효율적으로 많아짐으로 비효율적이다.

- 지금 기술로 제공되는 하드웨어로 구성된 하둡 클러스터 같은 경우 HDFS는 약 350,000,000 개 정도의 파일과 700,000,000 개의 파일시스템 오브젝트까지 저장할 수 있다.
Ozone의 아키텍쳐는 이러한 제한을 해결하기위해 구상되었다. 이 글은 사실상 HDSF와 Ozone의 아키텍처의 차이에 대해서 이야기 하려는 것이 아닌 성능차이에 대해서 기술한다

- 성능 차이를 확인하기 위해 널리 사용되는 벤치마크 도구인 TPC-DS를 사용한다. 이 도구는 일반적으로 Hadoop 스택(Hive, Tez, Yarn 그리고 Ozone과 비교가 될 HDFS)에서 성능 측정을 위해 사용된다.
현재 많은 산업군에서 compute 자원과 storage 자원을 분리해야 하는 요구사항들이 많이 나오는데 이것은 storage는 상대적으로 고정적이고 compute 자원은 유연하게 사용되기 때문이다.
그렇기 때문에 이 테스트에서는 HDFS datanode의 노드와 Yarn의 NodeManager의 노드를 분리시킨체로 테스트를 진행하였다.

- 이런 노력의 근본적인 목적과 제품 최적화에 대한 추가적인 노력을 통해서 HDFS의 안정성 및 성능 최적화와 비교할 수 있어야 할 것이다.
이것을 위해서 몇 개월동안 커뮤니티에서 수행한 작업들을 제공하려 한다. 현재 CDP에서 ozone은 beta버전으로 릴리즈될 예정이다.

테스트 수행 내역 (Ozone 기반의 hive의 성능이 빠르게 수행됨)

- 아래의 측정값들은 두개의 독립된 데이터셋인 100GB, 1TB에서 수행된 결과로 12개의 지정된 storage와 별도로 구분된 12 개의 compute 노드에서 수행된다. (이 글의 마지막 부분에서 설정 값에 대한 더 상세한 결과를 제공할 예정이다)

- 아래 그림은 전체 99개의 테스트 벤치마크 쿼리의 총 수행시간을 나타내는데, Ozone이 약 3.5% 차이로 두 데이터셋에서 더 좋은 결과를 얻었다.

100GB 데이터셋에 대한 TPC-DS 수행 결과

TPC-DS 쿼리 1번부터 99번까지 수행한 총 시간을 나타낸 것으로 1시간이 좀 안되게 걸린 것으로 보인다.
조금씩 차이가 나는 것은 외부 요인이라고 생각되며 100GB는 큰 차이가 없는 것으로 보인다.

1TB 데이터셋에 대한 TPC-DS 수행 결과

100GB에 비해서 조금 더 비율적으로 많이 차이가 나는 것으로 보인다. 1TB 데이터셋에 대해서 100GB보다 약 3배의 실행 시간이 증가되었다. 마찬가지로 외부요인에 의해서 차이도 달라지는 것으로 보인다.

- 더 자세한 결과를 얻기 위해서 쿼리를 3가지 분류로 구분하였다.
a. Ozone에서 더 빠른 쿼리들
b. HDFS에서 더 빠른 쿼리들(차이 25% 이하)
c. HDFS에서 더 빠른 쿼리들(차이 25% 이상)

TPC-DS 수행 시간 별 쿼리 분류 100GB

대부분의 쿼리가 ozone에서 빠른 결과 값을 얻었다. 2개의 쿼리가 ozone에서 매우 느린 성능 결과를 얻었는데
쿼리의 수행 작업에 따른 분류로 구분을 해주거나 outliers가 어떤 쿼리인지 확인할 수 있으면 더 좋았을텐데 아쉬움이 남는다.

TPC-DS 수행 시간 별 쿼리 분류 1TB

100GB에서 1TB로 데이터가 증가하자 faster가 줄어들고 outlier가 1개 증가하였다. 어떠한 쿼리인지 모르는게 정말 아쉽다.

- 70% 케이스 이상에서 Ozone이 HDFS 보다 더 좋은 성능을 가지고 있다는 것을 나타낸다.
커뮤니티에서 더 안정화 하고 높은 성능을 위해서 노력했지만 이 이상의 성능을 낼 수는 없었다.

- 아래에서는 TPC-DS 쿼리 각각의 성능 차이를 정리한 것이다. 이러한 결과는 연속된 10번의 수행 결과의 평균 값을 노즈값을 제외하고 표준화 한 것이다.

쿼리별 실행시간 분류 100GB

특정 쿼리에서 50% 정도의 실행시간 차이가 있다는 것은 매우 유의미한 결과가 아닌가 싶다.

쿼리별 실행시간 분류 1TB

100GB에 비해서 1TB로 데이터셋이 증가하면서 전체적으로 점들이 HDFS faster 쪽으로 내려왔다. 데이터의 양이 많으면 많을 수록 HDFS가 좋은 성능을 가질 것이라고 예측할 수 있을 것 같다.

결론

- TPC-DS 테스트의 결과로 70% 이상의 쿼리에서 약간 씩 더 빠른 성능을 갖는 것을 알 수 있었다.
여기에는 몇가지 이상치(outliers)들이 발생하였는 이는 병목현상 및 우선순위 문제로 발생한 것들이었다.

- Ozone은 tech preview 상태로 CDP-DC 에서 릴리즈 되었고 지속적인 피드백을 통해서 차세대 빅데이터 분산 스토리지 시스템을 발전시키고 있다. 이전에 언급했던 것처럼 beta release 가 매우 빨리되어야 되며, GA가 빠르게 뒤따라야 할 것이다. 이번 테스트와 같은 결과들이 안정성 및 성능 측면에서 빠른 GA를 현실적으로 만들어 줄 것이다.

테스트 환경

- 28개의 동일한 물리 노드
. 20 core intel Xeon CPU
. 128 GB memory
. 4*2TB 디스크
. 10Gb/s 네트워크
- Centos 7.4
- Cloudera Runtime 7.0.3 (Hadoop3, Hive3, Tez 0.9, 2020년 2월 git master에서 빌드된 버전의 Ozone)
. 4개의 master node (CM, Prometheus, Zookeeper, Yarn, Hive, HDFS, Ozone master)
. 12개의 storage node / 12개의 compute node (3개의 노드가 yarn log로 할당됨)
. SSL/TLS 는 비활성화 되어 있으며, simple authentication이 사용됨
. ozone은 하나의 버켓을 가진 volume을 사용함으로써 HDFS와 유사하게 구성함
. 어떠한 서비스도 HA는 설정하지 않음
- 클러스터의 인터넷 네트워크는 다른 노드들과 공유하여 트래픽이 전체적으로 높았다 낮아졌다 할 수 있음
(그렇기 때문에 10번의 테스트의 결과의 평균값을 구함)
- Hive의 결과 캐쉬 저장(LLAP?)는 비활성화 시킴으로써 모든 데이터는 FileSystem에서 읽어 올 수 있도록 함
- TPC-DS는 다음 repo에서 받아옴(https://github.com/hortonworks/hive-testbench)

전체적으로 Ozone이 HDFS보다 전반적으로 높은 성능을 얻었다는 점에서 유의미한 결과를 얻은 테스트라고 생각한다. 하지만 이 테스트 결과 아티클에서 갖는 아쉬움은 몇가지가 존재한다.

> 첫번째로 어떠한 ozone에서 어떠한 최적화 작업이 이루어졌는지와 HDFS에서 동등한 최적화 작업이 이루어졌는지에 대한 것이다.

> 두번째는 어떠한 쿼리를 수행하였을때 HDFS에서 좋은 성능이 나왔는지, 어떤 쿼리가 ozone에서 성능이 좋아졌는지에 대한 내용이 없다는 것이다.

> 마지막은 만약 storage와 compute 노드가 동일한 노드로 구성되었을때의 성능이 같이 제공되었다면 테스트가 더 완벽했을 것이라고 생각한다. 비록 테스트에 앞서 storage와 compute 노드를 분리하고자 하는 요구사항이 높아진다고 하지만 HDFS 자체가 compute 자원과 storage 자원을 동일한 노드에 구성하도록 설계가 되었기 때문에 ozone이 구성된 노드에 node manager가 같이 있다면 어느정도 성능 향상이 발생하는지도 제시가 되었다면, 각 환경에 맞는 최적화된 아키텍쳐를 설계할 수 있기 때문이다.

결과적으로 매우 재미있고 의미있는 벤치마크 테스트였다. 생각 했던 것 보다 apache ozone이 더 빠르게 GA될 수 있다는 생각과 함께 아직은 도입을 고민해야 할 시기가 아니라는 확신이 들게 되었다.

불러오는 중입니다...

출처 : https://blog.cloudera.com/benchmarking-ozone-clouderas-next-generation-storage-for-cdp/

[PAINT IN ROCK] 3. 또 다른 저항의 음악 Folk (feat. 60년대 미국의 분위기)

Paulss — Mon, 16 Dec 2019 01:08:03 +0900

잠깐 Rock 에서 한 발자국 떨어져 보자. 노래를 반복해서 많이 듣는 것 보다 그 시대 배경을 아는 것이 왜 그들이 그렇게 생각했는지.. 왜 그들이 이런 음악을 만들고 공감했는지 이해할 수 있게 해줄 것이다.

WoodStock Festival 1969

- 60년대 미국 사회는 미국 내외를 가리지 않고 많은 분노와 개혁의 운동이 벌어졌던 시기이다.
냉전, 베트남전쟁, 그리고 흑인과 여성의 인권문제, 정치권의 부패는 사회 내부의 갈등을 크게 고조시켰으며, 청년들은 저항의 대변가로써 운동에 앞섰다. 기존의 기성세대들과 그들의 체제의 반항을 노래하던 록은 이미 여러 아티스트들에 의해서 연주되었으며, 이는 빌 헤일리, 엘비스 프레슬리와 같은 아티스트들을 통해 미국 내 뿐만 아닌 영국에서도 큰 인기를 얻기 시작했다. 이와 함께 평화와 자유를 노래하는 곳에서 항상 연주되던 음악이 있었으니 바로 우리도 잘 알고 있는 folk 음악이다.

https://youtu.be/wxiMrvDbq3s?list=PLfARYCU8pMyZyzkYoY_Q_M0HVArPPaq1Q

(Woody Guthrie - This Land Is Your Land)

- Woody Guthrie 는 Bob Dylan과 같은 많은 folk 가수들에게 영향을 끼친 인물로, 그가 노래한 평화와 자유는 뉴욕의 Greenwich village를 중심으로 많은 음악가들에게 영향을 주었다.

https://youtu.be/Ld6fAO4idaI

(Peter, Paul and Mary - Blowing in the Wind) Bab Dylan의 곡을 Peter, Paul and Mary 가 불렀다.

- 1980년대 한국, 가까이는 2010년대 한국과 마찬가지로 1960년대 미국은 사회적 부도덕성, 불평등을 해결하기 위한 집회가 많이 열렀다. 아침이슬을 비롯하여 많은 folk음악들이 금지되었던 시기가 있었는데(지금도 왜 그런지는 크게 이해가 가지 않지만) 이는 미국의 folk음악을 100% 고려하지 않은것이라고는 할 수 없을 것이다. 하지만 정치적 성격을 띄는 Pete Seeger, Joan Baez 와 같은 음악가도 있었으나 Woody Guthrie 나 Bob Dylan과 같은 뮤지션은 보편적인 평화와 평등에 대해서 이야기 하였다. 이러한 사회적 분위기나 사상이 1960년대 Rock음악에도 영향을 끼쳤으며 개인적인 쾌락을 추구했던 1950년대의 Rock에서 벗어나 사회의 문제점을 지적하고 자유와 평화를 노래하게 되었다는 점에서 큰 의미가 있다.

https://youtu.be/1iHhWh9FtsQ?list=PLI-YryTGTh122nzF9addam3-QpIkVfgUT

(Bob Dylan - Don't Think Twice, It's All Right)

https://youtu.be/rm9coqlk8fY

(Bob Dylan - Knockin' On Heaven's Door)

https://youtu.be/IwOfCgkyEj0

(Bob Dylan - Like a Rolling Stone)

https://youtu.be/M_Ld8JGv56E

(Pete Seeger - We Shall Overcome)

https://youtu.be/j1zBEWyBJb0

(Joan Baez - Donna, Donna)

https://youtu.be/-4UoJ47SzjA

(Joan Baez - Forever Young)

[PAINT IN ROCK] 2. 초기 Rockin'Roll 시대의 제왕 Elvis Presley

Paulss — Sun, 8 Dec 2019 23:55:23 +0900

이제 본격적으로 Rockin'Roll의 시대가 시작된다. 우리가 익숙한 음악이 갑자기 나와서 반가울 수도 있다. 책의 일부분만 다루었음으로 더 자세한 부분은 'PAINT IN ROCK' 본문의 익살스러운 그림과 함께 보는 것을 추천한다.

------

- 흑인의 음악을 따라하는 백인들의 음악이 대중들의 관심과 사랑을 받게되자, 미국의 제작자들은 흑인과 같은 목소리를 내는 백인을 찾기 시작한다. 그러던 중 극장안내원과 트럭운전을 하며 돈을 벌던 노래를 곧잘 부르던 청년 Elvis는 어머니를 위한 노래 That's alright(mama) 라는 곡을 녹음하게 되는데, 이것을 계기로 본격적으로 활동하기 시작한다.

https://www.youtube.com/watch?v=NmopYuF4BzY

(Elvis Aron Presley - That's alright mama)

- 첫번째 곡이 발표된 54년에서 2년이 지난 후에야(Elvis도 한순간에 만들어진 것은 아니구나 싶다), 첫번째 레코드를 통해 음반을 발매하였으며 그 노래 모두는 크게 히트하며 단숨에 Elvis를 스타로 올려놓았으며 신화가 시작되었다. 첫 레코드의 Heartbreak Hotel은 싱글 발매 3개월 만에 히트차트 1위에 올랐다. Heartbreak Hotel은 백만장 이상 팔렸고 영국에서도 차트 2위에 오르며 큰 성공을 거두었다. 1956년에 Elvis는 모두 4곡의 넘버 원 히트 싱글을 발표하는데, Heartbreak Hotel, Don't be cruel, Hound dog, Love me tender이다. Elvis Presley는 이전의 락앤롤 가수들과 다르게 젊은이들이 원하는 반항 적인 모습과, 기성세대들이 원하는 부드럽고 젠틀한 모습, 그리고 수 많은 여성들을 초함한 대중들이 원하는 모습을 모두 갖추고 있었다. 결과적으로 Elvis의 인기는 과거 Bill Haley, Chuck berry, 심지어 Frank Sinatra 를 넘어섰다고 보여진다.

https://youtu.be/W4euyTDhFnk

(Elvis Aron Presley - Heatrbreak Hotel)

https://youtu.be/2d5FW0mUPiM

(Elvis Aron Presley - Don't Be Cruel)

https://youtu.be/MMmljYkdr-w

(Elvis Aron Presley - Hound dog)

https://youtu.be/PShNr38e06k

(Elvis Aron Presley - Love Me Tender)

- Elvis 외에도 많은 가수들이 Rockin'Roll을 연주했는데 Elvis와 같은 회사(RCA)소속 이였던 Little Richard 은
중간 중간 샤우팅을 하는 창법을 통해 훗날의 많은 가수들에게 영향을 주었다. 그리고 Buddy Holly도 이 당시 Elvis 못지 않은 인기를 누렸지만 안타까운 비행기사고로 22살의 젊은 나이에 목숨을 잃게 되었다. Buddy Holly가 스타덤에 오르던 시절 Elvis가 군입대를 했기 때문에 Buddy의 인기가 더 대단하게 느껴졌을 수도 있다. 하지만 그가 만약 더 오랫동안 활동 했더라면 rock의 역사는 바뀌었을 것이라고 이야기 된다. 그들의 죽음을 추모하여 Don Mclean이 훗날 Amerian Pie를 불렀다.

https://youtu.be/F13JNjpNW6c

(Little Richard - Tutti Frutti)

https://youtu.be/eq9FCBatl3A

(Buddy Holly - That'll be the Day)

https://youtu.be/OUesbTObC9A?list=TLPQMDgxMjIwMTm6uI4uRidv0g

(Buddy Holly - Puggy Sue)

https://youtu.be/7yHTpGog0IY?list=TLPQMDgxMjIwMTm6uI4uRidv0g

(Don Mclean - American pies)

- 이 외에도 Eddie Cochran, Bince Taylor, Jerry Lee Lewis, Carl Perkins 등이 그 시대를 함께 꽃 피웠다.
다들 크고 작은 사고로 일찍 운명을 한 이도, 말썽을 일으켜 사회적 물의를 일으킨 인물도 있지만
그들이 이 시대에 열정으로 Rock&Roll에 기여했음을 모두 인정하는 부분이다.

https://youtu.be/Qadw2rFiaJc

(Eddie cochran - C'mon everybody)

https://youtu.be/HvNHXbTL7Oc

(Vince Taylor - Brand New Cadillac)

https://youtu.be/xraIf_cYRQE

(Jerry Lee Lewis - Whole Lotta Shakin' Goin' On)

https://youtu.be/mvsYRAc-BWA

(Carl Perkins - Blue Suede Shoes)

[PAINT IN ROCK] 1. Rock&Roll의 시작

Paulss — Thu, 5 Dec 2019 23:24:58 +0900

책의 내용을 일부 발췌하고 사족을 달다보니 남무성 작가님의 의도/내용 전달과 약간 달라지는 부분이 있을 수 있습니다. 가장 좋은 것은 같이 책을 읽는 분들이 함께 글들을 봐주는 것이고, 만약 이 글만을 보시는 분들이라면 감안 하셔서 봐주셨으면 감사하겠습니다.

------

- 재즈의 시작과 마찬가지로 Rock&Roll의 시작 또한 요이 땅! 하며 시작된 것은 아니다. Rock과 Roll이란 단어는 기본적인 영어 단어이면서 음악에서 다양한 의미로 사용되었다. Rock은 흔들리다, 춤추다와 같은 의미로 사용되었으며 Roll은 휘감다와 같은 의미로 사용되었다. 그리고 이 둘은 JAZZ의 어원과 마찬가지로 성관계를 나타내는 육감적이고 자극적인 의미로도 쓰였던것 같다.

- 2차 세계 대전이 끝나고 승전국의 풍요속에서 자라난 베이비붐 세대들은 기성세대의 보수적 가치관에 반발하고
비도덕적이고 자유와 즐거움을 쫓았는데 이들을 일컬어 비트족(beatnik)이라고도 하였다. 50년대의 이런 젊은이들의 문화가 훗날 60년대 히피 문화의 밑거름이 되는 것으로 여겨진다. 백인 중산층 10대들은 이전 세대와 다른 감성을 가지고 있었으며 경제적으로 여유가 있었기 때문에 이들을 타겟으로 한 상품들이 쏟아져 나왔다.

- 흑인들은 2차 세계대전에서 미국을 위해서 큰 헌신을 하였지만 전후 미국 사회에서 지휘는 예전과 다르지 않았다.
많은 연주자들이 술집이나 사교모임에서 연주를 하며 생계를 이어나갔는데, 이 때문에 춤을 출 수 있는 비교적 빠른 리듬의 블루스를 연주했다. 이것은 새로운 형태의 리듬이 강조된 블루스는 R&B(Rhythm&Blues)로 불리기 시작했고, 이러한 음악을 백인들이 따라하게 되면서 인기를 얻기 시작했다. 백인들의 컨츄리송을 바탕으로 빠른 리듬의 블루스가 많은 인기를 끌었는데 대표적인 곡은 Rock Around Clock (Bill Haley&comets) 이다.

https://www.youtube.com/watch?v=ZgdufzXvjqw

- 이와 함께 락앤롤 사운드의 기초를 다진 기타리스트가 있었으니 바로 Chuck berry이다.
오리가 걸어가는 것과 같은 자세(duck tail step)로 기타연주를 하는 모습은 무척이나 우스꽝스러웠지만
비틀즈, 롤링 스톤즈와 같은 많은 60년대 락앤롤 스타들에게 큰 영향을 준 인물이였다.

https://www.youtube.com/watch?v=KGk8UvyjFuw

(Chuck Berry - Maybelline)

https://www.youtube.com/watch?v=kT3kCVFFLNg

(Chuck Berry - Roll Over Beethoven)

(Chuck Berry - Sweet little sixteen) 이 곡은 Surfin USA 라는 이름으로 Beach boys 를 통해 리메이크 된것으로 유명하다.

https://www.youtube.com/watch?v=2s4slliAtQU

이 외에도 롤링 스톤즈, 비틀즈를 비롯하여 많은 팀들이 Chuck berry 의 곡을 많이 연주 하였다.

(Beach boyes - Surfin USA)

- 영화 '백투더퓨쳐Back To The Future'에서 과거로 간 마티 맥플라이(Michael J. Fox 분)이 과거의 학교 축제에서 연주하는 장면으로 유명한데, 멋진 연주 중간에 보다보면 Chuck Berry의 덕테일 스텝을 따라하며 Chuck Berry가 언급되는 유쾌한 상상력도 재미를 더해준다.

https://www.youtube.com/watch?v=S1i5coU-0_Q

Johnny B. Goode - Back to the Future (9/10) Movie CLIP (1985) HD

[PAINT IN ROCK] 0.남무성의 만화로 보는 록의 역사

Paulss — Thu, 5 Dec 2019 23:16:12 +0900

- 최근에 들어 음악을 듣는 폭이 더 넓어졌다. 그래도 꽤 여러 사람들과 만나왔다고 생각했던 나인데
여기 저기서 만나는 사람들과 음악 취향을 나누다 보니 더 열린 마음으로 음악을 접하게 되는 것 같다.

그러던 중 아끼는 사람으로부터 PAINT IN ROCK 을 잠시 빌려주겠다는 제의(?)를 받았고 나는 흔쾌히 수락했다.
JAZZ IT UP을 어렸을 때부터 사 모으던 보았던 남무성님의 팬으로써 상당히 기대가 되었다.

가끔 ROCK과 비틀즈를 듣지만 그들을 잘 알지는 못하고 어떻게 보면 제대로 듣지도 못하고 있다. 책을 접하고 한장 두장 넘겨가며 읽다가 책에 나오는 주요 음악들을 유툽에서 찾아 듣다보니 그 시대의 아티스트들과 같이 호흡하는 것 같았다. 하지만 단점으로 너무 진도가 안나가고.. 뒤의 내용을 보다보면 앞에 내용이 생각이 안나게 되었다. (나이 때문은.. 아니라고 생각하고 싶지만).

이러한 문제를 해결하고자 간단한 상황 설명과 함께, 주요 곡들에 대한 유툽 링크를 정리해 올림으로써 리뷰를 위한 시간을 절약하고 싶다. 그리고 같이 뒤늦게 PAINT IN ROCK을 접하는 나와 같은 독자들과 같이 이야기를 나누면 어떨까 해서 2019년 초겨울날에 글을 남긴다.

얼마나 걸릴지 또 이런저런 일들로 다 읽기나 할런지는 모르겠으나.
뭐, 시작도 여러번 하다보면 언젠간 끝이 나지 않겠는가?

그때 내가 남긴 글들이 세이브 포인트가 되었으면 좋겠다.