마이크로서비스 아키텍처
오래된 응용 프로그램의 문제
많은 구형 클라우드 애플리케이션은 모놀리식 아키텍처를 사용합니다. 이러한 레거시 앱은 여러 테넌트에 서비스를 제공할 수 있지만 고도로 상호 의존적인 구성 요소의 크고 복잡한 집합으로 구축됩니다. 한 구성 요소에서 장애가 발생하면 다른 구성 요소에 치명적인 영향을 미쳐 많은 또는 모든 테넌트의 서비스가 중단될 수 있습니다. 이러한 시스템을 업데이트하려면 오프라인으로 전환해야 하므로 업그레이드 프로세스 중에 사용자 액세스가 제한됩니다. 모놀리식 서비스의 문제는 하드웨어가 제한된 독점 데이터 센터에 배포될 때 악화됩니다. 하드웨어 제약이 소프트웨어 리소스의 가용성과 확장성을 더욱 제한하기 때문입니다.
Genesys Cloud의 마이크로서비스 솔루션
Genesys Cloud는 마이크로서비스를 사용하여 모놀리식 아키텍처의 문제를 해결합니다. 마이크로서비스를 사용하여 단순한 상태 비저장 개체로 복잡한 문제를 해결합니다. 우리의 마이크로서비스 아키텍처는 또한 사실상 무제한을 제공합니다. 지리적으로 다양한 여러 데이터 센터에 있는 수천 대의 서버로 확장할 수 있습니다.
밀접하게 연결된 여러 구성 요소를 사용하는 대신 Genesys Cloud는 기능을 서비스로 나누고 각 서비스는 주어진 유형의 요청을 처리합니다. 각 Genesys Cloud 서비스는 Elastic Load Balancer(ELB)를 사용하여 작업을 분산합니다. 각 그룹에는 부하에 따라 동적으로 확장되는 여러 서버가 포함됩니다. 서비스 수준 트래픽을 지속적으로 모니터링하고 사용량 수준 및 요청 유형에 따라 마이크로서비스를 최적화합니다.
이 다이어그램은 Genesys Cloud의 주요 서비스를 보여줍니다.
주문형 확장
대부분의 Genesys Cloud 서비스는 ASG(Auto Scaling Group)와 함께 ELB를 사용합니다. Genesys Cloud는 서비스별 정책(컴퓨팅 집약적 서비스의 경우 CPU, 쿼리 서비스의 평균 응답 시간 등)에 따라 부하를 분산하고 그룹을 모니터링합니다. 임계값 정책을 초과하면 그룹은 필요에 따라 추가 리소스를 자동으로 추가하거나 제거합니다. 예를 들어 조직에서 갑자기 백만 개의 팩스를 보내야 하는 경우 연결된 마이크로서비스는 다른 기능이나 다른 테넌트에 영향을 주지 않고 수요를 충족하도록 자동으로 확장됩니다.
페일 세이프 처리
독립적으로 작동하기 때문에 한 마이크로 서비스의 문제가 다른 마이크로 서비스에 영향을 줄 수 없으므로 문제의 가능성이 크게 제한됩니다. 예를 들어, 3개의 개별 마이크로서비스가 음성 메일 검색, 아웃바운드 팩스 및 수신 고객 호출 라우팅을 처리합니다. 음성 메일 검색 마이크로 서비스가 실패하면 수신 고객 호출 마이크로 서비스는 중단 없이 계속 작동합니다.
복구를 통한 신뢰성
개별 서버가 실패하면 적절한 ELB/ASG가 상태 확인 실패 또는 시간 초과를 감지하고 로드 밸런서에서 비정상 구성 요소를 분리합니다. 이 오류가 일시적이지 않은 경우 추가 논리는 잘못된 노드가 중지되고 그 자리를 대신할 완전히 새로운 서버가 생성되는 자가 치유 동작을 트리거합니다. 트래픽은 계속 줄어들지 않고 그룹의 다른 서버가 추가 작업을 원활하게 수용합니다. Genesys Cloud는 사용자가 서비스 격차를 감지하기 전에 복구합니다. 이 복구 프로세스에는 리소스 급증이 필요하지만 Amazon Web Services(AWS)를 통해 충분한 온디맨드 대역폭 액세스에 액세스할 수 있습니다.
Genesys Cloud는 국제 클라우드 기반 배포의 확실한 리더인 AWS를 기반으로 구축되었습니다. 우리는 Amazon과 긴밀히 협력하여 Amazon의 모니터링 및 ELB 시스템을 테스트하고 개선합니다.
AWS 리전
Genesys Cloud는 전 세계 여러 독립적인 AWS 리전에 배포됩니다. 각 리전은 각각 하나 이상의 물리적 데이터 센터로 구성된 여러 Amazon "가용 영역"으로 구성됩니다. 각 가용 영역에는 별도의 전원, 백본 네트워크 연결, 복제된 데이터 메모리 및 (경우에 따라) 구조적 결함 플레이트에 걸친 물리적 분리가 있는 이 수준에서도 시스템의 패브릭에 중복성이 구축됩니다. 고객 데이터는 지역 내의 영역과 데이터 센터에 복제됩니다. 전체 데이터 센터의 손실은 일시적으로 용량을 감소시킬 뿐입니다. 상황은 자동으로 복구되며 데이터 손실 없이 복구됩니다. 데이터 내구성을 보장하는 것 외에도 데이터 주권은 클라우드 배포의 중요한 측면입니다. Genesys Cloud 아키텍처를 통해 조직은 "기록 영역"을 정의하여 데이터가 인프라 내에서 지역 경계를 넘지 않도록 할 수 있습니다.
Genesys Cloud Voice 배포를 위한 AWS 리전
브라우저 및 모바일 클라이언트
Genesys Cloud 클라이언트는 여러 면에서 마이크로서비스에서 사용하는 상태 비저장 접근 방식을 반영합니다. 브라우저가 Genesys Cloud를 렌더링할 때 데이터 업데이트에 대한 이벤트 알림을 포함하여 일련의 개체가 브라우저 메모리에 구축됩니다. 브라우저가 새 정보를 수신하면 메모리의 개체를 업데이트한 다음 사용자의 보기를 업데이트합니다.
사용자가 보기를 변경하거나 새 작업을 시작할 때마다 업데이트 확인을 요청하는 동안 기존 로컬 데이터가 즉시 표시됩니다. 이러한 데이터 요청은 사용 가능한 서비스와 일치하도록 구성되고 데이터 대역폭을 줄이고 클라이언트 보기의 속도를 개선하도록 최적화됩니다.
지속적인 업데이트
우리는 프로덕션 Genesys Cloud 시스템에 새로운 코드를 지속적으로 푸시합니다. 작은 결함이 감지되면 즉시 수정하고 영향을 받는 서비스의 새 버전을 푸시합니다.
분산 아키텍처를 사용하면 유지 관리를 위해 전체 시스템을 중단하지 않고도 롤링 업데이트를 릴리스할 수 있습니다. 우리는 로드 밸런싱과 "레드-블랙 배포"와 같은 기술을 사용하여 고객이 업데이트 프로세스에 의해 부정적인 영향을 받지 않도록 합니다. 새로운 버전의 마이크로 서비스(새로운 기능 또는 수정 사항 포함)를 사용할 수 있게 되면 해당 서비스에 대한 완전히 새로운 서버 이미지를 생성합니다. 이 이미지는 시스템을 제자리에 패치하는 대신 완전히 새로운 서버를 만드는 데 사용됩니다. 이러한 새 서버가 온라인 상태가 되고 정상 상태로 결정되면 이후에 로드 밸런서에 연결되고 이제 소량의 트래픽이 이 서버에서 처리되기 시작합니다. 새 서버가 원하는 대로 작동한다고 가정하면 더 많은 용량이 추가되고 이전 서버(이전 버전의 서비스 포함)가 로드 밸런서에서 제거되고 미해결 요청이 배출됩니다. 몇 분 안에 특정 마이크로서비스의 기능을 제공하는 전체 서버 집합을 교체할 수 있습니다. 이는 지속적인 서비스 제공을 원활하게 하는 것 외에도 비할 데 없는 안정성을 제공합니다. 제자리 업그레이드를 피하면 사전 프로덕션 환경에서 테스트하는 시스템이 프로덕션에 배포된 시스템과 기능적으로 동일하다는 것을 보장하여 취약성을 줄입니다. 또한, 새로운 버전이 원하는 대로 작동하지 않는 경우에 마이크로서비스의 알려진 양호한 변형으로의 빠른 롤백을 허용합니다.
마이크로서비스의 독립성과 광범위한 자동화된 테스트 및 빌드 프로모션 프로세스를 통해 Genesys는 실수로 다른 것을 깨뜨릴 염려 없이 버그 수정을 푸시할 수 있습니다. 또한 Genesys는 기존 서비스에 영향을 주지 않고 새로운 기능을 위한 마이크로서비스를 생성할 수 있습니다. 수백만 명의 고객이 Genesys Cloud를 적극적으로 사용하는 동안 업데이트가 발생합니다.
