블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

마이크로서비스 아키텍쳐에 대한 소고



간만에 낚시성 제목을 달아봤는데, MSA (마이크로 서비스 아키텍쳐)가 필수라는 이야기는 꼭 틀린말이라고 볼 수 는 없습니다. 특히나 개발팀의 규모가 큰 경우나, 지리적으로 개발팀이 나눠져 있는 경우에는 서비스 단위로 나눠서 각 팀이 서비스를 개발하고, 독립된 기술과 개발 체계를 가지면서 빠르게 개발해 나가는게 효율적이기 때문에, 규모가 어느정도 되는 팀에서는 효율성이 높습니다.


중앙에서 통제할 필요 없이, 각자가 알아서 설계하고, 만들고, 테스트 하고 운영하기 때문입니다.

이것을 분산 거버넌스라고 하는데, 관리나 의사결정의 권한을 중앙의 팀이 중앙 통제하지 않고, 각자의 팀에 자율적으로 맏기고, 책임도 맏긴다는 이야기 입니다.


그러면 분산 거버넌스를 하면,중앙 거버넌스가 필요하지 않냐?


MSA글을 보면, 보통 분산 거버넌스와 이에 대한 필요성과 장점에 대해서만 이야기를 한다.

그러나, MSA에 과연 중앙 거버넌스가 필요하지 않을까?


개인적인 생각으로는 이 또한 강한 중앙 거버넌스가 필요하다.

첫번째로, API로 서비스를 제공하기 위해서는 API 표준이 맞아야 한다. 헤더 구조, URI 컨벤션, Granuality (서비스 크기), 에러 추적을 위한 로깅 메세지의 표준화가 필요하다.

두번째로, 서비스의 기능에 대해서, 어떤 기능이 필요한지, 필요하다면 기능이 어떤 동작을 어떻게 하는지에 대한 정확한 스펙에 대한 정의가 필요하다 이건 서비스를 제공하는 팀 보다는 서비스를 사용하는 팀 입장에서 해야 한다.

세번째로, 이러한 서비스를 엮을려면, 필요에 따라서 aggregation API를 만들거나 또는 서비스 자체에 기능을 추가해야 하는데, 팀 이기주의로 인하여 타팀으로 일을 떠넘기는 현상이 생길 수 있기 때문에 중앙에서 이를 조율할 필요가 있다.


실제로 MSA와 유사한 구조로 서비스를 개발해본 경험으로 보면, 이러한 중앙 통제가 필요하고 거기에 드는 추가적인 비용 (코디네이션/조율)이 만만하지 않다.


또한 다른 문제점중의 하나는 각 서비스팀별 개발 수준이나 품질 수준이 다르기 때문에, 기능을 추가하고자 할때도 어느 서비스(즉 팀으로 보낼것인가)를 고민해야 한다는 것이다.


MSA의 도입은, 각 서비스 개발팀의 수준이 높아야 권한을 분산할 수 있고, 또한 중앙집중형 거버넌스 조직을 통해서 표준화등이 강력하게 이루어져야 한다.


결론적으로 난이도가 높은 아키텍쳐 스타일이라는 이야기이고, 전사 개발팀 차원에서의 많은 투자가 필요할듯 하다.


SSAG에서 토론글 중, 홍성진님이 재미있는 링크를 올려주셔서 첨부합니다

http://siliconangle.com/furrier/2011/10/12/google-engineer-accidently-shares-his-internal-memo-about-google-platform/


2009년 기술 전망

엔터프라이즈 솔루션 | 2009.01.06 09:42 | Posted by 조대협

1. Cloud and grid computing

클라우드 컴퓨팅과 이를 구현하기 위한 솔루션인 그리드 컴퓨팅은 금년에도 이슈가 될것같다.

구글이나 야후, 아마존들을 중심으로 한 글로벌 서비스 기업들이 그리드와 클라우드 컴퓨팅에 선두가 되고 있지만

정작, 기업에 있어서 클라우드 컴퓨팅이나 그리드 컴퓨팅의 도입은 소극적이다. 특히 클라우드 컴퓨팅의 경우

보안이나 성능상의 이슈로 기업에 도입이 될지 않될지는 지켜봐야 할것 같지만

그리드 컴퓨팅의 경우 Coherence와 같은 Data Grid제품이나, Hadoop과 같은 File grid, grid dbms등은 기업에도 충분히 사용이 가능한 솔루션이다. 얼마나 기업 고객들이 이 개념들을 이해하고 적응하느냐가 관건일테고, 다른 한축으로는 대부분의 그리드 솔루션이 오픈 소스로 구축 된 경우가 많기 때문에 기업의 오픈 소스에 대한 반감을 어떻게 풀어내느냐도 하나의 숙제가 될것이다.

 

2. Virtualization

여기서 언급하고자 하는 가상화는 특히 서버의 자원 가상화이다. 여러개의 CPU와 메모리가 있는 장비를 Partition해서 사용함으로써 자원의 효율성을 극대화 시키는 기술인데.

예를 들면 이전에 2 CPU 서버 3대로 3개의 업무를 하고 있다고 했을때, 1서버의 평균 CPU 사용률이 1.2 2서버 1.5, 3서버 1.5라고 했을때 이렇게 되면 총 6개의 CPU가 있지만, 사용되는 CPU수는 실제로는 4.2이다. 가상화를 사용하게 되면, 하나의 큰 서버에 CPU 사용률을 상황에 따라서 배정할 수 있기 때문에 초기에 5장의 CPU로도 충분히 운영이 가능하게 된다 또한, 갑자기 부하량이 늘어나는 경우에는 여분의 CPU를 해당 업무에 할당 할 수 있기 때문에 자원활용의 유연성을 더할 수 있다.

 

가상화의 다른 특징중의 하나는 가상화된 환경과 애플리케이션을 이미지로 관리하기 때문에, 쉽게 다른 하드웨어 환경으로 배포가 가능하다는 것이다. 이는 SM관점에서 많은 장점을 가질 수 있게 된다.

 

3. Saas,Pass,Iass

Saas (Software as a service)는 이미들 많이 사용되는 컨셉이고 내년에는 Iaas와 Pass가 화두가 되지 않을까?

Iaas(Infrastructure as a service)는 OS,CPU,메모리,디스크와 같은 자원을 서비스로 제공하는 형태이다. 이미 아마존이 Message Q, OS,Disk,DBMS등에 대해서 E3라는 형태의 서비스로 Iaas 서비스를 제공하고 있다. 단기적으로 컴퓨팅 파워가 필요한 캠페인이나, CPU가 많이 필요한 3D 렌더링 작업들에는 매우 유용하게 사용될 수 있고, IDC 센터가 세계에 나눠져 있기 때문에, 여러 위치에서 테스트가 필요한 경우 유용하게 사용할 수 있다.

이미 아마존 E3 서비스에서는 OS별로 이미지를 만들어서 업로드하면 수행할 수 있도록 되어 있다.

다음으로는 Pass (Platform as a service)가 있는데, 플랫폼을 서비스로 제공하는 것이다. Open API도 일종의 Pass가 될 수 있고, Google의 Android 플랫폼 (OS+Open API환경,애플리케이션 Store)나 Apple의 AppStore도 일종의 Pass가 될 수 있다. 이러한 Paas가 Iaas와 결합하면서, 무제한적인 자원(Iass)을 유연성있게 제공받을 수 있으며, 그위에 Pass를 구현함으로써 개발자들에게 Application을 개발할 수 있는 플랫폼을 제공한다. 이 Pass를 이용하여 소프트웨어가 개발되고 일반 사용자에게 서비스되는 형태가 Saas로 될 수 있다.

사실 한국에서는 이 3가지에 대해서 움직임이 매우 늦은게 사실이다. 이 3가지 기술들은 주로 Google,Amazon과 같은 서비스 업체들의 주도로 시장이 움직여가고 있는데, 우리나라의 N이나, D사의 경우 이 부분에 있어서 아주 초보적인 단계에 밖에 이르지 못했다.

 

국내에서도 Service Platform이라는 형태로 기업 내부의 유용한 자원을 Open API화하여 밖으로 서비스하려는 움직임이 있는데, 이런 움직임이 Pass와 같은 서비스 형태로 구현되었으면 한다.

 

4. REST

작년의 하나의 화두중에 하나가 REST였다. Roy Fielding의 논문에서 소개된 아키텍쳐 스타일로 웹의 장점과 인프라를 최대한 활용한다는 개념에서 출발하였다.

 

문제는 REST는 사실상의 표준이 없다. Google이나 Amazon이 주도하는 Defactor 표준 (암묵적인 표준)은 있지만 Spec과 같은 표준이 없기 때문에, 기업에서 사용할 경우 관리(Gorverning)이 어렵다. Google이나 Amazon의 경우 자체 개발 조직과 관리 조직을 가지고 있기 때문에, 잘 관리된 형태로 REST 서비스를 제공 및 사용하고 있지만, 기업내에서 REST가 얼마나 힘을 발휘할 수 있을지 미지수다. WebService를 사용해보고 REST도 모두 사용해봤지만 개발 관점에서 드는 Burden은 REST라고 결코 낮지는 않다. WebService의 경우 이미 Infra가 잘되어 있고 개발툴이나 자동화 스크립트가 많기 때문에 실제로 JAX-WS와 같은 개발 표준을 따를 경우 개발 공수가 사실 매우 낮은 것이 사실이다.

 

국내 상황을 보면 아쉽게도, Open API를 서비스 하는 포탈에도 REST를 지원하는 업체는 없는 것으로 안다. 또한 REST의 이해도 자체도 상당히 떨어지는데 HTTP + POX (Plain Old XML)은 REST가 아니다. 대부분 XML-RPC형태를 띄는데, REST는 Resource를 정의하고, Resource 지향적인 아키텍쳐로 설계되어야 하며, 사람이 직관적으로 이해하고 쉽고, Link등을 통해서 Resource간의 관계를 정의하고 Resource의 다음 상태 전이에 대한 정의 능력등이 있어야 한다.

국내 BLOG에 올라오는 글들을 보면 Jersey나 Apache CXF등을 이용하여 REST를 구현하는 샘플이나 예제는 종종 올라오지만, REST를 아키텍쳐 관점에서 접근하는 글은 매우 드문 것 같다. (아직까지는 못봤다.)

 

어쨌거나, REST가 JAX-RS로 JSR311 표준으로 등록되었고, WSDL 2.0에도 REST가 반영되었기 때문에, REST의 영향력이 커진 것은 기정사실이고, Amazon도 기존의 Open API를 서서히 REST형식으로 바꾸겠다니 Service World에서는 대세인 것은 분명하나 기업 아키텍쳐에서 얼마나 힘을 발휘할지는 지켜봐야할 사항이다.

 

5. SOA Governance

SOA는 어떻게 보면 양극화가 발생하는 듯한 인상인데, 이미 SOA에 적응한 기업은 SOA에 대한 성숙도를 높이기 위한 해가 될테이고 아직도 SOA를 시작하지 못한 기업은 이미 어느정도 성숙된 SOA 플랫폼과 개념을 바탕으로 SOA를 시작할것이다.

공통점은 이미 여러 SOA 프로젝트를 통해서 거버넌스의 중요성이 인식되었기 때문에 무엇보다 거버넌스에 많은 집중을 할 해가 될것이라고 생각되며 REST의 영향을 받아서 Restful webservice 기반의 SOA가 시험될 해라고 생각된다.

 

6. Mobile platform

모바일 플랫폼에 대해서는 더 이상 말할 필요가 없을 것 같다. Google의 Android, Apple의 AppStore, Nokia의 모바일 플랫폼에 이어서 MS나 기타 모바일 업체도 일반 개발자들에게 개발 환경을 오픈함으로써 User created contents(application)을 생산하게 하고 이 과정에서 수익을 창출하는 비즈니스 모델이 유행이 될것이다. 아마 금년은 이 모바일 플랫폼의 최고 격전의 해가 되지 않을까?

 

7. Collaboration

협업에 대해서는 ALM과 Agile 방법론이 금년에도 작년에 이어서 크게 유행할것이고 좀더 실용적이고 실질적인 개발 및 협업 프로세스의 발전과 이를 구현하는 도구들이 사용될 것이다. 작년에 비해서 크게 변화한 점이 있기 보다는 좀더 성숙된 형태로 발전하는 해가 되지 않을까 싶다.

 

'엔터프라이즈 솔루션' 카테고리의 다른 글

Apache Camel note  (0) 2013.02.12
아키텍쳐에 있어서 레퍼런스의 중요성  (2) 2009.10.20
2009년 기술 전망  (2) 2009.01.06

SOA 가 어려운 이유..

아키텍쳐 /SOA | 2008.11.12 15:00 | Posted by 조대협
SOA가 나온지도 오래되었고 개념이 좋다는 것은 다들 인정하고 있지만 쉽게 확산 되지 않는 이유가 무엇일까?
결과부터 따져보자면

성공적인 SOA<-- 성공적인 거버넌스 <-- 강력한 파워와 조직

SOA는 기업의 모든 업무를 서비스화하여 재 사용하고자 하는 아키텍쳐이다. 단순한 프로젝트처럼 단기간에 끝낼 수 있는 것도 아니고, 한팀이나 TF형식으로 만들고 끝날 수 있는 것이 아니라. 장기적인 관점에서 소프트웨어 컴포넌트를 서비스화하여 자산화 하고, 이 자산을 재 사용해야 한다.

그러기 위해서 가장 중요한 것이 장기적인 계획을 세우고 각 비니지스 업무 부서를 조율하여 서비스를 생성 및 관리하고 조합하여 업무에 반영 하는 역할을 할 수 있는 것!!이 필요하다.
이 "것" 이 거버넌스 인데. 거버넌스는 전체 SOA를 통제할 수 있는 조직과, 프로세스, 그리고 이것을 뒷받침해줄 플랫폼이 포함된다. 물론 여기에 돈이나 시간도 들어가겠지만 가장 중요한것은 이 3가지인데...
대부분의 실패한 SOA의 문제점을 이 거버넌스에서 생각해볼 수 있다.

  • 거버넌스 조직 구성 부터 생각해보면, 거버넌스 조직은 SOA를 수행할 만한 기술과 업무에 대한 전문적인 지식과 함께, 각 비지니스 부서를 통제할 수 있는 POWER가 있어야 한다. 거버넌스의 실무 인원들이 그런 POWER를 가지기는  불가능하고, 거버넌스 조직의 LEADER가 결국 그 힘을 주는 것인데.. SOA 거버넌스 모델에서는 그런 사람을 BACKER라고 한다. 한국말로 하면 빽..!! 거버넌스 조직이 실력과 이만한 파워를 갖춰야 각 업무 부서를 통제하고 서비스를 착착 만들어 나갈텐데.. 이것이 안되니 SOA가 제대로 될리가 있나?? 보통 이런 조직은 기업에서는 CIO 산하의 정보전략이 리딩을 하는게 하는것이 맞는데.. 정보전략이 그만한 힘이 없거나 또는 그만한 전문성이 없거나 단기적인 프로젝트에 집중할때 문제가 생긴다.
SOA 프로젝트가 다른 프로젝트와 틀린것은 기존 프로젝트는 하나의 비지니스 업무에 대해서 한 LOB에서 단기간에 시스템을 구축하면 끝났지만, SOA는 전사적으로 아키텍쳐가 설정되어야 하고 거버넌스 조직에 의한 전략에 따라서 LOB 간의 협업이 중요한데.. 사람이 하는일이니 쉽지 않은가 보다.
  • 프로세스 측면에서는, 프로세스가 현실과 동떨어져 있는 경우가 많다. RUP가 거버넌스 프로세스는 아니지만 예를 들어보면 좋은 방법론과 프로세스임에는 확실하지만 무겁고 이해하기가 어렵다. LOB별이나 직원별의 기술 수준이 다르기 때문에 프로세스에 대한 적응도가 떨어질 수 밖에 없고 있는 거버넌스의 실패 그리고 통제의 실패와 프로젝트의 실패로 연결이 된다. 그러면 어떻게 해야 하나? 프로세스는 가볍고 이해하기 편해야 한다. 커뮤니케이션 파이프라인은 되도록이면 짧아야 한다. 내 경우에는 감히 "하향 평준화"를 하라고 이야기 하고 싶다.
  • 시스템 관점에서 보면, 거버넌스 시스템의 예로 PPMS(프로젝트 관리도구), SCM(형상 관리 도구) 등이 있지만!! 실제 프로젝트를 보면 툴 따로 실제 업무 따로인경우가 많다. 툴은 업무를 돕는것이지 툴에 업무를 맞추는게 아니다. 물론 툴이 무지 좋다면 그것도 방법은 되겠지만...
사실 거버넌스의 실패가 SOA에만 해당되는 이야기는 아니다. 일반 프로젝트도 거버넌스의 실패가 대부분의 실패 요인이 되니까는 그럼에도 불구하고 SOA에서 거버넌스의 중요성을 언급한것은 위에서도 이야기 했지만, SOA는 장기적이고 여러 부서에 걸쳐 있는 프로젝트이기 때문에 무엇보다도 통제가 중요하기 때문이다..

이글을 썼다가 날라가서 다시썼는데.. 내용이 좀 꼬이는듯 하네..

'아키텍쳐  > SOA' 카테고리의 다른 글

OMG released SOAML draft  (0) 2009.01.16
Composition 과 Mashup의 차이  (0) 2008.11.13
SOA 가 어려운 이유..  (0) 2008.11.12
관심이 가는 오라클 제품들  (0) 2008.10.15
2008년 SOA 전망  (0) 2008.01.10
Next Enterprise  (0) 2007.12.21