CMDBを内製開発しているお話

再生速度

AI が生成した要約です。正確な内容は本文をご確認ください。

要約を読む

CMDBを内製化したことで、社内の資産情報が一元管理され、担当者間の連携がスムーズになりました。導入前はプロダクトが増えるにつれて情報が属人化しており、インシデント発生時に誰が何を担当しているかが判断できず、対応が遅れました。その問題を解決するために、社内にCMDBを内製で開発し、すべての資産情報を一元に管理できるようにしました。結果として、インシデント対応の準備時間は30分から10分に短縮され、チーム間の情報共有が劇的に改善されました。 CMDBではプロダクトやチーム、ドメインの情報を管理しています。プロダクトの障害が発生した際、どのチームがどの機能を開発しているかが一目で確認できるようになっており、対応が迅速に進みます。また、RDSの設計やポリシーの確認もDBREチームのツールと連携してCMDB上で可能にしています。さらに、ECRの脆弱性スキャン結果を自動でExcelとJiraチケットに変換し、MSPチームに連携できるようにしています。 CMDBのデータを紐づけるため、KTCではSIDという識別子を使っています。 SIDはService IDの略で、各プロダクトに固有の名前を設定し、例えばkakazan（花果山）という名前が使われています。このSIDはAWSリソースにタグとして設定され、どのリソースがどのプロダクトの所有物かを明確にしています。これにより、リソースとプロダクトの関係が一貫して管理され、情報の整合性が保たれています。開発ではReactとSpring Bootを使い、フロントとバックエンドを構築しています。共通フレームワークを活用し、認証やユーティリティ機能を標準化し、開発効率を高めています。バッチ処理もSpring Batchで実現しており、自動化された運用が可能になっています。今後はEKSやマイクロフロントエンド、PWAを試す予定です。社内システムだからこそできる試みとして、スマートフォンからCMDBのダッシュボードを見られるようにするなど、使いやすさを高めます。また、共通フレームワークの機能を強化し、Reactのコンポーネントを全社に共有できるようにしたいと考えています。

 はじめにこんにちは。KINTOテクノロジーズ(以下KTC) プラットフォームグループ PlatformEngineeringチームで内製ツールの開発・運用をおこなっている山田です。
今回はPlatformEngineeringチームで開発をしているCMDBについて、内製化に至った背景、機能や使用技術についてご紹介したいと思います。
 CMDBとはCMDB(Configuration Management Database：構成管理データベース)とは、ITサービスを提供する上で必要不可欠な資産とその構成を一元管理するものです。
CMDBの管理対象となる資産(ITサービスの提供に必要なインフラ、プロダクト情報、プロダクト担当者などの人的リソース等)のライフサイクル、情報の管理がCMDBの主な役割となります。
 CMDBを内製化した背景CMDBの導入前では社内のプロダクト数が増えていくにつれてプロダクトごとの資産情報管理が一元管理されず属人化していました。またインシデント発生時にプロダクトの担当者や影響範囲を迅速かつ的確に判断することが困難となっていました。
これらの問題の解決策として社内の資産情報を一元管理するCMDBの導入が検討されました。
CMDBの商用製品はいくつかありますが、導入・運用コストやカスタマイズ性などを考慮した結果、内製化する運びとなりました。
 CMDBの機能紹介KTCのCMDBではプロダクト管理やチーム管理のような基本的な機能に加え、プラットフォームグループの他チームが開発したツールとの連携などの特徴もあります。
まだ開発中の機能もありますが、ここを見れば知りたい情報が見れる！を実現するために日々機能追加に取り組んでいます。
 プロダクト管理ここではプロダクト名や所属部署、管理チームなどの基本的な情報を管理しています。
もしあるプロダクトで障害が発生した場合、簡単にプロダクトの担当者を見つけて連絡を取ることができます。また複数のマイクロサービスで構成されるプロダクトがある場合、どのチームがどの機能を開発しているかも管理されているため、障害発生時に適切な担当者の判別が的確にできるようになりました。
以下がプロダクト詳細画面で、プロダクトに紐づくチームやドメイン情報を確認できます。今後はプロダクトがどの環境に存在するかなどの情報も追加予定です。
また、「SID」という項目がありますがこれは後ほど説明します。
 ドメイン管理プロダクトに紐づくドメインを管理します。

 チーム管理プロダクトに紐づくチーム情報を管理します。

 管理者管理ユーザー、グループ単位で権限を管理します。
 DB管理ここでは同じプラットフォームグループのDBREチームが開発したツールとの連携をおこない、KTCで管理する全てのRDSの情報をCMDB上で簡単に閲覧できるような仕組みを提供しています。
RDSの基本的な情報に加え、DBREチームが設定したポリシーに則ってDB設計ができているかや、ER図を確認することができます。
 セキュリティ管理セキュリティ管理では、ECR上のリポジトリとその脆弱性情報を管理します。
週次でECRリポジトリのスキャンを実行して脆弱性が見つかった場合、運用サポートをおこなうMSPチームがリポジトリを管理するチームへの連携をおこないます。そのときに利用するスキャン結果のExcelファイルと担当者への対応依頼用のJiraチケットを作成するCSVファイルの出力も提供します。
 スケジューリング管理AWSのコスト削減を目的として、開発環境のEC2, ECS, RDSを一定時間停止させるスケジューリング管理機能を提供します。
これにより稼働する必要のない平日の深夜や土日を対象としてサービスを停止させ、コスト削減に繋がるようになります。
 外部連携外部連携ではAWS上のsandbox環境へのAutoProvisioning(自動環境構築)システムとの連携と履歴の管理をおこなっています。
詳しくは以下の記事に書かれているため、是非ご覧ください！

https://blog.kinto-technologies.com/posts/2023-05-30-AutoProvisioning/
 SIDについてここまで機能の紹介をしましたが、これらのデータの紐づけ方法としてKTCには SID という概念があります。

SID とは Service ID の略で、KTCで管理しているプロダクト単位で固有の識別子を設定しています。
例えばCMDBであれば kakazan というSIDを設定しています。

kakazan(花果山)は西遊記の孫悟空が生まれた山とされているため、ここから名前を取りました。

KINTOの名前は西遊記に出てくる孫悟空の筋斗雲が由来となっているため、KTC内でのプロダクトのSIDには西遊記由来のものが多く存在していて面白いです。
このSIDは各プロダクトの名称として使用しており、それぞれのプロダクトの所有者を明確にするなど、KTC内で浸透している概念です。

特にAWSリソース管理の面では、一つのプロダクトでECS、RDS、S3、API Gateway など、多くのAWSサービスを使用します。

どのリソースがどのプロダクトの所有物なのかを判別するために有効なのがTag設定で、リソースにはSIDタグを付けることでリソースとプロダクトを紐づけています。
CMDBではこのSIDタグの設定を活用することで様々な情報と連携させています。
 使用技術ここではCMDBの開発で使っている技術要素について簡単にご紹介します。
フロントエンドはReactで開発していて、バックエンドはSpring Boot製で認証認可やユーティリティクラスを提供する共通フレームワークと、その共通フレームワークを依存関係に持つサービス3つ(メインサービス用、DB管理用、外部連携用)で構築しています。また、バッチ処理はSpring Batchで開発しています。
システム構成に関してはまた別の機会に詳しく書ければと思います。
 これからまだ開発中の機能やこれから開発をしたい機能がたくさんあるため、これからも機能追加をしていく予定ですが、それと並行して試したい技術もあります。
例えばKTCではコンテナ実行環境としてECSを使っているためEKSを使ってみたり、(開発規模的に不要ですが)マイクロフロントエンドを試してみたり、PWA(Progressive Web Apps)を導入して社用スマートフォンからCMDBのダッシュボードを見れるようにしたり、、、
社内システムだからこそ試せる部分もあると思うので、将来的に社内に展開できるような技術を試す場としてもこのシステムをうまく利用していきたいと思います。
また、CMDBの開発でも使っている共通フレームワークの機能充実やKINTOのブランドイメージにあわせたReactのコンポーネント群を作成して、ライブラリとして全社に展開できればと思います。
 さいごに今回はKTCで開発しているCMDBについて、その開発背景から機能、そして将来のビジョンについてご紹介しました。
KTCではKINTOで扱っているサービスだけでなく、さまざまなシステムの開発に取り組んでいます。この記事を通じて、KTCの取り組みに少しでも興味を持っていただけたら嬉しいです。