구성 가능성과 작동 가능성의 구분

우리는 최근 NGINX를 인수한 데 따라 배달(앱 개발)과 배포(생산)의 구분에 대한 여러 블로그를 운영했습니다. 그중 하나는 오늘 살펴볼 개념인 운영 단순성 에 대해 간략히 언급했습니다.

"운영의 단순성"이라는 문구 뒤에는 구성 가능성과 운영성 사이에 분열이 존재합니다. 둘은 서로 극명한 대조를 이룹니다. 한편으로는 구성 가능성이 있습니다. 이는 네트워크, 플랫폼, 애플리케이션 서비스 계층에서 애플리케이션 서비스의 특성을 조작하는 능력입니다. 이를 통해 Nagle 알고리즘을 켜고 끄고, 프로토콜의 성능과 효율성에 영향을 미치는 설정을 조정할 수 있습니다.

다른 한편은 조작성입니다. 이를 통해 애플리케이션 서비스를 신속하게 배포, 관리 및 모니터링할 수 있습니다. 작동성에 대한 기대는 애플리케이션 서비스에 대한 지식일 뿐이며, 그 이상은 아닙니다. 운영자가 플랫폼이나 네트워크 계층의 전문가여야 한다는 요구 사항은 없습니다. 이를 달성하기 위해, 애플리케이션 서비스 계층에 존재하는 노브와 버튼을 제한할 수 있습니다. 주요 목표는 애플리케이션 서비스를 쉽게 배포하고 운영할 수 있도록 하는 것입니다.

이 중 하나는 복잡성을 초래합니다. 하나는 그것을 줄이는 것입니다. 전체 스택에 대한 깊이 있고 폭넓은 지식이 필요합니다. 다른 하나는 그렇지 않습니다. 각각은 애플리케이션을 안전하게 전달하는 데 중요한 역할을 합니다.

업무 분담

이러한 구분이 중요한 이유는 클라우드와 컨테이너가 애플리케이션 서비스 인프라를 보다 단순한 모델로 전환하라는 압력을 가하고 있기 때문입니다. 여러 가지 애플리케이션 서비스가 컨테이너에 의해 소비되고 있습니다. 부하 분산, 유입 제어, 모니터링, API 게이트웨이, API 보안은 성공적인 컨테이너화 전략에 필요한 구성 요소로 간주됩니다. 기본적으로 아키텍처의 변환은 애플리케이션 서비스 자체를 분할하는 것입니다. 일부는 데이터 경로에 배포하는 데 더 적합하고, 일부는 애플리케이션 아키텍처의 일부로 배포하는 데 더 적합합니다.

즉, 점점 더 운영(특히 DevOps) 부문이 온프레미스와 퍼블릭 클라우드에서 애플리케이션 서비스를 소비하고 있다는 뜻입니다. DevOps에 대한 기대에는 구성 가능성보다는 운영 성이 포함되기 때문에 이는 해당 애플리케이션 서비스에 큰 영향을 미칩니다 . DevOps는 TCP 스택을 조정하는 데는 특별히 관심이 없습니다. 대신 빠르고 빈번한 배포와 애플리케이션 가용성 유지에 관심이 있습니다.

이는 주로 더 빠른 전달 및 배포 속도를 요구하는 가치 실현 시간에 초점을 맞추기 때문입니다. 인프라를 엉망으로 만들 시간이 있는 사람은 없습니다. 시장에 출시해야 할 애플리케이션이 있으니까요.

하지만 그렇다고 해서 구성 가능성이 중요하지 않다는 것은 아닙니다. 특히 보안과 성능 측면에서 그렇습니다. 표준화된 네트워크와 플랫폼 스택은 어떤 것에도 최적화되어 있지 않습니다. 데스크톱을 최적화하는 동시에 모바일에 최적화하도록 조정할 수 없습니다. 클라우드나 온프레미스의 네트워크 에 최적화되어 있지 않습니다.

그리고 우리가 인정하든 인정하지 않든, 성과는 복합 측정입니다. 네트워크가 느리면 앱도 느려집니다. 가용성뿐만 아니라 성능을 보장하기 위해서는 네트워크 및 플랫폼 계층을 최적화하는 것이 매우 중요합니다. 그러므로 구성 가능성은 이를 활용할 수 있는 사람들에게 제공되어야 합니다.

이진 선택이 아닙니다

구성 가능성은 조작성만큼 중요합니다. 이는 실제로 이진 선택이 아닙니다. 애플리케이션 서비스의 소비는 이진 선택이 아니기 때문입니다. 오늘날 NetOps와 DevOps는 모두 애플리케이션 서비스를 사용합니다. 이러한 차이는 해당 애플리케이션 서비스의 배포 및 관리에 대한 기대치에서 발생합니다. NetOps에는 구성 가능성이 필요합니다. DevOps에는 운용성이 필요합니다.

기업에는 둘 다 필요합니다. 앱이 빠르고 안정적이지 않다면, 시장에 출시하는 속도가 아무런 도움이 되지 않기 때문입니다.

이러한 격차는 기술이 구성 가능성이 규칙이었던 세상과 작동 가능성이 기대되는 미래 상태 사이의 과도기 상태에 있기 때문에 발생합니다. 오늘날에는 운영자의 운영적 기대에 부합하는 애플리케이션 서비스를 통해 둘 사이의 격차를 메울 방법이 필요합니다. 그렇기 때문에 오늘날 F5와 NGINX의 조합이 매우 흥미로운 것입니다.

하지만 저는 구성 가능성과 조작성을 동시에 갖춘 미래가 있을 것이라고 봅니다. 그렇기 때문에 F5와 NGINX의 조합은 미래에 매우 유망합니다. F5와 NGINX가 어떻게 최신 API 관리를 제공하는지에 관심이 있으시다면, 곧 열릴 웨비나에 등록하세요 .