라즈베이 파이(Raspberry Pi) - 볼루미오(Volumio) 3에서 2로 돌아가기

구관이 명관인가? 가끔은 그럴 때도 있다. 구관이 명관일 확률이 1/2이라면, 인류 역사에 발전이란 아예 없었을 것이다. 세상 모든 일에는 양과 질의 문제가 전부 존재하므로, 수십 수백 명의 구관이 세상을 적당히 주무른 뒤 나타난 유능한 한 명의 신관(?)이 세상을 완전히 바꿀 가능성도 있을 것이다.

라즈베리 파이 3B(구입 당시 글 링크)에 설치한 볼루미오를 쓰면서 점점 성능이 예전 같지 않다고 느끼게 되었다. 주로 업데이트를 한 후가 그러했다. UI는 조금씩 나아지지만, Wi-Fi를 제대로 잡지 못하는 일이 많아졌다. 정격 용량이 나오는 전원 어댑터를 구입하여 이전에 사용하던 휴대폰 충전기를 대체하고, 조금이라도 거실의 무선 공유기에 가깝게 놓으려고 라즈베리 파이의 위치를 바꾸어 보기도 했다. 가장 최근의 버전인 볼루미오 3.224-2222로 업데이트한 뒤에는 아예 와이파이망 연결이 되지 않았다. 유선 랜으로만 라즈베이 파이를 써야 한다면 그 무슨 재미가 있겠는가?

이번 주말에는 아예 작정을 하고 와이파이 불량 문제를 해결해 보기로 하였다. 최신 이미지를 마이크로SD 카드에 기록하여(balenaEtcher 사용) 몇 번이고 재설치를 하였으나, 여전히 무선 연결이 되지 않았다. 내장 무선 네트워크 어댑터에 이상이 생겼을까? 다이소에서 구입했던 USB 와이파이 수신기(802.11N)을 꽂아 보았다. 

싸구려 USB 플래시 드라이브 위에 꽂은 싸구려 와이파이 수신기(구입 당시 글 링크)

그러나 아무리 노력을 해도 와이파이 접속이 되지 않았다. 내장 무선 랜카드를 무력화하고 USB 포트에 꽂은 것이 우선하여 쓰이도록 설정을 바꾸어야 할까? 검색을 거듭하며 찾아낸 짤막한 정보를 바탕으로 아무리 설정 파일을 건드려 보아도 소용이 없었다.

토요일 아침 이른 몇 시간을 이렇게 날려 버린 뒤, 볼루미오의 이전 버전으로 돌아가 보기로 하였다. 볼루미오 커뮤니티 사이트에서 2.917-2021-1006 버전('Volumio 2 download URL?' 링크; broken.pipe의 댓글 참조)을 구한 뒤, 마이크로SD카드에 기록한 다음 재설치를 시도하였다. 결과는 놀라웠다. 너무나 잘 작동하는 것이었다! 별도로 꽂은 USB 와이파이 어댑터에 자동으로 우선권이 부여되면서 언제 그랬냐는 듯이 거실에 놓인 무선 공유기의 와이파이 설정을 그대로 인식하는 것이 아닌가... 설치 후 첫 설정을 할 때 아예 이더넷 케이블을 연결하지 않은 상태에서 볼루미오의 핫스팟 기능을 이용하여 휴대폰에서 접속·제어하는 것은 아직 익숙하지가 않다. 볼루미오 3에서는 모니터와 키보드를 연결하여 타이핑을 하면 글자가 잘 나타나지 않거나, 커서가 갑자기 사라지고, 심지어는 엔터를 쳤는데 커서가 다음 줄이 아니라 입력이 이루어진 바로 그 줄의 홈 위치고 가기도 하였다. 그러나 볼루미오 2 버전으로 되돌리니 그런 현상이 일절 없었다. 

USB 와이파이 어댑터를 꽂으면 wlan0이었던 내장 무선 랜카드는 자동으로 wlan1이 된다.

USB 와이파이 어댑터는 꽂은 상태 그대로 두기로 했다. 라즈베리 파이의 금속 케이스가 와이파이 수신을 다소 불량하게 만든다는 의견평이 있기 때문이다. 이로써 최근 몇 주 동안 나의 <네트워크 음악 재생기> 라즈베이 파이의 활용성을 현저하게 떨어뜨렸던 와이파이 접속 불량 문제가 완전히 해결되었다.

생각하지 못한 곳에서 문제가 해결되어 버리니 오전 내내 여러 시도를 하면서 메모를 해 놓았던 것을 블로그에 기록할 필요가 없어졌다. 업데이트에는 항상 문제가 따를 수 있음을 기억해 두어야 하겠다. 

볼루미오 설치법

1. 마이크로SD카드에 볼루미오 이미지(.img 파일)를 기록한다. 볼루미오를 PC에 설치하려면 다른 저장 매체가 필요할 것이다. 볼루미오는 라즈베리 파이,  PC(X86/X64) 및 ASUS Tinkerboard에 설치할 수 있다.
2. 마이크로SD카드를 라즈베리 파이에 끼우고 유선 인터넷 선을 연결한 다음 전원을 넣은 뒤 5분 정도 기다린다. 볼루미오의 핫스팟 기능을 이용할 수도 있지만, 유선 인터넷을 사용하는 것이 가장 간단하다.
3. 휴대폰이나 컴퓨터의 웹브라우저에서 http://volumio.local에 접속하여 web-UI를 이용하여 설정을 마친다. 와이파이 접속을 위한 SSID와 password 설정을 이때 하게 된다.
4. 즐긴다!

볼루미오 공식 사이트는 https://volumio.com/en/get-started/이다. PDF 파일로 제공되는 quick start guide는 여기에 있다. 이미지 파일을 SD 카드 매체에 기록하는 소프트웨어는 여러가지가 있다. 예전에는 balena etcher를 쓰라고 하더니 요즘은 Raspberry Pi Imager를 쓰라고 권장한다(2023년 1월 31일 확인).

HP 1410-16G 스위치의 미스테리

흔히 스위치 허브라고 불리는 네트워크 장비(모델명: HP 1410-16G)가 복도를 건너온 뒤 제대로 작동이 되지 않는 기이한 현상에 대하여 기록해 보고자 한다. 원래 이 장비는 다음 사진에 보이는 장비(CISCO Catalyst 2960-S Series SI)에 이더넷 케이블로 직접 연결되어 있었다. 설치 장소는 접근이 쉬운 일반 사무실은 아니다.

HP 1410-16G에 딸린 식구들은 리눅스가 설치된 서버 몇 대와 NAS가 전부이다. 리눅스 서버는 최대 4대까지 구동한 적도 있었지만 성능이 노후하여 지금은 하나만 돌리고 있다. 

용이한 서버 관리를 위해 HP 1410-16G와 컴퓨터 및 NAS를 들고 복도 건너편의 내 사무실로 왔다. 사무실에는 벽면에서 랜 케이블이 하나 나와 있는 상태이다. 이를 '메인 인터넷 선'이라고 부르자. 평소에는 업무용 PC와 노트북 등을 사용하기 위해 ipTIME H5008 스위치 허브를 사용하고 있었다. 가끔 인터넷 연결이 끊어지면 H5008의 전원 어댑터를 뺐다가 다시 이어서 재개통을 하였다. 왜 불통 현상이 벌어지는지 그 이유는 모른다.

ipTIME H5008보다는 성능이 더 좋을 HP 1410-16G에 메인 인터넷 선을 꽂은 뒤, 나머지 포트에 NAS와 컴퓨터를 연결하였다. 그런데 인터넷이 전혀 되지 않았다. 게이트웨이까지 ping 명령어를 날려도 아무런 반응이 없었다. 더욱 이상한 것은, 메인 인터넷 선을 꽂은 포트의 Link/Act 표시등에 불이 들어오지 않는다는 점이다.

HP 1410-16G는 메인 인터넷 선이 꽂힌 것을 인식하지 못하는 것 같았다. 케이블이 불량인가? 그럴 수는 없다. 사무실에서 ipTIME H5008에 연결하여 몇 대의 컴퓨터를 이용할 때에 특별한 문제가 없었기 때문이다.

메인 인터넷 선을 ipTIME H5008에 꽂은 다음, 두 스위치 허브를 랜선으로 연결하였다. 그러고나서 HP 1410-16G에 NAS와 몇 대의 컴퓨터를 연결하였다. 이렇게 하니 소통이 원활하다. ipTIME H5008쪽에서 온 랜 케이블을 꽂은 HP 1410-16G 포트는 정상적인 작동을 알리는 불이 깜빡거리고 있었다.

이 현상을 어떻게 이해해야 할까? CISCO 장비에서 출발한 랜 케이블이 긴 배선을 통해 복도를 가로질러 건물 반대편에 있는 내 사무실까지 오는 동안 신호가 많이 약해졌는지도 모른다. 그런데 이렇게 약해진 신호가 ipTIME H5008을 구동하는 데에는 문제가 없고, HP 1410-16G를 구동하지는 못한다는 말인가? 하긴 음질이 좋은 튜너의 감도가 항상 높은 것은 아니니...

메인 랜 선 -> ipTIME H5008 -> HP 1410-16G라는 성공적인(그러나 유일한) 구성에서 중간에 위치한 ipTIME H5008은 일종의 리피터 역할을 한다고 이해해야 되는 것일까? 네트워크 실무를 제대로 이해하지 못하니 그냥 이런 정도로만 이해해야 할 것 같다. 

ipTIME H5008을 치워 버리려 했었는데 이게 뭐람!

머리 없는(headless) 컴퓨터

헤드리스 컴퓨터란 모니터/키보드/마우스 없이 운용되는 컴퓨터를 말한다. 서버 컴퓨터의 경우 보통 원격으로 접속하여 작업을 수행하기 때문에 본체에 이러한 '머리'를 붙이지 않아도 된다. 다소 오래 된 PC 중에는 키보드나 비디오 카드가 없으면 BIOS 수준에서 부팅이 중단되게 만들어진 것도 있다. 랙 마운트 서버라면 공간과 비용을 줄이기 위해 헤드리스 상태로 작업을 하는 것이 일반적이다.

가끔 터미널 에뮬레이터 프로그램으로 리눅스 서버에 접속하여 커널을 업그레이드한 뒤 재부팅 신호를 보내게 된다. 원격에서 컴퓨터를 재부팅할 때 가장 두려운 것은 새로 셋업한 설정이 맞지 않거나 하드웨어 오류가 나서 접속이 되지 않는 것이다. 모니터/키보드/마우스를 직결한 '머리 있는' 컴퓨터라면 훨씬 편안한 마음으로 부팅 프로세스를 진행할 수 있다.

8월이면 장기간의 외부 파견 근무를 나가게 된다. 내가 골방(원래는 통신 설비가 보관된 방)에서 헤드리스 상태로 쓰던 리눅스 서버의 하드디스크 드라이브를 정리하고 나서 1년 동안 비워둘 사무실로 본체를 가지고 왔다. 엄밀히 말하자면 KVM 스위치를 연결하여 사용하였으니 문자 그대로의 헤드리스 컴퓨터는 아니었다. 그러나 가끔 관리 작업이 필요해서 골방에서 엉거주춤 앉지도 못한 채 키보드를 두드릴 때에는 참 구슬프다는 생각이 들기도 했다.

SSH 포트 번호는 기본값인 22번을 쓰지 말라는 것이 전산 보안 담당 부서의 지시 사항이므로, 다른 값으로 바꾸기 위하여 컴퓨터에 직결한 '머리'에서 작업을 시작하였다. CentOS이므로 /etc/ssh/sshd_config 파일을 수정한 뒤 다음 sshd를 재시작하였다.

$ systemctl restart sshd

그런데 터미널에서는 에러 메시지를 토해냄과 동시에 메뉴바에 평소에 보지 못하던 아이콘이 하나 떴다. 뭔가 싶어서 클릭을 해 보았다.

이게 뭔가? SELinux(Security-Enhanced Linux, 보안 강화 리눅스)에서 문제를 발견했다는 뜻이다. 매우 어색하게 국문으로 표시된 설명을 보니 관리자 권한으로 무엇을 어떻게 하면 된다는 아주 친절한 안내가 있었다. 이대로 따라서 한 다음 systemctl 명령으로 sshd를 재시작한 뒤, 원격 컴퓨터에서 Xshell을 열고 바뀐 포트 번호로 접속을 시도하였다. 성공적으로 개통 완료!

SELinux 관련 설정은 리눅스를 새로 깔 때에나 접하고 그 후로는 아예 인식을 하지 못하고 있었다. Red Hat의 SELinux 관련 공식 문서(SELinux 개념, 설정, 사용법)를 참조하면서 /etc/sysconfig/selinux 파일을 열어 보았다. 'SELINUX=enforcing'라는 글귀가 선명하다. 만약 이 리눅스 컴퓨터를 헤드리스 상태로 유지한 채 포트 번호를 바꾸었더라면, 왜 접속이 되지 않는지 도무지 이유를 알 수 없었을 것이다. 그렇기에 컴퓨터에 머리를 붙이는 것이 중요한 것이다.

모니터를 직접 연결하지 않고도 여러 컴퓨터의 상태를 모니터하고 관리를 할 수 있는 방법이 없는 것은 아니다. 시리얼 포트를 이용하는 방법도 있고, 서버급 컴퓨터 중에는 RJ-45 커넥터로 연결하는 관리용 포트를 제공하기도 한다. 그렇다 하더라도 모니터 출력을 직접 보는 것만큼 간단하고도 강력한 수단은 없을 것이다.

보안과 네트워크 관련 설정은 언제나 해결하기 어려운 숙제이다. 그 자체가 어려운 주제이고, 많은 경우에는 서로 다른 OS를 넘나드는 일이기 때문에 더욱 그러하다. 집에서는 볼루미오를 업데이트한 뒤 Wi-Fi를 이용한 접속이 잘 되지 않고 있고, 사무실에서는 Synology NAS의 볼륨을 재구성한 뒤 NAS와 NFS 클라이언트 컴퓨터 측의 GID/UID가 서로 맞지 않아서 파일의 소유주가 이상하게 표현되는 문제에 직면하였다. 이 문제를 해결해야 생활이 편리해 지는데...

Circlator가 canu assembler 버전을 제대로 인식하지 못하는 문제

지난주 미생물 유전체 분석 워크샵을 실시하면서 실제 현장에서 맞닥뜨릴 컴퓨터 활용 환경이 제각각이라는 것을 깨닫게 되었다. 심지어 정부 조직에 속하는 어느 연구소에서 온 사람의 말을 들어보니 sudo 명령을 쓰려면 상급 부서의 허가를 받아야 한다는 것이었다. 쉽게 말해서 'sudo apt install <package>' 명령을 실행하기 어렵다는 뜻이다. 

그렇다면 유전체 분석에 필요한 모든 프로그램을 일반 관리자 권한으로 다룰 수 있는 conda로 설치해야 된다는 뜻이 된다. 교육을 위해서 내가 구축한 환경은 WSL에 우분투(+실습에 필요한 애플리케이션)를 설치하여 테스트를 거친 후 tar로 export한 것이었으니 누구나 다 자기가 사용하는 PC 또는 노트북 컴퓨터에 'wsl --import <배포> tar_file' 명령으로 이를 설치하면 된다. 또는 KRIBBuntu-focal 2205 distro 제작 및 재설치 과정 문서를 참조하여 tar 파일의 도움 없이 직접 자기 컴퓨터에 실습을 위한 환경을 만들어도 된다. 일부 프로그램은 conda를 이용하였지만, environment에 무관하게 골고루 쓰이는 유틸리티는 sudo 권한으로 dep 패키지를 깔았다. 이렇게 조성한 환경에서 박테리아 유전체 몇 개를 조립하는 정도의 일은 별 어려움이 없이 진행할 수 있다. 그러나 진핵 생물의 유전체를 조립하려면 '서버'라고 이름을 붙일만한 수준의 컴퓨터에 프로그램을 설치해야 한다. 

만약 그러한 서버급 컴퓨터에서 일반 사용자의 권한만 가진 상태에서 이번 교육의 실습 내용을 재현해 보려면 어떻게 해야 하는가?  'sudo apt install <package>'를 'conda install <package>'로 대체해야 되는데, 이것이 완벽하게 대응하지는 않는다.

예를 들어 매우 널리 쓰이는 long read assembler인 canu의 예를 들어보자. 오늘 'sudo apt info canu' 명령으로 확인해 보니 canu 1.9+dfsg-1build1 버전이 deb 패키지로 제공되기는 한다. 그런데 덩달아 깔리는 dependency가 무려 462개라고 나온다. 어차피 sudo를 쓰지 않고 canu를 설치하기로 했으니 다른 방법을 알아 보아야 한다. 기본 환경은 conda base environment라고 가정하자. 

만약 이미 만들어진 canu binary를 수동으로 설치한다면? 설치 후 실행을 해 보니 libgomp.so.1 라이브러리를 찾지 못한다.

$ canu --version
/home/kribb/apps/canu-2.2/bin/sqStoreCreate: error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory

'export LD_LIBARAY_PATH=~/miniconda3/lib/'를 먼저 실행해야 canu가 제대로 실행되었다. 만약 conda를 이용하여 canu 패키지를 설치했다면(v2.2), 구동에 필요한 라이브러리의 위치를 제대로 인식하고 있으므로 문제가 생기지 않는다.

Canu를 소스로부터 빌드한다면? Canu GitHub 사이트에서는 별로 권장하지 않는다. 안 될 일이 뭐가 있겠는가? 시도를 해 보니 에러 잔치가 벌어졌다. WSL에 우분투를 설치한 직후에는 프로그램 개발을 위한 환경이 일절 갖추어져 있지 않다. 무엇이 더 필요한가? Conda를 이용하여 설치할 수 있는 의존성을 하나씩 헤아려 보았다. make, gcc, gxx(g++이 여기에 있다), binutils(ar)... 이것을 conda base environment에만 둔다고? 별도의 관리자가 있는 상식적인 수준의 리눅스 서버 컴퓨터라면 이미 시스템 차원에 설치가 되어 있을법한 프로그램들이다. 

Canu의 설치 방법에 이렇게 열을 올렸던 이유는, 바로 circlator(pip로 설치; v1.5.5)에서 canu의 버전을 제대로 인식하지 못하는 문제가 발생했기 때문이다. 이는 이미 canu GitHub 사이트에서 여러 차례 제기된 이슈였다. Conda로 설치하는 circlator(역시 v1.5.5)도 마찬가지였다.

• #113 Canu version is not being detected properly
• #115 canu version

다음은 'circlator procheck' 실행 때 나타나는 에러 메시지이다. 

$ circlator progcheck
Circlator version: 1.5.5

External dependencies:
bwa     0.7.17  /home/kribb/miniconda3/bin/bwa
Found canu but couldn't get version.
nucmer  3.1     /home/kribb/miniconda3/bin/nucmer
prodigal        2.6.3   /home/kribb/miniconda3/bin/prodigal
samtools        1.15.1  /home/kribb/miniconda3/bin/samtools
WARNING: SPAdes version 3.15.5 is being used. It will work, but better results are usually obtained from Circlator using SPAdes version 3.7.1. Although 3.7.1 is not the latest version, we recommend it for Circlator.
spades  3.15.5  /home/kribb/miniconda3/bin/spades.py

Python version:
3.8.12 | packaged by conda-forge | (default, Jan 30 2022, 23:42:07)
[GCC 9.4.0]

Python dependencies:
openpyxl        3.0.10  /home/kribb/miniconda3/lib/python3.8/site-packages/openpyxl/__init__.py
pyfastaq        3.17.0  /home/kribb/miniconda3/lib/python3.8/site-packages/pyfastaq/__init__.py
pymummer        0.11.0  /home/kribb/miniconda3/lib/python3.8/site-packages/pymummer/__init__.py
pysam   0.19.0  /home/kribb/miniconda3/lib/python3.8/site-packages/pysam/__init__.py

가장 적극적인 해결 방법은 external_progs.py의 특정한 라인을 다음의 [1]에서 [2]로 고치는 것이다. 아무리 보아도 [2]가 더 합리적이다.

[1] 'canu': ('-version', re.compile(r'^Canu \D*([\d][\d\.]+)')),
[2] 'canu':('-version', re.compile(r'canu ([\d+\.\d+[\.\d]*)')),

'삽질'을 거듭하면서 circlator의 바람직하지 않은 행동에 대한 확실한 정보를 얻게 되었다. Circlator는 long read assembler로서 canu 또는 spades(default; v3.7.1을 선호하지만 너무 오래되었음) 중의 하나를 필요로 한다. 현재 $PATH에 canu와 spades가 전부 존재한다면 '--assembler {canu, spades}' 인수로 특별히 지정하지 않는 이상 spades를 이용한다. 따라서 기본 조건에서는 circlator가 문제 없이 실행된다. 그러나 canu의 버전을 제대로 인식하지 못하는 상태에서는 '--assembler canu' 조건을 주면 circlator가 에러를 발생한다. 

애플리케이션마다 요구하는 조건이 모두 다르므로, 최적의 실행을 위해서는 환경이 자꾸만 파편화된다. 관리도 어렵고, 발생하는 에러에 대해서 개별적으로 대처해야 한다. Conda 환경이 그 수고를 크게 덜어주는 것은 사실이지만, 기록을 해 놓지 않으면 내가 특정 프로그램을 'conda(또는 mamba) install'로 깔았는지, 또는 pip로 깔았는지 기억하기가 어렵다. 덕지덕지 땜질한 상태에서 프로그램을 사용하다가 특정 파이썬 라이브러리를 임의로 삭제하면 환경이 꼬이기 시작한다. 어쩌면 파편화의 단점을 감수하고서라도 중요 애플리캐이션에 대해서 환경을 독립시켜 두는 것이 바람직할 수도 있다. 꼬인 환경은 싹 지운 뒤 다시 만들면 되기 때문이다.

MicroPIPE 설치 후 테스트 실행을 성공적으로 마치다 - 덩달아 알게 된 프로그램 몇 가지(JAPSA, singularity, Easyfig)

이틀 전에 올린 글(링크)에서 나노포어 유래 박테리아 게놈 시퀀싱 자료의 조립 파이프라인인 MicroPIPE를 소개했었다. 오늘은 이 소프트웨어를 소개한 논문(링크)의 자료 일부를 가져다가 테스트 러닝을 돌리는 중이다. 테스트용 자료는 ST131 계열의 요로감염 대장균인 S129EC이다. 2004년 캐나다의 임상 시료에서 분리된 균주로서 나노포어 데이터는 MicroPIPE 개발팀인 호주 퀸스랜드 대학에서(SRR13089722), 그리고 일루미나 데이터는 Sanger Institute에서(ERR161292) 생산하였다. 서로 다른 기관에서 약 8년의 간격을 두고 별도로 생산하여 등록한 자료라서 BioSample이나 BioProject는 모두 별도로 존재한다.

MicroPIPE(GitHub)를 설치하는 것은 그렇게 간단하지 않다. 'sudo apt install'이나 'conda install'로 쉽게 해결되지 않는 사전 요구 사항을 충족해야 하기 때문이다.

1. Nextflow가 있어야 하고
2. Singularity가 필요하며,
3. MicroPIPE 소스도 가져다가 설치해야 한다. 이것 자체는 분량이 많지 않다.

Nextflow는 소프트웨어 컨테이너를 이용하는 파이프라인이다. 그럼 singluarity는 무엇인가? Docker와 유사한 개념인데, 최근에는 Apptainer라는 이름으로 바뀌었다. Apptainer를 설치하려면 Go 언어가 필요하다. 그런데 우분투 20.04에서 apt 명령어로 golang 패키지(v1.13)를 설치하면 최신 apptainer(v1.0.3)와 궁합이 맞지 않는다. 그래서 Go language는 다음 사이트의 method 2를 참조하여 소스로부터 버전 1.17.7을 설치하였다. Go를 알지도 못하고 앞으로 쓰게 될 것 같지도 않지만 apptainer를 쓰려면 Go 컴파일러를 설치해야 한다. 만약 비슷한 이유로 Ruby까지 써야 한다면(이미 우분투에 깔려 있다!) 정말 울고 싶어질 것이다...

How to install Go 1.17 on Ubuntu 20.04

병원성 대장균 S129EC에 대한 MicroPIPE 조립이 끝났다.

flowchart_dat.svg

각 단계를 구성하는 작업 모듈은 대부분 알고 있는 것이지만 porechop과 flye 사이에 위치한 japsa라는 것은 매우 생소하여 도대체 무슨 기능을 하는 것인지 찾아 보았다. JAPSA는 'Just Another JAva Package for Sequence Analysis'의 약자이다. 공식 문서 사이트를 방문해 보니 일반적인 서열 자료 처리와 더불어 나노포어 데이터를 다루는 기능도 포함하고 있었다. 아마도 MicroPIPE는 demultiplexing 작업을 JAPSA에게 맡기는 것 같다.

JAPSA에 포함된 도구 중 하나인 jsa.hts.n50을 singularity 컨테이너 상태에서 실행하려면 어떻게 해야 할까? 이미지를 받아 놓았으니 JAPSA를 별도로 설치하려고 애를 쓸 필요가 없을 것이다. 다음과 같이 입력하니 깔끔하게 결과가 나온다. 

$ singularity exec /opt/singularity_cache/vmurigneux-japsa-latest.img jsa.hts.n50 --input=assembly.fasta
593033	19	3844865.0

MinION으로부터 생성된 fast5 파일을 입력물로 하여 guppy basecalling과 demultiplexing부터 시작하게 만들 수도 있지만, 이를 GPGPU가 장착되지 않은 컴퓨터에 설치하기는 곤란한 상황이다. MinION MK1 running과 Guppy HAC basecall/바코드 해독은 전용 컴퓨터에서 실시한 뒤 중간 결과물을 MicroPIPE가 설치된 컴퓨터로 옮겨서 조립 및 polish를 실행하면 될 것이다.

Docker와 Singularity, 어느 것이 더 좋은가? 구글에서 'docker vs singularity'라는 검색으로 찾았을 때 제일 위에 나오는 문서(Containerization for HPC in the Cloud: Docker vs Singularity)에는 이런 문구가 있다.

Docker is currently the most widely deployed framework, ideally suited for micro-service architecture. Singularity is a framework that aims to provide mobidity of compute with a focus on bare-metal HPC cluster systems.

어렴풋하게 두 시스템의 차이점을 이해할 수 있을 것 같다. 다음 주에 나노포어 시퀀싱을 재개할 예정이니 이번에 새롭게 익힌 MicroPIPE를 본격적으로 사용할 기회가 될 것이다. 

ST131 대장균의 레퍼런스라 할 수 있는 EC958 균주의 유전체는 MicroPIPE의 개발팀인 호주 Scott Beatson 그룹에서 시퀀싱을 하여 2014년에 공개하였었다. 논문(링크)을 찾아서 훑어보다가 염색체 수준의 비교를 깔끔하게 그림으로 표현한 것이 눈에 뜨였다. Easyfig라는 소프트웨어를 썼다고 밝혀 놓았는데, 참고문헌을 확인한 결과 이것 역시 Beatson이 교신저자로 참여한 논문으로 소개되어 있었다(Easyfig: a genome comparison visualizer 논문 링크). 2011년에 Bioinformatics에 발표된 논문으로서 아직 웹사이트에서 프로그램을 배포하고 있다.

Easyfig 웹사이트 화면 갈무리.

Easyfig 개발자인 Mitchell J. Sullivan은 홈페이지)를 통해서 자신이 개발한 다양한 시각화 도구를 공개하고 있다. 아무리 복잡한 계산을 수행하였다 하더라도 결국은 이를 잘 정돈하여 연구자의 철학과 미적 감각을 담아서 시각적으로 표현하는 것이 중요하다.

커스텀 리눅스 배포(distro)를 공개하면 거기에 포함된 프로그램의 라이선스는 어떻게 되나?

생명정보학 관련 교육 프로그램을 진행하다 보면 늘 걸리는 것이 실습 환경이다. R이나 파이썬이라면 아나콘다를 이용하면 되므로 큰 문제가 되지 않는다. 수강생이 노트북 컴퓨터를 준비해 오면, Jupyter Notebook을 설치하는 것으로 실습을 시작하면 된다. 

리눅스 초급 강좌라면 어떻게 하겠는가? 가장 고전적인 스타일은 실습용 서버에 계정을 임시로 생성해 둔 다음 터미널 에뮬레이터로 접속하여 실습을 하는 것이다. 명령행 인터페이스를 익히는 정도라면 이렇게 해도 된다. 리눅스 설치를 직접 경험해 보는 것이 중요하다면, Windows Subsystem for Linux(WSL)를 이용하여 일반 PC의 윈도우 환경에 리눅스를 설치할 수도 있다. 단, 마이크로소프트 스토어를 통해서 공식적으로 내려받아 설치할 수 있는 리눅스 배포는 그 종류가 아주 다양하지는 않다. Docker를 이용하여 WSL용 coustm Linux를 셋업하는 기법도 있다고 하니 참조해 볼 만하다. 다음 링크의 글에서는 Microsoft Store에서 제공하지 않는 CentOS Stream 8 환경을 만드는 사례를 소개하였다. 사람들의 응용력이란 참으로 대단하다!

Create a Custom Linux Setup for WSL2

미생물의 유전체 조립 및 주석화 정도라도 실습 내용에 포함시키려면 문제는 더 커진다. Conda가 있으니 필요한 프로그램을 서버에 사전 설치하는 것은 별 문제가 아니다. 그런데 수강생들이 실습을 마치고 현장에 돌아가서 실무를 접할 때의 상황은 제각각일 것이다. 자기가 관리자 권한을 갖는 서버급 컴퓨터가 있다면 다행이겠지만, 대부분은 그렇지 않을 것이다. 따라서 필요한 프로그램 패키지를 직접 설치해 보는 것이 매우 중요한데, 실습 시간에 모두가 Miniconda부터 시작해서 필요한 패키지를 설치하게 유도하면 너무 시간이 많이 걸린다. Miniconda installer 정도는 설치가 빨리 끝나겠지만, 몇 개의 conda channel에서 여러 패키지를 가져오려면 의존성 체크 등으로 시간이 많이 걸린다. Mamba 덕분에 시간을 줄이는 것은 가능해졌으나, conda에 익숙해지기도 이해하기 어려운데 mamba까지 설명하기에는 어렵다.

그래서 어제(2022년 7월 21일) 있었던 KOBIC 차세대 생명정보 교육에서 내가 택한 대안은 WSL로 설치할 수 있는 우분투 배포('distro')를 사전에 제공하는 것이었다. 우분투 20.04 LTS(Focal Fossa)에 conda를 이용하여 실습에 사용할 소프트웨어를 미리 설치한 다음, 9 GB를 조금 넘는 tar 파일로 제공하여 실습일 전에 미리 노트북 컴퓨터에 설치해 보라고 하였다. 실제 교육에서는 실습실에 있는 PC를 사용하였다. 왜냐하면 노트북 컴퓨터의 성능이 제각각이라서 실행 시간에 차이가 날 수 있기 때문이다. 그리고 모두가 다 노트북을 갖고 다니는 것도 아닐 것이고... 더 큰 문제는 실습실의 네트워크 보안이 까다로워서 자료(명령어 모음 파일) 최종본을 당일 교육장에서 Wi-Fi를 통해 배포하기가 어려웠기 때문이다. 실습 내용 중에는 NCBI에서 유전체 및 raw sequencing read를 직접 다운로드하는 것도 있었다. 유선 LAN이 아니라면 시간을 맞추기가 어려웠을 것이다.

이러한 형식의 교육을 올해 3회 실시하였다. WSL에서 사용 가능한 커스텀 리눅스 배포를 만들어서 제공하는 모델은 나름대로 성공적이었다고 생각한다. 다만 실습 환경이 PC 또는 노트북 컴퓨터이므로 아주 큰 규모의 계산을 하는 것은 어렵다. 예를 들어서 100개 정도의 박테리아 유전체에 대한 pan-genome analysis('roary')라든가 pyani 계산 같은 것 말이다. GPGPU가 필요한 나노포어 시퀀싱 자료의 high-accuracy basecalling도 그러하다.

여기까지 해 놓고 보니 새로운 고민거리가 생겼다. 우분투에 곁들여 설치한 프로그램(대부분 conda를 통해 설치했지만 pip 또는 다른 방법으로 설치한 것도 있음)의 라이선스를 죄다 점검해 봐야 하는 것이 아닐까? 개인이 비상업적 용도로 직접 conda 패키지를 설치하는 것은 문제가 없지만, 우분투에 심은 상태로 제3자에게 제공하는 것에 대한 제한은 없을까? 이에 대한 답을 지금부터 찾아 나가야 한다.

한국저작권위원회에서 운영하는 오픈소스SW라이선스 종합정보시스템(OLIS)이라는 웹사이트가 있다. 이곳을 탐독하는 것으로부터 시작해야 될 것이다. 나는 프로그램 개발자가 아니지만, 이미 만들어진 소프트웨어를 다른 사람에게 배포하는 입장이 되다 보니 해당 소프트웨어가 어떤 라이선스를 통해서 배포되는지 소홀히 할 수 없게 되었다. 라이선스 소개와 라이선스 비교표를 한번 보라. 머리에서 슬슬 김이 나려고 한다. 각 라이선스마다 다음의 사항이 전부 다르며, 나의 경우에는 배포에 관련한 사항을 주목하여야 한다(OLIS 라이선스 비교표에서 인용).

• 복제, 배포, 수정의 권한 허용
• 배포시 라이선스 사본 첨부
• 고지권 고지사항 또는 attribution 고지사항 유지
• 배포시 소스코드 제공의무와 범위
• 조합저작물 작성 및 타 라이선스 배포허용
• 수정 내용 고지
• 명시적 특허라이선스의 허용
• 라이선시가 특허 소송 제기시 라이선스 종료
• 이름, 상표, 상호에 대한 사용 제한
• 보증의 부인
• 책임의 제한

apt 명령으로 설치한 deb 패키지는 가장 느슨한 라이선스를 표방할 것만 같다. 설치된 대부분의 deb 패키지는 /usr/share/doc/<packagename>/copyright라는 텍스트 파일에 저작권 관련 사항을 기록해 놓았으나 일정한 형식을 갖추지는 않는다. MUMmer의 사례를 보자.

$ cat /usr/share/doc/mummer/copyright 
Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: MUMmer
Source: https://sourceforge.net/projects/mummer/files/mummer/
Files-Excluded: */M*.pdf
                */X*.pdf

Files: *
Copyright: © 2003 by Stefan Kurtz and The Institute for Genomic Research.
           © 1999 by The Institute for Genomic Research.
License: Artistic
Comment: MUMmer 1.0 code and documentation are copyright (c) 1999 by The
 Institute for Genomic Research.  The principle architect for the system was
 Arthur Delcher.

Files: debian/*
Copyright: 2005-2007 Steffen Moeller <moeller@inb.uni-luebeck.de>,
           2007-2016 Andreas Tille <tille@debian.org>
License: GPL
 Available at `/usr/share/common-licenses/GPL'.

License: Artistic
 This program is free software; you can redistribute it and/or modify it
 under the terms of the "Artistic License" which comes with Debian.
 .
 THIS PACKAGE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED
 WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES
 OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Comment: On Debian systems, the complete text of the Artistic License
 can be found in ‘/usr/share/common-licenses/Artistic’.

Debian-기반 리눅스에서 설치된 패키지의 라이선스 정보를 출력하는 유틸리티(dpkg-licenses)가 따로 존재한다. Conda 패키지라면 각 환경 디렉토리로 가서 다음 명령어를 실행하면 된다.

grep '"license":' conda-meta/*.json

그러면 pip로 설치한 파이썬 패키지? git로 클로닝한 소스 코드는? legacy blast는? 개별적으로 라이선스 관련 문서를 찾아서 확인해 봐야 할 것이다. 개인적 사용과 비교하였을 때 '배포'는 훨씬 더 큰 책임이 따른다는 것을 인식하는 것이 중요하다.

박테리아 유전체 조립 파이프라인 MicroPIPE

Nanopore sequencing read와 일루미나 자료를 함께 사용하여 박테리아의 유전체 염기서열을 완성 수준으로 조립하는 파이프라인 MicroPIPE에 대하여 공부를 해 보았다. 호주 Queensland 대학의 작품이다.

MicroPIPE: validating an end-to-end workflow for high-quality complete bacterial genome construction. BMC Genomics (2021) 22:474 DOI: 10.1186/s12864-021-07767-z GitHub

설치 및 활용이 손쉬워서 즐겨 사용하던 ZGA pipeline과는 규모 자체가 다르다. MicroPIPE는 Nextflow에서 개발되었으며 각종 dependency는 Singluarity contaner image로 제공된다. Nanopore read의 basecaller인 Guppy는 사용자가 직접 설치하는 것을 전제로 하였다. 왜냐하면 ONT software를 웹사이트에서 직접 다운로드하지 않고 제3자가 배포하는 것은 허용되지 않기 때문이다.

Windows용 Linux 하위 시스템을 만들어서 생명정보 분석용 프로그램을 여러 가지 방법으로 설치하였다. 바이너리 패키지를 가져다가 단순히 압축을 푼 것도 있고, pip로 설치한 것도 있으며, conda를 통해서 깐 것도 있다. 이를 'wsl export' 명령으로 내보내기를 하여 tar 파일을 만들었다고 하자. 이를 자유롭게 주변에 배포해도 되는가? 올해 몇 차례 시행한 미생물 유전체 분석 교육 워크숍을 위해 Ubuntu 20.04 focal fossa 기반의 배포를 만들어서 교육생에게 제공하였다. 사실 이 행위가 정말로 문제가 없는지 확인하려면, 배포에 포함한 모든 외부 프로그램이 GPL 3.0 또는 최소한 MIT license 정도로 제공되는지를 알아 보아야 한다. 

MicroPIPE 논문의 그림 2에서는 파이프라인 개발을 위해 참조한 long read assembly를 간결하게 비교해 놓았다. 요로감염 대장균의 일종인 EC958(ST131의 reference)이 갖고 있는 염색체와 두 개의 플라스미드가 얼마나 정확하게 조립되었는지를 나타내었다. 웹사이트 화면을 캡쳐하여 이 블로그에 그림으로 올리고 싶었으나(종종 그렇게 해 왔으므로), 링크로 대체하였다.

EC958은 전세계적으로 널리 퍼진 다제내성 요로감염 대장균 O25b:H4-ST131의 대표 균주라 한다. 유전체 해독 결과 논문은 2014년 PLoS One(PubMed 링크)에 출판되었다. 이 논문과 MicroPIPE 논문의 교신 저자는 Scott A. Beatson으로 동일하다. University of Queensland의 부교수인 그는 Advanced Genome Informatics라는 대학원 강의를 주관하고 있으며, HAIviz(healthcare-associated infections visualization tool)을 개발하였다고 한다. 

의외로 호주의 생명정보학자들에게 신세를 많이 지고 있다. Prokka, snippy, nullarbor 등의 개발자인 Torsten Seemann이 그렇고, Unicycler, Filtlong, Bandage, 그리고 이제는 유지 보수를 중단하였다고 선언한 'abandonware' porechop의 개발자 Ryan Wick이 그러하다. 이런 일방적인 관계 말고 내가 호주 생명과학자들과 직접적인 관련을 맺었던 일은 없는가? 단 한 건이 있다. 대장균 W 균주(ATCC 9637)의 유전체 해독을 내가 맡아서 했었다(PubMed 링크). 호주 쪽 파트너였던 Lars K. Nielsen 교수도 역시 University of Queensland의 교수이다. 이 일도 벌써 10년이 넘게 지난 과거가 되었다.

MicroPIPE 논문을 보다가 문득 long read/hybrid assembler의 성능을 비교한 논문이 무엇이 있는지 궁금하여 검색을 해 보았다. 이러한 부류의 논문이 너무나 많아서 옥석을 가리기가 쉽지는 않다. 예를 들어 Ryan Wick이 저자로 참여한 논문 Benchmarking of long-read assemblers for prokaryotic whole genome sequencing에서는 500개의 simulated read set과 120개의 real reads set을 8가지 assembler(Canu, Flye, Miniasm/Minipolish, NECAT, NextDenovo/NextPolish, Raven, Reabean 및 Shasta)에 적용하여 그 결과를 비교하였다. 또 다른 논문 Benchmarking hybrid assembly approaches for genomic analyses of bacterial pathogens using Illumina and Oxford Nanopre sequencing에서는 MaSuRCA, SPAdes 및 Unicycler를 비교하였다. 

내가 즐겨 사용하는 long read assembler는 Canu, Unicycler, 그리고 Flye 정도이다. 요즘에는 Flye를 가장 많이 쓰는 것 같다. 소개한 논문은 각각 2019년과 2020년에 출판된 것이라서, 2022년 현재는 또 얼마나 많은 진보가 이루어졌을지 궁금하다. 새롭게 개발된 assembler를 한 번씩 찾아서 설치하고 테스트를 해 보는 것도 정말 품이 많이 드는 일이다. 예를 들자면 2021년 Cell Syst. 저널에는 Minimizer-space de Bruijn graphs: whole-genome assembly of long reads in minutes on a personal computer라는 논문이 실렸다. 여기에서 소개한 mdBG assembler('rust-mdbg', GitHub)의 성능을 보라.

A human genome is assembled in under 10 min using 8 cores and 10 GB RAM, and 60 Gbp of metagenome reads are assembled in 4 min using 1 GB RAM.

단일 박테리아 게놈을 조립하기 위해 쓰기에는 미안할 지경이다. 기술 발전이 이렇게 놀라우니 같은 저널에 Democratizing long-read genome assembly라는 코멘터리가 실릴 정도 아니겠는가.

내가 사용하는 assembler의 외연을 넓히고 싶어서 hybrid assembler인 MaSuRCA(2013년 논문, GitHub)를 설치해 보았다. MaSuRCA란 Maryland Super-Read Celera Assembler를 뜻한다. 즉 Celera Assembler를 계승하고 있는 것이다. 

병원성 박테리아의 genomics 관련 연구를 하면서도 내가 주도를 하지 못하니 주변에서 요청하는 것을 도와주는 식으로만 대응하게 되고 결과적으로 깊이 있는 연구가 되지 못한다. 대장균, Klebsiella pneumoniae, Acinetobacter baumanii, SARS-CoV-2, Streptococcus pneumoniae... 이제는 결핵균까지! 마치 메뚜기처럼 한 species에 대해서 논문 한 편 겨우 쓰고는 인건비(과제) 상황에 따라서 다음 주제로 건너뛰고는 만다. 이래서는 안 되는데...  

ZK-502H 블루투스 앰프(TPA3116D2) 구입

책상 위의 음악 감상 시스템을 단순화할 필요가 있어서 기존의 덩치 큰 앰프를 대체할 목적의 작은 블루투스 앰프를 구입하였다. 알리익스프레스를 이용했다면 더 싸게 구입했겠지만, 배송을 기다리기 곤란한 사정이 있는지라 신속한 네이버 쇼핑이 가능한 국내의 업체를 이용하였다. 전원장치로는 19V 1.58A의 스위칭 어댑터가 포함되어 있었다. 19V 어댑터 사용 시 4옴 스피커에서 30W x 2, 8옴 스피커라면 32W x 2의 최대 출력이 나온다고 한다. 하부 패널은 검정색 아크릴판이지만 상부 패널은 아무리 보아도 알루미늄으로 보인다. 이 가격에 이런 품질이 나오다니 놀랍기만 하다.

자질구레하게 챙겨주는 것도 많다. 친절하게도 조립용 공구와 전원 어댑터용 플러그까지!

더 이상 무엇을 바라겠는가? USB 매체용 단자는 사실상 별로 쓸모가 없다. 음원 파일을 복사하여 앰프에 꽂을 일이 없으니... 재생할 곡을 선택할 수도 없지 않은가?

유선 입력은 3.5mm 스테레오 폰잭을 통해서 이루어진다. 블루투스 연결을 하려면 유선 입력 단자에 플러그를 꽂지 말아야 한다. 헤드폰 출력용 단자도 있지만 단순히 입력을 라우팅하는 것 같다. 

주변에 잡음이 많아서 음질을 면밀히 검토하지는 못했으나 일반적인 음악감상 용도라면 큰 문제가 없어 보인다. 블루투스 연결을 잘 쓰지는 않지만 아마 얼마 지나지 않아서 유용성을 발견하게 될 것이다. 휴대폰에서 블루투스 연결을 시도하였더니 'Wuzhi Audio'라는 기기명이 보였다. 상부 패널의 모델명(ZK-502H) 위에 새겨진 장식적인 글꼴로 새겨진 글씨가 바로 Wuzhi Audio였다.

지금까지 class D 오디오 증폭기를 사용한 저가 앰프를 몇 개 써 보았다. 실제 음악을 들으면서 대단히 만족하지는 못했었다. 그 이유는 부실한 전원이나 주변 부품이 아니었나 한다. 이번에 구입한 앰프는 그런대로 괜찮다. 그리고 특별한 일이 없다면 앞으로 class D 앰프를 더 살 일은 없을 것이다.

MAX4410 헤드폰 앰프 보드를 살 때 잘못 선택하여 아직 활용을 하지 못하고 있는 모노 앰프 보드(XH-M542). TPA3116D2를 사용한 제품으로서 구동 전원은 DC 12-26V, 출력은 최대 100W라고 한다.  당연히 4옴 스피커에 대한 수치일 것이다.

phyloFlash를 수동으로 설치해 보니...

편리함으로 인하여 얻는 것이 있다면, 당연히 잃는 것도 있다. 편리함이라는 껍데기 속에 숨어있는 기초적인 원리를 알 수 없게 된다. phyloFlash는 whole-metagenome shotgun sequencing data로부터 full-length 16S rRNA 염기서열을 재구성해주는 Perl script 모음이다. Conda를 이용하여 쉽게 설치할 때에는 전혀 모르고 있던 16S rRNA reference DB의 설치 과정('phyloFlash_makedb.pl --remote')이 생각보다 간단하지 않았다. vsearch, bowtie, BBMap(bbmask.sh & bbmap.sh) 등 추가적으로 필요한 프로그램이 몇 개 더 있었다. 이를 다 확인한 다음에는 NCBI에서 UniVec 데이터베이스를 다운로드하고, 마지막으로 가장 중요한 단계인 SILVA rRNA DB를 가져다가 재가공을 거쳐 설치한다. DB의 설치 위치는 phyloFlash.pl 메인 스크립트 실행 때 -dbhome 파라미터 혹은 PHYLOFLASH_DBHOME 변수로 지정한다.

SILVA DB의 다운로드 및 재가공 과정은 다음과 같다.

1. SIVA DB ftp site에서 /current/Exports/*_SSURef_N?99_tax_silva_trunc.fasta.gz 파일을 다운로드하여 압축 해제(오늘 기준으로 SILVA_138.1_SSURef_NR99). 라이선스 정보(Creative Commons Attribution 4.0, CC-BY 4.0)를 읽어 볼것.
2. barrnap_HGV를 이용하여 SSU에 섞인 LSU contamination을 검색하여 제거. 120개의 염기서열이 사라졌다.
3. bbmask를 사용하여 low entropy region을 마스킹.
4. bbmap을 사용하여 UniVec contamination을 제거.
5. 'vsearch --makeudb_usearch'를 사용하여 UDB 파일 생성. Robert Edgar(drive5.com)의 설명에 의하면 UDB database file이란 서열과 그것의 k-mer index를 수록한 파일이라 한다(링크). 바이너리 파일이므로 .udb 파일을 텍스트 편집기로 열어 보는 것은 의미가 없다.
6. 'vsearch --cluster_fasta --id 0.96' 조건으로 사용하여 클러스터링.
7. bowtie로 인덱싱(bowtie2도 아니고...)

상당히 신경을 써서 후처리를 거치고 있다. Sequence identity threshold를 96%로 맞추어서 클러스터링을 한다는 점이 중요하다. 단계 6번이 실제로 어떻게 돌아가는지를 알기 위하여 화면에 표시되는 메시지를 확인해 보았다.

[09:50:44] running subcommand:
	   /usr/bin/vsearch   --cluster_fast
	   ./138.1/SILVA_SSU.noLSU.masked.trimmed.NR99.fasta --id 0.96
	   --centroids ./138.1/SILVA_SSU.noLSU.masked.trimmed.NR96.fasta
	   --notrunclabels --threads 32 
vsearch v2.14.1_linux_x86_64, 125.7GB RAM, 32 cores
https://github.com/torognes/vsearch

Reading file ./138.1/SILVA_SSU.noLSU.masked.trimmed.NR99.fasta 100%  
609727540 nt in 421417 seqs, min 803, max 3706, avg 1447
Masking 100% 
Sorting by length 100%
Counting k-mers 100% 
Clustering 100%  
Sorting clusters 100%
Writing clusters 100% 
Clusters: 156798 Size min 1, max 1184, avg 2.7
Singletons: 107548, 25.5% of seqs, 68.6% of clusters

클러스터링을 거쳐 최종적으로 만들어지는 파일은 다음과 같다. SILVA_SSU 뒤에 새로 붙은 문자열로부터 어떤 가공을 거쳤는지를 알 수 있다.

./138.1/SILVA_SSU.noLSU.masked.trimmed.NR96.fixed.fasta

Metagenome assembly를 일상적으로 실시하게 된 요즘, 동일한 데이터로부터 16S rRNA 염기서열을 찾아내는 일이 과연 무슨 의미가 있겠느냐고 할 수도 있겠으나, 꼭 그렇지만도 않다는 것이 나의 생각이다.

개미지옥과 같은 파일 복사 작업, 그리고 8시간 20분이 걸린 KRAKEN 2 standard DB 구축

파일의 수가 많으면 복사하는데 많은 시간이 걸린다. 계산작업용 서버에 보관 중이던 파일을 DAS로 rsync를 하는 중인데, dRep과 같이 pairwase comparison에 의해 만들어진 수많은 파일을 복사하면서 '차라리 tar로 묶어서 보낼 것을..'하는 후회를 하고 있다. 뿐만 아니라 어제부터 시작한 KRAKEN 2 standard database 설치 작업도 꼬박 하루를 넘기고 있다.

KRAKEN 2 standard database를 만드는 스크립트('kraken2-build --standard --db $DBNAME')를 실행하다가 'rsync_from_ncbi.pl: unexpected FTP path (new server?)'라는 에러가 발생하였다. 이는 KRAKEN 2 wiki의 FAQ 문서(링크)에도 나올 정도로 잘 알려져 있는데, 아직 완벽한 해결책이 나오지 않은 것 같다. 검색을 거듭하여 다음의 두 웹문서에 나온 방법을 참고하여 스크립트를 수정하니 겨우 에러 없이 파일 다운로드가 진행되었다.

• https://icode.best/i/86413643858934 이것은 중국어 웹문서
• https://bytemeta.vip/repo/DerrickWood/kraken2/issues/525 맨 아래에 있는 aeu79의 글 참조

KRAKEN 2 DB를 만드는 중에 화면에 표시되는 사항을 기록해 보았다. 신통치 못한 리눅스 머신에서 소요된 공식 시간은 8시간 20분이라고 나오지만(Intel Xeon CPU E5-2630 v3 @2.40GHz, 24 thread, 메모리 256GB), 중간에 'y'를 타이핑하기를 기다리는 상태로 밤새도록 진행이 되지 않았기에 실제로는 만 하루가 조금 더 걸렸다. 정말 소중하게 만든 DB라서 꼭꼭 숨겨놓을 것이 아니라 남에게 나누어 주고 싶다.

$ kraken2-build --standard --threads 24 --db MY_KRAKEN2_DB_20220707
Step 1/2: Performing rsync file transfer of requested files
Rsync file transfer complete.
Step 2/2: Assigning taxonomic IDs to sequences
Processed 459 projects (804 sequences, 1.26 Gbp)... done.
All files processed, cleaning up extra sequence files... done, library complete.
Masking low-complexity regions of downloaded library... done.
Step 1/2: Performing rsync file transfer of requested files
Rsync file transfer complete.
Step 2/2: Assigning taxonomic IDs to sequences
Processed 32062 projects (75757 sequences, 133.68 Gbp)... done.
All files processed, cleaning up extra sequence files... done, library complete.
Masking low-complexity regions of downloaded library... done.
Step 1/2: Performing rsync file transfer of requested files
Rsync file transfer complete.
Step 2/2: Assigning taxonomic IDs to sequences
Processed 11665 projects (14554 sequences, 464.18 Mbp)... done.
All files processed, cleaning up extra sequence files... done, library complete.
Masking low-complexity regions of downloaded library... done.
Downloading plasmid files from FTP... done.
Masking low-complexity regions of downloaded library... done.
mv: try to overwrite `assembly_summary.txt', overriding mode 0444 (r--r--r--)? y
Step 1/2: Performing rsync file transfer of requested files
Rsync file transfer complete.
Step 2/2: Assigning taxonomic IDs to sequences
Processed 1 project (705 sequences, 3.30 Gbp)... done.
All files processed, cleaning up extra sequence files... done, library complete.
Downloading UniVec_Core data from server... done.
Adding taxonomy ID of 28384 to all sequences... done.
Masking low-complexity regions of downloaded library... done.
Creating sequence ID to taxonomy ID map (step 1)...
Found 43829/43864 targets, searched through 839137274 accession IDs, search complete.
lookup_accession_numbers: 35/43864 accession numbers remain unmapped, see unmapped.txt in DB directory
Sequence ID to taxonomy ID map complete. [3m7.052s]
Estimating required capacity (step 2)...
Estimated hash table requirement: 62886222992 bytes
Capacity estimation complete. [20m56.119s]
Building database files (step 3)...
Taxonomy parsed and converted.
CHT created with 16 bits reserved for taxid.
Completed processing of 138785 sequences, 142856031428 bp
Writing data to disk...  complete.
Database files completed. [7h56m29.344s]
Database construction complete. [Total: 8h20m32.627s]
$ du -sh MY_KRAKEN2_DB_20220707/
228G	MY_KRAKEN2_DB_20220707/

NCBI BLAST DB 설치 역시 대단한 인내심을 요구한다. nt-nucl-metadata.jason 파일을 가져다가 다운로드할 파일의 FTP full path를 추출하여 전부 wget(parallel)으로 받은 뒤, md5 checksum을 확인해 보았다. 그런데 nt database를 구성하는 69개(2022년 7월 4일 기준) 파일 중 해시 값이 일치하는 것이 거의 없지 않은가? 접속이 원활하지 않아 끊어진 경우, 바로 다음 파일의 전송을 시도해서 그러는 것인지? '-c(--continue)'에 재시도 회수를 지정하면 더 나을지는 모를 일이다. 

파일을 가져오는 더 안전한 방법은 rsync를 쓰는 것이다. 찾아보니 rsync와 parallel을 함께 사용하여 BLAST DB를 다운로드하는 방법(링크)이 있었다. 방법을 소개하자면 다음과 같다. 

$ rsync --list-only rsync://ftp.ncbi.nlm.nih.gov/blast/db/nt*.gz | grep '.tar.gz' | head -n 1
-rw-r--r--  4,310,538,146 2022/07/05 02:51:08 nt.00.tar.gz
$ rsync --list-only rsync://ftp.ncbi.nlm.nih.gov/blast/db/nt*.gz | grep '.tar.gz' | awk '{print "ftp.ncbi.nlm.nih.gov/blast/db/" $NF}' > nt.links.list
$ head -n 1 nt.links.list 
ftp.ncbi.nlm.nih.gov/blast/db/nt.00.tar.gz
$ cat nt.links.list | parallel -j4 'rsync -h --progress rsync://{} .'

awk 명령어에서 '{print $NF}'는 입력물의 마지막 컬럼을 출력하게 해 준다. $1, $2,... $n이 각 컬럼을 가리키는 변수이므로, 컬럼의 수를 나타내는 awk 변수인 NF에 '$'를 씌워서 $NF라고 적으면 마지막 컬럼에 해당한다. 만약 '{print $(NF-1)}'라고 명령하면 마지막 직전의 컬럼을 인쇄한다.  

이를 이용하여 69개 파일을 전부 손쉽게 다운로드하였고, md5 해시도 정상임을 확인하였다. 명령어를 실행하고 있는데 다음과 같은 메시지가 튀어나와서 약간 놀랐다.

흠, 좀 무서운데?

wget이나 curl로 파일을 가져올 때에는 나타나지 않던 경고문이다. 이들 명령어보다 rsync가 네트워크 자원을 더 많이 잡아먹는가? 미안하지만 다음에도 rsync를 쓰게 될 것 같다. NCBI가 공식적으로 제공하는 다운로드 스크립트인 update_blastdb.pl은 접속이 원활하지 않은 상태에서 얼마나 안정적으로 돌아가는지 잘 모르겠다.

맘바(mamba)는 무엇인가? - Metagenome binning 관련 도구를 설치하다가 만난 새로운 세계

위키백과에 의하면 맘바(mamba)는 코브라과 맘바속에 속하는 매우 사납고 재빠른 독사라고 한다. 원래의 뜻은 뱀의 한 종류를 일컫는 것이겠지만, 오늘의 주제는 패키지 매니저인 conda를 대체하기 위해 나온 프로그램인 mamba에 관한 것이다. 경쟁자인 (아나)콘다보다 한 수 위임을 보이기 위해 이런 이름을 지은 것 같다. 

Mamba is a reimplementation of the conda package manager in C++.

귀여운 독사? mamba-org는 package manager(mamba), package server(quetz), 그리고 package builder(boa)로 구성된 새로운 생태계이다. 리눅스 디스트로처럼 자꾸 파편화되는 것은 싫은데... 왜냐하면 계속 공부하면서 따라잡기만 하다가 시간이 다 지나는 것 같기 때문이다.

 

Metagenomic analysis를 도와주는 종합 도구인 MetaWRAP을 설치하기 위하여 mamba를 쓰게 되었다. 설치 설명 문서에 의하면 conda보다 훨씬 빠르다고 한다. 실제로 체감 속도도 빠르다. 이번이 처음 설치는 아니다. 아마 이전 시도에서는 필요한 데이터베이스를 미처 다 설치하지 못해서 실제 활용은 하지 못했었다. MetaWRAP을 metagenome-assembled genome(MAG)의 binning 도구(metaBAT2, CONCOCT 및 MaxBin2)를 종합하여 최적의 결과를 만드는 솔루션으로만 기억하고 있었는데, 실제로는 일루미나 read의 처리와 조립을 담당하는 모듈도 들어 있었다. 괜히 BBduk과 FastQ-Screen을 사용하는 전처리 스크립트를 만드느라 시간을 낭비하고 있었다!

설치 막바지에는 QUAST가 요구하는 GRIDSS, SILVA 및  BUSCO(tools & databases)를 따로 설치하라는 메시지가 나온다.

The default QUAST package does not include:
* GRIDSS (needed for structural variants detection)
* SILVA 16S rRNA database (needed for reference genome detection in metagenomic datasets)
* BUSCO tools and databases (needed for searching BUSCO genes) -- works in Linux only!

To be able to use those, please run
    quast-download-gridss
    quast-download-silva
    quast-download-busco

BUSCO DB를 다운로드하는 과정에서 에러가 발생하였다. 'http error', 301, 'Moved Permanently'라니... BUSCO 웹사이트를 방문하니 v3로 바뀌었다는 안내가 보인다. 에러 메시지를 보면 다음의 세 파일을 수동으로 다운로드하여 path_to_miniconda3/envs/metawrap-env/lib/python2.7/site-packages/quast_libs/busco/ 아래에 복사하란다.

• https://busco.ezlab.org/v2/datasets/bacteria_odb9.tar.gz
• https://busco.ezlab.org/v2/datasets/eukaryota_odb9.tar.gz
• https://busco.ezlab.org/v2/datasets/fungi_odb9.tar.gz 

BUSCO v2 웹사이트의 Download all datasets 링크를 눌렀을 때 나오는 문서에는 https://가 아니라 http://로 시작하는 구식 URL이 나열되어 있었다.

KRAKEN 2 및 NCBI BLAST nt database를 설치하여  MetaWRAP을 쓸 수 있는 상태로 만들려면 시간이 더 걸릴 것이다. 비록 MetaWRAP이 좋은 도구임에는 틀림이 없으나, 2018년에 처음 논문으로 선을 보였으니(링크) 이에 대한 자체 업데이트 말고도 다른 연구팀에 의한 진보된 도구가 더 나왔을 것이다. 예를 들어 Nextflow 환경에서 돌아가는 nf-core/mag라든지... nf-core/mag는 일루미나뿐만이 아니라 long read를 수용할 수 있다는 것은 매우 바람직하지만, 개발자 Ran Wick도 이제 손을 놓은 porechop을 포함하고 있으니 이를 어쩌란 것인지?

Nextflow는 NanoCLUST와 Bactopia를 통해 조금 경험해 보았다. Dependency를 일일이 설치할 필요가 없어서 편리하기는 하나, metagenome 관련 도구라면 프로그램이 아닌 대용량의 DB를요구할 터인데 이를 어떻게 처리하는지 궁금하다.

아무 생각 없이 MAG의 binning이라는 표현을 썼는데, 이는 정확하지 않다. 엄밀히 말하자면 MAG는 완성도를 점검하여 어느 수준에 오른 bin이라고 한다. 즉 MAG는 binning 결과를 잘 갈고 다듬어서 얻어진 것이지, binning의 대상은 아닌 셈이다. Biostars에 실린 Difference between a bin and a MAG를 조금 인용해 본다.

Basically, MAGs are bins that have been checked for completeness and refined of necessary. Any of your bins that are >90% complete and <10% contaminated can be considered MAGs as they are.

FastQ-Screen으로 whole-metagenomic shotgun read에서 host genome sequence 없애기

Whole-metagenome shotgun(WGS) 시퀀싱 자료의 성공적인 분석을 위하여 host의 유전체 서열을 제거하는 일은 매우 중요하다. 그런데 어떤 방법으로? 즐겨 사용하는 CLC Genomics Workbench에서 인간 유전체 GRCh38.p7을 레퍼런스로 하여 매핑을 한 뒤 unmapped read를 모아서 후속 작업을 할 수도 있겠지만, metagenomic assembly는 외부 프로그램을 써야 하니 이를 export해야 한다. 파일의 수가 많으면 상당히 번거로운 일이 아닐 수 없다. 차라리 human genome sequence screen 등의 전처리를 아예 명령행 환경에서 하는 것이 낫다.

CLC Genomics Workbench의 Microbial Genomics Module을 써서 'de novo assemble metagenome' 기능을 실행할 수도 있지만, 내가 갖고 있는 버전은 너무 오래 되었다.

요즘 공부하고 있는 논문에서는 그저 Bowtie2를 이용하여 sequencing read를 인간 유전체 염기서열에 붙여서 제거하였다고만 간단히 기술하였다. SAM/BAM 파일을 만들어서 unmapped read를 추출하는 작업은 명령어 한 두 줄로 해결되지는 않는다. 좀 간단하게 할 방법은 없을까? 검색을 해 보니 이런 논문이 눈에 뜨인다.

Evaluation of methods for detecting human reads in microbial sequencing datasets. Microbial Genomics 2020; 6 DOI 10.1099/mgen.0.000393

매핑 후 Picard Tools를 써서 BAM 파일을 정제해야 하고, SAMtools view에 복잡한 파라미터를 넣어서 두 단계의 작업을 거치고... 할 일이 너무나 많다. 최적의 검출 방법을 결정하기 위한 연구 논문이니 이렇게 정성을 기울이는 것도 이해는 간다. 보다 심플한 방법이 없을까? 한참을 알아보다가 FastQC로 잘 알려진 Babraham Bioinformatics의 FastQ-Screen을 쓰기로 하였다. 일루미나 PE read는 BBduk과 BBmerge를 거쳐서 어댑터를 제거하고 fwd/rev read를 병합하여 사용하기로 했다.

Babraham Bioinformatics에서 개발하는 프로그램은 버전 번호를 올리는데 상당히 인색하다. FastQC는 2010년 v0.1에서 시작하여 지금은 v0.11.9이고, FastQC는 2011년 v0.1로 시작하여 현재는 0.14.0이다. NGS의 종말에 임박하면 비로소 v1이 되려는 것인지? 

FastQ-Screen은 Perl로 짜여진 프로그램이다. Reference genome을 내려받는 옵션이 있어서 실행해 보았지만 도무지 다운로드가 될 기미가 보이지 않아서 일루미나 iGenomes 웹사이트에서 인간 유전체 염기서열 자료만을 다운로드하였다. Configuration file에서 설정 가능한 genome database는 human, mouse, E. coli, PhiX, adapters, vectors의 여섯 가지. 여섯개의 DB를 다 적재한 상태에서 첫 번째 것에만 unique하게 매핑하고 나머지에는 하나도 붙지 않는 read만를 뽑아내려면 다음과 같이 명령어를 날리면 된다.

fastq_screen --tag --filter 100000 reads.fq.gz피

--filter 뒤에 오는 연속적인 숫자는 다음의 규칙에 의해서 만들면 된다.

• 0: Read does not map
• 1: Read maps uniquely
• 2: Read multi-maps
• 3: Read maps (one or more times)
• 4: Passes filter 0 or filter 1
• 5: Passes filter 0 or filter 2
• -: Do not apply filter to this genome

'fastq_screen --tag --filter' 명령과 달리 'fastq_screen'으로 단순히 탐색적인 분석을 실시하면 10만 개의 read만 샘플링하여 사용한다. 매우 합리적인 선택이다. 하긴, CLC Genomics Workbench에서 read mapping 후 paired reads distance distribution을 산출할 때에도 모든 mapped read를 다 쓰지는 않는다. 

FastQ-Screen 전단계에서 어댑터 서열을 제거하므로, 본 분석 단계에서는 human genome을 걸러내는 일만 하면 충분할 것이다. 따라서 다른 genome DB를 다운로드하여 설치할 필요는 없다고 본다. 단, PE read를 투입한 경우 어느 한 read라도 human genome에 매핑이 되면 나머지 것도 제거하는 후처리를 거쳐야 하고, 최종적으로 read pair를 수선해야 된다. 이러한 post-process용 스크립트를 짜는 것이 숙제로 남았다. BBMap/repair.sh를 쓰면 될 것이다. 프로그램 개발자인 Brian Bushnell에게 감사를! 더불어 Babraham Bioinformatics의 생명정보학 트레이닝 과정 웹사이트에 빼곡하게 소개된 교육 자료에도 감동을 받았다.

Brian Bushnell의 최근 행적을 찾아보려다가 비교적 최근의 논문을 발견하였다. 어머, 이건 꼭 봐야 해!

DOE JGI Metagenome Workflow. mSystems 2021; DOI 10.1128/mSystems.00804-20

약 50분 분량의 강의 동영상 3개를 만들어 보았다

동영상 편집 자체에 익숙하지 못하므로 되도록이면 중간에 끊지 않고 길게 녹화를 하려고 무던히 애를 썼다. 하지만 특별한 '촬영 철학'이 있는 것이 아닌 상태에서 '원 테이크'로 길게 녹화를 한다는 것이 결코 쉬운 노릇은 아니다. 강연으로 먹고 사는 사람이 아닌지라 어색한 모습이 보임은 당연하다. 

화면 캡쳐에는 OBS Studio를, 촬영 후 편집에는 OpenShot Video Editor를 사용했다. 전부 무료 프로그램이고, 아는 소프트웨어는 그것 뿐이라서... 음성 녹음에는 롤랜드 사운드캔버스 SC-D70에 싸구려 다이나믹 마이크로폰을 연결하여 사용하였다. 음성 기록에는 전혀 손을 대지 않았다. 잡음을 없앤다거나 음량을 조정한다거나 하는 등 후처리가 필요하겠지만, 당장의 실력으로는 엄두가 나지 않는다. 내 얼굴을 찍는 웹캠의 높이와 마이크로폰의 각도 및 모니터 위치 등이 전혀 최적화가 되어 있지 않아서 약 네 시간 가까운 촬영을 끝내고 나니 목덜미가 뻐근하다. 새로운 녹음용 장비를 사야 되겠다는 욕심만 늘어났다. 가장 중요한 것은 마이크 스탠드. 집에 있는 탁상용 마이크 스탠드(Audiotrak AMS-11)는 USB 콘덴서 마이크 전용으로 쓰도록 하고, 자바라 형태의 스탠드를 따로 사도록 하자. 기왕이면 마이크도 하나 더...

주름져서 접을 수 있는 물건의 총칭인 '자바라'는 '뱀의 배'를 뜻하는 일본어에서 유래했다고 한다. 오, 그렇구나!(나무위키 링크)

OBS Studio로 화면을 기록할 때의 해상도는 메인 모니터의 그것과 같은 2560x1440 픽셀이었는데, OpenShot에서 편집을 마치고(편집이라고 해 봐야 끝을 조금 잘라내고 이어 붙인 것이 전부) 기본 프로파일로 '비디오 내보내기'를 하니 1024x576 16:9 PAL이 되었다. 너무 저해상도가 아닐까? 만약 터미널 창에 타이핑하는 모습을 제대로 기록하려면 글꼴을 더 키워야 한다. Windows Terminal에서 글꼴을 키우려면 어떻게 해야 하지? 검색을 통해서 알아보아야 한다.

Windows Terminal tips and tricks

공부할 것이 너무나 많다. 몇 시간짜리 강의를 하기 위해 해당 전문 분야의 지식을 축적해 놓는 것과는 차원이 다른 문제이다. 카메라와 마이크가 나를 향해서 작동 중인데, 어떻게 해야 부드럽게 나의 말을 이어 갈 것인가? 내 모습을 찍어서 계속 문제점을 파악해 보고, 연습에 연습을 거듭하는 것 말고는 방법이 없다. 스크립트를 미리 만들어서 이를 보고 읽으면서 녹화를 하고싶은 유혹은 언제나 있다. 그러나 이는 올바른 방법이 아니다. 정 필요하다면 몇 가지 핵심 단어를 적은 메모지를 앞에 놓고 슬쩍 보면서 머릿속에서 할 말을 즉각적으로 조립해 나가는 것이 진정한 '진행자'의 능력이다. 물론 메모지 넘기겠다고 손가락에 침을 발라서는 안 될 것이다.

컴퓨터를 이용한 녹음 작업에 늘 관심이 많았었는데 이번 일과 같이 구체적인 목표가 생기면서 실행에 옮기게 된 것을 매우 즐겁게 생각한다.