[클파: 인사이드] 어떻게 만들었나?

http://www.slideshare.net/derekcollison/design-of-cloud-foundry

http://www.infoq.com/presentations/Cloud-Foundry-Inside-the-Machine

몇몇 핵심 요소들이 있는데…

  • 커널 (CloudFoundry OSS): 핵심 PaaS 시스템
  • 커널과 오케스트레이터(Orchestrator) 쉘: IaaS 상단의 레이어
  • 오케스트레이터: IaaS 생성, 관리 및 관장(?)

커널이라고 부르는건 VCAP이라는 이름으로 오픈소스로 공개한 핵심 패스 시스템을 말하는 것 같고.. 오케스트레이터 쉘은 뭔지 잘 몰겠넹;; 설명도 좀 짧고. 나중에 여러 계층과 어떻게 소통하는지 자세히 설명하겠다는군요.

오케스트레이터는 라이프사이클 관장으로 이 부분이 꽤 어려운 문제를 해결하는 부분이라고 합니다. 멀티 노드 설치 스크립트 등을 만들고 사용하는건 그리 어려운 부분이 아니라네요. 그런 부분보다는 “동작중인 시스템”을 만드는 것입니다. 즉.. 애플리케이션은 계속 돌면서도 그 밑단의 시스템이 죽었는지.. 전부 새로 껐다 켰는지 알 수 없게 만드는거라고 얼핏 이해했는데… 흠냐.. 맞겠지?.. 그렇게 하는게 어려운거라고 하고.. 이걸 어떻게 할 수 있게 했는지 설명하겠다고 하네요.

하드웨어 하드웨어고, IaaS 대충 알겠고, 오케스트레이터가 매우 중요하고 어려운 부분인데. 아마도 여기에 nats가 매우 중요한 역할을 하고 있을 것 같고.. CF Kernel이라는게 vcap일꺼고.. clients는 뭐.. http over json으로 통신하는 CLI나 STS 플러긴이나 웹앱이겠지.

클파의 기반 전제(Basic Premises)

  • Fail Fast
  • Self Healing
  • Horizontally Scalable Components
  • Distributed State
  • No Single Point of Failure
  • Should be as simple as possible

한글로 옮기기도 어렵고 이해하기도 어려운  용어들만 써있네. 덴장 ㅋㅋ 무학의 통찰이 필요해.

제대로 동작하지도 않는 상황에서 최적화 로직을 돌릴 필요는 없으니까 Fail Fast를 시키고 그래야 빨리 복구 시킬 수 있다. 실제로 자살하는 앱을 만들어서 배포한담에 얼마나 빨리 복구되는지 실험도 해봤다. 수평확장이 가능하기 떄문에 한 인스턴스로 4천 TPS 정도가 가능하다면 4만 TPS도 문제가 아니다. 분산 시스템이란게 본래가 복잡한데.. 가능한 단순하게 만들려고 노력한다.

기반 패턴

  • 이벤트 드리븐
  • 비동기(애싱크로너스)
  • 논 블락킹
  • Independent(인디페넌), Idempotent(아이뎀포던)
  • Message Passing
  • Eventually Consistent

클파의 신경 시스템(널브 시스템)에 대해서 이야길 많이 할텐데.. 그게 가능케 하는게 바로 idempotent하기 때문이다. 메시징 시스템은 내가 직접 만들었고.. 나머진 잘.. 몰겠네 블라블라

기반 설계(Basic Design)

  • 모든 컴포넌트는 loosely coupled 시킴
  • 메시징 기반
  • JSON 페이로드
  • HTTP 또는 File/Blob 데이터 전송

커널 특징

  • 모두 동적으로 발견한다.
  • 무작위로(? in any order) 실행하고 확장한다.
  • 필요에 따라 빠지거나 추가할 수 있다.
  • HTTP와 JSON을 사용해서 모니터링
  • Location independent

“모두 동적으로 발견한다”는 말은 신경 시스템으로 메시지를 보내서 모든 컴포넌트다 나는 어딨고 나는 무슨 타입이고 실행된지 얼마나 됐고 내 모니터링 풀은 여깄다 등등을 알수있다. 애플리케이션이 돌고 있는 IP와 포트를 알아낼 수 있지만 사실 애플리케이션이 돌고 있는 곳과 아무런 의존성이 없다.

커널 구성요소

  • 라우터
  • 클라우드 컨트롤러
  • DEA
  • HealthManager
  • Service Provisioning Agent
  • Messaging System

커널의 구성요소가 어떻게 구성되어 있는지 보여주는 논리적인 뷰인데.. HTTP REST 요청은 모두 라우터를 통해서 들어오기도 하고 일부는 애플리케이션으로 바로 들어오기도 한다. 이것은 즉 애플리케이션에 적용하는 모든 원칙을… fault tolerance, high availability, scaling을 커널 구성요소에도 그대로 적용한다는 뜻이다. DEA 풀은 매우 클수도 있고 매우 작을 수도 있다. 헬쓰매니저는 이곳에서 유일하게 싱글톤이다.

이건 아키텍처인데 녹색은 HTTP, 파랑은 메시징, 보라는 뭐지..? 왜 말을 안해;;;

오늘은 여기까지. 20분 48초.

 

[클파:인사이드] 클파의 목적은?

http://www.infoq.com/presentations/Cloud-Foundry-Inside-the-Machine

http://www.slideshare.net/derekcollison/design-of-cloud-foundry

Goal!

  • Raise the unit of currency to be the application and its associated services, not the infrastructures.
  • Best of breed delivery platform for all modern applications and frameworks.
  • Favor choice and openness.

여기까지가 6분 13초. 이 뒤부터 본격적인 내용이 시작인데… 볼 시간이 없구나. 스프링 강의 시작해야겠다;

 

 

[Cloud Foundry: Inside the machine] What is the Cloud Foundry? [클파:인사이드] 클파는 뭐다?

http://www.infoq.com/presentations/Cloud-Foundry-Inside-the-Machine

http://www.slideshare.net/derekcollison/design-of-cloud-foundry

클파 인사이드 동영상 강의 완벽 분석을 위해서 블로깅 시작… 먼저 클파란 무엇인가? (여기서 클파는 붙여쓰지 않는데 주목.. 가끔 붙여썼는데 앞으론 띄어써야겠다.)

한 마디로 The Open Platform as a Service라고 말할 수 있는데 플랫폼을 어떻게 정의하느냐에 따라 다들 PaaS 얘기하는게 장황해서.. 좀 더 구체적으로 말하자면 aPaaS라고 말할 수 있다.

aPaaS라고쓰고 앱패스 라고 읽는다.

aPaas란..

  • Application Platform as a Service
  • Applications and Services
  • 이것에 집중하는것이지… 다음과 같은건 신경쓰지 않는다.
    • VM, Memory, Storage, Networks, CPUs

그러니까.. 클파는 뭐다? 앱패스다.

이게 끝일까? 아니다. 클파는 OpenPaaS이기도 하다. 오픈 패~스.

데릭이 말하길… 그들은 트룰리 이코 시스템 플랫폼을 원한단다…

OpenPaaS란..

  • 다양한 언어
    • 루비, 자바, 스칼라, 노드제이에스, 얼랑, 파이썬, PHP
  • 다양한 프레임워크
    • 레일스, 시나트라, 스프링, 그레일스, 익스프레스, 리프트
  • 다양한 서비스
    • 마이시퀄, 포스트그레스, 몽고디비, 레디스, 래빗엠큐
  • 다양한 Cloud, 다양한 IaaS
    • vSphere, OpenStack, AWS, MicroCloud
  • 하이브리드, Public 하게 구성하거나 Private 하게 구성하거나 둘을 혼용하거나..
  • 그리고 이걸 모두 오픈 소스로… 캬..

출처: http://www.slideshare.net/derekcollison/design-of-cloud-foundry

그러니까.

클파는 == 앱패스 && 오픈패스.