技術ブログ株式会社エーピーコミュニケーションズの技術ブログです。エーピーコミュニケーションズの技術ブログです。ACS事業部の亀崎です。OAM」というものがありました。Model)の概要と、OAMの実装のひとつであるKubeVelaを実際にどのように使うかを紹介していました。Engineeringとの関係について考察してみたいと思います。KubeVelaの概要Kubernetesの課題のひとつは、設定の複雑さです。アプリケーションを実行しようとする際に、そのアプリケーション開発チームが様々な指定をしなければなりません。Up」での指定と呼んでいました。これを解決しようとするのがOAMであり、KubeVelaです。アプリケーションを実行する際に必要な設定項目をよく見ていくと、実は本当に設定しなければならない部分は少数で、多くの部分はアプリケーションの種別によって概ねパターンが決まっていることがわかると思います。OAM/KubeVelaではこうした「パターン」の部分をComponentとして規定し、それにアプリケーション固有の指定を加えることで最終的なYamlを生成しようとしています。一般なWebServiceの指定は次のようになります。barアプリケーション開発者が指定するのはこれだけです。Componentとして一般的な「webservice」という指定をし,それに対して名称や実行コマンド、環境変数などを指定するだけで、自動的にDeploymentやServiceに変換されるのです。Traitというものでそうしたものを追加することができます。ポリシーなども「標準的な」ものが用意されています。traits:の指定のような形式で指定します。これにより開発者は、そのアプリケーションに必要な項目のみを指定するだけでデプロイすることができるのです。Down」による指定と呼んでいます。Teamにおける利点さてこのKubeVelaのComponent、Trait、Poliicyといったものは自由に定義することができます。Teamが用意したサービスの利用をTraitを通じて公開することもできます。Policyなども指定することができます。した組織横断的なものを用意することができるのがKubeVelaのポイントです。Teamが行いたい部分にマッチしているものと思います。KubeVelaではこのことを「関心時の分離」と呼んでいます。Poiicyを利用すればよい。Component等に変更を行った場合でも、それを利用してるアプリケーションには自動的に更新できるようになる。目標の1つではないでしょうか。Engineeringにマッチしているのではないかと考えています。KubeVelaはKubernetes上で実行するツールですが、その利用は実はKubernetesだけにとどまるものではありません。ように、クラウドリソースをKubernetesから管理・プロビジョニングできるようなサービスもあります。アプリケーション実行環境の「コントロールプレーン」を実現できるようになると考えています。別のセッションで発表されていたコンプライアンスについても、こうした仕組みで実現できるのではないかと考えます。Backstageのカタログやドキュメントとして登録公開することで開発チームがいつでも参照・利用することができるようになり、アプリケーションでの指定についてもTemplateという形で共通化できるようになるのではとも思います。Teamや開発チームがそれぞれの知見を公開・議論できるようにすることで、各種標準パターンの継続的な改善も組織全体で実施できるようになると考えています。Engineeringの導入支援、データ&AI基盤に関連するサービスを提供しています。わたしたちは「エンジニアとお客様を笑顔にする」というVisionを掲げ、インフラエンジニアの未来を創るNeoSIerとして工夫と挑戦を行い続けます。読者になるこのブログについて引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。