파스-타 인사이드

실행환경

실행환경은 Cloud Foundry 오픈 소스를 기반으로 구성됩니다.

구성 요소의 기능 및 역할

1. Router
사용자 요청 트래픽을 목적지로 라우트하는 역할을 수행합니다. 주 목적지는 Cloud Controller이나 응용애플리케이션을 실행하고 있는 Garden Container 가 됩니다. Router의 라우터 정보는 Diego가 서비스하고 있는 애플리케이션 인스턴스 정보를 Receptor에서 수신하여 Route-emitter를 통해 업데이트 받습니다. Router와 route-emitter 모듈은 미래에 통합될 예정입니다.
Git 소스: https://github.com/cloudfoundry/gorouter
2. Router-Emitter
Receptor로부터 실제 LRP(ActualLRP) 상태를 모니터링하여, 목표 LRP((DesiredLRP) 와 비교하여 변경이 발생한 경우 Router 로 route 정보 등록/해제 요청 메시지를 보냅니다. 주기적으로 전체 라우팅 테이블을 Router로 보냅니다.
Git 소스: https://github.com/cloudfoundry-incubator/route-emitter
3. Cloud Controller
애플리케이션 스테이징과 실행을 위한 API를 제공합니다. 빌드팩 선정, 서비스와 바인딩, 접근 인가처리와 같은 애플리케이션의 전반적인 관리를 담당합니다.
개발자가 CLI를 통해 애플리케이션을 Cloud Foundry로 전송하면 Cloud Controller 가 수신하게 되며, Cloud Controller 는 애플리케이션 바이너리를 저장 후 애플리케이션 메타 데이터 기록을 생성하고 Diego와 통신하여 Stage 상태 준비 및 애플리케이션 실행을 지시합니다. Cloud Controller는 서비스를 위해 조직, 스페이스, 서비스, 서비스 인스턴스, 사용자 역할 등의 정보 유지를 위한 데이터베이스와 애플리케이션 코드 및 빌드팩 저장 등을 위한 Blob 저장소를 유지합니다.
Git 소스: https://github.com/cloudfoundry/cloud_controller_ng
4. CC-Bridge
  • CC-Bridge는 CC와 상호통신하며, CC의 애플리케이션 고유 메시지를 일반 Task와 LRP로 변환하여 Receptor로 전달하는 중재 역할을 담당합니다. 4개의 하위 모듈로 구성됩니다.

  • 1

    Stager는 CC로부터 스테이징 요청을 수신하여 일반 Task로 변환 후 Receptor에 요청합니다. Task Action을 통해 Diego Cell을 지시하여, 실제 스테이징 프로세스 수행 단계에서 플랫폼 고유 바이너리를 주입하게 합니다. Task 수행 완료 시 CC에 결과를 전송합니다.
    Git 소스: https://github.com/cloudfoundry-incubator/stager

  • 2

    Nsync는 애플리케이션 상태를 요청 받아 Receptor를 통해 목표 LRP를 생성하거나 업데이트, 삭제합니다. 또한 주기적으로 CC 에 요청하여 애플리케이션 전체 목표 상태를 Diego 목표 상태와 비교하고 일치하도록 유지합니다.
    Git 소스: https://github.com/cloudfoundry-incubator/nsync<

  • 3

    TPS는 CC에 현재 실행 중인 LRP 정보를 제공합니다. CC는 이 정보를 이용하여 “cf apps” 및 “cf app X” 요청에 응답합니다.
    Git 소스: https://github.com/cloudfoundry-incubator/tps

  • 4

    File-Server는 Executor 의 단순 HTTP POST 요청을 CC의 multipart-form의 업로드로 변환하는 역할을 수행합니다. 여러 컴포넌트에서 사용되는 정적 자원을 서비스하며, 특히 애플리케이션 라이프 사이클의 바이너리를 제공합니다.
    Git 소스: https://github.com/cloudfoundry-incubator/file-server

5. UAA
OAuth2 서버 및 로그인 서버로 동작하여 사용자 인증 관리를 제공합니다.
Git 소스: https://github.com/cloudfoundry/uaa
6. Receptor
RESTful HTTP API를 구현하여 Task와 목표 LRP(DesiredLRP) 요청을 수신하고 현재 실행 중인 Task 및 LRP 인스턴스 현황 정보를 Diego 클라이언트에 제공합니다.
Git 소스: https://github.com/cloudfoundry-incubator/receptor
7. Rep
Cell을 대표하며 BBS를 통해 다양한 서비스를 수행합니다. 즉, BBS의 Task 및 ActualLRP 정보가 Cell 내의 실제하고 있는 컨테이너와 일치하는지 확인하고, BBS 내 Cell이 실재하도록 유지합니다. 특정 Cell 이 실패할 경우, Converger 가 자동으로 해당 인스턴스를 다른 Cell로 이전시킵니다. 또한 Tasks/LRP 수신을 위해 Auction 에 참여하며, Executor에 요청, Tasks/LRPs를 실행하여 컨테이너를 생성하고 컨테이너 내에서 수행될 액션을 실행합니다.
Git 소스: https://github.com/cloudfoundry-incubator/rep
8. Executor
컨테이너의 생성 및 컨테이너 내 액션 수행, 컨테이너 삭제를 위한 HTTP API를 제공합니다. Task 및 LRP를 구분하지 않으며, 수행 액션을 위한 Action API를 구현합니다. Executor는 Cell에서 실행중인 metron-agent로 Stdout 과 Stderr 스트림을 전송하며, 해당 스트림은 Loggregator로 전달됩니다.
Git 소스: https://github.com/cloudfoundry-incubator/executor
9. Garden
컨테이너 관리를 위한 플랫폼 독립적인 서버 및 클라이언트 인터페이스를 제공합니다. 인터페이스는 다음의 액션 수행을 위한 메소드를 정의합니다.
- 컨테이너의 생성 및 삭제
- 컨테이너의 리소스 제약 적용
- 컨테이너에 네트워크 포트 연결 및 개발
- 컨테이너 내부/외부로 파일 복사
- 컨테이너 내 프로세스 실행과 Stdout 및 Stderr 데이터 스트리밍 처리
- 컨테이너에 임의 메타데이터
- 다운타임 없이 재배포하기 위한 컨테이너 스냅샷 생성
현재 Garden 인터페이스를 구현한 Linux 구현체로 Garden-linux 가 제공됩니다.
Git 소스: https://github.com/cloudfoundry-incubator/garden
10. App Lifecycle
  • Cloud Foundry 에서 실행될 애플리케이션의 라이프사이클을 관리하기 위한 Builder, Launcher, Healthcheck의 3가지 바이너리를 제공합니다.

  • 1Builder는 CF 애플리케이션의 스테이징을 수행합니다. CC-Bridge는 스테이징 요청을 Task로 요청하며, Builder는 애플리케이션 실행 전 코드 정적분석과 필요한 사전 작업을 수행합니다.

  • 2Launcher는 CF 애플리케이션을 실행합니다. CC-Bridge는 애플리케이션 목표 LRP(DesiredLRP)를 Action으로 요청하며, Launcher는 사용자가 지정한 시스템 환경 설정과 시작 명령을 수행합니다.

  • 3Healthcheck는 컨테이너 내에서 실행중인 CF 애플리케이션의 상태 점검을 수행합니다. CC-Bridge는 애플리케이션 목표 LRP(DesiredLRP)에 Healthcheck를 위한 모니터링 Action을 추가합니다.

  • 4현재 구현체로 Buildpack과 Docker 두가지 유형이 제공됩니다.
    Git 소스:
    - Buildpack-App-Lifecycle https://github.com/cloudfoundry-incubator/buildpack_app_lifecycle
    - Docker-App-Lifecycle https://github.com/cloudfoundry-incubator/docker_app_lifecycle

11. Auctioneer
Task와 AcutalLRP 인스턴스를 위한 auction을 저장합니다. Auctioneer와 Cell Reps 간 auction 을 HTTP로 통신합니다.
Git 소스: https://github.com/cloudfoundry-incubator/auctioneer
12. Converger
Task와 LRP의 Eventual consistency 및 fault tolerance를 보장하기 위해 BBS runtime-schema 의 converge 메소드를 사용합니다. LRP 조정 시 Converger는 DesiredLRP와 ActualLRP 상태가 일치하기 위해 필요한 조치를 수행합니다. 즉 만약 인스턴스가 부족한 경우, 시작 auction을 전송합니다. 인스턴스가 초과된 경우, 인스턴스를 호스팅하고 있는 Cell의 Rep에 정지 메시지를 전송합니다.
Git 소스: https://github.com/cloudfoundry-incubator/converger
13. Metrics-Server
BBS에서 metrics를 읽어 Droppler로 전송합니다.
Git 소스: https://github.com/cloudfoundry-incubator/runtime-metrics-server
14. Auction
Auction 시 행위 상세 정보를 저장합니다. Auctioneer와 Rep가 auciton에 참여하기 위해 Auction패키지를 이용합니다. 알고리즘의 정확성과 성능 검증을 위한 시뮬레이션 테스트를 포함합니다.
Git 소스: https://github.com/cloudfoundry-incubator/auction
15. BBS
Etcd 메시지 서비스 이용하며, Diego 컴포넌트와 Etcd 간 커뮤니케이션 정보를 인코딩합니다. Receptor, Rep, Converger가 사용합니다.
Git 소스: https://github.com/cloudfoundry-incubator/runtime-schema
16. Service Brokers
메시지큐, 데이터베이스와 같은 애플리케이션 실행 시 연동되어 사용되는 서비스를 위해 서비스 인스턴스를 생성합니다. SaaS 형태로 서비스를 제공하는 업체는 애플리케이션에 서비스 제공을 위해 Service Brokers를 구현하고 서버로 제공해야 합니다.
Git 소스: https://github.com/cloudfoundry/cf-mysql-broker
17. Buildpacks
언어 및 프레임워크을 감지하고 필요한 라이브러리를 다운받아 소스코드를 실행 파일로 컴파일 후 런타임환경과 함께 빌드팩을 생성합니다.
Git 소스:
- Java buildpack: https://github.com/cloudfoundry/java-buildpack
- Ruby buildpack: https://github.com/cloudfoundry/ruby-buildpack
- Nodejs buildpack: https://github.com/cloudfoundry/nodejs-buildpack
- Php buildpack: https://github.com/cloudfoundry/php-buildpack
- Go buildpack: https://github.com/cloudfoundry/go-buildpack
- Python buildpack: https://github.com/cloudfoundry/python-buildpack
18. NATS
Pub-Sub 패턴의 분산 메시지 큐를 지원하는 시스템으로 Cloud Foundry 컴포넌트 간 통신에 사용합니다.
Git 소스: https://github.com/apcera/gnatsd
19. Doppler

서비스환경

서비스 및 서비스 브로커 API 아키텍처를 보여줍니다.

서비스 아키텍처

구성 요소의 기능 및 역할

PaaS-TA 서비스 API는 Cloud Controller 와 서비스 브로커 사이의 규약(catalog, provision, unprovision, updateprovision, bind, unbind)을 정의합니다.
브로커는 HTTP (or HTTPS) endpoints URI 형식의 RESTful API로 구현됩니다. 하나 이상의 서비스가 하나의 브로커에 의해 제공 될 수 있고, 로드 밸런싱이 가능한 수평적 확장이 제공 될 수 있습니다.

또한 여러 실행환경의 서비스 인스턴스는 다른 URL 접두사 및 자격 증명(credentials)을 사용하여 하나의 브로커에 의해 지원 될 수 있습니다.
서비스는 서비스 브로커 API 라고 불리우는 cloud controller 클라이언트 API를 구현하여 실행환경에서 사용됩니다.

서비스 API는 독립적인 cloud controller API의 버전입니다.
이는 플랫폼에서 외부 application을 이용 가능하게 합니다.(database, message queue, rest endpoint, etc)

서비스 브로커 API 아키텍처

개발환경

개발 도구 통합을 위한 개방형 플랫폼으로, IDE 기반으로 Edit 기능을 제공합니다.

WST 확장
- Web 프로젝트 개발/배포
JST 확장
- J2EE 스펙의 애플리케이션 개발
CC REST API와 연동
- PaaS-TA 실행환경과 cf-client-lib를
  통해 연동

구성 요소의 기능 및 역할

  • - 이클립스 통합개발환경 플러그인으로 제공
  • - GUI 환경의 PaaS-TA 애플리케이션 개발 및 배포 관리
  • - 이클립스 프로젝트를 PaaS-TA 실행환경에 배포할 수 있는 환경 제공
  • - 애플리케이션 자원 설정, 서비스팩 바인딩, 라우트 설정 등 애플리케이션 관리 기능 제공
  • - 기존 eGovFrame 개발환경에 통합하여 사용 가능
인증정보 관리 PaaS-TA 실행환경 인증 정보 등록/관리
조직 및 목표 스페이스 연결
애플리케이 배포 관리 이클립스 프로젝트 패키징
애플리케이션을 PaaS-TA 실행환경에 배포
애플리케이션 관리 애플리케이션 메모리 관리
애플리케이션 인스턴스 관리(수평확장)
애플리케이션 상태 제어
애플리케이션 삭제
서비스팩 인스턴스 관리 서비스팩 인스턴스 생성/삭제
서비스팩 인스턴스 바인딩 관리
라우트 관리 애플리케이션 라우트 관리
환경변수 관리 런타임 애플리케이션 환경변수 관리
인스턴스 로그 관리 애플리케이션 인스턴스 로그 스트리밍

운영환경

웹 사용자 인터페이스 환경에서 플랫폼을 관리할 수 있도록 합니다.

운영환경 구성

구성 요소의 기능 및 역할

관리자 대시보드는 CCDB, UAADB로부터 데이터를 조회하고 PaaS-TA 실행환경에서 제공하는 REST API 호출을 통해 상호작용하며,
웹 사용자 인터페이스 환경에서 플랫폼을 관리할 수 있도록 합니다.

관리자 대시보드(admin-ui)는 웹 인터페이스를 통해 PaaS-TA의 데이터를 관리할 수 있도록 하는 웹 애플리케이션입니다.
루비 언어로 작성된 백엔드 애플리케이션과 백엔드 애플리케이션에서 제공하는 REST API를 AJAX 통신을 통해 데이터와 웹 사용자 인터페이스를 제공하는 프론트엔드 애플리케이션으로 구성되어 있습니다.

관리자 대시보드는 데이터 조회 시에는 CCDB 및 UAADB에 직접 쿼리하여 데이터를 조회하며, 조회 이 외의 기능은 PaaS-TA 실행환경의 REST API를 호출하여 처리합니다.

UAADB의 유저 데이터와 CCDB의 플랫폼 데이터(조직, 스페이스, 애플리케이션, 서비스팩, 서비스팩 브로커, 서비스팩 인스턴스, 라우트, 도메인 등)를 주기적으로 데이터를 읽은 후 메모리에 저장하여 관리자 대시보드를 통해 데이터를 빠르게 조회할 수 있도록 하며, 스케줄링 작업으로 인해 실시간 데이터 조회에는 제약이 따릅니다.

인프라 제어 및 관리 환경 구성

PaaS-TA 관리 및 배포를 위해 개발된 BOSH는 대규모 분산 시스템을 대상으로 한 배포 및 서비스의 생명주기를 관리하기 위한 공개 소프트웨어로 복수의 IaaS환경에 맞게 VM을 생성하고 소프트웨어를 설치할 수 있는 기능을 제공합니다.

BOSH는 Bosh Outter SHell의 약자로 BOSH 배포와 관련된 시스템들을 “Outter Shell”이라 부르고, 이와 반대로 BOSH에 의해 배포되고 관리되는 시스템들을 “Inner Shell”이라 부릅니다. BOSH의 주요 컴포넌트의 정의와 역할은 다음과 같습니다.
1. Command Line Interface (CLI)
CLI는 BOSH Director와 상호작용하면서 클라우드에 서비스를 배포하거나 특정 명령을 수행하도록 하는 운용도구입니다.
2. Director
Director는 VM을 생성과 배포뿐만 아니라 소프트웨어와 서비스의 생명주기를 제어하는 BOSH에서 가장 핵심적인 컴포넌트입니다.
3. Health Monitor
Health Monitor는 BOSH Agent로부터 클라우드의 상태정보들을 수집합니다.
클라우드로부터 특정 Alert이 발생하면 Resurrector를 하거나 Notification Plug-in을 통해 Alert Message를 전송할 수도 있습니다.
4. Database
Director가 사용하는 Postgres 데이터베이스로 Deployment시에 필요로하는 Stemcell / Release / Deployment의 메타 정보들을 저장합니다.
5. Blobstore
Blobstore는 Release 정보(BOSH Package의 Compiled Image외에도 자체 제작된 S/W Packages)들을 저장하는 곳으로 사용됩니다.
이러한 Release들은 BOSH CLI에 의해 업로드되고 BOSH Director에 의해 Blobstore에 저장됩니다.
운용자가 배포시 BOSH Agent는 Blobstore로부터 현재 설정된 release에 지정된 Job과 해당 Job과 관련된 Package정보를 가지고 옵니다.
6. Agent
Agent는 클라우드에 배포되는 모든 VM에 설치되고 Director로부터 특정 명령을 받고 수행하는 역할을 하게됩니다. Agent는 Director로부터 수신 받은 Job Specification(설치할 패키지 및 구성 방법)정보로부터 해당 VM에 Director의 지시대로 지정된 패키지를 설치하고, 필요한 구성정보를 설정하게 됩니다.
7. Message Bus (NATS)
Message Bus는 Director와 Agent간 통신하기 위한 publish-subscribe 방식의 Message System으로 VM 모니터링과 특정 명령을 수행하기 위해 사용됩니다.
8. Registry
Director가 VM을 생성 또는 수정할 때 설정 정보를 레지스트리에 저장합니다. 저장된 레지스트리 정보는 VM의 bootstrapping stage에서 이용됩니다.