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

F-Lab Java Backend 과정 10주차 후기 글이다.

F-Lab Java Backend 과정 10주차

F-Lab Java Backend 10주차

10주차 멘토링 주제

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

이론
1. Spring Security
2. Intrastructure as Code
3. Load Balancer & API Gateway

프로젝트
1. Git Command에 맞춰 코드 리팩토링
2. AWS EC2에 배포된 서비스와 RDS 연결하기
3. 컴퓨터 2대를 nGrinder Controller와 Agent로 구성해 클라우드에 배포된 서비스의 성능테스트 환경 구축
4. EC2에 서비스를 또 하나 배포한 뒤 Nginx 로드밸런서 구축하기

프로젝트

EC2에 배포된 서비스와 RDS 연결하기

RDS 연결하는 작업은 워낙 많이 해봤기 때문에 간단하게 끝날거라고 생각했다. 그런데 이상하게 로컬환경에서도 접속이 안되고, EC2와 연결도 되지 않았다. AWS VPS 등을 추가로 공부해사면서 여러가지를 시도해봤지만, 결국 AWS 계정을 새로 만들어서 해결했다.

• 원인 추측

이번주, 작동이 안되던 EC2는 시간이 없어서 더이상 건들 수가 없었다. 하지만 예상되는 원인은 AMI를 변경해가며 (Amazon-Linux -> Ubuntu -> Amazon-Linux) 보안그룹들이 여러개가 생성됐는데, 이것들 때문이지 않을까 추측해본다.

컴퓨터 2대를 이용해서 nGrinder Controller와 Agent 별도 구축

이전에는 메인 노트북(mac)에서 nGrinder Controller와 Agent 그리고 서비스까지 모두 띄워놓고 구동했다. 때문에 네트워크 문제 없이 테스트를 진행해 볼 수 있었다. 이번주에는 Agent를 윈도우 컴퓨터로 변경해 Controller, Agent, Service가 모두 다른 컴퓨터에서 구동되도록 할 계획이었다.

Architecture of Agent, Controller, and Service

하지만 윈도우 Agent와 맥 Controller간 통신에 실패했다. 아직 원인을 찾지 못했지만 다음주에 다시 한 번 시도해볼 예정이다.

Comments

멘토님께서는 일단 윈도우에서 3개를 모두 띄워놓고 테스트 해보고, 최종적으로는 EC2 컨테이너로 Agent를 띄우라고 하셨다.

Load Balancer 설치하기

nGrinder 사용과는 별개로, 서버에 로드밸런서를 도입해보기로 했다. Containered 서비스를 두 개 띄우고 nginx 컨테이너를 띄워서 모든 요청을 nginx가 받도록 할 계획이다.

Nginx Load Balancer

Nginx 로드밸런서 컨테이너를 띄우고, nginx.conf 설정까지는 정말 빠르게됐다. 정말 신기한건 불과 멘토링 시작하기 전까지만 해도 이런일들 너무 어렵고 난해해 했는데, 이상하게 술술 됐다. 2달간 공부한 것이 어렵게만 느껴지던 일들의 난이도를 낮춰준 것 같았다.

작동안됨

하지만 작동이 안된다. 요청이 가면 하나의 서버만 요청을 받고 있었다. nginx는 포트를 번갈아가면서 실행되는 것을 nginx의 로그를 통해서 확인했지만, 요청은 오로지 하나의 서버만 받고 있었다. 포트를 열거나, 모든 서비스를 도커 네트워크로 묶어주기도 하고, ping을 날려보고 다양한 시도를 해봤다. 마지막에 발견한 문제는 Dockerfile에 EXPOSE를 8080으로 해 모든 서비스가 8080포트로 열리도록 되있는 것을 발견했다. 그래서 port을 환경변수로 설정해 두고, 컨테이너를 생성할 때 전달해 주도록 했다. 하지만 아직 Spring 프로젝트는 8080으로 열리고 있었다. 여기까지하고 멘토링을 시작했는데, 다음주에는 이 문제를 해결해서 작동되도록 할 계획이다.

이론

Spring Security

Spring Security는 평소에 갈증이 많았던 부분이었기 때문에, 지난 주 MVC 흐름을 공부하듯이 Filter Chain의 요청 순서와 각 필터 내에서의 동작을 자세히 살펴봤다. Spring Security가 내부에서 어떻게 돌아가는지 살펴볼 기회가 정말 많지 않았는데, 정말 좋은 기회라 생각하고 내부 동작 위주로 열심히 살펴보았다.

Infrastructure as Code

요즘 대형 서비스들은 각각의 마이크로 서비스들을 별도의 서버로, 또 요청에 따라 오토스케일링을 하는 등 자주 생성하고 변경한다. 이렇게 변경이 잦아진 환경에서 문제 없이 일관된 서버 환경을 구축하기 위해 사용하는 것이 Inframstructure as Code이다. 코드로 작성해 놓은 서버 설정들은 어디서나 같은 환경을 보장할 수 있을 뿐만 아니라, 변경 포인트를 집중시켜 높은 유지 관리성을 보여준다. 이런 도구들 덕분에 더욱 더 큰 인프라환경을 손쉽게 관리할 수 있게 됐다. 이런 기술들을 하나씩 알아갈 수록 그 동안 막연하게 어렵고 두렵게만 느껴지던 네트워크와 인프라 세팅에 용기가 생기고 있다. 또 정말 자연스럽게 운영 환경을 넘나 들면서, 이런게 DevOps인가 하는 생각을 하게 됐다.

Load Balancer & API Gateway

이 내용들은 공부는 살짝 하긴 했지만, 한 주 더 공부하고 다음주에 이야기 나누기로 했다.