MSA Project (1)

이번에는 MSA 에 대해서 작성해보려고 한다.
작년에 회사에서 MSA 프로젝트에 참여했다. 아주 재밌고 좋은 경험이었다.
그래서 정리를 해야지 라고 마음먹었지만 이제서야 하게 되었다. 이번에라도 잘 작성해보자 !

---

아래와 같이 정리하고자 한다.

1. MSA 란 무엇인가?
2. 왜 MSA 프로젝트를 하게 되었나?  
3. 프로젝트 과정
4. MSA의 장점과 단점
5. 앞으로 해야 할 것

1. MSA 란 ?

MSA 는 Micro Service Architecture 의 약자이다.
Micro 는 그리스어로 작은 이라는 의미라고 한다. 단어 그대로 기능(서비스) 또는 배포 단위로 잘게 쪼개서 만든 구조를 뜻한다.
이렇게 여러 개로 작게 나뉜 서비스가 모여서 큰 서비스가 된다.
다음은 왜 우리 회사는 MSA 프로젝트를 하게 되었는지, 나는 왜 참여했는지 알아보자.

2. 왜 우리 회사는 MSA 프로젝트를 했는가 ?

우리 회사는 B2C, B2B 서비스를 모두 하고 있다.
그 중에서 메인 서비스는 php를 이용한 모놀리식으로 구성되어 있다.
모두가 알 듯이 모놀리식 구성이기 때문에 서비스가 거대하고 매우 복잡하며, 한 곳에서 에러가 발생할 경우 다른 곳까지 영향을 받는다. 이런 이유로 회사의 한 분이 전부터 MSA에 대해 준비를 하고 계셨고 마침 시작하게 되었다.
평소 이론으로만 알고 있었는데 직접 개발하며 값진 경험을 할 수 있게 되었다.

3. 프로젝트 과정

먼저 이 프로젝트에서 사용하는 기술 스택은 메시지 발행을 위해 kafka를 사용했고, 트레이싱을 위해 zipkin, slueth 를 사용했다. 프로젝트 시작 당시에는 가상화(xen) 서버에서 진행하였고 이 프로젝트 이후 기존, 신규 프로젝트들을 클라우드 환경으로 전환하는 작업을 하고 있다.

프로젝트 기간은 8월부터 10월까지 약 2달 동안 진행했다.

처음 시작은 작은 범위의 기능 수정부터 진행하게 되었다.
프로젝트에 참여하는 인원이 많지 않고 모두 MSA가 처음이기 때문에 맛보기(?) 같은 느낌으로 진행되었다.
기존 레거시의 소스를 분석하고 회의를 통해 빠진 것은 없는지, 리스크가 있는지, 더 좋은 방향이 있는지 등을 확인했다.
작은 범위의 기능이었지만 결코 간단하지 않았다. 레거시 코드를 분석하며 MSA 로 전환이 가능한 부분과 불가능한 부분을 파악하고 이를 어떻게 해결해 나갈지 먼저 파악해 나갔다.

이렇게 MSA로 전환이 불가능한 부분 때문에 일부는 스케줄러를 사용하여 메시지를 발행하고 있다. 그래서 완전한 이벤트 기반이 아니다. 추후, 완전한 이벤트 기반으로 이루어 질 수 있도록 내가 무엇을 할 수 있는지 고민해야겠다.

나는 클라이언트에서 처리해야 할 부분들을 팀원과 같이 확인했다.
내가 맡은 부분은 대상 조회부터 메시지를 발행해 다음 프로세스로 넘어갈 수 있도록 하는 기능을 담당했다.
회사 프로세스이기도 하고 워낙 작은 범위의 기능이기 때문에 자세히 설명을 할 수 없고 간단하게 프로세스는 이렇다.

해당 프로젝트가 끝나고 메인 기능을 MSA 로 전환하는 작업을 진행했다. 이 프로젝트 경험을 작성할 때 조금 더 자세히 작성할 수 있을 것 같다.

그 전에 지금까지 사용했던 기술 스택과 관련한 내용을 글로 작성해서 개념을 확실하게 익히고 가야겠다.
글로 정리해두지 않으니 자꾸 헷갈리는 것 같다.

4. MSA의 장점과 단점

다음은 나의 경험을 기반으로 MSA의 장점과 단점에 대해서 작성해보려고 한다.

장점

1. 독립적으로 실행이 가능한 형태이기 때문에 모놀리식 구성처럼 한 곳에서 장애가 발생했다고 멈추지 않는다.
2. 프로세스가 잘게 쪼개져 있기 때문에 업무를 익힐 때 좀 더 손쉽게 이해할 수 있다.
3. 장애가 발생했을 때 어느 프로세스에서 발생했는 지 명확하게 알 수 있다.
4. 서비스에 한정적인 프로세스가 아니라면 다른 곳에서도 사용할 수 있다.

단점

1. 기능 단위로 잘게 쪼개져 있기 때문에 관리해야 할 포인트가 많다.
2. 서버든, 담당자든 리소스가 많이 필요하다.
3. 새로운 기술들을 익혀야 한다.

내가 아는 일반적인 MSA의 장점이 서비스 한 곳에서 장애가 발생했다고 전체로 번지지 않는다는 것으로 알고 있다.
하지만 직접 경험해보니 장점 1에 대해선 의문이 있다.

모든 서비스들은 긴밀하게 연결 되어있다. 그렇기 때문에 한 곳에서 장애가 발생하면 뒤에서. 대기하는 것들이 밀리게 되고 결국 전체 장애로 번지게 되었다. 이 부분은 잘못 설계된 것인가? 이 부분에 대해서 조금 더 학습이 필요할 것 같다.

그리고 우리 회사는 잘게 쪼개진 서비스 별로 각 담당자가 배정되어 있지 않다.
현재는 만든 사람이 담당을 하고 있다. (회사 규모와 엄청나게 큰 범위의 기능이 아니기 때문에 어쩔 수 없는)
그래서 각 서비스 별 프로세스를 정확하게 익히지 않는다면 장점 3, 4가 모두 단점이 될 수 있다.
현재도 나는 프로세스를 더 정확하게 이해하기 위해 노력하고 있다. (퇴사자로 인해 에이전트까지 담당하게 된 ㅜㅜ)

5. 앞으로 해야 할 것

위에서도 작성했지만 완전한 이벤트 기반으로 실행하도록 프로젝트를 더 진행시켜야 할 것 같다.
최근 MSA 프로젝트를 진행하시던 분이 퇴사를 하셨다. 계속해서 앞으로 이런 도전적인 프로젝트를 이끌어야 할 것이다.
그게 내가 될 수 있도록 많은 노력이 필요하겠다.