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

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

F-Lab Java Backend 과정 13주차

F-Lab Java Backend 13th Week

13주차 멘토링 주제

프로젝트
1. 단일 서비스 - 다양한 JVM Heap 사이즈에 대한 성능 테스트
2. 서버 이중화 & 로드밸런서 도입

이론
1. Database ACID & CAP
2. Test(단위 / 통합/ 시스템/ 인수/ 회귀)

프로젝트

다양한 JVM Heap 메모리 사이즈에 대한 성능 테스트

멘토님께서 지난 주, 성능 테스트 결과를 보신 후 JVM Heap 메모리를 줄여가면서도 테스트 해보면 좋겠다고 가이드 해 주셨다. 그래서 이번주에는 JVM Heap 메모리를 변경해 하면서 테스트를 진행해 보았다. 그런데 다른 환경에서 관측된 메트릭들의 그래프가 너무 비슷했다. 뭔가 이상함을 느끼고 살펴보니, Agent와 서비스가 한 서버에 있을 때 서비스의 성능을 올바르게 측정할 수 없다는 걸 알게됐다. 처음 구현 성능테스트 모니터링 환경을 구출할 땐, 되게 하는게 급해서 급한대로 둘을 함께 뒀는데 이제는 둘을 분리시켜줘야 겠다는 생각이 들었다. 그래서 일단 Agent를 로컬 환경으로 옮기고 성능테스트를 진행했다. Agent 없이 단독으로 돌아가는 서비스는 기존에 Vuser가 1도 버거워했는데 500도 거뜬한 좀 튼튼한 서비스가 되었다. 좀 더 자세한 이야기는 아래 글에 작성해 두었다.

TIssue | 성능 테스트 적정 환경 찾기 (Feat. 매번 같은 양상의 메트릭 측정 됨)

EC2, 나한테 왜 그래...

이번주 가장 프로젝트를 진행하면서 가장 힘들었고 시간이 많이 소모 된 부분이 EC2 구동이다. 구동은 잘 되는데 SSH 접속도 안되고 요청도 전달되지 않는 이슈들이 있었다. 처음에는 EC2를 아예 종료한 뒤 다시 실행했었다. 그런데 이렇게 하면 Public IP가 변경돼 모든 설정을 다시 해줘야 한다. (아직 수동으로 관리중이다.)

그런데! 같은 이슈가 또 발생했다. 이번엔 최대한 안끄고 해결해 보려고 이것 저것 시도를 더 많이 해보았다. 두번째 문제는 nf_conntrack table이 꽉차서 발생한 이슈였다. nf_conntrack table 용량을 늘리거나 비워주기 위해선 일단 터미널에 접속이 돼야 하는데 접속은 당연히 안되고 있었다. 그런 와중 머릿속으로 nf_conntrack table은 추적 용도로 사용하는 테이블 이기 때문에 자체적으로 내용물을 조절하는 로직이 구축돼 있지 않을까 하는 생각이 들어 일단 아무런 조치를 취하지 않고 기다려 보기로 했다. 그랬는데! 정말로 20시간 정도 뒤 서버 접속이 되기 시작했다. 얼른 nf_conntrack table 용량을 늘려주었다.

TIssue | AWS EC2 작동중인데 연결 안되는 이슈 (Feat. 연결 추적 테이블 nf_conntrack table이 가득참)

 

그런데! 이슈가 또 발생했다. 이번엔 nf_conntrack table 이슈도 아니였다. 좌절스러웠지만, 이번엔 또 무슨 이슈인지 찾아보았다. 이것 저것 확인해 볼 수 있는 것들을 확인 하던 중 이번에도 찾게되었다. CloudWatch라는 곳에 가면 EC2에 대한 여러 정보를 확인해 볼 수 있는데, 여기서 CPUCreditBalance라는 것을 알게 됐다. 이 값은 Free Tiert사용중에 사용하는 만큼 소멸되는 값인데, 매 시간마다 채워지는 값이기 때문에 많이 사용하지 않는다면 전혀 문제가 없다. 그런데 읻민스의 경우, 지속적인 성능테스트로 이 Credit이 0으로 고갈되는 이슈가 발생했다. 이건 해결책이 딱 둘일 것이다. 돈을 내고 서버를 사용하거나, Credit이 다시 차오를 때 까지 기다리기. 일단은 기다렸다.

서버 증설

위의 2가지 결과를 볼 때, 이제는 유로 서버 인스턴스를 사용해야 할 때가 된 것을 알 수 있다. 첫 번째 이유로 한 서버에서는 하나의 서비스만 돌리는 것이 좋다는 걸 알게 됐고, 두 번째 이유로 무료 서버로는 원하는 수준의 테스트를 지속해서 수행할 수 없음을 파악했다. 그래서 다음주에는 서버를 늘려볼 계획이다.

이론

이번 주에는 모든 주제를 다루지 못했고, ACID vs. CAP와 TEST에 대해서만 멘토님과 대화를 나눠보았다.

CAP

CAP는 분산 데이터베이스를 구축하면서 동시에 만족시킬 수 없는 3가지 속성이다. Consistency, Availability, Partition Tolerance이다. Consistency는 모든 노드가 언제나 같은 데이터를 볼 수 있어야 하는 일관성을 뜻하고, Availability는 모든 요청에 대해선 언제나 응답을 받을 수 있어야 한다는 가용성을 뜻한다. 즉 장애가 발생해도 다른 노드 DB를 이용해서 읽기와 쓰기가 언제나 가능해야 한다. Partition Tolerance는 노드간 네트워크가 쪼개지더라도 시스템이 작동(읽기와 쓰기)돼야 한다는 것이다. 즉, 분산 데이터베이스를 구축하게 되면 분명히 포기해야 하는 부분이 존재하니까 이 점을 반드시 고려해야 한다는 원칙이다.

읻민스는 현재 결제 시스템을 만드는 프로젝트를 진행하고 있기 때문에, 금융 서비스에서는 위의 2가지를 지켜야 한다면 C와 A를 취해야 한다고 생각을 해보았다. 그런데, 멘토님께서 P를 포기하는데 다른 C와 A가 성립될 수 있는지 질문을 주셨다. 딱 답이 나오지 않아서 말문이 막혔는데, 질문을 주신이유가 '안되기' 때문이다. 그렇다 논리적으로 생각해 봐도, 네트워크가 분할 됐는데 모든 데이터베이스를 동기화 해 일관성을 유지하는 것은 불가능했다.

금융 서비스의 가용성

금융 서비스 회사의 채용 공고를 살펴보면 '고가용성'이라는 단어가 정말 자주 나온다. 그렇기에 CAP에서 A는 무조건 가져가야 하는 속성이라고 생각했는데, 금융 서비스는 솔직히 이 3가지를 모두 가져가야 한다. 하지만 중요도를 생각해 보자면 CP인 것이다. 즉, A를 트레이드 오프 할수 밖에 없었기 때문에, 마치 A를 취한 것 같이 가용성을 높히려는 노력을 해야 하는 것이다.