KINTO Tech Blog
PlatformEngineering

How We Developed a CMDB In-House

Masaki Yamada
Masaki Yamada
Cover Image for How We Developed a CMDB In-House

Introduction

Hello. I am Yamada, and I develop and operate in-house tools in the Platform Engineering Team of KINTO Technologies' (KTC) Platform Group.
In this article, I will talk about the CMDB developed by the Platform Engineering team, its functions, the technology used, and how we made it in-house.

What is a CMDB?

A CMDB (Configuration Management Database) centrally manages the assets and configurations that are critical to delivering IT services.
The primary role of a CMDB is to manage the lifecycles and information of assets (e.g., infrastructure required to deliver IT services, product information, product managers and other human resources).

Why We Made the CMDB In-House

Before we implemented a CMDB, as the number of products we had was increasing, everyone was working in silos with their asset information. Whenever there was an incident, it was difficult to determine who was in charge of a product or the extent of the impact.
As a solution to these issues, we considered implementing a CMDB to centrally manage asset information in the company.
There are several off-the-shelf CMDB software, but after considering installation and operation costs and customizability, we decided to make one in-house.

The Features of Our CMDB

Our company's CMDB includes fundamental functions like product and team management, and it's designed to seamlessly integrate with tools developed by other teams within the Platform Group.
Some functionalities are still in development, but we are adding more every day so that anyone can view it and find the information they want.

Product Management

It manages basic information such as product names, affiliated departments, and management team.
If a product malfunctions, you can easily find and contact the person responsible for it. For products that consist of multiple microservices, it can also manage which teams develop which functions, so you can accurately determine the right person in the event of a malfunction.
Below is the product details screen, where you can check the team and domain information associated with a product. We plan to add more information such as which environment the product is in.
There is also an item called "SID", which I will discuss later.
product

Domain Management

This manages domains associated with products. domain

Team Management

This manages team information associated with products. team

Manager Management

This manages permissions for each user and group.

DB Management

This provides a mechanism to easily view all RDS information managed by KTC in the CMDB by linking with tools developed by the DBRE Team, which is also part of the Platform Group.
In addition to basic RDS information, you check ER diagrams and DB designs according to the policy set by the DBRE team.

Security Management

Security management lets you manage the repository and its vulnerability information on the ECR.
If a vulnerability is found in the weekly ECR repository scan, the MSP Team, which provides operational support, will work with the team that manages the repository. In that situation, it outputs an Excel file of the scan results and a CVS file that creates a Jira ticket for a response request to the person in charge.

Scheduling Management

This provides a scheduling management function that stops EC2, ECS, and RDS in the development environment for a certain period of time for the purpose of reducing AWS costs.
By stopping services during late weekday nights and weekends when they are not required, it contributes to cost reduction.

External Linking

With external linking, you can link the AutoProvisioning system to the sandbox environment on AWS and manage the history.
For more information, please read the article below!

https://blog.kinto-technologies.com/posts/2023-05-30-AutoProvisioning/

SIDs

To connect the data in the functions I have talked about up to now, KTC has the concept of SID. SID stands for Service ID and is a unique identifier for each product managed by KTC.
For example, the SID of CMDB is set to kakazan. The name "Kakazan" comes from the mountain where the Monkey King was born in the novel Journey to the West. In fact, the name KINTO also comes from the Monkey King's story; it’s the name of his flying nimbus “Kinto'un”. So in the same way, it’s fun to see how a lot of the SIDs for KTC products are referencing Journey to the West.
SIDs are used as product names and makes clear who is the owner of each product. This concept is spreading throughout KTC. In particular, AWS resource management uses ECS, RDS, S3, API Gateway, and many other AWS services for each product. The Tag setting is effective when determining which resources belong to which product. The resources are then linked to the products by attaching a SID tag to the resource.
The CMDB uses this SID tag setting to link various information together.

Technology Used

I will briefly go over some technical elements used to develop the CMDB.
The frontend is developed using React, while the backend is built with Spring Boot. Both utilize a shared framework for authentication, authorization, and utility classes. Additionally, there are three services—for the main service, DB management, and external linking—that are all dependent on the common framework. Batch processing was also developed with Spring Batch.
I would like to write more about the system configuration another time.

Future Plans

We have more technologies to explore, and we plan to continually update features. Some are still in development, while others are on our agenda for future work.
For example, we can try using EKS since KTC uses ECS as its container execution environment, or we can try using microfrontends (which are not necessary in terms of development scale), or we can implement PWAs (Progressive Web Apps) so the CMDB dashboard can be viewed from company smartphones, and so on.
I think there are opportunities to explore only because the system was made in-house, so we will make good use of this system by trying out technologies that could be deployed in-house in the future.
We also want to add functions to the common framework used to develop the CMDB, create a group of React components to suit the KINTO brand image, and implement them as a library to be used throughout the company.

Conclusion

In this article, I talked about the CMDB we developed at KTC, its background and functions, and our vision for the future.
KTC s actively involved in the development of various systems alongside managing the services handled by KINTO I hope that this article has raised interest in KTC activities.

Facebook

関連記事 | Related Posts

We are hiring!

【DBRE】プラットフォームG/東京・名古屋・大阪

DBREグループについてKINTO テクノロジーズにおける DBRE は横断組織です。自分たちのアウトプットがビジネスに反映されることによって価値提供されます。

【プロダクト開発バックエンドエンジニア】共通サービス開発G/東京・大阪

共通サービス開発グループについてWebサービスやモバイルアプリの開発において、必要となる共通機能=会員プラットフォームや決済プラットフォームの開発を手がけるグループです。KINTOの名前が付くサービスやTFS関連のサービスをひとつのアカウントで利用できるよう、様々な共通機能を構築することを目的としています。