소소한 암호화키 DB 분리

방패맨·2024년 4월 2일
post-thumbnail

1. 기존 환경 분석

RDS 도입과 신규 솔루션2의 추가로 인해 문제가 발생하였다. 인프라 분리를 통해 솔루션1과 솔루션2는 서로 다른 서버에 있는 상태이다. 또한 암호화키를 저장, 갱신, 조회 하는 솔루션 (솔루션3) 은 각각 서버에 존재한다.

하지만 솔루션3의 접속정보는 변하지 않기에 솔루션 1,2 모두 같은 TABLE을 조회하고 수정하고 갱신한다.

아래는 솔루션과 테이블 조회 로직을 간단하게 나타낸 것이다.

2. 문제 확인

여기서 문제가 발생하였다. 키 갱신의 경우 로그인시 발생하는데 솔루션1에서 키 갱신 후 솔루션1에 갱신한 정보를 업데이트하지만 솔루션2의 경우는 갱신하였는지 모른다.

따라서 RSA테이블을 각각 두기 위해 기존 DB와 RSA테이블을 카피한 RDS를 추가 하였으며
암호화키를 조회,저장,갱신 하는 솔루션3의 소스코드를 하나의 소스로 가져가기 위하여

[sol1_properties] , [sol2_properties]

와 같이 properties를 통해 DB 접속 정보를 분리하기로 하였다.

3. 계획 수립 및 실행

문제해결 계획은 다음과 같다.
[1]
1-1 기존 RDS를 카피뜬 새로운 RDS 생성 및 RSA 테이블 생성
1-2 기존 RDS의 RSA테이블 데이터를 새로운 RDS의 RSA테이블로 데이터 마이그레이션.

[2]
2-1 sol1_properties는 기존 RDS 접속정보기입
2-2 sol2_properties는 새로운 RDS 접속정보 기입 

[3]
3-1 소스관리의 용이성을 위해 원소스로 가져가는 솔루션3 (RSA키를 갱신,조회,저장 하는 솔루션)
3-2 솔루션3를 서버1과 서버2에 clone
3-3 서버1에서 솔루션3 구동시 솔루션1용 sol1_properties로 구동 
3-4 서버2에서 솔루션3 구동시 솔루션2용 sol2_properties로 구동 

하기와 같은 작업을 운영서버에서 진행하기에 확실한 계획과 사전작업이 수반되었으며
모든 계획에 문제없이 진행되어 다음과 같이 <DB 분리작업> 은 솔루션 정지 이후 10분내로 완료되었다.

완성된 환경

profile
개발자 방패맨의 기술블로그

0개의 댓글