CLOUD SECURITY LAB

Backstageの原子、「Entity（エンティティ）」を徹底解剖 – サービスからチームまでを一つに！

—

by

cslab
in

プラットフォームエンジニアリングの世界へようこそ！🌟 Backstageを初めて使うと、すべてが「カタログ」を中心に回っていることに気づくでしょう。しかし、このカタログを構成する最小のレンガ、つまり基本単位が何であるかご存知ですか？

今日は、Backstageの根幹をなす「Entity（エンティティ）」について、非常に詳細に掘り下げていきます。この記事を読めば、皆さんの複雑なインフラがどのようにして一つの首尾一貫したデータモデルへと変貌するのかを理解できるでしょう！

1. Entity（エンティティ）とは何ですか？ 🧱

Backstageにおいて、Entityはソフトウェアエコシステム内のすべての個々の構成要素を説明する標準化された基本単位です。

単にソースコードが含まれる「サービス」だけを意味するものではありません。皆さんのシステムを構成する有機的なすべての存在がエンティティになり得ます。

  • サービス（Component）：実際に稼働するマイクロサービスやウェブアプリ
  • API：サービスが提供または消費するインターフェース
  • チーム（Group）＆開発者（User）：誰が作成し管理しているかに関する情報
  • インフラリソース（Resource）：DB、S3バケット、Kubernetesクラスターなど

2. エンティティはどのような構造ですか？ (YAML構造) 📝

エンティティは通常、catalog-info.yamlというファイルで定義されます。このファイルはKubernetesのリソース定義と非常によく似た構造を持っているため、馴染みがあるかもしれません。すべてのエンティティは大きく3つの部分で構成されます。

YAML

apiVersion: backstage.io/v1alpha1
kind: Component # エンティティの種類
metadata:
  name: my-awesome-service # エンティティの名前
  description: 우리 팀의 메인 API 서비스입니다.
  tags: ["java", "spring-boot"]
  annotations:
    backstage.io/managed-by-location: url:https://github.com/...
spec:
  type: service
  owner: team-alpha # 所有チーム（他のエンティティとの関係）
  lifecycle: production
  1. apiVersion & kind: このエンティティが何であるか（コンポーネントか、グループかなど）を定義します。
  2. metadata: 名前、説明、タグなど、検索と識別のための情報を含みます。
  3. spec: その種類（Kind）に特化した詳細情報と、他のエンティティとの関係（Relationship）を定義します。

3. エンティティが強力な理由：関係（Relationship） 🕸️

エンティティが単なる「説明書」を超えて強力な力を発揮する理由は、エンティティ間のつながりがあるからです。

例えば、Componentエンティティのspec.ownerフィールドに特定のGroupエンティティの名前を記述した瞬間、Backstageは自動的にこれら2つを接続します。

  • 「このサービスは誰が管理しているの？」👉 Groupエンティティに接続
  • 「このサービスが使用するDBは何？」👉 Resourceエンティティに接続
  • 「このチームはどのAPIを開発したの？」👉 逆方向から検索可能

これらの関係が集まって、巨大なソフトウェアグラフ（Software Graph）を形成します。

4. 主要なエンティティの種類（Kinds）を見てみましょう 🧐

Backstageはデフォルトで以下の主要なKindを提供します。

Kind 説明 例
Component コードで構成されるソフトウェアの断片 サービス、ウェブサイト、ライブラリ
API サービス間のインターフェース契約 REST API, GraphQL, gRPC
Resource ソフトウェアが動作するために必要なインフラ PostgreSQL, S3, RDS
Group 組織内のチームまたは部署 プラットフォームチーム、決済パート
User 個々の開発者 山田太郎、田中花子
System 関連するエンティティの大きな抽象化グループ 決済システム、ユーザー管理システム

—

5. エンティティが開発者に与える利点 💡

  1. 一貫性：すべてのチームが同じフォーマットで自身のサービスを説明します。
  2. 発見可能性（Discoverability）：「誰が作ったか分からないAPI」がなくなります。カタログでエンティティを一度検索するだけで、すべての情報を見つけることができます。
  3. 自動化の基盤：エンティティ情報に基づいて、デプロイ状況の確認、セキュリティ脆弱性スキャン結果を自動的に連携できます。🤖

🏁 まとめ

Backstageカタログの根幹であるEntityは、単なるデータの一部ではなく、組織の複雑なソフトウェアマップを描く座標のようなものです。エンティティをうまく定義し、接続すればするほど、開発者は不要なコミュニケーションの代わりに実際の「開発」により集中できるようになります。

皆さんのプロジェクトルートに今すぐcatalog-info.yamlを作成し、最初のエンティティを定義してみてはいかがでしょうか？🚀

Comments

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です