MSA해설80 서비스 설계 모델과 코드 샘플 위의 API, Event Publisher/Subscriber, Other Comminication(FTP, Socket 등) 을 어떻게 설계할 것인가? 이러한 내용을 Excel로 표현할 수 있을까? UML로 표현하려면 어떤 준비가 필요할까? Excel도 UML도 아닌 다른 설계 표현 방법 또는 도구는 없을까? 2022. 11. 25. MSA 이해 Micro Service Architecture, MSA Microservice에 대비되는 공룡 처럼 덩치가 크고 느린 시스템을 Monolithic Architecture/Application 또는 Monolith라 한다. MSA라는 용어는 2011년 등장했고, 우선 Microservice가 왜 필요하게 되었는지 등장배경을 이해하는게 중요하다. 그리고 MSA정의 문장 하나하나 천천히 생각해보자. 현재 우리 시스템이 이러한 상황이라면 MSA 도입을 검토해 봐야 한다. 그리고 MSA를 도입하기로 했다면 이러한 공정을 참고하자. MSA 도입 시 제일 처음 만나는 문제는 서비스를 어떻게 식별할 것인가이다. 서비스를 식별하는 방법은 다양한데 그 중에서도 Event Storming 이 자주 사용된다. 어떠한 방법이.. 2022. 11. 24. 어떻게 설계하십니까? Excel? UML? 설계자 머릿속으로 생각하든, 개발자를 옆에 앉혀두고 말로하든, 종이나, 화이트보드에 쓰든, 어떤 형태로든 설계를 할 것이다. 일반적으로 많이 작성하는 방법은 Excel과 같은 MS Office를 이용하거나 UML 도구를 사용한다. Excel와 같은 MS Office의 경우 작성은 쉽지만 양식이 제각각이다, 누군가 템플릿을 줘야 한다 시각화나 가독성이 떨어진다 공동작업이 어렵다 전사 라이센스 등 저렴한 비용으로 사용할 수 있다 UML도구의 경우 Learning Curve가 있다 그렇다 보니 MDD 처럼 Full code 생성이 아닌 이상 이러한 불편함, 어려움을 감수하면서까지 사용하지 않으려는 거부감이 있다 설계 표준 및 도구 Customizing이 필요하다 이러한 작업을 누가할 것인가? 공동작업을 위해 .. 2022. 11. 24. MSA 필요성 Pair Programming(PP)을 도입하면 여러 장점이 있다. 지식 공유 자연스러운 백업, 기술 이전 함께 고민, 디버깅, 해결이 빠름 업무에 집중 실시간 코드 리뷰 오류 최소화 품질 상승 팀워크 향상 궁극적으로 생산성, 품질 향상 하지만 이렇게 좋은 PP를 잘 도입하지 않는다. 왜 그럴까? 생산성 저하 비용 증가 감정 문제, 피로드 상승 등등 PP의 장점은 알지만 당장의 손해, 투자 때문에 망설이거나 포기하게 된다. MSA도 마찬가지라 생각한다. 궁극적인 방향성과 장점은 알지만, 당장 적용하기에는 어려운게 현실적인 상황이다. [우아콘2020] 배달의민족 마이크로서비스 여행기의 마지막 부분을 보면 이러한 질문을 한다. 왜 MSA를 도입하려는가? MSA가 필요한가? 당연히 모든 도메인 업무와 조직에 .. 2022. 11. 24. MSA 등장배경 Monolith Monolithic Architecture, Monolithic Application 또는 Monolith라고 부른다. Microservice에 대비된 기존의 커다랗고 무거운 시스템 구조다. 처음에는 동그라미, 세모, 네모 각 업무별로 기능과 데이터가 정규화되어 잘 개발되었겠지만 시간이 지남에 따라 좌측과 같이 스파게티 또는 큰 진흙 덩어리가 된다. 결국 전체 영향도 파악이 어려워지고 추가/변경 요구사항을 받아들이거나 유지보수가 쉽지 않게 된다. 논리적 분리 혼재된 기능과 데이터를 논리적으로 구조화한다. 모듈화 또는 컴포넌트라고도 한다. 구축 초기에는 업무 영역별로 명확해 보이지만 이 또한 시간이 지남에 따라 다시 스파게티가 되어 간다. 첫번째 Monolith든 두번째 논리적 분리든 다음.. 2022. 11. 24. MSA 단점 및 고려사항 MSA는 만병통치약이 아니다. MSA의 장점은 그냥 얻어지지 않는다. 공짜가 아니다. 당연히 단점이 있고, 사전에 고려해야할 사항이 있다. 제대로 준비하지 못한채 도입하려 덤빈다면, 흉내낸다면 오히려 단점만 더 부각될 것이다. 이렇게 힘든걸 왜 하자고 했느냐는 아우성만 빗발칠 것이다. 분산 환경으로 인한 복잡성 - Monolith에 비해 서비스별 분산 환경으로 복잡 - 분산 Transaction, 데이터 정합성 등 추가 설계/개발 필요 - REST API 뿐 아니라 Domain Event 특징에 맞춰 추가 설계/개발 필요 Event Driven Architecture 고려/내재화 필요 - Event 발행/구독의 장점 단점 내재화 - Eventually Consistency 이해와 내재화 API First.. 2022. 11. 24. MSA 장점 및 도입 시 효과 MSA를 도입했을 때 얻을 수 있는 장점이다. 기존 Monolith에서도 가능했을 수 있지만 Microservice Architecture를 갖추면 훨씬 더 쉽게 아래 장점을 얻을 수 있다는 의미고, Monolith에 비해 상대적인 장점이기도 하다. 물론 MSA를 제대로 잘 적용했을 때 이야기이고, 여러가지 Anti Pattern과 같이 잘 못 적용하게 되면 아래의 장점을 얻지 못하고 오히려 그 반대 또는 더 악화될 수 있음을 명심해야한다. (Anti Pattern 참고 : https://kooangelo.tistory.com/180, https://kooangelo.tistory.com/114) 덩치 큰 Monolith에 비해 여러 작은 Service들로 구성되었기 때문에 얻을 수 있는 대표적인 잇점이.. 2022. 11. 24. 서비스 식별 예 Loosely coupled highly cohesive (서비스간의 느슨한 결합) 타 서비스에 직접(동기 통신) 의존하는 경우 서로 밀접하게 결합되므로 가급적 Event Driven 지향 업무, 서비스 뿐 아니라 개발팀도 느슨한 결합 지향 (loosely coupled teams) 협력사 입점부터 폐점까지 독립적인 라이프 사이클 관리 수납로직 변경 시 미납도 함께 변경 배포 되어야 함 -> 수납 미납을 하나의 서비스로 Single responsibility (단일 책임) 우편번호, 주소, SMS/알림톡 등 공유/공통 업무 해지/휴면 고객 등 보안, 법적제약 등으로 분리 보관이 필요한 경우 권한, 결재와 같이 그룹웨어나 전자결재 등 해당 기능만을 처리하기 위한 별도의 솔루션 도입 예정인 경우 분리 Dat.. 2022. 11. 22. 서비스별로 DB를 꼭 분리해야 하나요? 2022. 11. 17. 경험적 Anti Pattern 답정너 이행전략 이행전략을 세운건 좋지만 '답정너'와 같이 무조건 따라 가서는 안된다 계획은 당연히 수정될 수 있고 조정이 가능하다 하지만 윗 선에 보고, 책임 등의 이유로 그냥 끌고 가는것은 어리석은 짓이다 수행사가 알아서, 전문가가 알아서 MSA 전문가를 투입해서 수행사가 알아서해주길 바란다? MSA이든 아니든 시스템의 주인은 고객사 본인이다 흉내만 유행이고, 남들고 했다고 하고, 위에서도 하길 바라고 해서 하긴 해야겠는데 시간, 비용, 공부 등 여러가지 이유로 실행하기는 어렵고 해서 적당히 적용한 것 처럼 해달라. 그렇게 보고 할 수 있게만 해달라 어설프게 흉내내면 오히려 더 악화된다 조직별로 따로따로 Chris Richardson Anti Pattern에 조직별 MSA를 별도로 도입하면 에포트 중.. 2022. 11. 17. Batch? Event? Batch 사용량이 적은 야간에 작업 대량의 데이터를 CRUD 장시간 성능 작업 중간 오류 시 Rollback, 재처리 등 복잡한 쿼리 계산과 과정에는 큰 비용 소모 동기화하는 데는 많은 트랜잭션 필요 ... 위와 같은 Batch 대신 Event 각 사건을 이벤트로 발행하고 필요한 곳에서 구독한다면 일이 보다 간단해지지 않을까 실제로, 무슨 일이 언제 일어났는지 분명히 알 수 있고 그 결과로 무슨 일이 일어나야 하는지에 관한 컨텍스트를 제공해주기 때문에 복잡한 쿼리를 제거할 수 있다 수신한 각 이벤트의 알림에 맞춰 작업하기만 하면 된다 (Choreography) 현재 I/O와 프로세서 집약적인 배치로 처리되는 사항이 하루 전체로 흩어져 짧게 처리되고 비즈니스 상황은 훨씬 빠른 시점에 조화를 이뤄서 사용자.. 2022. 11. 10. Iceberg(빙산) Microservice 위 빙산 모습을 단순화하면 다음과 같다 그런데 혹시 다음과 같은 빙산을 본적이 있는가? 당연히 있을 수 없는 모습이다. 불안정해 보이고 부자연스러운 모습이다. Microservice 별로 Data를 갖고 관련된 기능을 구현하면서 Client 에서 뭐가 필요할지 모르니 CRUD 형태로 최대한 많은 API를 노출한다고 생각하면, 아마도 이러한 부자연스러운 빙산의 모습이 될 것이다. 이러한 형태로 API가 노출된다면 DB Schema 또는 로직 등의 변경에 따라 API가 계속 흔들리게 되고 Client에 대한 영향력이 증가할 수 밖에 없다. API 정련이 필요하다. 제공하는 Provider 입장 뿐 아니라 Consumer와 상의하여 패턴화해야 한다. 이것은 단지 REST API 만의 문제가 아니다. Publi.. 2022. 10. 26. Microservice Architecture Style로 전환된다면 무엇이 가능할까? 다시 말해 크고 작은 여러 서비스들이 독립적으로 작동, 느슨하게 통신하며 서비스하고 있다면, 즉 Microservice Architecture가 갖춰졌다면 무엇이 좋을까? 기존 서비스와 다른 추가 기능이 필요한 경우 새로운 서비스를 만들어 끼워 넣기 쉽다. 기존 서비스들의 기능을 충분히 이용할 수 있다. (API, Domain Event 통신 이용) 그렇게 새롭게 끼워넣은, 추가된 서비스를 빠르게 검증할 수 있다. 만약 문제가 있다면 그 서비스는 다른 서비스와 관계없이 중지 또는 폐기가 쉽다. 이렇게 된다면 빠르고 다양하게 변하는 시장환경 및 고객 요구사항에 적시 대응할 수 있다. 궁극적으로 Business 경쟁력을 향상 시킬 수 있다. 2022. 9. 28. Monolith에서 Microservice들을 분리해 갈 때 뭘 먼저 떼내면 될까? 일단 더 이상 Monolith를 뚱뚱하게 만들지 않아야 한다. 특별한 이유가 없는한 새로운 서비스로 만든다. 그렇게 만들어진 서비스는 Monolith의 통합 DB와 연결되서는 안되고 자체 DB를 포함해서 만들어야 한다. 그렇지 않으면 Monolith와의 의존성은 여전할 것이다. 아래와 같은 경우 먼저 떼는게 좋겠다 Scalability 측면(업무적 확장성, 물리적 확장성)에서 효과가 큰 경우 자주 문제가 되어 장애격리가 필요한 경우 이렇게 부하, 장애 등의 이유로 분리 시 효과가 큰 경우 신규, 변경이 잦은 경우 해당 서비스에 적합한 기술 적용이 필요하면 경우 2022. 9. 20. 현재 우리 시스템이 이렇지는 않은지? 프로세스, 기능 또는 데이터 관리 주체 불명확 주문, 원장, 처방 등 메인/공통 테이블을 여러 곳에서 쿼리 하다보니 해당 테이블 Owner팀이라 하더라도 컬럼 하나 변경/삭제 등 스키마 컨트롤이 어려움 개발조직, 지원조직, 운영조직이 달라 협조나 의사결정이 더디거나 어려움 업무 요구사항을 반영해야하는 분석설계자/개발자의 입장(요구사항)과 배포 담당자(시스템 안정성이 더 중요)의 입장 차이 예를들어 주문완료 후 처리 프로세스가 늘어나면 주문파트에 요청해서 반영을 기다려야함, 더디거나 불가능 특정 시점 또는 특정 업무 서비스에 대해서만 부분적, 일시적 확장 어려움 용량 산정을 열심히 하지만 과도/과소 산정으로 인한 효율성 저하 업무별 개별 추가/변경 요구사항에 적시 대응 어려움 (정기 배포를 기다려야하거나 .. 2022. 9. 20. Sprint? Iteration? Timebox? Sprint? Iteration? Timebox? 무엇이 다른가? 위의 그림처럼 가운데 Iteration을 두고 하는 말로 모두 같은 반복적 모델을 의미이다. Pure Agile은 분석 > 설계 > 개발 > 테스트 전 과정을 반복적으로 수행하고 Hybrid Agile이라 불리는 곳에서는 보통 분석을 Waterfall 처럼 진행하고 설계와 개발을 반복적으로 수행한다. 중대규모 이상의 고객사와 계약된 일반적인 프로젝트에서는 프로젝트 규모를 산정해야기 때문에 분석단계에서 그 규모를 가늠하고 기본설계에서 전체 프로그램 목록을 파악하여 설계/개발 계획을 수립하고 상세설계 및 개발을 반복적으로 수행하면서 Feedback 을 반영한다. 2022. 9. 5. 분산 시스템은 근본적으로 다르다? 분산 시스템은 근본적으로 다르다 언제나 문제는 분산 시스템에 익숙하지 않은 개발자가 내재하는 복잡성을 얼버무리고 넘어갈 때 발생한다. 이는 특히 RPC를 사용할 때 그런데, 분산 경험이 미숙한 사람들은 보통 모든 원격 호출이 인프로세스 호출처럼 쉽다고 생각하기 때문이다. 이런 가정은 단 하나의 시스템이나 그 컴포넌트가 단지 일시적으로라도 사용이 불가능해질 때 많은 수의 시스템이 걸쳐서 연쇄적인 실패를 야기할 수 있다. 그러므로 분산 시스템 내에서 작업하는 모든 개발자는 다음과 같은 분산 컴퓨팅 원칙을 따르는지에 성공 여부가 결정된다. • 네트워크는 신뢰할 수 없다 • 언제나 지연이 있을 수 있고, 많을 수도 있다 • 대역폭은 무한하지 않다 • 네트워크가 안전하다고 가정하지 말라 • 네트워크의 위상(Top.. 2022. 9. 1. Microservice는 어떻게 식별하나요? Microservice(2012년)는 DDD(2003년)의 Bounded Context(BC) 의 개념과 많이 닮아있다. 그래서 Bounded Context 를 어떻게 정의하는지, 식별하는지를 보고 Microservice 에서 추가로 생각할 것이 무엇인지 살펴보자. "그 안에 도메인 모델이 존재하는 명시적 경계" "도메인 모델은 소프트웨어 모델로서 유비쿼터스 언어를 표현" (즉 Bounded Context : Ubiquitous Language = 1 : 1) - Implementing Domain-Driven Design, 반버논, p119 "모델링 영속성 데이터베이스 스키마의 생성을 주도할 때 데이터베이스 스키마는 경계의 안쪽에 위치한다. 이는 모델링 팀이 스키마를 설계하고 개발해서 유지하기 때문에 .. 2022. 8. 30. MSA 프로젝트에서는 어떤 방법론은 사용하나요? MSA는 Microservice Architecture로 아키텍처 스타일 중 하나이지 방법론은 아니다. MSA와 어울리는 방법론이 있다고 생각할 수는 있겠지만 MSA가 방법론까지 제공하는것은 아니다. 그리고 MSA와 Agile은 다른 이야기이다. MSA를 한다고해서 Agile을 꼭 선택해야할 필요는 없다. Agile을 하지 않았다고 해서 MSA를 못하는것도 물론 아니다. 즉 관계가 없다. 어느 정도 어울리는 부분이 있을수는 있겠지만 서로 반드시 필요한 관계는 아니다. 그럼 MSA 프로젝트에서는 어떤 방법론을 사용해야할까? 과거와 같이 정보공학? OOAD? CBC? Monolith때 사용하던 과거의 방법른을 MSA에서는 적용할 수 없는걸까? 또는 과거의 방법론을 적용했을 때 무슨 문제라도 있을까? 위의 그.. 2022. 8. 30. MSA 프로젝트 시 꼭 필요한 인력이 있나요? MSA 프로젝트 시작 전 또는 PoC 때 항상 듣는 질문 중 하나다. 어떤 아키텍트들이 있어야 하고 그들의 역할이 무엇인지, 그러한 아키텍트들을 구할 수 있는지? 이미 예상하고 있겠지만 프로젝트 상황에 따라 모두 다르기에 정답은 없다. 준비된 아키텍트들이 기다리고 있는 경우는 당연히 없고(그 만큼 여기저기 잘 팔리기 때문), 이론만 또는 교육만 수강하고 실전 경험이 거의 없는 각 아키텍트들도 구하기 쉽지 않다. 아래 열거하는 역할자들이 모두 있으면 좋겠지만 그렇지 않다면 최소한 그러한 역할자를 지정하거나, TBD로 두고라도 시작하면 할일을 놓지지 않는데 도움이 될 것 같다. 위의 그림은 어떠한가? 이해하기 쉽지 않은가? 위의 그림을 먼저 설명하는 이유는 이미 알고 있는 개발조직 또는 역할자 이기 때문이다.. 2022. 8. 10. MSA 설계는 뭐가 다른가요? 기존 설계와 뭐가 다를까? 기존 Monolith 설계와 어떤 부분이 가장 차이가 날까? 위의 그림과 같이 제일 큰 차이는 분산환경이다. Application 뿐 아니라 DB 서버까지 분리되어 있고, 각 서비스별 Data 가 필요한 경우 API 또는 Event로 주고 받아야 한다. 이렇게 서비스별로 물리적으로 분리된 분산환경을 어떻게 극복할 것인가? 데이터 정합성을 어떻게 맞추고, 독립적으로 작동하기 위해서 어떤 처리를 할 것인지에 대한 How, 방법을 찾는 것이 가장 큰 설계의 차이점이다. 이러한 분산환경을 받아들일 수 없다면, 우측과 같은 서비스별/물리적으로 분리된 아키텍처를 적용하지 않아도 확장성, 장애격리, 독립적 설계/개발/테스트/배포/운영이 가능하다면 굳이 MSA를 도입할 이유가 없다. API .. 2022. 8. 3. '착수'라는 단계도 있나요? 일반적인 SI 프로젝트는 분석, 설계, 개발, 테스트 등의 단계를 두고 진행한다. 각 단계별로 여러 Task가 있고 Task별로 작성해야하는 산출물이 있다. 중대규모 이상의 SI 구축 프로젝트라면 이러한 단계와 Task를 당연히 경험하게되는데 아래와 같은 질문에 대해 생각해 본적 있는지 모르겠다. 분석, 설계, 개발, 테스트 각 단계를 몇개월씩 진행해야할지? 설계를 기본설계와 상세설계로 나눌지? 상세설계 및 개발을 여러 Iteration으로 반복적으로 진행할지? 각 단계별 어떤 Task와 산출물이 있는지? 그들간의 관계는? 산출물은 어떤 도구로 작성하는지? 특히 설계 산출물? 설계 도구는? 설계를 전부 작성하는지? 핵심만 하는지? 핵심의 기준은? 누가 검토하는지? 제안할 때 방법론은 그대로 유지하는지? .. 2022. 8. 2. DDD로 워크샾하는거죠? MSA도입시 제일 먼저 맞닥뜨리는 문제가 서비스를 어떻게 쪼갤것인지, 즉 어떻게 식별하고 정의할것인가에 관한 문제다. 그 방법은 다양하지만 제일 먼저 고려되는것이, 많이 들어본 방법이, 유행하는듯한 기법이 워크샾을 통해 뭔가 할 수 있을것 같다는 것이다. 그리고 어디선가 DDD로 그렇게 할 수 있다는 이야기를 들은것 같다. MSA를 하려면 DDD를 해야한다는 말도 함께. DDD를 처음 주장한 에릭 에반스는 도메인 전문가를 포함한 DDD개발팀과 주로 화이트보드에 Class Diagram을 그리며 의사소통했다고한다. 너무 얽매이지 않았지만 그래도 기본적인 UML표기법에 따랐을것이고 어느정도 시간이 지나고 자주 보다보면 의사소통하는데 문제 없다는 듯 이야기하고 있다. 하지만 과연 그랬을까 하는 의문이 들었고,.. 2022. 8. 2. 서비스별로 DB를 꼭 분리해야하나요? "서비스별로 DB를 꼭 분리해야하나요?" MSA프로젝트 또는 서비스 정의 워크샾때 가장 많은 듣는 질문중의 하나다. "우리 회사는, 우리 도메인은, 우리 업무는 데이터 연관성이 너무 많아서 DB를 분리하기 어렵습니다" "Application Server 만 분리하고 DB는 통합해서 같이 사용하면 안되나요?" "DB분리를 하지 않으면 Microservice라고 할 수 없나요?" "Hybrid MSA인가 WAS만 나눌수도 있다고 하던데요" 위와 같이 질문은 다양하지만, 결론은 DB를 분리하고 싶지 않다는 것이다. 하기 싫다는 것이다. MSA를 하라고 하니, 하긴 해야겠지만 DB까지 분리하면 너무 힘들다는것이다. 1990년대 초반(1993년에 에릭 에반스의 DDD책 출간)부터 등장한 DDD에서부터 DB에 대한.. 2022. 7. 29. 실시간도 아니라는데 굳이 비동기 통신을 해야하나요? "동기 API만 쓰면 안되나요?" "실시간도 아니라는데 굳이 비동기 통신을 해야하나요?" "우리 업무는 실시간으로 처리해야하는데 비동기방식은 안되요" "실시간이 아니면 현업 설득이 안되요" "Kafka같은 메세지큐 안해봐서 잘 모르겠어요" "설계도 개발도 어렵다는데 이벤트 방식이 뭐가 장점인지 잘 모르겠어요" "그냥 예전처럼 배치로 하면 안되나요?" "더이타 접합성 맟추기, 동기화하기 어려워요" "Application Server만 나누고 DB는 통합하면 어때요? 그래도 MSA는 한거잖아요" "EDA가 뭐에요?" MSA를 검토하거나, 개발중에 흔히 하는 질문과 생각들이다. 다양한 질문이지만 결론은 다음과 같다. 실시간도 아니라는데, 공수도 더 든다는데, 굳이 왜 서비스를 DB까지 나눠서 비동기 통신까지 .. 2022. 7. 22. 서비스가 너무 잘게 쪼개진 것 아닌가요? "서비스의 크기는 어느 정도여야하나요?" "왜 이렇게 서비스가 잘게 쪼개졌나요?" "다른데 비해 서비스가 너무 많은거 아니에요?" "서비스가 너무 많으면 감당이 안되요, 유지보수하기 힘들지 않나요?" "서비스는 어느 정도 크기가 적당한가요?" MSA 구축 프로젝트 또는 Event Storming 과 같은 워크샾에서 위와 같은 질문을 거의 매번 듣늗다. 아래와 같은 질문도 있다. "바운디드 컨텍스트(서비스라고 바꿔 생각해도 좋다) 안에 어느 정도의 수(구성요소의 수)가 포함돼야 할까? 이는 '줄 하나의 길이는 얼마나 되나요?' 라고 묻는 것과 다를 바가 없다." - Implementing Domain-Driven Design, 반버논 > 2장 도메인, 서브도메인, 바운디드 컨텍스트 > 바운디드 컨텍스트의 .. 2022. 7. 20. MSA 해설 MSA 관련 책, 사이트, 동영상 등은 많지만 간단한 개념 설명, 기술 중심, 코드 중심으로 뭔가 아쉽다. 왜 필요한 것인지, 무엇이 중요한 것인지, SI 프로젝트에서 무엇이 필요한 것인지 등에 대한 설명이 되면 좋겠다. MSA 도입 https://youtu.be/SUtQnCxkCw0 MSA 이해 https://kooangelo.tistory.com/190 Event Driven - Batch? Event? https://kooangelo.tistory.com/177 - Domain Event, CQRS 적용 예 (배민) https://kooangelo.tistory.com/126 - 실시간도 아니라는데 굳이 비동기 통신을 해야하나요? https://kooangelo.tistory.com/148 DB -.. 2022. 7. 14. MSA, 준비된 조직만이 성공할 수 있다 https://www.comworld.co.kr/news/articleView.html?idxno=49710 [인터뷰] “마이크로서비스 아키텍처(MSA) 도입, 준비된 조직만이 성공할 수 있다” (2019.09.01) 위의 인터뷰 요약 + 첨언 MSA - 애플리케이션을 느슨하게 결합된 작은 구성 요소 서비스로 분해함으로써 독립적인 개발, 배포 및 운영이 가능 - 서비스 개발 팀이 보다 신속하게 새로운 기능 제공 및 확장 가능 하도록 - 이러한 MSA를 구현하기 위해서는 독립적인 배치, 확장, 운영이 가능한 서비스로 설계 필요 - 설계자는 인터페이스(API First Design) 및 데이터 정합성(Eventually Consistency) 관리 패턴 필요 - 서비스 설계 접근 방식은 서비스간의 느슨한 결.. 2022. 7. 14. Do Not Use MSA - 마이크로서비스 아키텍처가 꼭 필요한가요? https://www.samsungsds.com/kr/insights/msa.html Do Not Use MSA - 마이크로서비스 아키텍처가 꼭 필요한가요? 위의 글 발췌, 요약, 첨언 * Don't even consider microservices unless you have a system that's too complex to manage as a monolith (마틴 파울러) -> 모놀리식으로 관리하기에 특별히 복잡한 시스템을 운영할 상황이 아니면, 마이크로서비스는 고려할 필요조차 없다 -> 복잡한 Monolith로, 확장성/장애격리/독립성에 대한 대응이 어려운 경우, MSA를 고려 아래와 같은 질문에 대답 또는 설득할 수 있어야 MSA도입의 첫걸음일 것이다 * MSA를 요구할 만큼 시스템 복잡.. 2022. 7. 7. Application Modernization https://www.vmware.com/topics/glossary/content/application-modernization.html What is application modernization? 위의 내용을 발췌, 요약, 첨언했습니다 Application Modernization(AM) 이란 - 새로운 Languages, Framework, Infrastructure 등 새로운 컴퓨팅 접근방식으로 오래된 소프트웨어를 업데이트하는 것 - Legacy modernization or Legacy application modernization 라고도 함 - 효율성, 안전성 등을 개선하기 위해 오래된 집을 개조하는 것과 같은 소프트웨어 개발 Legacy Application을 왜 Modernize하는가 -.. 2022. 7. 7. 이전 1 2 3 다음
