BLOG
오늘날 AWS에서 SAP를 실행하는 고객들은 가장 광범위하고 심층적인 기본 클라우드 서비스를 이용하고 있습니다. 여기엔 컴퓨팅, 스토리지 및 데이터베이스와 같은 전통적인 서비스뿐만 아니라 IoT 및 머신 러닝과 같은 새로운 기술들이 신뢰성이 높은 글로벌 인프라 위에 포함되어 있습니다.
고객이 사용하는 주요 기능 중 하나는 인스턴스 유형 변경입니다. 워크로드가 변경됨에 따라 고객은 인스턴스 사용량이 너무 많거나(인스턴스 유형이 너무 작음) 사용률이 낮은 것(인스턴스 유형이 너무 큼)을 알아채게 됩니다.
이 확장성 개념을 수직 스케일링 이라고 합니다. 더 간단히 말하면, 리소스를 추가하는 것만으로 추가 워크로드에 대응 가능한 시스템의 기능입니다.
아시다시피 SAP의 데이터베이스 계층에서 수직 확장성이 중요하지만 애플리케이션 서버 계층은 어떻습니까? 모든 워크로드를 지원하기 위해 하나의 대규모 애플리케이션 서버를 만들 수는 없습니까? 어쩌면 가능할 수도 있지만 그건 좋은 생각이 아니기 때문에, SAP는 애플리케이션 서버를 수평으로 확장하도록 설계했습니다. 이에는 자동 스케일링의 개념이 종종 사용됩니다.
수평적 확장성을 확보 하기 위해 고객은 크기 조정을 수행하고 기록 데이터를 사용하여 최대 워크로드를 지원하는 데 필요한 애플리케이션 서버 수를 결정합니다. 이로 인해 마케팅 중심의 판매 주문 급증 또는 보고를 위한 대량의 데이터 추출과 같이 계획되지 않은 이벤트가 발생했을 때 활용률이 낮은 자원 또는 자원 병목 현상이 발생합니다.
수평적 확장성이 논의될 때 DevOps팀 또는 클라우드 엔지니어링 팀의 누군가가 Amazon EC2 Auto Scaling 을 제안할 수 있습니다. 그러나 우리 모두 알다시피 SAP는 때때로 맞지 않을 수도 있습니다. SAP는 온 프레미스 원점을 고려할 때 항상 확장성을 쉽게 처리할 수 있는 것은 아닙니다.
여기서 AWS의 온 프레미스 확장성 기능을 클라우드 네이티브 Auto Scaling 그룹에 연결하는 브리지를 구축할 수 있습니다.
솔루션 개요
기존의 자동 스케일링은 CPU사용률에서 로드밸런서 타겟 요청 수에 이르기까지 다양한 메트릭스가 사용됩니다. 이들은 워크로드와 기본 리소스의 응용 프로그램 사용에 대한 훌륭한 지표입니다. 그러나 고객이 SAP 활용을 위해 고려해야 하는 몇 가지 필요 동작 패턴을 반영하지 않습니다.
모든 SAP 애플리케이션 서버는 SAP 커널을 기반으로한 SAP 서비스인 작업 프로세스로 구성되며, 이는 SAP를 독특하게 만듭니다. 각 작업 프로세스는 CPU, 메모리, 네트워크 등을 소비하는 OS 계층에서 실행되는 특정 작업 유형에 특화되어 있습니다. SAP 응용 프로그램 서버의 크기를 조정할 때 이러한 밸런스와 분포는 SAP 시스템에 중요합니다.
마이크로 서비스 및 대부분의 최신 애플리케이션의 경우 CPU 및 요청 수와 같은 표준 자동 스케일링 메트릭은 애플리케이션 자동 스케일링을 처리하기에 충분합니다. SAP의 경우, 작업 프로세스, 특히 비어 있거나 사용중인 프로세스 수를 고려해야 합니다.
그렇다면 기본 자동 스케일링 기능을 연결하여 CPU 사용률 이나 요청 횟수 및 작업 프로세스 소비량을 고려하기 위해서는 어떻게 하면 좋을까요?
여기서 AWS Professional Services SAP Application Auto Scaling 솔루션이 등장합니다.
이 솔루션을 통해 기업 및 SAP Basis 관리자는 대화, 배치, 대기열 및 인쇄 작업 프로세스에 대한 SAP 특정 워크로드 메트릭을 기반으로 SAP 애플리케이션 서버 소비를 자동으로 감지할 수 있습니다. 이 솔루션은 동시 사용자 로그인, 월말 결산, 지불 실행 및 다양한 예측 가능한 워크로드 및 예측 불가능한 워크로드에 대한 급증 및 급락에 적응할 수 있습니다.
이 솔루션은 필요한 애플리케이션 서버만 프로비저닝 하는 온 디맨드 클라우드 모델을 사용합니다. 사용자가 정의한 메트릭에 따라 수평으로 확장(새로운 컴퓨팅이 애플리케이션 서버로 시작됨)되고 다시 돌아갑니다(기존 컴퓨팅의 애플리케이션 서버가 중지됨). 이것은 온도 조절기가 집의 온도를 유지하는 방식과 유사합니다. 온도를 선택하면 온도 조절기가 나머지를 수행합니다.
다음 이미지는 이 아키텍처가 구성되는 방법을 보여줍니다.
하지만 잠시 기다려주십시오. 이 솔루션이 확장될 뿐만 아니라 다시 돌아올 때, 사용자 및 백그라운드 작업이 실행되는 애플리케이션 서버를 종료 하시겠습니까?
또 다른 미묘한 SAP 과제가 하나 더 있습니다. 모든 SAP 트래픽이 로드밸런서를 통해 라우팅 되는 것은 아니며 연결 드레인을 사전에 사용할 수 있습니다. 이 트래픽 중 일부는 SAPGUI 또는 기본 SAP RFC를 통해 시스템을 호출하는 다른 시스템으로부터의 최종 사용자입니다.
SAP에서 이를 기본적으로 처리하려면 서버리스 컴퓨팅 계층인 AWS Lambda를 사용하여 SAP 내 에서 소프트 종료 또는 정상 종료 기능을 호출하십시오. 이를 통해 SAP 인스턴스를 종료할 때 요청 또는 데이터가 손실되지 않고 이 솔루션의 전체 TCO를 최소화할 수 있습니다.
소프트 셧다운은 특정 순서로 트랜잭션이 완료될 때까지 기다립니다. 그런 다음 이를 EC2의 API 컨트롤 플레인과 결합하여 애플리케이션 서버의 기반이 되는 EC 인스턴스를 조정하여, SAP 서버 온 디맨드로의 전체적인 접근 방식을 실현합니다.
AWS 서버리스 컴퓨터, 스토리지 및 분석을 사용하는 AWS Professional Services 솔루션을 사용하면 온 프레미스 및 단일체의 SAP 아키텍처에 묶인 고객이 보다 탄력적이고 확장 가능하며 비용 효율적인 방식으로 SAP를 실행할 수 있습니다.
글을 마치며…
해당 오퍼링은 기본 인프라 형태의 턴키 솔루션뿐만 아니라 고객별 요구 사항에 맞는 고도로 맞춤화된 솔루션을 구축하기 위한 가속기 역할을 합니다.
AWS Auto Scaling을 사용하면 필요한 비용만 지불하게 되어 운영 비용을 절감하고 더 높은 서비스 수준 목표를 제공할 수 있습니다. 주말 동안 새 프로젝트나 다가오는 마케팅 캠페인 때문에 SAPS를 초과하여 초과 프로비저닝 해야하는 애플리케이션의 서버 수를 계산하던 시절 이제 지났습니다.
온도 조절 장치와 마찬가지로 메트릭을 선택하면 솔루션이 나머지를 수행합니다.
이 솔루션을 사용하는 것에 관심이 있으신가요? 혹은 기본 서비스를 더 잘 이해하고 싶으신가요? 그렇다면 sap-on-aws@amazon.com으로 문의해 주시길 바랍니다.
원문 URL: https://aws.amazon.com/ko/blogs/awsforsap/using-aws-to-enable-sap-application-auto-scaling
** 메가존 클라우드 TechBlog는 AWS BLOG 영문 게재 글 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.