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

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

F-Lab Java Backend 과정 14주차

F-lab Java Backend 14th Week

14주차 멘토링 주제

프로젝트
1. 로드밸런서 도입 후 성능 저하 문제
2. 캐시 도입
2. 예외처리

이론
1. 동시성 이슈
2. TDD

프로젝트

로드밸런서 도입 후 성능 저하 문제

• 인스턴스 6개 생성

이번주는 모든 서비스를 독립된 서버로 분리해 서버 이중화를 진행했다. 이를 위해서 서비스 2개, 로드밸런서 1개로 서비스를 위해서 3개의 인스턴스를 생성했다. 여기에 모니터링을 위해 Prometheus 전용 인스턴스 한 개, 테스트를 진행하기 위한 독립적인 Agent 두 개까지 해서 총 6개의 인스턴스를 생성했다.

• 성능 저하 발생

예상 시나리오로는 서버를 이중화하고 로드밸런서를 도입하면 성능이 2배이상 높아질 것이라고 예상했다. 하지만 성능은 오히려 한 개의 서버로 운영할 때에 비해 30%정도의 성능밖에 보이지 않았다. 내가 뭔가 잘못한 것 같기도 하고, 테스트를 잘못한 것 같다는 생각도 들어서 이번주 살짝 멘탈이 나갔다. 멘토링 시간에 이에 대해서 멘토님과 라이브 코딩으로 트러블 슈팅을 시도해보았다. 다양한 시도를 하면서 원인을 좁혀 나가는 과정을 거쳤다.

1. 단일 서비스로만 테스트해 문제가 있는지 확인
2. 로드밸런서가 하나의 서비스로만 포워딩하도록 해 비슷한 성능이 나오는지 확인

여기서 바로 문제가 나왔다. 이론적으로는 로드밸런서가 한 곳으로만 포워딩 해준다면, 단일 서비스로 테스트 할 때와 비슷한 성능을 보여야 한다. 하지만 이 때 이전과 마찬가지로 성능저하가 발생했다. 이 문제를 해결하기 위해서 또 원인을 좁혀 나가는 과정을 거쳐보았다.

1. nginx.conf 파일에서 불필요한 내용들을 지워보기
2. nginx 컨테이너에 메모리를 넉넉히 설정해보기

하지만 여전히 문제가 해결되지 않았다. 그래서 돌아오는 주에는 해당 엔진엑스를 로컬에서도 테스트 해보고, 최신 nginx 또는 안정적인 nginx 이미지를 찾아서 대체해 보기로 하였다.

예외처리

이번 프로젝트를 진행하면서, 예외처리가 단순히 try-catch해서 컴파일 오류가 안뜨고 실행되게만 하면 되는게 아니라는 걸 많이 느끼고 있다. 하지만 아직 완벽한 정답은 모르겠다. 그래서 오랜 고민 끝에 고쳐 놓으면 다음날 일어날 때, 아닌 것 같은 생각 들기를 반복중이다. 지난 주에는 Exception처리를 Exception 핸들러 도입으로 중앙화 하였다. 이런 생각에 다달아 Exception 핸들러를 구현한 내자신이 정말 뿌듯했지만, 다음날 생각해 보면, 다양한 상황에서 발생하는 500 Exception이 과연 일관되게 처리될 것인지에 대한 의구심이 들었다. 이에 대해서 멘토님은 Exception을 발생지점에서 처리하거나 중앙처리하거나 둘 중 선택의 문제가 아니라고 말씀해 주셨다. 모든 걸 중앙에서 처리할수도 없고 해도 안되기 때문에 두 가지 모두 사용할 생각을 갖고 있어야 한다고. 지금 회고를 작성하면서 생각이 든 것은 꼭 개별 처리해야 할 것은 발생지점에서 처리하고, 기존 방식의 처리 방식이 필요하면 Handler가 처리하도록 두면 되겠단 느낌이 든다. 이것도 내일 아침엔 아니란 생각이 들랑가?

이론

동시성 이슈

요즘에 이론 공부를 복습하는 시간을 가지느라 프로젝트 시간이 예전에 비해서 많이 줄었다는 말씀을 드렸다. 이에대해서 멘토님께선 요즘 복습한 내용중에 어떤 내용이 재밌었는제 물어주셨다. 이에대해서, 동기화 문제를 공부한 이후 아직 완벽하게 알지 못하고 제대로 적용해보지 못한 것에서 오는 찝찝함을 갖고 있다고 말씀드렸다. 그에 대해 멘토님께선, 시나리오를 만들어서 하나하나 직접 테스트 해보면 좋다고 조언해주셨다. 그래서 다음주부터는 동기화 이슈를 좀 더 Deep Dive 해볼 계획이다.

TDD

위의 두 가지 내용으로 시간을 대부분 사용해, 이번주 이론 주제는 TDD만 다루기로 하였다. TDD는 개발 전 실패하는 테스트를 먼저 작성한 뒤, 테스트를 성공시킬 수 있는 최소한의 코드를 작성해 나가며 개발하는 방식이다. 말은 쉽지만, 아직 어떻게 개발할지 모든 계획이 정해지지 않은 상태에서 테스트 코드를 작성하는게 너무 어렵게 느껴진다고 말씀 드렸다. 이에 대해 TDD라는 건 일단 필요한 기능의 성공 케이스와 여러 실패 케이스를 만들어 놓고 그 틀에 맞춰 코드를 써나가는 것이라 말씀해 주셨고, 이렇게 했을 때의 가장 큰 장점은 테스트 하기 쉬운 코드를 작성하게 된다는 점이라고 말씀해 주셨다. 정말 공감갔던게, 작성한 로직의 테스트 코드를 작성하는 건 생각보다 너무 어려웠었고, 특정 예외들은 까먹고 작성을 못하기도 했다. 미리 발생할 수 있는 예외상황을 상정하고, 모든 상황에 대해 작성된 테스트 코드를 기반으로 본 코드를 작성하면 정말로 알맞는 코드를 쓰는데 도움이 될 것 같다는 생각이 들었다.