기본 콘텐츠로 건너뛰기

2016의 게시물 표시

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

개요 Webinar 시청 URL :  https://goo.gl/EVU5Za   (회원가입이 필요) Slide URL :  http://www.slideshare.net/SpringCentral/awesome-tools-to-level-up-your-spring-cloud-architecture-pivotal-webinar-2016-final/1 우리나라 시간으로 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 Project URL :  https://github.com/codecentric/spring-boot-admin \ Reference Guide :  http://codecentric.github.io/spring-boot-admin/1.3.0/ Webinar 내용을 통틀어 가장 마음에 들고 관심이 갔던 T

Semantic Versioning 2.0.0 에 대한 자료 정리

Gradle이라던가 Maven을 이용한 빌드 시스템을 구축하고 NEXUS 등의 리포지터리를 이용하고 Git 을 쓰면서 개발을 하다 보면 예전에는 별로 관심이 없었던 개발하고 있는 시스템의 버전관리에 대한 생각을 하게 되더군요(최소한 저의 경우는 그랬습니다) 혹시라도 공통 라이브러리 패키지가 있을때는 공통 라이브러리에 대한 버전관리가 예전부터도 중요하게 생각되었었지만, 최근에는 이 공통 라이브러리 패키지를 이용하지 않는데도 버전관리가 예전보다 더 중요하게 생각이 됩니다. 다른 부분들은 그렇다 쳐도 Git을 이용해서 형상관리를 하는 경우에는 특정 커밋에 태깅을 해 놓는 것이 나중에 해당 버전의 상태를 추적하는데 매우 편리한 도구가 될 수 있습니다. 버전관리에서 최근 가장 많이 쓰는 방식이 Semantic Versioning 이라고 하는 것이 아닐까 생각합니다. 최근이라고 하지만 사실 예전부터 많이 사용됐었고 Semantic Versioning 이라는 개념을 몰라도 일반적으로 비슷하게 사용하는 x.y.z이라는 Major.Minor.Patch 방식의 버전관리입니다. 예를 들어 "릴리즈 최초버전은 1.0.0이다" 가 바로 Semantic Versioning(줄여서 semver 라고도 하더군요) 입니다. 다른 내용에 대해 검색을 하다가 우연히 해당 Semantic Versioning 에 대한 공식 문서를 찾았습니다. semver 는 일반적으로 Public API에 대한 버전관리에 대해서 설명을 합니다만, 일반적인 프로그램에도 같게 적용될 수 있습니다. 결론적으로 가장 중요한 내용을 정리한다면, 기존 버전과 호환되지 않게 변경을 했다면 Major 버전 기존 버전에 새로운 기능이나 호환이 가능한 수정을 했다면 Minor 버전 기존 버전의 버그에 대해서 호환 가능하게 수정을 했다면 Patch 버전 (해당 버전) 부분을 하나씩 증가시킨다는 규칙을 말합니다. 일반 서비스를 개발하시는 분들의 경우는 조금 다를 수도 있겠네요.

개발자들의 기술에 대한 오만에 대해서...

최근 며칠간 회사일로 약간의 혼란상황이 있었습니다. 많은 부분 정리가 되긴 했지만, 아직 조금 더 시간이 걸리듯 하네요. 최근 블로그를 쓰지 않고 있었던 것은 다른 일로 좀 바빴기 때문인데, 역시 이것도 시간이 많이 필요해 보입니다. 오늘은 잠시 추석을 앞두고 휴식도 가질 겸 기술이 아니라 기술에 대한 생각들을 한번 이야기해볼까 합니다. 추석에는 다른 작업을 또 열심히 해야 하기에... 그동안도 몇 번 블로그에 정리하고 싶었습니다만, 저 자신도 부족한 것이 많은데 괜한 잘난 척이 되지 않을까, 몇 번이나 쓰기를 망설였던 내용입니다. 그 내용은 개발자들이 흔히 범하는 기술에 대한 오해에서 오는 오만에 대한 것입니다. 최근 면접을 위해 이력서를 보거나 다른 회사의 제안서를 검토하다 보면 애자일 방법론이라던가 도메인 주도개발이라던가 테스트 주도개발을 강점으로 내세우는 경우를 많이 보게 됩니다. 또한 머신 투 머신(이런 용어가 어디에서 나온 것인지 좀 궁금합니다만...)의 인터페이스를 이용한 개발방법론이라는 것도 보게 되더군요. 아마도 EIP(기업 통합 패턴, Enterprise Integration Pattern)을 말하는 것이거나, 마이크로서비스 아키텍트의 사촌쯤 되는 게 아닐까 생각해 봅니다. 심지어 위 기술들에 대한 전문가라고 칭하는 사람들도 보이더군요. 너무나도 당연히 해야만 하는 테스트주도 개발(제 주관적인 생각입니다)을 제외하고 다른 부분에 대해서는 좀 생각을 해봐야 하는 것이 아닌가 합니다. 위에 기술한 것들이 참 좋은 것들이고 올바른 트랜드라고 생각을 합니다만... 좀 더 깊게 한번 생각해 보겠습니다. 애자일 방법론의 핵심이 무엇일까요? 애자일 매니페스토의 한글 번역본은 이렇게 시작합니다. 우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다. 이 뒤로도 주옥같은 많은 원칙이 나옵니다만, 저에게 애자일의 가장 핵심은 위의 내용입니다. 몇 개월이 지나도록

npm, bower, gulp 를 이용한 웹 클라이언트 개발 환경 구축

서론 포스트를 작성해놓고 다른 소스들을 보다 보니 뭔가 문제가 많은 포스트네요. 포스트를 내릴까 하다가 어차피 제가 나중에 보려고 정리하는 포스트들인 것을 생각해서 일단 놔두려고 합니다. 개발 환경 관련 좀 더 나은 소스를 원하시는 분들은  https://github.com/angular/angular-seed  의 소스를 확인하시는 것이 더 현명한 선택이지 싶습니다. (2016/07/07) 그동안 Spring-cloud를 기반으로 마이크로서비스 아키텍처 구성과 관련된 포스트를 작성하다가 왜 갑자기 웹 클라이언트 개발 환경 구축인가 뜬금없다고 생각하시는 분들이 많을 것 같습니다. 아직 마이크로서비스 아키텍처도 정리할 것들이 많이 남았는데, 갑자기 개인적으로 진행하던 프로젝트에서 목업을 만들어야 할 일이 발생했습니다. 그래서 목업이지만 그냥 생각 없이 만들지 말고 새로운 환경구성을 해보자 하는 생각으로 이 포스트의 내용이 시작되었습니다. 오래 생각할 시간이 없어서 급히 이리저리 알아보니 npm, bower, gulp를 이용해서 만들면 뭔가 괜찮은 구조가 나올 것 같다는 생각을 하게 되었습니다. 뭐 제가 정리하는 포스트 대부분이 그렇지만 이번 경우에는 특히나 짧은 시간에 공부하고 구성하고 정리하다 보니 약간은 이상한 구조가 나와버렸네요. 그래도 참고가 되면 좋겠습니다. 전체 소스는 언제나 처럼 Github 에 올려놓았습니다. Github Repository :  https://github.com/roadkh/blog-npm 사전준비사항 포스트가 npm, bower, gulp를 이용해야 하니 우선 설치를 해야 합니다. 간단하게 설명을 했습니다만, 자세한 사항은 각 항목의 링크를 클릭하세요. 각 모듈의 링크에서 보시고 환경에 맞게 설치를 먼저 진행해 주세요. node.js : npm, bower, gulp 모두 node.js를 기반으로 합니다. 우선 node.js가 먼저 설치가 되어있어야만 합니다. 아래 제 환경을 보시면 nod

구글의 미래 - 토마스 슐츠

출간일 : 2016년 05월 30일 376쪽 | 682g | 152*225*30mm ISBN-13 : 9791186805268 ISBN-10 : 1186805269 어제 드디어 구글의 미래라는 책을 다 읽었습니다. 출퇴근 시간에 읽기에는 조금 무거운(500g이 넘는 책은 무겁...) 책이지만 그래도 생각보다 빨리 읽을 수 있는 책이었네요. 책 무게뿐 아니라 내용도 좀 무거운 책이지만, 전체적으로는 동어반복이 계속되는 느낌의 책이기에 적당히 무시하고 읽으면 읽기에 그렇게 힘든 책은 아닙니다. 책의 해제(책의 저자, 내용, 체재, 출판 연월일 등에 대한 간단한 설명)를 쓰신 서울대학교 장병탁 교수님께서 이 책이 어떤 질문에 대해 답을 해줄 수 있는가에 대해 간략하게 2페이지로 정리해 놓으신 내용이 있습니다. (세상에! 간략하게 소개한 내용이 2페이지라고!!!) 하지만 제 나름대로 이 책을 생각해보면 결국 디지털 시대에 사는 우리가 앞으로 기술을 어떻게 바라봐야 하는가에 대해서 구글이라는 기술기업을 통해 생각해 보고자 한 것이 이 책의 핵심이지 않을까 생각합니다. 책을 간단히 소개해볼게요. 전반부는 구글이 탄생하게 된 배경이라던가 구글의 창업자 및 주요 인물들에 대한 설명으로 시작됩니다. 중반부와 후반부에도 각 부서의 핵심인물들에 대한 설명이 나오긴 하지만, 창업자 위주의 소개는 앞부분에 집중되어있습니다. 중반부는 구글이 알파벳이라는 지주회사 체제로의 변화를 꾀하게 된 이유를 현재 진행되고 있는 수많은 사업을 기준으로 해서 설명하고 있습니다. 후반부로 가면 구글이 사악한 기업인가 아니면 이상적인 혁신주의를 실행하고 있는 기업인가? 구글은 앞으로 더 커나갈 수 있는가 아니면 점점 쇠약해질 것인가? 구글이 현재 진행하는 수많은 혁신적인 프로젝트는 사람들을 더욱 풍요롭게 하고 구글을 구원할 것인가 아니면 그 반대가 될 것인가? 등등의 앞의 해제에서 정리한 각종 물음에 대한 저자의 생각과 주변의 시선을 정리해놓고 있습니다.

Google I/O Extended Seoul

작년에 이어 올해도 구글 I/O Extended 를 다녀왔습니다. 지난 일요일인 6월 19일에 있었던 행사지요. 제가 구글 I/O Extended 를 웬만하면 꼭 가는 이유는 두 가지 입니다. 첫째는 일요일에 하기 때문에 회사의 눈치를 볼 이유가 없다는 것. 일단은 회사에 제가 갔는지 안 갔는지를 말할 필요도 없거니와 어떤 내용이 있었는지를 보고할 이유도 없어서 마음 편하다는 것. 둘째는 집에서 가까운 세종대에서 2년째 계속하고 있다는 것. 느리게 걸어도 10분 정도면 갈 수 있는 거리에서 행사가 열린다는 것은 분명 기쁜 일. 뭐 어쨌건 올해도 신청해서 다녀왔습니다. 뭐 꽤 많은 분이 오셨더군요. 제가 들었던 세션은 아래와 같습니다. 안드로이드 N을 준비하는 개발자를 위한 안내서 Building Extraordinary Apps with Firebase Analytics Google's PRPL web development pattern Tensorflow 101 우리는 낮에도 꿈을 꾸는 개발자들~ Daydream 열심히 준비들 하셔서 열심히 강연해주시느라 고생하셨으므로 각 세션에 대한 감상은 적지 않겠습니다. 모두 수고 많이 하셨습니다. 그래도 한 분 Building Extraordinary Apps with Firebase Analytics 를 발표하신 Bart Jarochowski 님은 외국 분이신데 한국어로 발표하시느라 정말 열심이셨습니다. 고생하셨어요. 일 년 해봐야 제가 참가하는 컨퍼런스나 세미나는 겨우 두 개 아니면 세 개 정도입니다. 그것도 정말 열심히 해야 그 정도 되고 일 년에 겨우 한 개 정도 참여하는 경우도 있습니다. 하나라도 참가를 하고자 노력을 하는 이유 즉, 제가 컨퍼런스나 세미나를 참가하고자 하는 이유는 사실 굉장히 간단합니다. 10여 명 남짓의 개발팀 그것도 한가지 서비스를 위해 달려가는 개발팀에서 벗어나 잠시 많은 개발과 관련된 분야에서 일하시는 분들 속에

소프트웨어 장인 - 산드로 만쿠소

  출간일 : 2015년 9월 25일  328쪽 | 500g | 148*225*14mm ISBN-13 : 9791186659489 소프트웨어 장인 : 프로페셔널리즘, 실용주의, 자부심  원제로는 The Software Craftsman-Professionalism, Pragmatism, Pride  입니다. 이 책은 로버트 C. 마틴 시리즈로 열한 살부터 코딩을 시작했고 열아홉부터 코딩으로 돈을 번 경험이 있는 브라질 출신의 산드로 만쿠소 가 본인의 경험담을 통해서 소프트웨어 장인에 관해 이야기하고 있는 책입니다. 아는 동생의 가볍게 읽을 수 있는 책이라며 추천을 해줘서 읽게 된 책이죠. 평소 책을 고를 때 다른 것 보다 무게를 먼저 확인하고 나머지를 고르는 제 버릇때문인지 무게가 가볍다는 것을 먼저 이야기하면서 추천을 해 주더군요. 한동안 기술서적에 손을 못 대고 있는 상황에 있었습니다. 여러 가지 이유로 슬럼프가 좀 길게 온 탓에 기술 서적을 읽는 것은 물론 코딩 한 줄 손대는 것도 고통스러웠습니다. 회사 일이야 돈 벌어야 하니 어쩔 수 없이 하고 있지만, 집에 와서는 매일 인텔리제이를 켜놓고는 한 줄도 못 짜고 끄는 날이 대부분인 요즘이었습니다. 이럴 때 가볍게(?) 읽을 수 있는 책이라니 정말 반가웠습니다.  "그래! 이럴 때는 책을 읽으면서 뭔가 계기를 만들어야 해"라는 생각에 보게 되었습니다. 우선 빠르게 한번 읽고 난 다음에 포스트를 쓰고 있습니다. 이 책을 약간의 시간을 두고 한 번 더 읽어볼 생각인데, 아마도 그때는 다른 느낌이 있을지도 모르겠습니다. 지금부터 이 책을 읽으면서 느꼈던 점들을 지극히 주관적인 입장으로 정리를 한 번 해보려고 합니다. 이 책의 구성을 제 나름대로 보면 대충 아래와 같은 구성입니다. 1~3장은 애자일과 장인 정신에 대한 정의를 찾아가는 여정을 보여줍니다. 어떻게 해서 애자일이 나타났고 어떻게 소프트웨어의 장인정신에 대한 논의가 시작

Spring Cloud + Docker + Docker Compose

수정이력 2016/06/12 - Docker compose restart policy 관련 정리 수정. Docker compose의 스케일 조정 관련 정리 추가 서론 지금까지 정리된 내용은 스프링의 프로젝트들(Spring-cloud, Spring-boot 등)을 이용해서 간편하게 마이크로소프트 아키텍처를 구현해 나갈 수 있는가에 대한 입문 수준의 내용을 담고 있습니다. 여기에 더해서 오늘은 Docker를 이용해서 그동안 만들었던 서비스들을 모두 Dockerizing 하고 이왕 하는 김에 Docker Compose 를 이용하도록 바꿔보겠습니다. 아래의 내용은 blog_cloud_docker 브랜치에서 전체 소스를 확인하실 수 있습니다. 또한, 본 포스트 내용은  https://github.com/sqshq/PiggyMetrics  의 내용을 참고했음을 미리 밝혀둡니다. 내용은 비슷한데 본 포스트보다 훨~~씬 잘 정리되어있으니 위 깃헙을 보시는 것도 좋을 것 같네요. 사전 준비사항 오늘은 사전 준비사항이 좀 많습니다. Docker 설치 : Docker가 설치되어 있어야만 합니다. 설치법은 아래 링크에서 확인하세요. Mac OS X :  https://docs.docker.com/engine/installation/mac/ Windows :  https://docs.docker.com/engine/installation/windows/ Ubuntu :  https://docs.docker.com/engine/installation/linux/ubuntulinux/ (우분투 버전별로 설치법이 좀 다르게 설명되어있으니 확인해서 설치하세요) Docker Compose 설치 : Docker를 설치하셨으면 이번에는 Docker Compose입니다. https://docs.docker.com/compose/install/  의 설명을 잘 따라하시면 됩니다. 마지막 블로그 포스트의 소스가 필요합니다. https://g

Ubuntu 14.04 + Oracle Java 8 설치용 도커 파일

개발 장비에는 이런저런 테스트용 라이브러리들이 깔리고 지워지기를 반복한다. 특히나 개인 개발 장비의 경우는 더욱 그렇다고 볼 수 있다. 몇 년 전부터 회사와 집에서 개발용 장비로 Ubuntu 또는 CentOS를 사용하고 있는데, 사용하다 보면 라이브러리나 서로 다른 의존성을 가지는 솔루션을 무분별하게 설치하다가 결국 장비를 다시 설치해야 하는 불상사를 겪곤 한다. 불상사를 겪게 되는 이유 중 첫째는 나 자신의 부주의함과 무식함이 그 원인이겠지만, 어쨌거나 언젠가부터는 뭔가 설치를 하고자 하면 겁부터 나곤 한다. 그러다 알게 된 것이 Docker였다. Docker에 대한 설명을 이 포스트에서 진행할 생각은 없다. 단지, 여러 가지로 내 조건에 많은 부분 부합하는 것이 Docker 라는 Container 였다는 점을 이곳에 적어놓고 싶었다. Docker에 대한 자세한 사항은  https://docs.docker.com/  을 참고하면 되겠지만, 우선은  https://training.docker.com/self-paced-training  에서 먼저 튜토리얼을 진행해 보면 좀 더 빠르리라 생각된다. 내가 또 하나 처음 공부할 때 봤던 것은 [가장 빨리 만나는 Docker: 클라우드 플랫폼 어디서나 빠르게 배포하고 실행할 수 있는 리눅스 기반 경량화 컨테이너] (이재홍, 도서출판길벗, 2015년) 이라는 책을 구글플레이에서 구매해서 봤었는데, 이 책은 빠르게 볼 수 있어서 괜찮았다. 또한, 맨 뒤쪽에 Docker 명령어를 정리해놔서 레퍼런스로도 볼 만 하다고 할까. 참고로 저 책 저자와 전혀 관계도 없으며 책을 사라고 하는 이야기는 아니다. 최근까지 아무 생각 없이 Docker Hub 에 있는 다양한 Official 또는 개인이 올린 이미지를 이용해서 사용하고 있었는데, 자바프로젝트 역시 이미지의 기본은 Official로 올라온 java8을 주로 이용했었다. 그런데 이 이미지는 OpenJDK 로 만들어진 이미지였다. OpenJDK가 좋은가 O

Hystrix, Hystrix dashboard, Turbine 의 구성

서론 Hystrix 는 Netflix 에서 제공하는 Circuit breaker 모듈이다. Circuit breaker는 차단기를 의미하는데, 전자회로에서 이상 전류의 발생을 중간에서 차단하는 장치이다. 비슷한 의미로 소프트웨어 애플리케이션에서도 사용되는데, 이상 현상이 있는 서비스에 대한 요청을 일시적으로 차단하여 이상 동작을 최소화하도록 처리하는 것을 말한다. 소프트웨어 애플리케이션의 Circuit breaker에 대한 내용은  http://martinfowler.com/bliki/CircuitBreaker.html 에서 확인이 가능하다. 마이크로서비스 아키텍처에서는 Circuit breaker의 역할이 중요하다. 아키텍처 구조상 다양한 통신채널(Rest API 또는 Message bus 등)로 서로 통신을 하게 되는데, 이 과정에서 네트워크 문제 등으로 서로 간의 통신할 수 없는 경우가 많이 있다. 이럴 경우 연쇄적인 오류를 방지한다거나, 문제가 있는 서비스에 계속해서 요청하고 대기하는 등의 작업을 최소화할 필요가 있다. Spring cloud에서는 Ribbon Loadbalancer와 함께 Hystrix를 이용한 Circuit breaker 를 사용하여 이러한 문제를 최대한 단순하게 처리할 수 있도록 제공하고 있다. 이번 포스트는 이 내용을 정리해보고자 한다. 이번 포스트에서 참고한 내용은 아래와 같다. Calistaenterprise 블로그 :  http://callistaenterprise.se/blogg/teknik/2015/04/15/building-microservices-with-spring-cloud-and-netflix-oss-part-2/ Josh Long의 Devoxx 2015 :  https://www.youtube.com/watch?v=SFDYdslOvu8&list=WL&index=3 이번 포스트를 준비하면서 테스트한 환경은 아래와 같다. Configuration Server 와 Di

Edge server와 Ribbon, 그리고 API 구성

서론 여기서 말하는 Edge Server는 다양한 API 서버들을 연결하는 Gatekeeper와 비슷한 역할을 그 주요 기능으로 한다. 이 외에 구성에 따라서는 외부 클라이언트와의 연결에서 Security의 진입점 같은 역할도 하기는 하지만, 그 부분은 다른 포스트에서 정리해볼까 한다. 이번 포스트를 정리할 때 사용한 예제는 대부분을 Calista 블로그의  Building microservices with Spring Cloud and Netflix OSS, part 1 에서 참고하였다. 사실 위 블로그의 내용을 거의 똑같이 따라 하면서 정리했다고 보는 것이 맞을 것 같다. 이 포스트보다 정리가 잘 되어있는 만큼 영어에 어려움이 없는 개발자라면 Calista 블로그의 내용을 보는 것이 더 나을지도 모르겠다. 한가지 참고할 수 있는 자료가 더 있는데 다른 포스트에서도 소개했던 적이 있는 Devoxx 2015 의 동영상 자료가 있다. 제목은  Getting started with Spring Cloud by Josh Long 으로 1시간 정도 라이브 코딩으로 Josh Long이 열정적으로 설명해준다. 영어를 못하는 나도 어느 정도 따라갈 수 있었던 동영상으로 강추하고 싶은 동영상이다. 시작하기에 앞서서 좋은 블로그 자료를 공개해줘서 샘플을 만들고 정리하는 데 도움을 준 Calista 블로그에 감사의 마음을 전하며, 자료를 함부로 가져다 쓰게 된 점에 대해 매우 미안한 마음을 전한다. 이번 포스트를 정리하기 위해 사용한 샘플은 아래와 같은 조건으로 작업이 되었다. Configuration Server 와 Discover Server : 이전 포스트 참고 JDK 8 : 1.8.0_65 Intellij 15.0.3 Gradle build : 2.10 Spring IO : 2.0.1  Spring Boot : 1.3.2 (이전 포스트 작성후에 버전이 1.3.1에서 1.3.2로 업그레이드됐다) Spring Cloud :  Angel