Jump to content
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr ×
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr

20년된 델파이 앱을 현대식 마이크로서비스 아키텍처로 전환하기


Recommended Posts

image.png

실제 브라질의 운송회사에서 20년된 델파이 프로그램을 현대식 마이크로서비스 아키텍처로 전환한 사례를 바탕으로 진행한 세미나 자료입니다. 

 

당면과제

브라질에서 가장 큰 로컬 운송회사에서 델파이6로 구축한 시스템을 15년간 회사의 매우 중요한 파트에서 운용해 왔다. 그간 회사는 크게 성장했지만, 클라이언트/서버 구조인 이 시스템으로는 더 이상 회사의 성장에 맞추어 확장하기 어려운 상황에 이르렀다.

시행착오

2014년 이후 회사는 두 번에 걸쳐 델파이가 아닌 다른 기술로 완전히 교체하려는 시도를 했다. 한 번은 SAP로, 다른 한 번은 Java(자바)로 시도했으나, 두 프로젝트 모두 실패했다. 그 기간 동안 기존 시스템은 20살이 되었고, 세번째는 더 이상 실패하면 안 되는 다급한 상황이 되었다.

해결 방안 및 결과

2019년 새롭게 구축한 시스템은 유연하면서도 확장성있고, 견고하며, 비용까지 절감해주고 있다. 현대식 시스템이며, 마이크로서비스 아키텍처가 적용되었다. 도커(Docker), 쿠버네티스(Kubernetes), 데브옵스(DevOps) 원칙이 반영되었다. 

그리고 무엇보다 이 새 시스템은 델파이(Delphi)로 구축되었다.

이 영상을 통해 알 수 있는 내용

  • 왜, SAP와 Java 두 번의 재구축 프로젝트가 실패했을까?
  • 어떻게, 델파이 개발자 단 8명으로 구성된 팀만으로 외부 훨씬 더 큰 규모의 개발팀보다 빠르고 획기적인 결과를 만들어 낼 수 있었을까?
  • 왜, 전환 프로젝트 비용이 시트릭스(Citrix) 비용 절감만으로도 충당되었을까?
  • (다른 시스템에서는 못했는데) 이 새로운 시스템은 유연하게 확장되고, 빠르게 개발될 수 있었다. 
    아키텍처는 어떻게 되어 있을까?

이 영상을 통해 기존 시스템의 가치를 인식하고, 기존 시스템에서 마이그레이션 하는 것이 완전히 새로 구축하는 것보다 어떻게 그리고 얼마나 더 빠르고 더 안전한지를 확인할 수 있다.

시스템 아키텍처

해당 세미나에서 소개한 아키텍처를 조금 구체적으로 그려보면 다음과 같다.
이해하기 쉽도록 계층을 구분하고, 각 계층의 역할과 서비스 구성, 서비스들의 역할을 설명했다.

image.png

해당 세미나의 아키텍처 중 시스템 아키텍처를 제외한 개발 도구와 배포 환경은 다음과 같다.

image.png

사용된 기술

Access Layer

클라이언트 요청을 분산하고, 요청에 대한 서비스로 연결하는 게이트웨이 역할

Reverse Proxy & Load Balancer : REST API의 경로에 따라 구현된 마이크로 서비스와 연결 및 요청 분산

HTTPS : 보안 프로토콜 지원

Business Layer

운용에 필요한 기능을 마이크로 서비스 기반으로 제공. 핵심적인 비지니스 로직이 포함되며 다른 서비스들과 연동해 운용

  • RAD 서버 : REST API 서비스를 손쉽게 개발할 수 있는 턴키방식 미들웨어 서버. 델파이, C++빌더로 개발

Persistance Layer

서비스 운용에 필요한 데이터를 제공하는 역할

RDBMS, NoSQL : 마이크로 서비스는 서비스 분리와 함께 데이터 분리가 가능하다. 서비스 필요에 따라 RDBMS와 NoSQL 사용가능

Data Grid(IMDG: In Memory Data Grid) : 일종의 메모리 클러스터. 여러 서버와 메모리를 연결 수십기가의 메모리 저장소를 만들고, 애플리케이션 서버에서 접근해 사용하는 방식

Message Queue : 비동기 요청 처리. 클라이언트 요청을 메시지 큐에 넣고 응답 후 다른 서비스에서 메시지 큐의 내용을 처리

  • Oracle - RDBMS
  • PostgreSQL - RDBMS
  • MongoDB - NoSQL / BigData
  • Redis - 메모리 기반 데이터 그리드. 서비스간 공유할 데이터를 메모리 기반으로 빠르게 조회 및 저장
  • RabbitMQ - 오픈소스 메시지 브로커. 서비스간 메시지를 큐잉하고 변경 시 이벤트를 받아 처리 가능

Analystics Layer

서비스 운용 시 발생하는 로그를 수집 분석하고, 서비스를 모니터링 및 장애 감지 역할

Log gathering / Analysis : 서비스들로 부터 로그를 수집, 저장, 분석 해 시각적으로 제공. Elastic(ELK) Stack 사용됨

Monitoring : 네트워크 및 서버 모니터링 및 장애 감지 및 알림

  • Logstash - 실시간 파이프라인 기능을 가진 데이터 수집 엔진
  • ElasticSearch - 분산형 RESTful 검색 및 분석 엔진
  • Kibana - ElasticSearch에 저장된 데이터를 검색 및 분석, 시각화 플랫폼
  • Zabbix - 네트쿼크 서비스, 서버 등을 감시, 추적 및 장애 알림
  • Grafana - 데이터를 시각화하여 효과적으로 데이터기반 의사결정 및 모니터링 가능
  • Prometheus - 이벤트 모니터링 및 경고. HTTP 풀 모델 사용이 특징

DevOps/Dev tooling

  1. RAD Studio
  2. Ranorex
  3. docker
  4. Sonar
  5. Gitlab
  6. Jenkins

Deployment environment

  • Ansible
  • Kubernetes
  • Ubuntu
  • Rancher
  • docker

다시보기

이 댓글 링크
다른 사이트에 공유하기

이 토의에 참여하세요

지금 바로 의견을 남길 수 있습니다. 그리고 나서 가입해도 됩니다. 이미 회원이라면, 지금 로그인하고 본인 계정으로 의견을 남기세요.

Guest
이 토픽(기고/질문)에 답하기

×   서식있는 텍스트로 붙여넣기.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   이전에 작성한 콘텐츠가 복원되었습니다..   편집창 비우기

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

중요한 정보

이용약관 개인정보보호정책 이용규칙 이 사이트가 더 잘 작동하기 위해 방문자의 컴퓨터에 쿠키가 배치됩니다. 쿠키 설정 변경에서 원하는 설정을 할 수 있습니다. 변경하지 않으면 쿠키를 허용하는 것으로 이해합니다.