요즘 진짜 덥다... 다들 개발 어캐하고있음??
난 에어컨 없이 못 살 것 같음 이제;;
암튼.
오늘은 내가 AWS를 써먹어보려고 고군분투한 이야기에 대해 써보고자 함.
서버에 대해서라면 거의 제로베이스인 내가 맨땅에 헤딩하면서 알아낸 것들이니까 누군가에겐 도움이 되지 않을까? 싶어서.
그나저나 요즘 진짜 AI 발전 많이 했다. 도큐먼트 굳이 하나하나씩 안 찾아봐도 그냥 '딸깍' 몇 번이면 뭐 해야하는지 잘 알려주네. 개꿀.
그러니까 이번 글을 통해서 나는 전체적인 사용 흐름을 알려주도록 할테니, 구체적인 내용 하나하나는 AI에게 물어봐. 진짜 자세히 알려주더라.
그래도 흐름을 알고있는 건 큰 도움이 될 거임. 난 이거 몰라서 많이 헤맸음...
나도 알려주고 싶은데 전문가가 아니라서 잘 모르겠다. 나중에 고수되면 더 알려줄게,,,
내가 AWS 사용을 검토하게 된 계기는 다음과 같음.
뭐??? 슬더스 개발자가 밸런스를 맞추기 위해서 유저들의 통계를 수집했다고?
흠.
이거 진짜 괜찮은 아이디어 같은 거임. 사실 당연한 거기도 하고.
유저 여론만 듣고 밸런스 패치를 하는 게임은... 요즘은 거의 없잖아? 내부 지표를 활용한다던가 아무튼 뭔가를 쓸텐데.
통계자료를 수집하는 건 그 중에서 가장 내가 듣기에 일리가 있는 방법 같았음.
근데 통계를 어떻게 수집하지?
서버를 두고 네트워킹을 활용해서 뭐... 데이터를 보낸다. 이건 알겠는데 그래서 어떻게 하는 건지에 대해서는 아무 것도 몰랐음.
로그를 쓴다? 이것도 몰랐지. 뭘 써야하지? 썼다면, 어떻게 보내야하지?
그래서 무작정 일단 해보기로 함.
"일단 똥을 싸라. 그러면 박수를 쳐 줄 것이다."
AWS 웹사이트에 들어왔는데 여기가 일단 뉴비 절단기임;;
뭘 해야하는지... 뭐 알려주지도 않고 이거 진입부터 개빡세더라. 무슨 루트계정을 만들고 어쩌구저쩌구;;
각설하고 내가 알아낸 내용부터 바로 알아보자.
0. 계정 생성 및 권한 할당
일단 계정의 종류를 알아야 함.
루트 계정이 있고.... 관리계정? 같은게 있음. 아마 처음 가입하면 만들어야 할 것은 루트계정. 루트 계정은 일종의 마스터키라고 보면 됨.
모든 권한을 갖고 있기 때문에 절대로! 노출되어선 안 됨. 그래서 AWS에서도 루트계정은 만들어두고 쓰지말라고 하더라.
대신 서브 계정을 만들어서 루트계정의 권한을 나눠주라고 하더라.
너는 결제 담당 계정, 너는 데이터 담당 계정... 이런 식으로.
애당초 AWS가 B2B를 상정하고 만든 시스템이라 그런지 여기서도 그런 냄새가 강하게 났음.
엔터프라이즈 요금제 쓸 때 라이센스 할당하는 개념으로 이해하면 될 듯?
암튼. 그래서 결론은 루트계정을 만들고 - 관리계정을 만들어야 함.
그리고 앞으로 대부분의 작업은 권한을 받은 관리계정에서 이행하게 될 거고.
권한 할당은 어디서 하느냐? 상단에 보면 검색하는 곳 있잖아? IAM을 치셈.
그럼 이렇게 IAM이 뜸.
참고로 IAM에서 크게 다루는 것은 '정책'과 '역할'인데,
정책이 권한이라고 생각하면 되고 역할은 그 권한묶음이라고 생각하면 됨. 계정에 할당하는 건 주로 역할이고.
그러니까 예시를 들어 쉽게 설명하면 정책은 뭐 '데이터 접근 권한' '데이터 수정 권한' 이런 것들이고
역할은 상술한 데이터 접근과 수정을 모두 수행하는 '데이터 관리자' 같은 거임.
그럼 무슨 정책을 할당해야하냐고? 그건 이제 너희들이 필요한 정책을 찾아서 할당해보자.
참고로 기본정책만 해도 개많고 커스텀 정책도 만들 수 있어서.... 자세히는 잘 모름. 난 내가 필요한 부분만 체리피킹했어. ㅋㅋ.
아... 미리 말하자면 루트계정과 관리자계정, 그리고 데이터관리자계정 총 3개를 만들어두는 걸 추천함. 왜냐고? 이유는 후술하겠음...
1. 스토리지 생성
자, 우리 목표는 데이터를 수집(저장)하고 분석하는 거니까 스토리지가 있어야겠지?
아마존에서는 이걸 S3가 해줌.
S3는 어디있냐고? IAM 찾았던 것처럼 검색하셈. 그럼 나온다. 버킷을 하나 만들어 주자. 버킷이 뭐냐고? S3에서 데이터를 담는 통임. 그래서 버킷인가 봄.
온갖 설정을 다 할 수 있다. 무슨 보안옵션이 어떻고 저떻고.
흠, 근데 아마존은 대기업이니까 웬만한 건 알아서 다 해주지 않을까? 난 모르겠고 기본 옵션으로 했음.
참고로 외부에서 버킷에 접근하려면 권한을 얻어야 함.
일종의 열쇠(key)가 필요한 셈인데, 이걸 할당하는 방법은 2가지가 있음.
1. presigned key라고 해서 1회용으로 쓸 수 있는 키를 넘겨주는 것.
2. 그냥 key 자체를 코드에 박는 것.
당연히 1번이 훨씬 안전하겠지? 근데 내가 아는 사람 중에 2번으로 구현한 사람도 있었는데...
그 사람도 몇만 다운로드 어플(심지어 결제도 있는!) 만든거 보면 당장 벌어지는 큰 문제는 없을 듯?
다만 누군가 내부 코드를 뜯어보면 다 털리는 불상사가 발생할 수 있음.
나는... 1번으로 구현하기로 했음. 만약 2번으로 할 거라면 2~3 항목 건너뛰고 바로 4번으로 넘어가도 돼.
2. Lambda 생성
이제 어떻게 찾는지 알겠지? 검색창에서 Lambda 검색해서 들어가.
람다가 뭐냐, 하면 말 그대로 함수야. AWS에서는 기능만 가진 함수를 만들어주는 것까지 해주나봐.
어떤 언어를 이용해서 어떤 기능을 가진 함수를 만들지를 여기서 결정해야 해.
나 같은 경우 Presigned key를 발급해주는 것을 목적으로 했기 때문에
여기서 해당 기능을 갖춘 스크립트를 만들었어. 참고로 테스트도 할 수 있음.
여기서 테스트 탭에 들어가면 우측의 주황색 <테스트> 버튼을 눌러서 결과값을 미리 받아 볼 수도 있음.
왜 화면을 시원시원하게 안 보여주고 자꾸 짤라서 보여주냐고??
나도 어디까지 보여줘도 되고 어디는 보여주면 안 되는지 몰라서 그래;;; 겁쟁이다 미안
그래도 알아 볼 수는 있잖아? 흐름만 읽어줘.
3. API Gateway
우리가 람다로 만든 함수는 말 그대로 기능만 있는 셈이야.
이걸 호출해주려면 외부에서 거쳐가야 하는 통로가 필요해. 그게 API 게이트웨이야.
API 게이트웨이를 통하면 어디서든 url 한 줄로 연결된 기능을 호출할 수 있게 돼.
그렇다고 웹페이지에서 url을 입력한다고 되는 건 아니더라. 나도 이건 전문가가 아니라서 잘 모르겠어.
뭐... 그치만 유니티에서 호출하면 되니까..... 그럼 된 거 아니겠어?! ㅋㅋㅋㅋ
아까 만들어 준 람다 함수를 여기에 연결해두자. 그럼 API Gateway > Deploy > Stage에서 url을 발급받을 수 있는데, 이걸 이용하면 돼.
4. 유니티 호출
자... 이제 유니티에서 호출해야겠지?
UnityWebRequest를 이용해서
이렇게 PresignedURL을 받아왔어.
이걸 통해서 데이터를 버킷에 넘기면....!
짠!!!
이렇게 버킷에 데이터들이 들어오게 돼. 짤은 처음 만들었을 때 테스트 용으로 넣은 로그들이야(벌써 한 달 전이네...!)
흠...
....
이것만으로는 그냥 데이터를 받아서 저장해 둔 것 뿐이고, 바로 클릭해서 읽을 수가 없더라고.
이제 이걸 통계로 볼 수 있게 만들어보자.
5. Glue
우리가 가져온 건 어디까지나 데이터의 집합일 뿐이야.
이제 이걸 AWS Athena가 '읽고 이해할 수 있도록' 만들어야해. 쿼리화시킨다고 생각하면 편하려나?
그걸 위해 필요한 게 글루야.
글루는 다음과 같은 메뉴로 이루어져 있어.
먼저 Database에 들어가서 Glue로 크롤링한 데이터들을 '어디에 저장할 지' 만들어주고
공간을 만들었다면 메뉴 하단에 Crawlers에 들어가서 크롤러를 하나 만들어 줘야 해.
참고로 크롤링은 크롤링 자체를 시작하고 끝내는데에 시간이 들기 때문에,
10개를 크롤링하던 100개를 크롤링하던 들어가는 시간은 2분 내외로 비슷하더라.
아마 AWS가 수십 수백만건을 기본으로하는 서비스를 제공 중이라 그런가봐. 이정도는 거기서 거기인 거지...
한 번 돌릴 때마다 돈이 조금씩 나가니까 조심해! 나도 프리플랜 이걸로 금방 깨져서 첫 달 천원인가 냈어 ㅋㅋㅋ
아무튼 이렇게 크롤링한 데이터들을? 이제 써먹어야겠지...
6. Athena
AWS 아테나는 통계분석을 해준다고 생각하면 돼.
SQL문법을 쓰니 써본 경험이 있는 사람은 쓰기 편할 거야. 난 처음 써보는 거라 지금도 고생 중이지만....
아무튼 그렇게 가져온 데이터들을 쿼리편집기에 넣고 SQL슥슥 써둔 다음에 딸깎 누르면???
짠!
이렇게 픽률/승률 통계를 뽑을 수 있음.
당장은 임시로 넣은 로그에 대한 데이터만 있어서 시행 횟수 자체가 적지만
이게 누적되면 꽤나 유의미한 데이터가 되지 않을까?? 그랬으면 좋겠다 히히.
7. Cloud Watch
자....
여끼까지만 하고 글을 마무리짓는다면 참 좋을 것 같지만.
사실 아직 해야할 일이 하나 남아있음....심지어 상당히 중요한 일임.
그치만 필수는 아니니까 내가 돈이 많다 or 내 게임은 어차피 망해서 아무도 안 할 것이다 이러면 안 해도 무방함.
바로 무엇이냐. 바로 로그 수집에 리미트를 거는 일임.
AWS는 놀랍게도 딸깍하면 마련할 수 있는 하드캡 시스템이 없다. 따라서 저렇게만 만들어두면 이론상 로그가 무한히 수집됨.
무한히 수집되는 로그는? 내 통장을 무한히 줄어들게 만든다.......
클라우드워치는 AWS의 활동을 감지하는 작업을 한다. 이걸 먼저 활성화해서 알람을 줄 수 있게끔 만들어야 함.
8. AWS Organization
이런 미친... 도대체 언제까지 해야하는 건데?
거의 다왔음. 조금만 참자...
앞서 설명한 정책과 역할 기억나지? 이걸 활용해서 Cost_Lock 정책을 하나 만들어야 함.
이 정책이 연결되면 모든 접근이 Deny되는 그런 정책으로.
그리고 이 정책을 데이터 관리자 계정에 걸어주는 방식으로 이용하면 되는....................... 데.
여기서 중요한 점은.
루트계정과 Admin 권한을 가진 관리계정은 해당 정책의 영향을 받지 않음.
중요하니까 크게 말함... 난 이걸 모르고 Admin 계정으로 만들었다가 여기서 다 갈아엎고 다시 데이터 관리 계정을 하나 만드는 불상사를 낳았음...
너희들은 나처럼 삽질하지 않길 바래............. 이러면 처음부터 다시 만들어야 함... 하 다시 생각해도 아득해진다.
아무튼! 이제 수동으로 권한 박탈하는 법을 알았으니까 이제 이걸 자동화시켜보자.
9. 결제 및 비용 관리
갑자기 한글이 나와서 낯설 수도 있지만 접근 방식은 같다.
이 친구도 검색 창에서 결제... 까지만 검색하면 자동완성으로 뜰 거임.
아참! 이 항목은 루트계정으로 들어가야 함. 관리계정으로도 되던가? 될 수도 있음. 아무튼 데이터관리자계정으로 접근하는 건 (보안상) 좋지 않다.
애당초 권한 설정을 빡빡하게 했다면 데이터관리자 계정은 내용에 접근조차 불가능 할 거임.
메뉴를 보면 '예산'이라고 적힌 항목이 있음.
해당 항목에 들어가서 예산을 만들어보자.
예산을 만들고 들어가보면 우측 상단에 '알림 항목이 있다.
대기 중인 작업 보이지?
나 같은 경우에는 80%, 100%일 때 알림을 2번 울리도록 설정했는데
이렇듯 80퍼센트 때에는 그냥 알림만 오고 100%가 되면 작업을 걸어서 cost_lock 정책을 연결하도록 만들었음.
여기서 코스트락 정책을 연결한다는 말은 아까 IAM Organization에서 말했듯이 접근권한을 박탈한다는 것. 이러면 더 이상 S3에 로그가 쌓이지 않게 됨.
해당 정책은 월초에 예산이 확보되면 자동으로 분리된다고 하니까 안심하자!
실험은 아직 못 해봤어. 보다시피 예산을 월15불로 걸어뒀는데 아직 15불을 써보질 못해서.
그나저나 15불.... 일단15불이긴 한데 게임이 잘 돼서 훨씬 더 많이 낼 수 있으면 좋겠다. 헤헤.
지금 생각해보면 어차피 로그 수집 정도로 쓸 거였다면 굳이 AWS를? 싶긴 하네. 닭 잡는데 소 잡는 칼을 쓴 느낌이랄까...(기능이 엄청 많고 다양하거든)
다음에 쓴다면 자체서버 한 번 도전해볼 듯??
10. 마무리
헥헥 힘들다...
지난 개발일지에서 말미에 다음에는 월드맵 관련 내용을 써본다고 했는데
생각해보니 개발자들은 그런 부분보다 새로운 내용을 더 좋아할 것 같아서 급하게 AWS 내용을 가져와봤어!
암튼 3줄 요약하자면
1. 통계수집하려고 AWS 썼음
2. AWS 생각보다 비전공자가 절대! 못 건들만한 통곡의 벽은 아닌 듯
3. 근데 다음에 또 쓴다면 비용 때문에라도 자체서버 도전할래
또 재밌는 소식 생기면 들고 올게~
다들 열심히 재밌게 개발하자~~ ㅎㅎㅎ
마무리는....... 우리의 기관사 임석대의 얼굴로 마무리!
댓글 1