May 10, 2018 10 min to read

서버리스에 대해 알아보기 전에...(1/2)

monolithic만 물고 빨면 생산성 뽕맞고 행복할줄 알았지... 하지만 웬걸? 운영올라가고 트래픽 몰리니까 불꽃놀이마냥 클러스터링 돌린 인스턴스 빵빵터지네 ㅎㅎㅎ 타마야~~~

주의

이 블로그의 내용은 대단히 주관적인 내용이 가득합니다. 그리고 양질의 글을 읽었지만 똥글이 나오는건 제 미숙함 때문입니다. 그럼에도 불구하고 피드백 많이 주신다면 자세히 조사하여 반영하도록 하겠습니다. 또한.. 가능한 링크로 올려놓은 자료들은 반드시 열어보시기 바랍니다. 분명 도움이 될 것입니다. (- -)(_ _)

이 포스팅에서 중요한 헷갈리는 용어들

서버리스, 서버리스 플랫폼, 서버리스 아키텍쳐, 서버리스 패턴, 마이크로 서비스, 마이크로 서비스 아키텍쳐

위의 6가지 단어는 전부 다른 단어이며, 동의어는 없다.

서버리스: 서버리스는 BaaS, FaaS 두 컨셉을 통틀어 말하며 AWS의 lambda나 functions같은 서비스 들 전부를 지칭하는 말이기도 하다.
서버리스 플랫폼: 실제로 이용할 수 있는 서버리스 서비스를 말한다. (ex: AWS lambda)
서버리스 아키텍쳐: 서버리스 서비스를 근간으로 하는 서버 아키텍쳐를 말한다.
서버리스 패턴: 서버리스 서비스를 베이스로 하는 아키텍쳐에서 best practice같은 정형화된 구조를 서버리스 패턴이라고 한다.
마이크로 서비스: 마이크로 서비스는 서비스 지향 아키텍쳐(SOA: Service Oriented Architecture)의 도메인, 기능별로 분리한 단위 보다 더 작은 최소 단위이다. 어떤것들은 기능단위로 빠지기도 하고, 최소 함수 및 로직 단위로 하나의 작은 서버를 하기도 한다.
마이크로 서비스 아키텍쳐: 마이크로 서비스를 베이스로하는 서버 아키텍쳐이다.

주의: 서버리스라는 단어는 마이크로 서비스의 이론을 구현한 구현체(서비스)이지만 그렇다고 서버리스가 마이크로 서비스가 서버리스 인것은 아니다.

위 글에 대한 용어의 정의는 Quara의 내용을 참고해서 멋대로 정의를 내렸으며, 만약 이에 대한 정의가 틀리거나, 올바르지 않거나, 자신이 생각하는 다른 정의가 있다면 부디 댓글로 남겨주세요! 해당 내용에 대해 조사하여 반영하겠습니다.

5초만에 끝내는 소프트웨어 아키텍쳐의 역사

5초만에 아키텍쳐의 역사를 어떻게 끝내…

5분이라는 시간으로 software들의 아키텍쳐를 둘러보고 싶다면? - 10가지 아키텍쳐 패턴 비교분석 )

서버리스(Serverless)?

서버리스는 단어만 놓고 보자면, 서비스를 하기위해서는 서버는 필수 불가결이다. 서버가 없다는 말은 말도 안된다. 하지만 이 말은 물리적으로 따져보았을때의 이야기이다. 서버, 없을수는 없다. 하지만 서버리스의 용어에서 less는 물리적으로 서버가 존재하지 않는것이 아닌 논리적으로 서버가 없다는 말이다. 즉 서비스 운영자는 서버를 소유하지 않고서 서비스를 운영할 수 있기 때문에 serverless라는 네이밍이 붙었다.

물론 AWS EC2 호스팅 역시 물리적으로 소유한것은 아니지만 EC2에서 컴퓨팅 자원을 자유롭게 이용할 수 있으며, 클라우드 플랫폼 서비스에서 제공하는 서비스들을 EC2 위에서 직접 구현하여 만들수 있을 정도로 자유도가 높다.

그리고 AWS EC2 호스팅을 할 때에 요금은 해당 자원을 빌려간 시간 만큼 돈을 지불한다. 마치 렌탈(소유)한 것 처럼 말이다. 하지만 서버리스는(AWS의 Lambda를 기준으로), 확장성은 높지만 EC2만큼 높은 자유도가 주어지지 않으며, 빌려간 시간이 아닌 사용한 시간만큼 돈을 지불해야한다. 렌탈의 개념이 아닌 이용, 사용 이 더 가까울 것 이다.

즉, 서버리스라는 단어는 서버를 소유하지 않기때문에 서버리스라고 한다. 이렇게 정의를 내리면 그나마 조금은 서버리스라는 정의에 납득할 수 있지 않을까 싶다.

그렇다면 서버를 소유하지 않고 어떻게 서버를 운영할 수 있지..?

서버리스 형태의 서비스 운영은 스크립트파일을 클라우드 제공업체(Google Cloud Platform, AWS, MS Azure)의 컴퓨터에 올리는 방식으로 서비스를 배포할 수 있으며, 서버리스를 제공하는 회사의 컨트롤러 콘솔 화면에서 각종 설정을 제어하면서 운영을 할 수 있다.

서버리스를 이용하려면 어떻게 해야할까?

서버리스는 서버의 소유자가 서비스를 운영하는 사람이 아닌 회사이다. 그렇기 때문에 서버리스를 이용하고자 한다면, 서버리스를 제공하는 회사의 서비스로써 이용해야한다. 그리고 그것에 대한 관리역시 그 회사가 제공하는 서비스를 이용해야한다. AWS의 경우는 web console 또는 aws-cli 프로그램을 이용할 수 있다.(다른 회사의 서비스들은 어떻게 제공되는지 잘 모르겠다.)

이러한 서버리스 서비스의 제공형태를 바로 BaaS(Backend as a Service), 또는 FaaS(Function as a Service)라고 한다. 대표적으로 BaaS 진영에는 대표적으로 Firebase가 있으며, FaaS 진영에는 GCP의 Functions, AWS Lambda가 있다.

사실 BaaS인가, FaaS인가 용어가 중요할까? 요즘은 많은 ‘as a Service’ 라는 마케팅용어를 달고있기 때문에 앞에 명사를 무엇으로 다느냐 그럴듯하기 떄문에 이것에 대해서 자세히 이야기 하지는 않으려고 한다. 나도 하나 마케팅용어를 만들어보자면…

서비스가 아니었던 단어를 붙여야 하는것 같다.

Ex) Chat-bot as a Service, Machine Learning as a Service, Orange as a Service

방금 대충 떠올려본 Machine Learning as a Service검색해보니 Firebase에서 제공하고 있었다. 이건 뭐… 막 가져다 붙이면 다 전문용어다. 젠장. 난 as a Service에 대해 대학교 기말고사 문제로 나온다 해서 열심히 공부한적 있었는데, 무엇하러 자세히 공부했지. 에이 쓸대없어라. 에잇!

서버리스와 MSA(Micro Service Architecture)

서버리스의 아키텍쳐는 마이크로 서비스 아키텍쳐(MSA: Micro Service Architecture)이다. 앞으로 마이크로 서비스 아키텍쳐를 MSA라 부르겠다)

MSA는 마틴파울러[Martin Fowler]를 빼고 이야기 할 수 없다. 마틴파울러는 MSA에 대한 개념을 정리하였으며, MSA를 엔터프라이즈 환경에서 성공적으로 도입한 사례와 특징들에 대해 공유한 사람이다. 마틴 파울러가 최초로 공유한 글에 대한 번역본은Channy’s Blog 님의 블로그에 있으며 원본에도 ‘한국어 번역본’이라며 공유 되어있다. MSA에 대한 자세한 내용은 여기에서 확인 할 수 있다.

많은 사람들이 혼동을 느끼는 부분이지만, MSA는 AWS의 lambda나 Azure 의 functions가 MSA가 아니다. 서버리스 아키텍쳐가 MSA를 따르고 있는 것이지 MSA가 서버리스 아키텍쳐를 위한 것은 아니다. 둘은 관계가 없는것은 아니지만 서로 같은것은 아니다. 이는 앞으로 설명할 MSA에 대한 장점과 단점을 설명할때에 lambda의 단점으로 인식하면 곤란하다는 이야기 이다. :D

Monolithic Architecture 에 대해 알아보자

띠용? MSA에 대해 설명할 줄 알았는데, 갑자기 Monolithic Architecture 이라구요?

사실, MSA가 나오기 까지, 어떤 방식으로 서비스를 했으며, 어떤 문제를 해결하기위해 이런 아키텍쳐가 나왔는지에 대해 이야기할 필요가 있다. 패턴이나 이론을 즐기기위해서는 그 이전까지의 불편함을 진득하니 맛봐야한다. 하지만 우린 맛본경험이 아마 적을것이기 때문에 전래동화 읽듯이 한번정도는 읽어보자. 도전과 좌절의 경험담은 생각보다 재미있다.

그렇기에, 우리는 **점프를 읽지**.

Monolithic Architecture

이 그림의 제목은? (힌트: 서버)[이용: 나의 히어로 아카데미아]

Monolithic Architecture, 그림에 써져 있듯이 one for all. 하나의 서버, 하나의 프로그램으로 모든 기능을 커버하겠다!

Monolithic Architecture 스타일은 기존의 전통적인 웹 시스템 개발 스타일(2-Tier 또는 Server-Client Architecture)로, 하나의 애플리케이션 내에 모든 로직들이 들어가 있는 말 그대로 아키텍쳐 계의 “원 포 올(One for all)” 이다. 예를 들어 온라인 쇼핑몰 웹 애플리케이션이 있을 때, 그 웹 애플리케이션 소스를 이루는 프로젝트 단위는 하나이고, 사용자 관리부터 상품의 주문관리까지 처리하는 모든 컴포넌트들과 UX로직까지 하나의 포장되서 들어가는 구조이다.

Monolithic Architecture 의 장점

가장 전통적인 개발 방법이지만, 그래도 이것에 장점도 있다. 생산성이 가장 빠른 아키텍쳐이다. Waterfall 방법론도 가장 전통적인 개발 방법론이지만, 이것 역시 생산성이 가장 빠른 개발방법론이다.

monolitic + waterfall 생산성에 뽕맞을 수 있다!

작은 규모에서는 빠른 프로토타입 실행, 그리고 생산성을 가져갈 수 있다.
배포할때에는 하나의 서버만 변경하면 되기 때문에 심플하게 재 배포할 수 있다.
call by reference에 의한 컴포넌트간 호출시 성능에 제약이 덜함
트트렌젝션 관리가 용이하다.
운영 관리가 용이하다.

Monolithic Architecture 의 문제점(주의 해야할 점)

생산성에 뽕맞을 수 있다면서! 어떤 문제점이 있길래!? 생산성에서는 뽕맞을 수 있지만, Monolithic 아키텍쳐인 상황에서 대형 시스템 개발시에 몇 가지 문제점을 갖는다.

Monolithic Architecture의 경우 작은 크기의 애플리케이션에서는 용이 하지만, 규모가 큰 애플리케이션에서는 불리한 점이 많다.

규모가 클 경우에 빌드 및 배포 시간 그리고 서버의 기동 시간까지 오래걸린다.
한 두 사람의 실수는 전체 시스템 빌드의 실패를 유발한다. (Java같은 컴파일 언어 시에) 때문에 협업개발하기가 쉽지않다.
구조가 커지면 커질수록 해당 프로젝트의 소스코드를 수정하기위해 전체 프로젝트 구조와 로직을 숙지하기 까지 러닝커브시간이 깊어진다.
컴포넌트 재 배포시, 수정된 컴포넌트 뿐만 아니라, 전체 어플리케이션을 재 컴파일 하기 때문에 잦은 배포가 있는 시스템의 경우 불리하다. 빌드, 구동 시간까지 오래걸린다.
예를들어 Java 언어 플랫폼에서, 비동기 입출력을 요구하는 스펙에 맞추는 기능을 개발했을때에, 전체 시스템이 꺼지지 않기위한 복잡한 예외처리를 요구한다.(이 경우 node.js같은 언어가 더 적합하지만..)

Monolithic Architecture로 엔터프라이즈 서비스를 운영하게 될 경우 발생한 문제점들은 실로 크게 다가왔다.

개발자를 새로 뽑았는데 소스코드를 만질 때 까지 문서를 아무리 읽어도 최소 한 달이 걸렸다거나, 배포 마감날이 점점 다가와서 급박하게 테스트 안돌리고 소스코드 커밋하고 머지 받아주다 보니 추가한 라이브러리에서 의존성문제로 컴파일이 되지 않거나, 불가피하게 에러 메시지를 서버에서 직접 만들어서 건내주는데 거기에 오타가 섞여있다거나, 등등…. 해당 코드를 유지 보수하기 위해 뛰어들었지만, 내부적으로 결합도가 높은 모듈을 수정하게 될 경우 테스트 지옥으로 몇 주, 몇 달 동안 테스트를 계속해야하는 상황이 오거나,

Monolithic Architecture는 초기 생산성을 선물로 주었지만 나중에는 아슬아슬한 피사에 사탑으로 변하게 되었다.

서비스 지향 아키텍쳐 SOA Service Oriented Architecture

이 블로그 포스트에서는 서비스 지향 아키텍쳐를 SOA라고 부르겠다.

하나만 실수를해도 전체가 터져버리거나, 특정 기능에 사람이 몰려서 전체 서버가 다운이 되어버린다거나.. 더 이상.. 운영및 관리의 고통을 느꼇다가는 성불할지도 모른다는 생각을 했을것이다. 그렇기 때문에 개발자들은 Monolithic 서버를 분리해야할 필요성을 느끼게 되었다.

기껏 비싼돈 들여 좋은 광고 만들었는데, 그 훌륭한 광고때문에 예상치 못한 트레픽이 몰려와도 터지지 않도록… 그리고 몰린페이지가 이벤트인데… 그런 이벤트 페이지때문에 기존 서비스가 터져버리는 일은 없도록…

Monolithic으로 구현된 서버를 분리하는 기준은 서비스의 도메인, 입출력에 대한 처리 그리고 자원에 따라 Monolithic Architecture을 분리하였다. 이러한 아키텍쳐를 SOA라고 한다. SOA에 따라서 분리된 서버는 비지니스 개념적으로 캡슐화되어 서비스를 하게 되었다. 그렇게 일단락 문제점들에 대해 해결이 되었다.

그렇다면 Service Oriented Architecture, SOA는 무엇일까? 2004년 IT업계에서 주목받기 시작한 아키텍쳐이며, 아래에 두 유명한 개발자들 정의는 다음과 같다.

토마스 얼의 SOA에 대한 정의

SOA는 공개, 기민성, 확장, 연합, 자립적 요소들로 구성된 조합가능한 아키텍처이며 서비스 품질, 다양한 벤더, 상호 운영성, 서비스 발견 그리고 잠재적으로 재사용 가능한 서비스들이 웹서비스로 구현된다. SOA는 비지니스 로직과 기술을 추상화하여, 이 도메인 간에 느슨한 결합을 유도한다.

SOA는 과거 플랫폼의 진화물로서 전통적인 아키텍처의 특징들을 고스란히 가지고 있으며, 명확한 원칙을 가지고 SOE를 지원하며 서비스 지향을 촉진한다. SOA는 엔터프라이즈 환경을 이상적으로는 표준화하지만, 치밀한 사전 계획에 의한 이전 필요성과 현재도 진화하고 있는 기술에 대한 지원만이 이러한 목적을 달성할 수 있다.
W3C의 Web Service Architecture Working Group에서 활동하고 있는 Hao He 박사의 SOA에 대한 정의

상호 작동하는 시스템 사이를 느슨하게 연결하려는 목적을 가진 아키텍처

중요한것은 분리된 서버(서비스)간의 느슨한 결합이다. 이 느슨한 결합이 키워드인 SOA는 지금 까지 나온 아키텍쳐들 중 가장 오래되었으며, 현재까지도 이어져 사용중인 아키텍쳐이다. 그리고 이에 따른 자료들과 포스팅글들이 많다. 아직은 우리들의 엔터프라이즈 서비스는 SOA에 머물러 있으며, 그리고 계속 발전중에 있다.

마이크로 서비스 아키텍쳐

우리들은 아직 SOA에 머물러 있다면서 Micro Service Architecture는 무엇?

라는 의문이 들것이다. 엄밀히 말하면 MSA는 SOA의 Next Step이 아닌 단지 추상적 확장의 개념이다. MSA는 2014년 부터 IT업계에서 알려지기 시작했다. 아키텍쳐의 사상은 SOA에 근간을 두고 있으며, 대용량 웹 서비스 개발에 맞는 구조로 사상이 경량화가 된 버전이다. 이는 대규모 웹 개발팀의 조직 구조에 맞도록 변형된 아키텍쳐이다.

독자: “응? 응!!!!!!!!?????? 내가 lambda를 쓰려고 하는건 대규모 웹 개발팀 조직이라 그런게 아닌데?!”

DrakeJin: “위에서도 언급했지만 serverless !== MSA입니다. 하지만, 서로 연관은 있습니다.”

아. 조금 웃기지만 마이크로서비스 아키텍쳐 스타일에 대한 이렇다 할 정확한 정의는 없다고 한다.(from MSA를 확산시킨 마틴 파울러 옹. 아직 없는것인지, 아니면 정말 없는것인지…..)

대신에 MSA에 대한 일반적인 특징을 나열해볼 수는 있다.

MSA의 특징 및 장점

컴포넌트(서비스)간의 의존성이 없이 REST API와 같은 표준 인터페이스로 그 기능을 외부로 제공한다.
서비스의 경계는 word 또는 domain(업무)의 경계를 따른다. RESTful의 URI 정의도 좋은 예가 된다.
배포구조 관점에서는 각각의 컴포넌트(서비스)는 독립된 서버로 타 컴포넌트와 의존성 없이 배포된다.
서비스가 분리되어서 운영됨과 동시에 데이터베이스도 분리해서 독립된 데이터베이스를 갖는다.
MSA에서 가장 중요한 컴포넌트중에 하나인 API Gateway. 프록시 서버 처럼 모든 api에 대한 end point를 통합하고, 추가적인 기능을 미들웨어로써 덧붙일 수 있다.
복수의 컴포넌트에서 필요한 공통의 기능에 대한 처리 용이(로깅, 인증 등)
확장성이 좋다.
여러 언어로 개발해도 문제가 되지 않는다. Polyglot

MSA의 단점(문제점)

컴포넌트가 분리되어있고 분리되어있는 컴포넌트는 독립된 DB를 갖고 있기 때문에 트랜젝션 처리를 해야할 경우, 독립된 컴포넌트끼리 RPC 통신으로 수행해야함으로 성능상 문제를 야기할 수 있다. (이 문제는 SOA때 부터 존재해왔다)
복수개의 컴포넌트가 공통으로 필요한 라이브러리나 모듈이 존재하게 될 경우, 그만한 메모리 사용량이 늘어나게 되고, 그것을 sync하기위한 전략이 필요함.
복수개의 컴포넌트에 맞는 환경을 구축해야하기때문에, 인프라에 대한 설계 및 운영을 개발자가 직접 담당해야한다.
해당 컴포넌트(서비스, 서버)를 개발하던 개발자가 퇴사하면, 이후의 개발자는 새로 만들거나 해당 컴포넌트를 분석해야한다.(쓸 수 있을때 까지)

한장으로 정리하는 이 포스팅의 결론

하. 힘들다.

솔직히 여기까지 왔으면 진짜 장한것이다. 고작 lambda 한번 나도 만져보자고, 모노리딕 아키텍쳐부터 SOA그리고 MSA까지 달려왔는데.. 너무 과했나 라는 생각이 든다. 하지만 다음장은 드디어 대망의 lambda. 매우 기대중이다. 메우.

무엇보다 중요한 SOA와 MSA에 대한 내용은 정말 많이 생략했는데, 이 부분은 아키텍쳐에 대해 궁금한게 있다면 참고자료를 반드시 열람하길 바란다.

후기

“아아아아!! 확장성에 취한다아아!!!

해도 됩니까? 해도 됩니까? 폴리글랏 이유 없이 질러도 서비스 돌아가는거 확실합니까아??”