2017.12.01

'소프트웨어 개발을 가뿐하게'··· 마이크로서비스 이해하기

Lucas Carlson | InfoWorld

지금 수 천, 수 만에 달하는 C++ 명령을 처리해야 한다고 가정해보자. C++가 싫다면, 1970년대 IBM이 개발한 포트란(Fortran)의 ‘변종’인 벡트란(Vectran) 수백 만 줄을 처리한다고 가정하자. 명령에 아무 문제가 없을지라도 항상 문제가 있다. 다른 사람이 피처(기능)를 추가하려 할 때마다 문제가 발생한다. 또한 버그를 고치려 할 때마다 버그가 증가한다. 손을 대지 않아야 한다. 그러면 문제 없이 작동할 것이다.

그런데 혁신에는 애질리티(민첩성)와 속도가 요구된다는 점이 문제이다. 밀레니엄 버그를 걱정할 필요가 없었던 신생 기업들이 문제 많은 오래된 레가시 소프트웨어를 보유한 당신 회사를 가뿐히 압도하고 있다. 투자자들은 ‘넥스트 빅 씽’을 요구한다. 고객들이 대량으로 이탈한다.

이를 해결할 방법은 비대한 애플리케이션 덩어리를 없애는 것이다. 그러나 더 이상 새로운 덩어리를 만들어서는 안 된다. 마이크로 서비스 아키텍처를 이용하면 이런 목표를 달성할 수 있다. ‘큰’ 애플리케이션들을 수평으로 확장할 수 있는 ‘가벼운’ 앱으로 분리해주는 기법이다.



마이크로서비스에 대한 정의
마이크로서비스는 여러 기능을 RESTful API로 느슨하게 연동된 별개의 애플리케이션으로 분리한다. 이베이가 2006년 사용자, 아이템, 계정, 피드백, 트랜젝션, 기타 70여 요소들을 처리하는 별개의 Java Servlet 애플리케이션들을 구현한 것을 예로 들 수 있다. 이 각각의 논리 함수 애플리케이션들이 마이크로서비스다.

각 마이크로서비스는 독립돼 있다. 마이크로서비스는 데이터 계층을 공유하지 않는다. 각자의 데이터베이스와 로드 밸런스를 가지고 있다. 이런 ‘분리’가 마이크로서비스 아키텍처의 핵심 요소다. 마이크로서비스마다 각기 다른 스케일링 기법이 필요하다. 예를 들어, 일부 마이크로서비스는 관계형 데이터베이스를, 또 다른 마이크로서비스는 NoSQL 데이터베이스를 사용한다.

마이크로서비스의 이점
마이크로서비스 아키텍처는 내부 아키텍처가 크고 복잡한 큰 덩어리의 애플리케이션들을 작고 독립적이며, 확장이 가능한 애플리케이션들로 분리시킨다. 따라서 쉽게, 그리고 작게 마이크로서비스를 개발, 업데이트, 배포할 수 있다.

그런데 여기에서 의문이 제기된다. 이런 기능들을 처음부터 하나의 애플리케이션으로 구현하면 안 되는 것일까? 이론적으로 별개의 애플리케이션과 데이터 사일로로 구현해도 큰 문제가 없다는 생각이 들지 모르겠다.

예를 들어 살펴보자. 입찰이 2개인 경매가 있는 상황을 가정하자. 그러나 피드백이 있는 매출은 전체의 약 1/4이다. 입찰 서비스가 피드백 애플리케이션보다 8배 이상 분주하다는 의미다. 이를 하나의 애플리케이션으로 통합하면, 필요보다 더 자주, 더 많은 코드를 실행시키고, 업데이트 해야 한다. 여러 기능 그룹을 별개의 애플리케이션들로 분리하는 것이 합리적인 상황인 셈이다.

또 마이크로서비스 아키텍처를 도입하면, PaaS와 Docker, Linux 콘테이너 등과 연동이 가능해지는 등 여러 보이지 않는 이점과 장점이 있다.

애플리케이션을 마이크로서비스로 구현하면 애플리케이션의 유연성과 확장성이 높아진다. 팀 구축 애플리케이션 프로세스의 확장성도 높아진다. 덩어리 코드의 경우, 한 개 팀 전부가 큰 덩어리 코드를 작업해야 한다. 또 구성원이 서로 업무에 관여해야 한다. 코드의 덩어리이 커지면서 개발 속도가 크게 느려진다.

그러나 마이크로서비스 아키텍처의 경우, 분산된 소규모 개발 팀이 각자 독립적으로 마이크로서비스인 앱을 개발, 변경할 수 있다. 그러면 서비스 업그레이드와 기능 추가가 훨씬 더 용이해진다. 소프트웨어와 개발 프로세스가 모두 민첩해지는 것이다.



마이크로서비스의 도전과제
하지만 모든 아키텍처가 ‘강점’과 ‘약점’을 갖고 있기 마련이다. 장점이 확실한 마이크로서비스 아키텍처도 다루기 힘든 고유의 문제점이 있다. 분산되고 느슨하게 연결된 애플리케이션의 로깅, 모니터링, 테스트, 디버깅 문제가 대표적이다.

2017.12.01

'소프트웨어 개발을 가뿐하게'··· 마이크로서비스 이해하기

Lucas Carlson | InfoWorld

지금 수 천, 수 만에 달하는 C++ 명령을 처리해야 한다고 가정해보자. C++가 싫다면, 1970년대 IBM이 개발한 포트란(Fortran)의 ‘변종’인 벡트란(Vectran) 수백 만 줄을 처리한다고 가정하자. 명령에 아무 문제가 없을지라도 항상 문제가 있다. 다른 사람이 피처(기능)를 추가하려 할 때마다 문제가 발생한다. 또한 버그를 고치려 할 때마다 버그가 증가한다. 손을 대지 않아야 한다. 그러면 문제 없이 작동할 것이다.

그런데 혁신에는 애질리티(민첩성)와 속도가 요구된다는 점이 문제이다. 밀레니엄 버그를 걱정할 필요가 없었던 신생 기업들이 문제 많은 오래된 레가시 소프트웨어를 보유한 당신 회사를 가뿐히 압도하고 있다. 투자자들은 ‘넥스트 빅 씽’을 요구한다. 고객들이 대량으로 이탈한다.

이를 해결할 방법은 비대한 애플리케이션 덩어리를 없애는 것이다. 그러나 더 이상 새로운 덩어리를 만들어서는 안 된다. 마이크로 서비스 아키텍처를 이용하면 이런 목표를 달성할 수 있다. ‘큰’ 애플리케이션들을 수평으로 확장할 수 있는 ‘가벼운’ 앱으로 분리해주는 기법이다.



마이크로서비스에 대한 정의
마이크로서비스는 여러 기능을 RESTful API로 느슨하게 연동된 별개의 애플리케이션으로 분리한다. 이베이가 2006년 사용자, 아이템, 계정, 피드백, 트랜젝션, 기타 70여 요소들을 처리하는 별개의 Java Servlet 애플리케이션들을 구현한 것을 예로 들 수 있다. 이 각각의 논리 함수 애플리케이션들이 마이크로서비스다.

각 마이크로서비스는 독립돼 있다. 마이크로서비스는 데이터 계층을 공유하지 않는다. 각자의 데이터베이스와 로드 밸런스를 가지고 있다. 이런 ‘분리’가 마이크로서비스 아키텍처의 핵심 요소다. 마이크로서비스마다 각기 다른 스케일링 기법이 필요하다. 예를 들어, 일부 마이크로서비스는 관계형 데이터베이스를, 또 다른 마이크로서비스는 NoSQL 데이터베이스를 사용한다.

마이크로서비스의 이점
마이크로서비스 아키텍처는 내부 아키텍처가 크고 복잡한 큰 덩어리의 애플리케이션들을 작고 독립적이며, 확장이 가능한 애플리케이션들로 분리시킨다. 따라서 쉽게, 그리고 작게 마이크로서비스를 개발, 업데이트, 배포할 수 있다.

그런데 여기에서 의문이 제기된다. 이런 기능들을 처음부터 하나의 애플리케이션으로 구현하면 안 되는 것일까? 이론적으로 별개의 애플리케이션과 데이터 사일로로 구현해도 큰 문제가 없다는 생각이 들지 모르겠다.

예를 들어 살펴보자. 입찰이 2개인 경매가 있는 상황을 가정하자. 그러나 피드백이 있는 매출은 전체의 약 1/4이다. 입찰 서비스가 피드백 애플리케이션보다 8배 이상 분주하다는 의미다. 이를 하나의 애플리케이션으로 통합하면, 필요보다 더 자주, 더 많은 코드를 실행시키고, 업데이트 해야 한다. 여러 기능 그룹을 별개의 애플리케이션들로 분리하는 것이 합리적인 상황인 셈이다.

또 마이크로서비스 아키텍처를 도입하면, PaaS와 Docker, Linux 콘테이너 등과 연동이 가능해지는 등 여러 보이지 않는 이점과 장점이 있다.

애플리케이션을 마이크로서비스로 구현하면 애플리케이션의 유연성과 확장성이 높아진다. 팀 구축 애플리케이션 프로세스의 확장성도 높아진다. 덩어리 코드의 경우, 한 개 팀 전부가 큰 덩어리 코드를 작업해야 한다. 또 구성원이 서로 업무에 관여해야 한다. 코드의 덩어리이 커지면서 개발 속도가 크게 느려진다.

그러나 마이크로서비스 아키텍처의 경우, 분산된 소규모 개발 팀이 각자 독립적으로 마이크로서비스인 앱을 개발, 변경할 수 있다. 그러면 서비스 업그레이드와 기능 추가가 훨씬 더 용이해진다. 소프트웨어와 개발 프로세스가 모두 민첩해지는 것이다.



마이크로서비스의 도전과제
하지만 모든 아키텍처가 ‘강점’과 ‘약점’을 갖고 있기 마련이다. 장점이 확실한 마이크로서비스 아키텍처도 다루기 힘든 고유의 문제점이 있다. 분산되고 느슨하게 연결된 애플리케이션의 로깅, 모니터링, 테스트, 디버깅 문제가 대표적이다.

X