블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

Google 앱앤진에 node.js 애플리케이션을 배포하기


조대협 (http://bcho.tistory.com)

PaaS 서비스란?

PaaS란 Platform as a service의 약자로, 간단하게 설명하면, Linux VM등에 직접 node.js나 기반 환경을 설치하고 디스크와 네트워크 구성, 오토스케일링등의 구성이 필요 없이, 개발자가 작성한 코드만 올려주면, 이 모든 것을 클라우드에서 대행해주는 서비스의 형태이다.

인프라 운영을 위한 별도의 작업이 필요하지 않기 때문에, 숫자가 적은 기업이나 개발에만 집중하고 싶은 기업에는 적절한 모델이라고 볼 수 있다.

근래에 스타트업 비지니스가 발달하고 또한 사용하는 기술 스택들이 복잡해짐에 따라 각각의 기술 스택에 대한 설치나 운영에 대한 인력을 두기보다는 PaaS와 같은 매니지드 서비스를 이용해서 애플리케이션을 개발하는  방식이 스타트업을 중심으로 많이 이루어지고 있다.

구글 클라우드 소개

구글 클라우드는 전세계에 걸쳐 유투브와 구글 검색, 이메일등의 서비스를 하는 구글의 인프라의 경험을 구글 외부의 개발자들에게 개방하기 위해서 개발된 클라우드 서비스이다.

글로벌을 대상으로 서비스를 하던 경험을 기반으로 글로벌 그리고 대용량 서비스에 적절한 특징들을 많이 가지고 있는데, 그 중에서 눈여겨 볼만한것이 네트워크와 빅데이타 서비스이다.

네트워크

구글은 자체 서비스를 위해서 전세계에 걸쳐서 많은 네트워크 망을 가지고 있다. 특히 전세계에 걸쳐 70개 이상의 Pop (Point of Presence)라는 서버들을 보유하고 있는데, 구글 클라우드에서 동작하는 애플리케이션은 클라이언트가 직접 그 데이타 센터의 서버로 인터넷을 통해서 접속하는 것이 아니라, 먼저 가장 가까운 Pop 서버로 연결이 된 후, Pop 서버와 구글 클라우드 데이타 센터간은 구글의 전용 광케이블을 이용해서 접속이 되기 때문에 빠른 네트워크 성능을 보장한다.

예를 들어 한국에서 미국의 서버를 접속하게 되면 일반 인터넷망을 타는 것이 아니라, 가까운 일본에 있는 구글 Pop 서버를 접속한 후에, 구글 광케이블망을 통해서 미국 데이타 센터에 접속하게 된다. 얼마전 7월에 일본-미국을 연결하는 20TB의 구글 클라우드 전용망이 오픈되었기 때문에, 훨씬 더 빠른 접속 속도를 보장받을 수 있다.

이런 특징 때문에, 구글 클라우드를 사용할 경우 여러 국가에 서비스를 제공하는 글로벌 서비스의 경우 이러한 망 가속의 잇점을 볼 수 있다.


또한 내부 네트워크 역시, 1 CPU당 2 GB의 대역폭을 제공한다. (실제 테스트해보면 1.6~1.8 GB정도가 나온다) 최대 8 CPU에 16 GB의 대역폭 까지 지원하기 때문에, 내부 노드간 연산이 많거나 또는 노드간 통신이 많은 클러스터링 솔루션을 사용할때 별도의 비용을 지불하지 않고도 넉넉한 네트워크 대역폭 사용이 가능하다.

빅데이타

구글은 사람들에게 알려진바와 같이 데이타를 기반으로 한 서비스에 강하며 특히 빅데이타를 처리하는 능력이 뛰어난 회사이다. 이러한 빅데이타 처리 기술이 클라우드 서비스로 제공되는데, 알파고와 같은 예측 통계학적인 머신러닝이나 딥러닝 이외에도, 분석 통계학적인 데이타 분석 서비스가 많은데 그중에서 특출난 서비스들로 Pub/Sub, Dataflow, BigQuery 등이 있다.

Pub/Sub은 전달 보장이 가능한 대용량 큐 시스템이다. 오픈소스 Kafka와 같은 서비스라고 보면 되고, 이러한 분산큐를 직접 깔아서 운영하기 어려운 사람들에게 쉽게 대용량 큐 서비스를 제공한다.

Dataflow는 스트리밍 및 배치 분석 시스템인데, Spark Streaming이나 Apache Flink와 같은 스트리밍 프레임웍과 유사하다고 보면된다. 윈도우,트리거,워터마크와 같은 스트리밍 서비스에서 발전된 개념을 이미 내장하고 있다.

마지막으로 BigQuery는 대용량 데이타 저장/분석 시스템으로 SQL과 같은 문법으로 데이타 분석이 가능하며, 데이타 저장 비용은 구글에서도 가장 싸다는 데이타 저장소인 CloudStorage 보다 저렴하며, 1000억개, 4TB의 레코드에 대해서 like 검색을 하는데 소요되는 시간이 불과 30여초로, 빠른 성능을 보장한다. (이 30초 동안에 CPU가 수천개, DISK역시 수천개가 사용된다.)


구글 클라우드 앱앤진

오늘 살펴볼 서비스는 구글 클라우드 중에서도 앱앤진이라는 PaaS 서비스이다. 구글은 처음 클라우드 서비스를 시작할때 PaaS 기반의 서비스를 제공하였고, 내부적으로도 PaaS 서비스를 오랫동안 제공해온 만큼, 진보된 형태의 PaaS 플랫폼을 가지고 있다.

그중에서 이번에는 새롭게 앱앤진 Flex environment 라는 새로운 서비스를 소개 하였다.

Flex environment에는 기존의 Java,PHP뿐 아니라, 요즘 스타트업등에서 많이 사용되는 Python, Ruby on rails 그리고 node.js를 지원한다.

그리고 재미있는 점 중의 하나는 일반적인 PaaS가 VM에 대한 로그인 (telnet 이나 SSH)를 지원하지 않는데 반하여, Flex environment 는 SSH 로그인을 제공함으로써, 고급 사용자들에게 많은 기능과 디버깅에 있어서 편의성을 제공한다.

계정 가입

자아 그러면 이제, 구글 앱앤진 Flex environment를 이용하여, node.js 애플리케이션을 배포해보도록 하자.

먼저 GCP 클라우드를 사용하기 위해서는 구글 계정에 가입한다. 기존에 gmail 계정이 있으면 gmail 계정을 사용하면 된다. http://www.google.com/cloud 로 가서, 좌측 상당에 Try it Free 버튼을 눌러서 구글 클라우드에 가입한다.




다음 콘솔에서 상단의 Google Cloud Platform 을 누르면 좌측에 메뉴가 나타나는데, 메뉴 중에서 “결제" 메뉴를 선택한후 결제 계정 추가를 통해서 개인 신용 카드 정보를 등록한다.


개인 신용 카드 정보를 등록해야 모든 서비스를 제한 없이 사용할 수 있다.  단 Trial의 경우 자동으로 한달간 300$의 비용을 사용할 수 있는 크레딧이 자동으로 등록되니, 이 범위를 넘지 않으면 자동으로 결제가 되는 일이 없으니 크게 걱정할 필요는 없다. (사용자가 Plan을 올려야 실제 카드에서 결재가 된다. 그전에는 사용자의 카드에서 결재가 되지 않으니 걱정하지 마시기를)


프로젝트 생성

계정 생성 및 결제 계정 세팅이 끝났으면 프로젝트를 생성한다.

프로젝트는 VM이나 네트워크 자원, SQL등 클라우드 내의 자원을 묶어서 관리하는 하나의 집합이다. 여러 사람이 하나의 클라우드를 사용할때 이렇게 프로젝트를 별도로 만들어서 별도로 과금을 하거나 각 시스템이나 팀별로 프로젝트를 나눠서 정의하면 관리하기가 용이하다.


화면 우측 상단에서 프로젝트 생성 메뉴를  선택하여 프로젝트를 생성한다.



프로젝트 생성 버튼을 누르면 아래와 같이 프로젝트 명을 입력 받는 창이 나온다. 여기에 프로젝트명을 넣으면 된다.


node.js 애플리케이션 준비

클라우드 프로젝트가 준비되었으면, 이제 구글 클라우드에 배포할 node.js 애플리케이션을 준비해보자.

Node.js 애플리케이션은 Express 프레임웍을 이용한 간단한 웹 애플리케이션을 작성해서 배포하도록 한다.

기본적으로 nodejs와 npm이 설치되어 있다고 가정한다. 이 글에서는 node.js 4.4.4 버전과 npm 2.15.1 버전을 기준으로 작성하였다.

Express generator 설치

Express 프로젝트는 Express 프로젝트 고유의 디렉토리 구조와 의존되는 파일들을 가지고 있다. 그래서 프로젝트를 생성하려면 Express generator가 필요하다. Express generator가 Express 프로젝트에 맞는 프로젝트 구조를 생성해주는데, Express generator를 설치하려면 아래 그림과 같이

% npm install express-generator -g

명령을 사용하면 설치가 된다.



프로젝트 생성

Express generator 설치가 끝났으면 이제, express 프로젝트를 생성해보자.

다음 명령어를 이용하여 helloappengine이라는 Express 프로젝트를 생성한다.

% express --session --ejs --css stylus helloappengine




Express 프로젝트 및 Express 프레임웍에 대해서는 http://bcho.tistory.com/887 http://bcho.tistory.com/888 글을 참고하기 바란다.

코드 수정

생성된 코드에서  ~/routes/index.js 파일을 다음과 같이 수정한다.


var express = require('express');

var router = express.Router();


/* GET home page. */

router.get('/', function(req, res, next) {

 res.render('index', { title: 'Hello Appengine' });

 console.log('Hello Appengine');

});


module.exports = router;


의존성 모듈 설치와 node.js 런타임 버전 정의

Express 애플리케이션 개발이 다 끝났다. Express 애플리케이션을 실행하려면, Express 프로젝트에 필요한 모듈들을 설치해야 하는데, 의존 모듈들은 ~/package.json에 이미 자동으로 생성되어 있다.

이 파일을 다음과 같이 수정한다.

“engines”라는 항목에 node.js의 버전을 아래와 같이 명기하는데, 이는 구글 앱앤진이 이 애플리케이션을 수행할때 어느 버전의 node.js를 가지고 수행을 할지를 지정한다.


{

 "name": "helloappengine",

 "version": "0.0.0",

 "private": true,

 "scripts": {

   "start": "node ./bin/www"

 },

 "engines":{

    "node":"4.4.4"

 },

 "dependencies": {

   "body-parser": "~1.15.1",

   "cookie-parser": "~1.4.3",

   "debug": "~2.2.0",

   "ejs": "~2.4.1",

   "express": "~4.13.4",

   "morgan": "~1.7.0",

   "serve-favicon": "~2.3.0",

   "stylus": "0.54.5"

 }

}




이 의존성 모듈 설치는 package.json 파일이 있는 디렉토리에서 아래와 같이

% npm install

명령어만 실행해주면 자동으로 설치된다.


테스트

샘플 애플리케이션 개발 및, 이를 실행하기 위한 환경 설정이 모두 끝났다.

그러면 이제 샘플 애플리케이션을 로컬에서 실행해보자.

실행은 ~/ 디렉토리에서 다음과 같은 명령을 실행하면된다.

% node ./bin/www



실행한 후, 결과를 확인하려면 http://localhost:3000 번으로 접속하면 아래와 같은 결과가 나오는 것을 확인할 수 있다.



구글 앱앤진으로 배포 준비

애플리케이션 개발 및 테스트가 끝났으면 이제 구글 앱앤진으로 이 애플리케이션을 배포해보자.

app.yaml 파일 작성

구글 앱앤진 Flex environment 로 애플리케이션을 배포하기 위해서는 애플리케이션에 대한 기본 정보를 app.yaml에 정의해야 한다. 이 파일은 배포할 node.js 애플리케이션이 있는 ~/ 디렉토리에 위치 시킨다.

runtime은 어떤 언어 (node.js , ruby 등)을 지정하고, VM으로 실행할지를 vm:true 로 정의한다.


runtime: nodejs
vm: true


Google Cloud SDK 설치

다음으로 배포를 하려면, gcloud라는 명령을 사용해야 하는데, 이 명령어는 Google Cloud SDK를 설치해야 사용할 수 있다. Google Cloud SDK는 https://cloud.google.com/sdk/downloads 에서 다운 받아서 설치한다.

Google cloud SDK 설정하기

Google cloud SDK 설치가 끝났으면, 혹시 google cloud SDK가 업데이트 되었을 수 있으니, 다음 명령어를 이용하여 최신 SDK로 업데이트 한다. (알파,베타 버전과 같은 신 기능이 들어가면 업데이트가 된다.)


% gcloud component update


라는 명령어를 수행하면 다음과 같이 업데이트 된 내용이 나오면서 업데이트 를 할 것인지 물어보고 “Y”를 선택하면 자동으로 Google Cloud SDK를 업데이트 한다.



Google Cloud SDK 배포가 끝났으면 gcloud 명령을 이용하기 위해서 초기화 작업을 해야 한다. 초기화 작업은 gcloud 명령을 사용했을때, 내 구글 클라우드 프로젝트 중 어느 프로젝트에 명령을 내릴 것인지, 그리고 어떠한 구글 계정을 사용할것인지 그리고 명령을 내릴때 어떤 리전을 디폴트로 해서 명령을 내릴것인지를 정하는 것이다. 사용자에 따라서 여러개의 프로젝트를 가질 수 도 있고, 또한 관리 목적상 여러개의 클라우드 계정을 가질 수 도 있기 때문이다.

초기화 방법은 다음과 같이 명령어를 실행하면 된다

% gcloud init

이 명령을 사용하면, 앞에서 언급한 바와 같이, gcloud 명령을 내릴 때 사용할 계정과, 디폴트 프로젝트 그리고, 리전을 선택하게 된다.


이제 배포를 위한 모든 준비가 끝났다.

구글 앱앤진으로 배포

이제 배포를 해보자. 배포는 매우매우 쉽다.

앞서 작성한 Express 애플리케이션이 있는 ~/ 디렉토리에 가서 다음 명령어를 수행하면 된다.

% gcloud app deploy

명령을 실행하면 다음과 같이 node.js 애플리케이션이 배포 되는 과정을 볼 수 있다.

배포는 수분이 소요된다. (내부적으로는 Docker 컨테이너를 이용하여 배포가 된다.)

서비스 기동확인

배포가 완료되면 자동으로 서비스가 기동이 된다.

서비스 기동 확인은 http:{프로젝트명}.appspot.com 으로 자동으로 서비스가 뜨게 된다.

해당 URL을 접속해보자. 여기서는 프로젝트명이 “useful-hour-138023”이다.


서비스가 정상적으로 기동 됨을 확인하였다.

모니터링

구글 클라우드 콘솔에 들어가 보면 현재 기동중인 node.js 앱을 확인할 수 있다.

콘솔에서 “App Engine”을 선택하면 다음과 같은 화면이 나온다.



아래 Instances 부분을 보면 Flexible 이라는 이름으로 현재 2개의 인스턴스가 기동되고 있고, 평균 QPS (Query Per Second : 초당 처리량)이 10.898 인것을 확인할 수 있다.


매니지드 서비스이기 때문에, 부하가 늘어나면 자동으로 인스턴스를 추가하고 줄어들면 자동으로 삭제하여 부하에 탄력적으로 대응을 자동으로 해준다.


로그 모니터링은 클라우드 콘솔에서 “Logging”이라는 메뉴를 선택하면 아래와 같은 화면이 나온다.


앱앤진 관련 request log 및 기타 로그들이 다 나오는데, 앞서 샘플코드에서 console.log(“Hello Appengine”) 명령어를 이용하여 Stdout으로 “Hello Appengine”이라는 문자열을 출력하도록 하였기 때문에, 이 문자열이 제대로 출력되었는지를 확인해보자.

App Engine 을 선택하고, 다음 “stdout”을 선택하면 위와 같이 앱앤진의 Stdout으로 출력한 로그들만 볼 수 있는데, 위와 같이 “Hello Appengine” 문자열이 출력된것을 확인할 수 있다.

수정 및 재 배포

그러면 다음으로 애플리케이션을 수정해서 배포해보자. routes/index.js를 다음과 같이 수정해보자


var express = require('express');

var router = express.Router();


/* GET home page. */

router.get('/', function(req, res, next) {

 res.render('index', { title: 'Hello Appengine is updated' });

 console.log('Hello Appengine is updated');

});


module.exports = router;



코드 수정이 끝났으면 배포를 해보자. 재 배포 역시 간단하게

%gcloud app deploy

명령어를 수행하면 간단하게 배포가 된다.

배포가 완료된 후 URL로 들어가서 확인을 해보면


애플리케이션이 업데이트 된것을 확인할 수 있다.

롤백

앱앤진의 장점 중에 하나가 배포도 쉽지만, 롤백도 매우 쉽게 가능하다는 것이다.

클라우드 콘솔에서 App Engine을 선택하고, 아래와 같이 Versions라는 메뉴를 선택하면 아래와 같은 그림을 볼 수 있다.




현재 두개의 버전이 배포되어 있고, 위의 최신 버전에 Traffic Allocation이 100%로 되어 있는 것을 확인할 수 있다. 이는 새로 배포된 버전으로만 트래픽이 100% 가고 있다는 의미인데, 롤백은 트래픽을 예전 버전으로 라우팅 해주고, 새버전의 서비스를 정지 시키면 된다.


아래 그림과 같이 예전 버전을 선택한 후에, 상단 메뉴에서 “Migrate Traffic”을 선택한다.



그러면 아래와 같이 트래픽이 이전 버전으로 100% 가고 있음을 확인할 수 있다.

그리고 나서 새 버전을 선택한 후 상단의 STOP 버튼을 눌러주면 아래 그림과 같이 새버전의 상태가 Serving 에서 Stopped로 변경된것을 확인할 수 있다.




예전 버전으로 롤백이 잘 되었는지를 확인해보자.

아래 그림처럼 예전 버전으로 롤백이 되었음을 확인할 수 있다.



버전별로 트래픽 분산하기

앱앤진의 장점 중의 하나가 여러 버전을 유지할 수 있고, 버전간에 트래픽을 자유롭게 조절할 수 있다. 예를 들어서 v1으로 90%, v2로 10% 의 트래픽을 보내는 것등이 가능하다.


이렇게 트래픽을 조절하는 것은 크게 2가지 방법으로 활용이 가능한데, 서버단의 A/B 테스팅과 카날리 테스팅이다.

A/B 테스팅은 사용자를 두개 이상의 집단으로 나눈후, 기능 A,B 에 대한 반응을 본 후, 반응이 좋은 기능을 선택하는 방식으로, 모바일 클라이언트단에서 많이 사용되고, 서버단에는 구현이 쉽지 않았는데, 트래픽을 버전별로 나눠서 주는 기능을 사용하면 손쉽게 A/B 테스팅을 수행할 수 있다.


다음으로 카날리 테스트는 옛날에 광부들이 광산에 들어갈때 카나리아 새를 데리고 들어가서 유독가스가 나오면 카나리아 새가 먼저 죽는 것을 보고 위험을 감지하는 방법에서 유래된것으로 서버 배포에서는 전체 사용자를 대상으로 새 버전을 배포하는 것이 아니라 1~2%의 사용자에게 배포해보고 문제가 없으면 전체 사용자에게 배포하는 개념으로, 마찬가지로 v2에 1~2%의 트래픽만 할당하고 나머지 98~99%는 v1에 할당하는 방식으로, 해서 v2에 대한 안정성 검증을 한 후에, v2를 전체 배포 하는데 활용할 수 있다.


버전간 트래픽 비율을 지정하는 방법은 클라우드 콘솔의 앱앤진 메뉴에서 Version을 선택하고 상단 메뉴에서 → 가 두개 겹쳐진 아이콘 (맨 우측)

를 선택하면 아래와 같이 Split traffic 이라는 메뉴가 나온다.

여기서 1개 이상의 Version을 추가한 후에, 각 버전으로 보낼 트래픽의 비중 (%)을 정의한다.






위의 예제에서는 xxx4403 버전으로 30%, xxxx3136 버전으로 70%의 트래픽을 보내도록 하였다.

설정을 완료한 후에 SAVE를 누르고, 다시 Version 부분을 보면, 수분 있다가 아래 그림과 같이 xxxx3136 버전에 70% 트래픽이 xxx4403 버전으로 가게 된다.


부가 기능에 대해서

구글 클라우드에서 앱앤진만 쓸 수 있는 몇가지 좋은 서비스 들이 있는데, 다음과 같다.

매니지드 memcached

앱앤진에서는 구글 매니지드 memcached 서비스를 사용할 수 있다 별도의 설정 없이 바로 사용이 가능하며, 최대 100GB 까지 사용이 가능하다. (100GB 이상도 요청하면 사용이 가능) Shared memcached의 경우에는 별도의 비용없이 일반적인 캐쉬로 사용이 가능하지만, 용량이나 성능등이 보장이 되지 않으니 주의가 필요하다.

https://cloud.google.com/appengine/docs/python/memcache/

보안 스캐닝 (Security Scanning)

매우 유용한 기능중의 하나가 보안 스캐닝 기능이다 앱앤진 메뉴에서 Security Scanning이라는 메뉴를 선택하면 앱앤진으로 개발한 웹 사이트에 대한 보안 스캐닝을 할 수 있는데, 한번만 스캐닝할 수 도 있고 자동 스케쥴 방식으로, 주기적으로 스캐닝 하는 것도 가능하다.


보안 정책이 수시로 업데이트 되기 때문에, 정기적으로 보안 스캔을 하는 것을 권장한다.

텍스트 검색 (Search)

node.js에는 지원하지 않지만, Python,Java,PHP,Go (앱앤진 Standard environment)에서만 지원되는 기능중 하나는 구글 검색 엔진과 같은 검색 엔진을 지원한다. 텍스트 검색 HTML 그리고 GEO_POINT (위/경도 기반 검색)이 가능하다.

https://cloud.google.com/appengine/docs/java/search/?hl=en_US

결론

지금까지 간략하게나마 구글 클라우드에 대한 소개, 앱앤진에 대한 개념 및, 간단한 node.js express 애플리케이션을 작성해서 배포해봤다. 다음글은 앱앤진에 대한 조금 더 구체적인 환경에 대해서 알아보도록 하겠다.



Logentries를 인스톨하고 나니, 얼마후에 무료로 Community pack을 인스톨하라고 이메일이 왔다.

https://community.logentries.com/packs/heroku/





CPU,Memory와 같은 인프라 모니터링도 가능하고, 앱 모니터링도 가능한 플러그인이다.

설치 방법이 복잡해서 당장은 실행은 해보지는 않았지만 시간 날때 테스트할만한 가치는 있는듯


Heroku에서 Metrics 메뉴를 이용하여 애플리케이션 모니터링 하기


조대협 (http://bcho.tistory.com)


heroku에서는 Metrics이라는 메뉴를 통해서 기본적인 시스템 모니터링을 지원한다. 기본 지원 항목으로는

응답시간 (Response time), 메모리 사용률 (Memory Usage), 분당 처리량 (Throughput-TPM), CPU 사용률 (Dyno Load)을 볼 수 있다. 이 항목들은 Heroku 대쉬보드에서 모니터링하고자 하는 애플리케이션을 선택한 후, 상단의 Metrics라는 탭을 선택하면 된다.  

 

아래는 Metrics 메뉴를 통해서 helloherokuterry 애플리케이션의 주요 지표를 모니터링 한 화면이다.



한가지 주의할점은 Metrics 모니터링 기능은 무료 dyno로는 사용이 불가능하며 최소 standard-1x dyno 부터 지원이 된다.

Heroku에서 newrelic을 이용한 node.js 애플리케이션 모니터링 (APM)


조대협 (http://bcho.tistory.com)


Heroku에서 node.js 애플리케이션에 대한 모니터링을 살펴보자. 애플리케이션의 모니터링은 모니터링 분야에서 APM (Application Performance Monitoring)이라는 분야로, 애플리케이션에서 어떤 API 들이 호출이 되었는지, 각 로직별 응답 시간등을 추적할 수 있다. 한국에서 유명한 APM으로는 제니퍼가 있다.

Heroku에서 사용할 수 있는 APM은 여러가지가 있지만 여기서는 newrelic이라는 제품을 소개한다.

Newrelicheroku 뿐 아니라, 모니터링 시장에서 매우 유명한 제품으로 APM 기능뿐만 아니라, 서버 인프라에 대한 모니터링등 상당히 많은 기능을 제공한다.

Heroku에는 그러한 기능을 제공하지는 않고 newrelicAPM 기능만을 제공한다.

 

newrelic add-on 설치


newrelic add-on부터 설치한다. 설치 명령어는 다음과 같다.


%heroku addons:create newrelic:{상품명}


상품명은 무료 상품을 사용할 예정이기 때문에, 상품명은 ‘wayne’를 선택한다. Heroku addons 명령어를 이용해서 다음과 같이 addons를 추가 한다.



Figure 7 newrelic addon 설치

 

상품 모델은 https://elements.heroku.com/addons/newrelic#plan_selector 를 참고하면 된다.

3 dyno 모니터링에 월 49$, 300 dyno에 월 4499% 까지 다양한 상품 모델이 있다. 가격은 다른 상품에 비해서 싼편은 아니지만, APM 쪽에서 그만큼 많은 기능을 제공한다.

 

newrelic 환경 변수 설정


다음으로 추가적인 환경 설정이 필요하다. 다음과 같이 heroku config 명령어를 이용해서 다음 환경변수들을 설정한다.

 

환경변수명

설정값

설명

NEW_RELIC_APP

‘helloherokuterry’

newrelic 을 적용한 heroku 애플리케이션 이름. 여기서는  helloherokuterry 앱을 사용하기 때문에, helloherokuterry 를 사용한다

NEW_RELIC_NO_CONFIG_FILE

‘true’

newrelicnode.js에서 사용하기 위해서 원래는 newrelic.js 에 환경변수를 설정하는데, herokunewrelic에서 이 옵션을 설정하면 newrelic.js 환경에서 환경변수를 읽는데, newrelic.js를 사용하지 않고, heroku config 를 이용하여 환경 변수를 설정할 경우, 이 옵션을 ‘true’로 세팅한다.

Figure 8 newrelic 환경 변수 목록

 

다음은 heroku config 명령을 이용해서 위의 두 환경 변수를 설정한 화면이다.



Figure 9 newrelic 환경 변수 설정 화면

 

node.js 애플리케이션에 에이전트 코드 삽입


환경 변수 설정이 끝났으면, newrelic 에서 node.js 애플리케이션의 실행 정보를 수집할 수 있도록 코드를 삽입해야 한다.

에이전트는 ‘newrelic’ node.js 모듈을 설치해서 app.js 에서 로딩 하면 된다.

package.json에서 다음과 같이 newrelic 모듈에 대한 의존성을 추가한다.


{

  "name": "helloheroku",

  "version": "0.0.0",

  "private": true,

  "scripts": {

    "start": "node ./bin/www"

  },

  "dependencies": {

    "body-parser": "~1.13.2",

    "cookie-parser": "~1.3.5",

    "debug": "~2.2.0",

    "ejs": "~2.3.3",

    "express": "~4.13.1",

    "morgan": "~1.6.1",

    "serve-favicon": "~2.3.0",

    "stylus": "0.42.3",

    "newrelic" : "~1.25.5"

  }

}

Figure 10 package.json  newrelic 의존성 추가

 

다음으로 이 모듈을 애플리케이션에서 로딩해야 하는데, app.js 맨 윗줄에 아래와 같이 require(‘newrelic’) 코드를 삽입한다.

 

require('newrelic');

 

var express = require('express');

var path = require('path');

var favicon = require('serve-favicon');

Figure 11 app.jsnewrelic 에이전트 로딩 코드를 삽입

 

코드가 수정되었으면 heroku에 배포한다.

 

Newrelic을 이용한 모니터링


이제 모든 준비가 끝났다. 애플리케이션을 기동하고 heroku 대쉬보드로 들어가 보자



Figure 12 애플리케이션 선택

 

그림과 같이 대쉬보드에서 애플리케이션을 선택하면, 다음과 같이 newrelic addon이 추가된것을 확인할 수 있다.



Figure 13 newrelic APM addon이 추가된 화면

 

newrelic을 클릭해보면, 설정이 제대로 되었다면 다음과 같은 화면이 나올것이다.



Figure 14 newrelic 첫번째 접속 화면

 

상단에서 APM화면을 눌러서 APM 화면으로 들어가면 아래와 같이 애플리케이션 리스트들이 나오고, 아까 등록한 helloherokuterry 애플리케이션이 나온다.



Figure 15 newrelic에서 애플리케이션 선택

 

해당 애플리케이션을 클릭하면 다음과 같이 애플리케이션에 대한 상세 정보가 나온다.



Figure 16 newrelic APM 모니터링 화면

 

전체 응답시간(Web transation time), 초당 처리량 (Throughput), 주로 호출되는 웹 트렌젝션 목록등을 볼 수 있다.

그이에도 각 인스턴스에 대한 디테일이나 개별 트렌젝션에 대한 추적, 에러등에 대해서도 추적이 가능하다.

Heroku에서 logentries를 이용하여 node.js 로그 모니터링 하기


조대협 (http://bcho.tistory.com)

 

Heroku에서 제공하는 로깅은 heroku logs –tail 명령을 이용해서 모니터링 할 수 있는데, 이 로그의 경우 최대 1500줄만 저장을 지원한다. 실제 운영 환경에서 1500줄의 로그란 부족해도 많이 부족한 양이다. 그래서 추가적인 서비스를 이용하는 것이 좋은데, 많은 로깅 서비스가 있지만, 간단하게 사용할 수 있는 로깅 서비스로 logentries 라는 서비스가 있다.

 



Figure 1 http://www.logentries.com

 

무료로 사용이 가능하고, 무료 사용시 최대 7일간의 로그를 저장해주고, 일 최대 33M 까지 로그를 저장할 수 있다.

가장 저렴한 Entry 플랜은 한달에 9$로 일 133M 로그를 최대 7일간 저장하고, 가장 비싼 Platium 플랜은 월 1399$로 일 최대 40GB의 로그를 최대 7일간 저장할 수 있게 해준다. (에러나 일반적인 시스템 로그라면, 왠만한 시스템이면 40GB정도면 충분하지 않나 싶다.)

 

그러면 앞서 작성하여 heroku에 배포한 node.js 애플리케이션에 이 logentires를 적용해 보자.

적용은 매우 간단하다. 명령창에서 간단하게 다음 명령을 실행하자

heroku addons:create logentries

 

명령을 실행하면 다음과 같이 logentries 가 설치되었다고 나온다.



Figure 2 logentries 설치

 

설치가 완료되었으면 이제 사용을 해보자. Heroku  대쉬 보드로 접속해서, 생성한 애플리케이션을 선택한다.



Figure 3 heroku dashboard에서 애플리케이션 선택

 

애플리케이션을 클릭해서 들어가면 하단 add-on 리스트에 logentries가 아래 그림과 같이 활성화가 되어 있는 것을 확인할 수 있다.



Figure 4 heroku 애플리케이션에서 add-onsLogentries가 설치된 화면

 

logentries를 클릭해서 들어가면, logentries를 이용한 로그 모니터링 화면이 나온다.

아래 그림과 같이 좌측에 “heroku”라는 Log set이 나오는데, 이를 클릭하고, 우측 상단에 “Live tail” 이라는 버튼을 누르면 현재 node.js의 로그를 실시간으로 보여준다. 실제로 해보면 heroku logs –tail 보다 약 1초 정도 지연이 발생한다.



Figure 5 logentries를 이용한 실시간 로그 모니터링

 

다음 화면은 node.js의 로그를 heroku logs –tail로 모니터링한 화면으로 위의 logentrieslive tail과 동일함을 확인할 수 있다.



Figure 6 heroku logs를 이용한 실시간 로그 모니터링

 

heroku 기본 로깅 시스템에 비해서 더 많은 로그를 볼 수 있는 것은 물론이고, 로그에 대한 검색이 가능하고, 특정 데이타를 기반으로 한 그래프등 다양한 기능을 지원한다.

Heroku 스케일링 (scaling)에 대해서


조대협 (http://bcho.tistory.com)

 

스케일링이란, 더 큰 다이노(더 많은 CPU와 메모리)를 사용함으로써 각 다이노의 성능을 올리거나, 더 많은 다이노를 추가함으로써 여러 다이노로 부하를 분산해서 전체 성능을 올리는 방법을 이야기 한다.

 

더 큰 다이노를 사용하는 것을 수직 스케일링 (vertical scaling), 더 많은 다이노를 사용하는 것을 수평 스케일링 (horizontal scaling)이라고 한다.

 

그러면 Heroku에서 스케일링을 어떻게 하는지 알아보자

스케일링은 다음과 같이

 

heroku ps:scale 다이노타입=다이노개수:다이노크기

 

 지정하면 된다. 이 스케일링은 무료 티어에서는 사용이 불가능 하기 때문에, 과금을 위한 신용 카드 정보를 등록해야 한다. 대쉬보드에서 “Manage Account > Billing” 메뉴에서 아래와 같이 신용 카드 정보를 추가한다.

 



Figure 1 계정 정보에 신용카드 정보 추가

 

수직 스케일링

 

수직 스케일링에서 다이노의 크기를 늘리는 것을 스케일 업 (scale up), 줄이는 것을 스케일 다운 (scale down)이라고 한다.

현재 하나의 Free 타이의 웹 다이노가 돌고 있을 때, 이를 standard-1x 한개로 스케일 업을 하고자 하면

 

%heroku ps:scale web=1:standard-1x

 

로 하면 간단하게 스케일 업을 할 수 있다.

반대로 스케일 다운을 하려면 더 작은 다니오 타입을 지정하면 된다. 다음은 현재 다이노를 free 타입으로 스케일 다운 하는 명령어 이다.

 

%heroku ps:scale web=1:free

 

수평 스케일링

 

수평 스케일링에서 다이노를 추가 하는 것을 스케일 아웃, 다이노를 빼는 것을 스케일 인이라고 한다.

스케일 아웃과 인은 heroku ps:scale 명령에서 다이노의 개수만 조정해주면 된다.

 

%heroku ps:scale web=2:standard-1x

 

아래는 standard-1x 다이노 2개로 스케일 아웃을 한후 ps 명령을 이용하여 2개의 다니노가 기동된것을 확인 한후, 다시 1개의 free 다이노로 스케일인 & 다운을 한 화면이다.

 



Figure 2 스케일링 테스트 결과

 

스케일 아웃이나 스케일 인이 되면, 자동으로 웹 로드밸런서에 붙어서 부하가 분산된다.

참고로, freehobby의 경우에는 1개의 웹 다이노만 사용이 가능하다. (스케일 아웃이 불가능하다)

 

제약 사항


스케일링에는 몇가지 제약 사항이 있다.

·         free hobby 1개의 웹다니오만 사용이 가능하기 때문에, 스케일 아웃이 불가능하다.

·         같은 타입의 다이노는 같은 크기의 다이노만을 사용해야 한다. 즉 웹은 standard-1x를 사용하면 모든 웹 다이노는 standard-1x만 사용해야 한다. Freehobby, standard-2x 등은 섞어 쓸 수 없다.

·         전체 다이노를 합쳐서 최대 100개의 다이노까지만 스케일링이 가능하다. (고객지원센터에 연락하면 이 한계를 풀 수 있다.)

·         perofmance 다이노의 경우 10개만 사용이 가능하다.

 

과금 방식


헤로쿠의 과금 방식은 초당 과금이다. (아마존의 경우 시간당 과금으로 1시간 1초를 사용해도 2시간 사용분이 과금된다.)  이 부분은 참 좋은듯.

 

오토 스케일링


 서버 부하에 따라서 자동으로 다이노를 늘리고 줄여주는 오토 스케일링은 헤로쿠에서 지원하지 않고, 추가 add-on을 설치해야 한다. 주로 사용되는 오토스케일링 add-on으로 adept (https://www.adeptscale.com/) hirefire (https://www.hirefire.io/) 등이 있다.

 

Heroku 클라우드에 node.js 애플리이션을 배포하기


조대협 (http://bcho.tistory.com)



가장 빠르게 이해하는 방법은 직접 해보는 것이다. Heorku 클라우드에 대한 이해를 위해서 express를 이용해 구현된 node.js 애플리케이션을 직접 배포해서 실행해보자

이 예제는 node.js 4.3.1 버전과 express 4.13.4 버전을 기준으로 작성되었다.


Heroku 가입

Heroku사용을 위해서 Heroku계정을 만들자. http://www.heroku.com 에 접속해서 Sign up 메뉴로 들어가면, 간단하게 이름과 이메일 정도의 정보만 넣으면 간단하게 계정을 만들 수 있다.



Figure 1 Heroku 가입 화면


다른 클라우드의 경우 향후 유료 사용을 위해서 회원 가입시 처음부터 신용카드 정보를 요구 하는 경우가 있어서 신용카드가 없는 학생등은 가입이 안되는 경우가 있지만, Heroku의 경우 별다른 부담없이 무료로 계정을 생성해서 사용할 수 있다. 지금부터 진행할 예제는 무료 계정에서 한개의 웹 서버를 기동하여 node.js 애플리케이션을 기동하는 예제로 별도의 비용이 필요없다.


계정이 생성되었으면 Heroku 웹 콘솔에 로그인해보자




Figure 2 Heroku 대쉬 보드


첫 대쉬보드에서는 각 개발플랫폼에서 개발을 시작하는 방법에 대한 가이드를 제공한다.


node.js 애플리케이션 준비


Heroku 계정이 준비되었으면, Heroku에 배포할 node.js 애플리케이션을 준비해보자. 

“Hello Heroku”를 출력하는 간단한 node.js 애플리케이션을 작성하자.

다음과 같이 express generator를 이용해서 node.js 애플리케이션을 생성한다.


% express -–session --ejs --css stylus helloheroku

% cd helloheroku

% npm install


애플리케이션을 설치한 후에, 애플리케이션 디렉토리로 들어가서 npm install 명령을 이용하여, 애플리케이션에서 사용되는 의존성을 가지고 있는 모듈들을 설치한다.


다음으로 /routes/index.js를 다음과 같이 수정한다.


var express = require('express');

var router = express.Router();


/* GET home page. */

router.get('/', function(req, res, next) {

  res.render('index', { title: 'Heroku' });

  console.log(' hello heroku ');

});


module.exports = router;


Heroku에 배포하는 node.js 애플리케이션을 개발할때, 주의할점 중의 하나가 package.json이다.

보통 로컬 개발환경에 npm 패키지들이 이미 설치 되어 있는 경우 실행이 제대로 되고, 문제가 없기 때문에, package.json에 필요한 모듈에 대한 정의를 빼먹는 경우가 많다. Heroku에 애플리케이션을 배포할때는 의존 패키지들이 설치되어 있지 않기 때문에 이를 설치 해야 하는데,  Heroku는 자동으로 package.json에 정의된 npm 모듈들을 설치해 준다. 반드시 배포전에 package.json에 필요한 모듈들이 제대로 정의되었는지를 확인해보자


소스코드가 준비되었으면 Procfile 이라는 것을 준비해야 한다. 위에서 만든 애플리케이션의 루트”/” 디렉토리에 다음과 같은 내용으로 Procfile을 작성하자.


web: node ./bin/www


Procfile은 애플리케이션을 Heorku에 배포 해서 실행할때, Heroku 클라우드가 맨 처음 실행하는 명령어를 지정하는 파일이다. 보통 애플리케이션을 기동하기 위한 명령어를 기술한다.

앞서 작성한 Procfile을 보면, “web:” 이라고 기술하였는데, 배포하고자 하는 애플리케이션이 웹 애플리케이션임을 정의한다. web 타입의 애플리케이션만 Heroku의 내부 HTTP 로드밸런서에 연결이 되서 웹 요청을 받을 수 있다.

다음으로 “node ./bin/www” 라고 지정하였는데, node.js 애플리케이션을 기동하기 위한 명령어이다. 우리가 작성한 애플리케이션은 express애플리케이션으로 기동 로직이 ./bin/www 에 들어 있다.


추후에 추가로 설명하겠지만, node.js는 모니터링등을 위해서 forever나 pm2와 같은 추가적인 도구를 이용해서 기동을 하는 경우가 있다. 실행을 할때 forever ./bin/www 식으로 실행하는데, Heroku에서 실행하려면 다음과 같이 실행하면 된다.


web: ./node_modules/.bin/forever ./bin/www


이제 배포를 위한 node.js 애플리케이션 준비가 끝났다. Heorku에 배포해보자.


Heroku 툴벳 설치


계정이 준비되고 애플리케이션 개발이 끝났으면, Heroku에 접속해서 배포를 진행해야 한다. Heroku는 툴벳이라는 커멘트라인 인터페이스 (CLI : Command line interface)를 이용해서 사용한다. 

툴벳은 https://toolbelt.heroku.com/ 에서 다운로드 받을 수 있다.




Figure 3 Heroku 툴벳 다운로드 페이지


툴벳을 인스톨했으면 실행해보자. 프롬프트 상에서 

%heroku 

명령어를 수행하면 간단한 사용법이 나온다.

이 툴벳을 통해서 Heroku에 명령을 내리기 위해서는 자신의 계정으로 로그인을 해야 한다. 로그인은 “heroku login”이라는 명령을 사용해서, Heroku 가입시 생성한 계정으로 로그인을 하면 된다.




Figure 4 툴벳에서 Heroku 로그인


Heroku 배포 준비


로그인이 끝났으면, Heroku내에 앱을 생성한다. Heroku의 앱은 애플리케이션 단위로, 이 앱단위로 배포를 하고 운영을 하게 된다. 

앱 생성 방법은 다음과 같다.


%heroku app:create {앱이름}


이 예제에서는 helloherokuterry 라는 이름의 앱을 생성할것이다.

이 앱 이름은 Heroku 클라우드에 걸쳐서 유일한 이름으로 사용을 해야 하기 때문에, 위의 이름으로 앱을 생성하고자 하면 이미 저자가 해당 이름을 사용하고 있기 때문에, 아마도 에러가 날것이다. 다른 적절한 이름을 이용해서 앱을 생성하자


아래는 helloherokuterry 라는 이름의 앱을 생성하고, “heroku apps” 를 이용하여 현재 생성된 앱 리스트를 확인해서 helloherokuterry 라는 앱이 제대로 생성이 되었는지 확인 하는 화면이다.




Figure 5 Heroku에 애플리케이션을 생성하는 화면


만약에 잘못 앱을 생성하였으면 다음 명령어를 이용해서 앱을 삭제할 수 있다.


%heroku app:delete {앱이름}


앱이 생성되었으면, 작성한 애플리케이션을 배포해야 하는데, heroku의 코드 배포는 git 소스코드 관리 시스템을 사용한다.

앱 디렉토리에서 git 리포지토리를 생성한다.

%git init .

다음, 작성한 애플리케이션들을 git에 추가한다.

%git add *

추가된 애플리케이션 코드들을 commit 한다.

%git commit


이제 로컬 git 리파지토리에 애플리케이션 코드들이 저장되었다. 이 코드들을 Heroku에 전송하자.

git에 Heroku 클라우드 상의 git 저장소를 리모트 저장소로 지정해야 한다.

Heroku의 git 저장소를 리모트 저장소로 지정하는 방법은 다음과 같다. 


%heroku git:remote -a {앱이름}


여기서는 애플리케이션의 이름이 helloherokuterry이기 때문에 다음과 같이 리모트 저장소를 추가하겠다.

% heroku git:remote –a helloherokuterry


heroku의 git 리파지토리가 리모트 저장소로 지정되었다.

아래 명령어를 이용해서 로컬에 저장된 코드를 heroku로 올려보자


%git push heroku master


명령어를 실행하면 소스코드를 Heroku에 배포 하는 것을 확인할 수 있다.




Figure 6 git를 이용하여 Heroku에 앱을 배포하는 화면


배포는 단순하게 소스 코드만을 올리는 것이 아니라 올라간 소스코드를 확인해서, package.json에 지정된 의존성 있는 모듈들을 설치 한다. 아울러 환경변수를 세팅한다.

Heroku의 경우 node.js에 대해서 디폴트 환경 변수를 정의하는데

NPM과 node.js에 대한 환경 변수를 다음과 같이 설정한다. 모드를 운영 모드로 설정하는 부분이다.


remote:        NPM_CONFIG_LOGLEVEL=error

remote:        NPM_CONFIG_PRODUCTION=true

remote:        NODE_ENV=production

remote:        NODE_MODULES_CACHE=true


배포에서 git를 사용하였는데, 혹시나 git에 대해 생소한 분들을 위해서 간략하게 배포 흐름을 정리하고 넘어가자.  




Figure 7 git를 이용한 Heroku 배포 개념도


개발환경에서 작성된 소스코드는 git의 로컬 저장소 (Local repository)로 저장되기전에 git add명령어를 이용하여 스테이징 단계 (stage)로 이동된다. 소스를 저장소에 저장하기 전 단계로, 전체 코드 중에서 어떤 파일들을 저장할지를 선택하고 검토하는 일종의 중간단계이다.

스테이징이 끝나면, git commit 명령을 이용하여 로컬 저장소 즉 내 PC에 있는 git 저장소에 소스 코드를 저장한다.

다음 이 코드를 원격에 있는 Heroku의 git 저장소로 전송을 해야 하는데, 이를 푸쉬(push)라고 한다. git push 명령어를 이용해서 실행하며, 코드가 Heroku의 git 저장소에 저장이 되면, 기동을 하기 위한 환경 변수 설정이나 npm 모듈들을 설치 하는 작업을 수행한다.


이제 애플리케이션 실행을 위한 모든 준비가 끝났다. 배포한 애플리케이션을 기동해 보자


서비스 기동 및 모니터링


서버의 기동은 Heroku에서 web dyno수를 0에서 1로 늘려주면 된다.


%heroku ps:scale web=1


서버가 기동된것을 확인하였으면 웹으로 접속해서 애플리케이션이 제대로 동작하고 있음을 확인하자.

Heroku app의 URL은 http://{heroku app 이름}.herokuapp.com 이다.

우리가 만든 예제는 helloherokuterry라는 앱 이름을 사용했기 때문에, https://helloherokuterry.herokuapp.com/ 가 접속 URL이 된다

또는 간단하게 명령 프롬프트 창 내에서 heroku open 이라는 명령어를 사용하면 해당 URL을 브라우져를 열어서 자동으로 열어준다.


%heroku open




Figure 8 Heroku open 명령어를 이용하여 기동중인 웹사이트를 오픈




Figure 9 Hello Heroku 실행 화면


드디어 Heroku에 node.js 애플리케이션을 배포하고 기동시켰다.

애플리케이션의 구동 상태와 로그를 확인해보자

현재 몇개의 dyno 가 구동되고 있는지를 확인하려면 다음 명령어를 실행하면 된다.


%heroku ps




Figure 10 ps 명령어를 이용하여 동작중인 서버를 확인


현재 web 타입의 1개의 dyno 가 실행되고 있음을 확인할 수 있다.

다음은 애플리케이션 로그를 확인해보자


%heroku logs –tail


이 명령어는 node.js에서 나오는 로그를 모니터링 할 수 있게 해준다



Figure 11 node.js의 로그를 확인


위의 로그를 보면 03:11:32에 서버가 기동 되었음을 확인할 수 있고

03:11:34초에 http://helloherokuterry.herokuapp.com/  URL이 호출되었음을 확인할 수 있다.

그리고 그 아래 애플리케이션에서 console.log(‘hello heroku’)로 출력한 로그도 같이 출력됨을 확인할 수 있다.


테스트가 끝났으면 실행중인 서버를 내려보자.

서버를 내리는 방법은 ps:scale 명령어를 이용하여 web dyno수를 1에서 0으로 변경해주면 된다

%heroku ps:scale web=0

명령을 실행하고 ps 명령어를 이용해서 현재 기동중인 dyno 수를 확인해보면, 아무 서버도 기동되지 않음을 확인할 수 있다.



Figure 12 동작중인 dyno를 종료하는 화면


로그에서도 아래와 같이 dyno를 끄는 로그를 확인할 수 있다.



Figure 13 dyno 종료 로그를 확인



요즘 마이크로소프트의 행보를 보면서


조대협 (http://bcho.tistory.com)


근 1~2년간, IT 솔루션에 대한 비지니스가 많은 변화를 겪고 있습니다. 전통적인 라이센스 기반의 영업을 통한 엔터프라이즈 시장은 점점 매출이 떨어져가고 있고, 클라우드와 오픈소스 서브스크립션 모델 기반의 비지니스가 활성화 되어가는 상황에서, 공룡 IT 기업들이 변화를 시도하고 있습니다.


거대 공룡인 IBM의 경우 클라우드 컴퓨팅에 집중하기 이해서 소프트레이어 클라우드 (http://www.bloomberg.com/news/articles/2013-06-04/ibm-to-acquire-cloud-computing-provider-softlayer-technologies) 를 인수하였고, PaaS 서비스인 블루믹스를 개발하여 서비스 하고 있습니다. 얼마전에는 Node.js로 프레임워크로 유명한 StrongLoop 를 인수하였습니다. https://developer.ibm.com/bluemix/2015/09/10/ibm-acquires-strongloop/

그렇지만 아직까지 큰 존재감은 주고 있지 않는것 같습니다.


세일즈 포스의 경우 PaaS 클라우드로 유명한 Heroku를 인수했지요. http://www.salesforce.com/company/news-press/press-releases/2010/12/101208.jsp PaaS 플랫폼중에 접근성이 좋고, 많은 플랫폼 포트폴리오를 가지고 있어서, 나중에 강한 클라우드 벤더가 되지 않을까 합니다.


이러한 공룡 IT 기업들의 변화속에서 요즘 계속해서 눈에 띄는게 마이크로 소프트입니다. 윈도우즈와 .NET 기반의 폐쇄적인 플랫폼 생태계를 가지고 있어서 한계로 인식이 되었는데, 요즘 무섭게 기업 인수와 오픈 생태계로 나오면서 변화를 시도하고 있습니다.


얼마전에는 모바일 앱 크로스 플랫폼인 Xamarine을 인수하였고 https://xamarin.com/pr/xamarin-microsoft-partner

MS SQL의 Linux 지원을 공표하였습니다. https://www.microsoft.com/en-us/server-cloud/sql-server-on-linux.aspx

그러더니 오늘은 소프트웨어 스위치를 Debian Linux 기반으로 개발하여 발표 하였고 http://www.theregister.co.uk/2016/03/09/microsoft_sonic_debian/

몇일 전에는 이클립스 IDE 플랫폼에 합류 하였습니다. https://blogs.msdn.microsoft.com/visualstudio/2016/03/08/microsoft-joins-the-eclipse-foundation/

이뿐 아니라 R 언어를 지원하기 위해서 Visual Studio에 R 지원 기능을 탑재하였고 

http://blog.revolutionanalytics.com/2016/01/r-coming-to-visual-studio.html

비주얼 스튜디오 코드를 오픈소스로 전환해 버렸습니다. http://www.bloter.net/archives/244097

node.js도, 기존 구글의 V8엔진에서, 새롭게 포크하여 자사의 차크라 자바스크립트 엔진을 기반으로 한 node.js를 제공하겠다고 발표하였습니다. http://www.infoworld.com/article/3024271/javascript/nodejs-welcomes-microsoft-chakra-javascript-engine.html

얼마전에는 구글이 영상 인식이 가능한 Vision API의 클라우드 버전을 발표하더니만, 마이크로 소프트도 https://www.projectoxford.ai/vision 프로젝트를 통해서 Vision API 를 발표하였습니다.


아침에 일어나면 하나씩 빵빵 터지는지라, 다 적기도 어렵습니다. 

거대 공룡 기업이 이렇게 빠르게 변화에 대응하면서 변화를 따라잡는거 보면 놀랍기도 하고, 다음 기술을 이끌어갈 주자로써 마이크로 소프트를 무시할 수 없겠구나 하는 생각이 듭니다.



이러한 많은 변화는 나델라 CEO가 취임하고서 벌어진 변화인데, 국내 대기업들도 변화에 적응하기 위해서 많은 시도를 하고 있지만, 시장에 큰 임팩트를 주거나 대단한 변화라는 가시성을 보여주지는 못하는 것 같습니다. 

아마 나델라 같은 혁신적인 리더 부재가 아닐까 조심스럽게 추측해보는데...


어쨌거나, 공룡 IT 기업들도 빠른 변화를 진행하고 있는 중간에... 나는 어떻게 변화해야 할까를 고민해봅니다.