It's already been 8 months since I joined my first company last June. In this post, I'll cover the detailed process of the server containerization project that I participated in as the main developer for the Inpock Link team starting this year.
If you're considering using various AWS stacks or thinking about building a better server, I hope this post can be of some help!
This post is a more detailed version of an article published on AB-Z's medium. For key decisions and trial-and-error processes, please refer to this link 😃
This project was conducted in the Inpock Link service environment, one of the services provided by AB-Z.
Inpock Link was created with the goal of "bridging the gap between influencers and consumers." It's a service that allows influencers to manage various links on a single page, enabling them to deliver value to their followers and consumers easily and quickly. Influencers can sign up as Inpock Link administrators and add desired links such as market, group purchase, shopping mall links, as well as CS channels and YouTube to their link pages. Visitors can easily access the links promoted by influencers.
The existing Inpock Link was built using AWS services with the server running on EB (ElasticBeanstalk) and the frontend on ECS (Elastic Container Service) for development and maintenance. This is where we faced a concern:
Can't we create a system that allows for faster server scale-out?
This is exactly where our project began.
We called it the Server Containerization project, and its main goals are as follows:
Through server containerization, migrate the server stack to ECS to significantly reduce the time required for auto-scaling. Enable zero-downtime deployment so users won't notice when deployments are in progress. Ensure there are no issues with existing external API usage.
The project lasted about 4 weeks and was divided into the following major phases: Part 1, Use Docker to create Django server and nginx images and push them to ECR. Part 2, Deploy using the built images through tasks, clusters, subnets, Route 53, etc. Part 3, Enable deployment and modification without going through the AWS console using GitHub Actions for CI/CD and CDK for stack deployment.