몇 년 전, 구글은 클라우드 제품 홍보 방식을 두고 고민을 거듭했다. 2017년 당시 필자는 구글이 일반 기업이 ‘구글처럼 운영’할 수 있도록 지원해야 한다고 제안했다. 그러나 한 구글 클라우드 제품 담당 고위 임원과의 대화에서 구글이 이 접근 방식을 배제했다는 사실을 알게 됐다. 이유가 무엇일까? 주류 기업의 요구사항이 구글과 달랐을 수도 있고, 구글처럼 하라는 말이 오히려 기업에 지레 겁을 먹게 할 것이라고 생각했을 수도 있다.

일반 기업의 IT 부서에서 일하는 보통 사람들(결국 모든 사람이라는 뜻)이 걱정할 필요 없다. 어차피 이제 구글이 하는 많은 일이 일반 기업의 IT 요구사항과는 맞지 않기 때문이다.

AWS 엔지니어이자 아파치 HTTP 서버를 만든 사람 중 한 명인 콤 맥카타이는 트위터에서 ‘아마존, 구글, 마이크로소프트, 페이스북이 하고 있지만 다른 모든 기업에는 맞지 않는 기술의 예’가 무엇일지를 물었다. 이 질문에 대해 과도한 업타임 보장, 사이트 안정성 엔지니어링, 마이크로서비스, 모노리포 등 여러 유익한 답이 나왔다.

과도한 업타임 보장

피트 엘크는 “99.999%, 또는 그 이상의 가용성 보장은 FAANG으로 불리는 페이스북, 아마존, 애플, 넷플릭스, 구글만한 규모가 아니라면 의료와 911 콜센터 정도를 제외하고 필요한 분야가 없고 ROI도 맞추지 못할 것”이라고 말했다.

필자도 여러 신생 기업과 어도비에서(어도비의 서비스 수준 보장 수치는 99.999%까지는 아니지만 필요 이상으로 높은 경향이 있음) 직접 경험해서 알고 있다. 멀티 플레이어 게임이 다운된다면 문제가 생기지 않을까? 괜찮다. 오피스 365가 몇 분, 심지어 몇시간 동안 다운되면 문제가 크지 않을까?아니, 괜찮다.

사이트 안정성 엔지니어링(Site reliability engineering)

데브옵스보다 먼저 나왔지만 조금 비슷한 면이 있는 SRE(Site reliability engineering, 맥카타이의 질문에 대한 답변에 여러 차례 언급됨)는 2003년에 구글에서 엔지니어링과 운영을 혼합하기 위한 목적으로 고안했다. SRE의 핵심 원칙 가이드는 다음과 같다.

• 위험 감수

• 서비스 수준 목표(SLO) 활용

• 단순 작업 제거

• 분산 시스템 모니터링

• 자동화를 활용하고 단순함을 수용

구글 SRE를 개발한 벤 트레이노어는 이렇게도 설명했다.

“SRE는 전통적으로 운영 팀이 해온 작업을 소프트웨어 전문 지식을 갖춘 엔지니어를 통해 수행하는 것이며, 이러한 엔지니어가 본질적으로 사람의 노동을 자동화로 대체하려는 성향이 있거나 그러한 능력이 있다는 사실에 의존하는 방식이다. 일반적으로 SRE 팀은 가용성, 지연, 성능, 효율성, 변화 관리, 모니터링, 비상 대응, 용량 계획을 담당한다.”

SRE는 업무 시간의 상당부분을 자동화에 쓴다. 궁극적인 목표는 자신의 작업을 완전히 자동화하는 것이다. 실비아 프레사드는 SRE가 ‘운영/요청 대응 업무와 사이트 안정성 및 성능을 높이는 시스템과 소프트웨어 개발’에 많은 시간을 투자한다고 말했다.

특히 ‘사이트 안정성’을 ‘비즈니스 가용성’과 동일시한다면 이 말은 중요하게 들린다. 그러나 대부분의 기업에서 개발자가 운영 전문가가 되어야 할까? SRE는 구글이나 아마존에서는 핵심적인 역할일 수 있지만 대부분의 기업에서는 개발자에게 지나치게 많은 운영 업무를 맡길 경우 성공적인 결과를 기대하기 어렵다. 

마이크로서비스 아키텍처

다른 한 사용자는 대부분의 기업에 필요 없는 선진 사례로 “당연히 마이크로서비스다. 직원 수가 단 20명이면서 마이크로서비스를 추진하려는 기업이 얼마나 많은지”라고 한탄했다. 마이크로서비스가 대부분의 기업에서 불필요하다고 주장하는 사람은 이 외에도 많다. 맥카타이 트윗에 대한 많은 응답에 마이크로서비스가 언급됐다.

마틴 파울러는 ‘마이크로서비스는 유용한 아키텍처지만 많은, 사실상 대부분의 상황에서는 모놀리스 아키텍처가 더 낫다’고 말했다. 아니, 모놀리스는 없애야 할 과거의 사악한 유물이 아니었던가? 물론 그렇게 간단한 문제가 아니다. 이에 대해 필자는 다음과 같이 주장한 바 있다.

“마이크로서비스의 달콤한 약속은 자유다. 애플리케이션을 각기 독립적으로 배포 가능한 개별 서비스로 분할할 자유, 이러한 개별 서비스를 다른 팀과 함께 그들이 선호하는 프로그래밍 언어, 툴, 데이터베이스 등을 사용해서 구축할 수 있는 자유 등이다. 요약하자면 개발 팀이 관료체계를 최소화하면서 해야 할 일을 할 수 있는 자유다.”

그러나 파울러가 다음과 같이 말했듯이 많은 애플리케이션에서 이 자유에는 불필요한 비용이 따른다.

• 분산 : 분산 시스템은 프로그램하기가 더 어렵다. 원격 호출은 느리고 항상 실패 위험을 안고 있기 때문이다.

• 궁극적 일관성 : 분산 시스템에서 강한 일관성 유지는 매우 어렵다. 모두가 궁극적 일관성을 관리해야 함을 의미한다.

• 운영 복잡성 : 정기적으로 재배포되는 많은 수의 서비스를 관리하려면 상당한 수준의 운영 팀이 필요하다.

샘 뉴먼은 특히 마지막 항목을 강조하며 ‘소규모 부서에 있어 마이크로서비스 아키텍처는 정당화가 어려울 수 있다. 마이크로서비스 자체의 배포와 관리라는 일이 생기기 때문’이라고 말했다.

마이크로서비스 접근 방법이 항상 잘못이라는 말은 아니다. 대규모 데이터센터를 유지하는 하이퍼스케일러 업체가가 사용한다는 이유만으로(이들에겐 보통 규모가 매우 중요하므로) 무조건 더 복잡한, 그러나 더 확장 가능한 접근 방식을 선택해서는 안 된다는 의미다.

모노리포면 다 된다?

본질적으로 마이크로서비스든 모놀리식이든 ‘모노리포’에 코드를 저장해서는 안 된다. 이것이 맥카타이의 질문에 대한 공통적인 답이었다. 모노리포는 코드 중복을 줄이고 팀간 협업을 촉진하는 데 따르는 (이론상의) 혜택을 얻기 위해 회사의 모든 코드를 하나의 버전 제어 시스템(VCS)에 저장하는 방식이다.

하지만 이론은 이론일 뿐이다.

현실은 전혀 다르다. 아마존, 트위터를 거쳐 현재는 리프트에서 고도의 정교한 시스템을 여러 차례 구축한 엔지니어인 맷 클라인은 “한 명의 개발자가 자신의 시스템에 전체 리포지토리를 두거나 grep 같은 툴로 검색하는 방식은 금방 타당성을 잃게 된다. 개발자가 한번에 코드베이스의 아주 작은 부분에만 액세스한다는 점을 감안하면, VCS를 통해 트리의 한 부분을 체크아웃하거나 여러 리포지토리를 체크아웃하는 것이 무슨 차이가 있는가? 아무런 차이가 없다”라고 주장했다.

클라인은 계속해서 다음과 같이 말했다.

“대규모의 협업과 코드 공유 관점에서 개발자는 상위 계층의 툴을 통해 코드의 세부 항목에 노출된다. 코드가 모노리포인지, 폴리리포인지는 상관이 없다. 해결되는 문제는 동일하다. 협업과 코드 공유의 효과는 전적으로 엔지니어링 문화에 의해 좌우되지 코드 저장소와는 아무 관계가 없다.”

참고는 어디까지나 각자의 상황에 맞게

물론 모노리포나 9x5 가용성 또는 마이크로서비스, SRE로 효과를 보는 기업도 있을 것이다. 자체 프레임워크, 자체 인프라를 구축하거나 맥카타이의 글에 댓글을 남긴 사람들이 조롱하는 다른 기술로 혜택을 얻는 경우도 존재한다.

요점은 단순히 구글과 페이스북, 아마존 또는 그 외의 하이퍼스케일러 기업이 한다고 해서 우리 회사도 그 방법을 따라하면 안 된다는 것이다. 확신이 없다면, 회사의 개별적인 요구부터 시작해서 소프트웨어를 구축하고 관리하기에 적절한 방법부터 알아보라. 기준은 ‘저렇게 되었으면 좋겠다’고 희망하는 대상이 아니라, 현재 우리 회사의 상황이 되어야 한다.

[출처] http://www.itworld.co.kr/news/167875?fbclid=IwAR3b322r6do8BrQpq4GZWJx8D9PoGmMxuGVXicIVTCCRBDi-saYTvemhlfU