* 지난번 아래 책 소개글을 많이 읽어주셔서 이번에도 간략한 글을 올립니다.
독서의 계절을 위한, '추리소설' 이야기와 추천작 ...(https://www.clien.net/service/board/lecture/16532781CLIEN)
* 이 글은 출판사와는 전혀 관계없으며, 개인적인 책소개 글입니다.
좋은 책은 친구를 찾는 것 만큼 힘든 일이므로, 혹시 도움이 될실 분이 있을까 해서 작성해 봅니다.
( 출처 : https://soosun.tistory.com/1254 )
당연하겠지만 'SW개발'이라는 직업은 오랜동안 개발자들을 울고 웃게 해왔습니다.
특히나 취미가 아닌 직업으로서의 SW개발은 사실 그리 만만하게 볼 일이 아닙니다.
최근 다양한 오픈소스, 개발을 직접적으로 도와주는 프레임워크, 성능 좋은 개발 언어와 툴 등이 등장하여
마치, SW개발이란 것이 아주 쉽고 재미있는 것으로만 여겨지는 부작용도 있지만, 실제 직업으로서 회사 개발조직에 소속되어 SW개발을 한다는 것은 여전히 어렵고 힘든 일입니다.
이런 SW개발자들에게는 숙명처럼, 새로운 기술 트렌드에 대한 학습이라는 숙제가 따라 다닙니다. 나이, 직급, 도메인, 역할 등과 관계없이 항상 학습해야 하고 이를 개발업무에 적용해야 합니다.
소개된지는 어느정도 시간이 지났지만, 최근에 다시 유행을 타고 있는 것들, 오늘은 그 중 하나인 MSA와 관련된 책들을 소개하려고 합니다. (SW분야는 특히 새로운 기술이 등장하면 너무 빠르게 일반화가 되어, 그 의미나 내용을 명확하게 모르고 지나갈때가 많습니다.
이럴때는 바쁘더라도 잠시 시간을 할애하여 책을 통해 한번쯤 정리를 하는 것도 좋은 방법이며, 그래야 자기 것이됩니다.)
대부분 이미 아시는 내용이겠지만, MSA를 정리하려면 다음과 같은 몇가지 토픽 정도는 이해하고 있어야 합니다.
(이 글은 책소개 글이므로 아래의 내용을 정리해주는 것은 범위를 벗어나는 일이니 skip 합니다....)
- MSA ?
- Cloud Native ?
- Monolithic & Micro Service Architecture ?
- MSA & SOA ?
집 책장을 뒤져보니, 위 토픽과 관련해서 아직 버리지 않고 소장하고 있는 책들이 몇권 있었습니다.
- 'SOA, WHAT & HOW', 2008년, 전병선 지음
- SOA와 CBD는 뭐가 다르지?, 비지니스 민첩성을 위해 SOA 개념과 아키텍처 설계 방법에 대해 설명 - 'SOA 서비스 지향 아키텍처', 2006년, 토마스 얼 지음
- SOA 패턴, 설계방법, 구축방법 등 전반에 걸친 내용을 사례와 함게 설명하는 내용 - '클라우드 컴퓨팅 애플리케이션 아키텍처', 2010년, 조지 리스 지음
- Salesforce.com과 같은 서비스를 AWS에서 제공하기 위한 준비, 개발, 인프라, 보안, 장애 등 전체적인 내용 소개

이 책들의 서문과 목차를 읽어보면, 우리가 지금 고민하고 있는 것과 크게 다르지 않은 이야기들로 가득합니다.
(역시 유행은 되풀이 되는 것인가...결국 분산과 통합인가?)
물론 그에 대한 해법도 머 크게 다르지 않은 것 같기도 하고...
이제 최근에 읽었던 MSA 관련책들을 소개합니다.
어느날 갑자기 MSA를 제대로 정리해보자는 생각에, 온라인 강의도 듣고 글로벌 유명 IT기업들의 자료들도 읽어보고,
정부에서 발표한 NIA의 전자정부 'MSA 기반의 표준프레임워크' 자료들도 학습해보았으나,
무엇이가 2% 부족함을 느껴 관련 책들을 구입해보았습니다. (그만큼 체계적인 정리나, 다양한 의견들이 있다는 반증인가?)
- '마이크로서비스 아키텍처', 2019년, 우메쉬 램 샤르마 지음
- '그림으로 공부하는 마이크로서비스 구조', 2022년, 다루사와 히로유키 외
- '클라우드 네이티브 애플리케이션 디자인 패턴', 2022년, 카순 외
- '마이크로서비스 아키텍처 구축(전면 개정판)', 2023년, 샘 뉴먼

「 '마이크로서비스 아키텍처', 2019년, 우메쉬 램 샤르마 지음 」
ㅇ 책의 주요 내용
- 이 책은 MSA 이전 프로젝트를 하고 있는 저자가,
MSA개념에서 다른 아키텍처와의 비교, 장단점, 기본 구조, 통신, 보안,데이터 모델, 테스트와 베포, 모니터링과 문제해결 방안 등 MSA 프로젝트를 진행하기 위해 필요한 부분들을 설명해주고 있습니다.
- 책 전반에 걸쳐 '신용 리스크 엔진'이라는 Java기반의 샘플 프로젝트를 이용하여 MSA 적용 과정을 설명합니다.
- 각 챕터는 "개념설명 -> 필요항목들 정의 -> 샘플 소스 설명 -> 내용 요약" 등의 절차로 구성되어 있습니다.
- 기존 시스템의 MSA 전환, 장애와 모티터링, 문제해결 등의 실무적인 내용이 잘 정리되어 있으나, 디테일한 부분은 약간 부족합니다.
=> 페이지는(약 290 페이지) 조금 많으나 샘플코드와 간략한 단락들로 구성되어 상대적으로 부담이 많지는 않은 편으로,
난이도 있는 내용보다는 MSA 프로젝트 진행을 간략하게 경험해보기에 좋은 책인 것 같습니다.
ㅇ 목차
1장. 마이크로서비스 아키텍처 소개
2장. 마이크로서비스 컴포넌트 정의
3장. 마이크로서비스와 엔드포인트 간의 통신
4장. 마이크로서비스 엔드포인트 보안
5장. 효과적인 데이터 모델 만들기
6장. 마이크로서비스 테스트
7장. 마이크로서비스 배포
8장. 기존 시스템을 마이크로서비스로 진화시키기
9장. 모니터링과 확장
10장. 장애 해결
「 '그림으로 공부하는 마이크로서비스 구조', 2022년, 다루사와 히로유키 외 」
ㅇ 책의 주요 내용
- 이 책을 보고 사실 조금 놀랐습니다. 일본 IBM 이야기가 잠깐 나오지만, 현업 경험을 바탕으로 한 저자의 다양한 생각과 지식들에, 그리고 MSA의 큰 틀과 다른 IT 트랜들 들과의 관계를 논리적으로 설명하려고 하는 노력 등
제목보다 가치있는, 어쩌면 제목 때문에 손해보는 책 이기 때문인 것 같습니다.('그림~' 이런 제목의 책들은 보통 그냥지나치는 경우가..)
MSA를 DX, DevOps와 연계해서 전체적인 이해를 하고자 하는 분들에게 많은 도움이 될 책이며,
쉽게 정리하는데 많은 도움이 되었고, 오랜만에 재미있게 읽었던 것 같습니다.
- 특히, 각 챕터에 개념을 쉽게 설명하려는 용도의 구성도와 요약 메세지를 박스로 정리를 해두었는데. 이게 생각보다 이해에 도움이 됩니다.
- 약 230페이지 정도로 많지 않은 분량에 디지털 전환, 아키텍처 설명, 패턴, 클라우드 네이티브 등 내용들을 짧지만 알차게 구성한 점이 장점이다. 물론 이런 특성으로 디테일은 약간 부족하지만 전체적인 현업의 분위기를 익히는데 도움이 주고 있습니다.
=> 어떻게 보면 첫번째 책을 요약한 듯한 느낌을 주지만, 약간 IT 테크니컬 컨설팅인 듯한 설명인 듯 합니다.
첫장에 DX(디지털트렌스포메이션) 내용이 나오는 것도 다른 책에 없는 특이한 점이다. 다이제스트북으로 추천할만 합니다.
ㅇ 목차
제1부 마이크로서비스의 아키텍처
CHAPTER 1 디지털 전환: 마이크로서비스가 중요해진 배경 3
CHAPTER 2 클라우드 네이티브 컴퓨팅과 마이크로서비스 15
CHAPTER 3 마이크로서비스 아키텍처의 기본 43
CHAPTER 4 마이크로서비스 패턴 65
제2부 마이크로서비스를 지탱하는 클라우드 네이티브 기술
CHAPTER 5 컨테이너, 쿠버네티스, 서버리스 121
CHAPTER 6 서비스 메시 161
CHAPTER 7 마이크로서비스의 개발과 운영 185
CHAPTER 8 클라우드 배포 모델 동향 213
「 '클라우드 네이티브 애플리케이션 디자인 패턴', 2022년, 카순 외 」
ㅇ 책의 주요 내용
- 서두에서 이야기한 것처럼 클라우드 네이티브 환경에서는 MSA가 필수이기 때문에, 이책의 제목에 MSA가 들어 있지 않아도 내용의 대부분은 MSA 아키텍처의 디자인 패턴에 대해 다루고 있습니다.
- 첫 챕터에 SOA와 MSA의 구조적 차이점에 대해 언급되고 있으며, 이후는 아래의 목차처럼 다양한 디자인 패턴들로 이루어져 있습니다.
- 특히, "정의 - 어떻게 동작할까요 - 어떻게 사용할수 있나요 - 고려해야할 사항들 - 관련 패턴들"의 포맷으로 각 패턴들을 설명하고 있는 점이 특징
- 디자인 패턴에 대한 개념적 설명이 주된 내용이고 샘플코드 등은 제공하지 않습니다.
=> 전체적으로 클라우드 네이티브 환경에서 MSA 기반의 어플리케이션 설계 패턴들에 대한 개념 설명에 집중합니다.
디자인 패턴 정리가 필요한 개발자들, 특히 아키텍트들에게 참고가 될만한 구성입니다.
ㅇ 목차
CHAPTER 1 클라우드 네이티브 애플리케이션이란?
CHAPTER 2 통신 패턴
CHAPTER 3 연결성 및 조합 패턴
CHAPTER 4 데이터 관리 패턴
CHAPTER 5 이벤트 주도 아키텍처 패턴
CHAPTER 6 스트림 프로세싱 패턴
CHAPTER 7 API 관리 및 사용 패턴
CHAPTER 8 클라우드 네이티브 패턴 적용하기
「 '마이크로서비스 아키텍처 구축(전면 개정판)', 2023년, 샘 뉴먼 」
ㅇ 책의 주요 내용
- 이 책은 MSA관련하여 가장 유명한 책들 중에 하나로 아래는 출판사 책소개 문구입니다.
"마틴 파울러가 극찬한 『마이크로서비스 아키텍처 구축』이 전면 개정되어 돌아왔다. 마이크로서비스와 관련된 모든 측면에 대해 광범위한 개요를 제공하고자 했다. ~ 1부에서는 마이크로서비스의 핵심 아이디어를 설명하고, 2부에서는 개념에서 구현 상세로 넘어가 마이크로서비스를 활용하는 데 도움이 되는 기법과 기술을 살펴본다. 마지막으로 3부에서는 1부, 2부에서 배운 내용을 토대로 사람과 조직의 입장에서 기술을 구현해내는 과정을 설명한다.(출처: 한빛미디어 출판사 소개문)"
- 최근에 읽었던 MSA 관련 책들중에 가장 추천할 만한 책입니다.
개정판 이전에 이미 읽은 사람도 많겠지만, 저자의 다양한 경험과 지식을 바탕으로 패턴, 인프라, 조직, 문화 등 MSA와 관련된 거의 모든 분야에 대한 저자의 생각과 고민이 정리되어 있습니다. 특히 각 패턴들에 대해서 가상의 회사를 예를 들어 설명해주는 친절함까지 제공해줍니다.
- 매 주제마다 저자는 본인의 생각을 의견으로 정리하여 제시하며 정답을 제시하는 방식이 아닌 의견을 제시하는 방식이 마음에 듭니다. 여기에 더하여 저자가 경험했던 프로젝트 사례를 예로 들어 줍니다.
- 챕터들 중에 패턴을 설명해주는 곳에는 '패턴' 참조 표시를 제공하며, 주요 외부 사례나 전문가들이 제시한 논문이나 주요 자료에 대해서도 코멘트를 제공하고 있습니다.
- MSA 관련하여 이보다 더 다양한 주제를 다룰수 있을까? 하는 생각이 들 정도, 무슨 설명이 더 필요할까, 일단 아래 목차를 보시라...
=> 유일한 단점은 분량(약 690 페이지)과 너무 많은 분야를 다루는 것이라고나 할까?
중간에 지칠수 있으니, 관심분야 위주로 필요할때마다 찾아 보는 방식으로 활용하는 것을 추천합니다.
ㅇ 목차
PART 1 기초
CHAPTER 1 마이크로서비스란?
CHAPTER 2 마이크로서비스 모델링 방법
CHAPTER 3 모놀리스 분해
CHAPTER 4 마이크로서비스 통신 방식
PART 2 구현
CHAPTER 5 마이크로서비스 통신 구현
CHAPTER 6 워크플로
CHAPTER 7 빌드
CHAPTER 8 배포
CHAPTER 9 테스트
CHAPTER 10 모니터링에서 관찰가능성으로
CHAPTER 11 보안
CHAPTER 12 회복 탄력성
CHAPTER 13 확장
PART 3 사람
CHAPTER 14 사용자 인터페이스
CHAPTER 15 조직 구조
CHAPTER 16 진화하는 아키텍트
매번 그렇지만 부족한 부분들은 이곳의 여러 전문가 분들이 채워주리라 기대해봅니다.
부족한 글 읽어 주셔서 감사합니다.
써서 안될거고요. 단순 개발용으로 좋은 환경이지만 굳이…
Msa는 압축에 압축을 해놓은 불편한 환경이에요
그리고 msa를 국내시장에 맞게 환경을 구성할려면 독립성은 위배 + 중복데이터 허용
저희 회사 서비스는 대부분 다 K8S와 MSA 기반으로 만들어지고 있습니다.
한번 MSA를 맛보면 이후 다시는 예전 방식으로는 못 돌아가죠. 그 관리 리스크를 어찌 감당할까 하는 한숨만... ㅎ
저번 프로젝트 대형홈쇼핑 구축이였는데 MSA 로 진행했죠. 정작 이거 하자고 우긴 윗사람은 중간에 퇴사..흘..
좀 산으로 갔습니다. 비즈니스는 놓아두고 개발만 저짓하니 이산저산 가지 않은 것만으로도 다행이였습니다.
우리 나라 국민성인지 몰라도 마스터 테이블들의 크기가 너무 크니까 MSA는 시작부터 빠그러집니다.
전체 구성원들이 큰 그림에 대한 이해와 공감이 있지 않으면 결국에는 개판 되기 쉽더라구요. 시간이 흘러 진급과 퇴사 등으로 담당자가 바뀌면 더더욱 큰 그림 보기 어려워지는게 단점이기도 하구요.... 백엔드 개발자들이 할 몫이 더더더 늘어나죠. 주력 언어 + DB 쿼리 + 도커 + 쿠버네티스 + 테라폼.... (DB어드민, 인프라엔지니어, SRE 다 따로 있는 회사에 들어가면 참 좋겠지만... 현실은 백엔드 개발자가 일단 알아서 해야하는 경우가 많죠).
그래도 MSA를 도입하면
- 잘게 쪼갠만큼 각 앱들 구현을 엔지니어들에게 나누어 주기 좋고
- 분리된 각 컨테이너들이 내부적으로 서로 다른 언어를 쓰기도 좋고
- 각 앱들의 권한을 명시함으로써 보안에도 좋고
- 장애 발생 시 문제 격리 하기에도 좋고
등등.... 원칙이 잘 지켜진다면 장점들도 적지 않은 것 같습니다.
거기서 일하는 개발자들이 각 어플리케이션 서비스만 개발하게 되고 운영하게 됨으로서 서비스의 큰 규모를 제대로 머릿속으로 그리지 못하고 부품으로 소비된다는 느낌이 강하게 듭니다...
어쩔 수 없는 부분이지만 저도 회사 서비스가 커지면서 점차적으로 앱 단위로 분산시키고 장애대응을 별도로 할 수 있도록 리스크를 최소한으로 줄여나가는 구성으로 가게 되고, 결국 신규 개발자나 엔지니어를 뽑게 되면 일부 파트만 설명함으로서 효율성을 높이는 방향으로 갈 수 밖에 없더라구요.
회사입장과 신규채용된 개발자/엔지니어입장에서는 장점이지만, 일하는 사람의 발전을 저해하는 요소가 다분히 있다고 생각되서 일주일에 한번씩 다른 앱들을 만드는 팀과 회의를 하면서 서로 팀간에 무엇을 지향하고 어떤걸 만들고 있는지 소통시키고 있습니다...
어떤 사람에게는 저 시간이 소모적이고 피로한 시간이라고 생각할 수 있겠지만... 누군가에게는 발전의 기회가 될 수 있다고 생각하고 "내일은 내가 좀 더 좋은 개발자가 된다" 라는 느낌을 갖을 수 있도록 노력하게 되더라구요.
클라우드와 복잡한 MSA를 거부하는 미국회사들도 적지 않은데 대표적으로 stackoverflow가 있습니다. 베어본 형태 서버 16대로 운영하고 MSA로 잘게 서비스를 분리하지도 않았고 심지어 가상화 조차도 안쓰면서 장애도 없이 운영을 잘하는 사례가 있습니다.
stackoverflow 서비스 자체가 단순해서 가능하다고 보는 시각도 있습니다만, 개인적으로는 stackoverflow가 굉장히 운영을 잘하는 편에 속한다고 생각합니다...
msa는 장님이 코끼리 만지는 느낌의 해석이 많은것같아요
SI개발자 vs 플랫폼개발자의 경험적 인식도 다르고
특히 업종이나 서비스 성격에따라 다르고
관리적 관점에서도 해석이 같을수가 없죠
본인의 회사 또는 주 고객사 성향도 중요하고요
두번째 책은 한번 보고 싶네요
감사합니다
저도 이 책 추천 합니다. 깊이 보다 전체적인 맥락을 짚어주는 느낌의 책입니다. 초급자들에게 보기 좋았습니다.
원문보기:
https://www.itworld.co.kr/t/61023/%EA%B0%9C%EB%B0%9C%EC%9E%90/293089#csidx1ebe9f9c1def77fb1e2ef48a5a6be1c
Monolithic 기반에 몇몇 작은 서비스를 쓰다가
수년에 걸쳐 micro service 로 거의 옮겨갔는데
실제로 서비스가 30-40종 되고 NoSQL 위주로 쓰다보니 관리 운용 문제가 더 커지게 되더군요.
넷플릭스 같이 아주 큰 규모의 서비스가 아닌한 MSA는 over engineering 인 경우가 많은것 같습니다. 실제로 monolithic 으로 돌아가는 회사도 봤구요.
서비스가 너무 많아지지 않게 적당히 중간 정도로 나눠서 서비스간 의존도와 통신을 최소화 하는게 좋을것 같습니다.
그래도 클라우드가 대세인 요즘에 MSA의 철학과 적용방법을 익힐 필요는 있구요.
단순히 기존 코드를 쪼개서 상호 의존성을 완전히 해소 못한 상태로 WEB API 사용하는 아키텍쳐를 만든다면,
굳이 겪을 필요가 없었던 네트워크 리소스들과 미들웨어를 추가로 사용하게 됨으로 인해,
리소스 사용량이나 유지보수는 늘고 성능은 떨어지는 지옥을 맛볼 수 있습니다. ㅎㅎ
모놀리틱이라고 꼭 나쁘고 클라우드네이티브가 꼭 좋은것만은 아닙니다
서비스의 특성이나 조직구성에 맞는 최적점을 찾는게 훌륭한 아키텍트의 역할입니다
애자일도 제대로 안할가능성
코드리뷰도 제대로 안할가능성
테스트코드도 제대로 작성안되어있을 가능성
CICD 파이프라인및 배포도 제대로 안할 가능성이 매우 높습니다
레가시 시스템 및 레가시 프로세스로 일하고 싶지않으면 되도록 피하는게 맞습니다