성능 측정 기술을 도입한다

[MyaGya]

이슈 설명

• 각자 생각한 성능 측정 기술에 대해 고려한다

• 성능 측정 툴

• 성능 측정 분야(압축, 캐시)

• 성능 측정 시나리오

[knae11]

고려사항

• DB에 얼만큼의 값을 넣을 것인지
• 우리 서비스에서 다량의 사용자는 얼만큼 존재할 것인지? (다량의 사용자가 존재한다고 가정할 경우, 어떤 경우에서 테스트를 진행할 건인지?)
• GM 서버는 얼만큼의 작업량을 돌릴 때, 현재 살아남을 수 있는지?
• 로그 데이터의 캐싱
• 시간 계산 현재 어떻게 해주고 있는지 궁금함?!ㅎㅎㅎ -> 이 항목도 캐싱될 수 있는지?

성능 개선점

• 로그 데이터 nginx 캐시 (frontcloud, nignx 둘다 캐시할 수 있을 것 같은데 서버측에서는 nignx 현재 리버스 프록시로 사용하고 있다고 생각하여 여기에 캐싱하는 방법이 가능할 듯 하다)참고링크

시나리오

1. GM에 public 주소를 넣을 때, 얼만큼의 작업이 가능한지 측정이 필요한가?
   • 예약이 엄청 많이 넣어지는 것도 측정을 해보아야 하는지? 혹은 GM이 동시에 얼만큼의 작업이 진행가는한지를 측정해야 하는지?
   • -> 사실 이 부분도 우리가 구현한 거지만, 예약시스템보다는 학습을 진행하는 GM 부분에 가깝다고 생각해서 이 부분도 테스트를 진행해야 하는지는 의문임)
2. 동시에 같은 작업에 대한 로그를 조회할 때, 몇명까지 조회해도 가능한지?
   • 현재 시나리오에서 다량의 사용자가 존재할 수 있는건지 의문임.
   • 랩당 연구원으로 진행할거면 필요 없다고 생각하고, 랩이 1개라고 가정한 뒤 전체에게 열어줄 거라면 확인하는 의미는 있다고 생각함
   • 지연시간이 얼만큼 발생하는지 측정
3. 로그를 캐싱한 뒤 얼만큼의 시간 지연이 단축되는지 측정, 몇명까지 동시조회가 늘어날 수 있는지 측정

기타 개선 도전과제_단일 장애점 지양

• 성능측정 기술은 아니지만, DB 레플리카(복제)를 도입하면 좋을 듯
• elasticsearch cluster를 3개로 구성해보면 좋을 듯
  • 다만, 구성 방법이나 구성했을 시 메모리를 얼마나 차지할지 의문이긴 함

[sjpark-dev]

웹 성능 테스트

• 도구: webpagetest, pagespeed
• 웹 성능 예산 설정: Timing based Metric, FCP
• 이유: 우리 서비스는 사용자가 선택한 화면을 빠르게 보여주는게 중요하다 생각

부하 테스트

• 도구: k6, smoke test
• 이유: 랩에서 사용을 해서 사용 인원이 많지 않을 것으로 예상하기에 시나리오 대로 잘 작동하는지 확인만 하면 충분하다고 생각

캐싱 전략

• 처음에는 캐싱 필요 없다고 생각했습니다.
• 왜냐하면 우리 서비스는 정적인 데이터가 없다고 생각했었기 때문이죠.
• 우리 서비스의 도메인은 수시로 상태값이 바뀌고 이에 따라 응답 데이터도 동적으로 바뀐다고 생각했었습니다.
• 하지만 위에 배럴이 말한 것 처럼 학습이 완료된 로그 데이터는 정적이고 이는 캐싱할 수 있다고 생각합니다.
• 문제는 학습이 완료된 이후 캐싱을 해야한다는 것이죠. 완료 이전에는 로그 데이터가 쌓이고 동적으로 변하는 상태이기 때문이죠.

압축 전략

• JSON을 gzip으로 압축하여 응답을 전송한다.
• 우리 백엔드는 API 서비스로 이루어져 있어서 모든 응답이 JSON으로 보내집니다.
• 이 JSON을 압축하면 데이터 사이즈를 줄일 수 있고 앱 성능을 향상 시킬 수 있습니다.
• https://www.baeldung.com/json-reduce-data-size

[knae11]

테스트할 상황

현상황파악

login 후, members/me 페이지 조회

• 3명 동시접속은 성공
• 9~10명까지 동시접속 가능, duration: 10s, threshhold 99<1.5s
• 250 정도 부터는 connectionpool 도 터짐

[MyaGya]

동시접속자 테스트 시나리오

1. 현재 우리가 가정한 테스트베드상 연구실 1개라고 생각했을때 Vuser 는 3이면 충분하다 -> 스크린샷

2. 그러나 연구실과 Vuser를 1:3이라고 했을 때 Vuser X 부터는 문제가 생기기 시작한다 -> 문제가 발생하는 시점 스크린샷

3. 따라서 VUser가 X 이상은 확장을 해야 하는 시점이고. 확장하지 않을 시 수용할 수 있는 연구소의 수는 X개이다

4. 확장은 동시 접속자 수를 늘려야 하므로 로드밸런싱을 사용하여 스케일아웃을 진행하던가 서버의 성능을 높여야 한다.

[ecsimsw]

1. gzip -> NginX & Spring (둘 다?) [에드]
2. 컨텐츠 캐싱 -> NginX [마갸]
3. DB 캐싱 -> Redis [배럴]
4. 로드밸런싱 -> 할?말? [코기]
5. HTTP2 / keep alive [완태]
6. 쿠버네티스

[MyaGya]

컨텐츠 캐싱

장점

1. 1분단위로 요청을 처리할 수 있다. -> 사용자가 아무리 많더라도 1분단위로 nginx 에 갱신된 캐시로 응답하기 때문

단점

1. 실시간 반영이 안된다.
2. 현재 방식으로는 백엔드 로직 침범이 발생한다. (동적 컨텐츠 캐싱)

고려할 점

1. 우리 서비스는 조회는 많이 일어나지만 job 추가는 적게 일어난다.
2. 정적 컨텐츠가 없는 상태에서 컨텐츠 캐싱 도입의 의미가 퇴색될 수 있다.
3. 시간 계산 등 전체 페이지에서
4. 캐싱 갱신 요청에 더 많은 리소스가 필요하지 않은가?