상냥한 IT 블로그

배경

서비스의 규모가 확장되고, 데이터 저장 및 통신을 클라우드를 통해 하는 요즘, 기존의 방식인 모놀리식과 대비되는 MSA가 대두되고 있다. 하지만 소규모 프로젝트나 대부분의 상황에서는 모놀리식 아키텍쳐도 합리적인 선택이 될 수 있다. 요구사항에 맞지 않는 아키텍쳐 선택은 오버 엔지니어링을 발생시켜 불필요한 작업을 초래할 수 있고 개발자들의 생산성을 저해할 수 있으므로 장단점을 파악한 후 충분히 고려하여 결정해야 할 것이다.

모놀리식 아키텍처 (Monolithic Architecture)

- 전통적인 방식의 아키텍처이다.

- 소프트웨어의 모든 구성요소가 한 프로젝트에 통합 되어 있는 형태이다.
- 모든 프로세스가 긴밀하게 결합되고 단일 서비스로 실행된다. 따라서 애플리케이션의 한 프로세스에 대한 수요가 급증하면 해당 아키텍처 전체를 확장해야 한다. 코드 베이스가 증가하게 되면 모놀리식 애플리케이션의 기능을 추가하거나 개선하기가 더 복잡해진다.

장점

- 소규모 프로젝트에서는 합리적이다.
- 개발, 빌드, 배포, 테스트가 용이하다.

단점

- 어플리케이션 구동시간이 늘어나고 빌드,배포 시간이 길어진다.
- 조그마한 수정사항이 있어도 전체를 다시 빌드하고 배포를 해야한다.
- 많은 양의 코드가 몰려있어 유지보수가 힘들다.
- 일부분의 오류가 전체에 영향을 미친다.
- 기능별로 알맞는 기술, 언어, 프레임워크를 선택하기가 까다롭다.
- scale out이 불가능 하다.

마이크로서비스 아키텍처 (MicroService Architecture)

마이크로서비스 아키텍처는 하나의 큰 애플리케이션을 여러 개의 작은 서비스 유닛으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처를 말한다. 각 마이크로서비스는 상호 통신이 가능하며 이를 통해 전체 서비스를 구성한다. 애플리케이션이 독립적인 구성 요소로 구축되어 각 애플리케이션 프로세스가 서비스로 실행된다. 이러한 서비스는 경량 API를 사용하여 잘 정의된 인터페이스를 통해 통신한다. 서비스는 비즈니스 기능을 위해 구축되며 서비스마다 한 가지 기능을 수행한다. 서비스가 독립적으로 실행되기 때문에 애플리케이션의 특정 기능에 대한 수요를 충족하도록 각각의 서비스를 업데이트, 배포 및 확장할 수 있다.

장점

- 독립적인 서비스로 배포가 빠르고 모놀리식보다 가볍다.
- 서비스별 개별 배포 가능하여 배포 시 전체 서비스의 중단이 없다.
- 각 서비스에 따라 개별적으로 서버를 나눌 수 있어 메모리 및 cpu 관리에 효율적이다.
- 각 서비스가 모듈화 되어있고 모듈끼리 RPC, Message-driven 이용하여 통신하기 때문에 각 서비스의 개발 속도가 증가한다.
- 분리된 서비스로 개발할 수 있기 때문에 서비스마다 가장 적합한 기술을 선택 할 수 있다.
- 서버 및 프로세스 장애 시, 격리 및 복구가 쉬워 장애가 전체 서비스로 확장될 가능성이 적다.

단점

- 각자 배포한 서비스에 대해 다른 서비스와 연계가 잘 되는지 확인해야 한다.
- 서비스 간 호출 시 REST API 사용으로 인한 통신비용, Latency(지연시간)가 증가한다.
- 서비스가 분산되어 있어 트랜잭션 관리, 장애 추적 및 테스트 등이 쉽지 않다.
- 서비스마다 DB가 분리되어 데이터의 조회가 어렵고 데이터의 중복이 발생한다.
- 전체 서비스가 커짐에 따라 복잡도가 기하급수적으로 늘어날 수 있다.

요구사항

1. 데이터베이스 7개 (유저정보테이블, 유저의 체력요인별 종목설정, 전국학교정보, 유저종목점수, 유저종합점수, 측정치점수계산, 게시판)

2. 1인 개발

3. 소규모 프로젝트

해결

소규모 프로젝트이기도 하고 서비스별로 많은 사람이 개발에 관여하는 프로젝트가 아니다보니 MSA를 적용할 필요를 느끼지 못했다. 모놀리식으로 적용하는 것으로 결정했다.

서버 및 프로세스 장애 시 서버의 고가용성(24시간 가동)을 달성하기 위해서, AWS 로드밸런싱 서비스인 AWS ELB(Elastic Load Balancing) 를 이용해서 무중단 서비스를 하면 될 것이다. 개발 완료 후 전체 프로젝트 크기가 1~2GB 내외로 예상되므로, 개발 및 배포 중에 문제 생길 일은 없다고 생각한다.

ELB(Elastic Load Balancing)

ELB(Elastic Load Balancing)란 여러 가용 영역에서 수신되는 애플리케이션 트래픽을 여러 EC2 인스턴스 및 리소스로 분산시켜서 부하를 분산시켜주는 서비스다. ELB는 L4(전송계층, TCP/UDP 등)나 L7(애플리케이션 계층, HTTP 프로토콜 등) 장비를 구입하거나 소프트웨어를 구축하지 않아도 L4/L7 레벨의 부하 분산 기능을 사용할 수 있고 고가용성 서비스를 구축할 수 있다. 로드밸런싱 알고리즘은 라운드로빈 방식을 사용하며, 헬스체크를 통해서 연결된 EC2 인스턴스가 정상적이지 않은 경우 해당 EC2 인스턴스는 트래픽 분배에서 제외시킨다.

출처 : OKKY

누가 칼럼에 글을 게재한 덕분에..

이제 애자일이 뭔지를 내 경험에 입각해 이해하게 되었다.

그동안 애자일을 실시(?)한다는 여러 회사도 다녔고.

비트버킷등 써가면서, 아침에 스탠드업회의 1시간씩 하면서..

그 난리부르스를 했지만 당췌 애자일이 뭔 소린지를 몰랐다.

이건 내가 쪼다라서 그런게 절대 아니라! ㅋㅋ

방어적인 수사로 애자일의 정의를 추상적으로 배배꼬아 이야기를 했기에.

주인없는 애자일이 그 이름만 통일한 채로 무수한 프로듀서들에게서

재창조되어 버렸기에.

그럼 애자일이 뭔지를 19년차 개발자인 내가 2가지로 정의해 보겠다.

1) SW개발이 HW개발과 다른 점은 완성이 없다는 사실.

물질로 만들어진 하드웨어는 내 손을 떠나는 완성이라는 단계가 있다.

물질은 시간의 지배를 받으니 닳고 부서지고. 질량보전의 법칙상 총량의

한계를 가지고. 거리의 제약이 있으니 지구 반대편으로 간 물건을

다시 만나기 어렵다. 그래서 꾸준한 유지보수가 어렵게 된다.

그러나 SW는 애초에 시간, 양, 거리의 한계가 없다.

그러므로 마치 영생하는 생물처럼 끊임없이 발전시키고 개선할 수 있다.

즉, 하드웨어처럼 1차원적 생산 파이프라인이 아니라

주기를 가진 환형 파이프라인이 점점 커지는 생산형태가 필요하다.

현재 페북, 유투브, 구글등 십년이상 장수하는 SW들이

마치 개발의 끝이 없는 듯, 끊임없이 개발력을 투입하고 있다.

하드웨어 제작자들은 대체 개발은 언제 끝나냐며 투덜되겠지만

하나의 SW제품으로 끝없이 돈을 벌고 있는 사실에 놀라게 된다.

즉, SW는 그런 것이다.

끊임없이 개발력에 돈을 쏟아붓고

끊임없이 돈을 버는.

2) 시장에 의해 꼭 필요한 기능만 필요한 시점에 빠르게 만든다.

즉, 제품의 전체 설계를 하지 말라는 거다.

시장과 고객의 요구사항에 따라서 조금씩 기능을 붙여나가고

방향성을 자주 의사타진해서 맞춰 나가라는 이야기다.

개발자 자신도 무엇이 완성될 지 모를 유연한 설계를 하고

시장이 필요한 것을 만들어가며 리팩토링하다 보면

지금은 이름붙여질 수 없는 무언가가 만들어지게 되면

그게 결국 검색엔진이 되거나, 동영상플랫폼이 되거나,

새로운 OS가 되거나, 차세대 브라우저가 되는 것이다.

무언가 생산의 목표를 잡고 시장이 뭐라하건 그것을

만들어 버리는 무식함은 원톱만 살아남는 SW시장에서

판매할 수 없는 의미없는 제품이 된다.

제품을 만들려 하지 말고 기술을 만들어야 한다.

생산을 하려지 말고 생산력 자체를 높이는 노력을 해야 한다.

특정 제품 자체를 오랫동안 만들지 말고

제품을 빨리 만들 수 있는 기술 자체를 오랫동안 만들어야 한다.

결론)

위 2가지 SW생산의 원리를 이해하고 전파하여 SW개발의 방식을

바꾸어 나가자는 새마을운동(?)같은 것이 애자일이라고 생각한다.

1) 완성에 대한 정의를 내리지 마라.

2) 전체 설계란 건 하지 말고 시장이 원하는 기능을 따라 붙여가라.