This wiki page is Japanese language.
Updated: Jun, 2019
OASIS TOSCA とは何か(What's TOSCA)
Topology and Orchestration Specification for Cloud Applications (TOSCA)
クラウド上で稼働する業務システムのシステム構成（"トポロジ"と呼ぶ）を定義するための標準仕様。システム構成を記述する仕様が定義されています。その定義を使った実際のシステム構成方法・手段などの実現方式については規定されていません。
記述の書式は、XMLからYAML化が進行中(2015/6現在)でドラフトが、2015/1 に公開されています。今後TOSCA記述は、YAMLが中心となっていくと考えられます。 (2019/1 YAML Version 1.2 Published)
- OASIS TOSCAの日本語解説ページ
以下、TOSCAについて、できるだけ簡易な言葉で説明してみます。
価値（Goal)
業務システムを標準仕様のDSLで定義することができます。これにより、業務システム構築のノウハウをコードとして残こせ、一度定義した業務システムをテンプレートとして使いまわすことができます。Infrastructure as Code の最上位、と考えることもできます。このことは、TOSCAの第一の価値である、コンポーザビリティ(Compos-ability)になります。
業務システムを定義したテンプレートを使って、任意のクラウド基盤上に実際のシステムを構築（プロビジョニング）することができます。このことは、TOSCAの第二の価値である、ポータビリティ(portability)になります。クラウドでのプロビジョニングでは、必要となる仮想マシンを用意し、OSインストール、ミドルウェアのインストールを行い、各マシン間のネットワーク設定やマシン間の接続設定（例えばDBMSの設定）を行います。これらを自動的に実施するオートメーションツールがそれぞれのレイヤに存在します。さらに各オートメーションツールを適切な順番で制御したり、適切なリソース選択を行うオーケストレータが存在します。TOSCAコンテナと呼ばれる実装では、トポロジ定義からオーケストレータやオートメーションツールを動かすためのコードを生成します。
オートメーションツールやオーケストレータは、様々な製品やOSSが存在します。それぞれ得意不得意があるため、組み合わせて使用したい場合が出てくるかもしれません。TOSCA仕様のテンプレートを作成する際、プロビジョニングするクラウドを様々な製品やOSSを組み合わせて利用する定義が可能となっています（エコシステムとも言われます）。このことは、TOSCAの第三の価値である、インターオペラビリティ(inter-operability)になります。
用途(TARGET)
上記の３つのTOSCAの価値は、誰のためものなのでしょうか。クラウドを取り巻くアクターごとに考えてみます。
クラウド事業者
パブリックプラウドを提供している事業者は、TOSCA仕様が広まると、脅威でもあり機会にもなります。ポイントは、インターオペラビリティです。TOSCAテンプレートにて、業務システムが他クラウドでも自クラウドでも変わりなく構築できることになると、クラウド利用者がクラウド間の乗り換えが容易になるためです。クラウド間のインターオペラビリティが実現すると、クラウド事業者は、価格面や提供サービスの差異化を図る必要があります。
一方、TOSCAアーカイブでの同一アーキテクチャクラウド間でのポータビリティが実現できると、クラウド事業者は、様々な商材をTOSCAアーカイブにて流通させることができ、自分のクラウドの価値が高まる可能性があります。
オンプレミス・クラウド利用企業
企業内予算管理部門
企業内でクラウドを各部門へ提供する企業内予算管理部門では、インターオペラビリティに価値を感じるかもしれません。不確定要素が大きい先行PJをパブリッククラウドにて小さく始めた後、システム規模や利用時間が増えコスト面で課題が発生する場合があります。この際、他のパブリッククラウドやオンプレミスクラウドへの移行での対応案が遡上、しかし移行に要するコストが大きいとそれが障壁となり、不満を持ちながらも次のシステム更改まで最初のクラウド上で稼働させ続けることになってしまうでしょう。TOSCAテンプレートでのインターオペラビリティが実現されると、TOSCA仕様の理論上は、前の環境と同じ状態でシステムの新規構築が（ほぼ自動で）できる、ということになります。
企業内情報システム部門
ここでの対象は、DevOpsの"Ops" の人々です。ため、日々さまざまな「運用でカバー」をすることで、利用者からの無理な要求や、製品やツールの穴を埋めて、業務システムを安定的に確実に稼働させています（場当たり的、綱渡り的の可能性もあります）。最近は、運用でカバーする領域をプログラムコード化して、"Ops"作業の属人性排除、自動化を目指す動きが出てきています。TOSCAテンプレートから、業務システムを定義しCSAR化することで、配備、起動まで全自動化が可能となるはずです。もう、「運用でカバー」は必要なく、すべて「定義でカバー」となるでしょう。
業務システム開発者
クラウド上で動作する業務システムを開発する開発者は、クラウド基盤を意識した実装は行う必要はなく、抽象化されたクラウドを構成する部品を選択することで業務システム設計を行えるようになります。これは、TOSCAの価値のコンポーザビリティに当たります。また、開発工程のライフサイクル内で、何度かデプロイをする必要が出てきます。開発者自身がユニットテストをする環境、ファンクションテストをする環境、品質部門が評価する環境、受け入れ部門が評価する環境、Opsによる本番環境、災害対策用環境・・・。これらの環境構築作業をTOSCAテンプレートから作成したCSARをベースにすべて自動化されているということは夢のようです。開発者は、開発に専念できることになるでしょう。
SIベンダー(SIer)
SIerも開発者と同様にクラウド基盤を意識することなく、SI計画を立てることができます。あるクラウド基盤にロックインされていないため、標準的な技術のみでシステム構築を行うことができます。また、一度作成したTOSCAテンプレートを流用することで同じようなシステム構築を属人性に依存することなく行うことが可能となります。
クラウド関連製品ベンダー
クラウドに関連するプロダクトを提供しているベンダーにとって、TOSCA対応は、MUST要件になるのかもしれません。クラウド基盤はコモディティ化し、差異化要素は、上位のサービスの充実やサポート力などにシフトしていくものと思われます。
必要性(CONNECT)
参考文献1に記載されている、「よいインフラサービスの１０原則」がTOSCAにも該当すると考えています。
- モジュール化
- 協調性
- 組立可能
- 柔軟性
- 拡張性
- 繰り返し可能
- 宣言的
- 抽象化
- べき等性
- 収束化
ユースケース(Usecase)
公式ユースケースの解説
3.2.1 Services as Marketable Entities
3.2.2 Portability of Service Templates
3.2.3 Service Composition
3.2.4 Relation to Virtual Images
対応製品、サービス(Powered by TOSCA, Products and Services)
プロダクト
- HP CSA
- IBM Cloud Orchestrator
-
VMware vRealize Automation
- Blueprint でTOSCA仕様を利用
サービス
OSS
OpenStack
- Heat-Translator TOSCA仕様をHOTへ変換する
- Murano アプリケーションカタログを提供する機能：TOSCA仕様を利用できる
- Magnum Dockerコンテナを管理する機能：コンテナで構成される業務システムの定義でTOSCA仕様を使う
Other
将来性はあるのか
OASISの標準仕様は、デファクトとはならないことが多い、とエンジニア間ではときどき語られています。TOSCA仕様についても、クラウドファースト時代になったにも関わらず、現時点(2015/6)は注目度は小さいと考えています。TOSCAの考え方は、総論・賛成するも、各論・現実的には個別最適、というのが実際のところでしょう。しかし、日本では、標準化団体が策定した仕様というお墨付きを重視する傾向があるため、確定した仕様を利用するという点において将来性はあると考えています。
TOSCAの最大の価値である、ポータビリティについて、2014年にDockerがブレイクしたことで、DockerイメージやDockerfile によるポータビリティの実現性に注目がいっているようです。日経コンピュータ：2015/4/2号の特集記事内で、IBMのコメントとして「これまではTOSCAを考えていたがDockerでのポータビリティ実現を考えている」、と記載されています。
注目度は小さいのですが、今後クラウド間でのポータビリティの要件が必ず出てくることとなり、その際、業務システム構成をコードで記載する必要性は高まると考えられます。この際にTOSCA仕様は、その表現方法の一つとして選択されていくものと思われます。仮に別の定義がデファクトとなったとしても、コンバータにより互換性を維持することは可能となるでしょう。
2015年10月に日本で開催されたOpenStack Summit Tokyo では、幾つかのプロジェクトのセッションでTOSCA仕様を利用しているという説明がありました。業務システムを塊で定義する、その定義をもとに、各種の自動化を実現するというメタ定義としてTOSCA仕様の利用が広まってきているように感じました。
== 2019年 追記 =
本投稿を作成したのが2015年です。それ以降、現在までGoogle でOASIS TOSCA を検索すると、本投稿が最上位となります。これは、数年間新しい記事等が出ておらず注目すべき技術では無い、ということを証明しているのではないかと思います。
また、TOSCA仕様を採用した実装は、メジャーな製品で存在しません。上記の「日経コンピュータ：2015/4/2号」の記事の通り、コンテナでのポータビリティが一般的になってきています。さらに、TOSCA仕様の宣言的モデルと同様な実装(Openstack Heat, AWS Cloudformation, Terraform など)が一定の地位を得ており、今後TOSCA仕様そのものが大きく広がることは無いと考えます。
OASIS TOSCA TC では、様々な議論は進んではいます。特にコンテナやネットワークに関する事項が多くなっています。今後ネットワーク関連の進展があるかもしれませんが、最近のトレンドでは、インテントベースネットワークという概念も出てきており、このあたりでの活用があるかもしれません。
関連技術の説明
オーケストレーション
オーケストレーションとは、クラウド環境への複数のITリソースのプロビジョニングやソフトウェアのデプロイ、設定のカスタマイズなどを「よしなに」実施してくれる機能のことです。TOSCAの”O"は、”Orchestration”です。クラウドへのITリソースのプロビジョニングを実現するソフトウェアやサービスでは、オーケストレーション機能を具備しているものが多くあります。Openstack のコンポーネントでは、Heat がそれに該当します。AWSでは、Cloud Formation が該当します。
「よしなに」オーケストレーションするためには、オーケストレータに対して動作させるための定義が必要になります。Heatは、Heatテンプレート、Cloud Formation は、Cloud Formation テンプレートが必要になります。
オーケストレータの定義は、「宣言的モデル」と「手続型モデル」があります。ワークフローでプロビジョニングの順番を制御しながらオーケストレーションするものを「手続型」、トポロジなどの関係性を定義してその接続状態を解析しながらオーケストレーションするものを「宣言的」といいます。
ポータビリティ
TOSCA仕様でのポータビリティとインターオペラビリティはどう書いてあり、どう解釈すべきか
TOSCA仕様はここ
- ポータビリティ：ある開発環境で作成したサービステンプレートを別の環境（例えば異なるベンダのクラウド）で使用できること。ポイントは、「サービステンプレート」≒トポロジ定義 が別の環境で読めること。現実的には、同一ベンダーのオンプレ用クラウドとパブリッククラウド間でのポータビリティを指すことになる。
- インターオペラビリティ：様々なベンダーが作成したノードタイプを自由に組み合わせてサービステンプレートを定義し、異なるベンダーでそのサービステンプレートが使用できること。ポイントは、「ノードタイプ」≒詳細なインタフェースやパラメータ定義 が相互利用できること。ポータビリティとの差異は、複数のベンダーのノードタイプを組合せられることになる。エコシステムとも言われる。
参考：ビジネスグリッドコンピューティングプロジェクト
経済産業省にて2003-2005年にかけて実施された国家プロジェクト。その研究成果物として、TOSCA仕様でのアーカイブ形式(CSAR = Cloud Service ARchive)と類似する仕様が"ZAR"という呼称で定義されている。
- ZAR
上記引用元：http://www.meti.go.jp/committee/materials/downloadfiles/g70406b08j.pdf
10年も前に日本の国家プロジェクトして定義されている仕様と同様なものが、OASISで検討されていることは、興味深い。
参考文献
- Chef実践入門
-
ウェブオペレーション サイト運用管理の実践テクニック オライリー・ジャパン John Allspaw, Jesse Robbins 著 ↩