반응형
KT의 GenomeCloud 서비스에는 연구자가 손쉽게 Reference Genome에 대해서 Mapping과 Variant Call을 해주고 데이터를 관리해 주는 g-Analysis라는 서비스가 있습니다. Mapping을 수행하고 나면 BAM이라는 표준 포맷으로 결과를 제공하고 있는데, 이 파일은 Human의 경우 대략 100 ~ 200 GB 정도의 크기가 됩니다.
GenomeCloud에서의 BAM 파일 활용법
이 파일을 가지고 Variant Call 이나 Genome Browser를 통해 시각화하는데에 사용됩니다. 그래서 GenomeCloud 서비스에서는 다음의 4가지 방법으로 이 파일을 사용할 수 있도록 하고 있습니다.
이제까지는 일반 사용자들을 위한 글이었습니다. 어떻게 구현된건지 궁금하신 분들이라면 계속 글을 읽으셔도 되지만, 필요 없으신 분은 여기까지만 읽고 창을 닫아도 됩니다. ^^;;
Indexed file & byte-range request를 이용한 BAM 파일 액세스
BAM 파일은 인덱스 정보가 담긴 인덱스 파일 (확장자가 .bai)과 함께 사용됩니다. IGV에서는 BAM 파일과 BAI 파일이 같은 폴더내에 존재해야 하죠. 가령 IGV를 통해 염색체 1번의 1,000~2,000 bp를 보고자 할때 IGV는 몇백기가바이트나 되는 BAM 파일을 모두 다운로드하지 않습니다. 모두 다운로드 후 보여주려면 시간이 많이 걸리기 때문입니다.
원격지의 BAM 파일을 요청할때에 IGV는 http request에 byte-range라는 header를 넣어서 요청합니다. 다시 정리하자면 원격지 BAM 파일을 요청하면 인덱스 파일을 우선 다운로드 합니다. 이 인덱스 파일을 통해 염색체 1번의 1,000~2,000 bp에 해당하는 부분이 실제 BAM 파일의 어느 부분인지를 계산해서 해당 부분만을 요청하기 때문에 전체 BAM 파일을 다운로드하지 않고 빠르게 해당 부분을 볼 수 있습니다.
따라서, BAM, TDF 등과 같이 indexed된 파일은 반드시 byte-range request를 지원하는 서버에 저장되어 있어야 합니다. Apache 웹 서버는 이를 지원하고 있습니다만 GenomeCloud에서는 Apache와 같은 웹 서버가 아닌 직접 구현한 서버를 통해 제공되기 떄문에 byte-range request를 직접 구현하여 제공하고 있습니다.
직접 구현해서 제공하고 있다는 것은 무슨 의미인가? BAM 파일이 됐건 모든 파일은 KT의 클라우드 스토리지인 swift에 저장되어 있습니다. swift는 아마존의 S3와 같은 스토리지로 비교적 저렴한 가격에 대용량의 파일을 저장하여 사용할 수 있습니다. 문제는 사용자가 직접 swift에 접속하여 파일을 IGV를 통해서 볼 수 있도록 하면 되지만, 이렇게 되면 swift의 인증 계정과 키를 클라이언트(사용자)측에서 관리되어야 하고 이러한 경우 보안에 취약성이 발생할 수 있게 됩니다. 따라서 사용자(클라이언트)와 swift(실제 파일 저장소) 사이에 서버를 두어 swift의 인증을 클라이언트가 아닌 서버에서 처리하고 서버가 swift에 접근하여 해당 파일을 받아서 클라이언트에 쏴~아 주는 방식입니다. 이렇게 되면 보안에 문제가 없게 되지만 다운로드되는 파일은 중간에 서버를 한번 거치게 되기 때문에 속도 저하가 발생할 수도 있게 됩니다. 또한 직접 구현한 서버이기 때문에 IGV에서 보낸 byte-range request 또한 직접 swift쪽에 전달하고 이를 받아서 다시 클라이언트에 전달해야 하죠.
Swift 파일 인증과 node를 통한 전달
그래서 클라이언트와 swift사이에서 인증과 데이터 전달을 처리하는 서버를 node.js를 통해 구현했습니다. Apache를 proxy 서버를 두어 실제 사용자는 Apache 서버에 https 요청을 하지만 프록시일 뿐 실제는 node가 처리하죠. 이미 보안은 구현된 상태이지만, 다시 한번 사용자의 GenomeCloud의 아이디와 암호를 넣어야 파일을 다운로드 할 수 있도록 IGV가 사용자 아이디와 암호를 요구 하도록 했습니다. 기본적으로 IGV는 Apache의 Web Auth를 통해 인증을 요구하는 페이지에 접속한 경우 아이디와 암호를 물어보도록 구현되었기 떄문에 이를 node에서 구현하여 처리하도록 했습니다.
실행은 java의 WebStart를 통해 Jnlp 파일을 실행하면 IGV가 실행되면서 자동으로 원격지의 BAM 파일에 접근합니다. 우선 Java WebStart를 통해 실행되면서 해당 jar 파일들에 대해서 인증서 검증을 합니다만, Broad에서 IGV에 대한 digital signature가 expired 되어서 -.-;; 이렇게 Security Information 창이 떠버립니다. 믿을 수 있으니 "Run" ㅋ
그 다음엔 파일을 접근하는 서버가 https인데 아직 서버 인증이 없어서 사설 인증을 하다보니 다시 한번 Security warining이 뜨지만, 안심하고 다시 "Yes" 버튼을 클릭합니다.
이제 마지막으로 해당 파일에 접근하기 위한 Username과 Password를 입력하면, IGV가 실행되면서 BAM 파일을 볼 수 있습니다.
IGV 실행 화면과 3rd Party 어플리이케이션 연동
다시 한번 말씀드리자면, BAM 파일과 같은 경우 웹 페이지상에서 손쉽게 g-Browser를 사용하시거나 자바 (JRE)가 설치된 데스크탑에서 IGV를 직접 실행하여 안전하게 파일을 visualization 할 수 있습니다. 하지만 로컬에 파일 전부를 다운로드 하지 않고 byte-range req를 통해 빠르게 액세스 하여 IGV의 모든 기능을 사용할 수 있습니다.
IGV가 GenomeCloud에 접근하는 것처럼 여러분이 만든 프로그램 (자체 개발한 Variant Call 알고리즘이나 Annotation 툴)을 GenomeCloud에 연동 할 수 있습니다. 이부분은 자체 API 정리가 끝나면 공개하여 여러분들이 만들어가는 GenomeCloud가 될 수 있도록 할것입니다. 아마 그 첫번째는 IGV가 되고 두번째는 시퀀싱 센터와의 연동이 될 것이며 세번째는 바로 당신의 어플리케이션이 될 것입니다. ^___^
GenomeCloud에서의 BAM 파일 활용법
이 파일을 가지고 Variant Call 이나 Genome Browser를 통해 시각화하는데에 사용됩니다. 그래서 GenomeCloud 서비스에서는 다음의 4가지 방법으로 이 파일을 사용할 수 있도록 하고 있습니다.
- GenomeCloud에 그냥 보관 (저희가 안전하게 보관해 드립니다. 1개월 또는 1년 단위로 추후 이 기간은 더 늘어 날 예정)
- 로컬로 다운로드 (GenomeCloud 클라이언트 툴을 이용해서 원하는 로컬로 다운로드 가능)
- 클러스터 컴퓨터로 export (클러스터 컴퓨터로 export하여 바로 2차 분석이 가능하도록 제공)
- GenomeCloud의 Genome Browser (g-Browser)로 시각화 (웹 페이지상에서 시각화가 가능하기 때문에 별도의 Genome Browser를 설치하거나 셋팅하지 않아도 된다는 잇점이 있지만 매핑된 Read등을 확인하는 등 제한된 기능만을 제공)
- 로컬의 IGV를 이용하여 시각화 (두말할 필요도 없겠죠, 걍 GenomeCloud에서 버튼 하나만 클릭하면 로컬에서 IGV가 실행되어 원격지의 BAM 파일을 읽어들여 시각화)
- Browsing Sample: 내장된 Genome Browser(g-Brwoser)가 실행되어 웹상에서 시각화
- Conduct New Analysis: BAM 파일을 가지고 Variant Call을 할 수 있도록 Wizard가 실행
- New Folder, Rename Folder, Delete, Rename File: 말 그대로 폴더를 생성하고 이름을 변경, 삭제하는 기능
- g-Cluster Export: 해당 BAM 파일이 들어있는 새로운 클러스터 컴퓨터 생성
- App Lunch (IGV): 3rd Party 어플리케이션을 실행하는 메뉴로 BAM 파일을 입력으로 하는 외부 프로그램을 실행하는 메뉴입니다. 현재 IGV가 App으로 등록되어 실행 가능하며(정식 출시 시점에 공개), 추후 협력사?를 통해 다양한 App들을 지원하도록 할 예정입니다. 가령 새로운 Variant Call 알고리즘을 개발한 랩에서 저희 GenomeCloud와 연동하여 해당 알고리즘을 실행하여 저희 플랫폼에서 판매?가 가능하도록 말이죠.
이제까지는 일반 사용자들을 위한 글이었습니다. 어떻게 구현된건지 궁금하신 분들이라면 계속 글을 읽으셔도 되지만, 필요 없으신 분은 여기까지만 읽고 창을 닫아도 됩니다. ^^;;
Indexed file & byte-range request를 이용한 BAM 파일 액세스
BAM 파일은 인덱스 정보가 담긴 인덱스 파일 (확장자가 .bai)과 함께 사용됩니다. IGV에서는 BAM 파일과 BAI 파일이 같은 폴더내에 존재해야 하죠. 가령 IGV를 통해 염색체 1번의 1,000~2,000 bp를 보고자 할때 IGV는 몇백기가바이트나 되는 BAM 파일을 모두 다운로드하지 않습니다. 모두 다운로드 후 보여주려면 시간이 많이 걸리기 때문입니다.
원격지의 BAM 파일을 요청할때에 IGV는 http request에 byte-range라는 header를 넣어서 요청합니다. 다시 정리하자면 원격지 BAM 파일을 요청하면 인덱스 파일을 우선 다운로드 합니다. 이 인덱스 파일을 통해 염색체 1번의 1,000~2,000 bp에 해당하는 부분이 실제 BAM 파일의 어느 부분인지를 계산해서 해당 부분만을 요청하기 때문에 전체 BAM 파일을 다운로드하지 않고 빠르게 해당 부분을 볼 수 있습니다.
따라서, BAM, TDF 등과 같이 indexed된 파일은 반드시 byte-range request를 지원하는 서버에 저장되어 있어야 합니다. Apache 웹 서버는 이를 지원하고 있습니다만 GenomeCloud에서는 Apache와 같은 웹 서버가 아닌 직접 구현한 서버를 통해 제공되기 떄문에 byte-range request를 직접 구현하여 제공하고 있습니다.
직접 구현해서 제공하고 있다는 것은 무슨 의미인가? BAM 파일이 됐건 모든 파일은 KT의 클라우드 스토리지인 swift에 저장되어 있습니다. swift는 아마존의 S3와 같은 스토리지로 비교적 저렴한 가격에 대용량의 파일을 저장하여 사용할 수 있습니다. 문제는 사용자가 직접 swift에 접속하여 파일을 IGV를 통해서 볼 수 있도록 하면 되지만, 이렇게 되면 swift의 인증 계정과 키를 클라이언트(사용자)측에서 관리되어야 하고 이러한 경우 보안에 취약성이 발생할 수 있게 됩니다. 따라서 사용자(클라이언트)와 swift(실제 파일 저장소) 사이에 서버를 두어 swift의 인증을 클라이언트가 아닌 서버에서 처리하고 서버가 swift에 접근하여 해당 파일을 받아서 클라이언트에 쏴~아 주는 방식입니다. 이렇게 되면 보안에 문제가 없게 되지만 다운로드되는 파일은 중간에 서버를 한번 거치게 되기 때문에 속도 저하가 발생할 수도 있게 됩니다. 또한 직접 구현한 서버이기 때문에 IGV에서 보낸 byte-range request 또한 직접 swift쪽에 전달하고 이를 받아서 다시 클라이언트에 전달해야 하죠.
Swift 파일 인증과 node를 통한 전달
그래서 클라이언트와 swift사이에서 인증과 데이터 전달을 처리하는 서버를 node.js를 통해 구현했습니다. Apache를 proxy 서버를 두어 실제 사용자는 Apache 서버에 https 요청을 하지만 프록시일 뿐 실제는 node가 처리하죠. 이미 보안은 구현된 상태이지만, 다시 한번 사용자의 GenomeCloud의 아이디와 암호를 넣어야 파일을 다운로드 할 수 있도록 IGV가 사용자 아이디와 암호를 요구 하도록 했습니다. 기본적으로 IGV는 Apache의 Web Auth를 통해 인증을 요구하는 페이지에 접속한 경우 아이디와 암호를 물어보도록 구현되었기 떄문에 이를 node에서 구현하여 처리하도록 했습니다.
실행은 java의 WebStart를 통해 Jnlp 파일을 실행하면 IGV가 실행되면서 자동으로 원격지의 BAM 파일에 접근합니다. 우선 Java WebStart를 통해 실행되면서 해당 jar 파일들에 대해서 인증서 검증을 합니다만, Broad에서 IGV에 대한 digital signature가 expired 되어서 -.-;; 이렇게 Security Information 창이 떠버립니다. 믿을 수 있으니 "Run" ㅋ
그 다음엔 파일을 접근하는 서버가 https인데 아직 서버 인증이 없어서 사설 인증을 하다보니 다시 한번 Security warining이 뜨지만, 안심하고 다시 "Yes" 버튼을 클릭합니다.
이제 마지막으로 해당 파일에 접근하기 위한 Username과 Password를 입력하면, IGV가 실행되면서 BAM 파일을 볼 수 있습니다.
IGV 실행 화면과 3rd Party 어플리이케이션 연동
다시 한번 말씀드리자면, BAM 파일과 같은 경우 웹 페이지상에서 손쉽게 g-Browser를 사용하시거나 자바 (JRE)가 설치된 데스크탑에서 IGV를 직접 실행하여 안전하게 파일을 visualization 할 수 있습니다. 하지만 로컬에 파일 전부를 다운로드 하지 않고 byte-range req를 통해 빠르게 액세스 하여 IGV의 모든 기능을 사용할 수 있습니다.
IGV가 GenomeCloud에 접근하는 것처럼 여러분이 만든 프로그램 (자체 개발한 Variant Call 알고리즘이나 Annotation 툴)을 GenomeCloud에 연동 할 수 있습니다. 이부분은 자체 API 정리가 끝나면 공개하여 여러분들이 만들어가는 GenomeCloud가 될 수 있도록 할것입니다. 아마 그 첫번째는 IGV가 되고 두번째는 시퀀싱 센터와의 연동이 될 것이며 세번째는 바로 당신의 어플리케이션이 될 것입니다. ^___^
반응형