앞선 포스팅인 1,2,3 편을 이어 이번 시리즈의 마지막인 4탄을 쓰게된 SpoonRadio DBA 김광호 (Ryan Kim)입니다.
이전 포스팅은 SRE(사이트 신뢰성 엔지니어링)와 DevOps를 중심으로, 마주친 문제와 그 문제를 해결해 나가는 과정에 대한 내용이었습니다. 이번 4탄에서 포스팅 될 내용은 Multiple Region / Account 에서 Database 를 어떻게 하면 효과적으로 운영하고 있는지에 대해 SpoonRadio 에서 활용하고 있는 기술을 통해 몇가지 예시를 설명할 예정입니다.
이전의 포스팅 내용이 궁금 하시다면 , 아래의 링크를 통하여 기술적 궁금증을 해소하는데 도움이 될 수 있을 것 같습니다.
앞선 포스팅에서 SpoonRadio 는 Multiple Region / Multiple Account 를 사용하고 있고, 그럴 때 발생할 수 있는 여러 문제들에 대해 충분히 설명을 했다고 생각합니다. 따라서 , 본 포스팅에선 문제점 보단 적용한 내용에 대해 초점을 맞추려고 합니다.
위 그림은 SpoonRadio 의 Tech Stack 입니다. 보시는 것처럼 저희는 Aurora PostgreSQL 및 Aurora MySQL 그리고 NoSQL 로 Document DB ( MongoDB ) 를 사용 하고 있습니다.
OLAP Data Pipeline
SpoonRadio 는 Multiple Account 에 산개되어 있는 데이터를 중앙 집중화 하여 Spark 에 적재 하고 있고, 이 데이터를 내부에서 사용 되는 OLAP Data로 활용 하고 있습니다.
중앙 집중화를 하기 위해서는 Multiple Account / Cross Region 간에 데이터가 이동하여야 하는 어려움이 있었지만 Data Tech 팀과의 협업으로 Pipeline 을 구축 하였습니다.
Service Define
- AWS Glue
- AirFlow
- AWS SNS ( Simple Notification Service )
- AWS SQS ( Simple Queue SErvice )
- AWS EventBridge
Service Workflow
이 작업은 2개의 파트로 진행 되었습니다.
- RDS Event Subscribe 로 부터 , Data Account 의 AWS SQS에 Message 를 전달 하는 과정
- AWS SQS 가 이벤트를 수신 하여 AirFlow가 적절한 작업을 통해 AWS Glue 로 데이터를 전송 하는 과정
위 내용 중에 제가 맡았던 RDS Event Subscribe 로 부터 AWS SQS 에 전달 하는 과정 까지를 이번 포스트에서 설명 하고자 합니다.
1차는 RDS 가 Automation backup 을 수행 하는 시간 + 1H 를 통해 Pipeline 을 구축 했었습니다. 이렇게 할경우 Data 가 너무 늦게 생성되는 이슈가 있어 그러한 이슈를 해결 하기 위해 Event 를 기반으로 처리 하는 방식으로 변경 하였습니다.
RDS 는 거의 모든 행위를 Event 로 발생시키고, 그 Event 를 Subscribe 하여 Airflow 로 전달만 한다면, 나머지는 Data Tech 팀에서 가능 하신것으로 판단 하여 Event 를 EventBridge 로 전달 할 수 있도록 이벤트를 구독 하였습니다.
이렇게 EventBridge 를 SNS Target 에 연결 하고, SNS 는 Data Account 로 받은 Topic 을 SQS 의 Queue 로 전달 하게 됩니다.
DataAccount 에서 SQS 를 설정한 뒤에 Topic 이 들어오길 기대 했지만, Topic 이 들어오지 않았습니다. SRE 엔지니어의 도움을 받아 아래와 같이 Access policy 를 설정 하였습니다.
{
"Sid": "topic-subscription-arn:aws:sns:us-east-1:{Service AccountId}:{SNSName}",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "SQS:SendMessage",
"Resource": "arn:aws:sqs:ap-northeast-1:{DataAccountId}:{SQSName}",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:sns:us-east-1:{Service AccountId}:{SNSName}"
}
}
}그리고 Queue 에 데이터가 들어오면 , 최초에 Confirmation message 가 들어옵니다.
{
"Type" : "SubscriptionConfirmation",
"MessageId" : "4e3f5270-3c08-447b-885a-668b59e5c192",
"Token" : "2336412f37fb687f5d51e6e2425ba1f2557c40cfa9296e76c92b2cb7ee7a2e143cc4f4d0b4f2de25bf6b29e9437d411f5aef604a1bc8f3f9ce09e6dca179610cffb05ed41f2a51d6f22d651035f80591191c11d32ccd81e2be6731203ddadafaace2e8935cbb142e9c7f583f9e09ed282fbd73f6e8f25128f23ddacc514911a3a7e0f23a3c5e8ac053c01d7f3a3bd2dd",
"TopicArn" : "arn:aws:sns:ap-northeast-1:{AccountId}:{SNSName}",
"Message" : "You have chosen to subscribe to the topic arn:aws:sns:ap-northeast-1:{AccountId}:{SNSName}.\nTo confirm the subscription, visit the SubscribeURL included in this message.",
"SubscribeURL" : "{Subscribe-URL}",
"Timestamp" : "2024-04-02T09:45:57.926Z",
"SignatureVersion" : "1",
"Signature" : "mzUxpREac1dDhyRlgL5D/vv2Oji5BHim52nSxcZFW9i0adqumJrmr0ukj0BAPXvGfLZHGpfPN1N3dv98A/ujmVSFzeosm+i1wrJVqJHtjRG19pukgCqwcqznnw8TNdmQyi7r4aQ8lRxja673Uqt1Bs9lUynJ8D/B8THBj6VBUQlfhVkVSoeto0DSjwvcNiqcPntNh+n0Kp3V7uQyudVRp+HCjBc3nei1OqRcnaAOKPUgmj/sed1fahnQU7zEsVXtX7EWXZXYeC2y7fy1AjocmMRhUCfWc8TELsJR2QVW8QKHsJPdsFEb/q3biBXFZok2dCfix0i76J1Kgwt2I2mAew==",
"SigningCertURL" : "{SigningCertURL}.pem"
}이런 형태의 Confirmation message 를 통해 SigningCertURL 을 Request Confirmation 에 넣으면 비로소 연결이 됩니다.
AWS SNS 와 Data Account 의 AWS SQS 를 연결함으로, 최종작업은 마무리 되었습니다.
Cost Optimization — RI
스푼라디오는 Cost Optimization 의일환으로 RI (Reserved Instance)를 활용하고 있습니다.
RI 는 아래와 같이 구성 되어있습니다.
- Partial Upfront: 반을 한번에 지불하고, 월별 금액을 지불 하는 형태
e.g. r5.large Instance : $869 , $ 0.099 / Hourly - All Upfront : 1년/3년 선택에 따라 전체를 구매하고 금액을 한번에 지불 하는 형태
e.g. r5.large Instance : $1,704.00 - No Upfront : 한번에 지불하는 금액을 $0 USD 로 하고, 매달 지불 하는 형태
e.g. r5.large Instance : $0.23 / Hourly
위 금액을 기준으로 월별 사용 금액을 예상해 본다면 Partial Upfront 는 $143.69 , All Upfront 는 $142 그리고 No Upfront 는 $165.6 로 계산 됩니다.
All Upfront 옵션을 선택할 경우 한 번에 큰 금액을 지불해야 하는 부담이 있으며, Partial Upfornt 에 비해 가격 메리트가 없다고 판단 했습니다. 따라서 SpoonRadio는 Partial Upfornt 를 채택하여 사용하게 되었습니다.
RI Design에는 두가지를 고려 하여야 합니다. SpoonRadio 는 아래와 같은 RI Design을 채택하여 활용 하고 있습니다.
해당 디자인을 만들 때 아래의 특징을 고려 하여 위 디자인을 구성 하였습니다.
- RI 는 Cross Account 는 가능 하지만 , Cross Region 은 불가능 합니다.
- RI 는 Aurora / RDS 는 Instance Family 까지만 일치 하면 되지만, Elastic Cache 등 다른 서비스는 Instance size 까지 모두 일치해야만 사용이 가능 합니다.
위 특징을 토대로 SpoonRadio Global Account 에 모든 RI 를 구매 하고, 각 Account 에서 RI 를 가져다가 Coverage 를 맞추도록 디자인 하였고 r5.large 단위로 구매 하여 같은 Region 에 r5 Family 를 갖고 있다면 유동적으로 사용할 수 있도록 디자인 하였습니다.
이로써 SpoonRadio 는 RDS 를 On demand 로 사용하는 것에 비해 약 35% 절감의 효과를 얻을 수 있었습니다.
Global monitoring With Datadog
SpoonRadio 에서는 Datadog 을 통해서 Multiple Account 의 모든 Database 를 모니터링할 수 있도록 구성 되어있습니다. 장애가 발생 하거나 문제 상황이 있을 때 각각의 Account 에서Cloudwatch metric 이나 Log 등을 확인하기는 많은 번거로움이 있습니다. 따라서 Database 를 효과적으로 모니터링 하기 위해 Datadog 을 활용하고 있습니다.
아래에서 DBM ( DataBase Monitoring ) , Log Forwarding , Cloudwatch metric 을 어떻게 설정 하였는지 설명 하고자 합니다.
Log forwarding
Datadog log forwarding서비스는 여러 가지 방법을 활용하여 Datadog에 Log 를 제공할 수 있도록 플랫폼을 제공 하고 있습니다. 이에 SpoonRadio 는 CloudFormation 을 통해서 Lambda 를 생성 하여 처리 하고 있습니다.
Launch Stack 을 클릭 하게 되면, 연결된 AWS 계정의 CloudFormation 으로 이동 하게되고, 설정을 하게 됩니다. 해당 CloudFormation 에는 아래의 Service 가 포함되어있고, SpoonRadio 는 최소한의 설정값을 변경하고 사용하고 있습니다.
- CloudWatchEventsPermission
- CloudWatchLogsPermission
- Forwarder ( Lambda )
- LogGroup
- S3
위에서 설명 한것 처럼 여러 Service 에 대한 설정이 포함되기 때문에 Menual 로 하는 경우 정확하게 설정이 되지 않을 수 있기 때문에 CloudFormation 혹은 Teraform 으로 진행 하는 것이 좋습니다.
CloudFormation 으로 생성을 다 마치면, Lambda 에 Forwarder 가 생성이 됩니다. 여기에 원하시는 Log Group 을 Trigger 하면 Forwarder 가 작동 하게 됩니다.
DBM ( DataBase Monitorig )
SpoonRadio 가 사용하는 Aurora Postgresql / MySQL 은 Session Level 을 trace 하여 모니터링 하는 것이 불가능 합니다. 전체적인 Query 와 Session 그리고 Plan 을 확인하기 위해서 SpoonRadio 에서는 DBM Service 를 활용 하고 있습니다
만약, Docker 를 이용하여 Datadog agent 를 실행 하고 있으시다면 아래의 설정을 확인하면 조금더 쉽게 Database monitoring 에 대한 설정을 확인할 수 있습니다.
그럼 SpoonRadio 에서 Database monitoring 에서 어떤 Insight 를 얻고 있는지 확인 해보겠습니다.
- Top Queries
DBM 을 활용 하는 첫번 째는 Top Queries 입니다. 어떤 Query가 어떤 이유 때문에 Database 에 부하를 주고 있는지를 확인할 수 있고 그로 인해 , 어떤 Query를 튜닝 하여 성능 개선에 도움을 줄 수 있는지 확인할 수 있습니다.
두 번째로 활용 하는 기능은 Active Connection 입니다. Active Connection 은 현재 실행 되고 있는 Connection 에 대한 정보를 표시 합니다. 여기서 쿼리를 하나 자세히 보기 위해서 한단계 더 들어가 보면 아래와 같은 정보를 볼 수 있습니다.
위 에서 보는 것 처럼 여기에는 Database 의 정보 ( User / Database / Client IP / Query ) 가 표시 되며, 그 Query 에 대한 정보 ( Total Excutions / Duration / Rows ) 가 표시 됩니다.
여기서 한가지 중요한 사실은 DBM 을 Enable 하는 시점 부터 모든 Query 는 하나의 Signature 를 갖게 된다는 것입니다. 따라서 Signature 단위로 추적이 가능 하게 됩니다.
Query signature 단위로 확인할 수 있는 정보는 다양하게 존재 합니다. 해당 쿼리에 Duration / Plan / Count / Total time / sample 등 DBA 들이 해당 쿼리를 튜닝 하기에 충분한 정보를 제공 하고 있습니다.
따라서, DBM 을 이용하여 Query의 Plan 을 활용 하고 Calling Service 를 이용하여 어디서 쿼리를 수행 했는지 까지 Databaes monitoring 을 통해 확인이 가능 합니다.
DBM 을 어떻게 활용 하는지를 좀더 자세하게 설명한 Youtube 가 있으니 확인 해보시면 더 많은 Insight 를 얻을 수 있을 것이라 생각합니다.
마치며..
SpoonRadio 에서 Multiple Account / Multiple Region 을 운영하면서 반복 작업을 최소화 하고, 통합 Account 에서 관리할 수 있는 방법들을 모색하는 과정은 많은 시간과 노력이 동반 되었습니다. 이러한 과정에서 다양한 산출물을 생성할 수 있덨던 것은 저에게는 큰 성과였습니다.
SpoonRadio의 SRE 팀과 DBA는 데이터베이스 관리뿐만 아니라 AWS 서비스에 대한 깊은 이해를 바탕으로 다양한 서비스를 활용해 아키텍처를 설계할 수 있는 역량을 갖추고 있습니다.
그런 역량을 토대로 팀내에서도 많은 프로젝트를 함께 진행했으며, 이러한 경험은 저를 포함한 팀원 모두에게 한 단계 더 성장할 수 있는 계기를 만들어 주었습니다.
지난 1편 부터 마지막 4편 까지 SRE팀의 플랫폼 엔지니어링으로 가기 위한 여정에 함께해 주셔서 감사드리며, SRE 팀 여정의 경험이 읽으시는 분들에게 많은 도움이 되었으면 합니다.
감사합니다!
