모든 고객에게 동일한 설계 방식을 적용합니다. 클라우드 관련 차이점(연결 제품, 핵심 서비스, 데이터베이스 엔진 등)은 재설계가 아닌 구성 선택 사항입니다. 바로 이 점 때문에 코드로 환경을 5일(영업일 기준) 만에 구축할 수 있습니다.
위에서부터 그림을 읽어보세요
- 사용자와 통합 시스템은 erp.<고객 도메인>이라는 단일 이름으로 접속하여 HTTPS, TLS 1.2 이상을 통해 WAF가 설치된 로드 밸런서를 거칩니다. 이것이 유일한 공용 접속 경로입니다.
- 최소 3개의 워커 노드(가용 영역당 하나씩)가 웹 및 API, 포스팅 엔진, ASK 운영자, 워커 및 작업을 실행합니다. 노드 하나 또는 전체 영역에 장애가 발생하더라도 사용자에게 서비스를 제공할 수 있는 용량이 유지됩니다.
- 고객이 선택한 엔진과 크기의 관리형 데이터베이스는 다른 영역에 동기식 대기 데이터베이스를 갖습니다. 영역 장애가 발생해도 데이터 손실은 없습니다. 즉, RPO(복구 목표 시점)는 0에 가깝습니다.
- 문서와 첨부 파일은 데이터베이스가 아닌 버전 관리되는 객체 저장소에 저장됩니다.
- 외부 트래픽은 NAT를 통해 허용된 목록(은행, 세금 및 전자 송장, 급여, 이메일, AI 엔진)으로만 나갑니다. 그 외에는 아무것도 나가지 않습니다.
- 백업은 별도의 계정에 있는 에어갭 방식의 저장소로 단방향으로 전송됩니다.
개인 엔드포인트와 내부 로드 밸런서는 개인 액세스를 사용할 때만 존재하기 때문에 점선으로 표시됩니다. HTTPS 전용 액세스의 경우 이러한 구성 요소는 생성되지 않습니다.
조절 손잡이 5개, 그 외에는 아무것도 없습니다.
노드 크기, 노드 개수(최소 3개), 데이터베이스 엔진 및 크기, Live DR 지역, 환경 개수. 그 외의 모든 것은 참조 아키텍처입니다.
구성하고, 통합하고, 그 다음에야 코딩하십시오.
표준 이상의 요구 사항은 플랫폼 업그레이드가 가능한 경우 구성 변경을 통해 충족됩니다. 그렇지 않은 경우 클러스터 외부에서 실행되는 TRANXACT API를 통한 통합을 통해 충족됩니다. 그런 다음 보안 및 엔지니어링 검토를 거쳐 클러스터 내부에 코드 또는 에이전트를 구현하는 것을 고려합니다. 승인되면 허용되고 고객 지원이 제공되며, 거부되면 클러스터 외부에서 실행됩니다.
고객은 데이터베이스에 직접 접근할 수 없습니다. 해당 기능은 제공되지 않는 것으로 표시되어 있습니다(DB_3.1.09). 보고 및 통합은 TRANXACT API와 추출 기능을 통해 이루어지며, 따라서 BI 도구는 데이터베이스 로그인이 아닌 API 또는 예약된 추출 기능을 통해 연결됩니다.
캘더우드의 BI 팀은 데이터 웨어하우스에 대한 읽기 전용 데이터베이스 사용자를 요청합니다. 해결책은 프라이빗 링크를 통한 예약 추출입니다. 인터페이스 목록의 BI 행은 "유지, 예약 추출, 프라이빗 링크"로 설정되어 있습니다.
한번 시도해 보세요 캘더우드 월말에 2번 영역의 워커 노드에 장애가 발생했습니다. 사용자에게 어떤 영향이 미치며, SLA 위반으로 간주됩니까?
해당 Pod는 부하를 처리할 수 있도록 크기가 조정된 영역 1과 3의 노드로 재배치됩니다. 데이터베이스는 영역 2에 기본 노드가 있는 경우를 제외하고는 영향을 받지 않으며, 기본 노드가 영역 2에 있는 경우에는 RPO가 거의 0인 동기식 대기 노드로 페일오버됩니다. SLA 위반은 해당 월의 가용성이 티어 목표를 달성하지 못하는 경우에만 발생합니다.