MSA, 준비된 조직만이 성공할 수 있다

https://www.comworld.co.kr/news/articleView.html?idxno=49710
[인터뷰] “마이크로서비스 아키텍처(MSA) 도입, 준비된 조직만이 성공할 수 있다” (2019.09.01)

 

위의 인터뷰 요약 + 첨언

 

• MSA
  - 애플리케이션을 느슨하게 결합된 작은 구성 요소 서비스로 분해함으로써 독립적인 개발, 배포 및 운영이 가능 
  - 서비스 개발 팀이 보다 신속하게 새로운 기능 제공 및 확장 가능 하도록
  - 이러한 MSA를 구현하기 위해서는 독립적인 배치, 확장, 운영이 가능한 서비스로 설계 필요
  - 설계자는 인터페이스(API First Design) 및 데이터 정합성(Eventually Consistency) 관리 패턴 필요 
  - 서비스 설계 접근 방식은 서비스간의 느슨한 결합 (Loose Coupling) 원칙 -> Event Driven 방식 필요

 

• 이러한 MSA를 통해 민첩성과 확장성이 향상된다는 것은 곧 비용
  (앞의 장점을 얻으려면 비용이 따름, 내재화/투자 필요)
  - 다수의 독립적인 서비스로 구성된 Application을 설계 및 관리하는 데 있어서의 어려움 
  - 서비스 지원에 필요한 Outer Architecture의 복잡성

 

• MSA를 채택할 때에는 무엇보다 비즈니스를 중심으로 생각해야
• 특정 기능에 대해 일정한 납기일을 요구하는 경우에는 MSA의 민첩성 및 유연성의 이점을 누릴 수 없음
  이 경우 MSA는 기술적으로 적합하지 않은 것보다는 문화적으로 더욱 적합하지 않음
• 조직이 MSA가 필요하지 않거나, 조직이 투자할 준비가 되지 않았다면 MSA를 채택해서는 안 됨
  (MSA필요성, 관리자부터 실무자까지의 공감대, 도입시 효과, 도입/이행 로드맵, 구성원 내재화 등의 준비)
• MSA라는 것은 결국 지속적으로 변화가 필요할 때 그 변화에 빨리 대응하기 위해 도입하는 것이고,
  그렇게 해야만 혜택이 생김
• 그러나 특정 조직이 언제까지 뭔가를 해야 한다는 데드라인을 요구한다면 MSA의 효과를 충족시키지 못함
  (MSA로 전환되는 동안 단계적, 조직적, 문화적, 내재화등이 필요한데 조직/개인마다 상황이 다르고 변화)

---

Q) MSA가 갖는 가치와 현재 위상? 이상적인 지향점 정도로 이해?

A) 일부에서는 MSA를 어떤 측면에서 보면 과장됐다고 이야기하기도 한다. MSA는 그 가치가 높긴 하지만, 특정 상황에만 가치를 낼 수 있다고 생각한다. 많은 기업 및 조직들이 MSA를 차세대 애플리케이션 아키텍처라고 생각하고 도입하는데,  그러면 안 된다. 기존의 모놀리식(Monolithic)한 아키텍처를 대체한다기보다는 하나의 대안, 또 다른 애플리케이션 개발 방식이라고 봐야 한다. MSA는 아직 완전히 성숙하지는 않았다. 많은 조직들을 살펴보면 MSA를 도입해 성숙된 경우도 있고, 그렇지 않은 경우도 있다. 현재는 전체적으로 성숙 중인 단계 (2019년 인터뷰 기준)라고 볼 수 있다

---

Q) MSA로 전환할 때 주의해야 할 점? (주의정도가 아니라 반드시 명심) 

A)
1) MSA를 기술적인 관점만이 아닌, 비즈니스 가치를 제공하기 위한 것이라는 것을 염두 

    (Biz Agility <- 독립 개발/배포/운용, 확장성, 장애격리)
2) MSA가 가치를 제공하기 위해서는 애플리케이션의 변화를 신속하게 따라가면서 서비스 가능해야, 
    그런데 애플리케이션을 개발해 놓고 변화 없이 그대로 가는 경우에는 굳이 MSA가 필요 없음
3) MSA에서 가치나 효과를 기대하기 위해서는 개발이 신속하게 이뤄져야 하는데, 
    그 전제조건으로 Agile한 개발(분석/설계/개발 반복 적용), DevOps, 파이프라인, 테스팅 자동화, 인프라(Cloud) 등 필요
    이러한 부분이 준비되지 않으면 전환해봐야 별다른 가치를 갖지 못함 (하나씩이라도 단계적으로라도 준비 필요)
4) Monolith -> MSA 전환과정이 점진적/단계별 접근이 필요
    처음에는 큰 부분(Macro)에서부터 점점 작은 부분(Micro)으로 가면서, 효과를 체크하면서 가야함
    얻을 수 있는 가치가 적어지기 시작하면 마이크로로 갈 필요가 없음, 때문에 단계적으로 추진해야

---

Q) MSA로의 전환을 주도해야 조직은 의사 결정자와 현업 개발팀 중 어느 쪽이라고 생각하는가? 그 이유는 무엇인가?
A) 둘 다 중요하고 같이 움직여야 한다

     탑다운 방식으로 할 경우 MSA가 ‘목표’가 되는 경우가 많음  
     MSA가 적절한 가치를 산출하려면 비즈니스 가치를 위한 (목표가 아닌)수단이 되어야  
    개인적으로 MSA에 대한 최적의 접근은 현업이 주도하면서 탑에서 적극적으로 지원하는 것이 중요

---

Q) MSA를 이해하는 개발자는 현재 충분하다고 볼 수 있는가? 부족하다면 어떤 해결책이 있다고 생각하는가?
A) 아직 부족
     개발자뿐 아니라 아키텍트, 매니저, DBA 등도 MSA와 관련해 충분히 이해하지 못하고 있다는 생각

     해결책이라면 점진적으로, 단계적으로 MSA로 전환해야

     넷플릭스, 아마존, 길트, 이베이 등 성공사례를 보더라도 이들 역시 굉장히 점진적으로 MSA를 도입, 실행
     완전히 MSA를 하기보다는 이렇게 조금씩 전환하는 과정에서 배우는 것이 생기고(내재화 됨), 점차 나아가는 게 최선

 

• MSA 도입을 위해 프로세스를 한 번에 너무 많이 바꾸면 실제 어떤 게 성공요인, 실패요인인지를 판단하기 어려움 
• 바꿔나가는 요소를 최소화해서 조그만 변화를 단계적으로 주는 것이 중요
  (예 : API First Design, Agile, DevOps, EDA, 다양한 DB 등을 순차적으로 적응/검증/내재화)

---

• 너무 많은 변화를 한 번에 주면 실패에 대한 위험부담이 크다
• MSA는 단계적으로 추진하면서 배워나가야 한다
• MSA, 만능은 아니지만 준비돼 있다면 가치 크다
• MSA, 조직의 문화가 준비돼 있어야
• 현업이 주도하고 위에서 지원
• MSA도입이 ‘목표’가 아닌 Biz Agility 를 위한 수단
• 결국 가장 중요한 것은 MSA를 도입하려는 조직의 문화(공감대)