환경변수 한 줄을 빼고 배포한 일

설정은 고쳤지만 배치 시간은 지나 있었다

모의투자 리워드 앱의 서버를 배포한 날이었다. 서버는 PHP로 만들어져 있었고, 여러 EC2 서버에 코드를 직접 올렸다. 설정은 서버마다 환경변수로 넣었다. 새 기능과 버그 수정을 반영하는 배포였고, 그날 저녁에는 비행기를 타야 했다.

배치가 정상적으로 돌지 않아 확인해보니 환경변수 하나가 빠져 있었다. 배치가 처리할 나라 목록을 담은 값이었다. 환경변수는 프로그램을 실행할 때 바깥에서 전달하는 설정값이다. 코드가 같아도 그 값에 따라 처리할 대상이 달라졌다.

원인은 금방 찾아 고쳤다. 하지만 배치가 실행될 시각은 이미 지나 있었다. 설정을 다시 넣는 것과 그동안 놓친 일을 처리하는 것은 달랐다. 빠진 구간을 사람이 직접 실행해서 채워야 했고, 결국 그날 저녁 비행기를 놓쳤다.

배포 방법을 바꾸기 시작했다

이 일 뒤에는 배포할 때 환경변수를 반드시 확인하게 했다. 코드를 직접 올리던 방식에서 S3를 쓰는 배포로 바꾸기도 했다. S3는 파일과 그 정보를 객체로 저장하는 서비스다. 여기서는 배포에 사용할 파일을 다루는 데 썼다. S3의 역할

그렇게 바꾼 뒤에도 조금 불안정했다. 이후에는 서버를 계속 직접 관리하던 구성을 Lambda 같은 서버리스로 옮겼고, 언어도 PHP에서 Node.js로 바꿨다. 정확한 전환 순서는 흐릿하지만, 이 일이 서버 구성을 다시 생각한 가장 큰 계기였다는 것은 기억한다.

PHP라서 생긴 문제라고 보지는 않는다. 코드를 올리는 일과 필요한 설정을 맞추는 일이 나뉘어 있었고, 그 절차에서 하나를 빠뜨렸다. 언어를 바꾼 사실만으로 그 틈이 사라졌다고 말할 수도 없다.

같은 배포물과 같은 설정은 다르다

지금 다시 구성한다면 컨테이너를 쓰는 방법도 살펴보고 싶다. 컨테이너 이미지에는 프로그램 코드와 실행에 필요한 파일·라이브러리를 함께 담는다. 같은 이미지를 배포하면 서버마다 코드를 따로 올리거나 실행 도구를 다르게 설치해서 생기는 차이를 줄일 수 있다. 컨테이너 이미지 설명

그렇지만 이미지가 같아도 실행할 때 전달하는 환경변수는 다를 수 있다. Docker에서도 컨테이너를 시작하면서 환경변수를 지정하거나 이미지의 기본값을 바꿀 수 있다. 같은 코드 묶음을 쓰는 것과 그 코드에 필요한 값을 제대로 전달하는 것은 각각 확인해야 한다. 컨테이너 실행 시 환경변수

예를 들어 나라 목록을 바깥에서 받는다면, 이미지를 잘 만들었어도 목록을 전달하지 않은 채 실행할 수 있다. 컨테이너는 빠진 나라가 무엇인지 알지 못한다. 당시 컨테이너를 썼다면 이 일이 저절로 막혔을 것이라고 생각하기는 어렵다.

그래서 배치가 시작되기 전에 설정을 검사하는 방법을 함께 생각하게 된다. 필요한 값이 있는지, 목록으로 읽을 수 있는지, 허용하지 않은 항목은 없는지 확인하고 문제가 있으면 실행을 멈추는 것이다. 설정이 잘못됐다는 것을 실제 처리 시각까지 기다려서 알기보다, 실행 준비 단계에서 드러내고 싶다.

설정의 규칙을 표현하는 데에는 JSON Schema 같은 방법도 있다. JSON Schema는 데이터에 어떤 항목과 형식이 필요한지 적는 규칙이다. 환경변수를 읽어 검사할 데이터로 만든 뒤, 필요한 항목을 required로 지정하면 그 항목이 빠졌는지 확인할 수 있다. 항목을 정의해 두기만 하면 필수값이 되는 것은 아니어서, 빠져서는 안 되는 항목을 명시해야 한다. 필수 항목 검사

여기에도 한계가 있다. 나라 목록이 존재하고 형식이 맞아도 이번 배포에서 처리해야 할 나라가 하나 빠졌다면, 존재 여부만 보는 검사는 통과할 수 있다. 배포하려는 범위와 실제 목록을 대조하는 확인이 더 필요하다. 설정 몇 개를 검사하는 일이라면 이미 있는 코드에서 조건을 확인하는 것으로 충분할 수도 있다. 어떤 도구를 쓸지보다 어디까지 확인해야 시작해도 되는지가 먼저다.

당시에 강화한 것은 환경변수 점검과 배포 절차였다. 컨테이너와 시작 전 검사를 더한다면, 파일을 맞추는 일과 값을 확인하는 일을 각각 어디에서 처리할지부터 정해야겠다.

놓친 일을 다시 실행할 때

그날은 설정을 고친 다음에도 해야 할 일이 남았다. 지나간 배치를 수동으로 실행하는 일이었다. 앞으로 비슷한 작업을 준비한다면, 설정을 되돌릴 방법과 이미 놓친 작업을 처리할 방법을 함께 살펴볼 것이다.

예를 들어 어느 날짜와 대상을 다시 처리할지 명확해야 하고, 그중 이미 처리된 것은 없는지도 확인해야 한다.

이후 여러 서비스의 설정을 한곳에서 관리하고 로컬과 서버의 환경을 나누는 일에서도 같은 질문을 만났다. 파일을 올렸다는 사실만으로 배포가 끝났다고 할 수 있을까. 프로그램이 필요한 설정으로 시작했고, 예정된 일이 실제로 수행됐는지까지 이어서 봐야 한다. 그날 설정 한 줄을 고친 뒤에도 자리를 떠날 수 없었던 이유가 거기에 있었다.