이승학 버즈니 서비스엔지니어링 팀장

▲ 이승학 버즈니 서비스엔지니어링 팀장

[컴퓨터월드] 많은 애플리케이션들은 서비스 사용성과 품질을 보장하기 위해 상당부분 ‘검색’ 기술에 의존하고 있다. 하지만 검색은 다양한 기술의 융·복합체로 쉽게 접근하기 어렵고 여러 가지 어려운 배경 지식을 필요로 한다.

이런 검색 기술의 접근성을 높이고 구현을 용이하게 해주는 솔루션들로는 아파치 루씬(Apache Lucene) 라이브러리에서 파생된 아파치 솔라(Apache Solr), 엘라스틱서치(Elasticsearch)등이 있다. 엘라스틱서치의 필수 구성 요소들을 통해 검색 엔진에 대한 이해도를 높이고 서비스로서의 활용 가능성과 효용 가치를 공유하고자 강좌(6회)를 신설했다. <편집자 주>

1. 엘라스틱서치 파이썬 클라이언트를 이용한 ‘검색’ 입문 (2018.9)
2. 엘라스틱서치로 검색엔진 전환하기 (2018.10)
3. 엘라스틱서치 활용(1): 자동완성 (2018.11)
4. 엘라스틱서치 활용(2): 로그 시스템 (2019.1)
5. 엘라스틱서치 단계별 최적화 (2019.2)
6. 검색엔진 관리 자동화 (이번호)


지난 강좌들을 통해 엘라스틱서치를 활용한 검색시스템의 시작과 활용 및 최적화 포인트를 알아보았다. 검색엔진/시스템을 잘 구축했다면, 마지막 퍼즐은 의도한 수준의 품질을 유지하고 손쉽게 관리할 수 있는 도구와 방법들이 되겠다.

서비스를 전제로 구축된 시스템은 다양한 신규 요구사항과 개선으로 인해 지속적으로 변화하는 환경을 갖게 된다. 지속적인 변화는 일정한 수준의 품질을 제공하는 것을 쉽게 허용하지 않는다. 이를 위해 품질 변화나 변화에 영향을 줄 수 있는 부분을 인지하기 위한 모니터링부터 인지 상황에 따른 데이터, 시스템의 터칭 포인트를 로그 모니터링 자동화 예제를 통해서 살펴보도록 하자.

▲ AWS 환경의 검색엔진 관리 자동화를 위한 구조 예시

본 기고는 전문적인 관리 솔루션을 개발하기 위함이 아닌 기존의 서비스나 시스템 관리에서 용이성과 안정성을 도모하는 것이 주목적이므로, 직접 모든 단계를 개발하는 것보다 상용 시스템을 최대한 활용했다. 또한 AWS, 구글클라우드플랫폼(GCP), 애저(Azure) 등 어떠한 플랫폼 서비스를 선택해도 유사하게 구축이 가능하기 때문에 참고 수준으로 활용하길 바란다.

 

# Log collecting
검색이나 인덱싱 작업의 트래픽수준이 높아지거나 클러스터 상태에 따라 평소에 보여주던 성능에 문제가 발생된다면 직접적으로 서비스 품질에 영향을 주게 된다. 때문에 이를 빠르게 파악하고 미리 정의된 임시 대처방법이 있다면 빠르게 적용하기 위해서 로그를 의도에 맞게 잘 메트릭화하고 적재해야한다.

▲ 로그 수집-적재 단계

엘라스틱서치는 로깅을 위해서 아파치 Log4j2을 사용하며, Docker는 내부에 다양한 로깅 드라이버를 제공한다. 두 가지 로깅 방식 모두 다양한 로그 저장-전달 방식을 지원하지만, AWS Cloudwatch를 로깅 스토어로 활용하기 위해서 엘라스틱서치 로깅은 모니터링하고자 하는 수준과 정도를 명확하게 규정하고 Docker는 로깅 사용의 편의성과 다양성을 확보하도록 하자.

▲ 인덱스 수준의 검색, 인덱싱 질의 관련 로그 설정 예시

엘라스틱서치에는 엔진 성능이나 상황을 대변할 수 있는 영역을 규정하고 로그로 제공하고 있다. 대표적인 영역이 클러스터 상태, 검색과 인덱싱이 포함된 질의 성능, 데이터 변경점 기록에 대한 부분이다. 또한 단순히 질의에 관한 잘못된 요청에 대한 피드나 질의 문법에 대한 가이드도 피드로 로그에 포함된다.

엘라스틱서치에서 확인하고자 하는 내용 또는 확인하고자 하는 수준의 로그 설정을 하였다면, 로그 데이터를 적재하기 위해 Docker의 log-driver설정만 추가로 해주면 된다. Docker는 다양한 log driver plugin을 지원하고 간단한 변경만으로 사용이 가능하다. 우리는 AWS Cloudwatch를 로그 적재소에 적재하기 위해서 <그림 4>와 같이 awslogs log-driver를 사용하게 된다.

▲ docker awslogs log-driver 설정 예시

이렇게 엘라스틱서치-Docker-Cloudwatch 로 이어지는 간단한 로그 파이프라인이 구성됐다. <그림 5>와 같이 AWS Cloudwatch에 엘라스틱서치의 로그가 적재되는 것을 확인 할 수 있다.

▲ Docker-AWS Cloudwatch 로그 적재 화면

 

# Metric, Situation, Decision

▲ AWS Cloudwatch-SNS연동 기반 알림 구조 예시

원하는 주기와 수준으로 로그가 적재되고 있음을 확인 했다면, 다음은 의미를 부여하기 위한 메트릭을 설정하고 해당 메트릭을 필요로 하는 대상에게 전달해야 한다.

Cloudwatch는 패턴을 기반으로 한 메트릭을 생성할 수 있도록 도와준다. 생성과정은 <그림 7>과 같이 매우 간단하다. 대상 데이터를 지정하고 패턴을 설정하면 테스트까지 한 번에 수행할 수 있다.

▲ Cloudwatch의 메트릭 설정 예시

메트릭이 준비됐다면 AWS SNS를 이용해 해당 메트릭 구독을 원하는 대상에게 전달해보자. <그림 8>은 SNS에서 구독 주제를 생성하고 구독 방법에 관한 일련의 과정을 보여주고 있다. SNS는 단순히 알림을 위한 모바일기기, 이메일, 문자메시지에서부터 AWS 내부의 트리거 포인트로도 활용 할 수 있다.

▲ 메트릭 구독을 위한 AWS SNS 사용 예시

이제 마지막으로 미리 설정한 메트릭을 구독대상에게 전달하기 위한 트리거 수준만 설정해준다면 원하는 정보를 원하는 시점에 원하는 채널을 통해 받아 볼 수 있다. <그림 9>는 앞서 설정한 “WARN” 메트릭이 단 한건이라도 발생할 경우 전달받을 수 있도록 설정했고, 등록한 구독 채널로 정확히 전달받은 결과를 보여주고 있다. 구독을 통해 전달받은 내용에는 알람이 발생된 이유와 메트릭의 정보를 간략하게 제공해주고 있어 후속 조치를 위한 충분한 정보를 포함하고 있다.

▲ Clowdwatch-SNS 통한 메트릭-구독 결과

 

# Easy, Simple Apply

▲ AWS Lambda 중심의 자동화 지원 예시

로그-메트릭으로 구독 대상자에게 원하는 통상적인 정보, 경보-위험 정보를 제공하는 것만으로도 관리의 용이성이 크게 향상된다. 하지만 여기까지 본다면 자동화라는 키워드를 사용하기에는 부족한 측면이 있다. 예측 가능한 문제나 위험들을 명확히 정의하고 그 중에서도 대응방식이 반복되는 단순 작업들의 수고스러움을 덜어내야 앞서 구축한 수집-모니터링-알림 행위 기반에 자동화의 의미를 부여할 수 있다.

좋은 코드를 생산하거나 훌륭한 아키텍처가 만들어지더라도, 효율성과 현실적인 측면에서 단순 반복작업은 쉽게 버릴 수 있는 것이 아니다. 필자는 이런 부분까지 포용하고 효과적인 프로세스를 만들기 위해 AWS Lambda가 적절한 선택이라 생각한다.

▲ AWS Lambda 트리거 포인트 예시

엘라스틱서치에서도 가장 유용하게 적용할 수 있는 포인트를 들여다 보자. 엘라스틱서치는 검색엔진임과 동시에 데이터 스토리지를 겸하고 있기 때문에, 검색과 인덱싱에 대한 트레이드오프가 빈번하게 발생한다. 스케일-아웃 상황과 다르게 검색엔진 내부적으로는 Threadpool 또는 인덱스, 클러스터 세팅을 빠르게 반영함으로써 성능과 복합적인 비용 측면의 부담을 줄일 수 있을 것이다. 때문에 관리영역까지 포함하는 높은 수준의 REST API를 지원하는 엘라스틱서치와 Lambda로 대표되는 서버리스 컴퓨팅 제품들과의 시너지를 기대 할 수 있다.

 

마치며
자동화는 개발자나 관리자에게 있어서 항상 해결해야 하는 숙명이다. 특히 단순반복 되는 작업이라면 효율성 측면에서 무조건적이다. 혹자들은 개발자는 코딩과 아키텍처링을 위해 모든 리소스를 쏟아야 하므로, 유지보수에 대한 부담을 최소한으로 줄이거나 그것을 전담하는 사람이 있어야 한다고 말한다. 반대로 개발자가 유지보수 포인트를 잘 모르거나 하지 않으려고 한다면 결국 스스로 코드나 아키텍처의 개선 포인트를 놓치는 것이라는 주장도 있다.

유지보수, 관리 등 다양한 단어로 표현되는 이 영역의 자동화는 어떤 이유나 사례든 필수요건이 되고 있다. 서비스 또는 시스템을 잘 알고 있거나 더 잘 알고 싶어서, 나아가 최적의 운용 환경을 만들기 위해서 등 다양한 목적들이 이를 떠받치고 있다.

필자는 지속적인 개선과 새로운 요구사항을 만족시키기 위한 새로운 축으로 자동화가 해줄 역할이 다양하고 중요해 질 것이라 예상한다. 본문에서는 단순한 패턴과 일반적인 것들을 가지고 해보았지만, 독자 여러분들이 구축하고자 하는 도메인-서비스-시스템을 최적의 상태로 유지하고 발전시켜줄 수 있는 자동화 환경을 만들어 보길 바란다.

저작권자 © 컴퓨터월드 무단전재 및 재배포 금지