[keyword] 15장 - 사례연구 : 고객에게 짓밟히다

[leejaeseung]

주제

'15장 - 사례연구 : 고객에게 짓밟히다'을 읽고 내용을 요약하거나,
중요✨ 하다고 생각하는 키워드 및 관련 설명을 코멘트로 달아주세요

연관 챕터

42

---

@caffeine-library/readers-release-everything

[leejaeseung]

15.3 부하 테스트

부하 테스트의 목적

책에서 필자의 부하테스트 이야기가 나와서 이전에 프로젝트를 진행하며 느꼈던 부하 테스트의 목적과 의의에 대해 간략히 소개드려 봅니다.

처음에 부하 테스트를 할 때 세웠던 기준은 “x 정도의 트래픽을 처리할 수 있는가?” 였습니다. 애플리케이션이 감당하지 못할 때까지 트래픽을 늘렸고, 감당하지 못하는 트래픽의 정도가 예상보다 크다면 부하 테스트가 잘 되었다고 판단했죠. (~~ 정도 트래픽이면 괜찮아요! 라고 증거자료를 남기는 느낌?)

그러다보니 부하 테스트의 결과라고 할 만한 것이 남지 않았고, 운영을 해도 잘 될거야 라는 자신감만 남았었습니다..ㅋㅋ 그러던 중 시니어 개발자분께서 부하테스트는 트래픽이 몰리는 상황에 얼만큼의 스케일 아웃을 해야하는지를 측정하는 과정이라는 말씀을 하셨습니다. 하나의 팟이 몇 TPS 를 버티는지를 부하 테스트를 통해 알아내고, 트래픽이 몰릴 것으로 예상되는 시점에 측정치를 통해 스케일 아웃을 해서 대비할 수 있게끔 하는 것이 부하 테스트의 목적이라는 말씀이셨죠. 부하 테스트 외에도, 운영 중인 애플리케이션의 상태를 모니터링하며 애플리케이션이 임계치에 도달했을 때의 TPS 를 계산해서 해당 애플리케이션의 인스턴스 당 한계치를 계산하는 것도 필요하다는 걸 배우고 있습니다 ㅎㅎ

[kth990303]

안정성 패턴을 적용해서 전체 시스템을 구축했다고 하더라도 전혀 새로운 시스템이란 말은 운영 환경에서 어떻게 돌아갈지는 아무도 모른다는 뜻이기도 하다. 처리 능력, 안정성, 제어, 적응성 모두 커다란 의문이다. (p.381)

• 실제로 이 문장을 읽기 전까진, 서비스 변경을 유연하게 할 수 있도록 아키텍처를 설계하고 구현했다면 해결될 문제일 것이라고 생각했습니다. 하지만 100% 해결이 보장되진 않는다는 것을 이 문장을 읽고 느꼈습니다.

  서버는 사용자가 마지막으로 클릭한 후 일정 시간동안 세션을 살려둔다. 이 말은 사용자가 머문 시간보다 세션이 유지된 시간이 언제나 더 길다는 뜻이다. (p.384)

• 현재 사용자 수가 한계치에 비해 적음에도 불구하고, 서버가 다운된다면? 활성 세션 수 != 사용자 수임을 기억해보면 좋을 거 같다는 생각이 들었습니다. (다만, 요즘은 세션 기법보단 토큰 기법을 많이 써서 이 말이 아직 유효할지는 모르겠네요.)

• 성능 및 부하테스트를 할 때에도 최대 분당 (또는 초당) 요청 수, tps를 보고 사용자 수를 계산할 것이 아니라 활성 세션 수를 보고 계산해야되겠다는 생각도 들었어요.

  ~~ 이는 검색 엔진에서 고객이 들어올 때마다 애플리케이션 서버의 세션이 생성된다는 뜻이다. 단지 404 페이지를 제공하기 위해서 말이다. 그날 우리는 많은 SEO 주스를 잃었다. (p.387~388)

• Q. 404 페이지를 제공하는 이유가 무엇인지 사실 이해하지 못했습니다. 이전 URL로 안내하는 게 정상적인 방식인데 404를 왜 띄우지? 하는 의문이 발생했습니다.
  • 404 페이지를 띄우기 위해 수많은 세션이 발생한 문제라면, 이러한 경우에 해결책은 어떻게 되나요? 세션을 띄우기 전에 캐싱된 404 페이지 바로 띄워주기? 그러면 검색엔진으로 접근한 모든 사람들이 404 페이지를 보게 되는건가...?

• SEO 주스를 잃었다는 것은, 검색엔진으로 많은 사람들이 무한히 대기하고, 404 페이지를 보게 됐기 때문이 맞을까요?

  우리는 검색 엔진 하나가 초당 세션 10개를 생성한다는 것을 발견했다. 이 현상은 애플리케이션 보안 팀이 세션 쿠키를 사용하지 말고 세션ID에 쿼리 매개변수를 사용하라고 명령하여 일어났다(이것이 잘못된 결정인 이유가 기억나지 않으면 <11.1.2 취약한 인증과 세션 관리>를 다시 읽어보자). (p.388)

• 기억 안나서 다시 되돌아가서 읽고 왔습니다ㅋㅋ 세션ID가 담겨진 url이 공유됐고, 그 url에 많은 사용자들이 접근하는 순간 같은 세션으로 여러 명의 사용자가 접근하게 돼 부하가 발생하게 되는 이슈로 이해했습니다. (보안, 그리고 성능 모든 면에서 위험.) 관련 이슈를 다룬 옛날 블로그글도 발견했습니다. 다시 한 번 11장 내용 되돌아볼 수 있어서 좋았네요.

  둘째, 트래픽 조절 기능이 있어서 신규 세션 비중이 얼마나 허용되는지 결정할 수 있었다. 우리가 25%로 설정하면 이 관문 페이지에 대한 요청 중 25%만이 실제 홈페이지를 제공받게 된다. 나머지 요청은 나중에 방문해달라고 부탁하는 정중한 메시지를 받을 것이다. (p.390~391)

• 괜히 대기 리스트 큐를 많은 사이트에서 사용하는게 아니구나 싶었습니다. 실제로 학교 수강신청 홈페이지에도 최근에 도입됐더라고요.
• 25% 라는 설정값이 상당히 보수적이라는 생각이 들었는데요, 보통 이렇게 보수적으로 잡는지 궁금해서 의견을 들어보고 싶습니다.

[emiling]

콘웨이 법칙

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure

• 시스템을 설계하는 조직은 그 조직의 의사소통 구조를 모방한 구조의 설계를 만들어내게 된다
• 규범방식 : 소프트웨어에 구체화 되기를 원하는 의사소통 구조를 만드는 방식
• 기술양식 : 조직의 실제 의사소통 구조를 이해하는데 도움이 되도록 소프트웨어의 구조를 대응하는 방식