OCS에 MSA를 적용한다면

국내 병원정보 시스템은 대략 위와 같은 형태일 것이다. 이러한 모습이 20여년 지속되고 있다. 여기에 MSA를 적용하면 어떻게 할 수 있을까?


최종적인 TOBE 모습은 아래와 유사할 것이다.

위의 최종 TOBE 모습이 갖춰 진다면 어떤 장점을 얻을 수 있을까?


1. Event Driven Architecture 측면

• 쇼핑몰에서 주문, 주문취소, 반품, 교환 등이 메인 Event이듯 OCS에서는 처방이 출발점이고 Main Event
• 대부분의 서비스에서 사용하는 내원, 처방, DC 등을 Event로 발행하면 필요한 서비스에서 구독
• 내원 예약/접수/실시, 진료 처방/DC 등 Publisher와 관계없이 구독만으로 해당 업무 Lifecycle에 참여가 쉬움
• 더 이상 진료 서비스 수정 불필요 (기존에는 처방 시 필요한 곳에 쏴줘야 했었음)
• 이와 같은 EDA 적용을 통해 느슨한 결합, 독립성/자율성 높아짐
• 진료 서비스 장애 시 간호, 원무, 각 종 진료지원 서비스는 이미 구독해(받아) 둔 처방에 대해 처리 가능
• Event와 API 적절한 혼합 사용 (예 : Event 수신 후 API로 상세정보 요청 등)
• 환자, 내원, 처방 등 대부분의 서비스에 사용되는 데이터는 중복되지만 EDA를 통한 Eventually Consistency 가능해당 서비스에 필요한 최소한의 데이터만 관리

2. MSA 측면

• 업무/조직/R&R 측면에서 DevOps팀 관리하는 서비스 명확
• 서비스별 DB가 분리됨에 따라 Data Ownership (관리 주체) 명확
• (ASIS Monolith 통합 DB에서는 내원, 처방 등의 테이블은 100여개의 컬럼으로 구성되어 Owner가 원무, 진료이지만 임의로 Control할 수 없었음, DDD의 Bounded Context 별 명확한 Ubiquitous Language 분리)
• 업무적 확장성 : 진료예약 홈페이지, ARS에 모바일 등의 추가 채널 구성 용이(필요한 채널을 New Service 로 만들어 끼우면 됨)
• 물리적 확장성 : 월요일 또는 공휴일 후 오전 외래환자 급증 대응 용이(Auto Scaling), 원무/진료 등의 필요한 서비스만 개별적으로 확장 가능
• 서비스별로 독립적인 분석, 설계, 개발, 테스트, 배포, 유지보수 가능
• ASIS Monolith와 같이 일부 테이블, 일부 기능 추가/변경 시 전체 배포, 서버 재시작 등 불필요
• 장애 격리 : 진료, 간호, 원무, 각종 진료지원 등 특정 서비스 장애 발생 시 해당 서비스만 못할 뿐 병원 시스템 전체로 장애 전파 최소화
• Polyglot : 서비스별 별도의 Language, Framework, DB, Library, 신규/변경 개발 프로세스 등 적용 용이, 더 이상 차세대 까지 기다릴 필요 없음

위의 장점 예 외에도 여러가지 장점을 생각해 볼 수 있다

• 진료지원, 일반관리, ERP 등 외부 솔루션이 필요한 경우 대체 용이
• (예 : 일반관리 또는 진료지원 등 외부 솔루션 도입시 기존 서비스를 갈아끼우기 쉬움, 또는 PACS 솔루션 A 에서 B로 갈아끼우기 등)
• 이와 같은 구조를 갖추고 있으면 더 이상 차세대 불필요 > 필요한 서비스만 추가/변경/배포/대체 가능

당연히 장점만 존재하지 않을것이다. 위와 같은 장점을 얻기 위해 아래의 단점, 고려사항 등을 극복할만한 의지, 노력, 필요성에 대해 공감해야 할 것이다.

• Inner/Outer Architecture 검증을 위한 PoC, 선도개발 등의 사전 작업 필요
• 모든 것을 PoC후 진행하는 것은 현실적으로 어렵기에 일반적으로 추천되는 환경(Cloud 등)과 기술(EDA 등)에서 우선 시작하여 경험, 내재화하는 것이 중요
• PoC 중 DB의 예를 들면
• RDB 상용, 오픈소스, MongoDB와 같은 NoSQL, Redis 와 같은 Cache, 검색을 위한 Elaticsearch 등 서비스의 특징 및 성능에 최적화된 DB 선택 가능한 장점이 있지만, 각 DB 특징을 사전에 PoC로 검증 필요
• 이행전략에 따른 내재화 기간, 전체 기간, 비용 등 로드맵 필요
• 이 외에도 CIO 부터 PM, PL, 분석설계자, 개발자, 유지보수 운영자 등 모든 이해관계자 구성원이 한마음 한뜻 까지는 아니어도 최소한 서로의 생각에 공감하고 토론하고 발전시키려는 노력이 필요하다. 그렇지 않은 동상이몽이라면 결로과는 안봐도 비디오다.

 

• 좌측 ASIS에서 우측 TOBE 모습으로 한번에 Big Bang으로 전개하기에는 Risk가 많으므로 Incrementally Refactoring(Strangler, 이행전략) 전략 필요
• 이행전략에 따라 조금씩 조금씩 장점을 얻어가다가 최종적으로 우측의 모습이 완성되었을 때 앞에서 이야기한 EDA, MSA 도입으로 인한 장점을 모두 취할 수 있게 될 것이다]

아래는 단계별로 어떻게 진행할 수 있을지 단계별 예

위와 같이 처방을 이벤트로 발행하고 구독하면서 각 서비스들이 유기적으로 일을 할 수 있다면
말 그대로 'Order Communication System 처방 전달 시스템' 이 될 것이다.
그리고 처방 이벤트도 하나로만 발행할 것이 아니라
약처방완료, 입원/퇴원처방완료, 재활처방완료 처럼 처방의 종류나 패턴별로 나눠서 Publish한다면 필요한 서비스에서 필요한 처방만 구독하니 훨씬 효율적일것이다. (또는 구독자가 필터링하여 필요한 로우와 항목만 저장한다. 무엇이 효과적일지 검증해보자)

• 이렇게 1단계를 마치고 나면 위의 빨간색 박스와 같은 모습
• 1단계를 통해 자신감을 얻고 내재화의 가능성을 엿볼 수 있음
• 기간, 예산, 인력, 스터디 등 어느 부분이 부족한지 등을 배울 수 있고 준비할 수 있음

 

 

• MSA를 도입하려는 조직은 위와 같은 이행전략(로드맵) 필요
• 이는 각 서비스의 특징을 고려하여 발주사가 주도적으로 구성해야 함
• 사전에 서비스정의 워크샾을 통해 전체 서비스를 예상해볼 수 있어야 함
• 몇 단계에 걸처 어떻게 진행될 지 예상은 할 수 있지만 반드시 이렇게 된다는 전제는 하지 말아야 함
• 단계를 거치면서 내재화나 투입인력의 수준 등에 따라 더 빨라질수도 늦어질수도, 필요하다는 예상이 빗나갈수도, 예산의 문제, 시장환경 등 예상치 못한 변수가 얼마든지 있을수 있으므로 위의 계획은 계속해서 수정해 간다고 생각해야함
• 그리고 반드시 Monolith가 모두 사라져야 하는것은 아님, 2단계까지 진행했고 그 단계의 Monolith, New Services 의 모습이 조직 목표에 충분하다면 더 이상 진행할 필요 없음
• 반대로 1단계만 했는데 가성비가 낮다고 판단되면 이후 단계를 진행하지 않아도 됨, 실패될 예산 감소