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초.