API GW, LB, Conway's Law, SOA, DevOps, Docker, DDD, EDA, Agile
마이크로서비스/모노리틱
[개념] 하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능한 아키텍처
[특징] API G/W(End Point통합), REST API(병렬처리)
[구성] WebUI,Mobile,3th Party>API G/W>RestAPI>User
[기술] Rest API 일반화, 도커(컨테이너 기술), 클라우드 컴퓨팅
1)아키텍처: Polygon 아키텍처(서비스 목적별 언어,플랫폼 선택)
2)수직분할:배치,분산
3)표준 API G/W:End-Point 통합
4)RESTful, Async:병렬지원
[구조] 서비스 컴포넌트화, 분산거버넌스, 분산데이터, 연계조직, 프로덕트지향
[요청처리] Web UI>API G/W>서비스(사용자,뉴스,메일,광고) (병렬처리가능)
[필요 체크리스트]
1)애플리케이션 배포 1시간 이상 소요
2)단순한 기능 수정시 전체기능 QA 필요
3)단순버그 수정으로 인한 중대한 버그 발생빈도 상승
4)애플리케이션 기능별 추상화시 수십개 서비스 분할가능
[단점] 서비스 간의 통신처리 추가, 관리포인트 증가,배포 자동화 필수
[고려] 요청 메시지 선후관계(비동기,콜백), 분산서버상태파악, 기존결과 캐싱재활용필요
마이크로서비스 도입, 기술보다 문화가 관건
마이크로서비스는 과거 대형 IT시스템에서 돌아가던 애플리케이션을 목적별로 쪼개 독립적으로 동작케 만든 구성요소를 가리킨다. 구성요소를 조합해 필요한 애플리케이션을 유연하고 빠르게 만들어내고 이를 통한 혁신과 비즈니스 성장을 거둔 사례로 아마존과 넷플릭스가 꼽힌다.
조직이 마이크로서비스의 이점인 빠른 SW개발 속도와 높은 안정성을 얻으려면 파이프라인 구축, 조율된 배포, 진행중 업무 감축, 3가지를 추구해야 한다고 지적했다.
"우선 코드를 개발한 다음 정확성, 의존성, 스타일 등을 종합 검토하고 테스트하는 파이프라인이 구축돼야 한다. API를 개발하고 관리하는 전체 생애주기를 아우르는 툴은 이 조건을 충족한다. 또 다양한 단계의 테스트를 높은 수준으로 자동화해 배포 안정성과 전체 SW품질을 높여야 한다. 마지막으로 진행중인 작업(work in progress)을 줄여야 한다. 단순한 개념이지만 실행하긴 쉽지 않고 대기업에선 특히 어렵다."
(http://m.zdnet.co.kr/news_view.asp?article_id=20171213144854#imadnews)
각 마이크로서비스는 독립돼 있다. 마이크로서비스는 데이터 계층을 공유하지 않는다. 각자의 데이터베이스와 로드 밸런스를 가지고 있다. 이런 ‘분리’가 마이크로서비스 아키텍처의 핵심 요소다. 마이크로서비스마다 각기 다른 스케일링 기법이 필요하다.
마이크로서비스와 콘테이너, PaaS의 관계
만약 애플리케이션을 독립적이며, 독립적으로 확장이 되는 작은 ‘비트’ 크기의 애플리케이션으로 분리하려 한다면, 그런데 이 ‘비트’ 크기의 애플리케이션이 PaaS 환경에 적합한 경우가 아주 많다.
마이크로서비스와 SOA의 관계
표면적으로 SOA는 SOAP 및 XML-RPC로 연결되고, 마이크로서비스는 JSON으로 연결된다.
SOA는 엔터프라이즈 서비스 버스를 사용하고, 마이크로서비스는 가벼운 Pub-sub 서비스 버스를 사용한다.
마이크로서비스 아키텍처와 SOA의 가장 큰 차이점은 마이크로서비스의 경우 독립적으로 배포할 수 있어야 하지만, SOA 서비스는 모놀리식으로 구현되는 경우가 많다는 것이다
하지만 모든 아키텍처가 ‘강점’과 ‘약점’을 갖고 있기 마련이다.
장점이 확실한 마이크로서비스 아키텍처도 다루기 힘든 고유의 문제점이 있다.
분산되고 느슨하게 연결된 애플리케이션의 로깅, 모니터링, 테스트, 디버깅 문제가 대표적이다.
(http://www.ciokorea.com/news/36479)
마이크로 서비스로 구성된 시스템에서는 서비스간 호출이 많이 발생하는데 이들 서비스간 호출하는데 있어 다양한 프로토콜을 사용할 수 있습니다. 제가 운영하는 서비스에서는 HTTP 기반으로 호출하고 데이터는 JSON 형태로 인터페이스를 하고 있습니다. 마이크로 서비스에서 서비스간 호출에 있어 조심해야 할 사항 중에 하나가 Connection Pool을 사용하지 않고 Socket을 지속적으로 만들고 Close 하는 것입니다.
얼핏 생각하면 Connection Pool을 사용하는 것과 사용하지 않는 것의 차이는 네트워크 연결 비용이 조금 더 들어 처리 속도가 조금 느려 진다는 정도만 생각할 수 있습니다. 저도 이번 테스트를 수행하기 전에 이런 생각을 가지고 있었는데 Connection Pool을 사용하지 않으면 서버 자체에 문제를 줄 수 있다는 것을 알게 되었습니다.
모노리틱 서비스 아키텍처
마이크로 서비스 아키텍처
'02.SW' 카테고리의 다른 글
프로젝트 관리 - 공공 SW - SW 산업 진흥법 (3) | 2024.10.13 |
---|---|
SW 품질 - GS 인증 (3) | 2024.09.24 |
지능형 로봇 - RPA (Robotic Process Automation, 공정 자동화) (8) | 2024.09.03 |
정보보안 - 융합보안 (7) | 2024.09.03 |
로우 코드(Low Code), 노 코드(No Code) (6) | 2024.07.31 |