백엔드가 이정도는 해줘야 함 - 17. RDS 인스턴스에 새로운 Security Group을 만들어 연결하기

테스트 코드와 관련된 챕터에 글을 쓰고 나서, 거기서 얘기한 테스트 코드를 모두 작성한 뒤에 챕터를 진행하려고 했더니, 평일에 하루종일 코딩하다 집 들어와서 다시 코딩해야 하는 상황이라 너무 진행이 되질 않습니다. 따라서, 이제부턴 테스트 코드 작성과 챕터 진행을 동시에 진행하려고 합니다.

AWS에서 인스턴스 기반으로 움직이는 요소(EC2, RDS 등)들은 기본적으로 보안 그룹이라는 가상 방화벽이 인바운드/아웃바운드 트래픽을 제어해 준다. 이걸 대충 배워서, 새로운 Security Group을 만들고 RDS 인스턴스에 할당해 보자. 이 귀찮은 일을 하는 것에는 많은 이유가 있다.

• 우리가 작성한 테스트는, 저번에 이야기했던 대로 테스트 메소드 하나가 종료될 때마다 모든 테이블에 대해 DROP TABLE이 실행된다. 16챕터 때 이야기했던 것처럼, 개발자가 그냥 아무 생각 없이 production DB를 쓰도록 설정을 바꾸고 돌려버리는 경우에 확실한 대비책이 없는 현재의 상태를 커버해야 한다. 물론 코드 상에서 원격 DB config 클래스는 데이터베이스 연결 정보(user, password, endpoint 등)를 환경 변수에서 가져오고 있어서(코드), 이들이 모두 설정되어 있지 않은 환경에 대해서는 방어할 수 있겠으나 나중에 이 코드가 어떻게 될지 모르기 때문에 안심할 수가 없다. 원치 않는 주체의 트래픽을 아예 차단해버리는 것이 더 낫다고 생각한다.

• RDS는 데이터베이스를 생성하면서 Security Group도 자동으로 생성하는데, 여기에 유일하게 인바운드 트래픽이 허용되어 있는 대상은 생성자 본인의 IP밖에 없다. 따라서 지금은 Lambda로 배포된 우리의 WAS가 RDS에 접근할 수 없는 상태다. 이번 챕터에선 WAS의 RDS 접근과 관련된 부분들까지 다루지는 않겠지만, 이번 챕터에서 쌓일 Security Group에 대한 아주 기본적인 지식이, 추후 서비스 릴리즈와 관련된 챕터를 진행할 때 도움이 될 수 있도록 판을 깔아두기 위함이다.

• Security Group을 사용하면 우리가 명시한 요소의 트래픽만을 허용할 수 있다. 잘 설정해 둔다면, 데이터베이스 연결 관련 정보가 탈취되었더라도 조금이나마 안심할 수 있다.

• 인바운드엔 IP만이 아니라 Security Group도 넣을 수 있어서, Security Group을 잘 정리해 두면 나중에 써먹기 좋다. API라는 이름의 Security Group을 만들어 두고, Security Group DB에서 API를 인바운드로 허용하는 등을 예로 들 수 있다.(이 부분은 지금 이해하지 못해도 상관없는 내용이고, 위에서도 말했던 것처럼 릴리즈와 관련된 챕터를 진행할 때 다시 이 내용을 풀어서 설명할 예정이다.)

새로운 Security Group을 만들어서 바꿔치기

자동 생성된 Security Group 확인하기

우리가 과거에 만들었던 RDS 인스턴스를 선택하면 나타나는 대시보드에서 '연결 & 보안' 탭의 '보안' 섹션을 보면, 'VPC 보안 그룹'이라는 요소에 RDS가 데이터베이스를 생성하며 자동으로 생성한 Security Group이 보일 것이다.

링크를 클릭하면, EC2 관리 콘솔의 '보안 그룹' 탭으로 리다이렉트된다. sg-로 시작하는 그룹 ID, 아마도 rds-launch-wizard라는 그룹 이름을 가진 Security Group이 보일 것이다. 우리가 주목해야 할 것은 아래쪽에 보여지는 추가 정보들인데, '인바운드' 탭을 클릭해서 현재 상태를 확인해 보자.

본인의 IP가 유일한 인바운드로 허용되어 있을 것이다. 만약 내가 개발을 진행하다가 실수로 production DB 정보를 가지고 테스트 코드를 돌리게 된다면, DB 날아가고 아주 난리가 날 것이다.

Security Group 새로 생성하기

자동으로 생성된 Security Group은, 이름이 너무 명시적이지 않다. rds라는 키워드는 들어갔지만, 조금 더 확실한 이름이 좋을 것 같다. 그러나 사실 한 번 생성된 Security Group은 이름을 바꿀 수가 없어서, 새로 만들어야 한다. '보안 그룹 생성' 버튼을 클릭하고, 이름과 설명 정도를 기입한 뒤 '생성' 버튼을 누르자. 나는 RDB라는 이름으로 생성하려고 한다.

새롭게 생성된 Security Group을 눌러보면, 인바운드 룰이 하나도 설정되지 않은 것(기본 상태)을 확인할 수 있을 것이다.

DB 인스턴스에서 Security Group 바꿔치기

이제 RDS Console에 들어가서, DB 인스턴스 대시보드에 접속한 후, '수정' 버튼을 눌러 인스턴스 수정 페이지에 접속해 새로 생성한 Security Group을 연결시켜 주자.

자동 생성된 Security Group인 rds-launch-wizard와, 이를 대신하기 위해 생성한 Security Group인 RDB가 동시에 연결될 것이다. 말했던 대로 rds-launch-wizard를 RDB로 대신하고자 하니, 기존에 연결되어 있던 Security Group을 해제하자. 아래 캡처와 비슷한 모습이어야 한다.

아래로 쭉 내려가서 '계속'을 누르고, 수정 사항을 확인한 뒤 'DB 인스턴스 수정' 버튼을 누르자. 그러고 나면, 아래처럼 Security Group 설정 변경이 진행되며,

조금 기다리면 성공적으로 Security Group 바꿔치기가 완료된다.

Security Group의 정상 작동을 확인하기

이제 우리가 새로 생성한 Security Group이 잘 동작하는지 확인해 보자. 가장 쉬운 방법은 인바운드에 내 IP를 허용한 다음 DB에 접속해 보는 것이다. Security Group 관리 콘솔로 들어가서, 인바운드에 본인의 IP를 허용하자. 인바운드 규칙을 편집하는 창을 띄우고, 다른 것들 건들 거 없이 '소스' 컬럼의 드롭박스를 열면 '내 IP'를 선택할 수 있게 되어 있다.

해당 항목을 클릭하면 IP가 알아서 기입된다. '포트 범위' 컬럼에 MySQL의 기본 포트 번호인 3306을 입력하고, '저장' 버튼을 눌러 새로운 인바운드 룰을 적용하자. 먼저 인바운드 설정이 잘 적용되었는지 확인하고,

DB에 접속해보자. 연결 정보를 까먹었으며 챕터를 착실히 따라왔다면, Lambda Management Console에 접속해 우리가 배포한 Lambda를 확인해 보자. 이전에 데이터베이스 연결 정보를 환경 변수로 넣어두었을 것이다. MySQL 클라이언트는 입맛대로 사용하자. 나는 평소에 DataGrip을 사용하는데, 지금 글을 쓰고 있는 데스크탑에는 설치되어 있지 않으니 예전에 설치해 뒀던 MySQL Workbench를 사용할 것이다. MySQL Workbench에 있는 'Test Connection' 기능을 통해 연결이 잘 되는 것을 확인했다.

이제 Security Group RDS에서 인바운드 룰을 제거하고, 다시 연결을 시도해 보자. 연결에 실패해야 한다.

rds-launch-wizard 걷어내기

드디어 자동 생성된 Security Group을 제거해도 되는 상태가 되었다. 기존에 RDS에 연결되어 있던 Security Group을 선택한 후 '작업' 드롭박스를 열고, '보안 그룹 삭제' 버튼을 눌러 제거해 주자. 별도의 경고 없이 삭제 확인 버튼이 활성화되어 있는 상태여야 한다.

만약 삭제하려는 Security Group이 아직 어딘가에 연결되어 있는 상태라면, 어디에 연결되어 있는지의 정보와 함께 삭제 버튼이 활성화되지 않는다. Security Group RDB를 삭제하려고 시도해 보면 알 수 있다.

삭제까지 완료되었다면, 나름대로의 레거시 하나가 청산된 것이다. 기본 Security Group과 함께 두 개의 Group만이 남아 있게 된다.

마음에 들도록 Security Group을 재할당했으므로 이제 여기에 필요한 인바운드 룰들을 세팅해 두면 되는데, 당장 RDS에 인바운드 트래픽을 열만한 주체는 WAS 정도밖에 없다. 그러나 이 부분은 위에서도 말했듯 나중에 이야기해보도록 하고, 지금 당장은 누구에게도 인바운드 트래픽을 허용하지 않은 상태로 둔 채 다음 챕터로 넘어가자.