Notice
Recent Posts
Recent Comments
Link
- Korea times
- 끌리면 오라...BGM 광고음악 라이브러리
- KartOO visual meta search engi…
- E-Book
- Channel9
- MSDN
- 여리의 작업실
- 유경상의 .NET 블로그
- window 쪼물딱 거리기
- 블루 홈(소현이 누님)
- IT 관련 전반 내용(정환이네)
- 비너스의 정보 공유(유틸리티들)
- 형기의 자료공간(디지털ERA에서 콘텐츠ERA로)
- EzineArticles (여러 분야의 글들이 올라옴)
- Relationship을 보여주는 라이브러리
- OpenRCE
- 젠틀의 블로그(무선 통신의 모든것)
- 헐랭이와 IT보안
- 워니. 추억ㅇㅔ ㅂㅣ추ㅇㅓ.
- Computer Forensics
- 토익 광장(YBM)
- Korea Times 이용하기
- Larkware Software
- TCP/UDP
- Black Hat
- DEF CON
- Slashdot
- ReallyUsefulEbooks.com Update
- 실리콘밸리 뉴스
- Application Development Trends
- Visual Studio Hacks
- MIT OCW
- Redmond Developer News
- SecurityFocus
- Microsoft Window Hacking Porta…
- Darknet - Don't Learn to Hack …
- Windows Tips, Tricks and Hacks
- Hack In the Box
- (IN)SECURE Magazine
- SuperSite Windows Vista
- Government Security
- Life is Still Talking (Good)
- PHRACK
- Found+Read(resource for startu…
- Jonathan Boutelle
- Venture Hacks
- 스마트플레이스
- All about Intellipedia
- Undocumented Windows 2000 Secr…
- HexBlog (Decompiler)
- TED (Ideas worth spreading)
- Crash Dump Analysis and Debugg…
- Rootkit
- DDK Developers(MS)
- 미친 감자의 블로그
- The Art of Assembly Language
- Chpie (키보드 후킹)
- Drivers Online
- (음악) Delicate SONG
- Reverse Engineering Community
- Software Best Practices
- Sara Ford's WebLog
- Cheat Happens
- Debugging,Unpacking,Assembling…
- 윤석찬님 블로그
- OK 괜찮아 다 잘 될거야
- RingBlog
- Art Life :: 하늘소
- IT's Paradise
- John Robbins!
- Wintellect
- Hacked Gadgets
- 소프트웨어 이야기
- Ryan Naraine's Zero Day
- VULN
- Stay Secure
- EBS 영어 공부(블루워터)
- 101BLoG : "Bright Size Life" o…
- Hacker Challenge
- Hackers Center
- White Hat, Chicago Con
- Ethical Hacker Network
- ChaseNet (Security)
- TechTarget
- Entrepreneur
- Infopackets
- Popular Science
- Dark Reading - The Business of…
- How Stuff Works
- codeDriver - Crack (역공학)
- Gadget (Windows)
- Serious Code
- Iguacu Blog(블루문)
- SecurityProof
- Power of Community(Hacker)
- Crack ?
- Security Freak
- Data Network Resource
- FoundStone - Security Consulti…
- Google Online Security Blog
- (BOOK) Cool DogBooks
- SachaBarber (좋은 개발자)
- System Software Incorporation
- 스카이 벤처
- NewsTorrent
- 글로벌 IT 네트워크
- Ethical Hacking and Infosec
- Realms of Hacking tricks
- CodeBreakers Journal
- Anti Rootkit Blog
- The Reverse Code Engineering C…
- Anti-Debug Tools
- Reverse Code Engineering Video…
- Damn Vulnerable linux
- Security Problems
- French Reverse Engineering Tea…
- Monac
- Open Source Vulnerability Data…
- Viruschaser 검사(바이러스)
- Windows Tips
- 보안 대처 연습
- [Download] Kartz CD
- [Download] FlMS Download
- [Download] DDL2
- 중국 해킹 사이트(안전중국)
- 바이러스 분석
- Javascript 전문가
- Virus Alert Zone (바이러스 분석)
- Computer World
- 문스랩닷컴(보안)
- Unpack China
- Black Storm Reverse Engineerin…
- 역공학 Reverser
- 문화 망명지 - 시, 소설
- WPF MVP
- Research Channel
- The Problem Solver - C# MVP
- Reversing - 리버스 엔지니어링
- Nigel Spencer's Blog (.NET)
- Kirill Osenkov (.NET C# IDE Te…
- H33T (BitTorrnet 검색 사이트)
- ITL (해킹, 보안)
- ITL (Invisible Things Lab) Blo…
- ebook, pdf, chm
- 주식 - 멘토클리닉
- CherryLove - 바이러스, 백신, 악성코드
- PMP
- 영원한 해커, hacker
- 리버싱, PE
- 신호철 - dsphome
- TechEd 2009
- SHOUT
- [도서] 오디오북
- [도서] 전자책
- [도서] 국내도서요약
- [도서] 해외도서요약
- TopCorder - 프로그래밍 연습
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
Tags
- .net
- 해킹
- security
- hacking
- Microsoft
- Visual Studio
- 보안
- .net framework 4
- 비주얼스튜디오
- MVP
- 책
- Windows 7
- 닷넷
- C#
- Windows
- VSTS 2010
- VSTS
- 구글
- .NET Framework
- english
- debugging
- 디버깅
- 디버그랩
- 마이크로소프트
- WPF
- 비주얼 스튜디오
- visual studio 2010
- 역공학
Archives
- Today
- Total
NaggingMachine
Volunteer Computing에 대한 회상 본문
KAIST대학원에서 연구했던 주제. 하지만 결국 논문을 완성하지 못하고 쓴맛을 봤던 연구였습니다. 최근들어 클라우드도 엄청나게 화제가 되고 있고 하둡(Hadoop)과 같은 시스템을 접해보고 활용하려고 하다 보니 예전 생각이 들어 혹시 같은 주제로 고민하는 다른 친구들이 있을까 싶어 마지막으로 정리해봅니다.
처음 대학원에서 Volunteer Computing을 연구 주제로 선택했을 때만해도 '연구(Research)'에 대해 참 순진했었습니다. 그저 남들과 다른 무언가를 선택하고 그것이 의미가 있든 없든 새로운 시도라면 괜찮을 것이라고 생각했고, 또한 나름 대로는 결과에 대해서도 자신하고 있었기 때문이었습니다. 뒤에 설명드리겠지만 결과는 참담했고 결과적으로 뚜렷한 대안도 제시하지 못하는 최악의 상황에 부딪히게 되었습니다.
Volunteer Computing(이하 VC)에 대한 관심은 SETI@Home이라는 유명한 우주 생명체 발견 프로젝트를 통해서였습니다. 이 프로젝트가 자주 언론에 소개가 되었고 저도 도움이 될 수 있을까 싶어 클라이언트 프로그램도 설치하고 저의 소중한 컴퓨팅 파워도 공유했었죠. 프로그램을 설치하면 어떤 잡(Job 또는 Task)을 어느 정도 수행했는지를 알려주기도 해서 그 피드백 과정이 신기하여 운영체제를 재설치해도 항상 클라이언트를 설치해서 운영하곤 했었습니다. 그런 차에 이런 생각이 들었죠. "회사에 있다보면 회의 할 때는 가볍게 차를 마실때, 식사를 하러 갈때 내 PC가 그냥 무턱대고 놀고 있다면 회사의 자원이 얼마나 낭비되는 걸까? 그 유휴 자원(Idle Resource)를 사용할 수 없을까?"라는 생각이었습니다. 그것이 만약 100대 이상의 PC를 운영하는 기업이라면 더욱더 활용도는 높아질것이라 생각했습니다. 그래서 생각해 낸 주제가 바로 Volunteer Computing in Enterprise 였고, 저는 곧바로 해당 주제를 검증하고 구현하는 작업에 착수했습니다.
BOINC(Berkeley Open Infrastructure for Network Computing)
SETI@Home은 버클리 네트워크 컴퓨팅을 위한 공개 기반(BOINC) 플랫폼을 이용하여 운영되고 있습니다. BOINC 기반의 VC 프로젝트들은 SETI@Home이외에도 여러 가지가 운영되고 있고 여러분들은 클라이언트만 설치하면 곧바로 여러분의 자원을 제공할 수 있습니다. BOINC를 기업 환경에서 직접 운영해야 하는 저 같은 연구원의 입장에서는 플랫폼이 어떻게 구성되어 있는지, 잡을 나누고 관리하기가 편리한지등에 대해서 관심이 많았고 당시 정확하게 기억이 나지는 않지만 BOINC이외에 선택할 수 있는 플랫폼의 종류가 많지 않아 여러 가지 대안을 고민하던 중 BOINC를 활용하기로 결정하였습니다. 연구원들은 잘 아시겠지만, 이쯤 되면 다시는 돌아오지 못할 강을 건너고 마는 것이죠. :-) 자세한 기술적인 얘기는 궁금하신 분에 한해서 질문하시면 말씀드리기로 하고, BOINC를 선택하게 되었다는 데까지만 말씀드리겠습니다.
저는 이 프로젝트를 '첫눈'이라는 검색회사에서 적용을 했는데, 실제 가용하여 적용해볼 수 있는 클라이언트 수는 20대 정도 였습니다(이 자리를 빌어 자발적으로 참여해주신 직원 분들께 감사하다는 말씀을 드립니다). 처음에는 간단한 테스트를 위해 압축 파일에 걸려있는 암호를 풀기 위해 VC를 활용하였습니다. 기능을 테스트하는 수준이었으므로 압축 파일을 각 클라이언트에게 전달하고 각 클라이언트에게는 압축을 풀기위해 사용할 암호 문자열 목록을 전달하는 방식이었습니다. 잡은 초기에 5자리 암호까지 알파벳 순으로 생성해서 나누었습니다. 처음에 이렇게 잡을 할당하고 나니, 오~! 정말 빨리 풀리더군요. (그 빠르다는 시간은 로컬에서 제 PC만 가지고 했을때와는 크게 다르지 않았습니다. 그 이유는 아래에서....) 몇 가지 테스트를 한 후에는 규모가 크고 해결이 어려운 문제를 선택해서 적용해 보았습니다. 그렇게 연구가 잘 진행되는듯 싶었지만 연구를 시작한 후 3개월 정도 지났을 때 몇가지 중요한 문제점을 발견하였고 그 때부터 고난의 연속이었습니다.
그 문제들은 VC가 가진 근본적인 문제였는데,
1. 데드라인에 맞출 수 있는가?
제가 시스템을 구축하고 (연구를 위한 관리 시스템은 추가 개발) 클라이언틀을 모아 잡을 배포하고 운영해보면서 몇가지 흥미로운 사실들을 발견하였습니다. 우선 많은 사람들이 컴퓨터를 켜고 30분 이내에 차를 마시러 간다든지, 점심 시간은 1시간 정도라든지, 퇴근은 참여하는 직원들의 50% 정도가 00시 이후에 한다든지의 내용이었습니다. 예측하실 수 있겠지만 대부분의 직원들의 PC가 유휴 자원으로 사용이 가능한 시간들은 비슷했고 생각보다 많지 않았습니다. 충격적이게도 말이죠. 물론 '유휴 자원'이 무엇인가에 대해서도 연구원이 정의를 잘 내려야 합니다. 예를 들면, 컴퓨터를 사용하지 않기 시작한지 (그러니까 화면 보호기등이 작동할 수 있는 매커니즘에 따라) 20분이 지난후 부터 유휴 자원이라고 판단할 수 있습니다. 하지만 이것 말고도 CPU 사용이 50% 미만일 때, 인터넷 트래픽이 100Kb 미만일 때, 화면이 정지되어 있을 때, 사용자가 특정 SW를 사용하지 않을 때 등등 규칙은 여러분이 정하기 나름입니다. 만약 더 많은 유휴 자원을 활용하고 싶다면 규칙을 좀 완화하면 되겠지만, 그렇게 되면 사용자 입장에서 작업에 방해를 받을 수도 있기 때문에 무엇이 답이다라고 말씀을 드릴수는 없습니다. 이런것들까지도 고민해야 한다는 것이죠. 몇가지 테스트를 통해 조직에 가장 잘 맞는 유휴 자원을 정의하셨다면 이제 잡을 잘 나누어야 합니다. 이에 대한 문제는 요즘 나오는 분산 시스템 구축 관련 서적을 보면 굉장히 잘 소개가 되어 있더군요. 하지만 상식 수준에서(그렇지만 정확하게 계산하여) 판단하시면 됩니다. 예를 들어 SETI@Home과 같이 전세계 사용자들에게 배포하는 잡의 경우 네트워크 속도를 보장하지 못하기 때문에 한번 자원을 배포하고 나면 오랜 시간 처리할 수 있도록 잡을 구성해 주셔야 합니다. 지나치게 네트워크 통신이 요구되는 일은 맞지를 않죠. 하지만 제가 생각한 기업 내에서의 VC는 네트워크 속도가 어느 정도 보장 된다는 장점이 있지만, 앞서 설명했던 대로 회사에서는 아무래도 사람들이 PC를 통해 작업하는 시간이 많다보니 유휴 자원이 많지 않다는 문제가 발생하였습니다. 상황이 이렇다 보니 서두에 소개한 근본적인 문제에 대한 답이 불명확해졌습니다. "주어진 시간 안에 일을 끝마칠 수 있는가?" 만약 최악의 경우 VC에 참여한 모든 직원들이 차도 한잔 마시지 않고 하루 종일 일만하게 된다면 저는 어떤 작업도 완료할 수 없습니다. VC는 할당 자원(Dedicated Resource)가 아니기 때문이죠. 한가한 사람한테 부탁해서 일을 좀 시키려고 했는데, 모두다 바쁘다니요! VC 연구를 하고 있는데, 이런 질문을 교수님께서 던지신다면 어떤 일이 벌어질까요? @.@ 물론 저 나름대로의 대안(?)은 있었습니다. 잠깐 언급했지만 저는 BOINC에 추가적으로 개발한 관제 시스템이 있었는데, 이 관제 시스템은 잡의 배포 현황과 평균 응답시간, 그리고 앞으로 잡을 완료하기 위해 필요한 추가 자원의 수와 완료 시점까지의 시간등을 예측하는 시스템이었습니다. 만약 자원이 부족하여 원하는 시간에 일을 마치지 못할 것으로 예상되는 경우 경고를 울려 추가자원 할당을 알리도록 했습니다. 어떻게 추가 자원을 하냐구요? 그것은 바로 Dedicated Resource의 활용이었습니다. 결국 제가 고안한 시스템은 (정교하지는 않지만) 잡의 완성에 필요한 자원과 예측 시간을 고려하여 VC 클라이언트와 Dedicated Resource를 동시에 활용함으로써 주어진 시간내에 작업을 완료할 수 있도록 설계되었습니다. 그러니까 비싼 자원과 싼 자원을 동시에 활용하겠다는 나름의 꼼수를 사용한 것이죠. 실제로 그렇게 해서 운영을 해보니 어느 정도의 Deadline을 보장해주는 효과를 얻을 수 있었습니다. (박수~!) 하.지.만. 교수님들의 집요한 "무조건 Deadline을 맞춰야 한다면?"이라는 질문에 제 시스템은 무용지물(Nothing)이 되었습니다. 아......... (한숨x100) 혹시라도 VC를 적용하시고자 하는 분이 있다면 반드시 사용 가능한 자원이 '영원히' 없을 수 있다는 가정을 꼭 해주세요. 그렇게 영영 작업을 못해도 된다면 VC 사용해도 됩니다. ㅋㅋ 결국 VC는 "Volunteer"라는 근본적인 문제에 대한 인식이 없다면 여러분의 연구는 영영 헤어나지 못하는 블랙홀이 될 것입니다. (생각만 해도 끔찍)
2. 어떤 문제를 해결하고자 하는가?
만약 앞선 문제를 해결한다고 하더라도 실제 기업에서 VC를 적용하기 위해서는 임원들을 설득할 수 있을만한 명분이 필요합니다. "환경을 위해서!" 라든지, "자원 활용의 극대화를 위해서!" 또는 "지구 평화를 위해서!"와 같은 이유는 의미 없구요, 기업이 해결하고자 하는 문제를 과연 VC로 해결할 수 있는지를 고민해보셔야 합니다. 근데 제가 해보니까 많지 않더군요. 하.하.하.(웃는게 웃는게 아닙니다) 앞에서 설명한건 근본적인 문제였고 이건 실질적인 문제인데 첫눈과 같은 검색 회사에서도 VC에 적용할 만한 문제를 찾기 어려웠으니 다른 회사들은 오죽하겠습니까. 문제가 명확하지 않으면 임원들을 설득할 수 없고, 그렇게 되면 애써 만들어 놓은 시스템을 장난삼아 활용해보는 것말고는 쓸데도 없는 시스템이 될 수 있으니 '연구원'의 입장이 아니라 임원의 입장에서 고민해보는 시간도 가져야 합니다. 그리고 그게 명확하지 않다면 답이 없어요~. 기업은 '돈' 버는 일이 아니면 큰 관심 없다는 사실 잊지 마세요~
3. 사람들의 인식
어떤 인식이냐구요? 무조건 싫어합니다. 제가 사람들한테 찾아가서, "저기요. 이번에 이런 일을 사내 PC를 이용해서 처리해보려고 하는데 프로그램 하나만 설치해도 될까요?" 라고 하면 저를 쭈욱 쳐다보죠. 그래도 그 상황에서 "네, 설치하세요."라고 하면 다행이고 "그런데요, 그 프로그램이 무슨일을 하는데요?"라고 물어보면 이제 얘기가 길어지고 결국 내가 놀 때 이놈이 돌아가서 작업을 한다고 하면, 이 프로그램 때문에 내 PC가 느려지거나 망가지는건 아닌지, 심지어는 날 감시하는건 아닌지와 같은 보안 문제로까지 확대될 수 있습니다. 저는 SETI@Home 프로젝트 참여했을 때 부터 거부감이 없어서 그런지는 몰라도 사람들이 그렇게 싫어할 줄은 몰랐습니다. 설치하는 저도 굉장히 부담스럽더군요. ^^;;; (그래도 첫눈 사람들은 불쌍한 저 같은 연구원의 사정을 잘 이해해 주셨습니다) 이런 부분들 까지도 고려하셔야 합니다. 배포하시는 클라이언트가 얼마나 안전한지 어떤 룰에 의해서 작동하는지, 사람들의 작업을 방해하지는 않는지등에 대해서 명확하게 설명해주셔야 하고 그 결과물도 가급적 공개적으로 공유하시는것이 좋습니다. 그래야 서로 신뢰가 쌓이죠 ^^
결론
지금까지 제가 VC 프로젝트를 진행하면서 배운 것들을 간단하게 설명해 드렸습니다. 성공한 연구가 아니라서 자랑할만한건 없군요. 그래도 개인적으로는 굉장히 많이 배웠던 프로젝트입니다. VC를 마냥 좋다고 포장하는 사람들에게 음지의 세계를 말해줄 수 있다는 것. BOINC 시스템을 직접 구축하고 운영해봤고 관리 시스템을 개발해 봤다는 점. Deadline에 맞추기 위해 이런 저런 예측 기법(다양한 속성 값 활용)을 사용해 보고 해결책등을 고민해 봤다는 점. 마지막으로 인생의 쓴 맛을 봤다는 점 등입니다. 저 같은 경우에는 애초의 문제, "기업의 남는 자원을 어떻게 활용할 수 있을까?"에 대한 해결책으로 VC를 선택했고 결국 실패하였지만 여전히 "기업의 자원 극대화"에 대해서는 관심이 많이 있습니다. 하여튼 짜낼대로 짜내어야 겠지요. ㅎㅎㅎ (사람을 말하는건 아니예요~) 그리고 VC를 기업 환경에서 적용하려고 해서 이런 문제가 발생했지 일반 사용자들을 대상으로 한다면 문제가 약간 달라질 수 있습니다. 제 생각에는 다음 분야에도 활용이 가능할 것 같습니다.
- 학교
학교는 기업이기도 하지만 약간의 공공재 성격이 있기 때문에 학교내의 PC를 활용하여 학생들(자연계 연구원들)에게 VC를 활용할 수 있는 기회를 준다면 서버급 PC를 구매할 필요도 없고 학생들이 이런 자원을 활용해볼 수 있는 좋은 경험도 제공해줄 수 있을 것입니다. 당연히 자원 활용도 끌어올릴 수 있겠죠.
지금까지 저의 다사다난했던 대학원 시절을 함께 해준 VC 구축 경험을 소개해드렸습니다. VC가 개념적으로는 훌륭하지만 실질적으로 널리 사용될 수 없는 다양한 이유가 있다는 점들을 알게 되었다면 저도 보람이 있을것 같습니다. 혹시 관련 분야에 대해 연구하시는 분들이 있으시다면 함께해요~ ㅎㅎㅎㅎ
저는 이제 다시 현실속으로 Go! Go!
처음 대학원에서 Volunteer Computing을 연구 주제로 선택했을 때만해도 '연구(Research)'에 대해 참 순진했었습니다. 그저 남들과 다른 무언가를 선택하고 그것이 의미가 있든 없든 새로운 시도라면 괜찮을 것이라고 생각했고, 또한 나름 대로는 결과에 대해서도 자신하고 있었기 때문이었습니다. 뒤에 설명드리겠지만 결과는 참담했고 결과적으로 뚜렷한 대안도 제시하지 못하는 최악의 상황에 부딪히게 되었습니다.
Volunteer Computing(이하 VC)에 대한 관심은 SETI@Home이라는 유명한 우주 생명체 발견 프로젝트를 통해서였습니다. 이 프로젝트가 자주 언론에 소개가 되었고 저도 도움이 될 수 있을까 싶어 클라이언트 프로그램도 설치하고 저의 소중한 컴퓨팅 파워도 공유했었죠. 프로그램을 설치하면 어떤 잡(Job 또는 Task)을 어느 정도 수행했는지를 알려주기도 해서 그 피드백 과정이 신기하여 운영체제를 재설치해도 항상 클라이언트를 설치해서 운영하곤 했었습니다. 그런 차에 이런 생각이 들었죠. "회사에 있다보면 회의 할 때는 가볍게 차를 마실때, 식사를 하러 갈때 내 PC가 그냥 무턱대고 놀고 있다면 회사의 자원이 얼마나 낭비되는 걸까? 그 유휴 자원(Idle Resource)를 사용할 수 없을까?"라는 생각이었습니다. 그것이 만약 100대 이상의 PC를 운영하는 기업이라면 더욱더 활용도는 높아질것이라 생각했습니다. 그래서 생각해 낸 주제가 바로 Volunteer Computing in Enterprise 였고, 저는 곧바로 해당 주제를 검증하고 구현하는 작업에 착수했습니다.
BOINC(Berkeley Open Infrastructure for Network Computing)
SETI@Home은 버클리 네트워크 컴퓨팅을 위한 공개 기반(BOINC) 플랫폼을 이용하여 운영되고 있습니다. BOINC 기반의 VC 프로젝트들은 SETI@Home이외에도 여러 가지가 운영되고 있고 여러분들은 클라이언트만 설치하면 곧바로 여러분의 자원을 제공할 수 있습니다. BOINC를 기업 환경에서 직접 운영해야 하는 저 같은 연구원의 입장에서는 플랫폼이 어떻게 구성되어 있는지, 잡을 나누고 관리하기가 편리한지등에 대해서 관심이 많았고 당시 정확하게 기억이 나지는 않지만 BOINC이외에 선택할 수 있는 플랫폼의 종류가 많지 않아 여러 가지 대안을 고민하던 중 BOINC를 활용하기로 결정하였습니다. 연구원들은 잘 아시겠지만, 이쯤 되면 다시는 돌아오지 못할 강을 건너고 마는 것이죠. :-) 자세한 기술적인 얘기는 궁금하신 분에 한해서 질문하시면 말씀드리기로 하고, BOINC를 선택하게 되었다는 데까지만 말씀드리겠습니다.
저는 이 프로젝트를 '첫눈'이라는 검색회사에서 적용을 했는데, 실제 가용하여 적용해볼 수 있는 클라이언트 수는 20대 정도 였습니다(이 자리를 빌어 자발적으로 참여해주신 직원 분들께 감사하다는 말씀을 드립니다). 처음에는 간단한 테스트를 위해 압축 파일에 걸려있는 암호를 풀기 위해 VC를 활용하였습니다. 기능을 테스트하는 수준이었으므로 압축 파일을 각 클라이언트에게 전달하고 각 클라이언트에게는 압축을 풀기위해 사용할 암호 문자열 목록을 전달하는 방식이었습니다. 잡은 초기에 5자리 암호까지 알파벳 순으로 생성해서 나누었습니다. 처음에 이렇게 잡을 할당하고 나니, 오~! 정말 빨리 풀리더군요. (그 빠르다는 시간은 로컬에서 제 PC만 가지고 했을때와는 크게 다르지 않았습니다. 그 이유는 아래에서....) 몇 가지 테스트를 한 후에는 규모가 크고 해결이 어려운 문제를 선택해서 적용해 보았습니다. 그렇게 연구가 잘 진행되는듯 싶었지만 연구를 시작한 후 3개월 정도 지났을 때 몇가지 중요한 문제점을 발견하였고 그 때부터 고난의 연속이었습니다.
그 문제들은 VC가 가진 근본적인 문제였는데,
1. 데드라인에 맞출 수 있는가?
제가 시스템을 구축하고 (연구를 위한 관리 시스템은 추가 개발) 클라이언틀을 모아 잡을 배포하고 운영해보면서 몇가지 흥미로운 사실들을 발견하였습니다. 우선 많은 사람들이 컴퓨터를 켜고 30분 이내에 차를 마시러 간다든지, 점심 시간은 1시간 정도라든지, 퇴근은 참여하는 직원들의 50% 정도가 00시 이후에 한다든지의 내용이었습니다. 예측하실 수 있겠지만 대부분의 직원들의 PC가 유휴 자원으로 사용이 가능한 시간들은 비슷했고 생각보다 많지 않았습니다. 충격적이게도 말이죠. 물론 '유휴 자원'이 무엇인가에 대해서도 연구원이 정의를 잘 내려야 합니다. 예를 들면, 컴퓨터를 사용하지 않기 시작한지 (그러니까 화면 보호기등이 작동할 수 있는 매커니즘에 따라) 20분이 지난후 부터 유휴 자원이라고 판단할 수 있습니다. 하지만 이것 말고도 CPU 사용이 50% 미만일 때, 인터넷 트래픽이 100Kb 미만일 때, 화면이 정지되어 있을 때, 사용자가 특정 SW를 사용하지 않을 때 등등 규칙은 여러분이 정하기 나름입니다. 만약 더 많은 유휴 자원을 활용하고 싶다면 규칙을 좀 완화하면 되겠지만, 그렇게 되면 사용자 입장에서 작업에 방해를 받을 수도 있기 때문에 무엇이 답이다라고 말씀을 드릴수는 없습니다. 이런것들까지도 고민해야 한다는 것이죠. 몇가지 테스트를 통해 조직에 가장 잘 맞는 유휴 자원을 정의하셨다면 이제 잡을 잘 나누어야 합니다. 이에 대한 문제는 요즘 나오는 분산 시스템 구축 관련 서적을 보면 굉장히 잘 소개가 되어 있더군요. 하지만 상식 수준에서(그렇지만 정확하게 계산하여) 판단하시면 됩니다. 예를 들어 SETI@Home과 같이 전세계 사용자들에게 배포하는 잡의 경우 네트워크 속도를 보장하지 못하기 때문에 한번 자원을 배포하고 나면 오랜 시간 처리할 수 있도록 잡을 구성해 주셔야 합니다. 지나치게 네트워크 통신이 요구되는 일은 맞지를 않죠. 하지만 제가 생각한 기업 내에서의 VC는 네트워크 속도가 어느 정도 보장 된다는 장점이 있지만, 앞서 설명했던 대로 회사에서는 아무래도 사람들이 PC를 통해 작업하는 시간이 많다보니 유휴 자원이 많지 않다는 문제가 발생하였습니다. 상황이 이렇다 보니 서두에 소개한 근본적인 문제에 대한 답이 불명확해졌습니다. "주어진 시간 안에 일을 끝마칠 수 있는가?" 만약 최악의 경우 VC에 참여한 모든 직원들이 차도 한잔 마시지 않고 하루 종일 일만하게 된다면 저는 어떤 작업도 완료할 수 없습니다. VC는 할당 자원(Dedicated Resource)가 아니기 때문이죠. 한가한 사람한테 부탁해서 일을 좀 시키려고 했는데, 모두다 바쁘다니요! VC 연구를 하고 있는데, 이런 질문을 교수님께서 던지신다면 어떤 일이 벌어질까요? @.@ 물론 저 나름대로의 대안(?)은 있었습니다. 잠깐 언급했지만 저는 BOINC에 추가적으로 개발한 관제 시스템이 있었는데, 이 관제 시스템은 잡의 배포 현황과 평균 응답시간, 그리고 앞으로 잡을 완료하기 위해 필요한 추가 자원의 수와 완료 시점까지의 시간등을 예측하는 시스템이었습니다. 만약 자원이 부족하여 원하는 시간에 일을 마치지 못할 것으로 예상되는 경우 경고를 울려 추가자원 할당을 알리도록 했습니다. 어떻게 추가 자원을 하냐구요? 그것은 바로 Dedicated Resource의 활용이었습니다. 결국 제가 고안한 시스템은 (정교하지는 않지만) 잡의 완성에 필요한 자원과 예측 시간을 고려하여 VC 클라이언트와 Dedicated Resource를 동시에 활용함으로써 주어진 시간내에 작업을 완료할 수 있도록 설계되었습니다. 그러니까 비싼 자원과 싼 자원을 동시에 활용하겠다는 나름의 꼼수를 사용한 것이죠. 실제로 그렇게 해서 운영을 해보니 어느 정도의 Deadline을 보장해주는 효과를 얻을 수 있었습니다. (박수~!) 하.지.만. 교수님들의 집요한 "무조건 Deadline을 맞춰야 한다면?"이라는 질문에 제 시스템은 무용지물(Nothing)이 되었습니다. 아......... (한숨x100) 혹시라도 VC를 적용하시고자 하는 분이 있다면 반드시 사용 가능한 자원이 '영원히' 없을 수 있다는 가정을 꼭 해주세요. 그렇게 영영 작업을 못해도 된다면 VC 사용해도 됩니다. ㅋㅋ 결국 VC는 "Volunteer"라는 근본적인 문제에 대한 인식이 없다면 여러분의 연구는 영영 헤어나지 못하는 블랙홀이 될 것입니다. (생각만 해도 끔찍)
2. 어떤 문제를 해결하고자 하는가?
만약 앞선 문제를 해결한다고 하더라도 실제 기업에서 VC를 적용하기 위해서는 임원들을 설득할 수 있을만한 명분이 필요합니다. "환경을 위해서!" 라든지, "자원 활용의 극대화를 위해서!" 또는 "지구 평화를 위해서!"와 같은 이유는 의미 없구요, 기업이 해결하고자 하는 문제를 과연 VC로 해결할 수 있는지를 고민해보셔야 합니다. 근데 제가 해보니까 많지 않더군요. 하.하.하.(웃는게 웃는게 아닙니다) 앞에서 설명한건 근본적인 문제였고 이건 실질적인 문제인데 첫눈과 같은 검색 회사에서도 VC에 적용할 만한 문제를 찾기 어려웠으니 다른 회사들은 오죽하겠습니까. 문제가 명확하지 않으면 임원들을 설득할 수 없고, 그렇게 되면 애써 만들어 놓은 시스템을 장난삼아 활용해보는 것말고는 쓸데도 없는 시스템이 될 수 있으니 '연구원'의 입장이 아니라 임원의 입장에서 고민해보는 시간도 가져야 합니다. 그리고 그게 명확하지 않다면 답이 없어요~. 기업은 '돈' 버는 일이 아니면 큰 관심 없다는 사실 잊지 마세요~
3. 사람들의 인식
어떤 인식이냐구요? 무조건 싫어합니다. 제가 사람들한테 찾아가서, "저기요. 이번에 이런 일을 사내 PC를 이용해서 처리해보려고 하는데 프로그램 하나만 설치해도 될까요?" 라고 하면 저를 쭈욱 쳐다보죠. 그래도 그 상황에서 "네, 설치하세요."라고 하면 다행이고 "그런데요, 그 프로그램이 무슨일을 하는데요?"라고 물어보면 이제 얘기가 길어지고 결국 내가 놀 때 이놈이 돌아가서 작업을 한다고 하면, 이 프로그램 때문에 내 PC가 느려지거나 망가지는건 아닌지, 심지어는 날 감시하는건 아닌지와 같은 보안 문제로까지 확대될 수 있습니다. 저는 SETI@Home 프로젝트 참여했을 때 부터 거부감이 없어서 그런지는 몰라도 사람들이 그렇게 싫어할 줄은 몰랐습니다. 설치하는 저도 굉장히 부담스럽더군요. ^^;;; (그래도 첫눈 사람들은 불쌍한 저 같은 연구원의 사정을 잘 이해해 주셨습니다) 이런 부분들 까지도 고려하셔야 합니다. 배포하시는 클라이언트가 얼마나 안전한지 어떤 룰에 의해서 작동하는지, 사람들의 작업을 방해하지는 않는지등에 대해서 명확하게 설명해주셔야 하고 그 결과물도 가급적 공개적으로 공유하시는것이 좋습니다. 그래야 서로 신뢰가 쌓이죠 ^^
결론
지금까지 제가 VC 프로젝트를 진행하면서 배운 것들을 간단하게 설명해 드렸습니다. 성공한 연구가 아니라서 자랑할만한건 없군요. 그래도 개인적으로는 굉장히 많이 배웠던 프로젝트입니다. VC를 마냥 좋다고 포장하는 사람들에게 음지의 세계를 말해줄 수 있다는 것. BOINC 시스템을 직접 구축하고 운영해봤고 관리 시스템을 개발해 봤다는 점. Deadline에 맞추기 위해 이런 저런 예측 기법(다양한 속성 값 활용)을 사용해 보고 해결책등을 고민해 봤다는 점. 마지막으로 인생의 쓴 맛을 봤다는 점 등입니다. 저 같은 경우에는 애초의 문제, "기업의 남는 자원을 어떻게 활용할 수 있을까?"에 대한 해결책으로 VC를 선택했고 결국 실패하였지만 여전히 "기업의 자원 극대화"에 대해서는 관심이 많이 있습니다. 하여튼 짜낼대로 짜내어야 겠지요. ㅎㅎㅎ (사람을 말하는건 아니예요~) 그리고 VC를 기업 환경에서 적용하려고 해서 이런 문제가 발생했지 일반 사용자들을 대상으로 한다면 문제가 약간 달라질 수 있습니다. 제 생각에는 다음 분야에도 활용이 가능할 것 같습니다.
- 학교
학교는 기업이기도 하지만 약간의 공공재 성격이 있기 때문에 학교내의 PC를 활용하여 학생들(자연계 연구원들)에게 VC를 활용할 수 있는 기회를 준다면 서버급 PC를 구매할 필요도 없고 학생들이 이런 자원을 활용해볼 수 있는 좋은 경험도 제공해줄 수 있을 것입니다. 당연히 자원 활용도 끌어올릴 수 있겠죠.
지금까지 저의 다사다난했던 대학원 시절을 함께 해준 VC 구축 경험을 소개해드렸습니다. VC가 개념적으로는 훌륭하지만 실질적으로 널리 사용될 수 없는 다양한 이유가 있다는 점들을 알게 되었다면 저도 보람이 있을것 같습니다. 혹시 관련 분야에 대해 연구하시는 분들이 있으시다면 함께해요~ ㅎㅎㅎㅎ
저는 이제 다시 현실속으로 Go! Go!
'TechnoBabbler' 카테고리의 다른 글
JQuery Timer 사용 (0) | 2012.01.16 |
---|---|
JQuery에서 동적으로 객체 바인딩하기 (0) | 2012.01.16 |
복잡성을 숨기는 기술 (0) | 2012.01.03 |
앨런 쿠퍼의 인터랙션 디자인 원칙 (2) | 2012.01.03 |
PHP용 MongoDB 관리자 페이지 (0) | 2011.12.21 |