SAP Concur: DevOps 전략으로 Elastic 로깅 이용

이 게시물은 Elastic{ON} 2018에서 열린 커뮤니티 대담을 요약한 글입니다. 이러한 대담을 더 보고 싶으신가요? 컨퍼런스 아카이브를 확인하거나 근처 도시에서 Elastic{ON} Tour가 언제 열리는지 알아보시기 바랍니다.

경비 보고서를 작성해 본 경험이 있다면 SAP Concur를 사용해 보셨을 가능성이 높습니다. 150개국 이상에서 4,500만 명이 넘는 사용자(포춘 500대 기업의 70% 포함)를 보유한 Concur는 최고의 출장 및 경비 관리 솔루션입니다. 2016년 한 해에만 이 SaaS 솔루션은 870억 달러 이상의 경비를 처리했으며, 이는 매일 240만 건 이상의 영수증과 1억 8,700만 달러 이상의 청구서를 처리했다는 의미입니다. 엄청난 양의 회계 항목처럼 보일 수 있지만, 로깅 솔루션이 매일 처리해야 하는 로그 라인 수는 훨씬 더 많이 발생합니다.

Concur는 20년 넘게 운영되어 왔으며, 제품이 성장하고 발전함에 따라 로깅 솔루션도 함께 발전하였습니다. 사용하는 기술뿐만 아니라 사용 범위와 의도 또한 확장되었습니다. 처음에는 간단한 로그 저장에 사용되는 SQL 기반 솔루션이었으나, Elastic Stack에 구축된 현재의 로깅 솔루션은 엔드 투 엔드 애플리케이션 소유권을 촉진하고 개발, 테스트, 운영을 조율하는 데 도움을 줍니다. 앞으로 Concur의 LAMA(로깅, 경보, 모니터링, 분석) 팀은 운영 분석과 인사이트뿐만 아니라 롤아웃 및 롤백 자동화를 위해 Elastic 머신 러닝을 사용할 계획입니다. 로깅 분야에서 큰 발전을 이루었지만, 로그 저장에서 분석으로의 전환은 하루아침에 이루어진 것이 아닙니다.

원래 관계형 데이터베이스를 기반으로 구축된 이 로깅 솔루션은 RabbitMQ를 통해 XML 형식으로 로그 데이터를 수집했으며, 사용자들은 SQL을 사용하여 로그를 쉽게 쿼리할 수 있다는 점을 높이 평가했습니다. 하지만 서비스의 인기가 높아짐에 따라 사용량도 증가했습니다. 최대 데이터 수집량이 하루 200GB에 달하고 초당 1,500건 이상의 문서 처리 속도를 기록하면서 서비스는 한계에 도달했고, 성능 저하로 인해 사용자는 시스템에서 로그를 사용할 수 있을 때까지 최대 20분까지 기다려야 했습니다. 이에 대한 대응으로 로깅 팀은 데이터베이스를 더 강력한 하드웨어로 이전하는 것 외에는 다른 조치를 취할 수 없었지만, 이는 지속 가능한 해결책이 아니었습니다. 필요한 것은 수평적 확장성이었고, 더 나은 솔루션을 찾기 위한 여정을 시작했습니다.

Concur는 Elasticsearch를 조사하고 비슷한 상황에 처한 여러 기업의 성공 사례를 접한 후 로깅 솔루션으로 Elastic Stack을 선택했습니다. Elastic Stack은 빠르고 강력하며 확장성이 뛰어났을 뿐만 아니라, 내부 사용자들에게 더 중요한 기능인 시각화 기능을 갖추고 있었습니다. 이전에는 각 팀이 자체 인터페이스와 대시보드를 구축하면서 작업에 필요한 도구에 대한 라이선스 비용을 지출하는 경우가 많았습니다. Kibana를 도입함으로써 Concur는 통합 시각화 솔루션을 확보하여 자체 개발 또는 타사 시각화 솔루션에 대한 의존도를 없앴습니다.

Elastic을 처음 구현한 것은 Elasticsearch 1.1과 Kibana 3이며, Logstash, RabbitMQ(이전 SQL 솔루션에서 사용한 것과 동일), Fluentd에서 인제스트를 받았습니다. 로깅 팀은 Elastic의 오픈 소스 특성 덕분에 자체 경보 플러그인을 개발할 수 있었습니다. Elastic Stack에는 아직 경보 플러그인이 없었기 때문입니다. Elasticsearch의 향상된 속도, Kibana의 시각화 기능, 그리고 자체 개발한 Watcher 플러그인의 경보 기능 덕분에 Concur 전반에서 서비스 도입이 증가하였고, 인제스트 속도는 초당 5,000건의 문서로 급증하였습니다. 이는 기존 SQL 솔루션으로는 감당할 수 없는 수준입니다.

Elastic과 함께 솔루션에서 전략으로 성장

초기 구현 이후, Concur의 로깅 솔루션은 Elastic Stack과 함께 성장하였습니다. 2015년에 Elasticsearch 2.3과 Kibana 4.5로 업그레이드하고 골드 구독을 구매하였으며, Beats(Fluentd 대체), Watcher(자체 개발 솔루션 대체), Shield(보안용)를 사용하기 시작하였습니다. 또한 이번에는 맞춤 집계 UI를 포함한 또 다른 맞춤형 플러그인을 개발하였습니다. 로깅 솔루션이 개선됨에 따라 도입률도 증가하여 2017년에는 인제스트 속도가 최대 60,000문서/초(4TB/일)에 달하였습니다.

Elastic{ON} 2017에 참석한 후, Concur는 다시 업그레이드했습니다. 이번에는 클러스터 간 검색, 향상된 보안(GDPR 준수를 보장하기 위해 필요), 그리고 컨퍼런스에서 알게 된 다른 새로운 Elastic Stack 기능을 활용하기 위해서입니다. 클러스터 간 검색을 사용하여 모놀리식 클러스터를 여러 지역에 분산된 여러 개의 작은 클러스터로 나눌 수 있었습니다. 이 버전 업그레이드와 플래티넘 구독으로의 전환은 다양한 인제스트 소스, 여러 지역에 걸친 Elasticsearch 클러스터(미국의 경우 하루 5TB), 운영, SRE, 지원, 경영진 등에서 사용하는 Kibana 대시보드를 통해 현재 사용하는 환경을 구축하는 데 도움이 되었습니다. 그리고 6명의 엔지니어와 2명의 매니저로 구성된 LAMA 팀에서 모든 것을 관리하고 있습니다.

Concur가 로그 저장소에서 소유권 실현으로 전환한 과정을 알아보려면 Elastic @ SAP Concur: Driving the Journey to DevOps and End-to-End Ownership from Elastic{ON} 2018 동영상을 시청하세요. 이 동영상에서는 원클릭 로깅 서비스 배포를 구현한 방법, 200개 이상의 팀을 위한 매핑(비동적) 및 필드 구성 방법, 그리고 Elastic 머신 러닝의 강력한 기능을 활용하기 위한 향후 계획까지 확인할 수 있습니다.