プラットフォームエンジニアの皆さん、こんにちは！🚀 Backstageを使っていると、catalog-info.yamlファイルがどうやって魔法のように画面に表示されるのか、不思議に思ったことはありませんか？
Backstageカタログは単にDBを照会するだけでなく、巨大な「データパイプライン」のように動作します。今日は、そのパイプラインの最初の段階であるIngestion（取り込み）プロセスについて詳しく掘り下げていきます！
1. カタログバックエンドの全体フローを理解する 🌊
詳細なステップに入る前に、まず全体像を把握しましょう。カタログデータは大きく3つの段階を経ます。
- Ingestion (取り込み): 外部データ（GitHub、YAMLなど）をシステム内部に取り込む段階 （今日の主役！）
- Processing (処理): 取り込んだデータを検証し、関連性を分析する段階
- Stitching (スティッチング): 分散したデータ断片をまとめ、最終的な「エンティティ(Entity)」オブジェクトを完成させる段階
2. 最初の関門：Ingestion (取り込み) 📥
システム外部の「Raw Data（加工されていないデータ）」がカタログの世界に足を踏み入れる最初の段階です。この段階の目標は、「どこかからデータを読み込み、カタログDBの一時保存領域（Shadow Table）に入れること」です。
この役割を果たす主な方法は2つあります。
① Entity Providers (エンティティプロバイダー) 🤖
最新のBackstageアーキテクチャで推奨される方式です。外部システム（例：AWS、GitHub組織、LDAP）を定期的にスキャンし、一度に多くのデータを投入する際に使用します。
- 利点: 大量のデータを効率的に取得し、外部システムの変更を同期するのに最適化されています。
② Processors (プロセッサー – Reading段階) 📖
伝統的な方式で、特定のURL（例：GitHubのyamlファイルパス）を介してデータを「読み込む」役割を果たします。
- 動作: UrlReaderインターフェースを使用して、指定されたパスのファイル内容をテキスト形式で読み込みます。
3. なぜこの段階が重要なのでしょうか？ ✨
ProcessingやStitching段階は、既に取り込まれたデータを「料理」する過程です。しかし、Ingestion段階は「食材を買いに行く過程」と同じです。
- データソースの多様性: GitHubだけでなく、データベース、API、Excelファイルなど、何でも「取り込み」段階を実装すればBackstageに登録できます。
- パフォーマンスの起点: ここでデータをどれだけ効率的に取得するかによって、カタログ全体の更新速度が決まります。⚡
4. Raw Dataが取り込まれた後、何が起こるのでしょうか？ 🔄
データがシステム内部に取り込まれても、まだ「Stitched」されていない状態です。
- Validation: 取り込まれたYAMLが仕様に合致しているか検証します。
- Relation Parsing: owner: team-aという記述を見て、このサービスとチーム間の関連性を見つけ始めます。
- Final Stitching: すべての検証が完了すると、ついに画面で見る素晴らしいエンティティカードが完成します！
5. 要約：核心は「Entity Provider」と「Reader」 📝
Backstageカタログバックエンドのフローにおいて、データを処理しスティッチングする前に、外部の生（Raw）のデータをシステム内部に引き込む段階はIngestionです。
開発者として、新しいデータソースをBackstageに連携させたい場合、まさにこのIngestion段階のカスタムEntity Providerを作成することから始めることになります。
🏁 終わりに
Backstageは単なるウェブサイトではなく、強力なデータ統合エンジンです。そのエンジンに燃料を供給するプロセスが、今日学んだIngestion段階です。このプロセスを理解することで、「なぜ私のサービスがカタログに表示されないのだろう？」といったトラブルシューティングの状況でも慌てずに原因を見つけることができるでしょう！
コメントを残す