윤경구의 Log on Java

Grid에 대한 호기심이 한창이던 시절은 X 파일이 전성기를 구가하던 시절이 아니었나 싶다. 외계의 신호를 분석하기 위해 각 개인의 컴퓨팅 파워를 합쳐보려는 스크린세이버에 대한 기억... SETI@home 프로젝트는 외계 생명체를 찾는 유명한 Grid 프로젝트였다. 현재 grid computing의 상황에 대해서는 각 벤더들이 여러 가지 소프트웨어에서 grid 지원을 공언하고 있고, Grid Computing에 관심 있는 여러 업체들이 open grid forum이란 것을 형성하고 Globus Toolkit을 만들고 있다. OGSA 구현체인 Globus Toolkit은 자세히 들여다보지는 않았지만, 웹서비스를 사용한다는 점에서 장점과 단점이 분명하다. 여기 저기를 뒤져보면 오픈 소스인 GridGain이 나온다. 러시아의 뻬떼스부르크에 있는 같은 이름의 회사에서 자바 기반의 그리드 컴퓨팅 솔루션을 만든다. 흔히 grid라고 하면 compute grid와 data grid 두 가지를 구분해볼 수 있는데 기존의 컴퓨팅을 분산하는 방법은 compute grid의 영역이고, data replication의 다양한 영역은 data grid의 영역이다. GridGain은 compute grid 솔루션이라고 볼 수 있고 data grid는 상용인 Oracle Coherence나 오픈 소스인 JBossCache 같은 솔루션을 들 수 있다. GridGain의 여러 가지 기능과 구조에 대해서 깔끔하게 정리된 문서는 없지만, 자바와 함께 발전해온 여러 가지 장점들을 잘 통합해놓았다는 느낌이다. AOP나 Spring(IOC 패턴)과의 결합 그리고 그리드 자체의 여러 기능들... 아래 URL에 있는 위키를 참조하면 되겠다. http://www.gridgain.com/product_features.html http://www.gridgainsystems.com/wiki/display/GG15UG/Basic+Concepts

블로거에 손을 댄지 꽤나 많은 시간이 흘렀다. 뭔가 글로 publish해야겠다는 욕구가 없었고, 또 계기가 될 incident들에 대한 sensor가 동작하지 않았다. 하나의 목표에 강박하여 다른 여유가 없었거나, 환경적 요인에 짓눌려 sensor를 꺼버렸거나, 그저 현상에 적응하여 사고 엔진을 정지시켰거나... 세상은 참 도전적인 곳인데, 한번 마음을 무너뜨리면 다시 돌이키기 어렵다. 신중하고, 깊이있게 뒤돌아보고, 조급하지 말아야 할 터이나 재촉하는 시간에 쉽게 결어부터 정해버린다. 엄청난 수의 이벤트들이 끊임없이 발생한다. 하지만, 이벤트 처리가 가능하려면 적합한 sensor가 가동 중이어야 한다. event sensor는 noise를 filtering해서 불필요한 event들을 discard하고, 유효한 event들을 stream 형태로 stream processor에게 넘긴다. event sensor가 event stream을 stream processor에 넘겨주면 stream processor가 적합한 형태로 가공을 해야 한다. semantic pattern filter가 동작하고 aggregation filter가 동작하고, 또 stream query가 동작한다. 이제 event processor의 결과 내용에 따라, decision이 필요하다. 여러 가지 business evaluation을 거쳐 action을 취해야 한다. 어느 하나라도 정상 동작하지 않으면 모든 이벤트는 외부 자극에서 빠지게 되거나 잘못된 action이 이루어진다. 모든 것이 정상 동작하더라도 evaluation이 정확한지 여부는 여전히 의심스럽다. 모든 것이 잘 evaluate되더라도 대응 action이 최선인지 여부는 여전히 알 수 없다.