KubeCon + CloudNativeCon Europe 2024 詳細レポート - OpenTofu Registry

ZIPAIR Tokyoでバックエンドエンジニアをしている山本です。2024年3月18日から3月22日にかけてパリで開催されたKubeCon + CloudNativeCon Europe 2024に技術チームのメンバーが参加しました。Day 1からDay 4の速報記事を投稿していますので、興味のある方はぜひZIPAIR TokyoのPublicationからご覧ください。

本記事では私が聴講したOpenTofu Registry: The Low-Maintenance & Highly-Available Open Source SaaSについてお伝えします。実際の発表はYoutubeへアップロードされておりますので、より詳細な内容を希望の方はこちらもご確認ください。

本発表では、OpenTofu Registryの運用指針の決定と開発の経緯について述べられていました。登壇者はOpenTofuのコアチームメンバーであるArol Rabinowicz氏とJames Humphries氏でした。

OpenTofu Registry開発の経緯

まず、OpenTofu Registryの構築がなぜ必要となったかの経緯が述べられました。OpenTofuはTerraformがBSLライセンスへ移行したことを契機としてforkされたOSSで、両者ともクラウドサービスのリソースや設定を管理するツールになります。

OpenTofuおよびTerraformは初期化時にて実行に必要なプロバイダーやモジュールをレジストリサービスから取得します。Terraformの提供元であるHashiCorpはプロバイダーやモジュールのレジストリサービスとしてTerraform Registryを公開しています。TerraformはこのTerraform Registryを参照し、プロバイダーやモジュールをダウンロードします。
一方で、Terraform Registryは利用規約により、OpenTofu等のサードパーティツールからの利用に制限がかけられています。これにより、OpenTofuは独自のレジストリサービスが必要となり、OpenTofu Registryの開発に至ったようです。

OpenTofu RegistryはAlpha Registryという初期バージョンを経て安定版のStable Registryに至りました。それぞれの開発段階で得られた学びを含めてどのように開発されたかが次に語られました。

Alpha Registry

OpenTofu RegistryのAlpha Registryは、OpenTofuプロジェクトの初期段階で用意されたレジストリです。レジストリの公開までのスピードを優先した一時的な解決策として主にAWSを使用して設計されました。基本的な構造としては、APIリクエストを処理するAWS Lambdaと、そのAPIを管理するAPI Gatewayによるものでした。

ほとんどのプロバイダーやモジュールはGitHubのRelease Assetとして公開されており、GitHub APIを使用してそれらを取得できます。Alpha Registryでは、処理を実行するLambdaがGitHub APIへプロバイダーとモジュールの取得リクエストを送信する設計でした。それが原因となり、GitHubからのAPIレート制限に抵触し、プロバイダーやモジュールを取得できない問題が発生しました。この問題を解決するために、新たにAPI GatewayをLambdaとGitHubの間に追加し、GitHubへのリクエストをキャッシュしました。これにより、APIレート制限に抵触する問題は回避できましたが、リクエストタイムアウトが発生するなどの問題が新たに出現しました。メンテナーは問題が起こる度にキャッシュ機構を強化するなどの対応をしましたが、構造が複雑になり、メンテナンス性の低下を招く結果となってしまったようです。Alpha Registryは、何度も改良を重ねながらOpenTofuの初期リリースを支えることができました。しかし、その設計は一時的なものであり、今後のStable Registryに向けてAlpha Registryは廃止されました。

Alpha Registryを運用して得られた教訓

OpenTofuのコアチームメンバーがAlpha Registryの開発を通して得た学びとして以下の3点が挙げられていました。

• シンプルに保つこと
• OpenTofuの仕組みと調和させること
• メンテナンスの負荷を軽くすること

シンプルに保つこと

Alpha Registryの開発では、問題を解決するために新たなLambdaやキャッシュ機構を追加し続けた結果、システム全体が複雑化しました。システムの複雑さにより、Alpha Registryにおいて問題が発生した際の対応が困難でした。これにより、次のバージョンの開発においてシンプルな設計にすべきであることを認識することになったようです。

OpenTofuの仕組みと調和させること

Alpha Registryはスピードを重視して開発されたため、OpenTofuとレジストリとのやり取りの仕組みが十分に反映されていませんでした。これにより、システムの設計において、既存のコードやプロセスに合わせることの重要性を学びました。

メンテナンスの負荷を軽くすること

Alpha Registryにおいて問題が発生した際は解決するために多くの時間が費やされました。開発者の時間は貴重であり、問題の解決やデバッグに費やす時間を最小限に抑えるような設計を考えることが不可欠でした。

Alpha Registryの開発運用で得られた以上の知見をもとに安定版であるStable Registryの開発が開始されました。

Stable Registry

Stable Registryの設計プロセスはRFC（Request For Comments）という方法を採用しました。これは、コミュニティ全体に提案を公開し、フィードバックや意見を求めるものです。実際に起票されたRFCはOpenTofuのGitHub RepositoryにあるIssuesから見ることができます。RFCプロセスを用いることでコミュニティの知識と経験を最大限利用することが期待されています。RFCが活用された一例として、コミュニティがRFCプロセスを通してHomebrewのようなレジストリのデザインを採用したことが紹介されていました。

また、Stable Registryを実現する具体的な方法として取り組まれた4つの項目について説明がなされました。

• リポジトリのフォルダ構造の設計
• 定期的なバージョンの更新
• APIによる静的ファイルの提供
• PR (Pull Request)を通じたプロバイダーやモジュールの追加

リポジトリのフォルダ構造の設計

OpenTofu Registryが提供するコンテンツはGitHubにあるopentofu/registryリポジトリにて管理されています。コンテンツは各プロバイダーとモジュールのメタデータが記載されているJSONファイルになります。このリポジトリはhomebrew-coreのフォルダ構造に倣い、プロバイダーおよびモジュールのイニシャルアルファベットごとにJSONファイルが配置されるよう設計されました。

定期的なバージョンの更新

opentofu/registryリポジトリでは定期的にGitHub Actionsのワークフローが実行されています。このワークフローはプロバイダーとモジュールのバージョン情報をスクレイピングし、更新を検知するとJSONファイルへと取り込みます。Alpha Registryと異なり、クライアントからのリクエストごとにGitHub APIへアクセスすることがなくなったため、レート制限への抵触の回避が可能となりました。

APIによる静的ファイルの提供

Stable Registryが提供するAPIは全て静的なJSONファイルをレスポンスとして返すように設計されました。それにより、Cloudflare R2によるホスティングが可能となり、複雑性の排除を実現しました。

PR (Pull Request)を通じたプロバイダーやモジュールの追加

プロバイダーやモジュールを追加するためのプロセスとして、GitHubのPRが採用されました。新しいプロバイダーやモジュールを追加したいコミュニティメンバーは、opentofu/registryリポジトリにプロバイダーやモジュールのメタデータを記載したJSONファイルを含むPRを作成します。PRが作成されると、プロジェクトのメンテナーがレビューします。レビューした結果、内容に問題なければPRはマージされ、新しいプロバイダーやモジュールがStable Registryに追加されます。PRを通じたプロバイダーやモジュールの追加は、コミュニティからのコントリビューションを効率的に受けるための重要なプロセスとなっています。

以上の取り組みにより、今日のOpenTofu Registryは秒間500リクエストを処理し、99%以上のキャッシュヒット率を維持する安定的な運用がなされています。新しいプロバイダーやモジュールの追加などが活発に行われているとのことでした。

まとめと所感

KubeCon + CloudNativeCon Europe 2024の数ある発表の1つであるOpenTofu Registryの沿革に関する発表のレポートをお届けしました。OpenTofu Registryはコミュニティから得られるサポートの最大化を目指しつつ、Alpha版を経て安定版のリリースを達成しました。OpenTofuのコアチームメンバーが乗り越えた苦難を交えつつ、多くの深い学びが共有されているセッションでした。OpenTofuの発展はコミュニティの拡大が不可欠であるため、Terraformからのユーザーをどのように獲得していくのかも注目するポイントです。