[FINDA] MSA를 위한 Kubernetes 세팅과 CI/CD Pipeline 구성, 그리고 Monitoring 시스템 구축 — 1

Published in

finda 기술 블로그

6 min readFeb 24, 2020

Overview

FINDA의 마이크로 서비스 아키텍쳐(MSA)를 위하여 구성한 쿠버네티스 환경과 개발의 프로세스 개선을 위해 구성한 DevOps 환경, 그리고 FINDA의 전반적인 서비스 모니터링을 위해 구성한 내용을 정리해 보았습니다.

기존 핀다의 인프라 스트럭쳐는 전통적인 모놀리틱 아키텍쳐에 로드밸런서를 앞단에 위치시킨 방식으로 운영하고 있었습니다. 하지만 점차 규모가 커져가고 다양한 기능들이 늘어남에 따라 서비스를 좀 더 슬림하고 확장성있게 개발하고 운영해야 한다는 고민이 생겼습니다.

따라서 우리는 마이크로 서비스 아키텍쳐(MSA)를 고려하게 되었습니다.

MSA란?

MSA의 정의와 목적, 그리고 핀다가 MSA를 채택한 이유

MSA(Micro Services Architecture)란, 소프트웨어를 구축하기 위한 아키텍쳐이자 하나의 접근 방식으로, 어플리케이션을 상호 독립적인 최소 구성 요소로 분할하는 방법입니다. 간단하게 말하자면 하나의 모놀리틱한 어플리케이션을 핵심 기능으로 세분화한 것 이라고 보시면 될 것 같습니다.

그렇다면 왜 MSA로 개발할까요? 심플하게 하나의 어플리케이션에 그냥 모든 기능을 다 담당하게 하면 안될까요?

결론적으로 말씀드리면 그래도 됩니다. 이건 회사마다 지향하고자 하는 개발 스타일에 따라 갈릴 것 같습니다.

하지만 모놀리틱 아키텍쳐는 아래와 같은 단점이 있습니다.

하나의 기능을 추가하거나 수정하면 전체 시스템을 재배포 해야 한다.(핫픽스도 마찬가지)
개발을 하면 할수록 어플리케이션이 점점 무거워진다.
한 부분의 기능에 장애가 발생하면 전체 시스템이 마비된다.

위의 이유로 핀다에서는 MSA를 고려하게 되었습니다.

그렇다면 MSA는 모놀리틱 아키텍쳐와 달리 어떤 장점이 있을까요?

서비스들이 상호 독립적이기 때문에 유지보수 및 배포하기 간편하다.
서비스에 장애가 발생하면 각 서비스마다 독립적으로 발생하는 것이기 때문에 전체 시스템이 다운 되지 않는다.
개발자들에게 담당 서비스를 나누어 주기 편리하고 개발자는 각자 자신이 편한 언어로 개발할 수 있다(Polyglot).
새로운 기능이 필요하면 새로운 서비스를 만들어 배포하면 되기 때문에 확장성이 용이하다.

그래서 핀다는 기존의 모놀리틱한 어플리케이션의 핵심 기능을 나누어 MSA 구조로 변경하기로 했습니다.

하지만 그냥 나누기만 해서는 운영 및 관리 측면에서 공수가 더 늘어날 것이라는 새로운 고민거리가 생겼습니다.

왜 공수가 더 늘어날까요? 위에서 핀다가 MSA를 채택한 이유에서는 고민거리가 하나도 없을 것 같은데 말이죠..

Kubernetes

쿠버네티스를 도입한 목적 & 환경 구성 방법

핀다가 MSA를 채택함에 있어서 생긴 고민 거리의 이유는 바로 MSA 자체에 있었습니다.

즉, 하나였던 어플리케이션을 여러개의 어플리케이션으로 나누는 것이기 때문에 그만큼 운영이나 배포, 모니터링에 대한 관리 포인트도 많아진 것이죠.

이렇듯 MSA를 채택 함에 있어서 오는 수많은 관리 포인트를 손쉽게 관리하기 위해 우리는 쿠버네티스(Kubernetes)를 도입하기로 결정했습니다. 독립적인 여러 서비스를 개별적으로 Docker 컨테이너로 배포하고 이를 운영 적인 부분에서 쉽게 관리하자는 목적이었습니다.