With S/4HANA, you have a data-hungry production system. And the sizing of hardware is not just disk, it's also memory. These come packaged either as a pre-built appliance, or you can leverage hyperscalers who provide T-shirt sizings for consumption. But in the hyperscaler model, you typically can’t go from 1 to 1.1 of something. When your system starts to fill the recommended maximum capacity, you have to go up a size – which is often double the previous allocation.
우리는 지금이 유례없는 기술 변화의 시기라는 말을 끊임없이 듣고 있습니다. AI와 그 엄청난 힘으로 인해 일터에서의 생활의 많은 부분을 다시 생각해야 할 것이라고요. 우리가 이해해야 할 것의 규모는 엄청나게 압도적인 것이지만, 여기서는 그 모든 것에서 잠시 벗어나 단순한 기술 변화와 우리가 다르게 행동해야 하는 이유를 명확하게 볼 수 있는 시간을 갖도록 하겠습니다.
지난 30년 동안 SAP를 운영하는 대부분의 기업은 시스템 복제를 수행해 왔습니다. 단위 테스트, 회귀 테스트, 통합 테스트, 시스템 테스트, 테스트 등을 수행하려면 운영 실데이터를 활용하는 것이 유일한 방법이라는 것이 분명해졌습니다. 따라서 운영 시스템의 꾸준한 증가는 비운영 시스템의 증가가 더디다고 하더라도 동일한 단계의 성장을 의미했습니다. 기존 데이터베이스의 3 레이어 모델(데이터베이스 서버, 애플리케이션 서버, 프레젠테이션 계층)은 필요에 따라 볼륨을 추가하는 것이 매우 쉬웠고, 이후에는 SAN(스토리지 영역 네트워크)을 통해 작은 공간을 거의 즉각적으로 추가할 수 있었습니다.
따라서, 충분한 디스크를 할당하고 운영시스템을 여러 개의 비운영 시스템에 다시 복 제하는 프로세스는 SAP Basis 팀의 연간 일정에 너무 깊숙이 자리 잡았기 때문에 어쩌면 거의 문제가 되지 않습니다. 단, S/4HANA 시스템 환경을 도입하기 전까지는 말이죠.
이제 더 많은 데이터를 사용하는 운영 시스템을 갖추게 됩니다. 그리고 하드웨어의 크기는 디스크뿐만 아니라 메모리도 마찬가지입니다. 이는 사전에 구축된 어플라이언스로 패키지로 제공되거나, 티셔츠 사이즈라고 일컬어 지는 규격화된 사용량기반의 하이퍼스케일러를 활용할 수 있습니다. 하지만, 하이퍼스케일러 모델에서는 일반적으로 1에서 1.1로 늘릴 수 없습니다. 시스템이 권장 최대 용량을 채우기 시작하면 크기를 한 단계 올려야 하는데, 이는 이전 할당의 두 배인 경우가 많습니다. 따라서, 순간적으로 활용도가 높았던 1TB 운영 어플라이언스가 낮은 활용도의 2TB 어플라이언스가 되고, 다음 QA 업데이트 전에 하드웨어도 확장하지 않으면 운영 데이터 볼륨(디스크 및 메모리)을 처리할 수 없게 됩니다.
지난 20년 동안 저는 10년 전과 같은 아주 오래된 운영 데이터는 QA 시스템에 필요하지 않다고 주장해 왔습니다. 표시, 보고, 변경, 처리 등이 이루어지지 않을 것이기 때문입니다. 내년에 장비가 다시 교체된다 하더라도 그대로 휴면 상태로 남아 있을 것입니다. 이제 비로소야 제가 외처온 주장은 비용 측면에서 절대 부인할 수 없는 사실입니다. 트랜잭션 데이터는 일반적으로 SAP 시스템 볼륨의 50~90%이므로, 테스트 시스템에서의 데이터 규모를 통제할 수 있다면 하이퍼스케일러 하드웨어에 더 작은 어플라이언스나 더 작은 티셔츠 사이즈를 활용할 수 있습니다.
하지만 더 좋은 점은 비운영 시스템이 동일한 속도로 증가하지 않는다는 것입니다. 비즈니스에서 많은 마스터 데이터를 생성하거나, 정리작업과 같은 house-keeping 을 정말 못하거나(저희가 도와드릴 수 있습니다), 작년에 전년도보다 더 많은 트랜잭션을 생성한 경우가 아니라면, QA 시스템의 크기는 동일하게 유지될 수 있습니다(물론, 다소 차이가 있을 수 있습니다). 이 경우 Client Sync 솔루션 (EPI-USE Labs의 Data Sync Manager 제품군의 일부)을 활용하여 모든 사용자 지정, 마스터 데이터 및 지난 6개월과 같은 특정 기간의 트랜잭션만으로 비운영 시스템을 구축할 수 있습니다. 이 정도면 테스트 목적으로 필요한 전부가 될 것입니다.
또한, 이 솔루션은 여유 공간도 제공합니다. 마스터 데이터가 더 많아지거나 트랜잭션이 더 자주 발생하여 데이터 조각(data slice) 이 늘어나기 시작하면, 조각 날짜를 조정하여 약간 더 작게 만들거나, 특정 대표 회사 코드로만 선택영역을 제한하여 하드웨어 투자를 1~2년 더 연기할 수 있습니다.
이는 동전의 한쪽 면에 불과합니다. 테스트 시스템에서 실제로 더 많은 작업을 수행하고 특정 프로젝트 또는 파일럿을 위한 소규모 클라이언트를 추가로 확보할 수 있는 잠금 해제 기능도 있습니다. 시스템이 모든 비즈니스 프로세스가 실행되는 영역이 아니라, 이를 뒷받침 하는 디지털 백본이 되면서 S/4HANA 세계에서는 이러한 기능이 점점 더 필요해질 것입니다. 클라우드 애플리케이션은 다른 프로젝트를 방해하거나 영향을 받지 않고 인터페이스를 테스트할 수 있는 전용 백엔드 클라이언트가 필요합니다. 따라서, 단기적으로 비용을 절감하는 것이 장기적으로 비즈니스의 번창을 지원하는 데 도움이 될 수 있습니다.
한국어 자막이 포함되어 있습니다.
S/4HANA 환경에서의 시스템 환경 및 테스트 데이터 관리 요구 사항에 대해 자세히 알아보고 싶으신가요? Paul Hammerley의 전자책을 다운로드하세요.
