AWS Summit Seoul 2024 - 2일 차 후기

 

2024.05.18 - [일상] - AWS Summit Seoul 2024 - 1일 차 후기

 

1일차에 너무 많이 걷고, 세션에서 줄서는 시간이 길었어서 2일차부터는 전략을 다시 짰다.

 

기업 부스를 안가고(1일차에 많이 봣음) 세션 열리기 30분전부터 대기해서, 좋은 자리를 선점하는 방식으로 움직였다.

 

2일차는 플랫폼 엔지니어링이 뭔지 막연하게만 알고 있던 나에게 도움이 되는 좋은 세션이었들이 많았다. 

(1일 차 후기에 플랫폼 엔지니어링에 대한 내용이 들어갈 수 있었던건 2일차까지 봐서 였다)

 

 

4:30분 세션은 조기 연설 강연장에서 WAF에 대한 세션이 있어서 거기로 빠졌다.

 

강연장에서 준비된 세션이 있다는 걸 알았으면 더 필요한 것만 쏙쏙 잘 들었을 것 같은데 아쉬웠다.

 

플랫폼 엔지니어링 기반 개발자 생산성 극대화

여기서 플랫폼 엔지니어링 업무가 뭔지 분명히 설명을 해줬는데, 이 때는 내가 잘 이해를 못했던 것 같다.

 

아는만큼 보인다랄까

 

 

카카오페이증권은 전자금융감독원 하의 제약조건들이 많다. 케이 뱅크와 비슷한 상황인 듯함

 

두 개 이상의 데이터 센터에서 데이터를 관리 중이고, 요새 금융권의 클라우드 규제가 조금씩 풀리는 추세

 

 

들어가기에 앞서 카카오페이증권 데브옵스 팀에서 하는 업무를 정리하고 들어감

 

배포와 로그 수집에 관여함, k8s 이슈 확인 등의 업무를 처리하고 있음

 

 

그러나 개발자들의 요구사항을 한 팀에서 다 커버하기가 너무 힘듬. 서비스마다 사용하는 리소스들이 다 다르기 때문

 

그래서 이런 운영업무는 주번제로 처리하면서, 이러한 반복적인 운영 업무의 근본원인을 찾기 위해서 노력했다고 함

 

그리고, 가이드 문서화하고 자동화하는데 집중하기 시작.

 

시작하기에 앞서 어느부분까지 개발자들이 할수있나를 알아야 함 > GS 리테일 세션에서도 R&R이 중요하다고 했다

 

 

Wallga라는 CI/CD 플랫폼을 만들어서 DevOps팀의 업무를 자동화해서 개발자가 배포할 수 있록 있도록 처리

 

 

Hawk Eye라는 이벤트 플랫폼을 만들었음

 

개인화 설정을 추가해서 알림이나 파드, 노드의 이벤트를 알아볼 수 있게 함, 이벤트 히스토리 기반 추적할 수 있게 됨

> 서비스 통합 로그를 보는 셀프 서비스 같다

 

kubectl 사용성 개선 권한 통합관리 리소스 변경 감지

 

kubectl 사용성 개선을 위해 Hela라는 권한 통합관리, 리소스 변경 감지를 담당하는 셀프서비스를 만들었음

 

ES에서 누가 언제 어디에 접근했는지 알 수 있음, 상황에 맞게 자동화하고 모니터링도 가능하게 만들었음..

 

생산성 관리 플랫폼 WECAN

 

서비스 출시에는 많은 시간이 필요하다.

 

커뮤니케이션도 중요하고 코스트가 커지면서 지연과 병목 현상이 발생함

 

병목 구간을 찾아서 개발자가 해결할 수 있도록 하는게 목표.

 

backstage와 같은 단일 채널이 필요하게 됨

 

 

소프트웨어 생명 주기 전체 관리하고 싶었고, 인프라부터 개발환경 설정 API 테스트 배포까지 지원

 

플랫폼화해서 개발자가 불편함없이 사용할 수 있는게 목표라고 했음

---

여기서부터는 당근 세션

 

개발자에게 많은 자유로움을 제공하고 싶었다. 당근에서는 AWS의 모든 부분을 개발자가 관여할 수 있음

 

그러다보니 개발팀이 늘어감에 따라서 클라우드 담당자들에게 부하가 발생(다른 회사들과 동일한 이슈 발생)

 

병목이 생길 수 밖에 없다

 

여기서 IaC 도입 이유를 설명해줬음

AWS 리소스를 코드로 표현하고 싶었다 > 나도 할수만 있다면 좋다고 생각함 그러나...

현실은 코드와 리소스가 100프로 일치하지 않게 됨(콘솔에서도 많이 생성)

현재상태 반영을 하지 못해서, 버전별 플러그인 등 이리저리 문제가 발생함..

> 여기서 인프라 관리자들은 다 똑같은 문제를 겪고 있구나... 라고 있다고 생각함

 

너무 잦은 변경으로 인해 서비스용 리소스는 IaC와 헤어지기로 결정

 

 

개발자들이 실수하지 않고 개발 허들을 낮추는 것이 목표 였다고 함

 

KRP(캐럿 리소스 플랫폼)을 만들었음

AWS 리소스를 개발자들이 적절하게 배포하고 사용할 수 있게함

 

개발자플랫폼을 만들면서 배운점

1. AWS API(boto3) 장점과 단점 

장점 : 문서대로 작동함, 호출은 동기적이지만 비동기로 동작함

단점 : 지나치게 세세한 Client(클라이언트가 너무 많아서 언제 어떤걸 써야하는지 헷갈리), 콘솔과 다른 경험(ex 서브넷 그룹), 생성 중 실패한다면 중간에 생성된 리소스들이 삭제되지 않음

 

2. 사용자 경험의 중요함

너무 추상화해버리면 개발자들이 이해를 못하는 현상이 발생해버림. 그리고 한 리소스씩 생성하도록 유도해야함

쉬운 플랫폼 빠른 반응 > 어려운 이슈 쓰기 느린 반응 (플랫폼이 사용하기 쉬워서 플랫폼이 제공하지 않는 기능들을 사용하지 않게 되는 현상이 발생했지만 이건 의도된거라 문제가 없었음)

 

개발팀의 요청이 많이 줄어들게 되었음

적절한 비용 내에서…. 비용 추적 모니터링도 있음, 하나의 프로젝트는 하나의 태그를 사용하도록 해서 비용 추적

 

모두가 플랫폼을 만들어서 대응해야하는건 아니니까, 팀 상황에 맞춰서 적절한 작업을 해라는 조언을 해줬음

 

그냥 사내 서비스를 위해서 저런 것들까지 만드는구나하고 넘어갔던 세션인데 플랫폼 엔지니어링을 위한 셀프 서비스 제품을 만들었다는 걸 이해하는데는 조금 시간이 걸렸다.

 

Karpenter로 쿠버네티스 클러스터 최적화 : 비용 절감과 효율성 향상

나에게 꼭 필요했던 세션 중 하나다. 혼자 Karpenter를 구성하고 분석하느라 쉽지 않았는데 많은 도움이 됐다.

 

 

 

카펜터 말고 다른 오토스케일러인, 클러스터 오토 스케일러 + 오토스케일링 그룹을 사용하는 방식이 있는데 느리고 비용도 많이나가서 별로다. > 2024.05.09 - [개발/인프라] - Terraform으로 EKS 배포하기 6. 노드 오토스케일러 - Karpenter

 

카펜터는 컨테이너 확장 요구사항을 분석해서 가장 적절한 컨테이너를 선택해서 배포함, ASG에 종속되지 않아서 빠름

 

앞사람의 머리가 계속 찍힘

 

spec.requirements 설정으로 내가 원하는 cpu 아키텍처를 여러개 조건벼로 선택할 수 있고, 용량이나 스팟, 온디맨드 설정도 가능하다.

 

카펜터의 장점

1. 비용최적화

- 노드 통합 활성화, 효율적인 노드로 파드의 위치를 통합함, 스팟 중단에 대한 매커니즘도 있음

 

2. 스케줄링

- 파드 생성에는 시간이 소요되는데 최대 10초까지의 보류중인 파드들을 단일 배치로 구성

- 확장 윈도우 알고리즘을 사용함

  : 유휴대기시간(유휴파드가 생기고 다음 유휴파드가 생기기까지의 간격), 최대확장시간(윈도우를 나누는 시간)

 

3. 배치 빈패킹 의사결정

- 어떤 인스턴스를 만들 것인가? 비용순으로 인스턴스를 정렬하고 요구사항 교집합 > 재사용, 스케일 업 혹은 생성

- 데몬셋도 고려, 많은 수의 작은 인스턴스 대신 적은 수의 큰 인스턴스 타입을 선호

- 사용률 최적화가 아니라 비용 최적화다

- ec2 fleet을 AWS API로 관리하고, ec2를 생성하는데 유형에 따라 다른 할당전략을 사용한다.

- 온디맨드 가장 싼 가격, 스팟 가격 용량 최적화

- karpenter drift : 사용자가 정의한 내용과 실제 배포된 인스턴스가 다를때 워커노드가 중단됨. ami family로 aws제공하는 ami를 쓰면 알아서 노드가 재시작되면서 os가 교체됨

 

심층분석

지금 운영중인 노드가 중단되는 경우가 발생

 

중단 사유 정리

- Expiration : 특정 기간

- Drift : 스펙 해시 주기적 폴링

- Consolidation :  비용 최적화(노드 중단 가능 여부 파드 중단 최소화 오래된 노드 선호)

- Interruption : 비자발적 스팟용량 헬스 이벤트 등

 

어노테이션을 통해서 중단을 배제 시킬 수 도 있다. (do-not-disrupt 옵션)

 

위대한 상상의 Karpenter 도입기

 

카펜터의 여러 옵션이 있는데, instance generation은 설정하는게 좋다. 그리고 6세대 7세대만 쓰는게 좋다 차이 최대 50%

 

 

리소스 태깅 - 비용 추적, ebs gp3, kubelet 커스텀 추가 설정함

 

아직 조금 문제가 있다고 함

스팟 인터럽션 120초 안에 떠야 되지만 안되는 상황

노드가 100퍼씩 차는경우가 많아서 노드 오버 프로비저닝 전략을 씀

PodDisruptionBudget(PDB)도 잘 세워야함

 

오버 프로비저닝이란?

우선순위가 낮은 더미파드를 만들어서 사용량이 오버되면 더미파드가 내려가도록하는 전략

사용 빈도가 적은 시간에 되도록 재배치 되도록 전략을 세움

더미 파드 자리를 정말 배치되어야하는 파드가 배치되면서

더미 파드가 새로운 노드의 생성을 대기하고 배치된다.

안티 어피니티를 설정하면 더미 파드가 서로 다른 노드에 배치되도록 정의

 

PDB란?

파드의 중단을 제어하는 정책 PDB를 사용하면 클러스터 내의 파드 중단 시점에 대한 제한을 설정

 

다양성 측면에서 보는 Observability

데이터독에서 진행한 세션. 재미는 있었는데 너무 제품 홍보라 간단히 정리하고 넘어감

 

환경이 다양해질수록 모니터링.. 옵저버빌리티 해야할게 많아지고 있음

 

데이터독은 풀스택 옵저버빌리티가 가능함

 

메트릭이란?

 

하나의 메트릭으로는 큰 의미를 찾기 어렵지만

 

과거 데이터와 다른 메트릭과 연동해서 본다면 문제를 확인할 수 있는 경우가 많다.

 

 

메트릭의 종류 정리하고 나머진 제품 소개

 

로그

이벤트에 대한 기록

메트릭과 결합하면 조금 더 진화한 결과를 얻을 수 있음

 

트레이스

서로 연관된 메트릭들의 처리 정보

라이브러리가 필요하지만 데이터독에선 다 됨ㅋ

상관관계분석이 어렵지만 중요함

 

신세틱 테스트

실제 유저환경과 동일하게 두고 테스트를 하는 방법

 

Serverless 활용 : 스타트업의 효율적인 개발 환경 구축

2024.04.17 - [일상] - 4월 16일 (화) - AWSKRUG 서버리스 #serverless 모임 후기

 

4월 서버리스 소모임에서 발표자 두분이 AWS 서밋을 준비한다했었는데, 발표 자료만 정리되고 동일하게 들어왔다.

 

 

스타트 업의 개발 사이클은 하루에 10번 이상 배포한다. 그러다보니 3~5개의 서로 다른 개발 환경이 필요했음.

 

당연히 문제가 되는건 비용

발표자 분 서비스의 개발 환경 특이한건 없어보임

 

발표 내용은 앞서 말한 것 처럼 거의 같았음

 

FE : 버셀로 관리, 가격이 인당 20달러 추가.. 동시 빌드50개

로그 보관 1일, 제공하는것만 볼 수 있음, GitHub 자체에 문제가 생기면 배포 불가

 

 

서버리스로 테스트 환경을 구축했고 여러가지 팁을 남겨 줬음

 

- 프로비저닝을 해서 사용하기엔 비용 부담이 커서 사용한만큼 내고 싶을 때 좋다.

- 콘솔에서 생성환경을 불러 올 수 있음

- AWS 파라미터 스토어를 사용해보자

- 파게이트 종료시간을 즉시하지말고 여유롭게 둬라

- 파게이트 캐시 이미지를 가져오는 설정을 할 수 있음

- s3에 아티팩트를 저장하면 더 빠르게 할 수 있음

- 이벤트 브릿지로 Fargate를 종료 시킬 수 있음

- Fargate 스팟도 적극적을 이용해보자

 

 

이 파트는 물음표를 많이 띄웠을만한 세션이다.

 

내가 잘못 이해 한게 아니라면, 테스트를 서버리스로 하는게 아니라 서버리스 인프라를 테스트하는 법을 소개한 거였다..

 

 

여기서도 스파이크 트래픽이 문제가 됐음

 

스파이크 트래픽에 발생하는 문제에 대응하기 위해 부하 테스트를 진행했다고 한다.

 

테스트 용어 정리

 

 

이 발표자분 세션은 소모임 때랑 바뀐게 하나도 없었다.

2024.04.17 - [일상] - 4월 16일 (화) - AWSKRUG 서버리스 #serverless 모임 후기

 

개인적으로는 소모임에 나오셨던 마지막 발표자 분이 나와서 이런저런 이야기를 더해줬으면 재밌었을 것 같았다.

 

네번째 세션은 딱히 들을 게 없어서 회사 부스를 돌아다닐까 고민하던 중 EXPO 세션이 있는 걸 봣다.

 

 

현재 서비스에서 WAF를 사용하고는 있지만, 잘쓰고 있는지 것 같지 않아서 시간이 딱 맞아서 한번 들어봤다.

 

전 세션인 EKS를 선택한 이유를 들어 봤으면 좋았을 것 같긴했다.

AWS WAF 실전 도입 101

이런 넓은 곳에서 발표함

 

짧은 세션이라 특별한 내용은 없는데, 요약하면 네가지 정도의 권장사항을 알려주셨다.

 

WAF는 CloudFront에 연결해야 한다.

정규식을 쓰면 WCU를 많이 절약할 수 있다

실시간 모니터링엔 Firehose를 추가하는게 좋다.

테라폼을 쓰면 히스토리 관리나 장점이 많다.

 

WAF IP set 업데이트 간편하게하는 요령도 알려주셨는데, 그 정도는 수동으로 하지 싶다.

 

DevOps의 혁신 : Amazon EKS를 활용한 플랫폼 엔지니어링 적용하기

플랫폼 엔지니어링이 왜 필요하고, 어떤 업무를 하는지 명확히 정리해준 세션이었다.

 

이전 세션들에서도 소개가 있긴 했는데, 하는게 뭔진 알겠는데 저런거까지 필요한가 싶었던 부분들을 한번에 정리해줬다. 

 

 

플랫폼 엔지니어링이 필요한 이유 : 자주보던 문제인 서비스 어플리케이션마다 사용하는 인프라가 다르다. 

 

 

누가 인프라를 관리할 것인가? 가 이슈가 되기 시작 (R&R 이슈 발생)

 

 

1. 데브옵스팀이 중앙관리식으로가면 다수의 개발팀에 대한 대응은 어려움

2. 개발팀에게 모든 인프라 권한을 주기도 애매함 불일치 오류 보안취약 등등 > 개발자에게 더 많은 책임

3. 각팀에 데브옵스를 배치하기도 부담스러움

 

내부 플랫폼을 만들어서 개발자에게 제공하는게 골든 패스다.

 

사실상 셀프 서비스 지원을 위한 내부 제품을 만드는 것이다.

 

 

장점만 이야기하고 단점은 이야기해주지 않긴 했다.

 

단점은 아마 C레벨에게 오더를 받기 힘들 것 같다는 점이다. 굳이 그렇게 까지해야해? 라는 이야기가 나오기 딱 좋은 업무

 

 

고려할 점은 소유권과 추상화 수준, 언제 어떻게 도입할 것인지, 어떤 문제를 해결할 것인지 등이 있다.

 

개발자가 필요로하는 소유권과 개발자가 이해할 수 있는 추상화 수준이 DevOps 팀과 다를 수 있다는 점을 주의해야한다.

 

그리고, 개발자의 자유도를 낮추는 방향은 아니어야 함.. 개발자들이 손쉽게 사용해야한다.

 

관찰가능성(Observerablity)도 필요하다.

 

 

고객은 개발자임..

 

 

카카오페이 증권 발표자 분이 말했던, 작은 것부터 점진적으로 충분한 시간을 들여서 하라는 말을 다시 한번 해 줌

 

 

무신사가 플랫폼 엔지니어링을 시작한 이유 : 이대로는 안될것 같다는 절박함이 있었다.

 

 

모든 플랫폼에 대해서 지원해주고싶은데, 안되는 부분이 있어서 가능한 부분부터 나눠서 만들기 시작

 

인프라 생성 부분만 셀프서비스로 만들었음 : LaunchPad

 

셀프 서비스 지향 아키텍처가 필요해서 인프라를 먼저 수정함

셀프 서비스에 용이한 인프라가 먼저여야 한다. 개발자의 인지부조화를 추상화를 통해서 잘 지원해야한다.

개발자에게 필요한 부분만 지원해줘야 한다(인프라 담당자와 개발자의 영역을 잘 나눠야한다)

 

 

소프트웨어 카탈로그도 필요하다.

 

조직이 커지면 필요한 정보는 방대해지고 업무를 처리하는 시간보다 필요한 정보를 찾는 시간이 더 걸린다.

 

 

소프트웨어 카탈로그는 어느 서비스에서 어떤 툴을 사용하는지 백스테이지에서 제공.

 

어떤 개발자가 어떤 것을 담당하고 있는지도 알려준다.

 

명확한 소유권, 정보접근성 향상, 거버넌스 보장, 온보딩 시간 감소, 장애 대응 속도 향상 등의 이점을 얻음

 

가드레일 : 개발자의 독립상과 자율성을 높이는 방법 가드레일을 인지하는 것만으로도 사고를 막음

 

AWS 컨트롤 타워를 통한 샌드박스 환경 제공해서 퍼블릭 접근을 못하게 하고 고비용 인스턴스를 못 만들게 함

 

측정되지 않은 시스템은 알 수 없는 비용을 만든다.

 

인프라 사용량 비용 최적화 대시보드도 제공한다.

 

개인별로 기간별로 볼 수 있었음

 

 

무신사는 마지막으로 플랫폼에 GenAI를 적용해보려고 한다고 했다.

 

마치며

 

둘째날 세션이 나한테 필요한 정보들이 많았다.

 

AWS 쪽 아키텍트/컨설턴트 + 기업의 사례 소개로 구성된 세션들이 대부분 좋았다.

 

가장 큰 수확은 플랫폼 엔지니어링이 어떤 업무인지를 확실히 갈무리하고 왔다는 점이다.

 

어플리케이션이 계속 늘어나는 상황에서 BE 개발자들이 결국 인프라를 구축/관리해줘야 하는데,

 

이제는 필수 불가결인 쿠버네티스를 BE 개발자들이 다루기 어려워했을 것이다..

(BE 개발자인 내가 쿠버네티스를 다루는 입장이 되니까 확실히 알 수 있다. 알아야할게 너무 많다)

 

그러다보니 DevOps팀에서 개발 환경 구축 등 단순 반복 작업 요청이 많아져 병목이 발생했고,

 

반복작업에 지친 DevOps 팀이 인프라 관리를 플랫폼화해서 개발팀에게 작업을 위임시키는 일이 플랫폼 엔지니어링이다.

 

현 회사 전 팀장님과 서밋 후기를 주고 받다가 플랫폼 엔지니어링에 대한 이야기를 나눴는데, 

 

DevOps 팀이 클라우드 인프라 구축 > 안정화 > 비용 절감 > 그 다음 뭘하지? 하다가 나온 업무일거라고도 했다.

 

이런저런 새로 생기는 직무들이 보이는 와중에 BE 개발 업무에 대한 경계가 어떻게 되는걸까에 대한 고민이 많았는데,

 

BE 업무가 나눠진게 아니라 DevOps 업무가 개발팀의 필요에 따라 DevSecOps나 플랫폼엔지니어링으로 나뉜 것 같다.

 

확실히 AWS Summit을 다녀오고 견문이 넓어진 느낌이 든다.