OSSで実現する効率化・コスト削減

Backstageによるセルフサービス型開発者ポータル構築事例：開発・運用効率化とオンボーディングコスト削減

Tags: Backstage, Developer Platform, 開発効率化, 運用効率化, コスト削減, OSS事例, DevOps, マイクロサービス, セルフサービス, オンボーディング

導入部：マイクロサービス時代の複雑性と開発者生産性の課題

近年、多くの組織でシステムがマイクロサービス化され、サービス数や関連ツールが爆発的に増加しています。これにより、個々のサービスの開発・運用は小規模化・俊速化する一方で、システム全体の構成やサービス間の依存関係を把握することが困難になりつつあります。

このような状況は、開発者や運用者が以下のような課題に直面する要因となります。

これらの課題は、開発者生産性の低下や組織全体の運用コスト増加に直結します。ある技術部門では、これらの課題に対し、開発者がセルフサービスで必要な情報にアクセスし、開発タスクを実行できる「Developer Platform」の構築が不可欠であると判断しました。その実現手段として、OSSであるBackstageに着目しました。

導入前の状況：サイロ化された情報と非効率な開発・運用プロセス

Developer Platform導入以前、この組織ではマイクロサービス化が進行していましたが、各サービスやチームごとにツール、情報ソースが分散していました。

導入の意思決定と選定：OSSとしてのBackstageに注目

これらの非効率を解消し、開発者体験（Developer Experience）を向上させるためのDeveloper Platform構築にあたり、組織は以下の選択肢を検討しました。

  1. 商用Developer Platform製品の導入: 機能は豊富だが、コストが高額になる可能性があり、既存ツールとの連携における柔軟性に懸念があった。
  2. フルスクラッチでの内製開発: 要件に完全に合致させられる可能性があるが、開発・保守に多大なリソースが必要となり、本業の開発が圧迫されるリスクがある。
  3. OSSの活用: コストを抑えつつ、コミュニティの力やPlugin機構による拡張性が期待できる。

検討の結果、特にマイクロサービス環境における開発者体験向上に焦点を当てたOSSであるBackstageが、組織の課題解決に最も適していると判断されました。選定理由は以下の通りです。

一方で、懸念点として、Backstage自体が比較的新しいOSSであり、ドキュメントや知見が商用製品に比べて少ない可能性、Plugin開発・保守に必要な技術力の確保などが挙げられました。これらの懸念に対しては、PoC（概念実証）を通じて技術的な実現可能性と学習コストを見極め、段階的な導入計画を立て、必要に応じて社内技術者の育成やOSSコミュニティへの参加を支援することで対応することとしました。

具体的な導入・活用：Backstageを開発者ポータルとして活用

Backstageの導入は、まず基本的なサービスカタログ機能とドキュメント表示機能から開始し、段階的に他のPluginを組み込む形で進められました。

アーキテクチャ概要:

Backstage本体（TypeScript/Reactベースのフロントエンド、Node.jsベースのバックエンド）をコンテナ化し、既存のKubernetesクラスタ上にデプロイしました。データストアとしてはPostgreSQLを利用しました。既存のGitLab, Jenkins, Prometheus, Grafanaなどのツールとは、それぞれのAPIを利用するBackstage Pluginを介して連携しました。

graph TD
    A[開発者/運用者] --> B[Backstage UI]
    B --> C[Backstage Backend]
    C --> D[PostgreSQL DB]
    C --> E(サービスカタログ Plugin)
    C --> F(ドキュメント Plugin)
    C --> G(ソフトウェアテンプレート Plugin)
    C --> H(外部ツール連携 Plugins)
    E --> I[GitLab/GitHub (SCM)]
    F --> I
    G --> I
    H --> J[Jenkins/GitLab CI (CI/CD)]
    H --> K[Prometheus/Grafana (監視)]
    H --> L[Elasticsearch/Kibana (ログ)]
    H --> M[その他ツール API]

    I --> N(リポジトリ/コード)
    J --> O(CI/CD情報)
    K --> P(メトリクス/ダッシュボード)
    L --> Q(ログ情報)

    N, O, P, Q --> B

    classDef default fill:#f9f,stroke:#333,stroke-width:2px;

導入プロセスと具体的な活用:

  1. PoC: 小規模なチームを対象にBackstageの基本機能を検証。サービスカタログへの既存サービス登録、TechDocsによるドキュメント表示、簡単なテンプレート実行などを試行し、有効性を確認。
  2. 初期導入: まず全開発チームに対し、主要なサービス情報のサービスカタログ登録と、TechDocsによるMarkdownドキュメントのBackstage上での表示を義務付けました。これにより、どのサービスがどこにあるか、基本的な仕様はどうなっているかといった情報へのアクセス性が向上しました。
  3. Plugin拡張と全社展開:
    • CI/CD連携: Jenkins PluginやGitLab CI Pluginを導入し、サービスカタログから直接、各サービスの最新ビルド状態やパイプライン実行結果を確認できるようにしました。
    • 監視・ログ連携: Prometheus Plugin, Grafana Plugin, Elasticsearch Pluginを導入し、サービスに紐づく監視ダッシュボードやログ集計結果へのリンクをBackstage上に集約しました。これにより、問題発生時の情報収集時間が大幅に短縮されました。
    • ソフトウェアテンプレート: 標準的なマイクロサービスのテンプレートを作成し、開発者がBackstage上から数クリックで、リポジトリ作成、CI/CDパイプライン設定、基本的な構成ファイルが揃った状態のサービスを生成できるようにしました。
    • スクラッチ開発Plugin: 社内固有のツールやワークフローと連携するためのPluginを自社開発しました。

導入によって得られた成果：開発者体験向上と具体的なコスト削減

BackstageをDeveloper Platformの中核として活用した結果、組織は以下の定量的・定性的な成果を得ることができました。

直面した課題と克服：OSS導入・運用のリアルな側面

Backstageの導入は順調に進みましたが、いくつかの課題にも直面しました。

まとめと今後の展望：OSS Developer Platformがもたらす組織変革

この事例は、OSSであるBackstageをDeveloper Platformとして活用することが、マイクロサービス時代の複雑なシステム開発・運用環境において、開発者生産性の向上、運用コストの削減、そして組織全体の効率化に大きく貢献できることを示しています。

Backstageは、単なるツールではなく、サービスや技術情報、開発プロセスを統合する「中心的なハブ」となり、サイロ化された情報を解消し、開発者がより迅速かつ自律的に業務を進められる環境を整備します。これにより、新規参加者のオンボーディング期間短縮や、既存メンバーの開発・運用効率向上といった具体的な成果に繋がります。

OSSを選択することで、高額な商用ライセンス費用を削減できるだけでなく、Plugin機構による高い拡張性を活用し、組織独自の要件や既存ツールとの連携を柔軟に実現できる点も大きなメリットです。ただし、OSSであるゆえに、導入・運用にはある程度の技術力や、コミュニティを活用した情報収集能力が必要となります。また、ツール導入だけでなく、情報の整備や組織文化への定着促進といった、技術以外の側面への配慮も成功には不可欠です。

今後の展望としては、Backstageにさらに多様なPluginを開発・組み込むことで、FinOps関連情報（サービスごとのクラウドコスト可視化）や、AI/MLモデルの情報連携など、Developer Platformの機能をさらに拡張し、組織全体のさらなる効率化とコスト最適化を目指していくことが考えられます。

本事例が、複雑化するIT環境における効率化・コスト削減戦略を検討されている他の技術部門責任者層の皆様にとって、OSS活用の一つの有効な選択肢として参考になれば幸いです。