한빛출판네트워크

본 글은 Todd Decapua, Shane Evans가 지은 “Effective Performance Engineering(Free Download)”에서 발췌하였다.

퍼포먼스 엔지니어링을 응답 시간, 효율적 자원 활용, 처리량 등의 비기능적 요구사항을 만족시키는 행위로 정의하는 것과 달리, 요즈음은 그 단어의 의미가 더 넓게 확장되고 있다.

“퍼포먼스 엔지니어링”은 특정한 활동만을 지칭하지 않는다. 퍼포먼스 엔지니어링이란 이해하기 쉽고, 기술, 비즈니스, 사용자에게로부터 높은 성능을 이끌어 낼 수 있도록 하는 전사적으로 적용 가능한 기술들과 사례들을 말한다. 

퍼포먼스 엔지니어링은 조직, 기능적 요구사항, 보안, 사용 편의성, 기술 플랫폼 관리, 기기, 서드파티 서비스, 클라우드 등을 통틀어 제품의 질과 성능을 구성할 수 있는 사례들과 기능을 모두 포함하는 개념이다.

퍼포먼스 엔지니어링의 이해관계자는 비즈니스, 운용, 개발, 테스트와 품질 관리, 최종 사용자까지 전반을 포함한다.

하드웨어

1970년대와 1900년대까지의 퍼포먼스 엔지니어링의 목표는 비즈니스의 니즈에 하드웨어를 최적화하거나 더 정확하게는 서비스를 제공하는 역할을 하였다. 퍼포먼스 엔지니어링은 앞으로의 계획을 수립하는 기능을 하였는데, 많은 팀들이 운영 팀과 인프라 팀에게 보고받은 애플리케이션의 하드웨어 성능을 기반으로 하였다. (일부는 아직도 이런 기능을 한다. 이는 괜찮은 방법이다!)

하드웨어가 더 상품화 되고, 일반적으로 서비스에 클라우드와 가상환경을 적용함에 따라, 계획 수립의 기능은 더 빨리 고객에게 전달하는 개발작업에서 점점 더 뒷전으로 물러나게 되었다. 이제는 가상화 환경을 이용한 다양한 환경에서 개발, 테스트, 실사용 테스트 등을 점검하는 것이 낯설지 않은 풍경이 되었다. 가상화 환경은 비용 측면에서 더 효율적임과 동시에 다양한 환경에 자유롭게 접근할 수 있도록 해주었다.

클라우드는 서비스 제공자로 하여금 높은 수준의 가용성과 가상적으로 제한 없는 기능을 컴퓨팅 파워로서 제공이 가능하다는 장점이 있다. 그러나, 클라우드는 현재에는 최적화된 유저 경험이 존재하지 않는다. 클라우드 애플리케이션은 투자대비 최고의 효율을 얻기 위해서, 클라우드 환경상에서 최적화를 진행 할 필요가 있다.

소프트웨어

지난 30년동안 소프트웨어는 거대한 단일 소프트웨어에서 여러 개의 분산된 소프트웨어로 변화했다. 그리고 MVC 개념은 SOA 개념으로, 마이크로 서비스 아키텍처로 진화했다. 이 모든 것들이 변화, 실패의 횟수를 줄이고, 새로운 기능이 추가되었을 때 시간대비 가치를 향상시키기 위함이었다. 독립적인 컴포넌트는 개발자로 하여금 단일 컴포넌트의 행위를 테스트할 수 있도록 하였고, 이는 기존의 통합 테스트에서 다룰 수 없었던 부분이었다. 이러한 일들이 가능할 수 있도록 하는 작업들의 가정은 모든 컴포넌트들이 잘 동작한다는 가정아래에서 가능하다는 것이다. 그러나 거대하고 복잡한 분산 환경에서 시스템이 구동되면 성능, 사용자 경험에 영향을 줄 수 있는 많은 요인이 존재한다. 이 요인들은 직접적으로 소프트웨어에 영향을 끼치지는 않지만 네트워크 지연, 각 컴포넌트의 오류, 클라이언트의 행위 등 놓치지 않고 반드시 고려를 해야 하는 부분이다. 애플리케이션 컴포넌트를 빌드하고 테스트할 때 이 요인들을 고려하고, 최적화 하는 것이 매우 중요하다.

문화

모든 조직과 그룹은 나름의 목표와 비전을 가지고 있다. 이 목표들 안에는, 성능은 내재적으로 포함되어 있다. 하지만, 성능이 목표를 성취하기 위한 단계들의 의사결정의 영향을 끼치는 부분으로 포함되어야 한다. 이러한 의사결정에 대한 고려는 조직의 목표와 비전을 성취하는 문화 전반에 어떻게 퍼포먼스 엔지니어링이 적용될지 근간을 이루게 되기 때문이다. 우리는 MVC를 사용하거나 마이크로 서비스 아키텍처를 사용하거나, 새로운 패러다임(애자일 등의 새로운 단어)이 왜 우리의 비즈니스에 중요한지 등의 설계 철학과, 어떻게 성능이 우리의 비즈니스, 기술, 사용자에게 다름을 만들어 줄 수 있는지 등을 고려해야 한다. 성능은 프로젝트 시작부터 모든 요구사항과 연결 할 수 있어야 하고, 우리가 이미 이러한 작업 없이 프로젝트를 시작하였더라도 요구사항과 연관시킬 수 있어야 한다. 

조직과 사용자들의 성능 요구사항을 존중하는 문화를 만들기 위해서는, 몇 가지 장려해야 할 사항들이 있다. 하향식 방식이 아니라면, 상향식 기법을 사용할 수도 있다. 그러나 가장 먼저 고려해야 할 점은 우리의 비즈니스, 사용자, 팀에게 성능이 무슨 의미를 갖는지 수치화하는 것이다. 시스템의 모든 트랜잭션의 비용과 그에 따른 효과를 이해해야만 하고, 이것들을 어떻게 최적화를 하면 향상을 시켜서 성공에 가깝게 갈 수 있을지 그 방법을 찾아야만 한다.

이 방법론을 취하기 위해서는 모두가 책임감을 가져야 한다. 개발자, 테스터, 운영 팀만 아니라 모두가 가져야만 한다. 집단의 근본 속성이 돼야 하며, 성능이 우선이라는 것이 모든 이해관계자들 사이에 만트라(공통된 개념)처럼 작용해야만 한다.

사용자 경험은 성능을 고려할 때 우선시 되어야 하는 사항이다. 우리의 사용자 만족도는 사업의 성공과 실패를 좌우하게 될 것이다. 이러한 사용자 경험들을 수치화 할 수 있는 공식들이 82페이지에 서술되어 있다.

CPU 사용량 80%아래에 1000개의 서비스를 처리할 수 있느냐는 중요하지 않다. 만약 사용자가 느리거나 신뢰할만한 서비스라고 느끼지 못한다면, 그 결과는 실패했다고 여기게 될 것이다.

비즈니스

성능이 우리의 비즈니스에 무슨 의미를 가질까? 애버딘 그룹(Aberdeen Group)은 연간 1억 달러를 벌어들이는 160개의 회사를 설문하였는데, 1초의 응답시간 지연은 11%의 페이지 뷰를 감소시켰고, 7%의 서비스에 대한 관심과 16%의 고객만족도를 감소시켰고 밝혔다.

구글은 두 개의 서로 다른 페이지 디자인에 대하여 실험을 하였는데, 페이지당 10개의 검색 결과를 보여주는 페이지와 30개를 보여주는 페이지로 실험을 진행하였다. 페이지당 30개의 검색 결과를 보여주는 페이지는 수백 밀리초가 로딩이 요구되었는데, 이는 사용량이 20% 감소를 보였다. 구글에서의 트래픽은 페이지 클릭과 연관이 되어 있는데, 이는 수익으로도 높은 연관성을 보인다. 따라서, 20%의 클릭이 감소했다는 말은 20%의 수익이 감소했다는 말로도 볼 수 있다. 구글은 자사의 구글맵의 페이지 크기를 100킬로바이트 감소를 통해서 거의 3배의 사용자를 증가시켰다.  

응답시간과 수익은 구글에만 국한된 이야기는 아니다. 전직 아마존 직원은 100밀리초의 지연 시간 감소는 1%의 수익 증가로 이어진다고 밝혔다. 온라인으로 물품을 판매하던지, 시민들에게 건강증진 프로그램 가입 페이지를 제공하던지 관계 없이, 애플리케이션의 성능과 사업의 성공은 직접적으로 연관이 되어있다는 뜻이다.

*****

원문 : What is effective performance engineering?

번역 : 김준호