인상적인 성능 향상이 중요하지 않을 때

 (blog.colinbreck.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 성능 최적화는 복잡한 시스템을 이해하고 제품을 개선하는 강력한 수단이지만, 10배 빠른 결과도 실제 업무 방식이나 처리량을 바꾸지 못할 수 있음
  • 쿼리 응답을 5~10분에서 30초~1분으로 줄여도, 사람이 기다리며 주의를 유지하는 약 10초 임계값을 넘으면 체감 효과가 제한됨
  • 작업이 하루 1건·2건처럼 정수 단위로 묶이면 25~50% 개선만으로는 부족하며, 이동 시간을 포함해 각 작업이 4시간 이하가 되어야 하루 2건이 가능함
  • 데이터 파이프라인에서는 느린 단계가 상류에 백프레셔를 걸기 때문에, 단일 단계가 크게 빨라져도 모든 병목이 풀리기 전까지 종단 간 처리량이 늘지 않을 수 있음
  • 성능 개선은 개별 벤치마크가 아니라 원하는 결과를 기준으로 평가해야 하며, 주의 유지·작업 단위 증가·전체 처리량 같은 제약을 넘지 못하면 큰 개선도 실질 효과가 작음

성능 수치와 실제 결과가 어긋나는 이유

  • 성능 작업은 시스템을 더 효율적으로 만들고 고객에게 새로운 가능성을 열 수 있어 보람 있는 작업임
  • 규모와 부하가 걸린 복잡한 시스템이 어떻게 상호작용하는지 경험적으로 이해하는 데도 도움이 됨
  • 시스템을 가까이 다루는 과정에서 제품과 서비스를 개선할 아이디어가 나오며, 그중 일부는 성능 최적화와 직접 관련이 없음
  • 다만 “10배 빠름”, “리소스 50% 감소”처럼 보기 좋은 성과도 숨은 제약을 넘지 못하면 기대한 변화를 만들기 어려움

10초를 넘으면 사용자의 주의가 끊김

  • 새 데이터베이스의 쿼리 성능을 개선해, 기존 데이터베이스에서 가장 비싼 쿼리가 5~10분 걸리던 것을 30초~1분으로 줄인 사례가 있음
  • 이 결과는 10배 수준의 개선이었지만, 사용자 경험을 바꾸려면 또 한 번의 큰 개선이 필요했음
  • 인간-컴퓨터 상호작용 연구에서는 사람이 전체 작업에 주의를 유지하는 한계를 약 10초로 봄
    • 0.1초는 즉각적인 피드백으로 인식되는 임계값
    • 약 1초는 작업 흐름이 이어지는 임계값
    • 약 10초는 전체 작업에 대한 주의를 유지하는 임계값
    • 진행 표시기나 예상 시간 같은 피드백은 주의 유지에 도움을 줄 수 있음
  • 30초와 5분은 모두 10초를 넘기 때문에 사용자는 메시지를 확인하거나, 커피를 마시러 가거나, 대화를 시작하거나, 다른 작업으로 전환함
  • 사용자가 몇 분 또는 몇 시간 뒤 돌아왔을 때 UI가 이미 로드되어 있다면, 실제 대기 시간이 30초였는지 5분이었는지는 업무 방식에 큰 차이를 만들지 않음
  • 해당 프로젝트에서는 결국 다수의 쿼리를 10초 이하로 줄였고, 이전에는 타임아웃 때문에 불가능했던 일부 쿼리도 가능해짐
    • 데이터 쿼리 지연뿐 아니라 메타데이터 쿼리 지연과 웹페이지 렌더링 시간도 전체 성능 개선에 중요했음
    • 비동기 IO와 데이터 집계 개선으로 또 한 번의 10배 개선 가능성이 남아 있으며, 그렇게 되면 예전에는 몇 분 걸리던 쿼리가 1초 이하로 돌아올 수 있음

하루 1건에서 2건으로 넘어가는 임계값

  • 한 프로젝트에서는 수동 작업 자동화, 불필요한 단계 제거, 일부 병렬화, 나중에 비동기로 처리할 수 있는 단계 지연을 통해 전체 프로세스를 몇 시간에서 안정적으로 1시간 미만으로 줄임
  • 개선 폭은 대략 25~50% 였지만, 전체 프로세스는 물류 제약 때문에 바뀌지 않았음
  • 배관공, 전기공, 목수처럼 장소를 예약하고 이동한 뒤 작업을 완료해야 하는 경우를 생각할 수 있음
    • 하루 8시간 일하고 한 장소의 작업에 8시간이 걸리면, 2~3시간을 아껴도 새 장소로 이동해 새 작업을 끝낼 시간이 없음
    • 이동 시간을 포함해 각 작업이 4시간 이하가 되지 않으면 하루 2건을 완료할 수 없음
  • 이런 임계값을 넘기 전까지는 중간 단계의 효율 개선이 생산량 증가로 이어지지 않음
  • 성능에 집중한 덕분에 고객 경험에 직접 영향을 주는 품질과 안정성 개선도 함께 이뤄질 수 있음
    • 프로덕션에서 돌파구가 되지 못한 작은 성능 개선도 테스트 환경의 반복 속도를 높여 기능 개발과 결함 해결을 빠르게 만들 수 있음

백프레셔가 있는 파이프라인의 병목

  • 많은 비즈니스 소프트웨어 인프라는 차량, 공장 장비, 모바일폰, 금융 거래 같은 여러 소스의 이벤트를 처리하는 데이터 파이프라인을 포함함
  • 이벤트는 보통 내구성 있는 로그에 저장되고, 하류 서비스가 이를 소비해 처리함
  • 대규모 고처리량을 위해 로그는 파티션되어야 하며, 하류 서비스는 배치, 파이프라이닝, 병렬성, 효율적인 메모리 할당, 동적 확장 같은 기법을 사용함
  • 데이터 파이프라인의 병목은 시스템 동작이 서로 연관되어 있어 찾기 어려움
    • 느린 단계는 의도적으로 상류 단계에 백프레셔를 검
    • 병목이 여러 개 있으면 마지막 병목까지 제거되기 전에는 전체 처리량이 늘지 않음
  • 파이프라인을 단계로 나누고 각 단계의 성능 특성과 한계를 이해하는 것은 좋은 엔지니어링 관행임
  • 하지만 단일 단계를 여러 자릿수 규모로 개선해도 전체 처리량에는 영향이 없을 수 있음
  • 처리량 개선에서 중요한 수치는 개별 단계의 벤치마크가 아니라 종단 간 처리량임

병목을 찾는 경험적 접근

  • 이런 시스템의 동역학과 병목을 이해하려면 파이프라인의 시작점부터 경험적으로 확인하는 방식이 유용함
  • 예를 들어 분산 로그에서 이벤트를 읽고 버리는 단계부터 시작함
    • 이 단계만으로 목표 처리량에 도달하지 못하면 하류 단계를 최적화해도 시간 낭비가 됨
  • 데이터베이스에 초당 몇 행을 삽입할 수 있는지 같은 하류 벤치마크도 중요할 수 있지만, 분석은 상류부터 시작해야 함
  • 복잡한 시스템과 성능을 이해하는 데는 시뮬레이션도 가치 있는 방법임

성능 개선의 기준은 원하는 결과

  • 성능 작업은 어렵지만, 복잡한 시스템을 깊이 이해하고 더 나은 제품을 만드는 훈련이기도 함
  • 사람의 주의를 붙잡아야 한다면 약 10초 안에 응답해야 함
  • 전체 작업 단위가 제약이라면 퍼센트 개선만으로는 부족하고, 하루 1건에서 2건으로 넘어갈 수 있어야 함
  • 백프레셔가 있는 파이프라인의 처리량을 극대화하려면 한두 개 병목이 아니라 모든 병목을 해결해야 하는 경우가 많음
  • 이런 제약을 넘지 못하면 10배 수준의 성능 개선도 원하는 결과를 만들지 못함

함께 보면 좋은 글 β

GN⁺   [-]
Lobste.rs 의견들

  • 전체 처리량에 영향이 없는 단계 하나를 수십 배 개선하고 실망하는 경우라면, 여기서는 Amdahl's law 를 짚을 만함

    • 컴퓨터과학 전반의 여러 법칙 이름 모음 같은 게 있는지 궁금함
      계속 새 법칙을 듣게 되는데, 자주 쓰이지 않을 만큼 틈새라서 다시 잊어버리곤 함. 그렇다고 그런 법칙들이 세대 지식으로서 유효하거나 유용하지 않다는 뜻은 아님

  • 애초에 왜 전체 시간에서 아주 작은 조각만 차지하는 부분을 최적화하고 있었는지 의문임
    가이드가 나빴는지, 성능 도구가 부족했는지 모르겠음. 의식적으로 영향이 거의 없는 일을 하려는 사람은 드물고, 보통 더 큰 문제가 숨어 있음

    • 이런 일이 생기는 한 경로는 대략 이렇다고 봄
      어떤 문제를 보다가 샘플링 결과에서 특정 함수가 크게 보이고, 잠깐 살펴보니 구현을 꽤 쉽게 개선할 수 있어 보임. 하지만 지금은 다른 일을 하는 중이라 “나중에 처리하자”고 미뤄둠
      나중에 그 쉬운 개선을 떠올리고 시작하는데, 막상 수정이 생각보다 복잡해져도 터널 비전이 생기고 퍼즐을 풀고 싶어져 시간을 많이 쓰게 됨
      실제로는 그 성능 문제가 사소했을 뿐임. 당시 보던 맥락 안에서 비율상 커 보였거나, 절대 시간이 별 의미 없었거나, CPU가 아니라 입출력에 막힌 상황일 수 있음. 일종의 자기 자신에게 당한 nerd sniping에 가까움
    • Google에서 한 번, 파이프라인 일부를 최적화하겠다는 제안이 있었고 여러 사람이 그 부분이 전체 계산량의 0.1% 미만이라 전체 이득도 정의상 0.1% 미만이라고 설명했음
      그래도 무시하고 최적화를 진행했고, 전체 개선이 0.1% 미만으로 나오자 당황했음. 도메인 지식이 있으면 직관적으로도 비싸지 않은 부분이었지만, 시간을 낭비하지 않게 하려고 실제 성능 비용 측정까지 도와줬음
    • 추측으로 움직이거나, 항상 적용하는 모범 사례를 내면화했거나, 제한된 상황에서 본 실제 문제를 과도하게 일반화했을 수 있음
      또는 벤치마크가 오해를 불러왔을 수도 있음. 모든 시스템이 운영 환경에서 모든 메서드나 프로세스의 비용을 쉽게 보여주지는 않음
      이런 설명들은 정도 차이는 있지만 모두 기능 장애에 가깝고, 어떤 건 개인의 문제에 더 가깝고 어떤 건 환경의 문제에 더 가까움
    • 가능한 이유가 몇 가지 있음
      1. 재능 있는 주니어 엔지니어가 문제 해결은 배웠지만, 풀 가치가 있는 문제를 고르는 법은 못 배운 경우임. 발견한 모든 비효율을 종단 간 영향과 무관하게 공격함. 운이 좋으면 누군가 가르쳐주고, 아니면 PM이 단단히 통제해야 하는 시니어 엔지니어로 정체됨
      2. 종단 간 성능을 제대로 볼 수 없음. 시스템 어딘가 성능 저하가 있고 경영진은 압박하지만 제대로 된 모니터링 도입 권한은 못 받아서, 추측으로 여러 컴포넌트를 건드리다 하나가 맞기를 바람. 그러다 급한 불이 꺼지면 다시 사용자 기능 출시로 돌아감
      3. 지금은 문제가 아니지만 곧 문제가 될까 봐 미리 고치는 경우임. 영향력이 충분하거나 야근을 밀어붙일 수 있으면 당장 보이는 효과가 없어도 진행함. 훌륭한 엔지니어도 미래에 중요하다고 믿으면 이런 일에 정치적 자본을 쓰고, 덜 좋은 엔지니어는 전부 태워버림
        3.1. 하이퍼스케일러에서 일하면 사용자에게 전혀 보이지 않는 계산량 0.1% 절감만으로도 해변가 집값을 댈 만큼 손익에 영향이 생길 수 있음
      4. 도전을 참지 못하는 경우임. 실제로 아무것도 바뀌지 않을 걸 알지만 CRUD 앱만 만들다 지루해졌고, 블로그에서 본 걸 시도해볼 기회가 생긴 것임. 무의미함의 무게를 덜려고 스스로를 nerd snipe하는 셈임
    • 통념과 달리 많은 시스템은 몇 개의 병목으로만 구성되지 않음
      흔한 프로그래밍 관행 자체가 전반적으로 느린 경우가 많음. 예를 들면 포인터가 잔뜩 있고 일반 할당자를 통한 힙 할당이 엄청 많은 객체지향 코드가 떠오름. 어디를 고쳐도 전체 시간에서 작은 조각이라, 최악의 경우 완전 재작성 외에는 해결이 안 됨. 운이 좋으면 점진적으로 재작성할 수 있음
      병목이 두 개뿐이어도 서로 한 자릿수 배율 안에 있으면 최악의 병목을 완벽히 고쳐도 한 자릿수 배 개선조차 안 나옴. 많은 경우 글에서 말하듯 의미 있는 이득을 얻으려면 그보다 훨씬 더 크게 넘어야 함
      또 컴퓨터는 병렬로 돌아가는 분산 시스템에 가까움. CPU 몇 개, GPU, 디스크, Ethernet 등이 있고, 프로세스 속도는 파이프라인에서 가장 느린 단계가 제한함. 그 단계를 고치면 다음으로 느린 단계가 제한하고, 최악에는 가장 느린 단계가 여러 개라 하나만 고쳐서는 아무 이득도 없음
      그래도 이건 선의로 해석한 설명이고, 때로는 그냥 최적화 게임에 빠져 우선순위를 잃거나 실수하기도 함

  • 사용자가 알아차리지 못하더라도 소프트웨어의 계산 시간 절감은 여전히 좋음
    비용을 줄이고 확장을 더 쉽게 만들 수 있기 때문임

    • 그건 복잡도 비용에 달려 있음
      코드를 빠르게 만드는 대가로 과도한 복잡도가 들어오면, 유지보수성은 제쳐두더라도 장기적으로 성능을 해치는 후속 결과가 생김. 구조 변경 시 이제는 불필요해질 코드가 남는데, 그걸 이해하거나 제거하려면 전체 복잡도를 완전히 이해해야 하기 때문임
      “더 빨라진다”는 이유가 복잡도나 유지보수성 우려를 무시해도 되는 면죄부가 되어서는 안 됨

  • 지금 비슷한 상황에 있고, 여러 작은 프로젝트로 5분 걸리던 쿼리를 30초 미만으로 줄이고 있음
    장기적으로는 충분하지 않다고 팀에 말하지만, 분명 개선이고 영향도 큼
    고객 입장에서는 기다림이 격분할 수준에서 그냥 짜증나는 수준으로 내려감
    지금 초점은 사용자별 성능이 아니라 전체 성능임. 5분, 10분, 30분짜리 프로세스 수십 개를 최적화하면 시스템의 다른 부분과 생기는 경합이 크게 줄어듦. 10분 동안 데이터베이스를 두들기는 건 매우 긴 시간이고, 결국 모든 것이 더 빨라져 모두가 이익을 봄

답변달기