2018.05.18

마이크로서비스 확장을 위한 비법 7가지

Christian Beedgen | InfoWorld

마이크로서비스를 도입해 ‘현대적인’ 애플리케이션을 구현하는 것은 더 이상 차별화 요소가 되지 못한다. 그러나 시장에서 입지를 유지하기 위해 반드시 해야 할 일이다. 기술 혁신의 속도 때문에 기업은 더 빨리 움직이고 있고, 더 ‘스마트’해지고 있고, 더 간호화되고 있다. 경쟁에서 앞서 나가고 경쟁력을 유지하고 비즈니스를 확장하기 위해서는 반드시 IT 현대화가 필요하다.

Image Credit : GettyImagesBank

모놀리식(획일적) 애플리케이션 대신 분산형 마이크로서비스를 도입한 기업의 사례는 많다. 그러나 수모 로직(Sumo Logic)의 이야기는 꽤 ‘급진적’이다. 필자의 팀은 수모 로직을 창업하기 전에 엔터프라이즈 소프트웨어로 전달되는 모놀리식 아키텍처와 유사한 솔루션 구축과 확장에 약 10년이라는 시간을 투자했다. 우리는 새로운 방식으로 차세대 로그 관리 시스템을 구현하기 위해 수모 로직을 창업했다. 새로운 방식이란 규모를 확대하거나 축소할 수 있는 분산형 멀티테넌트 서비스를 가리킨다.

우리는 로그와 매트릭스를 위해 아주 규모가 큰 데이터 처리 시스템을 점진적으로 구현하면서 중요한 교훈을 많이 터득했다. 우리가 극복해야 했던 도전과제와 문제를 피할 수 있도록, 지금부터 비즈니스를 확장하는 데 마이크로서비스를 활용하는 방법 7가지를 소개한다.

#1 PDU(Product Development Unit)를 구현한다
가장 먼저 팀을 구성해야 한다. 우리는 현재 PDU(Product Development Unit)라는 모델을 적용하고 있다. PDU는 고유의 마이크로서비스로 구성된 완전한 유닛이다. 규모가 작은 팀이 특정 프로젝트에 집중하면서, 특정 마이크로서비스 세트에 너무 많은 관여가 있을 때 초래되는 복잡성(충돌 또는 분규) 문제를 피하도록 도와준다. 아마존의 제프 베조스가 창안한 ‘피자 두 판의 규칙’에 토대를 두고 있는 개념이다. 피자 두 판으로 모두 한 끼 식사를 해결할 수 있는 규모로 팀을 구성해야 한다는 개념이다.

PDU는 꽤 강력하다. 제품의 특정 부분에 대한 운영 지식과 전문성을 갖추고 있기 때문이다. 그렇지만 교차 편집 성격의 변화를 추진해야 할 때 도전에 직면한다. 자바 7과 자바 8에서 트랜지셔닝된 모든 마이크로서비스가 관여된 프로젝트를 예로 들 수 있다. PDU가 이런 관통형 변화를 실행하도록 만들기란 쉽지 않다. 그러나 팀이 효과적으로 커뮤니케이션하면 충분히 할 수 있다. 통상 한 사람으로 하여금 이런 변화와 관련된 모든 커뮤니케이션과 ‘고양이 몰이’를 책임지도록 하고 있다. 이 사람은 꽤 많은 사람들에게 색을 입혀 구분한 마이크로서비스 목록을 보낸다. 여기에 붉은색으로 표시가 되는 것은 좋지 않다.

#2 책임감을 갖도록 조직 구조를 바꾼다
시간이 경과하면서 팀을 편성하는 방식이 바뀌었다. 시작할 당시에는 4~5명의 개발자와 소수의 마이크로서비스로 팀을 구성했다. 지금은 팀의 규모가 훨씬 더 커졌고, 마이크로서비스는 40~50개에 달한다. 처음에는 한 명 또는 한 팀이 하나의 서비스를 책임지는 것이 합리적으로 판단되지 않았다. 아키텍처가 급속도로 진화하고 있었기 때문이다. 그러나 아키텍처의 주춧돌들이 딱 맞아 떨어지고 팀이 성장하면서, 서비스를 몇몇 팀으로 나눠 맡겼다.

소프트웨어를 개발한 사람들이 완전히 책임을 지는 것이 중요하다. 다시 말해, 소프트웨어를 구축한 사람들이 테스트와 배포, 운영을 해야 한다는 의미이다. 이들은 전체 라이프사이클을 책임진다. 우리는 이를 통해 만들어진 책임의식을 높이 평가한다. 다른 한편으로는 자신의 일에 대해 완전한 자율성, 소프트웨어에 대해 결정을 내릴 수 있는 권한이 주어진다. 한 밤 중에 코드와 관련된 문제를 해결해야 하는 상황을 고려하자. 이들이 결정을 내릴 수 있도록 신뢰해야 한다.

이는 연방 시스템과 사회의 문화와 아주 유사한 시스템이다. 시스템은 여러 독립적인 유닛(단위)들을 중심으로 구축되어 있고, 이들 단위는 서로 힘을 합해 더 큰 목적을 달성하는 것을 추구하기 때문이다. 이는 유닛의 독립성을 일정 수준으로 제한한다. 그러나 더 작은 그룹 내에서 더 높은 수준에서 정한 가이드라인에 따라 수많은 결정을 내릴 권한을 갖고 있다.

#3 서비스의 경계를 결정한다
서비스 경계를 결정할 때, 때론 순수하게 직관에 의존해야 하는 경우도 있다. 하지만 출발점은 다른 사람들처럼 화이트보드에 시스템의 주요 구성 요소를 기록하고, 그 주변에 상자를 그리는 것이다.

처음에는 마이크로서비스에 단단한 경계를 만들었다. 아주 단호하게 추진했던 전략이다. 모든 것에 별개의 리포지토리를 만들었다. 이는 마이크로서비스가 3개에 불과했던 시절까지 거슬러 올라간다. 과거 모놀리식 시스템 관련 작업에서 진이 빠진 경험이 있었다. 자바 패키지에 반드시 포함시켜야 하는 것, 사람들이 특정 패키지에서 다른 특정 패키지를 호출하지 않도록 한다는 것 등 코드 구성과 관련된 기본적인 약속조차 지키지 않는 경우가 적지 않았기 때문이다. 그래서 커플링을 낮은 상태로 유지하기 위해 이 부분에는 급진적인 원칙을 적용했다. 결국에는 모놀리식 리포지토리와 부드러운 경계로 귀결되었다. 그러나 과거와 달리 지금은 작동을 잘한다. 모든 팀에 경계를 존중할 것을 가르쳤기 때문이다.

최초 시스템 팩토링 관점에서 보면, 영역별 경험도 도움이 된다. 우리의 경우 초기 팀은 로그 관리 시스템 구축과 관련된 경험을 갖고 있었다. 그러나 우리가 크게 틀린 부분이 있었다. 예를 들어, 어느 시점에서 처음에는 데이터 인덱싱과 검색을 분리했었다. 동일한 모듈이나 동일한 서비스여야 했기 때문이다. 본질적으로 동일한 데이터를 클러스터 간에 교환하는 아주 성가신 프로세스이다. 여기에 지연식나이 늘어난다. 아키텍처에 아주 골치 아픈 구현 방식이다. 2~3년 뒤에 이런 최초 결정이 아키텍처의 핵심에 어떤 영향을 줬는지 파악했다. 이후에는 개발자들의 삶이 훨씬 편해졌다.

#4 신중하게 서비스 업그레이드 시기를 결정한다
아주 중요한 이야기를 하겠다. 한 번에 모든 서비스를 업그레이드하는 것은 정말 좋지 않은 생각이다. 한 번에 몇 주 동안 배포를 하고, 무언가 궤도를 벗어나면 롤백을 하고, 다시 시작했던 시기가 있었다. 여기에서 끝나는 것이 아니다. 다시 배포를 하고, 또 무언가 잘못되면 롤백을 하고, 처음부터 다시 시작한다. 이런 일을 연속해서 3~5주 동안 했던 적도 있다. 그러다 바보 같은 짓이라는 점을 깨달었다. 더 효율적이 방법을 찾아야 했다. 물론 지금은 상식이다. 2010년에나 그랬을 것이다. 그러나 이런 기본적인 진실을 직접 겪고야 발견하는 경우도 있다.

당시 서비스는 약 25개, 팀은 15~20명으로 구성되어 있었다. 대안은 서비스 별로 업그레이드를 하는 방법이었다. 이 또한 바보 같은 짓이라는 생각이 들었다. 2시간이라는 유지관리 시간 동안 25번에 걸쳐 서비스를 업그레이드하고, 재시작하고, 올바르게 작동하는지 확인할 것인가? 간단히 대답하면 불가능한 일이다.

결국 중간에 해당하는 해결책을 찾았다. 우리는 이른바 ‘어셈블리 그룹’이라는 개념을 만들었다. 25개 서비스를 작은 그룹으로 분리해 묶었다. 2~6개의 서비스를 함께 업그레이드하는 방법이다. 그리고 훨씬 현실적인 방법이라는 점을 확인했다.



2018.05.18

마이크로서비스 확장을 위한 비법 7가지

Christian Beedgen | InfoWorld

마이크로서비스를 도입해 ‘현대적인’ 애플리케이션을 구현하는 것은 더 이상 차별화 요소가 되지 못한다. 그러나 시장에서 입지를 유지하기 위해 반드시 해야 할 일이다. 기술 혁신의 속도 때문에 기업은 더 빨리 움직이고 있고, 더 ‘스마트’해지고 있고, 더 간호화되고 있다. 경쟁에서 앞서 나가고 경쟁력을 유지하고 비즈니스를 확장하기 위해서는 반드시 IT 현대화가 필요하다.

Image Credit : GettyImagesBank

모놀리식(획일적) 애플리케이션 대신 분산형 마이크로서비스를 도입한 기업의 사례는 많다. 그러나 수모 로직(Sumo Logic)의 이야기는 꽤 ‘급진적’이다. 필자의 팀은 수모 로직을 창업하기 전에 엔터프라이즈 소프트웨어로 전달되는 모놀리식 아키텍처와 유사한 솔루션 구축과 확장에 약 10년이라는 시간을 투자했다. 우리는 새로운 방식으로 차세대 로그 관리 시스템을 구현하기 위해 수모 로직을 창업했다. 새로운 방식이란 규모를 확대하거나 축소할 수 있는 분산형 멀티테넌트 서비스를 가리킨다.

우리는 로그와 매트릭스를 위해 아주 규모가 큰 데이터 처리 시스템을 점진적으로 구현하면서 중요한 교훈을 많이 터득했다. 우리가 극복해야 했던 도전과제와 문제를 피할 수 있도록, 지금부터 비즈니스를 확장하는 데 마이크로서비스를 활용하는 방법 7가지를 소개한다.

#1 PDU(Product Development Unit)를 구현한다
가장 먼저 팀을 구성해야 한다. 우리는 현재 PDU(Product Development Unit)라는 모델을 적용하고 있다. PDU는 고유의 마이크로서비스로 구성된 완전한 유닛이다. 규모가 작은 팀이 특정 프로젝트에 집중하면서, 특정 마이크로서비스 세트에 너무 많은 관여가 있을 때 초래되는 복잡성(충돌 또는 분규) 문제를 피하도록 도와준다. 아마존의 제프 베조스가 창안한 ‘피자 두 판의 규칙’에 토대를 두고 있는 개념이다. 피자 두 판으로 모두 한 끼 식사를 해결할 수 있는 규모로 팀을 구성해야 한다는 개념이다.

PDU는 꽤 강력하다. 제품의 특정 부분에 대한 운영 지식과 전문성을 갖추고 있기 때문이다. 그렇지만 교차 편집 성격의 변화를 추진해야 할 때 도전에 직면한다. 자바 7과 자바 8에서 트랜지셔닝된 모든 마이크로서비스가 관여된 프로젝트를 예로 들 수 있다. PDU가 이런 관통형 변화를 실행하도록 만들기란 쉽지 않다. 그러나 팀이 효과적으로 커뮤니케이션하면 충분히 할 수 있다. 통상 한 사람으로 하여금 이런 변화와 관련된 모든 커뮤니케이션과 ‘고양이 몰이’를 책임지도록 하고 있다. 이 사람은 꽤 많은 사람들에게 색을 입혀 구분한 마이크로서비스 목록을 보낸다. 여기에 붉은색으로 표시가 되는 것은 좋지 않다.

#2 책임감을 갖도록 조직 구조를 바꾼다
시간이 경과하면서 팀을 편성하는 방식이 바뀌었다. 시작할 당시에는 4~5명의 개발자와 소수의 마이크로서비스로 팀을 구성했다. 지금은 팀의 규모가 훨씬 더 커졌고, 마이크로서비스는 40~50개에 달한다. 처음에는 한 명 또는 한 팀이 하나의 서비스를 책임지는 것이 합리적으로 판단되지 않았다. 아키텍처가 급속도로 진화하고 있었기 때문이다. 그러나 아키텍처의 주춧돌들이 딱 맞아 떨어지고 팀이 성장하면서, 서비스를 몇몇 팀으로 나눠 맡겼다.

소프트웨어를 개발한 사람들이 완전히 책임을 지는 것이 중요하다. 다시 말해, 소프트웨어를 구축한 사람들이 테스트와 배포, 운영을 해야 한다는 의미이다. 이들은 전체 라이프사이클을 책임진다. 우리는 이를 통해 만들어진 책임의식을 높이 평가한다. 다른 한편으로는 자신의 일에 대해 완전한 자율성, 소프트웨어에 대해 결정을 내릴 수 있는 권한이 주어진다. 한 밤 중에 코드와 관련된 문제를 해결해야 하는 상황을 고려하자. 이들이 결정을 내릴 수 있도록 신뢰해야 한다.

이는 연방 시스템과 사회의 문화와 아주 유사한 시스템이다. 시스템은 여러 독립적인 유닛(단위)들을 중심으로 구축되어 있고, 이들 단위는 서로 힘을 합해 더 큰 목적을 달성하는 것을 추구하기 때문이다. 이는 유닛의 독립성을 일정 수준으로 제한한다. 그러나 더 작은 그룹 내에서 더 높은 수준에서 정한 가이드라인에 따라 수많은 결정을 내릴 권한을 갖고 있다.

#3 서비스의 경계를 결정한다
서비스 경계를 결정할 때, 때론 순수하게 직관에 의존해야 하는 경우도 있다. 하지만 출발점은 다른 사람들처럼 화이트보드에 시스템의 주요 구성 요소를 기록하고, 그 주변에 상자를 그리는 것이다.

처음에는 마이크로서비스에 단단한 경계를 만들었다. 아주 단호하게 추진했던 전략이다. 모든 것에 별개의 리포지토리를 만들었다. 이는 마이크로서비스가 3개에 불과했던 시절까지 거슬러 올라간다. 과거 모놀리식 시스템 관련 작업에서 진이 빠진 경험이 있었다. 자바 패키지에 반드시 포함시켜야 하는 것, 사람들이 특정 패키지에서 다른 특정 패키지를 호출하지 않도록 한다는 것 등 코드 구성과 관련된 기본적인 약속조차 지키지 않는 경우가 적지 않았기 때문이다. 그래서 커플링을 낮은 상태로 유지하기 위해 이 부분에는 급진적인 원칙을 적용했다. 결국에는 모놀리식 리포지토리와 부드러운 경계로 귀결되었다. 그러나 과거와 달리 지금은 작동을 잘한다. 모든 팀에 경계를 존중할 것을 가르쳤기 때문이다.

최초 시스템 팩토링 관점에서 보면, 영역별 경험도 도움이 된다. 우리의 경우 초기 팀은 로그 관리 시스템 구축과 관련된 경험을 갖고 있었다. 그러나 우리가 크게 틀린 부분이 있었다. 예를 들어, 어느 시점에서 처음에는 데이터 인덱싱과 검색을 분리했었다. 동일한 모듈이나 동일한 서비스여야 했기 때문이다. 본질적으로 동일한 데이터를 클러스터 간에 교환하는 아주 성가신 프로세스이다. 여기에 지연식나이 늘어난다. 아키텍처에 아주 골치 아픈 구현 방식이다. 2~3년 뒤에 이런 최초 결정이 아키텍처의 핵심에 어떤 영향을 줬는지 파악했다. 이후에는 개발자들의 삶이 훨씬 편해졌다.

#4 신중하게 서비스 업그레이드 시기를 결정한다
아주 중요한 이야기를 하겠다. 한 번에 모든 서비스를 업그레이드하는 것은 정말 좋지 않은 생각이다. 한 번에 몇 주 동안 배포를 하고, 무언가 궤도를 벗어나면 롤백을 하고, 다시 시작했던 시기가 있었다. 여기에서 끝나는 것이 아니다. 다시 배포를 하고, 또 무언가 잘못되면 롤백을 하고, 처음부터 다시 시작한다. 이런 일을 연속해서 3~5주 동안 했던 적도 있다. 그러다 바보 같은 짓이라는 점을 깨달었다. 더 효율적이 방법을 찾아야 했다. 물론 지금은 상식이다. 2010년에나 그랬을 것이다. 그러나 이런 기본적인 진실을 직접 겪고야 발견하는 경우도 있다.

당시 서비스는 약 25개, 팀은 15~20명으로 구성되어 있었다. 대안은 서비스 별로 업그레이드를 하는 방법이었다. 이 또한 바보 같은 짓이라는 생각이 들었다. 2시간이라는 유지관리 시간 동안 25번에 걸쳐 서비스를 업그레이드하고, 재시작하고, 올바르게 작동하는지 확인할 것인가? 간단히 대답하면 불가능한 일이다.

결국 중간에 해당하는 해결책을 찾았다. 우리는 이른바 ‘어셈블리 그룹’이라는 개념을 만들었다. 25개 서비스를 작은 그룹으로 분리해 묶었다. 2~6개의 서비스를 함께 업그레이드하는 방법이다. 그리고 훨씬 현실적인 방법이라는 점을 확인했다.



X