험프리 12월 20일, 2021에 포스트됨 공유하기 12월 20일, 2021에 포스트됨 실제 브라질의 운송회사에서 20년된 델파이 프로그램을 현대식 마이크로서비스 아키텍처로 전환한 사례를 바탕으로 진행한 세미나 자료입니다. 당면과제 브라질에서 가장 큰 로컬 운송회사에서 델파이6로 구축한 시스템을 15년간 회사의 매우 중요한 파트에서 운용해 왔다. 그간 회사는 크게 성장했지만, 클라이언트/서버 구조인 이 시스템으로는 더 이상 회사의 성장에 맞추어 확장하기 어려운 상황에 이르렀다. 시행착오 2014년 이후 회사는 두 번에 걸쳐 델파이가 아닌 다른 기술로 완전히 교체하려는 시도를 했다. 한 번은 SAP로, 다른 한 번은 Java(자바)로 시도했으나, 두 프로젝트 모두 실패했다. 그 기간 동안 기존 시스템은 20살이 되었고, 세번째는 더 이상 실패하면 안 되는 다급한 상황이 되었다. 해결 방안 및 결과 2019년 새롭게 구축한 시스템은 유연하면서도 확장성있고, 견고하며, 비용까지 절감해주고 있다. 현대식 시스템이며, 마이크로서비스 아키텍처가 적용되었다. 도커(Docker), 쿠버네티스(Kubernetes), 데브옵스(DevOps) 원칙이 반영되었다. 그리고 무엇보다 이 새 시스템은 델파이(Delphi)로 구축되었다. 이 영상을 통해 알 수 있는 내용 왜, SAP와 Java 두 번의 재구축 프로젝트가 실패했을까? 어떻게, 델파이 개발자 단 8명으로 구성된 팀만으로 외부 훨씬 더 큰 규모의 개발팀보다 빠르고 획기적인 결과를 만들어 낼 수 있었을까? 왜, 전환 프로젝트 비용이 시트릭스(Citrix) 비용 절감만으로도 충당되었을까? (다른 시스템에서는 못했는데) 이 새로운 시스템은 유연하게 확장되고, 빠르게 개발될 수 있었다. 아키텍처는 어떻게 되어 있을까? 이 영상을 통해 기존 시스템의 가치를 인식하고, 기존 시스템에서 마이그레이션 하는 것이 완전히 새로 구축하는 것보다 어떻게 그리고 얼마나 더 빠르고 더 안전한지를 확인할 수 있다. 시스템 아키텍처 해당 세미나에서 소개한 아키텍처를 조금 구체적으로 그려보면 다음과 같다. 이해하기 쉽도록 계층을 구분하고, 각 계층의 역할과 서비스 구성, 서비스들의 역할을 설명했다. 해당 세미나의 아키텍처 중 시스템 아키텍처를 제외한 개발 도구와 배포 환경은 다음과 같다. 사용된 기술 Access Layer 클라이언트 요청을 분산하고, 요청에 대한 서비스로 연결하는 게이트웨이 역할 Reverse Proxy & Load Balancer : REST API의 경로에 따라 구현된 마이크로 서비스와 연결 및 요청 분산 HTTPS : 보안 프로토콜 지원 Traefik : HTTP 리버스 프록시 및 로드 밸런서. REST API 수신 시 설정에 따라 하위 마이크로 서비스와 연결 HAProxy : 소프트웨어 로드 밸런서, 네트워크 스위치에서 제공하는 L4, L7 기능 및 로드 밸런서 기능 제공 참고> Naver D2 - L4/L7 스위치의 대안, 오픈소스 로드 밸런서 HAProxy Certbot : HTTPS 지원 Let's Encrypt : 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 풀 모델 사용이 특징 참고> 오픈소스 모니터링 시스템 prometheus #1 DevOps/Dev tooling RAD Studio Ranorex docker Sonar Gitlab Jenkins Deployment environment Ansible Kubernetes Ubuntu Rancher docker 다시보기 인용하기 이 댓글 링크 다른 사이트에 공유하기 더 많은 공유 선택 사항
Recommended Posts
이 토의에 참여하세요
지금 바로 의견을 남길 수 있습니다. 그리고 나서 가입해도 됩니다. 이미 회원이라면, 지금 로그인하고 본인 계정으로 의견을 남기세요.