충분히 좋은 것은 더 이상 좋지 않을 때까지만 좋습니다.

터키에 대해 이야기해 봅시다. 아니면 크림 계란. 아니면 사탕 상자. 이들은 무엇이 공통점인가? 물론, 이는 모두 휴일과 관련이 있죠. 그리고, 그런 휴일은 웹사이트의 수익과 성과 저하를 동시에 가장 많이 가져오는 것으로 밝혀졌습니다.

영국의 최근 연구를 고려해 보십시오. "100명 이상의 전자상거래 의사결정권자가 참여했습니다." 이 연구에 따르면 "절반 이상(58%)이 작년의 성수기 동안 웹사이트 속도 문제에 직면했다고 인정했습니다."

이제 우리는 모두 성능이 중요하고, 마이크로초 단위의 지연도 수백만 달러의 손실을 초래한다는 것을 알고 있습니다. 더 이상 말할 필요도 없습니다.

문제는, 이에 대해 무엇을 할 수 있느냐는 것입니다.

답은 연산 공리 #2를 기억하는 데 있습니다. 부하가 증가하면 성능은 감소합니다.

앱 서버가 클라우드에서 실행되는지, 데이터 센터에서 실행되는지, 가상 머신에서 실행되는지, 컨테이너에서 실행되는지는 중요하지 않습니다. 이 공리는 항상 참이기 때문에 공리입니다. 무슨 일이 있어도. 시스템에 부하를 많이 주게 되면 시스템 실행 속도가 느려집니다. 기간.

더 나은 성능을 위한 핵심은 부하를 최대화하여 비용을 절감하는 것과 동시에 성능을 최적화해야 하는 필요성의 균형을 맞추는 것입니다. 대부분의 경우, 이는 특히 피크 기간(어디에 있든 시스템에 많은 부담을 주는 기간)에 균형을 회복하기 위해 가능한 모든 도구를 사용하는 것을 의미합니다.

1. 부하를 균형있게 조절하다

이것이 충분히 좋은 (기본적인) 앱 서비스가 아닌 이유입니다. 이러한 솔루션은 종종 손쉽게 확장할 수 있지만, 실제로는 사용 가능한 리소스에 걸쳐 부하를 분산시키지는 않습니다. 이러한 기능은 성능이나 기존 부하에 따라 리소스를 선택하는 데 필요한 정보를 제공하지 않습니다. 그들의 '최선의 노력'은 맹목적인 우연과 크게 다르지 않습니다.

부하를 분산하려면 기존 부하를 이해하여 새로운 요청이 가능한 한 신속하게 응답할 수 있는 리소스로 전송되도록 해야 합니다. 기본적인 부하 분산은 알고리즘 기반의 결정에만 초점을 맞추고, 사용 가능한 리소스의 정적 가중치 외에는 거의 고려하지 않기 때문에 이를 달성할 수 없습니다. 실시간 결정을 내리려면 지금 존재하는 부하에 대한 실시간 정보가 필요합니다. 그렇지 않으면 로드 밸런싱이 아니라 로드 분산이 됩니다. 

2. 부하를 줄이세요

부하를 분산하면서 성능을 높이는 데 도움이 되는 것은 단순히 리소스를 선택하는 것 이상입니다. 가용성을 해치지 않고 부하를 줄이는 다양한 프로토콜 향상 기능을 채택하는 것도 중요합니다. TCP 연결을 다중화하고 재사용하고, 암호화와 보안을 오프로드하고, 압축 작업을 상위 서비스에 재할당하면 앱과 웹 서비스의 부담이 줄어들어 리소스가 확보되고 성능에 실질적인 영향을 미칩니다.

서버는 클라우드나 데이터 센터에 있든, 컨테이너나 VM에서 실행되든 서비스를 제공해야 합니다. 암호화와 압축은 여전히 컴퓨팅 집약적인 기능으로, 해당 작업을 위해 설계된 상위 서비스에서 수행할 수 있습니다.

3. 부하를 제거하다

요청-응답 경로에서 불필요한 홉을 제거하면 성능도 향상됩니다. 네, 부하 분산 서비스 간에 수평적으로 확장할 수는 있지만, 그렇게 하면 의사 결정(라우팅)이라는 또 다른 계층이 방정식에 들어가게 되는데, 이는 실행(어느 것이 이 요청을 처리해야 할까?)과 전송 시간(네트워크를 통해 해당 서비스로 요청을 보내는 것) 모두에 시간이 걸립니다. 즉, 웹이나 앱 서버가 작업 을 수행하는 데 걸리는 시간이 줄어든다는 뜻인데, 이게 바로 우리가 원래 원하던 바였죠. 일반적인 부하 상황에서는 하나의 시스템이 백만 개의 연결을 관리하는 것과 열 개의 시스템이 각각 동일한 연결의 일부를 관리하는 것의 차이는 무시할 수 있습니다. 수요가 부하를 높이고 운영상의 공리도 그에 맞춰 적용될 때까지는 말이다. 성능 저하의 원인은 단순히 웹이나 앱 서버의 부하만이 아니라 앱 전송 체인 전체에 영향을 미치기 때문입니다.

부하 분산 서비스가 동시에 처리할 수 있는 용량(연결)이 많을수록 필요한 인스턴스 수가 줄어듭니다. 이를 통해 다른 서비스와 마찬가지로 운영 원칙 #2에 주의를 기울여야 하는 또 다른 계층의 리소스를 관리하는 오버헤드가 줄어듭니다.

성과는 소매업체에게 여전히 중요한 문제이며, 빠르게 확장되는 디지털 경제로 인해 (아직 그렇지 않다면) 디지털 존재감을 가진 모든 사람에게 문제가 될 것입니다. 휴일 전에 늘 겪는 서두름 속에서 사람들은 성과가 좋지 않은 것을 더욱 용납하지 못하게 됩니다. 어제는 좋았던 것이 이제는 그렇지 않은 것이다. 대부분의 경우 성능 문제는 애플리케이션의 잘못이 아니라 이를 제공하고 보호하는 데 사용되는 아키텍처와 서비스의 잘못입니다. 적절한 기능과 함께 적절한 서비스를 활용함으로써, 조직은 과부하 상황에서 성능 문제에 부딪히는 일을 예방할 가능성이 더 높습니다.

충분히 좋은 것은 충분했지만, 더 이상 그렇지 않게 될 때까지는 그렇지 않다. 그러면 실망한 고객을 다시 돌아오게 하는 것은 너무 늦습니다. 그들은 당신이 그들에게 팔려고 했던 것이 무엇이든 이미 다른 공급자를 찾았습니다.