민스씨의 일취일장

후기 | F-Lab Java Backend 과정 12주차 본문

Personal Development/F-Lab 자바 백엔드 과정 [진행중]

후기 | F-Lab Java Backend 과정 12주차

읻민스 2024. 8. 21. 17:09
반응형

F-Lab Java Backend 과정 12주차 후기글입니다.

F-Lab Java Backend 과정 12주차

F-Lab 자바 백엔드 12주차 썸네일 이미지이다.
F-Lab Java Backend 12th Week

12주차 멘토링 주제

12주차 멘토링 주제는 아래와 같다.

프로젝트
1. 성능 테스트에서 사용할 메트릭 선정하기
2. 그라파나 커스텀 대시보드 만들기
3. 서비스 메모리 제한 설정
4. 성능 테스트 진행하기
...

이론
1. Database ACID & CAP
2. DDD
3. TDD
4. TEST (단위/ 통합/ 시스템/ 인수/ 회귀)

프로젝트

성능 테스트에서 사용할 메트릭 선정하기 & 커스텀 대시보드 만들기

성능이 좋은지 않좋으지를 판단하기 위해선, 성능이 좋다는 것이 어떤 것을 의미하는지 생각해볼 필요가 있다. 웹 서비스 운영이라는 측면에서 어떤 서비스가 좋은 성능을 갖고 있다고 말할 수 있을지 생각해 보았을 때 아래와 같은 것들을 꼽을 수 있을 것 같다.

  1. 빠른 반응 시간
  2. 어떠한 상황에서도 멈추지 않고 원활히 사용할 수 있는 가용성
  3. 작업한 내용이 내일가도 변형되지 않는 데이터 신뢰성

이런 것들을 위해서 "어떤 지표"들을 측정해야 하는지 알아보는 시간을 가졌다. 지표들을 선정한 다음 해당 메트릭들을 한 눈에 파악할 수 있도록 Grafana에 대시보드 까지 완성하였다.

 

Grafana | 성능 테스트 | 모니터링 | 필요한 지표들 선정한 뒤 그라파나 대시보드 생성하기

성능 테스트에서 측정할 지표들에 대한 글로, Github Issue #12의 1-2에 대한 내용입니다.성능 테스트 지표들 선정하기성능테스트를 기반으로 프로젝트를 진행할 계획이다. 이를 통해 적절한 최적화

ydmins.com

변인 통제 : 서비스 메모리 제한

앞으로 여러 목적으로 테스트를 진행할 때 일관 된 테스트 환경을 제공하고 비교하기 위해 서비스의 메모리 사용량에 제한을 두었다. 메모리 제한은 생각보다 간단하다. 도커 컨테이너를 실행할 때 설정을 해주면된다.

 

성능 테스트 | 컨테이너 메모리 제한 설정

컨테이너 구동 시 메모리 제한 설정에 대한 글로, Github Issue-#12의 일부 내용입니다. 단일 엔드포인트 성능 테슽 - /payments · Issue #12 · f-lab-edu/MetaPay/payments 엔드포인트에 대한 성능테스트를 진행

ydmins.com

성능테스트 진행하기

이렇게 환경을 설정한 다음 어떤 시나리오로 테스트를 할지 고민하며 계획을 세웠고, 계획에 따라 본격적으로 성능테스트를 시작하였다.

 

nGrinder | 성능 테스트 결과 - Simple Case

Simple Case에 대한 성능 테스트 결과 자료이다.성능 테스트 결과Simple Case는 앞으로 성능 테스트의 비교군이 될 가장 기초적인 테스트 케이스이다.Case 1 - Simple Case- 고정 Vuser : 10- 테스트 시간 : 1분-

ydmins.com

 

 

nGrinder | 성능 테스트 결과 - Dynamic UserId Case - 서버 과부하

Dynmic UserId Case에 대한 성능 테스트 결과 자료이다.Case 3 성능 테스트 결과Dynamic UserId Case는 동적으로 userId를 생성해, 고정 userId와 다르게 모든 요청이 다른 사용자가 접근하는 시나리오이다.Case 2

ydmins.com

동시성 이슈 생성하기

이번 주 테스트의 목적은 동시성 이슈를 발생시키고 이를 해결해 보는 것이었다. 그런데 기존에 아주 간단하게 작성해 놓은 서비스에 동시성 문제를 야기할 수 있도록 몇 가지 수정을 하면서 수정의 늪에 빠지고 말았다. 기존 상황들에 비해서 다양한 곳에서 예외 상황이 발생할 수 있어 예외처리를 해주어야 했고, 예외 처리가 증가한 만큼 테스트 코드도 작성해줘야 했다. 하지만 가장 큰 문제는, 기존 테스트 코드를 많이 수정해줘야 했다는 것이다. 결제 처리를 실제와 점점 비슷하게 만들 수록 결제 처리 시나리오가 좀 더 정교화해지고 복잡해 지는데, 테스트 코드를 작성할 땐 이를 예상하지 못했기 때문이다. 이번 주 멘토링이 있기 이틀 전부터 정말 머리가 너무 복잡한 시간을 가졌다.

 

그럼에도

 

조금씩 정신차리고 살펴보면서 고치고, 테스트하고. 잠시 쉰 다음 또 살펴보고 고치고. 밥 먹고 와서 또 고치고 테스트했다. 그렇게 이틀 정도 머리싸매고 헤매다 보니 복잡하게만 느껴지던 서비스 처리 로직이 또 신기하게도 머릿속에 지도처럼 그려지기 시작했다.

멘토링 시작까지 완전히 해결하진 못했지만, 멘토님께선 해당 내용은 차 주에 처리하지만 동시성 이슈는 결제처리 말고 결제 조회부분에서 진행하라고 조언해 주셨다.

라이브 코딩 테스트

이번 멘토링 시간에는 위의 프로젝트에 대해서 이양기 나눈 뒤 라이브 코딩 테스트를 진행해 보았다.

  • 어떻게 진행되나?

이번에 진행한 라이브 코딩 테스트는 멘토님께서 입력 값과 출력 값을 주시면 그 것을 해결하는 코드를 작성하는 방식이었다. 과제를 해결하면 그 다음 단계 입출력 값을 주셔서, 기존 코드를 수정 발전시켜 하나의 코드로 모든 단계별 입출력 결과를 출력하도록 만드는 것이다.

  • 당혹, 떨림, 긴장 < 혼잣말

누군가에게 코드를 작성하는 "과정"을 보인 적이 없어서 살짝 긴장한 상태로 내내 진행했다. 실수를 하면 당혹 스럽고 당장 답이 떠오르지 않을 땐 긴장감이 치솟았다. 이렇게 롤러코스터 타는 마음을 잡아놓으려고 입은 쉬지 않고 떠들었는데, 이게 도움이 되었는지 결국 마지막 단계까지 다 풀어내긴 했다. 👏🏻

  • 신선한 경험

프로그래밍을 시작한 이후, 정말 다양한 경험을 해보게 된다. 해보기 전까진 취업 과정중에 라이브 코딩 전형이 걸리면 어떡하지 하는 불안감이 있었는데, 막상 한 번 경험해 보니까 "하다 보면 또 할 수 있을 것 같다"는 용기를 얻었다. 또 동시에 굉장히 신선한 경험이었단 생각도 들었다.

이론

위의 프로젝트 이야기와 라이브 코딩으로 시간을 모두 사용해, 이론은 다음 주 주제로 넘기기로 하였다.

타임 캡슐

멈추지 말고 늘 하던대로 오늘 하루도 그저 열심히 임해라.
결국 복잡한 먼지는 날아가고 무거운 핵심만 남을 것이다.
YdMinS

 

728x90
반응형