インベントリを使用して資産を管理し、重複を防ぐ
組織が成長するにつれて、追跡する必要がある量も増えます。あるチームが他のチームのプロジェクトについて把握していないために、組織で内部作業が重複していることがよくあります。 チーム間で人事移動があったり、新しい人が入社したり、誰かが退職したりすると、プロジェクトが孤立する可能性があります。 インベントリはこれらの問題を解決するのに役立ち、プラットフォーム エンジニアリングの重要な部分です。
インベントリは、組織の技術的資産を追跡、管理、整理するために使用されるツールまたはシステムです。 これらの資産には、コード、API、コンテナー、仮想マシン (VM)、チームのアクセス許可などが含まれます。
資産を追跡しないと、既に存在するものを簡単に検出できないという理由だけで、技術的なスプロールや無駄につながります。 既に存在するものを追跡できなくなることは、よくある課題です。
大量のコンテナーまたは [VM] インスタンスが実行されています。 古い VM を削除できますか? わかりません。 古いものをクリーンアップし、適切なタグを使用する方法を考え出して、実行できることやライフサイクルについて、通知できる所有者またはチームを把握する必要があります。... 何が起こるか不明なため、特定の VM をシャットダウンできるかはわかりません。 - Martin、DevOps エンジニア、大手物流会社
資産の追跡
必要なのは、内部の顧客が理解できる方法で視覚化された、作成済みまたはエコシステムに組み込んだすべての "もの" を追跡するためのインベントリです。
インベントリにより、セキュリティが向上し、再利用が促進され、一般的に検出が容易になります。 異なる種類の資産を追跡するために使用できるさまざまなツールがあります。 これらの各ツールには、無駄なものの管理、追跡、クリーンアップに役立つインベントリが用意されています。
使用可能な追跡ツールは次のとおりです。
- Azure Deployment Environments を使用すると、抽象環境として、コードとしてのインフラストラクチャ (IaC) を介して作成された複雑なインフラストラクチャを追跡できます。
- Azure API Center は、開発者が API を検出して使用する方法を提供します。
- GitHub Packages や Azure Artifacts (または承認済みパッケージや SDK のその他のインベントリ) などのパッケージ レジストリにより、サプライ チェーンのセキュリティが向上します。
インベントリの可視性を決定するときは、組織に最適なアプローチを検討してください。 一部の組織では、すべての開発者がソフトウェア資産を表示できますが、一部の組織では、オープン キッチンと同様に変更できます。 特に規制対象の業界では、アクセスをより厳密に制限し、秘密度のためにプロジェクト名の可視性を制限する場合もあります。
検出可能性、ガバナンス、再利用の強化
既存のものを追跡するのに役立つ 1 つまたは複数のインベントリ システムを用意することは、プラットフォームのエンジニアリング プラクティスと技術的なスプロールの回避にとって重要です。 最初は、一連のフラット インベントリ リストで十分な場合があります。 ただし、複数のインベントリ間で異なる資産間のリレーションシップを追加することで、検出可能性をさらに向上させることができます。 必要な可視性のレベルに関係なく、集約ポイントを一元化することで、チームは利用可能なすべての資産をすばやく検索して検出できます。 これにより、再利用が促進され、冗長性が低下し、ガバナンスに対する一貫したアプローチが確立されます。
API 定義と、インターフェイスを実装するデプロイされたアプリケーション コードの間の関係を検討してください。 このコードはリポジトリに格納され、チームが管理し、その使用に関するドキュメントを提供します。 開発、テスト、運用、さらには一時的なサンドボックス環境が作成されます。 クラウド ネイティブ シナリオでは、環境が共有の Kubernetes クラスターにデプロイされる場合があります。 API を構築する開発チームとその内部コンシューマーは、これらの各要素に関する情報を取得できる必要がありますが、リソースの関係は明らかではありません。
最初に、Wiki ページのようにシンプルなものを使用して、それぞれの関係を追跡することができます。 しかし、ドキュメントはすぐに古くなり、検索したり、解析したりすることの両方が難しくなる場合があります。 理想的には、インベントリ内のこれらのリレーションシップを走査するユーザー インターフェイスを有効にできるリレーションシップ グラフ を持つシステムが必要です。 検出可能性を本当に向上させるには、複数の種類のインベントリまたはグラフに保存されているものを関連付ける必要があります。 インベントリを直接使用する必要はありませんが、API カタログ システム内の情報に関連付けることができます。
インベントリをリレーショナル グラフとカタログとリンクする
デジタル ストアに例えて、カタログ内のアイテム (テンプレート) を結果のインベントリの内容に関連付けるのも役立ちます。 たとえば、いずれかのテンプレートで安全ではない構成が作成されている場合は、テンプレートを作成したすべてのリソースをすばやく見つけて修正する必要があります。 起動に適したアプリケーション テンプレートも、基本的にこのカタログ内のスタート キット バンドルであり、他の種類のカタログのアイテム (IaC テンプレートなど) と結び付いています。 これらの関連付けを追跡すると、インフラストラクチャがまだプロビジョニングされていない場合でも、不適切な IaC テンプレートを参照するアプリケーションを事前に見つけることができます。
この概念的で高度な開発者プラットフォーム グラフの簡略化されたバリエーションは、現在、いくつかのツールキットや製品で見つけることができますが、呼び出される内容は異なります。 たとえば、オープンソース ポータル ツールキット Backstage.io はこれをソフトウェア カタログと呼び、他の製品には異なる用語を使用しています。 ただし、これらの製品やツールキットのほとんどは、より広範な機能セットを使用していることを前提としており、インベントリの内容をそれらの中で複製する必要があります。 この重複は、カタログ データベースの内容がユーザー固有ではなく、古くなる可能性があり、実際のソース システムのユーザー承認メカニズムによって制御されていないことを意味します。 ただし、オープン キッチンのアプローチに従っている場合は、組織で問題なく動作する場合があります。