기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

데이터베이스 래퍼 서비스 패턴으로 액세스 제어

래퍼 서비스는 데이터베이스의 파사드 역할을 하는 서비스 계층입니다. 이 접근 방식은 향후 분해를 준비하면서 기존 기능을 유지해야 할 때 특히 유용합니다. 이 패턴은 간단한 원칙을 따릅니다. 무언가 너무 지저분한 경우 먼저 지저분한 내용을 포함합니다. 래퍼 서비스는 데이터베이스에 액세스할 수 있는 유일한 승인된 방법이 되어 기본 복잡성을 숨기면서 제어된 인터페이스를 제공합니다.

복잡한 스키마로 인해 즉각적인 데이터베이스 분해가 가능하지 않거나 여러 서비스에 지속적인 데이터 액세스가 필요한 경우이 패턴을 사용합니다. 시스템 안정성을 유지하면서 신중한 리팩터링을 위한 시간을 제공하므로 전환 기간 동안 특히 유용합니다. 이 패턴은 데이터 소유권을 특정 팀에 통합하거나 새 애플리케이션에 여러 테이블에서 집계된 뷰가 필요한 경우에 적합합니다.

예를 들어 다음과 같은 경우이 패턴을 적용합니다.

데이터베이스 래퍼 서비스 패턴의 이점 및 제한 사항

다음은 데이터베이스 래퍼 패턴의 이점입니다.

다음은 데이터베이스 래퍼 패턴의 제한 사항입니다.

데이터베이스 래퍼 서비스 패턴 구현

데이터베이스 래퍼 서비스 패턴을 구현하는 두 단계가 있습니다. 먼저 데이터베이스 래퍼 서비스를 생성합니다. 그런 다음 모든 액세스를 통해 전달하고 액세스 패턴을 문서화합니다.

1단계: 데이터베이스 래퍼 서비스 생성

데이터베이스에 대한 게이트키퍼 역할을 하는 경량 서비스 계층을 생성합니다. 처음에는 모든 기존 기능을 미러링해야 합니다. 이 래퍼 서비스는 직접 데이터베이스 종속성을 서비스 수준 종속성으로 변환하는 모든 데이터베이스 작업에 대한 필수 액세스 포인트가 됩니다. 이 계층에서 세부 로깅 및 모니터링을 구현하여 사용 패턴, 성능 지표 및 액세스 빈도를 추적합니다. 기존 저장 프로시저를 유지하되이 새 서비스 인터페이스를 통해서만 액세스해야 합니다.

2단계: 액세스 제어 구현

래퍼 서비스를 통해 모든 데이터베이스 액세스를 체계적으로 리디렉션한 다음 데이터베이스에 직접 액세스하는 외부 시스템에서 직접 데이터베이스 권한을 취소합니다. 서비스가 마이그레이션될 때 각 액세스 패턴 및 종속성을 문서화합니다. 이렇게 제어된 액세스를 통해 외부 소비자를 방해하지 않고 데이터베이스 구성 요소를 내부 리팩터링할 수 있습니다. 예를 들어 복잡한 트랜잭션 워크플로 대신 위험이 낮은 읽기 전용 작업으로 시작합니다.

3단계: 데이터베이스 성능 모니터링

래퍼 서비스를 데이터베이스 성능에 대한 중앙 집중식 모니터링 포인트로 사용합니다. 쿼리 응답 시간, 사용 패턴, 오류율 및 리소스 사용률을 포함한 주요 지표를 추적합니다. 성능 임계값 및 비정상적인 패턴에 대한 알림을 설정합니다. 예를 들어 실행 속도가 느린 쿼리, 연결 풀 사용률 및 트랜잭션 처리량을 모니터링하여 잠재적 문제를 사전에 식별합니다.

이 통합 보기를 사용하면 쿼리 튜닝, 리소스 할당 조정 및 사용 패턴 분석을 통해 데이터베이스 성능을 최적화할 수 있습니다. 래퍼 서비스의 중앙 집중식 특성을 통해 일관된 성능 표준을 유지하면서 모든 소비자에 걸쳐 개선 사항을 구현하고 영향을 검증할 수 있습니다.

데이터베이스 래퍼 서비스 구현 모범 사례

다음 모범 사례는 데이터베이스 래퍼 서비스를 구현하는 데 도움이 될 수 있습니다.

시나리오 기반 예제

이 섹션에서는 AnyCompany Books라는 가상의 회사가 데이터베이스 래퍼 패턴을 사용하여 모놀리식 데이터베이스 시스템에 대한 액세스를 제어하는 방법의 예를 설명합니다. AnyCompany Books에는 발송, 재무 및 주문 처리라는 세 가지 중요한 서비스가 있습니다. 이러한 서비스는 중앙 데이터베이스에 대한 액세스를 공유합니다. 각 서비스는 다른 팀에서 유지 관리합니다. 시간이 지남에 따라 특정 요구 사항을 충족하도록 데이터베이스 스키마를 독립적으로 수정합니다. 이로 인해 종속성 웹이 얽히고 데이터베이스 구조가 점점 더 복잡해졌습니다.

회사의 애플리케이션 또는 엔터프라이즈 아키텍트는이 모놀리식 데이터베이스를 분해해야 할 필요성을 인식합니다. 이들의 목표는 각 서비스에 자체 전용 데이터베이스를 제공하여 유지 관리를 개선하고 팀 간 종속성을 줄이는 것입니다. 그러나 상당한 문제에 직면하고 있습니다. 세 팀 모두 진행 중인 프로젝트에 맞게 데이터베이스를 계속 적극적으로 수정하는 동안 데이터베이스를 분해하는 것은 거의 불가능합니다. 지속적인 스키마 변경과 팀 간의 조정 부족으로 인해 상당한 재구성을 시도하는 것이 매우 위험합니다.

아키텍트는 데이터베이스 래퍼 서비스 패턴을 사용하여 모놀리식 데이터베이스에 대한 액세스 제어를 시작합니다. 먼저 주문 서비스라는 특정 모듈에 대한 데이터베이스 래퍼 서비스를 설정합니다. 그런 다음 데이터베이스에 직접 액세스하는 대신 주문 처리 서비스를 리디렉션하여 래퍼 서비스에 액세스합니다. 다음 이미지는 수정된 인프라를 보여줍니다.