IT 블로그에 웬 유전자 관련 내용이냐고 의아해 하실 분도 있겠군요.
하지만 요즈음 가장 각광받는 분야중 하나가 바로 Bio-informatics!
즉 생물의 생명정보를 컴퓨터를 이용해 정리하고 분석하는 것입니다.
그리고 그 중에서 빼놓을 수 없는 것이 바로 생명체의 유전정보 이지요.
데이터의 량이 방대하고, 패턴이 복잡하여 컴퓨터의 도움없이 분석하기가 어렵답니다.

그래서 이번 포스팅을 통해, 선수지식을 알려드리려 합니다.
아래 자료는 생물체 유전자의 구조, 역할, 작동 방식에 대해 매우 쉽게 설명한 자료입니다.
그냥 소설책 보시듯이 휘휘 읽으셔도 될 정도니 부담없이 보시길...
(이 정도는 상식으로 알아두심이... ㅎㅎ)

꽘스와 함께하는 유전자 탐험
View more presentations from OnTheWheel.


다음 포스팅에서는 생명체의 DNA를 어떻게 데이터화 하는지,
'시퀀싱'이라고 일컫는 과정에 대해 간단히 알아보도록 하겠습니다. ^^
신고
Posted by OnTheWheel

댓글을 달아 주세요

1.What is EDA?

 EDA(Event-driven architecture)라는 용어에 대한 정의는 약간씩 다르지만, 공통적으로 거론되는 키워드들을 중심으로 정리하면 다음과 같이 말할 수 있다.

 분산된 시스템 간에 이벤트를 생성, 발행하고 발행된 이벤트를 필요로하는 수신자에게 전송, 필요에 따라 처리하는 시스템 아키텍쳐

 따라서 EDA를 이해하려면 이벤트 대한 정의, 시스템 구성, 각 구성 요소에 대한 이해가 필요하다.

 

- 이벤트란 무엇인가?

 EDA에서의 이벤트란 시스템의 내,외부에서 발생한 '주목할 만한 상태의 변화(a significant change in state)'를 뜻한다. 자동차라는 컴포넌트를 예로 들면

1. 초기 상태가 '판매중(for sale)' 인 자동차가

2. 고객의 구매로 인하여

3. '판매됨(sold)' 상태로 바뀌게 되며

 자동차의 상태 변화를 감지한  판매 시스템은 이 이벤트를 발행하고 이벤트 중개자에 의해 재무, 마케팅 등 판매 이벤트를 필요로 하는 시스템으로 자동 전송된다. 이렇게 전송된 이벤트는 각 시스템의 요구에 따라 적절한 처리 과정을 수행하게 된다.

 

 - EDA의 구성 요소

 EDA는 크게 3개의 구성 요소로 나누어 볼 수 있다.

  •  Event generator : 시스템 내,외부의 상태 변화를 감지하여 표준화된 형식의 이벤트를 생성

  •  Event channel : 이벤트를 필요로 하는 시스템까지 발송

  •  Event processing engine : 수신한 이벤트를 식별, 적절한 처리를 함. 때에 따라 이벤트 처리의 결과로 또 다른 이벤트를 발생시킬 수 있음.

 앞의 예에서 판매 시스템은  Event generator, 중개자는 Event channel, 재무, 마케팅 시스템은 Event processing engine에 해당한다.


- Event processing styles

  수신한 이벤트를 처리하는 방법에는 세가지 종류가 있다.

  •  Simple event processing

 각각의 이벤트가 직접적으로 수행해야할 action과 매핑되어 처리 됨. 실시간으로 작업의 흐름을 처리할 때 사용되며, 이벤트 처리 시간과 비용의 손실이 적다.

  •  Event Stream Processing

 이벤트를 중요도에 따라  필터링하여 걸러진 이벤트만을 수신자에게 전송. 실시간으로 정보의 흐름을 처리할 때 사용되며, 기업에 적용될 경우 신속한 의사 결정을 가능케한다.(BAM)

  •  Complex event processing

 일상적인 이벤트의 패턴을 감지하여 더 복잡한 이벤트의 발생을 추론하는 것. 예를 들어 '주식의 등락'이라는 일상적인 이벤트의 패턴을 감지하여 '투자 적기'라는 상위의 이벤트를 추론해 낼 수 있다.

 

2.EDA & SOA

  얼핏 보면 두 아키텍쳐 간에 큰 차이가 없어 보이지만 둘 사이에는 근본적 차이가 존재한다.

  • SOA : 동기화된 요청/응답 방식

  • EDA : 비동기화된 배포/구독 방식

 

  더 자세히 설명하자면 SOA의 경우 1.필요한 서비스를 찾고, 2서비스 제공자에게 서비스를 요청하고, 3 요청에 대한 응답을 받는 단계를 순차적으로 처리한다. 즉 서비스 요청자와 제공자가 사전에 '표준화 된 호출 규약'을 합의해야하며, 하나의 서비스가 다른 서비스의 상태에 의존성을 가지게 된다.

 

 반면 EDA는 불특정 다수에게 이벤트를 발송하기만 하면 되며, 이벤트의 처리에 대한 내용은 발송자가 전혀 관여하지 않는다. 즉 발송자와 수신자가 서로에 대한 규약 없이 독립적으로 수행된다. 따라서 EDA는 보다 향상된 유연성(loosely coupled)을 제공 한다.

 

 Outsourcing, M&A, 잦은 구조 조정 등으로 인해 기업의 구조가 자주 바뀌는 상황에서 IT 시스템을 구축하고자 한다면 EDA가 더 나은 선택일 수 있다. 그러나 EDA는 SOA의 대체제가 아니라 보충물의 역할을 한다는 견해가 지배적이다.

  • 은행 업무 처럼 트랜잭션 처리가 필수적인 경우

  • 수직적인 기업 구조에서 명령/통제가 필요한 경우

  • 순차적인 처리가 보장되야 하는 경우

 이런 경우 SOA의 사용이 적합하다. 반면 process chain 상에서의 수평적 관계에는 EDA의 사용이 적합하다.

 

 

 

이 글은 스프링노트에서 작성되었습니다.

신고
Posted by OnTheWheel

댓글을 달아 주세요

  1. 붉은돼지 2010.11.19 15:37 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 글 잘 봤습니다.

  2. BlogIcon Christian Louboutin 2011.12.18 13:56 신고  댓글주소  수정/삭제  댓글쓰기

    이전에 영단어 공부하면서 쓰던 책에 epitome이라는 단어가 있었다.

1.데이터 중복 제거란?

 데이터 중복 제거란 서로 다른 데이터(파일)들 간에 중복되는 부분을 검출해내고, 중복된 부분을 제거함으로써 스토리지 활용의 효율성을 높이는 것을 말하며, 크게 보아 데이터 압축의 일종이라고 볼 수 있다. 좀 더 쉬운 이해를 위해 간단한 예를 들어보면, 우리가 매일 사용하는 메일의 첨부 파일을 생각해 볼 수 있다. 가령, 특정 부서의 관리자가 새로 도입된 시스템의 설치 메뉴얼을 100명의 임직원에게 보냈다고 생각해 보자. 만약 데이터 중복 제거를 사용하지 않는다면 똑같은 내용의 파일임에도 불구하고 100개의 파일이 스토리지에 저장되어야 한다. 그러나 만약 데이터 중복 제거를 사용한다면 100개의 파일을 저장하는 대신, 단 1개의 파일을 저장한 후, 그 1개의 파일을 가리키는 포인터 100개를 유지함으로써, 스토리지 사용량을 비약적으로 줄일 수 있다.


 용량 대비 스토리지의 가격이 급속히 하락하면서 데이터의 크기에 대한 제약은 점점 사라지고 있으며, 우리가 다뤄야할 데이터의 양은 점점 더 폭증하고 있다. 특히 이렇게 급증하는 데이터를 백업하기 위해서는 더욱더 방대한 스토리지 및 그것을 뒷받침 하기 위한 시스템이 필요하게 되었다. 그러나 기업이 사용할 수 있는 비용은 언제나 제한되어 있으며, 최소한의 비용으로 방대한 데이터를 유지 및 관리하기 위해서, 데이터 중복 제거는 선택이 아닌 필수가 되어가고 있다.

2.데이터 중복 제거의 이점

  • 데이터 중복 제거의 가장 큰 이점은 역시 비용 절감이다. 일차적으로 스토리지 사용량을 줄여서, 고가의 스토리지 시스템을 확장하는 비용을 절감할 수 있다. 저장되는 데이터의 종류에 따라 최대 90%의 절감율을 보이며, 통상적으로 40% 이상의 스토리지 용량 절감 효과를 갖는다고 한다. 또한 네트워크 사용량 감소로 인한 회선 비용 절감 효과도 누릴 수  있다. 뒤에서 설명할 소스(source) 중복 제거 방식을 사용할 경우 파일 전송이나 백업시의 네트워크 트래픽을 획기적으로 줄일 수 있다.(그 외에도 상면 비용, 전력, 냉각 등 다양한 측면에서 TCO(총 소유 비용) 절감에 도움을 준다.)
  • 데이터 백업 비용의 절감과 효율성 향상 역시 큰 이점이다. 특히 백업의 경우 각각 다른 버젼의 백업 데이터 대부분이 실제로는 중복되는 부분을 매우 많이 포함하므로 중복 제거의 효과를 톡톡히 볼 수 있다. 이러한 스토리지 용량 절감 효과로 인해 용량 대비 비용이 줄어들어 기존에 주로 백업 매체로 사용되어오던 자기 테이프를 디스크로 대체할 수 있다. 테이프는 보관이 어려우며, 순차적인 액세스만 가능하기 때문에 복구시 오랜 시간을 필요로 한다. 반면 랜덤 액세스가 가능한 디스크를 사용하면 필요한 데이터에 직접 접근할 수 있어 복구시 효율성을 높일 수 있다. 또한 앞에서 언급했듯이 소스(source) 중복 제거 방식을 사용할 경우 백업 및 복구시의 네트워크 트래픽이 줄어들고, 이는 백업에 소요되는 시간의 단축으로 이어진다. 즉 백업의 수행 주기를 더 작게 유지하여, 한 단계 높은 서비스 수준(SLA)을 보장하는데 도움이 된다.
  • 서버 가상화가 일반화된 요즈음, 데이터 중복 제거는 또 다른 의미를 갖는다. 바로 가상화 이미지 백업에 활용될 수 있는 것이다. 가상화 이미지는 일반적으로 그 크기가 매우 크며, 실행중인 시스템에 대한 모든 정보를 담고있기 때문에 반드시 백업이 필요하다. 가상화를 사용하는 기업의 데이터 센터는 물론이고, 가상화된 자원을 서비스로 제공하는 IaaS 제공자에게 고객이 사용하는 이미지의 백업 및 복구는 필수 사항이다. 결국 방대한 용량을 갖고 중복 부분이 큰 이미지 백업에 중복 제거는 그야말로 안성맞춤이라 하겠다. (실제로 많은 중복 제거 솔루션들이 가상화 관리 솔루션에 통합된 이미지 백업 기능을 제공하고 있다.)

3.데이터 중복 제거의 분류

 데이터 중복 제거는 몇가지 기준에 따라 분류될 수 있다. 각각의 장단점을 살펴보자.

3.1.중복 제거의 수준에 따른 분류

  •  먼저, 파일 수준의 중복 제거는 말 그대로 파일 전체가 중복되는 경우에만 중복 제거를 수행하는 방식으로 SIS(Single Instance Storage)라고도 불린다. 중복되는 파일이 많은 경우 손쉽게 구현될 수 있다는 장점이 있으나 효율성 면에서는 바람직하지 못하다. 예를 들어, 두 파일이 딱 1비트만 달라도 서로 다른 파일로 인식되기 때문이다.
  •  반면 한 파일을 블록(혹은 청크, 세그먼트) 단위로 나누거나 비트 단위의 중복 제거를 수행하는 방식이 있다. 중복되는 블록은 오직 1번 저장되고, 그 블록을 가리키는 포인터를 저장함으로써 추후에 파일을 재조합할 수 있다. 당연히 효율성 면에서는 파일 수준의 중복 제거보다 훨씬 뛰어나다. 블록 수준의 중복 제거는 다시 두가지로 나뉠 수 있다. 블록의 크기가 고정되어있는 고정 길이 방식과 블록의 크기가 가변적인 가변 길이 방식이 그것이다. 일반적으로 블록의 길이를 최적화 할 수 있고, 중복된 블록의 파일 내 오프셋 변경이 가능한 가변 길이 방식이 더 효율적이다.

3.2.중복 제거가 일어나는 장소에 따른 분류

  •  먼저, 애플리케이션(예를 들면 백업 프로그램)이 위치하는 데이터 소스에서 중복 제거가 이루어지는 소스(source) 중복 제거 방식이 있다. 별도의 데이터 중복 제거 모듈을 소스 디바이스에 설치한 후, 중복된 부분에 대해서는 그 포인터 만을 타깃 스토리지에 전송하는 방식이다. 위에서 언급했듯이 실제 데이터를 전송하지 않고 그 포인터만을 전송하기 때문에 네트워크 트래픽이 크게 줄어드는 장점이 있다. 그러나 중복 제거 작업이 많은 CPU 작업을 요구하기 때문에 본래 애플리케이션의 수행에 오버헤드로 작용할 수 있다.
  •  반면 소스 디바이스에서 보내진 원본 데이터를 타깃 스토리지 측에서 중복 제거하는 방식을 타깃(target) 중복 제거 방식이라고 한다. 소스 디바이스에 별도의 오버헤드가 없고, 중복 제거 기능을 갖추지 않은 기존의 애플리케이션을 그대로 사용할 수 있다는 장점이 있으나 전송되는 데이터의 크기가 클 경우 대량의 네트웍 트래픽이 발생하며 백업 및 복구 소요 시간이 커질 수 있다.
  •  위의 두 방식의 절충점이 바로, 소스와 타깃 사이에 전용 어플라이언스를 두는 것이다. 위에서 설명한 두 방식의 장점을 고루 가지고 있지만 전용 어플라이언스의 비용 및 확장성이 문제가 될 수 있다. 소스 디바이스의 갯수가 늘어나면 전용 어플라이언스 갯수 역시 늘어나야 하며, 잘못하면 어플라이언스가 병목 구간으로 작용할 수 있다.

3.3.중복 제거가 일어나는 시점에 따른 분류

  •  모든 데이터를 임시 디스크에 저장한 후, 추후 시점에 데이터 중복 제거를 진행하는 방식을 사후 처리 중복 제거 방식(post-process deduplication)이라한다. 이 방식은 별도의 임시 스토리지가 필요하며, 저장된 임시 데이터가 많을 경우 작업 완료 시간이 지연될 수 있다. 그러나 데이터를 수신하는 시점에는 별도의 오버헤드가 존재하지 않아 빠른 송수신이 가능한 장점이 있다.
  • 데이터를 수신 받은 후 바로 중복 제거 작업을 진행하는 방식이 인라인 중복 제거(in-line deduplication) 방식이다. 별도의 임시 스토리지가 필요치 않으나, 데이터 송수신시 오버헤드가 존재한다.

3.4.중복 제거의 방식에 따른 분류

  •  가장 많이 사용되는 방식은 해시 함수(hash function)를 사용하는 것이다. 특정 파일이나 블록, 혹은 비트 스트림에 대하여 해시 값을 계산하고 해시 값이 같은 두 세그먼트를 중복된 데이터로 간주하는 것이다. 또한 각 해시 값에 대한 인덱스를 유지하여 빠른 저장 및 조회가 가능토록 한다. 그러나 이론상 아무리 강력한 해시(strong hash)를 사용하더라도 해시 충돌(hash collision)의 가능성은 존재한다(그 가능성은 매우 적을지라도). 즉 해시 값이 같은 두 세그먼트가 실제로는 다른 데이터일 수 있다는 것이다. 따라서 경우에 따라서는 해시 충돌을 처리하기 위한 메커니즘이 필요하다.
  •  또 다른 방법으로는 형상 관리 툴에서 주로 사용되는 델타 기반 중복 제거(텔타 인코딩)가 있다. 이 방식은 기본 복제본을 기준으로 향후 변동된 내용에 대해서만 기록하는 방식이다. 해시 방식이 CPU 자원을 주로 사용하는 반면 델타 기반 방식은 이전 복제본과의 비교를 위해 디스크 입출력이 많다. 

4.향후 발전 방향

 현재까지 데이터 중복 제거의 활용 영역은 백업을 비롯한 2차 스토리지에 국한되어 있었다. 그러나 최근 데이터 중복 제거를 1차 스토리지에 활용코자하는 노력이 계속되고 있다. 이를 위해서는 중복 제거에 의한 오버헤드를 최소화하여 작동중인 시스템의 동작에 주는 악영향을 줄여야 한다. 또한 각종 SW 솔루션의 수정이나 별도의 통합 작업 없이 데이터 중복 제거 기능을사용할 수 있도록 표준화된 인터페이스를 제공해야 한다.

이 글은 스프링노트에서 작성되었습니다.

신고
Posted by OnTheWheel

댓글을 달아 주세요

 자, 약속드린대로 통계에 대한 연재를 시작해 보지요. 첫 포스팅이니 가볍게 출발하는 마음으로 통계란 무엇일까를 함께 생각해 보면 좋겠습니다. 원래 모든 발표와 모든 공부는 정의에서 시작하는 법이죠.. 쿨럭 -_ㅡ;;

 자 여러분, 그렇다면 통계(Statistics)란 무엇일까요? 여러가지 정의가 있겠지만, activity의 측면에서 보면...

  • 필요한 데이터를 올바로 수집하고
  • 수집된 데이터를 요약하여 표현하며
  • 데이터를 분석하여 어떤 사항에 대해 판단하며
  • 분석에 기초하여 미래를 예측하는 것.

 정도라고 할까요? 예를 들어 설명하면...

  • 수집 : 매 선거마다 실시되는 출구조사를 예로 들 수 있겠지요? 하지만 데이터 수집도 체계적으로 하지 않으면 엉뚱한 결과를 초래할 수 있습니다. 만약 충청도나 경상도 같은 특정 지역에서만 조사를 한다면, 분명 분석 결과도 엉뚱하게 나올 겁니다.
  • 요약 : 우리가 흔히 알고 있는 평균, 분산, 표준편차 등을 이용하면 데이터의 전체적 특성을 짧게 요약하여 말할 수 있습니다. "우리 반 성적은 평균 80점이야."라는 말은 우리반 성적을 대표하는 값이 80 이란 이야기이고, "우리 반 성적은 표준편차가 4.5야." 라는 말은 대부분의 학생들이 평균적으로 4.5 내외의 편차를 가진다는 이야기이죠.
  • 분석 및 판단 : 통계적 분석으로 어떤 일이 일어날 확률을 구할 수 있으며, 더 나아가 어떤 가설에 대한 판단이 가능합니다. 예를 들어 우리 반 학생을 아무나 한 명 골랐을 때 85점 이상의 성적이 나올 확률을 구한다거나, "우리 학교 애들은 보통 83점 이상은 돼." 라는 교장 선생님의 구라에 대해 올바른 판단을 내리는데 도움을 줍니다.
  • 예측 : 만약 '할머니의 무릅 통증'과 '비오는 날'에 대한 데이터를 분석하고, 둘 간의 상관 관계를 이끌어 낸다면 "오늘 할머니 무릎 통증이 X 만큼 심하니 우산을 준비해야겠군." 이런 예측이 가능하지요 -_ㅡ;;

 결국 이런 통계적 도구들을 무기로 삼는다면 여러분의 회사생활이 조금은 수월해지지 않을까요?

거시기... 방학도 돌아오고 허니 초딩들을 위한 장난감을 메인에 걸면 어떨런가요?

 라고 말하기보다,

시스템 로그 분석 결과 방학 기간 동안 초딩들의 트래픽이 42.5% 급증하니 초글링을 집중 공략해야 합니다.

 라고 말하면 간지도 나고, 열심히 일한 티도 나고, 설득력도 있지요.('설득의 법칙'이란 책을 읽어보시길...) 그럼, 저와 여러분의 성공적인 회사 생활을 위해, 앞서 언급한 것들에 대해서 조금씩 포스팅 해나가겠습니다.

 

이 글은 스프링노트에서 작성되었습니다.

신고
Posted by OnTheWheel

댓글을 달아 주세요




  "웹과 IT를 주로 다루는 블로그에서 웬 통계?" 라고 생각하실지도 모르겠네요. 하지만... 호랑이가 가죽을 남기고, 사람이 이름을 남긴다면, 웹 서비스는 로그를 남기는 법이지요.

 비록 말못하는 웹 서비스이지만 자신이 안고있는 문제점과 희망 사항을 '로그'라는 언어로 남기기 마련이지요. 그렇기에 로그를 통계적으로 분석해서 의미있는 정보를 끌어내는 것은 정말 중요한 작업입니다.

 통계적인 분석을 통해서 생성된 자료는 전략 수립, 기획, 아키텍쳐 설계, 운영에 이르기까지 전 과정에 있어서 중요한 의사결정을 위한 참고자료 및 근거로써 사용할 수 있습니다. 그렇기에 통계의 기본 원리를 아는 것이 중요하다고 생각했고, 나름대로 공부한 내용들을 이 블로그를 통해 간단히 정리하고, 공유하려고 합니다.

 자주 올린다는 약속은 못 드리겠지만 일주일에 한 두번 꼴로 꾸준히 올린다는 약속은 꼭 지키도록 노력해 보지요. 그리고 혹시나 잘못된 내용이 있으면 꼭 지적해 주세요. 바로 수정토록 하겠습니다.

 그럼... 여러분들께 도움이 되길 바라며, '통계의 기초'로 향하는 완행 열차를 운행해 보도록 하지요~! 함께 해욤~! 오라이~!
신고
Posted by OnTheWheel

댓글을 달아 주세요

  1. BlogIcon harris 2008.12.10 11:22 신고  댓글주소  수정/삭제  댓글쓰기

    와우~기대 만빵입니다.^^*

  2. BlogIcon 오리™ 2008.12.10 14:57 신고  댓글주소  수정/삭제  댓글쓰기

    기대되네요. ^^



티스토리 툴바