【ITニュース解説】Starry: An Internal Developer Platform (IDP) for Ephemeral Environments Part 1

ソフトウェア開発の現場では、大規模なバックエンドアプリケーションが複数のフロントエンドアプリケーションに情報を提供し、ユーザーはウェブブラウザを通じてそれらのフロントエンドとやり取りをする構成がよく見られる。このような環境で開発者が新しい機能を追加したり、既存のコードを変更したりする際には、テストが非常に重要になる。しかし、多くの企業では、開発者が変更したコードを「開発環境」と呼ばれる共有の環境にデプロイしてテストを行うのが一般的である。この方法にはいくつかの問題がある。

まず、ある開発者がデプロイした変更が開発環境を壊してしまうと、他のすべての開発者が自分のテストを進められなくなり、その問題が修正されるまで作業が滞ってしまう。また、複数の開発者が同時に自分の変更をデプロイするため、テスト中にエラーが発生しても、その原因が自分のコードにあるのか、それとも他の誰かの変更にあるのかを特定するのが非常に難しいという課題がある。開発環境、ステージング環境、本番環境といった限られた数の共有環境では、このような問題が頻繁に発生し、開発効率を低下させる要因となるのだ。

このような課題を解決するために、「一時的な環境（Ephemeral Environment）」という考え方が登場する。これは、開発者が特定の機能開発のために作成したブランチ（フィーチャーブランチと呼ばれる）に基づいて、短期間だけ利用できる専用のテスト環境を自動的に構築する仕組みだ。この一時的な環境では、自分の変更だけがデプロイされるため、他の開発者のコードに影響されることなく、独立してテストを進めることができる。これにより、エラーの切り分けが容易になり、開発者は安心して自分のコードの品質を確認できるようになる。テストが完了すれば、この一時的な環境は自動的に削除されるため、リソースの無駄も発生しない。

この一時的な環境を、開発者が簡単かつ迅速に作成・管理できるように提供する仕組みが、「Internal Developer Platform（IDP）」、すなわち社内開発者プラットフォームである。IDPは、社内の「プラットフォームチーム」と呼ばれる専門チームが構築するもので、開発者が日々の開発作業を効率的に行えるように、「ゴールデンパス」と呼ばれるベストプラクティスに基づいた開発手順やツール群を提供する。IDPの大きな特徴は、開発者が自分で必要な操作を行える「セルフサービス」の機能を提供することだ。 IDPは、数多くの異なる技術やツールを組み合わせることで実現されるが、開発者にとってはそれらの複雑さを意識することなく、直感的に操作できるインターフェースを提供するように設計される。これにより、開発者は基盤となる技術の深い知識がなくても、高度な開発タスクを実行できるようになる。プラットフォームチームは、このIDP自体を一つの「プロダクト」として捉え、ユーザーである開発者のニーズを継続的に調査し、プラットフォームを維持・改善していくというアプローチを取る。

今回紹介する「Starry」というIDPの設計例は、まさにこの一時的な環境の簡単な作成を可能にするものだ。例えば、あなたの会社に大規模なバックエンドアプリケーションと、それに情報を供給する複数のフロントエンドアプリケーションがあると想定しよう。Starryを使えば、開発者は自分のフィーチャーブランチ（例: feat/myfeature-00）のコード変更をテストするために、専用の環境（例: test-00）を構築できる。この環境では、test-00.sample-be.starry.mycompany.com のように、特定のURLを通じてその環境内のアプリケーションにアクセスできる。自分の変更がバックエンドやフロントエンドにどのような影響を与えるかを、他の誰にも邪魔されずに確認できるのだ。

StarryのようなIDPを構築するためには、いくつかの重要な技術ツールが組み合わされる。

まず、「Kubernetes（クーバネティス）」は、アプリケーションのデプロイやリソースの管理を劇的にシンプルにするためのシステムだ。多数のアプリケーションを安定して動かし、必要に応じてスケールさせることができる。Google Cloud Platform（GCP）上で稼働する「GKE（Google Kubernetes Engine）」のようなKubernetesクラスターが、Starryシステムの基盤となる。アプリケーションのコンテナイメージ（実行可能なプログラムのパッケージ）は「Artifact Registry」に保存され、アプリケーションが必要とするパスワードやAPIキーなどの機密情報は「Secret Manager」によって安全に管理される。

次に、「Helm（ヘルム）」は、Kubernetes上でアプリケーションをデプロイするための「パッケージマネージャー」のような役割を果たす。複雑なアプリケーションの定義を「Helmチャート」という形で一つにまとめ、簡単なコマンドでデプロイや管理を可能にする。Starryの設計では、二つの種類のHelmチャートが使われる。一つは、一時的な環境全体を定義するカスタムチャートだ。これには、バックエンドアプリケーション、複数のフロントエンドアプリケーション、データベース、キャッシュ、そしてそれらが互いに通信するためのサービス設定、さらにはアクセスを制御するIngressや必要な秘密情報などが含まれる。このチャートは、それぞれの環境のために固有の「名前空間（namespace）」と呼ばれる隔離された領域をKubernetes内に作成する。もう一つは、Starryアプリケーション自体をデプロイするためのHelmチャートだ。このStarryアプリケーションは、開発者がウェブブラウザを通じて一時的な環境を作成したり、その詳細を確認したり、テスト後に削除したりするためのユーザーインターフェースを提供する。

そして、「ArgoCD（アルゴシーディー）」は、Kubernetes環境におけるアプリケーションのデプロイを自動化し、管理するためのツールである。Starryアプリケーションや各一時的な環境のアプリケーションがKubernetes上で常に望ましい状態にあることを保証する役割を担う。例えば、Starryのメインコードに変更がマージされた場合、ArgoCDが自動的にその変更を本番環境のStarryアプリケーションに反映させる。また、一時的な環境が削除された際には、その環境に関連するすべてのリソース（アプリケーションだけでなく、設定ファイルなども含む）がKubernetes上から確実に削除されるように管理する。ArgoCDは、個々のリソースのデプロイ状況や健康状態を詳細に追跡し、プラットフォームチームがシステムの状態を把握しやすくするだけでなく、開発者自身が自分の環境の問題をトラブルシューティングするための情報も提供できる。

最後に、これらすべてのインフラストラクチャを最初に構築し、管理するために、「Terraform（テラフォーム）」という「Infrastructure as Code（IaC）」ツールが使用される。Terraformを使うと、Kubernetesクラスターやクラウドサービスの設定などをコードとして定義できる。これにより、手動での設定ミスを防ぎ、必要なインフラを自動的かつ一貫性のある方法で、何度でも再現性高く構築できるようになる。

最終的に、これらのツールが連携することで、システムの全体像が形作られる。GitHubのようなバージョン管理システムには、バックエンドアプリケーション、フロントエンドアプリケーション、各種Helmチャート、ArgoCDの設定、そしてTerraformのインフラ定義など、すべてのコードがリポジトリとして保存される。また、各アプリケーションやStarry自体に対応するコンテナイメージが、それぞれのイメージリポジトリに格納される。

このように、一時的な環境をIDPとして提供することで、開発者は自分のコードを他の開発者の影響を受けずに、迅速かつ確実にテストできるようになる。これは、開発のスピードと品質を向上させ、最終的にはより良いソフトウェアをユーザーに提供することにつながる、現代の開発現場において非常に強力なアプローチなのだ。