본문으로 건너뛰기

"linux" 태그로 연결된 2개 게시물개의 게시물이 있습니다.

모든 태그 보기

· 약 11분

파이썬 웹 애플리케이션을 배포할 때 고려할 점들이 많이 있습니다. 특히 선택할 수 있는 대안이 많으면 고민이 되는데요. 멋지게 '베스트 프랙티스'를 제시하면 좋겠지만 아직 그러기엔 많이 부족하고, 이 글에서는 제가 선택한 방식과 이유를 정리해서 공유해봅니다.

운영체제: Ubuntu

일반적으로 CentOS 아니면 Ubuntu를 사용하는 것 같습니다. Ubuntu를 선택한 가장 큰 이유는 '익숙해서'입니다. 그 밖에는 다양한 써드 파티 패키지(PPA)에 쉽게 접근할 수 있다는 점, 그리고 개발 환경으로 Ubuntu 데스크탑을 사용하면 배포할 때 환경 맞추기 훨씬 수월하다는 점이 있겠습니다. (CentOS를 데스크탑으로 쓰신다면야 말리지는 않겠습니다...) 버전은 굳이 LTS를 고집할 필요 없이 적당히 최신 버전을 쓰면 되는 것 같습니다.

WSGI 서버: Gunicorn

WSGI 서버로는 uWSGI 또는 Gunicorn이 많이 쓰입니다. uWSGI는 설정할 수 있는 파라미터도 많고 성능도 좋긴 하지만, Gunicorn은 성능이 크게 뒤지지 않으면서 훨씬 간단해서 관리하기가 수월하다고 생각합니다. 그리고 uWSGI는 graceful reload가 안돼서 재시작할 때 다운타임이 발생하는 것으로 보입니다. (해결 방법이 있다면 알려주세요.)

프로세스 관리: Upstart

대안이라면 supervisord가 있겠지만 Upstart는 Ubuntu에 기본으로 들어있어서 덜 귀찮죠. Upstart에 대해 자세히 알고 싶으시면 저번에 쓴 글을 참고하세요. 앞으로 Ubuntu가 systemd로 전환한다면 systemd를 사용하게 되겠죠.

웹 서버: nginx

이 선택은 딱히 논란의 여지가 없을 겁니다. 리버시 프록시와 정적 리소스 서빙에 사용합니다. 다만 반드시 Apache로 돌려야 하는 레거시가 있다면 예외입니다.

코드 배포: Git

애플리케이션 코드가 업데이트 되었을 때 어떻게 받아올 것인가 하는 이야기입니다. 정석대로(?) 하자면 Git 작업 사본과 실제 서비스되는 애플리케이션 코드를 분리하는 것이 좋습니다. 왜냐하면, git pull을 하는 동안 코드의 중간 상태가 노출될 수 있기 때문입니다. 예를 들어 이전 버전의 템플릿 파일과 새로운 버전의 템플릿 파일이 공존하게 된다면 서비스에 문제가 생길 수 있습니다. 하지만 대부분 아주 잠깐 발생하는 일이고, 템플릿 캐싱을 켜는 등 우회할 수 있는 방법이 있어서 큰 문제가 되지는 않습니다.

virtualenv나 설정 파일 등을 어디에 위치시킬 것인지도 고민하게 됩니다. 많은 경우 Git 작업 사본 안에 만들게 되는데, 그런 경우 .gitignore 파일에 확실히 추가하여 저장소에 들어가지 않도록 주의가 필요합니다.

돌아가는 서비스가 많을수록 헷갈리지 않도록 디렉토리 구조를 통일하면 도움이 됩니다. 애플리케이션 코드에서도 가급적 설정 파일 등의 위치나 파일명을 강제하지 말고 환경 변수에서 읽도록 하는 편이 좋습니다.

파이썬 패키지: virtualenv에 직접 설치

시스템에서 제공하는 바이너리 패키지를 설치할 수도 있지만 별로 권장하지 않습니다. 일단 virtualenv로 격리할 수도 없고, 최신 버전이 아닐 가능성이 매우 높고, 언제 업데이트가 될지도 알 수 없습니다. 다만 배포 대상 서버가 많다면 빌드 시간이 낭비되니까 직접 패키징하는 것을 고려해봐야 합니다.

추가로, 의존성을 setup.py로 관리할지 아니면 requirements.txt를 사용할지도 선택해야 하는데요. 이 쪽은 특별히 선호하는 방식이 있지는 않습니다. 하지만 많은 경우에 requirements.txt로만 관리해도 충분합니다. 어쨌든 관리가 되고 있다는 것이 중요합니다.

정적 리소스 배포

캐시 관리 전략: URL 기반

리소스가 갱신되었을 때 브라우저의 캐시를 어떻게 무효화 할 것인지 고려해봐야 합니다. 가장 확실한 방법은 리소스가 바뀔 때마다 URL을 바꾸는 것입니다. 아예 파일명을 바꾸거나 주소 뒤에 쿼리 문자열을 붙여서 (?v=3처럼) URL이 바뀌도록 해줍니다. 이런 일을 손으로 하면 실수할 가능성이 높으므로 가급적 자동으로 처리할 수 있는 시스템을 만드는 것이 좋습니다. 이렇게 하면 Expiry 헤더를 매우 길게 잡아 서버에 전혀 요청이 들어오지 않게 만들 수도 있어 성능상 이득이 있습니다.

내려주는 곳: 예산에 따라

서버가 한국에 있고, 접속자도 모두 한국 거주자라면 그냥 애플리케이션과 같은 서버에서 내려주면 되므로 특별히 고려할 것이 없습니다. 하지만 서버와 접속자의 위치가 다르고 충분한 예산이 있다면 CDN을 사용하는 것이 좋습니다.

CDN을 사용할 경우 S3와 같은 스토리지 서비스에 파일을 올릴지, 아니면 일반 웹 서버를 사용할지 선택해야 합니다. 스토리지 서비스를 사용할 경우에는 애플리케이션 배포 시 추가적인 리소스 배포 과정이 필요하지만 훨씬 안정적이라는 장점이 있습니다.

전처리: 상황에 따라

최근 웹 프론트엔드 개발에서는 SASS나 CoffeeScript처럼 전처리 과정이 필요한 언어를 사용하는 추세입니다. 크게 세 가지 방법이 있습니다.

  1. 배포하기 전에 미리 빌드: 배포할 서버 수가 많을 때 유리합니다. 혼자 개발하는 서비스라면 아예 Git 저장소에 같이 커밋할 수도 있습니다. 또한 스토리지 서비스를 통해 리소스를 내려줄 경우, 어차피 업로드하는 과정이 필요하므로 업로드하기 전에 해주면 됩니다.
  2. 서비스하는 서버에서 미리 오프라인 빌드: Git 훅 스크립트로 지정해두면 편하게 할 수 있습니다. 또한 애플리케이션 서버와 무관하므로 안전하다는 장점이 있습니다.
  3. 애플리케이션 서버에서 온라인 빌드: webassets 같은 라이브러리를 사용하여 애플리케이션 서버가 관리하도록 합니다. 서버 구동이 느려지거나 서비스에 영향을 미칠 수 있으므로 추천하는 방법은 아닙니다.

오류 추적: Sentry

실제 서비스를 시작하면 테스트할 때는 발견하지 못했던 예외가 발생할 수 있습니다. Sentry를 통해 오류를 수집하면 많은 도움이 됩니다. 또한 로거와 연동해서 치명적인 오류는 아니지만 예외적인 상황에 로그를 남기게 하면 비상시에 대처할 수 있어 좋습니다.

더 생각해볼 것들

  • 배포 자동화: Fabric으로 원격 배포를 자동화합니다.
  • 서버 설정 자동화: Chef, Puppet이나 Ansible 등을 사용해서 서버 세팅 과정을 형상 관리/자동화합니다.
  • 성능 모니터링: New Relic이 굉장히 좋지만, 가격이 만만치 않아서 아직 적절한 대안을 찾지 못했습니다.
  • 서버 접속 권한과 민감한 정보 관리
  • 업로드 된 파일 관리
  • 데이터베이스 / 메모리 캐시
  • 백그라운드 워커 (Celery) / 메시지 큐

· 약 7분

오래 돌아야 하는 서버 또는 워커를 어떻게 관리하고 계신가요? 설마 이렇게 하고 계신가요?

  • screen이나 tmux 안에 띄워놓고 잊어버리기
  • nohup으로 실행해두고 잊어버리기
  • 프로세스가 꺼졌는지 한참동안 모르고 있다가 당황하기
  • 시스템 재부팅 될 때마다 헬을 만나기

우분투에서 기본으로 제공되는 Upstart를 사용하면,

  • 시스템 부팅 시에 서비스 띄우기
  • 다른 서비스가 시작된 후에 서비스 띄우기
  • 프로세스가 오류로 꺼지면 자동으로 다시 띄우기
  • stdout/stderr를 로그 파일에 기록하기
  • 로그 파일이 커지면 쪼개기

와 같은 기능을 어렵지 않게 사용할 수 있습니다.

설정 파일 설치하기

Upstart 서비스 설정 파일은 /etc/init/에 모여있습니다. 따라서 /etc/init/ 디렉토리에 서비스명.conf 파일을 만들어 넣으면 됩니다.

심볼릭 링크로 설치하기

/etc/init/에는 시스템 서비스의 설정 파일도 모두 들어있기 때문에, 조금 더 관리를 편하게 하려면 별도의 디렉토리에 서비스 설정 파일을 모아두는 것도 좋은 선택입니다. 그러려면 /etc/init에 심볼릭 링크를 걸어야 합니다.

sudo ln -s /home/ubuntu/something.conf /etc/init/

주의! /etc/init/에 직접 들어있지 않고 심볼릭 링크로 들어있는 파일이 수정될 때는 Upstart가 변화를 감지하지 못합니다. 따라서 다음 명령어로 설정 파일을 다시 불러오게 해야 합니다.

sudo initctl reload-configuration

서비스 관리

설정 파일 작성법을 알아보기 전에 서비스 관리하는 방법을 먼저 알아둡시다.

  • 시작: sudo start 서비스명
  • 중단: sudo stop 서비스명
  • 재시작: sudo restart 서비스명 (주의: 서비스 설정 파일을 다시 읽어오지 않습니다. 설정 파일이 바뀌었으면 stop 후 start할 것)
  • 점잖은 재시작: sudo reload 서비스명 (정확히는, 프로세스에 HUP 시그널을 보냅니다)

설정 파일 작성하기

명령어 지정

가장 간단하게는 exec 뒤에 명령어를 쓰면 됩니다.

exec uname -a

좀 더 긴 쉘 스크립트가 필요할 경우 script 구문을 사용합니다.

script
sleep 5
uname -a
end script

어떤 명령어들은 실행하면 자동으로 백그라운드로 들어가는(detach/daemonize) 경우가 있습니다. 이를 방지하는 옵션이 있다면 켜는 것이 좋습니다. (보통 --foreground--nodetach)

포어그라운드 모드로 실행하는 옵션을 지원하지 않는 경우 Upstart 문서를 참고해서 설정하시기 바랍니다.

자동 시작/중단 조건

서비스를 특정 조건이 만족되었을 때 시작되거나 중단되게 할 수 있습니다.

가장 많이 사용하게 될 설정은 부팅 시 시작, 시스템 종료 시 중단이겠죠? 다음과 같이 적으면 됩니다.

start on runlevel [2345]
stop on runlevel [016]

또는 다른 서비스가 시작된 이후에 띄우고 싶을 수도 있습니다. A 서비스가 시작된 후를 조건으로 지정하려면,

start on started A

and 연산자로 여러 조건을 조합할 수도 있습니다.

start on started mysql and started nginx

mysql과 nginx 서비스가 시작된 뒤가 시작 조건이 됩니다.

실행 권한

프로세스는 기본적으로 root 권한을 가지고 실행됩니다. 보안을 위해 별도의 사용자/그룹 권한을 주고 실행하는 것을 권장합니다.

setuid username
setgid groupname

실행 환경 설정

  • 환경 변수 설정: env KEY=value (환경 변수는 exec/script 구문 안에서 $KEY로 참조할 수 있습니다)
  • 디렉토리 변경: chdir /path/to/current/dir

자동 재시작(respawn)

한 줄만 추가하면 프로세스가 예기치 않게 종료됐을 때 (종료 코드가 0이 아닐 때) 자동으로 다시 실행됩니다.

respawn

프로세스가 너무 빨리 되살아나는 것을 방지하기 위해 5초 동안 10번 재시작되면 더이상 재시작하지 않습니다. 이 제한은 respawn limit으로 바꿀 수 있습니다.

# 주의: respawn limit 구문이 있더라도 respawn 구문이 없으면 자동 재시작이 되지 않습니다
respawn
respawn limit COUNT INTERVAL # INTERVAL초 동안 COUNT번 재시작되면 포기합니다.
respawn limit unlimited # 제한을 없앱니다.

로그 파일

stdout/stderr로 출력된 내용은 /var/log/upstart/서비스명.log에 저장됩니다.

우분투 (14.04 기준)에서는 이 로그 파일이 하루에 한번 분할되고 최대 7개의 파일이 유지되는 것이 기본 설정입니다. /etc/logrotate.d/upstart에서 설정을 바꿀 수 있습니다.

설정 파일 예제

gunicorn으로 파이썬 웹 애플리케이션을 실행하는 예제입니다.

대안

  • 우분투 차기 (또는 차차기) 버전에서 Upstart가 systemd로 대체될 예정이라고 합니다. 데비안에서는 이미 systemd가 기본입니다.
  • 시스템과 독립적으로 작동하면서 Upstart 같은 기능을 제공하는 Supervisor도 많이 사용됩니다.