road..道..みち

서론 이글을 쓰고 있는 나는 마이크로서비스의 전문가가 아니다. 마이크로서비스는 커녕 마이크로서비스 이전에 나왔던 Service-Oriented Architecture(SOA) 조차도 설계하거나 구현하거나 적용해 본적이 없다. 그저 최근 1~2년간 뉴스리더나 각종 컨퍼런스에서 마이크로서비스라는 말을 들었고 흥미로운 접근 방식이라 생각했으며, 최근 springframework의 spring-cloud 프로젝트를 가지고 파일럿을 진행하는 과정에서 좀 더 관심이 생겼을 뿐이다. 파일럿을 진행하다보니 개념적으로 정립이 안되어있어서 그런지 혼란이 올때가 많이 있다. 그래서 생각을 좀 정리할 겸 마틴파울러의 2014년 마이크로서비스에 대한 글을 참고로하여 그 개념을 정리하려고 이 글을 쓰게 되었다. [원문 : Microservices - a definition of this new architectural term] 전문가는 커녕 굉장히 얕은 지식으로 이해를 하다보니 잘 못 이해한 부분도 있고, 영어실력이 그리 뛰어나지 않아 오해한 부분이 있을지도 모르겠다. 마지막으로 이 글은 일부 마틴파울러의 글을 번역해서 사용했지만, 전문 번역을 한 글이 아님을 밝힌다. 마이크로서비스란 무엇인가? 마이크로서비스 패러다임은 아래와 같다. 작은 기능을 하는 독립된 작은 서비스를 독립된 어플리케이션으로 개발한 것이다. 독립된 어플리케이션들은 다른 어플리케이션과 통신하여 좀 더 복잡한 서비스를 만들 수 있다. 어플리케이션간의 통신은 경량 매커니즘으로 된 통신 방법을 이용해야 한다. 독립적인 비즈니스 기능을 가지고 있어야 하고 독립적이면서 자동화된 방식으로 배포가 가능해야 한다. 최소한의 중앙집중식 관리시스템에 의해서 관리가 가능해야 한다. 서로 다른 기술로 만들어질 수 있어야 하고 독립된 저장소를 가질수도 있다. 뭔가 좋아는 보이지만 개념이 확 와닿지 않는다(최소한 나 같은 경우는 그랬다). Monolithic service 와 비

서문 프로젝트를 진행하다보면, 배포 환경에 따른 설정 파일 관리에 여러가지로 어려움을 겪는 경우가 많다. 개발 환경설정파일에만 내용을 넣고 배포를 한다던가 배포시에 프로파일을 잘못 설정해서 배포가 된다던가 하는 실수들은 작지만 상당히 귀찮은 확인 작업을 동반하기도 한다. 그나마 자동화된 배포툴(Hudson 등등)을 사용하여 잘 짜여진 배포 프로세스를 만들어 놓은 훌륭한 회사에서는 그나마 이런 실수들을 줄일 수 있는 방법이 많지만, 아직도 쉘을 이용한 배포를 하는 우리 회사 같은 경우는 작업자의 실수를 가끔씩 겪을 수 밖에 없다. (이 경우 윗 사람으로 부터의 더 가혹한 소리들을 들어야만 한다. 부주의에 의한 실수이기에...) 특히, 실수가 일어난 경우 해당 내용을 확인하기 위해서는 배포되어있는 서버에 들어가 일일이 파일을 확인해야 하는데 이 작업 또한 만만찮은 귀찮은 작업 중 하나다. 모든 툴 들이 그렇듯 완벽하게 모두 해결해 주지는 않지만 Spring Cloud 의 Configuration 서버의 경우는 간단한 설정만으로도 꽤 괜찮은 솔루션을 제공해주고 있다. 이 글은 최대한 간단하게 만들어진 Configuration Server 에 대해서 정리하고자  작성된 글이다. (거의 Spring Cloud 프로젝트 사이트의 Document 를 간단히 정리한 수준임을 밝혀둔다) 요구사항 - 버전 관리를 편리하게 하고 Gradle 을 간단히 유지하기 위해서 Spring IO 를 이용한다. - Gradle 은 이전 포스트에서 작성했던 multi project 대응의 build.gradle 설정에서 시작한다.   ( 이전글 보기 ) - Configuration Server 는 Configuration Server의 local properties 를 이용한다. (github을 이용한 방법에 대한 설명은 인터넷에 굉장히 많고 spring cloud 프로젝트 사이트의 샘플도 이것으로 되어있으니 참고 바람) Spring IO 설정 gr

개요 회사에서 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 을 설정한다. 본인의

뭐 역시나 내가 직접 조사한 것은 아니고 Java Code Geeks 에서 본 내용에 대한 정리이다. 자세한 사항은 [원문보기]  를 클릭해서 확인하면 된다. 원문에서는 코드와 스크린샷을 포함한 예제를 확인할 수 있으니 내용을 보시고자 하시는 분들은 꼭 원문을 참고하시길... 내가 쓰는 포스트가 대부분 그렇지만, 이 글도 그저 내용을 정리해서 내가 나중에 확인하기 위해 쓰는 글일 뿐... 1. Files.probeContentType(Path)를 이용하는 방법 [JDK 7] 이 방법은 파일 확장자를 이용해서 판단하는 것으로 보인다. 즉, gif 파일을 png라고 확장자를 주면 png 로 인식한다는 것. 또 확장자가 없는 파일의 경우는 null 을 리턴한다. 2. MimetypesFileTypeMap.getContentType(String) 을 이용하는 방법 [JDK 6] 이 방법은 클래스 명에서 유추가 가능한 것 처럼 Mime type 을 이용한다. 앞서의 경우와 같이 gif 파일을 png 라고 하거나 pdf 파일을 txt 로 하거나 하면 확장자로 판단을 한다. 1번 경우와 다른 점을 이야기하자면 기본적으로 텍스트나 이미지 확장자가 아닌 경우에는 xml 파일을 포함해서 application/octet-stream을 반환한다. 또한 확장자가 없는 파일의 경우도 application/octet-stream을 반환한다. 3. URLConnection.getContentType() 이 방법 역시 확장자에 의한 판단. 대신 null 대신 content/unknown을 반환 4. URLConnection.guessContentTypeFromName(String) 역시 확장자. 3번과 다른 것은 null을 반환. 5. URLConnection.guessContentTypeFromStream(InputStream) 예제에서는 전부 null 을 반환. 저자의 설명에 따르면 여기서 매개변수로 주어진 InputStream은 marks를

SpringOne2GX 에서 있었던 Gradle 과 Jenkins 를 이용한 CD Pipeline 구성에 대한 Webinar. 오늘은 CD/CI 와 관련된 Webinar에 대한 소개. 사실 소개라기 보다는 자료를 저장해 놓으려고 쓰게 된 포스트. 뭐 이런저런 핑계로 실제로는 Jenkins 를 이용해서  pipeline 을 구성해 본 적이 없지만, 항상 도전하고 싶은 분야이긴 하다. (아직 회사에서는 bash 를 이용 deploy를 진행하고 있다) 전체적으로 매우 도움이 될만한 내용을 담고 있는데 대충 아래와 같은 내용을 포함하고 있다. Gradle과 Git 을 이용한 기본 빌드 및 버전 관리. Gradle 에 파라미터를 이용하여 Environment Configuration 을 관리하는 방법 Test(Unit/Integration)/Code Analysis/Deploy 툴과의 연계 등과 관련된 Gradle 설정 방법 Jenkins를 이용한 테스트 및 Deploy 까지의 Pipeline 구성 방법 gradle 에 Pipeline 각 단계에 필요한 task 를 정의하고 command line 에서 어떻게 동작이 되는지를 보여준다. 그리고 마지막 부분에 그 task 들을 이용해서 어떻게 Jenkins를 구성하는지까지를 설명하고 있다. 플레이타임이 약 1시간 30분으로 짧지 않은 시간인데다 자막이 제공되지 않아서 영어를 못하는 나같은 경우는 많이 힘들었지만, 관심있는 사람들은 한 번쯤 꼭 봐 둘만한 내용일 것 같다. 아래와 같은 분들께 추천... Continuous Delivery, Continuous Integration이 뭐지? 하시는 분들. Unit/Integration test, Code Analysis, Manual Deploy 모두 또는 일부를 프로젝트에 사용하고 있지만, 왜 하지 라는 생각을 하시는 분들. 개발에서 배포까지 매번 너무 힘들어서 못 해먹겠다고 생각하시는 분들 Devops 에 관심이

[원문보기 : 10 Tips for Creating a Winning Business Plan in PowerPoint] 위의 내용을 요약하면 아래와 같다. 사업계획을 발표용 PowerPoint presentation으로 만드는 방법의 가장 기본적인 Rule 은 10-20-30 규칙. 즉, "10 슬라이드, 20분 분량, 최소 폰트 크기는 30 pt" 라는 것이다. (만들어보면 이것 정말 어려운 일이다) 이것을 가능하게 하는 Tip. 1. 첫 슬라이드는 비즈니스명(또는 발표제목), 발표자 이름/직위/연락처. 그리고 있다면 slogan 을 적는다. 2. 다음 슬라이드는 비즈니스의 타겟 마켓이 가지는 문제점에 대해 적는다. 통계가 있으면 설명이 쉽지만, 가장 적합하다고 생각하는 통계 두개 정도만 언급하고 넘어가자. 3. 다음 슬라이드는 두번째 슬라이드에 대해서 내 비즈니스가 어떻게 문제점을 완화 시키는지에 대한 간략한 설명을 넣자. 단, 청중에게 내가 유니크하게 접근했다는 것을 이해시키는 것이 중요. 4. 다음은 수익 모델에 대해서 설명한다. 수입원은 무엇인지, 고객이 누구인지, 만약 요금제라면 요금제는 어떻게 이루어져 있는지 등을 설명. 5. 다음으로 좀 더 자세한 운영 계획에 대해서 설명하자. 전체 비즈니스가 어떻게 이루어지는지에 대해서 설명하자. 이 부분에서 아주 약간의 기술적인 언급이 있어야 하지만 정말 적은양의 기술적인 언급만 하도록 하자. 6. 이제 내 마케팅 플랜에 대한 요약본을 넣자. 무엇보다도 청중에게 내가 합리적인 비용내에서 효과적인 마케팅 계획을 가지고 있다는 것을 알리면 된다. 7. 주요 경쟁자들에 대해서 소개하자. 경쟁자를 무시하거나 하지말고 내가 경쟁우위에 있다는 점을 부각시키자. 8. 내 팀에 대해서 설명하자. 팀에 대한 설명이 매우 중요하다는 것을 잊지 말자. 9. 이쯤에서 앞으로 3년, 5년 매출 목표에 대해서 소개하자. 10. 마지막으로 현재 내 비즈니스가 어디