MSA에서의 다중 DB 설정

 

msa구조에서 인증서버에서 발급받은 jwt토큰을 소스서버에서 인증처리 한 후 로직을 처리할려고 해 이때 인증처리를 할때 멤버db를 가지고 있어야 할거 같은데 소스서버의 db와 멤버 db둘다 동시에 가지고 잇어야 하는거야?

 

**Microservices Architecture (MSA)**에서 인증 서버에서 발급한 JWT 토큰을 소스 서버가 인증한 후 해당 로직을 처리하는 방법에 대한 질문이군요. 여기서 고려해야 할 몇 가지 사항이 있습니다.

1. JWT 토큰 인증:
   • JWT 토큰 자체에는 필요한 정보(예: 유저 ID, 권한 등)가 포함되어 있습니다. 소스 서버는 JWT 토큰의 서명을 검증하여 유효성을 확인할 수 있습니다.
2. 멤버 DB 정보 활용:
   • 회원과 관련된 세부 정보가 필요하다면 별도의 멤버 DB를 참조해야 합니다. 예를 들어, 유저의 세부 정보나 추가 권한 정보가 필요할 수 있습니다.
3. 소스 서버와 멤버 DB의 관계:
   • 소스 서버에서 JWT 토큰을 검증하고 추가적인 멤버 정보를 조회해야 하는 경우, 소스 서버가 멤버 DB에 접근할 수 있어야 합니다.
4. 데이터베이스 접근 방법:
   • 멤버 DB와 소스 서버의 DB를 완전히 분리하거나, 소스 서버의 DB에 멤버 정보를 중복 저장하지 않도록 유의해야 합니다.
   • 소스 서버는 멤버 DB에 직접적인 읽기 작업만 수행하고, 멤버 DB의 상태를 변경하는 작업은 반드시 인증 서버를 통해서만 이루어지도록 하는 방법도 있습니다.

따라서 소스 서버는 JWT 토큰의 검증을 자체적으로 처리할 수 있지만, JWT 토큰만으로 로직처리에 충분하지 않다면 멤버 DB에 접근하여 추가 정보를 얻어야 할 수 있습니다. 이 경우, 소스 서버와 멤버 DB 모두에 접근할 필요가 있습니다.

궁극적으로 어떻게 설계할 것인지는 시스템의 요구 사항에 따라 다르겠지만, 좋은 설계는 최소한의 데이터 중복과 최대한의 보안 및 효율성을 목표로 해야 합니다.

 

 

 

네, 정확합니다. 말씀하신 대로 소스 서버가 멤버 DB에 대한 조회 작업을 직접 수행하고, 멤버 DB의 상태 변경 작업은 반드시 인증 서버를 통해서만 이루어지도록 하는 경우, 소스 서버는 다음과 같이 구성되어야 합니다:

1. 소스 서버의 DB:
   • 어플리케이션과 관련된 로직들을 처리하는 데 필요한 데이터베이스입니다. 예를 들어, 비즈니스 로직 처리에 필요한 데이터를 저장합니다.
2. 멤버 DB:
   • 사용자의 인증 정보, 프로필 정보, 권한 정보 등 회원 관련 데이터를 저장하는 데이터베이스입니다.

따라서 소스 서버는 다음 두 가지 데이터베이스를 연결하여 접근할 수 있어야 합니다:

1. 소스 서버의 기본 DB: 어플리케이션 전반에 필요한 데이터를 저장하고 관리합니다.
2. 멤버 DB: JWT 토큰을 통해 인증된 사용자에 대한 상세 정보를 얻는 데 사용됩니다.

이러한 구조가 필요하게 되는 이유는, JWT 토큰의 검증을 통해 소스 서버가 요청한 사용자가 유효한 사용자임을 확인하는 것 외에, 해당 사용자의 추가적인 정보를 필요로 하는 경우가 자주 발생하기 때문입니다. 예를 들어, 사용자의 세부 프로필 정보나 특정 권한을 확인하고자 할 때 멤버 DB의 접근이 필요할 수 있습니다.

하지만 멤버 DB의 상태 변경 작업은 인증 서버를 통해서만 이루어지도록 하면 보안과 일관성을 유지할 수 있습니다. 이런 방식으로 설계할 경우, 소스 서버가 읽기 작업을 직접 수행할 수 있지만, 기록 작업은 인증 서버를 통해야만 가능합니다.

따라서 결론적으로, 소스 서버는 멤버 DB와 소스 서버의 DB 두 개 모두에 접근할 수 있도록 설정되어야 합니다.

 

 

 

API를 호출하는 방법과 데이터베이스에 직접 연결하는 방법 각각의 장단점이 있습니다. 이를 비교해보고 어떤 방법이 더 적합한지 결정할 수 있습니다.

1. API 호출 방법

장점:

• 캡슐화: 멤버 DB의 구조나 데이터베이스 구현 방식을 소스 서버와 완전히 분리할 수 있습니다. 이는 시스템의 모듈화를 높이며 변경 관리가 용이하게 합니다.
• 보안 강화: 직접적인 데이터베이스 접속을 최소화하여 중간 계층 (인증 API 서버)을 거치게 함으로써 데이터베이스에 대한 접근을 보다 엄격하게 관리할 수 있습니다.
• 유지보수 용이: 멤버 DB의 구조나 성능 개선 등이 필요할 때 API만 수정하면 되기 때문에 유지보수가 용이합니다.

단점:

• 성능: API 호출은 네트워크를 통한 통신이기 때문에 데이터베이스에 직접 접근하는 것보다 속도가 느릴 수 있습니다. 성능이 중요한 경우 이는 문제점이 될 수 있습니다.
• 복잡성 증가: 한 번의 서비스 요청을 처리하기 위해 여러 번의 API 호출이 필요할 수 있어서 시스템 복잡성이 증가할 수 있습니다.

2. 데이터베이스 직접 연결 방식

장점:

• 성능: API 호출에 비해 데이터베이스에 직접 연결함으로써 성능이 더 빠를 수 있습니다. 소스 서버가 멤버 DB에 직접 접근할 수 있어서 데이터를 빠르게 조회할 수 있습니다.
• 간단함: 구현이 상대적으로 간단하고, 중간 계층(API 서버)을 따로 구성할 필요가 없습니다.

단점:

• 보안: 소스 서버가 멤버 DB에 직접 접근하기 때문에 보안 강화가 어려울 수 있습니다. 누가 어느 데이터를 접근할 수 있는지에 대한 강력한 통제가 필요합니다.
• 변경 위험성: 멤버 DB의 구조가 변경되면 소스 서버의 로직도 함께 변경해야 할 가능성이 높습니다. 이는 유지보수의 어려움을 야기할 수 있습니다.
• 강결합: 소스 서버와 멤버 DB가 강하게 결합되어 있어 시스템의 유연성이 떨어질 수 있습니다. 이는 시스템이 더 커질수록 문제가 됩니다.

결론

• 보안과 모듈화를 중시할 경우: API 호출을 통해 멤버 DB 접근을 중간 계층(API 서버)으로 캡슐화하는 것이 좋습니다. 이는 유지보수와 보안에 유리합니다.
• 성능과 간단한 구조를 중시할 경우: 데이터베이스에 직접 연결하는 방식이 더 적합할 수 있습니다. 이는 더 나은 성능을 제공할 수 있습니다.

만약 두 가지 방식을 절충하고 싶다면, 주로 읽기 작업은 캐시 또는 로컬 데이터베이스를 통해 처리하고 변경 작업만 API를 통해 처리하도록 하는 방안도 고려해 볼 수 있습니다.

결국, 시스템의 요구사항과 제약 조건을 종합하여 가장 적합한 방법을 선택하는 것이 중요합니다.