크리에이티브 커먼즈 라이선스
Creative Commons License


우리는 기술을 다루는 일을 한다. 

가끔은 기술만 다루려 하는 사람들을 만난다. 

엔지니어이기 때문에 당연하다. 

그러나 이 업종의 특성은 

엔지니어와 예술가와 관계중심적인 사람과 외곬수와 전문가 등등의 여러가지 성격의 복합적인 생각을 요구하게 될때가 있다. 

지금도 그렇지만... 예전엔 내가 졸라 잘난줄 알았다. 

그리고 내가 졸라 잘났다고 생각하는 그런 시각을 가지지 못한 사람은 정말 무시했다. 

즉, 내려봤다는 이야기다. 

내려보는 자세로 살다보면 내가 가르침을 내려줄때가 있다. 

'이 쉬키... 한수 알려주마.. 넌 임마 어디서도 이런말 못들을꺼야...'

예전에 강사를 한적이 있다. 한 8개월?

그랬더니 어디를 가도 내가 가르치려고 하고 있더라...

이런 나도 그랬는데.. 

평생을 유치원 교사나 초등학교 교사 를 한 사람이 내 마누라라면.... '아 정말 미칠꺼야...'

갑자기 다른 이야기로 갔는데... 내가 하고자 하는 말은 그게 아니니 돌아와보자..

경험과 역할이 달라지면서 코드를 직접 만지는 일이 드물게 되어버렸다. 

가끔은... 내가 '아.. 내가 관리자가 맞는 적성인가?' 하는 생각을 하고 있는 걸 발견한다. 

하지만! 정확하게 관리자가 아니기도 하다. 왜냐하면 나에게는 관리자! 에게 꼭 있어야 하는 권한은 없기 때문이다. 지랄같은  프리랜서...

프리랜서는 뭐.. 장단점이 있으니깐.. 이 놈에 대해서는 또 따로 이야기 하기로 하자..

관리자의 시각으로... 또는 아키텍트 역할을 하는 시각으로 개발자들을 바라보다 보니.. 오히려 나 자신을 돌아보게 된다. 

내 모습들을 거울처럼 보게 되기 때문이다. 

자존심 하나만으로 똘똘 뭉친 친구들이 있다. 

그 친구들은 자존심이 상하게 되면 그 다음부터는 일을 안해버린다. 

뭐.. 나 역시도 그랬다. 

그냥 직업처럼 하는 친구도 있다. 

내 직업이니깐.... 할일만 해주고... 나머지는 여가생활을 즐긴다..

돈을 공으로 먹으려는 친구들도 있다.. 

이 친구들에 대해서는 말하기도 싫고... 

자기 자신을 알아주기만을 바라는 친구들도 있다..

이 친구들은 알아주지 않으면 일 안한다..

기타 등등... 

오만가지 스타일의 친구들이 다 있다.

난 몇년전부터 일하기 전에 개인적인 인간관계부터 쌓고 시작한다고 생각을 한다..

나는 그렇게 해서 잘 해 나간다고 생각을 하는데.. 

어느순간 무너질때가 있다. 

내 암묵적인 법칙들이... 

내가 바쁠때다.. 

내 나름의 법칙은 내가 물밑에서 오리가 발길질 하듯이 내가 졸라 움직여야 하는 법칙이었던 게다...








저작자 표시 비영리 변경 금지
신고
블로그 이미지

[짱가™]

그 두번째 이야기 | 아키텍처에 대한 단상, 그리고 살아가는 이야기 | 대한 민국 아키텍트로 가는 길 | 열정전도사 "짱가|

크리에이티브 커먼즈 라이선스
Creative Commons License



프로그래머로써 생활한지 어느덧 십몇년차가 되었다. 

다른 업종으로 보면 그다지 길지 않은 시간이고 군대로 비유해봐도 이제 갓 일병 말호봉 정도 된 시기라고 생각이 된다. 
그러나 이쪽 산업의 발전 속도와 인력 구성을 생각해봤을 때 어느덧 기성세대로 접어들고 있다는 것은 거부할 수 없는 사실이리라 생각이 된다. 
이즈음에서 기성세대가 소프트웨어 산업에서 해야 할 역할이 무엇일까를 생각해보았다. 
중년의 시기가 되면 흔히 말하는 '멘토놀이' 를 생각하는 시기가 된다. 
호랑이는 가죽을 남기고 사람은 이름을 남긴다는 옛 성현들의 말을 굳이 떠올릴 필요도 없이 어느 정도 자신의 일에서 숙달 되었다 생각하면 자신의 시행착오를 후진들이 겪지 않게 하고 싶다는 생각과 더불어 잘난체 하고 싶은 생각이 들게 마련이다. 
나는 개인적으로 이런 생각들이 나쁘다고 생각하지 않는다. 
그런 행위들과 시도들이 시행착오가 되고 '소뒷발에 쥐잡기'로 좋은 결과를 낳듯 간에 그런 시도는 없는 것보단 낫다. 

나 역시도 그런 생각을 몇년 전부터 해오던 중에 지속적으로 마음속에서 떠오르는 자극이 있다. 
'내가 그럴만 한 경험과 시각을 가지고 있는가?'
'내 위치에서 한점 부끄럼 없이 내세울 것이 있는가?'
생각하면 생각할 수록 부끄러웠다. 
아무것도 할 수 없었고 누구 앞에도 서기가 힘들었다. 
글 한줄도 쓰기 힘들었고 자극만 받고 자책만 했다. 
그럴필요가 있는가? 과연 정말 부끄럼없이 잘난 사람만 그런 말 할 자격이 있는가? 하는 생각에도 이르렀고… 
그 이후론 그 생각을 하지 않으려한다. 

나는 현 시점이 우리나라 소프트웨어 개발 역사에서 큰 과도기적인 시기라고 생각을 한다. 
1. 인력의 불균형의 심화
2. 기술적인 발전의 급 가속화
3. 분야의 다변화
4. 국내 소프트웨어 산업의 불균형으로 인한 지병

이런 몇가지의 요인으로 인해서 복합적으로 병이 들고 있는 시기라고 생각한다. 
나는 SI 업계에서 거의 모든 경험의 대부분을 경험함으로 인해 패키지 업계나 서비스 업계, 게임업계 등에서 겪고 있는 장/단점 에 대해서는 경험도 없을 뿐더러 깊이 있는 생각을 해 본적이 없다. 
가시적으로 기준이 드러나는 '내 몸값 키우기' 에 바빴고 될만한 일을 하는 것에 바빴다.
그리고 후배들에게 이런 말을 했다.
'될만한 일을 해라. 되지 않을 일은 과감히 던지고 되지 않을 회사에서는 과감하게 나와라'
그러나 나 역시 회사에 입사해서 생활할 당시에는 그 부분 지켜지지 않았고 내가 직접 상황에 맞딱뜨리니 맘대로 되지 않는 것은 똑같다. 
역시 중이 제머리 못깎나보다. 

그럼 Developer 를 지향하는 후배들에게 기성세대가 할 수 있는 것들이 어떤 것이 있을까? 라는 관점을 가지고 내 경험에 비추어서 이야기를 해보자. 

- 롤모델이 되면 좋겠다
얼마전 97 Programmers 번역서에 몇페이지의 컬럼을 쓴적이 있다. 
거기에서 했던 이야기는 내 주변의 ( 나는 내세울게 없어서…^^;; ) 좋은 사례를 가지신 분들을 소개하며 개인의 Toy Project 를 만들어라고 이야기를 했다. 
엔지니어로써, 프로그래머로써 열정을 유지하고 스스로의 테스트베드를 가지는 것은 이만한 것이 없다. 
그리고 그 분들이 보여준 사례는 귀감이 될만한 사례들이다. 
크게 성공한 회사를 운영하거나 만든 앱이 대박을 친 인물들은 천명에 한명? 아니 그보다 극소수의 사람들이다. 
우리는 평범함에서 위대하게 발전해 나가는 그런 이들을 롤모델로 삼고 흉내내어 보는 것이 더 현실적이라는 것을 이미 알고 있다. 
내 개인적으로 가지고 있는 신념 중의 하나는 '충고를 바라지 않는 이에게 하는 충고는 잔소리요, 기분나쁜 소리일 뿐이다' 라는 생각이 있다. 
보여줘야 한다. 후배들에게 보여주는 사람들이 더 많아져야 한다. 
프로그래머를 꿈꾸는 이들에게 발전되어 나가는 것을 보여주는 롤모델들이 더 많아져야 할 것이라고 생각을 한다. 

- 소프트웨어 산업에 대한 시각을 통한 문화의 변화 추구 
어느 분야를 막론하고 먼저 경험하고 오랜 시간을 보낸 사람들에게 기대하는 것은 '실력' 외에도 그 분야를 바라보는 시각일 것이다. 
좀 과하게 이야기 하자면, 기계처럼 누군가가 시키는 일을 하는 것에 익숙해져서는 그런 시각을 가지기 힘들다. 
'내가 있는 이곳' 에 속한 사람들에게 밀려오는 흐름, 이곳을 둘러싼 환경들의 변화, 기술의 발전과 문화의 변화 등에 민감하게 생각하고 관찰을 잘 하는 사람들이 이런 시각을 가지게 될 것이다. 
그런 시각을 통해서 후배들에게 가르침을 줄 수 있어야 하고 문화를 변화시켜 나가야 할 것이다. 
우리가 살아온 척박한 환경보다 좋은 환경을 후배들에게 물려줄수 있어야 하지 않겠는가? 
'우리때는 저러지 않았는데…' 하는 고까운 시선으로 후배들을 바라보기 전에 말이다. 

- 학습의 가이드
소프트웨어 개발자라고 해서 모두 같은 개발 언어를 사용하는 것은 아니다. 
회사나 팀에서의 역할도 수없이 많은 분류를 가지고 서로 다른 영역의 능력을 원하게 된다. 
프로덕트/프로젝트 매니저를 꿈꾸는 이들, 아키텍트를 꿈꾸는 이들, 장인 개발자를 꿈꾸는 이들, 데이터 스페셜 리스트를 꿈꾸는 이들… 
등은 모두 서로 다른 능력을 필요로 하게 될 것이다. 
그들에게 필요한 학습을 하며 성장가능하도록 적절한 가이드를 할 수 있어야 한다. 
그러려면 우리 기성세대로 변해가는 이들이 먼저 고민한 부분이 있어야 하겠다. 
고민이 없는 경험은 자신의 지식이나 지혜가 되기에는 부족한 부분이 많다. 
스스로 고민을 많이 해 본 사람만이 적절한 가이드라인을 제시할 수 있을 것이다. 

- 경력 설계 
'회사를 찾아주는 헤드헌터' 가 아니더라도 우리는 선배로써 경력 설계를 해줄 수 있어야 할것이다. 
사람마다 성향이 다르고 목적한바가 다르다. 
그 사람의 성향에 따라 학습을 시키고 경력설계에 따른 조언으로 갈피를 잡지 못하고 있는 초년병들에 적절한 성장 가이드를 주자. 
먼저 사람에 대한 관심이 선행되어야 할것이다. 
사람에 대한 관심으로 그의 성향을 알고 장/단점을 알아야 적절한 성장을 도와줄 수 있을 것이다. 


물론 더 있을 것이지만 이 정도로 적어보았다. 
다음에는 프로그래머의 학습계획서(http://www.slipp.net/questions/201) 에 대해서 생각해 봐야겠다. 




저작자 표시 비영리 변경 금지
신고
블로그 이미지

[짱가™]

그 두번째 이야기 | 아키텍처에 대한 단상, 그리고 살아가는 이야기 | 대한 민국 아키텍트로 가는 길 | 열정전도사 "짱가|

크리에이티브 커먼즈 라이선스
Creative Commons License



소프트웨어 아키텍트 역할에 대해서 한번 생각해본다. 

생각해보면.... 

2005년의 Database 와 UML , 객체지향을 학습하던 어느날'software architecture' 라는 단어가 눈에 들어왔다. 
도대체 이놈이 무엇일까를 고민하면서 많은 research 를 하고 고민을 하던 중 만나게 된 교육과정.SEI 의 교육과정과 동일한 커리큘럼으로 진행되는 비트 컴퓨터의 과정이었다.
여기서 훌륭하신 멘토 분들을 만났다. 그리고 꿈을 꾸었다. 
'저 사람들 처럼 되고 싶다.'
그리고 마틴파울러를 알게 되고 켄트벡을 알게 되었다. 
내가 꿈에 그리던 아키텍트가 아닌 다른 모양을 바라보는 현재까지도 그 꿈은 여전히 현재 진행형이다. '아름다운 아키텍처' 를 만들어보고 싶다 라는 생각을 항상 마음속에 품고 산다. 
여전히 능력은 내가 만족할 만한 수준도 아니요, 어딘가에 보여줄 수준도 아니다. 
가끔 고민을 해보는데.... '멘토 코스프레' 라고 했나? 그런 '멘토 코스프레'를 할 생각은 없다. 

아키텍트 라는 역할에 대해서 우리가 성장하기 위한 목표를 잡기 어려운 이유가 무엇일까? 
필자가 생각하기엔 아마도'아키텍트' 라는 역할의 정의가 불분명 하기 때문이다. 
'소프트웨어 아키텍트'는 직함이나 회사에서의 위치를 뜻하거나 지식수준을 일컫는 단어가 아니다. 
소프트웨어를 만들기 위해서 설계에 참여하는 사람들의 역할을 지칭한다.
그리고 저명한 서적들에서는 그들 중에서 기술구조를 결정할 수 있는 의사결정권이 있는 기술리더를 '소프트웨어 아키텍트' 라고 칭한다. 

필자가 경력을 시작하던 1999년 정도에 우리나라 소프트웨어 개발에서 설계자는 DB 모델러 라고 했다. 
정보시스템에서 기반이 되는 데이타를 설계하는 주 집단이 ( 특히 우리나라에서는 ) RDBMS 를 기반으로 하는 관계형 모델러 들이었기 때문이다. 
그래서 그들을 위주로 소프트웨어 개발을 돌아갔고 우리는 그게 당연했다. 필자 역시도 Data Modeler 가 초반 경력의 꿈이었다. 
대단하지 않은가? 프로젝트 혹은 프로덕트 전체가 특정 역할을 하는 사람들에 의해서 기반이 세워지고 그 시스템이 만들어 진다는 것이..
내게는 그 사람들이 시스템의 창조자 였으며 건물을 설계하는 아키텍트였다.
그러나 개발 패러다임이 바뀌고 '소프트웨어 아키텍처' 라는 이야기들을 들은 것은 '카네기 멜론 대학' 등의 교육과정을 통해서 성장한 이들이 우리나라에도 교육과정을 만들고 설파하기 시작한 2004년 정도 라고 생각을 한다. 
그때부터 소프트웨어 아키텍처 라는 이야기를 시작하고 소프트웨어 아키텍트 가 도대체 뭘까? 하는 이야기들을 하기 시작했다. 
그 때 당시의 소프트웨어 아키텍트의 정의는 '소프트웨어 아키텍처 인 프랙티스' 에서 정의한 '한 시스템의 소프트웨어 아키텍처란 그 시스템의 한 구조나 구조들로 각 요소들과 외부에 보이는 특성들 그리고 그들간의 관계를 절충한다' 였다. 
그리고 소프트웨어를 개발하기 위한 전지전능한 존재 라고 이야기 하기 시작했다. 
누가 어떤 논리로 이 단어를 표현하기 시작했든 간에… 
'전지전능한 존재'… 이 정의에서부터 프로그래머, S/W Developer 에게 진입장벽을 만들었고 개발자들에게는 위화감을 조성하게 되었다.
그리고 실제 일을 해보니 화성인 아키텍트와 현실에서 구현을 하는 개발자간에 생기는 간극을 해소하지 못하는 문제들이 발생하게 되었다. 
그래서 그 두 집단(?)은 서로를 멀리하게 되고 서로를 욕하는 경우가 많아지게 되었다고 생각을 한다. 
왜 이런일이 일어나게 되었고 서로 어떤 부분을 오해하고 있는지에 대해서 조금더 많은 생각이 필요하다.

용어정의 ( 가끔 단어를 구분하지 않는 분들을 위해서 일단 단어 정의를 한다 ) 
소프트웨어 아키텍트 - 아키텍처를 설계하는 일을 하는 역할? 혹은 시스템 구조 설계자 
소프트웨어 아키텍처 - 소프트웨어를 구축하기 위해서 설계를 하기 위한 뼈대 설계 ( 더 낫고 디테일한 정의는 '소프트웨어 아키텍처 인 프랙티스' 를 추천한다 ) 

가끔 그런 글을 보거나 훌륭하신 분들중에서 이런말을 하시는 분이 있다.
'나는 대한민국에서 소프트웨어 아키텍트를 손가락으로 꼽을 만큼만 인정한다.'
'제대로 하시는 소프트웨어 아키텍트를 본적이 있습니까?'
필자는 몇가지 측면에서 이 말 자체가 잘 못 되어있다고 생각하는 사람이다. 
1. 일단 말 자체가 잘못되었다.
위에서도 이야기 했듯이 필자는 소프트웨어 아키텍트는 '역할' 이라고 생각한다. 
특히, 특정시점에서 소프트웨어 아키텍처를 설계하는 역할.
그런데 소프트웨어 아키텍트를 인정한다. 안한다. 이말이 무슨말인가… 말 자체가 이상하지 않은가? 
좀 어거지 스러울지 몰라도 이 말은 
'xxx 시스템에서 xxx 아키텍처를 설계하신 ooo 그 분은 xxx 측면으로 훌륭하게 아키텍트 역할을 하셨다' 는 의미로 들릴수 있도록 이야기가 되어야 한다고 생각한다. 
2. 대학에서 가르치는 사람은 교수, 건축물을 설계하시는 사람은 설계사 혹은 아키텍트 라고 불리운다. 
어떤 교수가 ooo 과목을 가르치는데 수준을 평가한다. 그리고 수준에 따라서 그 사람은 교수라고 불리지 못하게 되나? 
xxx 건축사가 건물 설계를 했는데 건물설계가 개판이다. 그럼 그 사람은 건축사가 아닌건가? 그냥 그 건축사에게 의뢰만 안하면 되는거 아닌가? 
소프트웨어 맥락으로 돌아와 보자.
저명한 서적에서 말했던 수많은 역량들
정치력, 커뮤니케이션 능력, 문서화 능력, 프레젠테이션 능력, 프로세스 설계 능력, 소프트웨어 설계능력, 구현능력, 배포/릴리즈 관여 …
이런 역량을 모두 갖춘 사람만 소프트웨어 아키텍트 역할을 하는 사람이라고 할 수 있는가? 

다른 측면에서 역할 이야기를 해본다. 
정보시스템 구축에서 2006년 즈음에Enterprise Architecture 에 대한 패러다임이 등장하고 그에 의해 나눠진 역할AA, BA, TA, DA 그리고 'Software Architect 는 이 네가지 역할중에 AA 에 가장 가깝지만 그 사이에 있는 것이다' 라는 모호한 경계선상에 놓여진 역할로 여겨지기 시작했다.
2013년 현재 프로젝트를 다니다보면 기업별로 정의하기 나름인 이 역할들그리고 Software Architect 라는 역할보다는 AA 혹은 TA 를 사용하기 시작했다. 
이런 역할과 관련된 일을 하면 그 사람은 시스템을 구축하는 아키텍트 역할을 하고 있는 것이다.
그렇지 않은가?  

저작자 표시 비영리 변경 금지
신고
블로그 이미지

[짱가™]

그 두번째 이야기 | 아키텍처에 대한 단상, 그리고 살아가는 이야기 | 대한 민국 아키텍트로 가는 길 | 열정전도사 "짱가|

크리에이티브 커먼즈 라이선스
Creative Commons License

AOSA 1권 9장. CI 정리 



http://www.aosabook.org/en/integration.html






저작자 표시 비영리 변경 금지
신고
블로그 이미지

[짱가™]

그 두번째 이야기 | 아키텍처에 대한 단상, 그리고 살아가는 이야기 | 대한 민국 아키텍트로 가는 길 | 열정전도사 "짱가|

크리에이티브 커먼즈 라이선스
Creative Commons License



http://www.aosabook.org/en/hdfs.html 

의 내용을 정리하였으며 웹 상에서 여러 다른 정보도 참조하였습니다. 




















8.HDFS

introduction

하둡 분산 파일 시스템(Hadoop Distributed File System, HDFS)은 기성 하드웨어에서 실행할 수 있도록 디자인된 분산 파일 시스템.

ㅇ 다른 분산 파일 시스템과의 차이점

HDFS  fault-tolerant 하고 저비용 하드웨어를 통해 배포할 수 있도록 설계됨.

HDFS는 응용 프로그램 데이터의 접근에 높은 처리량을 제공하고, 대용량 데이터 집합을 갖는 응용 프로그램에 적합

ㅇ 하둡의 중요한 특징은 수 없이 많은 데이타와 계산의 파티션, 병렬 계산의 실행임

ㅇ hdfs는 메타데이타와 데이타를 분리하여 저장한다.

namenode 에 메타 데이타 저장

datanode 에 데이타 저장

TCP 를 이용하여 서로 통신

ㅇ 목적

대용량 분산 파일 시스템에서 사용

ㅇ 높은 안정성

 –파일을 여러 개 복제하여 하드웨어 장애에 안정적임

 –결함 탐지와 자동 복구를 수행함

ㅇ 일괄처리 최적화

 –매우 높은 대역폭 제공

ㅇ 특징

ㅇ single-writer & multiple-reader 모델

ㅇ 전체 클러스터에 대한 하나의 namespace를 가짐

   ㅇ namespace는 계층적인 파일, 디렉토리를 가진다.

    –권한 등의 속성, 수정/접근 시간, 디스크 공간 할당량 등을 기록함

ㅇ 시스템의 메타데이터, 응용프로그램의 데이터를 분할하여 저장

 - 시스템 메타데이터: NameNode / 응용프로그램 데이터: DataNode

ㅇ 파일 내용을 블록단위로 분할 및 복제

- 각 블록은 독립적으로 여러 DataNode 에 복제 - replica (일반적으로 3)



<Read&Write에 대한 간략한 도식화는 http://bcho.tistory.com/650 의 프로세스와 순서 설명을 참고한다.>


Architecture

1. namenode

파일시스템의 namespace 를 관리 

 - 파일 목록 

 - 파일이름과 파일의 블록 목록 맵핑 

 - 블록과 DataNode 위치 맵핑 


그 외에도

 - 클라이언트의 요청 (읽기/쓰기

 - CheckpointNode , BackupNode 를 관리하며 image, checkpoint, journal 을 저장한다. 


2. image and journal

inodes name system 의 메타데이타를 저장하는 블록의 목록을 이미지라고 함

클라이언트의 시작 트랜잭션이 journal 에 기록하고 ack가 클라이언트로 전송되기 전에 저널 파일은 플러쉬 되고 동기화 된다


image 

- 파일시스템의 메타 데이터 

- inode data + 각 파일의 블록과 블록의 복제인 replica들의 목록 


checkpoint ( image에 대한 지속적인 기록을 위해서 사용 )

   - 파일 시스템의 메타데이터 보호 위해 사용하는 메커니즘. 


journal 

- image의 수정사항에 대한 쓰기 전에 commit 로그 ( 파일 시스템의 변경사항 기록 )


checkpoint journal 손상 대비하여 checkpoint, journal을 다른 볼륨이나 다른 서버에 저장 


3. datanodes

데이터노드는 로컬 파일 시스템의 파일에 HDFS 데이터를 저장

ㅇ 데이터노드는 HDFS에 관한 지식이 없음.

 - 로컬파일시스템에 분리된 파일들로 HDFS 블록을 저장 

ㅇ 파일을 같은 디렉토리에 생성하지 않음 

 - 디렉토리당 최적의 파일수를 판단하고 서브디렉토리 생성 

ㅇ 블록레포트 : 네임노드가 시작할때(주기적으로) 로컬파일시스템에 있는 모든 HDFS 블록들을 검사후 정상적인 블록의 목록을 만들어 네임노드에 전송


ㅇ 블록 서버로서의 역할 

- 응용 프로그램의 데이터 저장 

- 블록의 메타 데이터 저장 

- 클라이언트에게 데이터와 메타데이터 제공 

ㅇ Block Report (주기적으로 NameNode로 전송, Namespace에게 replica들의 위치를 알림 )


ㅇ heartbeat 

- 주기적으로 NameNode로 전송 

- 해당 replica가 사용 가능함을 알림    


ㅇ handshake 

- 시스템 시작 동안 각 DataNode NameNode가 수행 

- Namespace ID DataNode S/W 버전 불일치 시 자동 종료   

- Handshake 성공 후, DataNode는 자신의 storage ID NameNode에 등록



4. HDFS client 

사용자 응용 프로그램이 파일시스템에 접근 위해 사용 




- HDFS 클라이언트가 파일을 read할 경우 

1)replica들의 목록 및 위치를 알기 위해 NameNode에 요청

2)클라이언트와 가장 가까이에 있는 replica 확인 

3)DataNode에 직접 접근하여 원하는 replica의 전송 요청 







- HDFS 클라이언트가 파일을 write할 경우 

1)replicas 생성을 위해 NameNode DataNode로부터 블록 할당 요청 ( 권한 체크 

2)DataNode가 파이프라인을 구성하면 클라이언트는 첫 블록에 데이터 전송 

3)전송 완료 후 클라이언트는 DataNode에게 다음 replica를 위한 새로운 블록 선택 요청 

4)새로운 파이프라인이 구성되고 클라이언트는 데이터 전송 

5)복제가 모두 끝나면 Ack 를 보내고 파일 쓰기를 완료한다.



- 파이프 라인 구성 및 데이터 전송 

1)DataNode로부터 replica 들을 위한 블록들이 할당됨 

2)DataNode는 클라이언트에서 마지막 replica블록 까지의 전체 네트워크 거리를 최소화 하는 파이프라인 형성 

3)패킷 버퍼가 가득 차면 데이터가 파이프라인에 push




NameNode 는 또 다른 역할을 가질수가 있는데 checkpointNode 또는 BackupNode 로서의 역할이다. 

5 CheckpointNode

- 주기적으로 새로운 checkpoint 생성 

ㅇ checkpoint + journal = new checkpoint, empty journal 

ㅇ 파일 시스템의 메타데이터 보호 위해 존재하는 역할


6 BackupNode

- 파일시스템의 블록 위치를 제외한 모든 메타데이터 정보를 갖고 있음 

- 항상 NameNode 상태와 동기화 유지 

ㅇ namespace의 최신 데이터를 내부 메모리에 유지 

ㅇ NameNode 결함 시 BackupNode namespace 복구 



7 Upgrades and Filesystem Snapshots

ㅇ HDFS에서 스냅샷 생성 목적 

ㅇ 시스템 시작 시 클러스터 관리자 선택에 의해 스냅샷 생성 

 클러스터의 각 DataNode storage 디렉토리의 복사본과 실제 존재하는 block파일들의 하드링크 생성 

ㅇ DataNode에서 블록 삭제는 단지 하드링크만 제거하고 수정 시에는 복사, 쓰기를 수행 


8  

마스터/슬레이브 구조 로 관리됨

• HDFS 클러스터( 1.NN + N.DN )

 # 마스터 - 단일 네임노드  : 파일 시스템 네임스페이스를 관리(메타데이터)  

* 클라이언트에 의한 파일접근을 통제  

* 데이터노드의 블록 매핑 


# 슬레이브 

- 많은 데이터노드  : 스토리지를 관리  

* 파일은 여러개의 블록으로 분리되며 여러개의 데이터노드에 저장  

* 네임노드의 지시에 따라 블록 생성, 삭제, 복제 수행



 File I/O Operations and Replica Management

1 File Read & Write

- 위의 Hdfs Client 에서의 Read & Write 참조 


2 Block Replacement

replica 배치 정책 목적 

ㅇ HDFS를 다른 분산 파일 시스템과 구분 시킴 

ㅇ 데이터의 안전성, 신뢰성, 가용성, 네트워크 대역폭 이용 극대화 


ㅇ 하나의 DataNode에는 같은 블록의 replica를 하나만 포함해야 함 





3 Replication Management

ㅇ 하나의 rack은 같은 블록 replica를 두 개 이상 포함하지 않아야 함 Block Placement 

- 첫번째 replica : 로컬 rack의 하나의 노드에 배치 

- 두번째 replica : 로컬 rack의 다른 노드에 배치 

- 마지막 replica : 두 번째와 같은 rack의 다른 노드에 배치

- 추가적인 replica는 랜덤으로 배치 (기본적으로 3개의 replica 사용복사본이 두 개 이상의 rack에 저장되므로 하드웨어 장애에 안정적

4 Balancer

- HDFS 클러스터에서 디스크 공간 사용을 위한 균형 도구임. 


5 Block Scanner

DataNode가 주기적으로 replica들을 검사하여 저장된 checksum이 블록 데이터와 일치하는지 확인하는 도구 

ㅇ 손상된 replica블록 감지 시 ( 데이터를 보존하는 것을 목표로 하는 정책임)

-NameNode에 알리고 NameNode는 해당 replica를 손상된 것으로 표시 하고 바로 삭제 하진 않고 블록의 정상 replica를 추가로 생성 한다. 

-replica들 중 절반이 손상된 replica가 될 경우에만 손상된 replica를 삭제




참고자료 

http://www.aosabook.org/en/hdfs.html

http://bcho.tistory.com/650




저작자 표시 비영리 변경 금지
신고
블로그 이미지

[짱가™]

그 두번째 이야기 | 아키텍처에 대한 단상, 그리고 살아가는 이야기 | 대한 민국 아키텍트로 가는 길 | 열정전도사 "짱가|

크리에이티브 커먼즈 라이선스
Creative Commons License


나는 지식 노동자다. 

그래. 노동자다. 

아직 비즈니스를 만들고 어쩌고는 ... 뭐 먼 나라 얘기다.

엔지니어 이다. 라고는 말하지만, 예전의 기준으로 보면 배운놈이 하는 일을 하는 거다.

다만, 기술을 가지고 하니깐,,,, 엔지니어니 뭐니... 하는 거다.

자신의 지식을 가지고 모니터와 대화하고 같은 지식 배경을 가진 사람들과 갑론을박 하면서 살아가는 이 세상에서 늘어가는 것은 기술과 자신의 지식에 대한 자부심과 아집일듯 하다.


'지식 노동자' 란 내가 가진 지식으로 인정을 받고 싶어하는 사람일게다.

그러다 보니 자기도 모르게 상대방을 누르려고 하기도 하고 자신의 영향력을 키우기 위한 행동을 하게 되기도 한다.

아직도 인정받지 못하면 자괴감과 더불어 '그 자리에 내가 왜 있나?' 를 생각하기도 한다. 

그래도 자존심을 세우나 보다. 


그런데...근래 들어서 그런 기술적인 다툼을 피하려고 하는 내 모습을 자주 발견한다. 

솔직히 솔루션 이라는 것이 어떤 방법을 사용하든 된다 돼!

어떻게든... 그게 효율적이든 효율적이지 않든. 

효율적이라는 것도 솔직히 주관일 경우가 많다. 
모든 경우에 BMT 를 할 수 없쟎은가? 

그렇게 피하고 어떻게든 좋게 가려고 하면.. 또 나를 누르려 하는 사람을 보게 된다.
눌려준다. 왜? 어차피 사람이 하는 일이니까... 같이 가려고... 
그런데.. 그런 시간이 지나고 지날수록.... 내 맘속에서 올라오는 짜증은.. 
그래... 어쩔수 없는 쟁이구나...

뭐 그래도 어쩔수 없다. 
내 주관이 어차피...
소프트웨어 프로젝트 및 제품은 '사람' 이 중심이다. 
그리고 솔루션은 정답이 없다. 
이 두가지 이기 때문에... 
나는 내가 깊이 뛰어든 일이 잘 되기 위해서는 그런 행동을 지속할 것이다. 

다만, 내게 있어서 과제는 ... 
내가 어떤 의도로 이런 저런 행동을 하고 잘 되고.. 했을때...
내가 인정받지 못하면 짜증나는....( 내가 생각하기엔...암묵적이고 숨겨진 내 이러 저러한 역할이 있었는데 말이지? ) 
그런 보상 심리를 가지는 그런 감정 상태를 극복해야 한다는 거다.
몇년간 가지고 있는 주관과 과제인데...

쉽지 않은 것 같다.
워낙 인정받고자 하는 욕구가 강하고 
떠들기도 좋아하고 
말하지 않으면 못견뎌하고 
속물적인 성향이라.... 





저작자 표시 비영리 변경 금지
신고
블로그 이미지

[짱가™]

그 두번째 이야기 | 아키텍처에 대한 단상, 그리고 살아가는 이야기 | 대한 민국 아키텍트로 가는 길 | 열정전도사 "짱가|

크리에이티브 커먼즈 라이선스
Creative Commons License

코드는 이해하기 쉬워야 해!


무엇이 코드를 '더 좋게' 만들까?

return exponent >=0 ? mantissa *(1 << exponent) : mantissa / (1 << -exponent);



위 코드가 더 보기 좋은가? 아니면 아래의 코드가 더 보기 좋은가?


if ( exponent >= 0 )

return mantissa * (1 << exponent);

else

return mantissa / ( 1 << -exponent );


- 정답은 없다. 관습의 차이와 사람의 흔한 습관적인 부분일 수도 있다.

- 나는 적어도 두번째가 내 눈에 잘 들어온다. 



가독성의 기본

- 코드는 다른 사람이 그것을 이해 하는데 들이는 시간을 최소화 하는 방식으로 작성되어야 한다. 


분량이 적으면 항상 좋은가? 

- 예전 환경에서는 어땠을 지 모른다. 하지만, 현재의 환경 (display, memory 등의 변화) 에서는 별 무리 없이 모든 것들이 수행되게 된다. 

- 오히려 변수를 길게 서술형으로 쓰는 유명인들도 꽤 있다. 



그!러!나! 실천하기 어려운 부분이 있다.

- 상상속에서 다른 사람이 내 코드를 읽는 다고 생각하면 당연히 추가적인 시간과 노력이 들고 , 

  지금까지와는 다른 사고방식이 필요하게 된다. 


자... 하지만, 이런 목표를 받아들여서 스스로를 자랑스럽게 해보자. 




저작자 표시 비영리 변경 금지
신고
블로그 이미지

[짱가™]

그 두번째 이야기 | 아키텍처에 대한 단상, 그리고 살아가는 이야기 | 대한 민국 아키텍트로 가는 길 | 열정전도사 "짱가|

크리에이티브 커먼즈 라이선스
Creative Commons License


읽기 좋은 코드가 좋은 코드다

저자
더스틴 보즈웰 지음
출판사
한빛미디어 | 2012-04-06 출간
카테고리
컴퓨터/IT
책소개
이 책은 코드를 작성할 때 언제나 적용할 수 있는 기본적인 원리...
가격비교



( 맨날 뭐 하려고 하면 거창하게 생각하고 거창하게 시작해서 아무것도 못하는 것 같아서... 

스텝 바이 스텝으로 천천히 생각하기로 했다. 



오늘부터 한 챕터씩 '읽기 좋은 코드가 좋은 코드다' 를 정리해보기로 했다.


'소설처럼 읽히는 코드' - 이게 내 평소 지론이다. 

이것을 도와주는 책으로는 국내 책중에는 현재까지는 Clean Code 가 최고였다만,,,, 

이 책 역시 던져주는 메시지가 꽤 좋으므로... 정리. 





목차는 다음과 같다. 


1장. 코드는 이해하기 쉬워야 한다
   01. 무엇이 코드를 '더 좋게' 만드는가?  
   02. 가독성의 기본 정리  
   03. 분량이 적으면 항상 더 좋은가?  
   04. 이해를 위한 시간은 다른 목표와 충돌하는가?  
   05. 어려운 부분  

PART I. 표면적 수준에서의 개선

2장. 이름에 정보 담기
   01. 특정한 단어 고르기  
   02. tmp나 retval 같은 보편적인 이름 피하기  
   03. 추상적인 이름보다 구체적인 이름을 선호하라  
   04. 추가적인 정보를 이름에 추가하기  
   05. 이름은 얼마나 길어야 하는가?  
   06. 이름 포메팅으로 의미를 전달하라  
   요약  

3장. 오해할 수 없는 이름들
   01. 예: Filter()  
   02. 예: Clip(text, length)  
   03. 경계를 포함하는 한계값을 다룰 때는 min과 max를 사용하라  
   04. 경계를 포함하는 범위에는 first와 last를 사용하라  
   05. 경계를 포함하고/배제하는 범위에는 begin과 end를 사용하라  
   06. 불리언 변수에 이름 붙이기  
   07. 사용자의 기대에 부응하기  
   08. 예: 이름을 짓기 위해서 복수의 후보를 평가하기  
   요약  

4장. 미학
   01. 미학이 무슨 상관인가?  
   02. 일관성과 간결성을 위해서 줄 바꿈을 재정렬하기  
   03. 메소드를 활용하여 불규칙성을 정리하라  
   04. 도움이 된다면 코드의 열을 맞춰라  
   05. 의미 있는 순서를 선택하고 일관성 있게 사용하라  
   06. 선언문을 블록으로 구성하라  
   07. 코드를 '문단'으로 쪼개라  
   08. 개인적인 스타일 대 일관성  
   요약  	
	
5장. 주석에 담아야 하는 대상
   01. 설명하지 말아야 하는 것  
   02. 생각을 기록하라  
   03. 코드를 읽는 사람의 입장이 되어라  
   04. 마지막 고찰 - 글 쓰는 두려움을 떨쳐내라  
   요약  
	
6장 명확하고 간결한 주석 달기
   01. 주석을 간결하게 하라  
   02. 모호한 대명사는 피하라  
   03. 엉터리 문장을 다듬어라  
   04. 함수의 동작을 명확하게 설명하라  
   05. 코너케이스를 설명해주는 입/출력 예를 사용하라  
   06. 코드의 의도를 명시하라  
   07. 이름을 가진 함수 파라미터 주석  
   08. 정보 축약형 단어를 사용하라  
   요약  
	
PART II. 루프와 논리를 단순화하기

7장. 읽기 쉽게 흐름제어 만들기
   01. 조건문에서 인수의 순서  
   02. if/else 블록의 순서  
   03. (삼항 연산자로 알려진)?:를 이용하는 조건문 표현  
   04. do/while 루프를 피하라  
   05. 함수 중간에서 반환하기  
   06. 악명 높은 goto  
   07. 중첩을 최소화하기  
   08. 실행 흐름을 따라올 수 있는가?  
   요약  
	
8장. 거대한 표현을 잘게 쪼개기
   01. 설명 변수  
   02. 요약 변수  
   03. 드모르간의 법칙 사용하기  
   04. 쇼트 서킷 논리 오용하기  
   05. 예: 복잡한 논리와 씨름하기  
   06. 거대한 구문 나누기  
   07. 표현을 단순화하는 다른 창의적인 방법들  
   요약  
	
9장. 변수와 가독성
   01. 변수 제거하기  
   02. 변수의 범위를 좁혀라  
   03. 값을 한 번만 할당하는 변수를 선호하라  
   04. 마지막 예  
   요약  
	
PART III. 코드 재작성하기

10장. 상관없는 하위문제 추출하기
   01. 소개를 위한 예: findClosestLocation()  
   02. 순수한 유틸리티 코드  
   03. 일반적인 목적의 코드  
   04. 일반적인 목적을 가진 코드를 많이 만들어라  
   05. 특정한 프로젝트를 위한 기능  
   06. 기존의 인터페이스를 단순화하기  
   07. 자신의 필요에 맞춰서 인터페이스의 형태를 바꾸기  
   08. 지나치게 추출하기  
   요약  
	
11장. 한 번에 하나씩
   01. 작업은 작을 수 있다  
   02. 객체에서 값 추출하기  
   03. 더 큰 예제  
   요약  
	
12장. 생각을 코드로 만들기
   01. 논리를 명확하게 설명하기  
   02. 라이브러리를 알면 도움이 된다  
   03. 논리를 쉬운 말로 표현하는 방법을 더 큰 문제에 적용하기  
   요약  
	
13장. 코드 분량 줄이기
   01. 그 기능을 구현하려고 애쓰지 마라 - 그럴 필요가 없다  
   02. 요구사항에 질문을 던지고 질문을 잘게 나누어 분석하라  
   03. 코드베이스를 작게 유지하기  
   04. 자기 주변에 있는 라이브러리에 친숙해져라  
   05. 예: 코딩 대신 유닉스 도구를 활용하기  
   요약  

PART IV. 선택된 주제들
	
   14장. 테스트와 가독성
   01. 읽거나 유지보수하기 쉽게 테스트를 만들어라  
   02. 이 테스트는 어떤 점이 잘못되었을까?  
   03. 이 테스트를 더 읽기 쉽게 만들기  
   04. 읽기 편한 메시지 만들기  
   05. 좋은 테스트 입력값의 선택  
   06. 테스트 함수에 이름 붙이기  
   07. 이 테스트 코드는 무엇이 잘못되었는가?  
   08. 테스트에 친숙한 개발  
   09. 지나친 테스트  
   요약  
	
15장. '분/시간 카운터'를 설계하고 구현하기
   01. 문제  
   02. 클래스 인터페이스 정의하기  
   03. 시도1: 순진한 해결책  
   04. 시도2: 컨베이어 벨트 설계  
   05. 시도3: 시간-바구니 설계  
   06. 3가지 해결책 비교하기   

   요약  



이책 정리 하고 나서는... 다음 책은 (지앤선) 의 '자바파워툴'  을 정리해봐야지... 
- 이놈은 내용이 많아서 간략하게만 해야겠다... ^^;; 



저작자 표시 비영리 변경 금지
신고
블로그 이미지

[짱가™]

그 두번째 이야기 | 아키텍처에 대한 단상, 그리고 살아가는 이야기 | 대한 민국 아키텍트로 가는 길 | 열정전도사 "짱가|

크리에이티브 커먼즈 라이선스
Creative Commons License


사용자 추가 하다가... 기록.


이전 5.0 대 버전에서의 사용자 추가는 아래같은 설정으로 우분투에서 추가했었다. 

( mysql server setting ) 
$ sudo apt-get install mysql-server mysql-client

root 패스워드 : root 로 설정

sudo vi /etc/mysql/my.cnf
#bind-address = 127.0.0.1 --> 로 처리 

sudo /etc/init.d/mysql restart
mysql -u root -p

use mysql
select host, user from user ;

#사용자추가
INSERT INTO user (Host, User, Password) VALUES ('%','root',password('root'));

INSERT INTO user (Host, User, Password) VALUES ('localhost', 'myuser', password('myuser'));



그런데 5.5 버전에서는 이외의 필드들이 모두 필수가 되었는지 insert 가 되지 않는다. 

http://blog.naver.com/lawofbest?Redirect=Log&logNo=100140706664

블로그를 참고하고... 

아래의 사용자 추가 명령으로 사용자를 추가. 


create user 'myuser'@'%' identified by 'myuser';

grant all privileges on *.* to 'myuser'@'%';



mac 에서의 설치는 http://j07051.tistory.com/377  를 참고. 



저작자 표시 비영리 변경 금지
신고

'개발의 즐거움 > 개발환경설정' 카테고리의 다른 글

mysql5.5 초기 설정(사용자추가)  (0) 2012.07.12
HTTP 1.1 status codes  (0) 2008.10.10
Document 생성하기  (0) 2008.08.20
블로그 이미지

[짱가™]

그 두번째 이야기 | 아키텍처에 대한 단상, 그리고 살아가는 이야기 | 대한 민국 아키텍트로 가는 길 | 열정전도사 "짱가|

크리에이티브 커먼즈 라이선스
Creative Commons License


일을 하면서 대화를 하다보면 최초에 이야기 한 것과 달라져서  당황해 하는 나를 발견할 때가 있다.


우리가 어떤 일을 처리하거나 서로간의 대화를 통해서 이야기를 풀어나가는 프로세스를 분석하고 싶어졌다.


나는 프로그래머다. 

정확한 정보가 없으면 솔루션을 제시할 수도 해결의 단초를 생각하기도 힘들다.

때로는 해결책을 겨우 생각해 내고 이야기를 진행해 가는데 진행하다보면 전혀 다른 문제여서 접근법을 달리 해야 한다는 생각이 들때 당황하면서 상대를 질책하게 된다.

그렇기 때문에 Garbage in garbage out 의 규칙에 생각조차도 얽매여 있는 것 같다는 생각이 든다.


반대로 컨설팅 및 멘토링의 프로세스는 무언가를 꺼내어 놓을 지 모르는 상대방을 탐구하고 상대방과 대화를 하면서 욕구를 끄집어 내는 것을 먼저 진행한다.


엔지니어로서의 내 대화법 및 사고 방식은 전자를 많이 따라가다 보니 지인들과의 문제 해결에 대한 대화를 나누다가 충돌할 때가 가끔 있다. 나도 모르게 상대방을 질책하고 있다.

충분한 정보를 주지 않아서 전혀 다른 곳으로 방향진행이 되고 있었기 때문이다.

상대에게서 올바른 정보를 얻어내려면

배경/목적/환경/현황 등을 명확하게 이야기 해야 답을 얻을 수 있다는 생각을 함으로써 일어나는 일들이다.


그런데 내가 너무 기계 혹은 컴퓨터 적인 사고에 빠져서 살고 있는 건 아닌가? 하는 생각이 들었다.

원래의 내 성향(잔소리 많은) 이 좌우 했겠지만,

고기를 직접 잡아 주는 것 보다는 같이 접근해 나가는 방향을 선호하는 성향도 좌우했겠지만,

그것보다 먼저 말한대로 사고/접근법 자체가 사람을 대하는 컨설팅/멘토링 의 형태가 아닌

input 을 통한 output 을 도출해 나가는 데에 너무 익숙해서 일어나는 일이 아닐까 싶은 생각이.. 번뜩....


고민해 볼일이다.

저작자 표시 비영리 변경 금지
신고
블로그 이미지

[짱가™]

그 두번째 이야기 | 아키텍처에 대한 단상, 그리고 살아가는 이야기 | 대한 민국 아키텍트로 가는 길 | 열정전도사 "짱가|

티스토리 툴바