설계 원칙—모던 앱 개발

가능한 모든 경우 로코드 플랫폼 사용, 그렇지 않은 경우에는 완성형 프로그래밍 언어 및 경량 프레임워크 사용

개요
 앱 구축을 위해 도입한 프로그래밍 언어와 프레임워크는 앱의 성공적인 제공 및 이후 유지 관리에 필수적인 역할을 합니다. 선택한 언어 및 프레임워크는 비즈니스 확장 방식, 앱 운영 방식, 고객에게 양질의 기능을 제공하는 방식에 장기간 영향을 미칩니다. 언어나 프레임워크에 대한 변경은 일반적으로 비용이 많이 듭니다. 여러 언어 및 프레임워크의 병렬 생태계를 지원하는 일은 복잡성을 더하고 민첩성을 떨어뜨릴 수 있습니다.

또한 선택한 언어 및 프레임워크는 기존 생태계의 전달 속도, 안정성, 파워, 운영 준비도, 생산 성능 등 다양한 요소에 영향을 미치죠. 가능한 모든 경우에 로코드 플랫폼을 사용하면 전통적인 개발 방식의 복잡성을 다루느라 분투하는 대신 비즈니스 문제 해결에만 집중할 수 있습니다. 앱의 요구 사양이 보다 복잡하다면 완성형 언어 및 경량 프레임워크를 선택하시면 됩니다.

세부 원리
로코드 플랫폼은 기존 수동 코딩 방식에 비해 더욱 빠른 속도로 엔터프라이즈 앱을 구축, 테스트, 배포할 수 있게 해줍니다. 로코드 플랫폼은 비즈니스 이해관계자들과 함께, 데이터 보고 및 분석 앱을 병용하여 새로운 기회를 포착하기 위한 앱을 구축하기에 적합합니다. 또한 로코드 플랫폼을 통해 SaaS 앱을 확장하고 레거시 앱을 현대화할 수 있습니다. 이와 같은 접근 방식은 신기능을 추가하는 과정에서 데이터 시각화, 데이터 수집, 데이터 분석, 보안, 접근성, 성능, 세계화 등과 관련된 복잡성을 피할 수 있게 해줍니다. 로코드 플랫폼은 이와 같은 복잡성은 물론 유지해야 하는 코드의 수도 극적으로 줄여줍니다.

그러나 앱에 보다 정교한 요구 사양이 필요한 경우 경량 프레임워크와 결합된 완성형 프로그래밍 언어를 선택하세요. 프로그래밍 언어 선택 시, 다음과 같은 혜택을 제공하는 언어를 선택하는 것이 좋습니다.

• 보안
• 고성능 및 효율성
• 툴링 지원
• 광범위한 최신 설명서
• 라이브러리 생태계
• 테스트 스위트 또는 참조 구현 준수
• 강력한 커뮤니티

새로운 언어일수록 언어 설계, 해당 생태계 및 라이브러리의 변화가 자주 발생합니다. 변화가 잦다는 건 위험을 평가하기가 더욱 어렵다는 것, 후속 변경의 적용 비용이 더욱 높아진다는 것을 의미합니다.

프레임워크 선택 시 오픈 소스 방식의 프레임워크를 선택할 것을 추천합니다. 오픈 소스 프레임워크는 지속적인 피어 리뷰의 대상이 되기 때문에 대부분의 개발자가 원하는 것과 가장 가까운 기능들을 갖추고 있을 가능성이 높습니다. 개발자들이 해당 프레임워크의 생성 및 유지 관리에 기여하니까요. 버그도 빠르게 발견되고 수정됩니다. 또한 CPU, 메모리, 네트워크 대역폭, 파일 처리 등 리소스의 소비량이 적은 경량 프레임워크를 선택하는 게 좋습니다.

작업 집중도 개선 효과(보일러플레이트 또는 스캐폴딩보다 비즈니스 로직에 집중)와 유연성(현재 및 미래의 기능 니즈를 지원할 수 있게 해줌)을 균형있게 제공하는 앱 프레임워크를 사용하세요. 로깅, 원격 측정, 보안, 구성, 공통 패턴(예: REST API 구축) 등 공통 기능에 대한 사용이 손쉽고, 실용적이며, 논란의 여지가 적은 기본값을 제공하는 프레임워크를 도입하는 게 좋습니다.

Oracle 권장 사항
Oracle APEX는 양식, 차트, UI 위젯 등 하이 레벨 구성 요소를 제공하는 로코드 플랫폼입니다. APEX는 또한 직관적인 그래픽 개발 환경을 통해 일반 설계 패턴을 제공합니다. APEX를 사용해 개발한 앱들은 SQL을 통해 로컬 데이터에 액세스할 수 있고, REST API를 통해 외부 서비스와 통합될 수 있습니다. APEX에서 개발한 기능을 REST API로 게시해 외부에서 사용할 수도 있죠.

앱에 로코드 플랫폼이 적합하지 않은 경우 Java를 프로그래밍 언어로 채택하시면 됩니다. Java는 가장 일반적인 앱 사용 사례를 위해 안정적이고 방대한 일련의 기능을 제공하며, 현대적 앱 개발을 위한 신뢰할 수 있고 안정적인 라이브러리와 프레임워크의 건강한 에코시스템을 보유하고 있습니다. Java는 정적 분석 툴과 테스트 프레임워크를 포함한 개발자 툴, 테스트 프레임워크 등을 위한 탁월한 지원과 함께 단순성 및 읽기 용이성에 중점을 두며 운영 앱의 버그 위험을 줄여 줍니다.

GraalVM를 사용해 앱을 개발 및 실행할 수 있습니다. GraalVM은 동적 런타임 최적화, 보안 취약성에 대한 빈번하고 사전 예방적인 패치 적용, Java Flight Recorder 및 기타 저비용 성능 분석 및 진단 도구 등을 활용한 동급 최강의 성능을 Java의 안정성과 결합한 JDK 배포판입니다.

Graal Development Kit for Micronaut 또는 Helidon 프레임워크를 사용하여 API 우선 접근법으로 앱을 구축할 수 있습니다. 두 가지 접근법 모두 로깅, 원격 측정, 스토리지 등 공통 활동을 위한 단순하고 직관적인 프레임워크 집합을 기반으로, 앱 배포까지 걸리는 시간을 크게 줄여주는 스캐폴딩 및 REST API와 같은 공통 사용 사례를 위한 손쉬운 사용 패턴을 제공합니다. 또한 두 가지 접근법 모두 모두 관용적인 반응형 API를 갖춘 비동기 I/O(Nonblocking I/O) 지원을 통한 고성능 서비스, 그리고 고성능 네트워크 라이브러리 지원을 통한 낮은 지연 시간을 제공합니다.

• CDI, JAX-RS, JPA 등 엔터프라이즈 Java 생태계와 긴밀하게 연계된 앱에는 Helidon MicroProfile을 사용해 보세요. MicroProfile을 통한 모던 Java 엔터프라이즈 패턴용 Helidon의 표준 우선 지원은 마이크로서비스에 대한 기존 Java EE 앱의 포팅을 단순화해 줍니다.
• 기존 엔터프라이즈 Java 생태계에 의존하지 않는 앱의 경우 Graal Development Kit for Micronaut(GDK) 또는 Helidon SE 또는 Helidon SE를 사용할 수 있습니다. GCN의 컴파일 타임 애플리케이션 스캐폴딩을 사용하면 런타임 시 앱 성능을 높이고 프레임워크 수준으로 확인할 수 있습니다. 이렇게 하면 리플렉션 및 런타임 구성에 관한 다양한 보안 및 품질 관련 문제를 해결할 수 있습니다.

Helidon과 GCN 모두 GraalVM 네이티브 이미지용 빌트인 지원을 제공하므로, 메모리 효율적이고 컴팩트한 앱을 구축할 수 있습니다.

REST API를 통해 커뮤니케이션하는 서비스 제품군으로서의 앱 구축

개요
앱의 각 기능 또는 작업을 느슨하게 연동되어 함께 작동하는 독립적 서비스로 분할할 수 있습니다. 각 서비스가 하나의 기능 또는 능력에 중점을 둔 제한된 기능 범위를 가지도록 설계하세요. 이 접근 방식은 전통적인 모놀리식 아키텍처와 비교했을 때 앱 유지 관리, 기능 개발, 테스트, 배포, 확장성을 개선합니다.

계약 우선 REST API 설계 접근을 선택하면 서비스와의 커뮤니케이션 및 서비스 간 커뮤니케이션을 위한 명확하고 이해하기 쉬운 인터페이스를 제공할 수 있습니다. API 계약은 서비스 구현에 관한 내부 세부 정보에 의존하지 않고도 팀의 협업과 기능 활용을 가능하게 하는 매커니즘을 제공합니다. 예를 들어 서비스는 개발 팀이 완전히 소유할 수 있으며, 개발 팀은 타 개발 팀과 코드 종속성을 조율할 필요 없이, 구현 시 서비스를 자유롭게 개선할 수 있습니다.

세부 원칙
서비스의 REST API를 특정함으로써 계약 우선 접근을 시작할 수 있습니다. 그다음 API 구현을 프로토타입화하여 해당 서비스를 실제로 사용할 팀 등 이해관계자들이 API를 체험해볼 수 있게 하세요. 모두가 API의 세부 내용에 동의하면 각각의 팀이 해당 서비스 및 이 서비스를 사용하는 타 서비스를 병렬 방식으로 구현할 수 있습니다.

제품 수명 주기 초기 단계에 보안 및 SLA(서비스 수준 계약)에 관한 정책 시행을 정의하여 모두가 서비스 계약의 모든 내용을 명확히 파악할 수 있게 해야 합니다.

API 사양을 코드처럼 취급하고 이를 소스 코드 및 정책 구성과 함께 버전 제어 시스템을 통해 관리하세요.

Oracle 권장 사항
하나의 구현물에 치우치지 않는(implementation-agnostic) 양식 OpenAPI를 사용해 API를 특정한 다음 이를 Oracle Cloud Infrastructure (OCI) DevOps가 제공한 저장소에 저장할 수 있습니다.

서비스를 Graal Development Kit for Micronaut 또는 Helidon과 같은 경량 오픈 소스 접근법을 통해 구현할 수 있습니다.

Oracle Container Engine for Kubernetes , Oracle Functions 등 서버리스 플랫폼에 서비스를 배포하여 손쉬운 배포, 확장성, 비용 효율성을 확보할 수 있습니다.

Oracle Cloud Infrastructure API Gateway를 사용하면 API 사양을 통해 보호 및 관리되는 전용 또는 공용 엔드포인트를 생성할 수 있습니다.

Oracle Cloud Infrastructure(OCI) Mesh를 통해 Oracle Container Engine for Kubernetes 클러스터에 호스트된 서비스 간 커뮤니케이션을 간소화 및 보호할 수 있습니다. OCI Service Mesh를 사용하면 애플리케이션 Pod에서 사이드카로 실행되는 프록시 구성 요소가 내보낸 측정 지표 및 로그를 통해 서비스 간 모든 네트워크 트래픽을 관찰할 수 있습니다.

앱을 컨테이너 형식으로 패키지화 및 배포

개요
컨테이너는 코드와 그 종속성을 하나의 단위로 패키지화합니다. 덕분에 앱이 여러 컴퓨팅 환경에서 신속하고 안정적으로 실행될 수 있죠. 컨테이너 이미지는 실행 시 컴퓨팅 환경에서 컨테이너를 생성 및 실행하는 파일입니다.

기존 가상 머신과 비교했을 때 컨테이너는 더 작고, 리소스가 더 적게 필요하며, 더욱 빠르게 실행됩니다. 또한 플랫폼으로부터 독립적이고, 어디서든 앱을 실행할 수 있죠. 이와 같은 이점을 누리기 위해서는 앱을 개별적인 비즈니스 기능을 수행하는 개별 서비스로 분해한 뒤, 각 서비스를 컨테이너로 패키지화하면 됩니다. 레거시 앱의 경우 전체 앱이 완전히 리팩터링될 때까지 앱 내의 각 기존 기능을 점진적으로 컨테이너화된 서비스로 대체하세요.

세부 원칙
애플리케이션 코드 및 종속성을 실행 가능한 단일 단위(컨테이너 이미지)로 패키지화한다는 것은 컨테이너의 이식성이 대단히 높아진다는 걸 의미합니다. 이 이식성을 인프라 추상화와 결합하면 컨테이너는 앱에 운영 일관성을 제공합니다. 물리 서버의 온프레미스 환경에서 실행 중이든, 가상 머신의 클라우드에서 실행 중이든, 앱이 매번 동일한 결과를 생성하죠.

이와 같은 일관적인 복제 가능성과 예측 가능성을 통해 컨테이너는 DevOps 프로세스를 단순화하고 개발 팀이 앱을 더욱 빠르게 배포할 수 있도록 지원합니다. 컨테이너는 프로세스 수준의 격리를 제공하고, 빈번하게 교체되기 때문에, 소프트웨어 취약성 완화와 관련된 프로세스를 단순화 및 가속화해 줍니다. 앱을 모듈식 컨테이너화 서비스로 분할하면 앱의 성능을 크게 높일 수 있습니다. 개별 서비스에 발생한 오류 또는 실패는 앱 전체의 가동 중단을 야기하지 않으며, 해당 서비스에 대해서는 앱의 나머지 부분과 무관하게 별도로 업데이트 또는 패치 적용을 할 수 있습니다.

가상 머신과 달리 컨테이너는 자체 운영체제를 갖추지 않습니다. 대신 호스트의 운영체제를 공유하죠. 그 결과 컨테이너는 가상 머신에 비해 더욱 작은 크기와 빠른 실행 속도를 제공할 수 있게 되었습니다. 몇 기가바이트까지 커질 수 있는 가상 머신에 비해 대부분의 컨테이너 이미지의 크기는 수십 메가바이트에 그치며, 가상 머신을 실행하는 데는 몇 분이 걸리지만 컨테이너 이미지 실행은 몇 초면 완료됩니다.

컨테이너에 모듈화된 서비스로 구성된 앱을 실행 및 확장하기 위한 최고의 방식은 컨테이너당 하나의 서비스를 배포하는 것입니다. 이 접근 방식은 각 서비스를 서로 격리하기 때문에 다운타임이 사라지고 각 서비스의 독립적인 확장이 가능해 집니다.

컨테이너를 수동 방식으로 배포할 수도 있지만, 지속적인 통합 및 지속적인 배포 도구와 통합되는 컨테이너 관리 소프트웨어를 사용하는 게 더 효율적입니다.

Oracle 권장 사항
Oracle Cloud Infrastructure Registry(Container Registry)를 사용해 컨테이너 이미지를 저장하고 Oracle Cloud Infrastructure Container Engine for Kubernetes(OKE)를 사용해 컨테이너를 실행 및 관리할 것을 권장합니다. 이 모든 관리형 서비스는 다양한 OCI 플랫폼 기능과 완벽하게 통합되고, 모든 Oracle Cloud 리전에서 사용할 수 있고, PCI, ISO, SOC, HIPAA, FedRAMP등의 규제 표준을 준수합니다.

Container Registry에 컨테이너 이미지를 저장할 수 있는 것 외에도, 매니페스트 목록을(멀티 아키텍처 이미지라고도 부름) 저장하여 ARM, AMD64 등 다양한 아키텍처를 지원할 수 있습니다. 잠재적인 보안 취약성을 식별하고 이를 완화하기 위해 Container Registry에 업로드된 모든 이미지에 대한 이미지 스캐닝을 활성화해 두세요. 또한 컨테이너 이미지에 서명하여 권한이 있는 신뢰할 수 있는 이미지만이 OKE에 배포될 수 있게 해야 합니다.

구축, 테스트, 배포 자동화

개요
지속 통합(CI) 및 지속 배포(CD)는 도구 세트이자 개발 팀이 잦은 코드 변경을 안정적으로 실행하기 위해 사용하는 절차입니다. CI/CD 모범 사례에는 코드 리뷰 및 단위 테스트, 통합 테스트, 코드 체크인, 티켓 제출, 개발 및 테스트 환경을 위한 애플리케이션 배포를 위한 가이드가 포함됩니다.

지속 통합은 개발자가 공유 저장소의 주 분기에 빈번하게 코드 변경을 통합하는 사례를 설명합니다. 개발자의 변경 사항은 빌드를 생성한 뒤 해당 빌드에 대한 자동화된 테스트를 실행하는 방식으로 검증됩니다. 새로운 변경 사항이 주 분기에 통합될 때마다 앱이 손상되지 않았음을 테스트를 통해 검증할 수 있습니다.

지속 통합의 이점은 다음과 같습니다:

• 자동화된 테스트가 회귀 실패를 조기에 식별하기 때문에 프러덕션 단계로 침투하는 버그 수를 줄일 수 있음
• 통합 관련 문제를 초기에 해결할 수 있기 때문에 구축 프로세스가 손쉬워짐
• 오류가 보다 빠르고 쉽게 감지 및 발견됨(일반적으로 각 변경 내용이 사소하기 때문에)

지속 전달은 지속 통합 이후의 단계입니다. 적절한 테스트를 거친 빌드는 테스트 및/또는 프러덕션 환경으로 자동으로 전달됩니다. 지속 전달의 목표는 코드베이스가 언제든 고객 프러덕션 환경으로 배포될 수 있도록 준비하는 것입니다.

지속 전달의 추가 이점은 다음과 같습니다:

• 복잡한 배포 과정이 자동화된다는 것은 개발 팀이 릴리스 준비에 소비하는 시간이 줄어든다는 것을 의미함
• 보다 빈번한 릴리스가 고객 피드백 루프를 가속화함
• 사소한 변경 적용 시 의사결정 부담이 줄어들기 때문에 반복 속도가 향상됨

지속 배포는 지속 전달의 다음 단계로 모든 테스트를 통과한 모든 변경 사항이 고객의 프러덕션 환경에 자동으로 배포됩니다. 이때 인적 개입은 일어나지 않습니다. 테스트 실패만이 변경 사항의 프러덕션 환경 배포를 중지할 수 있습니다. 인적 개입이 없는 지속 배포는 효과적으로 설계된 테스트 자동화에 크게 의존합니다.

지속 배포의 추가 이점은 다음과 같습니다:

• 릴리스를 위한 일시 중단 과정이 필요하지 않기 때문에 개발 속도가 높아짐
• 향상된 품질 및 지속적인 개선 덕분에 고객 만족도가 높아짐

CI/CD는 코드의 저장, 통합, 배포, 유지 관리를 위한 모범 사례를 제공해 앱 구축 방식을 자동화해 줍니다. 모범 사례에는 다음이 포함됩니다:

• Shift left 접근을 적용해 소프트웨어 개발 수명 주기(SDLC) 내 문제를 가능한 한 빨리 감지하고 예방하는 데 주력합니다. 예를 들어 통합 중 앱의 서드파티 종속성에 대한 취약성을 모니터링합니다.
• Git 기반 코드 저장소를 사용하여 모든 코드 자산을 저장하고, 변경할 수 없는 아티팩트 서비스를 사용하여 생성된 자산을 저장합니다.
• 지속적인 통합을 구현하려면 모든 코드를 하루에 한 번 이상 "릴리즈 후보" 분기로 병합합니다. 코드를 해당 분기로 병합할 때 빌드가 자동으로 트리거되는지 확인합니다. 빌드 파이프라인의 일환으로 모든 단위 테스트를 실행하고, 릴리스 후보 분기에 대한 추가 개발을 진행하기 전에 파이프라인 실패가 발생하는 즉시 이를 수정합니다. 코드에서 보안 스캔을 사용해 취약성을 감지합니다. 취약성 문제를 보유한 아티팩트는 저장하지 마세요. 개발을 진행하기에 앞서 릴리스 후보 분기의 모든 취약성을 수정해야 합니다.
• 지속 배포를 구현하려면 릴리스 후보를 테스트 환경에 자동으로 배포하거나 카나리 배포를 사용해야 합니다. 테스트 배치가 통과되면 자동으로 전체 프로덕션으로 승격됩니다. 테스트 배포가 실패한 경우 릴리스 후보 분기에 대한 추가 개발을 진행하기 전에 즉시 문제를 해결해야 합니다. 보안 기능을 배치의 일부로 사용하여 권한 없는 아티팩트와 취약한 아티팩트가 기반 구조에 배포되지 않도록 합니다.
• 운용 환경에서 모니터링 툴을 사용하여 배치된 앱의 상태를 평가하고 배치 후 취약점을 감지합니다. 문제가 발견되면 이전 버전으로 자동 롤백을 구현합니다. 배포 이후의 환경에서 보안 검사를 수행하고, 문제 감지 시 이를 즉시 해결해야 합니다.

Oracle 권장 사항
DevOps 서비스를 사용해 클라우드 네이티브 앱의 배포를 자동화하는 게 좋습니다. 먼저 코드를 DevOps 코드 저장소에 저장하고 릴리스 분기를 생성합니다. 릴리스 분기에 변경을 적용하기 위해서는 소규모 단위로 작업하고, 안정성 확보를 위해 분기와 관련된 문제를 매일 조정해야 합니다. 그다음 코드 저장소의 트리거 기능을 사용해 DevOps 빌드 파이프라인을 자동으로 실행합니다.

단일한 DevOps 빌드 파이프라인을 사용해 코드 저장소와 관련된 모든 아티팩트를 구축할 수 있습니다. 빌드가 실패하면 완료되기 전에 승인을 기다리도록 빌드 파이프라인을 구성합니다. 승인 요청은 빌드를 트리거한 커밋자로 이동해야 하며 새 코드 커밋으로 문제를 해결한 다음 빌드 완료를 승인해야 합니다. 성공적인 구축을 위해 빌드 파이프라인이 아티팩트를 Oracle Cloud Infrastructure Artifacts Registry 서비스로 자동으로 전달하고, DevOps 배포 파이프라인을 자동으로 트리거하도록 구성하세요.

Application Dependency Management를 추가해 OCI DevOps 구축 파이프라인의 구축 단계에서 애플리케이션 종속성의 보안 취약성(CVE)을 감지합니다. 이 방식으로 잠재적인 CVE를 가능한 한 빠르게 감지 및 해결할 수 있습니다.

Resource Manager를 사용해 모든 인프라 환경을 최대 보안 영역에 생성하면 배포 보안의 혜택을 자동으로 누릴 수 있습니다. Resource Manager를 사용하면 IaC(Infrastructure as Code)를 사용하여 모든 지역에서 일관된 방식으로 인프라를 생성할 수 있습니다. 그다음 DevOps 배포 파이프라인이 항상 보안 영역에 생성한 리소스에만 배포되도록 구성하세요.

단일 빌드 파이프라인에서 생성된 모든 아티팩트를 배치하는 단일 DevOps 배치 파이프라인을 생성합니다. OCI 리전, 가용성 도메인, 장애 도매인 등 배포 환경을 구성하세요. 카나리, 롤링 또는 블루 그린 배포 전략으로 파이프라인을 구성하세요. 트리거 테스트가 자동으로 이루어지도록 구성해야 합니다. 애플리케이션 및 인프라의 OCI Monitoring 및 Application Performance Monitoring을 활성화해 문제를 감지할 수 있습니다.

아무런 문제도 감지되지 않고 테스트가 성공적으로 완료되면, 아티팩트가 배포 전략의 다음 환경에 자동으로 배포되도록 배포 파이프라인을 구성하세요. 해당 과정은 아티팩트가 모든 프러덕션 환경에 배포되어야 끝납니다. 아티팩트를 프러덕션 환경에 배포할 때는, 아티팩트가 가용성 도메인 내 모든 장애 도메인에 한 번에 하나씩 배포되도록 파이프라인을 구성하세요. 하나의 리전 내 각 가용성 도메인마다 한 번에 하나씩 배포한 다음, 각 리전마다 한 번에 하나씩 배포합니다. 애플리케이션 및 인프라에서 OCI Monitoring 및 Application Performance Monitoring을 계속 사용하여 문제를 빠르게 감지합니다. 경보를 설정하고 배포 중 주요 측정항목이 갑자기 떨어지면 자동으로 배치를 실패하고 이전 버전으로 롤백이 트리거됩니다.

관리형 서비스 활용으로 앱 개발 및 운영의 복잡성 제거

개요
관리형 서비스는 사용자가 성능, 가용성, 확장성, 보안성, 업그레이드 최적화와 관련된 별도의 유지 관리 작업 없이도 특정 기능을 활용할 수 있게 해줍니다. 관리형 서비스를 활용하면 운영의 복잡성 걱정 없이 고객에게 다양한 기능을 제공하는 데만 집중할 수 있게 됩니다.

관리형 Oracle Cloud Infrastructure(OCI) 서비스는 클라우드 전용 배포를 위한, 확장 가능하고 보안성이 뛰어난 구성 요소들을 제공합니다. 앱 개발 및 실행과 앱 데이터 저장에 관리형 서비스를 활용하면, 앱 개발 및 운영 시 각 도메인에 대한 전문성 없이도 동급 최강의 솔루션을 사용할 수 있습니다.

세부 원칙
관리형 서비스는 보안성, 규정 준수, 탄력성을 갖춘 고가용성, 확장성, 민첩성, 고성능 애플리케이션을 생성할 수 있게 해줍니다.

관리형 서비스는 앱의 기본 구성 요소에 내재된 복잡성을 추상화하여 데이터를 손쉽게 저장 및 검색하고, 앱을 손쉽게 생성 및 실행할 수 있게 해주죠. 이 서비스는 자동화 앱 구축, 테스트, 배포 기능을 제공하는 도구 세트와 통합됩니다. 관리형 서비스는 생산성을 높이고, 제품의 시장 출시 기간을 단축해 줍니다.

관리형 서비스는 다양한 인프라 관리 작업을 중앙 집중화 및 자동화함으로써 인적 오류 및 전문적인 스킬의 필요성을 제거합니다. 기본 인프라는 늘 최신 상태로 안전하게 유지되며, 관리형 서비스 덕분에 앱에 대한 수정 또는 액세스를 모니터링 및 추적할 수 있습니다. 그 결과 앱 및 데이터의 기밀성 및 무결성이 보장되죠.

고도의 가용성과 확장성을 자랑하는 관리형 서비스는 앱의 니즈를 충족하고, 사용한 만큼에 대해서만 비용을 청구합니다. 소규모로 시작해 성능 또는 안정성의 저하 없이 확장할 수 있습니다.

Oracle 권장 사항
다음의 클라우드 서비스 사용을 권장합니다:

• Oracle Autonomous Database는 데이터 웨어하우징 또는 트랜잭션 처리를 위한 데이터를 관리합니다. Autonomous Database는 자율적인 관리 오버헤드 감소를 위해 인메모리, NoSQL 및 SQL 데이터베이스를 제공합니다.
• Oracle Cloud Infrastructure Container Engine for Kubernetes를 사용해 컨테이너를 생성, 실행, 관리할 수 있습니다.
• Oracle Functions를 사용하면 단기간 구동되는 앱을 안전하고 고립된 상태에서 인프라 관리 없이 생성, 실행, 확장할 수 있습니다.
• Oracle API Gateway는 API 사양에서 보호 및 관리되는 전용 또는 공용 엔드포인트를 생성할 수 있습니다.
• Oracle Cloud Infrastructure Object Storage는 콘텐츠 종류와 상관없이 모든 비정형 데이터를 무제한으로 안전하게 저장 또는 검색할 수 있게 해줍니다. 성능 또는 서비스 안정성의 저하 없이 매끄러운 확장이 가능합니다.
• Oracle Cloud Observability and Management Platform 서비스는 상기의 모든 서비스와의 통합을 거쳐 로그, 측정 지표, 이벤트에 가시성을 부여합니다.
• Oracle Application Express(APEX)는 로코드, 모던, 데이터 중심 애플리케이션의 신속한 구축에 사용됩니다. APEX는 가용성과 확장성 극대화를 통해 로코드 앱의 급변하는 요구 사항을 처리할 수 있습니다. 자동화된 관리, 일관적인 고성능, 자동 확장, 손쉬운 관리 기능을 제공합니다.

이 서비스들은 고도의 가용성, 고성능, 탄력성을 자랑합니다. 각 서비스의 기본 인프라는 사용자 앱의 보안을 보장하기 위해 관리 및 패치 적용됩니다.

앱의 무상태 계층 유지

개요
앱의 상태는 데이터 캐시, 사용자 환경설정, 개인화, 서비스 간 교환된 메시지, 다중 단계 워크플로에서의 포지션, 앱 배포, 런타임 구성, 사용자의 세션(예: 사용자가 마지막으로 방문한 페이지 또는 사용자의 장바구니 크기 및 장바구니에 담긴 물건) 등  다양한 요소로 구성됩니다. 앱의 상태가 손실되면, 이는 데이터의 손실, 앱의 기능 오류, 최적화되지 않은 사용자 경험, 심지어 영구적인 앱 손상으로 이어질 수 있습니다.

앱의 상태를 로컬 파일 시스템 또는 단일 호스트의 메모리에 저장하면 앱 중단이 발생하는 경우(예: 재시작 또는 로컬 디스크 실패) 앱 상태가 손실될 수 있습니다. 그래서 앱 상태를 외부 영구 저장소에 저장하는 게 좋습니다. 영구 저장소의 개수는 적을수록 좋습니다. 데이터 일관성을 위해 하나의 영구 저장소를 사용하는 것이 가장 이상적입니다.

세부 원칙
앱 상태의 요소는 기본적으로 다양한 포맷의 여러 아티팩트로 저장됩니다(예: 직렬화된 객체, JSON, XML 문서, 텍스트 파일 등). 만일 각 요소가 외부 파일 시스템, 메시지 저장소, 객체 저장소, 여러 데이터베이스, 탄력적 블록 스토리지 등 여러 영구 저장소에 저장되면 다양한 데이터 저장소 간에 동기화가 무너지고 데이터는 불일치 상태(state inconsistencies)가 됩니다. 또한 앱이 트랜잭션, 조인, 멱등성(idempotency)을 구현해야 상태를 하나의 단위로 업데이트해야할 경우 데이터 일관성을 유지할 수 있습니다.

앱 상태의 각 요소를 여러 저장소에 분산하면 보안 취약성이 발생할 가능성이 높아집니다. 노드 추가/제거, 패치 적용, 백업/복구 및 재해/복구를 위한 복제 등 수명 주기 작업은 매우 복잡하므로 여러 저장소에서 상태 일관성을 유지하기 위해 특별히 고려해야 합니다.

결론적으로, 가능한 경우라면 모든 앱 상태 및 데이터를 단일한 데이터베이스에 저장하는 것이 가장 효과적인 접근 방식입니다. 단일 저장소는 데이터 일관성 유지 및 손쉬운 관리에 유리합니다. 이 방식을 사용하면 앱 인스턴스 교체도 가능합니다. 이 방식은 특히 탄력적인 마이크로서비스 또는 인스턴스가 하나 또는 소수의 요청 사항만 처리하기 위해 존재하는 일시적 인스턴스 등 모던 앱 아키텍처에 유용합니다. 단일 노드를 추가하는 과정도 간소화됩니다. 하나의 노드가 상태에 대한 최신 사본을 얻게 되기 때문이죠. 또한 노드를 삭제한다 해도 상태가 완전히 손실되지 않습니다. 패치는 실행 파일을 교체하는 방식으로 순차적으로 적용할 수 있습니다. 노드는 백업 파일에서 복구할 수 있고, 데이터베이스에서 상태를 가져올 수 있습니다. 상태는 재해 복구를 위해 다양한 리전에 하나의 유닛으로 일관적으로 복제될 수 있습니다. 다양한 리전에 일관적인 상태를 보유하면 앱 실패 또는 스위치오버 이후에도 앱의 기능에는 어떠한 문제도 발생하지 않습니다.

Oracle 권장 사항
앱이 데이터베이스를 사용하는 경우 상태를 저장할 때도 동일한 데이터베이스를 사용하는 것이 좋습니다. 데이터베이스는 파일 또는 인메모리 표현 등 대체안에 비해 더 나은 가용성, 무결성, 보안성을 제공합니다. 다양한 포맷을 저장할 수 있는 멀티 모델 데이터베이스를 사용해 앱 상태의 모든 요소를 저장하는 것이 가장 이상적입니다. 단일 용도의 데이터 저장소 여러 개를 사용하는 것보다 멀티 모델 데이터베이스를 사용함으로써 앱 상태의 모든 요소 전반의 일관성을 손쉽게 달성 및 유지할 수 있습니다. (참고: 앱에서 캐시에 저장된 상태를 저장할 수는 있지만 앱은 데이터베이스를 신뢰성 있는 소스로 사용하도록 설계되어 데이터베이스에서 해당 상태를 재생성할 수 있어야 합니다.) Oracle Database가 특히 이 부분에서 이상적입니다. Oracle Database는 다양한 포맷의 데이터를 저장하고, 예측 가능한 성능을 제공합니다. 따라서 앱 상태를 저장해도 앱의 성능이 저하되지 않죠.

앱이 데이터베이스를 사용하지 않는 경우 Oracle Cloud Infrastructure Object Storage 등 내구성을 갖춘 다른 영구 저장소에 상태를 저장할 수 있습니다. 앱 상태를 단일 데이터 저장소에 저장하는 것이 불가능한 경우, 앱 상태의 동기화가 가능하고 실패 후에도 일관적인 하나의 단위로 복구할 수 있는 여러 데이터 저장소에 저장할 수 있도록 앱을 설계하는 게 좋습니다.

Oracle Database에 상태를 저장하는 것이 권장되는 사례 몇 가지를 준비했습니다.

• 사용자 세션 객체 상태: JPA, 관계형 테이블 등 JSON 객체/관계형 매핑을 사용하세요.
• 로컬 데이터 캐시: 데이터가 앱 계층에 캐시된 경우, 신뢰할 만한 데이터 출처는 데이터베이스가 되어야 합니다. 캐시는 앱 실행 시점 또는 필요 시 재구축되어야 합니다. 캐시 업데이트는 백엔드 데이터베이스를 업데이트하는 캐시 나중에 쓰기(write-behind) 방식으로 이루어져야 합니다. 캐시가 새로고침될 수 있도록 앱 인스턴스 내 다른 캐시 인스턴스에 변경 사항이 고지되어야 합니다.
• 앱 구성 데이터: 이 데이터는 보통 JSON 문서, XML 파일, 속성 파일로 저장되는 연결 엔드포인트, 제한, 로깅 레벨, 로그 대상 및 포트 번호 등 아티팩트입니다. 적합한 데이터 유형을 사용하여 이 데이터를 데이터베이스에 저장하세요.
• 프로세스 간 커뮤니케이션 또는 원격 프로세스 호출: 보통 애플리케이션 마이크로서비스 및 구성 요소는 메시지를 사용해 서로 커뮤니케이션합니다. Oracle Database 트랜잭션 큐를 사용하면 해당 메시지의 내구성을 높이고 중단이 발생해도 메시지가 살아남아 처리되도록 할 수 있습니다.
• 텍스트(감사 로그 기록 등): 앱은 감사 로그, 진단 로그와 같은 로그 파일을 생성합니다. Oracle Text 기능을 사용하여 해당 로그를 중앙에 저장할 수 있습니다.
• 성능 모니터링: 앱은 측정 지표 또는 시계열 데이터를 생성해 성능을 모니터링합니다. Oracle Database 시계열 데이터 또는 JSON 데이터 기능을 사용해 이와 같은 데이터를 저장할 수 있습니다.
• 워크플로 상태: 일부 워크플로 엔진은 앱 상태를 로컬에 저장합니다. 그래서 해당 워크플로의 실패는 상태의 손실로 이어지죠. 데이터베이스에서 워크플로 엔진을 사용하면 이러한 문제를 방지할 수 있습니다. 최소한 워크플로 엔진이 데이터베이스를 앱 상태를 위한 영구 저장소로 사용할 수 있도록 구성할 수 있습니다.

완전한 기능을 갖춘 통합 데이터베이스로 모든 데이터 지원

개요
사용자의 앱은 표(관계형), 비정형, XML, JSON, 공간, 그래프 등 다양한 포맷의 데이터를 사용할 수 있습니다. 일반적으로 이와 같은 다양성 때문에 각 데이터 포맷에 대한 다양한 종류의 데이터베이스가 필요했죠. 관계형 데이터를 위한 관계형 데이터베이스, 비정형 데이터를 위한 문서 저장소, 계층 연결된 데이터를 위한 그래프 데이터베이스 등을 그 예로 들 수 있습니다. 하지만 여러 데이터베이스를 사용하면 운영상의 복잡성과 데이터 비일관성이 추가되죠. 대신 단일한 멀티 모델 데이터베이스를 사용해 다양한 유형 및 포맷의 데이터를 저장, 인덱스화, 검색해 보세요.

앱 로직을 단순화해 주는 데이터베이스 기능도 활용할 수 있습니다. 예를 들어 쿼리, 조인, 분석에 SQL을 사용하고, 일관성 및 격리 확보를 위해 트랜잭션을 사용하고, 불필요한 데이터 전송을 막기 위해 내장 머신러닝 알고리즘 및 분석 기능을 사용할 수 있습니다. 민감한 데이터 보호를 위해 데이터베이스의 보안 기능 및 액세스 제어를 사용할 수 있고, 앱의 가용성, 확장성, 탄력성을 높이기 위해 복제 기능을 활용할 수 있습니다.

세부 원칙
멀티 모델 데이터베이스를 사용해 JSON 문서, 속성 그래프, 관계형 데이터 등 다양한 유형의 데이터를 저장할 수 있습니다. 첨단 멀티 모델 데이터베이스는 데이터베이스에 저장된 모든 유형의 데이터에 대한 전체 기능 지원을 제공합니다. 새 JSON 문서를 저장하고, 관계형 행을 삽입하고, 동일한 ACID 트랜잭션 내에서 속성 그래프를 업데이트할 수 있습니다. SQL 문을 사용해 이 다양한 유형의 데이터를 조인, 필터링, 집계할 수 있죠. 이 기능은 관계형 데이터베이스를 통해 익숙해지게 되는 강력한 일관성 및 동시성을 보장합니다. 이와 같은 풍성한 기능 외에도 멀티 모델 데이터베이스는 단일 목적의 데이터 저장소로도 사용될 수 있습니다(SQL 대신 REST API, 문서 저장소 API, 그래프 API 등 API를 사용해 액세스).

멀티 모델 데이터베이스 사용의 주요 이점은 재사용성입니다. 데이터의 유형 및 구성이 다양하더라도 해당 데이터를 관리하는 데 사용되는 기본 기술은 변하지 않습니다. 다시 말해 각 데이터 유형에 맞는 여러 데이터베이스 기술을 배우거나 각 데이터베이스의 사용법 및 튜닝법을 배우지 않아도 된다는 뜻이죠. 기술이 일관성을 유지하기 때문에 앱 코드를 재작성할 필요도 없습니다. 또한 멀티 모델 데이터베이스는 데이터 단편화를 줄여 앱의 탄력성을 개선합니다. 덕분에 백업과 복구도 더욱 손쉬워지죠.

Oracle 권장 사항
멀티 모델 통합 데이터베이스인 Oracle Autonomous Database를 사용해 모든 데이터를 저장, 관리, 분석할 수 있습니다. 데이터를 표로 보여주는 보기 방식을 사용해 앱을 손쉽게 유지 관리할 수 있고, 덕분에 기존 앱에 영향을 주지 않고 기본 스키마를 변경할 수 있습니다. 에디션 기반 재정의를 사용해 다운타임 없이 앱을 업그레이드할 수 있습니다. Oracle Data Safe를 사용해 보안 제어를 구현 및 평가하고, 민감한 데이터를 마스킹하고, 데이터 액세스를 감사할 수 있습니다. Oracle Data Guard를 데이터의 고도로 확장 가능한 읽기 캐시로 사용할 수 있고, 재해 복구를 위해 일관적인 백업을 유지하는 데에도 활용할 수 있습니다.

Oracle Autonomous Database는 워크로드에 아무런 영향이나 장애를 유발하지 않고 운영 작업을 수행합니다. 확장 또는 장애 조치 시나리오를 처리하기 위한 복잡한 보상 로직을 앱에 추가할 필요가 없다는 뜻이죠. 이 데이터베이스는 CPU, 스토리지 등 리소스를 독립적으로 관리하고, 탄력적인 양방향 확장성을 제공합니다.

종단간 모니터링 및 추적용 도구

개요
단일 사용자 요청은 모던 앱을 구성하는 여러 서비스 또는 마이크로서비스 전반의 복잡한 경로를 따를 수 있습니다. 포괄적 추적 기능이 소스에서부터 인프라의 깊이에 이르기까지 각 요청의 여정을 따라가고 문제의 근본 원인을 디버깅할 수 있게 지원합니다. 일반적으로 모니터링 기능은 진단 도구로 사용되며, 앱이 의도된 대로 작동하지 않을 때 개발자에게 이를 알리는 역할도 합니다.

개발자, 관리자, 보안 담당자는 앱의 건전성, 성능, 운영 상태, 보안 사고 가능성 등에 대한 권한을 유지하고, 해당 사항들을 시의적절하게 파악할 수 있어야 합니다. 이와 같은 이해는 수명 주기 내내 앱의 기능과 성능이 사용자의 기대를 충족시킬 수 있게 합니다. 또한 사고의 진단과 애플리케이션 복구 과정을 간소화해 주죠. 종합적이고 포괄적인 모니터링 및 추적은 앱에 추가 복잡성을 더하지 않는 방식으로 간단하게 구현 및 관리되어야 합니다.

원칙 세부 사항
사용자의 앱이 기대한 작업 수행에 실패하는 방식은 매우 다양합니다. 예를 들어 성능이 저하되거나 작업 수행에 실패할 수 있습니다. 전통적인 모놀리식 앱과 달리 마이크로서비스를 통해 구축된 앱은 구성 요소 간 다중 상호 작용으로 인한 추가적인 진단 문제를 일으킵니다.

추적은 마이크로서비스 및 앱을 구성하는 구성 요소(인프라 등)를 돌아보며 사용자 요청 사항에 어떤 일이 발생했는지 빠르게 파악할 수 있는 최적의 방법입니다. 각 사용자의 요구 사항에 대한 데이터를 수집하기 위해 포괄적인 추적 기능을 사용하고, 데이터를 검토해 앱의 어느 단계에 병목 현상 또는 대기시간이 발생했는지 파악할 수 있습니다. 예를 들어 요구 사항이 최종으로 이행되기 전에 여러 마이크로서비스를 오가며 처리될 수 있습니다. 요구 사항의 전체 여정을 추적하지 않고서는 장애의 근본 원인을 찾을 수 없습니다.

일반적으로 모니터링 과정은 훨씬 더 세부화됩니다. 앱을 미세 조정한 뒤 측정 요소를 수집, 축적, 분석하여 앱의 활동 방식을 더욱 잘 파악할 수 있죠. 포괄적 모니터링은 리소스 용량을 동적으로 조정하고, 예상치 못한 이벤트에 대한 반응을 조정하는 데 쓰이는 여러 도구의 자동화된 지능형 통합을 가능케 합니다.

앱의 작동 상태 및 기록에 대한 명확하고, 정확하고, 시의적절한 파악은 최종 사용자 경험 측정만을 위한 것은 아닙니다. 지역 및 국가의 규정을 준수해야 하기 때문이기도 하죠. 요청에 따라 세부적인 활동에 대한 보고서를 작성해야 할 수도, 특정 민감한 데이터 요소 처리에 대한 증명서를 작성해야 할 수도 있으니까요.

일반적으로 모니터링 솔루션은 서드파티 도구와 호환되어야 하며 특히 사용자 환경의 관리 도구와도 호환되어야 합니다. 설계 유연성을 유지하고 공급업체 종속을 피하는 것이 중요합니다.

Oracle 권장 사항
처음부터 포괄적인 모니터링 및 추적 기능을 앱에 구축하고 앱 수명 주기 내내 기능의 일관성을 유지해야 합니다. 이 기능은 개발, 테스트, 배포 과정에 어떠한 복잡성도 더하지 않아야 하며, 구현과 관리가 간편해야 합니다. 가능하면 현재 사용하는 다양한 플랫폼을 수용하도록 확장되는 솔루션을 채택하고 미래에 배포할 수 있습니다.

Monitoring을 비롯한 Oracle Cloud Infrastructure(OCI) 서비스들은 즉시 사용 가능한 모니터링 관련 지원을 제공할 수 있도록 설계되었습니다. 또한 지원되는 API 및 SDK를 통한 일관적인 배포 및 관리 경험을 활용해 다양한 OCI 서비스를 앱 구성 요소로 확장할 수 있습니다. 예를 들어 모든 가상 머신 및 앱에 대해 중앙 집중식 스토리지를 사용하여 자동화된 모니터링 측정항목 수집 또는 로그 캡처를 추가할 수 있습니다.

배포 및 테스트가 진행되는 동안에는 기본적인 디버깅 또는 성능 테스트 정보 수집용으로만 서비스를 구성할 수 있습니다. 앱이 프러덕션 배포 단계에 접어들면 기존 구성 패러미터를 간단히 업데이트해 수집되는 정보의 범위, 빈도, 추적 가능성을 높일 수 있죠.

Oracle Cloud Infrastructure Service Mesh는 Oracle Container Engine for Kubernetes에서 실행 중인 서비스의 다양한 커뮤니케이션 측정 지표 및 로그를 자동으로 수집합니다. 이 데이터를 사용해 메시 내 서비스의 건전성을 추적하고 애플리케이션의 성능을 향상시킬 수 있습니다.

전체 클라우드 테넌시 환경에 대한 강력한 중앙형 데이터 수집 방식을 활용해 분석, 공동 조사, 경보 생성을 위한 단일 위치를 제공할 수 있습니다. Service Connector Hub는 이벤트에 유연하고, 일관적이며, 맞춤 설정 가능한 응답을 제공할 수 있게합니다. OCI Logging Analytics를 통해 모든 클라우드(및 외부) 이벤트 로깅 시스템에 대한 효율적인 분석 및 조사를 수행할 수 있습니다.. 또한 Oracle Cloud Infrastructure(OCI) Service Connector Hub, Functions, Notifications들을 사용하여 수집된 측정 지표 및 로그를 실질적 효과를 발생시키는 경보로 변환할 수도 있습니다. 또한 Splunk 및 Grafana와 같은 타사 제품 및 서비스와의 통합을 활용할 수 있습니다.

다음 OCI 서비스는 앱 호스트 환경 전반의 로깅, 모니터링, 추적을 통합할 수 있게 지원합니다: Logging, Monitoring, Logging Analytics, Application Performance Monitoring, OS Management, Database Management, Java Management. 이 완전 관리형 서비스들은 일반 OCI 인프라 리소스와 통합되어 있으며, 커스텀 앱 리소스 통합에 필요한 매커니즘에 대한 지원을 제공합니다.

자동화된 데이터 복제 및 장애 복구를 통해 SPOF 제거

개요
SPOF(single point of failure)는 앱의 구성 요소로, 장애 발생 시 이용이 불가능하거나 안정적이지 않은 앱 전체를 렌더링합니다. 가용성이 높고 안정적인 앱을 개발하려면 자동화된 데이터 복제 기능을 사용해 단일 구성 요소의 장애가 데이터 손실로 이어지지 않도록 조치해야 합니다.

기계 전반에서 데이터 복제 및 중복 네트워킹 기능을 사용하면 자주 발생하는 기계 및 네트워크 장애로부터 시스템을 보호할 수 있습니다. 여러 다양한 지역에 위치한 데이터 센터(또는 가용성 도메인) 전반에 데이터를 복제해 두면 화재, 지진, 홍수, 허리케인 등 지역적 재해로부터 시스템을 보호할 수 있습니다.

세부 원칙
 고가용성 앱을 구축하려면, 장애 발생 시에도 앱이 사용하는 데이터가 이용 가능한 상태로 유지되도록 해야 합니다. 데이터 고가용성의 핵심은 자동화된 데이터 복제를 통해 데이터 중복성을 확보하는 것입니다.

복제는 표 등 데이터베이스 객체를 분산형 데이터베이스 시스템을 구성하는 여러 데이터베이스에 복사 및 유지 관리하는 프로세스입니다. 한 사이트에 적용된 변경 사항은 로컬에서 수집 및 저장된 뒤 원거리에 위치한 복제본에 포워드 및 적용됩니다.

복제된 데이터베이스는 액티브-패시브 및 액티브-액티브 두 가지 모드로 작동합니다. 액티브-패시브 모드에서는 하나의 기본 복제본과 하나 또는 그 이상의 보조 복제본이 존재하며, 기본 복제본만이 앱 데이터 처리에 참여합니다. 액티브-액티브 모드에서는 모든 복제본이 데이터 처리에 참여합니다. 액티브-액티브 모드의 경우 기본-보조 장애 조치가 필요하지 않기 때문에 더욱 효과적인 리소스 활용 방식과 고가용성을 누릴 수 있습니다.

중복성은 데이터 복제본의 장애가 독립적으로 발생하도록 보장합니다. 기계 또는 디스크 장애는 일반적으로 독립적으로 발생하지만, 네트워크 또는 전원 장애는 여러 기계의 동시다발적인 장애를 유발합니다. 이와 같은 사고로부터 시스템을 보호하기 위해서는 네트워크 및 전원 인프라 역시 중복성을 지녀야 합니다. 또한 데이터 복제본이 동시에 장애를 겪지 않도록 다양한 기계 및 위치에 신중하게 배치되어야 합니다.

Oracle 권장 사항
OCI 데이터 센터는 심각한 단일 실패지점(SPOF)을 방지하기 위해 신중히 설계되었습니다. 일반적인 데이터 센터 또는 가용성 도메인은 장애 도메인으로 알려진 여러 개의 독립적인 장애 단위를 포함합니다. 두개의 독립적인 장애 도메인은 동시에 장애를 일으킬 수 없습니다. 마찬가지로 여러 개의 가용성 도메인을 지리적으로 분산해 보유한 단일 리전의 경우에도, 두 개의 가용성 도메인이 동시에 장애를 일으키지 않습니다.

Block Volumes, Object Storage, File Storage등 OCI 스토리지 서비스를 사용하면 장애 및 가용성 도메인 전반의 데이터를 복제해 SPOF가 앱 데이터의 가용성에 영향을 미치지 못하도록 할 수 있습니다. Container Engine for Kubernetes를 통해 OCI에 내장된 탄력적인 장애 격리(장애의 영향을 받는 서비스 구성 범위를 제한하는 기능)를 활용하면 여러 개의 장애 및 가용성 도메인에 걸쳐 앱을 배포할 수 있습니다. Oracle Autonomous Database, Data Guard, GoldenGate는 고가용성 및 다운타임 없는 패칭 및 업그레이드를 위해 액티브-액티브 하드웨어 및 소프트웨어 복제를 제공합니다. 고가용성 데이터에 이 관리형 서비스를 사용하면 자체 스토리지 인프라를 구축하거나 관리할 필요가 없습니다.

앱 및 데이터 보호를 위한 자동화된 심층 방어 구현

개요
심층 방어는 여러 개의 독립적이고 중복된 보안 제어 기능이 앱을 위한 여러 겹의 방어 계층 역할을 하는 접근 방식을 말합니다. 각 계층은 그중 하나가 장애를 일으키더라도 보안 기능을 제공하도록 설계되었습니다. 예를 들어 방화벽이 침입 감지와 결합되는 식이죠.

그러나 각 보안 제어 기능을 수동으로 관리 및 구성하는 일은 개별적으로도, 전체적으로도 복잡하고, 이해하기 어렵고, 오류에 취약할 수 있습니다. 그대신 자동화된 보안 제어를 사용하면 앱과 그 데이터를 보호할 수 있죠.

세부 원칙
심층 방어 기능은 보안의 물리적, 기술적, 행정적, 운영적, 인적, 절차적 요소를 아우르는 다양한 제어를 사용해 위험을 제어합니다. 각 기능이 독립적이란 건 각각이 장애, 유출 및 기타 보안 취약성을 다룰 수 있는 심층적인 보안 기능을 제공한다는 뜻이죠. 제어 기능은 다양한 방식을 통해 위험에 접근하도록, 보안 침해 시도가 적절한 이해관계자에게 감지 및 보고될 수 있게 로깅, 감사 등의 기능을 제공하도록 설계되었습니다.

복잡한 보안 제어를 수동으로 구성하기 보다 간편하고 규범적인 자동 제어 기증을 사용해 앱을 보호해 보세요. 자동화된 보안 제어 기능은 인적 오류(다양한 보안 사고의 근본적인 원인)를 제거하고, 보안 전문성을 갖추지 않은 사용자도 앱 및 데이터를 보호할 수 있게 지원합니다.

Oracle 권장 사항
개발, 구축, 테스트, 배포, 런타임 등 앱 수명 주기의 모든 단계에 사용이 손쉽고 자동화된 보안 제어 기능을 구현하세요. 수명 주기의 각 단계에서 사용자, 허가, 액세스 정책을 검증하고 액세스가 적합한 사용자에게만 주어지도록 보장합니다. 소프트웨어 개발 수명 주기의 초기 단계에도 보안 문제를 감지할 수 있습니다. 초기 감지 기능 덕분에 앱은 보안 아키텍처 모범 사례를 통해 프러덕션 환경에 배포될 수 있고, 잘못된 구성 또는 알려진 취약성으로 인한 운영상의 보안 문제도 사전에 감지 및 경감될 수 있습니다.

OCI는 고객의 앱 및 데이터를 보호하기 위해 여러 자동화된 보안 서비스를 제공합니다. OCI 서비스 사용에 대한 권장 사항을 몇 가지 준비했습니다:

• Web Application Firewall(WAF)은 알 수 없는 위치에서 유입되는 트래픽을 제한합니다. TLS(transport layer security)의 경우 로드 밸런서 인증서 및 오토로테이션을 사용할 수 있습니다. HTTPS 컨텐츠를 제공하는 모든 로드 밸런서에서 WAF를 사용으로 설정합니다. Oracle 관리 규칙을 활성화하고 오탐을 튜닝합니다. GeoIP 액세스 규칙을 사용하면 비즈니스 관계를 맺지 않은 국가로부터 유입되는 트래픽을 제한할 수 있습니다. WAF의 위협 인텔리전스를 사용하여 Tor 노드를 차단할 수 있습니다.
• Oracle Cloud Infrastructure Identity and Access Management(IAM)는 ID 우선 보안 접근 방식을 통해 손쉬운 사용자 온보딩 및 관리를 지원합니다. 앱의 프론트엔드에서 OCI IAM을 사용하면 강력한 인증 방법을 통해 사용자를 인증하고, 동시에 맥락을 인지하는 적응형 보안, 소셜 또는 통합 로그인 옵션, 암호 없는 인증(요구 사항에 따라) 등을 통해 최적의 사용자 경험을 유지할 수 있습니다. 사용자가 이용약관에 대한 동의를 관리할 수 있게 하고, 데이터 레지던시 요구사항을 지원함으로써 규제 요구사항을 지원할 수 있습니다. 백엔드에서 OCI IAM을 사용하면 필요 시 앱의 구성 요소에 대한 액세스를 제한할 수 있습니다. 강력한 MFA(multifactor authentication) 옵션을 통해 관리자에 대한 인증을 의무화할 수 있습니다. 명시적인 승인을 받은 사용자에게만 액세스를 허용하는 강력한 보안 정책을 도입할 수 있습니다. 책임을 구분해 액세스가 필요한 사용자에게만 제한적으로 주어질 수 있게 보장할 수 있습니다.
• 키를 사용하여 하드웨어 보안 모듈이 지원되는, OCI Vault에 저장된 유휴 상태의 데이터를 암호화할 수 있습니다. 각 서비스별로 별도의 암호 키를 사용하는 것을 선호할 수도 있지만 OCI Vault 엔티티의 경우 구획을 일치시키는 것이 좋습니다. 마스터 암호화 키는 최소 연단위로, 데이터 키는 3개월마다 전환하는 게 좋습니다. 프러덕션 환경에서 전용 Vault를 사용하고 보조 영역에 키를 복제해 두세요. 백업을 생성한 뒤 이를 다른 리전에 위치한 Oracle Cloud Infrastructure Object Storage에 저장할 것을 권장합니다. 암호화 키를 보호하고 앱 소유자가 승인한 키에만 액세스를 제한합니다.
• 내장된 보안 주체를 사용하여 컴퓨트 인스턴스에 다른 OCI 서비스에 대한 작업을 수행하도록 권한을 부여합니다.
• OCI VCN(virtual cloud networks)의 네트워크 보안 그룹 기능을 사용해 엔드포인트 격리에 대한 최소 도달 가능성의 원칙을 시행할 수 있습니다. 모든 VCN에서 NetFlow 로깅을 활성화 하세요. DNS 로깅을 모니터링해 활동 또는 명령을 암호화하고 서버 활동을 제어할 수 있습니다.
• Oracle Security Zones를 사용해 기본 보안 구성으로 앱을 실행할 수 있습니다. 전용 서브넷을 갖춘 구획에는 최대 보안 영역을 사용하는 것이 좋습니다. 전용 서브셋의 모든 컴퓨트 인스턴스에 대한 운영자 액세스는 Oracle Cloud Infrastructure Bastion을 거치도록 설정해야 합니다.
• Oracle Cloud Guard를 활성화하여 모든 문제를 해결하거나 승인 및 미사용 상태로 전환할 수 있습니다. 드리프트에 대한 통지를 사용으로 설정하고 긴급도에 새 문제를 처리합니다.
• Oracle Data Safe를 활성화하여 사용자 및 액세스를 모니터링함으로써 Oracle Database를 보호할 수 있습니다. 또한 Data Safe는 데이터베이스를 스캔하여 보안 모범 사례와 간결한 경고에 대해 알립니다.
• Oracle Cloud Infrastructure Vulnerability Scanning Service를 사용하면, 알려진 보안 문제 파악을 위해 인스턴스 및 컨테이너를 주기적으로 스캔할 수 있습니다.
• OCI Service Mesh를 사용하여 Oracle Container Engine for Kubernetes(OKE) 클러스터 내의 서비스 간 커뮤니케이션을 인증 및 암호화할 수 있습니다. OCI Service Mesh는 또한 서비스 간 커뮤니케이션을 제어하고 외부 요청 사항을 검증하는 액세스 정책을 사용자가 구성할 수 있게 해 줍니다.