몇 년간 집 인터넷을 이용한 웹서버를 사용해왔다. 첫서버는 CubieTruck 이었나(기억이 가물가물)? 그러다가 OrangePi 로도 쓰다가, 최근 몇 달은 LattePanda 를 서버로 사용하고 있었는데…
망할 놈의 라테판다가 지난 9월 말, 갑자기 사망해버리는 사태가 발발했다. 다행히 데이터는 미리 미리 보관을 잘 해놨었기에, 급한대로 큐비트럭에 올려놓고 임시방편으로 사용 중이었다.
그렇게 몇 주 지내는 동안, 집구석 서버를 계속 써야 할 지, 아니면 임대를 하는게 나을지를 고민하다가, 임대로 가기로 결정했다.
살짝 찾아본 결과, 요즘 인기있는 서비스는 AWS Lightsail 이었기에, 주저없이 선택을 했다. 요금도 상상 이상으로 저렴했고(US $3.5), 유명한 회사(?)이기도 하고.
또, 고민할 필요도 없었던게, 하다가 맘에 안들면 바꾸면 되니까. 우분투만 설치된다면 그 어디든 옮겨갈 수 있다는 게 워드프레스 류의 장점이 아닌가.
그리하여 설치에 들어갔는데..
공인 IP
먼저 공인 IP 얘기를 해야겠다. Lightsail 은 공인 IP 를 받을 수는 있지만, 가상머신에 직접 부여할 수는 없다. 마치 가정용 공유기가 공인 IP 를 받은 뒤, 포트포워딩을 하듯, 그런 식으로만 사용해야한다.
Lightsail 이 아닌, 더 고급(?) 서비스들은 다른 방식인지는 모르겠지만, 적어도 Lightsail 은 이렇다.
짧은 생각으로는, 이런 작동 방식 때문에, 굳이 가상머신 안에 방화벽(ufw)을 따로 사용할 필요는 없어 보인다. 어차피 Lightsail 에서 일단 DenyAll 이 기본 시행되고 있기에, 그것만으로도 충분해 보이는데.. 이 부분은 확인해볼 필요가 있다.
공인 IP 는 Lightsail-홈-네트워킹 페이지에서 생성(할당)할 수 있고, 이렇게 할당받은 IP 를, 가상머신에 붙여서 사용한다. (만약, 공인 IP 를 받기만 하고 어디에도 사용하지 않으면 벌금(?)을 내야한다고 한다.)
SSH / EdDSA 설정
설치 초기 단계에서 AWS 는 ssh 공개키를 요구한다. 이 공개키는 RSA 방식이어야만 한다. EdDSA 방식의 키는 사용할 수가 없다.
키가 없다면 그 페이지에서 만들어도 되긴 하지만, 이미 있는 공개키를 그냥 사용하는 편이 좋겠다. (아마존을 못믿어서 그렇다기 보다는.. 어쨌든 작은 가능성이라도 아예 남기지 않는 편이 좋지 않겠나.)
이 때, 반드시 ‘공개키’ 를 올려야 한다. 절대로, 개인키(Private Key) 를 올리면 안된다. (우분투라면 이 키는 ~/.ssh/id_rsa.pub 이다.)
그런데.. RSA 만 쓸 수 있는 건 또 아니다. (이 얘긴 잠시 뒤로)
일단, 공개키를 업로드한 뒤, 우분투 인스탄스를 만든다.
이때 생성되는 계정명은 무조건 ‘ubuntu’ 다. 새로운 사용자를 만들 수는 있지만, UID 1000 의 이름을 바꿀 수는 없다. (적어도, 간단히 바꿀 수는 없다. 이에 대한 글이 몇가지가 있는데, 어느 하나도 쉽지는 않았다.)
‘ubuntu’ 계정은 당연하지만 sudo 계정인데, 특이하게도(어찌보면 당연하게도?), password 가 아예 할당되어 있지 않았다.
좋은 보안은 password 를 쓰지 않고도 가능해야한다는 내용은 글로만 몇 번 접했었는데, 그 실제 사례를 이렇게 보게 될 줄이야.
패스워드가 없는데 어떻게 접근을 하느냐고?
따지고 보면 패스워드는, 비네트워크 접속에서는 반드시 필요하지만, ssh 를 사용한 네트워크 접속에선 보안 측면에선 별 도움이 못되는 존재라고 할 수 있다.
간단히 말해, 털리면 그만이기 때문이다.
그에 반해, 공개키에 기반한 암호화를 사용하여 인증을 수행하게 되면, 귀찮은 패스워드도 필요없고, 보안도 강화되니 더 좋은 방식이라 할 수 있다.
그런 이유로 여기서도 패스워드를 아예 사용하지 않는 계정을 사용하고 있나보다. (요즘 이런 서비스들은 다 이런 식인지.. 촌놈이 첨 써보니 뭘 알 수가 있나.)
어쨌든, 이렇게 우분투 인스탄스가 생성되었다면, 웹브라우저상에서 ssh 를 사용해서 접속할 수 있다. (그냥 클릭하면 된다.)
터미널에서 직접 접속하려면, 몇가지 정보가 필요하다.
접속가능한 IP 는 그 페이지에 나와있고, id 는 ubuntu 이고, 포트는 기본값 22 를 쓰고 있으니, 다음 명령으로 접속할 수 있다.
ssh ubuntu@ip
이때 사용되는 키는 당연하지만, RSA 기반 키가 된다.
만약, EdDSA 를 사용하고 싶다면?
먼저, 내 컴퓨터에 저장되어 있는 id_ed25519.pub 의 내용을 복사한 뒤, 서버의 /home/ubuntu/.ssh/authorized_keys 에 붙여넣는다.
그리고나면, EdDSA 방식으로 접속할 수 있게 된다.
RSA, EdDSA 두 방식의 키가 모두 존재하는 환경에서 특정키로 ssh 접속을 하고 싶다면, -i 옵션을 사용한다.
ssh -i ~/.ssh/id_ed25519 ubuntu@ip
또는, .ssh/config 파일에 다음 항목을 넣어두고 사용할 수도 있다.
IdentityFile ~/.ssh/id_ed25519
만약, 포트도 바꾸고 싶다면, /etc/ssh/sshd_config 를 편집하여, 원하는 포트 번호로 바꿔준다.
Port 1234
포트를 변경했다면, AWS Lightsail 관리자에서 해당 포트를 열어줘야만 ssh 접속이 가능해진다. 또, 이 경우 Lightsail 관리자에서 ssh 항목(22)은 삭제해도 무방하다.
다만, Port 까지 바꿨다면, 더 이상 웹브라우저를 사용한 접속은 되지 않는다. 터미널로만 접속이 가능하게 되는데, 굳이 웹브라우저를 쓸 일은 없으니, 문제가 되진 않으리라 생각한다.
그런데.. 만약 ssh 관련 정보가 불의의 사고로 손상되어 접근이 안된다면, 이걸 어떻게 해결할 수 있으려나..??
얼핏 찾아보니, 새로운 인스탄스를 임시로 만들고, 그 인스탄스에서 이 인스탄스에 사용된 드라이브를 마운트한 후, .ssh/authrized_keys 를 수동편집하는 방법이 있었다.
물론, 이런 일은 일어나지 않는 편이 좋겠지.
MariaDB 설정 및 스왑설정
MariaDB 는 현재 최신판인 10.4 를, MariaDB 공식 저장소를 통해 설치했고, 이전에 사용 중인 DB 를 불러와서 설정을 마쳤다.
그런데… 며칠에 한번 꼴로 서버가 죽는다. 가상 머신 자체가 죽는 경우도 있고, MariaDB 서버가 죽는 경우도 있다.
로그를 살펴보니, Out of Memory 오류가 발생했음을 알 수 있었다.
Oct 21 21:22:02 nemo_webserver kernel: [35338.055228] Out of memory: Kill process 7477 (mysqld) score 209 or sacrifice child
지금까지 쓰던 방구석 서버들에선 이런 일이 없었는데, 왜 이런 문제가 나를 괴롭히는 걸까??
내가 신청한 Lightsail 서비스는 가장 저렴한 512MB 를 제공한다. 방구석 기기들은, 제일 작았던 게 1GB 였다. 512 는 처음이다. 게다가, Lightsail 의 우분투 기본 설치에선 스왑파일도 만들지 않는다.
아.. 셋방살이 DIY 는 이리도 어렵구나.
먼저 swap 파일을 만들었다.
sudo fallocate -l 1G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile
그리고, fstab 에 스왑파일을 등록.
# /etc/fstab /swapfile none swap sw 0 0
그리고 재부팅 후, swapon -s 로 확인하면 제대로 작동하고 있음을 확인할 수 있다.
$ swapon -s Filename Type Size Used Priority /swapfile file 1048572 19968 -2
여기까지만 하고 또 좀 기다려볼 수도 있었는데, 찾아보니 MariaDB 의 메모리사용량을 줄일 수 있는 방법이 있어서 그대로 따라해봤다. (Stackoverflow 없는 세상.. 어찌 살까.)
# /etc/mysql/my.cnf # 원래 128 인데 8로. (19-10-22, Out of memory 오류 발생으로 인해) key_buffer_size = 8M # 원래 256 인데 64로. (19-10-22, Out of memory 오류 발생으로 인해) innodb_buffer_pool_size = 64M # 원래 8M 인데 256K로. (19-10-22, Out of memory 오류 발생으로 인해) innodb_log_buffer_size = 256K
하는 김에 swappiness 10, cache pressure 50으로 설정했다.
자.. 이걸로 문제가 해결될 수 있을런지.. (결과는 나중에 덧붙일 예정.)
** 이 글을 쓰고 며칠이 지났는데, Out of Memory 오류는 1회도 발생하지 않았다. 스왑파일 때문인지, MariaDB 설정 변경 때문인지는 모르겠다. (둘이 협력했는지도?)
대략 메모리는 75% 선에서, 스왑은 10% 선에서 유지되고 있다.
아무튼, 이제 웹서버는 안정감 있게 돌아가고 있는 중!
아 심정지라는 이야기 듣고 아예 뽐뿌가 멈췃네요.. 주식투자용 서버로 저전력 컴터 고민하다가 라떼판다가 눈이 들어왔는데.. 심정지면… 역시 장난감 용 그이상은 아니군요
라테판다 안정성에 대해선 말씀드리기가 애매합니다.
그저 뽑기 운이 없었다고 할 수 있겠죠.