System Compleat.

Business Trip to US of A, MAR '11

Stories
( younjin.jeong@gmail.com, 정윤진 )


이야기를 시작하기에 앞서 먼저 기분 좋게 사진을 찍을 수 있게 카메라를 협찬해 준 준호형에 무한 감사한다.
원두막쓰리의 촬칵 소리는 무섭게 생긴 코쟁이 아저씨들의 주목을 받게끔 해주기도 하고, 차량 주차시에도 언제나 백팩에 넣어서 메고 다녀야 안심이 될 정도로 챙겨야 제맛인 이 카메라 덕분에 여기에는 공개하지 못하는 사진을 재미나게 많이 찍었던 것 같고, 또 앞으로도 찍을 듯 하다.  귀국하면 갈비찜 고고.

어쨌든,

최근 클라우드 관련 일을 꽤 깊은 레벨에서 손을 대고 있는데, 이번에 팀장님께서 San Jose 에서 진행되는 Cloud Connect Event 에 참가해서 이것 저것 좀 들어보지 않겠냐고 제안을 주셔서 3월 5일날 KE 023 편을 통해 미국에 오게 되었다.  작년 겨울에도 와 보았던 SFO 였지만, 이번에는 겨울이라기도 좀 그렇고 봄이라기도 좀 뭐한, 그런 상태랄까.

첫날 오전 9시 좀 넘어서 랜딩했을때의 날씨만 해도 영상 10도로 참 좋았는데, 저녁부터는 비가 부슬부슬 내렸다.  도착하자 마자 차를 렌트했는데, 한국 면허증과 여권만 가지고도 렌트가 되는게 참 신기했다는.

팀장님과는 다른차로 미국에서 처음 운전 하는데다가,  목적지가 San Francisco 의 다운타운에 있는 Yang Sing 이라는 딤섬집이어서 찾아가는데 제법 고생했다. 미국 네비게이션은 참 처음 보면 익숙해 지기 쉽지 않은데, 게다가 이놈의 물건이 좀 복잡한 골목길에만 들어가면 길을 잘못들었네 어쩌네 하면서 사람 진을 뺀다.  한국에서와 같이 네비를 맹신하면 고생길이 훤하고, 그래도 Street 나 Avenue, 이런 주소체계는 대충 알아야 헤메지 않을 것 같다.
게다가 주차장에는 차가 또 어찌나 많던지. 차를 대려고 여섯바퀴는 뱅글뱅글 돌다가 간신히 나가는차 기다려서 주차.

아무튼 도착한 딤섬집은 사진은 없지만 딤섬이 정말 맛있었다는.  정신적으로 너무 지쳐서 사진을 찍지 않은것이 이제와 아쉽다는.

그러고 나서 호텔로 옮겼다. 호텔을 운전으로 찾는것도 나에겐 쉽지 않은 일이었달까..  그래도 재미는 있었다.
본의 아니게 신호위반 하고 나서 경찰이 있는지 없는지 두리번 거리기도 하고, 일방 반대편으로 깜빡이 넣고 기다리고 서 있는데 지나가는 운전자들이 날 보고 웃는걸 보고 나서야 실수 하지 않았던 것 등.  옛말 틀린거 하나 없다.

"길 모르면 초보운전"


그러고 도착한 호텔.   The Westin San Francisco Market Street

Hotel Lobby



입국심사가 생각보다 일찍 끝나는 바람에 점심도 너무 일찍 먹게 되었고, 그러는 바람에 3시인 호텔 체크인 시간까지 기다려야 했다.  그래도 배가 부른 상태여서 다행이었던듯.  혹시나 이 호텔에 묶으시려는 분이 있다면, 차를 렌트해서 가지고 갔을때 주차비가 제법 비싸다.  보통 호텔 투숙객에게는 그냥 주는 경우가 많은데, 여기는 24시간에 $60 정도.
대신, 호텔 정문 맞은편에 Office Depot 건물 뒷편으로 주차 타워가 있는데, 여기는 하루에 $20 정도이므로 비용이 부담이 된다면 주차 타워를 이용 하는것이 좋겠다.


Westin San Francisco Market Hotel, Room 1225



방은 12층 25호가 배정 되었는데, San Francisco 가 한눈에 시원하게 보이는 넓은 창이 있어서 매우 좋았다.
다운타운에 있는 호텔 치고도 방이 제법 넓었고, 소파와 의자, 그리고 커피메이커 등이 비치되어 있다.  다만, 힐튼이나 쉐라톤에는 그냥 물이 2병 정도 제공 되는경우가 많은데, 여기는 모두 구매해야 했다.  호텔에서 잠깐 걸으면 바로 CVS 같은 편의점이 있으므로 필요한 물품은 거기서 저렴한 가격에 조달.


Westin Market Street Hotel

Westin Market Street Hotel

Westin Market Street Hotel



방의 분위기는 대충 저런 느낌이다.  신혼부부, 연인 딱 2명이 아주 편하게 쉬다 올 수 있는 방인듯.

저녁을 먹으러 나갔어야 하는데, 시차때문인지 너무 피곤해 져서 밖에서 물과 마실것을 좀 사온 후 저녁에 맥주 3병을 마시고 완전 기절해 버렸다.  결국 시차적응 1일차 실패 ㅠㅠ

이 맥주는 작년에 왔을때도 마셨던 맥주인데, 그 맛이 꽤 좋아서 한국에서도 찾아 봤는데 파는데가 잘 없었던 것 같다.


Blue Moon


 

자는데 비가 부슬부슬.
역시나 7시 정도에 어설프게 잠들은 탓에 새벽에 깨어나 버리고 말았다.

자는걸 포기하고 커피한잔 내려 마신후에 넷질.


Rainy SFO



주르륵 주르륵 이라기 보다는 보슬 보슬 이라는 표현이 맞을 정도의 비가 하루 종일 내렸다.
가랑비라기엔 좀 굵은.


팀장님 가족과 함께 아침식사 하러 차이나 타운 쪽으로 가는길.  아마도 Broadway 674 번지의 중국식 레스토랑이었던 것 같은데, 죽이 일품인 집이라고 하셨다.

Toyota Hybrid


차는 토요타의 프리우스였는데, 하이브리드 차는 이번이 처음이었다.  생각보다 잘 나가는 듯 하고, 엑셀 반응이 조금 느리단다.  시동이 걸리고 꺼지는건 잘 느끼지 못할 정도였는데, 내가 탔던 니산의 알티마 하이브리드는 지 맘대로 시동을 껐다 켰다 하는게 격하게 느껴질 정도였달까.  아무튼, 실내 구조가 매우 혁신적으로 생기기도 했지만, 연비를 생각하면 정말 괜찮은 차 인듯.  고속도로에서는 10대가 지나가면 2대는 이 차량일 정도로 많이 돌아다니고, 요트가 있는 부촌에도 종종 있는걸 보면 장거리에는 이만한 대안이 없는 것 같다.


Chinese Donut


중국식 도넛이라고 하는데, 제법 맛있게 먹었다.  맛은 뭐랄까, 어머님이 어렸을때 집에서 해 주시던 도넛인데 그 중에 실패하셔서 다소 기름기도 있고 설탕맛도 달달하게 나는, 뭐 그런 맛? 크기가 꽤 커서 혼자 저거 3개 다먹으면 배가 금방 불러 올 것 같다.

뭔가 만두 국수



이것은 국수에 만두를 넣은건지, 만두국에 국수를 넣은건지는 모르겠지만,  면의 맛이 일본이나 한국의 것과는 매우 달랐다.  뭐랄까, 국수를 한번 더 튀겨서 삶았다는 느낌?  쫄깃 하다기 보다는 뭔가 군대에서의 쌀국수가 엄청 고급스럽게 되면 이런 식감이랄까. @_@;;;

만두는 안먹어 봤는데 맛있을 것 같았다.


뭔가 죽


음.. 내가 기억하지 못하는 음식 이름은 비단 이탈리아 음식만이 아니었나보다.  @_@;;
얘는 미트볼과 돼지의 간이 들어있는 죽인데, 죽의 맛이 꼭 닭 백숙 다 먹고 난 후 넣어 먹는 죽의 맛과 매우 비슷했다.
고소하고 의외로 담백해서 맛이 좋다는.  미트볼은 일반적으로 생각하는 그런 것이고, 간이 문제인데 생 간을 삶아서 요리 한듯.  순대에 들어있는 간 보다는 훨씬 수분이 많고 생고기 같은 느낌이다.  역시 맛있다.



식사 후에는 샌프란시스코의 몇몇 명소들을 돌아다녔다.  여기는 뭔가 꾸불텅 꾸불텅한 길이 있는 곳인데, 비가오는데도 관광객이 많아서 사진 찍기가 쉽지 않다.  언덕배기에 있는 길이라서 사진을 위에서나 아래에서 찍을 수 있는데, 위에서 보다는 아래에서 찍는게 더 잘 나올 듯.

그리고 미국에서의 주차는 참 이게 뭐랄까.  차 잘못 주차하면 견인은 시간문제랄까. ;;
잘 보고 주차 해야 한다.  그래도 뉴욕보다는 차대기가 좀 나아 보이는건 사실.




비가오는 바람에 날이 흐려서 사진이 망했다. ㅠㅠ  아무튼 이건 아래쪽에서 찍은 사진.
나중에 이름을 검색하게 되면 업데이트~


비가와서 다소 어둡고, 언덕이 많아서 언덕 꼭대기에 있는 고층 건물은 안개속에 잠겨있는 경우가 많았다.  오래된 양식의 건물이 있는 지역은 가끔 보면 참 뉴욕스러울 때가 있는듯.  뭔가 음침해


Union Square 에 가기 위해서 주차 후 엘레베이터.  가끔 미국 엘레베이터를 타다 보면, 여기는 철의 왕국인가 싶을 때가 있다.  우리 나라나 일본의 엘레베이터는 굉장히 만듦새가 오밀조밀하고 견고한 듯 한데, 미국은 그냥 대강대강 철을 썩뚝썩뚝 잘라 만들어 낸 것 같은 느낌.



지하 주차장. 주차장 정산기는 자판기 형태로 된 것이 대부분이다.



여자친구가 쇼핑을 좋아하는데 주머니 사정이 별로 좋지 않다면 절대 피해야 할 관광지.  있을만한 명품 매장은 다 이 근처에 있다고 보면 된다.  하지만 정작 빌딩들은 토요일에 11시 이전에는 열지 않는다고 해서 들어가 보지는 못함.



샌프란시스코 하면 또 떠오르는게 이 전기선 매달고 다니는 버스.  스파이더맨이 샌프란시스코 오면 이 전기선때문에 아마 생존이 힘들지도 모르겠다 라는 뻘생각을 해본다.



유니온 스퀘어 근처의 쇼핑단지들. 토요일에는 사람이 참 많았는데 일요일에는 비가 오기도 하고, 또 워낙 이른 아침이기도 해서 사람이 별로 없었다.



미국 도심의 교통신호는, 뭔가 잘 되어 있는것 같으면서도 허술하다. 좌회전 신호는 있는데도 있고 없는 곳도 있고, 또 좌회전이 없어서 눈치껏 갈려고 보면 횡단보도에 사람들 건너고 있고.  비보호 좌회전이라는 사실을 한참 뒤에 알았다는..




Fisherman's Wharf 로 이동, 엄청난 크기의 게모양, 거북이 모양 등 각종 해산물 모양의 빵을 만드는 빵집.
이곳은 비가 제법 오는데도 많은 관광객이 있었다.  근데 난 여기가 대체 왜 유명한지 모르겠다는.

속초의 대포항 정도의 느낌이랄까.. 물론 그거 보다야 한 스무배는 크겠지만.;;;



어느 노부부의 관광.  또 모른다. 어디 누군가의 요트 주인인지도.



연을 파는 상점도 있었다.


뭔가 꽃.


정박중인 어선 및 요트들.  여기 노을지면 참 멋있는데 비와서 다 망했음. ㅋ
돈벌어서 샌프란에 요트와 별장 하나만 있으면 참 좋을건데.



어느 도시를 가던지 I Love 어디 티셔츠는 다 있는 것 같다. Atlantic City 에도 있었고, NY 는 유명하고.
다른 도시도 있을 듯.



내가 사랑하는 포레스트 검프에 나왔던 "버바 검프" 새우 회사의 상표.
전에 진님한테 물어 봤는데 이거는 그냥 만들어 둔 거란다.  그런 회사는 없다는 말. ㅋ

우리나라에서도 검프처럼 살면 성공 할 수 있을까?  난 불가능하다고 생각 함.



"더 락" 의 배경이 되었던 알 카트레즈 교도소.  여객선을 운항해서 관광이 목적이라면 구경다녀와도 좋을 듯.
이 섬은 Golden Gate Bridge 에서도 보이고, Bay Bridge 에서도 보이고, 여기 Fisherman's Wharf 에서도 보인다. 뭐, 바다 한가운데 쯤 같다는 말.




병따개.  병맛인 애들은 따줘야 제맛이지만... (응???)



난 이런 티셔츠 참 좋아하는데, 뉴욕보다는 좀 그 종류가 많지는 않아 보인다.
뉴욕에서는 남자나 여자 속옷에 써있는 재미있는 글귀들, 또 티셔츠에도 그런 것들이 많아서 쇼핑하다보면 즐거울 때가 많다.  아, 물론, 뉴욕에서 산 그런 셔츠들을 뉴욕에서 입어주면 웃긴다. 

하나 생각나는건, 커다랗게 써 있는 FBI 아래에 ( Female Body Inspector ) 라는 글귀 보고 한참 웃었던 듯.


정박중인 배. 실제 운항하는 페리로 보이는데 어디서 어디까지 가는지는 잘 모르겠다.
실제로 꽤 먼거리를 운항하는 페리도 많은 것 같았다.



샌프란시스코! 하면 떠오르는게 바로 이런 장면이 아닐까 싶다.  물론 저 기차가 언덕에 있어야 제대로지만, 날이 흐려서.
언덕 + 가로수 + 뭔가 엔틱풍의 건물 + 맑은 날씨 + 길바닥을 달리는 경전철 = 샌프란시스코. 이어야만 할 것 같다는 생각.


Golden Gate Bridge


뭐 그랬다. 날씨가 대충 이랬다.
전에 똑딱이 가져왔을때랑은 느낌이 또 다른데, 비가 워낙 와서 다니기도 쉽지 않고.




이때부터는 101번 고속도로를 타려고 Tiburon 이라는 도시 쪽으로 돌아다녔다.  날씨가 맑으면 참 좋았을 텐데, 뭐 날씨 좋은날 사진은 엽서로 많으니까 하는 위안을 삼아본다.



새우깡 있었으면 이 오빠를 사랑하게 되었을 텐데.

이렇게 돌고 돌아 San Jose 근처의 Sheraton 이 있는 Milpitas 라는 지역으로 왔다. Fisherman's Wharf 에서 출발한게 약 오후 2시 40분 정도였는데, 중간에 두세군데에서 잠시 정차했다가 Milpitas 라는 지역까지 오는데 길을 또 헤메고 그래서 오후 6시 정도에 도착하게 되었다.  생각 외로 한적하고 또 주변 경관도 잘 조성되어 있는 데다가, 방도 매우 좋아서 나중에 결혼하면 이런 코스로 신혼여행 해도 되겠다 라는 생각이 들 정도였다.


자고 일어나니 날씨가 정말 좋았다.  어제까지의 비내리던 추적한 날씨는 어디갔어 할 정도로.



방에 딸려있는 베란다(?) 에서의 광경.  한산해서 참 좋다.
 


방의 창문을 열고 나가면 있는 의자.  이런 따뜻한 아침에 연인과 간단한 아침과 커피를 여기 앉아서 먹는다면.
하지만 난 출장으로 혼자 있으므로 무효.



날씨가 너무 좋아서 주차장으로 한바퀴 돌았다.  아마도 투숙객들이 모두 타지에서 와서 그런 탓도 있겠지만, 일본차들 참 많다.  거의 다 렌트카일 거라는 생각.



이렇게, 월요일의 아침이 밝았다.  KE 023 도 그렇고, 미주행 비행기는 기본 9시간 이상이라서 이게 이코노미로 다니면 스트레스가 장난이 아닌 듯. 게다가 왼편에는 인도에서 오신듯한 할아버님이 뭔가 알아 듣기 힘든 영어로 계속 물어보고 말 시키시는데 참으로 난감스럽더라는.

오늘부터, Cloud Connect Event ( http://www.cloudconnectevent.com ) 이 시작이다.


몇일 있으면 다시 돌아가서 정신없이 지내겠지만, 출장중에 이렇게 까지 돌아다니기 힘든데 기회가 되어서 다닐 수 있었던 조건들에 감사한다.  개인적으로 정신 없었던 것도 있긴 했지만, 뭔가 나를 정신 차리게 만드는게 있는 것 같은 기분.


커피 한잔을 내려서 설탕 두봉지에, 노트북을 끼고 USA Today 를 테라스에서 읽고 있는 내가 웬지 다른 인생에 들어와 있는 기분이 들어 묘하게 좋은 아침이다.

( younjin.jeong@gmail.com , 정윤진 )

엉망으로 사는 이야기

Stories
( younjin.jeong@gmail.com , 정윤진 )


Starbucks, Tokyo

Starbucks, Tokyo




클라우드네 쉐프네 하면서 2010년을 정신없이 보내고 보니 어느덧 새해가 밝은지 50일도 넘어 버렸다. 
어째 연말 정산은 매년 토해내기만 하는지 일하는 것 말고는 정말 어느것 하나 재주가 없나보다. 그 흔한 신용카드 한장 없이 살면서 부지런히 체크카드를 사용하고 있지만, 타고난건지 언젠가부터 생긴 트라우마 때문인건지 한번씩 우울증이 도지면 몸 상해 가는일에 돈 써버리기도 부지기수. 

작년 연말 부터 뭔가 스텝이 하나 둘 꼬이는 기분이 들더니, 이제 이 꼬였던 모든 것들이 결실을 이루려는지 뭔가 전방위적인 압박감을 느끼면서 지내고 있다.  굳이 그 실체가 있는 것은 아니지만 오랜만에 해 보았던  연애의 실패, 그로인한 충격, 회복에 걸렸던 되돌이켜 보면 언제나 무의미하게 보낸 부지기수의 시간들, 그리고 회의.

28살 때까지만 해도 내인생에 후회란 단어는 없게끔 매 순간 최선의 선택을 하면서 살도록 하겠다 하며 호언 장담을 하곤 했고, 또 그때 까지는 그런식으로 살아 지는 듯 하더니, 이게 삼십줄을 넘기면서 생긴 개인적 일들이 모두 후회 투성이다. 

물론 일이야 매번  빠지면 정신을 못차리고 끝낼 때 까지 달리는 성격이라 큰 문제는 없고, 또 그런 방식의 삶이 가져다 주는 경제적 및 개인적 자부심을 채워주기엔 충분 했지만, 일 이외의 모든 것들에 나이를 먹어감에 따라 자연히 생겨야 하는 센스들이 없다보니, 이건 뭐 겪는 일 마다 경험으로서 데이터베이스 화 되지 않고 오히려 트라우마 꺼리만 계속 재생산 해 내는 천부적인 능력을 가지고 있지 않나 하는 의심이 들 정도로 악재가 겹치고 있달까. 

주말까지 끝냈으면 하는 원고가 있음에도 불구하고 어제 밤 간밤에 들이 부은 술 탓인지 정말 오랜만에 진지하게 사랑이라는 오글거리는 주제를 생각해 보았다.  그래, 일 말고는 다른 재주는 없다손 치더라도, 이 사랑이란건 자주 새드엔딩을 보게 되더라도 매번 이번엔 해피엔딩으로 마무리 해야지 라는 기대로 살아가야 하건만,  남들 다 잘하는 듯 보이는 연애라는 주제가 왜 나한테만 오면 엉망이 되는지와 함께 혼자만의 생각의 결과는. 

"상대에게 마음을 너무 주고나서, 그 감정의 속도를 주체하지 못해 스스로 붕괴하곤 한다." 

왜, 모든걸 자신에게 맞게 알아서 해 주기를 바라면서 또 자신만을 좋아 해 주기를 바라면서, 또 그렇게 해 주면 좋아하면서 넌 너무 생각이 많아 라는 말을 들어야 하는지 이해가 잘 안되곤 했다.  

솔직히 아직도 그런건 잘 모르겠다.  다음번에 사람을 만나게 되더라도 그렇게 되지 않을 거라는 자신도 없다.  아마도 내게는 이런식으로 맞는 사람이 없거나 아니면 내가 너무 이상해서 잘 될 수 없거나 하겠다 라는 정도의 결론이랄까. 

사랑에 실패한 후에 자빠져 있는 시간이 길면 길 수록 결국 내 손해인 것 같다.  누구도 도와줄 수 없는 부분이기도 하고, 슬퍼하고 있는 대신 다른 무언가를 열심히 하는것이 더 좋은 나중의 상황을 만들 것이다 라는 생각은 점점 더 강하게 든다. 
이제껏 그렇게 살아왔고, 앞으로도 나의 그런 부분들은 변하지 않을 것 같지만 한가지 확실한 점은 보다 무덤덤하고 보다 평소처럼 안정되게 살아갈 때 더 많은 기회가 있을 것이라는 점과,  이제는 누구 하나 때문에 다른 사랑 못할 것 같다 하는 감정보다는, 원체 못하는 거라 자주 해 봐야 괴로워 할 시간들만 늘어날 거라는 점에서 가급적 안하고 싶다. 

나 스스로도 돌보지 못하고 심적 평정을 찾지 못하는데, 다른 누가 무슨 소용이 있으랴. 

적절한 시기가 올 때 까지 그저 스스로를 가다듬고 하던일 더욱 열심히 하며, 자동차나 기계 그리고 평소에 관심이 많은 것들에 보다 신경을 쓰면서 살고 싶다.  물론 한번씩 찾아오는 우울함을 다스리는게 쉽지 않겠지만, 비오는 날 쇼팽과 함께 드라이브라면 괜찮을 것 같다는 기대를 해 본다. 


등록금이다, 구제역이다, 이런 저런 일로 흉흉한게 많아서 그냥 살아가기에도 빠듯하고, 젊은이들이던 가장이던 목숨걸고 살아가야 하는 세상이다.  게다가 내가 제일 싫어 하는 짓거리 중에 하나가 죽은자식 불알 만지는 행동 아닌가.  
못하는건 못하는거고, 아닌건 아닌거다.  생각이 많아도 침묵이 금이라는 격언을 실천해 가며, 나의 30대를 잘 다듬어 40대를 준비해야 겠다. 

그리고, 당연한 말을 써 두어야 할 것 같은 말은, 어떤식으로든 여기씌여진 감정으로 나와 엮였던 분들께 감사드린다.  종국에야 당연히 힘들게 되었지만,  온전한 정신을 다해 사랑 할 수 있었던, 그래서 행복했던 시간들 까지 부정할 필요는 없으니까. 


이런 글, 3년에 한번 쯤은 쓰는 듯.  Cloud Connect 준비나 해야지.  ( http://www.cloudconnectevent.com/ )
아, 물론 이 아래의 짧은글을 읽고 손발이 오글거리게 되는건 저의 책임이 아님을 미리 밝혀두는 바입니..;; 

Wired Man



- 고문 - 

수 많은 새드 엔딩 너머에 
단 하나의 해피 엔딩이 
한 개인의 연애사 라면 

그것 만으로 삶은 
충분히 잔인하지 않은가. 

하지만 더 가혹한 진실은 
지금 만들고 있는 인연이 
해피엔딩일 거라 
굳게 믿어야 한다는 것. 



- 노비 - 

네게 빠져들면서 
완벽하게 노예가 되었지만 
능숙하게 복종하지 못했다. 

지리한 기다림에 순종하는 것이 
고달픈 그리움에 좌절하는 것이 
실패의 씁쓸함에 후회하는 것이 
버려진 노예의 숙명이란 걸 
알았더라면. 

스쳐지나는 목소리 하나 
스쳐지나는 눈빛 하나 
스쳐지나는 향기 하나 

그런 것들이 
훨씬 더 고통 스러울 것이란걸 
알았더라면. 

낙인을 거부 할 수 있었을까. 



- 망각 - 

담배 타 들어가는 소리가 요란하다. 
운전대의 차가움에 손가락 마디마다 시려온다. 
귀에 거슬리는 라디오의 시시콜콜한 대중가요. 

잊게 되기를 바라진 않는다. 다만, 
조금 덜 자주 생각 났으면 하는 바람 뿐. 

시간이라는 모호한 조력자의 도움은
기억이라는 생물 본연의 영역으로 
손길이 미치지 않는가 보다. 



( younjin.jeong@gmail.com , 정윤진 )


HPC in the KT Cloud, and CHEF

Techs
( younjin.jeong@gmail.com, 정윤진 )


개인적인 사정과 몇몇가지 머리 복잡한 일들이 최근에 겹치게 되면서 블로그에 많이 소흘했었다. 지난회에 연재하기로 한 Chef 코드도 작성하다가 말아버리고 끈을 놓아 버리게 되어서 다시시작하려면 한동안 시간을 투여 해야 본 궤도에 올릴 수 있을 것 같다.  뭐, 그다지 어려운 코드들은 아니지만...

뭐 쉬어가는 페이지 처럼, 금일은 조금 뚱딴지 같지만 조금 있으면 런칭될 KT 의 클라우드 서비스가 잘 사용될 수 있을만한 분야 중 하나를 소개하고자 한다.  구체적인 런칭 일자가 언제일지는 모르겠지만, 아마존의 EC2 와 비슷한 스타일의 컴퓨팅 클라우드를 제공 할 예정이다.  물론, 여기서 소개하는 내용은 아마존 EC2 에서 사용 될 수 있거나, 이미 사용 되고 있는 내용이다.


우리가 주변에서 쉽게 접하지만 실제 일반 고객에게는 잘 알려지지 않은 분야들 중에는 굉장히 높은 컴퓨팅 리소스를 요구하는 분야들이 있다.  이를 테면 "쿵푸팬더", "슈렉" 등과 같은 3D 실사 애니매이션이라던가, 수집돤 온도, 습도, 대기압 등의 자료를 기반으로 수학 모델로서 시뮬레이션 하는 일이라던가, 정유/화학 또는 신소재 개발 부분등에서 사용되는 분자/화학 시뮬레이션 및 기타 전통적으로 컴퓨터가 사용 되어야만 하는 모든 분야들이 소위 말하는 HPC , 즉 High Performance Computing 의 범주로 넣을 수 있는 분야들이겠다.  

기존의 일반적인 서비스 시스템을 사용하는 기업 입장에서도, 또 위와 같은 일반적이지 않은 시스템을 구비하고 있는 기업 입장에서도 클라우드는 매력적일 수 밖에 없다.  전자에게는 기업이 직접 운용 하는 것 이상의 시스템 가용성과 확장성을, 후자에게는 단시간 내에 저렴한 비용으로 최대한의 컴퓨팅 파워를 얻을 수 있는 점이 바로 그렇다.  이전에는 기상청에서 슈퍼컴퓨터를 어마어마한 규모의 비용으로 구매를 해야 했지만, (라이브러리 및 기존 어플의 포팅이 가능하다는 전제하에) 이제는 시간당 몇백원 또는 몇십원 하는 클라우드의 인스턴스를 계산에 필요한 시간만큼 필요한 수량으로 생성하여 계산에 사용하고, 종료 되면 인스턴스를 끄거나 지워 버리면 된다.  Compute Node 는 그 자체로 이미 Temporary 한 성향을 가지고 있기 때문에, Master Node 및 계산 결과 등이 저장되는 노드를 적절히 배치 하였다면 이런식의 저렴한 컴퓨팅 파워의 사용이 이롭지 않을리가 없다.

실제 이러한 HPC 컴퓨팅의 특성은 다음과 같다고 할 수 있다.

1. 시스템 구조적 모델이 비교적 단순하다.
2. 결과값을 만들어 내는 어플리케이션의 최적화에 효율성과 비용이 연계되어 있다.
3. 시스템적 구조 보다는 컨텐츠 ( 계산식 또는 렌더링 하게 될 Scene ) 가 매우 중요하다.
4. 어플리케이션에 따라 컴퓨팅 노드에 요구되는 구조가 다를 수 있다.


또한, 이러한 HPC 클러스터들은 단순하게 보면 다음의 구조적인 공통점을 가지고 있다.

1. Job Queuing 또는 Job Orchestration 이 중요하다. 보통 이런 역할을 담당하는 노드를 마스터 또는 메인노드라 한다.
2. 마스터 노드와 연계되어 실제 죽어라 계산만 담당하는 컴퓨팅 노드들. 컴퓨팅 노드의 적절한 수량 산정 및 필요에 따라 MPI 와 같은 형태로 컴퓨팅 노드간에 적절한 수량으로 클러스터를 구축 해 줄 필요가 있을 수 있다.
3. 결과 값을 저장하기 위한 공용 스토리지.
4. 어플리케이션에 따라 결과값을 파싱하여 Db 화 할 필요가 있을 수 있다.

위에서 이야기한 기능을 구현하기 위해서는, 고전적인 베오울프 프로젝트를 따라해 보자면 다음과 같은 것들을 준비해야 했다.

0. 계산에 필요한 물리적 서버. ( 필요에 따라 수십 ~ 수백 또는 그 이상 )
1. PXE Boot / DHCP
2. system image ( Optimized for application / Hardware )
3. Bootstrap
4. NFS / DB / PBS like Queuing System.

다른 것들은 고사하고 물리적 서버의 준비에 어마어마한 비용이 들어간다는 것은 잘 알것이다.  여기에 각종 라이센스.

분자/화학 분야에서 사용되는 어플리케이션의 경우 예를 들기가 다소 곤란하므로 일반적으로 생각 할 수 있는 렌더링 팜이나 MPICH 클러스터, 또는 HDR ( High Dynamic Range ) 이미지를 수만장을 생성/ 자료화 해야 하는 경우등을 생각 해 볼 수 있겠다.  시스템의 구조가 단순하며, 동일 목적의 노드가 많은 동시에, 해당 노드들의 라이프 사이클이 짧고 재사용성이 요구되는경우, 우리는 이러한 시스템의 구현에 무엇을 생각 할 수 있는가?  바로 그렇다. 자동화 툴, Chef.
물론 CFEngine 이나 다른 툴을 사용하여도 무방하다.  다만 나는 Chef 가 편하기 때문에. 
이러한 경우에는 심한경우 Cookbook 1개로도 처리가 가능하다.


예를 들자면, 일반적으로 많이 사용되는 3Ds MAX 의 경우, Windows 만을 지원한다. ( WINE 은 접어두도록 )  물론 내가 지금 3DS MAX 의 라이센스를 가지고 있는 것은 아니어서 스크린샷을 찍게 되지는 못하겠지만, 보통 다음의 순서로 환경의 구성이 가능해진다. ( MAYA 및 기타 다른 툴도 대부분 동일한 구성 )

0. 렌더러 및 배치 또는 큐잉 또는 오케스트레이션 설치 및 설정을 위한 Chef 코드 및 서버를 준비한다.
1. 돈내고 Instance 를 필요한 수량만큼 만든다.
2. 작업용으로 사용하는 워크스테이션에 VPN 환경을 구성한다. 물론 서버는 클라우드 안에 있다.
3. 생성된 인터페이스에 Chef 구동을 위한 환경을 준비한다.
4. Computing 노드에서 적절히 Chef 를 구동한다.
5. 사용한다.

위의 0 ~ 5 와 같은 작업은 만약 3D 툴로 Blender 를 사용한다면 쉽게 오픈소스만으로 구성이 가능하다.
렌더링 팜이 아니라, 계산식을 위한 노드의 사용으로서도 위의 0~5 의 시스템 구성 순서에는 큰 차이가 없다.

예전에는 1대의 워크스테이션을 구매하여, 포트폴리오 또는 양질의 영상을 만들기를 원하는 개인 또는 영세 사업자가 1분 이상의 동영상을 만드는건 굉장한 일이었다.  렌더링 시간을 위해 프레임을 아껴야 했고, 플러그인 등 각종 화려한 기법들을 눈물을 머금고 삭제해야 했으며 그렇게 힘들게 만들어낸 영상은 당연히 맘에 들지 않을 수 밖에 없었다.  어마어마한 비용과 쓰러지는 감가상각비를 가진 서버로 구성된 렌더링 팜을 소유하는 대신, 이제 쉽게 "클라우드" 라는 자원을 활용함으로서 약간의 지식만 있으면 수억원을 들이지 않고도 양질의 결과를 얻게 될 것이다.

실제 서비스를 런칭 해 보면 알 일이지만, Amazon 의 EC2 와 같은 컴퓨팅 서비스가 국내에 대규모로 런칭 되는것은 매우 환영할 만한 일이다.  물론 기존의 호스팅 업계에서는 문제가 될 수 있긴 하겠지만,  개인 및 각 기업의 다양화 되어있는 서비스 요구사항을 충족하기에는 기존의 호스팅이 다소 버겁거나 제한적인 요소가 있어왔던 것도 사실이기 때문에, 충분한 성능및 사용성에 대한 부분들만 검증 된다면  많은 기업에 비용을 획기적으로 줄일 수 있는 서비스가 될 것이기 때문이다.

다만, "오~ 클라우드 죽이는데" 하는 태도로 자신들의 솔루션에 대한 검토없이, 즉 마이그레이션에 대한 사전 준비 및 고려 없이 무작정 달려든다면, 분명 2중으로 지출되는 비용에 클라우드는 마법의 양탄자가 아님을 깨닫고 물러서게 될 수 밖에 없다.  마찬가지로, HPC 에는 수많은 어플리케이션이 있고, 경우에 따라서는 그 구조 자체가 다소 복잡 해 지거나 추가적인 어플리케이션의 개발이 필요 할 수 있다.  이런점을 모두 인지 하고 가능성을 충분히 검토한다면,  클라우드는 저비용, 고성능, 고가용성으로 사장님 및 팀장님을 미소짓게 만들 수 있을 것이다.


위에서 대략 설명한 내용들에 대한 구성을 실제 문의 받고 싶다면, 본 블로그에 적혀진 메일 주소로 이메일 주시면 가용한 범위 내에서 충분히 설명 드리겠다.


다음의 Amazon EC2 페이지 참조 및 관련 Case Study 를 찾아보면 많은 자료를 얻을 수 있다.
http://aws.amazon.com/ec2/hpc-applications/

NASA JPL  Image Processing in the Cloud
http://aws.amazon.com/solutions/case-studies/nasa-jpl/

Ushering Biotech Firms into the Cloud ( from hpcinthecloud.com )
http://www.hpcinthecloud.com/blogs/Ushering-Biotech-into-the-Cloud-115020599.html?utm_source=twitterfeed&utm_medium=twitter

설명 하려던 바와 비슷한 형태의 HPC 솔루션
http://www.cyclecomputing.com/products/cyclecloud/overview

Molecule Related Work case in Cloud
http://aws.amazon.com/solutions/case-studies/pathwork-diagnostics/

그나저나 코드 쓰던거 마저 써야 하는데... 이게 시간이 영...;;;

( younjin.jeong@gmail.com , 정윤진 )

Formula One Kor GP

Hobbies
( younjin.jeong@gmail.com , 정윤진 )


어릴때부터 자동차를 참 많이 좋아했다.  개인적 설명은 뭐 여기서 끝내기로 한다.
그래서 영암에 다녀왔다.  2010.10.22 ~ 24  Formula One, 한국 그랑프리.

Yongam International Circuit



한마디로 정리하자면,  서킷과 서킷에서 이루어지는 그 자체는 최상, 나머지는 모두 최하 였다.

일이 끝나는 금요일밤 부랴부랴 용산 KTX 역으로 향해 밤 9시 반 목포행 열차에 올라 00:40 분 즈음 목포에 도착하였다.
티켓은 J-b 의 나름 가격도 싸고 저속 코너인지라 마음에 드는 사진도 제법 건질 수 있을 것이라는 개인적 분석하에 구한 것이라 비록 연습날인 금요일 관람을 놓쳤을 지라도 예선 경기 및 결선에 대한 기대감으로 충만한 밤을 보낸 후.

금요일에 먼저 영암과 목포 시내를 돌아다닌 친구의 추천대로 오전 11시 즈음 해서 목포의 평화공원인가 하는 곳의 각종 차량/ 슈퍼카 전시장에 갔더니 이런 언니들이 마음껏 포즈를 취해 주고 계셨다. 

평화공원, 자동차 쇼


사진은 좋아해도 평소 많은 사진 클럽에서 언젠가 한번은 뵌 듯한 분들이 줄지어 계시길래 파인더에 담아 보았다.  그런데, 이거 원 평소 포트레이트를 워낙 좋아했던 나에게 D3 와 SB800 , 28-70 렌즈를 들이대자 마자 갖은 표정과 포즈 변화를 주시는 분들을 뵈니 나도 모르게 연사를 눌러 버렸다.   이 외에도 다수의 컷이 있으나 그 사진들은 따로 보정해서 이 분들의 성함을 알게 되는 대로 따로 포스팅 할 예정.

어쨌든 링 스트로보를 가지고 싶다는 강한 열망을 느끼면서 실물로 직접 처음 뵙게 된 분들에 대한 놀라움과, 그분들을 이렇게 사진으로 담아내는 내 자신에 대한 의아함을 뒤로 하고 1시를 조금 넘긴 시각,  영암으로 향했다.


친구의 말에 의하면, 영암으로 들어 갈 수 있는 길은 대략 세군대 정도라고 했으나, 실제 네비게이션에 나타나는 경로는 단 하나 뿐이었다.  아마도 새로 건설한 도로들이 아직 지도 데이터에 반영도 되어있지 않아서 겠지만, 문제는 거의 모든 차량들이 그 도로 하나로 몰리는 바람에 바로 영암 서킷 입구 약 4Km 부근 부터는 어마어마한 정체가 발생하고 있었다.

길바닥에서 거의 한시간 가량을 소비하고 나서 간신히 서킷 근처 삼거리에 다가서니, 이번에는 아예 주차장 진입 자체를 운영 본부와 경찰들이 모두 통제하고 있고, 어이 없게도 서킷-목포방향-또다른길의 세번째 8차선의 도로로 차량들을 안내하여 길바닥에 주차를 하도록 유도하고 있었다.  어마어마한 숫자의 약 800여 미터 정도 늘어선 길바닥 주차 행렬을 보니 한숨부터 나왔지만,  이미 시작된 Qualification 1 에서의 F1 머신 엔진음이 들려오고 있어 마음이 급했다.

어찌 저찌 주차를 하고나니, 이제 서킷 입구 까지 가는게 일인데, 계속 꾸역꾸역 들어오는 차와 사람들을 보고 친구와 나는 서킷으로 가는 길 중 가까워 보이는 지름길을 택하기로 했다.

논두렁 지름길


도저히 돈잔치로 이루어지는 최첨단의 F1 경주장으로 향하는 길이라고 믿어지지 않겠지만, 사실이다.  8차선 길바닥 주차장에서 서킷으로의 지름길은 사진과 같았다.

서킷으로 가는길은 생각보다 멀었다.  대략 50분 정도를 걷다 보니, 이미 Q2, Q3 까지 끝났다는 팀장님의 문자메세지에 길바닥에 주저 앉고 싶었다는.  그나마 투스카니 원메이크전과 그랜드 스탠드 쪽의 여러 컨스트럭터 몰 등을 구경하다가 본의 아니게 땡을 잡은 사건은, 바로 각 선수의 피트 공개였다.

이 피트 공개가 얼마나 큰 사건인지 별 감흥이 없으셨던 분들도 줄 서면서 많았던것 같다.  더구나 마크웨버 등 퍼스트클래스 드라이버들의 사인회 까지 겹쳐 줄은 끝이 없었고..

피트 & 사인회 가는길


어마어마한 새치기 신공이 작렬하는 순간이었다.

내 앞의 어느 국내 레이싱 팀은, 무슨 줄에서 사람이 알을 까는지 두명 세워놓고 정작 들어갈때는 무려 여덟명 여의 인원이 앞으로 들어오는 초유의 사태가 벌어지기도.  게다가 뒤에서 앞으로 일행을 서슴치 않고 호출하기도 하고, 이런 레이싱 팀 뿐 아니라 입구 전반에서 어느틈엔가 슬그머니 삼삼오오 앞서거니 ( 뒤서거니는 없었다 ) 하다보니 짜증이 머리 꼭대기 까지.

뭐 다들 그럴려고 그랬냐마는, 정말 아무렇지 않게 양해 한마디도 없이 멋쩍은 웃음 하나 없이 너무 자연스럽게 앞으로 들어오는 사람들을 보면서 어이가 없었달까.


사인회 중인 마크 웨버



이 사진을 찍으면서 사진기자의 슬픔을 알아버렸다.  "장난 아니다" 라는 말이 뭔지 알고 싶다면, 사인회 중인 F1 드라이버 사진을 찍어 보면 된다.  바로 알게 된다.

여성분은 아마도 레드불 레이싱팀의 홍보 또는 시큐리티 분 이실 듯.  안전을 위해 뒤에는 각종 서포트 인원들이 계셨다.


포디움


포디움은 아직 공사중이었다. 


SC, Safety Car


아마 댁에서 레이스 도중 많은 시간 보셨을 안전 차량.  이 차량은 원래 서킷에 사고가 나거나, 기타 규정등으로 인하여 문제가 발생했을때 레이스 도중 피트에서 튀어나간다.  이 차가 출발하게 되면 머신들은 추월이 불가능하며, 이 차 앞으로 차가 추월 할 수 없다.  나름 서행으로 보여도 이 차 역시 직선/코너 에서 200Km/h 는 거뜬히 뽑아주는 녀석으로, 드라이버도 아무나 타지 않는다.  보통 이 차가 나왔을때 추월이 금지 되므로 랩타임이 뒤쳐져 있던 머신들은 앞차와의 간격을 좁히기 매우 좋으며, 따라서 SC 가 등장한 경우 타이어 등의 교체를 위해 많은 머신들이 피트인 하기도 한다.
단, 피트인 한 차량은 SC 가 한바퀴 다 돌고 두번째 바퀴를 돌거나 또는 피트인 하기 전에 다시 피트 아웃 해야 한다.
이런 용도의 차량은 데이토나 등의 미국식 레이스에서도 접할 수 있다.  보통 SC가 출발하면 서킷의 각 포인트에는 노란 깃발이 나부끼며, 이는 "운행 주의" 또는 "서행" 등으로 인식 될 수 있다.


하지만 난 저 차의 이름을 모르겠다. ㅠㅠ  암튼 디게 빠르고 엔진음 예술이었지만 머신에 비해선 초큼 느리;;;;


Pit of Schumacher


그 이름도 유명한 Mercedes GP 의 미하엘 슈마허의 Pit.  뒤에는 리프트로 올려진 머신과, 엔지니어가 카본 합성소재로 만들어진 프런트 윙을 체크 하고 있다.


Mercedes GP Team Pit


수많은 타이어들.  혹자의 말로는 개당 5백이라던데.


RedBull Team Pit


레드불 팀의 베텔 피트.  머신을 점검중인 엔지니어들과 카본으로 된 아름다운 형상의 카울이 관객을 위해 전시중이다.


Mark Webber Pit



강력한 우승후보 였으나 악천후로 인한 슬립으로 리타이어한 마크 웨버의 피트.  역시 엔지니어들이 머신을 점검중이다.


McLaren Pit


맥라렌의 피트.  그이름도 유명한 루이스 해밀턴과 젠슨 버튼의 머신이 점검중이다.
앉아서 카울의 외견을 정성스럽게 닦고 있는 미케닉의 모습도 보인다.


Team Ferrari


이제는 전설인 페라리 팀의 피트.  이번대회 각각 1위를 한 알론소와 3위를 한 마사의 머신이 정비중이다.
이 흰색과 빨강색, 그리고 검정색 폰트의 조화는 아이덴티티 강한 두 회사를 상징하게 만들어 버린다. 페라리와 말보로.

하지만 말보로는 더이상 페라리를 서포트 하지 않는 듯 보인다.


경기중 팀 머신의 상태를 체크하고, 드라이버와 교신하며 서킷의 상황을 통한 작전등을 수립하고 모니터링 하는 일종의 팀 상황실.  수많은 모니터가 각각 머신에 부착된 센서를 통해  엔진의 RPM , 타이어 및 브레이크의 온도, 드라이버가 밟는 악셀과 브레이크의 답력 등을 실시간으로 모니터링 한다.


이후 각 팀의 피트.


Team Williams

Team Lotus

Team Virgin Racing



이렇게 피트 관람을 마친 후에, 숙소를 정하기위해 목포로 다시 돌아갔으나, 이미 거의 모든 숙박업소가 매진 사례.
아이폰의 구글맵으로 주변 검색후 각 모텔의 번호로 친구와 줄기차게 전화한 결과 한군데의 모텔에서 온돌방이 남았단다.  가격은 10만원.  장담하건데 평일에 놀러가서 얻으면 5만원 이상 주면 돈아까운 방이었으나, 예선도 못본 상태에서 상경하기엔 피눈물 나는 지난 1년 이기에, 눈 딱 감고 가서 잤다.

Grand stand


피트를 돌아 보고 난 뒤.  이 길은 메디컬 차량이나 대회에 필요한 각종 인원 및 운송을 위한 도로로 보면 된다.




그리고, 결승전이 시작 되었다.

전날의 억울함이 뼈에 사무쳐, 무려 2시간 전에 출발 하고 막히지 않는 길로 돌아 갔음에도 불구하고 1시간이 걸렸다.
내년의 티켓 구매를 하시는 분들께 미리 조언을 드린 다면,

1. 절대 제일 저렴한 티켓을 구매하지 말 것.
2. 1번이 경제적으로 어려워서 구해 한 경우, 사진을 찍기를 원하신다면 티켓 발행시에 제일 상단, 또는 제일 좌우 끝 좌석 배정을 요구할 것.



E-b Stand


대충 이런 분위기에서 관람했다.  ( 사진에 일부 얼굴이 표시된 부분이 문제가 되는 경우 자삭하겠습니다. )


서킷은 안보이고... 비는 오는데 옆자리 앞자리에서는 우산 펴고, 친구와 나는 우산펴면 뒷사람 안보일까봐 그냥 안펴고 비 쫄딱 맞았는데.  거기까지는 좋지만, 우산의 뼈대가 우리를 찌르고 또 우산 끝에서 나는 물줄기는 나의 바지를 전부 적셨다.  솔직히 성질 많이 났는데, 기분 좋게 보고 가고 싶었다.  참았다.

스텐드의 안전검사가 완료되지 않아, 내가 원래 구매했던 J-b 를 포함, J-a 와 일부 다른 스텐드에 사람이 앉지를 못했다.  이로인해 원래 E 스텐드를 예매했던 사람들은 자리를 찾지 못하고, 예상보다 훨씬 많은 인원이 들어서는 것을 감당하지 못한 주최측은 그냥 꾸역꾸역 정해진 대로 사람들을 밀어 넣었다.  몰리고, 혼잡하고.

여러가지 중에서도 한가지 이해 할 수 없는건, 어디서 얼큰하게 한잔 걸치고 오신 할아버님 들 및 할머님들의 등장이다.
맨 앞쪽에서 우산을 편 채로 계시다가, 결국 비슷한 연배의 다른 어르신께서 제지하는 사태가 사람이 들어오는 내내 계속 되었다.   또 하나는, 아주 어린아이 ( 3세 미만 )를 그 시끄러운 서킷에 데리고 오는 사람들이다.

전체적으로 무슨 드라이버나 팀, 아주아주 간단한 정보 조차 없어 전국 노래자랑에 오실 법한 분들이 많이 계셨던게 아닌가, 나름 생각 해 본다.  이 부분에 대해 뭐라 할 지도 모르겠지만, 적어도 현장에서의 내 감상은 그랬다.
그 감상을 더욱더 굳히게 한건, 제일 마지막 흥미 진진했던 부분에서 ( 마크 웨버 리타이어 전 ) 대부분의 사람들이 스텐드에서 빠질 때 였다고 할까.

우천으로 인해 경기가 중단되면서, 정말 짜증나서 미쳐 버릴 뻔 했다.
동시에 내년엔 기필코 여친 만들어 더 좋은 자리로 예매 해야 겠다는 굳은 각오를;;;


RedBull, Mark Webber


리타이어 하기 전, 노면에 빗물이 빠지지 않아 미약한 슬립을 일으키며 고속 코너로 진입하는 레드불 마크 웨버의 머신.
저기서 부터 몇 차례의 변속이 일어나는 듯 한데, 그 사운드가 장난이 아니다.  초고속 엔진의 배기음 + 열라큰 미스파이어링 같은 환상적 사운드.  물론, 애들과 여인들은 귀를 막는다.

Mercedes GP, Schumacher


노면이 어느정도 마른 후, 경기 종반부에 고속 코너를 빠르게 진입하는 슈마허의 머신.  노면이 많이 젖었을 때와는 속도의 차원이 달랐다.  SC 가 빠진 이후의 각 드라이버의 코너 공략은, 선행 머신을 기필코 추월 하겠다는 드라이버의 의지가 느껴질 정도로 어마어마 한 것이었다.


The Winner, Alonso



우승 체커기를 받은 이후 피트에 들어가기 전 서행하며 승리를 자축하고 있는 페라리팀의 알론소. 우천시에도 페이스를 잃지 않고 신뢰성 강한 머신으로 할 수 있는 것을 해낸 팀이 결국 승리했다.  이렇게 축하의 한바퀴를 도는 동안 스텐드에 남아 있던 사람들은 일부 연인, 기념 사진을 촬영중인 사람들 몇몇, 그리고 소수의 유러피언과 내 친구 뿐.



이번에 영암에 다녀와서 3시간 여의 운전 후에 이렇게 긴 포스팅을 하는 이유는, 내일 일이 없어서가 아니라 별 것 아닌 것 같은 이 감상을 오늘 적고 싶어서이다.  이 경주는 정말 대단했고, 비로 인한 FIA 규정을 눈으로 확인 할 수 있었으며, 또한 비로인한 각 팀의 타이어 전략에 따른 수많은 리타이어를 눈 앞에서 경험 할 수 있었던 F1 의 진면목을 보여주는 아주 재미난 경기였던 것이다.   하지만 수많은 오류로 인해 대회를 즐기게 되기 까지에는 많은 인내가 필요했던 것 또한 사실이다.  내 개인적 견해로 비추 어 본 점들을 대략 정리 하자면,

1. 경기장 자체로의 진입에 대한 어려움  -  차량 이동을 제외 하더라도 J 스텐드는 15 ~ 30분여가 소요 될 것으로 보인다.  따라서, 향후 정비가된다면 에버랜드 처럼 주차장 간 셔틀이나 간단한 모노레일 정도의 설비가 필요하지 않을까 생각 해 본다.

2. 경기장은 잘 포장 되었지만, 경기장 주변은 비가오니 그야말로 진창이었다. - 고속도로 휴게소에서 사람들 신발과 바지 밑단만 보아도 이사람이 영암에서 나온 사람이라는걸 쉽게 알 수 있었다.  시간이 지나면 보강 되리라 생각한다.

3. 말도 많고 탈도 많은 숙박업소 -  가격에 대해서는 주최측의 지혜가 필요하리라고 생각된다.  다른 나라의 포뮬라 경주의 티켓을 구매 할 때는, 보통 항공권, 숙박, 티켓 을 함께 고려하게 된다.  물론 티켓 가격에 강제로 모두 포함 할 수는 없겠지만, 적어도 전일권 구매자에게는 지역 상권과 협의 하여 보다 좋은 가격에 티켓 구매 옵션에 포함 시키면 더 좋지 않았을까 한다.  물론 교통편 까지 연계 된다면, 조금 비싸더라도 구매하지 않을 이유가 없다.  물론 내년에는 러브모텔에서 나도 자고 싶지 않다.

4. 각 스텐드에는 진행요원이 필요하다. - 내가 앉은 스텐드의 경우, 통제 할 사람이 없었다.  이는 시민간의 감정 격화로 인해 자칫 잘못하면 폭행 사태가 벌어 질 수도 있으며,  우산 관련 규정 등에 대해 당연히 미숙지 한 사람들을 위해 또 다른 사람들의 보다 좋은 관람을 위해 적절한 안내를 하고 실행을 시켜줄 공인된 사람이 필요하다.

5. 지역 주민 꽁짜표 문제  -  VIP 가 아니라고 해서 지역 주민들에게 무료 표 또는 보다 저렴한 표를 나누어 주지 못할 이유는 별로 없다고 생각한다. 다만, 정상적인 비용을 지불 하고 경기장을 찾는 관람객에게 불편을 제공 해서는 안될 것이다.  말인 즉슨, 관리 해라.  스텐드 별로 미리 좌석 수를 잡아 두던가.


이 외에도 많지만, 결국 경기 자체와 첫 경험(?) 이 매우 인상적이었기 때문에 나름의 재미는 있었다고 생각한다.
원래 오피셜에 지원 해서 합격했고, 1차 시험까지 보고 실기 교육을 받으러 갔어야 하지만, 이직등의 개인적인 문제로 결국 손님 행세를 하게 되었지만 말이다.


사진은 훨씬 더 많이 있지만, 시간에 이만큼 추려 낼 수 있었던 내가 놀라울 따름이니 더 많은 사진은 나중에 정리 해서 한꺼번에 올리는 것이 좋을 듯.

내년에도 예매 할 가능성이 많지만, 한가지 팁은 -  고속에서 저속으로 급 다운되는 지역이 관전 포인트다.


이상.

( younjin.jeong@gmail.com , 정윤진 )

Build Automated Infrastructure with Chef - Chapter 2

Techs
( younjin.jeong@gmail.com , 정윤진 ) 

지난번에 이야기 한 대로, 금일은 다음과 같이 구성된 시스템을 chef 를 통해 자동화 하는 과정을 살펴보겠다. 
빠른 코드 작성을 위해서 대부분의 코드는 OPSCODE ( http://www.opscode.com ) 으로 부터 가져왔으며, 가져오는 방법은 아래에 설명한 대로 진행하면 쉽다. 



지난번에 설명한 초간단 쇼핑몰의 인프라의 추상화는 대략 아래와 같은 모양일 것이다. 물론 성능의 향상이나 사용하고 있는 코드의 구조에 따라 자잘한 구성은 충분히 변경 될 수 있으며, 물론 이것보다 훨씬 좋은 구성도 얼마든지 존재한다.

Figure 1



이제 우리가 준비해야 할 내용은 다음과 같다.

1. opscode.com 의 chef 서버를 사용하거나, stand alone 서버를 만들어 망 내에 설비한다. ( chef 서버의 설치는 3호에 다루도록 한다. )
2. 필요한 package 별로 cookbook 을 다운로드 하여 서비스에 맞도록 수정하고, 필요한 것들은 만들도록 한다.
3. knife 툴을 사용하여 생성된 cookbook 을 업로드 하고, 이를 테스트를 수행할 노드에서 이상이 없는지 코드를 실행, 서비스가 정상적으로 동작하는지 확인한다.
4. 각 서버에 OS 를 설치하고, chef-client 구동 환경을 준비하여 미리 지정된 role 을 사용하여 서버를 셋업한다.


1. 번의 내용을 진행하기 위해, 다음을 수행한다. ( opscode 의 chef server 를 사용하여 진행하는 경우 )
설명되는 절차는 다음의 wiki 페이지에서 그대로 따라 할 수 있다.
 - http://wiki.opscode.com/display/chef/Quick+Start#QuickStart-SetupanewChefClient

a. Cookbook 개발 및 배포에 사용할 VM 을 준비한다.  현재 사용하고 있는 데스크탑 또는 노트북의 VMWare 또는 VirtualBox 등으로 준비하면 된다.  사용하는 Linux 배포판은 Ubuntu 나, CentOS 등 일반적으로 많이 사용하는 배포판으로 준비 하도록 한다.  지난번에 Ubuntu 로 설명 했으니, 이번에는 CentOS 한번 간다. ㅎ

b. http://www.opscode.com 에 계정을 등록하고, 가입한다.
   - https://cookbooks.opscode.com/users/new

c. 가입 후, 우측 상단에 보이는 ID 를 클릭하면 나오는 페이지에서 key 를 다운 받는다.
  

ID Section



Get a new Private key


d. http://manage.opscode.com  으로 이동하면, Organization 탭이 보일 것이다.  적당한 이름으로 생성하고, 역시 동일하게 key 를 다운 받는다.  또한, 바로 옆에 있는 knife.rb 파일도 다운 받도록 한다.

e. 다운 받은 세개의 파일이,  id.pem  //  organizationname-validation.pem // knife.rb  인지 확인한다.

f. 설치해 둔 CentOS VM 에서, root 계정으로 다음을 실해하여 chef 가 구동 될 수 있는 환경을 구성한다.

# sudo rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm

# sudo rpm -Uvh http://download.elff.bravenet.com/5/i386/elff-release-5-3.noarch.rpm

위의 패키지 인스톨은 적절한 ruby 버전을 설치하기 위한 몸부림으로 보면 되겠다.

g. FQDN 을 요구하는 경우가 많으므로, /etc/hosts 를 수정하여 훼이크를 준다. vi /etc/hosts
..
...
10.0.0.111   someone.hohoho.com


h. 안락한 사용을 위하여 yum 으로 필요한 패키지를 설치한다.
# yum install git chef -y

i. 모든 패키지의 설치가 끝났다. 이제 루트가 아닌 적절한 사용자 계정으로 전환하고,  기본 chef-repo 를 opscode.com 의 github 로부터 가져온다.
# su - USERID
# cd ~
# git clone git://github.com/opscode/chef-repo.git ~/chef-repo

j. 자, 이제 아까 받아 두었던 3개의 파일을 다음의 위치에 집어 넣는다.
@ mkdir -p ~/chef-repo/.chef
@ cp -r OPSCODE_USERID.pem VALIDATION.pem ~/chef-repo/.chef/
@ cp -r knife.rb ~/chef-repo/.chef/

k. 모든 절차가 정상적으로 진행 되었다면, 다음과 같은 커맨드를 때려 다음과 같은 메세지가 잘 나오는지 확인한다.
@ knife node list
[

]

위와 같이 나온다면, 일단 사용자 인증에는 문제가 없는 것이다.  여기서 Authentication Error 를 밷어 낸다면, 받아 온 사용자아이디.pem 파일이 정상인지 확인하도록 한다.

l. 위의 내용이 정상 동작 한다면, 이제 client 로서의 등록을 위해 다음의 과정을 진행한다.
@ cd ~/chef-repo
@ knife configure client ./client-config
@ sudo mkdir -p /etc/chef
@ sudo cp -r ./client-config/* /etc/chef/
위의 커맨드는 client 등록을 위한 validation.pem / client.rb 파일을 생성하며, 이 파일들은 chef-client 의 기본 설정파일 참조 위치인 /etc/chef 디렉토리에 넣어 준다.

m. 위와 같이 모두 준비 되었다면, 다음의 커맨드로 정상적으로 클라이언트 등록이 되는지 확인하도록 한다.
@ sudo chef-client

[Wed, 13 Oct 2010 18:39:26 +0900] INFO: Client key /etc/chef/client.pem is not present - registering
[Wed, 13 Oct 2010 18:39:31 +0900] WARN: HTTP Request Returned 404 Not Found: Cannot load node localhost.localdomain
[Wed, 13 Oct 2010 18:39:36 +0900] INFO: Starting Chef Run (Version 0.9.8)
[Wed, 13 Oct 2010 18:39:37 +0900] WARN: Node localhost.localdomain has an empty run list.
[Wed, 13 Oct 2010 18:39:39 +0900] INFO: Chef Run complete in 3.40439 seconds
[Wed, 13 Oct 2010 18:39:39 +0900] INFO: Running report handlers
[Wed, 13 Oct 2010 18:39:39 +0900] INFO: Report handlers complete
모두 정상적으로 수행이 되었다면, Report handlers complete 라는 메세지를 확인 할 수 있다.
또한, /etc/chef/client.pem 파일이 생성되는데, 이는 validate.pem 키를 기반으로 서버에서 인증을 받고 생겨난 새로운 클라이언트 키이다.   이 키는 해당 노드에서 계속 사용되므로, 실수로 지워먹거나 하지 말도록 하자.

역시 이 부분에서도 인증 관련 문제가 발생 하는 경우를 많이 봤는데, 이는 매번 똑같이 설정해도 잘 안되는 경우가 있고, 또는 기존에 한번 등록했던 노드를 다시 등록 하려는 경우 등 몇가지 쉽게 발생하는 휴먼에러들이 있다.
이럴떄는, manage.opscode.com 에 가서 Organization 의 키를 다시 생성하여 다운 받고, 해당 키를 .chef 디렉토리에 넣어 준 후에 다시 knife configure client DIR 을 수행하여 발생한 키를 /etc/chef 에 넣어 준다.  이때, client.pem 파일이 /etc/chef 디렉토리에 있다면 반드시 지워주도록 한다.

o. 위의 모든 과정이 완료 되었다면, 다음의 커맨드로 본인의 VM 의 내용이 나타나는지 확인해 본다.
# knife node list
[
  "domU-12-31-38-04-6C-92.compute-1.internal",
  "localhost.localdomain"
]
# knife client list
[
  "domU-12-31-38-04-6C-92.compute-1.internal",
  "localhost.localdomain",
  "younjinjeong_org-validator"
]

p. 역시, http://manage.opscode.com 에 자신의 계정으로 로그인 하면 현재 붙어있는 노드 및 해당 노드에서 수행하는 프로세스 및 MAC 정보 등 많은 시스템 정보를 확인 할 수 있다.  이는, 향후 관리를 용이하게 하며 각 노드에서 수행해야 할 cookbook 및 run_list 를 서버측에서 관리함으로서 필요시에 원하는 형태로 패키지 설정 및 노드 검색 등이 가능하다.
이는, ohai 라는 chef 가 설치 될 때 함께 설치되는 util 에서 나타나는 output 과 같으며, 쉘에서 수행 가능하므로 직접 수행하여 어떤 내용을 나타내 주는지 확인 해 보면 되겠다.



자, 이제는, knife 를 통해 opscode.com 에 생성된 나만의 chef 서버와 api 통신이 가능해 진 것이다.  이후 opscode 로 부터 이미 생성된 cookbook 을 자유롭게 받아 수정하고, 업로드하여 새로운 노드에 반영하면 될 것이다. 위에 일부러 굵게 볼드체로 해 놓은 2번의 내용은 제법 기니깐, 한두어 가지의 cookbook 을 knife 를 통해 다운로드 하고, 이를 수정하여 노드에 직접 적용해 보는 것으로 마무리 하며, 나머지는 향후 3부에 올려 놓을 github.com 링크를 통해 코드를 확인 하시면 되겠다.


a. cookbook 의 download.  다운 로드 가능한 cookbook 의 리스트는, 다음과 같이 확인이 가능하다.
# cd ~/chef-repo
# knife cookbook site list
마치 yum search 한 것마냥 쿡북이 줄줄이 나오는데, 이는 OPSCODE 에서 미리 작성해 둔 코드들이다.  이 코드들의 라이센스는 각 소스에 적혀있으므로, 미리 확인하도록 하자.  Aaron Peterson씨 의 말에 따르면 아파치 라이센스라지만, 각자 확인하여 미리 문제가 없도록.

b. 확인한 cookbook 은 다음과 같은 형태로 다운로드가 가능하다.
# knife cookbook site vendor COOKBOOK_NAME -d
커맨드 설명만 하는  것 같아서 기분이 좀 그런데, knife 커맨드의 각 2열까지는 type 후 그냥 엔터를 쳐도 대략적인 help 정보를 볼 수 있으며, 이후에는 --help 를 붙여 주시면 되겠다.

c. 다운로드 한 Cookbook 은 아직 각 노드에 배포 될 수 있는 형태가 아니며, 이를 위해서는 다음과 같은 작업이 필요하다.
/* Upload  All Cookbook */
# knife cookbook upload -a

/* Specify a cookbook to upload */
# knife cookbook upload COOKBOOK_NAME 

d. 이렇게 업로드된 쿡북은, run_list 또는 role 로 정의되어 선택된 노드에서 동작 할 수 있게 된다. 노드의 추가 및 run_list 추가는 조금 이따가 보기로 하고,  여기까지 그냥 따라 했다면 이제는 이 Chef의 Server - Client 시스템 및 쿡북의 생성 및 적용, 배포에 관한 사이클에 대해 이해 할 필요가 있다.

Cookbook Life cycle


대략 이런 흐름으로 Cookbook 을 유지한다.  PPT 를 발로 그린건 너그러이 용서를 바람.  집에 가고 싶어서 ㅠㅠ

실제 업무를 한다면, 이런 그림이 되지 않을까 싶다.
어쨌든 개발 및 배포 프로세스는 위와 같으며, 이제 실질적으로 cookbook 을 살펴 보기로 하자.

knife cookbook site list 해서 나온 것 중, 이번 쇼핑몰 구성에 필요하거나 있는 쿡북은 모두 내려 받는다.
# for i in apache2 cron eaccelerator heartbeat iptables mysql nagios nginx rsyslog rsync ; \
do cd ~/chef-repo ; knife cookbook site vendor $i -d ; done
이상한 현상중의 하나가 어떨때는 tar.gz 으로 쿡북이 오거나 또는 압축이 풀린상태로 cookbook 디렉토리에 이쁘게 잘 들어가기도 한다.  아마, knife 의 옵션에 뭔가 있을 것 같은 생각이므로 궁금하신 분들은 wiki.opscode.com 을 참조.

위의 목록에서 빠졌거나 또는 기본으로 실려오는게 좀 부족하거나 볼륨이 너무 큰 감이 있다면 다음과 같이 비어있는 쿡북을 만들도록 한다.
# knife cookbook create COOKBOOK_NAME

e. 자 이제 많은 부분이 준비 되었다.  이제는 Cookbook 자체를 수정하는 일만 남았다.

Cookbook 을 수정하기 위해서는, 먼저 chef 의 디렉토리 구조를 알아야 할 필요가 있다.
쓰다보니 제법 길어져서, 이제 3회를 향해 가야 할것 같은 분위기. ㅋ


KT 회의실에 혼자 쭈그려 있기 좀 민망하므로 오늘은 여기까지.


( younjin.jeong@gmail.com , 정윤진 )