예전부터 시간은 금이라는 얘기를 많이 들었지만, 실제  한시간이 어느 정도의 가치를 가지는지에 대한 직관적인 감이 없어서 시간을 낭비하는 경우가 많았다. (정말? ㅎㅎ) 이번에 오랜만에 기차를 타면서 시간에 대한 가치에 대한 insight를 얻어, 간단히 정리해보았다.

평일 오후, 서울에서 부산으로 이동하는 교통수단 별 소요시간과 운임을 이용하여, 시간에 대한 가치를 분석해보자.

우선 가장 보편적인 교통 수단 중 하나인 고속버스는 서울에서 부산까지 약 4시간 30분이 걸리며, 운임은 32,800원이다.

만약 평일에 KTX를 탄다고 가정하면, 서울에서 부산까지 약 2시간 30분이 걸리며, 운임은 53,300원이다. 즉, 약 2시간을 단축시키기 위한 비용은 53,300 – 32,800 = 20,500원이며, 시간 당 비용은 대략 1만원 정도로 볼 수 있다.

여기서 재미있는 점은, 수원을 경유하는 KTX를 탈 경우인데, 이 때 소요시간은 약 3시간 30분으로 고속버스에 비해 1시간이 적고, 경유를 하지 않는 KTX에 비해 1시간이 많다. 그렇다면 운임은 얼마일까? 운임은 정확하게 43,200원으로, 고속버스에 비해 10,400원 많고, 경유하지 않는 KTX보다 10,100원이 적다.

슬슬 감이 잡히는가? 마지막으로 한 가지 더 찾아보면, 구포를 경유하는 KTX의 소요시간은 약 3시간 정도이며, 운임은 49,200원이다. 수원을 경유할 때 보다 시간은 30여분이 단축되는 대신, 운임은 6천원이 오르고, 경유하지 않을 때 보다는 시간이 30여 분 더 걸리고, 운임은 4,100원 싸진다.

그렇다면 비행기를 타고 하늘을 날아가는 경우는 어떨까? 비행기의 경우, 비행시간만 따지면 55분이고, 운임은 대한항공 평일 기준으로 62,400원이다. 김포공항의 접근성과 티켓팅 시간을 고려하여 비행시간에 30분 정도의 소요시간을 더해주면, 가장 빠른 KTX와의 시간 차이는 약 1시간이 되고, 운임 차이는 9,100원이 된다.

정리해보면, 우리나라에서 운송수단을 제공하는 회사들이 책정한 국민들의 시간의 가치는 약 1시간에 1만원 정도로, 남들보다 1시간 빨리 도착하고 싶다면, 1만원을 더 쓰면 된다.  

시간을 낭비하고 있는가? 그렇다면, 당신은 지금 한 시간에 만원씩 버리는 셈이다. :) 열심히 살자!

ps) KTX의 경우, 중간에 정차역에 몇 곳이냐에 따라 소요시간이 5~10분 정도 차이가 난다. 가장 빠른 열차의 경우, 서울에서 대전, 동대구만 거쳐서 부산에 도착하며, 소요시간은 2시간 25분이다. 느린 경우, 중간에 5~6곳 정도 정차하며, 소요시간이 2시간40분이 넘는 경우도 있다.

소요시간	2시간 25분	2시간 45분

ps2) 항공사의 경우, 출발시각에 따라 운임 할인이 적용되기도 하지만, KTX도 사전 예매에 따른 할인이 가능하므로, 일단 무시하고 표준 요금으로 계산하였다.

ps3) 가장 엽기적인 것은, 새마을호인데 고속버스에 비해 시간은 30분이 더 걸리는 주제에 요금은 9,800원 더 비싸다. 대체 무슨 배짱인가..

#1. 회사에서 조직개편이 있었다. 우리 회사 (옮긴지 세 달이 넘었는데, 아직도 왜 이렇게 어색하다냐)는 조직 개편 이후에, 구성원들에게 팀을 이동할 수 있는 기회를 준다. 물론 아무나 막 할 수 있는 건 아니고, 특정 조건을 만족시키면, (한 분야에서 3년 이상 일했다던가) 조직 개편 후, 일정 기간 동안 다른 팀에 공식적으로 지원을 할 수 있다. 물론 경력채용 된 나는, 3년인가 5년인가 우리 팀에 묶여 있어야 하므로, 딴 나라 얘기이긴 하다.

#2. 팀 회의를 하고 있는데, 팀장님께 쪽지가 왔다. 팀명을 지금 정해서 보내야 한단다 –_-; 그래서 약 5분 간의 논의 끝에 팀명을 정했다. 그 후 10분 쯤 뒤에 다시 팀장님께 걸려온 전화 한 통.. 원장님께서 이름이 맘에 안 드셨는지, 다시 팀장님이랑 열심히 전화로 논의를.. 개인적으로 난 별로 였던, 뭔가 굉장히 긴, 무려 세 단어로 이루어진 팀명이 정해졌다. 그리고 다시 오늘 공식적으로 발표가 났는데, 세 단어 중에서 중간 단어가 빠진 이름이 최종 낙점. 뭔가 우리 회사 좀 즉흥적인 거 같애;;

#3. 이건 약간 다른 얘긴. 오늘 신문에 30대 대기업 초봉에 관한 기사가 나왔다. 내가 겪었던 N모사와 친구에게 들었던 K모사는 대략 맞는 것 같고, 여기 신입공채로 들어온 우리 팀 매니저 분께 물어보니 S사 초봉도 인센 포함하면 비슷한 거 같다고.. 그런데 또 다른 S사는 절대 저 연봉이 아닌데,, 하면서 출처를 확인해 보니,

12일 머니투데이가 국내 시총 상위 30대 기업들과 해당 기업의 최근 입사자 등을 상대로 지난해 1월 입사한 대졸 사무직 신입사원의 지난해 기본급과 상여금, 각종 수당, 연말 성과급을 모두 합친 세전 연봉을 조사한 결과, 이 같이 나타났다.

그냥 기자들 인맥 총동원해서 기사 썼나 보다 ㅡ.ㅡ;;

Hadoop World 2011에서 발표되었던 HDFS Federation 요약

video를 보고 이해한 거 + 대략적인 소스 분석을 토대로 한 거라 틀린 부분이 있을 수도 있음

한 마디로 요약하면? 하나의 cluster에서 여러 namespace (namenode)를 쓸 수 있도록 한 것! 왜 이런 걸 했는지, 어떻게 했는지, 그리고 앞으로는 어떻게 발전할 것인지에 대해 소개함.

1. 현재 HDFS Architecture에 대한 요약 : 자세한 내용은 여기 참조
   1. Namespace와 Block Storage의 조합
      
   2. Namespace : directory, file, block으로 구성 / file 및 directory에 대한 create, delete, modify, list를 지원
   3. Block Storage : Datanode membership 관리 / block에 대한 create, delete, modify, get 을 지원 / 복제 계수 관리
   4. 현재는 cluster 전체에 하나의 Namespace Volume이 존재, namespace는 하나의 namenode에 올라감
      1. 전체 namespace는 namenode의 메모리에 올라가며, block file들은 datanode의 local file system에 저장됨
2. 무엇이 문제인가?
   1. Scalability : datanode만 추가하면, 용량은 쉽게 증가하지만, namespace자체는 그렇지 않음
      1. 메모리의 한계로, namespace의 file와 directory 개수에 제한이 있음
         1. 64 GB 메모리에 약 2억 5천 만개의 파일과 block들이 저장
      2. 여전히 매우 큰 클러스터라고 할 수 있지만.. (Facebook은 약 70 PB를 저장함)
   2. Performance : namenode가 하나이므로, 당연히 throughput에 제약이 있음 (한 대가 아무리 좋아 봐야 몰리면.. 뭐..)
      1. 120,000 read ops / sec & 6,000 write ops / sec (write를 할 때는 file로 edit log를 떨궈야 하기 때문에 느림)
      2. 코드 최적화를 통해 20,000 write ops / sec 정도까지는 쉽게 올릴 수 있음
      3. 아무리 최적화를 하더라도, 한 대로 서비스를 하면 bottleneck이 생길 수 밖에 없음
   3. Poor Isolation : 모든 사람/application이 하나의 namespace를 쓰는 문제
      1. 최적화가 덜된 실험적인 job과 상용 job이 하나의 namespace를 사용하는 것은 문제
      2. production cluster에서 하나의 테스트 job이 파일을 어마어마하게 생산하고 지우는 무식한 작업을 한다면, 다른 중요한 job들이 실행되는데도 영향을 끼침
   4. Tight Coupling : 따지고 보면, Namespace와 Block 관리는 서로 다른 분리된 서비스들임. 그런데 엮여 있다 보니 scaling하기 복잡함.
      1. 현재는 모두 namenode 관련 코드로 묶여있음
      2. 두 가지를 분리하여, block 관리도 단순화하고, namespace도 단순화하자!
      3. 궁극적으로 Block Storage 서비스를 일반화 하자.
         1. 이 경우, namespace는 block storage를 사용하는 하나의 어플리케이션이 되는 것
         2. 그 외 HBase 등도 block storage 서비스를 사용할 수 있음
3. 사실 scaling 보다는 isolation이 더 문제임
   1. namenode에 64 GB 메모리만 꼽으면, 대부분의 cluster에서는 큰 문제가 안됨 (HDFS 특성 상 2억 개를 넘는 file을 저장할 일이 있을까?)
   2. 하지만, 다른 종류의 application들에게 독립적인 namespace를 제공해주는 것은  cluster의 크기가 작더라도 필요함
4. HDFS Federation
   1. 하나의 cluster에 여러 개의 독립된 namenode들과 namespace volume이 존재
      
   2. Block Storage는 일반적인 storage service 처럼 사용됨
      1. 1423 번 block에 xxx~~라는 내용을 저장하고, 이 block을 세 개 정도 안전하게 복사해주세요!
      2. 가장 가까이 있는 서버에서 2698 번 block을 읽고 싶어요!
      3. 이런 느낌?
   3. Block Pool
      1. 하나의 namespace는 하나의 block pool을 가짐
      2. 이전에는 datanode에게 1234 번 block에 저장해주세요~ 라고 요청했다면, 이제는 9876번 block pool (namespace 별로 unique하게 생성됨)에 1234번 block에 저장해주세요~ 라고 변경됨
         1. 즉, namenode와 datanode 사이에 block pool이라는 layer가 하나 더 생긴 것
      3. 기존의 block은 block id (long)로 구분되지만, block pool에서 사용되는 ExtendedBlock은 pool id (string)와 block id (long)로 구분됨
         1. pool id는 "BP-" + rand + "-"+ ip + "-" + System.currentTimeMillis(); 와 같이 생성되며 (NNStorage.java의 newBlockPoolID() 참조), 하나의 namespace가 고유의 block pool id를 가짐
      4. datanode들은 모든 namenode의 namespace에 소속되며, (몇 개의 datanode가 하나의 namenode에 종속되는 개념이 아님) 모든 namespace의 block들을 독립적으로 저장.
         1. 이전 :  /dfs/data/current/blk_-291620265307745070 와 같이 저장
         2. 0.23이후 : /dfs/current/block_pool_id/current/blk_-291620265307745070 와 같이 저장 (수정필요)
5. 좋은 점은?
   1. 분산된 namespace : 여러 개의 namenode들로 분산됨
      1. 독립된 master (namenode)구조이므로 단순하고 robust함
      2. namenode code는 거의 고치지 않았으므로, 이전의 namenode 안정성을 그대로 유지
   2. Block Pool이 하나의 일반적인 storage service로 제공됨
      1. 각각의 namespace volume은 독립적임 (하나의 namenode가 죽어도, 다른 namenode에는 영향이 없음)
      2. 새로운 innovation와 빠른 발전을 가져올 것임
         1. 예컨대, 다양한 garbarge collection scheme이 적용된 tmp storage 라던가
         2. 좀 더 효율적인 distributed cache 라던가
         3. small object storage 등등..
6. 좀 더 상세한 사항
   1. Namenode code는 거의 안 고치고, 대부분 datanode code와 config, tool code들이 수정됨
   2. core 개발은 4개월 만에 끝남
   3. namespace와 block management는 여전히 namenode에 남아 있음
      1. 미래에는 block management 부분은 namenode 밖으로 나갈 수도 있음
   4. 현존하는 cluster 배포에도 큰 영향이 없도록, 예전 설정으로도 동작이 가능함
   5. Cluster Web UI가 multi namespace를 지원할 수 있도록 수정됨
   6. 각종 tool들이 수정됨
      1. datanode들이 여러 namespace에서 decommission이 가능하도록 변경
      2. balancer가 여러 namespace에서 동작하도록 변경
         1. datanode들의 저장용량 뿐만 아니라, block pool storage에서도 balancing 이 가능
   7. federated cluster에서 namenode를 추가/삭제할 때, 전체 cluster 재시작 없이 가능
   8. 하나의 설정 파일로 namenode와 datanode 모두에 적용
7. Namespace 관리
   
   1. /data/test.txt 파일은 어느 namespace를 봐야 할까?
   2. global namespace는 존재하지 않음

   3. client에 mount table이 존재함
      
      

      1. e.g.) /data/ –> NS1
         /project/ –> NS2
         /home/ –> NS3
         위와 같은 mount table이 설정 파일로 존재
8. Next Step
   1. namespace와 block management layer의 완전한 분리
   2. 좀 더 나은 scalability를 위해 namespace에서 부분적인 내용 (e.g. 자주 access되는 file)만 memory에 올리고 나머지는 파일로 저장
   3. 실제 data copy (datanode들 사이의 block copy)없이 하나의 namespace를 다른 namespace로 이동

좀 더 많은 사항이 궁금하신 분들을 위해.. 아래의 HDFS 상위 설계서 일독을 추천합니다.

https://issues.apache.org/jira/secure/attachment/12453067/high-level-design.pdf

2012년 회사에서 나의 목표를 정하다가, 팀장님께 내가 하고 싶은 걸 말씀 드릴 기회가 있었다. 이런 저런 얘기를 하다가 내가 말한 item 중에 하나가 어찌어찌 변형되어서, 팀장님께서 평소에 필요로 하시던 tool을 만드는 것이 되어 버렸다.

의외로 공수가 별로 안들 것 같기도 하고, 마침 평소에 생각하고 있던 idea의 feasibilty도 볼 겸해서, 뚝딱뚝딱 prototyping 중이다. rough하게 말해서 php로 만든 hdfs explorer + filtering tool 정도가 되려나? (당근 hadoop에 기본으로 포함된 hdfs web viewer보다는 훨씬 더 편하고 이쁘다 ㅎ)

jquery랑 jquery ui, jqgrid까지 붙여놓으니 꽤 그럴듯한 툴이 되긴 했는데, 처음엔 간단했던 요구사항에 점점 추가사항이 붙고 있어서 낭패.. 적당한 선에서 끊고, 얼른 다른 것을 해야겠다. 흐흐

나른한 일요일 오후. 간만에 주말임에도 불구하고 일찍 일어난 덕에, 오후 두 시가 되니 끝없이 졸리기 시작했다. 그런데 난 낮에 자 버리면 밤에 잠을 잘  못 자기 때문에.. 정확히 30분만 자고 일어날 계획을 세웠다.

그런데 고전적인 방법대로 알람을 30분 뒤에 맞춰놓고 자려니, 내가 정확히 지금 잠들 거라는 보장이 없다. 기껏 20분 뒤에 잠들었는데, 10분 뒤에 깨 버린다면?! 휴대폰을 던져버리고 싶을 거야 –_-a

정확히 잠들기 직전에 알람을 맞춰놓고 잔다면 그게 가장 이상적이겠지만, 그게 어디 맘처럼 쉽나.. 그래서 나온 절충안 :

1. 스마트폰의 Tango 앱(영상통화 앱)을 통해 여친이랑 연결을 한다.
2. 여친이 TV를 보면서 5분 간격으로 내가 자고 있나를 확인한다. (“오빠 자~?”) (“아니”)
3. 내가 잠든 것이 확인 된 후 30분 뒤에 나를 깨운다.

덕분에 정확히 30분 잘 잤음 ^^v 스마트한 시대의 유용한 스마트폰 활용법이라고 자랑하고 싶지만, TV보면서 뒹굴거리는 여친이 있어야 가능한 방법이기에.. 나중에 시간이 나면 앱으로 만들어볼까 한다. ㅋㅋ