클라우드 호스팅 고려 사항 및 패턴

ISV(독립 소프트웨어 공급업체)의 경우

ISV(독립 소프트웨어 공급업체)는 애플리케이션 호스팅을 위해 안전하고 확장 가능하며 안정적인 플랫폼 & 인프라 서비스가 필요합니다. ISV는 클라우드에서 백오피스 시스템을 실행하는 IT(정보 기술) 조직에 비해 훨씬 더 많은 문제를 마주하게 됩니다. 여기에는 연중무휴 운영, 지리적으로 다양한 배포, 탄력적 확장이 필요한 동적 고객 트래픽 패턴 처리, 퍼블릭 인터넷에서 애플리케이션의 노출에 따른 보안 문제 등이 포함됩니다.

하나 이상의 대규모 클라우드 플랫폼으로 전환 중이거나 운영 중인 ISV는 여러 가지 중요한 선택 사항과 패턴을 고려해야 합니다. 애플리케이션을 있는 그대로 전환하는 리프트 앤 시프트 방식을 고려하고 계십니까? 아니면 클라우드 마이그레이션을 통해 보다 클라우드에 친숙한 환경으로 재설계하고 공급업체의 관리형 PaaS 서비스를 활용할 수 있기를 원하십니까? 클라우드 배포를 통해 데이터 센터 내부의 장애 도메인, 지역 내 가용성 도메인 또는 지역 간 상호 연결을 활용함으로써 고가용성(HA) 및 재해 복구(DR) 혁신을 이룰 수 있습니까? 클라우드 공급업체가 데이터, 내부 네트워크, 컴퓨팅 호스트/컨테이너, 고객과의 상호 작용을 보호하기 위해 어떤 도구를 제공합니까? 마지막으로 애플리케이션을 다중 테넌트 SaaS로 배포하길 원하십니까? 아니면 각 고객에 맞는 단일 테넌트 구성이 필요하십니까?

Oracle 클라우드 엔지니어링 팀은 수백 개의 애플리케이션에 대한 OCI 이전 외에도 수십 곳의 ISV에서 OCI로의 이전을 계획하고 실현하는 데 도움을 주었습니다. 이 마이크로사이트는 지침을 제공하고 ISV를 위한 고유한 호스팅 패턴을 제시합니다.

또한 Oracle Cloud를 채택하는 다양한 접근 방식을 통해 다양한 주제를 살펴봅니다.

이 마이크로사이트는 선형 진행 방식으로 구성되지 않았습니다. 아래 다이어그램은 사용자 자신의 프로파일을 기반으로 이 사이트에서 사용할 수 있는 탐색 경로를 시각적으로 보여줍니다. 이 소개를 마친 후 Oracle 프로세스 섹션을 읽고 현재 호스팅 모델에 따라 BitC(Born in the Cloud) 또는 온프레미스/코로케이션 섹션을 선택하십시오. 그런 다음 애플리케이션 제공 모델에 따라 다중 테넌트 또는 단일 테넌트 SaaS 섹션을 참조하십시오. 마지막으로 요약과 함께 일반적인 공통 우려 사항 섹션을 참조해야 합니다.

Oracle 프로세스

Oracle 설계자 및 엔지니어 팀은 OCI로의 마이그레이션은 물론 OCI에서의 탁월한 애플리케이션 운영을 돕기 위해 최선을 다하고 있습니다. Oracle은 실무 중심의 접근 방식으로 귀사의 모든 여정 단계에서 개인화된 지원과 전문 지식을 제공합니다. Oracle은 수명 주기 초기부터 프로젝트에 참여하여 귀사가 OCI 및 SaaS 제품의 핵심 구성요소를 이해할 수 있도록 도움을 드립니다. 그런 후 이러한 두 가지 핵심 구성요소를 통합하기 위해 협력합니다. Oracle은 OCI 기초에 대한 팀 교육을 지원할 뿐만 아니라 전체 OCI 테넌시를 구상, 설계 및 구현할 수 있도록 도움을 드립니다.

내부적으로 Oracle 클라우드 엔지니어는 고객을 위해 클라우드 배포를 신속하게 구축하는 접근 방식을 따릅니다. 여기에는 Oracle 엔지니어들이 합의된 마일스톤 및 아티팩트를 포함하여 솔루션을 정의, 설계, 제공하는 과정을 안내하는 통합 참여 모델이 포함됩니다. 생성된 프로세스 아티팩트 중 일부에는 고객의 자사 클라우드 구축 프로세스에 유용하게 활용할 수 있는 공동 프로젝트 계획, 논리적 아키텍처 및 운영 RACI가 포함되어 있습니다.

예를 들어 잠재적인 ISV 파트너와 일반적인(무료) 계약을 맺을 때는 아래와 같은 프로세스가 적용됩니다.

  1. Oracle은 계약을 위해 경영진 스폰서, 비즈니스 분석가, 숙련된 클라우드 설계자를 배정합니다.
  2. Oracle의 지원 업무는 양측의 참여 목표, 범위, 가정, 일정, 주요 참여자를 정의하고 이를 공동 실행 계획에 문서화하는 것으로 시작됩니다.
  3. 그런 다음 귀사의 기술 팀과 함께 귀사의 현재 아키텍처를 철저하게 파악하는 과정을 진행합니다. 이를 위해 Oracle은 상세한 검색 질문과 데이터 수집 과정을 통해 사람, 프로세스, 기술을 중심으로 귀사의 기존 소프트웨어 인벤토리, 논리적 아키텍처, 운영 모델을 파악합니다.
  4. 교육 세션이 필요한 경우 Oracle 클라우드 설계자는 보안, 데이터베이스, 관측 가능성 등의 분야에서 심층 논의를 진행할 수 있는 전문가를 찾아서 지원합니다.
  5. Oracle은 귀사의 팀과 협력하여 OCI에 대한 미래 기술 아키텍처를 구축하고 OCI에 관한 세부 내역을 제시합니다. 필요에 따라 기존 호스팅 환경과 비용을 비교하고 경쟁력 있는 비즈니스 사례를 구축할 수 있도록 지원합니다.
  6. Oracle은 개념 증명(POC) 구현을 강력하게 권장합니다. 여기에서 Oracle 설계자는 귀사 팀과 협력하여 POC 범위를 정의합니다. 그리고 귀사에 필요한 참여 수준에 맞게 POC를 실행하는 데 필요한 Oracle 클라우드 엔지니어링 리소스를 제공합니다.
  7. OCI로의 전환이 준비되면 긴밀한 실무 협의를 통해 OCI 테넌시를 구성하고 처음부터 모범 사례를 적용할 수 있도록 지원합니다.

이러한 참여는 첫 번째 워크로드가 전달되었을 때 끝나지 않습니다. OCI와 다른 클라우드 공급업체 사이의 명확한 차별점은 Oracle Cloud Lift Services에 있습니다. OCI 전문가들로 구성된 Oracle 전담 팀은 평가, 설계, 프로토타이핑, 마이그레이션, 관리를 포함한 GLA(go-live activity)를 통해 초기 계획 단계부터 면밀한 하이터치 서비스를 제공하고 추가 비용 없이 가치 실현 시간을 단축할 수 있도록 도움을 드립니다. 신규 고객과 기존 고객 모두 이 프로그램의 혜택을 받을 수 있으며, 계약 단계 또는 확장 기회가 발생할 때 자격 조건이 결정됩니다. 적격한 워크로드에 대한 마이그레이션 및 GLS(go-live support)를 통해 영업 프로세스가 진행되는 기간은 물론 이후까지 전문가 참여를 통해 워크로드를 프로덕션으로 더 빠르게 전환할 수 있도록 도움을 드립니다.

ISV는 Oracle Cloud Lift Services를 활용하여 추가 비용 없이 다음 활동 중 일부를 수행할 수 있습니다.

  • OCI로 애플리케이션 마이그레이션
  • OCI 테넌시, 컴파트먼트, 할당량, ID 구성과 네트워크 구성 및 보안, FastConnect 설정, 감사, 규제 준수 평가에 대한 기본 검토 수행
  • OCI에 대한 사내 리소스 교육
  • 코드형 인프라(Infrastructure-As-Code) 작업 자동화에 도움이 되는 Terraform 계획 수립

Oracle의 클라우드 엔지니어링 조직이 수년 동안 고객 SaaS 애플리케이션을 OCI로 마이그레이션하면서 얻은 다양한 교훈에 대해 자세히 알아보려면 ISV를 위한 SaaS 마이그레이션 플레이북을 참조하십시오.

Oracle의 클라우드 엔지니어들이 수많은 고객 워크로드를 마이그레이션하면서 얻은 반복되는 패턴과 청사진은 OCI 아키텍처 센터에 확인할 수 있습니다. 또한 일반적인 모범 사례는 OCI 모범 사례 가이드에 정리되어 있습니다. 오늘날 OCI에서 운영되는 다양한 맞춤형 솔루션을 살펴보기 위해 잠시 시간을 내어 이 자료들을 검토하시기 바랍니다.

많은 ISV SaaS 제공업체가 'BitC(Born in the Cloud)'이기 때문에 '클라우드 네이티브'로 보이지만 항상 그렇지는 않습니다. BitC라는 표현은 일반적으로 기존 시스템에서 벗어나서 현대적인 애플리케이션 설계 원칙을 따르고 싶어하는 열망을 의미합니다. 현대적인 애플리케이션 설계는 Twelve Factor App에 요약된 원칙에 기초한 아키텍처 지침입니다. 이 개념은 클라우드 네이티브 아키텍처와 구별되지만 밀접한 관련이 있습니다. Oracle 관점에서 클라우드 네이티브 개념을 보다 깊게 이해하기 위해서는 클라우드 네이티브 설계에 중점을 둔 Cloud Native Patterns eBook을 살펴보는 것이 좋습니다.

SaaS 애플리케이션이 현대적인 애플리케이션 설계 원칙 또는 클라우드 네이티브 원칙에 따라 구축되었는지에 관계없이 애플리케이션의 발전을 이끄는 몇 가지 동일한 핵심 요소가 있습니다.

  • 현대적인 애플리케이션 개발 원칙 채택
  • 인프라가 아닌 애플리케이션에 집중
  • 기능의 가치 실현 시간 단축
  • 지속적이고 신뢰할 수 있으며 반복 가능한 배포
  • 구시대적이거나 제한적인 것으로 간주되는 '레거시' 또는 단일 공급업체 시스템과의 결별
  • 현대적인 아키텍처 구축, 운영 및 지원
  • 클라우드 컴퓨팅으로 지원되는 탄력적인 방식의 운영

이러한 목표를 설정한 ISV는 일반적으로 보다 모듈화된 방식의 서비스 아키텍처를 채택합니다. 이러한 ISV에서 워크로드에 사용되는 애플리케이션 구성요소는 종종 컨테이너로서 독립적으로 배포할 수 있으며, 구성요소 장애가 발생하더라도 애플리케이션이 계속 작동하도록 애플리케이션 아키텍처가 구축됩니다. 데이터 일관성뿐만 아니라 애플리케이션 가용성도 지원할 수 있어야 합니다.

선택한 런타임 아키텍처에 따라 ISV는 모니터링 및 알림 시스템을 인프라 관리에 통합할 가능성이 높습니다. OCI는 다음과 같은 지원 서비스를 제공합니다.

구성요소 간 통신에서는 직접 명령 대신 구성요소가 이벤트를 생성하고 응답하는 비동기 패턴을 구현하는 경우가 많습니다. OCI는 이러한 통신을 처리하는 데 자주 사용되는 서버리스 스트리밍 서비스이자 Kafka와 호환되는 스트리밍 서비스를 제공합니다. 이 접근 방식은 지능형 대기열 구성 또는 라우팅을 활용해서 폭발 반경을 최소화하여 장애 발생 시 구성요소를 보호하는 이점이 있습니다.

추가적인 분리 효과는 인프라에서 애플리케이션 분리를 통해 얻을 수 있습니다. 탄력성은 종종 클라우드 서비스 제공업체(CSP)가 제공하는 자동 크기 조정 메커니즘을 사용하여 얻을 수 있습니다. 자동 크기 조정은 Oracle Container Engine for Kubernetes(OKE)를 사용하는 컨테이너 수준, 인스턴스 그룹화 수준 또는 서비스 그룹 수준 등 다양한 수준에서 수행될 수 있습니다.

시간이 지남에 따라 일부 SaaS 애플리케이션은 팀에서 단일 CSP로 제공되는 기본 PaaS 서비스 활용이 시작되면서 처음에 계획된 표준 기반 아키텍처에서 벗어날 수 있습니다. 예를 들어, 여기에는 단일 클라우드 전용 데이터 관리 서비스를 사용하고, 향후 교체를 위해 적절한 추상화 계층 없이 공급업체별 NoSQL 플랫폼에 직접 API 호출을 임베딩하고, 공급업체별 코드를 생성하는 IDE를 사용하는 경우 등이 포함됩니다. 클라우드 이식성을 보장하기 위해서는 ISV가 플랫폼 서비스를 이용할 때의 편의성과 단일 공급업체에 종속되어 서비스의 공급업체 중립성을 잃을 위험 사이에서 균형을 유지하도록 주의해야 합니다. 많은 ISV가 진정한 멀티 클라우드 공간 확보를 목표로 애플리케이션을 다시 현대화하기 위한 여정을 진행하고 있습니다. 이를 위해 단일 공급업체 또는 단일 용도 기술과의 긴밀한 결합 지점에 대한 검토가 다시 진행되고 있습니다.

시간이 지남에 따라 인프라 구성은 점진적으로 변화를 겪을 수 있습니다. 대부분의 ISV는 코드형 인프라(IaC) 접근 방식을 따르며, OCI는 산업 표준 도구를 지원합니다. 하지만 OCI는 한 걸음 더 나아가 인프라 구성의 차이를 모니터링, 추적, 복구할 수 있는 관리형 Terraform 서비스인 OCI Resource Manager를 제공합니다.

리프트 앤 시프트 구현에는 온프레미스 또는 코로케이션 시설에서 실행되는 프로덕션 워크로드를 OCI(Oracle Cloud Infrastructure)로 마이그레이션하는 작업이 포함됩니다. 일부 경우에는 애플리케이션 강화를 위해 OCI 내에서 제공되는 기본 클라우드 서비스를 활용할 수 있습니다. 이러한 "이동 및 개선" 활동은 OCI로 이전해야 하는 또 다른 강력한 이유입니다. 다음 섹션에서는 리프트 앤 시프트 프로세스를 살펴보고, 필요에 따라 이동 및 개선과 관련된 고려 사항에 대해 알아봅니다.

이 시나리오는 자본 지출을 줄이고 가용성, 보안, 성능과 관련된 운영 복잡성을 Oracle과 같은 클라우드 서비스 제공업체(CSP)에 위임하려는 ISV에 이상적입니다. 일반적으로 ISV는 다음 전략 중 하나를 구현합니다.

  • 리프트 앤 시프트: 온프레미스 또는 코로케이션된 애플리케이션을 OCI로 마이그레이션합니다.
  • 이동 및 개선: 온프레미스 또는 코로케이션된 애플리케이션을 OCI로 마이그레이션하고 클라우드 네이티브 서비스를 활용하거나 데이터베이스를 클라우드 기반 오퍼링으로 마이그레이션하여 이를 강화합니다.

다양한 마이그레이션 전략을 유연하게 결합할 수 있습니다. 일부 워크로드는 있는 그대로 이동하고, 다른 워크로드는 OCI의 관리형 서비스(PaaS)를 활용하도록 조정할 수 있습니다.

리프트 앤 시프트

리프트 앤 시프트 클라우드 마이그레이션 전략에는 결과 배포가 온프레미스 배포와 매우 유사하도록 온프레미스 애플리케이션을 OCI로 이동하는 과정이 포함됩니다. 이 프로세스의 첫 번째 단계는 OCI 기능을 사용하고 전략적 목표를 달성할 수 있는 워크로드/애플리케이션을 식별하는 것입니다. 데이터 상주, 대기 시간, 연결 요구 사항에 따라 선택 가능한 다양한 호스팅 옵션이 제공됩니다. 다음 중 어떤 호스팅 유형을 선택하든 OCI의 전체 포트폴리오에 액세스할 수 있습니다.

호스팅 유형 설명
퍼블릭 클라우드 IaaS, PaaS 및 SaaS 서비스의 광범위한 플랫폼
정부 클라우드(제한된 영역) 정부 클라우드(제한된 영역) 공공 부문 엔터티를 위해 제한된 영역에 배포된 IaaS, PaaS 및 SaaS 서비스의 광범위한 플랫폼
전용 리전 Cloud@Customer 데이터 센터에 배포된 IaaS, PaaS 미 SaaS 서비스의 광범위한 플랫폼
로빙 엣지 인프라스트럭처 네트워크 에지와 연결되지 않은 위치에서 클라우드 컴퓨팅 및 스토리지 서비스를 제공하는 Ruggedized Oracle Roving Edge Devices(Oracle RED)에 배포된 IaaS, PaaS 및 SaaS 서비스의 광범위한 플랫폼
Oracle Cloud VMWare 애플리케이션을 재설계하거나 운영 방식을 조정할 필요 없이 VMware 기반 워크로드를 클라우드로 이동하거나 클라우드를 포함하도록 온프레미스 VCenter를 확장할 수 있습니다.

클라우드 아키텍처를 설계할 때 Oracle은 다양한 네트워크 연결 옵션을 지원합니다. 이러한 옵션을 사용하면 OCI 리소스를 데이터 센터 내에서 실행되는 구성요소와 혼합하는 하이브리드 클라우드 솔루션을 구축하거나 현재 OCI 설치 기반을 다른 클라우드 서비스 제공업체의 설치 기반과 연결하는 멀티 클라우드 솔루션을 구축할 수 있습니다. 이러한 두 가지 방법 모두 널리 사용되며 온프레미스 또는 다른 클라우드 공급업체 환경에서 실행되는 기존 애플리케이션의 워크로드 종속성을 쉽게 마이그레이션할 수 있으며, 이를 통해 데이터 상주 요구 사항, IT SLA 또는 기타 요구 사항을 충족할 수 있습니다.

OCI는 퍼블릭 인터넷, IPSec VPN, 전용 연결(FastConnect)을 통해 이러한 통신을 지원합니다. 다음 표에서는 이러한 각 접근 방식의 몇 가지 특성을 설명합니다.

방법 대기시간 비용 안정성 보안
퍼블릭 인터넷 변수 변수 변수 최소 보안
IPSec VPN 변수 변수 변수 트래픽이 암호화되지만 퍼블릭 인터넷을 통해 이동함
OCI FastConnect 낮고 예측 가능 예측 가능 가장 안정적 가장 안전하며 트래픽이 프라이빗 연결을 통해 이동함

또한 위에 언급한 기술을 사용하여 OCI와 다른 클라우드 사이의 클라우드 간 상호 연결도 가능하지만 Oracle은 Microsoft Azure와 파트너십을 맺고 전 세계 여러 지역에서 두 클라우드 간에 대기 시간이 짧은 즉각적인 상호 연결을 제공하고 있습니다.

Oracle은 경쟁사 퍼블릭 클라우드 및 가상화/비가상화 온프레미스 환경을 포함하여 다양한 소스에서 OCI로의 마이그레이션 프로세스를 자동화하는 데 특화된 여러 파트너와 협력하고 있습니다. Rackware 및 ZConverter와 같은 주목할만한 사례를 포함하여 마이그레이션 공급업체의 전체 목록은 Marketplace에서 확인할 수 있습니다.

다른 클라우드 또는 온프레미스 환경에서 Oracle Database 마이그레이션을 고려할 때 Oracle은 오프라인 또는 제로 다운타임/라이브 마이그레이션을 지원하는 여러 도구를 제공합니다. 이러한 다양한 도구에는 제로 다운타임 마이그레이션(ZDM), OCI 데이터베이스 마이그레이션(DMS), GoldenGate, DataPump, RMAN 등이 있습니다. 도구 선택은 소스 및 대상 데이터베이스 특성과 운영체제에 따라 달라집니다. 자세한 내용은 OCI 데이터베이스 클라우드 마이그레이션 시작 페이지를 참조하십시오.

이동 및 개선

이동 및 개선 클라우드 마이그레이션 전략에는 기존 서비스를 클라우드 오퍼링으로 강화하거나 대체하는 과정이 포함됩니다. 팀에서 클라우드로 마이그레이션할 적절한 후보를 식별할 때는 서비스를 강화하거나 대체할 수 있는 가능성을 고려하는 것이 가장 중요합니다. 예를 들어 미션 크리티컬 애플리케이션을 지원하는 온프레미스 데이터베이스를 Oracle의 관리형 Database Cloud Service, 최고의 자율 구동 Autonomous Database 또는 클라우드에서 Oracle Database를 실행하는 가장 빠른 플랫폼인 Exadata Cloud Service로 마이그레이션하여 기존 온프레미스 애플리케이션을 향상시킬 수 있습니다.

또한 Oracle Cloud Infrastructure를 채택하여 다음과 같은 전체 서비스 포트폴리오에 액세스할 수 있습니다.

SaaS 공급업체를 위한 다중 테넌트 제공 모델은 공유 인프라에서 실행되는 소프트웨어를 활용하여 개별 ISV 최종 고객(테넌트)을 지원합니다.

고객 데이터는 일반적으로 공유 테이블 세트에 저장되며 모든 애플리케이션 계층에서 고객의 고유 식별자가 인식됩니다. 애플리케이션 자체는 다중 클라이언트를 인식하도록 설계됩니다. 또한 애플리케이션 자체가 사용자 구독 관리를 담당합니다. 그리고 고객 수, 트랜잭션, 지원이 필요한 규정에 따라 인프라를 서버 그룹으로 분류해야 합니다.

이 모델을 선택하는 이유

다중 테넌트 모델은 ISV(독립 소프트웨어 공급업체)에 이점을 제공합니다. 다중 테넌트 모델에서 제공되는 규모의 경제를 활용하여 많은 효율성을 얻을 수 있습니다. 서버 그룹 구성으로 잘 알려진 대로 인프라 관리 및 모니터링 측면에서 효율성을 얻을 수 있습니다. 인프라 자동화 코드를 실행하고 애플리케이션을 배포하는 것처럼 새 서비스 영역을 쉽게 시작할 수 있습니다. 또한 공통 인프라 세트는 모니터링을 위한 통합된 '단일 창'을 제공합니다.

공통 컴퓨팅, 스토리지, 데이터베이스 호스팅을 통해 애플리케이션 배포 전략을 단순화할 수 있습니다. 이 모델을 사용하는 ISV는 일반적으로 단일 코드 베이스를 통해 고객 기반 전체에 업데이트를 쉽게 배포할 수 있습니다. 이 모델을 활용하는 많은 ISV에서는 고객이 기능 플래그를 통해 새로운 기능을 선택할 수 있습니다.

물론 이러한 모든 이점이 단점이 될 수도 있습니다. 특정 데이터 상주 요구 사항이 있는 고객을 지원하기 위해서는 지역별 배포 전략이 필요합니다. 또한 고객이 비즈니스 요구 사항에 따라 경쟁사와 동일한 서버를 공유하지 않는 방식을 선호할 수도 있습니다. 애플리케이션 아키텍처에 따라 클라이언트에 시끄러운 이웃 시나리오가 적용될 수 있습니다. 서버 그룹이 포화 상태가 되면 ISV는 활용도가 낮은 새로운 서버 그룹으로 고객을 마이그레이션하거나 기존 그룹 용량을 확대할지 결정해야 합니다.

다중 테넌트 SaaS 모델을 성공적으로 구현하기 위해서는 단일 테넌트 아키텍처보다 더 포괄적인 수준에서 애플리케이션 아키텍처를 세심하게 설계하고 계획해야 합니다. 처음부터 적절한 액세스 제어 및 데이터 분리 모델을 애플리케이션 프레임워크에 통합하는 것이 중요합니다. ISV는 이러한 목표를 달성하는 데 필요한 사내 엔지니어링 기술을 보유하고 있는지 확인해야 합니다.

Oracle은 클라우드 설계자 지원을 통해 클라우드 성공을 위한 애플리케이션 현대화 및 최적화 조언을 제공함으로써 격차를 해소하도록 도움을 드릴 수 있습니다. Oracle 설계자는 다양한 분야의 ISV와 협업하고 유사한 과제에 대한 해결 경험과 클라우드 전환을 위한 모범 사례를 제공합니다.

서버 그룹 격리

다중 테넌트 모델의 핵심 구성은 호스팅된 테넌트의 공유 환경입니다. ISV는 SaaS 애플리케이션이 런타임 중에 고객 데이터를 적절하게 분리하고 보호할 수 있도록 설계되었는지 확인해야 합니다. 또한 애플리케이션을 호스팅하는 다양한 서버 그룹에서 수행되는 작업을 적절하게 관리, 모니터링 및 유지 관리할 수 있어야 합니다.

경우에 따라서는 특정 지역의 고객을 다른 지역(또는 하위 지역)의 고객과 분리해야 할 수 있습니다. 이러한 분리 목표는 워크로드를 특정 OCI 지역 및 컴파트먼트 조합에 배포함으로써 달성할 수 있습니다. 예를 들어 미국에서 의료 및 일반 제조 시장에 서비스를 판매하는 SaaS 공급업체가 있습니다. 이 공급업체는 지역 및 컴파트먼트 구성을 사용하여 이러한 워크로드를 분리하고 차별화된 기능(예: 의료 워크로드에 대한 HIPPA/HITRUST 규정 준수)을 제공할 수 있습니다.

다중 테넌트 모델로 시작한 ISV는 고객 데이터에 대해 더 나은 격리 수준을 제공하도록 서비스가 자연스럽게 발전합니다. 일반적으로 이러한 발전은 데이터 수준에서 먼저 나타납니다. Oracle Database는 독립적이고, 연결 가능한 데이터베이스를 단일 컨테이너 데이터베이스에 임베딩할 수 있는 다중 테넌트 모델을 지원합니다.

단일 테넌트 제공 모델은 전용 인프라에서 실행되는 소프트웨어를 사용하여 개별 ISV 최종 고객을 지원합니다. 여러 고객이 동일한 컴퓨팅 리소스를 공유하고 공통 데이터베이스 테이블에 데이터를 함께 저장하는 다중 테넌트 모델과 달리, 단일 테넌트 모델에서는 각 고객에 대해 전용 컴퓨팅 VM, 전용 데이터베이스, 전용 지원 인프라(로드 밸런서, 메시지 대기열 등)가 사용됩니다.

이 모델을 선택하는 이유

단일 테넌트 모델은 ISV(독립 소프트웨어 공급업체)에 여러 이점을 제공합니다. 개별 컴퓨팅, 스토리지, 데이터베이스에 각 고객/테넌트를 호스팅함으로써 보안 및 성능 관점에서 우려되는 사항을 명확하게 분리할 수 있습니다. 악의적이든 비의도적이든 한 고객이 다른 고객에게 영향을 미치거나 정당한 것 이상으로 리소스를 소비할 수 없습니다. 또한 치명적인 장애가 발생했을 때 영향을 최소화할 수 있습니다. 데이터베이스 또는 메시지 대기열과 같은 단일 구성요소에 장애가 발생한 경우 전체 SaaS 애플리케이션이 아닌 단일 고객으로 영향 범위를 제한할 수 있습니다. 각 테넌트는 고객 중심의 제공 모델 구축을 위한 고유 기능과 패치로 사용자정의된 고유 환경을 갖추고 있습니다.

물론 이러한 모든 이점이 단점이 될 수도 있습니다. 고객 중심의 환경을 제공함으로써 얻는 이점이 있지만 구성 관리와 모니터링 및 유지 관리 증가와 같은 추가적인 부담도 발생할 수 있습니다. 다중 테넌트 모델에서 이러한 접근 방식으로 많은 이점을 얻을 수 있지만 ISV의 SaaS 애플리케이션을 보다 세심하게 설계하고 구현해야 합니다.

결국 결정은 ISV가 SaaS 애플리케이션을 지원하는 다중 테넌트에 투자할 의향이 있는지에 따라 달라집니다. 이는 필요한 사내 소프트웨어 엔지니어링 기술을 보유하고 있는지 여부에 크게 좌우됩니다. 그렇지 않은 경우 ISV는 소프트웨어 플랫폼 및/또는 하이퍼스케일 클라우드 제공업체에서 제공되는 고유 컴파트먼트 기능을 사용하도록 선택할 수 있습니다. 각 ISV는 자신의 고유 상황에 맞게 이를 선택해야 합니다.

Oracle은 성공적인 클라우드 구현을 위해 애플리케이션 현대화 및 조정을 도와줄 수 있는 클라우드 설계자를 지원함으로써 선택 가능한 옵션을 탐색할 수 있도록 도움을 드릴 수 있습니다. Oracle 설계자는 다양한 분야의 ISV와 협업하고 유사한 과제에 대한 해결 경험과 클라우드 전환을 위한 모범 사례를 제공합니다.

테넌트 격리

단일 테넌트 모델의 핵심 구성은 각 테넌트에 대해 격리된 환경입니다. ISV는 각 고객에 대해 전용 컴퓨팅, 네트워크, 스토리지, 메시징, 데이터베이스 리소스를 프로비저닝할 수 있기를 바랍니다. 그리고 런타임 및 관리 관점에서 리소스가 서로 구분될 수 있도록 해야 합니다.

OCI는 각각의 OCI 리소스를 강력하게 논리적으로 구분하는 컴파트먼트라는 고유한 기능을 제공합니다. 네트워크, 컴퓨팅 등이 포함된 전체 고객 환경을 하나의 컴파트먼트 내에 배치하고 이러한 리소스에 대한 액세스를 제어하는 OCI 정책을 작성할 수 있습니다. 이러한 두 가지 핵심 OCI 기능을 활용하여 한 고객을 다른 고객과 효과적으로 분리하고 리소스, 관리 또는 정보의 교차 오염을 방지할 수 있습니다. 컴파트먼트는 계층적으로 구성되므로 중첩이 가능하며 복잡한 고객 구성을 모델링할 수 있습니다. 예를 들어 한 고객이 여러 개의 부서를 갖고 있으며, 각 부서는 특정 기업 리소스를 공유하면서도 어느 정도 수준의 분리가 필요한 경우를 가정해 보십시오.

컴파트먼트 모델이 가장 강력한 분리를 보장하지만, 애플리케이션의 특정 계층에서 사용할 수 있는 다른 중간 수준의 접근 방식도 있습니다. 이 방법을 사용하면 사용자정의 없이도 테넌트 분리를 유지하면서 리소스 사용을 최적화할 수 있습니다. 예를 들어 각 테넌트에 대해 개별적인 데이터베이스 시스템을 설정하는 대신 Oracle Database의 다중 테넌트 기능을 활용하여 여러 연결 가능한 스키마로 단일 컨테이너 데이터베이스를 구현할 수 있습니다. 이 접근 방식은 여러 데이터베이스 클러스터를 설정하는 프로세스를 간소화하는 동시에 데이터베이스의 분리 기능을 유지하여 애플리케이션 스키마를 재설계할 필요가 없습니다. Oracle의 가상 머신 및 베어메탈 서비스형 데이터베이스는 기본적으로 다중 테넌시를 지원합니다. 게다가 집약적인 워크로드에 사용 가능한 Autonomous Dedicated Database 기능도 제공합니다.

이러한 중간 접근 방식은 데이터 계층뿐만 아니라 다른 계층에서도 구현할 수 있습니다. 애플리케이션이 컨테이너화된 경우에는 Oracle의 Container Engine for Kubernetes(OKE)를 활용하여 여러 고객 컨테이너를 단일 인프라에 배포할 수 있습니다. 그 다음에는 네임스페이스, 역할 기반 액세스 제어(RBAC), 비밀, 리소스 할당량과 같은 Kubernetes의 내장 기능을 활용하여 테넌트 간 분리를 유지합니다. 데이터베이스와 마찬가지로 테넌트를 인식하도록 애플리케이션을 다시 작성하는 대신 단순히 기본 클라우드 서비스의 기능을 활용할 수 있습니다.

ISV가 Oracle Cloud를 선택하는 이유 알아보기

ISV는 OCI의 광범위한 서비스와 지원을 통해 고객에게 더 나은 가치를 제공합니다.

자세히 알아보기

공통 우려 사항

아마도 귀사가 하이퍼스케일 클라우드 제공업체의 고유한 기능을 활용하여 단일 테넌트 SaaS 인프라를 구축하는 BitC 형태의 ISV일 수도 있습니다. 온프레미스에서 시작하여 다중 테넌트 SaaS 애플리케이션을 클라우드로 전환하는 경우일 수도 있습니다. 또는 비즈니스에 이러한 접근 방식이 혼합되어 있을 수도 있습니다. 어떤 경로를 선택했든 클라우드에서 운영되는 모든 ISV는 보안, 관측 가능성, 비즈니스 연속성, 자동화와 같은 필수적인 공통 우려 사항을 고려해야 합니다. 다음 섹션에서는 이러한 기능적 문제를 해결하고 경쟁사와 차별화하기 위한 Oracle의 포지셔닝을 검토합니다.

  • 보안, 거버넌스 및 규정 준수

    Oracle에서 보안은 기본적으로 "항상" 활성화되어 있어야 하고, 이해하기 쉽고, 구현하기 쉬워야 합니다. 고객이 비용과 보안 사이에 타협할 필요가 없어야 합니다. Oracle은 시장 전반에서 대안 솔루션을 제공하는 파트너와 함께 무료 또는 최소한의 비용으로 모든 보안 관련 서비스를 제공하기 위해 노력하고 있습니다. 고객 환경에서 데이터 침해가 발생하는 이유는 취약성을 방지하는 도구가 없기 때문이 아니라 이러한 도구를 조직에서 효과적으로 활용하기에 비용이 너무 많이 들거나 복잡하기 때문입니다.

    Oracle에서 보안은 클라우드 제공업체와 ISV가 함께 공유해야 할 책임입니다. Oracle은 격리된 네트워크 가상화 및 하드웨어 신뢰 기반 구축과 같은 필수 기능을 제공합니다. 또한 ISV가 보안 조치를 사용자정의하는 데 사용할 수 있는 도구와 서비스를 제공합니다. Oracle 보안 제품 개요를 확인하고 싶은 ISV는 보안 시작 페이지 및 클라우드 보안 아키텍처 검토로 시작해야 합니다.

    핵심 보안은 직관적인 정책 프레임워크와 역할 기반 액세스 제어를 통합하는 강력한 ID 및 액세스 관리(IAM) 구현으로 시작됩니다. 이 기능에는 사용자, 그룹, ID 페더레이션, 인스턴스/리소스 주체 권한 부여 등의 다양한 주제가 포함됩니다. IAM의 일부는 아니지만, 또 다른 필수 보안 개념은 네트워크 보안 규칙, 그룹, 목록을 활용한 사용자정의 네트워킹과 관련이 있습니다.

    OCI(Oracle Cloud Infrastructure)에서 보안 기술 아키텍처 개발을 시작할 때 권장되는 출발점은 공급업체 전반에 적용 가능한 보안 모범 사례를 수집하는 조직인 CIS(Center for Internet Security)입니다. CIS는 OCI 애플리케이션에 대한 보안 벤치마크를 개발했으며, Oracle은 Terraform을 통해 ISV의 CIS 권장사항 구현을 도와주는 자동화 도구를 개발했습니다.

    OCI는 다음과 같은 다양한 기본 보안 서비스를 제공합니다.

    OCI 내에서 발전된 한 가지 고유한 기능은 OCI에서 보안 정책을 자동으로 구성하고 구현하는 최대 보안 영역입니다. 이 기능을 사용하면 보안 모범 사례에 따라 보안 조치를 선언적으로 적용하고 가장 중요한 리소스의 보안에 대해 대응적 방식이 아닌 사전적으로 접근할 수 있습니다.

    마지막으로 Cloud Guard에서 관리하는 OCI 환경 전체의 보안 상태와 Data Safe에서 처리하는 데이터베이스 워크로드에 대한 보안 상태를 보장하지 않고서는 보안 스토리가 완성되지 않습니다. 두 서비스 모두 OCI 고객에게 무료로 제공되며, 사전 정의된 보안 구성을 통해 또는 SIEM/SOC에 대한 데이터 전송을 통해 잘못 구성된 리소스 및 안전하지 않은 활동을 자동화된 방식으로 신속하게 파악하고 해결할 수 있도록 보장합니다.

  • 관측 가능성

    모든 조직은 운영 지원 및 이후 IT 계획을 목적으로 클라우드 자산 성능에 대한 통계를 수집할 수 있어야 합니다. 특히 ISV는 일반적으로 더 철저한 애플리케이션 성능 계측이 필요한 맞춤형 애플리케이션을 실행하기 때문에 보다 광범위한 기능이 필요합니다. 또한 ISV는 연중무휴 24시간 외부 소비자 기반의 클라우드 환경에서 워크로드를 실행하기 때문에 일반적인 백오피스 시스템보다 더 높은 수준의 가동 시간이 필수적입니다.

    기본 수준에서 OCI는 OCI에서 워크로드 성능에 대한 실시간 통계를 확보할 수 있는 모니터링 서비스를 제공하며, 건전성 및 성능에 대해 즉시 사용 가능한 측정항목을 제공합니다. 사용자가 이상 징후를 감지하고 대응하도록 경보를 구성할 수 있습니다. 이 서비스는 워크로드에서 생성된 로그 외에도 OCI 로그를 제공하는 핵심 로깅 서비스와 결합되어 있습니다. 앞서 언급한 서비스 중 하나로 식별된 조건 또는 문제는 Oracle의 알림 서비스로 처리할 수 있습니다. 이 서비스는 낮은 지연 시간과 고가용성의 게시-구독 시스템을 제공하여 서버리스 기능(자동 해결), 이메일 또는 메시지 전달 파트너(예: SMS, Slack, PagerDuty)에 경보를 보냅니다.

    Oracle은 기술 발전에 따라 로깅, 애플리케이션 성능, 데이터베이스 성능, 운영 부문에서 더 철저한 분석 기능을 지원하는 다양한 머신 러닝(ML) 기반 서비스를 제공합니다. 로깅 분석을 통해서는 모든 로그 데이터를 모니터링, 집계, 인덱스화 및 분석하고 ML을 사용하여 시각적인 방식으로 문제가 있는 클러스터와 이상 상황을 감지할 수 있습니다. 애플리케이션 성능 모니터링은 표준 호환(OpenTracing 및 OpenMetrics) 서비스로서, 많은 ISV가 제공하는 Kubernetes/Docker 환경에서 파생되는 마이크로서비스 원격 분석을 위한 고유 지원을 포함하여 맞춤형 애플리케이션에 대한 합성 모니터링, 분산 추적, 트랜잭션 실행 분석을 지원합니다. 데이터베이스 관리는 Oracle Database 플리트에 대한 모니터링 기능과 운영 통계 기능을 제공합니다. 관리자는 이를 통해 성능 문제를 발견하고, 소비를 예측하고, ML 분석을 통해 용량을 계획할 수 있습니다. 조직은 이러한 기능을 사용하여 데이터에 기반한 의사 결정을 통해 리소스 사용을 최적화하고, 서비스 중단을 사전에 방지하고, 성능을 향상할 수 있습니다.

    이러한 모든 관측 가능성 기능은 OCI에서 통합 서비스로 제공되며, 넉넉한 "무료 계층"을 포함합니다. 이를 통해 ISV는 제한된 시나리오에서 서비스를 사용한 후 초기 성공을 기반으로 사용량을 확장할 수 있습니다.

  • 비즈니스 연속성

    ISV의 비즈니스 연속성 요구는 일반적인 ISV 조직보다 더 까다로운 경우가 많습니다. 인적 자본 관리(HCM) 또는 전사적 자원 관리(ERP) 시스템과 같은 전통적인 백오피스 시스템의 다운타임이 문제가 될 수 있지만, 대부분의 ISV는 비즈니스 운영에 필수적인 고객 대면 시스템에 있어서 일시적인 중단도 용납할 수 없습니다. 이를 위해서는 고가용성(HA) 및 재해 복구(DR)와 같은 개념이 매우 중요하며 ISV는 이러한 영역에서 OCI가 제공하는 기능을 가능한 최대 범위까지 활용할 수 있어야 합니다.

    고가용성

    OCI 지역은 하나 이상의 가용성 도메인으로 구성된 지역화된 지리적 영역이며, 각 영역은 세 가지 장애 도메인으로 구성되어 있습니다. 고가용성은 가용성 도메인 내에서 장애 도메인의 중복성으로 보장됩니다.

    가용성 도메인은 지역 내에 있는 하나 이상의 데이터 센터를 의미합니다. 가용성 도메인은 서로 격리되고 내결함성이 있으며 동시에 실패할 가능성이 낮습니다. 가용성 도메인은 전원 또는 냉각과 같은 물리적 인프라 또는 내부 가용성 도메인 네트워크를 공유하지 않으므로 하나의 가용성 도메인에 영향을 주는 장애가 다른 도메인의 가용성에 영향을 줄 가능성이 거의 없습니다.

    장애 도메인은 가용성 도메인 내의 하드웨어 및 인프라 그룹을 의미합니다. 각 가용성 도메인에는 3개의 장애 도메인이 포함됩니다. 장애 도메인을 사용하면 단일 가용성 도메인 내의 개별 물리적 하드웨어 단위로 인스턴스를 분산할 수 있습니다. 따라서 예상치 않은 하드웨어 장애 또는 컴퓨팅 하드웨어 유지 관리로 인해 하나의 장애 도메인에 영향을 주더라도 다른 장애 도메인의 인스턴스에는 영향을 주지 않습니다.

    영역의 모든 가용성 도메인은 지연 시간이 낮은 고가용성 네트워크를 통해 서로 연결되어 있습니다. 가용성 도메인 사이에 이러한 예측 가능하고 암호화된 상호 연결을 통해 고가용성 및 재해 복구를 위한 기초를 형성할 수 있습니다.

    보호하려는 장애 등급에 따라 여러 지역, 여러 가용성 도메인, 여러 장애 도메인에 걸쳐서 솔루션을 설계할 수 있습니다.

    또한 OCI에서 제공하는 많은 기능 및 옵션을 통해 지역화된 장애로부터 네트워크 리소스, 스토리지 시스템, 데이터베이스 리소스를 보호할 수 있습니다. 시작하기에 좋은 출발점은 OCI 아키텍처 센터의 고가용성 솔루션 플레이북을 자세히 읽고 운영 모델에 적합한 옵션을 선택하는 것입니다.

    재해 복구

    재해는 네트워크 중단부터 장비 장애 또는 자연 재해까지 애플리케이션을 위험에 빠트리는 모든 이벤트가 될 수 있습니다. 잘 설계된 재해 복구(DR) 계획이 있으면 재해로부터 신속하게 복구하고 사용자에게 서비스를 지속적으로 제공할 수 있습니다. OCI의 DR 기능은 이전 섹션에서 논의한 광범위한 HA 기능을 기반으로 구축되어 있습니다.

    DR 전략을 고려할 때는 먼저 복구 시간 목표(RTO)와 복구 지점 목표(RPO)를 고려해야 합니다. RTO는 재해 발생 후 해당 애플리케이션을 복원해야 하는 목표 시간을 의미합니다. 일반적으로 애플리케이션의 중요도가 높을수록 RTO가 낮습니다. RPO는 재해 발생 시점부터 재해가 비즈니스에 영향을 주기 전까지 애플리케이션이 데이터 손실을 용인할 수 있는 기간을 의미합니다.

    그 다음에는 설계하려는 재해 시나리오의 유형을 결정해야 합니다. 애플리케이션 장애, 네트워크 장애, 데이터 센터 장애, 지역 서비스 중단 또는 이 모든 항목과 같이 보호하려는 대상이 무엇인지 결정해야 합니다. RTO/RPO 결정과 함께 보호하려는 대상이 무엇인지에 따라 DR 전략을 추진해야 합니다.

    OCI는 컴퓨팅, 네트워크, 스토리지, 애플리케이션, 데이터베이스 수준에서 재해 내결함성 아키텍처를 구축할 수 있도록 도와줍니다. 이러한 도구를 사용해서 다양한 유형의 복원력이 있는 아키텍처를 구축할 수 있습니다. 예를 들어 앱이 두 지역에서 동시에 작동하는 활성-활성 아키텍처를 구성하면 한 지역에 장애가 발생하더라도 이를 다른 지역에서 처리할 수 있습니다. 웜 백업 시나리오에서는 기본 지역에 장애가 발생하더라도 보조 지역을 기본 지역으로 전환해서 트래픽을 인수할 수 있습니다. 콜드 백업 시나리오에서는 수동 및/또는 자동 단계를 혼합하여 비즈니스 운영을 복원하거나 하이브리드 조합을 지원할 수 있습니다.

    시작하기에 좋은 출발점은 OCI 아키텍처 센터의 재해 복구 솔루션 플레이북을 읽고 운영 모델에 적합한 옵션을 선택하는 것입니다.

  • 예산 및 할당량

    격리를 위해 OCI 컴파트먼트를 활용하여 SaaS 애플리케이션을 실행하는 ISV는 리소스 관리를 최적화하기 위해 몇 가지 관련된 도구를 고려할 수 있습니다. 각 OCI 테넌시는 일반적으로 연간 달러 한도가 미리 구성되어 있습니다. 이 한도를 초과한다고 해서 패널티가 발생하지는 않지만 대부분의 ISV가 리소스 사용량을 면밀히 관리하기를 선호합니다.

    ISV는 먼저 테넌시의 다양한 컴파트먼트에 걸쳐서 테넌시 전체 리소스를 분배하기 위한 도구로 컴파트먼트 할당량을 활용하는 방법을 고려하는 것이 좋습니다. 이 기능을 사용하면 CPU 및 스토리지 블록과 같은 공통 리소스 또는 GPU 및 Exadata와 같은 전문 리소스를 서로 다른 컴파트먼트에 할당할 수 있습니다. 이렇게 하면 테넌트 간에 리소스 분배가 공정하게 이뤄지고 적절한 위치에 전문 리소스가 할당되도록 보장할 수 있습니다.

    할당량은 클라우드 리소스 사용을 통제합니다. ISV는 예산 배분을 관리할 때 OCI 예산을 살펴봐야 합니다. 이 기능을 사용하면 각 컴파트먼트의 사용 예산을 설정하고 예산이 미리 정의된 임계값에 가까워지거나 초과되었을 때 알림을 받을 수 있습니다. ISV는 이 기능으로 여러 고객 간의 지출을 관리하고 이후 리소스 증가 요구를 예측할 수 있습니다.

    비용 추적

    ISV마다 SaaS 서비스 가격을 다르게 책정하지만, 일반적으로 많은 가격 책정 모델에서 COGS(매출원가)라는 개념이 고려됩니다. 공정한 가격 결정과 다양한 소비자의 가격 조정을 위해서는 제품을 생산하고 제공하는 데 드는 비용을 이해하는 것이 매우 중요합니다.

    SaaS 서비스에 엔지니어링 및 마케팅과 같은 비용을 포함한 많은 가격 책정 항목이 포함되지만 한 가지 중요한 구성요소는 클라우드 호스팅 비용입니다. 이 영역에서는 OCI 비용 분석이 도움이 될 수 있습니다. 이를 사용하면 고객 테넌트 간의 사용량을 동적으로 시각화하여 컴파트먼트 및/또는 비용 추적 태그에 따라 세분화할 수 있습니다. 이러한 도구를 사용하면 각 고객과 관련된 호스팅 비용을 이해하는 데 도움이 될 수 있으며, 고객에게 제공하는 가격에 대한 조정이 필요한지 여부를 결정하는 데 도움이 될 수 있습니다.

    시각화로 제공되는 것보다 더 자세한 데이터가 필요하면 이후에 선택한 도구로 분석할 수 있도록 기계가 판독할 수 있는 형식으로 완전히 세분화된 사용량 데이터를 익스포트할 수 있습니다. 또한 하이브리드 클라우드 환경에서 운영할 때는 CloudHealth와 같은 다중 클라우드 타사 도구를 자유롭게 사용하여 통합 분석을 수행할 수 있습니다.

  • 인프라 자동화

    환경을 수동으로 구축하는 조직은 소수에 불과합니다. 특히 ISV는 Terraform, Ansible, Puppet 등의 코드형 인프라(IaC) 도구를 사용하여 인프라 조정 및 구성 관리를 수행하는 것이 얼마나 중요한지 잘 알고 있습니다. IaC는 조직 규모나 기술 기반 또는 배포 접근 방식에 관계없이 모든 조직에 유리하지만, 지역 및 설치 기반에서 지속적으로 입지를 확대하고 있는 성장 중인 ISV에 있어서 특히 중요합니다. 자동화하지 않으면 처리해야 할 유지 관리 작업이 크게 증가하고 관리하기 어려워집니다.

    OCI는 특정 클라우드에 영향을 받지 않고 자동화 전략을 구현할 수 있도록 다양한 업계 표준 자동화 도구를 지원합니다. 여기에는 HashiCorp Terraform, Ansible, Chef에 대한 표준화된 지원이 포함됩니다. OCI는 모든 기능을 SDK 및 CLI를 통해 제공하기 때문에 Puppet과 같은 여러 다른 도구와 쉽게 통합할 수 있습니다.

    또한 OCI는 리소스 관리자라는 관리 서비스로 Terraform 기능을 확장합니다. OCI 고객에게 무료로 제공되는 이 서비스를 통해 OCI 정책 기반 보안 모델 범위 내에서 Terraform을 운영할 수 있습니다. 이 서비스는 자동 상태 관리, 템플리트 작성, 리소스 검색, GitHub/GitLab 통합을 지원합니다.

  • 소프트웨어 수명 주기 자동화

    ISV는 소프트웨어 개발 수명 주기의 여러 단계를 거쳐 코드를 구축하고 배포하기 위해 자동화된 도구를 사용합니다. 단일 테넌트 제공 모델을 고려할 때는 수백 개의 테넌트 인스턴스에 단일 배포를 전달해야 할 수도 있기 때문에 강력한 자동화가 더욱 중요합니다. 또한 다운타임을 없애기 위해 이러한 배포를 연속적으로 수행해야 하는 경우가 많고, 개별 고객의 특정 브랜치 기반 사용자정의 문제를 처리할 수 있도록 충분히 유연하게 수행할 수 있어야 합니다.

    OCI는 시판 중인 업계 최고의 CI/CD 도구를 대부분 지원합니다. Jenkins, Jenkins-X, Spinnaker, TravisCI, GitHub Actions, CircleCI 또는 기타 유사한 도구 등 무엇을 사용하든 소프트웨어 생태계 내에서 자신이 선택한 도구를 OCI와 통합할 가능성이 있는 사용자를 찾을 수 있습니다.

    또한 OCI는 개발자를 위한 엔드 투 엔드 방식의 지속적 통합 및 지속적 전달(CI/CD) 플랫폼인 사용하기 쉬운 DevOps 서비스를 제공합니다. ISV는 이 서비스를 사용하여 OCI에서 소프트웨어를 쉽게 구축, 테스트, 배포할 수 있을 뿐만 아니라 호스팅된 프라이빗 Git 저장소로 소스 코드를 관리할 수 있습니다.

결론

Oracle은 모든 ISV가 기원, 소스 환경, 기술 아키텍처, 배포 모델, 비즈니스 및 기술 요구 사항 등고유한 배경을 가지고 있음을 인정합니다. Oracle Cloud Infrastructure(OCI)로 전환할 때 이러한 개별 요소를 고려하지 않고 OCI 기능을 활용할 때 고려할 수 있는 "모든 시나리오에 적합한 단일 솔루션"이란 존재하지 않습니다.

ISV의 마이그레이션을 돕기 위한 "세심한 접근 방식"의 일환으로 Oracle은 클라우드 솔루션 설계를 돕기 위해 협력하는 설계자, 비즈니스 컨설턴트, 전문 엔지니어가 포함된 참여 프로세스를 Oracle의 Cloud Lift Services와 결합합니다. 이러한 서비스는 귀사와의 긴밀한 협력을 통해 워크로드를 OCI로 마이그레이션하는 데 실질적인 도움을 줄 수 있습니다.

ISV 분야에서 Oracle은 전략, GTM(Go-to-Market), 아키텍처, 구현 측면에서 고객과 일대일로 협력한다는 고유한 의지와 열망을 갖고 있습니다. Oracle은 전문 지식 제공과 귀사와의 긴밀한 협업을 통해 귀사의 클라우드 요구를 종합적으로 충족시킬 수 있도록 보장합니다.

ISV가 Oracle Cloud를 선택하는 이유 알아보기