수백 개의 Oracle 인스턴스를 하나의 인스턴스로 통합하는 지혜

수백 개의 Oracle 인스턴스를 하나의 인스턴스로 통합하는 지혜

우리의 애플리케이션은 웹에서 실행되고, 대부분은 문의 도구이며, 일부 거래를 수행합니다.Oracle 데이터베이스를 호스팅합니다.이 앱에는 항상 고객마다 다른 Oracle 인스턴스가 있습니다.고객은 회사의 직원들에게 서비스를 제공하기 위해 우리에게 돈을 지불하는 회사입니다. 일반적으로 고객당 10,000명에서 25,000명의 직원이 있습니다.우리는 수백 명의 고객을 확보할 계획입니다.몇 년에 한 번씩 주요 릴리스를 제공하고 있으며, 이 새로운 릴리스로 마이그레이션하는 것은 매우 어렵습니다. 고객 사이트에 몇 주 동안 팀을 배치하여 새로운 기능을 설명하고 해당 고객에 맞는 주행 데이터를 설정할 수 있습니다.

비용을 절감하기 위해 모든 고객을 윈도우즈 서버 2008 서버의 단일 공유 오라클 11g 인스턴스에 통합하여 멀티 클라이언트로 전환하는 것을 고려하고 있습니다.저는 그게 바람직한지 궁금합니다.

각 고객에 대해 별도의 인스턴스를 갖는 것에는 몇 가지 이점이 있습니다.이것들이 가짜인지 알려주세요.중요성 감소에 대한 대략적인 추측으로는:

• 스키마가 변경되면 MyCorp와 YourCo 고객을 별도로 마이그레이션할 수 있습니다. (멀티 클라이언트를 사용하면 하룻밤 사이에 300개 이상의 고객을 마이그레이션할 수 있습니다!?)!)

• MyCorp의 데이터는 다른 고객에게 영향을 미치지 않고 쉽게 백업 및 복원할 수 있습니다.

• MyCorp의 데이터는 개발자나 DBA가 올바른 구성을 제공하는 데 의존하지 않고 경쟁업체인 YourCo의 데이터와 안전하게 분리됩니다.

• 한 고객에게 발생한 재해(누군가 실수로 모든 사람의 급여를 두 배로 늘렸다가 급여 지급일 이후에 오류가 발견됨)는 다른 고객에게 영향을 미치지 않기 때문에 여러 사례가 위험을 낮출 수 있습니다.모든 고객(Woops, 신규 DBA, 갑자기 모든 참가자가 동일한 SSN!?!)에게 영향을 준 재해가 발생하면 당사가 파산할 수 있습니다.

• 한 서버에 하나의 인스턴스가 있으면 단일 장애 지점이 발생하며 허리케인이 건물을 덮칠 경우 전체 고객 기반이 문을 닫게 됩니다.여러 서버의 여러 인스턴스를 통해 지리적 분산이 가능합니다. 대규모 고객에게 영향을 미치는 재해는 없으며, 다른 지역의 영향을 받지 않는 서버가 장애가 발생한 서버의 부하를 감당할 수 있습니다.

• 데이터베이스가 더 작기 때문에 성능이 향상됩니다(최대 50개 테이블의 2,000,000 행과 비교하여 10,000 행).

• MyCorp의 사무실이 (대부분) 한 지역에만 있는 경우 MyCorp의 인스턴스를 지리적으로 동일하게 배치할 수 있으므로 네트워크 지연으로 인해 성능이 저하되지 않습니다.우리는 같은 이유로 글로벌 고객들에게 더 나은 서비스를 제공할 수 있습니다.

• MyCorp에서는 데이터베이스를 사내로 가져가려고 합니다. 그러면 MyCorp의 데이터를 얻기 위해 인스턴스를 쉽게 내보낼 수 있습니다.

• 인스턴스를 다른 서버에 배치할 수 있기 때문에 로드 밸런싱이 더 쉽습니다(웹 팜 사용).

• DEV 또는 QA 인스턴스가 필요한 경우 데이터가 훨씬 적기 때문에 실제 인스턴스를 복제하고 데이터를 익명화하는 것이 더 쉽습니다.

• 개발자는 크기가 충분히 작기 때문에 자체 인스턴스를 로컬에서 실행할 수 있기 때문에 공항에서 대기하는 동안이나 기내에서 VPN의 번거로움 없이 코드 작업을 할 수 있습니다.

Q1: 개별 인스턴스의 다른 이점은 무엇입니까?

데이터베이스 스키마를 변경하고 모든 고객을 하나의 무거운 서버에서 실행되는 하나의 오라클 인스턴스로 통합하는 방안을 고려 중입니다.

다음은 다중 클라이언트 인스턴스 접근 방식의 장점으로, 가장 중요한 첫 번째 방법(My WAG)입니다.만약 이것들이 가짜라면 잘라주세요:

• 수백 개가 아닌 하나의 인스턴스만 유지 관리하면 되므로 DBA의 작업량이 줄어듭니다.DBA 작업이 줄어들면 비용이 절감되고 이러한 변화의 주요 동기가 됩니다.

• 단 하나의 인스턴스로 DBA는 성능 최적화 작업을 더 잘 수행할 수 있습니다.그들은 적절한 인덱스를 추가하고 SQL을 검토할 시간을 가질 것입니다.

• 스키마와 앱이 하나뿐이기 때문에 개발자가 애플리케이션을 디버깅하고 향상시키는 것이 더 쉬울 것입니다(스키마 버전마다 앱의 버전이 다른 수백 개의 인스턴스가 있는 경우 수십 개의 스키마 버전이 있을 수 있습니다).이를 통해 비용도 절감됩니다.대안은 (1) 이 고객이 실행 중인 버전이 무엇인지, (2) 해당 개발 환경, 코드 및 데이터베이스를 다시 만들기 위해 노력하는 것입니다.(각 패치 및 릴리스에 대한 코드와 데이터베이스 인스턴스가 포함된 가상 시스템이 필요합니다!)

• Oracle 라이센싱은 무게에 관계없이 서버당 가격이 책정되기 때문에 더 저렴합니다.

• 인스턴스가 하나뿐이므로 데이터베이스는 웹 세션 데이터에 대한 사용 가능한 영구 저장소가 됩니다.

• 일부 데이터베이스 운영은 하나의 다중 클라이언트 인스턴스로 더 쉽습니다. 예를 들어, 참가자가 어떤 고객(또는 배우자)을 위해 일하는지 알 수 없을 때 참가자를 찾는 것과 같이, 모든 이름이 한 테이블에 있습니다.고객 전체에 걸친 보고는 간단합니다.

Q2: 한 인스턴스에 여러 클라이언트가 있을 경우의 다른 이점은 무엇입니까?

Q3: 어떤 접근 방식이 더 낫다고 생각하십니까(이유는)?고객당 인스턴스 또는 한 인스턴스의 모든 고객?

하나의 다중 클라이언트 인스턴스가 마이그레이션을 거의 불가능하게 만드는 것이 걱정됩니다. 그것은 거래를 성사시키는 것입니다.

두 개의 다중 클라이언트 인스턴스(구 클라이언트 인스턴스와 새 인스턴스)를 갖는 것과 같은 타협적인 솔루션이 없는 한,이 경우 당사는 참가자 찾기, 보고 등을 위한 교차 인스턴스 솔루션을 설계하여 고객이 한 멀티 클라이언트 인스턴스에서 다른 인스턴스로 이동할 수 있도록 지원합니다.

Oracle XE(무료 한정판)를 사용하지 않는 한, 단일 코어 단일 CPU 박스를 구입하는 경우에도 서버당 하나의 데이터베이스를 보유하는 것은 매우 빠르게 비용이 많이 듭니다.각 데이터베이스는 CPU 및 RAM 사용량의 오버헤드를 발생시키기 때문에 서버당 여러 개의 데이터베이스를 보유하는 것은 비효율적입니다.경합을 진단하기가 더 어렵기 때문에 조정이 더 어렵습니다.

따라서 단일 대형 서버는 관리가 용이할 뿐만 아니라 별도의 소규모 서버보다 저렴한 비용으로 작동해야 합니다(보증 없음, 비용 반환 없음).최대한 크고 빠른 칩과 여유 슬롯이 있는 만큼의 RAM을 구입해야 합니다.라이센스 비용에 영향을 주지 않으면서 성능을 향상시킬 수 있습니다.

여유가 있다면 파티션 옵션을 고려해 보십시오.이렇게 하면 각 파티션에 고유한 테이블 공간이 있을 수 있기 때문에 백업 및 복구와 관련된 우려 사항을 해결할 수 있습니다.따라서 (client_id로 파티셔닝을 지정하면) 다른 클라이언트에 영향을 주지 않고 개별 클라이언트의 데이터를 백업하거나 복원할 수 있습니다.개별 파티션을 내보내고 가져올 수도 있습니다.파티션 가지치기가 VPD에서 작동하지 않았다는 David의 관찰에 놀랐습니다.하지만 저는 이 조합을 먹어본 적이 없어서 그의 말을 믿겠습니다.

통합으로 인해 손실될 수 있는 한 가지는 애플리케이션의 다른 버전에서 서로 다른 클라이언트를 지원할 수 있다는 것입니다.하지만, 이것이 반드시 나쁜 것은 아닙니다.보시다시피, 애플리케이션의 개별 버전을 포기하면 수백 명의 고객을 유지 관리하는 것이 훨씬 쉬워질 것입니다.개별 클라이언트에서 일부 기능을 베타 테스트하는 경우에도 맞춤형 기능을 제공해야 한다면 11gR2의 Edition-Based Redefinition을 살펴보십시오. 이 기능은 매우 유용합니다.또한 Enterprise뿐 아니라 모든 Oracle 라이센스에도 사용할 수 있습니다.

'별도 인스턴스'라고 하면 여러 개의 스키마가 있는 하나의 인스턴스를 말하는 것입니까?아니면 단일 시스템에서 여러 인스턴스가 실행된다는 뜻입니까?단일 인스턴스에서 여러 스키마를 실행하는 것과 달리 단일 시스템에서 여러 인스턴스를 실행할 이유가 거의 없습니다. 각 스키마에는 여전히 고유한 테이블, 인덱스 등이 있습니다.

어쨌든 전체적인 답변은 아니지만 한 가지 염두에 두어야 할 것은 Oracle의 라이센스 비용과 이로 인해 최적의 솔루션이 무엇인지에 어떻게 영향을 미칠 수 있는지입니다.

오라클 스토어에 따르면,

• Oracle 표준 버전 1은 $5,800.00 / 프로세서입니다(여기서 x86에서는 프로세서가 소켓이며 최대 2개의 소켓으로 이동할 수 있습니다).
• Oracle Standard Edition은 $17,500.00 / 프로세서입니다(여기서 x86에서는 프로세서가 소켓이며 최대 4개의 소켓까지 이동할 수 있음).
• Oracle Enterprise Edition은 프로세서당 $47,500.00입니다(x86의 경우 프로세서는 코어가 2개이므로 쿼드코어 CPU의 가격을 효과적으로 두 배로 높여야 함).

예를 들어, 100개의 고객을 처리하기 위해 8개의 쿼드코어 CPU가 필요한 경우, 단일 데이터베이스에 라이센스를 부여하는 것이 각각 25개의 고객을 실행하는 2개의 쿼드코어 CPU가 있는 4개의 별도 데이터베이스보다 훨씬 더 비용이 많이 듭니다.

8개의 쿼드코어 CPU를 사용하려면 엔터프라이즈 에디션이 필요하며 정가는 16 x 47,500달러 = 760,000달러입니다. 각각 표준 에디션을 실행하고 있으며 2개의 쿼드코어 CPU를 사용하는 시스템의 정가는 8 x 5,800.00달러 = 46,400달러로 16배 차이가 납니다.아무도 엔터프라이즈 에디션의 정가를 지불하지 않지만 여전히 고려해야 할 큰 차이가 있습니다.

클라이언트 간에 데이터베이스 작업이 크게 필요하지 않고 Enterprise Edition 기능이 필요하지 않으며 이 수준의 CPU 성능이 필요하거나 이 수준의 CPU 성능이 필요할 것으로 예상되는 경우 라이센스 비용은 단일 인스턴스 방식의 큰 단점이 될 수 있습니다.

영업 인력을 조사할 가치가 있을 수 있으며, 귀사가 찾고 있는 유행어는 "멀티 테넌트 아키텍처"입니다.

이것은 좋은 읽을거리입니다.

http://blog.dayspring-tech.com/2009/02/forcecom-multitenant-architecture-under-the-covers/

Salesforce는 Oracle 데이터베이스를 사용하기 때문에 좋은 예입니다.

좋은 질문입니다. 모든 대안을 고려하고 있다니 기쁩니다.좋은 점이 많지만 한 가지만 짚고 넘어가겠습니다.

저는 호스팅된 애플리케이션의 DBA였고 개발자들은 이를 위해 Oracle Virtual Private Database 기능을 사용하기로 결정했습니다.

이 애플리케이션은 로드 밸런싱을 위해 애플리케이션 서버 풀을 공유하고 백엔드에 단일 데이터베이스 스키마를 사용하도록 설계되었습니다.

VPD 이전에는 모든 쿼리가 데이터베이스로 이동하기 직전에 "where customer_id=?" 또는 "및 customer_id=?"를 태그하여 고객이 데이터만 볼 수 있도록 하는 Java 클래스가 있었습니다.DB에 로그인할 때 VPD에서 이를 구현하기 위해 앱이 VPD 정책에서 사용할 변수를 앱 컨텍스트에 설정하여 세션이 자신의 레코드만 볼 수 있도록 합니다.따라서 올바른 코드를 작성하고 VPD 정책을 테이블에 할당해야 하며 Oracle이 계약의 목적을 달성할 수 있다고 확신해야 합니다.

그래서 그게 우리에게 좋았나요?이론적으로는 SQL 서술어 처리를 애플리케이션 외부로 오프로드하는 것이 좋았지만 실제로는 장점이 단점을 능가하지 않았습니다.

• 한 데이터베이스에 수십 개의 클라이언트가 있을 때와 업그레이드할 때 모두 동시에 업그레이드해야 했습니다.어떤 이유로든 업그레이드를 원하지 않거나 새로운 버전에 대해 자체 QA를 수행하려는 고객과 많은 줄다리기를 했습니다.

• 업그레이드를 위해 이전 인스턴스/새 인스턴스 작업을 수행했지만 데이터 마이그레이션이 위험하고 관련 다운타임으로 인해 고객이 만족하지 못했습니다.우리는 테이블을 통과하고 데이터를 내보내는 우리만의 절차를 실행했습니다.그러나 신속한 내보내기 또는 데이터 펌프 작업만큼 쉽지는 않습니다.

• 파티셔닝과 관련하여 VPD 술어 분석에도 문제가 있었습니다.많은 Oracle 기능과 마찬가지로 자체적으로 작동할 수도 있지만 다른 기능과 결합하면 예측할 수 없게 됩니다.현재 customer_id와 관련이 없는 파티션은 SQL 문 처리가 너무 늦었기 때문에 제거되지 않았습니다.정적인 VPD 정책에서 동적인 VPD 정책으로 변경하여 이 문제를 해결했지만 분석에 소요되는 시간이 급증했습니다.

그래서 결국 그것에 대한 나의 견해는 무엇입니까?저는 앱이 바인딩 변수를 잘 활용하고 SQL 문에 customer_id를 추가한 기존 메커니즘을 계속 사용하도록 시간을 보냈을 것입니다.

Oracle은 이러한 종류의 부하를 처리하도록 설계되었습니다.

나의 질문 - 고객이 천 명이고 만 명이라고 하면 어떻게 합니까?
아직도 별도의 인스턴스/구성표를 보관하고 있습니까?

아무도 그렇게 하지 않을 거예요.저는 이전에 각 클라이언트가 중앙 위치에 별도의 데이터베이스와 사본을 가지고 있는 곳에서 일했습니다.
변경 관리는 골치아픈 문제가 되며, 데이터베이스 개정, 스키마, 앱 버전 등에 대해 어느 클라이언트/회사가 있는지에 대한 매우 좋은 정보를 유지해야 합니다.이것은 그 자체로 소프트웨어가 될 것입니다.
SaaS 모델을 기반으로 모든 사용자가 쉽게 유지보수할 수 있고 동일한 데이터베이스/구성표를 사용할 수 있는 소프트웨어/설계를 만들 것을 제안합니다.

안정성을 위해 클러스터링 - Oracle RAC를 계속 사용할 수 있습니다.

저는 같은 결정을 몇 번 고려해야 했습니다.이 경우 MySQL을 사용하므로 별도의 데이터베이스에서 모든 고객을 운영하는 데 따른 비용이 들지 않습니다.

모든 고객을 별도의 데이터베이스에서 운영할 경우의 이점은 매우 큽니다.로드 밸런싱을 위해 고객의 전체 인스턴스를 모든 서버로 이동할 수 있는 스크립트가 있습니다.이 스크립트는 데이터베이스를 통해 복사하고, 사용자 지정 파일을 통해 복사하고, 애플리케이션을 회전시키고, 사용자를 새 인스턴스로 전송하도록 라우팅 시스템을 설정합니다.이 모든 과정은 단 몇 분 만에 완료됩니다.

대규모 mysql 데이터베이스에서 데이터베이스 변경은 매우 오랜 시간이 걸릴 수 있습니다.모든 클라이언트가 자체 데이터베이스를 가지고 있기 때문에 모든 데이터셋을 작게 유지할 수 있습니다.백업 속도도 매우 빠릅니다.

개발 인스턴스는 동일한 방식으로 작동하므로 이 방법을 사용하면 새로운 기능을 개발하고 테스트할 때 다양한 데이터베이스 스키마를 동시에 실행할 수 있습니다.우리는 종종 고객과 협력하여 다른 인스턴스에 새로운 기능을 구현하기 전에 새로운 기능을 사용해 보도록 합니다.언급한 몇 가지 단점을 방지하기 위해 우리가 고수하는 한 가지 규칙은 모든 클라이언트가 서로의 한 버전 내에 있어야 한다는 것입니다.여러 클라이언트에서 여러 버전을 유지 관리하면 오버헤드가 매우 큽니다.

페이스북은 그들의 회사를 시작했을 때 같은 접근법을 취했습니다.그들이 시작한 각 학교는 별도의 데이터베이스를 가지고 있었고 그들은 매우 빠르게 새로운 인스턴스를 설정할 수 있었습니다.그들이 마침내 데이터베이스를 통합한 주된 이유는 사용자들이 학교 간에 의사소통을 할 수 있도록 하기를 원했기 때문입니다.

잠재적인 비용 문제가 아니라면 별도의 데이터베이스 접근 방식을 고수하는 것이 좋습니다.

언급URL : https://stackoverflow.com/questions/2405658/wisdom-of-merging-100s-of-oracle-instances-into-one-instance