📌 서론
작년에 회사에서 AWS 관리를 맡으면서 AWS 서비스들을 공부하고 관리하게 되었었다. 자연스레 매년 5월마다 열리는 AWS Summit 행사를 알게되었고 작년에 첫 참가했었다. 세션을 직접 들으면서 AWS 서비스들을 어떻게 활용하는지, 내가 몰랐던 AWS 서비스들을 알게되었고, 비용적으로 최적화 하는 기술들을 배웠었다. 작년에 참석했던 좋은 기억에 이어서 올해도 참가 신청을 했다.
작년과 다른점은, 회사가 바뀌고 프론트엔드 업무를 하고 있어서 AWS Summit을 출장 다녀오듯이 하지않고 회사에 굳이 알리지 않고 월차를 내고 조용히 다녀왔다.
📌 세션 선택
참가 신청을 하고 작년과 같이 어떤 세션이 열리는지 보고 듣고 싶은 세션에 동그라미 쳐두었다. 인기있는 세션 같은 경우에는 세션 입장시간이 다돼서 입장하려고 하면 일찍 마감되는 경우도 있기 때문에 한 세션이 끝나고 바로 다음 세션으로 들을 수 있는 강의장 앞으로 이동했다.
내가 선택한 세션들이고, 세션들을 보았을 때 좀 더 인공지능(AI)와 관련된 서비스들을 활용한 세션들이 많이 열린 것을 체감했다. 내가 써봤고, 우리 회사에서 다루거나 관심있는 분야를 위주로 선택했다. 그리고 자사 서비스를 홍보할 것 같은 세션은 선택에서 제외했다.
(하지만, 자사 서비스를 홍보하는 세션도 듣게 되었다... 제목만 보고는 완전히 파악할 순 없었다)
📌 입장
작년과 다르게 입장 등록을 하는 공간도 달랐다. 작년에는 바깥 복도에서 입장 등록을 했다면, 이번에는 입장 등록을 하는 큰 공간도 있었다. 그곳에서 입장등록을 하고 입장했다. 조금 불편했던 점은, 대여한 공간들이 워낙 크다 보니 입장 등록을 하는 곳과 엑스포는 붙어있지만 세션을 듣는 곳들의 거리가 꽤 돼서 이동하는 데 최소 10분이 소요되었다.
입장 등록하는 별도의 공간을 화려하게 꾸며놓았고, 항시 특정 영상을 틀어놓고 볼 수 있게 되어있었다.
입장 등록하는 바로 옆쪽에는 AWS 스폰하는 회사들의 엑스포가 있었고, 여기서 많은 기념품들을 수령할 수 있었다.
이번에도 여러 회사들을 돌아다니면서 기념품들을 받았고, AWS에서 주는 티셔츠도 받았다.
📌 세션 후기
내가 선택한 세션들을 듣고 간략하게 느낀 것을 메모해두었다.
📕 클라우드 보안의 새로운 패러다임
클라우드에 올려둔 서비스들의 보안을 어떻게 다룰지, 보안을 쉽게 제공하는 서비스인 Trand vision one 의 홍보로 끝나게 된 세션이다. 앞 내용에서는 보안에 대해 유용한 내용들을 소개해주어서 괜찮았다.
EC2 인스턴스를 위험 평가 대상으로 선택한다면, 권한 부여가 된 인스턴스가 외부로부터 침투 받았을 때 그 권한을 가지고 행사할 수 있는 게 있을 것이다. 예를 들면 EBS에 데이터를 가져온다거나, DB와 연동 되었다면 RDS를 접근함으로써 데이터를 외부로 유출할 수도 있다. EC2 인스턴스와 연관된 리소스 간의 관계를 미리 그려둠으로써 실제 침투를 받았을 때 빠르게 대응할 수 있다. 이 관계 그래프를 자산 그래프라고 한다.
클라우드 보안 핵심 - 잠재적 공격 경로 분석: 자산 그래프를 보고 위험 분석을 통해 잠재적인 위험 경로를 분석하는 내용, 외부로부터 인스턴스에 접근 되었을 경우 어떤 위험성이 있는지 파악하는 것
최근 많이 사용하는 컨테이너 서비스에 대한 부분인데, 컨테이너 보안을 위해서는 더 복잡한 구현이 필요하다. 개발자가 이미지를 빌드하면 CI 툴로 레포지토리에 이미지가 올라갈 것이고, 해당 클러스터에 배포가 되고 관리가 될텐데 빌드 과정에서 이미지 검사를 함으로써 취약점을 미리 발견하는 것이다. 검사를 통해 컨테이너 취약점이 있는 버전을 빌드하지 않았는지, 악성코드가 포함된 파일이 이미지에 포함되어 있지는 않은지 배포가 되기 전에 사전 검사하는 것이 중요하다.
안전한 이미지가 런타임에 배포가 된 뒤에도 런타임 시점에 취약점 검사(컨테이너를 실행시키는 EKS 쿠버네티스에서 발생할 수 있는 취약점)가 필요하다.
📕 서버리스 활용, 스타트업의 효율적 개발 환경 구축
그랜터의 윤창현님이 발표한 내용이다.
프론트엔드는 EKS로 운영했었는데, 비용이 더 많이 들었고 vercel을 사용하니까 비용도 줄였고 GUI도 잘되어있어서 편했다. 활용성 부분에서 EKS 보단 vercel이 더 좋았던 경험을 공유했다.
vercel을 사용하면 대부분의 기능을 무료로 사용할 수 있었고, 배포를 할 수 있는 노드는 한개를 제공하고 추가적으로 노드 한개당 50달러를 부과한다.
데이터독 럼을 이용해서 프론트엔드 모니터링을 하였다.
하지만, vercel과 git이 문제가 생겼을 때 손을 쓸 수가 없었다.
요구사항: 자유로운 환경을 구축하고 테스트 환경이 증가하더라도 비용이 크게 들지 않고 모니터링이 가능한 환경을 구축하고 싶었다.
따라서 비용을 절감하면서 가변적으로 테스트 환경을 구축할 수 있는 서버리스 환경을 구축하였다.
서버리스
- 관리할 서버가 없다
- 유연한 확장
- 고가용성
- 사용한만큼 지불
vercel은 코드가 푸쉬되면 s3 배포 대기열에 추가되고 순서가 되면 AWS Fargate를 통해 빌드 된다.
깃허브 코드 푸쉬 -> 파이프라인 시작 -> 코드 빌드 도커 생성 -> 코드 디플로이 -> ECR에 올라온 걸 fargate 실행 이순서로 진행된다.
각 테스트 환경마다 환경변수 변화가 필요할 수 있는데 AWS Parameter store을 사용해서 관리했다. AWS Code Deploy에서 환경변수를 동적으로 가져올 수 있었다.
Code Deploy - Fargate 배포는 콘솔의 몇번 클릭만으로 블루-그린 배포를 손쉽게 설정할 수 있었지만 배포 했을 때 몇초동안 502 에러가 발생하는 경우가 있었다. 블루-그린 배포를 원본 완료시간을 즉시로 하지말고 여유롭게 해서 해결하였다.
S3에 코드 아티팩트를 업로드하고 로컬 캐싱을 지정하여 빌드시간을 단축시킬 수 있었다.
AWS Eventbridge를 사용하면 테스트 환경 구축을 자동화 시킬 수 있다. 일정을 등록하여 어느 시간에는 테스트 환경을 끄고, 어느시간엔 키고 할 수 있다. (비용 절감)
Fargate spot: 유효 자원을 할인해서 사용할 수 있다. (최대 70퍼 할인)
결론적으로, 서버리스 환경을 구축하여 비용을 80% 절감했던 사례를 공유했다.
📕 스타트업을 위한 서버리스 기반에서 부하 테스트 진행 방법
노머스 김선형님이 발표한 내용을 메모했다.
프롬 서비스를 운영하고 있는데, 이 서비스의 패턴은 아티스트가 말하면 일시적으로 큰 부하가 오는 서비스 패턴을 가졌다. 따라서 부하 테스트의 필요성을 가지게 되었다.
부하 테스트 진행 절차는 아래와 같이 진행하였다.
- 테스트 툴 선정
- 테스트 시나리오 선정
- 목표 지표 정리
- 인프라 파악
- 테스트 준비
- 테스트 진행
- 개선방향 정리 결과 적용
-
테스트 툴 선정
Jmeter, locust(python) 등을 사용하였고, 사람이 많이 사용하는 툴로 선정하는것이 좋다. 확장에 유연해야 한다. -
테스트 시나리오 정의
모든 상황을 고려해야 한다. -
목표 지표 정리
현재 서비스가 원활할 때 응답 속도를 파악하며 기준을 잡아야 한다. 기존 데이터 기반으로 기준을 계산한다. -
인프라 파악
모든 인프라 리소스를 체크하고, 특정 API가 성능이 안나올 때 어떤 리소스에서 문제인지 확인해야한다. 꼼꼼하게 인프라를 확인해야 한다. -
테스트 준비
실제 운영 환경을 복제한다. 완전히 동일하게 만들어야 한다. -
테스트 진행
테스트 대상 리소스 인프라 변경이 빠르게 이뤄질 수 있는 환경을 구축한다. 모든 하드웨어 대상을 병목현상의 원인으로 둔다. 모니터링 대상에 부하 발생기도 두자. -
개선 방향 정리 결과 적용
점진적인 배포를 통해 모니터링을 병행하며 변경사항을 적용한다. 서버리스 환경에서 부하테스트를 진행하면서 유용한 팁을 공유했다.
- AWS Support plan을 화룡ㅇ하자
- 테스트 1회당 1개의 변수를 사용하자
- 비용을 너무 절약하는 것보다 테스트를 빠르게 진행하는것이 최종적으로 비용과 시간을 아낄 수 있다.
📕 AWS 서비스들을 활용하여 데이터레이크 구축하기
에티버스 서호석님이 발표하신 내용을 메모했다.
데이터레이크는 모든 규모의 정형 및 비정형 데이터를 저장할 수 있는 중앙 집중식 레포지토리이다. Raw data를 저장하고 신뢰성이 낮은 편이다. 일단 저장하고 보는 방식이다.
데이터 웨어하우스는 데이터를 구조화된 형태로 저장하고 포맷에 맞춰서 저장해야 하므로 신뢰성이 높은 편인다.
데이터레이크의 근본은 저장, 저장소인 S3가 핵심이다.
데이터 레이크하우스는 데이터 웨어하우스와 데이터 레이크를 합친것이다.
AWS에서의 데이터 레이크 하우스는 두개 합친것을 넘어 수집 저장, 가공 처리 분석, 보여주는것까지 총 플랫폼을 통틀어서 말한다.
금융에서의 데이터레이크는 일반적인 데이터 레이크에 보안, 관리, 규정까지 더하여 강화된 것을 말한다.
데이터 레이크 아키텍처는 수집 -> 전환, 향상 -> 분석, 시각화 영역으로 구성되어 있고, 중요한 영역은 스토리지 영역이다.
수집 영역에서는 AWS Kinesis를 사용하였는데, 서버리스 서비스로 예측이 어려운 이벤트성 수집에 사용했다. AWS Msk는 서버 기반으로 구성하여 지속적인 수집 영역에 주로 사용했다. Flume은 온프레미스에서부터 사용했으며 레거시 환경에서의 수집에 주로 사용했다.
전환, 향상 영역에서는 AWS Glue, Amazon Emr을 사용했다. Glue는 특수 요건 업무 또는 etl 업무에 사용했다. Emr은 지속적인 성능이 요구되는 영역에 사용했다. 추가적으로 세이지 메이커를 사용했는데 머신러닝 분석이 필요한 경우 추가적인 분석을 수행에서 데이터를 향상시켰다.
분석,시각화 영역에서는 시각화는 quicksight를 사용하며 여기에 필요한 질의는 Amazon Athena를 연계해서 사용했다.
스토리지 영역에서는 메타데이터인 카탈로그 데이터를 데이터 레이크 중앙 관리 계정에서 관리했다. 그러고 각 계정에서 카탈로그 카피본을 가지고 있게 했다.
보안 영역에서는 s3 액세스를 하는 경로를 인터넷을 통하는게 아니라 사설 네트워크 망으로 액세스하게 구축했다. 인터넷을 사용하는 구간은 한구간도 없게 구축했다. (금융권 보안)
결론적으로, 통합적으로 관리해줄 수 있는 AWS Lake Formation을 사용하면 완전 관리형 데이터레이크를 구축할 수 있다. 보안 및 관리 프로세스를 편리하게 구성할 수 있다.
