올게 왔다.

답변 받았습니다! 프로젝트를 배포한지 어느새 1년이나 됐나보다. 졸업이 코앞이라 바쁘게 살고 있던 와중, 위의 이메일을 받은 날 기준 1주일 후에 AWS 프리티어가 만료된다는 이메일이 도착했다.

우리 프로젝트는 AWS의 아래 서비스들을 사용하고 있다:

• CDN으로의 쉬운 프론트엔드 배포를 위한 Amplify
• 유저 풀 관리를 위한 Cognito
• 백엔드 서버 구동을 위한 EC2 (+https 리다이렉션을 위한 로드밸런서)
• 도메인 관리를 위한 Route 53
• 데이터베이스를 구동하는 RDS

시작할땐 규모가 작은 프로젝트였지만, 1년동안 구색을 갖추다 보니 어느새 사용하는 서비스가 매우 많아졌다. 실사용 유저도 200명 가까이 되기 때문에, 프리티어가 끝나도 금액이 많이 나가지 않는다면 별도의 계정 이전 없이 게속 사용하려 했으나...

쓰으으으ㅡ으으읍. 도메인 연장 비용이 포함되어있긴 하지만 프리티어가 끝나면 예상 금액이 확 올라서 그냥 계정을 이전하기로 결정했다. 이전을 진행하며, 이런 상황을 상정하지 않고 서비스를 설계한 것에 대한 벌도 많이 받았고, 배운점도 많아 이를 기록해보려 한다.

EC2 이전

사실 EC2의 경우는 Spring Boot 백엔드 프로그램을 Docker 이미지로 빌드 -> Github Self-hoster Runner를 사용하여 이미지를 풀해오고 컨테이너 실행 이라는 간단한 스텝으로 배포를 진행중이어서, 별도의 스냅샷을 만들거나 해서 EC2를 이전하지는 않았다.

새 계정에서 EC2 인스턴스를 새로 생성하고, Github에서 Self-hosted runner를 새로운 인스턴스로 설정하기만 하면 되어서, 매우 간단하게 끝났다. 이후 하던대로 로드밸런서를 설정하여 https 연결을 설정하면 마무리. 하지만 이는 다른 서비스들을 이전하기 전 몸풀이었을 뿐이었다...

새벽 3시까지 밤샐줄은 몰랐지...

Cognito 유저풀 이전

무려 200명 이상의 유저정보를 담고있는 우리의 소듕한 유저풀

우리 프로젝트는 사용자 인증 풀로 Cognito를 사용한다. Amplify와 연동하여 로그인 플로우를 구축하기도 편하고, 직접 db에 유저를 관리하는것보다 안전하다 판단하여 당시 도입하였다. 양날의 검이 되어 모든 유저 정보가 여기에 있으니 이친구를 이전하면 안되는 상황이 되어버리기도 했지만.

하지만 이걸 이전하는게 제일 난관이었다. 우선 가장 큰 문제는 AWS는 Cognito 유저풀을 계정간 이전하는 쉬운 방법을 마련해 두지 않았다는 것이다.

그래도 방법이 없진 않은데, 조사 결과 크게는 아래의 두가지 방법이 있다 (이 글이 큰 도움이 되었다):
1. CSV 형식으로 유저풀을 export한 이후, 새 계정에서 이를 사용하여 import하기. 이 경우 이전은 문제없이 진행되지만, 비밀번호는 안전상 이유로 export가 되지 않아 유저들이 로그인 시 모두 비밀번호 변경을 진행해야한다는 단점이 있다.
2. AWS가 제공하는 람다 트리거를 이용하여, 유저들이 이전 풀에 로그인할 때마다 해당 정보를 새 풀에 옮겨오는 방식. 이 방식에서 비밀번호 변경은 필요하지 않지만, 로그인을 할 때 이전이 실행됨으로 오랫동안 로그인을 하지 않는 유저는 마이그레이션이 되지 않는다.

제한된 시간상, 우리는 1번 방법을 택했다. 2번의 경우 복잡한 설정이 필요했고, 서비스 출시 후 1년이 지나서 보안상 비밀번호 변경을 진행할 때도 된다고 판단하였기 때문이다. 아래에 해당 방법을 사용해 마이그레이션을 진행한 과정을 기록해본다. 의외로 한국어로 해당 자료가 없어서 이 글이 비슷한 방법으로 이전을 하는 분들께 도움이 되면 좋겠다!

CSV 파일로 유저풀 Export하기

아까 말했듯, AWS는 유저풀을 이전하는 쉬운 방법을 마련해 두지 않았다. 근데 첫단계부터 어려울줄은 몰랐는데, 딸깍하고 누르면 유저풀이 csv 형태로 export되지 않고, 수동으로 (...) 이 파일을 만들어야 한다.

이 글에서 수동으로 유저 정보를 일일히 AWS CLI로 불러오는 방법을 설명하는데, 유저가 200명이 넘는데 이를 일일히 할 수는 없는 노릇이다. 그래서 이미 사람들이 만들어둔 코드를 사용한다.

이 링크의 파이썬 스크립트는 지정된 유저풀을 자동으로 csv로 만들어 준다. 사용법은 간단하다. 컴퓨터에 aws configure를 통해 AWS credentials 파일이 제대로 만들어졌다는 가정 하에, python pooltool.py export userpool --file backup.csv --id [유저풀ID] --region [리전, 예를들어 ap-northeast-2] --profile [AWS프로파일명]라는 커맨드를 사용하면 지정된 유저풀의 데이터를 csv로 만들 수 있다.

만들어진 CSV 파일로 import 진행

이후 새로운 계정에서 유저 풀을 만들고, 밑에 있는 사용자 가져오기로 가서 가져오기 작업 생성을 누른다. 처음 진행하는거면 위처럼 새 IAM 역할 생성을 선택하고 역할 이름을 부여 후, 방금 export 한 csv 파일로 작업을 생성한다.

그러면 위처럼 작업이 진행되고, 상태가 같이 뜬다. 유저풀마다 상황이 다르겠지만, 나의 경우는 아래의 문제를 해결해야 작업이 성공했다 (그래서 5번이나 했다 흨흨):

• email_verified 속성이 있는 유저풀의 경우, 해당 필드가 TRUE인 유저들만 가져올 수 있었다. 그래서 FALSE인 유저들은 삭제하고 진행했다.
• 우리 프로젝트는 이메일이 즉 username이었는데, cognito:username의 경우 보통 고유 식별자 (sub)가 들어간다. 그런데 username을 이메일로 설정해서 그런지 해당 컬럼의 값을 이메일로 변경해야 했고, 새로운 풀에서는 sub가 모두 새롭게 변경되었다. 덕분에... 우리는 백엔드에서 sub로 유저 식별을 하고 있어서 백엔드 대규모 공사를 진행해야했다.

위 과정들을 거치면, 유저가 로그인 후 비밀번호 재설정을 진행한다면 유저풀 이전이 완료된다!

Route 53 도메인 이전

우리 프로젝트는 도메인을 Route 53에서 구매해서 관리하고 있었다. 소유권을 새로운 계정으로 옮기는 법은 생각보다 간단했다.

• 우선 Route 53에 들어가 '등록된 도메인' 메뉴에 들어간다.
• 옮길 도메인을 선택하고, 아래처럼 송신- 다른 AWS 계정으로 이전을 누른다.
  
• 도메인을 옮길 새로운 AWS 계정의 ID를 밑의 창에 입력한다. 여기서의 AWS ID는 이메일이 아니라, AWS 콘솔에서 우측 상단 본인 계정명을 누르면 나오는 숫자 형태의 ID다.
  
• 문제가 없다면 암호가 생성되고, 새 AWS 계정 이메일의 안내에 따라 암호를 입력하면 매우 손쉽게 도메인 이전이 완료된다!

RDS 이전

스냅샷을 만들어서 이전하는 방법과, 덤프를 만들어 이전하는 방법이 있어 이전이 매우 쉽다.

Amplify 이전

여기도 repo를 다시 연결만 하고, 도메인 연결이 완료되었다면 다시 잇기만 하면 되기에 큰 어려움은 없었다.

결론

글을 보면 알듯, Cognito를 이전하는 것이 제일 큰 난관이었다. 유저 풀을 옮기고, 백엔드에서 유저 식별에 사용하던 sub값이 모두 바뀌어버려 결론적으론 백엔드도 대규모 공사를 진행해야 했다...

Amplify의 연동성과 유저 관리의 용이성을 위해 택한 Cognito 유저 풀이지만, 우리처럼 계정간 이전이 필요한 경우를 전혀 고려하지 못해 불필요한 시간 낭비가 생긴 셈이다. 최초 구현 당시엔 아직 웹개발 입문 3개월차라 별 생각없이 진행했는데, 이번에 그 교훈을 뼈저리게 느낀것 같다. 프로젝트를 설계할때는 꼭!!!! 미래지향적으로 인프라 설계를 해야한다. AWS 자격증을 어서 따든 해야겠다...!