Open Application Model 스펙 정리하기

https://github.com/oam-dev/spec에 나온 공식 OAM 스펙을 기반으로 정리한 내용입니다. 

의도, 목적

Cloud Native Application Deployment를 어떻게 하는지 명세하는 Runtime-Agnostic한 표준을 정의하는 것

Cloud Native Application?

A cloud native application is a collection of interrelated, but discrete components (services, tasks, workers) that, when coupled with configuration and instantiated in a suitable runtime, together accomplish a unified functional purpose.

 

서로 관련이 있지만 독립적이고 완결성있는 각자만의 기능을 하는 분리된 Component가

특정 Runtime에서 Configuration되고 인스턴스화 되면서 결합하여 하나의 목표를 수행하는 어플리케이션

 

Runtime-Agnostic?

Runtime이 hybrid 환경이냐, Clouds 환경이냐, 심지어는 Edge Devices환경이냐에 상관없는 것.

특정 Runtime에 종속적인 내용을 사용하지 않는 것.

 

다음과 같은 것은 달성하고자 하는 바가 아니다.

• 특정한 Orchestrating Workflow를 정의하는 것
• Operational Resources를 정의하는 것 (such as Networks, Volumes...)
• Runtime을 정의하거나 묘사하는 것

Overview

Cloud Native Application 의 정의에 따라서 OAM에서는 다음과 같은 Model들을 제공한다.

• Component
  • 실행 가능한 단위
• Workload type
  • Component가 실행할 수 있는 workload를 정의한다.
• Trait
  • Operator Concerns을 대표한다. (Not Developer Concerns)
  • Component에 부가적인 Operations-Specific 기능을 추가하여 기능을 확장하는 것
• Application Scope
  • 해당 Component에 적용되는 공통된 Property와 Dependency를 포함한다.
  • Component를 Grouping하여 Application Boundary를 표현하는 것.
• Application Configuration
  • Parameter와 Metadata를 설정하는 곳
  • Component (Traits + Application Scope)의 집합을 모아서 위치시키는 곳.

Component (What to deploy?)

하나의 Functional Unit을 표현한다.

커다란 Application 배포의 일부로써 인스턴스화 될 수 있다.

Application을 통해서 다른 Component와 그룹화 되고, 설정된다.

 

실제 예시로 생각해보면, 각 Microservice는 하나의 Component로 정의될 수 있다.

실제로 인스턴스화 되는 시점은 Application Deployment시점이므로 여기에선, 설정가능한 Runtime 속성들을 정의하도록 한다.

ComponentDefinition

Component Provider가 인프라-독립적 포맷으로 Component를 정의할 수 있도록 하는 entity다.

Workload Type

Platform이 제공한다.

따라서 Platform에서 어떤 Workload Type을 제공하는지 학습해야 한다.

End User는 새로운 Workload Type을 만들지 않도록 한다.

WorkloadDefinition

각 OAM-Runtime은 자신의 Workload Type을 정의할 수 있다.

The Relationship of Component and Workload Type

Traits System이 어떤 Trait를 이 Component에 붙힐 것인지 말지를 결정하는데 Workload Type을 알아야한다.

Component는 본인의 Workload Type이 무엇인지 캡슐화 하게된다.

Workload?

k8s에서 실행되는 app.

하나 이상의 component 집합이여도 상관 없다.

k8s의 built-in Workload 예시

• Deployment
• ReplicaSet
• StatefulSet

Application Scope

여러 Component를 하나로 묶는 논리적인 Application.

그룹화된 Component에 공동의 Property와 Dependency를 제공하는 것.

• 행동이나 그룹의 Component간의 공통의 메타데이터를 정의하기 위해서 사용한다.
• 하나의 Component는 여러 개의 Application Scope를 통해서 동시에 배포될 수 있다.
• Component가, 같은 Application Scope타입의 instance로 배포될 수 있는지 결정할 수 있다.
• Component의 그룹과 infrastructure에 의해서 제공되는 용량들(networking, ...)을 연결하는 메커니즘 처럼 사용할 수 있다.

Trait (How to operate?)

일종의 runtime overlay로써, Component의 Workload instance에 Operational Feature을 추가한다.

예를 들어, sidecar trait는 해당 workload에 sidecar container를 추가한다.

Operational Feature가 정확히 무엇인가?

Application (ApplicationConfiguration)

Application Deployment시점에 어떤 Component들을 인스턴스화 할지 정의하는 곳

각 Component, Trait, Scope의 구체적인 Parameter를 적는 곳

Component instance

• Application Deployment 시점에 생성된다.
• Upgrade, New Revision 시점에 생성된다.

Design Principles

Separation of Concerns

Component, Application, Schematics, Configuration 등 과 같이, 독립적인 functional, behavioral 인 것들로 나누어저 구성되어 있다.

이러한 것을 만들 때, 다양한 사용자 그룹의 역할과 책임을 기준으로 나누게 된다.

Runtime Neutrality

특정한 runtime feature를 가정하지 않는다.

원하는 형상과 동작을 특정한 platform에 독립적이게 명세할 수 있도록, 공통된 term을 제공하는 것이 목적이다.

Balance(Elegance)

불필요한 복잡성을 제거해서 여러개의 역할을 동시에 수행해야 하는 작은 팀에서도 쓸 수 있도록 하자.

Reusability

Application Models are not Programming Models

Application Model

Application를 구성하는 Component의 Topology의 조합을 명세하는 것이다.

어떻게 각 Component가 구현되었는가는 관심 영역이 아니다.

Programming Model

어떻게 각각의 software들이 구성되었는가?

그리고 OPM은 Programming Model에 독립적인 Application Model을 정의하는 기능을 제공한다.

참고

https://github.com/oam-dev/spec