著者| Zhang Lei Deng Hongchao
はじめに：最近、AWS ECSチームは、公式のGitHubでAmazon ECS for Open Application Modelと呼ばれるオープンソースプロジェクトをリリースし、OAMの実践を模索するメーカーが増えています。OAMの魅力は何ですか？複数のクラウドベンダーが団結して受け入れますか？
サーバーレスとAWS
サーバーレスという言葉は、「なぜソフトウェアとアプリの未来がサーバーレスなのか」という2012年の記事で最初に使用されました。しかし、本当に考古学に行くと、この記事の内容は実際には継続的インテグレーションとコードバージョン管理のソフトウェアエンジニアリングの概念であることがわかります。 FaaS / BaaSのように、これらのことはまったく問題ではありません。
2014年、AWSはLambdaという製品をリリースしました。この製品のデザインコンセプトは非常にシンプルです。クラウドコンピューティングが最終的にアプリケーションにサービスを提供すると考えており、ユーザーがアプリケーションをデプロイする場合、特定のタスクを実行するための独自のプログラムを作成する場所だけが必要です。プログラムが実行されるマシンまたは仮想マシン。
「サーバーレス」というパラダイムをまったく新しいレベルに引き上げたのは、ラムダのリリースでした。サーバーレスは、クラウドでアプリケーションをデプロイして実行するためのまったく新しいシステムアーキテクチャを提供します。ユーザーは複雑なサーバー構成を気にする必要はなく、自分のコードと、ホストできるクラウドコンピューティングプラットフォームにコードをパッケージ化する方法だけを気にする必要があることを強調します。運用エンティティ」。AWSは、事前割り当てされたリソースではなく、実際のトラフィックに基づくアプリケーションインスタンスのスケーリングや実際の使用量に基づく請求など、一連の従来の機能を経て、サーバーレスの分野で事実上の標準を徐々に確立してきました。
2017年に、AWSはFargateサービスをリリースしました。これはサーバーレスの概念をコンテナベースの実行可能なエンティティに拡張しました。すぐにこのアイデアは、Google Cloud Runなどにも続き、「次世代」のコンテナベースのサーバーレスランタイムが始まりました。ブーム。
サーバーレス与Open Application Model（OAM）？
では、Open Application Model（OAM）はAWSとサーバーレスとどのように関係しているのでしょうか？
まず、OAM（Open Application Model）は、Alibaba CloudとMicrosoftが共同で開始し、クラウドネイティブコミュニティが共同で管理しているアプリケーション記述仕様（仕様）のセットです。OAMのコアコンセプトは次のとおりです。「アプリケーション中心」。R＆Dと運用および保守は、複雑であいまいなインフラストラクチャレイヤーAPIを直接使用するのではなく、宣言的で柔軟で拡張可能な上位レベルの抽象化のセットの周りで連携することを強調します。
たとえば、水平拡張にK8s HPAを使用するコンテナーベースのアプリケーションの場合、OAM仕様の次の2つのYAMLファイルで定義されます。
R＆Dによって準備されたYAMLファイル：
apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
name: web-server
spec:
# 待部署的应用详情
workload:
apiVersion: core.oam.dev/v1alpha2
kind: Server
spec:
containers:
- name: frontend
image: frontend:latest運用と保守（またはPaaSプラットフォーム）によって書き込まれたYAMLファイル：
apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
name: helloworld
spec:
components:
- name: frontend
# 该应用运行所需的运维能力
traits:
- trait:
apiVersion: autoscaling.k8s.io/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: scale-hello
spec:
minReplicas: 1
maxReplicas: 10OAM仕様では、R＆Dと運用および保守の焦点が完全に分離されていることがわかります。研究開発と運用とメンテナンスは、K8sのデプロイメントとHPAオブジェクトを完成させるのではなく、それらに関連する非常に少数のフィールドを記述するだけで済み、アプリケーションを簡単に定義および公開できます。これは、「上位の抽象化」がもたらすメリットです。
上記のようなYAMLファイルがK8sに送信されると、OAMプラグインによって完全なDeploymentおよびHPAオブジェクトに自動的に変換され、実際に実行されます。
OAMは、「アプリケーション」、「運用および保守機能」、「リリース境界」などの一連のクラウドネイティブなアプリケーション配信定義標準を規制しているため、アプリケーション管理プラットフォームの開発者は、この仕様を使用してそれぞれを説明できます。さまざまなアプリケーションと操作および保守戦略、そして最後にOAMプラグインを介して、これらのYAMLファイルをK8の実際のリソース（CRDを含む）にマップします。
言い換えると、OAMは「上位抽象化」を定義するための事実上の標準を提供し、この「上位抽象化」の最も重要な役割は、さまざまなインフラストラクチャの詳細（HPA、入力、コンテナー、ポッド、サービスなど）を防ぐことです。など）R＆Dクラスメートに漏れ、不要な複雑さを引き起こしました。したがって、OAMがリリースされると、K8sアプリケーションプラットフォームを開発するための「武器」と呼ばれます。
しかし、より重要なのは、アプリケーションの説明から「インフラストラクチャレイヤーの詳細を取り除き、開発者に最も親しみやすい上位レベルの抽象化を提供する」というこの考え方は、「インフラストラクチャ解除」のサーバーレスの概念と一致することです。より正確には、OAMは本質的にサーバーレスです。
このため、OAMがリリースされると、サーバーレスの分野で大きな注目を集めました。もちろん、AWSも欠かせません。
究極のエクスペリエンス：AWS ECS for OAM
2020年3月の終わりに、AWS ECSチームは、Amazon GCS for Open Application Modelと呼ばれるオープンソースプロジェクトを公式GItHubでリリースしました。
プロジェクトアドレス：https : //github.com/awslabs/amazon-ecs-for-open-application-model
このプロジェクトは、AWSチームがサーバーレスサービスに基づいてOAMをサポートする試みです。このプロジェクトの基盤となるランタイムは、前述のサーバーレスコンテナーサービス、Fargateです。そして、このAWS ECS for OAMプロジェクトが開発者にもたらす経験は非常に興味深いものです。
準備作業には3つのステップがあります。
1.ユーザーは、AWSアカウントの認証情報をローカルに持っている必要があります。これは、AWS公式クライアントのaws configureコマンドを使用してワンクリックで生成できます
。2.プロジェクトをコンパイルすると、oam-ecsという実行可能ファイルを取得できます
。3。 oam-ecs envコマンドを実行して、その後の展開のために環境を準備する必要があります。このコマンドが終了すると、AWSはVPCと対応するパブリック/プライベートサブネットを自動的に作成します。
準備が完了したら、OAMアプリケーションのYAMLファイルをローカルで定義するだけです（上記のhelloworldアプリケーションの例など）。次に、次の1行のコマンドを使用して、HPAを備えた完全なアプリケーションをFargateに配置できます。これはインターネット上に展開され、パブリックネットワーク上で直接アクセスできます。
oam-ecs app deploy -f helloworld-app.yamlとても簡単ですか？
AWS ECS for OAMプロジェクトの公式ドキュメントでは、より複雑な例が示されています。説明しましょう。
今回デプロイするアプリケーションは、3つのYAMLファイルで構成されています。これらのファイルは、R＆Dと運用と保守の2つの問題に分かれています。
1.研究開発
- server-component.yaml：このファイルのコンテンツはアプリケーションの最初のコンポーネントであり、デプロイするアプリケーションコンテナーを記述しています。
- worker-component.yaml：このファイルのコンテンツアプリケーションの2番目のコンポーネント。具体的には、現在の環境のネットワークに障害がないかどうかを確認するループジョブを記述します。
2. O＆Mは書き込みを担当します
example-app.yaml：このファイルの内容は、完全なアプリケーションコンポーネントトポロジと、各コンポーネントの操作とメンテナンスの特性（特性）です。具体的には、「手動スケーラー」の操作とメンテナンスの戦略について説明しています。 worker-componentを展開します。
したがって、完全なアプリケーション記述である上記のexample-app.yamlは次のとおりです。
apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
name: example-app
spec:
components:
- componentName: worker-v1
instanceName: example-worker
traits:
- name: manual-scaler
properties:
replicaCount: 2
- componentName: server-v1
instanceName: example-server
parameterValues:
- name: WorldValue
value: Everyoneご覧のとおり、2つのコンポーネント（worker-v1とserver-v1）を定義しています。worker-v1コンポーネントには、manual-scalerと呼ばれる手動の拡張戦略があります。
このデモの3つのYAMLファイルはすべて、次のディレクトリで確認できます。https：//github.com/awslabs/amazon-ecs-for-open-application-model/tree/master/examples
ただし、上記の複雑なアプリケーションのデプロイメントは、非常に単純なコマンドです。
oam-ecs app deploy \
-f examples/example-app.yaml \
-f examples/worker-component.yaml \
-f examples/server-component.yaml上記の手順を実行した後（中国の学生は特別なネットワークの問題のために少し忍耐が必要になる場合があります）、oam-ecs app showコマンドを使用してアプリケーションアクセス情報とDNS名を表示できます。ブラウザを開いてアクセス情報を入力すると、以下に示すように、アプリケーションに直接アクセスできます。
イメージの更新やreplicaCountの値の変更など、アプリケーション構成を変更する場合は、上記のYAMLファイルを変更してから再度デプロイするだけで済みます。これは完全に宣言型の管理です。
実際、上記の操作がAWSコンソールを介して行われる場合、さまざまな構成のために少なくとも5つのクラウド製品ページを互いにジャンプする必要があります。または、CloudFormation構文を学び、非常に長いCFを記述する必要があります。ファイル。アプリケーションがFargateインスタンス、LoadBalancer、ネットワーク、DNS構成などを実行するために必要なすべてのリソースを取得します。
ただし、OAM仕様により、上記のアプリケーションプロセスの定義と展開は非常に単純になっただけでなく、クラウドサービスオペレーションの元のプロセスをより簡潔でわかりやすい宣言型YAMLファイルに直接変換しました。ここでOAM仕様を実装するために必要な具体的な作業は、実際には数百行のコードだけです。
さらに重要なことは、AWS FargateのようなサーバーレスサービスをOAMのような開発者に優しいアプリケーション定義と組み合わせると、あなたは本当に感じるでしょう：このシンプルでさわやかで非常に低い精神的負担はサーバーレスであることがわかります開発者にとっての究極の体験。
最後に：アプリケーションモデルがサーバーレスと出会うとき
OAMモデルは、クラウドネイティブアプリケーション配信エコシステムに大きな影響を与えました。現在、Alibaba CloudのEDASサービスは、OAM上に構築された業界初の本番レベルのアプリケーション管理プラットフォームになり、次世代の「アプリケーション中心」の製品体験をすぐに開始します; CNCFコミュニティでは、有名なクロスクラウドアプリケーション管理と配信プラットフォームのCrossplaneプロジェクトは、OAM仕様の重要な採用者および保守者にもなっています。
EDAS公式ウェブサイト：https : //help.aliyun.com/product/29500.html
Crossplane：https : //github.com/crossplane/crossplane
実際、AWS Fargateだけでなく、クラウドコンピューティングエコシステムのすべてのサーバーレスサービスは、OAMを開発者指向のプレゼンテーションレイヤーおよびアプリケーション定義として簡単に使用できるため、元の複雑なインフラストラクチャAPIを簡略化および抽象化できます。元の複雑なプロセス操作の「ワンクリック」アップグレードで、Kubernetesスタイルの宣言型アプリケーション管理になりました。さらに重要なことに、OAMの高いスケーラビリティのおかげで、Fargateにコンテナーアプリケーションをデプロイできるだけでなく、OAMを使用して、関数、仮想マシン、WebAssembly、さらには考えられるあらゆるタイプのワークロードを記述することもできます。これらはサーバーレスサービスに簡単にデプロイでき、異なるクラウドサービス間でシームレスに移行することもできます。これらの「魔法」のように見える能力はすべて、標準化された拡張可能な「アプリケーションモデル」がサーバーレスプラットフォームに出会うときに衝突する可能性のあるイノベーションスパークです。
アプリケーションモデル+サーバーレスは、クラウドネイティブエコロジーで最もホットなトピックの1つになりつつあります。CNCFクラウドネイティブアプリケーションデリバリーグループ（SIGアプリデリバリー）に参加して、クラウドコンピューティングエコシステムを「アプリケーション中心」に促進することができます。前進し続けなさい！
AWS ECS on OAMプロジェクト：https : //github.com/awslabs/amazon-ecs-for-open-application-model/
Open Application Modelプロジェクト：https : //github.com/oam-dev/spec
CNCF SIG App Delivery ：Https : //github.com/cncf/sig-app-delivery
現在、OAMの仕様とモデルは多くの既存の問題を実際に解決していますが、その旅はまだ始まったばかりです。OAMは中立的なオープンソースプロジェクトであり、クラウドネイティブアプリケーション配信の未来を共同で定義するために、より多くの人々がそれに参加することを歓迎します。
参加方法：
- OAMプロジェクトの中国語ディスカッショングループに参加
著者について
Zhang Lei Alibaba Cloudシニアテクニカルエキスパート。彼はKubernetesプロジェクトのメンテナーの1人です。Zhang Leiは現在、AliのKubernetesチームで働いており、Kubernetesやクラウドネイティブのアプリケーション管理システムなどを担当しています。
Deng Hongchaoは、Alibaba Cloud Container Platformのエキスパートです。元CoreOSエンジニアであり、K8sオペレータープロジェクトの中心的な作成者の1人。
「Alibaba Cloud Nativeは、マイクロサービス、サーバーレス、コンテナ、サービスメッシュ、およびその他の技術分野に焦点を当て、クラウドネイティブの一般的なテクノロジートレンド、クラウドネイティブの大規模なランディングプラクティスに焦点を当て、クラウドネイティブの開発者を最もよく理解している公開番号です。」
