앱을 더 빠르게 만들기

애플리케이션과 이를 기반으로 하는 네트워크를 분리하여 데이터 센터를 지속적으로 분할함에 따라 하나의 비즈니스 격언은 변함없이 진실입니다. 속도가 가장 중요합니다. 실적은 매출에서 생산성까지 모든 것에 영향을 미치는 기업 수준의 관심사로, 때로는 최종 이익까지 잠식하기도 합니다.

DZone의 최근 기사인 2016년 웹 애플리케이션의 속도는 얼마나 빠른가에서는 성능과 관련된 몇 가지 구체적인 내용을 다루며 "일반적인 웹 애플리케이션의 경우 거래의 4.2%가 포기된다"고 언급했습니다. 이는 "500개의 다양한 웹 기반 애플리케이션과 50억 개의 사용자 상호작용"을 기반으로 합니다.

물론, 그것이 달러로 어떻게 환산되고 이익이나 생산성에 영향을 미치는지는 사업 모델에 따라 달라집니다. 이는 수백만 달러 또는 수십억 달러의 손실이 될 수도 있고, 통화 시간이 늘어나면서 시간 손실이 발생하고 고객이 분노하게 될 수도 있습니다.

그럼에도 불구하고, 성능은 개발자와 운영자 모두에게 중요한 고려 사항입니다. 여기서 운영이란 인프라, 네트워크, 스토리지, 보안 등 모든 운영을 의미합니다. 최근의 애플리케이션 제공 현황 조사 결과에서도 모든 IT 역할에서 성과가 중요하다는 태도가 확인되었습니다. 더 나은 보안을 위해 포기할 가능성이 가장 낮은 항목(단 9%만 그런 거래를 하겠다고 답함)이며, 응답자의 14%가 멀티 클라우드 구현에서 직면한 심각한 과제로 이를 언급했습니다.

이러한 상황에도 불구하고 현재 앱 가속 서비스를 도입했다고 응답한 사람은 38%에 불과했고, 내년에 도입할 계획이라고 응답한 사람은 22%에 불과했습니다. 다소 놀랍게도 40%는 앱 가속을 배포하거나 사용할 계획이 없다고 답했습니다.

이는 "앱 가속"이 무엇을 수반하는지에 대한 인식이 다소 모호하기 때문일 수 있습니다. 그리고 "클라우드" 때문이 아니라 수년에 걸쳐 QoS에서 브라우저 기반 델타 새로 고침 및 캐시로 진화하고 변형되어 실제로는 성능 중심 기능을 갖춘 특수 프록시인 소위 애플리케이션 프런트 엔드(AFE)로 바뀌었기 때문입니다.

우리가 "앱 가속"에 대해 생각할 때, 대부분 압축 및 캐싱, 최소화 및 이미지 최적화를 떠올립니다. 우리는 프로토콜 최적화를 오늘날 기업과 사용자 기대에 만연한 "Warp 9가 필요해, 스코티"라는 사고방식의 일부로 생각하지 않습니다. 하지만 그래야죠.

아, 요즘은 프로토콜 오프로딩이 많이 쓰이는 것 같네요. 2015년에는 클라이언트 측 SSL 오프로드(사용자와 보안 HTTP를 관리하는 측) 사용이 80%에서 거의 100%로 증가했습니다. “Let's Encrypt!” 및 “SSL Everywhere”와 같은 노력으로 보안 통신에 대한 관심이 높아졌다는 점을 감안하면 이는 놀라운 일이 아닙니다. SSL/TLS는 성능에 영향을 미칩니다(좋은 방향으로는 아닙니다). 특히 부하가 증가할 때 그렇습니다. 유능한 프록시로 오프로드하는 것은 합리적이며, 많은 기업이 모든 것을 안전하게 만들면서 성능에 미치는 영향을 상쇄하기 위해 이를 활용하고 있습니다.

하지만 우리는 방정식의 백엔드, 서버 측에서 비슷한 증가를 보지 못했습니다. 지난 1년 동안 성능을 개선하고 동시에 리소스 용량을 늘리기 위해 TCP 멀티플렉싱을 사용하는 방식은 크게 바뀌지 않았습니다. 조직의 절반에 약간 못 미치는 수준(약 46%)이 이 알려지지 않은 최적화 기술을 사용하고 있습니다.

현재 많은 조직이 컨테이너 열풍을 겪고 있다는 점을 생각하면 무섭기도 합니다.

왜 무서운가요? 그 이유를 말씀드리겠습니다. 가상화를 통해 조직이 각 인스턴스의 TCP 스택을 미세 조정하여 앱당 가능한 가장 높은 성능을 보장할 수 있었을 가능성은 충분히 있지만, 컨테이너의 등장으로 이 모델이 위협받고 있습니다. 컨테이너는 단일 네트워크 스택을 공유하기 때문입니다. 한 컨테이너에 배포된 한 앱을 튜닝해도 동일한 호스트의 다른 컨테이너에 있는 다른 앱에 대한 최적의 구성이 보장되는 것은 아닙니다.

TCP 멀티플렉싱과 같은 TCP 기반 최적화는 프로토콜 계층에서 작동하므로 꿀오소리와 같습니다. 그들은 앱이 컨테이너에 있는지, 가상 머신에 있는지, 아니면 웹 플랫폼에 그대로 있는지 신경 쓰지 않습니다. 그들은 앱이 어떻게 또는 어디에 배포되었는지에 관계없이 해당 연결을 최대한 활용하고 성능을 개선할 것입니다. 이러한 서비스는 프로토콜에만 관심을 두고 클라이언트 측과 서버 측을 분리하여 클라이언트 측이 클라이언트에 최적화되고 서버 측이 앱에 최적화되도록 보장합니다. 즉, 성능이 두 배로 향상됩니다.

기존의 앱 가속 서비스와 기술은 정말 훌륭합니다. 오해하지 마세요. 위의 다채로운 차트에서 볼 수 있듯이, 기업은 이러한 모든 서비스를 활용하여 애플리케이션 성능을 개선하고 있습니다. 하지만 할 수 있는 일은 아직 많으며, 앞서 언급한 성과 데이터가 보여주듯이 해야 할 일 이상이 많습니다.

프록시(아마도 부하 분산에만 사용하는 프록시)를 살펴보고 현재 사용 중인 프록시보다 앱 성능을 위해 더 많은 것을 할 수 있는지 확인하는 것이 좋습니다.

F5가 앱을 더욱 빠르고, 스마트하고, 안전하게 만드는 방법을 알아보세요.