인프라 정의에서 떼어 놓은 코드

인프라 정의 안에 애플리케이션 배포가 들어 있어서 코드를 고칠 때마다 인프라를 건드려야 했다. 인스턴스 정의 안에 배포 명령이 박혀 있었기 때문이다.

Open Table of contents

빈도가 다른 두 가지

코드를 배포하려면 인스턴스를 다시 만들어야 했고 배포 한 번에 몇 분이 걸리며 그동안 서비스가 끊겼다. 인프라 정의는 한 달에 한두 번 바뀌는데 애플리케이션은 하루에 몇 번 바뀐다.

빈도가 크게 다른 둘이 한자리에 있으니 자주 바뀌는 쪽에 맞춰 전부가 움직이고 있었다. 같이 두면 둘 다 어려워지므로 바뀌는 빈도로 나눴다.

인프라 정의에는 서버와 망과 저장소와 권한을 두고 배포에는 코드 올리기와 의존성과 마이그레이션을 뒀다. 배포할 때 인스턴스를 안 건드리게 되면서 시간이 몇 분에서 몇십 초로 줄었다.

경계가 애매한 것도 있었다. 데이터베이스 스키마가 인프라 같기도 하고 코드 같기도 했는데 코드가 그 스키마를 전제하므로 코드와 같이 가야 한다고 보고 배포 쪽에 뒀다.

나누고 나니 서로 의존하는 지점이 드러났다. 인프라가 보안 그룹에서 포트를 열고 배포가 그 포트로 붙는 구조라 인프라를 바꾸면서 포트를 닫으면 배포가 깨진다.

인프라가 그 값을 출력으로 내보내고 배포가 시작 전에 그 포트로 접속되는지 확인하게 했다. 나누기 전에는 안 보이던 의존이 나눈 뒤에 드러났고 그것을 확인 절차로 만든 것이 나눈 값이었다.

인프라 정의의 상태 파일은 원격에 두고 잠금을 걸어 두 사람이 동시에 바꾸는 것을 막았다. 상태 파일에 비밀 값이 들어갈 수 있어서 접근도 좁혔다.

정의와 실제가 다른지도 주기적으로 확인했는데 손으로 추가한 규칙이 나왔다. 정의에 없으므로 다음에 적용하면 사라질 것이라 필요한 것이면 정의에 넣고 아니면 지웠다.

나누고 나서 되돌리는 방법도 나뉘었다. 배포는 옛 판으로 링크를 바꾸면 몇 초이고 인프라는 정의를 옛 커밋으로 되돌려 적용해야 하므로 몇 분에서 수십 분이 걸린다.

무엇이 문제인지 먼저 갈라야 어느 쪽을 되돌릴지 정해진다. 배포 직후 문제면 배포를 먼저 되돌리고 인프라 변경 직후면 인프라를 보며 둘 다 최근이면 배포를 먼저 되돌린다. 배포를 먼저 되돌리는 것은 그쪽이 빠르고 위험이 적기 때문이다.