01.OK ! Stangler Pattern 변화를 위한 기술 조건은 ?
MSA를 해야 하는 이유를 살펴 보았다 http://web.joang.com:8083/books/01-why
그러면 MSA를 하기위한 조건은 어떻게 되는가 ?
첫째로 우리는 마이크로한 서비스로 우리의 시스템을 재편해야 하고, 그러한 마이크로한 서비스는 하나의 서버로 구성(Pod)될 것이다. 그리고 그러한 하나하나의 서비스에 일정한 분량의 인프라 자원을 할당해야 하고 그리고 무수히 만들어지는 서비스를을 유지적으로 관리할 수 있는 환경을 구축해야 한다.
1. 그럼 모노로틱한 서비스를 마이크로한 서비스로 분리할 때 마이크로 서비스는 어떻게 나누어질 수 있을까 ?
모노로틱한 개발은 명시적이고 가시적이고 온전한 개발에 용이하다 . 우리가 모노로틱한 개발에서 마이크로서비스로 전환하고자하는 것은 모노로틱 애플리케이션의 한계 때문이다.
어떻게 나눌것인가 ? 결론부터 말하자면 나누지 말자 이다. 너무도 명시적인 분리가 사실 모노로틱에 존재한다.
우선은 오랜 세월과 개발 관계에서 자연스럽게 만들어진 코웨이의 법칙을 인정하자 그리고 그것이 우리 조직과 운영에 최적이라는 사실을 용감하게 인정하고 시작하자
마이크로소프트 ㅋㅋ
그리고 그 과정을 통하여 마이크로서비스를 구축한다 . 우선은 운영성을 고려하고 안전한 마이크로서비스로의 전환을 만든다.
이제 다소 거북한 마이크로서비스에 대한 부담이 느껴진다면 과감하게 시작하면 될것이다.
마이크로서비스 저니 Journey to Microservices.pptx
2. 마이크로 서비스들이 하나 둘이면 크게 문제가 될 여지는 없지만, 마이크로서비스가 100여개가 넘어갈 때 어떻게 해야 하는가 ?
상기한 바와 같이 이제 콘테이너라고 하는 놈들이 많아질 것이다. 더불이 콘테이너 뿐만 아니라 콘테이너에 외부 호출을 연결하여 주는 네트워크까지 복잡하게 고려를 해야 한다.
한때 XX면제점에서 Docker 기반으로 개발을 하였을 때, 내가 비관적으로 보았던 이유 중의 하나가 콘테이너를 관리하는 것이 없이 저렇게 많은 node들에 docker run을 하는 것이 맞는가 하는 것이었다.
이후 내가 XX카드사의 채널과 기간계를 구축하면서 콘테이너 플랫폼인 OCP의 덕을 톡톡히 보기는 하였다. 이후로 PaaS 구축의 전도사가 되었다.
각각의 Pod들은 서로 다른 리소스를 사용하고 각각의 라이프 사이클과 더불어 기획 개발 테스트 운영의 주체가 별도로 구성되어 진다.
네오(키아누리브스)가 잘싸웠지만 스미스 요원은 우리를 경악하게 하였다 네오는 PaaS 였으면 굳이 힘들지 않았을 텐데 싶다. 동양은 송오공의 머리키락일텐데, 사실 황당하지만 오래전부터 사실 누구나 그랬으면 싶은게 분신사바 기술이 아닐까 한다.
3. 이제 마이크로한 서비스는 비교적 모노로틱한 서비스에 비하여 작게 나누어 지는데 그럼 작은 Linux 서버나 UNIX 서버를 그때 그때 사야 하는가 ?
이제 모든게 준비되었다면 그 작은 콘테이너가 독자적으로 동작할 수 있는 환경의 자원이 필요하다.
그때 그때 작은 자원의 활당과 회수 그리고 확장에 용이한 구조의 리소스 자원 관리는 무엇인가 ?
당연히 누구나 예측할 수 있는 클라우드 환경이다. 클라우드 환경은 아래와 같이 다양한 클라우드가 존재하고 , 기업에서는 가장 적합한 환경의 클라우드를 구축하면 된다.
4. 주의할 점
마이크로서비스는 역설적이게도 마이크로서비스로 만들지 말라는 것이다 . 즉 모노로틱한 서비스를 나누어 효율적으로 진화해 나가는 것이 마이크로서비스이기 때문에 미리 진화한 모습으로 만들지 말자 어떻게 진화할 지 모르는데 ... 단 아주 중요한 것은 모노로틱하게 우선 만들더라도 인터페이스를 활용하여 호출하는 형태로 나들라는 것이다 그래야 마이크로로 진화하는데 용이하다.
둘째 마이크로서비스는 결코 마이크로만하지 않다는 것이다. 고정관념을 가지고 작은 것으로 나누는 것이 효율적이라는 선부른 생각은 버려야한다. 결코 마이크로서비스가 작은 단위의 서비스가 아니라는 것이다.
Netflix가 되지 말아야 합니다. 우리 회사가 Netflix 는 아니니까
