마이크로 서비스 포스트를 마치며
사실 공부하는 책의 일부분이 어느 정도 남았지만 사실 이론에 가깝고 실습이 어렵기에 이전 포스트 집킨을 끝으로 블로그에 포스트 되는 글은 마지막이 이 글이 마지막이 됩니다 그간 저는 약 6개월간 마이크로 서비스 관련한 이론과 실습에 대해서 공부를 했습니다 사실 이론 부분이 강한 책을 붙잡고 하는 바람에 코드에 어려움이 있어서 여러 블로그를 방문해서 비교해서 저만의 마이크로 서비스를 만들어보았습니다 이번 포스터는 그간 무엇을 배웠는지에 대해서
공부하게 된 계기
사실 거의 대부분의 개발자들은 모놀리식 방법으로 일생을 개발하게 됩니다 저도 그 축에 속했고 그간 모든 프로젝트들은 모놀리스식으로 개발 배포되었습니다 다만 한창 MSA 가 무엇인지에 대해서 공부는 필요할거 같아서 책을 하나 선정 읽으면서 코드를 만들고 책의 해석과 나만의 해석을 덧붙여서 지금의 마이크로 서비스 포스트를 완성시킬 수 있었습니다
끝으로 알게 된 것
저는 사실 도커를 몰랐습니다 다만 이번 공부를 하면서 도커를 그렇게 잘 쓰는 것은 아니지만 그래도 컨테이너 간 통신, 컨테이너 불러오기, 스크립트 작성 이 부분에 대해서는 재밌게 배워갔습니다 그간 필요한 오픈소스 애플리케이션은 VM에 설치해서 포트포워딩, 방화벽 해제 후 사용했는데 docker를 사용하다 보니 그런 중간 설정이 필요 없다는 게 장점이었습니다 마이크로 서비스가 왜 필요한지 알게 되었고 그렇다고 기존에 사용하던 모놀리스식 방식 또한 없어서는 안 될 프로젝트 생성 방법이라는 것을 알게 되었습니다
Docker
1장에서 5장까지는 마이크로 서비스 실습을 위한 Docker 공부를 진행했습니다 깊이 있는 공부는 아니지만 docker 가 무엇인지 왜 쓰는지에 대해서 알게 되었습니다
https://time-kimdongy1000.github.io/posts/Spring-MicroService-1/ https://time-kimdongy1000.github.io/posts/Spring-MicroService-5/
Config-server
마이크로 서비스의 첫 단추 설정 정보를 한곳에 모아놓는 Config-Server에 대해서 공부했습니다 기존 모놀리스식에서는 개발 프로젝트에 대해서 설정 정보를 각기 가지고 있었던 반면 마이크로 서비스에서는 각 모듈별 서비스에 필요한 설정 정보를 중앙에서 관리를 했습니다 이때 파일서버에서 관리할 것인지, github 같은 중앙 저장소에서 관리할지에 대해서 공부했습니다
https://time-kimdongy1000.github.io/posts/Spring-MicroService-6/
EUREKA
이 부분에서 처음 보는 개념이 나왔습니다 각 모듈별 서비스 상태를 검색하고 서비스를 이어주는 중앙 처리 서비스 모듈 유레카가 필요한 이유는 우리는 지금까지 port를 숨겼던 적도 있었고 보여주면서 진행을 한 적이 있었습니다 마이크로 서비스는 클라이언트가 해당 서버에 직접적으로 도달하지 못하게 하고 그중 실습할 수 있는 일부 방법이 포트를 랜덤하게 넣는 방법이었습니다 그럼 이때 각 모듈별 서비스가 통신하기 위해서 반드시 필요한 게 유레카 서버 이 유레카 서버는 해당 서버의 도메인 포트로 접근을 하는 게 아니라 등록된 서비스에 한해서 이름으로 접근할 수 있는 방법을 제공하는 서비스입니다
https://time-kimdongy1000.github.io/posts/Spring-MicroService-11/
클라이언트 회복성
사실 이 부분이 실습이 조금 부족해서 아쉬운 부분입니다 사실 실습을 만들기 어려운 부분이기도 한 회복성 클라이언트 회복성은 한 모듈에 대해서 서버 상태 이상이 감지되었을때 서버 스스로 자신을 호출하지 못하게 막거나 다른 우회 api로 전환하는 서비스였습니다 특히 회로 차단기 (서킷브레이커) 우회 api를 제공하는 fallback 처리 동일한 요청 시 네트워크 이슈로 서버 발생했을 때 일정 시간 동안 몇 번 다시 호출하는 (Retry) 처리 여러 곳에서 한 번에 처리가 들어올 시 속도 제한을 걸어 모듈의 안정성을 도모하는 속도제한기까지 다루어보았습니다
https://time-kimdongy1000.github.io/posts/Spring-MicroService-14/
마이크로 서비스 관문
Gateway 사실 Gateway를 배우기 전까지 유레카 서비스를 활용해서 각 모듈별 통신하거나, 직접 모듈에 접근해서 통신을 했었는데 이제 클라이언트는 Gateway 하고만 통신을 하고 이 gateway 가 요청한 api를 토대로 각 모듈에 api를 호출해서 결과를 반환하게 만들었습니다 이때 각 모듈은 포트를 모두 숨겨서 클라이언트가 직접 접근할 수 없게 만들고 진행을 했습니다
https://time-kimdongy1000.github.io/posts/Spring-MicroService-18/
보안
프로그램을 만드는 거만큼 중요한 것이 프로그램을 안전하게 보관하게 하고 인증된 사용자만 접근이 가능하게 만들어야 했었습니다 보안을 통해서 마이크로 서비스와 Oauth2 (keyclock)를 활용해서 애플리케이션 보안을 강화했습니다
https://time-kimdongy1000.github.io/posts/Spring-MicroService-22/
분산 캐싱
이는 클라이언트 회복성 및 강한 결합성에 관련한 이야기로 어떤 모듈이 어떤 모듈의 데이터를 가져오려고 할 때 그 모듈과 직접적인 연결을 통해서 가져오면 해당 모듈의 문제 발생 시 본인 모듈에도 문제가 생길 수 있기 때문에 그것을 방지하고자 카프카 같은 비동기 메시지 처리를 통해서 데이터가 변경이 되었을 때 그것을 수신하여 redis 저장소를 최신화하고 각 독립 모듈은 데이터 필요시 필요 모듈에 직접 접근하는 것이 아니라 캐싱을 통한 데이터를 가져오는 방식으로 개발을 했습니다
https://time-kimdongy1000.github.io/posts/Spring-MicroService-24/
분산 추적
마이크로 서비스는 결론적으로 각 모듈이 떨어져 있기 때문에 에러 발생 시 이를 디버깅하거나 추적하는 것이 상당히 어려웠다 다만 스프링 그리고 오픈소스가 제공하는 서드파티 라이브러리를 활용해서 추적을 했습니다 슬루스를 통해서 각 로그를 추적할 수 있게 추적 ID 와 스팬 ID를 심어주었고 이를 각각 로그스태시 , 엘라스틱서치로 전송해서 키바나로 시각화 진행 그리고 각 모듈이 직접 집킨하고 연결이 되어서 각 요청시 발생하는 api 들의 성능을 눈으로 볼 수 있게 구성을 했습니다
https://time-kimdongy1000.github.io/posts/Spring-MicroService-26/
여기까지가 우리가 포스터하고 배운 내용 전부입니다
아쉬운 점
개인적으로 분산 트랜잭션에 대해서 공부해 보고 싶었지만 그 부분이 없어서 아쉬웠습니다
끝으로
정말 재미있었던 공부였던 거 같았습니다 물론 모든 내용을 깊게 다루지는 못했지만 각 파트별로 해당 서비스들이 무엇을 하는지에 대해서는 확실히 알게 된 시간이었습니다 언제 마이크로 서비스 프로젝트를 해볼 수 있을진 모르겠지만 언제 한번은 배운 것들을 실전 코드에서는 어떻게 다루어질지 궁금하네요