Amazon Web Services ブログ
AWS CloudFormation Registryの歴史と今後のロードマップ
AWS CloudFormation は、テンプレートファイルを利用してクラウドリソースをモデル化することができる IaC サービスです。テンプレートは AWS Cloud Development Kit (CDK) などを使ってさまざまな言語で生成することもできます。リソースをデプロイするスタックは、 AWS Management Console 、 AWS Command Line Interface (AWS CLI) 、または API を介して管理できます。CloudFormation は、お客様がクラウドリソースを迅速に一貫性をもってデプロイし管理できるように支援しますが、他の IaC ツールと同様に、 AWS サービスの急速な革新に追随しなくてはならないという課題に直面しました。この記事では、 CloudFormation registry の歴史を振り返ります。これはスケーリングと標準化、そして他の主要な IaC ツールやパートナー製品との統合に取り組むために考え出された戦略の結果です。また、 CloudFormation のリソースカバレッジの現状を説明し、 CloudFormation や他の IaC ツールを AWS の最新のサービスや機能に追随させるための今後のあり方についても考察します。
歴史
CloudFormation は 2011 年 2 月に はじめて発表 されました。一緒に公開されたサンプルテンプレートには、ブログや Wiki などの一般的なアプリケーションのデプロイ方法が記載されていました。ローンチ時の CloudFormation は、当時利用可能だった 15 種類の AWS サービスのうち 13 種類をサポートし、合計 48 種類のリソースタイプが利用可能でした。当初、リソースカバレッジはコアな CloudFormation エンジンと密接に結びついており、リソースに関する開発はすべて CloudFormation チーム自身が行っていました。一方で、過去 10 年以上にわたって AWS は急速に成長し、現在では合計 200 以上のサービスが存在します。この間常に発生していた課題は、お客様が AWS のサービスを利用して達成できることと CloudFormation テンプレートで定義できること、つまりカバレッジのギャップでした。
何百ものサービスチームが日々新しい機能を提供することによる急速なイノベーションに対応できるような方法でリソース開発をスケールさせるには、明らかに戦略を変更する必要がありました。 2011 年に 80 件 の重要な新機能がリリースされたのに対し 2021 年には 3,000 件以上がリリースされ、過去 10 年間でイノベーションのペースは約 40 倍に加速しました。 CloudFormation は新しい AWS サービスの導入の動機（または導入の阻害要因）として鍵になる存在であったため、サービスチームは自分たちの開発するリソースを自分たちで作成して管理する方法を必要としていました。目標は、完全な CloudFormation のリソースカバレッジを実現し、新しいサービスのローンチ時に初日からサポートできるようにすることでした。
2016 年に、サービスチームが自分たちの開発するリソースを自分たちで管理できるようにするための社内セルフサービスプラットフォームを立ち上げました。これにより、 CloudFormation のコアチームがすべての作業を行わなければならないという、以前のモデルに内在していたスケーリングの問題が解決され始めました。サービスチームは担当するプロダクトに関する深い知識を持っているため、単に開発者の労力を分散するだけにとどまらず、より効果的な IaC コンポーネントを作成できるようになりました。しかし、このモデルでリソースを開発する中で、ドリフト検出やリソースインポートなどの機能を自動的にサポートできるようにする仕組みの標準化など、さらなる設計上の工夫が必要であることに気付きました。
私たちはこれらの懸念に対処するため新しいプロジェクトに着手しました。その目的は、社内の開発者体験を向上させるとともに、お客様が同じプログラミングモデルを使用して独自のリソースタイプを定義できるパブリックレジストリを提供することです。私たちは、単に新しいモデルを利用できるようにするだけでは不十分で、トレーニングキャンペーンやエンジニアブートキャンプの実施、ダッシュボードやデプロイメントパイプラインのテンプレートなどの優れたツールの構築、そして包括的な導入支援ドキュメントの作成が必要だと気付きました。もっとも重要なのは、CloudFormation をサポートすることを新サービスのリリース時の必須要件にしたことです。この要件はドキュメントに記載するだけにとどまらず、社内のリリースツールに組み込まれています（レジストリに関するトレーニングおよび社内での認識が時間をかけて向上した結果、現在この要件に対する例外はほとんどありません）。これは Amazon でよく繰り返される格言の 1 つである「良い仕組みは善意に勝る」(good mechanisms are better than good intentions)の典型例でした。
2019 年に、開発者がプライベートリソースタイプを作成および管理できる機能である CloudFormation registry を発表 したことで、社内で利用していたこの機能を一般のお客様にも提供しました。2021 年には AWS パートナーネットワーク (APN) のパートナーなどの 3rd Party が拡張機能を公開できる パブリックレジストリ を発表しました。このオープンソースのリソースモデルによって、お客様やパートナーは 3rd Party リソースを CloudFormation で管理する機能を公開できます。これはAWSサービスチームが彼らの機能をCloudFormationでサポートするために使用するのと同じモデルです。
サービスチームがリソースを新しいリソースモデルに組み込み、期待される CRUDL(Create、Read、Update、Delete、List) のハンドラーを実装すると、ドリフト検出 や リソースインポート などの CloudFormation が持っている機能は追加の開発作業なしにすべてサポートされます。最近の有名な新機能のうち、CloudFormationが初日からサポートしたものの例としては、単一機能のマイクロサービス用ビルトイン HTTPS エンドポイントを提供する Lambda Function URLs があります。また、 Amazon Relational Database Service (Amazon RDS) は、データベースインスタンスリソース (AWS:: RDS:: DBInstance) を 2022 年 9 月に新しいリソースモデルに移行しました。その後 1 か月以内に CloudFormation が Amazon AuroraServerless v2 をサポート しました。このような迅速な提供が可能になったのは、レジストリのオーナーシップを分散するモデルによって、各サービスチームが独立して開発・公開できるようになったためです。
現在の状況
お客様が一貫したイベントハンドラーを実装することで恩恵を受けることができるように、私たちはこの新しい標準化されたリソースモデルに基づいて CloudFormation サービスの今後のイノベーションを構築しています。私たちはこの新しいリソースモデルに基づいて AWS Cloud Control API を構築しました。Cloud Control API は、新しいリソースモデル用に記述された CRUDL(Create、Read、Update、Delete、List) ハンドラーを、リソースをプロビジョニングするための一貫した API として利用できるようにします。HashiCorp Terraform、Pulumi、RedHat Ansible などの APN パートナープロダクトは Cloud Control API を利用することで、開発作業を繰り返すことなく AWS サービスのローンチに追随できます。
Figure 1. Cloud Control API Resource Handler Diagram
3rd Party アプリケーションのサポートの他に、開発者コミュニティはパブリックレジストリを使用して AWS のサービス上で便利な拡張機能を作成することもできます。CloudFormation リソースの機能を拡張するための一般的な方法は カスタムリソース を作成することです。これには通常、スタック操作中に CREATE 、 UPDATE 、 DELETE シグナルに応答して実行するインラインの AWS Lambda 関数コードが含まれます。これらのユースケースのいくつかは、代わりにレジストリ拡張リソースタイプを作成することで解決できるようになりました。カスタムリソースとリソースタイプ、および両者の違いについての詳細は、 AWS CloudFormation Resource Types を利用したリソースの管理 を参照してください。
CloudFormation Registry modules は JSON または YAML で記述されたビルディングブロックです。これにより、お客様は壊れやすいコピー＆ペーストによるテンプレート再利用ではなく、レジストリに公開された、あたかもリソースタイプであるかのように利用できるテンプレートスニペット(コード片)を使うことができます。ベストプラクティスをカプセル化して組織全体で共有することができるため、インフラストラクチャ開発者はリソース構成の複雑さを抽象化するモジュラーコンポーネントを使用することで、容易にベストプラクティスを順守できます。
CloudFormation Registry hooks は、リソースを作成、変更、削除する前にスタックのデプロイを検証するための重要なツールをセキュリティチームやコンプライアンスチームに提供します。インフラストラクチャチームは AWS アカウント上でフックを有効にすることで、スタックのデプロイがフックハンドラーに実装された予防的制御を回避したり抑制したりできないようにできます。完全にクライアントサイドで動作するプロビジョニングツールには、このレベルの強制力はありません。
リソースタイプをパブリックレジストリに公開することで得られる便利な副産物の 1 つは、GitHub の cdk-cloudformation と呼ばれる実験的なオープンソースリポジトリを通じて AWS Cloud Development Kit (CDK) が自動的にサポートされることです。大規模な組織では、宣言型テンプレートを使用する CloudFormation のデプロイと、 TypeScript や Python などの言語で CDK を使用するデプロイが混在しているのが一般的です。再利用可能なリソースタイプをレジストリに公開することで、アプリケーションの作成とデプロイにどのツールを選択してもすべての開発者がより高いレベルの抽象化の恩恵を受けることができます。（このプロジェクトはまだ開発者向けプレビュー版であり、変更が発生する可能性があることに注意してください）
特定の CloudFormation リソースが新しいレジストリモデルにあるかどうかを確認するには、 DescribeType API を呼び出し、レスポンスの ProvisioningType 要素を検査して Fully Mutable と Immutable のいずれかであるかを確認します。
新しいレジストリモデルにある AWS:: Lambda:: Function リソースの情報を取得するサンプル CLI コマンドを次に示します。
FULLY_MUTABLE と IMMUTABLE の違いは、 Update ハンドラーの有無です。 FULLY_MUTABLE のリソースタイプには、スタックの更新操作中にリソースの更新を処理する Update ハンドラーが含まれています。一方、 IMMUTABLE のリソースタイプには Update ハンドラーが含まれていないため更新することはできず、代わりに新しいリソースで置換する必要があります。レガシーリソースタイプの場合は NON_PROVISIONABLE になります。
改善の機会
すべての機能を網羅しレガシーリソースモデルから完全に移行するという最終目標に向けて努力を続ける中で、私たちは常に改善の機会を見出しています。私たちは現在、 EC2 VPC Endpoints のタグ付けサポート などサポート対象リソースの機能不足への対応や、ドリフト検出、リソースインポート、Cloud Control API をサポートするためのリソースタイプのカバレッジの拡大に取り組んでいます。130 を超えるリソースを完全に移行しましたが、まだ多くのリソースが残っていること、および移行に当初の予想よりも長い時間がかかっていることを認識しています。私たちの最優先事項は、既存のスタックの安定性を維持することです。期限を守るために後方互換性を破壊することはできないので、慎重に慎重を期しています。サービスチームの新しいリソース管理モデルへの移行プロセスを合理化し、可能な限り簡単で効率的なものにすることに引き続き取り組んでいます。
Java以外の言語でレジストリ拡張を開発する際は、一部に荒削りな体験があります（Javaは AWS サービスチームがリソースタイプの開発に選択する言語であるためです）。それらの言語では、スキーマ作成、ハンドラー関数作成、コードが期待どおりに動作することを確認するためのテストを、もっと簡易にしていく必要があります。私たちは CLI および Python 、 Typescript 、 Go のプラグインのメンテナンスに多くのリソースを費やしています。 aws-cloudformation の GitHub organization の中にあるこれらのリポジトリ、またはその他のリポジトリの Issue や Pull Request への応答時間は本来あるべきほど速くはないので、改善を進めています。その一例が cloudformation-cli のリポジトリで、 2022 年 10 月以降、 30 件を超えるPull Requestをマージしています。
リソースカバレッジの進捗状況を把握したい場合は CloudFormation Coverage Roadmap を確認してください。この GitHub プロジェクトですべての未解決課題をカタログ化しています。 GitHub 上で報告された機能要望やバグ報告への対応を改善するために最近実施したことの 1 つは、 GitHub の Issue を私たちの社内 Issue トラッキングシステムのチケットに変換するシステムを構築したことです。変換されたチケットは担当のサービスチームに直接送信されます。たとえば Amazon RDS resource provider では何百もの Pull Request がマージされています。
先日、 community-registry-extensions という新しい GitHub リポジトリを発表しました。このリポジトリでは、パブリックレジストリ拡張機能の namespace を管理しています。皆さんも拡張機能の新しいアイデアを投稿したり、議論したり、プロジェクトに貢献できます。私たちは AWS Community:: namespace の中のすべてのリソースのテスト、検証、デプロイを行います。この namespace のリソースは、任意の AWS アカウントでアクティベートして皆さんのテンプレートの中で利用できます。
CloudFormation registry を使い始める際は、 ユーザーガイド を参照してから、 CloudFormation Command Line Interface (CFN-CLI) を使用して独自のリソースタイプ、モジュール、フックを作成する方法についての詳細な開発者ガイドを読んでください。
最近、 CloudFormation 専用の Discord サーバー を新たに立ち上げました。ぜひ参加して、質問をしたり、ベストプラクティスについて話し合ったり、フィードバックを提供したりしてみてください ! ただ遊びに来てくれることも歓迎します! 皆様のお越しを心よりお待ちしています。
まとめ
この記事を読むことで、 CloudFormation registry の歴史と、AWS のサービスチーム、お客様、APN パートナーが共有できる標準化されたスケーラブルなリソース開発モデルへの進化の過程で下された設計上の判断について洞察を得ていただけることを願っています。この過程で私たちが学んだことの中には、皆さんの会社での複雑な設計の取り組みで役に立つものがあるかもしれません。一緒に豊富なレジストリリソースを作り上げていきましょう! Discord や GitHub で皆さんにお会いできることを楽しみにしています !
著者について
本記事は 2023/05/04に投稿された The history and future roadmap of the AWS CloudFormation Registry を翻訳したものです。翻訳は Solutions Architect : 国兼 周平 (Shuhei Kunikane) が担当しました。