안녕하세요. SpoonRadio SRE 팀에서 DBA 업무를 담당하고 있는 Beaver(이선영)입니다. SpoonRadio에서는 다양한 데이터베이스를 사용하여 운영하고 있습니다. 그중에서도 NoSQL 데이터베이스로는 AWS DocumentDB를 사용합니다. 최근에 DocumentDB 3.6 버전이 EOS (End Of Service)가 되면서 5.0 버전으로의 업그레이드가 필요했습니다. SpoonRadio에서는 다국가 서비스를 하고 있으며 이에 따라 DocumentDB와 EC2 위에 MongoDB 사용을 혼용하여 서비스를 운영하고 있었습니다. 이번 작업시 모든 서비스의 안정적인 운영을 위해 MongoDB를 DocumentDB로 전환을 추가적으로 진행하였습니다.작업 절차작업 절차를 결정하기 위해서 DocumentDB 3.6의 데이터 용량 및 이동할 데이터양을 확인했습니다. 먼저, 사용되지 않는 데이터베이스는 제외하였습니다. 나머지 데이터베이스 중에서는 배치가 실행된 결과 값이 저장되고 있는 데이터베이스가 가장 큰 용량을 차지하고 있음을 확인하였습니다.그에 따라서 배치성 데이터베이스에 대해서 이동을 하지 않는다면 작업 시간을 최소화할 수 있어서 무중단으로 작업을 진행할 수 있을 것이라고 판단하였습니다. 해당 데이터베이스를 이동하지 않기 위해서 우리는 DocumentDB 3.6 과 5.0 버전에 양쪽에 데이터를 쓰도록 미리 변경을 진행하였습니다.Document DB 3.6 데이터 용량DocumentDB를 사용중인 환경에서의 작업 절차는 다음과 같습니다. 먼저, DocumentDB Parameter Group 에서 audit_log를 활성화하고 모든 쿼리문에 대한 로그를 dml_write로 변경하여 남기도록 설정하였습니다. 해당 파라미터는 Amazon CloudWatch audit logs가 활성화되었음을 나타내며, dml_write는 DML 쓰기 이벤트에 대한 감사 기록을 활성화하고, ddl은 DDL 이벤트에 대한 감사 기록을 활성화한다는 것을 의미합니다.Defines whether Amazon CloudWatch audit logs are enabled.enabled—CloudWatch audit logs are enabled.dml_write—auditing for DML write events is enabled.ddl—auditing for DDL events is enabled.데이터 이동 작업은 Backup, Restore, Resync로 나누어 진행했습니다. Backup은 Mongodump를 활용하여 진행하고, Restore는 MongoRestore를 이용하여 진행했습니다. 특히 Restore 과정에서는 불필요한 컬렉션을 제외하고 진행하여 작업 시간을 단축하였습니다.데이터 Backup과 Restore가 완료된 후에는 사용자에게 데이터베이스 권한부여, Batch 실행, DocumentDB 5.0의 정보를 확인하였습니다. 그리고 CloudWatch Logs를 통해 변경 내용을 확인하고 Resync를 통해 데이터 이동을 완료하였습니다.

이번 글에서는 분석 테이블을 API로 만들 수 있는 데이터서빙 서비스를 만들었던 과정을 소개 드리겠습니다.뱅크샐러드에서는 S3, Airflow, Spark 기반의 데이터 파이프라인을 통해 매일 수백종의 분석이 진행되고 있습니다. 데이터 파이프라인과 관련한 자세한 내용은 이전 글 데이터 분석가가 직접 정의, 배포, 관리하는 뱅크샐러드 데이터 파이프라인을 참고해주세요. 🙂데이터 파이프라인이 늘어나면서 자연스럽게 “데이터 파이프라인에서만 계산할 수 있는 데이터를 제품에서 사용할 수는 없을까?”는 고민을 하게 되었습니다. 이런 고민에서 “새소식”, “사용자 분석 태그” 등의 제품을 고안하게 되었습니다.먼저 새소식은 각종 소비, 건강, 자산 생활 소식을 사용자 별로 알려주는 서비스입니다. 월급날을 알려준다거나, 지난주 소비를 요약하고, 소비 패턴을 분석해주기도 합니다. 지금까지의 모든 누적 가입자에게 새소식을 발행하는 것은 비효율적이기에 새소식 발송 대상을 추출하고 대상에게만 새소식 내용을 계산하여 보낼 필요가 있는데요, 예를 들자면, 최근에 급여 이체 내역이 있는 사용자에게 월급날 새소식을 보내고, 지난주 소비 내역이 연동된 사용자에게 주간 소비리포트를 보내야 합니다. 그런데 “급여 내역이 존재”, “지난주 소비 내역이 연동됨” 같은 조건을 프로덕션 데이터베이스에서 계산하는 것은 꽤 어렵습니다. 계산에 필요한 데이터가 여러 서비스에 걸쳐 있고, 긴 기간 데이터에 복잡한 연산이 필요하기 떄문입니다. 그렇기에 새소식 발송 대상에 해당하는 각종 조건들을 데이터 파이프라인에서 쿼리로 계산하여 새소식 서비스에 매일 전송하기 위해 데이터 파이프라인을 활용하게 되었습니다.<사용자 분석 태그>사용자 분석 태그는 각종 데이터 분석을 통해 파악되는 사용자 속성을 서빙하는 서비스입니다. 미혼/기혼, 부모, 출산 예정, 구독중인 상품이 있는지, 자차 보유 여부, 부동산 구매 준비 여부 등 다양한 사용자 속성을 분석하고 사용자 별로 태깅합니다. 사용자별 태그는 각종 서비스와 어플리케이션 화면에서 사용자별 최적화 경험을 보여주는데 사용됩니다. 이런 사용자 분석 역시 여러 서비스와 여러 일자에 걸치는 복잡한 계산이 필요합니다. 그렇기에 사용자 분석 태그 서비스를 데이터 파이프라인을 통해 각 태그를 계산하고 매일 서비스 데이터베이스에 계산된 태그를 넣는 구조로 구현했습니다.문제 - 분석 테이블을 서비스에서 쉽게 사용 할 수 없을까?분석 데이터를 프로덕션에 사용하는 사례가 늘어남에 따라 파이프라인에서 어떻게 프로덕션 서비스에 데이터를 넣어주고, 명세를 약속하고, 서비스 API를 설계할지 매번 논의하게 되었습니다. 정해진 틀이 없었기에 매번 다른 아키텍처로 설계되곤 했는데요, 파이프라인이 프로덕션 서비스를 직접 호출하기도 하고, 프로덕션 데이터베이스에 데이터를 넣어주기도 하고, 서비스에서 분석 쿼리 서비스를 호출하여 배치로 데이터를 가져가기도 했습니다. 또, 앞서 설명 드린 새소식, 사용자 분석 태그 보다 작은 분석 데이터 제품을 만들 때면 이 제품 만을 위해 새로운 서비스를

지난 글에 이어 이번 글에서는 로깅 및 모니터링 영역과 데이터 보호 영역에 대해 살펴보겠습니다. 목차 * Logging & Monitoring * Logging * Log Retention Period * Centralized Logging * 로그 중앙화의 어려움 * Monitoring * 로그 모니터링 시스템 구성 * 리소스 사용량 모니터링 * Continuous Compliance * AWS Trusted Advisor * Data Protection * Encryption in Transit * HTTPS with ACM Certificate * VPC 내부 통신 등에서 TLS 사용 * Encryption at Rest * Server-Side Encryption * Client-Side Encryption * KMS를 활용한 암호화 키 관리 * 데이터 정책 수립 * 중요도에 따른 데이터 분류 * 민감한 정보가 포함된 데이터 관리 * 태그를 통해 분류된 데이터 관리 LOGGING & MONITORING 로깅 및 모니터링 영역은 클라우드 환경에서 발생하는 로그를 중앙으로 모아 보관하여 잠재적 보안 문제나 의심스러운 활동의 원인을 쉽고 빠르게 조사, 분석, 식별할 수 있는 환경을 구축하는 것을 목표로 합니다. 로깅 및 모니터링 아키텍처를 잘 갖추면 클라우드 사용 중에 발생하는 문제를 빠르게 파악하고, 문제의 원인 또한 수월하게 찾을 수 있습니다. 핑퐁팀에서 로깅 및 모니터링 영역 강화를 위해 적용한 내용을 소개하겠습니다. LOGGING 로깅 및 모니터링 영역에서는 로깅이 가장 중요합니다. 로그가 없으면 후술할 모니터링이 애초에 불가능할 뿐만 아니라, 사고가 발생했을 때 원인을 분석할 수 없기 때문입니다. 애플리케이션에서 오류가 발생하면 로그를 분석하여 원인을 찾는 것처럼, 클라우드 환경에서의 오류 또한 마찬가지입니다. 따라서 클라우드 API 호출과 관리 콘솔을 이용한 동작을 로그로 남겨야 합니다. AWS에서 로깅을 위해서는 대표적으로 CloudTrail을 사용할 수 있습니다. CloudTrail은 클라우드 감사 로그 서비스로, 활성화하면 사용자의 모든 활동이 사용한 역할(role), 활동의 위치(source IP), 행위의 형식(API 호출/관리 콘솔 접근 등), 요청의 파라미터 등과 함께 기록됩니다. CloudTrail을 활용하면 개발자의 실수나 보안 사고로 인해 클라우드 자원의 설정이 변경되거나 자원이 유실되는 경우에도 행위를 역추적하거나 의심스러운 활동을 분석하고 식별할 수 있습니다. 보안 강화를 위해서는 감사 로그뿐만 아니라 AWS 관리형 서비스의 로그도 수집해야 합니다. 아래 목록은 핑퐁팀에서 수집하는 AWS 서비스 로그입니다. * WAF ACL Logs: 웹 방화벽으로 들어오는 트래픽의 정보와 트래픽 허용 여부를 수집합니다. * GuardDuty Findings: VPC Flow Logs, AWS CloudTrail Logs, DNS Logs를 분석하여 위협을 탐지하고 그 결과 로그를 수집합니다. * S3 Access Lo

개발자를 위한 AWS 클라우드 보안 (2) - 로깅 및 모니터링과 데이터 보호이것만 알아도 클라우드 보안 마스터지난 글에 이어 이번 글에서는 로깅 및 모니터링 영역과 데이터 보호 영역에 대해 살펴보겠습니다.목차Logging & Monitoring로깅 및 모니터링 영역은 클라우드 환경에서 발생하는 로그를 중앙으로 모아 보관하여 잠재적 보안 문제나 의심스러운 활동의 원인을 쉽고 빠르게 조사, 분석, 식별할 수 있는 환경을 구축하는 것을 목표로 합니다. 로깅 및 모니터링 아키텍처를 잘 갖추면 클라우드 사용 중에 발생하는 문제를 빠르게 파악하고, 문제의 원인 또한 수월하게 찾을 수 있습니다.핑퐁팀에서 로깅 및 모니터링 영역 강화를 위해 적용한 내용을 소개하겠습니다.Logging로깅 및 모니터링 영역에서는 로깅이 가장 중요합니다. 로그가 없으면 후술할 모니터링이 애초에 불가능할 뿐만 아니라, 사고가 발생했을 때 원인을 분석할 수 없기 때문입니다. 애플리케이션에서 오류가 발생하면 로그를 분석하여 원인을 찾는 것처럼, 클라우드 환경에서의 오류 또한 마찬가지입니다. 따라서 클라우드 API 호출과 관리 콘솔을 이용한 동작을 로그로 남겨야 합니다.AWS에서 로깅을 위해서는 대표적으로 CloudTrail을 사용할 수 있습니다. CloudTrail은 클라우드 감사 로그 서비스로, 활성화하면 사용자의 모든 활동이 사용한 역할(role), 활동의 위치(source IP), 행위의 형식(API 호출/관리 콘솔 접근 등), 요청의 파라미터 등과 함께 기록됩니다. CloudTrail을 활용하면 개발자의 실수나 보안 사고로 인해 클라우드 자원의 설정이 변경되거나 자원이 유실되는 경우에도 행위를 역추적하거나 의심스러운 활동을 분석하고 식별할 수 있습니다.보안 강화를 위해서는 감사 로그뿐만 아니라 AWS 관리형 서비스의 로그도 수집해야 합니다. 아래 목록은 핑퐁팀에서 수집하는 AWS 서비스 로그입니다.WAF ACL Logs : 웹 방화벽으로 들어오는 트래픽의 정보와 트래픽 허용 여부를 수집합니다.: 웹 방화벽으로 들어오는 트래픽의 정보와 트래픽 허용 여부를 수집합니다. GuardDuty Findings : VPC Flow Logs, AWS CloudTrail Logs, DNS Logs를 분석하여 위협을 탐지하고 그 결과 로그를 수집합니다.: VPC Flow Logs, AWS CloudTrail Logs, DNS Logs를 분석하여 위협을 탐지하고 그 결과 로그를 수집합니다. S3 Access Logs : 중요한 정보가 들어있는 버킷의 접근 이력을 수집합니다.: 중요한 정보가 들어있는 버킷의 접근 이력을 수집합니다. VPC Flow Logs : VPC 내의 네트워크 흐름을 로깅하여 수집합니다. VPC Flow Logs 의 경우 양이 많을 수 있기 때문에 소수의 Network Interface 에 대해서만 제한적으로 수집합니다.: VPC 내의 네트워크 흐름을 로깅하여 수집합니다. VPC Flow Logs 의 경우 양이 많을 수 있기 때문에 소수의 Network Interfac