2.0 Cloud Version Overview

[Seungpil Park]

Cloud - 고객별 cluster

1. 클라우드 이용 고객에게 클러스터 단위로 제공
2. 클러스터 생성,스케일,프로비져닝 하는 관리체계가 별도로 필요하고, 각 Iass 제공자와 Api 연계가 필요하다.
3. 고객의 클러스터에 아래와 같은 구성요소가 제공되고, Mandotary 서비스가 인스톨 된다.

• Master 1~5
• Agent N개
• Mandotary 서비스 일체
  • dc/os
  • cloud-ui
  • cloud-server
  • cloud-iam
  • cloud-db
  • cloud-config
  • eureka
  • marathon-lb
  • docker registry
  • gitlab
  • gitlab ci
  • naver pinpoint , Hbase 저장소
  • elk , Elastick search 저장소

4. Mandotary 서비스의 메뉴얼 제공, 운영사고 고객책임.

Cloud - 고객별 app unit

1. 클라우드 이용 고객에게 App 단위로 제공하고, 유엔진은 클러스터 풀을 제공한다.

2. 고객이 사용한 App 사용이력을 Elk 에서 조회하여, 빌링 시스템으로 과금해야 한다.

3. 고객이 Mandotary 서비스를 공유하는 과정에서, 어떤 서비스가 얼마만큼의 부하에서 안정적으로 서비스 될 수 있는지 측정자료가 필요하며, 자료를 토대로 고객에게 서비스 자원의 분배가 필요하다.

   • Mandotary 공유 서비스의 구분
     • 클라우드 오케스트레이터 클러스터 :
       • 앱 생성,관리
       • 도커 레지스트리
       • 유레카 서버(고객 회사별 Zone 으로 분리 / 또는 고객 회사마다 유레카 서버 하나 제공)
     • App 클러스터 :
       • 고객 수 / 앱 수 에 따라 가변적으로 변함
       • 최초 서비스에서는 하나의 DC/OS 클러스터에 맥시멈 50노드로 잡음.
       • 각 클러스터에는 malathon-lb 가 하나씩 배정.
       • 고객이 어떤 클러스터에 배정되면 계속 거기서만 앱을 배정가능(물리적인 네트워크 제약)
     • gitlab 클러스터 :
       • gitlab 퍼포먼스, High Availability 관련 측정 필요
       • gitlab ci 인스턴스 풀은 동적 확장이므로 현재 아키텍쳐 그대로 감.
     • naver pinpoint:
       • Hbase 클러스터링, High Availability 관련 측정 필요.
       • pinpoint web / collector 는 일반 웹 서비스이므로 단순 스케일링.
     • elk:
       • Elasticksearch 샤딩, High Availability 관련 측정 필요.
       • kibana / logstach 는 단순 스케일링.

4. 공유 Mandotary 서비스에 대한 24 시간 모니터링이 강제됨. Mandotary 서비스 관련된 운영 사고 유엔진 책임.

On-premise

1. 고객의 인프라 환경에 직접 설치.

Hybrid(On-premise & Cloud)

1. 고객의 인프라 환경에 설치될 Mandotary 서비스와, 유엔진이 클라우드에서 대리 운영가능한 Mandotary 서비스 로 나뉨.

   1. 고객 인프라
   • dc/os
   • cloud-ui
   • cloud-server
   • cloud-iam
   • cloud-db
   • cloud-config
   • eureka
   • marathon-lb
   • docker registry
   • gitlab
   2. 유엔진 인프라 (대용량 클러스터링 환경 구축시 다수의 이용자를 받는 것이 유리한 서비스. 별도 과금)
   • gitlab ci pool
   • naver pinpoint , Hbase 저장소
   • elk , Elastick search 저장소