この記事は、8月30日に公開された「VMware Aria Graph: API First Approach」の抄訳です。
注意：この記事には現在開発中の製品の特徴や機能が含まれている可能性があります。この新しいテクノロジーの概要は、VMware がこれらの機能を一般に利用可能な製品で提供することを約束するものではありません。機能は変更される可能性があり、いかなる種類の契約、注文書、販売契約書にも記載されるものではありません。技術的な実現可能性と市場の需要によって、最終的な納品が左右されます。議論された、または提示された新機能/機能/技術の価格とパッケージは決定されていません。
VMware Explore で発表された VMware Aria は、あらゆるクラウドにおけるインフラストラクチャとクラウドネイティブ アプリケーションのコスト、パフォーマンス、構成、デリバリーを管理するための一連のエンドツーエンド ソリューションを提供するマルチクラウド管理ポートフォリオです。VMware Aria Graph は、クラウドネイティブなアプリケーションや環境の運用上の課題に特化して設計されています。ほぼリアルタイムで更新される単一の真因へのアクセスを提供する新しいテクノロジーです。Aria Graph は、API ファーストのアプローチで開発されており、DevOps チームや IT運用チームは、複数のクラウドにまたがるアプリケーションの統合ビューにアクセスすることが可能です。さらに、グラフは、マルチクラウド環境全体を管理するためのリッチで集中的なビューとコントロールを提供する Aria Hub を介してアクセスすることができます。以下は、Aria Graph が提供するパブリック API をベースに構築された Aria Hub のアプリケーションビューの例です。
このブログでは Aria Graph API に焦点を当てます。これはマルチクラウド環境への単一で一貫したプログラム的なインタフェースを確立するもので、DevOps と ITOps を実現するための重要な機能です。Aria Graph API は、Aria Graph データへの正確かつエレガントなアクセスを提供し、それを信じられないほどのスピードで実現します。
モダンな API アプローチ
クラウド管理をマルチクラウドに対応させるという課題に取り組んだとき、マルチクラウドのデータに焦点を当て、ほぼリアルタイムに更新できるアプローチが必要であることが明らかになりました。さらにこの新しいアプローチは、データを照会し、データ変更のフィードをサブスクライブし管理された環境とワークロードの変更を実行する機能をサポートする必要があります。
これらの要件を満たすために私たちは何よりもまず、指針となる API アプローチに焦点を当てました。これにより組織がマルチクラウドを採用する際に直面する課題に対応できるソリューションの採用が可能になりました。次にマルチクラウド管理ソリューションの現状を踏まえて、どのような課題があるのかを見ていきましょう。
課題： 1つの仮想マシンに多くの真実
Amazon EC2 や VMware Cloud on AWS などのパブリッククラウドや、VMware vCenterを経由してプライベートデータセンターで仮想マシンを作成すると、仮想マシンには識別子が割り当てられ、その仮想マシンに関するメタデータはそのシステムのインベントリーに保存されます。ここで、仮想マシンの作成に Aria Automation（旧 vRealize Automation ）を使用する場合は、その仮想マシンにも識別子が割り当てられ、Aria Automation 固有のメタデータとともに Aria Automation データベースに格納されます。このように、1つのオブジェクトに、そのオブジェクトの状態や属性に関する複数の情報源が存在することになります。
次に、接続性、アプリケーションの検出、フローを監視する Aria Operations for Networks（旧 vRealize Network Insight ）、パフォーマンスと容量を監視する Aria Operations（旧 vRealize Operations ）などのサービスを追加し始めます。これらの情報はすべて、それぞれのサービスのコンテキストで有用ですが、Aria Automation または Aria Operations for Networks で知ることが重要であるような情報が Aria Operations にある可能性があります。
ここにはいくつかの課題があります。例えば、Aria Automation からのアプリケーションのデプロイが現在健全であることをAria Operations で確認したい場合、 2 つの異なる API を理解しアクセスする必要があります。そして必要とする情報を得るために、両方のサービスから情報を関連付ける必要があります。これはあくまで1つのオブジェクトに対するものです。もし、ホストやデータストア、ネットワークなど関連するオブジェクトの情報が必要なら、より多くのサービスが追加されるにつれて、複雑さが急速にスケールすることがわかります。
解決策：統一されたデータと共通のオブジェクトモデル
Aria Graph は、クラウド管理者と SRE のユニークなニーズを満たす、統一されたコンサンプションの面を提供します。アーキテクチャの観点からは、これはプログラムによる利用を想定したプラットフォームの構築と、確固たる「API ファースト」アプローチを意味します。このブログを読めば、Aria Graph の API が管理 API に求められるものを引き上げるものであることに同意していただけると思います。このブログでは、管理ツールにプログラムでアクセスしようとし、API を使うことを好む SRE の頭の中で作業しています。
冒頭で述べたように、Aria Graph は複数の管理サービス（パブリッククラウド、VMware Cloud on AWS、Aria ファミリーなど）からデータを取り込み、データをグラフ形式の単一の共通オブジェクトモデルに正規化します。これにより、共通のデータモデルの上にサービスを構築することができ、実際に新しい機能でグラフを拡張することができます。
もうひとつ、これが実現する重要な機能があります。それは1回の API コールであらゆる管理サービスのあらゆるオブジェクトを参照できるようになることです。以下は、このメタデータが Aria Graph でどのように見えるかの例になります（この場合は、EC2 インスタンスを使用しています。EC2および Aria サービスからの固有のプロパティがここにリストアップされていることに注目してください。プロパティを説明するために、各ソースからいくつかのプロパティのみを表示していますが、もっと多くのプロパティが存在します。）
あらゆるオブジェクトについて、複数のサービスからあらゆる情報を入手することができるのです。では、API を使ってプログラムからこれらの情報にアクセスする方法を見ていきましょう。
GraphQLの紹介
VMware Aria（旧 vRealize ）の API に慣れている方は、RESTful API や、学習とテストを容易にする Swagger ドキュメントに慣れていると思います。REST の代わりに、Aria Graph はデータの取得に GraphQL を使用します。これにより、より強力で簡単なコンテンツ検索が可能になります。もしあなたが GraphQL に触れたことがないのであれば、REST や Swagger よりもさらに使いやすいと感じられると思います。GraphQL の詳細については、同社のウェブサイトをご覧ください。このブログの目的のために、Aria Graph で GraphQL がどのように機能するかを掘り下げて説明します。
まず、GraphQL はクエリー言語であり、リクエスト操作は基本的に3種類しかありません。
- クエリーはGraphQLの本質であり、特定のオブジェクトに関する情報をフェッチします。
- ミューテーションは、サーバーにオブジェクトに対するアクションの実行を要求する機能を提供します。
- サブスクリプションは、システムで発生した変更を追跡する機能を提供します。
RESTよりシンプルでしょう？GraphQL は Aria Graph のような、複数のシステムからのデータを統合、正規化、単純化することを目的としたソリューションに理想的です。Aria Graph は、完全なオートコンプリート、インラインドキュメント、curl へのエクスポート機能を備えた GraphQL 用の組み込み Web IDE を提供します – あるいは独自の GraphQL クライアントを使用することもできます。
以下は、名前に “Cloud_Machine” という文字列を含む（そして最初の3回に限定される）AWS EC2 インスタンスのエンティティについて API に問い合わせ、その名前とエンティティIDを応答として要求する例です。
レスポンスには、パブリッククラウドから直接検出された EC2 インスタンスのエンティティだけでなく、Aria Automation、Aria Operations、Aria Operations for Networks を通じて検出されたエンティティも含まれます。現時点では基本的な詳細しか尋ねていませんが、このアプローチの威力をお分かりいただけたかと思います。
ここでは、もう少し複雑なクエリです。これも EC2インスタンスに対するクエリーですが、異なるデータソース（これは「namespaces」に格納されています）からプロパティも要求し、どのエンティティがそれに関連しているかを問い合わせています。
GraphQL の説明にはあまり時間をかけませんので、もっと学びたい、さらには自分で試してみたいという方は、世の中にはたくさんの公開された GraphiQL インスタンスがあるのでそれを使ってみてください。例えば、GitHub GraphQL API や APIs.guru からたくさんの例を使うことができます。
背景を説明したところで、これらが Aria Graph でどのように動作するかを挙げてみます。
オブジェクトの検索と探索
Aria Graph が共通のオブジェクトモデルを用いて他のシステムからのデータを統合し整理する方法について説明しました。インベントリオブジェクトは、Aria Graph 内では “エンティティ” と呼ばれます。今度は、マルチクラウドの観点から、異なるクラウドのデプロイメント環境について見てみましょう。Aria Hub の UIではこのように見ることができます。
Aria Graph API では、このようにデプロイメント環境とそのメンバーに対してクエリを実行できます。
これは以下の出力を生成し、デプロイメント環境とその第 1 レベルのメンバーを表示します。ここから、EKS クラスタや EC2 インスタンス、vCenter クラスタとその VM などを表示するためにナビゲートし続けることができます。
このブログの前半で、別のマルチクラウドの視点、アプリケーション中心の世界観を持った Aria Hub の UI イメージを紹介しましたが、このビューでは、アプリケーションがどこにデプロイされているかは考慮されていません。
これはアプリケーションとそのメンバーに関するクエリの例で、アプリケーションの検出は Aria Operations for Networks によって実行されています。
これはマルチクラウドのクエリであることが、以下のレスポンスでわかります。1つは vCenter 上で動作し、vCenter VM で構成されるアプリケーション層を持ち、もう1つは EC2 上で動作し、 EC2 インスタンスで構成されるアプリケーション層を持つ、2つのアプリケーションが表示されていることがわかります。
このエンティティから名前空間の情報を問い合わせると、それぞれの Aria サービスにおける同じ VM の固有の ID とタイプを取得でき、これらのエンティティのコンテキストで Aria サービスやその他の外部 REST API とやり取りすることができます。
この優れている点は、各 Aria サービスから仮想マシンに関する情報を取得するために、実際にこれらのユニーク ID を知る必要がないということです。それは Aria Graph API で直接行うことができます。たとえば、いくつかの仮想マシンの Aria Operations からの CPU 使用率を知りたいとします。その際は以下のようなクエリを作成します。
上記のクエリは、vCenter の VM (最初の 10 台に限定) に対して、Aria Operations 名前空間からそれぞれいくつかの統計情報を要求するものです。デフォルトでは、これは最新のメトリック値を返しますが、Aria Operations REST API を使用するように、開始および終了タイムスタンプ、間隔タイプ、およびロールアップタイプをオプションで追加することができます。この同じ stats API クエリを使用して、Aria Operations for Networks、AWS CloudWatch、または Aria Graph 自身からエンティティの時系列データを取得することができます。
次に、Aria Graph API を使用してエンティティに対してアクションを実行する方法を見てみましょう。
ミューテーションを用いたアクションの実行
REST では、通常 PUT や POST などのメソッドを使用して、API リクエストでアクティビティを起動します。GraphQL では、これは操作の一種であるミューテーションです。まず、どのようなアクションがあるのかを知る必要があります。このクエリを使って、あるエンティティに使えるアクションを探します。
Aria Graph は利用可能なアクションを応答し、アクションの利用可能性はエンティティの状態に依存します。たとえば、この VM はパワーオンしているので、パワーオフのアクションがあることがわかりますが、パワーオンのアクションは「INVALID_RESOURCE_STATE」という「検証失敗」があり、そのアクションは利用できないことを示しています。これは、vCenter UI でパワーオンアクションが利用できない、またはグレーアウトした状態で表示されるのと同じです。
また、”actionRequests “をクエリすると、このエンティティで実行されたアクションのリストが返されるので、私自身や他の人がエンティティで実行したアクティビティを監査する方法も持っていることに気づいたかもしれません。
電源オフのアクションを開始するには、ミューテーションリクエストを送信します。上記のクエリから、entityId と actionDefinitionId を提供する必要があります。アクションが成功したことを確認するために、actionRequestId と actionStatus も要求してみましょう。
アクションが送信されたことがレスポンスに表示されているのがわかります。
これで、数分後に完了したことを確認することができます。
アクションが Aria Automation サービスを通じて実行されるため、クラウド管理者が設定したポリシーとガバナンスの範囲内でアクションがコミットされることにお気づきかもしれません。
しかし、基礎となるサービスからの何かがまだ完全に Aria Graph に統合されていない場合はどうなるのでしょうか？Aria Graph API と Aria Hub UI では、任意のエンティティに対して各サービスのリソース識別子を取得し、それを使用してサービスの REST API を呼び出すことができることに加え、任意のエンティティのコンテキストで任意のサービスの UI を直接起動することができます – Aria Graph API の複数の場所でハイパーリンクを問い合わせることが可能です。
これは、任意のエンティティのコンテキストでサービスを直接起動するためのハイパーリンクを返します。Aria Graph は、’ENS’ 名前空間の下に、独自の Aria Hub UI ハイパーリンクを含んでいることに注意してください。
グラフを拡張する新サービス
VMware Aria Graph は、拡張可能性をもって構築されています。既存の Aria サービスの機能を統合し、Aria Graph 上に新しい SaaS サービスを構築する場合、これらのサービスはすべて同じ GraphQL エンドポイントからアクセスできるようになります。これらのサービスは、コアエンティティモデルを活用、拡張し、エンティティや他のノード上の新しいサービス固有のフィールド、新しい名前空間、新しいクエリ、および新しいミューテーションで既存のグラフを拡張します。
Aria Graph の拡張可能なコアモデルと GraphQL の複数のサブグラフをつなぎ合わせる機能を組み合わせることで、既存のすべてのサービスから中央のストアにデータをインポートする必要がなく、ネイティブのパブリッククラウドメトリクス、SaaSマイクロサービス、さらには従来のモノリシックサービスなど、多くの異なるソースからのデータを1つの拡張可能なグラフに結合することができるようになりました。これは、Aria Graph プラットフォームのコア部分ですでに使用されており、新しいサービスに拡張する際にもこのパターンが使用されています。その結果、（マルチクラウド規模では事実上不可能な）データの一元化を回避した、シームレスなAPIが実現します。
新しいサービスといえば、例えば VMware Skyline や Aria Operations for Logs (旧 vRealize Log Insight ) と連携して、すでにカバー範囲を広げ始めています。
まとめ
VMware Aria Graph API は、強力な Aria Graph プラットフォームへのプログラムによるアクセスを提供し、VMware Cloud Management との統合を簡素化します。この単一のマルチクラウド API は、ビジネスアプリケーションやワークロードに関する情報を取得し、アクションを起こすために使用することができます。
