Self Introduction

Nice to meet you, I am Iwasaki, the group manager of the Platform Group at KINTO Technologies Corporation. I joined the development and organization department of KINTO Corporation, the predecessor of KINTO Technologies Corporation, in December 2019. As an infrastructure engineer, I have been building and operating systems while promoting the launch of the group. In addition to being group manager, I am also responsible for SRE, MSP, and CCoE. I originally worked at an IT company that ran e-commerce sites. After working as a server administrator for on-premise and private cloud infrastructure environments, SRE team engineer, and part of management, I joined KINTO.

My Goals for This Article

In this article, my goals are to present you the teams we have in the Platform Group, as well as its past activities and its future, and make you, the reader, want to work with us.

Platform Group

Role

The group is in charge of infrastructure design, construction, and operation with a focus on AWS

Characteristics

There is a mixture of standardized things and ideas that will be implemented in the future. We enjoy the unknown and proactively help others while receiving help in return.

Organizational Structure

Team name	Number of members	Location
System Administrator	6	Tokyo and Osaka
DevOps	6	Tokyo
SRE	3	Tokyo
DBRE	4	Tokyo
MSP	3	Tokyo and Nagoya
CCoE	2	Tokyo and Osaka

• as of November 2022
• Some members are in more than one team

Changes in Number of Team Members

Although it has been three years, it is still growing, albeit not at the rate of Moore's Law.

Team Members' Personalities

Our team includes a wide variety of personalities. We are not hiring people in order to collect all 16 personality types, but I'd be happy to get people with different working styles, as we will be able to have more diverse discussions.

FY23 Group Slogan

This is the slogan for this fiscal year. We envision focusing on increasing the utilization of the various products released in the first half and linking this to our results.

FY2023 Group Mission

This is the group mission for this fiscal year. For Agility and Stability, we originally aimed for +10% on a quarterly basis, and our message is that we will challenge ourselves to see what we can do to further accelerate that.

Team Introduction

The System Administration Team

A team of AWS professional engineers and the core of the Platform Group that is responsible for operation work such as IaC system construction and system change, as well as improvements for things such as system pack releases and application monitoring.

Recruitment page

The DevOps Team

A team of professionals who are familiar with AWS and application tuning and operation. It is responsible for providing CI/CD through GitHub Actions and promoting DevSecOps. One of the key figures behind KINTO Technologies Corporation's switch to a container service (ECS), it is currently focusing on implementing and spreading APM, distributed tracing (X-ray), and other processes.

Recruitment page: No recruiting planned

The SRE Team

A team of experts responsible for the reliability of future products. It is creating SRE guidelines and building up the SRE hierarchy from the bottom up to find out how to improve reliability. It also narrows down products and provides SRE support to the Development Group.

Recruitment page

The DBRE Team

A team of database specialists. It provides tools to visualize databases and improve their reliability and is establishing security measures, masking measures, and other measures.

Recruitment page

The MSP Team

The MSP Team is the administration team that cooperates with partner companies, which take on the roles of the service desk, handling application failures and inquiries, and primary system maintenance, performing primary operations for failures and routine work.

Recruitment page: No recruiting planned

The CCoE Team

A team of cloud security specialists. Creates cloud security guidelines, implements guardrails, and provides AWS/GCP educational support.

Recruitment page

The Trajectory of the Platform Group's Activities

Switching to an In-House Infrastructure Design, Construction, and Operation

The first thing we did was switch from an outsourced system environment to our own AWS environment while converting 24x7 surveillance and other operations to make them in-house. Although we considered it a switch to in-house, we started by doing construction work and a system where one person was on 24x7 PagerDuty.

Using Terraform IaC (Infrastructure as Code) to Create Modules with a Focus on Overall Optimization

Next, we switched to IaC. We had excellent engineers join us, and we decided to fully switch to IaC. We also adopted Terraform with a focus on multicloud. We started EC2 construction by creating an OS image (AMI) with Packer + Ansible and finishing it with Terraform. The initial designs of the Terraform modules were the cornerstone of the switch to ECS.

Switching to Container Service (Moving Away from EC2 and Proceeding with ECS)

Next, we switched to containers (EC2->ECS). We chose ECS instead of EKS because there were many system configurations built for individual products at the time, and we thought ECS had lower learning costs, including CI/CD, and made it easier to switch to containers. Since we expected that the Development Group would be granted access rights for release work after the switch to containers, we wanted to switch while reducing the engineering burden of the Development Group as much as possible and lowering implementation costs.

CI/CD (GitHub Actions) Provision, Education, and Implementation Support

CI/CD was essential to drive the switch to containers. Even if I told them that they could use containers with ECS, it was meaningless unless they could see the merits. So, we provided CI/CD with GitHub Actions and started providing DevSecOps elements that allowed information to be pushed and analyzed statically if used with the CI/CD provided by SonarQube.

System Release (Reducing the Time Spent Building One System Configuration from Two Weeks to Three Days)

Next, we worked on providing a system pack. By narrowing down the system types that are often requested in advance to about six types and having the minimum required input information, we can do the system configuration on AWS and deliver it in three days. This is a system pack. By doing this, we were able to reduce stress and time when doing interviews during the system design process, and I think it contributed to improving relationships with the Development Group. About 70% of requests we have today are to build a Dev environment with a system pack, then have it customized with the content dropped as conditions from STG, PROD, and Pack reflected in the system while the application is being designed.

Starting Provision and Implementation Support for MSP (Managed Service Provider) Implementation and Development

While we worked on the system packs, we also worked on the Development Group's first response to problems and tried having an external contractor operate the routine work. It might not have been necessary for the Platform Group to do this work at the time, but the company was still growing at the time, and we wanted to further contribute to the development group and started supporting it while cooperating with some of the Development Group members and contractors. Now, the MSP is becoming the center of inquiries from business divisions and affiliates, and it has become an important presence.

Enhancing Application Monitoring

Next, we worked on strengthening monitoring. However, the infrastructure monitoring and system design were already almost complete, so we targeted application monitoring.

Starting Log Platform (OpenSearch) Implementation and Implementation Support

Initially, we only provided CloudWatch as a log platform, but when the logs were not stored in JSON format, the logs were separated in chronological order when they were viewed, and it was difficult to analyze them when they were sent from multiple servers. To address this, we built and provided OpenSearch, which is an AWS managed service. At the time, we knew that providing OpenSearch alone would not increase usage, so we also provided the container image of the ECS sidecar (fluentbit), which sends logs to OpenSearch, and added it to the CI/CD template.

Starting APM (Application Performance Management: Prometheus and Grafana) Implementation and Implementation Support

After switching to containers, it became necessary to monitor resources of in-container applications. To address, we are providing APM with AWS Managed Prometheus and Grafana. We also provide a sidecar (Open Telemetry) similarly to the log platform and provide an easy-to-use environment.

• related blog: Collecting application metrics from ECS for Amazon Managed Service for Prometheus

by @sokasanan

Starting Distributed Tracing (X-Ray) Implementation and Implementation Support

We have started providing distributed tracing (X-Ray) as three pillars of monitoring enhancement. This makes it possible to visualize communication between containers and communication to the backend endpoint and DB, and problems can be identified instantly.

Conclusion

After getting through the startup stage, the group has entered a growth period. We are improving our on-boarding process to welcome you after joining the company. If you are interested, please do not hesitate to apply for a casual interview with me.