emart DT

D/T, Digital Transformation 을 위한 아키텍처 설계는 그 단어에서 내포하듯 어떤 대상을 변화시켜야 하는 미션입니다. 물론, 그 대상은 시스템, 환경, 사람, 프로세스, 비즈니스 등 매우 포괄적이기도 합니다. 이마트에서도 마찬가지인데요. 이마트 D/T본부 아키텍처 조직에 합류하고 가장 먼저 한 일은, 과거와 미래가 공존하고 있는 이마트앱 시스템과 인프라에 대한 As-Is 아키텍처 분석과 To-Be 아키텍처 설계였습니다.

그림1 에서 보는 바와 같이 하나의 대상을 두고 바라보는 시각은 다양합니다.

(그리고, 재미있게도 이 View Model 을 시각화 한 그림도 다양하게 존재합니다.)

이마트는 꾸준히 IT 시스템을 유지하고 발전시켰으며, 분사 시킨 SSG.com 뿐 아니라 내부 영업정보 관리, 상품판매 및 고객정보 분석 등 매우 다양한 시스템으로 구성되어 있었습니다. 최근 Digital Transformation 을 시도하며 신세계 그룹사의 IDC 에 더하여, Public Cloud를 적극 도입하여 Hybrid Multi-Cloud Infrastructure 환경 하에, 전체 시스템은 더욱 복잡하고 다양해지고 있었습니다.

이마트 앱의 경우도 마찬가지였습니다. 아니 가장 핫 했습니다. End User 에게 직접적으로 노출 되는 대표 POC 였기에 이곳에서 생성되는 정보는 Origin Data 로서 제공되며 새로 시도되는 비즈니스 모델의 창구가 되기도 하는 핵심 역할을 수행해야하는 Product 이기 때문이었습니다. 기존 시스템의 Refactoring 과 함께, 신규 기능 추가 개발에 더해 내/외부 시스템 간의 연동까지 그 미션은 매우 도전적이었고 광범위했으며, 자칫 타 시스템/조직의 업무 추진에 병목으로 제공될 수도 있는 포지션이었습니다.

이러한 이마트앱에 대한 이해는 대부분의 업무 개발자라면 필요한 기본 배경 정보가 되어야 했고, Code Refactoring 에 더하여 Re-Architecture 가 진행되어야 보다 높은 확장성을 기반으로 안정적인 시스템 구축이 가능했었습니다. 그리고, 변화를 시도한 후에는 그 전/후를 비교하여 측정할 수 있는 기반도 마련되어야 했고, 기존 기획이나 개발 부서원의 시간은 항상 촉박하다는 점도 감안을 해야 했습니다. 요약하면 가장 중요한 것은 Tech-RoadMap 일 수 있고, 개발자의 작업을 원활하게 지원하는 아키텍처를 구체적으로 제시해야 한다는 것이었죠.

가장 먼저 이마트 앱의 Conceptual 한 Software Architecture 로서의 Abstraction 작업을 진행했고, 그 결과물은 다음과 같았습니다. (IT 인력이 아닌 구성원들도 이해할 수 있는 범위에서, 내부 커뮤니케이션 채널 중 하나의 Confluence WIKI 의 Gliffy Diagram를 이용하여 작성했습니다. 참고로, 아래 이미지는 최신 버전이 아니며 공개 가능한 범위의 정보만 포함하고 있습니다.)

이마트앱의 As-Is 아키텍처에 대한 상호 이해를 위한 View 를 작성하고 이를 기반으로 Stakeholder 들 간의 커뮤니케이션을 할 수 있도록 지원했습니다. 이 중심에 위 그림을 두었고, As-Is 에 대한 이해 및 기획/개발의 내부 계획과 외부 연동 포인트에 대해 주로 Consensus 하는데 많은 도움이 되었던 것 같습니다.

아울러 커뮤니케이션 과정 중 혼선이 있는 부분에 대해서는 High Level Infrastructure Allocation View 를 작성하여 공유해 혼선을 최소화하였는데요. 이 문서는 공유하기 어려워 포함시키지는 않겠습니다. (만약, 이마트 멤버가 보고 계시다면, https://wiki.emart.com/display/SAC/High+Level+Infra.+Allocation+View 를 참고하시면 됩니다.)

도출한 Architecture Requirements 는 기존의 멤버들도 어느 정도 알고는 있었으나 본격적인 시작은 보다 많은 리소스가 필요하여 바로 시작하기 어려웠던 상황으로 보였습니다. 너무나 이해되는 상황이었습니다. 현실적인 To-Be 아키텍처 설계가 필요했고, 이는 기존의 Stakeholder 분들과의 소통을 통해 정할 수 있었습니다.

당장 Oracle Database 를 Cloud-Native 한 Database 로 나눌 수 없고, 당장 Monolithic 기반으로 구축 된 이마트앱 백엔드 서비스를 MSA 로 바꾸는 것은 리스크도 크다고 볼 수 있습니다. 기존 시스템을 한번에 모두 변경하는 것은 많은 노력이 필요하나, 어차피 개발하고자 했던 신규 모듈(특히 연동을 위한) 에 MSA 적용은 가능해 보였고, 한 번 적용해보는 학습의 효과도 얻을 수 있는 장점도 있습니다. 아울러 Oracle Database를 Cloud-Native한 Database 로 바로 전환하는 것이 어렵다면, Oracle 은 유지하고 가용성만 먼저 높이는 구조로 개발 영향도를 최소화하는 단계적 접근을 통한 이슈 해소도 가능해 보였습니다.

위와 같은 판단을 기반으로, 이마트앱의 To-Be Architecture Requirements 를 아래와 같이 정리했습니다.

① IDC ~ Cloud 전반에 걸친 시스템 분석/모니터링 툴 도입 (알람, 측정, 튜닝의 도구)

② 연동 시스템과의 개발/운영 및 시스템 의존성 최소화 (신규 모듈 개발부터MSA 아키텍처 설계/적용 후 기존 시스템 전환)

③ IDC 내의 Database 에 대한 Scale-Up/Out 방안 수립을 통한 시스템 가용 트래픽 증가 (시스템 병목 지점 식별과 해소)

그리고, 실현하고 있습니다. Architecture Realization 은 제가 가장 좋아하는 용어입니다. Architecture Realization 은 정책과 프로세스와 같은 Ground Rule 과 함께 기반이 되는 Infrastructure, Runtime Software, Development Environment, Application Framework/Module 등의 형태로 매우 다양한 모습으로 완성될 수 있는 매력이 있기 때문입니다.

이제, 위 To-Be Architecture Requirements 를 풀어나간 과정을 공유 드리도록 하겠습니다.

(1) 통합 모니터링 시스템 구축

우선 As-Is 모니터링 시스템 적용 현황을 파악하고, 이를 그대로 사용하면서 필요한 요건을 충족할 수 있는지와 신규 솔루션을 도입해야 하는지에 대한 판단이 필요했습니다.

As-Is 모니터링 시스템은 IDC 환경에서 운영되고 있어 AWS 클라우드 환경에 적용하기에는 한계가 있었습니다. APM Solution 들이 Cloud-Native 하게 Container 를 모니터링 할 수 있도록 전환되고 있으나, APM 외에 인프라 레벨의 Metrics 정보와 복잡한 연동 관계를 식별할 수 있는 Tracing 기능까지 모두 갖추고 있는 솔루션을 도입하고 싶었습니다. (개인적으로는 비용에 대한 고민 없이 원하는 솔루션을 도입할 수 있다는 상황에 신났던 것 같아요.)

로그 분석까지 가능한 2가지 솔루션을 검토하였고, 이마트 앱을 대상으로POC (Proof Of Concept) 를 진행 한 뒤, 적합하다고 판단한 솔루션을 선정하였습니다. 이 후 이마트 앱과 관련된 IDC 환경의 Oracle Database 들은 물론, AWS Cloud 와의 Seamless 한 Tracing 이 가능한 모니터링 시스템을 구축하고, 수 초 단위의 메인 화면 Health Check 를 통해 이상 현상 발생 시 메신저 연동을 구성해 바로 알람 받을 수 있도록 구성하였습니다.

당시 이마트앱은IDC 에서 개발/운영되고 있었던 전형적인 WEB-WAS-DB 의 아키텍처였던 As-Was 시스템의 WEB-WAS 의 영역을 AWS ECS Fargate 로 Migration 을 막 끝낸 상황이었습니다. (참고로, As-Is 대비 더 이전의 경우를 As-Was 로 지칭했습니다.) 통합 모니터링 솔루션을 통해 As-Is 에 대한 시각화를 할 수 있었고 현재의 품질 지표를 통해 개선 포인트를 찾아 실행하는 개발팀을 보면서 매우 뿌듯했던 것 같았습니다. 측정과 분석을 위한 적절한 도구를 제공하는 것이 얼마나 개발자에게 필수로 필요한지 다시 한번 깨닫게 되었습니다. 무엇보다 정적 컨텐츠에 대한 CloudFront 적용을 통한 캐싱 처리를 통해 ECS 부하를 감소시키고, 동기 방식의 로깅 정보 기록도 비동기 방식으로 전환한 점은 사용자 체감 응답 속도를 향상시킬 수 있었던 것은 어쩌면 간단하게 생각할 수 있는 방법일 수 있으나 직접 시각적으로 느끼는 것과는 차이가 크죠. 개발 팀 내부적으로 우선 순위를 조정하기 위한 기초 데이터로 작용도 했습니다.

지금은 D/T 본부의 기본 솔루션으로 적용하여 이마트 앱 뿐 아니라 다른 여러 시스템에서 활용하고 있습니다. 비교적 복잡한 아키텍처 설계는 필요하지 않았으나, 운영을 위한 Ground Rule 을 정의하고, 인프라가 아닌 개발 소스 배포 레벨에서 설정해야 하는 부분에 대한 템플릿화 등을 진행한 내용은 향후 별도 글로 풀어보도록 하겠습니다.

(2) 신규 연동 아키텍처 확장을 위한MSA 적용

As-Is 연동은 기존 Monolithic 으로 개발 된 어플리케이션에서 BackEnd API 를 통한 연동 방식이었습니다. 사실 상 As-Was WEB-WAS 영역만 Cloud 로 Migration 했으며, 동시에 Micro Service 로 전환하는 것보다 우선 Re-Platform 만 수행한 것이 현실적이고 합리적인 의사 결정이었다 생각했습니다. 어쩌면 연동 방식도 As-Was 의 연동 방식을 안정적으로 유지하는 것이 1차 목표였음은 당연할 수 밖에 없었을 것 같습니다.

이제는 Viewpoint 를 Developer 로 바꿔서 Architecture View 를 작성해야 합니다.

자체적으로 환경 구성 및 CICD 까지 고려하여 Simulation 했을 때 통해 API G/W, ALB, NLB 의 트래픽 Routing 의 경로를 확정할 수 있었습니다. 이 과정은 사실 상 아키텍처 설계 시 매우 중요한 과정으로 충분한 테스트를 통해 견고하고 안정적인 아키텍처를 제공할 수 있기 때문입니다. 이 후 개발자 가이드를 통해 아키텍처 변화를 시도했고, 구현 이후 개발자와 사전 검증 및 QA 를 지원하며 안정화 단계를 거치게 되었습니다.

레거시 시스템은 위 위키백과에서 정의한 것처럼 "낡은(old)" 그것입니다.

숨만 쉬게 그냥 두라고 하던걸요. (fade-out 이 예정되어 있어요)
건들지 마요. 어디서 문제가 터질지 몰라요. (변경의 영향 범위를 파악하는 것이 쉽지 않습니다.)
시스템의 반 이상을 바꿔야 하는데, 신규 구축을 하고 병행 운영하며 바꾸죠. (동시 운영이 더 어려울 것 같은데요.)
레거시 시스템을 Refactoring 하는 것은 달리는 자동차의 바퀴를 바꾸는 일입니다. (시스템 다운타임 필요해요.)
더이상 구하기도 기술 지원을 받기도 어려워요.

"낡은(old)" 의 의미는, 또한 End 를 의미하기도 했습니다.

"Re" 라는 것은 "다시 한다" 는 의미죠. 어떻게 다시 하겠다는 의사 결정은 현재와 미래를 이해하고, 그 갭을 줄이기에 적절한 전략을 선택하는 것일지도 모릅니다. 그리고, 비슷한 듯 다른 위 “Re” 개념들을 현장에서는 복합적으로 적용되고 있습니다.

Oracle Database 의 경우, EOS 버전도 섞여 있었고, 장기적으로는 Cloud Native 한 전환을 목표로 하고 있습니다. 당장의 미션 (트래픽 수용 가용성 증대, 연동 시스템 간의 의존성 최소화) 을 위해 일정 관리도 필요한 상황이었습니다.

우선, IDC 내에서 ADG (Active Data Guard) 방식과 OGG (Oracle Golden Gate) 방식의 Replica. Database 구성을 검토하였고, 최소 시간/노력으로 구현될 수 있는 ADG 방식을 선택하였습니다. 이 후 개발 부서에 Select Query 의 경우 Replica. Database 로 Data Source 변경을 가이드 했고, 지금은 Code 수정이 완료되어 검증 중에 있습니다.

이 단기적 해결책에 대해서는 사실 반대 의견도 있었습니다. 굳이 IDC 에 투자를 해야 할 필요가 없었기 때문이었습니다. 그리고, 어플리케이션에 대한 변경 부담도 있었습니다. 그러나, 트래픽 수용의 병목인 Database 에 대한 트래픽 분산 효과에 비해 매우 작은 투자이고, 최종의 목표인 Cloud-Native Database Architecture 에서도 Read Replica. 기반의 트래픽 분산을 위한 Code Refactoring 은 필연적인 부분임을 강조하여 설득할 수 있었습니다.

아쉽게도 Oracle Standard License 로 인해 OGG 외에는 방법이 없었던 Database 의 경우에는 Retain 을 선택했고, 다음 전략으로의 진행 우선 순위에 반영을 하는 방향으로 의사 결정했습니다.

결과적으로 Legacy Database Transformation 은 클라우드 환경으로의 Re-host, Re-platform, Re-architect 순으로 진행될 예정이며, 이 기간 동안에는 ADG 구성을 통한 트래픽 부하 분산이 어느 정도의 시간을 벌어 줄 것이라 생각됩니다.

이상으로 이마트 D/T 본부에 조인해서 가장 먼저 진행한 이마트앱의 As-Is 아키텍처 분석 및 To-Be 아키텍처 설계 과정에 대한 글을 마칩니다. 중점이 되었던 3가지 포인트 위주로 작성되어 사실 상 많은 내용을 포함하지는 못했지만, 이후에 개발팀에서 공유할 아키텍처 개선 활동의 결과도 매우 기대되고, 남은 아키텍처 개선 작업 추진도 성공적으로 이뤄내고 싶습니다.

그리고, 이 글의 To-Be Architecture Realization 과정에 대한 상세 레벨에 대해서는 공개 가능한 범위의 내용을 잘 발췌하여 이후에 공유할 예정입니다. 사실 이마트 D/T 의 중요 핵심 중의 하나인 Data 기반의 혁신의 기반이 되는 Data Lake / Service와의 연동 구조를 설계하는 과정에서 Architecture Model/Viewpoint/View 의 메커니즘을 가장 잘 살려야 하는 부분이기도 합니다.

여러 관점에서의 아키텍처를 설계하고 실현하는데 관심 있는 분들의 피드백과 조인은 언제나 환영합니다. eunbong.choi@emart.com 으로 편하게 연락 부탁 드립니다.

감사합니다.