統合アプリケーション管理アーキテクチャをアップグレードするためのOAMの使い方

技術専門家であるLi XiangとZhang Leiが、OAMとは何か、そしてアリババの標準化された統合アプリケーション管理アーキテクチャのアップグレードにどのように使われているかについて説明します。

![スクリーンショット 2021-05-13 14.03.26.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/91060b56-213a-dc20-d283-1a7ccef45d2d.png)


#OAMとは？
2019年10月、アリババは[OAM](https://www.alibabacloud.com/blog/announcing-the-open-application-model-oam-an-open-standard-for-developing-and-operating-applications-on-kubernetes-and-other-platforms_595450?spm=a2c65.11461447.0.0.705f4d2fpX63Kp)（Open Application Model）をマイクロソフトと共同で立ち上げることを発表しました。このキーテクノロジーは、Alibabaの統合アプリケーション管理アーキテクチャのアップグレードの中で徐々に進化していきました。

OAMは、クラウドネイティブ・アプリケーションとそのO&M機能を定義・記述するための標準化されたオープンソースの仕様です。したがって、OAMは[Kubernetes](https://www.alibabacloud.com/product/kubernetes?spm=a2c65.11461447.0.0.705f4d2fpX63Kp)アプリケーションを定義するための標準的なプロジェクトであるだけでなく（非活動的なKubernetesアプリケーションのCustom Resource Definition（CRD）プロジェクトと比較して）、様々なO&M Kubernetesの能力をカプセル化して整理・管理し、O&M能力とアプリケーションをプラットフォーム層で接続するためのプロジェクトでもあります。アプリケーションの定義とアプリケーションのO&M機能の整理・管理というコア機能により、OAMプロジェクトは、アリババが統合アプリケーション管理アーキテクチャをアップグレードし、次世代のPaaSやサーバーレスアーキテクチャを構築するための最適な選択肢となりました。


また、OAMはアプリケーションやケイパビリティを実装しません。代わりに、それらはKubernetesが提供するAPIプリミティブやコントローラによって実装されます。そのため、OAMはAlibabaがKubernetesのネイティブPaaSアーキテクチャを構築するための主要なアプローチとなっています。

OAMでは、アプリケーションは3つのコアコンセプトを含んでいます。

1、マイクロサービス、データベース、サーバーロードバランサー（SLB）など、アプリケーションを構成するコンポーネント。
2、オートスケーリング機能やingress機能など、アプリケーションのO&M特性。これらは、アプリケーションの運用に欠かせないものですが、環境によって実装形態が異なります。
3、O&M担当者は、アプリケーション構成を使用してコンポーネントと対応する特性を組み合わせ、これらの特性を特定のアプリケーションに変換してから、アプリケーション用のインスタンスを作成してデプロイします。

アリババでは、インターネットシナリオにおけるKubernetesクラスタやAlibaba Cloud製品の管理で多くの経験をOAMに提供しており、特にアリババが無数の社内アプリケーションCRDからOAMベースの標準アプリケーション定義に移行する過程で得られたものです。エンジニアとして、私たちは失敗やエラーから学び、革新と開発を続けていきます。

この記事では、より多くのユーザーにOAMを理解してもらうために、OAMの動機について詳しく説明します。

#背景
###1、我々について
私たちはAlibabaのインフラストラクチャオペレーターであり、[Kubernetes](https://www.alibabacloud.com/product/kubernetes?spm=a2c65.11461447.0.0.705f4d2fpX63Kp)チームとしても知られています。大規模なKubernetesクラスタの保守、コントローラやオペレーターの実装、各種Kubernetesプラグインの開発など、様々なレベルのKubernetesの機能開発、インストール、保守を行っています。アリババでは、私たちはプラットフォームビルダーと呼ばれています。

Kubernetesを担当するPaaSエンジニアと区別するために、本稿ではインフラストラクチャー・オペレーターと呼んでいます。ここ数年、私たちはKubernetesによって大きな成功を収め、同時に貴重な教訓も得ました。


###2、様々なKubernetesクラスターの管理
アリババのEコマース事業のために、世界最大かつ最も複雑なKubernetesクラスターを管理しています。
これらのクラスターは、

- 10,000ノードまでスケールアップ可能。
- 10,000以上のアプリケーションをホストすることが可能。
- ピーク時には毎日10万個のアプリケーションのデプロイメントを処理。


また、Alibaba Cloud [Container Service for Kubernetes](https://www.alibabacloud.com/product/kubernetes?spm=a2c65.11461447.0.0.705f4d2fpX63Kp)（ACK）もサポートしています。このサービスは、約1万台の中小規模のクラスターをホストし、外部顧客向けの他のAlibaba Cloud Kubernetes製品と同様のサービスです。当社の社内外のお客様は、ワークロード管理に対する多様な要件やユースケースをお持ちです。

###3、研究開発者にサービスを提供するアプリケーションオペレーターへサービスを提供
アリババのテクノロジースタックは、他のインターネット企業と同様に、インフラ事業者、アプリケーション事業者、ビジネス開発者が共同で実装しています。ビジネスデベロッパーとアプリケーションオペレーターの役割は次のとおりです。

###ビジネスデベロッパー
ビジネスデベロッパーは、ビジネス価値をコードで提供します。ほとんどのビジネスデベロッパーは、インフラストラクチャやKubernetesに精通していません。その代わり、PaaSやCIパイプラインを使ってアプリケーションを管理します。ビジネス開発者の生産性は、Alibabaにとって大きな価値があります。

###アプリケーションオペレーター
アプリケーションオペレーターは、ビジネスデベロッパーに対して、クラスターの容量、安定性、パフォーマンスに関する専門知識を提供し、大規模なアプリケーションの設定、デプロイ、実行（アプリケーションの更新、スケールアウト、リストアなど）を支援します。アプリケーションオペレーターは、KubernetesのAPIや機能について一定の知識を持っていますが、Kubernetesを直接操作することはありません。PaaSを使ってKubernetesの基本機能をビジネスデベロッパーに提供するケースが多く、アプリケーションオペレーターの多くはPaaSのエンジニアです。

要約すると、インフラ事業者は、ビジネスデベロッパーにサービスを提供するアプリケーションオペレーターへサービスを提供します。

#連携の課題
前述したように、三者はそれぞれ異なる専門知識を持っていますが、スムーズに連携するためには、Kubernetesでは難しい連携が必要になります。

以下では、これらの当事者のペインポイントについて説明します。要するに、根本的な問題は、それらの間の効率的で正確な相互作用のための標準を欠いていることです。これは、非効率的なアプリケーション管理プロセスや、最終的な運用の失敗につながります。OAMはこの問題を解決する鍵となります。

###インフラ事業者とアプリケーション事業者の相互作用
Kubernetesは拡張性が高く、インフラ事業者はO&M機能を思い通りに構築することができます。しかし、Kubernetesの柔軟性は、これらの機能の利用者（アプリケーション運用者）に問題をもたらすこともあります。

例えば、CRON式をベースにアプリケーションを拡張するためのCron Horizontal Pod Autoscaler（CronHPA）Custom Resource Definition（CRD）を開発しました。これは、日中と夜間で異なるスケールアップポリシーが必要な場合に有効です。CronHPAはオプション機能で、クラスターにのみオンデマンドで導入されます。CronHPAのYAMLファイルのサンプルは以下のようになります。

```
apiVersion: "app.alibaba.com/v1"
kind: CronHPA
metadata:
  name: cron-scaler
spec:
  timezone: America/Los_Angeles
  schedule:
  - cron: '0 0 6 * * ?'
    minReplicas: 20
    maxReplicas: 25
  - cron: '0 0 19 * * ?'
    minReplicas: 1
    maxReplicas: 9
  template:
    spec:
      scaleTargetRef:
        apiVersion: apps/v1
        name: php-apache
      metrics:
      - type: Resource
        resource:
          name: cpu
          target:
            type: Utilization
            averageUtilization: 50
```

これは、Kubernetesにおける典型的なCRDであり、直接インストールして使用することができます。しかし、これらの機能をアプリケーションオペレーターに提供した後、アプリケーションオペレーターがCronHPA CRDのようなCRDを使用する際に、すぐに問題が発生します。

###1、 KubernetesのCRDの使い方の間違い
アプリケーションオペレーターからは、specについて不満の声がよく聞かれます。specは、CRDの中に現れたり、ConfigMapの中に現れたり、設定ファイルの中にランダムなパスで現れたりします。また、CNIやCSI（Container Storage Interface）プラグインなど、Kubernetesの多くのプラグインのCRDが、単にそれらのインストール手順であって、ネットワーク機能やストレージ機能などの対応する機能の説明ではないことについて、アプリケーションオペレータは困惑しています。

###2、Kubernetesクラスタが特定の機能を持っているかどうかの判断が難しい
アプリケーションオペレーターは、O&M機能がクラスタに備わっているかどうか、特に新しく開発されたプラグインによって提供されている場合には、よくわかりません。インフラ担当者とアプリケーション担当者が何度もコミュニケーションを取り、問題点を明確にしていく必要があります。また、管理面でも課題があります。


###3、O&M機能間のコンフリクトは対処が難しい場合がある
KubernetesクラスタにおけるO&M機能間の関係は、以下のタイプに分類できます。

- Orthogonal:能力は互いに独立しています。例えば、トラフィック管理にはingressを、ストレージ管理にはpersistent storageを使用します。
- Combinable:複数の機能を同じアプリケーションに協調して適用できます。例えば、アプリケーションのアップグレードにはrolloutを、プログレッシブトラフィックスイッチングにはcontrol ingressを使用します。
- Conflicting:複数の機能を同じアプリケーションに適用することはできません。例えば、Horizontal Pod Autoscaler（HPA）とCronHPAは、同じアプリケーションに適用すると競合します。

直線的で組み合わせ可能なケイパビリティは安全性が高く、相反するケイパビリティは予期しない、または予測不可能な操作をもたらす可能性があります。


Kubernetesはコンフリクトの事前警告を送ることができず、アプリケーションオペレータは同じアプリケーションで2つのコンフリクトするO&M機能を使用する可能性があります。コンフリクトが発生すると、それを解決するためのコストがかさみます。極端な例では、これらのコンフリクトが災害につながることもあります。

では、アプリケーションオペレータは、互いに競合する可能性のあるO&M機能をどのように特定し、管理するのでしょうか。インフラ事業者は、アプリケーション事業者に有利なO&M機能を構築することができるのでしょうか？

#OAMにおけるO&M特性
OAMでは、O&M特性を使用して、プラットフォーム層の発見可能で管理可能な能力を記述し、構築します。これらのプラットフォーム層の能力は、基本的にアプリケーションのO&M特性です。

###1、 発見可能なO&M機能の構築
ACKでは、ほとんどの特性はインフラ運営者によって定義され、Kubernetesのカスタムコントローラを使って実装されます。例えば、以下のようなものです。


- Ingress
- Autoscaler
- Volume-mounter
- Traffic-shifting and Security-policy

TraitsはKubernetesのプラグインと同等ではありません。例えば、クラスターには、動的なQoS（Quality of Service）特性、帯域制御特性、トラフィックミラーリング特性など、複数のネットワーク関連の特性がある場合があります。これらの特性はすべて、1つのCNIプラグインで提供されます。

traitsはアプリケーションオペレーターのためにKubernetesクラスタにインストールされます。traitsとして機能が提示されると、アプリケーションオペレーターはkubectl getコマンドを実行して、クラスタがサポートするO&M機能を発見することができます。

```
$ kubectl get traitDefinition
NAME                AGE
cron-scaler         19m
auto-scaler         19m
```

前述の例では、クラスタがcron-scalerとautoscalerの両方の機能をサポートしていることを示しています。ユーザーは、CRONベースのスケールアウトポリシーを必要とするアプリケーションをクラスターに展開することができます。

traitは、特定のO&Mケイパビリティの構造化された説明を提供します。これにより、アプリケーションオペレーターは、kubectl describeコマンドを実行することで、特定のケイパビリティを簡単かつ正確に理解することができます。ケイパビリティの説明には、traitのワークロードと使用方法が含まれています。

たとえば、kubectl describeコマンドを実行して、TraitDefinitionタイプのcron-scalerケイパビリティを問い合わせることができます。

```
apiVersion: core.oam.dev/v1alpha2
kind: TraitDefinition
metadata:
  name: cron-scaler
spec:
  appliesTo:
    - core.oam.dev/v1alpha1.ContainerizedWorkload
  definitionRef:
    name: cronhpas.app.alibaba.com
```

OAMでは、DefinitionRefでtraitの使用方法を記述するためにCRDが使用されており、KubernetesのCRDからも切り離されています。

trait の仕様は trait の実装から分離されています。traitの仕様は、異なるプラットフォームや環境において、異なる技術に基づいて実装することができます。実装層は、既存のCRD、統一された記述を持つ中間層、または最下層の異なる実装に接続することができます。Kubernetesのingressのような特定のケイパビリティには何十ものインプリメンテーションがあるかもしれないので、仕様とインプリメンテーションの分離は非常に有用です。traitは、アプリケーションオペレーターが正確に理解して使用できるように、統一された記述を提供します。

###2、管理可能なO&Mケイパビリティの構築
アプリケーションオペレーターは、ApplicationConfigurationを使用して、アプリケーションにインストールされた1つまたは複数のtraitを設定できます。ApplicationConfiguration コントローラは、特性の競合を処理します。以下に ApplicationConfiguration の例を示します。

```
apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
  name: failed-example
spec:
  components:
    - name: nginx-replicated-v1
      traits:
        - trait:
            apiVersion: core.oam.dev/v1alpha2
            kind: AutoScaler
            spec:            
              minimum: 1
              maximum: 9
        - trait:
            apiVersion: app.alibabacloud.com/v1
            kind: CronHPA
            spec:            
              timezone: "America/Los_Angeles"
              schedule: "0 0 6 * * ?"
              cpu: 50
              ...
```


OAMでは、ApplicationConfigurationコントローラは、これらの特性間の互換性を確保する必要があります。これが失敗した場合、アプリケーションのデプロイは直ちに失敗します。そのため、アプリケーションオペレーターがYAMLファイルをKubernetesに提出すると、OAMコントローラはtraitの競合によるデプロイの失敗を報告します。このようにして、アプリケーションオペレーターはO&M能力の競合を予見することができます。

一般的に、私たちのKubernetesチームは、アプリケーションオペレーターのミスを防ぐことができない長ったらしいメンテナンス仕様やO&Mガイドラインを使うよりも、OAM traitを使ってKubernetesベースの発見可能で管理可能なO&M能力を提示することを好んでいます。これにより、アプリケーション運用者はO&M機能を組み合わせて、コンフリクトのないアプリケーションO&Mソリューションを構築することができます。

#アプリケーションオペレーターとビジネスデベロッパーとの交流
KubernetesのAPIは、アプリケーションオペレータとビジネスデベロッパーの両方に公開されています。つまり、誰もがKubernetes APIのどのフィールドにも責任を持てるということです。このようなAPIをオールインワンAPIと呼びます。初心者にも優しいのです。

異なる関心事を持つ複数のチームが同じKubernetesクラスタで共同作業を行う必要がある場合、特にアプリケーションオペレーターとビジネスデベロッパーが同じAPIで共同作業を行う必要がある場合、そのようなAPIの欠点が顕著になります。以下は、デプロイ用のシンプルなYAMLファイルを示しています。

```
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      deploy: example
  template:
    metadata:
      labels:
        deploy: example
    spec:
      containers:
        - name: nginx
          image: nginx:1.7.9
          securityContext:
            allowPrivilegeEscalation: false
```

アプリケーションオペレーターとビジネスデベロッパーは、クラスター内でYAMLファイルを完成させる前にオフラインミーティングを行う必要があります。しかしなぜこのような時間のかかる複雑な協力をしなければならないのでしょうか？

#フィールドは関係ない
この場合、ビジネスデベロッパーがデプロイ用のYAMLファイルを完成させるのが最も簡単な方法です。しかし、デプロイ用のフィールドの中には、自分とは関係のないものがあることに気づくかもしれません。例えば、次のような質問を考えてみましょう。

**allowPrivilegeEscalationフィールドを知っているビジネスデベロッパーは何人いるでしょうか？**

このフィールドを知っている人はほとんどいません。本番環境では、アプリケーションがホスト内で適切な権限を持つようにするために、このフィールドを（デフォルトではtrueであるのに対し）falseに設定する必要があります。実際には、このフィールドはアプリケーションオペレーターのみが設定できます。ビジネスデベロッパーは、このようなフィールドの意味を推測するか、あるいはこれらのフィールドを無視することしかできません。


#アプリケーションオペレーターとビジネスデベロッパーのどちらがフィールドを担当するか？
Kubernetesについてご存知の方は、Kubernetesのフィールドを完成させる当事者を決定するのが難しいことに気づかれるかもしれません。

例えば、ビジネスデベロッパーがデプロイ用のYAMLファイルでレプリカを3に設定する場合、その値はアプリケーションのライフサイクルを通じて一定であると想定します。

しかし、ほとんどのビジネスR&D担当者は、KubernetesのHPAコントローラがreplicasフィールドを引き継ぐことができ、ポッドの負荷に応じてその値を変更する可能性があることを知りません。システムによって自動的に行われる変更は、次のような問題を引き起こします。ビジネスデベロッパーがreplicasの値を変更しようとしても、新しい値が有効になりません。

この場合、KubernetesのYAMLファイルでは最終的なワークロードを指定できず、ビジネスデベロッパーを混乱させてしまいます。そこで私たちはこの問題を解決するためにfieldManagerを使おうとしました。なぜ変更が必要なのかを把握できないため、困難な作業となります。

#アプリケーションオペレーターとビジネスデベロッパーの分離で問題は解決できるのか？
KubernetesのAPIを利用する場合、ビジネスデベロッパーとアプリケーションオペレーターの関心事がどうしても混在してしまいます。そのため、複数の参加者が同じAPIをもとに共同作業を行うことは困難です。

また、アリババのPaaSなどのアプリケーション管理システムの多くは、Kubernetesのすべての機能を公開していないことがわかります。つまり、ビジネスデベロッパーに対して、さほど多くのKubernetesのコンセプトを公開していないのです。

最も簡単な解決策は、ビジネスデベロッパーとアプリケーションオペレーターの間に境界を設けることです。例えば、ビジネスデベロッパーのみがデプロイ用のYAMLファイルに特定のフィールドを設定できるようにすればいいのです。これはAlibabaの多くのPaaSプラットフォームで採用されています。しかし、この方法ではうまくいかない場合もあります。

#アプリケーションオペレーターにはビジネスデベロッパーからの提案が必要
多くの場合、ビジネスデベロッパーは、アプリケーションオペレーターにO&Mに関する自分の意見を受け入れてもらいたいと考えています。例えば、ビジネスデベロッパーは、アプリケーションのために10個のパラメータを定義しましたが、アプリケーションオペレーターは、異なる実行環境に適応するために、これらのパラメータを上書きすることがあります。では、ビジネスデベロッパーは、アプリケーションオペレーターが5つの特定のパラメータだけを変更することを許可することができるでしょうか？

ビジネスデベロッパーとアプリケーションオペレーターが分離した状態で、アプリケーション管理プロセスにおいてビジネスデベロッパーのO&M意見を伝えることは非常に困難です。多くの場合、ビジネスデベロッパーは自分のアプリケーションについて多くの情報を伝えたいと思っているでしょう。

- スケールアウトできない（つまり、1つのインスタンスしか認められない）
- 長時間稼働するサービスではなく、バッチジョブであること
- 最高のセキュリティレベルを要求する

ビジネスデベロッパーはアプリケーションのことを一番よく知っているので、前記の要求はすべて合理的です。このような状況下で、Alibaba Kubernetesがビジネス開発者とアプリケーション運用者に別々にAPIを提供し、ビジネスデベロッパーがO&Mのニーズを効果的に伝えられるかどうかが課題となります。

#OAMにおけるコンポーネントとアプリケーション設定
OAMでは、KubernetesのAPIを論理的に分割し、ビジネスデベロッパーが分野を指定してアプリケーション運用者に要求を伝えられるようにしています。これには、アプリケーションを定義するだけでなく、記述することも含まれます。

###1、コンポーネント
OAMでは、コンポーネントとは、ビジネスデベロッパーがO&Mの詳細を考慮せずにアプリケーションを定義するためだけに設計されたキャリアです。アプリケーションには1つ以上のコンポーネントが含まれます。例えば、Webアプリケーションは、Java Webコンポーネントとデータベースコンポーネントで構成されます。次の図は、ビジネスデベロッパーがNGINXを導入するために定義したコンポーネントの例です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/072e5af1-da23-13cb-cfe4-fca8e9d5a3ff.png)


OAMでは、コンポーネントは以下の部分で構成されます。

- ワークロードの記述:コンポーネントの実行方法とコンテンツは、完全なKubernetesカスタムリソースを構成します。（CR.）
- 書き換え可能なパラメータリスト:ビジネスデベロッパーは、アプリケーションオペレータやシステムがオーバーライド可能なフィールドをこのパラメータリストで指定します。

コンポーネントでは、ワークロードフィールドが、ビジネスデベロッパーがアプリケーションをどのように実行するかをアプリケーションオペレータに伝えます。また、OAMのコンテナアプリケーション用にContainerizedWorkloadが定義されており、クラウドネイティブアプリケーションの典型的なパターンをカバーしています。

ワークロードはOAMで定義・拡張することで、ユーザーのワークロードタイプを宣言することができる。我々は常にワークロードを拡張し、ビジネスデベロッパーがFunction ComputeなどのAlibaba Cloudサービスコンポーネントを定義できるようにしています。

前述の例では、ビジネスデベロッパーはレプリカを設定する必要はありません。代わりに、HPAまたはアプリケーションのオペレータがレプリカの値を制御できるようにします。一般に、コンポーネントを使用すると、ビジネスデベロッパーは、アプリケーションの宣言的記述を独自の方法で定義することができます。また、このコンポーネントを使用することで、ビジネスデベロッパーは、いつでも意見や情報をアプリケーション運用者に正確に伝えることができます。その情報とは、例えば、どのパラメータが書き換え可能か、どのようにアプリケーションを実行するかなど、O&Mの要求を含みます。

###2、 ApplicationConfiguration
コンポーネント名とアプリケーションへのバインディングの特徴を利用して、アプリケーションオペレーターは ApplicationConfiguration を使用してアプリケーションをインスタンス化することができます。以下に、コンポーネントと ApplicationConfiguration を使用する連携ワークフローの例を示します。

- 様々なワークロードタイプがKubernetesにインストールされています。
- ビジネス開発者は、選択したワークロードタイプを使用してcomponent.yamlファイルを定義します。
- アプリケーションオペレータ（またはCIやCDシステム）は、kubectl apply -f component.yamlコマンドを実行してコンポーネントをインストールします。
- アプリケーションオペレータは、app-config.yamlコマンドを実行して、アプリケーションをインスタンス化するための- ApplicationConfigurationを定義します。
- 最後に、アプリケーションオペレーターは、kubectl apply -f app-config.yamlコマンドを実行して、アプリケーションのデプロイをトリガーします。

app-config.yamlファイルの内容は以下の通りです。

```
apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
  name: my-awesome-app
spec:
  components:
    - componentName: nginx
      parameterValues:
        - name: connections
          value: 4096
      traits:
        - trait:
            apiVersion: core.oam.dev/v1alpha2
            kind: AutoScaler
            spec:            
              minimum: 1
              maximum: 9
        - trait:
            apiVersion: app.aliaba.com/v1
            kind: SecurityPolicy
            spec:           
                allowPrivilegeEscalation: false
```

ApplicationConfigurationのYAMLファイルに含まれる主要なフィールドを以下に示します。

- parameterValues:このフィールドは、アプリケーション・オペレータがコネクションの値を4096に更新するために使用します。このコンポーネントでは、connectionの初期値は1024です。このフィールドのスキーマはコンポーネント内で十分に定義されているため、アプリケーションオペレーターは「4096」という文字列の代わりに4096という整数を入力する必要があります。
- AutoScaler:このフィールドは、アプリケーションオペレータがHPAなどのオートスケーラートレインをコンポーネントにバインドするために使用します。そのため、レプリカの数はオートスケーラーによってのみ決定されます。
- SecurityPolicy:このフィールドは、アプリケーション・オペレータがセキュリティ・ポリシーをコンポーネントに適用するために使用します。アプリケーションオペレーターは、トレイトリストを変更してより多くのトレイトをバインドすることもできます。例えば、Canary Deployment trait は、アプリケーションが後続のアップグレードにおいて段階的なリリース・ポリシーに従うことを示します。

ApplicationConfigurationにより、アプリケーション・オペレータやシステムは、ビジネス・デベロッパーから伝達された情報を理解して使用できるようになり、最終的なO&MのためにO&M機能をコンポーネントにバインドできるようになります。

#アプリケーション管理を超えるもの
結論から言うと、OAMを使ってアプリケーション管理における以下の問題を解決します。

- Kubernetesに発見可能、組み合わせ可能、管理可能なO&M機能を構築する。
- Kubernetesの複数の参加者が、単一のAPIを中心に正確かつ効果的にコラボレーションできるようにする。
そのため、OAMはAlibaba Kubernetesチームによって提案されたApplication CRD仕様となっています。これにより、すべての参加者が構造化された標準的な方法を使用して、アプリケーションとそのO&M機能を定義することができます。

また、Alibabaは、ハイブリッドクラウドや複数の環境でのソフトウェアの配布や配信のためにOAMを開発しています。Google AnthosやMicrosoft Arcの登場により、Kubernetesが新しいAndroidシステムになりつつあり、クラウドネイティブエコシステムの価値がアプリケーションレイヤーに急速に移行していることがわかります。本記事で紹介した事例は、Alibaba CloudとAnt Financialのクラウドネイティブチームが提供しています。

#OAMの未来
現在、OAMの仕様やモデルはすでに多くの問題を解決していますが、これはまだ始まったばかりです。例えば、OAMを使ってコンポーネントの依存関係を処理する方法や、DaprのワークロードをOAMに統合する方法などを研究しています。

OAMの仕様やKubernetesの実装について、コミュニティと協力していきたいと考えています」。OAMは中立的なオープンソースプロジェクトです。その貢献者はすべて、非営利財団のCLA（Contributor License Agreement）に従わなければなりません。

ご質問やご意見がございましたら、ぜひご連絡ください。

以下のリンクのいずれかをクリックして参加することができます。

- [Gitterで議論に参加する](https://gitter.im/oam-dev/?spm=a2c65.11461447.0.0.705f4d2fpX63Kp)
- [オープンソースのOAM実装のURLを見る](https://github.com/oam-dev/rudr?spm=a2c65.11461447.0.0.705f4d2fpX63Kp)
- [GitHubのこのページをクリック](https://github.com/oam-dev/rudr?spm=a2c65.11461447.0.0.705f4d2fpX63Kp)

#著者について
Li XiangはAlibaba Cloudのシニアテクニカルエキスパートです。彼はAlibabaでクラスタ管理システムを担当し、Alibabaグループでの[Kubernetes](https://www.alibabacloud.com/product/kubernetes?spm=a2c65.11461447.0.0.705f4d2fpX63Kp)採用の促進を支援しています。Alibabaに勤務する前は、CoreOSのアップストリームKubernetesチームのオーナーを務めていました。また、etcdやKubernetes Operatorsの生みの親でもあります。

Zhang Leiは、Alibaba Cloudのシニア・テクニカル・エキスパートです。彼は[Kubernetes](https://www.alibabacloud.com/product/kubernetes?spm=a2c65.11461447.0.0.705f4d2fpX63Kp)プロジェクトのメンテナーの一人です。Alibaba Kubernetesチームに所属し、Kubernetesやクラウドネイティブなアプリケーション管理システムを扱っています。


2019年以降、Alibaba Cloudのクラウドネイティブアプリケーションプラットフォームチームは、Alibaba経済全体の標準的なアプリケーション定義と配信モデルに基づいて、アプリケーション管理製品とプロジェクトの統一アーキテクチャのアップグレードを開始しました。

Kubernetesが正式にAlibabaのアプリケーションインフラとなった2018年末、AlibabaとAlibaba Cloudの製品群でアプリケーション管理の断片化問題が発生しました。

クラウドネイティブエコシステムの急速な発展に伴い、AlibabaとAlibaba CloudのPaaS（Platform as a Service）製品を含むアプリケーション管理製品アーキテクチャは、クラウドネイティブエコシステムを受け入れ、エコシステムの刻々と変化する機能を利用して、より強力なPaaSサービスを構築しなければなりません。

しかし、PaaSをKubernetesに移行したり統合したりするだけでは問題を解決できません。PaaSとKubernetesの間にはこれまで明確な境界線がなく、Kubernetesはエンドユーザー向けに設計されていません。

KubernetesやPaaSを利用する際の問題を解決するためには、アリババのR&DやO&Mの担当者がクラウドネイティブ技術のイノベーションの恩恵を受けられるようにし、既存のPaaSシステムをKubernetesにシームレスに移行または統合し、新しいPaaSシステムがKubernetesの技術やエコシステムの機能や価値を十分に活用できるようにする方法を考えることが鍵となります。

*本ブログは英語版からの翻訳です。オリジナルは[こちら](https://www.alibabacloud.com/blog/unified-application-management-architecture-with-oam_596361)からご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。*

*アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
[アリババクラウドジャパン公式ページ](https://www.alibabacloud.com/ja)*