서비스 진단하기

이번 미션에서는 본격적으로 ‘성능’에 대한 점검 방법 및 필요성에 대해 학습했다.

  1. webpagetest, pagespeed를 활용하여 웹 성능의 예산을 고민하는 법
  2. 부하 테스트를 통해 점진적으로 목표치를 설정하는 방법
  3. USE 방법론을 활용하여 서버 진단 & Thread 덤프를 통해 서버의 이상점을 점검하는 방법

성능 점검과 그 개선점에 정답은 없다.
따라서 서비스 특성을 고려하고 정책적인 결정을 내려야 하기 때문에 많은 시간과 이해당사자간 협의가 필요하다.

하지만, 성능을 개선하는데 있어서 어느정도 기준이 필요하다.
크게 3가지로 나눌 수 있다.

  • 정량 기반(Quantity Based Metric)
    • ex1) 메인 페이지의 모든 오브젝트 파일 크기는 10mb 미만으로 제한한다.
    • ex2) 모든 웹 페이지의 각 페이지 내 포함된 자바스크립트 크기는 1mb 미만 이어야 한다.
    • ex3) 검색 페이지에는 2mb 미만의 이미지가 포함되어야 한다.
  • 시간 기반(Timing Based Metric)
    • ex) LTE 환경에서의 모바일 기기의 TTI(Time To Interactive)는 5초 미만이어야 한다.
  • 규칙 기반(Rule Based Metric)
    • ex) Lighthouse 성능 검사에서 80점 이상이어야 한다.

복합적일 경우 더욱 엄격한 시스템이 될 수 있을 지 언정,
각 성능 개선 목적의 기준은 상호 배제되는 기준이 아니다.
예를 들어, 메인 페이지의 모든 오브젝트 파일 크기는 10mb 미만 이면서,
Lighthouse 성늠검사에서 70점 이상 이라는 예산을 잡을 수 있을 것이다.

참고로 대표적으로 많이 활용되는 가장 중요한 예산은 아래와 같다.

  • 시스템에서 가장 트래픽이 많은 페이지, 가장 중요한 페이지 기준으로
    • 경쟁사 대비 20% 차이
    • 3초 안에 로딩

아무래도 사용자의 심리적인 요소가 감안된 것으로,
경쟁사 대비 20% 초과하여 느리거나, 3초 안에 로딩이 되지 않으면
대부분의 사용자들이 ‘느리다’라는 인식을 갖게 된다는 것이다.

OS의 리소스가 성능에 영향을 끼치는지 검증하는 방법으로
USE 방법론를 학습해봤다.

  • Utilization : 얼만큼 자원을 썼는 지
  • Saturation : 얼마나 많은 부하가 몰리는 지
  • Error : 에러가 발생했는 지

또한 성능 개선의 해결방법 차원에서 Scale up 혹은 Scale out 의 각각 개념에 대해 학습해보았다.

  • Scale up : 서버의 스펙을 올리는 것(메모리를 더 꽂는다 등등..)
  • Scale out : 장비를 추가해서 확장

회고

이번 미션에서 잘 한 점

성능 점검 필요성에 대한 높은 수준의 이해

성능 점검은 시스템을 운영하는데 반드시 필요한 행위이다.

이제까지 나를 돌아보면 어떤 기술의 개념에 집중해서 학습했던 경향이 있다.
혹은 유지보수성을 고려해서 소스코드를 작성하는 방법이라던지 철저히 개발을 하는 입장에서 모든 것을 고려했다.

부득이하게 이번 ‘서비스 진단하기’ 미션을 ‘레거시 코드 리팩터링’ 미션과 일부 겹치는 기간에 동시에 병행하게 되었다.
레거시 코드 리팩터링에서 자세하게 회고 해 볼 예정이지만, 이런 말이 나온다.
소프트웨어의 본질은 해당 소프트웨어의 사용자를 위해 도메인에 관련된 문제를 해결하는 능력에 있다.
나는 개발자로서 늘 ‘문제를 정의’하고 ‘해결법을 제시’하는 차원에서 학습하고 실제 업무에 적용해왔다.

하지만, 성능 점검은 철저히 사용자 측면에서 접근해야 한다.
사용자는 냉정하다. ‘3초 안에 로딩’이 되지 않으면, 그 서비스를 극단적으로 사용하지 않게 된다.
더 나아가선 그 서비스에 대해 좋은 감정을 가지지 못하게 된다.
따라서, 성능 점검은 어쩌면 개발의 모든 과정 중에서 가장 중요한 과정이라고 볼 수 있을 것 같다.

단순히 성능 점검하는 방법이나 어떻게 개선하는 지 방법에 대한 학습을 떠나서,
성능 점검 & 개선에 대한 필요성을 경험할 수 있는 좋은 시간이었다.

마지막으로 소프트웨어의 정의를 기업을 운영하는 입장에서 다시 정의를 해본다면, 아래와 같을 것 같다.
소프트웨어의 본질은 사용자의 문제를 소프트웨어를 통해 해결해주고, 그 대가로 상응하는 금전적 보상을 받는 것
이라고 볼 수 있지 않을까?

따라서, 성능 점검 및 개선은 사용자를 모으기 위해선 정말정말정말 중요하고,
이미 많은 기업들은 성능 개선을 위해 많은 투자를 하고 있다고 생각했다.

어려웠던 점

웹 성능의 예산을 고려하는데 정답은 없다

이번 미션에서 가장 어려웠던 점은 ‘성능 예산 설정’이었다.

위에서 다루었던 내용처럼 정량적인 기준은 설정할 수 있다.
다만 어느정도 예산을 두고 설정해야 ‘사용자가 만족할 수 있는 지?’에는 정답도 없고 끝도 없다.

따라서, 적절한 예산을 설정하는 것이 가장 어려웠다.

가령, 이번 미션에서 구축했던 시스템은 ‘지하철 노선도 검색 서비스’ 인데,
노선 검색기능에 대하여 경쟁사 대비 20% 예산, 3초 내 로딩 이라는 목적을 이루기 위해선,
이제까지 다루었던 ‘코드를 어떻게 효율적으로 작성하는가?’ 라는 문제를 떠나서,

경쟁사의 성능 자료, 사용자 수 등을 파악하는 것 조차 막막한 일 이었다.
결과적으론 웹 브라우저의 퍼포먼스 탭을 활용하거나, webpagetest, pagespeed 등을 활용해서
경쟁사의 성능을 확인 할 순 있었지만, 나의 서비스의 초기 사용자 수를 어느정도 설정해야 하는가? 등등
문제가 꼬리에 꼬리를 물고 계속해서 생겨났다..

‘정답이 없는 문제를 해결하라’는 것은 정말 어렵다.
이번 미션 중에서 ‘성능 예산 작성하기’가 나에겐 정답이 없는 문제 였다..

느낀점

이번 미션에서 잘한 점에서 밝혔듯이 성능 점검의 필요성에 대해 깊은 수준에서 고민할 수 있는 좋은 기회였다.

앞으로 프로그래밍과 관련된 학습도 꾸준히 진행하지만, 그에 못지 않게 성능과 관련된 학습도 병행해야겠다고 생각이 든다.
당장에 기획하고 있는 side-project 중 하나를 실제 서비스하는 수준까지 진행할 예정인데,
이와 관련해서 서비스 진단하기에서 학습했던 내용들을 반드시 적용하고, 계속 학습해야겠다는 생각이 들었다.