logo
logo
데이터
AWS Athena
표준 SQL을 사용해 Amazon S3에 저장된 데이터를 간편하게 분석할 수 있는 서버리스 대화식 쿼리 서비스
사용 기업
인공지능
교육
패션
부동산/인테리어
직장
기타
여행
금융/보험
푸드테크
이커머스
소셜/컨텐츠
헬스케어
종합
모빌리티
블록체인
techstack-logo
슈퍼브에이아이
techstack-logo
뤼이드
techstack-logo
딜리셔스
techstack-logo
직방
techstack-logo
모두싸인
techstack-logo
그린랩스
techstack-logo
버즈빌
techstack-logo
마이셀럽스
techstack-logo
카카오스타일
techstack-logo
야놀자
techstack-logo
뱅크샐러드
techstack-logo
우아한형제들
techstack-logo
번개장터
techstack-logo
아이오크롭스
techstack-logo
네오사피엔스
techstack-logo
튜링
techstack-logo
버킷플레이스
techstack-logo
옴니어스
더 보기
기술 블로그 글
SK텔레콤
AWS 정책변수 기반 사용자 리소스 별 IAM Policy 설계하기
Identity and Access Management(IAM)은 AWS 리소스에 대한 액세스를 안전하게 제어할 수 있는 웹 서비스입니다.AWS 웹콘솔에 접근하는 사용자들의 경우, IAM User를 발급 받아 직접 로그인을 하거나,IAM Identity Center에서 AD와 연동하여 사용자 별 IAM Role(Permission Set)을 임시로 할당 받아 SSO로 로그인 합니다.Athena, Sagemaker, S3 등 AWS 웹콘솔을 통한 매니지드 서비스를 사용자들에게 제공하는 경우,일반적으로 개인 별 WorkGroup, 개인 별 Domain, 개인 별 디렉토리 환경을 구성하여 접근하도록 합니다.이러한 구성을 할 때 사용자 별 권한 분리를 명확하게 하지 않을 경우, 리소스 안전성이 보장되지 않고 비용에 대한 추적도 어려워집니다.때문에 사용자 별 개인용 리소스에 대한 접근 권한 분리를 해주어야 하는데요,사용자가 두 명밖에 없다면 두 개의 IAM Policy를 만들어서 각각의 사용자에게 부여하면 되겠지만,사용자가 많아질 경우 사용자 수 만큼 IAM Policy를 늘리기엔 관리가 힘들어집니다.하여 AWS 정책변수를 활용하여 각 사용자 리소스 별 IAM Policy를 설계하는 방법을 공유 드리고자 합니다.1. 리소스 이름 기반으로 권한 분리하기 (S3)위와 같이 zero-user-bucket 이라는 S3 버킷 아래에 user1, user2 디렉토리를 만들어 두었습니다.그리고 user1이라는 IAM User를 생성하여, s3-policy-test라는 IAM Policy를 할당하였습니다.s3-policy-test의 내용은 아래와 같습니다.{aws:username}라는 정책변수는, 접근한 IAM User의 이름을 반환해 줍니다.우리는 user1 이라는 디렉토리를 만들었기 때문에, 위 권한을 통해 user1 IAM User는 자신의 이름과 동일한 user1 디렉토리에만 접근 권한을 갖고, user2 디렉토리는 접근할 수 없도록 policy를 설계하였습니다.-> user1 디렉토리는 정상적으로 접근이 됩니다.-> user2 디렉토리는 접근이 되지 않습니다.이로써 원하는 대로 설계한 policy가 리소스 이름에 따라 권한이 부여됨을 확인할 수 있었습니다.이번엔 Athena Workgroup에 대해 Tag 기반으로 접근 권한을 부여해 보겠습니다.위와 같이 2개의 Athena Workgroup을 만들어 두었습니다.그리고 각각의 Workgroup에는 해당 Workgroup 소유자에 대한 Tag 정보를 기입하였습니다.그리고 user1 IAM User에서 태그 기반 Athena 접근을 하기 위해 아래와 같이 athena-policy-test라는 IAM Policy를 추가 할당하였습니다.내용은 아래와 같습니다.위 내용을 보면, Resource Tag의 'owner' 키의 값이 {aws:username}과 일치하는 리소스에 대해서만 athena 권한을 획득할 수 있도록 하였습니다.이제 테스트를 해보겠습니다.-> user1-workgroup에서는 테이블 생성 쿼리가 정상적으로 수행됩니다.-> user2-workgroup에서는 athena:GetWorkGroup 권한을 획득하지 못하여 에러가 발생합니다.이로써 정상적으로 Tag 기반 사용자 별 리소스 권한 부여가 적용되었음을 확인할 수 있었습니다.(번외) IAM User가 아닌 SSO 사용자의 경우?AWS 공식 문서를 보면, 아래와 같이 IAM User가 아닌 Federation 혹은 Assume Role 사용자는 {aws:username} 정책변수가 존재하지 않습니다.이러한 경우에는 {aws:userid}라는 정책변수를 사용해 주면 됩니다.userid 값은 아래와 같이 AWS STS CLI를 통해 얻어낼 수 있습니다.
awsathena
브랜디
돈이 되는 Data Analytics
안녕하세요, Tech Data AI검색 소속 데이터 분석가 최정현입니다.지난해 말부터 커머스 유저 데이터를 분석 및 지표를 기획하고 대시보드로 자동화 하는 업무를 진행하였습니다. 이를 통해 추가적인 수익을 얻게 되었고 데이터를 통한 최적화 방향을 잡을 수 있었습니다.Databricks와 AWS 서비스를 활용한 데이터 파이프라인 설계 및 고도화 부분은 해당 작업을 맡아주셨던 같은 팀 권순철님이 작성해주셨습니다.먼저 대시보드를 만들게 된 계기와 구체적인 지표 선정 작업을 공유드려요. 그리고 Databricks와 AWS 서비스를 활용한 데이터 파이프라인 설계 과정과 대시보드의 임팩트 그리고 개선할 점으로 글을 구성했습니다.🏐 들어가며지난 11월, 브랜디 서비스는 메인페이지 추천 및 비즈니스 로직에 대한 실험을 진행했습니다. 그 결과, 실험을 진행한 조닝*에서 실험 집단이 통제 집단에 비해 압도적인 거래량을 발생시켰지만 실험 대상이 아닌 타 조닝에서 통제 집단이 실험 집단에 비해 높은 거래액을 발생시켰어요. 결국 상쇄된 거래액으로 인해 기존의 상품 진열 비즈니스 로직을 제거하지 않는 방향으로 결론이 났습니다.*조닝: 상품이 전시되는 영역해당 실험의 결과를 좌우한 핵심 지표는 ‘거래액’이었지만, 저희 팀은 이커머스 맥락에 맞춰 AARRR 지표를 위주로 추적하며 유저의 서비스 이용 과정에서의 어떤 차이가 해당 조닝에 대한 거래액 차이를 만들어냈는지 원인을 파악하는 작업을 진행했습니다.여기서 AARRR이란, 사용자의 서비스 이용 여정을 다섯 단계로 나누어 분석하는 프레임워크입니다. Activation(고객 획득), Activation(활성화), Retention(재방문율), Revenue(수익률), Referral(추천)으로 구성되어 있습니다.아래로 갈수록 사용자의 비율이 줄어드는 깔대기 모양으로, 더 많은 사용자를 각 단계에서 그 다음 단계로 전환시키키는 것을 목적으로 합니다. 궁극적으로는 사용자가 해당 서비스를 더 적극적으로 이용하고 더 많은 수익을 창출하는 건강한 사용자 여정을 만들고자 하는 것이죠. 해당 실험에서는 이 중에서도 Activation, Retention, Revenue 관련 지표를 개발하여 실험 결과를 측정했습니다.실험 기간인 한 달 간, 아래와 같이 매일 아파치 스파크를 활용하여 지표를 수동으로 추출 및 실험 리포트를 작성했는데요. 이 과정에서 실험 이후에도 해당 지표를 꾸준히 추적할 필요를 느꼈습니다. 따라서 해당 작업을 자동화하고 더욱 세밀한 AARRR 분석을 위해 대시보드 작업을 시작하였습니다.🥎 기존 고객 이탈을 방지하기 위한 AR 대시보드이전에는 대시보드가 없었나요?기존 태블로 대시보드가 존재했습니다만,(1) 다양한 차트와 대시보드가 산발적으로 존재해 서비스의 현황을 한눈에 진단하기 어려웠습니다.(2) 사업부의 요구사항에 따라 그때 그때 필요한 내용을 작성한 경우가 많아, 데이터 분석가가 서비스를 바라보는 관점은 포함되지 않았습니다.(3) 대부분 거래액과 같은 ‘결과 지표’ 위주로 집계하는 방식으로 작성되어 있었으며 ‘
awsathena
tableau
카카오페이
클라우드 비용 가시화 그렇게 어렵지 않아요!
안녕하세요, 카카오페이증권의 DevOps 팀에서 FinOps 업무를 담당하는 션이에요.이번 블로그는 최근 AWS 2023 re:Invent에서 카카오페이증권 CTO 블리츠가 발표한 일상과 투자를 연결하는 카카오페이증권의 클라우드 활용사례 ESG, 효율성 그리고 비용에 대한 도전 중에서 비용 가시화에 대한 내용을 깊게 알아보려고 해요. 조직의 규모가 커질수록 CostExplorer와 MSP에서 제공하는 비용관리와 가시화에 한계를 느끼는 경우가 많아요. 이런 한계를 카카오페이증권은 어떻게 기술적으로 풀어냈는지 한번 살펴봐요.우리는 어떤 한계를 만났을까?AWS에서 제공하는 CostExplorer는 전반적인 비용을 아주 잘 보여주는 서비스에요. 그러나 RI/SP 약정을 사용하고, EKS를 사용하다 보면 문제가 발생하는데요.• RI/SP 약정의 한계 RI를 사용하는 경우 결제 방식에 따라 비용이 다르게 표현되고, 개발팀에서 필요로 하는 사용량 증감을 CostExplorer에서 확인하기란 쉽지 않았어요.• EKS의 한계 카카오페이증권은 EKS를 표준으로 사용하고 있어요. 여기서 우리는 EKS에서 운영하는 서비스별 비용을 보고 싶었지만, CostExporer에서 확인 할 수 없었어요.카카오페이증권에서는 우리가 보고 싶은 데이터를 볼 수 있는 가시화가 필요했어요. 간략하게 살펴보면!• Amazon Athena view 테이블을 기반으로 Amazon QuickSight에서 가시화우리는 이 순서로 가시화를 진행했어요. 이제부터 하나씩 알아볼게요!AWS CUR 데이터는 시간 단위로 AWS에서 사용하는 모든 resource에 대한 비용 및 사용량 데이터에요. 매월 조직 규모에 따라 수백만에서 수십억 개의 데이터로 표현돼요. AWS CUR 생성할 때는 아래 옵션들을 통해 특정 S3에 데이터를 내보냈어요. 이 글에서는 직접 설정한 옵션을 한번 살펴볼게요.상세한 생성 가이드는 AWS Document - Creating Cost and Usage Reports에서 확인 할 수 있어요.• Include resource IDs : True• resource 단위로 세분화된 비용을 확인하는 옵션이에요.• Report data time granularity : Hourly• 시간당 데이터를 확인하는 옵션이에요.• Compression type : Parquet• Parquet는 csv, gzip보다 더 작고, Amazon Athena를 통해서 데이터를 확인 할 수 있는 압축 방식이에요.이렇게 설정을 해주면 AWS CUR데이터가 S3에 쌓이게 돼요!KubeCost는 cpu, memory 등의 컴퓨팅 자원 사용량을 기반으로 실제 Pod가 사용한 비용을 알 수 있도록 하는 오픈소스에요.설치는 helm chart를 이용해 운영하는 모든 클러스터에 적용했어요. KubeCost의 데이터를 AWS CUR 데이터와 통합하기 위해 지속적으로 KubeCost api를 이용해 pod 별 사용량을 수집하고, S3로 보내고 있어요.• accumulate : 출력된 데이터를 aggregate 단위
awsathena
삼성SDS
생성형 AI 기반의 직무 업스킬링 사례
이 글은 IDG의 아티클을 전재하여 제공합니다. [원문보기] 제품과 워크플로우에 생성형 AI 모델을 추가하려는 기업들의 움직임이 숨 가쁘다. 이로 인해 조직 인력의 역량을 높이려는 투자가 우선 과제로 부상하고 있다. 특히 프롬프트 엔지니어링, 윤리적 AI 관련 역량 고도화에 기업들이 주목하고 있다. 10월 말에 발표된 1,200명의 글로벌 CEO를 대상으로 한 어니스트 앤 영의 설문조사에 따르면, 무려 99%가 생성형 AI에 대한 투자를 계획 중이거나 이미 상당한 투자를 진행 중이라고 답했다. 11월에 발표된 2,100명 이상의 IT 리더를 대상으로 한 내쉬 스퀘어드 설문조사에 따르면 54%는 기술 부족으로 인해 변화의 속도를 따라잡지 못한다고 답했다. 가트너의 애널리스트 아룬 찬드라세카란은 기본적으로 AI 애플리케이션을 사용하는 모든 직원은 프롬프트 엔지니어링에 어느 정도 익숙해야 할 것이라고 진단했다. 최종사용자 수준에서 프롬프트 엔지니어링은 생성형 AI 도구로부터 최상의 응답을 얻을 수 있는 방식으로 질문하는 방법을 아는 것이다. 개발자 수준에서는 예를 들어 벡터 데이터베이스에서 보충 정보를 삽입하는 등 추가적인 뉘앙스가 있다. 또한 엔지니어는 모델을 미세 조정하는 방법을 배워야 할 수도 있으며, 일부 직원은 AI 모델을 안전하고 윤리적으로 책임감 있게 배포하는 방법을 배워야 한다고 했다.톰슨 로이터는 정보 비즈니스에서 활동해 온 기업이다. 톰슨 코퍼레이션은 1934년 신문사로 설립됐으며, 로이터는 그보다 훨씬 이전인 1851년에 주가 정보를 전송하는 조직으로 설립됐다. 이 미디어 조직에 인터넷의 등장은 치명타가 될 수도 있었지만 결국 살아남았고 번창했다. 회사는 지난 15년 동안 법률, 회계, 세무 전문가를 위한 새로운 비즈니스, 연구, 워크플로우 제품으로 다각화했다. 2008년 20달러로 떨어졌던 주가는 현재 170달러까지 올랐다. 지난 6월에는 6억 5,000만 달러를 들여 직원 104명의 케이스텍스트를 인수했다. 이 회사는 오픈AI의 GPT-4로 구동되는 AI 어시스턴트를 법률 전문가들에게 제공하는 조직이다. 톰슨 로이터는 또 주력 제품에 생성형 AI 기술을 추가하기 위해 연간 1억 달러를 투자할 계획이다. 이미 톰슨 로이터 생성형 AI 플랫폼을 구축하고 법률 리서치 도구인 웨스트로 프리시전을 위한 첫 번째 생성형 AI 어시스턴트를 출시했다. 내년에는 더 강력한 AI 어시스턴트가 다른 톰슨로이터 제품 전반의 인터페이스가 될 예정이다. 최고 인력 책임자인 메리 앨리스 부이치치는 단순히 기업에 정보를 제공하는 회사에서 벗어나고자 하는 것이 목표라고 했다. 회사는 더 창의적인 문제 해결과 더 많은 영향력을 발휘하는 전략적 파트너가 되기 위해 역할을 전환하고자 했다. 특히 직원들이 이러한 고부가가치 활동에 집중할 수 있는 시간을 확보할 수 있도록 업무의 속도와 품질을 개선하는 생성형 AI가 전략의 중심에 자리할 수 있도록 했다. 이 과정에서 교육과 업스킬링은 이러한 혁신에 필수였다. 지난 4월에는 1만 4,000명이 참석한 글로벌
awsathena
연관 기술 스택
techstack-logo
AWS Redshift
techstack-logo
Google BigQuery
techstack-logo
Presto
Copyright © 2025. Codenary All Rights Reserved.