Day2. 한국의 마이크로서비스 아키텍처 도입과 문제점

마이크로서비스와 SaaS와의 관계

마이크로서비스와 SaaS에 대해 먼저 개념에 대한 정리가 필요합니다.  

제가 이해한 개념에 대해 정리한 사항입니다.

2000년대 분산처리 아키텍처 및 소프트웨어 공학 (복잡도, 중복도에 대한 대책) 측면에서 CBD 및 SOA 관심 높아짐

2000년대 웹사이트 간 인터페이스 기술 대안으로 웹서비스 관심 높아짐

2000년대 ESB 기반의 SOA 프로젝트가 많이 진행됨 – 결과적으로 초기 이해 부족과 ESB 종속성 때문에 기대한 결과 확보가 어려워짐

2000년 중반 웹서비스 및 비동기 연동기술(AJAX)를 통한 매쉬업이 관심 높아짐

2000년 말 온디맨드 서비스를 확장한 Cloud 서비스 개시 (모든 것의 가상화가 시작됨)

2010년 구글, 아마존 등의 시스템 구축 및 운영 방식 + Cloud 서비스 관심도 높아짐

2013년 Martin fowler가 마이크로서비스 아키텍처 개념 제시 – 웹서비스 및 비동기 연동기술로 구현한 분산처리 아키텍처 및 소프트웨어 공학 방법에 대한 정리

2010년 실리콘밸리 스타트업 들의 마이크로서비스 아키텍처 적용 사례 확대 – Netflix, Facebook 등 기존 monolithic 구조에서 microservices 구조 전환 성공 사례

2010년 중반 마이크로서비스 아키텍처 구조를 지원하는 개발도구, 운영도구 (Docker) 출시 – 기존에도 있던 기능을 마이크로서비스 환경으로 확장

2010년 마이크로서비스 형태의 어플리케이션 개발자 공유 트랜드 형성 – Github 통해 모듈화된 서비스 및 기능에 대한 개발자 커뮤니티 생성

2010년 마이크로서비스 형태의 개발조직 Scrum 및 개발 후 운영, 고도화 DevOps, 반복적인 개발 -> 운영 -> 개발 형태 Agile방법론, 초기 소규모 서비스에서 지속적으로 서비스를 추가하는 형식의 CI(Continuous Integration)에 대한 개념이 한국에도 소개됨

---- 여기까지는 외국의 사례 ^^

2010년 중반 이후 한국에서도 마이크로서비스 아키텍처와 DevOps조직, Agile 방법론, CI에 대한 관심이 높아집니다.

기존 조직을 DevOps팀으로 개명하고, 프로젝트 진행 시 아침에 Scrum 미팅하고 Pilot 기반으로 고객요구사항 받는 Agile방법론..  그리고 source를 branch 따서 개발하다가 version 통합하는 CI 수행..  REST API 만들어보는 마이크로서비스 구성…

한국에서 IT 서비스 사업의 특징인 고객의 요구사항을 받아서 분석/개발/테스트 하는 전통 방식에서는 그다지 효율적이지 않은 도구인 것 같습니다.  그래서 국내 IT 서비스 사업 방식인 SI 프로젝트에서는 성공 사례가 없을 것 같습니다.

하지만 플랫폼 기반 사업자인 Kakao, Naver 등에서는 이러한 방식으로 조직 및 방법론을 전환하였고, 사업의 경쟁력을 확보하고 있다고 생각됩니다.

---- 여기까지는 한국의 사례 ^^

자사도 2000년 대 초반 진행한 H사 NIS 프로젝트를 SOA 기반으로 진행하였습니다.  SOA에 대한 결과나 평가는 기대 이하였고, 얼마 후 고도화 프로젝트에서 ESB를 제거하게 됩니다.

2010년 사업부 체계로 조직이 변경되면서 해운, 항만, 물류 및 기타 조직에서 각자 제품 개발 및 사업을 진행합니다.

2010년 고객마다 새로운 버전의 제품이 나와 관리해야 할 대상은 많아지고 제품의 품질 수준은 관리 노력보다 나아지지 않고 있습니다.

현재 고객들은 더 저렴하고 품질 좋고 바로 사용할 수 있는 서비스 형태로 제공하는 비즈니스 시스템을 요구하기 시작했습니다.  

그래도 다행히 솔루션 기반 SI 프로젝트에 대한 고객 수요가 남아 있습니다.

--- 여기까지는 현재까지의 자사

사장님이 플랫폼 사업으로 회사를 재창업 선언을 하시고, 사업부 체계가 아닌 역할별 통합형태로 조직이 구성되었습니다.

사업부 체계에서는 하지 못한 부분이 이제 좀더 가능한 상황입니다.

다소 허황되어 보이지만 다음과 같은 요구가 예상되는 시점입니다.

1.     전 제품의 기능의 공통화/표준화

2.     전 제품의 상호 연동성 향상

3.     전 제품의 외부 기술 연동성 향상

4.     전 제품의 신기술 도입 가속화

5.     전 제품의 동시 성능 향상

6.     전 기능의 매일 업데이트/배포 가능

7.     전 제품의 대량 판매 가능

허황된 목표를 달성하기 위해서는 기존과 다른 생각, 방법이 필요할 것 같습니다.

새롭게 일할 수 있는 환경을 구성하고 다른 조직에서 성공한 새로운 방식을 도입하고 새로운 문화를 만들어야만 달성 가능할 것입니다.

앞서서 시도하는 조직이 필요할 것이고 이를 준비하고 실행하는 프로젝트를 작은 규모로 진행하려고 합니다.

--- 여기까지는 본 프로젝트를 통해 해보고 싶은 변화?

  

문의 1. [프로젝트]에서 '마이크로 서비스'이외에 다른 SaaS 기능(ex. 테넌트 격리 아치텍처..등 )은 어떤것을 고려하시는지요 ?

         

       

마이크로서비스 = REST API 제공하는 작은 단위 서비스로 이해가 된 것 같습니다.  정확히 표현하면 마이크로서비스 아키텍처 구성이고, 플랫폼 구성요소 중 고객별 테넌트 분리항목과 통합항목을 구분하고 이를 적용하기 위한 방안(아키텍처)를 수립할 예정입니다.

본 프로젝트는 고객별로 다른 프로세스, 다른 설정, 다른 기능 구성 (가변성 관리)에 대해서도 마이크로서비스 (REST API) 개발 후 조합하는 형식으로 생각하고 있습니다.  

방안 수립을 컨설팅 통해서 진행할 예정이며, 결과물을 통해 SaaS 방안에 대해 이해할 수 있도록 준비하겠습니다.

문의 2. 계획서에 있는 협역업체가 아래와 같은 SassS 파트너 프로그램에 포함되어 있는 'APN 기술 파트너'와 비슷한 지원을 받을 수 있는 궁급합니다.

          - 잘 알아보셨을 것인데, 워낙 SaaS 실패 사래가 많이서 노파심에 문의 드립니다.

APN 기술 파트너 프로그램은 PaaS 플랫폼 제공업체가 지원하는 걸로 AWS, Google, IBM, MS 등이 할 수 있을 것 같아요.  다만 APN 기술 파트너가 되면 그 회사의 PaaS 플랫폼에 종속(Engagement) 될 가능성은 있습니다.

좋은 점은 DevOps 환경 구성 및 플랫폼에서 필요한 Value Chain (가입자 관리 등..)에 대해 사전 구성된 서비스를 사용할 수 있을 것 같네요.  

1단계 컨설팅 진행 결과에 따라 특정 업체 선정 및 2단계 PoC 수행을 진행할 예정입니다. 전사적으로 종속성이 없게 기술본부주도로 아키텍처 및 운영 방안, 개발 방법론이 수립된 후 업체 선정이 될 것으로 기대하고 있습니다.

문의 3. '마이크로서비스'는 2016년부터 많이 이야기 되었지만, 아래 '3가지 전체조건'때문에 쉽게 논의하기 힘들었던 것으로 알고 있습니다.

         특히, Culture 부분이 많이 고민되었는데, PM님만의 해결방안을 들을 수 있으면 많은 도움이 되겠습니다.

확장성에 대한 3차원 모델은 다음과 같은 구조입니다.  Y축은 기능분해(마이크로서비스), X축은 서버 병렬구성 서버스펙 향상, Z축은 데이터 파티션, 샤딩 (테넌트별로 서버 분리)

말씀하신 데로 문화와 조직과 도구가 (Process, People, Tool) 바뀌어야지만 도입이 가능한 것이 새로운 아키텍처라고 생각합니다.. 맞구요 ^^

이런 고민과 관련된 도서가 많이 나와 있습니다.  제가 읽어본 책은 다음과 같습니다.

마이크로서비스 아키텍처 구축 – 대용량 분산 설계 (아키텍처 관리요소)

마이크로서비스는 기존 대용량 시스템의 복잡성과 운영?배포?유지보수의 문제점을 해결할 새로운 대안이다. 이 책은 마이크로서비스 아키텍처를 구축, 관리할 때 고려할 문제와 이에 관한 포괄적 시각과 실용적인 조언을 제공한다. 지속적 통합을 통해 개별 마이크로서비스를 배포하는 과정을 설명하고, 실제로 마이크로서비스를 도입한 기업들의 구체적 사례를 소개한다.

스프링 5.0 마이크로서비스 2/e (Java/JVM으로 마이크로서비스 구성 – 항공사 시스템 사례 포함)

마이크로서비스는 복잡한 시스템을 더 작은 여러 개의 서비스로 나눠서 대규모의 비즈니스 서비스를 처리하는 아키텍처 스타일이나 패턴이다. 마이크로서비스는 자율적이고, 자기 완비적(self-contained)이며, 독립적으로 배포할 수 있다. 오늘날 많은 기업에서는 마이크로서비스로 대규모의 서비스 지향 기업 애플리케이션을 만드는 것을 표준으로 삼는다.

도메인 주도 설계 (해운선사 시스템 사례 포함)

소프트웨어의 복잡성을 다루는 지혜, 비즈니스를 도메인으로 분리하는 방법에 대한 아이디어를 제공합니다.

데브옵스 2.0툴킷 (DevOps 관리 도구)

클라우드 환경, DevOps 조직 개발/운영에 필요한 도구 목록 및 추천 도구 제시합니다.

Day1. 플랫폼 비즈니스 성공공식과 지원 기술요소

플랫폼 비즈니스 성공 공식

하버드 비즈니스 리뷰에서는 플랫폼 비즈니스에 대한 성공 공식 3가지를 다음과 같이 제시하였습니다.

다양한 참여자, 수익모델, 데이터 기반한 추천 등 너무 익숙한 이야기들이고 당연한 내용입니다.  

그리고 이렇게 성공한 플랫폼 기업의 결과는, 오늘은 Startup이지만 내일은 Star라는 것입니다.

성공 공식 별 기술 아키텍처 요구사항

이러한 비즈니스 요소를 다음과 같은 기술 아키텍처 요구사항으로 정의해 보았습니다.

Agility – 민첩성

요구사항 1. 서비스는 가입하고 바로 사용을 할 수 있어야 한다.

요구사항 2. 폭발적인 비즈니스 성장에서도 서버나 서비스로 인한 성능 저하가 없어야 한다.

요구사항 3. 다양한 참여자의 요구에 .신속하게 대응할 수 있어야 한다.

요구사항 4. 내/외부간 데이터 및 서비스 연계가 손쉬워야 한다.

요구사항 5. 외부 개발자가 손쉽게 서비스 개발에 참여할 수 있어야 한다.

요구사항 6. 각 참여자의 보안이나 권한은 통합된 방식으로 관리되어야 한다.

ð  오늘은 지도 서비스, 내일은 배달 앱, 모레는 금융 서비스로 확장이 가능한 플랫폼 구조인가?

Resiliency – 탄력성

요구사항 7. 사용 비용이 저렴하지만 기능은 최신이어야 한다.

요구사항 8. 공정한 평가모델로 참여자 간 신뢰가 형성되어야 한다.

요구사항 9. 서비스 사용량이나 수익 공유 방식으로 과금이 되어야 한다.

요구사항 10. 서비스 수준이 측정되고 서비스 불안정에 따라 보상이 제시될 수 있어야 한다.

요구사항 11. 장애가 없거나 발생하더라도 전체 서비스 영향은 최소화 되어야 한다.

ð  장애의 영향은 최소화 되게 구조화 되어 있고, 투자 회전율은 높은 플랫폼 구조인가?

Efficiency – 효율성

요구사항 12. 축적된 데이터를 신속하게 처리하여 추천, 검색을 통해 참여자간 연계가 용이해야 한다.

요구사항 13. 다양한 특성의 대용량 데이터 처리와 AI같은 기술 연계가 손쉬워야 한다.

ð  새로운 기술요소를 쉽게 적용해 보고, 쉽게 교체할 수 있는 플랫폼 구조인가?

아키텍처 요구사항 해결방안

이러한 요구사항은 비즈니스 성장과 기술발전에 따라 지속적으로 플랫폼에 적용될 수 있는 구조가 될 수 있어야 합니다.

사실 이러한 요구는 낯설지 않은 것이고 지금까지 다음과 같은 방법으로 해결을 했습니다.

1.     모든 비즈니스 요구사항 및 가능성을 예측한다.

2.     대규모 투자를 통해 분석, 설계, 개발, 그리고 테스트를 통해 단일화된 시스템 구조를 확보한다.

3.     사업을 진행하고 시스템을 운영하다가 기술요소 한계가 발생하면, 차세대 프로젝트를 진행한다.  -> 1번으로 돌아감

사업을 하다가 발생할 수 있는 기술요소의 한계는 다음과 같습니다.

시스템을 운영하는 시간이 길수록 소스의 복잡도와 중복도가 높아진다. 개발과 운영 조직이 달라서 운영 이관 후 개발소스에 대한 이해도가 떨어진다. 새로운 비즈니스나 기술을 적용하려고 하나 단일화된 시스템 구조의 성능과 연계성이 한계가 된다. 단순한 변경을 수행하더라도, 전체 시스템 영향을 고려해서 테스트 및 배포에 시간 소모가 길어진다. 특정 기능의 성능 저하는 전체 시스템 사용에 영향을 주기 시작한다. 모든 데이터의 연계는 데이터베이스 중심으로 진행되고 데이터베이스 구조의 변동이 가끔 재앙이 된다. 한 서비스의 장애는 곧 전체 시스템의 서비스 중단으로 이어진다. 프로그램 간의 결합도가 높아서 개발자 혹은 운영자간 책임소재가 불분명해지고 있다. ð  운영 비용이 점차 증가하기 시작하고, 새로 개발하자는 의견이 많아진다.

사실 이러한 소프트웨어 아키텍처의 한계는 프로그램 자체에서 발생한 것이 아니라 사람과 관습에서 만들어 낸 것입니다.

이러한 한계를 극복하고자 많은 사람이 조직과 프로세스를 바꾸는 시도를 했고, 이를 마이크로서비스 아키텍처를 구축하는 과정을 통해 달성했다고 합니다.

즉, 작은 규모 서비스(마이크로서비스)의 개발/운영(DevOps)를 지속적으로 반복(Agile)해서 최적의 모델을 만들어 가는 방식으로 변화하는 것이며,

처음에는 속도가 나지 않던 조직/프로세스가 반복을 통해 민첩성과 성과가 개선되는 구조가 되는 것입니다.

마이크로서비스 혹은 단일화된 시스템 구조(Monolithic)

하지만 마이크로서비스는 모든 문제를 해결할 수 없습니다.  다음과 같은 경우는 단일화된 시스템 구조가 더 적합할 수 있습니다.

-       무엇을 개발할지 결정되지 않았다거나 기본적인 서비스 구조도 해보지 않은 상황에서는 단일화된 시스템 구조로 시작하는 편이 낫습니다.

-       비즈니스 성장이 한계가 있고 새로운 요구사항이 많지 않은 경우 단일화된 시스템 구조로 운영하는 것이 더욱 저렴할 수 있습니다.

-       새로운 기술요소나 기능내의 기술 다양성이 높지 않은 경우 단일화된 시스템 구조로 개발하는 것이 효과적입니다.

-       요구사항 분석, 설계, 대규모 외주개발, 테스트가 진행되는 프로젝트는 마이크로서비스 방식으로 진행해서는 안됩니다.

-       외주조직을 연계하거나, 개발과 운영 조직을 다르게 가져가는 경우는 DevOps 형태의 마이크로서비스 방식과 관련이 없습니다.

본 프로젝트 구현에 마이크로서비스 방식을 도입하고자 하는 이유는 위와 같은 상황과 반대이기 때문입니다.

-       구현 대상이 명확하다.  (지금 개발된 기능을 대상으로 전환)

-       비즈니스 성장이 급속할 것으로 기대하고 있으나, 처음에는 작은 규모로 사업을 시작하고 싶다.

-       참여자가 규모, 지역적으로 다양하고 요구사항이 다양하며 신속한 적용이 요구되어 잦은 배포가 필요하다.

-       새로운 기술요소의 도입이 절실히 요구된다.

-       테스트는 단위 기능별로 진행해도 전체 서비스에 영향이 적거나 문제 발생 시 손쉽게 롤백이 필요하다.

-       저렴한 인프라 저렴한 기술요소로 새로운 기술을 구현하고 싶다.

-       작은 규모의 조직으로 지속적인 서비스 확대 및 개선을 수행할 예정이다.  (개발과 운영을 동일한 조직으로 수행)

-       외부 개발자도 쉽게 개발 참여를 할 수 있지만, 외부로 노출된 제한된 API를 통해서 개발을 수행할 수 있어야 한다.

-       여기에 앞에서 언급한 플랫폼 비즈니스 요구사항을 적용할 계획이다.

결론.

플랫폼 비즈니스, 마이크로서비스 방식의 개발은 회사 누구도 경험이 없고 성공에 대한 확신도 없습니다.

이런 방식은 기존처럼 단일 제품이나 아키텍처 선정하여 진행하자는 것도 아닙니다.

지금은 새로운 방식으로 시작하지 않으면 안 되는 상황이라고 판단됩니다.

하지만 작은 규모 마이크로서비스 방식이기 때문에 신속하게 실패하고 다시 시작할 수 있습니다.

실패의 확률을 최소화하고 더 빨리 성공하기 위해서는 조직과 프로세스가 이런 시도를 이해하려는 노력이 필요할 것 같습니다.