기본 콘텐츠로 건너뛰기

[Webinar 정리] Awesome tools to level up your Spring Cloud architecture

개요




우리나라 시간으로 2016년 11월 9일 새벽 3시부터 1시간가량 진행이 됐던 Webinar입니다.

제목에서도 알 수 있듯이 대부분 개발툴과 Devops Tool에 대한 간단한 소개 형식이었네요.

물론, 새벽 3시에 본방사수를 외쳤습니다만, 3시에 일어났다가 틀고 잠이 들어서 결국 끝 10분만 봤습니다. 그래서 본방사수는 놓쳤고 나중에 보고 정리한 내용입니다.

Webinar이고 영어다 보니 거의 알아들을 수가 없었습니다만(이럴 땐 영어를 못 하는 것이 아주 아쉽습니다) 프리젠테이션과 데모로 대충만 알아들었습니다.

Webinar 사이트에 들어가 보시면 관련 자료가 엄청나게 많이 링크로 걸려있습니다. 해당 내용을 다 확인하려고 해도 엄청난 시간이 필요하겠네요.

여기에는 Webinar 진행 중에 나왔던 다양한 Tool 중에서 관심이 있는 내용에 대해서 주로 정리를 해 볼까 합니다.

아래 Tool들의 대부분은 Spring Cloud(특히 Eureka Discovery Server)가 필수이거나 있어야 효용성이 늘어난다는 것을 염두에 두시고 보시기 바랍니다.


Monitoring And Dashboard Tools


1. Spring Boot Admin



Webinar 내용을 통틀어 가장 마음에 들고 관심이 갔던 Tool 되겠습니다. 이건 현재 진행하는 프로젝트에 꼭 적용을 해보려고 합니다.

Eureka Server의 정보를 기반으로 해서 각 마이크로서비스의 Actuator 정보를 이용해 관리할 수 있는 다양한 기능들을 제공해 줍니다. 제공되는 내용을 잠시 간단히 살펴보니 기본적으로는 서비스 레지스트리에 등록된 서비스들의 목록을 제공합니다. 거기서 상세정보를 확인하기 위해서 들어가면 아래와 같은 내용을 제공하는 것으로 보입니다.
  • 각 서비스의 상세 상태 정보 
    • 각 서비스의 Health 정보 : Memory, Disk, Db 상태 등
    • Memory 상세 정보
    • JVM 정보
    • Servlet Container 정보
    • Garbage Collection 정보
  • Metrics 정보
  • 로그 : 이거 정말 마음에 들더군요. 얼마나 표시가 되는지는 모르겠지만 유용해 보입니다.
  • 스프링 설정 정보의 확인과 편집 : 확인만으로도 유용한데 편집하고 실시간 적용 가능합니다. 물론 @RefreshScope 으로 정의된 내용에 한해서만 되겠지만요.
  • logback의 로그  레벨 확인 및 편집 : 등록된 logback의 로그 레벨을 확인하고 변경할 수 있습니다.
  • Thread dump와 Request trace : actuator 기능을 보면서 나중에 꼭 가져다 써보자 했던 부분입니다.
  • Hystrix dashboard : 해당 서비스의 hystrix dashboard를 연결해 놓았습니다.

주절주절 리스트를 열거했습니다만, 간단히 Actuator의 기능을 전부 모아놨다고 봐야 할 것 같습니다.

사실 최근에 Spring Cloud 프로젝트를 기반으로 마이크로서비스 비스므리한 프로젝트를 개인적으로 진행해보고 있는데 완성할 때는 꼭 Actuator와 Hystrix Dashboard 를 연결하는 Dashboard를 하나 만들어야겠다 생각했었는데, 이런 유용한 것을 만들어주다니 정말 감사하다는 생각밖에는... 역시 세상은 살만한 곳입니다.

Spring Boot Admin과 3번에 나올 Microservices dashboard와 관련해서는 Josh Long이 22분정도의 라이브 코딩으로 설명하는 영상도 있으니 참고해 볼 만 합니다.(Spring Tips : Bootiful Dashboards - Josh Long)

2. Prometheus and Grafana


그 외로 Prometheus와 Grafana Tool도 설명이 나옵니다. 좋은 기능이긴 한데 솔직히 이것까지 필요할지는 한번 생각해 봐야 하겠습니다. 두 가지 Tool 모두 향상된 Visualization을 제공해 주고 유용한 것은 분명해 보입니다. Grafana 에서 Latency를 퍼센트별(90%, 95%, 99%, 100%)로 나눠서 제공해주는 정보는 꽤 좋아 보이긴 했습니다.

3. Microservices dashboard


jworks 팀이 만들고 있는 프로젝트로 보입니다. 따로 내용을 정리하기보다는 아래 그림을 참고하시면 될 것으로 보이네요.


현재는 그렇게 복잡한 서비스를 개발하고 있지 않아서 이런 것까지 필요할까 생각했습니다.


Log Analysis


1. ELK and Zipkin/Slueth


로그분석툴을 논할 때 절대 빠질 수 없는 것이  ELK가 아닐까 생각합니다.
지금은 Elastic Stack이라는 제품명으로 제공이 되고 있고, 정말 엄청난 속도로 버전업이 이루어져 왔습니다. 얼마 전에 Docker를 이용해서 Elastic Stack 5.0에 대한 테스트 파일럿을 진행해 보았습니다. 예전에 해 보았을 때보다 Kibana도 조금 편리해진 느낌이더군요. 아직 Kibana 사용법과 Elasticsearch 쿼리가 익숙하지 않아서 그렇지 굉장히 유용한 Tool임에는 분명해 보였습니다. 올 초부터 꼭 블로그에 정리해 놓겠다고 생각했었는데 아직 그러지 못하고 있네요.

아무튼, ELK 를 구성해 놓고 로그를 분석하면서 가장 아쉬운 것이 각 서비스에서 올라오는 많은 로그의 연속성을 따라가는 방법이었습니다. 즉 A 서비스가 request를 받아서 B 서비스로 처리를 요청해서 응답을 받아 사용한 경우 그 관계를 파악이 불가능 하더구요. 시간 관계로 할 수는 있는데 로드 테스트를 돌려본 결과 요청이 여러 개가 동시에 들어오는 경우 불가능하다는 판단을 했었습니다.

이럴 때 사용하는 것인 Zipkin과 Slueth 입니다. 최초 요청을 받은 Request 로그만 있다면 해당 로그에는 Trace id 와 Span id 가 자동으로 생성돼서 들어갑니다. 이것을 이용해서 추적한다면 가능하게 됩니다. 무려 Out Of Box로 적용이 되기 때문에 단순히 스프링 프로젝트에 Dependency만 잡으면 적용이 되는 편리함까지 있습니다. 아직은 파일럿이었기 때문에 샘플 수준에서 기본기능만 확인해 봤지만, ELK와 Zipkin/Slueth를 함께 사용한다면 분명 유용하지 싶습니다.

2. Splunk 


유료버전인데다 가격도 엄청나다는 이야기만 들었던 제품입니다. ELK만 소개하기가 뭐했던지 잠시 Splunk 이야기가 나옵니다.


Development Support Tools


1. Sonarqube/OWASP/FindSecBugs/...


뭐 워낙 유명해서 설명이 필요할 것 같지 않아서 설명 안 하겠습니다. 실제로 Webinar 에서도 간단히 언급만 하고 넘어갑니다. 유명하지만 전 사용해 본 적이 없습니다. OTL...

2. Spring REST Docs


비슷한 제품으로 Swagger가 유명합니다만, 최근 Spring 진영에서는 REST Docs를 더 밀고 있는 느낌입니다.

Integration Test를 이용해서 API Document를 작성해 주는 Tool이지요. Endpoint 별 Request/Response뿐 아니라 Mock을 이용해서 Request와 Response 샘플까지를 문서에 포함해줍니다.

자세한 내용은 국내의 김대성님과 아라한사님께서 만드신 발표자료들이 있고 샘플 소스가 있으니 참고하세요. 저도 그 자료들을 이용해서 공부해서 한 번 사용해볼까 합니다.




Deployment



1. Spinnaker 


마지막으로 Spinnaker에 대한 설명입니다. Jenkins를 사용해보려고 여러 번 도전했다가 실패한 경험이 있어서 사실 CI/CD Tool은 별로 관심을 가지지 않았었습니다. 그런데 최근에 개인 프로젝트를 Cloud에 올릴 일이 있었는데 CI/CD Tool을 하나 알아봐야겠다 생각했었습니다. Jekins가 매우 좋은 툴이긴 한데 저한테는 설정이나 고민해야 하는 사항이 많아서 좀 어렵더군요.
그런데 Spinnaker는 설정이 꽤 편리해 보입니다. 나중에 한 번 공부를 해봐야겠습니다.


결론 


대충 이번 Webinar에서 나온 Tool들은 이 정도였습니다.
많은 설명이 있습니다만 영어라서 저는 그냥 어떤 Tool들이 소개되는지 정도만 확인하는데 만족할 수밖에 없었네요. 그래도 대충 모양새를 보고 앞으로 뭘 공부해봐야 할지는 대충 감이 온 것 같습니다.
PCF(Pivotal Cloud Foundry)에 대한 자랑과 선전으로 마무리!! 컥.. 그냥 비교 설명이 있었습니다.

마지막으로 Slide에 나왔던 두 장의 Architect 구성도로 마무리해 보겠습니다.





댓글

이 블로그의 인기 게시물

경력 개발자의 자기소개서에 대해서...

갑자기 뜬금없이 이런 글을 쓰다니 무슨 생각이야? 라고 생각하시는 분들이 있을지도 모르겠네요. 뜬금없음에 대한 변명은 잠시 접어두고 일단 오늘 쓰려고 하는 글을 시작해볼까 합니다. 개발자로 대충 16년을 그럭저럭 보내왔습니다. 시대적 상황으로 5년 차쯤에 대리로 처음 팀장을 시작했으니, 일반 개발자로 산 시간보다는 어쨌건 프로젝트 또는 팀의 리더로 산 시간이 더 많았던 것 같습니다. 그 기간 동안 남들보다 좀 심하게 회사를 많이 옮겨 다니다 보니 꽤 많은 면접을 볼 수 있는 경험이 있었고, 또 옮긴 회사가 대부분 팀을 리빌딩하는 곳이었다 보니 꽤 많은 채용절차에 관여할 기회가 있어서 어린 나이부터 비교적 많은 이력서를 검토했고 면접관으로도 여러 사람을 만날 수 있었습니다. 처음 면접을 보러 다니던 시절의 제 이력서의 자기소개서는 항상 "19XX년 봄 XX업계에 종사하시던 아버님과 집안일에 헌신적인 어머니의 유복한 가정에 1남 1녀의 막내로..." 로 시작되었습니다 (이 문장에 향수를 느끼시는 분들 많으실 거예요. ^^). 경력이 5년이 넘은 어느 날 도대체 이 문장을 왜 써야 하느냐는 의문이 생겨서 조금 바꾸긴 했습니다만, 그 뒤로도 꽤 오랜 세월을 이런 자기소개서가 항상 제 이력서에 붙어있었죠. 요즘 누가 저런 식으로 자기소개서를 써? 라고 생각하시는 분들 많으실 거로 생각해요. (대신 요즘은 대학 시절의 봉사활동이나 해외연수 이력이... 뭐 어차피 그놈이 그놈입니다.) 저런 자기소개서를 써야 한다는 것이 어디서 어떻게 시작된 것인지는 몰라도 회사를 그만두기 전인 2년 전까지도 약간의 표현은 다를지 모르지만 비슷한 문장으로 시작하는 자기소개서를 이력서에 첨부해서 보내는 지원자들을 볼 수 있었습니다. 이제 제가 뜬금없는 이런 글을 쓰게 된 이유를 밝히고 계속 진행해야겠네요. 블로그에 올릴 글을 준비하는 일이 생각보다 힘들어요. 블로그에 올리려고 준비한 주제에 맞는 소스를 작업하고 거기에 글을 입히다 보면 가끔

Springframework 5에서 바뀌는 것들에 대한 간단 정리 및 생각

Spring framework 5 에 대해 많은 분이 기대와 두려움을 가지고 계시지 않을까 생각합니다. 특히 기대를 하고 계신 분들은 Reactive Programming 지원을 기대하고 계시지 않은가 생각이 드는데요. 7월 초에 John Thompson 이란 분이 D-Zone에 아주 깔끔하고 멋지게 정리를 잘해서 글을 쓰셨더라구요. 해당 글은  https://dzone.com/articles/whats-new-in-spring-framework-5 에서 확인을 하실 수 있습니다. 혹시 Spring framework 5에서 달라지는 내용의 좀 더 자세한 내용이 필요하신 분들은 Spring framework github의 wiki 를 참고하시면 됩니다. 본 포스트는 언제나 그렇듯이 윗글에 대한 번역이 아닙니다. 그저 윗글을 다시 정리하면서 제 생각을 한번 정리해 놓은 포스트입니다. Spring framework 5는 현재 5.0.0.RC2(2017.07.23일 기준)까지 릴리즈된 상황입니다. Spring framework 5에서 크게 변화하는 내용을 John Thompson은 8가지로 깔끔하게 정리해주고 있습니다. 1. JDK 지원 버전의 업데이트 5버전은 원래 JDK 9 버전의 지원을 위해서 시작됐던 프로젝트로 알고 있는데 맞는지는 모르겠네요. JDK 9의 Release가 늦어져서 Spring framework 5가 먼저 Release 될 것으로 보이지만, JDK 9가 Release가 되면 언제건 적용할 수 있다고 합니다. 좀 아쉬운 부분은 JDK의 최소 버전은 JDK 8이라는 부분이 아닐까 싶네요. 이 때문에 Spring framework 5에 무관심한 분들도 많으실 거라고 생각합니다. 지금 진행하는 프로젝트는 JDK 8을 기반으로 합니다만, 최근까지 다니던 회사의 경우는 JDK 7까지가 업그레이드 한계였던 회사였습니다. 아마도 JDK 업그레이드를 쉽게 못 하시는 회사들이 많으니 "나랑은 관계없는 얘기군"

Gradle 을 이용해서 Multiproject 를 구성하는 방법 (중 하나)

개요 회사에서 Gradle 을 이용하게 된 이래로 계속 Multi-project 형태로 설정하여 진행을 해 오고 있다. 매번 멀티 프로젝트 형태로 만들어지고 있는 회사의 프로젝트들이다 보니 그때마다 다시 이전 빌드 스크립트를 보면서 만드는데 프로젝트들이 복잡하다보니 필요없는 설정들까지 복사해서 쓰고 있는 부분들이 있어서 한번 정리를 했으면 하고 있었다. 가장 기본적인 상태의 멀티프로젝트용 build.gradle 에 대한 여러가지 방법 중 한가지라 생각하고 참고가 된다면 좋겠다. 요구사항 기본 요구사항은 다음과 같다. 1) 멀티프로젝트는 디렉터리를 기반으로 아래와 같이 그룹으로 만들어 질 수 있어야 한다.   - Shared : 다른 프로젝트에서 Dependency로 추가될 수 있는 공통 라이브러리를 포함하는 라이브러리 모듈 그룹   - Web : Front 모듈 그룹   - Server : 주로 어플리케이션 간의 설정 등을 관리하는 Server 모듈 그룹   - Service : Web API 서버 모듈 그룹 2) 모든 Subproject 들은 Java project 이며, 프로젝트 명은 "모듈그룹명-모듈명" 으로 만든다. 즉, Server 모듈의 configuration-server 모듈이라면 server-configuration-server의 형태로 만들어지면 된다. 이후에 작업된 모든 내용은 Ubuntu 14.04 OS와 IntelliJ IDEA 15에서 작업되었다. (윈도우즈와 이클립스에서도 동일한 내용을 동작이 될 것으로 보인다. 다만, 테스트되지 않았을 뿐이다) Main Gradle Script 작업 1) 파일 구성   - build.gradle : gradle script 파일   - settings.gradle : sub project 관리를 위한 파일 2) build.gradle 파일 작성   - 우선은  프로젝트 기본 정보로 group 정보와 version 을 설정한다. 본인의