클라우드 가속 : 클라우드 네이티브로 전환

이 기사는 Ampere Computing의 "Accelerating Cloud Computing"시리즈의 세 번째 부분입니다. 여기에서 첫 번째와 두 번째 부분을 읽을 수 있습니다.

이 시리즈의 두 번째 부분에서 시연 한 바와 같이, 클라우드 네이티브 컴퓨팅 플랫폼에 응용 프로그램을 재배치하는 것은 종종 비교적 간단한 프로세스입니다. 예를 들어 Momento는 재배치 경험을 "Google의 Ampere 기반 클라우드 네이티브 플랫폼에서 즉시 실행하는 것보다 훨씬 적습니다 물론 응용 프로그램은 많은 구성 요소와 종속성으로 복잡 할 수 있습니다. 복잡할수록 더 많은 문제가 있습니다. 이러한 관점에서, Pelikan 캐시를 Ampere Cloud Native 프로세서에 배포 한 Momento의 경험은 많은 통찰력을 제공합니다. 이 회사는 가능한 한 모든 것을 자동화하고자하는 복잡한 아키텍처를 구축했습니다. 재배치 프로세스는이를 달성 할 수있는 기회를 제공합니다.

클라우드 네이티브 프로세싱에 적합한 응용 프로그램 가장 먼저 고려해야 할 것은 클라우드 네이티브 컴퓨팅 플랫폼에서의 재배치로 응용 프로그램이 어떻게 이익을 얻는 지 결정하는 것입니다. 대부분의 클라우드 응용 프로그램은 클라우드 기본 처리에 적합합니다. 클라우드 네이티브 접근 방식에서 가장 많은 혜택을 누릴 수있는 응용 프로그램을 이해하기 위해 Ampere Cloud-Native 프로세서 아키텍처를 신중하게 살펴 보았습니다. Ampere는 더 높은 처리 효율과 전력 소비량을 높이기 위해 핵심을 설계하기위한 다양한 접근 방식을 채택했습니다 비 클라우드 사용 사례에 추가 된 프로세서 기능. 예를 들어, 확장 가능한 벡터 스케일링은 애플리케이션이 다량의 3D 그래픽 또는 특정 유형의 고성능 컴퓨팅 처리를 처리해야하지만 전력 소비 및 핵심 밀도 측면에서 트레이드 오프를 가져올 때 유용합니다. 클라우드의 Android 게임과 같은 SVE가 필요한 응용 프로그램의 경우 클라우드 서비스 제공 업체는 Ampere 프로세서를 GPU와 페어링하여 3D 성능을 가속화 할 수 있습니다. 클라우드 네이티브 워크로드의 경우 Ampere 코어의 전력 소비 감소 및 코어 밀도 증가는 응용 프로그램이 전력을 덜 소비하고 열을 줄이는 동시에 응용 프로그램이 더 높은 성능에서 실행된다는 것을 의미합니다. 요컨대, 대부분의 응용 분야에서 클라우드 네이티브 컴퓨팅 플랫폼은 운영 비용을 줄이면서 탁월한 성능, 에너지 효율 및 컴퓨팅 밀도가 높을 수 있습니다.

Ampere는 많은 독립적 인 구성 요소가있는 마이크로 서비스 기반 응용 분야에서 특화되어 있습니다. 이러한 응용 프로그램은 더 많은 코어의 가용성으로부터 큰 이점을 얻을 수 있으며, Ampere는 단일 칩에서 128 코어의 높은 코어 밀도와 2 개의 슬롯이있는 1U 섀시에서 최대 256 코어를 제공합니다.

실제로, 수평으로 확장 할 때 (즉, 많은 인스턴스에 걸쳐로드 밸런싱) Ampere의 장점을 실제로 볼 수 있습니다. Ampere는 하중으로 선형으로 스케일링되므로 추가 한 각 코어는 직접적인 이점을 가져옵니다. 이를 X86 아키텍처와 비교하여 각 새로운 커널의 이점이 빠르게 감소됩니다 (그림 1 참조).

그림 1 : Ampere가 하중으로 선형으로 스케일하기 때문에 각 코어 추가는 직접적인 이점을 가져옵니다. 이것을 X86 아키텍처와 비교하여 각 새로운 커널의 이점이 빠르게 줄어 듭니다.

독점 종속성 응용 프로그램의 재배치에 직면 한 과제 중 하나는 독점적 의존성을 식별하는 것입니다. 이진 파일 또는 전용 X86 기반 소프트웨어 패키지를 사용하는 소프트웨어 공급망의 어느 곳에도 주목해야합니다. 이러한 종속성 중 다수는 파일 이름에 "x86"이 포함 된 코드를 검색하여 찾을 수 있습니다. 교체 프로세스는 일반적으로 완료하기 쉽습니다. X86 패키지를 적절한 ARM ISA 기반 버전으로 교체하거나 소스 코드에 액세스 할 수있는 경우 Ampere Cloud 기본 플랫폼에 사용 가능한 패키지를 다시 컴파일하십시오.

일부 종속성은 성능 문제를 일으키지 만 기능 문제는 아닙니다. X86 플랫폼에 최적화 된 코드를 사용하는 머신 러닝 프레임 워크를 고려하십시오. 프레임 워크는 여전히 클라우드 기본 플랫폼에서 실행될 수 있지만 X86 기반 플랫폼에서 실행되는 것만 큼 효율적이지는 않습니다. 솔루션은 간단합니다. AMPERE AI에 포함 된 것과 같이 ARM ISA에 최적화 된 동등한 버전의 프레임 워크를 식별합니다. 마지막으로 생태계 의존성이 있습니다. Oracle Database와 같은 응용 프로그램의 일부 상용 소프트웨어는 ARM ISA 기반 버전으로 사용할 수 없습니다. 이 경우 해당 버전을 사용할 수있을 때까지 재배치에 적합한 응용 프로그램이 아닐 수 있습니다. 클라우드 네이티브 친화적 대안으로 교체하는 것과 같은 이러한 종속성에 대한 해결 방법은 가능할 수 있지만 응용 프로그램을 크게 변경해야 할 수도 있습니다. 일부 종속성은 스크립트 (즉, Ansible의 Playbook, Chef의 요리법 등)와 같은 응용 프로그램 코드 외부에 있습니다. 스크립트에 특정 패키지 이름 또는 스키마를 가정하면 클라우드 네이티브 컴퓨터 플랫폼에 배포 할 때 변경해야 할 수도 있습니다. 이러한 변경의 대부분은 간단하며 스크립트에 대한 자세한 검토는 이러한 문제의 대부분을 보여줍니다. 개발 팀이 수년에 걸쳐 건전한 명명 가정을 조정하는 데주의를 기울이십시오. 현실은 이러한 문제가 일반적으로 다루기가 쉽다는 것입니다. 당신은 그것들을 철저히 식별하고 처리하면됩니다. 그러나 그러한 의존성을 해결하는 데 드는 비용을 평가하기 전에 기술 부채의 개념을 고려해야합니다.

기술 부채

Forbes 기사 "기술 부채 : 디지털 전환의 측정 가능한 장애가 어려워", 기술 부채는 "시스템에서 비교적 빠른 수리 또는 무겁지만 잘못 지시 된 투자의 축적은 장기적으로 재정적 일 수 있습니다. 장기적으로 이탈하면 "빠른 해결책은 시스템을 계속 운영 할 수 있지만, 기술 부채는 너무 높아서 무시할 수 없습니다. 시간이 지남에 따라 기술 부채는 커피 머신의 규모 축적이 결국 성능을 줄이는 것처럼 소프트웨어 시스템의 변화 비용을 증가시킵니다.

예를 들어, Momento가 Pelikan Cache를 Ampere Cloud Native 프로세서에 재배치했을 때 15 년 전부터 오픈 소스 코드에 의존하는 로깅 및 모니터링 코드를 설치했습니다. 코드는 작동하므로 업데이트되지 않습니다. 그러나 시간이 지남에 따라 도구가 변경됨에 따라 코드를 다시 컴파일해야합니다. 역 호환성을 유지하려면 일부 작업이 필요하며 이전 코드에 대한 종속성을 만듭니다. 이러한 모든 의존성은 수년에 걸쳐 축적되었습니다. 어느 시점에서, 이러한 종속성을 유지하는 것이 너무 복잡하고 비싸게되면 새 코드로 전환해야합니다. 기술 부채는 회수 될 수 있습니다.

클라우드 네이티브 컴퓨팅 플랫폼에 응용 프로그램을 재배치 할 때 현재 기술 부채와 결정을 내리는 방법을 이해하는 것이 중요합니다. 수년에 걸쳐 레거시 코드를 유지하고 조정하면 기술 부채가 축적되어 재배치가 더욱 복잡해집니다. 그러나 이것은 자체가 재배치 비용이 아닙니다. 다른 플랫폼으로 재배치하지 않기로 결정하더라도 언젠가 코드 업데이트를 연기하기 위해 이러한 모든 빠른 수정 및 기타 결정을 보충해야합니다. 당신은 아직 그렇게하지 않았습니다.

기술 부채는 얼마나 실제입니까? McKinsey 연구 (Forbes Article 참조)에 따르면,이 연구에서 CIO의 30%는 신제품 기술 예산의 20% 이상이 기술 부채와 관련된 문제를 해결하는 데 실제로 사용 된 것으로 추정했습니다.

레드 배치는 수년에 걸쳐 신청서에 의해 누적 된 기술 부채 중 일부를 해결할 수있는 좋은 기회입니다. 회사가 해결하기 위해 사용하는 기술 부채의 "20%"의 일부를 되 찾는 상상해보십시오. 이로 인해 재배치 프로세스의 시간이 증가 할 수 있지만 기술 부채를 처리하면 장기적으로 코드 관리 및 유지 관리의 복잡성을 단순화하는 이점이 있습니다. 예를 들어, 코드를 현재 개발 환경으로 마이그레이션하여 계속 의존하지 않고 많은 의존성을 "재설정"할 수 있습니다. 이것은 개발주기를 단순화하여 즉시 지불 할 수있는 투자입니다.

Plesk의 제품 관리자 인 Anton Akhtyamov는 재배치 경험을 설명했습니다. "포팅 후 몇 가지 제한 사항이 발생했습니다. Plesk는 많은 애드온 모듈/확장을 설치할 수있는 큰 플랫폼입니다. 일부는 Dr. Web 및 Kaspersky Antibirus와 같은 ARM에 의해 지원되지 않습니다. 그러나 일부 확장도 사용할 수 없습니다. 대부분의 확장 장치는 ARM을 위해 공급 업체가 재건 한 패키지를 사용하여 이미 지원됩니다 (주로 C). 중요한 문제 클라우드 네이티브 플랫폼에 응용 프로그램을 재배치하는보다 실제적인 예는 ARM 및 Ampere Altra의 OpenMandriva로 Takua를 포팅하는 것을 참조하십시오.

이 시리즈의 네 번째 부분에서는 응용 프로그램을 클라우드 네이티브 컴퓨팅 플랫폼에 재배치 할 때 기대할 수있는 결과에 뛰어들 것입니다.

위 내용은 클라우드 가속 : 클라우드 네이티브로 전환의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!