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

 はじめにこんにちは。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の取り組みに少しでも興味を持っていただけたら嬉しいです。