클라우드 네이티브 및 REST 평가

이 단원에서는 클라우드 네이티브 어플리케이션을 빌드하고 ABAP에서 실행할 수 있는 모델인 ABAP Cloud 개발 모델(ABAP Cloud)을 살펴봅니다. 그러나 ABAP 클라우드는 부분적으로 클라우드 컴퓨팅의 등장과 클라우드 네이티브 패러다임에서 영감을 얻으므로 두 주제에 대한 간략한 논의가 보증됩니다.

S4CP01: SAP Cloud ERP 살펴보기 과정에서 논의한 바와 같이, 최근의 비즈니스 환경에서 기업들은 변화하는 비즈니스 조건과 변화하는 고객 요구에 대응하기 위해 비즈니스 프로세스를 신속하게 조정해야 합니다. 이러한 조정 요구사항에는 확장 가능하고 견고하며 중요한 유연성이 필요한 어플리케이션이 필요합니다. 클라우드 컴퓨팅 환경은 이러한 요구사항을 해결하는 한 가지 방법입니다. 다른 하나는 클라우드 네이티브입니다.

클라우드 컴퓨팅은 여전히 컴퓨팅이지만 클라우드 컴퓨팅은 과거에 IT 인력이 사용했던 일반적인 온프레미스 데이터 센터 인프라와는 다른 방식으로 설계되었습니다. 온프레미스 인프라(온프레미스 데이터 센터라고도 함)를 사용하는 경우, 고객은 서버 및 네트워킹 설비와 같은 물리적 요소의 설치 및 유지보수를 담당합니다. 클라우드 컴퓨팅을 사용하면 이러한 인프라 컴포넌트가 외부 클라우드 제공자에 의해 제공됩니다.

일반적으로 클라우드 제공업체는 다음 컴포넌트를 제공합니다.

• 네트워크
• 서버(컴퓨팅 및 메모리 용량 제공)
• 저장소
• 운영 체제 및 가상화

이러한 컴포넌트의 초기 설정과 진행 중인 운영, 유지보수 및 업그레이드는 클라우드 제공자가 처리합니다.

이러한 컴포넌트는 다음 원칙을 사용하여 고객에게 제공됩니다.

• 탄력성(Elasticity)

  대부분의 조직은 리소스 사용 시 피크 및 계곡을 경험합니다. 예를 들어 급여 계산은 한 달에 두 번 실행될 수 있으며 이 경우 추가 네트워크 및 서버 용량이 보증됩니다. 클라우드 프로바이더는 일반적으로 제공의 일부로 고객을 위한 탄력적 기능을 제공합니다. 이렇게 하면 더 많은 리소스가 필요하므로 리소스를 할당할 수 있으며 개별 및 전체 어플리케이션 성능을 원하는 레벨에서 관리할 수 있습니다.

• 가격결정

  클라우드 컴퓨팅 컴포넌트는 합의된 가격 책정 및 소비 플랜트로 고객에게 제공됩니다. 이는 제공자마다 다를 수 있습니다. 예를 들어, SAP는 SAP BTP를 제공하는 PaaS(Platform as a Service)의 일부로 asubscription-based 계획뿐 아니라 두 가지 유형의 소비 기준 구매 계획으로도 다양한 런타임과 서비스를 제공합니다.

• 가용성

  앞에서 언급한 급여 계산 예제로 돌아가면 클라우드 컴퓨팅 리소스의 가용성은 월 2회(월 2회 급여 계산 실행 가정)입니다. 다른 유형의 비즈니스 프로세스(예: 공급망 관리 프로세스)의 경우 해당 프로세스의 유형과 회사의 운영 방식에 따라 가용성이 달라집니다. 특히 대규모 조직에서는 하루 24시간, 일주일에 7일 동안 적어도 하나의 프로세스를 실행하려면 리소스가 필요하다는 것이 공정합니다. 바로 가용성이 필요한 부분입니다. 클라우드 제공업체는 자사 제품의 일부로 자사 구성요소의 예상 가용성을 고객에게 투명하게 전달합니다. 또한 기술적으로 필수는 아니지만 거의 모든 제공자가 연중무휴(24x7) 가용성 옵션을 제공하여 특정 작업이 연속적으로 또는 예측할 수 없는 간격으로 실행되어야 하는 경우 고객에게 최대한의 유연성을 제공합니다.

• 서비스 레벨 계약(SLA)

  가용성과 밀접하게 관련된 것은 서비스 레벨 계약(SLA, Service Level Agreement)입니다. 가용성은 일반적으로 숫자(연중무휴)로 표현되는 반면, SLA는 시간 차원(즉, 월의 99.99%에 대해 연중무휴)을 더합니다. 이 예제를 사용하여 한 달에 30일이 43,200분(하루 30일의 24시간 x 시간당 60분)으로 환산되는 경우 99.99%의 SLA에서는 약 4~30분(.0001배 43200) 동안 시스템을 사용할 수 없습니다(해당 월에 걸쳐).

처음에는 "제공자 외에는 클라우드 컴퓨팅과 고객이 제공한 데이터 센터 간에 실제적인 차이가 없는 것 같습니다"라고 생각하는 경향이 있을 수 있지만, 이러한 상황은 그렇지 않아야 합니다. 클라우드 제공자가 컴퓨팅 인프라를 제공함에 따른 결과로 인해 소프트웨어 어플리케이션은 인프라에 종속되지 않도록 설계되어야 합니다. 클라우드 제공자가 제공하는 특정 서버, OS 또는 저장소 시스템에 관계없이 동일하게 실행되어야 합니다. 클라우드 제공자가 인프라를 자주 변경할 수 있다는 것은 전적으로 생각할 수 있습니다. 또한 고객이 클라우드 제공자를 변경하기로 결정할 수 있습니다(즉, 다른 제공자가 상위 SLA 성능을 제공함). 또한 어플리케이션을 빠르게 조정해야 한다는 것은 서로 다른 유형의 인프라에서 어플리케이션을 테스트하여 호환성을 보장할 필요가 없으며, 여러 인프라 유형에서 실행될 수 있도록 어플리케이션의 다른 버전을 개발하는 데 드는 시간과 비용을 언급하지 않아도 된다는 것을 의미합니다. 개발자의 관점에서(그리고 궁극적으로 최종 사용자) 클라우드 컴퓨팅에 사용되는 인프라 컴포넌트는 추상화입니다.

이러한 추상화를 위해서는 클라우드 컴퓨팅에서 애플리케이션 개발 및 유지보수를 수행하는 데 사용되는 프로그래밍 모델, 툴 및 기술을 위에서 아래로 재구상해야 합니다. 클라우드 네이티브는 이러한 재구상의 결과로 등장했습니다.

클라우드 네이티브는 무엇보다도 클라우드 컴퓨팅 환경에서 소프트웨어 애플리케이션을 개발, 배포, 유지보수하는 접근 방식으로서 신속한 애플리케이션 적응성과 유연성을 제공합니다. 클라우드 네이티브의 특정 정의는 소스마다 다르지만, 사용 중인 정의에 따라 모든 정의가 일반적으로 동의하고 ABAP Cloud 개발 모델을 이해하는 데 매우 중요한 몇 가지 컴포넌트가 있습니다.

• 인프라 비종속
• 마이크로 서비스
• 어플리케이션 프로그래밍 인터페이스(API)

앞서 언급한 바와 같이, 클라우드 제공자는 클라우드 컴퓨팅 환경(네트워크, 서버(컴퓨팅 및 메모리 용량 제공), 스토리지, 운영 체제, 가상화)으로 구성된 인프라 컴포넌트를 제공합니다. 다양한 클라우드 제공자가 다양한 기술, 구성, 브랜드 등을 사용하여 이러한 리소스를 제공합니다. 클라우드 네이티브 어플리케이션은 이러한 차이점과 클라우드 제공업체에 관계없이 동일하게 실행됩니다.

많은 클라우드 네이티브 프로그래밍 모델이 어플리케이션 개발에 대한 3계층 접근법을 따릅니다. 첫 번째는 최종 사용자가 상호 작용하는 사용자 인터페이스의 시각적 렌더링을 담당하는 사용자 계층(사용 계층이라고도 함)입니다. 두 번째는 데이터 레이어로서, 어플리케이션에서 필요로 하는 데이터가 일부 데이터 소스(일반적으로 데이터베이스)에 영구적으로 저장되는 위치입니다. 이 두 계층 사이에 서비스 계층이 있습니다. 서비스 계층은 한 쪽에서 사용자 계층에 의해 트리거된 요청에 응답하므로 데이터 레이어 레벨에서 데이터 소스의 데이터에 대한 작업을 수행합니다. 이러한 작업은 일반적으로 CRUD 작업이라고 하는 다음 네 가지 유형으로 분류됩니다.

• 생성
• 읽기
• 업데이트
• 삭제

이러한 레이어는 필수는 아니지만 여러 위치와 다양한 유형의 런타임 환경에서 실행되도록 설계되는 경우가 많습니다. 이러한 위치와 환경 중 일부는 클라우드 기반일 수도 있고, 다른 곳에서는 온프레미스일 수 있습니다. 이러한 하이브리드 접근법은 흔하지 않으며 많은 고객이 사용합니다. 마이크로 서비스 디자인은 각 계층이 자체 독립 실행형 피스로 구현됨을 의미합니다. 이와 같이 다른 계층과 별도로 유지보수하고 조정하는 동시에 완전한 어플리케이션의 컨텍스트에서 통신하고 조정할 수 있습니다.

이전 섹션에서 참조된 통신 및 조정은 API를 사용하여 수행됩니다. API는 두 개의 소프트웨어가 서로 통신하고 합의된 데이터 정의 및 표현을 사용하여 정보를 교환하거나 조작할 수 있는 기술입니다(흔히 프로토콜이라고 함). 예를 들어, 대부분의 사용자가 사용한 앱은 계좌 잔액 점검, 청구서 지급을 위한 자금 이체 시작 등 다양한 기능을 실행할 수 있는 은행 업무 앱입니다. 이 앱은 은행 웹 사이트를 사용하여 인터넷을 통해 자유롭게 액세스하거나 휴대폰에 설치할 수 있습니다. 어느 쪽이든 앱의 디자인은 백그라운드에서 하나 이상의 API를 사용하여 앱 최종 사용자가 요청한 다양한 뱅킹 기능을 수행하는 것입니다. 각 API는 앱에 필요할 수 있는 몇 가지 태스크를 수행하도록 설계되었으며 일반적으로 "온디맨드"를 사용할 수 있습니다. 사용은 일반적으로 "호출 및 응답" 프로세스의 일부 형태를 기반으로 합니다(즉, 앱이 API에 대한 호출을 만들고 API가 어떤 방식으로 응답함).

이 시나리오의 은행은 (은행 계좌의 법적 거버넌스가 있으므로) API를 제공하며, 이를 재량에 따라 서드 파티 사용(예: 뱅킹 기능을 추가하려는 제품을 설계하는 개발자)이 사용할 수 있도록 하고 자체 앱 개발에 API를 직접 활용할 수 있습니다. API는 수십 년 전부터 사용되어 왔습니다. 그러나 API 개념은 클라우드 컴퓨팅과 마이크로 서비스 개발의 요구사항을 포괄하도록 진화해 왔습니다. 이러한 진화된 방식 중 하나는 오늘날 가장 일반적인 API 아키텍처 중 하나인 REST(Representational State Transfer)를 채택하는 것입니다.

API를 사용하여 은행 업무 앱의 예시를 계속하여, 예를 들어 계정 잔액을 확인하기 위해 중요한 REST 용어를 학습할 수 있습니다. REST 아래에는 어플리케이션에 필요할 수 있는 정보, 즉 "리소스"(이 경우 은행 계좌)를 나타내는 데 사용되는 특수 용어가 있습니다. 이 리소스에는 "상태"(항상 은행 계좌에 잔액이 있음)가 있으며 이 상태가 변경될 수 있지만(은행 잔액이 위/아래로 이동) 언제든지 이 상태가 존재합니다. REST 용어에서는 이 상태를 일반적으로 "리소스 표현"이라고 합니다. 이 상태는 ("내 잔고를 말해, 제발") 요청할 수 있으며, 심지어 이 상태에 대한 변경을 시작할 수 있습니다 ("여기 내 계정에 입금 할 수표가 있습니다; 내 업데이트된 잔액을 말해"). 마지막으로, 앱과 API 간의 모든 통신은 인터넷을 통해 이루어집니다. 즉, 상태를 앞뒤로 "전송"해야 합니다. [Resource] "Representational" "State" "Transfer"가 있습니다.

• 일련의 아키텍처 제약 조건
• 개발자가 API를 생성할 때 따르는 규칙 세트
• 클라이언트, 서버 및 리소스로 구성되며 HTTP를 통해 관리되는 요청으로 구성된 클라이언트-서버 아키텍처
• 상태 비저장 클라이언트-서버 통신 - 요청 간에 클라이언트 정보가 저장되지 않으며 각 요청이 분리되고 연결되지 않음

REST API는 다음 원칙을 중심으로 고정되어 있는 아키텍처 패턴을 기반으로 개발됩니다.

• URI(Uniform Resource Interface)

  리소스(여기서는 은행 계좌)는 하나의 주소 지정 메커니즘을 기반으로 고유하게 식별됩니다. (예: http://www.somebankserver.com/Account).

• 클라이언트-서버

  마이크로 서비스 디자인 접근법과 일치하는 클라이언트(이 경우 앱)와 서버(API가 있는 위치)는 인터넷을 통해 서로 통신하는 별도의 계층입니다.

• 상태 비저장

  상태 비저장 전송 절차는 클라이언트가 요청을 하고(앱에서 은행 잔액 점검 요청) 서버 호스팅 API가 잔액을 응답으로 전송하는 경우 API는 해당 요청에 대한 정보를 저장하지 않음을 의미합니다. 두 번째 분할 후에 앱에서 동일한 계정의 은행 잔액 점검을 다시 요청하는 경우, API는 이전 요청과는 아무 것도 사용하지 않고 새로운 요청으로 처리합니다(인식되지도 않음).

  인터넷에서 가장 많이 사용되는 응용 프로그램은 HTTP 프로토콜을 사용하여 다양한 클라이언트와 서버 간에 정보를 주고받는 월드 와이드 웹(Web)이다. HTTP 프로토콜은 상태 비저장이므로 전송에 사용되는 프로토콜 REST의 역할을 합니다.

• 캐시 가능

  확장성 및 성능을 개선하기 위해 REST API에 대해 캐싱을 구현할 수 있습니다. 특정 데이터를 이러한 방식으로 저장하여 빠른 액세스를 통해 요청에 더 빠르게 응답할 수 있습니다. 예를 들어 은행 계좌 잔액은 원격 데이터베이스에서 검색되는 대신 캐시에 저장할 수 있습니다.

• 계층적 시스템

  중개 시스템이 허용됩니다(예: 부하 분산 또는 인증 수행). 클라이언트가 이러한 중간 시스템을 인식하지 못할 수 있으며 클라이언트-서버 통신이 부정적인 영향을 받거나 손상되지 않습니다.

• 요청 시 코드

  서버는 실행 코드(예: JavaScript)를 클라이언트로 전송하여 클라이언트 기능을 확장할 수 있습니다. 이는 선택사항인 원칙 중 유일한 원칙입니다.

앞에서 설명한 것처럼 서비스 계층은 사용자 계층과 데이터 계층 사이에 위치하며 둘 사이의 통신을 중재합니다. REST API는 서비스 계층에 있으며 클라이언트-서버 통신에서 서버로 작동합니다(사용자 계층이 클라이언트 역할을 함). REST는 HTTP를 기본 전송 및 통신 프로토콜로 사용하므로 모든 REST API 요청도 HTTP 요청입니다. 클라이언트는 다음과 같이 네 가지 기본 HTTP 메소드를 사용하여 REST API와 상호작용합니다.

• 리소스에 대한 생성 작업을 수행하기 위한 HTTP POST
• 하나의 특정 리소스를 검색하기 위한 HTTP GET
• 리소스에 대한 업데이트 작업을 수행하기 위한 HTTP PUT
• 리소스 삭제를 위한 HTTP DELETE

클라이언트는 이러한 메소드를 기반으로 하는 HTTP 요청을 REST API로 전송하여 해당 리소스에 대해 요청된 작업을 수행하고 HTTP 응답을 클라이언트에 다시 보냅니다.

앞서 언급한 바와 같이, REST는 클라우드 네이티브 접근법의 일부로 사용되는 더 인기 있는 API 아키텍처 중 하나가 되었습니다. 마이크로서비스 디자인과 REST API를 사용하는 클라우드 네이티브 어플리케이션은 세련된 최신 사용자 인터페이스를 통해 모바일 어플리케이션 및 데스크톱에서 실행되는 앱에 대한 현대적인 소비자 기대치의 요구사항에 적합합니다. 특히 SAP와 ABAP은 이러한 기대로부터 영향을 받지 않습니다. 그 결과, ABAP가 클라우드 컴퓨팅과 클라우드 네이티브 개념을 수용하기 위해 진화할 필요성이 대두되었습니다.