System Compleat.

외국인 노동자

Cerberos — Sun, 29 Mar 2020 08:03:11 +0900

(younjin.jeong@gmail.com, 정윤진)

일요일 아침이다. 우연한 계기로 해외의 은행에서 일을 시작한지 어느덧 5개월째에 접어든다. 지난 5개월은 무수히 많은 일들의 연속이었다. 너무나도 새로운 일의 환경, 회사는 싱가포르 로컬이지만 영국, 호주, 인도, 포르투갈, 중국, 베트남 그리고 싱가포르 사람들까지 정말 다양한 국가의 사람들과 함께 일하고 있다.

새 직장

어떤 사람은 은행에서만 20년 넘게 일하고 있고, 또 다른 사람은 얼마전에 스타트업에서 성공을 이끌던 사람도 있으며 실리콘밸리에서 일하다가 넘어온 사람도 있다. 같이 일하는 모두가 하나하나 살펴보면 정말 명석한 사람들이다. 간혹 이렇게 명석한 사람들 사이에서 내가 일해도 되나 하는 생각이 들기도 한다.

최근 10여년간 다녔던 회사들에서는 어떤 일을 진행하기 위해 누구에게 반드시 승인이 필요한 적은 없었다. 아마도 어떤 새로운 일을 시작하게 될때는 그것이 새로운 일이기 때문에 종전의 일들과 크게 관계가 없기 때문이기도 했으며, 보통 필요한 권한을 위임 받는데 큰 문제가 없었기 때문이기도 했으리라.

하지만 그야말로 엔터프라이즈에서 일을 하기 시작하니 모든것이 다른 사람들과 연결되어 있다. 단순한 내부 임직원 대상 설문을 돌리는데도 설문을 위한 질문을 시스템에 등록하는 사람 따로, 그 설문 결과를 볼 수 있는 사람 따로, 그 설문에 쓰여진 질문이 맞는지를 검토해야 하는 사람들 따로, 뭐 그런 식이다. 가설을 세우고 실험을 해서 결과를 얻는다는 것이 이전 회사들에선 그토록 간단했는데 큰 회사에서는 그것마저 쉽지 않다.

아마 설문 시스템을 담당하는 일로 그 사람을 채용했을리는 없을 것이다. 이것이 사실 더 심한 문제라고 볼 수 있는데, 각 개인은 항상 다른 어떤일로 바쁘다. 무언가 다른 일로 바빠하는 사람에게 설문의 결과가 어떻게 진행중이냐고 묻고 다시 응답을 받는 것 자체가 서로에게 딜레이가 되는 상태가 된다. 동시에 왜 그런지도 이해한다.

우리는 서비스와 애플리케이션 구조에 있어 간결함을 유지하고 핵심 기능에 집중 해야한다는 말에 익숙하다. 지난 십년간 클라우드를 기반으로 발전해온 여러 테크 회사들의 성공사례 뒤에는 어김없이 이 내용이 뒤에 숨어 있다. 보통은 공개되지 않는 그런 내용을 넷플릭스가 블로그와 코드를 공개함으로서 마이크로서비스라는 이름으로 널리 알려지고 있다.

하지만 우리는 문화를 이야기하는 것에 익숙하지 않다. 그리고 그 문화 없이는 저런 테크 컴패니들이 이루어낸 성과를 내는 것이 힘들것이라는 점을 배우는 중인것도 같다. 스스로 할 수 있어야 하는 일에 누군가의 승인이 필요하다는 것 자체가 시스템과 서비스간 의존성과 다르지 않다. 한줄의 코드를 바꾸기 위해 누군가에게 설명을 들어야한다는 상황 자체가 눈에 보이지 않는 의존성과 다름없다.

의존성은 신기한 녀석이다. 애초에 무언가 분리되지 않는다면 다른 것에 의존할 필요가 없다. 그는 그의 일을 하고 나는 나의 일을 하기에 필요한 경우 그에게 무언가를 요청해야 하는 원시적인 의존성이 발생한다. 하지만 시간이 흐를 수록 이런 의존성이 많아지고 복잡해짐에 따라 하나의 변화가 힘들어지고 그 변화에 따른 위험도가 높아지기에 의존성은 점점 골치아픈것이 되어간다.

셀프-서비스라는 말을 많이 사용한다. 어떤 일을 처리하기 위해서 필요한 것은 스스로 공급 받아서 스스로 준비하여 결과를 딜리버리하는 것을 의미한다. 셀프 서비스가 가능하기 위해서는 기능만을 딜리버리 하기위해 집중하던 것과는 다른 훈련을 필요로 한다. 내가 만든 무언가가 다른 사람에 의해 ‘셀프 서비스’의 방법으로 처리될 수 있어야 한다는 것이다.

컨벤셔널 커밋 메세지, 브랜칭 전략, 테스트, 코드 스타일, 재 사용 가능한 코드, 설정의 분리, 코드 저장소의 읽기 권한 공개등 많은 컨셉들이 코드를 잘 쓰는 것 외에도 필요한 팀 내의, 아니 팀 외부로도의 공통 분모일 것이다.

자연스럽게 발전한 오픈소스 생태계는 보통 이런 방식에 매우 익숙하다. 이미 구조적으로 잘 짜여진 협업의 방법과 의존성 발생으로 인한 위험을 낮추는 다양한 해법들이 존재한다. 그리고 이것은 시간이 지남에 따라 더욱 발전하고 있다고 생각한다.

인터넷이 온전히 개발자에게 열려있어 어떠한 도구든 사용할 수 있는 상태와 그렇지 않고 인터넷에서 필수적인 것들만 내부에 별도로 준비해서 운영하고 있는 시스템 안에 있는 개발자들은 분명히 다른 상황에 처했다고 볼 수 있다. 이런 갭이 있는 상태에서 필요한 것은 무엇인가.

예를 들어 많은 엔터프라이즈들이 내부에 별도의 넥서스를 운용한다. 이 운용의 방법은 보통 매우 매뉴얼이다. 새로운 버전의 무엇이 필요하면 어떤 승인지가 있고 이를 통과하는 프로세스가 존재하며 이 모든 것들이 지나야 무언가가 넥서스에 준비된다. 그것이 라이브러리든 패키지든 도커 이미지던간에 다르지 않다.

사용하는 개발자의 입장에서는 일단 손봐야 할 것이 많다. 문제는 이 손봐야 할 것들이 인터넷이 열려져있는 환경에 있던 개발자라면 매우 생소하고 처음보는 것들이라는 점이다. “원래 메이븐은 그냥 돌아가는거 아니야?” 아니다. VSCODE의 플러그인을 설치할 수 없는 상태라면? 인텔리제이 아이디어에 프락시 설정을 넣어야 한다면?

다른 사람들은 그냥 사용하는 것을 어딘가에서는 그냥 사용하지 못한다. 이것은 의존성과는 또 다른 큰 문제의 축이다. 익숙한 도구를 즉시 사용하지 못한다는 것은 꽤나 불편한일이 아닐 수 없다.

당장 프락시와 넥서스의 엔드포인트에 대한 정보를 누군가 알려주지 않으면, 어딘가 정리되어 있지 않다면, 아니 항상 업데이트되고 있는 스크립트가 제공된다면 좀 더 편리할지도 모르겠다.

다만 더 쉬운 방법으로 모든 개발자가 그런 설정을 할 필요가 없게 리버스 프락시 하나 제대로 준비해 주면 어떨까.

요새는 이런 일들에 집중하고 있다. 수천명의 개발자들에게 보다 편리한 환경을 제공해 주는 일. 매일 매일이 전쟁같고, 작은 하나를 바꾸는데도 많은 사람들의 도움이 필요하다. 그리고 그 사람들에게 나를 누군가 먼저 소개해 주기 이전에는 내가 그 사람에게 메일을 보낼 명분조차 없다.

하지만 조금씩 바뀌고 있다. 시간을 투자하고, 신뢰를 얻으면 그것이 미래의 자산이 될 것임을 믿어 의심치 않는다. 올바른 일을 하고 있다고 믿고 베짱있게 추진하다 보면 죽던지 살던지 둘중의 하나는 답이 나오겠지.

싱가포르 생활은 한국 생활과 크게 다르지는 않다. 워낙 라이프스타일이 집회사 집회사지만, 한가지 크게 변한게 있다면 여기서는 집에서 얌전히 마신다는 것.

COVID-19이 아니었다면 벌써 한국에 몇번 날아가서 누군가에게 징징댔겠지만, 그런 재미도 없어져버려 강제 적응 중.

모두가 이 험난한 시국을 잘 버티어내고 결국에는 행복이 다다르길 바란다.

의존성, 개발환경, 클라우드 아마도 난 올해 좋은 목표를 세우고 있는것 같다.

(younjin.jeong@gmail.com, 정윤진)

과거, 현재 그리고 미래

Cerberos — Mon, 4 Nov 2019 05:27:09 +0900

(younjin.jeong@gmail.com, 정윤진)

바람이 거센 가을이다. 엘레베이터에서 내려 공동 현관문을 나서면 기다렸다는듯 차디찬 바람이 얼굴을 때린다. 그런 바람을 맞으며 계단을 걸어 내려가 아파트 단지 사이의 길을 따라 편의점으로 향하다 보면 싸늘한 추위가 자켓안으로 스며든다.

편의점에서 한동안 끊었던 담배를 한갑 산다. 2019년 11월 난 무엇을 하고 있는가. 커리어에 대한 고민으로 년초부터 이곳 저곳면접을 보았더랬다. 어떤 회사는 스타트업 어떤 회사는 대기업, 어떤 회사는 전에 다니던 외국계 회사들 이었다. 사실 즐겁지만은않았다. 지금 다니고 있는 회사가 나의 장래와 더 이상 합치 되지 않는다는 사실은 괴로운 자각 같은 것이었달까.

훌륭한 회사지만 내가 무엇을 더 할 수 있는가를 생각해 보면 눈 앞이 어두웠다. 좋은 동료들이 많아 어떤 일을 성공으로 이끌어 내기에 충분하기도 했지만, 동시에 그런 동료들이 생기기 전에 했던 일들의 많은 부분을 덜어내기도 해야 했다.

단순한 이분법으로 나누어 보자면, 회사에서 일하는 개인들은 무엇을 팔거나 또는 무엇을 만드는 일로 나뉜다. 2013년 이전의 나는 무엇을 만드는 사람이었으며, 2013년 이후로 나는 만든 경험을 바탕으로 파는 일을 해 왔다고 볼 수 있다.

파는 사람은 언제나 어떤 상품이나 서비스에 대해 좋은 부분만을 이야기하게 된다. 대부분의 판매직에 있는 사람들은 그 상품이나 서비스가 가진 취약점이나 문제에 대해 먼저 언급하지 않는다. 당연히 누구도 판매에 문제가 발생할 만한 행동은 하지 않게 마련이다.

하지만 그런 서비스나 상품을 구매한 측에서는 언제나 문제에 마주한다. 그것이 그 제품에 대한 몰이해에서 비롯된 것이건, 제품자체의 문제에서 발생한 것이건 간에 문제와 마주한다. 이런 문제와 마주한 고객을 대하는 것에는 여러가지 기술이 필요하다.

마찬가지로 그런 문제가 발생한 경우, 내가 고객의 입장에서 그 문제를 해결할 방법을 궁리해야 하는 것도 필수적인 부분이다. 어떤 기술이 원하는 기능은 구현했지만, 원치 않았던 부차적 문제를 함께 가져오는 것은 매우 일반적인 일이기 때문이다.

개인적인 커리어에 대한 고민은 여기서 시작이었다. 예전에 무언가를 만들고 매일매일 발생하는 문제를 해결하는 위치에 있었을때에는 더 많이 배울 수 있었는데, 무언가를 파는 입장에서는 매일매일 새로운 기술을 배워 시장에 알리는 일만 하지 않는가 하는그런것이었다.

새로운 무언가를 배우는 것은 사실 나쁜것은 아니다. 누구보다 빠르게 해당 기술을 배우고, 익혀서 소개하는 것은 적절한 시점에잘 이루어진다면 매우 뿌듯한 일이다. 하지만 간과해서는 안되는 것이, 왜 그 기술이 새로 발생했으며 어떤 사업적 이유에서 필요했기 때문에 등장했는가에 대해서는 수동적일수 밖에 없다는 점이다.

거꾸로 어떤 서비스를 직접 개발하고 운영하는 경우에는 기술에 대한 필요가 간절하다. 매일 해결해야 하는 문제에, 아! 이런 기능이 있었다면! 하고 생각하는 경우가 많기 때문이기도 하고, 어떤 기술에 대한 깊이 자체가 다를수 밖에 없다. 어떤 이유에서 어떤 기술이 필요했는데 이제 생겼네! 하는 필요와 충분의 조건에 다름아니다.

그러한 이유들로 인해 직접 개발하고 운영하는 서비스에 대한 욕심이 점점 더 커졌다. 내가 직접 만들고 고쳐야지, 내가 직접 문제들을 해결해야지 하는 욕심들 말이다. 하지만 이미 판매를 주로하는 직업을 가진 상태에서 나를 받아주는 회사들은 별로 없었다. 실무는 손 떼신지 오래 되었네요, 매니저 경력은 도드라지지 않네요, 이 일 할수 있으시겠어요?

나는 내가 언제나 쓸모가 있는 기술자이기를 바랬다. 어디서나 필요한 사람이고 싶었다. 그런 바램이 항상 무언가를 배워야한다는 강박으로 이어지고는 했다. 사실 더 젊을때는 새로운 무엇을 배우는 것이 강박이 아니라 즐거움이었다. 하나를 알고, 그 하나를 알기 위해 수많은 것들을 배우고 그래서 다른 하나를 새로 아는 과정은 괴로움이기보다는 즐거움이었다.

하지만 어느 순간 나는 많은 조직으로부터 필요한 사람이 되고 있지 않았다. 그 사실이 너무나 괴롭고 즐겁지 않았으며, 해법을찾지 못하는 상태에 이르렀다. 나는 어떻게 되고, 나의 미래는 어찌될 것인가 하는 고민들이 겹치고 현재의 상태에 만족하지 못하며 더 이상 발전할 수는 없는 것인가 하는 고민들이 매일의 나를 괴롭게 만들었다.

결론부터 말하자면 오늘의 나는, 2019년 11월의 나는 다른 나라에서 완전히 새로운 직업을 가지게 되었다. Senior Vice President of Technology & Operations in Development Bank of Singapore, Group Consumer Banking and Big Data Analytics Technology 라는 길고도 긴 타이틀과 직급이다.

장장 5개월의 면접, 오퍼, 그리고 비자까지 매우 긴 기다림의 시간이었지만 동시에 설렘과 흥분으로 가득차 있기도 하다. 나 개인으로서는 거의 10년만의 서비스 운영, 그리고 수많은 개발팀에 필요한 도구의 제작, 그리고 동시에 내가 가장 잘 하는 분야로의다른 나라에서 완전 새로운 도메인에 대한 도전이기 때문이다.

사람들은 좋은 직장을 원한다. 물론 나도 그러했다. 월급 80만원 받으며 공공기관의 석고보드 천장을 뜯고 카테고리 5의 랜케이블을 던지며 몰딩하던 시절에도 커널을 버리지 않았다. 나는 내가 80만원짜리 인생이기를 원한적이 없다.

생각해 보면 재미있는 것은 한달에 80만원을 벌고, 120만원을 벌고, 200만원을 벌고, 다시 300만원을 벌고 하던 성장의 단계다. 나는 매 성장의 단계가 나에게는 하나하나 소중했으며 격렬한 투쟁의 결과라고 생각했지만 사회에서는 그렇지 않았다는 것이다. 소중했던 성장의 과정이 언제나 행복했던것 만은 아니었던것 같다. 물론 그도 그럴것이 위에는 언제나 그 위가 있으며, 나는 그생태계에서 계급의 착각만을 반복했던것 같다.

어쨌든 이제 또 새로운 길에 들어섰다. 새로운 시대에, 새로운 나라에서 새로운 사람들과 새로운 경험을 하게 된다. 처음 서비스를 맡아 개발할 때에도 그랬고, 생전 처음 보는 문제들을 반드시 해결해야만 하는 상황들도 있었고, 수백의 사람들 앞에서 처음발표를 해야 했을때도 그랬으며, 그 발표를 다시 영어로 해야 할때도 그랬다. 저지르고 보는 나의 성격은 그 결과의 성패와 관계없이 저돌적이었고 무지렁이 같았으며, 그래서 겁나기도 하고 가슴이 두근거리기도 했다.

이 모든 과정을 함께할 수 있는 반려자가 있었으면 했다. 하지만 거꾸로 그런 반려자가 있었다면 이토록 무모할 수 있었을까. 이지독한 혼자의 길을 항상 치유받기를 원했다. 하지만 그런일은 발생하지 않았고, 그 지독함은 결국 새로운 도전으로만 연결되는것이 아닌가 싶다.

나는 앞으로도 항상 필요한 사람이 되고 싶다. 어디서나, 내가 위치한 자리 그리고 내가 잘 했던것을 누군가에게 필요당하고 싶다. 그것이 기술이건, 아니면 다른것이건 말이다. 그러나 그렇게 되지 않는 때가 온다면 보통의 슬픔으로는 표현할 수 없는 좌절과 마주하게 될 지도 모르겠다.

나는 내가 슬픈 사람임을 깨달았다. 내 외로움은 앞으로도 해결되지 않을 것이며, 인생의 동반자는 없을 것이다. 따라서 나는 좋아하는 것에 더욱 집중하고 더욱 강렬한 도전을 멈추지 않을 것이다. 인생의 원동력이 슬픔이라는 것은 다소 안타까울지 모르나, 도전과 실패의 총합은 나를 필요한 사람으로 만들어 줄 것이라고 믿는다.

진정으로 나를 사랑해 주었던 사람에게 고마워보는 밤이다. 그리고 지난 모든 사람들에게도.

나의 미래는 고독과 외로움 위에 명예롭기를 바란다.

그냥 그렇다고.

새 직장 주소.

https://www.dbs.com/

(정윤진, younjin.jeong@gmail.com)

마이크로 컴퓨터와 RC (Remote Control) - 1편

Cerberos — Thu, 25 Apr 2019 03:36:07 +0900

(정윤진, younjin.jeong@gmail.com)

약 10여년 전, 인터넷 검색을 하다가 우연히 어린 시절에 원격 조종 자동차나 비행기를 엄청 하고 싶었던 기억이 떠올랐다. 어린시절 용돈으로 감당하기엔 그 벽이 너무 높았던 장난감, 이제 성인이 되어 직장도 다니고 하니 하나 사서 가지고 놀아 보는 것도 괜찮겠다 싶었다.

당시에 이미 다양한 중국산 제품들이 생각보다 저렴한 가격으로 홍콩의 하비킹이란 사이트를 통해 판매되고 있었다. 개인적으로 기술도 그렇고 놀이도 그렇고 뭔가 빨리 발견한다는 느낌인데, 그때 그런 느낌이었다. 발사라는 매우 가벼운 나무로 만들어진, 그리고 조종을 실패하면 상당한 파손 비용을 감당해야 했던 것들과는 다르게, 강화 스티로폼으로 만들어진 비행기들이 주력을 이루었다. 입문용 비행기는 16만원 선으로, 추락해도 본드칠로 고치면 되겠다는 생각에 누구 가르쳐 주는 사람을 알아볼 생각도 없이 무조건 질렀다.

최초로 구매한 무선 조종 비행기. 여러번의 추락으로 이미 많이 아프다...

검색에 검색이 꼬리를 물다 보니, FPV라는게 눈에 띄었다. First Person View라 불리는 것으로 이제는 많은 사람들이 알고 있듯이, 무선 조종 비행기나 자동차 앞에 카메라를 달아서 실시간으로 영상을 보면서 즐기는 장치들이었다. 이거 대박인데? 하는 생각과 관련 시스템들을 알아보기 시작했다. 다양한 주파수로 동작하는 영상 신호 전송 및 수신 모듈, 수신 받은 영상을 실감나게 볼 수 있는 고글, 그리고 고글에 자이로를 달아 여기서 나오는 신호로 비행기에 붙은 카메라를 조절해 고개를 돌리면 카메라도 돌아가는, 마치 실제 비행을 하는 느낌을 주는 시스템, 그리고 OSD라 불리며 배터리로 동작하는 비행기의 남은 전략 상태, 고도, 속도, 배터리 잔량 등을 영상에 오버랩 해 주는 장비까지 정말 끝이 없었다.

무선 영상 전송 카메라와 OSD 선 정리에 영 소질이 없... - FatShark

이쯤 되다 보니, 비행 안정 장치가 있지 않을까 하는 생각도 들기 시작했다. 아니나 다를까 EagleTree라는 회사에서 만든 자이로가 달린 마이크로 컴퓨터 기반 장치를 무선 조종 수신기와 서보 사이에 연결하면 바람의 영향으로 발생하는 자세의 흔들림을 보정했다. 게다가 그라운드 스테이션 컴퓨터도 있어, 이 장치에서 송신되는 텔레메트리 정보를 모으고, 더 장거리 비행을 위한 지향성 안테나를 날고 있는 비행기의 위치에 맞게 조절해 주는 장치도 있었더랬다.

당시에 한가지 더 대두되었던 기술 중 하나는 바로 오픈 하드웨어, 최근엔 라스베리 파이나 아두이노로 알려진 프로그램 가능한 마이크로 컴퓨터들이었다. 코드를 통해 움직이는 무언가를 만들 수 있다는 것은, 그리고 그렇게 할 수 있는 장치들이 십만원 이상을 넘지 않는다는 것은 꽤나 충격적인 변화였다. 2000년대 중반만 하더라도 ARM기반의 학습용 보드들은 쉽게 천만원대를 넘고는 했으니까.

특히 비행 제어 장치 부분에, 당시에는 꽤나 소규모 회사였던 DJI의 장치들이 달린 유튜브 영상들이 매우 충격적이었다. 매우 정밀한 포지셔닝, 그리고 강한 바람에도 흔들림 없는 자세를 유지하던 DJI의 RC용 컴퓨터들은 그 예쁜 디자인 만큼이나 꽤나 고가였다. EagleTree 같은 장치가 20-30만원 할때, DJI의 비행 제어 장치들은 당시에도 100만원을 호가하고는 했었다.

취미와 토이 프로젝트를 통해 기술을 배워 보자 하는 생각을 시작한 것은 그때 쯤이었던것 같다. 아두이노 보드를 사고, GPS를 사고, 자이로를 사고 하며 서보와 연결하고 코드를 쓰고 하면서 꽤나 즐거웠던것 같다. 하지만 뭔가를 잘 하는 것에는 시간이 필요하고, 만들고 싶은 결과물은 너무나 거대했다.

ArduPilot을 사용한 시험 기체. 활주 없이 이륙하기엔 너무 무거워 첫 비행에 손을 떠나자 마자 꼬꾸라 졌다고 한다. 힝.

그러는 동안 국내 통신사의 클라우드 서비스를 만들고, 큰 외국계 기업에 입사하게 되고 하면서 취미를 통해 배우는 일은 매우 시간을 내기 어려운 것이 되었다. 거실의 티비 뒷쪽에는 윙스팬 2.5미터의 거대한 글라이더가 조립만을 기다린채 먼지만 쌓여갔고, 부모님 댁에 놓아두고 온 스핏파이어 발사 비행기는 아버지의 단골 핀잔거리였다.

그렇게 세월이 흐르는 동안 FPV와 비행제어 시스템들은 날로 발전해 드론 레이싱이라는 취미까지 발전하게 된다. 예전에는 320 240 해상도만으로도 감지덕지 했던 것들이 이제는 상당한 해상도로 실시간 전송된다. DJI는 취미를 넘어 항공 촬영이라는 분야로 전문성을 넓혔고, 이것은 그 회사의 상당한 사업적 성공을 가져왔다. 한동안 4차 산업 혁명의 선두 주자 같은 이미지까지 확보하게 되었으니 허허 하는 웃음이 자연히 나는 것도 어쩔 수 없다.

세월의 흐름에 따라 기술의 발전은 끝이 없다. 머신 러닝을 지나 딥 러닝과 비전 컴퓨팅이 등장했다. 카메라로 들어오는 영상 정보를 분석하고 분류하며 이 정보를 바탕으로 다양한, 그야말로 너무나도 다양한 것들을 할 수 있는 시대가 되었다. 오픈 하드웨어를 통해 열린 새로운 세상에는 그와 함께 사용 할 수 있는, 심각하게 저렴한 센서들도 함께 세상에 나오게 했다. 오늘날 Adafruit, Sparkfun 을 비롯한 수많은 몰에서 저렴하게 센서를 구매해서 마이크로 컴퓨터에 연결 할 수 있다. 수년 전에 AVNet과 같은 페이지에서 센서를 구매하려면 상당한 가격과 센서의 스펙을 달달달 읽어 보아야 했던 것과는 매우 다르다. 접근이 편하고, 바로 사용할 수 있는 라이브러리들이 존재하고, 저렴하기에 관심만 있다면 즉시 아이디어를 구현 할 수 있게 된 것이다.

비글 보드를 필두로 라즈베리 파이가 등장했고, 아두이노보다 더 강력한 컴퓨팅 성능을 가진 컴퓨터들이 등장하기 시작했다. 심지어 이것들은 우분투와 같은 리눅스가 올라가 있다. 즉, 성능 좋은 마이크로 컴퓨터들을 위해 리눅스들이 포팅되기 시작했고, 이제 어지간한 규모의 코드들은 손쉽게 돌릴 수 있는 환경이 된 것이다. 심지어 표준이라 불릴만한 생태계를 이루어, 카메라를 구매할 때도 CSI, MIPI 같은 인터페이스의 규격을 모르더라도 '아두이노 호환' '라즈베리 파이' 호환과 같은 설명을 보고 구입해도 실패가 없을 지경이다.

Nvidia의 Jetson TX2 보드. 당시로서는 GPGPU가 탑재된, 구매 가능한 가장 저렴한 보드였다. 현재 1:5 스케일 차에서 열일중.

이것은 이제 필시 넋 놓고 보기만 할 상황은 아닌 것이다. 심지어 이 분야, 즉 컴퓨터, 코드, 서비스와 관계된 일을 업으로 하면서 이런 기술을 배우지 않으면 안되겠다는 위기감이 들기도 했다. 그래서 다시 취미를 통해 새로운 기술을 배운다는 목표를 세우고 실행해 보기로 했다.

이전의 실패중 하나는, 제어의 대상을 무선조종 비행기로 했다는 점이다. 첫째로 무선조종 비행기는 사실 일정 크기가 넘어가면 사람, 특히 어린 아이에게 매우 위험할 수 있다. 그리고 그 특성상 전신주나 전깃줄이 많은 지역, 도심 지역에서는 날리는 것이 불가능하다. 마이크로 컴퓨터를 비행기에 얹기 시작하면 그 무게가 있어 일정 규모 이상이 되지 않으면 안된다. 이러한 종합적 문제들로 인해, 비행기를 포기하고 자동차를 선택했다.

무선 조종 자동차는 의외로 비행기보다 가격대가 높다. 취미로서 무선 조종 자동차는 그 역사가 상당하고, 쉬운 접근성으로 인해 마니아층이 상당해서 그런지는 몰라도, 대부분의 무선 조종 자동차들의 기본 구조는 실제 자동차의 것을 그대로 가져다 만들었기에 부품의 종류와 양이 많다. 뭐 어쨌든 자동차로 하기로 했다.

1:5 스케일은 정말 더럽게 크다. 배터리도 무시무시함. 사진에 보이는 배터리는 단지 수신기와 서보용.

멍청했던 것 중의 하나는 컴퓨터가 올라가려면 좀 커야지! 하는 생각에 1:5 스케일의 자동차를 구매했다는 점이다. 사실 이것은 인터넷을 통해 접하게된 '오토 랠리'라는 조지아 공대의 프로젝트를 보고 따라하려다 보니 그렇게 된 것이다. 이 오토랠리 프로젝트에는 마이크로 컴퓨터가 아니라, 실제 itx 사이즈의 메인보드를 기반으로 한 컴퓨터가 들어간다. 이들의 깃헙에 소개된 부품 리스트들을 보면 그 종류에 입이 떡 벌어지고, 그 가격의 총 합에 턱이 빠지게 된다.

필요한 센서와 부품들은 보다 낮은 등급, 즉 보다 낮은 정밀도를 가진 것들로 대체해서 해결 한다지만, 일단 가까운 곳에 트랙을 찾을 수 없는 것이 더 큰 문제였다. 자동차를 만들어도 굴릴데가 없다는 말이다. 1:5 스케일의 자동차를 본 적이 있는지 모르겠지만, 무게가 킬로그람 단위로 나가는 물건이 시속 80킬로미터 이상으로 달릴 수 있다면 이것은 비행기와 맘먹는, 아니 어쩌면 비행기보다 더 위험한 장난감이 될 수 있기에 다시 안전한 장소를 찾아야 했고, 그런 안전한 공터는 생각보다 많지 않다.

Team Losi의 DBXL-e 차량과 ZED 스테레오 캠 등.

그러는 사이에 또 일년이 지났다. 아마존 웹 서비스에는 '딥 레이서' 라는 장난감과 서비스가 출시되었다. 취미를 통해 배우는 것이 좋다는 것을 아마도 아마존이 알아버렸나보다. 대량으로 생산할 수 있는 적절한 성능과 규모의 자동차와 많이 사용하는 소프트웨어 도구들을 쉽게 얹을 수 있는 딥레이서를 보자마자 나는 또 아차 싶었다.

사실 그동안의 세월이 아무 소용이 없었던 것은 아니었다. 모든 분야가 그렇듯이 하나를 알기 위해서는 그 주변에 연결된 것들을 함께 알아야 할 필요가 있다. 지난 두번의 시도들은 많은 것들을 배울 수 있게 했지만, 일과의 직접적인 관계가 없었기에 충분히 집중하지 못했다. 일을 하다 식사시간에 스마트폰으로 검색하고, 퇴근하다 문득 생각나 검색하고 했던 느슨한 공부들이 어느순간 갑자기 연결되기 시작했다. 그리고 지난 세월 동안 투자했던 시간과 장비들을 모아모아 이번에는 기필코 무언가 완성하겠노라, 그래서 내가 아는 모든 것들을 되짚어 보고 새로운 것을 배워 익히겠노라 하는 다짐을 하게 되었다.

하여 언제든 가까운 곳에서 가지고 놀 수 있고, 위험하지 않으며, 가격도 비교적 저렴한 "컴퓨터가 탑재된 무선 조종 자동차"를 기획했다. 목표는 다음과 같다.

무선 조종기의 스위치 조작을 통해 컴퓨터 제어와 직접 조종을 즉시 변환 할 수 있다.
마음대로 제어가 되지 않는 상황에서는 버튼 하나로 즉시 정지할 수 있어야 한다.
트랙 내에서 가능한 고속으로, 그리고 스스로 주행하도록 하는 것이 목표이다.
주행중 수집된 데이터는 분석을 위해 모아서 저장할 수 있어야 한다.
수집된 정보는 원하는 경우 실시간으로 클라우드 서비스에 스트림으로 보내 저장하여 다양한 목적으로 사용한다.
스마트폰을 통해 달리고 있는 자동차에서 전송되는 정보를 다양한 그래프와 게이지로 확인할 수 있어야 한다.

이 목적을 이루기 위해서 지난 수년간 검색한 결과를 토대로 다음과 같은 리스트를 만들었다.

무선 조종 자동차, 1:10 스케일
Nvidia Jetson Nano // WiFi 및 블루투스 익스텐션 // 전용 레오파드이미징 MIPI 카메라
Arduino Uno 와 데모 보드
무선 조종기 / 수신기
야외에서 사용 가능한 무선 공유기
오차 범위가 센티미터 단위인 GNSS 와 안테나
9축 가속도와 나침반을 포함한 센서 - 9DoF IMU
자동차의 바퀴 속도를 수집하기위한 Hall Effect 센서와 바퀴에 장착할 자석
각종 저항과 연결 실험을 위한 브레드 보드
자동차와 컴퓨터들에 전력을 공급할 전원 분배 장치 - Matek Duo
서보 케이블, 마이크로 USB 케이블 등 케이블 류
3D 프린터
6각 렌치 세트를 비롯한 각종 공구
납땜을 위한 인두

이렇게 새로운 프로젝트는 다시 시작되었다. 이번에는 필시 끝을 보리라...

Sparkfun의 9DoF IMU 센서

다음편에는 1:10 스케일 차량을 포함한 부품들의 구매, 그리고 무선 조종 제어를 위한 PWM 시그널의 이해와 코드를 살펴보기로 한다. 한번에 쓸 수 있다면 MPPI 에 대해서도 간략히 설명을... 언제 또 블로그를 쓸 수 있을지 모른다는 것은 안비밀.

(정윤진, younjin.jeong@gmail.com)

국민 청원 및 제안 - 정부 전산 시스템

Cerberos — Tue, 20 Feb 2018 14:04:53 +0900

쓸때마다 답답한거 청원 한번 넣어 보았다.

https://www1.president.go.kr/petitions/142901?navigation=petitions

이로인해 고통받는 국민들이 얼마나 많을까.

전자 정부 프레임워크도 스프링 부트로 좀 올리고 유닉스 같은거도 좀 그만쓰고 제일 중요한건 좀 브라우저에서 별도 설치 없이 돌아가게 좀. 쪼오오옹오옴

ffmpeg를 자막 입히기, 자막 위치 조정

Cerberos — Thu, 18 May 2017 13:50:57 +0900

(younjin.jeong@gmail.com, 정윤진)

간혹 이런 저런 목적으로 유튜브에 비디오를 자막과 함께 올리는데, 유튜브의 경우 특정 자막이 포함된 링크를 생성하는 것이 불가능하여 아예 자막을 영상에 구워서 업로드 하는 방법을 사용하고 있다. 관련해서 매우 많은 다양한 도구가 있지만, 편의상 사용하는 방법은 아래와 같다.

ClipGrab 과 같은 도구를 사용해서 원하는 영상을 다운로드 받는다. (저작권 문제는 논외)
Youtube 에서 제공하는 "Creator Studio" 를 사용하여 원본 영상을 올린다.
Creator Studio 에 보면, "새로운 자막을 생성" 옵션에서 자막을 신규로 만들어 넣을 수 있도록 기능을 제공하는데, 이걸 사용해서 자막을 제작 한다.
자막을 만들고 나면, "Action" 버튼에서 만들어진 자막을 srt 외 몇가지 포멧으로 다운로드 받을 수 있다.
srt 로 다운 받는다.
ffmpeg 로 ass 포멧으로 변환한다.
.ass 자막 파일을 열어 자막의 위치를 원하는대로 수정한다.
ffmpeg 로 자막을 비디오에 입힌다.

Youtube Creator Studio

.srt 자막을 .ass 로 변환하는 커맨드는 다음과 같다.

ffmpeg -i input.srt output.ass

output.ass 파일을 열면 아래와 같은 포멧이 나타난다.

[Script Info]

; Script generated by FFmpeg/Lavc57.24.102

ScriptType: v4.00+

PlayResX: 384

PlayResY: 288

[V4+ Styles]

Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding

Style: Default,Arial,16,&Hffffff,&Hffffff,&H0,&H0,0,0,0,0,100,100,0,0,1,1,0,2,10,10,10,0

[Events]

Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text

Dialogue: 0,0:00:00.00,0:00:01.04,Default,,0,0,0,,피보탈 | 마이크로 서비스

Dialogue: 0,0:00:01.22,0:00:05.60,Default,,0,0,230,,마이크로 서비스는 거대한 서비스가 각각 독립적인 코드로 구성된 작은 서비스들로 이루어진 것을 말합니다.

Dialogue: 0,0:00:05.66,0:00:08.68,Default,,0,0,270,,개발자들은 마이크로 서비스를 새로운 앱을 개발할때 적용하거나

Dialogue: 0,0:00:08.88,0:00:12.88,Default,,0,0,270,,기존의 소프트웨어를 다수의 파트로 나누어 구성하기도 합니다.

Dialogue: 0,0:00:12.96,0:00:17.26,Default,,0,0,250,,마이크로 서비스 아키텍처는 소프트웨어의 빠른 릴리즈를 도울 뿐만 아니라

Dialogue: 0,0:00:17.38,0:00:20.94,Default,,0,0,250,,팀을 작은 규모로 유지하여 더 나은 업무 프로세스를 만들 수도 있습니다.

Dialogue: 0,0:00:21.06,0:00:24.84,Default,,0,0,250,,이런 마이크로 서비스 접근은 팀이 변화의 요구에 부응하며

Dialogue: 0,0:00:24.84,0:00:26.84,Default,,0,0,250,,새로운 기능을 고객에게 전달할 수 있도록 합니다.

Dialogue: 0,0:00:27.06,0:00:30.84,Default,,0,0,250,,마이크로 서비스 아키텍처는 작은 규모의 소프트웨어를 독립적으로 운용 함으로서

Dialogue: 0,0:00:30.90,0:00:35.36,Default,,0,0,250,,개발과 혁신의 속도를 높여주는 핵심 엔진입니다.

Dialogue: 0,0:00:35.56,0:00:37.56,Default,,0,0,0,,피보탈 | 세상이 소프트웨어를 만드는 방법을 혁신 합니다.

여기서 Events 부분의 Format 을 살펴보면, MarginL, R, V 의 값이 있다. 상단과 하단의 조정은 V 값을 변경해서 적용한다. 변경 적용이 완료 되면 파일을 저장하고 ffmpeg 를 사용해서 비디오에 자막을 입힌다. 이때, ffmpeg 에는 자막 관련 라이브러리를 사용해서 컴파일이 되어 있어야 한다.

커맨드는 아래와 같다.

ffmpeg -i INPUT_VIDEO.mp4 -vf subtitles=INPUT_SUBTITLES.ass OUTPUT_VIDEO_NAME.mp4

그러면 아래와 같은 화면이 출력되며 신나게 인코딩을 수행한다.

built with Apple LLVM version 7.3.0 (clang-703.0.29)

configuration: --prefix=/usr/local/Cellar/ffmpeg/3.0 --enable-shared --enable-pthreads --enable-gpl --enable-version3 --enable-hardcoded-tables --enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-opencl --enable-libx264 --enable-libmp3lame --enable-libxvid --enable-libass --enable-vda

libavutil 55. 17.103 / 55. 17.103

libavcodec 57. 24.102 / 57. 24.102

libavformat 57. 25.100 / 57. 25.100

libavdevice 57. 0.101 / 57. 0.101

libavfilter 6. 31.100 / 6. 31.100

libavresample 3. 0. 0 / 3. 0. 0

libswscale 4. 0.100 / 4. 0.100

libswresample 2. 0.101 / 2. 0.101

libpostproc 54. 0.100 / 54. 0.100

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'What are Microservices.mp4':

Metadata:

major_brand : isom

minor_version : 512

compatible_brands: isomiso2avc1mp41

creation_time : 2017-05-08 22:20:16

encoder : Lavf54.6.100

Duration: 00:00:38.10, start: 0.000000, bitrate: 2137 kb/s

Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 2029 kb/s, 24 fps, 24 tbr, 90k tbn, 48 tbc (default)

Metadata:

creation_time : 2017-05-08 22:20:16

handler_name : VideoHandler

Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 125 kb/s (default)

Metadata:

creation_time : 2017-05-08 22:20:16

handler_name : SoundHandler

File 'What-are-Micro-Services-KR-sub.mp4' already exists. Overwrite ? [y/N] y

[Parsed_subtitles_0 @ 0x7fb1dc500a60] Shaper: FriBidi 0.19.7 (SIMPLE) HarfBuzz-ng 1.2.4 (COMPLEX)

[Parsed_subtitles_0 @ 0x7fb1dc500a60] Using font provider coretext

[libx264 @ 0x7fb1dc80de00] using SAR=1/1

완료되면 비디오를 열어 확인한다.

AEGISSUB 와 같은 좋은 도구가 많지만 웬지 커맨드 라인이 더 익숙해.

(younjin.jeong@gmail.com, 정윤진)

AWS re:Invent 2016 - Keynote 2 신규 서비스

Cerberos — Fri, 2 Dec 2016 08:11:14 +0900

(younjin.jeong@gmail.com, 정윤진)

어제에 이어 오늘도 새로운 서비스들이 쏟아져 나왔다. re:Invent 첫째날은 아마존 웹 서비스의 사장인 Andy Jassy 가 발표를 했고, 두번째 날에는 아마존의 CTO인 Werner Vogels 박사님이 또 새로운 서비스들을 쏟아내었다. 죽 보면서 느끼는건데, 대체 각 서비스별로 Amazon 과 AWS의 이름 규칙은 무엇인가. 알수가 엄쏭.

Keynote 첫날 발표된 내용은 여기로. : http://kerberosj.tistory.com/231

http://venturebeat.com/2016/11/30/aws-reinvent-2016/

2일 동안 발표된 서비스 및 추가 기능은 무려 24개에 달하는데 이는 역시 아마존이 시장의 선두를 유지하기 위해 박차를 가하는 모습이다. 대부분의 서비스들은 기존 고객의 요구 또는 고객들이 아마존 웹 서비스에서 주로 직접 구현해서 사용하는 것에 어려움을 겪는 문제를 해소하기 위해 매니지드 서비스로 만들어 배포하고 있다.

두번째 날에 공개된 서비스들은 주로 개발자들이 관심을 가질만한 내용들로 보인다. 아래에 간단히 그 용도와 링크를 적어본다. 한국에 대한 아마존 웹 서비스의 투자가 늘어나 re:Invent 에서 발표된 내용이 실시간으로 한글 블로그로 번역되어 나오는것에 신기할 따름이다.

AWS X-Ray : https://aws.amazon.com/ko/blogs/korea/aws-x-ray-see-inside-of-your-distributed-application/

- 웹 애플리케이션에서 클라이언트로 부터 서비스로 들어온 요청이 내부에서 어떻게 처리되는지에 대한 가시성을 확보하는 것은 매우 중요하다. 특히 마이크로 서비스와 같은 구조를 구현하고 있는 경우라면 더더욱 그러한데, 이를 AWS에서 사용할 수 있는 것이 X-ray 라는 서비스로 발매 되었다. 트위터가 만든 오픈소스 Zipkin (http://zipkin.io) 의 AWS 버전으로 보인다.

AWS CodeBuild : https://aws.amazon.com/ko/blogs/korea/aws-codebuild-fully-managed-build-service/

- 아마존의 코드 삼형제라는 별명을 붙여서 한참 발표하고 다녔는데 이제 코드 4형제가 되었다. AWS가 만든 Jenkins 라고 이해하면 되겠다. AWS CodeCommit, AWS CodePipeline, AWS CodeDeploy 와 연동 가능하며 특히 CodePipeline 에서 빌드 서비스 공급자로 CodeBuild 를 추가할 수 있어 유용하겠다. 사실 CI/CD 파이프라인 및 컨테이너 레벨의 빌드와 테스트를 수행하는 도구를 직접 설치해서 운영하는 것은 매우 피로도가 높은 일인데, 이렇게 서비스로 제공되면 사용이 편리하겠다.

AWS Shield : https://aws.amazon.com/ko/blogs/korea/aws-shield-protect-your-applications-from-ddos-attacks/

- 많은 사람들이 아기다리고기다리던 기능이 아닐까 싶다. 아울러 이쪽 분야에 솔루션을 판매하던 보안회사들 몇몇은 곡소리가 날지도... 아무튼 AWS 의 DDoS 방어 서비스다. 설명에 따르면 Standard 서비스는 모든 사용자가 무료로 사용할 수 있으며, 지원을 받고자 하는 경우에는 Advanced 를 선택 가능한 모양이다. DDoS 방어의 경우 도메인 부터 서비스 엔드포인트까지 다계층에서 감지 및 조치를 취해야 할 필요가 있는데, Shield 서비스의 경우 Route53 의 도메인, CloudFront 의 CDN edge, 그리고 ELB의 밸런서의 다계층에서 DDoS를 방어한다. 모든 사용자가 살펴볼 필요가 있는 서비스.

AWS Pinpoint : https://aws.amazon.com/blogs/aws/amazon-pinpoint-hit-your-targets-with-aws/

- 마케팅에서 선별된 고객에게만 메세지를 보내는 기능은 매우 중요하다. AWS Pinpoint 는 Mobile analytics 에서 제공하는 몇몇 간단한 지표를 바탕으로 특정 조건에 부합하는 고객들에게 SNS(Simple Notification Service) 를 통해 푸시알람이나 이메일등을 보낼 수 있는 마케팅 그룹용 매니지드 서비스라고 할 수 있겠다. 어떠한 모바일 서비스건 꼭 구현해야 하는 기능이지만 직접 구현하려면 시간과 노력이 필요한 기능을 서비스로 만들었다.

AWS Batch : https://aws.amazon.com/ko/blogs/korea/aws-batch-run-batch-computing-jobs-on-aws/

- 배치 작업의 종류는 다양하지만, 그 기본 구성요소는 거의 대부분 비슷하다. 작업을 위한 클러스터와 이 클러스터를 통제하는 메인 노드 (또는 서버) 그리고 클러스터가 수행할 작업을 분배하고 결과를 수집하는 작업 큐, 그리고 그 클러스터의 수행 목적에 따라 결과를 저장하는 데이터베이스 또는 파일 시스템으로 보통 구성한다. Batch 서비스는 이전 MIT의 StarCluster 와 같은 도구가 하던 일을 아예 서비스로 만들고, 데이터 소스 및 결과물 저장을 위한 DynamoDB, S3 등과의 연동 및 작업을 위한 클러스터 노드 생성과 큐를 만들어 그야말로 뚝딱 사용할 수 있는 서비스다. 예를 들면 렌더링이나 분자화학식 계산, 각종 산업 시뮬레이션 등에 사용 가능하겠으며, 아마도 GPGPU 가 달린 또는 Elastic GPU 등을 사용해 OpenCL 등을 사용하는 클러스터도 제공할 것 같다.

AWS Personal Health Dashboard : https://aws.amazon.com/ko/blogs/korea/new-aws-personal-health-dashboard-status-you-can-relate-to/

- AWS에서 서비스를 운영하다 보면 관리를 위한 정보를 각 서비스 콘솔에서 별도로 확인해야 하는 등의 불편함이 있었다. 예를 들면 메인터넌스를 위한 AWS의 EC2 인스턴스 재부팅 대상이라던가, RDS 데이터베이스의 업데이트 또는 CloudWatch 를 통해 확인해야 하는 각종 알람과 같은 정보들이다. 이런 정보들을 이제 여기저기 돌아다닐 필요 없이 하나의 대시보드에서 확인할 수 있도록 제공하는 서비스로 보인다.

Blox, OSS Container scheduler : https://aws.amazon.com/ko/blogs/korea/blox-new-open-source-scheduler-for-amazon-ec2-container-service/

- 어째서 ECS에서 사용하는 컨테이너 스케줄러를 서비스로 제공하지 않고 오픈소스 도구로 처리하라는지는 잘 모르겠지만, 어쨌든 그렇다. 아마존 웹 서비스를 사용하다 보면 EC2도 그렇고 현재 내가 어떤 인스턴스들 또는 컨테이너를 동작하고 있는지 Describe 관련 API 를 호출하는 경우가 많다. 이는 각 컨테이너의 "State - 상태" 를 그때그때 조회해야 하기 때문에 여간 불편한 것이 아닌데, 이 Blox 라는 도구는 CloudWatch 등을 통해서 상태를 추적하고 사용자가 원하는 수량 또는 작업을 SQS 를 통해 처리하도록 하는 오픈소스란다. 난 피보탈 직원이니까 컨테이너를 클라우드에서 돌리고 싶은 엔터프라이즈라면 그냥 피보탈 클라우드 파운더리를 살펴보는걸 권고. 데헷

AWS Lambda@Edge : https://aws.amazon.com/ko/blogs/korea/coming-soon-lambda-at-the-edge/

- AWS 람다는 함수 단위의 코드를 서버 없이 실행해 주는 서비스다. 이 서비스가 이제 CloudFront의 Edge에서 돌아간단다. 그러니까 즉, CDN에 컴퓨팅 파워를 부여해서 외부에서 들어오는 요청에 대해 더 스마트한 통제를 구현할 수 있게 된다. 현재는 자바스크립트 코드만 동작 가능한 것으로 보이는데, 정리하면 웹 서버 또는 NginX 와 같은 리버스 프락시에서 구현하는 다양한 웹 요청에 대한 조작을 CDN 엣지에서 내가 원하는 대로 자바스크립트를 사용해서 처리할 수 있겠다. 다양하게 응용이 가능하므로 웹 서비스를 수행한다면 꼭 살펴 보아야할 기능.

AWS StepFunctions : https://aws.amazon.com/ko/blogs/korea/new-aws-step-functions-build-distributed-applications-using-visual-workflows/

- 서버리스가 점점 발전하고 있다. Lambda 에서 작성한 각각의 함수 레벨의 애플리케이션을 서로 엮어 개발자가 원하는 조건에 따라 원하는 동작을 처리할 수 있는 일종의 "람다 함수를 묶어 하나의 서비스로" 와 같은 컨셉. 아마존에서 주창하는 서버리스와 람다에 열광하는 사용자라면 반드시 살펴볼 것을 권고한다.

AWS Glue : https://aws.amazon.com/ko/glue/

- 아마존의 공식 블로그 포스팅은 아직 없는 모양. 서비스 홈 페이지를 링크. 간단히 말해서 ETL as a Service. JDBC 로 연결 가능한 모든 데이터 저장소와 S3, RDS, Redshift 간의 데이터 이동등을 편리하게 처리할 수 있겠다. 또한 이렇게 만들어진 ETL을 Python, Spark, Git 또는 IDE 등을 사용해서 다른 Glue 사용자들과 공유를 할 수도 있단다. 따라서 Kinesis firehose 등을 사용하여 인입된 데이터를 서비스간 원하는 대로 편리하게 쪼물락 할 수 있다는 말.

몇가지 서비스가 더 있기는 하지만, 일단 영문과 국문 블로그에 소개된 서비스들을 우선으로 정리 했다. 어차피 다들 시간을 두고 차근차근 살펴보아야 할 서비스들이므로, 몇개월 재미지게 생겼다.

매번 느끼는 거지만 최근의 비지니스들은 모두 인터넷과 소프트웨어 그리고 데이터를 사용하지 않는 경우는 드물다. 더 중요한 것은 동일한 작업의 반복, 예를 들면 주로 테스트나 빌드, 그리고 배포등 과 같이 사람이 하면 오래걸리거나 실수가 발생하여 장애로 발전하는 형태의 것들이 클라우드 시대에 더더욱 많아진다. 금번 아마존 웹 서비스의 re:Invent 를 보면 인프라는 내게 맡기고 너는 서비스에 집중하라 는 메세지가 매우 강하다. 탄탄한 기본 서비스들을 바탕으로 점점 발표되는 신규 서비스의 양이 가속화 되는 것을 보면 굉장하다.

나 역시 아마존 웹 서비스의 강렬한 팬이지만, 아마존 웹 서비스를 사용한다고 아마존 닷 컴을 만들 수 있는 것은 아니다. 결국 핵심 역량은 서비스에 필요한 애플리케이션과 데이터 코드를 얼만큼 빠르게 개발하고 테스트해서 배포할 수 있는가 하는 것이 아닐까.

아마존 웹 서비스의 시장과 고객에 대한 집착이 보이는 굉장한 2일의 키노트였다.

(younjin.jeong@gmail.com, 정윤진)

AWS re:Invent 2016 - Keynote 1 신규 서비스

Cerberos — Thu, 1 Dec 2016 05:51:06 +0900

(younjin.jeong@gmail.com, 정윤진)

오랜만에 아마존 웹 서비스 관련 내용. 아마존 웹 서비스는 매년 10월-12월 사이의 겨울에 글로벌 규모의 행사를 진행한다. 이 행사는 re:Invent 라고 불리며 매년 참가자가 늘어나고 있다. 올해 2016년에는 3만 5천명 규모의 행사로 라스베가스의 베네시안에서 진행된다. 여러해 동안 아마존 웹 서비스와 이렇게 저렇게 인연을 쌓아왔지만 re:Invent 에 참석하는 것은 처음이다. 어마어마한 사람들, 해를 거듭할 수록 쏟아지는 새로운 서비스들, 그리고 이 서비스들을 사용한 다양한 경험의 공유와 더 잘 사용하기 위한 팁 등이 발표된다.

2016년 올해도 다양한 서비스들이 발표 되었다. 전반적인 서비스 개선의 흐름을 보자면 사용성의 개선을 통한 신규 사용자의 진입 장벽을 낮추고, 데이터 분석과 관련된 신규 서비스들이 발표 되었으며 특히 아마존 에코를 통해 축적된 음성 인식 기술을 보편적으로 사용할 수 있도록 하는 서비스들, 이미지 분석, 그리고 대량의 데이터 이전 등 첫날의 발표는 다소 데이터에 집중하는 모습이다.

아마존 웹 서비스는 탄탄한 기반의 EC2와 S3를 바탕으로 지속적으로 서비스 포트폴리오를 확장해 왔는데, 이번에도 역시 아마존의 서비스를 지원하기 위해 필요했던 다양한 기술, 그리고 아마존의 경험이 녹아있는 기술들이 아마존 웹 서비스로 발표 되었다는 느낌이다.

아래는 발표된 서비스에 대한 간략한 설명과 자세한 사용을 위한 링크다.

EC2 확장 기능, Elastic GPU : https://aws.amazon.com/ko/blogs/korea/in-the-work-amazon-ec2-elastic-gpus/

- EC2 서버 인스턴스에 GPU를 붙였다 떼었다 할 수 있도록 디자인된 EC2 확장 기능

F1 인스턴스 패밀리 : https://aws.amazon.com/ko/blogs/korea/developer-preview-ec2-instances-f1-with-programmable-hardware/

- FPGA를 사용할 수 있는 새로운 인스턴스 타입

Amazon Athena : https://aws.amazon.com/ko/blogs/korea/amazon-athena-interactively-query-petabytes-of-data-in-seconds/

- S3에 저장된 데이터에 표준 SQL을 사용할 수 있는 서비스

Amazon LEX : https://aws.amazon.com/ko/blogs/korea/amazon-lex-build-conversational-voice-text-interfaces/

- 음성 인식 및 자연어 이해를 통해 채팅봇 또는 애플리케이션에 음성 인터페이스를 추가할 수 있도록 하는 신규 서비스. 아직 한국어 지원은 되지 않는 듯

Amazon Polly : https://aws.amazon.com/ko/blogs/korea/polly-text-to-speech-in-47-voices-and-24-languages/

- 다양한 음색과 언어를 지원하는 문장 -> 음성 인터페이스 서비스. 지원하는 언어에 사용되는 다양한 어휘를 상황에 따라 올바르게 읽는 능력을 제공, 따라서 LEX 와 함께 사용할때 애플리케이션에서 처리한 내용을 음성으로 사용자에게 전달할 수 있음

Amazon Rekognition : https://aws.amazon.com/ko/blogs/korea/amazon-rekognition-image-detection-and-recognition-powered-by-deep-learning/

- 이미지의 내용을 분석해 주는 서비스. 이미지의 사람 표정에서 감정을 추출하거나, 이미지의 내용을 딥러닝에 기반하여 리턴

Amazon Aurora - Posgresql : https://aws.amazon.com/ko/blogs/korea/amazon-aurora-update-postgresql-compatibility/

- 아마존 오로라는 아마존이 만든 오픈소스 기반의 데이터베이스 서비스인데, 종전에는 MySQL 호환만 존재 하였으나 이번에 Postgres 엔진도 발표 됨. 기존의 RDS Posgres 로 부터의 손쉬운 마이그레이션 등을 제공하며, 일반적으로 두배 정도의 성능 향상을 기대할 수 있다고 함

AWS Greengrass : https://aws.amazon.com/ko/blogs/korea/aws-greengrass-ubiquitous-real-world-computing/

- IoT 관련 서비스를 만들다 보면 데이터를 클라우드로 전달하는 과정에서 누락등이 발생하기 때문에 이를 보완하기 위해 Sensor 게이트웨이 같은 장치를 구현하는 경우가 많은데, 이를 클라우드로 직접 전달하는 대신 센서등이 위치한 로컬의 하드웨어에서 Lambda 기반의 Greengrass Core 를 실행하여 작업을 처리하는 도구. 즉, IoT 데이터 처리를 위한 로컬 람다 소프트웨어.

AWS Snowball Edge : https://aws.amazon.com/blogs/aws/aws-snowball-edge-more-storage-local-endpoints-lambda-functions/

- 내용을 보다 보면 기존의 Storage Gateway 와 Snowball 을 합친 모양새. Snowball 은 로컬의 데이터센터에서 아마존으로 데이터의 이동이 필요한 경우 제공되는 일종의 운반용 디스크 세트였는데, 이를 아예 센터의 로컬에 설치하여 연동할 수 있도록 구현한 것으로 보임. 인터페이스는 10G, 25G, 40Gbps 를 제공하며, 심지어 Zigbee 역시 지원한단다. S3의 API 가 달려있으며 멀티파트 업로드 등으로 데이터 전송을 빠르게 처리할 수 있고, 몇개를 더 묶어서 클러스터링까지 가능한 모양. 람다를 사용한 컴퓨팅 기능까지 포함 하고 있는 로컬 스토리지 + 컴퓨팅 머신

AWS Snowmobile : https://aws.amazon.com/blogs/aws/aws-snowmobile-move-exabytes-of-data-to-the-cloud-in-weeks/

- 엑사 바이트 규모의 데이터 이전에 사용한다. 데이터센터에 아무리 빠른 네트워크가 있다고 하더라도, 엑사바이트 규모의 데이터를 아마존으로 전송하기 위해서는 수개월-1년 이상의 시간이 필요할 수 있다. 이에 아마존은 스노우모바일이라 불리는 서비스를 출시 하였으며, 거대한 컨테이너가 달린 트럭을 사용한다.

http://venturebeat.com/2016/11/30/aws-unveils-snowmobile-truck-for-moving-data-to-its-cloud/

오늘 나온 서비스들이라서 더 자세한것은 써봐야 알겠지만 어쨌든 클라우드 서비스 시장에서의 맹주로서 무서운 속도로 서비스를 내어 놓는 것 만은 분명하다. 새롭게 늘어난 인스턴스 종류, 직접 구현하기 힘든 다양한 음성 및 데이터 관련 서비스들은 아마도 다양한 스타트업들에서 다양한 형태로 사용될 것으로 생각된다.

놀라운 점은, 이미 시장에서 선두를 달리고 있는 회사가 이런 속도로 또 다시 신규 서비스들을 발매 한다는 점이다. 아울러 최근의 모든이가 알겠지만, 1.0 버전의 발매는 거기서 끝이 아니라 지속적인 개선을 필요로 한다. 수십개가 넘는 각각의 아마존 웹 서비스의 제품들이 저마다 또 다른 속도로 개선될 것을 생각해 보면, 2017년에는 아마도 일주일에 50개씩 업데이트가 생길지도 모르겠다. ㅎㅎ

아울러 피보탈의 클라우드 파운더리에서 Amazon Service broker 를 통해 다양한 신규 서비스를 애플리케이션 개발자가 손쉽게 연동해서 사용할 날이 오기를 기대한다.

(younjin.jeong@gmail.com, 정윤진)

고가용 서비스 - Spring Cloud - #5 Deploy your applications to the cloud / Cloud Foundry

Cerberos — Fri, 18 Nov 2016 17:54:46 +0900

(younjin.jeong@gmail.com, 정윤진)

지금까지 이런저런 스프링 부트/스프링 클라우드에 대한 내용을 살펴보았는데, 사실 더 진행을 위해서는 또 다른 역할을 하는 마이크로 서비스를 만들어 내야 한다. 그런데 사실 로컬 랩탑에서 이런저런 마이크로 서비스들을 서로 다른 포트로 localhost 에서 돌리는것은 꽤나 귀찮은 일이 아닐수 없다. 그리고 아마 스프링 부트를 살펴보시는 분들이 하고계시는 고민중의 하나가 아마도 "어? WAS를 따로 안써도 된다고? 그럼 서비스는 어떻게 돌려?" 일 것이다. 물론 java -jar 의 방법이 아름답지만, 수십 수백기가의 메모리가 달려있는 서버에서 딸랑 저렇게 수행하는 것은 뭔가 맞지 않는 느낌적인 느낌이다. 그래서 docker 를 사용해서 올리거나 하는 방법을 사용할 수 있지만 뭐 요새 docker 는 하도 사방에서 이야기가 많으니까 나는 그걸 하지 않는 것으로 하고...

이런 도구를 왜 굳이 설치해서 사용해야 하느냐? 클라우드 어쩌고 이런 말은 일단 빼고 간략히 설명하면,

- 개발된 애플리케이션의 배포를 빠르게 수행하고 싶다.

- 각각의 애플리케이션을 80/443 포트에서 구동할 필요가 있다.

- 마이크로 서비스 구현 및 개발을 위해 필요한 애플리케이션 여러개를 동시에 동작해야 할 필요가 있다.

- Redis, RabbitMQ, MySQL 의 리소스를 사용한 애플리케이션 개발을 해야 할 필요가 있다. (물론 다른 도구들도 리소스가 있다면 연결 가능하지만, 위의 세개 서비스를 즉각 할당 받아 사용할 수 있으므로.)

- 로컬에서 docker 컨테이너를 여러개 돌렸을때 발생하는 의존성들에서 자유롭고 싶다.

개발, 테스트 및 학습을 위해 오늘은 Cloud Foundry 를 소개한다. 회사에서 서버 레벨로 구동하지 않는 경우를 제외하고 개발자를 위한 환경을 소개하면 두가지 방법이 있는데, 하나는 PCFDEV 라고 불리는 로컬용 개발 버전을 사용하는 것과 다른 하나는 Pivotal Web Services 라고 불리는 환경을 60일 정도 무료로 제공받아 사용하는 방법이 있다. 로컬 버전을 설치하거나 PWS를 사용하거나 클라이언트 도구가 올라간 이후에 사용 방법은 동일하기 때문에 별 문제될 것은 없다. 다만 PWS를 사용하는 경우 백엔드 서비스의 선택폭이 다양하기 때문에 편리할 수 있다.

Pivotal Web Services - 신용카드 등록 따위 없이 후리티어를 경험합시다!

먼저 PWS 를 사용하는 방법은 간단하다. https://run.pivotal.io 의 도메인으로 접근한 뒤, 페이지의 안내에 따라 sign-up for free 버튼을 누르고 로그인 화면이 나오면 아래 "create account" 를 클릭해서 필요한 내용을 기입하면 된다.

패스워드 복잡성 체크를 예쁘게 해준다. 그러면 Pivotal 로 부터 Verification 메일이 하나 온다. 메일은 요렇게 생겼다.

이메일 안의 Verify your email address 를 클릭하면 아래와 같은 Free trial 등록 페이지로 넘어간다. 사용을 위해, SMS 를 선택하고 Korea, Republic of 를 선택한다. 그리고 제일 아래에는 모바일 번호를 넣어주면 된다. 그냥 한국 전화 번호 010-xxxx-xxxx 를 넣어도 정상적으로 문자 메세지가 수신 되는데, 만약 잘 안된다면 국가 번호를 더해서 넣어 보아도 된다.

그러면 페이지가 넘어가면서 문자 메세지를 전화번호로 보냈으니 살펴서 코드를 입력하라 한다.

개인정보 보호를 위해 선글라스를 씌웠더니 이미지에 검은색 배경이 생긴다능...

화면이 넘어가면서 Org 라는걸 생성하라고 한다. 얘는 조직 이름인데, 블로그를 보고 따라 하시는 분들 께서는 거의 개인 목적의 사용일 테므로 원하는 이름을 주면 된다. 기본으로 주어지는 이름을 사용해도 되지만 아마 전체 계정에서 유일한 이름을 사용해야 할 필요가 있을지도 모르겠다. 아무튼 기억할건 이 이름이 너무 길면 나중에 타이핑이 좀 힘들 수 있으므로 간략하고도 유니크한 나만의 조직 이름을 선택하도록 하자.

아울러 페이지의 오른쪽에 보면 어떤 서비스를 얼만큼 무료로 사용할 수 있는지 나온다. 프리 트라이얼 기간이 끝나면 청구되는거 아냐! 하고 겁내지 말자. 일단 신용카드 정보 기입과 같은 단계는 없다. 무료 사용 금액을 넘어가는 리소스는 쿼터로 제한되어 어차피 구동되지 않는다. 하지만 1년이 지나면 동작하던 서비스들이 중단될 수 있으므로 주의할 필요는 있겠다. 아울러 이 PWS 는 현재 미국 동부의 아마존 웹 서비스 위에서 기동되고 있으므로 속도가 찌끔 느리더라도 아 멀어서 그렇겠거니 하시면 된다.

자, 이제 PWS 사용을 위한 준비가 모두 끝났다. 로컬 버전 설치를 원하지 않는 경우라면 다음의 pcfdev 부분을 건너 뛰고 보시면 되겠다.

pcfdev - 누가 뭐래도 나는 로컬이 짱이야! / 우리 회사는 방화벽이 빡세거든! / 내가 만든 애플리케이션은 나만 봐야지!

다음의 링크는 각각 pcfdev 를 로컬에 다운로드 받아 구동에 대한 설명이다. 그다지 어려울 것은 없고, 윈도우든 맥이던 Virtualbox 를 준비한 이후 pcfdev.io 또는 network.pivotal.io 에서 개발 버전을 다운로드 받을 수 있겠다. 물론 코드가 궁금하신 분은 오픈소스이므로 아래의 깃헙 링크를 참조하실 수도 있겠다. https://github.com/pivotal-cf/pcfdev

윈도우용 설치 : https://docs.pivotal.io/pcf-dev/install-windows.html

OSX 용 설치 : https://docs.pivotal.io/pcf-dev/install-osx.html

pcfdev 를 사용하여 랩탑이나 데스크탑의 개발 환경에서 운용 하는 방법은 의외로 간단하다. cf dev start / cf dev stop 의 커맨드로 필요한 환경을 들었다 놓았다 할 수 있다. 시스템에 기본적으로 20기가 바이트 이상의 디스크 여유 공간과 8기가 바이트의 메모리가 탑재되어 있어야 하며, 사실 이클립스나 IntelliJ 같은 도구를 같이 틀어놓고 작업하려면 16기가바이트의 메모리를 가진 머신에서 사용하는 것을 권고 한다.

위의 링크에 나온대로 살짝 따라하다 보면 어느새 내 랩탑에도 클라우드 파운더리가 뙇!

Downloading VM...
Progress: |====================>| 100%
VM downloaded
Importing VM...
Starting VM...
Provisioning VM...
Waiting for services to start...
40 out of 40 running
 _______  _______  _______    ______   _______  __   __
|       ||       ||       |  |      | |       ||  | |  |
|    _  ||       ||    ___|  |  _    ||    ___||  |_|  |
|   |_| ||       ||   |___   | | |   ||   |___ |       |
|    ___||      _||    ___|  | |_|   ||    ___||       |
|   |    |     |_ |   |      |       ||   |___  |     |
|___|    |_______||___|      |______| |_______|  |___|
is now running.
To begin using PCF Dev, please run:
    cf login -a https://api.local.pcfdev.io --skip-ssl-validation
Admin user => Email: admin / Password: admin
Regular user => Email: user / Password: pass

메모리나 코어를 조금 더 할당하고 싶다면 -m 스위치와 -c 스위치를 사용하여 환경을 구동할 수 있다.

$ cf dev start -m 8192 -c 4

환경이 필요 없다면 아래의 커맨드로 간단히 모든 환경을 종료 할 수 있다.

cf dev stop

PWS는 인터넷에 공개된 환경이고, 제한된 쿼터이긴 하지만 소규모로 프로덕션으로 사용할 수도 있기는 하다. 다만 실제 서비스에 유입되는 트래픽 규모가 커진다면 그때는 쿼터를 해제하거나 별도의 방법을 사용할 필요가 있다. 반대로 PCFDEV는 "개발"을 위한 환경이며 절대로 프로덕션용 서버에 배포해서 사용하는 일이 없도록 한다.

두 도구의 차이는 아래의 이미지에서 살펴볼 수 있다.

https://pivotal.io/pcf-dev

클라우드 파운더리는 기본적으로 꽤 많은 인스턴스를 만들어 낸다. 로컬이던 프로덕션용이건 간에 암튼 많다. 이게 왜 많냐면, 다음과 같은 것들을 개발자가 신경쓰지 않게 해 주기 때문이라고 생각하면 된다.

- 동적 로드밸런싱, 도메인 라우팅

- 헬스 모니터링

- 컨테이너 이미징

- 로그 어그리게이션

- 컨테이너 오케스트레이션

- 컨테이너 기동

- MySQL, RabbitMQ, Redis 인스턴스

- API 인증

- 앞에서 소개한 Config server, Circuit breaker, Registry (유레카) 의 3개가 서비스로 이미 뙇!

- 업로드된 빌드/아티팩트 저장, 보관

- 기타 등등 오퍼레이션 잡무

준비 됬다면? 고고고

위의 도구들 중 하나가 준비 되었다면 cf 라는 클라이언트를 통해 애플리케이션의 배포가 가능하다. PWS를 사용하는 경우라면, 로그인 후 나오는 웹 인터페이스에서 왼쪽을 보면 "Tools" 탭이 있다. 클릭하면 각 운영체제에 맞는 클라우드 파운드리의 클라이언트 도구를 다운로드 받을 수 있다. cf 클라이언트가 준비 되었다면, 다음의 과정을 수행한다.

PWS의 경우 :

$ cf login -a https://api.run.pivotal.io

pcfdev 의 경우 :

$ cf login -a https://api.local.pcfdev.io --skip-ssl-validation

Email>  admin

Password>
인증 중...
확인

조직 선택(또는 Enter를 눌러 건너뜀):
1. pcfdev-org
2. system

Org> 1
대상 지정된 조직 pcfdev-org

대상 지정된 영역 pcfdev-space

로그인이 완료되면, 이제 다양한 cf 클라이언트를 사용할 수 있다. 먼저 cf apps 를 때려 보면 현재 조직의 "스페이스" 라고 불리는 환경에 동작하는 모든 애플리케이션 리스트를 보여준다. 아마 처음 PWS를 사용하거나 pcfdev 를 사용하면 아무런 애플리케이션이 보이지 않을 것이다.

$ cf apps
yjeong@pivotal.io(으)로 yjeong-org 조직/development 영역의 앱 가져오는 중...
확인

앱을 찾을 수 없음

최근의 pcfdev 는 아래와 같은 웹 콘솔까지 제공한다. https://console.local.pcfdev.io 로 접근하면 된다. 임의로 만든 SSL 인증서를 사용하므로 접근시 등장하는 경고는 무시해 주면 된다.

자, 그럼 이제 이전 시리즈에 만들어 두었던 애플리케이션들을 구동해 보자.

- Config-server

- Discovery-service

- Zipkin-service

- helloworld-service

- helloworld-client

의 순서대로 푸시한다. 먼저 빌드하고,

$ ./mvnw clean package

[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building config-server 0.0.1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
...
..
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 11.762 s
[INFO] Finished at: 2016-10-21T12:37:50+09:00
[INFO] Final Memory: 35M/278M
[INFO] ------------------------------------------------------------------------

push, 즉 배포를 수행한다.

$ cf push config-server -p target/config-server-0.0.1-SNAPSHOT.jar

admin(으)로 pcfdev-org 조직/pcfdev-space 영역에 config-server 앱 작성 중...
확인

config-server.local.pcfdev.io 라우트 작성 중...
확인

config-server에 config-server.local.pcfdev.io 바인드 중...
확인

config-server 업로드 중...
업로드 중인 앱 파일 원본 위치: /var/folders/j0/vxfr0q8d2mx58xt27jx2dsd80000gn/T/unzipped-app841413472
38.1M, 185 파일 업로드
Done uploading
확인


admin(으)로 pcfdev-org 조직/pcfdev-space 영역에서 config-server 앱 시작 중...
Downloading dotnet_core_buildpack_beta...
Downloading python_buildpack...
Downloading binary_buildpack...
Downloading php_buildpack...
Downloading staticfile_buildpack...
Downloaded binary_buildpack (9.1K)
Downloading go_buildpack...
Downloaded staticfile_buildpack
Downloading java_buildpack...
Downloaded java_buildpack (246M)
Downloading ruby_buildpack...
Downloaded go_buildpack (320.8M)
Downloading nodejs_buildpack...
Downloaded dotnet_core_buildpack_beta (99.4M)
Downloaded python_buildpack (255.2M)
Downloaded nodejs_buildpack (96.7M)
Downloaded ruby_buildpack (261.5M)
Downloaded php_buildpack (274.9M)
Creating container
Successfully created container
Downloading app package...
Downloaded app package (33.9M)
Staging...
-----> Java Buildpack Version: v3.8.1 (offline) | https://github.com/cloudfoundry/java-buildpack.git#29c79f2
-----> Downloading Open Jdk JRE 1.8.0_91-unlimited-crypto from https://java-buildpack.cloudfoundry.org/openjdk/trusty/x86_64/openjdk-1.8.0_91-unlimited-crypto.tar.gz (found in cache)
Expanding Open Jdk JRE to .java-buildpack/open_jdk_jre (0.8s)
-----> Downloading Open JDK Like Memory Calculator 2.0.2_RELEASE from https://java-buildpack.cloudfoundry.org/memory-calculator/trusty/x86_64/memory-calculator-2.0.2_RELEASE.tar.gz (found in cache)
Memory Settings: -Xms104169K -XX:MetaspaceSize=64M -Xmx104169K -XX:MaxMetaspaceSize=64M -Xss228K
-----> Downloading Spring Auto Reconfiguration 1.10.0_RELEASE from https://java-buildpack.cloudfoundry.org/auto-reconfiguration/auto-reconfiguration-1.10.0_RELEASE.jar (found in cache)
Exit status 0
Staging complete
Uploading droplet, build artifacts cache...
Uploading build artifacts cache...
Uploading droplet...
Uploaded build artifacts cache (108B)
Uploaded droplet (79.4M)
Uploading complete
Destroying container
Successfully destroyed container

0 / 1 인스턴스 실행 중, 1 시작 중
1 / 1 인스턴스 실행 중

앱 시작됨


확인

`CALCULATED_MEMORY=$($PWD/.java-buildpack/open_jdk_jre/bin/java-buildpack-memory-calculator-2.0.2_RELEASE -memorySizes=metaspace:64m..,stack:228k.. -memoryWeights=heap:65,metaspace:10,native:15,stack:10 -memoryInitials=heap:100%,metaspace:100% -stackThreads=300 -totMemory=$MEMORY_LIMIT) && JAVA_OPTS="-Djava.io.tmpdir=$TMPDIR -XX:OnOutOfMemoryError=$PWD/.java-buildpack/open_jdk_jre/bin/killjava.sh $CALCULATED_MEMORY" && SERVER_PORT=$PORT eval exec $PWD/.java-buildpack/open_jdk_jre/bin/java $JAVA_OPTS -cp $PWD/. org.springframework.boot.loader.JarLauncher` 명령을 사용하여 config-server 앱이 시작되었습니다.

admin(으)로 pcfdev-org 조직/pcfdev-space 영역에서 config-server 앱의 상태 표시 중...
확인

요청된 상태: started
인스턴스: 1/1
사용법: 256M x 1 인스턴스
URL: config-server.local.pcfdev.io
마지막으로 업로드함: Fri Oct 21 03:38:16 UTC 2016
스택: unknown
빌드팩: java-buildpack=v3.8.1-offline-https://github.com/cloudfoundry/java-buildpack.git#29c79f2 java-main open-jdk-like-jre=1.8.0_91-unlimited-crypto open-jdk-like-memory-calculator=2.0.2_RELEASE spring-auto-reconfiguration=1.10.0_RELEASE

상태      이후                     CPU    메모리          디스크          세부사항
#0   실행 중   2016-10-21 12:39:07 PM   0.0%   185.2M / 256M   160.7M / 512M

배포후 정보를 보면 URL 부분에 배포된 애플리케이션이 어느 주소로 동작하고 있는지 나온다. config-server 를 배포해 보았으므로 정상적으로 동작하는지 확인해 보자.

$ curl http://config-server.local.pcfdev.io/account-service/cloud | jq
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
100   936  100   936    0     0    499      0  0:00:01  0:00:01 --:--:--   498
{
  "name": "account-service",
  "profiles": [
    "cloud"
  ],
  "label": "master",
  "version": "dc82fb551c53e86af22e064eedfb35678e98917e",
  "propertySources": [
  {
    "name": "https://github.com/younjinjeong/demo-config/application.properties",
    "source": {
    "eureka.instance.hostname": "${vcap.application.uris[0]:localhost}",
    "logging.level.com.netflix.discovery": "OFF",
    "eureka.client.registryFetchIntervalSeconds": "5",
    "spring.sleuth.sampler.percentage": "1.0",
    "logging.level.com.netflix.eureka": "OFF",
    "server.port": "${PORT:0}",
    "endpoints.shutdown.enabled": "true",
    "eureka.instance.leaseRenewalIntervalInSeconds": "3",
    "eureka.instance.prefer-ip-address": "true",
    "eureka.instance.metadataMap.instanceId": "${vcap.application.instance_id:${spring.application.name}:${spring.application.instance_id:${server.port}}}",
    "info.id": "${spring.application.name}:${server.port}",
    "eureka.client.region": "default",
    "spring.jpa.generate-ddl": "true",
    "spring.sleuth.log.json.enabled": "true"
    }
  }
  ]
}

pcfdev 또는 PWS 에 환경이 준비 되었다면, 이제 다음 포스팅에서 본격적으로 애플리케이션을 구동하고 데이터 소스와 연동하는 방법을 살펴 보겠다. 일단 어디든 올릴데가 생겨야 서킷 브레이커든 다른 스프링 클라우드 관련 리소스를 올려서 테스트 할 수 있을 듯. 오늘은 힘드니까 여기까지.

(younjin.jeong@gmail.com, 정윤진)

고가용 서비스 - Spring Cloud - #4 Monitor your Micro services - Zipkin

Cerberos — Sat, 24 Sep 2016 19:23:09 +0900

(정윤진, younjin.jeong@gmail.com)

서비스를 모니터링하는 것은 매우 중요하다. 모니터링 동작은 기본적으로 각종 시스템의 지표를 주기적으로 취득하여 이를 로그로 남기거나 또는 이 로그 스트림을 어딘가로 보내 그래프를 만들고, 특정 값 또는 특정 문자열이 발견되면 알람을 울리는 식의 단계를 가진다. 이런 각종 시스템의 지표, 이를 테면 CPU, 메모리, 디스크, 네트워크 사용율과 같은 정보들은 OS에서 제공하는 /proc 하위 디렉토리 내용을 참조하거나 별도의 커맨드를 크론으로 주기적으로 돌려서 실행하곤 한다.

이런 행위는 애플리케이션 서버에서도 동일하게 발생하는데, 보통 웹 애플리케이션 서버와 관련된 프로세스를 체크하거나 역시 이 서버들이 내리는 로그를 모니터링 하고 여기에 문제가 발생한 경우 알람을 울리는 역할을 하도록 하는 경우가 대부분이다. 물론, 역시 커스텀 로그의 생성도 가능하겠다.

로그는 서비스 운영에 있어 굉장히 중요한 자산이다. 하지만 대부분의 레거시 시스템들에서는 이런 로그를 별도로 모아서 서비스에 어떤일이 발생했었는지, 또는 고객들의 서비스 사용 패턴에 대해 분석한다던지 하는 작업을 하는 경우는 별로 없었다. 거의 대부분 운영체제와 프로세스가 만들어 내는 로그들은 디스크에 차곡차곡 쌓이다가 어느 순간 디스크 사용율이 98% 정도에 이르면 시원하게 로그를 비워주는 작업을 하고는 했다. 하지만 이런 로그의 처리 방식은 최근 클라우드 기반의 (또는 클라우드 기반이 아니더라도) 서비스에서는 도저히 용납될 수 없는 처리 방식이라고 할 수 있다. 따라서 각 서버들이 생산해 내는 로그들은 깔때기 처럼 로그를 어느 한군데로 원격으로 수집하고, 이를 별도의 클라우드 스토리지에 자연스럽게 연계하여 저장하고, 저장된 정보를 하둡이나 데이터웨어 하우징에서 처리하도록 구성한다. 이런 방식의 로그 처리에 대해서는 아래의 링크를 살펴보면 보다 더 자세한 정보와 함께 다양한 옵션을 확인할 수 있겠다. (https://logging.apache.org/log4j/2.x/manual/appenders.html) 로그 스트림 처리에 대해서는 나중에 기회가 되면 소개를.

http://www.slideshare.net/petervandenabeele/akka-streams-kafka-kinesis-49863296

사실 로그는 오늘 언급할 주된 범주가 아니다. 로그는 사실 "어떤 사건이 발생했다" 라는 정보를 감지하는데는 매우 중요하지만, "왜 발생했는지" 에 대해서 설명을 해 주진 않는다. 아니 사실 해 주기는 하는데, 이는 로그를 스트림으로 처리해서 일련의 사건 흐름을 되짚어 보는 형태의 분석에 대한 구성이 필요하고, 이는 생각보다 꽤나 노력이 드는 일이다. 어쨋든 우리에게는 "왜 이런일이 발생했는가" 에 대한 내용을 볼 필요가 있는데, 마이크로 서비스를 구성하게 되는 경우 이는 각각의 서버 인스턴스에서 발생하는 로그를 위에 소개한 방법으로 전부 취합해서 시각화 하고 분석을 돌려야 하는 노력이 필요하다. 그러므로, 그래서 오늘 소개하는 도구는 바로 이런 일을 간단히 해 줄 수 있는 도구다.

Zipkin 이 하는 기본적인 일은, 외부로 받은 요청과 그 요청을 처리하기 위해 발생하는 내부 요청을 기록한다. 그리고 이 기록된 요청에 대해 일목 요연하게 시각화 해 주며, 따라서 특정 요청을 처리하기 위해 어떤 서비스들이 참조 되었고 또 어떤 서비스가 제 속도를 내고 있지 못하는지의 여부를 쉽게 확인할 수 있다. 이는 트위터에서 만든 도구인데, 홈페이지는 http://zipkin.io

백문이 불여일견, 백견이 불여일행.

스프링 클라우드에서는 이 Zipkin 을 정말로 매우 쉽게 사용할 수 있도록 한다. 먼저 이전 포스팅에서 사용했던 헬로월드 클라이언트와 서버에 이 Zipkin 을 붙여 보도록 하자.

먼저 zipkin-service. properties 파일을 demo-config 에 추가한다.

server.port=${PORT:9411}
spring.datasource.initialize = false
spring.sleuth.enabled = false
zipkin.store.type = mem

Config server 가 참조하는 코드 저장소에 커밋하고 푸시한다.

아래의 설정을 application.properties 에 추가한다. 이 설정은 모든 서비스에 글로벌로 적용된다.

spring.sleuth.sampler.percentage=1.0
spring.sleuth.log.json.enabled=true

아래의 순서로 Zipkin 서버를 준비한다.

- http://start.spring.io 에 간다.

- artifact 에 zipkin-service 이름을 준다.

- dependencies 에 Config client, Discovery, Zipkin UI, Zipkin server 를 추가하고 프로젝트를 생성하여 다운로드 받는다.

- IDE 를 열어 아래와 같이 애플리케이션에 Zipkin 과 Eureka 사용을 위한 어노테이션을 추가한다.

spring-cloud-zuul-proxy-demo/zipkin-service/src/main/java/com/example/ZipkinServiceApplication.java

package com.example;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.EnableEurekaClient;
import zipkin.server.EnableZipkinServer;

@SpringBootApplication
@EnableZipkinServer
@EnableEurekaClient
public class ZipkinServiceApplication {

   public static void main(String[] args) {
      SpringApplication.run(ZipkinServiceApplication.class, args);
   }
}

spring-cloud-zuul-proxy-demo/zipkin-service/src/main/resources/bootstrap.properties

- bootstrap.properties 를 추가하고 Config server 참조를 위한 설정과 애플리케이션의 이름을 할당한다.

mvn spring-boot:run 으로 서버를 구동시켜 보자. 아래와 같은 화면이 보인다면 성공.

자, 그러면 이제 각 서비스로 부터 실제 리퀘스트 데이터를 모아보기로 한다. 별도로 해 줄 것은 없고, helloworld-client 와 helloworld-service 의 두 모듈의 pom.xml 에 아래의 dependancy 를 추가한다.

<dependency>
   <groupId>org.springframework.cloud</groupId>
   <artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>

그리고 지난 포스팅에서와 마찬가지로 Config server, 유레카 서비스, 헬로 월드 서버, 헬로 월드 클라이언트, zipkin 서비스의 순서대로 서비스를 모두 구동한다. 구동이 완료되면, zuul 을 통해 서비스에 요청을 해 보도록 하자. 그리고 zipkin ui 로 진입하여 find 버튼을 누르면 아래와 같은 내용이 나타난다.

Zipkin 에서 보이는 데이터는 크게 두개인데, 하나는 전체 요청을 추적하는 trace 와, 다른 하나는 각각의 내부 서비스간 요청과 응답을 기록하는 span 의 두가지다. 이 데이터를 통해 위와 같이 각 리퀘스트의 처리에 걸리는 시간을 보여준다. 하나를 클릭해 보면 아래와 같은 세부 정보를 볼 수 있다.

이는 외부로 요청을 받은 시점부터 이 요청을 처리하기 위해 내부 서비스간 발생한 요청에 대한 처리 시간을 보여준다. 헬로 월드 클라이언트는 헬로월드 서비스로 요청을 포워딩 했고 여기에 각각이의 처리 시간이 나타난다. 그리고 이 전체 요청의 처리에는 7ms 가 걸렸음을 확인할 수 있다. 이런 방식으로 내부 서비스가 다수 존재한다면, 예를 들어 캐시 마이크로 서비스가 존재하는데 여기서 지연시간이 증가했다면 서비스가 느려진 이유는 캐시 미스가 증가한 것으로 생각할 수 있다. 또는 별도의 데이터베이스나 메세지 큐와 같은 서비스를 참조하는 마이크로 서비스가 있다면 여기에서 발생한 지연 역시 확인할 수 있다. 즉, 이 도구는 "왜" 를 설명하기 위한 것이다.

우측 상단의 JSON 을 살펴보면 친절하게 JSON으로 만들어진 이 요청에 대한 데이터를 확인할 수 있다.

그리고 서비스간 구조가 복잡하다면 아래의 그림과 같이 서로 어떻게 연관되어 있는지 그림도 그려 준다.

마지막으로 언급할 내용은, 이 데이터들은 무슨 데이터웨어 하우징 도구에 넣고 "우리 반년전 상태가 어땠지?" 하는 질문에 사용하는 도구가 아니다. 즉, 이 데이터는 길어야 하루나 이틀 정도를 두고 "현재 우리 서비스의 상태를 빠르게 참조할 수 있는" 도구로 사용하는 것이 올바르다. 필요하다면 pgsql 과 같은 데이터베이스를 사용하여 각 요청을 저장할 수도 있겠다. 본 데모에서는 메모리에 저장하는 옵션을 사용했다.

한가지더, 모든 요청을 기록할 필요가 없다. 위의 설정 내용을 보면 spring.sleuth.sampler.percentage=1.0 이런 설정이 있는데, 이는 데모를 위해서 전체 요청을 추적하는 것이다. 이럴 필요가 없이 적절한 수량의 요청을 샘플로 사용하여 서비스에 불필요한 부하를 주지 않도록 하자. 트위터의 경우에는 1/6,000,000 의 비율로 샘플링을 수행한다고 한다. 즉, 6백만 요청당 1개를 zipkin 에 넣고 보는 것이다.

서킷 브레이커 보다 zipkin 이 먼저 나왔다. 어쨌든 도움 되는 포스팅이기를.

(정윤진, younjin.jeong@gmail.com)

고가용 서비스 - Spring Cloud - #3 Smart microproxy - Zuul

Cerberos — Wed, 21 Sep 2016 07:30:01 +0900

(younjin.jeong@gmail.com, 정윤진)

로드 밸런서라는 것을 처음 접했던것은 리눅스의 LVS 였다. 1990년대 말엽 쯤이었던것 같은데 트래픽을 분산 처리할 수 있다는 개념에 매우 놀라워 했던 기억이다. 당시 리눅스 배포판에는 모두 How to 문서가 함께 배포 되었었는데 여기에 소개된 LVS 를 구현 하려면 깡통 머신이라도 몇대는 있어야 했기 때문에 침만 꿀떡 삼키곤 했다.

LVS - HA http://www.linuxvirtualserver.org/ (이 사이트가 아직 살아있다니)

후에 국내 대규모 호스팅 업체에서 연구원으로 이런 저런 서비스를 개발하면서 당시 이슈가 되던 DDoS 처리와 함께 네트워크 기반의 밸런서가 아닌 리눅스 박스 기반의 밸런서를 회사에서 고려하면서 직접 구현할 기회가 생겼더랬다. 지금은 매우매우 유명해져서 인천 국제공항 짐 찾는데서 광고도 하고 있는 모 인터넷 쇼핑몰이 그때 장사가 폭발하기 시작하면서 서버의 부하 분산 처리를 해야 했는데, 기존의 서버를 웹 애플리케이션 서버와 웹 서버로 나누고 Memcached 와 같은 도구의 사용과 PHP 의 프로파일링을 opcode 레벨로 수행하기도 하고 뭐 여러가지를 붙이면서 여기에 LVS도 들였던 기억이다. 왜냐면 지금 아마존도 그렇지만 호스팅은 원가 절감에 사업 생명이 달려있기 때문에...

어쨌든 로드 밸런싱이라는 것은 외부에서 들어오는 웹 또는 트래픽을 내부의 여러대의 서버로 분산해서 처리하는 것을 말한다. 지금은 믿기 힘들겠지만 예전에는 한대의 서버에서 웹 서버, 데이터베이스 이런것들을 다 구동시키던 시절도 있었... 그리고 로드 밸런서는 이 부하를 분산해 주는 역할을 하는 서버나 네트워크 장치 또는 소프트웨어 또는 어플라이언스를 말한다. 이런 기능이 제공하는 성능 향상은 그야말로 확장이 거의 불가능한 관계형 데이터베이스가 퍼질때까지 웹 서버를 늘릴 수 있는 장점이 있다. 게다가 로드 밸런서 뒷쪽에 있는 서버에 장애가 발생하거나 업데이트를 하는 경우에도 트래픽의 핸들링이 가능하기 때문에 서비스의 가용성이 더 높아지는 이유도 있다. 따라서 서비스에 유입되는 트래픽이 증가하는 특정 시점에는 반드시 로드 밸런서의 도입을 고려해야 하는 시점이 있었다. 물론 루프백 인터페이스의 수정과 같은 대규모 작업과 함께.

밸런서에 대해 조금 더 이야기 해 보자면, 이런 리눅스 박스 기반의 밸런서를 구성하는 것은 뭐 약간의 기술이 필요하기 때문에 이런 구성의 편의를 위해서 리눅스 박스를 벤더별로 커스터마이징 해서 아예 네트워크 장치 처럼 내어 놓는 '어플라이언스형' 밸런서들이 유행을 타기 시작했다. 물론 편의 뿐만 아니라 다양한 네트웍적인 기능, 그리고 편리한 웹 기반의 인터페이스, 그리고 일부 암호화 같은 기능들의 경우에는 순수 소프트웨어를 사용하는 대신 별도의 ASIC을 사용하기 때문에 더 높은 성능을 보이는 것들도 있었다. 처음에는 노텔이, L4 로 대표되는 스위치로 흥하다가 이후에는 F5 와 같은 벤더에서 강력한 L7 기능과 함께 컨텐츠 캐싱과 같은 복합적인 역할을 수행하는 제품을 내어 놓기도 했고, Citrix 와 같은 벤더에서는 WAN 구간의 데이터 전송에 더 적은 트래픽을 사용하는 압축 기술 등을 적용한 제품을 내어 놓기도 한 나름대로 흥망성쇠가 있는 레이어였다.

여담이긴 하지만 이런 로드 밸런서를 본격적으로 사용하기 전에는 RRDNS 라고 해서 동일한 네임서버의 레코드에 여러개의 서버 주소를 넣어서 요청하는 클라이언트 별로 순차적으로 응답을 주는 방식을 사용하기도 했었다. 이 DNS 작업을 서버의 IP 주소 레벨로 처리 했을때를 상상해 보면 어떨까 생각해 보길 바란다. 그래서 사람들은 서버들은 로드 밸런서에 연결하고 로드 밸런서에도 부하가 생기기 시작하면 여러개의 로드 밸런서를 마련하여 이 로드 밸런서의 주소를 DNS 에 등록하는 방식을 사용하게 된다. 그리고 여기에 발전하여 DNS 가 점점 똑똑해 지면서 클라이언트의 IP가 어느 지역에 위치한지를 GeoIP 와 같은 데이터베이스를 통해 알아내서 그 지역에 가까운 로드 밸런서의 주소를 할당해 주는 형태로 발전하게 된다. 이게 RRDNS 부터 GSLB 라고 불리는 방식으로의 발전이다.

아무튼 이런 전통적인 방식의 로드 밸런서들은 끊임없이 발전했는데, 그중 한 부분이 바로 고가용성 부분이다. 약 7년전 까지만 하더라도 로드 밸런서를 Active-active 로 (즉 두대 다 동시에 사용가능하게) 하는 구성은 돈도 비싸고 네트웍적으로도 골치 아픈 것이었다. 두대의 어플라이언스 기반 로드 밸런서를 고가용성으로 구성하려면 거의 대부분 가능한 옵션은 Active-Standby(두대중 한대만 가용) 였고, 이 구성 마저도 로드밸런서간 세션 공유를 위한 네트웍 회선 이중화 구성, 로드 밸런서가 연결되는 라우팅 구간과의 Port trunking 을 연계한 HSRP 또는 VRRP 구성, 그리고 내부의 네트워크 장비와의 고가용성 연결 등 이게 그렇게 단순한 이야기가 아니었던 거다. 더 중요한 것은, 서비스를 운영하는 관점에서 보면 네트워크는 네트워크 장치끼리 따로 움직이는 것이 아니다. 이는 각 역할을 하는 서버와 연결되며, 각 서버는 또 기본적으로 Bonding / Teaming 이라고 불리는 이중화 기술을 사용하고 만약 윈도우를 사용한다면 클러스터링 여부에 따라 AD 구성이 필요하게 된다. 그리고 만약 데이터베이스 클러스터를 SAN 기반으로 구성했다면 역시 데이터베이스의 tablespace 위치 설정과 SAN의 Zoning 작업, HBA 설정등 모든게 거대한 하나의 세트가 된다. 이런 클러스터링의 정상 동작은 상단의 밸런서 구간, 그리고 서버와 서버의 연결 구간이 일목 요연하게 동작해야 비로소 아름답게 (라고 쓰고 비싼 돈 들여서 정상적으로 동작하는거 구경이라고 읽는..) 동작한다.

F5 Networks LTM - 한때는 매우 아름다운 고성능의 어플라이언스 전원을 넣으면 오른쪽 다마에 불이 켜져요

암튼 사설이 너무 길었는데, 로드 밸런서가 active-active 의 고가용성으로 구동되기 힘들었던 이유중 가장 큰 것은 바로 '세션 클러스터링' 이라는 기능때문이었다. 보통 Sticky bit 또는 persistence 라고 불리는 밸런서의 기능은 현재 어느 클라이언트가 내부의 어느 서버와 연결되었는지에 대한 연결 정보를 기억한다. 이건 개발자들에게 웹 애플리케이션에서 세션을 서버 로컬에 저장해도 되는 편리함을 제공했다. 그래서 역설적으로 이 기능이 없는 밸런서를 사용하면 웹 서비스가 정상동작 하지 않기도 하는 경우가 있었다.

그래도 역시 이런 고가의 어플라이언스는 별로야 라고 생각했던 사람들은 리버스 프락시라는 도구에 주목한다. 세션 클러스터링 따위 REST로! 라고 사람들이 생각하기 시작하면서, 그리고 클라우드가 대두되면서 리버스 프락시는 널리 사용되기 시작한다. 이 블로그에 NginX 를 처음 소개했던게 2009년이란다. 세월 참 빠르다. 아무튼 Nginx, HAProxy, Varnish 와 같은 리버스 프락시들은 단순히 로드 밸런싱 뿐만 아니라 HTTP 헤더의 조작, uri 기반으로 내부의 서버를 선택해서 포워딩 할 수 있는 등의 참으로 아름다운 기능들을 제공하기 시작한다. 특히 나는 Nginx 를 매우 사랑했는데, 모듈을 통한 손쉬운 기능확장, 이를 테면 memcached 를 붙여 시원한 캐시를 할당한다던가 SSL 엔드포인트로 사용한다던가 CPU affinity 설정과 같은 매니악한 기능들, 그리고 uri 라우팅을 통한 인증서버, 파일(이미지) 서버, 그리고 웹 애플리케이션 서버를 내맘대로 밸런싱하는 재미가 있었기 때문이다.

어쨌든, 세션 클러스터링 따위가 별게 아닌게 되기 시작하면서 밸런서는 소프트웨어로 손쉽게 확장할 수 있는 도구가 되었고 이런 기능성은 클라우드 위에서 매우 매력적인 도구가 되었다. 그런데, 클라우드 서비스는 대부분 밸런서를 기본으로 제공하고 (처음부터 기본은 아니었지만) 있다. 아마존의 ELB(Elastic Load Balancer)만 해도 처음에는 그냥 밸런싱만 하는 깡통이더니, sticky 지원을 시작해서 connection drain 등 점점 예전 상용 밸런서와 같은 기능을 제공하고 있다.

옛날 이야기는 이쯤 하기로 하고, 이런 부하를 분산하는 기능을 했던 밸런서는 ELB 로 충분한데 클라우드 기반의 서비스가 발전하면서 더 많은, 즉 더 똘똘한 "무엇"이 필요하게 된다. "무엇"을 대충 정리하면 아래와 같다.

- 단순이 네트워크적 라우팅 또는 L7 '지원' 수준의 분배가 아닌, 실제 애플리케이션 레벨에서의 백엔드 애플리케이션 연결

- 동적인 라우팅, 즉 설정따위 변경 없이 리소스의 생성과 삭제에 따른 라우팅 즉각 반영

- 모니터링

- 빠른 복구, 그리고 보안성

- 추가 기능, 예를 들면 아마존 웹 서비스에 위치한 다수의 오토 스케일링 그룹으로의 리퀘스트 라우팅

예를 들면 샤드로 구성된 데이터베이스들에 요청을 분배해야 하는 경우를 생각해 볼 수 있다. 이러한 요구사항을 서비스를 지속적으로 개선함에 따라 발견했던 넷플릭스는, 처음에는 외부의 상용 서비스를 사용하다가 결국 Zuul 이라는 새로운 도구를 만들어 내었다.

Zuul, the Gatekeeper from Ghostbusters movie - http://villains.wikia.com/wiki/Zuul

이름이 의미하는 바와 같이 이는 서비스의 대문을 지키는 수장의 역할을 한다. 이 Zuul 이 제공하는 기능을 정리해 보면 다음과 같다.

- 인증 및 보안 : 각 요청이 갖추어야 할 내용을 충족하지 못한 경우 해당 요청을 거부한다.

- 모니터링 : 모든 트래픽이 지나기 때문에 의미있는 데이터와 지표를 수집할 수 있다.

- 동적 라우팅 : 필요에 따라 즉시 원하는 백엔드 클러스터로 트래픽을 보내고 끊을 수 있다.

- 부하 테스트 : 신규 추가한 서비스 또는 백엔드에 트래픽을 점진적으로 증가하는 등의 방식으로 부하를 유발할 수 있다.

- 트래픽 드랍(정확히는 Shedding) : 각 요청에 대해 제한된 이상의 요청이 발생한 경우 이를 드랍하는 방식을 사용할 수 있다.

- 정적 응답 처리 : 특정 요청에 대해서는 백엔드로 트래픽을 보내는 대신 즉시 응답하도록 구성할 수 있다.

- 멀티 리전 고가용성 : Zuul 은 받은 요청을 아마존 웹 서비스의 리전 레벨에서 분배할 수 있다.

그리고 이와 같은 사용성을 기반으로 넷플릭스가 추가적으로 할 수 있는 일은

- Test : 넷플릭스 규모의 마이크로 서비스 구성에서는 어떤 테스트는 반드시 프로덕션을 통해서만 가능한 경우가 발생한다. 이때 신규 서비스를 배포하고, 전체 트래픽 중 아주 일부의 트래픽만 이 테스트로 흘려 테스트를 수행하고 있다. 또는 이 개념을 조금 더 확장해서 Canary 테스트로 사용할 수도 있다. 배포 전 신규 버전의 서비스를 준비하고, 이 신버전으로 구버전을 대체하기 전에 동일한 요청에 대해 아주 작은 양의 트래픽만 신버전으로 흘린다. 로그를 모니터링 하고, 테스트를 통과하여 서비스에 문제가 없다는 것이 확인되면 트래픽의 비율을 조정한다. 자연스럽게 구버전으로 흐르는 트래픽은 감소하고 신버전은 증가하며, 구버전에 더 이상의 트래픽이 처리되지 않으면 모두 terminate 한다.

https://github.com/Netflix/zuul/wiki/How-We-Use-Zuul-At-Netflix

이 외에도 SpringOne platform 에서 넷플릭스의 Zuul 담당 헤드가 다양한 내용을 소개해 주었다. 넷플릭스는 Zuul 을 사용하여 50개 이상의 ELB 로 트래픽을 분배하고, 3개의 아마존 웹 서비스 리전을 사용하고 있으며, 넷플릭스 서비스의 대부분의 트래픽을 처리하고 있다고 했다. 그리고 이 도구를 Edge-gateway 라고 부르고 있다. 혹시 infoq.com 계정이 있으신 분들은 Netflix 의 Zuul 매니저의 발표를 감상하실 수 있겠다. (https://www.infoq.com/presentations/netflix-gateway-zuul?utm_source=infoq&utm_medium=QCon_EarlyAccessVideos&utm_campaign=SpringOnePlatform2016)

넷플릭스가 공개하고 있는 Zuul 에 대한 정보는 아래의 링크에서 더 찾아 볼 수 있겠다.

https://github.com/Netflix/zuul/wiki

https://github.com/Netflix/zuul/wiki/How-We-Use-Zuul-At-Netflix

이쯤 되면 나오는 이번 시리즈 단골 멘트. 스프링 클라우드에서는 이 마이크로 프락시를 사용하기 쉽게 제공하고 있다. 게다가 이전에 1, 2 시리즈를 통해 이미 소개한 유레카와 config 서버를 연계하여 사용하는 것이 가능하다. 백문이 불여일견, 백견이 불여일행. 우리의 사랑 START.SPRING.IO 로 접근하여 마이크로 서비스 구조를 만들어 보기로 한다. 다이어그램은 아래와 같다.

~~오늘도 즐거운 발그림~~

Zuul proxy 의 동작만을 확인하는 간단한 코드는 spring cloud 프로젝트에서도 참조할 수 있으며, 블로그의 내용은 아래의 github 링크를 참조하면 되겠다. 간단한 데모이므로 별도의 암호화 처리등은 없다. 본 데모에서 가장 중요한 것은 온라인 설정의 업데이트, 유레카를 참조한 로드 밸런싱의 처리이다.

https://github.com/younjinjeong/demo-config

https://github.com/younjinjeong/spring-cloud-zuul-proxy-demo

Config server 구성

- github.com 에 가서 신규 repository 를 만든다. (위의 demo-config 참조)

- 애플리케이션의 properties 파일을 생성한다. : application.properties / helloworld-service.properties / helloworld-client.properties / discovery-service.properties https://github.com/younjinjeong/demo-config 참조

- bootstrap.properties 파일에 spring.cloud.config.uri 주소를 조정한다.

- Config server 를 시작한다.

Discovery-service

- start.spring.io 에 접근한다.

- artifact 에 discovery-service

- dependencies 에 eureka server, config client 를 추가하고 프로젝트를 다운 받는다.

- 설정은 demo-config 의 discovery-service 를 참조

Helloworld-service

- http://start.spring.io 로 접근한다.

- artifact 에 helloworld-service 대신 더 상상력 넘치는 이름을 준다.

- dependancies 에 web, rest repositories, actuator, actuator docs, config client, eureka discovery 를 적용한다.

- Generate project 를 눌러 프로젝트 파일을 다운로드 받고, IDE 를 사용해서 연다. 아래와 같이 간단한 코드를 작성 한다.

package com.example;

import org.springframework.boot.SpringApplication;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.context.config.annotation.RefreshScope;
import org.springframework.cloud.netflix.eureka.EnableEurekaClient;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@SpringBootApplication
@EnableEurekaClient
public class HelloworldServiceApplication {

   public static void main(String[] args) {
      SpringApplication.run(HelloworldServiceApplication.class, args);
   }
}

@RefreshScope
@RestController
class MessageRestController {

   @Value("${message}")
   private String message;

   @Value("${eureka.instance.metadataMap.instanceId}")
   private String instanceId;

   @RequestMapping("/")
   String message() {
      return this.message;
   }

   @RequestMapping("/id")
   String instanceId() { return this.instanceId; }
}

Hellowworld-client : 실제 Zuul proxy 가 동작하는 구간이다. 보통 edge-service 라는 이름을 사용하기도 한다.

- http://start.spring.io 로 접근한다.

- artifact 에 helloworld-client 대신 더 상상력 넘치는 이름을 준다.

- dependancies 에 Zuul, Config client, Discovery client, Ribbon 를 적용한다.

- Generate project 를 눌러 프로젝트 파일을 다운로드 받고, IDE 를 사용해서 연다.

Zuul Proxy 를 사용하기 위해서는 기본적으로는 어노테이션 추가외에 아무것도 할 일이 없다.

package com.example;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.EnableEurekaClient;
import org.springframework.cloud.netflix.zuul.EnableZuulProxy;

@SpringBootApplication
@EnableEurekaClient
@EnableZuulProxy
public class HelloworldClientApplication {

   public static void main(String[] args) {
      SpringApplication.run(HelloworldClientApplication.class, args);
   }
}

당연한 말이지만 라우팅 설정이 필요하다. 설정에 대한 내용은 demo-config 저장소의 helloworld-client.properties 을 살펴볼 필요가 있다. 아래의 설정을 살펴 보자.

server.port=${PORT:9999}
info.component="Zuul Proxy"

endpoints.restart.enabled=true
endpoints.shutdown.enabled=true
endpoints.health.sensitive=false

zuul.ignored-services='*'
zuul.ignoredPatterns=/**/api/**

#route 규칙은 zuul.routes.스프링애플리케이션이름=path
zuul.routes.helloworld-service=/hello/**
zuul.routes.discovery-service=/eureka/**

ribbon.ConnectTimeout=3000
ribbon.ReadTimeout=60000

정리해 보면,

- helloworld-service 는 백엔드 서비스로 동작한다. 두개의 RequestMap을 가지는데, 하나는 "/" 요청에 대해 설정 파일에 주어진 메세지를 응답하는 것이고, 다른 하나는 /id 로 현재 동작중인 인스턴스의 정보를 서버의 정보를 리턴한다. 즉, 동일한 애플리케이션을 로컬에서 서로 다른 포트로 동작하거나, 실제 클라우드에 배포하여 로드 밸런싱이 정상적으로 수행되는지 확인 할 수 있다.

- helloworld-client 는 edge 서비스로서 zuul proxy 를 사용하고, 유레카를 통해 얻어진 백엔드 서버 정보를 기반으로 ribbon 을 사용하여 로드 밸런싱 한다.

- 라우팅 규칙은 "zuul.routes.[유레카를통해 얻어진 spring.application.name]=경로" 로 구성된다.

- 당연하지만 위에 설명한 기능을 제공하기 위한 더 많은 설정이 존재한다.

Config Server, Discovery service, helloworld-service, helloworld-client 의 순서대로 애플리케이션을 구동한다. localhost:8000/ 으로 요청하여 서비스가 정상 동작 하는지 확인한다. 정상적이라면 Hello world! 를 볼 수 있다.

$ curl http://localhost:8000/
Hello World!

먼저 서비스의 재시작 없이 설정을 변경하는 방법을 위의 메세지 처리를 통해 확인해 보자. demo-config/helloworld-service 에서 message 설정을 원하는 메세지로 변경한다. 변경했으면, 연결된 커밋, 푸시한다. 설정이 정상적으로 반영되었다면, Config 서버에서는 변경된 최신의 설정을 바로 참조하고 있으나 서비스에는 반영이 안된것을 확인할 수 있다. 아래의 주소로 접근하면 message 의 내용이 변경되었고 이를 config server 가 들고 있는것을 확인할 수 있다.

http://localhost:8888/helloworld-service/default

{

name: "https://github.com/younjinjeong/demo-config/helloworld-service.properties",
source:
{
- server.port: "${PORT:8000}",
- message: "Spring Cloud is awesome! "
}

서비스에 바로 반영되지 않는 것은 원래 그렇게 디자인 했기 때문이다. 설정이 변경될 때마다 자동으로 서비스에 반영하는 것은 위험할 수도 있으며, config server 에 부담을 주지 않기 위한 것도 있다. 서비스에 변경을 적용하려면, 지난번에 설명한 바와 같이 empty post 요청을 다음과 같이 전달하면 된다.

$ curl -X POST http://localhost:8000/refresh
["message"]

정상적으로 동작했다면, 어떤 내용이 변경되어 반영됬는지 리턴될 것이다. 그럼 이제 백엔드 서비스로 다시 직접 요청해 보도록 하자.

$ curl http://localhost:8000/
Spring Cloud is awesome!

이 동작이 의미하는 바는 무엇인가. 설정을 변경하고 프로세스 재시작, 재배포 이런 과정을 별도로 수행하지 않아도 변경된 설정이 동작중인 서비스에 즉각 반영할 수 있는 메커니즘이 있다는 것이다. 이러한 방법은 Config server / client 를 통해 동작하며 이는 당연하게도 Zuul proxy 의 라우팅 변경에도 사용할 수 있는 것이다. 즉, 신규 애플리케이션을 만들어 동작하고 있는 중이라면, 해당 애플리케이션으로의 트래픽을 서비스 재시작 없이 변경하거나 추가할 수 있다는 의미가 된다.

이제 로드 밸런싱을 살펴보자. 포트 8000에서 동작하고 있는 서비스는 백엔드다. 그리고 Zuul 은 9999 포트에서 동작중이다. 그리고 오늘의 주제와 마찬가지로 Zuul 이 정상적으로 프락싱을 수행하고 있는지 확인해 보도록 하자. 위의 라우팅 규칙에 따르면, Zuul proxy 서버의 /hello 로 요청을 하게 되면 위의 메세지가 리턴 되어야 한다.

$ curl http://localhost:9999/hello
Spring Cloud is awesome!

사실 helloworld-client 애플리케이션에 보면 뭐 한것도 없다. 그럼에도 불구하고 프락싱은 정상적으로 동작하고 있는 것이다. 이제 밸런싱을 확인해야 하는데, 위의 메세지는 설정 서버로 부터 동일하게 가져와 반영되는 것이므로 밸런싱이 정상적으로 동작하는지 확인하기가 쉽지 않다. 따라서 동일한 백엔드 서비스를 다른 포트로 동작하게 하고 실제 밸런싱이 되는지 확인해 보자. 아래의 커맨드를 사용하면 동일한 애플리케이션을 다른 포트로 구동할 수 있다.

# helloworld-service 디렉토리로 이동하여 먼저 빌드를 수행한다 
PORT=8989 java -jar target/helloworld-service-0.0.1-SNAPSHOT.jar

유레카 서비스를 확인해 보면 새로 구동한 백엔드 서비스가 HELLOWORLD-SERVICE 애플리케이션으로 2개의 인스턴스에서 동작하고 있는 것을 확인할 수 있다.

localhost:9999/hello/id 로 요청을 수행하면 서비스 이름:포트 정보가 나타나는데, 반복적으로 요청을 수행하면 8000 포트와 8989 포트가 번갈아 가며 나타난다. 즉, 정상적으로 로드 밸런싱이 수행되고 있는 것이다. 다시 8989로 동작중인 애플리케이션을 종료하게 되면 이는 즉시 밸런싱에서 제외되고 8000번만 나타난다. 이것은 무엇을 의미하는가. 바로 동적으로 멤버의 추가와 제거가 발생하고, 이 정보가 즉각 참조되어 서비스-인, 서비스-아웃을 수행할 수 있다는 것이다.

이러한 사용성은 필요에 따라서 전세계에 위치한 데이터센터 중 내가 원하는 지역의 어디로든 트래픽을 동적으로 분산할 수 있는 유연성을 제공한다. 그리고 이런 동작은 그 어떤 프로세스의 재시작도 없이, 그 어떤 애플리케이션의 재배포도 없이 가능하다. 이런 구성이 바로 클라우드에서 동적으로 생성되고 삭제되는 각종 서비스와 그 서비스에 할당된 애플리케이션 인스턴스를 서비스에 사용하고 제거하는 "클라우드에 맞는" 방법인 것이다.

금번 포스팅에서는 자세히 소개하지는 않겠지만, 이 Zuul 을 사용하여 필터를 적용할 수 있다. 필터는 클라이언트의 HTTP 요청을 받고 응답하는 과정에서 리퀘스트를 라우팅 하는 동안 어떤 액션을 수행할지에 대한 범위를 지정하는 역할을 한다. 아래는 아래는 몇가지 Zuul 의 필터에 대한 특징이다.

- Type: 리퀘스트/리스폰스 라우팅 되는 동안 필터 적용 상태의 변경을 정의함

- Execution order: Type 안에 적용되는, 여러개의 필터 적용 순서를 정의

- Criteria: 순서대로 실행될 필터에 필요한 조건들

- Action: Criteria, 즉 조건이 매칭하는 경우 수행할 액션

필터에는 아래의 타입들이 존재한다.

- PRE: 백엔드 서버로 라우팅 되기 전에 수행되는 필터. 예를 들어 요청에 대한 인증, 백엔드 서버의 선택, 로깅과 디버깅 정보

- ROUTING: 요청을 백엔드로 라우팅을 제어할때 사용되는 필터. 이 필터를 통해 Apache HttpClient 또는 넷플릭스 Ribbon 을 사용하여 백엔드 서버로 요청을 라우팅 (본 블로그의 예제에서는 Ribbon 을 사용중)

- POST: 백엔드 서버로 요청이 라우팅 되고 난 후에 수행되는 필터. 예를 들면 클라이언트로 보낼 응답에 스텐다드 HTTP 헤더를 추가한다던가, 각종 지표나 메트릭을 수집하거나 백엔드에서 클라이언트로 응답을 스트리밍 하는 것등.

- ERROR: 위의 세 단계중 하나에서 에러가 발생하면 실행되는 필터

Zuul 은 사용자에게 커스텀 필터 타입을 정의하고 사용할 수 있도록 한다. 따라서 특정 요청을 백엔드로 보내지 않고 바로 클라이언트에 응답을 수행하는것과 같은 구성이 가능하다. 넷플릭스에서는 이런 기능을 내부의 엔드포인트를 사용하여 Zuul 인스턴스의 디버그 데이터 수집에 사용하고 있다고 한다. 아래는 Zuul 내부에서의 요청이 어떤 흐름을 가지는지 보여주는 좋은 그림이다.

https://github.com/Netflix/zuul/wiki/How-it-Works

스프링에서 Zuul 필터의 사용은 아래의 두 코드를 살펴 보자.

먼저 com.netflix.zuul.ZuulFilter 를 익스텐드 해서 pre 필터를 생성한다. helloworld-client 애플리케이션에 아래의 파일을 추가한다.

spring-cloud-zuul-proxy-demo/helloworld-client/src/main/java/com/example/filters/pre/SimpleFilter.java

package com.example.filters.pre;

import com.netflix.zuul.ZuulFilter;
import com.netflix.zuul.context.RequestContext;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import javax.servlet.http.HttpServletRequest;

public class SimpleFilter extends ZuulFilter {

    private static Logger log = LoggerFactory.getLogger(SimpleFilter.class);

    @Override
    public String filterType() {
        return "pre";
    }

    @Override
    public int filterOrder() {
        return 1;
    }

    @Override
    public boolean shouldFilter() {
        return true;
    }

    @Override
    public Object run() {
        RequestContext ctx = RequestContext.getCurrentContext();
        HttpServletRequest request = ctx.getRequest();

        log.info(String.format("%s request to %s", request.getMethod(), request.getRequestURL().toString()));

        return null;
    }

}

- filterType() 은 필터의 타입을 String 으로 리턴한다. 이 경우 pre 이며, 만약 route 에 적용했다면 route 가 리턴된다.

- filterOroder() 는 필터가 적용될 순서를 지정하는데 사용된다.

- shouldFilter() 이 필터가 실행될 조건을 지정한다. 위의 설명에서 Criteria 부분

- run() 필터가 할 일을 지정한다.

spring-cloud-zuul-proxy-demo/helloworld-client/src/main/java/com/example/HelloworldClientApplication.java

package com.example;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.EnableEurekaClient;
import org.springframework.cloud.netflix.zuul.EnableZuulProxy;
import org.springframework.context.annotation.Bean;
import com.example.filters.pre.SimpleFilter;

@SpringBootApplication
@EnableEurekaClient
@EnableZuulProxy
public class HelloworldClientApplication {

   public static void main(String[] args) {
      SpringApplication.run(HelloworldClientApplication.class, args);
   }

   @Bean
   public SimpleFilter simpleFilter() {
      return new SimpleFilter();
   }
}

curl http://localhost:9999/hello/id 로 요청을 해 보면, 아래와 같은 로그를 확인할 수 있다.

2016-09-22 17:58:33.798  INFO 7307 --- [nio-9999-exec-6] com.example.filters.pre.SimpleFilter     : GET request to http://localhost:9999/hello/id

지금까지 소개한 3개의 도구, Config Server, Eureka, Zuul 의 세개는 모두 스프링 클라우드의 도구다. 스프링 클라우드에서는 클라우드에 맞는 서비스 연동을 제공하기 위해 이러한 넷플릭스 오픈소스들을 넷플릭스와 함께 만들고 있다. 이것은 시작일 뿐이며, 이 다음 번에는 서비스에 장애가 발생했을때 GET 요청을 처리할 수 있는 기법을 제공하는 Circuit breaker (Netflix Hystrix) 와 POST 메세지에 대해 고가용성의 방법으로 처리할 수 있는 방법에 대해 적어보도록 하겠다.

이 Zuul 의 구조에 대해 더욱더 궁금하신 분들은 아래의 넷플릭스 블로그를 참조하시면 되겠다.

http://techblog.netflix.com/2013/06/announcing-zuul-edge-service-in-cloud.html

추가로 Zuul 에 대해 더 관심이 있으신 분들 중 비밀 댓글로 이메일 주소를 적어주시는 5분께 금번 SpringOne Platform 에서 발표된 넷플릭스의 Zuul 사용에 대한 영상을 공유 할 수 있도록 하겠다. 유료 행사라 아직 전체 공개는 하지 않는 듯. (만약 공유가 잘 안되더라도 용서를.)

https://www.infoq.com/presentations/netflix-gateway-zuul?utm_source=infoq&utm_medium=QCon_EarlyAccessVideos&utm_campaign=SpringOnePlatform2016

(정윤진, younjin.jeong@gmail.com)