Polpid's Pensieve

한빛 미디어 "나는 리뷰어다" 에서 "아마존 웹 서비스 인 액션" 을 보내줬다. 실제로 회사에서는 업무와 직접 연관이 없어서 사용을 못해봤지만 항상 써봐야겠다는 생각 하고 있었다. 그런데 실제로 어떻게 쓴는 건지도 모르고 겨우 알고 있는것은 무료 계정을 만드는 정도밖에 몰랐다. 덕분에 예전에 아마존 세미나 가서 받았던 100달러 크레딧도 하나도 안쓴채 그대로 계정에 남겨져 있었다.

이 책 덕분에 현재는 AWS 에 내가 만들어 놓은 우분투 서버가 돌고 있다. 그안에 뭔가를 만들어서 운영중이지는 않지만 지금은 주로 우분투에 설치 되어있는 DB를 쓸일이 있어서 심심치 않게 사용을 하고 있다. 

2017/06/17 - [Development/AWS] - [AWS]AWS 에 가상서버 만들기

2017/06/20 - [Development/AWS] - [AWS]AWS 가상 서버에 고정 공인 IP 주소 할당하기

책을 보면서 따라해보면 실습도 어렵지 않게 할 수 있다. 

책은 AWS 에 대한 설명부터 시작해서 서버 사용, 운영하기, 배포, 보안 설정, DB, 아키텍쳐 설계에 이르기까지 AWS를 이용해서 할수 있는 많은 내용들이 담겨져 있다. 

위 사진은 실제 책 내용에 들어있는 그림이다. 실습을 진행하면서 쉽게 따라 할수 있도록 그림에도 화살표 표시를 해놓았다. 가끔 컴퓨터 관련 책들을 읽다 보면 글과 그림이 같이 나오는데 글의 내용이 그림의 어느 부분을 가르키고 있는지 찾기가 힘들때가 있다. 다행스럽게도 이 책에서는 화살표 표시를 해줘서 실습을 혼자서 진행하는데 무리가 없다.

그리고 "클린업" 이라는 중요한 코멘트가 각 실습의 끝네 나온다. 이 "클린업" 이라는 코멘트는 실습에 사용한 AWS 인스턴스를 초기화 시킨다던지 제거 한다던지 하는 내용을 담고 있다. 내가 가입 되어있는 페이스북 SNS 에 가끔씩 AWS 를 사용하다가 요금 폭탄을 맞았다는 사람들의 글을 올라온다. 나같은 무료 계정을 사용하고 있기 때문에 1년간 무료로 사용할 수 있지만 이 무료가 모두 다가 무료가 아니다. 일정 범위내에서 사용을 해야 무료이고 무료의 범위를 넘어간 사용량에 대해서는 당연히 과금이 들어간다. 그렇기 때문에 저 "클린업" 이라는 코멘트는 이책을 보고 실습을 하면서 비용이 발생하지 않도록 방지하는데 꼭 필요한 요소이다. 그리고 실습내용에 앞서서 현재 실습 내용은 무료범위에서 가능하다라든지, 이번 실습은 무료 범위를 벗어난다라든지 요금에 관련된 주의 사항이 항상 써있다. 내가 AWS 관련 책들을 많이 읽어보지는 않았지만 이 부분이 이 책의 큰 장점이 아닐까 생각이 된다. 

지금은 많은 부분을 다양하게 사용하고 있지는 않지만 앞으로더는 더 자주 다양한 방법으로 사용하게 될것 같다. 그래서 이 책은 AWS 를 활용하기 위한 가이드 북으로 딱 좋다고 생각이 된다. 

회사에서 Spring boot를 사용하기 시작한지는 한 1~2년 정도 된것 같다. 쓴다기 보다는 Spring 사이트에 있는 소스들을 가져다 붙이는 수준이었다. 체계적으로 공부해본적은 없고 눈앞에 닥치면 찾아서 하다보니 부족한 점이 많이 느껴졌다. 이번에 받은 이 "실전 스프링 부트 워크북"은 그런 부족한 점을 채워줄수 있는 좋은 가이드가 되었다. 

Chapter 1에서 부터 4까지는 Spring Boot를 실습하기 위한 준비 단계정도로 볼수 있다. 기본적인 이론과 설명들, 프로젝트 구성에 대해서 소개를 해주고 있다. 그리고 Chapter 5부터 본격적으로 Spring Boot를 가지고 Web 어플리케이션을 만들기 시작한다. 

특히 Chapter 6 을 보면 Spring Boot Test 에 대해서 설명을 하고 있는데 책을 읽을 당시 회사에서 Spring Boot Test에 대한 내용을 한참 구글링 하던 시기였다. 내가 개발중인 코드에 대한 Controller Test case를 어떻게 작성을 해야 하나 고민을 하던 중이었는데 책의 내용들이 내게 많은 도움이 되었다. 아마도 이 책이 없었으면 코드가 뭐가 뭔지도 모를 코드들을 가져다가 썼을것이다. 

그리고 이 책의 좋은 점이 실제 작성된 코드에 대해서 중요한 부분에 대한 설명들이 많이 있다는 점이다. 다른 Spring 관련 책들도 소스 코드에 대한 설명들이 있기는 하지만 너무 추상적이거나 어렵게 설명한 책들이 많다. 하지만 이책에서는 적어도 내 기준에는 각각의 소스 코드에 대한 설명들이 이해하기가 쉬웠다. 그리고 개발관련 서적의 딱딱함이 덜 하다는 느낌이 들었다. 

기본적인 Spring Boot 에 대한 설명부터 시작해서 security, 메세징등 기본적으로 알아야 할 기능들은 잘 설명해 놓은 책이다. 물론 이거 한권으로 Spring Boot에 대한 모든 기능을 마스터 할수는 없지만 기본기를 다지기에는 아주 좋은 책이라고 생각이 든다. 단지 아쉬운 점은 이 책에도 중간중간 언급이 되어있지만 지금 사용하고 있는 Spring Boot 최신 버전과는 약간 차이가 있을 수 있다는 점이다. 책에서는 1.3.3 Release 버전을 사용하고 있는데 현재 Spring Boot 최신 버전을 1.4를 넘어 1.5, 2.0을 바라보고 있다. 이부분에 대한 것만 제외 한다면 Spring Boot에 관심 있는 분들에게 한번쯤 읽어보라고 추천해주고 싶다. 

  내가 마이크로 서비스 라는 말을 처음 들었던 것은 재작년이었던 것 같다. 회사에서 업무 때문에 처음 접하게 되었던 이 용어는 좀처럼 이해하기가 쉽지 않았다. 그리고 마이크로 서비스라는것 자체가 아직은 먼 이야기라고 생각이 되었다. 그때만 해도 "말이 쉽지. 이게 되겠어?" 라는 의심이 더 컸던것 같다. 하지만 최근에는 많은 서비스 들이 기존의 물리적 인프라 위에서 서비스를 제공하는게 아니라 클라우드 상에서 서비스를 제공하는 일이 많아 지면서 마이크로 서비스 아키텍처라는게 더 힘을 받고 있는것 같다.  

마이크로서비스

마이크로서비스란 작고 자율적으로 협업하는 서비스를 의미한다.

  단어의 뜻 자체는 그렇게 어렵지 않다. 말 그대로 "Mirco(작은단위)" + "Service",  작은 단위의 서비스를 말한다. 각각의 서비스들은 하나의 독립된 주체이며 전체는 각각의 서비스들의 집합라고 생각하면 될것 같다. 하지만 이렇게 시스템을 구성하기에는 그렇게 쉬운 일은 아니다. 이 책에서는 이렇게 쉽지 않은 마이크로서비스 아키텍처에 대해서 알아야할 이론적인 내용에 대해서 설명해주고 있다. 마이크로 서비스에 대한 정의부터 시작해서 모델링, 통합, 분해, 배포, 테스팅, 모니터링, 보안에 이르기 까지 전체적인 그림을 그릴 수 있는 내용을 담고 있다. 

  많은 내용을 담고 있지만 그중에서도 몇가지 눈여겨 본 대목을 뽑아봤다. 

  하나의 시스템을 설계 하는데에 아키텍트의 역할은 정말 중요하다. 위에 글처럼 아키텍트가 결정한 방향의 파급력은 프로젝트 내에서 정말 어마어마 하다. 방향 한번 잘못잡았다가 프로젝트가 산으로 가는 경우도 정말 많다. 그만큼 아키텍트는 의사결정에 있어서 신중해야 하고 많은 것들을 고려해야 하는 역할을 가졌다. 그리고 설계와 함께 개발에 대해서도 어느정도 이해를 하고 있어야 한다. 수채화를 그리는데 밑그림만 다 그렸다고 그림이 완성된것은 아니다. 밑그림 위에 알맞은 색깔을 칠한 후에야 그림이 완성되는 것이다. 그렇기 때문에 아키텍트가 그린 그림을 구현하는 개발 담당자들과의 협업이 그만 큼 중요하다. 가끔 이 역할 관계가 갑을관계처럼 엮이는 경우가 있다. 아키텍트가 설계를 하면 마치 그것이 마치 불변의 법인것 처럼 행동하고 잘못된것을 지적하거나 의문점을 제시하면 받아들이지 않는 사람들이 있다.  그리고 프로젝트의 인프라와 기간, 인력등을 고려하지 않고 이상만을 추구해서 설계를 하는 아키텍트들도 있다. 그리고 나서 안되면 개발자를 탓한다. 이런 상황을 겪어보다 보니 위에 나온 내용을 읽으면서 절로 고개가 끄덕여 졌다. 

  마이크로서비스 아키텍처 상에서는 각각의 기능들이 서로 다른 기능들을 이용하기 위해서는 통신을 해야 한다. 그렇다 보니 서비스간 호출에 대한 정의도 해야하고 보안 또한 중요하다. 아무래도 내부 호출보다는 외부 프로토콜을 이용한 호출이다보니 보안에 취약할 수 밖에 없다. 취약하다기 보다는 더 신경을 써야 한다. 서비스에 대한 호출이 정당한지, 아니면 권한과 역할에 대한 정보를 제대로 가지고 있는지 확인해야 할 정보들이 많다. 그래서 게이트웨이를 쓰고 인증토큰을 발행하고 정보를 암호화 하는 절차들이 필요하다. 전체적인 아키텍처 그림이 위하고 항상 같을수는 없지만 기본적인 틀은 아마 비슷할 것이라고 생각이 된다. 

  나도 현재 마이크로서비스로 구성하지는 않았지만 비슷하게 서비스를 구성하면서 보안에 관련된 검증을 받았었다. 생각지도 않은 곳에서 사용자 정보가 노출이 되고 쉽게 다른 사람의 정보를 수정/삭제 할수 있다는 것을 직접 체험을 했고 그것을 보완하면서 많은 것을 배웠다. 아마도 저 그림이 눈에 들어온 것은 그것때문이었던것 같다. 

  마이크로서비스 아키텍처는 실버불릿은 아니다.

  항상 모든것은 지나치면 오히려 독이 된다. 마이크로서비스가 최근들어 주목을 받고 있긴 하지만 모든 곳에 다 적용할 수 있는 만능은 아니다. 오히려 모놀리스 아키텍처의 구조를 가져가는게 더 알맞은 프로젝트들도 있다. 무작정 하게 되면 오히려 독이 될 수 있다. 마이크로서비스 아키텍처를 적용하기 위해서는 이 구조가 가진 장점들을 잘 살리고 단점들을 잘 보완 할 수 있는 설계를 할 수 있어야 하고 많은 것들을 고려해야 한다. 

  책을 읽으면서 대학교 전공 서적같은 느낌이 들었다. 지금은 번역서를 읽어서 그렇지만 영문 원서였으면 아마도 예전에 대학다닐때 운영체제 전공과목을 들었을 때와 더 비슷한 느낌이 들었을것 같다. 그만큼 많은 내용이 담겨 있고 어려운 내용들이다. 단순히 한권의 책을 읽었다고 해서 마스터 될 영역은 분명 아니다. 하지만 각각의 포인트에서 생각해야 할 점들을 잘 설명해주고있다. 좀 아쉬운점은 번역서이다 보니 번역투의 표현들이 눈에 띄었다. 약간은 매끄럽지 않다고나 할가. 그리고 설명에 대한 그림들이 좀 부족한것 같다. 글로 설명하기가 어려운 내용들을 그림으로 표현해서 설명을 했을때 이해가 더 쉽듯이 책에서 설명하고 있는 내용들을 좀더 그림으로 풀어줬으면 더 좋았을 것 같다는 생각이 들었다. 

마이크로서비스 아키텍처 구축 국내도서 저자 : 샘 뉴먼(Sam Newman) / 정성권역 출판 : 한빛미디어 2017.03.01 상세보기

  예전에는 그냥 JAVA 기반에 eclipse 설정만 하고 코딩만 했었다. 주변 환경에 대해서는 거의 신경을 안썼고 별로 관심도 없었다. 그런데 점점 프로젝트를 하면서 개발 환경 구성하는 작업들을 볼 기회가 많아졌다. 그리고 내가 직접 구성하거나 환경 설정을 해야 하는 일도 자주 생기게 되었다. 그러다 보니 자연 스럽게 리눅스에 대한 관심이 가게 되었다. 항상 사용할때마다 구글에서 검색해서 명령어 정도만 찾아보고 뭔가 기억해야 겠다는 생각은 해본적이 없었다. 그때그때 찾아 쓰면 되지 라는 생각이 컸다. 

  올해 초에 이 책이 나온 것을 알고 살가 말까 고민 하고 있던 시기에 한빛리더스 14기에 선정이 되었고 첫번재 미션으로 받은 도서 목록에 이 책이 있었다. 그래서 미션 도서 선정 때 아무런 망설임이 없이 이 책을 선택했다.

  이 책에서는 VMware를 사용해서 일반 호스트 PC에 4개의 게스트 OS를 구성해서 실습을 진행하고 있다. 게스트OS로는 리눅스 서버 2대, 리눅스 클라이언트 1대, 윈도우 클라이언트 1대로 구성되어있다. VMware를 사용한 이유는 책에서도 언급이 되어있지만 집에서 사용하는 1대의 PC에서 window가 아닌 다른 운영체제를 구성하는 부분에 대한 부담을 덜기 위함이다. 

  우분투 리눅스에 대한 설명을 하면서 중간중간 일반적인 하드웨어, 네트워크에 대한 내용들도 나와 있어서 전반적인 서버 구성 및 네트워크 구성에 대한 지식도 쌓을 수 있다. 책을 보면서 실습 하는 것도 중요하지만 이런 배경이 되는 기초지식에 대한 이해도 중요하다고 생각하는 나로써는 책의 내용이 정말 만족스러웠다. 

  각각의 챕터 앞부분에는 학습목표와 진행 방향이 간단히 요약 정리되어 있어서 이번 챕터에서는 무엇을 공부하고 무엇을 알아야 하는구나 라는 것을 알 수 있다. 

  또 설명을 하면서 캡쳐 화면이 많아서 실습 하는데에 도움이 많이 된다. 실제 PPT를 보는 듯한 느낌의 화면과 상세한 설명, 주석으로 내용을 이해하는데 어렵지 않았다. 위에 그림처럼 캡쳐 화면에서 화살표 표시는 실습하는데 헷갈리지 않고 차례차례 진행하는데 도움이 되었다. 그리고 꼭 알아야 되는 부분에 중요 표시를 해둬서 나처럼 처음 공부하는 사람들이 어떤 부분이 핵심이고 아닌지를 잘 판단할 수 있다. 

  그리고 마지막으로 중요한 점은 유투브 동영상 강의가 있다는 점이다. 솔직히 책 두께로 봐서는 들고다니면서 읽기는 불가능 하다. 하지만 그것을 대신해서 유투브 강의가 제공되니 이동시에는 강의를 시청하고 책과 병행 하면서 예습, 복습을 한다면 더 효과적으로 이해를 할수 있다. 

  책 두께에서 오는 포스처럼 약간 바이블 같은 느낌이 나는 학습 책이지만 그만큼 그 역할을 충실히 하고 있는 책이 아닌가 생각이 된다. 그만큼 저자 분이 책 내용에 세심한 노력을 기울였다는 생각이 책 곳곳에 보인다. 한가지 분야에 대한 책을 고를때 상당히 고민을 많이 하는 편인데 이번에 정말 좋은 책을 잘 읽었다는 생각이 들었다. 

원문 : Refactoring open source business models

http://www.hanbit.co.kr/network/category/category_view.html?cms_code=CMS7808268979

오픈소스 비즈니스를 운영하는 것은 오픈소스 커뮤니티의 일부가 되는 것과는 많은 차이점을 가지고 있다.

저는 Lucidworks에서 일할 때 맨 처음 영업 상담 전화를 잊지 못할 것입니다. 우리는 막 펀딩의 첫걸음을 시작하고 첫번째 영업사원을 고용했습니다. 저는 기술적 자원으로써 잠재적인 고객들과 통화를 했습니다. 통화가 끝날 때 즈음 저는 고객들의 기술에 관련된 모든 질문에 대답을 했고, 그 결과 영업사원의 기회를 차례로 망쳐버렸습니다. 고객들은 우리회사의 도움없이도 자신들의 문제를 해결할 수 있었습니다.

저는 오픈소스 비즈니스를 운영한다는 것은 오픈소스 커뮤니티의 일부가 되는 것과는 많이 다르다는 것을 빨리 깨달았습니다. 우리가 지원을 우선시 하는 사업에서 제품에 초점을 맞춘 조직으로 성장함에 따라 지난 몇 년 동안 이 테마에 대한 변화는 정기적으로 발생해왔습니다.  모든 사업과 마찬가지로 우리는 어떻게 수입을 만들어낼지 생각해야 합니다. 오픈소스 비즈니스들은 주요 제품의 결과물이 프리(Free) 라이선스가 된다는 고유한 특성을 가지고 있습니다.  이것으로 인해 심각한 가격 하향을 야기하는 경우는 최선의 경우입니다. 최악의 경우에는 무료 소프트웨어, 무료 지식, 무료 지원처럼 모두 무료가 됩니다.

만약 오픈소스 프로젝트로 비즈니스를 하고 싶다면 당신은 이 현실이 어떻게 돌아가는지 알 필요가 있습니다. 실제로 “당신의” 코드 베이스가 실제로 당신 소유가 아니고 Apache Software Foundation과 같은 오픈소스 기관의 소유일 경우 더욱 복잡해 집니다. 그리고 당신은 종종 “당신의” 샌드박스 내에서 이익이 상충이 될 수 있습니다.

Lucidworks에서는 컨설팅과 지원을 우선적으로 하면서 “어떻게 이익을 만들수 있나” 라는 질문에 대답하기 위해 여러번 반복을 했습니다. 이것은 점차적으로 오픈소스로 직접 만들기를 원하는 사람들을 지원하는 옵션을 가지고 있으면서도 오픈소스로 만들어진 플랫폼을 판매하는 우리의 현재 모델로 진화를 했습니다. 이러한 접근에는 각각의 장점과 단점이 존재합니다.

컨설팅이 알맞은 팀에게 큰 이익을 가져다 줄 수는 있지만 변경하기가 힘듭니다. 따라서 마진이 적고 거의 벤처 기업 정도의 수익을 창출하는 회사가 알맞습니다. 우리들에게는 초기 컨설팅 프로젝트들은 무슨 기능을 만들지 학습하는데 중요한 역할을 했습니다.

당신의 소프트웨어가 유비쿼터스이고 반복되어 발생하는 계약의 사용자 비율을 변환할 수 있다면 지원은 정말 좋은 사업이 될 수 있습니다. 어떤 경우에는, 지원은 단지 초기에 소프트웨어에 버그가 발생하는 기간에만 필요하다고 생각했습니다. 그리고 일단 고객들이 초기 러닝커브를 극복하고 성공적인 배포를 하게 되면 기업들은 판매를 위한 다른 모델을 찾도록 강요합니다.

많은 기업들은 상업적 확장을 위해서 오픈소스 프로젝트를 선택합니다. 그리고 그들은 사람들이 부가적인 추가 기능을 사용하기 위해 돈을 지불하기를 기대합니다. 여기에서 문제는 특정 업체에 종속되거나, 또는 커뮤니티에 의해 만들어진 유사한 기능과 구분되고 지원을 강요 받는 데에서 생기는 어려움입니다. 만약 좋은 스위트 스폿을 찾았다면 당신이 커뮤니티의 좋은 집사 역할을 하는 동안은 마진을 유지할 수 있을 것입니다. 하지만 제품 개발에 대한 예리한 눈을 가지고 사용자가 실제로 필요한 것을 더 잘 이해하기 위해 지원하고 컨설팅 한 후에 성장하는 경우도 있습니다.

최선의 선택은 무엇일까요? 물론 대답은 당신의 오픈소스 프로젝트의 특별한 능력을 포함한 회사가 어떻게 출자됐는지, 팀의 스킬셋, 경쟁구도와 같은 다양한 요인에 따라 결정됩니다. 당신이 스스로 확산하지 않는 한 하이브리드 모델도 실용적이 될수 있습니다.

결론적으로 오픈소스 기업으로서 여전히 커뮤니티가 성장하고 육성되는 동안 “무료”라는 함정을 회피하기 위한 방법을 빠르게 결정해야 합니다. 단지 소프트웨어 회사로서 정상적으로 작동되지 않는 모델을 리펙토링하는 것을 두려워해서는 안됩니다. 

원문 : 3 challenges for using Docker

http://www.hanbit.co.kr/network/category/category_view.html?cms_code=CMS3858827361

컨테이너가 어떻게 사용되고 어떤 기술과 인프라가 채택되고 있는지 알아봅시다.

요즘 컨테이너는 IT 업종에서 가장 뜨거운 주제입니다. 그런데 실제로 컨테이너가 어떻게 사용되고 있습니까? 2015년 5월에 Ruxit과 공동으로 O"Reilly Media는 현재 조직이 어떻게 컨테이너를 사용하고 있는지 또는 사용할 계획인지를 공유하기 위해 O"Reilly커뮤니티에 사람들을 초대해서 조사를 했습니다.
그 결과 컨테이너 기술들은(특히 Docker는) 어플리케이션 배포를 빠르고 쉽고 보다 유연하게 해주기 때문에 빠르게 채택되고 있는 것으로 밝혀졌습니다. 2015년 DockerCon에서 있었던 설문에서는 컨테이너를 어떻게 사용하고 있는지,어떤 컨테이너 기술과 인프라를 채택하고 있는지 그리고 그 컨테이너를 사용하는 데에 동기를 주거나 연관된 요소들은 무엇인지 밝히는 데에 중점을 두었습니다.

컨테이너, 확실하긴 하지만…
설문 응답자들 중 40%는, 현재 개발을 위해 사용하고 있다는 86%와 비교하여 "생산을 위해 컨테이너를 사용한다"고 대답 했습니다. Docker 컨테이너는 "한번에 빌드를 하고 언제 어디서나 실행 가능하도록" 설계 되어있습니다. 그런데 왜 컨테이너를 생산에 좀더 많은 부분에서 사용하지 않는 걸까요? 응답자들은 컨테이너를 채택하기 위해서는 기술의 성숙도, 오케스트레이션, 모니터링,자동화, 그리고 환경의 크기뿐만 아니라 컨테이너를 적용함으로써 생기는 장점을 개발팀, 관리팀, 고객에게 설득해야 하는 어려움도 존재 한다고 대답했습니다.


적용하는데 걸림돌이 되는 기술 성숙도
56%이상의 설문 응답자들은 컨테이너 기술을 활용한 인프라 구조로 변경하는데 가장 큰 장벽은 기술의 성숙도라고 응답했습니다. 과거 2년동안 릴리즈된 컨테이너와 연관된 모든 툴과 프로젝트들을 계속해서 파악하는 것은 어렵습니다. 그리고 그 것들 중 몇몇은 이름이 바뀐 것도 있고 아직 베타 버전인 경우도 있습니다. 이렇게 개발의 빠른 속도는 아직 안정성이나 성숙도를 보여줄 정도는 아닙니다.

그러나 컨테이너로 패키징 되고 동적으로 관리되는 마이크로 서비스 기반의 어플리케이션 개발을 발전시키기 위한 기존 기술들과 조화를 이루는데 초점을 맞췄던 설문은 6월, OCI가 포메이션에 대한 발표를 하기 전과 7월, Cloud Native Computing Foundation(CNCF)가 설립 되기 전에 종료되었습니다. 이런 주도적인 행동들로 짧은 기간에 컨테이너 기술이 어떤 영향을 줄 수 있는지 말하는 것은 쉽지 않습니다. 기존 기술들과 융화 되려면 아직은 시간이 필요합니다.

그러나 이 공간에 기존 툴을 가지고 있는 선두 업체들이 돌아오게 되면 이러한 주도적인 행동들은 안정성을 보장할 수 있게 됩니다. 그리고 그들은 컨테이너로 기동하는 일련의 안정적 통합 솔루션을 찾기 위한 진입 점을 제공할 것입니다.

대규모 배포 시에 중요한 요소인 오케스트레이션
응답자중 절반은 컨테이너를 채택하려고 할 때 오케스트레이션은 하나의 요소라고 응답했습니다. 이미 Docker를 사용하고 있던 응답자들은 이런 응답을 했습니다.

오케스트레이션은 멀티 컨테이너, 멀티 호스트 어플리케이션에 있는 컨테이너를 조직화하고 연결하는 기능을 가지고 있습니다. 그리고 특히 마이크로 서비스 아키텍쳐로 되어 있는 어플리케이션들을 위해 중요한 역할을 합니다. 예를 들어 웹 어플리케이션은 각각의 컨테이너에서 동작하는 수많은 백앤드 서비스들과 마찬가지로(페일오버나 로드발란싱을 위한) 프론트 앤드의 여러 개 인스턴스를 관리하기 위한 웹 서버들을 구동하는 컨테이너의 집합으로 구성되어있습니다.

분명하게 Google 의 Kubernates와 Mesosphere"s Marathone을 지원하는 오케스트레이션 툴들은 Apache Mesos로 만들어졌습니다. Docker 자체적인 오케스트레이션 툴인 Swarm, Compose, Machine은 2월에 릴리즈 되었고 Compose는 기존의 Fig 툴이 변경된 것입니다. 어떤 컨테이너 관련 기술들을 사용하고 있는지 응답자들에게 물었을 때 38%는 Docker Swarm을, 22%는 Kubernates를 , 22%는 Mesos를 사용하고 있거나 사용할 예정이라고 응답했습니다. 그리고 Kubernetes를 사용한다고 응답한 사람들은 대개 큰 기업에서 일을 하고 있었습니다. Docker Swarm과 Machine은 여전히 베타 버전이지만 Kubernetes는 CNCF를 출시했던 7월21일에 버전 1.0을 릴리즈 했습니다. 따라서 이러한 툴들이 발전할 수 있는 기회를 준 후에 적용 비율을 비교해보는 것은 매우 흥미로운 일이 될 것 입니다.

확장성 모니터링에 대한 제한 요인
컨테이너가 제품의 넒은 영역에 사용되면서 모니터링 툴에 대한 요구가 또한 증가하게 되었습니다. 응답자중 46%는 모니터링이 컨테이너화한 어플리케이션으로 변경하는데 중요한 요소라고 응답했습니다. 오직 1개의 호스트에서만 동작하고 디스크에 있는 로그파일(예:/var/log 아래)을 분석하는데 의존했던 기존 Linux기반의 모니터링과 리포팅 툴들은 멀티 컨테이너 클러스터 어플리케이션으로 변경하기에 적합하지 않았고 싱글 컨테이너 어플리케이션을 모니터링 하는 것 조차도 적합하지 않았습니다. 왜냐하면 저장되지 않은 데이터들은 컨테이너가 동작하지 않을 때에 디스크의 내용이 유지 되지 않기 때문입니다. 컨테이너 인식 모니터링 툴 또는 서비스를 사용하여 어플리케이션을 모니터링 하고 로그를 확인하는 것에 대한 집중화된 접근은 동적으로 다수의 컨테이너 어플리케이션을 관리하는 데에 더 적합합니다.

컨테이너의 상태를 모니터링 하기 위한 셀프 호스트 솔루션으로는 오픈 소스 툴인 cAdvisor와 Sensu, Prometheus가 있습니다.

Docker는 1.5버전부터 동작중인 컨테이너들의 스트리밍 자원의 사용 상태를 확인 하기 위한 Stats API를 지원해왔습니다. 그리고 수많은 벤더들은 New Relic, Scout, DataDog, SignalFX, AppDynamics 를 포함한 Docker Stats API로 만들어진 호스트 모니터링 툴을 제공합니다. 이 툴들은 컨테이너 상태를 모니터링 하지만 Stats API를 통해 제공된 데이터에 의존적입니다. 그리고 그런 이유로 컨테이너 안에서 동작하고 있는 서비스들이나 어플리케이션에 대한 좀더 상세한 정보는 제공하지 않습니다. Ruxits의 Docker Monitoring은 새로 생성된 컨테이너에 대한 오토 디스커버리를 제공합니다. 그리고 컨테이너 내부에서 동작하고 있는 어플리케이션과 서비스들에 대한 디스커버리와 Docker컨테이너 안에서 실행되는 마이크로서비스들과 동적 분산 어플리케이션에 대한 어플리케이션 중심 모니터링을 제공합니다.

자동화
40%의 응답자들은 자동화는 또 다른 요소라고 말합니다. 특히 자동화는 변경이 많은 마이크로 서비스 기반의 분산 어플리케이션 구현하는 데에 유용합니다. 예를 들어 하나의 서비스를 새로운 컨테이너로 변경 하는 것이 장소를 업그레이드 하는 것보다 낫습니다. 기존에 Jenkins와 같은 배포 툴(배포를 위해 Ansibl과 같은 CM 툴과 결합한)과 CircleCI같은 컨테이너 사용가능한 서비스들은 DockerHub로부터 직접적으로 Docker이미지들을 내려받고 CI/CD프로세스의 부분처럼 직접 빌드를 하고 배포를 할 수 있습니다. 동적으로 서로 관련이 있는 서비스들을 미리 연결하는 것보다 다른 서비스들을 동적으로 디스커버리 하는 것을 가능하게 하기 위한 Etcd와 Consul을 포함한 서비스 디스커버리 툴들은 이 이야기에 중요한 부분입니다.

요약
설문 응답자들에 의하면 컨테이너 기술 채택에 대한 높은 비율은 Docker와 컨테이너에 관련된 현재 업계에 대한 추세를 반영합니다. 응답자중 반 이상이 앞으로 6-12개월 안에 제품에 컨테이너를 사용할 예정이라고 말했습니다. 그리고 설문에 의해 확인된 분산 컨테이너 어플리케이션을 위한 자동화, 모니터링, 오케스트레이션과 같은 핵심적인 요소와 관련된 영역을 다루는 통합솔루션과 안정성, 제품준비에 대한 명백한 수요도 있습니다.
어떻게, 왜 사람들이 Docker를 사용하는지 배우기를 원하시나요? 설문의 나머지 부분을 읽어보십시요.

간신히 마친 번역

원문 : 3 easy reasons why you’ll move your business to the cloud

http://www.hanbit.co.kr/network/category/category_view.html?cms_code=CMS7356601744

클라우드 네이티브 애플리케이션 아키택쳐로의 변화는 혁신으로 이어집니다.

클라우드 네이티브 애플리케이션 아키택쳐를 적용할 때 어떻게 클라우드가 혁신과 변화를 가능하게 하는지 회사가 고려해야 할 부분과 클라우드 네이티브 애플리케이션 아키택쳐로의 변화가 가지고 있는 기본적인 동기들을 살펴봅시다.

속도(Speed)

속도가 시장에서 중요한 성공 요인이라는 것은 분명합니다. 소프트웨어 기반의 솔루션들을 개발하고 제공하는 사업들은 경쟁자들보다 빠르게 기존의 딜리버리 모델들을 습득해야 합니다.

엔터프라이즈 환경에서 새로운 애플리케이션 환경을 제공하고 새로운 버전의 소프트웨어를 반영하는데 걸리는 시간은 기본적으로 일, 주, 또는 월 단위로 측정됩니다. 신속성의 부족은 특정 릴리즈에 의해 발생할 수 있는 위험을 엄격하게 제한합니다. 왜냐하면 오류를 만들어내고 수정하는 비용 또한 동일한 시간 단위로 측정되기 때문입니다.

인터넷 기업들은 종종 하루에 수 백 번씩 배포를 하는 작업에 대해 표창을 하기도 합니다. 왜 빈번한 배포가 중요한 걸까요? 만약 당신이 하루에도 수 백 번 배포가 가능하다면 거의 즉시 오류들을 처리할 수 있을 것입니다. 그리고 당신이 즉시 오류를 처리할 수 있다면 더 많은 위험을 떠맡게 될 것입니다. 그리고 더 많은 위험을 떠맡게 된다면 결과적으로 당신은 다른 경쟁자들 보다 우위에 설수 있게 됩니다.

탄력성과 셀프서비스를 갖춘 클라우드 기반의 인프라는 자연스럽게 이런 작업에 적합합니다. 클라우드 서비스 API를 호출해서 새로운 애플리케이션 환경을 제공하는 것이 수많은 절차를 거쳐서 진행되는 양식 기반의 방식보다 빠릅니다. 다른 API를 호출해서 새로운 환경에 코드를 반영할 때에는 속도가 더 빠릅니다. 팀에 있는 통합 빌드 서버 환경에 셀프서비스와 후크를 추가하게 되면 속도는 더 향상될 것입니다. 결과적으로 우리는 Lean 그루인 Mary Poppendick이 말한 “당신의 조직은 단 한 줄의 변경된 코드를 반영하는데 얼마나 시간이 걸립니까?” 라는 질문의 답을 몇 분 또는 몇 초 안에 측정할 수 있습니다.

당신이 그렇게 빠르게 처리 할 수 있다면 당신의 팀이, 당신의 비즈니스가 무엇을 할 수 있을지 상상해 보십시오.

보안(Safety)

단지 빠른 것만으로는 충분하지 않습니다. 만약 당신이 차를 타고 건물을 향해 패달을 밟는다면 치명적인 사고를 당하게 될 것입니다. 항공기나 특급 고속열차 같은 운송수단은 빠르고 안전하게 만들어졌습니다. 클라우드 네이티브 애플리케이션 아키택쳐는 내구성, 유효성, 안전성에 대한 요구에 빠르게 대응할 수 있도록 균형을 유지해 줍니다. 따라서 속도와 보안은 갖추는 것은 기본이고 필수입니다.

우리가 앞에서 언급했듯이 클라우드 네이티브 애플리케이션 아키택쳐는 오류를 빠르게 복구하는 것을 가능하게 해줍니다.

우리는 지금 엔터프라이즈 환경에서 프로세스 엔지니어링에 많은 시간을 투자해서 오류를 예방해야 한다는 이야기를 하고 있는 것이 아닙니다. 화려한 디자인, 철저한 문서, 아키텍처 리뷰보드, 긴 회귀 테스트 사이클은 우리가 추구하는 속도에 역행을 하고 있습니다. 물론 이런 관행들은 좋은 의도에서 만들어졌던 것들입니다. 하지만 안타깝게도 그 중 어느 하나도 수많은 결함을 제품으로 만드는 데에 꾸준하게 주목할만한 향상을 보여주지 못했습니다.

그렇다면 우리는 어떻게 빠르고 안전하게 할 수 있을까요?

가시성(Visibility)

우리의 아키텍처는 장애가 발생했을 때 확인하기 위해 필요한 툴을 제공해야만 합니다. 우리는 모든 것을 측정할 수 있어야 하고 “정상적인 것이 무엇인지”에 대해 설명을 할 수 있어야 합니다. (절대값과 변화율을 포함한) 일반적인 상태와의 편차를 찾아내고 원인에 대해 알아낼 수 있어야 합니다. 다양한 통계, 모니터링, 경고, 데이터 시각화 프레임워크와 툴들은 모든 클라우드 네이티브 애플리케이션 아키택쳐의 핵심입니다.

장애 고립(Fault isolation)

장애와 연관된 위험을 줄이기 위해 위해 장애로 인해서 영향을 받을 수 있는 컴포넌트, 또는 기능들의 범위를 제한하는 것이 필요합니다. 만약 실시간 추천 엔진에 문제가 발생해서 Amazon.com에서 물건을 구매할 수 없다면 큰 재앙일 것입니다. 모놀리틱 애플리케이션 아키텍처는 이런 장애 모드에 대한 유형을 가지고 있습니다. 클라우드 네이티브 애플리케이션 아키택쳐는 종종 마이크로 서비스를 사용합니다. 마이크로 서비스로 구성된 시스템들 중에서도 오직 장애 허용 능력을 가지고 있는 마이크로 서비스만이 장애에 대한 범위를 제한할 수 있습니다.

장애 허용능력(Fault tolerance)

시스템을 독립적으로 반영할 수 있는 컴포넌트로 분해하는 것은 적합하지 않습니다. 그리고 우리는 컴포넌트들 중 한곳에서 발생한 장애가 의존관계를 통해 장애를 야기시키는 것을 막아야만 합니다. Mike Nygard는 그의 저서인 “Release It”(Progmatic Programmers) 에서 몇 가지의 장애 허용 패턴들에 대해서 언급하면서 가장 많이 사용되는 것은 서킷 브레이커라고 했습니다. 소프트웨어에서 서킷 브레이커는 전자기기에서 사용되는 서킷브레이커와 매우 유사하게 동작을 합니다. 서킷브레이커가 보호하고 있는 컴포넌트와 그 이외에 오류가 발생한 시스템 사이에 서킷을 오픈 함으로써 오류가 전이되는 것을 방지합니다. 또 서킷이 오픈되어 있는 동안 제품에서 기본적으로 제공되는 기본 셋 같은 폴백도 제공합니다.

자동 복구(Automated recovery)

가시성, 장애고립, 장애 허용능력과 같이 우리는 식별 및 복구 과정에 참여하는 동안 오류를 식별, 복구하고 우리의 고객들에게 적절한 레벨의 서비스를 제공하는데 필요한 툴을 가지고 있습니다. 발생할 때마다 쉽게 발견할 수 있는 패턴을 보여주는 오류들은 식별하기 쉽습니다. 예를 들어 헬스 체크 서비스는 건강한지 아닌지, 상태가 좋은지 나쁜지에 대해 2진법으로 응답을 합니다.

이런 종류의 오류가 매번 발생할 때마다 우리는 같은 행동을 반복할 것입니다. 헬스 체크에 오류가 생겼을 경우, 우리는 단순히 서비스를 다시 시작하거나 다시 배포할 것입니다. 클라우드 네이티브 애플리케이션 아키택쳐는 이런 상황에서 수동으로 개입하는 것을 기다리지 않습니다. 대신 감지 및 복구를 자동화해서 사용합니다. 다시 말해 사람대신 컴퓨터가 호출기를 착용한 것과 마찬가지입니다.

크기(Scale)

요구사항이 많아짐에 따라 요구사항에 대한 서비스를 제공하기 위한 우리의 능력도 조정을 해야만 합니다. 과거에 우리는 더 큰 용량의 서버를 구매하는 방법으로 수직적으로 크기를 확장해서 요구사항을 만족시켰습니다. 결국 목표는 이루긴 했지만 점점 많은 비용을 지불해야만 했습니다. 이것은 용량에 대한 사용이 최대 사용 시점을 기준으로 계획이 되었기 때문에 발생한 문제입니다. 우리는 “이 서비스가 필요한 가장 적절한 용량은 어느 정도인가?” 라는 의문을 갖고 그에 맞는 충분한 하드웨어를 구매합니다. 하지만 대부분의 경우 우리는 이 예측이 잘못되었다는 것을 깨닫게 되고 블랙프라이데이 같은 이벤트 기간 동안에 여전히 허용량을 초과하게 됩니다. 또한 더 빈번하게 유휴상태의 CPU를 가지고 수십, 수백대의 서버를 보게 되고 비효율적인 결과를 초래하게 될 것입니다.

혁신을 선도하는 기업들은 두 가지 방법으로 이 문제를 해결하고 있습니다.

• 대용량 서버를 구매하여 숫자를 늘리는 것보다 다수의 장비를 이용해서 수평적으로 애플리케이션 인스턴스의 크기를 조정한다. 이 장비들은 취득(또는 조립), 그리고 빠르게 배포하는 것이 보다 쉽다.
  
  
• 대용량 서버들이 가지고 있는 비효율성은 같은 공간에 여러 개의 작은 서버들을 가상화하고 여러 개의 고립된 워크로드를 배포하여 개선한다.

Amazon Web Service 같은 일반적인 클라우드 환경이 가능해지면서 이런 두 가지 움직임은 수렴되었습니다. 가상화에 대한 노력은 클라우드 제공자에게로 위임되었고, 소비자들은 수많은 클라우드 서버 인스턴스에 걸쳐있는 그들의 애플리케이션들을 수평적으로 확장하는데 초점을 맞추고 있습니다. 최근 또 다른 변화는 응용 프로그램 배포 단위가 가상서버에서 컨테이너 단위로 변하고 있습니다.

더 많은 혁신을 위해 클라우드 환경이 보여준 변화는 더 이상 기업들은 그들의 소프트웨어를 배포하기 위해 수많은 초기자본이 필요하지 않게 되었습니다. 또한 더 적은 투자로도 지속적으로 유지를 할 수 있게 되었고, API를 통한 공급은 최초 배포 속도를 향상시켜줄 뿐만 아니라 수요의 변화에 대한 대답을 최대한 빨리 할 수 있게 되었습니다.

안타깝게도 이런 모든 혜택들은 비용이 필요합니다. 애플리케이션들은 수직적 크기 보다는 수평적으로 다르게 설계되어야만 합니다. 클라우드의 탄력성은 짧은 수명을 요구합니다. 뿐만 아니라 새로운 애플리케이션 인스턴스를 빠르게 생성할 수 있어야 하며 빠르고 안전하게 그것들을 폐기할 수 있어야 합니다.

이런 필요는 어떻게 지속적으로 처분할 수 있게 상호작용을 해야 하는지라는 상태관리에 의문을 가지게 됩니다. 매우 수직적인 아키텍쳐에 해당하는 세션을 클러스터링 하거나 파일 시스템을 공유하는 고전적인 방법은 스케일링을 제대로 수행할 수 없습니다.

클라우드 네이티브 애플리케이션 아키택쳐의 또 다른 특징은 애플리케이션 인스턴스를 기본적으로 상태없이 유지하는 동안 인-메모리데이터 그리드, 캐쉬, 영구적인 객체 저장에 대한 외부화 입니다. 상태 없는 애플리케이션은 빨리 생성할 수 있고 없앨 수 있습니다. 마찬가지로 요구사항 변화에 대한 응답에 대한 능력을 향상시킬 수 있도록 외부의 상태 매니저에 붙이거나 떼어낼 수 있습니다. 

물론 이건 스스로 확장할 수 있는 외부 상태 관리자가 필요합니다. 대부분의 클라우드 인프라를 제공자들은 이 부분의 필요성을 알고 있으며 이런 서비스들을 제공하고 있습니다.