System Compleat.

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

Techs


(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, 정윤진) 





저작자 표시 비영리
신고

Cloud software engineering

Techs


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

Meetup을 하고, 중국 두개 도시, 일본 동경, 서울에서 Pivotal Cloud roadshow 를 하고, SpringOne Platform 행사를 다녀오고 각종 회사의 내부 발표와 미팅을 하다보니 어느덧 추석을 목전에 두고 있다. 블로그 작성은 고사하고 써야하는 책 진도가 엄청 밀려서 달리고 달려도 데모의 컨셉과 구현을 병행하다 보니 혼이 나가는 것 같다. 그래도 스트레스는 풀어야겠다고 종종 PS4의 "더 디비전" 으로 지옥이 되어버린 뉴욕 맨하탄에서 악당들을 쏘곤 했다. 어쨌든, 참 시간은 화살과 같다. 


시장, 그리고 엔터프라이즈. 


위의 이미지는 아주 오래전부터 내부 직원들끼리 유머용으로 사용하던 것이다. 기술의 발전과 그 발전을 수용하는 단계에 대한 것인데, 2010년 초반 부터 시작된 거대한 패러다임 쉬프트가 이제 6년째에 접어들어 엔터프라이즈 들에게는 "Oh no" 정도의 단계에 오지 않았나 생각해 본다. 주목할 만한 것은 다른 세상의 모든, 즉 엔터프라이즈를 제외한 세상과 엔터프라이즈의 기술 도입에 대한 그래프의 모양이 다르다는 점이다. 이게 현실 세계의 타이밍에서 묘하게 재미있는 부분은, "Oh fuck" 단계에 들어서면 이전에 주구 장창 이야기 되었던 ROI 와 같은 질문은 더 이상 나타나지 않는다는 점이다. 

국내 클라우드 시장에서, 아마존 웹 서비스의 도입에 대해 이야기를 2012년, 2013년에 하다보면 거의 대부분의 엔터프라이즈 기업들이 데이터센터 운용 비용 및 서버 구매 비용이 어떻게 차이가 나는지 많이 물었다. 그리고 ROI 가 어떻게 개선되는지, 그리고 그 개선에 대한 사례가 없으면 우리는 절대 도입 못할거라고 했다. 비슷한 시기에 만났던 수많은 스타트업과 그리고 게임회사들은 한발 두발 이 기술에 다가서고 있었고 그 동안 어떤 회사들은 보유하고 있는 서버의 숫자의 3년 단위 비용 계획과 아마존 웹 서비스가 제공하는 동일 스펙의 서버 비용을 멋있는 엑셀 차트로 만들어 "아 이거 뭐야 전혀 저렴하지 않잖아" 의 결론을 내고 멀리해 왔다. 

이제 2016년 중반을 지나 말엽으로 가는 마당에 클라우드 도입 자체에 대해 부정적인 의견은 전과 같지 않다. 왜 그럴까. 그것은 애초부터 계산이 불가능했던 ROI 의 효과에 원래 무시되었던 서비스 속도, 확장성, 그리고 자동화를 통한 휴먼 에러의 제거 이런 것들에 대한 가치가 수많은 사례들을 통해 검증되었기 때문이다. 이를테면 3계층 구조의 서비스를 클라우드로 이전하는 방법에 있어 아주 간단하게는 그 모양 그대로 옮기는 것, 주로 지게차를 사용한다는 의미를 가지는 forklift 의 방식을 사용할 때와 이 3계층 구조를 구현 하는데 있어 손쉬운 확장성이 보다 더 낮은 성능의 저렴한 서버를 사용할 수 있도록 하는 구성이 주는 가격적 효과와 같은 것을 깨닫게 되는 것이다. 엔터프라이즈에서는 별로 크게 관심이 없지만, 최근 강력히 대두되는 서버리스와 같은 구조까지 가게 된다면 더 효율적이겠지만 말이다. 

위의 그림처럼 이것이 스타트업과 엔터프라이즈에 대한 문제일 뿐 아니라, 엔터프라이즈 자체도 이제 혁신을 하고 있는 엔터프라이즈와 그렇지 않은 엔터프라이즈로 나뉘고 있다. "Software is eating the world" 라는 말이 나온게 2010여년 즘이고, "Silicon Valley is coming" 이라는 말이 나온건 2015년이다. 이 5년의 차이를 공포로 "인식"하고 있는 J.P. Morgan Chase 같은 회사는 이미 소프트웨어 기술이 그들의 비지니스에 핵심이라는 것을 깨닫고 이 역량 확보를 위한 길에 투자하고 있다. 그리고, 이런 투자는 포츈 500대 기업의 대부분에서 발생하고 있으며, 이들은 아마존과 월마트, 아마존과 메이시 같은 효과에서 아마존 쪽에 서기를 원하는 기업들이다. 그리고 현재 돈을 가지고 있는 기업들이 미래 수익을 놓치지 않기 위해 하고 있는 행동들이기도 하다. 사실, 이런 접근에 최근 한국을 제외한 국가에서 이의를 제기하는 경우는 경험적으로 본적이 거의 없다. 

클라우드 서비스들을 사용이 자유로운 리소스 풀로 사용하는 것은 이제 아주 공통된 개념이다. 당장 하루에 페타바이트씩 쌓이는 데이터를 수용할 수 있는 공간은 여러 방식으로 조달할 수 있겠지만, 별도의 소프트웨어적인 또는 운영적인 노력 없이 바로 사용이 가능한 것은 이미 규모의 경제를 바탕으로 서비스를 제공하고 있는 클라우드 사업자의 서비스를 사용하는 것이 유일한 방법이다. 왜 페타바이트냐, 우린 기가바이트다 라고 하면 이건 이미 엔터프라이즈 규모로 사업을 하고 있지 않거나 그만한 데이터를 모을 수 있는 기술이 없거나 아니면 이전의 운영 방식에 따라서 매일 지우고 있거나일 것이다. 한동안 빅데이터에 대한 가장 큰 거부반응이 우리가 보유한 데이터는 크지 않아요와 비슷하달까. 어쨌든 요점은, 시대는 클라우드 서비스를 리소스 풀로 사용하는 것을 넘어 이 위에 돌아가는 데이터 및 서비스 소프트웨어를 어떻게 만드는가 하는 것에 더 관심이 많다. 즉 프로세서, 메모리, 디스크를 빨리 조달 받는 문제가 해결 되면 이 위에 원래 돌려야 했던 서비스 및 데이터 소프트웨어를 어떻게 처리하는가에 대한 부분의 노력에 관심이 더 많은 시대가 되었다. 아마존 웹 서비스의 사장님인 앤디 제시가 "Cloud is normal" 이라고 말하는데는 여러가지 의미가 있지만, 내맘대로 해석하면 클라우드를 사용하는 것은 기본이라는 말이다. 기본 다음은 무엇인가. 바로, 클라우드 기반의 데이터 운용 및 서비스 소프트웨어 구동, 그것이다. 그리고 그것은 처음부터 그랬듯이, 모든 가치가 있는 곳이다. 

위의 그래프에서 처럼, 엔터프라이즈의 기술 도입 그래프는 빠르게 상승하게 된다. 다만, 이전에 경험을 가진 "세상의 다른 기업"과 동일한 높이를 얼마나 빨리, 그리고 그들이 했던 실패의 반복 없이 어떻게 수행할 수 있을까. 바로 "세상의 다른 기업" 을 넷플릭스나 아마존으로 놓고, "엔터프라이즈"에는 GE를 놓고 보면 된다. 국내의 경우 회사마다 위의 단계가 다 조금씩 다른데, 우리 회사가 "Oh No" 까지 왔다면 이 이야기는 아마 관심이 좀 생기는 이야기가 될 것이라고 예상해 본다. 


뭣이 중헌디 

Value line 이라는 것이 있다. 이것을 대표적으로 설명할 수 있는 것은 바로 "올해 운영체제 튜닝해서 매출 증가를 이루어 회사에서 상 받으신분" 과 같은 질문이다. 대부분의 엔터프라이즈, 뭐 엔터프라이즈 뿐만 아니라 모든 기업은 그 영위하는 서비스와 돈 버는 방법이 있다. 그 서비스의 제공을 위한 운영 체제가 돈을 벌어주는 경우는 없다. 하지만 이것이 중요하지 않다고 할 수 없다. 최신으로 업그레이드 된 운영체제 위에서 견고하게 동작하는 소프트웨어는 강력하다. Value line 은 이것을 누가 어떻게 처리해야 하는지, 그리고 더 깊게는 이런 반복적이지만 쉽게 처리할 수 없었던 것들에 대한 해법이 있다면 과연 사업 성장 및 유지를 위해 어디에 가치 중점을 두어야 하는지에 대한 이야기다. 그리고 이것은 아래와 같은 몇가지 기술 요소들에 대한 고려를 해 볼 필요가 있다. 



첫째로, 그럼 운영체제 업데이트가 서비스 시스템에서 왜 힘들지만 중요한지의 여부다. 답은 간단하다. 위험. 리스크. 운영체제에 긴급한 보안 패치가 필요한 경우, 이 보안 패치를 적용함으로서 서비스에 무슨 문제가 발생할 지 모른다. 정확한 표현으로는, 그 운영체제에서 동작하는 소프트웨어가 이전 버전에서 처럼 제대로 동작할지 안할지를 모른다. 동작하지 않으면 서비스 다운이다. 그리고 이런 종류의 업데이트는 운영체제를 새로 설치하지 않으면 롤백도 쉽지 않다. 그래서 하지 않게 된다. 

하지만 사람들은 방법을 생각해 내게 되는데, 바로 배포 전 테스트를 한다. 머리가 있다면 당연히 사전에 테스트를 한다. 문제는 테스트를 하는 환경과 서비스 하는 환경이 또 다른 모양인 것이다. 사실 테스트 및 운영 환경을 분리하기 본격적으로 시작한 것도 몇년 되지 않는다. '리소스'와 '비용'의 문제 때문에 개발하던 환경이 운영환경이 되었던 사례는 수도 없이 많다. 클라우드는 이런 리소스 문제를 해결 해 왔고, 그래서 각각의 환경을 준비할 수 있었다. 

그렇지만 클라우드를 사용하는 환경임에도 불구하고 버전 업그레이드에 따른 문제는 지속적으로 발생하는데 여기에 가장 중요한 이유는 바로 소프트웨어가 가진 운영체제에 대한 의존성이다. 시스템 라이브러리, 웹 애플리케이션 서버가 제공하는 클래스 패스의 종속성, 그리고 그 시스템  라이브러리가 다시 운영 체제의 커널 버전과 가지는 의존성, 이런 문제들이 발생하고 이는 소프트웨어와 운영체제 및 그에 포함된 기타 라이브러리의 독립적인 업데이트를 보장할 수 없도록 한다. 따라서 각 배포 단계에 항상 서비스 소프트웨어 개발자가 개입하지 않으면 업데이트가 진행되지 않는 사태가 발생하게 되거나, 업데이트 후 문제가 발생하여 화재 진압이 필요하게 되는데 이것은 궁극적으로 업데이트를 꺼리는 환경을 만든다. 

이러한 업데이트를 꺼리게 되는 업무 환경은 사업에 도움이 될 것이 하나도 없다. 그래서, 이런 반복적인 운영 관리 작업을 어떻게 안전하고도 효율적으로 처리할 수 있을지에 대해 고려가 필요하고 이것은 클라우드 서비스가 제공하는 운영체제 템플릿을 교체하는 것 만으로는 여전히 해결되지 않기 때문에 소프트웨어와 운영체제, 그리고 소프트웨어가 사용하는 각종 라이브러리 업데이트 등에 대해 종전과는 다른 방식으로 처리해야 할 필요가 발생한다. 이것이 기본적으로 Immutable artifact 또는 동적 링크보다 static binary 가 대두되는 이유이며, 특정 소프트웨어 버전에 필요한 라이브러리 등에 대해 필요한 버전을 명시해야 하는 이유이기도 하다. 


둘째로 이렇게 빌드된 소프트웨어의 배포에 대한 처리다. 요즘엔 클라우드 종류보다 많은 배포 도구들이 존재한다. 오픈 소스부터 상용에 이르기까지, 선택할 수 있는 도구는 매우 다양하고 각 도구들이 제공하는 범위도 다르다. 이 모든 도구들에 대한 언급 보다는 빌드된 애플리케이션이 인터넷에 연결되어 동작하기 위해서 무엇을 해야 하는가에 대해서 조금 집중해 보기로 하자. 그리고 그것이 세상에서 많이 사용하고 있는 자바를 기준으로 하자. 

자동화 스크립트 또는 도구가 해야 할 일은 먼저 클라우드 서비스에 리소스를 준비하는 것이다. 이것은 보통 가상 머신이다. 가상 머신이 올바르게 준비되어 접근 가능한 상태가 되면, 부트 스트랩이나 또는 ssh 의 방법등을 통해 필요한 패키지를 준비하는데, 예를 들면 아파치 웹 서버나 톰캣과 같은 것이다. 그 준비가 끝나면 이제 젠킨스와 같은 도구에서 빌드된 파일을 전송하여 적절한 디렉토리에 위치시키고 웹 서비스 프로세스를 시작한다. 정상적으로 시작되고, 약간의 테스트가 끝나 동작할 준비가 되면 이 가상 머신을 로드 밸런서에 연결한다. 로드 밸런서가 신규 가상 머신에 대해 정상 동작 여부를 몇번의 테스트를 통해 점검하게 되면 서비스-인 상태가 되어 밸런싱을 수행할 수 있는 상태가 된다. 그리고 필요하다면 이 밸런서에 다시 도메인을 연결하고, 최근 추세에 따라 해당 Zone apex 및 레코드에 대한 TTL 을 짧게 준다. 이게 전부 매뉴얼 스크립트로 구성되어야 하는 것이다. 

하지만 클라우드 서비스들은 서버에 대한 커스텀 템플릿을 만들수 있는 환경을 제공한다. 따라서 매번 새로운 배포를 할 필요가 없이 해당 버전의 소프트웨어가 탑재되고, 톰켓이 이미 설치된 운영 체제를 구성하고 이를 템플릿으로 만들어 추가 웹 애플리케이션 서버가 필요할때 바로 바로 사용한다. 이것은 하나의 immutable artifact 로서 취급될 수 있지만, 문제는 그 제작의 번거로움과 서비스 업데이트 및 릴리즈, 또는 서버에 필요한 설정 변경이 필요할 때마다 새로 만들어 주어야 한다. 심지어 사용해야 하는 원본 운영체제의 버전 업데이트가 반영된 새로운 템플릿이 생기면 여기에 다시 이전에 스크립트로 했던 작업을 수행해야 한다. 그래서 다시 템플릿으로 만들어야 하고, 예를 들어 클라우드 서비스 공급자가 제공하는 오토 스케일 기능이라도 사용하고 있다면 이를 새로운 오토 스케일링 그룹 정책에 반영해 주어야 한다. 하루에 한두번이야 하겠지만, 만약 하루에 서비스가 4천번 업데이트 되는 경우라면 어쩌겠는가. 아니, 그냥 10번만 업데이트 하더라도 이것은 피곤한 일이다. 그리고 이러한 문제는 docker 이미지 생성에도 발생한다. 

언급하고 싶은 문제는 일단 이런 도구들을 다 컨테이너에 넣는것 자체가 약간 비효율이라는 것이다. 하여 스프링 부트(Spring Boot)에서는 스프링을 톰켓에서 구동하는 대신 톰켓을 스프링 부트 애플리케이션에 임베드 하는 방법을 제공한다. 이렇게 Jar 로 빌드된 파일은 java -jar 로 간단하게 실행 가능하다. 당연하지만 SERVER_PORT 와 같은 다양한 옵션 환경 변수를 운영 체제 또는 애플리케이션 시작에 적용할 수 있다는 것이다. java -jar SERVICE-001.jar 커맨드는 컴퓨터를 모르는 우리 어머니도 실행하실 수 있다. 즉, 애플리케이션 레벨에서 immutable artifact 상태로 빌드가 제공되고 이는 JVM만 돌릴 수 있는 환경이라면 동작을 보장하는 방법이 제공 된다는 것이다. 일단 여기에서 회사 위키에 적혀져 있는 500줄짜리 매뉴얼 스크립트를 copy & paste 할 필요가 없어진다. 


이렇게 동작하는 컨테이너 또는 가상 머신에 밸런서를 붙여야 한다. 여기에는 동적 서비스 디스커버리와 마이크로프락시, 그리고 클라이언트간 로드밸런싱의 기법이 오래된 DNS를 대체한다. 강력한 테스트와 한계를 넘나드는 변태적 애플리케이션 아키텍처의 구성으로 유명한 넷플릭스는 이런 도구들을 오픈소스로 제공한다. 서비스 디스커버리엔 유레카(Eureka), 마이크로 프락시 및 API GW 역활에는 줄(Zuul) 및 훼인(이름이 좀 그렇지만, Feign), 그리고 클라이언트간 로드 밸런싱에는 리본(Ribbon) 등이 있다. 유레카는 등록된 애플리케이션에 대한 연결 정보를 서비스 멤버의 모든 인스턴스에 동적으로 공유해 준다. 이렇게 공유된 정보는 API 요청에 따라 동적으로 Zuul 과 같은 도구를 통해 밸런싱 되고 프락싱된다. 아울러, 이 모든 도구들은 스프링 부트의 방법으로 스프링 클라우드 라는 이름으로 제공된다. 이것들은 모두 JVM 위에서 동작하며, Jar 단일 애플리케이션으로서 java -jar 로 구동이 가능하다. 게다가 대부분의 도구는 멀티 데이터센터 레벨로 고가용성 확보가 가능하며, 필요한 경우 암호화 처리 할 수 있다.  

경험상 이러한 동작이 의미하는 바를 개발자 분들께 전달할때, 이게 뭥미 라는 반응을 심심치 않게 본다. 대부분의 경우 고가용성은 사실 애플리케이션의 영역이라기 보다는 운영의 영역인 경우가 많았다. 다른 이야기는 차처하고 나서라도, 위와 같은 도구를 조합해서 사용하게 될때 얻어지는 효과는 기존 운영 영역에서 제공되던 기능들과는 애초에 레벨이 다르다. 예를 들어 넷플릭스의 Zuul 프락시에서는 Canary 테스트가 필요한 경우 특정 API 요청의 일부 트래픽만을 신규 버전의 백엔드에 보낼 수 있다. 즉, 새로운 버전의 배포를 이미 수행해 두고 여기에 동일한 API 요청을 "일부만" 보냄으로서 이게 정상 기능을 하는지 아닌지를 확인할 수 있다. 당연히 이것이 정상이라면 신규 버전을 확장하고 구 버전을 종료한다. 이런 기능이 제공하는 장점은 이런 제로 다운 타임 업데이트 안정성 뿐만 아니라 각종 실험이 가능해지고 이는 더 작은 위험으로 더 많은 일들을 가능하게 한다. 당연하지만, 위에 언급한 스크립트가 따로 필요없는 것은 덤이다. 넷플릭스는 이 도구를 다양한 종류 및 목적으로 트래픽 분배에 사용하고 있으며, 이는 스프링 클라우드로 구현이 되어 있고 따라서 스프링 부트의 사용 방법으로 가져다가 사용이 가능하다. 


셋째로는 최근에 많이 언급되고 있는 컨테이너다. 2013년 초에 다커를 처음 접할 기회가 있었는데, 처음 볼때 아 이거 대박 이라는 생각을 지울 수 없었다. 그 후 몇년뒤, 이건 역시 거대한 흐름을 만들고 있는 도구임에 틀림 없다. 한번 빌드로 다양한 환경에서 구동, 더 효율적인 리소스 사용, 그리고 가상 머신을 신규 배포하는 것에 비해 더 빠른 속도로 확장과 축소가 가능한 점 등등. 그런데 이 부분에 대해 생각할 필요가 있다. Day 1 에 다커는 분명 놀라운 기술이다. Day 2 에 프로덕션 반영을 생각하게 될 정도로. 하지만 현실은 역시 녹록치 않다. 랩탑에서 한두개 올려서 사용하면 분명 대단한데, 일단 수십개, 또는 그 이상 수백개 및 수천개 심지어는 수만개로 돌려야 할때는 어떨까. 현실에서는 많은 것들을 요구한다. 로그의 취합, 적절한 리소스로의 분배, 권한의 관리, 그리고 "업데이트". 예를 들어 하루에 10번 정도 (매우 적은 숫자의) 배포를 수행한다고 하면, 매일 10번 정도의 신규 다커 이미지 생성이 필요하다. 그리고 서비스 별로 약 10-30개 정도의 다커 이미지를 사용하고 있는 중인데 원본 이미지의 업그레이드가 발생하거나 업그레이드를 해야 할 필요가 있을때 이를 모두 새로 이미지로 만들고 또 이 새로운 이미지에서 각 소프트웨어가 무결하게 동작하는지 확인해야 한다. 이런 것들을 지속적으로 유지하다 보면 어느새 현실은 개미지옥. 


따라서 현실적으로 오케스트레이션의 문제를 제외하고 소프트웨어 신규 배포 및 업데이트 만을 놓고 보면 CI 파이프라인 안에 이미지를 동적으로 생성하고 보관해 주는 단계를 구성해 줄 필요가 있다. 즉, 코드가 레포에 올라가고 이렇게 올라간 신규 커밋을 테스트 도구가 받아다가 유닛 테스트 등을 하고 나서 문제가 없이 빌드 되면, 이 빌드된 앱을 다커 이미지로 생성하여 다커 레포로 올리는 단계가 필요하다는 것이다. 물론 RC 관리등의 추가 파이프라인으로 연결할 수 있겠지만, 어쨌든 이런 과정을 현재 수동으로 하고 있다면 근 미래에 이미지 관리에 난항을 겪게 될 것이다. 당연하지만, 여기에는 리모트 로깅, 권한 관리를 위한 툴 등이 빌드된 애플리케이션이 다커 이미지로 생성될때 함께 포함 되어야 한다. 즉, 다소 복잡하지만 정교한 관리가 CI 파이프라인 안에 포함 되어야 한다. 

오케스트레이션 문제를 제외 하지 않으면 문제는 더 복잡해 진다. 물론 다양한 도구들이 나와 있지만 스타트업들 조차 이 다커의 오케스트레이션 구현은 녹록치 않다. 다커의 에코시스템이 발전하는 것은 매우 좋고 선택의 옵션이 다양해 지므로 환영할 일이지만, 현재의 현실 세계에서는 누가 어떻게 이것을 관리하고, 또 다커의 철학인 '한번 빌드로 여러개의 환경에서 구동한다' 를 따라 데이터 센터나 퍼블릭/프라이빗 클라우드에 운영 환경을 준비할 것인가. 물론 각 클라우드 서비스에서는 최근 다커를 운용할 수 있는 환경을 제공한다. 위의 CI 파이프라인과 함께 서비스 업자가 제공하는 환경을 사용한다면 아마도 좋은 접근이 될 것이라고 예상한다. 다만 역시 이 경우에도 언급하고 싶은 것은 과연 이 서비스들에 대한 학습 시간, 누가 배울 것인가, 누가 운영할 것인가, 그리고 서로 다른 서비스가 수백 수천개의 컨테이너를 운용하고 있을때 태그 구분만으로 운영하기에 충분한가, 그리고 이것을 다양한 클라우드 서비스 공급자 별로 제공하는 툴을 따로 배울 것인가 하는 사항들이다. 

클라우드 서비스 공급자가 제공하거나 또는 Chef / Puppet 과 같은 도구들은 물론 인상적이고 훌륭하다. 다만 현장에서 이것들을 최신에 맞게 지속적으로 업데이트 관리해서 배포에 사용하는 경우는... 


넷째로, 마이크로 서비스 이야기를 좀 붙여야 할 것 같다. 마이크로 서비스가 가져다 주는 장점은 서로 관계 없는 기능들이 덩어리 지어 있기 때문에 발생하는 팀간 또는 사람간의 커뮤니케이션과 의존성을 줄이는데 그 목적이 있다. 이를 통해 코드의 양이 적어지고 따라서 운영 관리 및 신규 개발해야 하는 노력이 작아진다. 이는 더 빠른 개발과 배포를 가능하게 한다는 장점이 생기며, 아마존이나 넷플릭스와 같은 회사들이 취하고 있는 방법이다. 하지만 질문도 동시에 생긴다. 외부 요청은 하나인데 내부 서비스 100개에 발생하는 요청 현상, 즉 필연적으로 발생하는 fan out 은 어떻게 해결할 것인가. 현재 조인 관계로 복잡하게 얽힌 데이터 모델을 가진 데이터베이스 안에서 특정 기능들이 스토어드 프로시져로 기능하고 있는 것들은 어떻게 분산해 낼 것인가. 제로 다운타임 업데이트를 데이터베이스 레벨에서 어떻게 처리할 것인가. 각 서비스에 대한 보안 또는 싱글 사인 온등은 어떻게 처리할 것인가. 각 서비스는 서로 다른 개발 스택 또는 프레임 워크를 선택하는것이 옳은 것인가. 운영 관리 방법은 현재도 요청이 많은데 이게 마이크로 서비스로 분산되면 내가 할 일은 더 많아지는게 아닌가. 사람도 안뽑아 주는데. 

먼저 확실하게 말하고 싶은건, 언급한 모든 내용들은 해법이 있고 이는 소프트웨어 아키텍처 및 서비스 아키텍처로 접근 가능한 모델들이 존재한다. 그리고 이러한 모델들에 대해 분명히 학습해 둘 필요가 있고, 이런 경험이 뒷받침 되어야 진정 마이크로 서비스에 대한 접근이 가능할 것이다. 한가지 더 언급하고 싶은 것은, 이런 기법이나 구조를 구현하기 위한 도구들이 넷플릭스에서 만들어 둔 것이 많이 있고 이를 스프링 클라우드에 반영해 둔 것이 많다는 것이다. 

먼저 fan out의 경우, 가능하다면 다운이 발생하지 않는 거대한 캐시풀을 운용하는 방법이 있다. 거대한 캐시풀 이라는 말이 의미하는 것은 예를 들면 아파치 Geode 와 같은 인-메모리-데이터 그리드를 사용하거나, 넷플릭스의 EvCache 를 사용하거나 하는 방법으로 다수의 데이터센터에 존재하는 서버 리소스의 메모리에 중복 저장하여 요청하여 사용하는 방법이다. 예를 들면 수천만명이 로그인을 하고 난 후 발급 받은 토큰으로 다시 다른 마이크로 서비스에 접근이 필요할때 이 검증을 위해 다시 유저 서비스로 접근하지 않고 이 캐시를 사용하는 방법이 있을 수 있다. 이러한 캐시는 비단 캐시의 용도로 사용되는 것 뿐만 아니라 전체 서비스 내에서 일관성을 유지하는 방법으로 사용될 수도 있다. 인 메모리에 저장하는 방법 외에도 분산된 트랜젝션의 로깅과 이를 바탕으로 한 플레이백이 필요한 경우, 이를 테면 이벤트 소싱과 같은 방법을 사용한다면 NoSQL 이나 카프카와 같은 스트림 도구를 사용할 수도 있다. 


조인의 관계는 마이크로 서비스 구조에서는 보통 서비스간 요청으로 처리한다. 데이터베이스 안에서 조인으로 처리하던 것들을 다른 서비스에 대한 요청으로 바꾸는 것이다. 또는 반드시 조인이 필요한 경우라고 하면, 예를 들어 게임이라면 캐릭터와 아이템의 상관 관계와 같은 것들은 아마존의 다이나모 디비와 같은 도구를 사용하는 방법으로 바꿀 수 있다. 세컨드리 인덱스 구성의 변경을 통해 검색 조건에 따라 데이터를 저장함으로서 조인 관계에 대한 극복이 가능하다. 즉, 아이템으로 캐릭터를 검색할 수 있고, 캐릭터로 아이템을 검색해야 하는 조건을 굳이 조인이 아니라 인덱싱으로 처리가 가능하다는 것이다. 그리고 이런 다이나모 디비와 같은 도구의 구현을 참조한다면, 다른 NoSQL 데이터베이스를 사용할 수도 있다. 이런 형태의 데이터 베이스에 대한 구조 및 컨셉은 아마존의 CTO인 버너 보겔스박사(Dr. Werner Vogels) 가 공저한 논문 Dynamo 를 참조하면 더 자세한 정보를 얻을 수 있다. 링크는 여기. (http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf) 그리고 이 논문의 아마존 버전이 다이나모 디비이며, 넷플릭스 버전의 구현이 Dynomite 다. https://github.com/Netflix/dynomite 

스토어드 프로시저와 같은 방법으로 데이터베이스 내에서 순차적으로 처리되고, 문제가 발생한 경우 롤백이 필요한 트랜젝션의 구분에 대해서는 자주 사용하는 예인 주문, 결재, 배송을 예로 들 수 있겠다. 여기에는 아마존의 Simple Work Flow 와 같은 도구의 컨셉이 사용될 수 있다. 즉 주문 서비스, 결재 서비스, 배송 서비스는 각각의 데이터 저장소를 가진 각각의 서비스로 별도로 구현되며, 이는 상품의 주문은 주문 서비스가 처리한다. 주문 서비스는 예를 들면 주문 데이터 저장을 위해 MongoDB 와 같은 저장소를 사용하고, 이를 RabbitMQ 나 SQS 같은 큐에 주문이 들어왔음을 알린다. 그럼 이 큐를 subscribe 하고 있는 "다음 프로세스를 담당하는 마이크로 서비스"인 결재 서비스는 기입된 정보를 바탕으로 데이터 저장소 없이 관계된 신용카드 트랜젝션을 처리한다. 이것이 문제 없이 끝나면 다시 RabbitMQ 나 SQS의 별도 채널을 이용하여 주문이 완료 되었다는 메세지와 함께 내용을 큐로 전달한다. 그러면 다시 배송을 담당하는 마이크로 서비스는 이 큐의 내용을 바탕으로 주문 정보를 작성하는 구조가 된다. 각 단계의 마이크로 서비스들은 로그 어그리게이션 또는 로그 스트림의 방법을 통해 처리 결과 및 에러를 취합하고, 자신의 프로세스에 이상이 발생하면 그 이상에 대해 다시 큐에 기록한다. 그러면 알림 서비스는 이 큐에 기록된 에러를 바탕으로 고객에게 어느 단계에서 문제가 발생했으니 주문을 다시 확인하라 라는 메세지를 보낼 수 있다. 

위에 설명한 방법들은 몇가지 기본적인 처리 방법들이다. 그리고 서비스에 따라 이것이 요청을 받은 즉시 처리되어야 하는지 아니면 의미 있는 시간 내에 처리가 되면 되는지에 따라 선택적으로 사용할 수 있다. 그리고 이런 것들이 가능한 이유는 클라우드 기반에서 매우 확장성 있는 메세지 큐나 캐시, 또는 데이터베이스를 구현할 수 있기 때문이다. 또한, 위와 같은 방법들은 전체 마이크로 서비스에 천편 일률적으로 사용되는 것이 아니다. 관계형 데이터베이스로 모든것을 처리하는 것이 아닌, 필요한 상황에 맞는 스토리지를 각각의 서비스가 해결할 문제에 맞도록 선택해서 사용하는 것이다. 넷플릭스는 카산드라를 많이 사용하지만, 그것으로 모든것을 처리하는 대신 EvCache 와 같은 도구를 개발했고, Dynomite 와 같은 도구도 필요했다. 중요한 것은, 마이크로 서비스는 이런 내용을 아주 기본으로 각각의 서비스를 만들고 이 서비스들에 대한 변경을 빠르게 해야 한다는 것이다. 만약 서비스를 잘못 찢어내어서 불필요한 중복이 발생했다면 이를 다시 없애고 다른 형태로 서비스에 반영할 수 있어야 하는 것이지, 무슨 처음 부터 역할을 다 구분해 놓고 팀에 쪼개서 할당하면 구현이 될거라는 방식은 절대 동작하지 않는다. 그리고 마이크로 서비스에 대한 접근에서 클라우드 오퍼레이션에 대한 이해, 즉 운영체제의 업그레이드, 라이브러리의 업그레이드 및 트러블 슈팅등과 같은 방법이 제공 되지 않는다면 이것은 분명 오퍼레이션 비용에 대한 수직 상승을 불러올 것이다. 클라우드 파운더리가 가지는 핵심 장점 중 하나가 여기에 있다. 

마이크로 서비스에 대해서 마지막으로 하고 싶은 말은, 언제 해야 하는가 이다. 기존의 모놀리틱 방식으로 개발된 애플리케이션이 충분히 작다면 마이크로 서비스를 해야 할 이유가 없다. 다시 이를 좀더 엄밀히 말하자면, 애자일 개발 방법을 이미 사용하고 있는 상태에서 해당 서비스를 개발하는 팀의 인력이 바뀌거나, 누군가 슬럼프가 갑자기 오거나 하는 별다른 문제가 없는데 속도가 떨어지고 있다면 이때를 기존 서비스에 분리가 필요한 시점이라고 볼 수 있다. 언제 무엇을 해야하는지에 대한 결정은 반드시 데이터 지표가 있어야 한다고 생각한다. 


위에 언급한 내용들에 대해 별도의 견해나 해법이 있을 수 있다. 이 글을 쓰고 있는 목적은 순전히 경험의 공유이며 이것들이 실제로 동작하는 서비스가 있고 또 기존의 서비스에서 다운타임 없이 마이그레이션 할 수 있는 방법도 있다. 그것이 바로 클라우드의 매직이 아닌가. 그리고 우리에게 필요한 것은 이런것에 집중하는 것이지, 웹 애플리케이션 설정과 업그레이드가 아니라는 것이다. 


그래서 결론은 (Pivotal) 

모든것은 비지니스다. 멀티 데이터센터 또는 멀티 클라우드를 하려는 이유가 무엇인가. 사업적으로 무중단이다. 마이크로 서비스로 구성된 넷플릭스에서 서킷 브레이커 로직이 필요한 것은 무엇인가. 특정 장애의 고립을 통한 전체 서비스 장애 확산 방지다. 데이터베이스 클러스터링을 통해 아무리 견고하게 구성해도 그것이 하나의 덩어리로 되어 있다면 서비스가 데이터베이스 장애를 데이터베이스 만으로 고립할 수 있는가? 아닐거다. 따라서 수많은 리소스를 쉽게 조달 받을 수 있는 클라우드를 기반으로 서비스에 필요한 리소스를 효율적으로 사용하고 그 위에 클라우드에 맞게 기능을 하는 서비스 소프트웨어를 얹는 것이 바로 클라우드 네이티브의 본질이다. 

마지막으로 클라우드 파운더리에 대해 언급하고 싶다. 현재 클라우드 서비스의 도입과 사용에 대해서 열기가 뜨겁다. 대부분의 경우 클라우드를 배운다는 것은 어렵다. 퍼블릭 서비스들은 각자의 운영 방식이 있고 인터페이스가 다르고 사용하는 언어가 다르다. 프라이빗 서비스 역시 마찬가지다. 이는 모든이에게 모든것을 알게하는 동시에 풀스택 개발자라는 말을 탄생시켰다고 해도 과언이 아니다. 모든이가 모든것을 아는것이 과연 가능한 일인가. 클라우드 파운드리는 이 문제를 해결한다. 개발자가 다커를 배울 필요가 없고 운영자가 개발자의 요청에 의해 데이터베이스와 네트워크를 준비하고 업데이트 때문에 곧 다가올 추석에 밤 새는 일을 없도록 한다. 위에 언급한 대부분의 운영적 문제로 발생하는 그리고 반복적으로 발생하기 때문에 새로운 서비스의 시장 공개를 더디게 하는 문제를 해결한다. 그리고 이것은, 각 클라우드 서비스를 별도로 배울 필요가 없도록 하기도 한다. Multi-AZ 에 대한 개념은 필요하지만 그것이 꼭 Multi-AZ 라는 이름으로 특정 서비스에서 사용 된다는 것을 학습하는 것은 필요 이상의 노력이다. 뒤쳐져서 갈길 바쁜 엔터프라이즈에게 스프링과 클라우드 파운더리는 value line 아래의 일에서 조직을 해방시킨다. 

쓰다보니 간만에 굉장히 장문의 글의 되었지만, 어쨌든 다음의 내용을 검색을 통해 알아보기를 강권한다. 그래도 아직 못다쓴 내용은 나중에 책으로 더. 새벽에 졸릴때 썼으므로 문장이 좀 이상한 것들은 양해를 구합니다. ㅠㅡ ㅠ 


1. 넷플릭스 오픈소스 및 넷플릭스 테크 블로그 

2. http://concourse.ci  http://ci.concourse.ci 

3. Pivotal Cloud Foundry 

4. http://start.spring.io  http://cloud.spring.io 

5. Micro services

6. https://www.youtube.com/watch?v=GTnRl_BIkzc  

7. https://run.pivotal.io 

8. SpringOne Platform 2016 videos https://www.youtube.com/watch?v=xdw_9dADM-4&list=PLAdzTan_eSPQ1fuLSBhyB4eEZF7JQM0Mx


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

저작자 표시 비영리
신고

Deploy your application to every cloud - Azure

Techs


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


제목과 같은 내용의 설명을 원하는 경우라면 섹션 4로 바로 점프. 



1. 멀티 클라우드, 그리고 인프라? 


클라우드에 관심이 있다면 멀티 클라우드 라는 말을 한번쯤은 들어 보았을 것이다. AWS에 오토 스케일링 이라는 기능조차 없던 시절, RightScale 이라는 회사가 있었다. 이 회사는 인프라 레벨에서 템플릿의 구성과 배포를 멀티 클라우드에 할 수 있도록 해 주었던 기업이다. 물론 대부분의 인스턴스 consume 은 AWS에서 발생했다고 알고 있고, 그리고 전술했듯 AWS의 오토스케일링이 없던 시절 AWS의 API를 와 별도의 모니터링 에이전트를 사용해 부하를 측정, 특정 시점에 정밀한 오토스케일링의 구현이 이 회사가 가졌던 장점이었다. 사실 생각해 보면 매력적인 제안인데, 단 하나의 클라우드 서비스 공급자를 사용하는 것이 아닌 다양한 클라우드 공급자를 탄력적으로 사용함으로서 부하 및 장애에 대해 효율적으로 분산할 수 있다는 개념은 지금도 구성만 잘 할 수 있다면 뛰어난 운영 전략이 될 수 있다. 



http://www.rightscale.com/


다만 현재 이 회사가 오늘날 그다지 성공적(?) 이라고 말하기 힘든 이유는, 당시의 이 회사의 주요 자금원이었던 오토스케일링 기능이 AWS의 EC2에 기본 기능으로 제공이 되면서 부터였고, 또한 당시의 다른 클라우드 서비스 공급자들의 서비스가 AWS에 비해 매력적이다 라고 말하기는 다소 힘든 상황이었기 때문이다. 사실 말이야 바른말이지 몇년 전 까지만 해도 Virtual Machine 의 구동 및 관리 자체가 힘든 서비스들은 널리고 널렸었다. 따라서 이 오토스케일링의 매력 저하와 멀티 클라우드라는 컨셉 두개가 모두 잘 동작하지 않으면서 전략적으로 힘든 위기 상황을 맞이 하지 않았나 싶기도 하고 말이다. 물론 이 외에도 다양한 요인이 있었겠지만, 가장 핵심적인 사안은 이것 두가지가 아니었을까 한다. 


시대는 이제 가상화를 넘어 컨테이너를 향하고 있다. 그것이 팬시하건 좋건 나쁘건 그리고 현 상태에서 그 사용의 방법과 범위를 오인하는 사람들이 많건 적건 어쨌든 컨테이너는 Docker를 중심으로 빠르게 발전하고 있다. 이 말인 즉 인프라 레벨에서의 멀티 클라우드 사용에 장점이 있었던 RightScale은 앞으로 조금 더 힘들어 지지 않을까 하는 개인적 견해와 맞물려, '인프라'만으로서의 장점은 이제 원한다면 바로 어디에나 배포할 수 있는 컨테이너가 있기 때문이다. 


인프라 레벨에서의 접근에는 사실 다양한 선택지가 있을 수 있다. 하지만 그 모든 선택지에는 각 클라우드 서비스에 대해 아주 잘 알아야 실제 서비스에 도입 할 수 있다는 이면이 숨어있기도 하다. Docker 를 사용하면 물론 이론적으로는, 그리고 실제적으로도 다양한 클라우드 서비스 공급자 또는 심지어 데이터센터에 구축 가능한 환경에도 애플리케이션을 배포할 수 있다. 하지만 이 애플리케이션의 배포 주기가 매우 자주 발생한다면, 그리고 이걸 다양한 클라우드 위에서 동작시켜야 한다면 추가적으로 처리해야 할 일이 보통 많은것이 아니다. 이 '보통 많은 것이 아닌' 부분을 처리하기 위해 Docker 는 다양한 eco를 지속적으로 개발 및 개선하고 있지만, 프로덕션 레벨에서 사용하고 있다는 엔지니어링 블로그를 본 적이 별로 없다. 


정리해 보면, 컨테이너의 장점은 분명 '플랫폼과 상관없이'에 있지만 그 프로덕션 레벨에서의 구현이 기술력 높은 회사라고 하더라도 아직 많지 않다 라고 할 수 있는 것이다. 각 클라우드 서비스 공급자에서 docker 를 지원하잖아요 라고 말은 할 수 있겠지만, 그래서 그 docker image 를 각 클라우드에 직접 배포하고 동작하는 환경을 만들겠다는것은, 완전히 다른 이야기라는 점이다. 아, 물론 하지 말라는 말 아니다. 시간과 기술과 환경이 허락하는 한 하고 싶으면 할 수 있다. 대한민국은 기술 스택 선택의 자유가 있는 나라니까. 



2. 컨테이너가 필요한거야 docker가 필요한거야? 


먼저 이 블로그 포스팅에서의 컨테이너 사용의 언급 범위는 '애플리케이션이 동작하는' 부분만을 포함한다. 무슨 말인고 하니, '서비스를 동작하기 위한 용도'로서의 컨테이너 기술은 제외한다. MySQL이나 카산드라, PgSQL, 하둡 스파크 기타 등등의 수많은 서비스들을 컨테이너에 동작시키고자 하는 시도가 많이 있는줄로 안다. 하지만 여기서는 애플리케이션을 동작시키기 위한, 이를테면 NodeJS, Spring, Java, PHP, Python, Go, Ruby, Linux binary, .NET 과 같은 도구로 제작된 것들 말이다. 





특정 버전의 애플리케이션의 라이프사이클을 살펴보면, 먼저 프로덕트 매니저를 통해 해당 기능의 구현 및 추가가 요구된다. 이는 이슈 트래커를 통해 등록되고, 각자 조직의 입맞에 맞게 구성되어 일감으로 엔지니어에게 할당된다. 이렇게 할당된 일감은 코드로 구현되고, 그것이 다른 사람으로 이루어진 팀이건 자동화 된 도구건 어쨌든 테스트를 거쳐 다음번 릴리즈 배포를 위해 준비된다. 릴리즈 타이밍이 오면, 그 동안 차곡 차곡 모아온 기능들의 커밋을 주워담아 프로덕션에 배포한다. 그렇게 배포된 버전은 다음번 릴리즈가 오기 전까지 열심히 동작하다가, 때가 오면 다음 버전에 그 자리를 물려주고 은퇴한다. 


컨테이너의 사용은 먼저 개발자의 랩탑에서 시작될 수 있다. 개발자는 구현 시점에서 컨테이너를 사용한다. 이것이 잘 동작하려면 지난 버전의 애플리케이션 코드를 바탕으로 내가 개발하고자 하는 기능을 지속적으로 구현 및 테스트를 시도한다. 따라서 랩탑에 컨테이너 구동의 환경이 필요하다. 개발자 스스로 테스트도 하지 않고 배포할 수야 없지 않은가 말이다. 두번째로, 만약 테스트를 자동화 구성했다면 신규로 코드 저장소에 반영된 코드를 가져다가 지정한 테스트 작업을 돌릴 것이다. 아니면 별도의 빌드 작업이 여기서 처리 될 수도 있겠다. 새로 업데이트 된 기능이 반영된 커밋을 가져다가 지지고 볶고 테스트 하는 것을 VM으로 하면 그거 제법 돈 낭비일 수 있다. 개발팀이 하나 있거나 하루에 두세개 코드가 신규로 생성되고 테스트 된다고 하면야 그것이 무슨 상관이겠냐마는, 하루에 십수개, 또는 수십개의 팀이 지속적으로 코드를 생성해 내고 이렇게 생성된 코드가 지속적으로 빌드 되고 테스트 되는 환경이라면 VM은 분명히 낭비다. 특정 클라우드 공급자를 사용하는 경우라면 시간당 리소스 사용 비용을 지불해야 할 것인데, 이것이 매 테스트마다 새로 켜지고 테스트 하고 꺼지고 한다면 돈이 쏠쏠하게 요구된다. 그래서 컨테이너를 쓰면 좋다. 테스트 및 빌드에서 컨테이너를 사용하는 것은 사실 좀 쿨한 아이디어라고 할 수 있다. 따라서 테스트 환경을 어떻게 컨테이너로 구성해야 하는지에 대한 아이디어와 또, 구현이 필요하다. 마지막으로는 서비스의 배포인데, 당연한 말이지만 원하는 클라우드 사업자 환경에 컨테이너 기반의 배포 환경을 구성해야 한다. 물론 그것이 꼭 컨테이너가 되어야 하는가에 대한 이의가 있을 수 있겠지만, 만약 멀티 클라우드 라는 꼭지를 생각했다면 반드시 docker를 함께 생각하고 있을 것이라고 예상 되므로, 그렇다고 할 수 있다. 그래서 다시 프로덕션 환경에 어쨌든 docker를 준비한다. 



https://bitcontainer.wordpress.com/2015/09/18/scaling-microservices-with-docker-compose-interlock-and-haproxynginx/

코드를 쓸 것인가 인프라 놀이를 할 것인가. 그것이 문제로다. 10초만 봐도 질문이 10개는 생김. 



한문단이 매우 길었다. 어쨌든, 이 글을 읽고 계신 분이 docker 를 매우 사랑한다면 위에 말한 문단의 사이클과 각 단계에서 필요한 구현에 대해 매핑이 금방 이루어질 것이라고 믿어 의심치 않는다. 이 의심치 않는 부분에 있어, 몇가지의 질문에 대해 생각해 보면 어떨까 싶다. 그것은 첫째로, 만약 전체 서비스 시스템 수준의 라이브러리 업데이트가 필요한 상황은 어떻게 대처해야 할 것인가, 이를테면 CVE와 같은 것들 말이다. 두번째로, 지속적으로 발생하는 수많은 애플리케이션의 커밋 별로 이미지를 제작할 것인가. 그렇지 않다면 그 이미지와 애플리케이션 업데이트의 상관 관계는 어떻게 되는가. 셋째로, 애플리케이션이 녹아있는 docker 이미지가 신규로 배포되거나 서비스에서 삭제 되었을때, 서비스-인, 서비스-아웃 처리는 어떻게 할 것인가. 만약 HAproxy 를 사용할 것이라고 답한다면, 매번 오토스케일링 트리거로 인해 이벤트가 발생했을때 마다 설정을 변경하고, 서비스를 리로드 할 것인가. 넷째, docker 이미지 원본이 변경되어야 할 필요가 있을 경우, 기존 배포된 컨테이너들은 어떻게 처리할 것인가. 이를테면 Go_lang의 alpine 버전을 사용하다가 의존성, 보안, 기타 등등의 문제로 업데이트가 필요한 경우에는 어떻게 대처할 것인가. 다섯째, 실제로 docker를 AWS, OpenStack, Azure 등 다양한 환경에 프로덕션에 올릴 것이라면 앞서 말한 네가지를 역시 다양한 프로덕션에 준비해야 할텐데 실제 구현까지 얼마나 걸리겠는가. 


이의가 있을 수 있다. 처리하는 기술이 있을 것이라고 말하고 싶을 것이라는 것도 잘 안다. 그리고 필드에서 실제로 내가 듣는 답변은, 어쨌든 우리의 to be는 거기에 있기 때문에 가야 한다고 말한다. 그래서 when 의 질문과 함께, how 를 함께 던지면 그 답변이 요원한 것도 항상 자주 목도하는 것이기도 하다. 



3. Tracker - Github - Concourse - Cloud Foundry 의 링크 


본 블로그에서 여러번 소개하긴 했지만, 위의 체인이 Pivotal Labs 에서 사용하고 있는 방법이다. 이들 중 Concourse 와 Cloud Foundry 는 Docker 를 지원한다. 그리고 Cloud Foundry 는, docker 가 시장에 풀리기 이전부터 lxc 를 사용한 컨테이너를 사용해 왔으며, docker 가 없더라도 컨테이너 사용성을 제공한다. 뭔말이냐면, 개발자는 코드 저장소에 commit 만 하면 클라우드에서 컨테이너로 알아서 돌려준다는 말이다. 테스트 및 빌드 도구로 사용할 수 있는 Concourse 는 docker 를 이미 지원한다. 다양한 스크립트를 제작하고, 빌드, 테스트, 배포 파이프라인을 만들어 자동화 테스트를 구현하는데 이미 docker 를 사용할 수 있도록 제공 한다는 말이다. 어쨌든 이 체인에 대한 연동은 지난번 포스트에서 설명 했으므로 더 깊이 가지는 않기로 한다. 


위에서 제시한 다양한 질문에 대한 답으로, 아래와 같은 환경을 상상해 보기로 한다. 이슈 트래커인 피보탈 트래커에서 일감이 생성된다. 생성된 일감을 코드로 만든다. 만들어진 코드는 코드 저장소에 업로드 된다. 업로드 된 코드는 Concourse 도구를 통해 docker 기반의 빌드 테스트, 배포 작업을 한다. 테스트 환경에 배포까지 완료가 되면, 일감을 할당한 사람이 해당 기능이 잘 동작하는지 리뷰한다. 잘 돌아가면 승인하고, 승인된 코드는 다음번 릴리즈에 반영되도록 추가된다. 그리고 다음번 릴리즈의 배포는 특정 시점에 역시 Concourse 에 구성된 '프로덕션 배포 파이프라인' 을 통해 Cloud Foundry 에 배포된다. 





개발자는 랩탑에 컨테이너 구동을 위한 환경을 구성할 이유가 없다. 안그래도 설치할 거 많은데 docker 건 lxc 건 그런 구성환경 docker 개발자가 아니라면 설치할 필요가 애초에 없다. 그냥 스프링이건 노드건 루비건 파이썬이건 원하는 개발 환경을 준비하면 된다. 그렇게 커밋된 코드는 데이터센터나 클라우드 환경에서 테스트 된다. 그리고 테스트 된 코드는 데이터 센터건 AWS, Azure, OpenStack 어디든 배포된다. 각 환경에 수많은 개발자들이 한꺼번에 커밋하더라도 별 문제 없이 업데이트 된 코드는 각각 가져다가 테스트 된다. 공장의 라인이 돌아가듯, 일단 커밋되면 나머지는 빙글빙글 돌아간다는 말이다. 그것이 가능하도록 하는 것이 바로 이 체인이다. 


구성과 배포에는 얼마나 시간이 걸리나. Cloud Foundry OSS 버전이라면 아마도 공부도 좀 하고, 복잡한 bosh 도 공부하고, 몇번 설치 실패도 경험하고 하면 보통 한달 정도면 구현 하는 것 같다. 물론 그 한달은 보통 하나의 클라우드 서비스 공급자에 제한된다. 이를테면 AWS에 배포 방법을 알게 되었다고 해서 Azure에 당장 똑같이 할 수 있는 것은 아닐 것이다. 완전 다르지는 않지만 별도의 설정이 필요하고, 관리 방법에 대해 학습할 필요가 있다. 만약 Pivotal Cloud Foundry 의 상용 버전이라면, OpenStack, AWS, Azure 등의 환경 배포에 1일-3일 정도면 끝난다. 필요한 다른 다양한 데이터 서비스, 이를테면 MySQL이라던가, PgSQL, Redis, RabbitMQ 등등등의 도구와 함께. 



https://ritazh.com/deploy-and-run-concourse-ci-on-azure-2fc9fec1f8a8#.zc3cnssdj



Concourse 를 사용한 테스트 파이프 라인의 구현 역시 어렵다고 보기는 힘들다. 오히려 어려운것은 테스트 자동화 그 자체라고 볼 수 있는데, 이것은 조직의 DevOps들이 지속적인 경험을 통해 테스트 방법을 개선해 갈 수 있다. 그리고 이런 테스트들은 보통 해당 서비스의 유지 기간과 함께 지속적으로 증가하기 때문에, 시간이 지날수록 견고한 테스트 파이프라인을 구성할 수 있다는 장점이 있다. 자주 받는 질문이 꼭 사람이 테스트 해야 하는것은 어떻게 해요 인데, Pivotal Labs 에서는 이것이 코딩을 통한 구현 단계에서 확인 된다. 두사람이 앉아 개발하고 새로운 코드에는 반드시 테스트를 위한 코드가 따라 붙는다. 여기에는 현장에서 사용되는 다양한 방법과 룰이 있는데, 이런 것들이 바로 조직이 세월이 지나며 쌓아야 하는 기술 노하우라고 볼 수 있다. 아울러 각 서비스 별로, 각 회사별로 테스트 항목이 같은 것도 있지만 다른 부분도 많기 때문에, 어쨌든 시간을 들여 견고하게 만들어야 한다고 볼 수 있다. 뭐 썰이 길었지만, 정리하면 이 컨테이너 기반 파이프라인 환경을 사용하기 위한 준비 역시 1일-1주일 정도면 구성한다. 나머지는 코드의 영역이다. 


'언제까지' 는 아마 지겹도록 듣는 말일 것이다. 특정 클라우드 서비스 공급자에 종속을 받고 싶지 않다는 것은 그 나름대로 타당한 이유라고 볼 수 있다. 현재로서는 거대한 여당 하나가 있는데, 그 여당이 매우 참 잘하고 있다. 운영도, 개발도, 그리고 심지어 고객 응대 방법과 규모 및 가격 요소까지 두루 훌륭한 여당이다. 반대로 다수의 야당이 존재하는데, 처음 시작할때도 언급 했지만 지난 세월 동안 많은 발전을 이룩하여 이제 많은 서비스들이 사용에 불편함이 없는 정도로 제공되고 있는 것으로 보인다. 이 말에 주의해야 할 필요가 있는데, 클라우드 서비스 공급자의 선택이 단일화 되어야 하는 경우와 다수의 클라우드 서비스 공급자를 선택해야 하는 경우는 다르다. 단일 서비스 공급자 선택시에도 중요하지만, 다수 서비스 공급자를 함께 사용할때의 전체 아키텍처는 도메인 부터 스토리지 레벨까지 준비해야 할 것이 많다. 즉, 멀티가 훨씬 복잡한 작업이 될 수 있지만, 그것을 잘 준비할 수 있다면 - 바로 이부 부분이 PCF/CF의 매력 - 좀 아름 다울걸. 


Concourse 를 Azure 에서 사용하고 싶다면 여기 링크를. - https://ritazh.com/deploy-and-run-concourse-ci-on-azure-2fc9fec1f8a8#.zc3cnssdj  AWS나 OpenStack 등에서 사용하고 싶은 경우에도 검색을 쌔우면 금방 나옴. 



4. Pivotal Cloud Foundry on Microsoft Azure 


사실은 이 부분을 간단하게 포스팅 하고 자려고 했는데 망했다. 사설이 매우 길었다. 내 손꾸락도 노동을 많이... 


Amazon Web Services 에서 Cloud Foundry 를 동작하는 것은 사실 쉬운일이다. 그것이 오픈소스건, 상용 버전이건간에 관계없이 다양한 경험들이 있고, 조금 찾아보면 - 물론 날짜가 지나 유효성이 떨어지는 답변도 많지만 - 어쨌든 레퍼런스나 해답에 대한 아이디어를 얻을곳은 많다. 그리고 특히 상용 버전은 https://network.pivotal.io 에서 가입후 그냥 다운로드 받아서 문서대로 따라해 보면 쉽다. 문서 링크는 여기. https://docs.pivotal.io/pivotalcf/customizing/cloudform.html 


최근 Pivotal 과 Microsoft 는 Pivotal Cloud Foundry 를 Azure 의 Marketplace 에 배치하고, PoC 를 위한 용도로 편리하게 사용할 수 있도록 제공하고 있다. 따라서 Azure 의 고객이라면 누구나 쉽게 PCF 를 준비하고, 함께 제공되는 몇가지 데이터서비스와 함께 파일럿으로 사용해 볼 수 있겠다. 그리고 이 부분에서는 어떻게 하면 설치가 가능한지, 물론 영문 문서가 있기는 하지만 단계별로 좀 쉽게 설명 하고자 한다. 원하는 분들은 위의 1~3 섹션에서 언급되었던 '컨테이너 기반의 오케스트레이션', '코드를 커밋하면 클라우드위에서 컨테이너로 동작하는', 및 기타 등등 로깅 등의 다양한 기능을 Azure 위에서 활용할 수 있는데 테스트로 사용해 볼 수 있겠다. 


Pivotal 이 제공하는 다양한 서비스들은 PCF를 포함하여 bosh 라는 설치 도구를 사용하게 되어 있다. bosh 에는 CPI 라는 부분이 존재하는데, 이는 Cloud Provider Interface 의 약자로 보면 된다. 그리고 이 bosh 자체는 오픈소스 프로젝트이며, Pivotal 이 주도하기는 하지만 CPI 와 같은 인터페이스 부분은 각 클라우드 서비스 공급자들이 참여한다. 이는 Microsoft Azure 의 경우에도 마찬가지며, 아래의 github 그래프를 보면 AdelHu 씨와 Bin Xia 씨가 수고해 주고 있음을 확인 가능하다. https://github.com/cloudfoundry-incubator/bosh-azure-cpi-release/graphs/contributors 그래서 뭔말이냐고? Microsoft 가 Cloud Foundry 발전에 이바지하고 있다는 것. 


다시한번 언급하지만, 상용에서의 멀티 클라우드 사용을 위해 PCF를 AWS, Azure, OpenStack 과 같은 환경에 준비하는 경우에는 도메인부터 스토리지까지 저와 함께 이야기 하시면 됩니다. (쿨럭..) 



아무튼 고고씡. 



a. 사전 준비 사항. 

- Microsoft Azure account : 가입해야 한다. 당삼 빠따루. 카드 정보 필요하다. 으헝 

- Subscription : 가입 후에는 프리로 사용할건지, msdn 플랜을 사용할 것인지, 아니면 사용한 만큼 지불할 것인지 등의 옵션을 선택해야 한다. 본인의 경우 마이크로소프트의 신현석 차장님께서 지원을 해 주셨다. 소주 사야 함. 

- https://network.pivotal.io 의 계정. 없다면 그냥 가입하면 된다. 

- 매뉴얼 :  https://docs.pivotal.io/pivotalcf/customizing/pcf_azure.html 

- Core 리밋 해제 요청 : https://portal.azure.com 에 로그인 하면 대시보드가 나타나는데, 여기서 도움말 + 지원을 클릭하면 아래와 같은 화면을 볼 수 있다. 



AWS와는 다르게 화면이 좀 이쁘다. 리소스 사용의 컨셉이 약간 다르기 때문에 AWS web console 이 편리한 분들께는 아마 처음에 매우 낮설지도 모르겠다. 어쨌든 새 지원 요청을 누르면 오른쪽에 기본 사항이 나타나고, 만약 한글이라면 '할당량' 을 선택하고, 할당량 유형에서 '구독당 코어' 를 선택한다. 




Azure 를 전문으로 하시는 분들은 알겠지만, 본 PCF의 Azure 배포는 Marketplace 를 사용한다. 이 경우 리소스 그룹으로 배포되므로 배포 모델에서 '리소스 관리자'를 선택하였다. 심각도의 경우 각 지원 요청이 비지니스에 미치는 영향을 기준으로 등록하는데, 보통 AWS에서는 Serverity 로 표기되고 구매한 서포트의 등위에 따라 선택 가능한 범위가 정해지는데 Azure 도 그런지는 잘 모르겠다. 어쨌든 중요한 것은, 어느 위치에 반영할 것인가 라는 문제다. Azure Marketplace 에 등록된 기본 템플릿에 정의된 VM size 는 Standard D2 타입이다. 궁금하신 분들은 Azure 홈페이지 참조. 아무튼 이 VM size 가 일본 서부에 없기 때문에, 본 설치에서는 East Asia 를 선택했다. 배포 템플릿은 AWS 의 CloudFormation 과 유사한 사용성을 지니는 것으로 보이는데, 역시 JSON 타입으로 되어 있어 일부 수정을 하면 일본 서부에서도 배포가 가능할지 모르겠다. 


아무튼 East Asia 를 선택하고, 기본 20인 할당량을 100 정도로 늘려 달라고 요청한다. 요청의 처리는 보통 업무일 기준으로 2-3일 정도 걸린다고 나오는데, 본인의 경우 아래의 채팅 창을 사용해서 조금 징징댔더니 빨리 처리해 주었다. 


이렇게 준비가 끝나면, 이제 본격 설치 단계로 진입하자. 별로 안어렵다. 



b. Azure CLI 의 설치. 


되게 당연한건데, CLI 가 존재한다는 사실에 살짝 놀랐다. 왜 놀랐을까는 나도 모르겠다. 아무튼 아래의 링크 내용을 참조하여 CLI 를 설치하자. 역시 AWS CLI 와 마찬가지로, 쉽게 설치가 가능하고 사용성도 좀 유사하다. 뭐 CLI 가 다 그렇지... 


https://azure.microsoft.com/en-us/documentation/articles/xplat-cli-install/



c. 아래의 Github 에 있는 쉘 스크립트를 로컬에 준비한다. 


https://github.com/cf-platform-eng/bosh-azure-template/blob/master/create_azure_principal.sh 


이 스크립트는 Azure 에 PCF 를 배포하기 위해 필요한 기본 정보를 생성해 주는 역할을 한다. 스크립트의 구동은 간단한데, ARGV1 으로 구독 형태를 넣어주면 된다. 본 경우에는 msdn 구독이므로, 뒤에 msdn 을 써 주었다. 그렇게 스크립트를 실행하면 지혼자 일을 알아서 하지 않고 뭔가를 기다리는 것처럼 뱅글뱅글 돈다. 멍잡고 있으면 안되고, 잘 읽어보면 https://aka.ms/devicelogin 이라는 페이지에 가서 인증 코드를 넣어주란다. 그렇다. CLI 가 계정 정보 접근을 위해 웹을 통해 OAuth 인증하고 있는거라고 보면 된다. 


스크립트 실행. 인증을 위한 URL과 코드가 주어진다. 



위의 화면에서 콘솔에 제공되는 코드를 입력하도록 한다. 코드를 입력하면 어떤 계정과 연결할 것인지 묻고, 만약 사용중인 메인 브라우저가 다르다면 다시 한번 로그인 해야 할 것이다. 어쨌든 브라우저 창을 닫아도 좋다는 메세지를 확인하면, 스크립트가 다음 단계로 진입하는 것을 확인할 수 있을 것이다. 



개인정보 보호를 위해 사방팔방 빵구가 보이는데, 아무튼 중요한 정보는 제일 아래 나오는 tanantID, clientID, CLIENTSECRET 의 세 부분이다. Azure CLI 사용에 관심이 많다면 역시 해당 홈페이지를 살펴보면 되겠다. 사전에 서비스 이해는 필수~ 



d. https://network.pivotal.io 에서 계정 API 토큰 확인 


Pivotal의 제품 다운로드 페이지인 network.pivotal.io 에 가입후 로그인을 하면, 우측 상단에 내 ID가 보인다. 클릭하면 드랍다운 메뉴가 나오는데, 여기서 "Edit Profile" 을 클릭하면 계정 정보 페이지로 이동한다. 페이지의 제일 하단으로 이동하면 API TOKEN 이 보이는데, 여기 나오는 토큰 정보를 준비해 두면 되겠다. 




e. Marketplace 검색, 그리고 해당 정보 입력 


https://portal.azure.com 으로 돌아와 로그인을 하면, 기본 화면 좌측에 +새로 만들기 버튼이 있다. 클릭하면 제일 상단에 검색이 가능한데, 여기에 Pivotal Cloud Foundry 를 입력하면 우측에 탭이 확장되며 관련 정보가 나타난다. 



마켓 플레이스에서 Pivotal Cloud Foundry 검색 




만들기 버튼까지 오면 된다. 설명을 살펴보면, Pivotal Cloud Foundry 와 MySQL, Redis, RabbitMQ, Spring Cloud Services, Apps Manager 가 설치될 것이라고 안내 된다. 다른건 아마 익숙할 테니 Spring Cloud 와 Apps Manager 만 설명하면, Spring Cloud Services 는 Netflix OSS 중 Circuit Breaker, Eureka, Config Server 의 세가지를 별도의 설치 없이 바로 애플리케이션에 사용할 수 있도록 준비한 것이라고 보면 되겠다. 이 세가지에 대해 처음 들어 보았다면, 각각의 이름으로 검색해 보자. 마이크로 서비스 아키텍처 라던가 클라우드에 맞는 확장성 및 고가용성을 구현하고자 할때 반드시 필요한 도구의 형태로 볼 수 있으며, 현재는 Spring Cloud 에 녹아있다. Pivotal 의 동료 중 한명이 Tip Toe 인가 하는 이름으로 닷넷에서도 사용할 수 있도록 하는 프로젝트를 하고 있단다. (Pivotal 공식 프로젝트는 아님) 



어쨌든 만들기 버튼을 클릭하면 위의 리소스가 다 뾰로롱 생긴다. 물론 이전의 필요한 내용을 다 이상 없이 준비한 경우에 말이다. 무언가 문제가 생겼다면 로그를 확인할 수 있으므로 반드시 참조하여 원인을 파악하도록 한다. 경험상 할당량이 충분하지 않다던가, CLI 에서 Oauth 를 통한 로그인 뒤 한참 있다가 (수시간 후) 만들기 버튼을 통해 배포를 수행한다던가 하면 세션 만료등과 같은 이유로 배포가 실패하는 것 같다. 그 이외에는 별다른 문제는 없었다. 



f. 필요 정보 입력 



위의 화면에 나타나는 정보 기입만 문제가 없다면 이후 배포는 알아서 자동으로 스뭇쓰 하게 된다. 각각의 항목에 대해 설명하면 다음과 같다. 


- Storage Account Name Prefix : Blob Storage, 이를테면 아마존의 S3와 같은 형태의 저장소를 준비한다. 아마존의 S3를 사용해 보신 분들은 알겠지만, 버켓의 이름 자체가 FQDN 이 되거나 또는 그렇지 않더라도 오브젝트 스토리지는 보통 global 하게 유일한 이름을 요구하는 경우가 일반적이다. 따라서 본 배포에 사용할 스토리지 이름의 prefix 를 주어야 하는데, 이것을 유일하게 지정하지 않으면 배포 중 에러를 보게 될 것이다. 즉, pcf, pivotal, superman 과 같은 아주 흔한 이름을 사용하면 실패할 확률이 높다는 뜻이다. 유일할 가능성이 높은 본인의 이름과 같은 것을 사용하면 된다. 즉, 어디 사이트 가입할때 아이디 만드는 느낌적인 느낌으로 기입하면 된다. 


- SSH public key : 모두 그런것은 아니겠지만, 배포 후 생성되는 자원에 접근하기 위한 SSH 인증 정보를 넣으면 된다. 보통 ssh-keygen 커맨드로 사용해서 생성되는 ~/.ssh/id_rsa.pub 정보를 넣어 주면 된다. 맥이나 리눅스 사용자라면 매우 쉽겠지만, 윈도우 사용자라면 아래의 Azure 링크를 살펴보도록 하자. https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-ssh-from-windows/


- TenantID : 스크립트 수행으로 나오는 STDOUT 에서 tenantID 내용을 붙여 넣는다. 

- ClientID : 스크립트 수행으로 나오는 STDOUT 에서 clientID 내용을 붙여 넣는다. 

- Client Secret: 스크립트 수행으로 나오는 STDOUT 에서 CLIENTSECRET 내용을 붙여 넣는다. 

- Pivotal Network Token: network.pivotal.io 의 계정 페이지에서 얻은 API TOKEN 을 넣는다. 

- 새로 만들기 후 리소스에 이름을 지정한다. 이를테면, Younjin-PCF-Azure 와 같은 느낌으로. 



모든 정보가 올바르게 기입 되었다면, 확인 버튼을 누른다. 이후 템플릿이 자동으로 생성되는데, 이 템플릿의 유효성을 검사하는 페이지가 나타난다. 1분 내외의 시간에 검사가 종료 되면, 배포 버튼으로 PCF 를 배포 한다. 그리고 아무 문제가 없다면, 이 시점으로 약 2-3시간 정도 후에 PCF 를 사용할 준비가 된다. 이 과정 동안 배포 정보를 확인하면 현재 어떻게 배포가 되고 있는지를 확인할 수 있는 인터페이스를 제공하는데, 해당 링크는 아래 g 섹션의 스크린샷의 '마지막 배포' 아래의 하늘색 링크를 클릭하면 나오는 페이지에서 확인할 수 있다. 





왜 3시간이냐면, PCF 는 배포될 때마다 각 배포 버전에 맞는 리소스들을 컴파일 한다. PCF 자체가 마이크로 서비스 아키텍처로 이루어져있기 때문에, 여기에 사용되는 다양한 도구들이 모두 컴파일 되고, 필요한 VM을 생성한 이후 컴파일 된 패키지가 설치된다. 따라서 컴파일 + 리소스 준비 + 업데이트 시간이 소요되는 것이라고 이해하면 된다. 그럼 업데이트 할때마다 이렇게 오래걸리겠네? 라고 하면 맞다. 좀 걸린다. 다만, PCF 는 다운타임이 없이 업데이트 되므로, 서비스에 지장 없이 사용하면 되겠다. 물론, 배포 준비는 확실하게. 



g. 배포 완료 후 확인 사항 


배포가 완료되면, 아래와 같은 화면을 볼 수 있다. 대시보드에 새로 로그인을 했다면, 새로운 배포의 단축 타일을 확인할 수 있을 것이다. 



무언가 무지하게 많이 배포가 되었다. 이 리소스들이 PCF 를 동작시키는 각각의 서비스 컴포넌트이며, 추가적으로 MySQL 과 같이 설치전에 명시된 서비스들도 함께 동작하고 있다. 만약 할당량이 부족하다면 배포에 에러가 발생하며 중지 될 것이다. 만약 배포가 중지 되었다면, 원인을 알아낸 후 리소스 페이지의 상단에서 '삭제' 버튼을 눌러 반드시 쓸데없는 과금이 발생하지 않도록 주의 하자. 


'마지막 배포' 아래의 하늘색 날짜 링크를 클릭하면 배포의 STDOUT 페이지로 이동하는데, 여기에는 JUMPBOX 의 주소, 현재 어떻게 배포가 진행 되고 있는지에 대한 tail log 를 볼 수 있는 링크가 주어진다. JUMPBOX 로 로그인 하고 싶다면 ssh-keygen 을 수행한 머신 또는 해당 키를 가지고 있는 머신에서 pivotal 계정으로 ssh 접근하면 바로 붙는다. 


한가지 더 확인해야 할 것은, 바로 Pivotal Cloud Foundry 의 IP 다. 위의 리소스 페이지에서 배포된 머신들을 살펴보다 보면, 끝에 -cf 라는 이름이 할당된 머신이 있을 것이다. 이를 클릭하면, 우측에 세부 정보가 표시 되는데 여기에 IP 를 확인 할 수 있다. PCF의 배포는 반드시 도메인이 필요하기 때문에, 이 경우에는 https://apps.system.[IP_ADDRESS].xio.ip 의 도메인으로 접근이 가능하다. 이 주소는 APPS Manager 라 불리는 PCF 의 웹 관리 도구라고 보면 된다. 



새로 배포된 여러분의 CF IP 주소를 사용해 접근하면, HTTPS 경고가 나타난다. 이는 임시 도메인에 대한 임시 인증서를 사용한 것이기 때문에 그러하며, 향후 프로덕션의 사용을 위해서는 회사의 멀티 도메인 인증서를 사용하면 사라지는 문제 되겠다. 로그인을 하면, Pivotal Web Services 에서 보던것과 동일한 환경을 확인할 수 있다. 


앗차. 로그인 정보는, 반드시 JUMPBOX 에 SSH 로 로그인을 해서 확인해야 한다. 방법은, 

ssh pivotal@[YOUR_JUMPBOX_DOMAIN]
cat manifests/elastic-runtime.yml | grep admin
admin_user: admin
admin_password: "0a0d2a13b6521ee2bf8b"

따라서 로그인 할때 계정은 admin, 패스워드는 위의 grep 결과로 나온 패스워드를 사용한다. 


로그인을 하고 Marketplace 항목을 살펴 보면, 바로 애플리케이션을 배포해서 연결할 수 있는 서비스의 목록이 나타난다. 




이후에는 PCF / PWS 사용 방법과 완전히 동일한데, 다만 한가지 주의 할 것은 기본 계정은 관리자인 admin 밖에 만들어져 있지 않다. 따라서 Cloud Foundry CLI 로 로그인 한 후, create org / create space / create user 등과 같은 기본 사용자 계정 생성 및 조직 생성 작업은 처리해 주어야 할 것이다. 이는 어드민 작업이며, 처음 설치 후 한번만 해 주면 되므로 너무 부담갖지 않도록 한다. Cloud Foundry 의 어드민 작업에 대해서는 아래의 링크를 참조 한다. 


https://docs.pivotal.io/pivotalcf/adminguide/index.html



h. 이후 할 일. 


- cf client 를 설치하고 애플리케이션을 배포 해 본다. 샘플 애플리케이션이 없다면 아래의 링크를 참조해 본다. 

https://github.com/cloudfoundry-samples  이들 중, MSA에 관심이 많다면 아래의 링크를 수행해 보자. https://github.com/spring-cloud-samples/fortune-teller


- 서비스 바인딩 및 구성. : 간단한 MySQL 애플리케이션을 작성하고, 플랫폼 환경 변수로 부터 endpoint 를 참조하여 코드를 작성 및 배포 하는 방법을 살펴 보자. 정보는 요기 참조  https://docs.run.pivotal.io/devguide/deploy-apps/environment-variable.html


- Spring Cloud Services 도 사용해 봅시다. 

http://docs.pivotal.io/spring-cloud-services/ 



i. Docker 이미지 배포. 


Pivotal Cloud Foundry 1.6 버전 이후 부터는 Diego 라는 새로운 런타임을 사용하여 닷넷과 다커를 지원한다. 이들 중 docker 이미지의 배포는 무지하게 쉽게 처리할 수 있다. 어떻게? cf 도구에 -o 커맨드 로 이미지를 지정해 주면. 


아래는 Docker Hub에 있는 Jenkins 를 Azure 에서 동작하는 Pivotal Cloud Foundry 에 올리는 모습이다. 

cf enable-feature-flag diego_docker # Admin 계정에서 수행해 주어야 한다. cf push jenkins-test -o jenkins ...

별 문제가 없다면 Docker 이미지가 Pivotal Cloud Foundry 로 그대로 배포되어 동작 할 것이다. cf apps 와 같은 커맨드로 엔드 포인트를 알아내고 접근하면, jenkins 동작을 확인 할 수 있다. 




Docker 버전의 jenkins 를 사용해 보신 분들은 알겠지만, 처음 접근 후에 Admin key 를 넣어 주어야 한다. 이를 위해서는 컨테이너에 ssh 로 접근할 필요가 있는데, Cloud Foundry 에서는 이를 매우 쉽게 처리할 수 있다. 바로, cf ssh 커맨드를 사용해서. 


$ cf ssh [APP_NAME]


컨테이너 내부에 접근해서 /var/jenkins_home 디렉토리에 가면 원하는 Key 를 찾을 수 있을 것이다. 사실 이와 같은 도구는 매우 유용한데, 왜냐 하면 개발 중 (프로덕션 아님에 주의) 개발 환경에 배포된 애플리케이션이 동작하는 컨테이너에 ssh 터널을 구성하고 각종 원격 디버깅 툴을 연결할 수도 있기 때문이다. 이에 대해서는 아래의 링크를 참조해 본다. 


https://blog.pivotal.io/kr/pivotal-cloud-foundry/products/%EC%83%88%EB%A1%9C%EC%9A%B4-cloud-foundry-java-%EB%B9%8C%EB%93%9C%ED%8C%A9-%EA%B0%9C%EB%B0%9C-%EC%A7%84%EB%8B%A8%EB%8F%84%EA%B5%AC



적절한 정보를 넣고 나면 다음과 같이 jenkins 가 동작하는 모습을 확인 할 수 있다. 




당연한 말이지만, 이대로 Jenkins 를 사용하라고 소개하는 것은 아니다. 중요한 것은 바로, Docker image 가 있다면 바로 PCF에 배포해서 사용할 수 있다는 것이다. 즉, 코드를 그대로 전달해도 컨테이너화 해서 동작하며, Docker 이미지가 있다고 해도 PCF 에서 사용이 가능한 것이다. 물론 편의를 위해서 전자를 선택하라고 하고 싶지만, 워낙 docker 사랑꾼들이 많으니까... 




5. 결론. 


Azure 에서의 PCF 는 매우 쉽게 배포할 수 있고, 잘 동작한다. 현재로서는 PoC 를 위한 정도이며, 프로덕션의 사용을 위해서는 지원이 필요하다. 그리고 PCF 는 현재 AWS 에서 매우 잘 동작하며, VMware 의 vCenter, vCloud Air, 그리고 최근 버전의 마이크로바이저인 Photon 역시 지원하고 있다. 향후 로드맵에는 이미 GCE 가 포함되어 있다. OpenStack 역시 지원한다. 이 의미는 무엇인가. 


"애플리케이션을 클라우드에서 동작하고 싶다면, 개발 부터 배포까지 Pivotal Cloud Foundry 를 통해 내일 당장 동작하는 컨테이너 오케스트레이션 / 계정, 조직별 권한 관리 / 레거시 저장소 연동 - 이를테면 유닉스 기반 오라클 /  각종 클라우드 서비스 연동 / docker 오케스트레이션 / 컨테이너 ssh 접근 / 로그 애그리게이션 / 애플리케이션 별 로그 스트림 / 빅 데이터 서비스 연동 / APM 구성 이 가능하다는 것이다." 



짧게 쓰고 싶었는데 뭐가 많이 써지고야 말았.. 



어쨌든 모두 즐거운 Azure, 그리고 멀티 클라우드, 아울러 Pivotal Cloud Foundry! 

물론 시간이 더 되시면 Concourse 를 보셔도 됩니다요.  https://concourse.ci 




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


저작자 표시 비영리
신고

bosh.io

Techs


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


아마 Cloud Foundry 에 관심이 있는 분이라면 bosh.io 를 한번 정도는 방문 했을 것으로 생각된다. 그리고 개인적인 생각인데, OSS Cloud Foundry 를 설치 시도했다가 입을 쩍 벌리고 포기하신 후, 어머 이건 우리가 사용할 수 있는 물건이 아니야 라고 생각했던 분들도 많지 않을까 한다. 사실 이해가 당연히 되는것이, 나도 어디가서 뭐 설치는 정말 많이 해봤다고, 삽질 좀 해봤다고 자부하는데 이거 Cloud Foundry 는 처음 설치를 시도할때 정말 많이 애를 먹었다. 마치 2011년에 오픈스택을 설치하는 느낌. 문서는 버전별로 다르고, 각 문서에 소개된 도구가 다르고, 그 도구별로 또 다른 repository 가 존재하는건 정말 지옥중에 지옥이 아니었을까 한다. 





인터넷에 찾아보면 수많은 OSS CF 설치에 대한 글을 찾아 볼 수 있는데, 이 역시도 굉장히 out date 된 내용들이 많아서 참조하기가 매우 곤란한 경우가 많다. 그리고 거기에 나온 내용을 하나 둘 이렇게 저렇게 따라하다 보면 어느새 랩탑은 너덜너덜 거지꼴을 못면한다. 이 대표적인 이유가 bosh 는 아직 현재까지는 ruby 와 ruby gem 을 사용하여 구현 된 것을 사용해야 하기 때문이다. 


어쨌든 이놈의 bosh 라는 도구가 사용하기 와이리 힘드노 하는 이유를 간략하게 정리해 보자면 아래와 같다. 

  • 일단 ruby 기반이다. 뭐 하나 시키면 더럽게 느려서 결과를 볼 때까지 시간이 매우 걸린다. 
  • 기본적으로 그 구조를 이해하는 것이 매우 쉽지 않다. 처음 접하면, CF 와 bosh 가 무엇이 다른지도 잘 감이 오질 않는다. 
  • YAML 지옥이다. 간단한 환경 설정이나 properties 정도를 적어두는 것이 아니라, 그 배포 대상의 용도에 따라 어마어마한 내용을 살펴야 할 때가 많다. spiff 라는 YAML merge 도구를 사용하다 보면 OSS CF 배포에 사용되는 YAML 은 보통 1800 줄 정도 된다. 
  • 문제가 발생할때 까지도 시간이 오래 걸리고, 문제를 확인 하는것도 오래 걸리고, 문제를 고쳐서 잘 돌아가는 것을 확인하는데도 오래 걸린다. 즉, 문제가 생기면 골때리게 시간을 오래 잡아 먹을 가능성이 높다. 

(이미치 출처: https://lh3.googleusercontent.com/-FZftK6jFru8/UC1OtbbRb6I/AAAAAAAADqI/D-8bbqzCjug/w640-h400-p-k/mario-yamld.png)



bosh 에 대해 설명해 보자면, 바로 배포 도구다. 어떤 배포 도구냐면, 예를 들어 MySQL 이나 PostgreSQL, Gemfire, Hadoop 과 같은 도구들에 대해서는 잘 알고 있을 것이다. 이러한 도구들을 각 클라우드 서비스에 '설치' 하는 도구를 바로 bosh 라고 할 수 있다. 당연하지만 이 설치에 필요한 설정이 바로 manifest 파일이고, 이는 YAML 을 사용하도록 되어있다. 따라서 설치 하려는 대상이 복잡하면 복잡할 수록, 구성해야 하는 내용이 많으면 많을 수록 YAML 파일의 길이는 안드로메다로 간다. 어쨌든, bosh 는 클라우드 서비스에 뭔가를 설치하려는 경우 사용할 수 있는 설치도구로 보면 된다. 

현재 bosh 의 repository 를 살펴보면 CPI 라고 해서 클라우드 서비스 프로바이더 인터페이스를 bosh-core 와 분리해 놓은 것을 볼 수 있다. 현재로서는 VMWare vSphere, vCloud Air, Amazon Web Services, Azure, OpenStack 을 지원하고 있다. 이전에는 bosh-core 와 CPI 인터페이스가 덩어리로 뭉쳐 있어 새로운 IaaS의 지원 속도가 좀 떨어졌다면 2015년 부터는 이 부분을 좀 개선해서 새로운 클라우드 서비스의 지원이 조금 빨라지고 있는 모양이다. 

개발자 분들이라면 아래의 링크들을 살펴보면 bosh 의 개발이 어떻게 이루어지고 있는지 눈으로 확인하실 수 있겠다. 

Bosh CI on Concurse: https://main.bosh-ci.cf-app.com/ 


일단 어떤 도구인지는 알았으니, 그 사용할때 어떤 점을 알아두면 좋은가 하는건 아래와 같이 대략 정리가 가능하겠다. 

  • Bosh 에서 말하는 jobs 는 각 용도별 Virtual Machine 을 일컫는다. 즉, YAML에 jobs: 하위에 consul 이 정의되어 있다면 이것은 consul 을 배포하는 작업이다. 
  • Stemcell 이라는 방법을 사용하여 VM 위의 OS 레이어를 추상화 한다. AWS 로 치자면 사전에 패킹된 AMI 를 지정한다고 보면 된다. 따라서 bosh 를 사용함에 이로운 점은 CVE 와 같은 긴급 패치가 발생한 경우 배포한 서비스들에 AMI 를 바꿔치기 하는 방법으로 전체 서비스의 업데이트가 가능하다. 물론, multi-AZ 와 같은 구성은 필수겠다. 
  • 보통 bosh micro 라는 VM 을 배포하고 여기를 director 로 연결해서 사용한다. Jumpbox 를 만들면 편리한데, 이는 클라이언트와 디렉터간에 간혹 무거운 파일 전송이 발생하는 경우가 있기 때문이다. 
  • bosh 는 매번 배포를 진행할때, 이전에 했던 모든 동작을 다시 반복한다. 물론 전체를 매번 재배포 하는것은 아니지만, manifest 의 설정대로 작업을 진행하며 이미 있는건 검사하고 넘어간다. 이러한 특징 때문에 신규 작업을 위해서 해당 배포는 시간이 엄청나게 오래 걸리는 단점이 있다. 
  • 문제를 해결해야 하는 경우가 상당히 자주 발생한다. 그것이 YAML 자체의 문제이건, 중간에 나오는 설정의 문제이건 간에 아무튼 엄청나게 자주 발생한다. 따라서 이러한 문제를 해결하기 위해서는 STDOUT 의 메세지만으로는 턱없이 부족한데, 다음과 같은 것들을 알아두면 좋다.  

경험상 필요했던 도구들 
  • bosh task [task number] --debug | egrep -i error   특정 bosh 작업에서 어디의 어떤게 문제였는지 빠르게 확인할 수 있다. 보통 ruby 에러 메세지 및 output 이 담겨있으므로 모든 내용을 보는것은 좀 짜증 날때가 많음 
  • 뭔가 더이상 진행되지 않거나 진행되다가 롤백 된다면, 꼭 ngrep host 나 tcpdump 를 사용해 볼 것을 권고한다. 어느 포트에서 어느 포트로 통신이 필요한데 이것이 제대로 되지 않으면, 그러니까 이를테면 NATS bus 와 같은 메세지 통신이 기존 bosh director 와 bosh 의 job 으로 생성된 vm 간에 허용되지 않으면 두 VM 모두 멍때리는 경우가 많다. 덤프 떠 보자. 
  • 구글 검색에서 사실 cloudfoundry.org 의 문서를 참조하는것이 도움이 된다고 말하기 힘들때가 많다. 문제를 해결하는 가장 빠른 방법은 bosh 나 cf-release 디렉토리 내에 있는 코드와 템플릿, 스크립트를 참조하는 것이다. 그렇다. 나는 지금 에러 메세지를 통한 검색 방법 보다 코드를 보면서 문제를 해결하는 것이 빠르다고 말하고 있는것 맞다. 
  • Manifest 파일 안에서 실수하기 좋은 것들이 static ip 설정이나 이에 따른 subnet 할당이다. multi-az 로 배포한다면 이것이 뒤바뀌면 문제가 많다. 
  • AWS 의 Security Groups, Routing Table, VPC 와 같은 설정들은 아무리 본인이 전문가라해도 항상 의심해서 확인에 확인을 거듭하는 것이 좋다. 
  • 한 2일 정도 붙들고 있으면 대략 윤곽이 보인다.
  • 의외로 Ruby 와 Ruby Gem 이 상당히 짜증을 유발한다. 뭔가 여기 저기서 권고하는 도구를 설치하다가 버전이고 뭐고 다 이상하게 되었다는 생각이 든다면, 아래의 doctor 를 써보자. 나름 잘 고쳐줌.  --  

    https://gist.github.com/mislav/4728286/raw/rbenv-doctor.sh  




정리해 보면, 전체적으로는 다음과 같은 과정이다. 

1. bosh 및 bosh micro 클라이언트 설치 
2. bosh director 준비를 위한 stemcell, manifest.yml 파일 준비 
3. bosh micro deploy 를 사용하여 bosh director 준비
4. Cloud Foundry 또는 다른 bosh 를 통해 배포할 manifest 준비 
5. bosh target x.x.x.x 로 로그인 
6. bosh create release 
7. bosh upload release 
8. 배포될 서비스에 필요한 버전의 Stemcell 업로드 : bosh upload stemcell [스템셀링크 또는 스템셀] 
9. 대망의 bosh deploy 


YAML 은 매우 엄격하다. 그리고 spiff 도구를 통해 필요한 YAML 을 합체하다 보면 순서가 뒤죽박죽 합체되어 뭐 하나 찾으려면 골치가 아프다. 막상 배포에 뭐가 잘못 되면, 그 해당 에러와 YAML 의 어느 부분이 문제인지에 대한 상관 관계 확인 또는 매핑이 매우 어렵다. 아울러 이러한 에러에 대한 정보가 아예 없거나 너무 구버전의 정보이거나 아니면 케이스바이케이스로 풀리는 것도 많이 봤다. 따라서 정리하면 현재로서 사용하려면 매일 이것을 업으로 삼고 있는 사람이 아니면 쉽지 않은 것이다. 

그래도 OSS Cloud Foundry 가 매력적인것은 당연하다. 괜히 I 사나 H 사가 가져다가 자사의 IaaS 에 올리고 있는것이 아니다. 클라우드는 결국 애플리케이션의 구동을 위해 필요한 것이며, 이 애플리케이션의 구동을 더욱 쉽게 해 주는 도구이기 때문에. 

Cloud Foundry 의 Product Manager 의 말에 의하면, 조만간 공개될 새로운 버전의 BOSH 는 YAML 이 지옥에서 현실적인 수준으로 바뀐다고 한다. 아울러 Cloud Foundry 에서 서비스 연결을 할때 원하는 "기존의" 서비스를 연계하도록 하는 것이 아니라, 원하면 BOSH 를 통해 "새롭게 배포된" 서비스를 할당할 수 있도록 더욱더 강화할 예정이라고도 한다. 

CF release 211 때 한번 격렬하게 삽질했다가 이번에 밋업 준비하면서 233 release 에 또한번 격렬한 삽질을 하고 보니 이거 지속적으로 한번씩은 해 줘야 감을 유지하겠구나 싶다. ㅎ 

엔터프라이즈라면 OSS 말고 PCF 를 씁니다. 거기에는 OpsManager 라는 매우 편리한 GUI Bosh 가 있거든요. 

아래는 클라우드파운드리 밋업 주소. 

만약 설치 버전이 아니라 경험만 하고 싶은 경우라면 이런 심한 고생 하실 필요가 없습니다 여러분. http://run.pivotal.io 

AWS 에 배포하는 경우라면 반드시! EC2 limit increase 가 필요합니다. 이것은 각 EC2 콘솔의 대시보드에 있으니 미리 미리 늘려두어 어머 하는 당황스러운 사태를 피합시다 그려. 집에 놀고 있는 vSphere 가 있다면 도전! 

클라우드 때문인지 오픈소스가 날이 갈수록 복잡해짐. ㅋ  

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



저작자 표시 비영리
신고

Cloud9 IDE 에서 Cloud Foundry 로의 애플리케이션 배포

Techs


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


원래는 페이스북에 간단한 담벼락 포스팅이었는데, 아무래도 다시 사용하게 될 것 같아서 블로그에도 포스팅. 

Cloud9 이라면 Node.js 개발자 분들께는 추억의 이름일지도 모르겠다. 이제는 Coda 라던가, Brackets 라던가 MS 에서도 만들어 내어 놓는 아주 좋고 심플한 툴들이 많이 나왔으니까. 하지만 당시에는 "협업" 이라는 타이틀 때문에 많이들 관심이 있었고, 그 C9 자체의 구현방법이나 로컬 또는 우리회사 내부에서 돌리면 좋겠다는 생각에 실제로 그렇게도 돌릴 수 있었으니까. 


그런 C9의 장점들을 살펴보면, 대략 이런것들이 있었다. 

  1. Github 와 같은 온라인 repo 와의 연동이 매우 좋았다. 
  2. 웹 브라우저 기반의 IDE 였기 때문에 어디서나 접근 가능하고, 테스트가 가능했다. 
  3. 하단에 쉘로 연결되는 콘솔을 제공해서 매우 편리했다. 
  4. 온라인에서 협업해서 개발된 애플리케이션의 배포를 테스트 도구에 연동한다거나, Heroku 와 같은 클라으드에 배포가 매우 편리 했다. 

그러한 장점들을 살려, 아련한 기억속에 다시 생각나는 C9 IDE 에 Cloud Foundry 배포를 살짝 테스트 해 봄. 물론 당연하지만, 실제 개발 및 배포에서는 중간에 자동화 된 테스트와 이슈 트래커의 연동, 그리고 스테이징 배포가 개발자의 랩탑에서 바로 진행되지 않고, 보통 지정된 repository 와 연동 되도록 하는 것은 잘 알고 계실 것이다. 하지만 이러한 구성이 의미가 있는것은, 내가 지금 로컬에서 동작하도록 만든 애플리케이션이 과연 프로덕션 환경에서도 이상없이 동일하게, 즉 코드 변경없이 구동 될 것이냐 하는 테스트에 그 의미가 있다고 하겠다. 

아래의 내용을 진행하기 이전에 작업이 필요한 것이 있다. 
  1. https://c9.io 의 계정, 그리고 기본 Node.js 애플리케이션 프로젝트 구성. - 퍼블릭으로 만들면 돈 안듦 
  2. PWS 의 계정. Pivotal 이 제공하는 60일간 무료 사용 가능 Cloud Foundry. Log Stream, APM, 컨테이너 스케일링 등 다양한 기능을 제공, 무엇보다 배포가 매우 간단. 
  3. 크롬이나 사파리와 같은 "모던" 웹 브라우저 

그다지 친절한 블로그도 아니긴 하지만 그렇다고 가입 화면까지 스크린샷 찍으면 그것은 매뉴얼이지. 

프로젝트를 처음 만들어서 구성하면, 아래와 같은 이쁜 화면이 보인다. 


당연한 말이지만, 여기서 코드 수정도 하고 소스 레포 연동도 하고 커맨드 라인도 날려보고 만들어진 코드가 동작하는지 테스트도 가능하다. 즉, 개발에 매우 편리한 환경. 우리는 여기에 Cloud Foundry 클라이언트 도구를 설치하고, 작성된 코드를 즉시 배포해서 동작하는지 확인 할 것이다. 


혹시 입맛에 맞게 코드를 변경했거나 하는 경우라면 녹색 Run 버튼으로 잘 동작하는지 브라우저 내의 로컬에서 바로 확인이 가능하시겠다. 


이후에는 일반 x86_64 기반의 리눅스에 cf 클라이언트를 설치하는 방법과 동일한 방법으로 클라이언트를 설치. 이는 하단의 탭 중 "bash" 로 지정된 탭에서 수행 가능하다. 설치시에는 원하는 별도의 디렉토리를 구성해도 되고, export PATH 로 설치된 CLI 를 편리하게 사용하도록 구성하는 것도 가능하겠다. 


커맨드는 


cd ~

wget -O cf.tgz 'https://cli.run.pivotal.io/stable?release=linux64-binary&source=github'

tar xvzf cf.tgz




그러면 위와 같이 주르륵 주르륵 진행된다. 

cf 가 잘 설치 되었는지 확인하려면 cf 쳐보면 된다. cf help 쳐도 된다. 


디렉토리 구조를 보면, ~ 아래에 workspaces 라는 디렉토리가 보인다. 그리로 들어가서, 이제 배포 하면 끝. 

tree 가 들어있나 쳐봤는데 오오오 있다. 



원한다면 이후 cf 로의 배포를 위해 manifest.yml 를 넣을 수 있다. 빌드팩의 정보라던가, 필요한 데이터베이스의 바인딩이라던가, 컨테이너에 지정할 메모리 크기라던가 하는 것들. 


이제는 다음의 커맨드를 사용해 애플리케이션을 배포한다. 기본적으로 방법은 git push 와 아주 유사하다. 아울러, cloud foundry 에는 빌드팩이라는 용어를 많이 사용하는데, 이는 코드나 컴파일된 파일에 맞게끔 동적으로 합체되는 런타임, 더쉽게 말하면 설치할 필요 없는 미들웨어 패키지와 그 친구들로 이해하면 편하다. 뭔말이냐면, cf push 로 업로드 되는 파일이 jar 라던가 war 라면, java 빌드팩이 뿅하고 합체되어 톰캣이라던가 그런게 자동 구성. 클라우드 파운더리가 기본 지원하는 빌드팩은 cf buildpacks 커맨드로 확인이 가능하고, 원한다면 구글에서 cloud foundry buildpacks 로 검색하면 nginx 라던가, elarng, 애플의 swift 등 다양한 빌드팩으로 런타임을 구성할 수 있겠다. 아물론 커스터마이징도 가능. 




cf push -b 스위치로 온라인에 있는 다양한 빌드팩을 사용하는 것도 가능하지만, 이것들이 엔터프라이즈에서 오프라인으로 필요한 경우라면 PCF 라는 설치 버전에서 빌드팩을 오프라인으로 등록해 사용하는 것이 매우 가능하다. 따라서 보안상의 이유로 인해 런타임 환경에서 인터넷으로의 접근이 막혀있는 경우에서도 동작이 가능하다는 말. 

이제는 진짜로 배포를 한다. ㅋ 

cf push [app-name] -m 256M -c "node server.js"

# 이경우에는

cd ./workspace

cf push yjeong-nodejs -m 256M -c "node server.js"

여기서 지정된 app-name 은 클라우드 파운더리가 설치된 메인 도메인의 서브 도메인으로 동작한다. 무슨말이냐면, 만약 PCF 가 mycorporate.com 으로 되어 있다면 이때 app-name 으로 배포된 애플리케이션은 app-name.mycorporate.com 의 FQDN 을 자동으로 가지게 된다는 말. 물론 당연하지만 애플리케이션은 여러개의 이름을 가질 수 있고, 실제 서브 도메인의 이름은 다른것을 사용할 수 도 있으며, 해당 서브 도메인은 다른 애플리케이션으로 동적으로 라우팅을 변경할 수도 있다. 물론 본 예제에서는 PWS 라는 피보탈 제공 서비스를 사용하기 때문에 기본 도메인인 cfapps.io 가 붙는다. 물론 원한다면 본인 소유의 도메인을 여기에 CNAME 매핑하셔도 되겠으며, 원한다면 AWS 의 Cloud Front 와 같은 CDN 연결 가능하시겠다. 


아무튼 위의 커맨드를 날리고 보면 뭔가 막 바쁜것을 확인할 수 있다. 이는 도메인을 생성하고, package.json 에 명시된 패키지들을 다운 받아서 준비하고, 뭐 그런 내용들이 주르륵 나온다. 별 문제가 없다면 1개의 컨테이너에서 애플리케이션이 정상 동작하고 있다는 메세지를 확인 할 수 있다. 



뭔가 막 바쁜 모습.jpg 

App started 라는 메세지를 보면 일반적으로 문제가 없이 배포가 완료 되어, 애플리케이션이 up & running 상태라고 보면 되시겠다. 





cf a 커맨드는 cf apps 의 알리아스로 현재 나에게 할당된 org 안의 space 에서 동작하고 있는 애플리케이션의 전체 리스트를 보여준다. cf app [app-name] 은 해당 애플리케이션의 디테일을 보여준다. 현재는 별도의 명시가 없었기 때문에 1개의 컨테이너로 동작하고 있지만, -i 스위치를 사용해 동적으로 수량을 변경해 줄 수 있다. 아래는 -i 5 를 사용해 컨테이너를 확장한 모습. 당연한 이야기지만, 이 컨테이너들은 모두 동적 라우팅 경로에 추가되어 밸런싱 되고 있다. 


cf scale yjeong-nodejs -i 5


 

아무튼 애플리케이션이 잘 동작하는지 확인하려면? 해당 도메인에 접근해 보면 되겠다. 


http://yjeong-nodejs.cfapps.io 


현재 사용가능한 PWS 는 AWS 의 동부 리전을 사용중이므로, 만약 속도가 다소 느리면 거의 대부분 네트웍 문제로 보시면 된다. 만약 한국에서의 접근이 폭발적으로 많게 되면, 제가 한국 AWS 리전에 PWS 운영을 건의해 보도록 하겠습니다 여러분~ (선거 코스프레) 



별 문제가 없었다면 위와 같은 기본 프로젝트의 페이지가 나온다. 하단이 공백이라 허옇게 뜨는... 

뭐 어쨌든 잘 돌아가시겠다. 


이번에는 PWS 사이트, https://run.pivotal.io 에서 로그인 해서 보면 해당 페이지가 문제없이 동작하고 있는것이 보인다. 



어! 쿼타가 나랑 다르네 하시는 분들께서는 제가 그 저기 피보탈 직원이라 이런 혜택은 조금 있습니다. 음. 

아무튼 yjeong-org 라는 조직 내에 2개의 space 가 있는데 하나가 development 고 다른 하나가 labtest. 여기 중 development 에 해당 애플리케이션이 배포 되었다고 보시면 된다. 이러한 조직 구성과 권한의 관리가 있다는 것은, org 로 할당된 하나의 마이크로 서비스 조직에서 운영하는 애플리케이션의 개발 / 스테이징 / 프로덕션으로 ORG 내에서 Space 로 나누어 낼 수 있다. 그리고 이 각 Space 에는 별도의 권한을 할당하여, 개발 환경에는 개발 팀의 권한을, 나머지 환경에는 테스트 및 배포 자동화 도구에만 권한을 주는 방법을 사용할 수 있다. 


PWS 를 사용하는 경우에는 오른쪽에 Billing 내역을 확인하여 내가 지금 얼마를 사용하고 있는지 (유료 계정이라면) 확인이 가능하다. 이는, 엔터프라이즈의 설치 버전인 PCF 의 경우 각 조직에 할당된 리소스에 대해 청구를 할 수 있는 메커니즘을 가지고 있어, 그룹사의 각 조직에 할당된 사용량에 대해 빌링이 가능하다. 이는 많은 그룹사가 원하시는 꽤 아름다운 기능. 


애플리케이션이 배포된 Space 에 들어가 보면 아래와 같이 나온다. 



이전에 구성한 바와 같이, 배포한 애플리케이션의 이름, 각 컨테이너에 할당한 메모리, 컨테이너의 갯수 같은 정보들이 나오며, 해당 애플리케이션으로 한 뎁스 더 들어갈 수 있다. 아래에 보이는 Add Service 버튼을 누르면, 해당 스페이스나 애플리케이션에 필요한 각종 서비스를 바로 바인딩 하여 사용할 수 있는 다양한 서비스들을 확인할 수 있다. Cloud Foundry 에서는 이런 사용성을 marketplace 라고 부르는데, 이는 cf marketplace 라는 커맨드 라인도구를 사용해서도 확인이 가능하겠다. 


설치버전인 PCF 에서는 운영자 또는 조직의 요구에 따라 다양한 서비스를 PCF 와 연동하도록 구성할 수 있다. Redis, RabbitMQ, MySQL, MongoDB, New Relic, PostgreSQL, Memcached, Elasticserch 등 이미 제공되는 도구를 다운로드 받아 연동을 구성할 수도 있으며, 종전의 기업에서 사용중인 다양한 On-premise 도구를 연동하는것도 가능하다. 이를테면 Oracle DB 라던가 DB2, 또는 하둡 클러스터등과 같은 도구를 Service Broker 라는 방식으로 애플리케이션에 할당하고, 환경변수에 등록하여 참조해서 사용할 수 있는 방법을 제공한다. 여기에는 조금 더 설명이 필요하긴 한데, 이후 버전에서는 더 개선된 방식으로, 즉 서비스가 필요할때 AWS 나 Azure, 또는 오픈스택에 bosh 라는 도구를 통해 배포해서 할당하는 방법이 준비되고 있다. 


뭐 말이 복잡한데 정리하면 필요한 서비스를 할당 받아서 애플리케이션에 바인딩 하면 환경 변수로 참조해서 사용 가능하다. 이말인즉, 12factor.net 에서 이야기 하는 Code 와 Config 의 분리, 그리고 각 환경간의 이질성 최소화가 지원이 되어 애프리케이션의 배포와 테스트 그리고 프로덕션 반영의 속도가 빨라질 수 있다는 말. 



마켓 플레이스. 이런 도구가 주는 강점은, 만약 AWS 와 같은 클라우드를 선택해서 DynamoDB 라던가 RDS 와 같이 CSP 가 제공하는 서비스를 사용하는 경우에도 연동이 가능하다는 것이다. 즉, 애플리케이션에 필요한 데이터 소스 또는 스토어, 이런 것들에 대한 접근이 각 환경별로 독립적으로, 그리고 자유롭게 주어질 수 있다는 것. 물론 이러한 서비스 바인딩에 대한 권한 역시 통제 할 수 있겠다. 


아래는 배포된 애플리케이션의 디테일이다. 



인스턴스의 수량 조절, 애플리케이션의 메모리 변경등이 가능하고, 아래의 내용을 보면 탭으로 구분된 다양한 내용을 볼 수 있다. 여기에는 해당 애플리케이션에 대한 히스토리, 로그, 라우팅 정보, 연결된 서비스와 애플리케이션에 필요한 환경 변수 등을 지정할 수 있다. 당연한 말이지만 이러한 기능들은 모두 커맨드 라인 도구에서 사용이 가능하고, 특히 로그와 같은 기능은 애플리케이션의 문제 분석에 매우 유용하다. 또한 Cloud Foundry 자체가 별도의 로그 분석 도구와 연동하고 있다면 여기에 하둡이나 HWAQ, GreenPlum 과 같은 도구의 연동도 가능하겠다. 3rd 파티로는 DataDog 와 같은 도구를 연동할 수 있는 것도 물론 가능. 




로그 스트림 



아마, 현재 근무하고 계신 회사에서 동작하는 모든 애플리케이션의 로그가 한꺼번에 저장되서 스트림으로 처리 되거나, 또는 그렇게 모여진 애플리케이션 로그를 애플리케이션 별로 수집해서 보는곳은 많지 않을것이라고 생각된다. 하지만 반드시 필요한 기능이고, 문제가 생겼을때 추적을 하는 것 뿐만 아니라 분석에 필요한 기본 자료가 되기도 하기 때문이다. 하지만 이를 실제로 구현하기 위해서는 배포된 모든 서버에 별도의 에이전트를 넣는다던가, 또는 분산 로깅 구성을 반드시 해야 할 필요가 있다. 이것이 쉬운 작업이 아닐 뿐만 아니라, 그것을 애플리케이션 개발자 입장에서 편하게 접근하는 것은 또 다른 이야기다.  특히 Node.js 개발자 분들이 항상 로그를 검색해야 할 필요가 있는 경우를 생각해 본다면 이런 도구가 제공하는 장점이 매우 매력적이지 않을 수 없다. 


이런 로그 연동에 더하여 만약 애플리케이션 성능 효율까지 같이 볼 수있다면 어떻게 될까? 이후 로드맵에서는 일종의 Splunk 와 유사한 뷰를 제공할 예정이지만, 현재 PCF Metrics 라는 이름으로 애플리케이션이 어떤 상태로 동작하는지 실시간으로, 그리고 히스토릭하게 확인이 가능하다. 이는 애플리케이션 대시보드의 오른쪽에 있는 "View in Pivotal APM" 버튼을 누르면 확인 가능하다. 




퍼포먼스 모니터링 대시보드 




컨테이너 모니터링 - 블로그 포스팅을 하는 와중에 기록이 남은게 별로 없... 




네트워크 상태 모니터링. 


위와 같은 메트릭을 제공하는데, 이게 이후에는 조금 더 발전해서 애플리케이션 로그와 합체된 그래프의 형태가 된다. 따라서 언제 새로운 애플리케이션이 배포가 되었고 이와 연동하여 언제 서비스가 어떤 상태인지 추적이 로그와 연동하여 보기 매우 편리해 진다는 말. 대부분의 클라우드 기반 애플리케이션 모니터링을 위해 Pager Duty, DataDog, New Relic 과 같은 도구를 사용하는데 여기저기서 다른 로그를 보고 분석하는 것 보다 훨씬 편리해 지겠다. 뭐 , 2016년에 지속적으로 확장 로드맵이 있으므로. 



시작은 C9 IDE 와 Cloud Foundry 와의 연동이었는데, 이게 어쩌다 보니 클라우드 파운드리에 대한 설명이 더 많아져 버린 느낌이다. 그리고 눈치 빠른 분들은 이미 아시겠지만, 이는 C9 뿐만 아니라 리눅스나 윈도우, 맥에서도 CF 클라이언트를 설치하면 cf push 한방으로 이 모든 것이 가능하다. 또한 테스트 도구와의 연동, 이를테면 Jenkins 를 사용한다면 함께 제공되는 Cloud Foundry 플러그인을 사용할 수도 있고, 아니면 테스트가 종료되면 실행할 내용에 cf push 를 적어주면 되겠다. 아울러 Spring 에 오너쉽을 가지고 Eclipse 에 심각한 수준으로 Contribution 을 하고 있는 회사가 바로 Pivotal 이므로, STS 와 같은 도구 또는 이클립스에서 플러그인으로 검색하면 바로 Cloud Foundry 에 애플리케이션을 배포할 수 있겠다. 



이 모든 것들이 시사하는 바가 무엇인가. 아마 컨테이너와 그 컨테이너들의 오케스트레이션, 로그 어그리게이션, 권한 관리, 자동화된 배포 및 테스트 연동, 이런것들이 필요해서 직접 구성하고 계신 시도가 매우 많이 관찰되고 있다. 하지만 잘 아시겠지만, 이런 서로 다른 회사의 서로 다른 스택을 한꺼번에 프로덕션에 반영하는 것은 매우 어렵고, 버전 관리나 업데이트, 배포 연동 이런게 보통일이 아니다. 아울러 서비스 전체에 심각한 보안 패치가 필요한 경우, 이것이 상상도 안되는 일이라는 말이지. 


우리 회사의 본 Pivotal Cloud Foundry 프로덕트 총괄이 발표에 이런 이야기를 한다. 


Here's my source code, 

Run it on the cloud for me, 

I don't care how


여기에 대한 답, cf push. 


정리하면,

  1. 컨테이너 기반의 애플리케이션 배포 가능 
  2. 컨테이너의 동적인 확장 및 축소 가능 
  3. 웹 애플리케이션 서버, 이를테면 런타임 구성의 자동화 
  4. 랩탑에서 프로덕션까지, 12factor 앱 구성에 필요한 실질적 환경을 제공 
  5. 컨테이너간 네트워킹이 필요하다면, - 조만간 지원 : MSA 애플리케이션간 통신의 유연화 
  6. 필요한 서비스를 인터넷이던 인트라넷이던 언제나 연동 가능 
  7. 멀티 클라우드. - 오픈스택에서 AWS, Azure, 이젠 GCE 까지. 물론 VMware 는 모회사 중 하나이므로 당삼 지원. 
  8. Docker? Docker 가 지원하는 (Endorse) 유일한 도구가 바로 Cloud Foundry.  cf push -o 를 통해 Docker 배포를 순식간에. 
  9. 그거 안전한가? - 특히 많이 사용되는 곳이 제조 및 금융, 중국에서는 바이두 같은 곳? 
  10. 권한 관리. 빌링. 로그 취합. APM. 

클라우드와 컨테이너의 구성에 대해 구상하고 계신 분들께 참조가 되었으면 한다. 
아울러 상용 버전도 있지만, 오픈 소스 버전도 있다는 거. 


물론 오픈 소스 버전도 거의 비슷한 기능을 제공하지만, 다른건 APM 같은것이 없다거나, 설치할때 보면 YAML 지옥이라는 정도? 
당연한 말이지만 개선중에 있습니다 여러분. 

그리고 우리 회사에서 설치 테스트 해 보고 싶은데 하는 분들은 아래의 주소로 가시면 클라우드 파운더리 및 관련 다양한 서비스를 받아 함께 구성해 보실 수 있겠습니다. VMware 에도 되고, AWS에도 되고, 아직 베타긴 하지만 Azure 에도 됩니다. 

설치 순서는 대략 
- OpsManager 
- ElasticRuntime (요게 PCF) 
- 기타 다른 타일을 다운로드 받아 OpsManager 에 등록하여 서비스 추가 가능. 
- 디테일은 매뉴얼 참조 

랩탑에서 구성하는 방법도 있는데, 내 랩답이 메모리가 좀 빵빵하지 후훗 하시는 분들 께서는 microPCF 검색 고고. 

끝내기 전에 한가지 주요 질문. - 여러분은 80포트 애플리케이션 구동과 배포를 위해 얼마나 많은 일을 하고 계십니까? 

그럼 오늘 포스팅은 여기서 끝. 
기승전피(보탈) 

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








저작자 표시 비영리
신고