우리는 각각 고유 한 기본 데이터가있는 여러 서비스를 통합하는 웹 플랫폼을 구축하고 있습니다. 이러한 서비스는 서비스 지향 아키텍처 (Service-Oriented Architecture) 의 원칙에 따라 독립적으로 구축 되지만 잠재적으로 관련된 데이터와는 거래됩니다. 우리는 이러한 서비스가 하나의 큰 데이터베이스를 공유해야하는지 또는 각각 고유 한 데이터베이스를 보유해야하는지 고려하고 있습니다. (Windows 2008 클러스터에서 SQL Server 2008 Enterprise를 사용할 계획입니다.)

우리가 이미 고려한 각 접근 방식의 장점 중 일부는 다음과 같습니다.

단일 데이터베이스

• 외래 키 제약 조건으로 서로 다른 서비스의 데이터 관련을 함께 바인딩 할 수 있습니다.
• 분석 추출은 작성이 간단하고 실행 속도가 빠릅니다.
• 재난 발생시 플랫폼을 일관된 상태로 복원하는 것이 더 쉽습니다.
• 여러 서비스에서 참조하는 데이터의 경우 한 서비스에서 캐시 된 데이터는 다른 서비스에서 곧 사용될 수 있습니다.
• 관리 및 모니터링이 더 간단하고 저렴합니다.

여러 데이터베이스

• 유지 관리 작업, 하드웨어 문제, 보안 위반 등이 반드시 전체 플랫폼에 영향을 미치지는 않습니다.
• 각 데이터베이스가 별도의 하드웨어에 있다고 가정하면 여러 컴퓨터를 확장하면 하나의 큰 데이터베이스를 확장하는 것보다 더 많은 성능 이점이 있습니다.

운영 관점에서 볼 때이 플랫폼의 각 서비스가 자체 데이터베이스를 가져 오거나 모두 동일한 데이터베이스에있는 것이 더 유리합니까? 이 질문에 대한 답변을 제공하는 주요 요인은 무엇입니까?

필자의 의견으로는, 진정한 SOA 시스템 (의사 SOA, 유비쿼터스 화되고있는 ntier / 분산 시스템)의 주요 차별화 요소는 개별 서비스간에 상호 작용이 전혀 없어야한다는 것입니다. 이것이 달성되는 경우, 이러한 서비스에서 작성하는 모든 응용 프로그램은 구성 부품의 고장을 견딜 수 있도록 구축 될 수 있으며 구축되어야합니다. 실패는 기능을 줄이지 만 서비스는 유지됩니다.

이 시나리오에서는 각 서비스마다 기본 데이터베이스를 분리하는 것이 논리적이거나 필수입니다. 그러나 상호 의존적 인 서비스가 있다면 분할에서 얻을 것이 거의 없습니다 (아마도 없음).

결코 실패하지 않는 유형의 웹 사이트에서 채택한 아키텍처를 파는 HighScalability.com 과 같은 사이트를 읽는 것이 좋습니다 . 내가 가장 좋아하는 것 중 하나는 Coding Horror 에 언급 된 Netflix Chaos Monkey 의 이야기였습니다 .

귀하의 질문에 몇 가지 요점을 제시하십시오.

재난 발생시 플랫폼을 일관된 상태로 복원하는 것이 더 쉽습니다.

이것은 사실이지만 아마도 이러한 서비스를 더 잘 분리하여 문제가되는 것을 막는 방법에 대해 생각해야합니다. 또는 여러 데이터베이스 간의 동기화를 보장하는 방법 ( 예 : SQL Server의 트랜잭션 표시)이 있습니다.

여러 서비스에서 참조하는 데이터의 경우 한 서비스에서 캐시 된 데이터는 다른 서비스에서 곧 사용될 수 있습니다.

분산 캐시 솔루션 (memcached et al)은 여기서 도움이 될 수 있지만 서비스 독립성 원칙을 위반하게됩니다. 이는 두 서비스가 서로 직접 통신하거나 서비스 인터페이스가 우회하여 다른 데이터 저장소에 액세스하는 것이 더 나빠질 수 있습니다. 필연적으로 데이터는 관련되어 있고 호출 플랫폼에 의해 서비스간에 전달 될 것이며, 까다로운 결정은 어떤 서비스가 어떤 데이터를 소유 할 것인지에 관한 결정이다. 보다 일반적인 SOA 문제를 해결하기 위해 StackOverflow 또는 프로그래머 사이트를 더 잘 배치 할 수 있습니다.

각 데이터베이스가 별도의 하드웨어에 있다고 가정하면 확장하면 더 많은 성능 이점을 얻을 수 있습니다.

단일 머신을 확장하는 것보다 여러 개의 낮은 사양의 머신을 확장하는 것이 더 저렴할 수 있습니다. 그러나 추가 개발 노력과 운영 복잡성의 부드러운 비용이 고려 될 때 총 소유 비용에서 하드웨어 비용이 절감 될 수 있습니다.

이것이 SOA가 아니고 물류상의 이유로이 팀의 구성 요소 서비스가 다른 팀 / 공급 업체에 의해 구축되는 경우에는 단일 데이터베이스를 사용하고 위의 모든 것을 완전히 무시하십시오! :)