저는 오늘 웹 서비스 개발 과정에서 발생할 수 있는 문제를 발견하고 해결한 과정에 대해서 공유를 드리고자 합니다.

저의 경험이 누군가에게 도움이 되고 영감이 되었으면 좋겠습니다.

목차

• 문제 배경
• 문제 해결 과정
• 도입 후 지속적인 개선 전략
• 결론
• 교훈과 배운 점

문제 배경

구글에서는 성능 측정 도구를 제공합니다. 이를 통해 웹 페이지의 성능을 정량화하고 분석할 수 있는데요.

텀블벅의 페이지를 분석하는 과정에서 서비스 성능의 병목점을 발견하게 됩니다. 그건 바로 실제 이미지의 사이즈와 렌더링 되는 이미지의 사이즈가 맞지 않았기 때문입니다.

텀블벅과 같은 크라우드 펀딩 서비스의 특성상 유저에게 고품질의 많은 이미지를 노출하게 되는데요.

이 과정에서 실제 이미지의 사이즈와 렌더링 되는 이미지의 사이즈가 맞지 않으면서 페이지의 성능을 저하시켰습니다.

기존 기술의 한계

텀블벅은 이미지를 처리하기 위해 SaaS 플랫폼을 사용하고 있습니다.

기존 구조에서는 관리와 비용 문제로 인해 서버에서 정해진 크기의 이미지만을 가져올 수 있었는데요. 이는 다음과 같은 문제를 가지고 있습니다.

1. 렌더링 되는 이미지의 사이즈와 실제 이미지가 일치하지 않습니다.

클라이언트에서 원하는 사이즈의 이미지를 요청할 수 없었기 때문에, 실제 렌더링 되는 사이즈와 관계없이 실제 이미지가 더 크게 내려오는 경우가 더러 있었습니다. 이는 웹 페이지의 성능을 저하시키는 원인이 됩니다.

2. 백엔드와 종속성이 생깁니다.

이미지 수정이 필요한 경우 백엔드 엔지니어에게 변경이 필요한 이미지는 어떤 것인지, 어떤 수정이 필요한지를 요청해야 합니다. 이미지를 사용하기 위해선 백엔드 작업이 완료되어야 했습니다.

이런 점들이 웹 서비스를 만들어나가는 데 있어서 팀의 퍼포먼스를 떨어뜨리는 병목점이 된다고 판단하였고, 팀의 퍼포먼스 증가와 비용 절감 이 두 가지 문제를 해결하기 위해 이미지 솔루션을 직접 도입하기로 결정하였습니다.

저희의 목표는 다음과 같았습니다.

• 이미지 작업시 팀의 퍼포먼스를 높이고 결과 이미지를 사용자에게 효율적으로 서빙한다.

새로운 기술 소개

현재 텀블벅의 가장 오래된 코드는 8년 전 2016년에 시작됩니다. 2016년이면 react의 버전 15가 등장한 시점인데요. (현재는 버전 16을 사용하고 있습니다.) 현재 대세를 이루고 있는 Next.js에서 이미지 최적화를 너무나도 잘 제공하고 있지만, 저희와 같이 레거시가 공존하고 있는 프로젝트에서 Next.js를 도입하는 것은 너무나도 큰 비용을 지불해야 합니다.

개발자가 의사결정할 때 항상 염두에 두어야 하는 것은 최소한의 노력으로 최대의 성과를 내는 것입니다. 그 과정에서 최소한의 자원으로 최대의 효과를 낼 수 있는 기술을 찾아내다보니 자연스럽게 서버리스로 눈이 향하게 되었습니다.

위의 문제를 해결하기 위한 서비스를 찾는 과정에서 저희가 선택한 해결 방안은 AWS Serverless Image Handler(이하 SIH)입니다.

SIH를 선택하게 된 이유는 다음과 같습니다.

• 클라이언트에서 원하는 크기의 이미지를 요청할 수 있다.
• 서버리스 아키텍처 특성상 인프라 관리 부담이 줄어든다.
• 이미지들이 AWS S3에 저장되고 있기 때문에 비용과 성능 면에서 많은 이점이 있다.
• 성능 향상은 유저의 경험 향상으로 이어진다.
• 확장성이 높기 때문에, 이미지 처리 요청 증가시 자동으로 확장되어 트래픽 증가에 따른 대응이 가능하다.
• S3에서 원본 데이터를 가져올 수 있기 때문에 별도의 Origin Caching Layer를 둘 필요가 없다.
• 성능 향상을 위한 지속적인 업데이트가 되고 있다. (업데이트 이력)

동작 원리

1. 클라이언트에서 HTTP 요청을 보내면 CloudFront에서 API Gateway로 전달된 요청을 Lambda 함수로 전달합니다.
2. 이전 요청으로 인해 이미지가 CloudFront에 의해 캐시된 경우, CloudFront는 요청을 API Gatewary로 전달하는 대신 캐시된 이미지를 반환합니다.

캐시되지 않은 요청은 API Gateway로 전달되고 전체 요청은 Lambda 함수로 전달됩니다. Lambda 함수는 S3 버킷에서 원본 이미지를 검색하고 Sharp를 사용하여 이미지의 수정된 버전을 API Gateway에 반환합니다.

주요 특징 및 기능

SIH는 다음과 같은 AWS 서비스를 사용합니다:

• CloudFront를 사용하여 유저에게 이미지를 빠르고 안전하게 제공합니다. SIH는 캐시된 액세스를 제공하기 위해 CloudFront 도메인 이름을 생성합니다.
• S3를 사용하여 이미지 asset을 저장합니다.
• AWS Secrets Manager의 이미지 URL signature를 통해 이미지 접근을 제한합니다.

도입 이후 예상 이점

성능 향상

• 클라이언트에서 원하는 사이즈의 이미지를 요청할 수 있습니다.
• CDN을 통해 빠르게 이미지를 제공할 수 있습니다.
• 확장성이 증가합니다. 이미지 처리 요청 증가 시 자동으로 확장되어 트래픽 증가에 따른 대응이 가능합니다.

비용 절감

• 이미지 처리 SaaS 사용 시에 비용의 대부분은 master images(원본 이미지)의 수에 의해서 결정됩니다. S3에서 이미지를 실시간으로 처리하기 때문에 해당하는 비용 자체를 없앨 수 있습니다.
• 저렴한 AWS Lambda를 사용하기 때문에 비용이 절감합니다.

유지 보수 용이성

• 서버리스 아키텍처 특성상 인프라 관리 부담이 줄어듭니다.

사용자 경험 향상

• 성능이 향상되면 이미지가 더 빠르게 전달되고, 이는 사용자 경험을 높여줍니다.

사용 방법

이미지 요청 생성 및 사용 방법은 대략적으로 아래와 같습니다.

1. JSON 요청 객체를 문자열화합니다.
2. Base64로 JSON 문자열을 인코딩합니다.
3. 인코딩된 문자열을 CloudFront URL에 추가합니다.

사용 방법에 대한 자세한 내용은 AWS 공식 문서에서 확인하실 수 있습니다.

문제 해결 과정

점진적인 도입 vs 전면적인 도입

텀블벅 서비스는 이미지를 굉장히 많은 곳에서 다루고 있습니다. 전면적인 도입을 한다고 가정했을 때, 대부분의 페이지에서 수정이 필요했기 때문에 전면적 도입의 리스크가 크다고 판단하였습니다.

이런 리스크를 줄이기 위해 이미지가 사용되는 일부 페이지에 점진적인 도입을 하는 것이 옳다고 판단하였습니다. 로그 관찰과 운영 이슈 트래킹을 통해 추이를 지켜본 이후 다른 페이지에도 적용하는 순서로 가는 것이 좋다고 판단하였습니다.

개발 순서

1. 원본 이미지를 resize 하는 S3 트리거(lambda) 개발
2. SIH 생성
3. 적용
4. 테스트
5. 배포

1. 원본 이미지를 resize 하는 S3 트리거(lambda) 개발

여기까지 잘 따라오신 분들은 이렇게 되물으실 수 있습니다.

“그냥 SIH 만들면 되는거 아니야 ? 뭔 갑자기 S3 트리거 개발 ??”

그 이유를 알기 위해서는 S3 트리거를 통해 무엇을 이루려고 하는지를 알아야 합니다.

저희가 만든 트리거는 특정 S3 버킷에 들어온 이미지가 특정 width를 넘으면 resize해주는 역할을 하고 있습니다. 특정 width가 넘으면 이미지의 크기가 불필요하게 크다고 판단한 것이지요.

그렇다면 resizing이 왜 필요한 것일까요 ?

이는 어찌 보면 당연합니다. 이미지 데이터가 S3 — CDN — end user 사이를 오가는데, 거대한 용량의 이미지보다는 경량화된 이미지가 더 적은 리소스로 처리될 것이기 때문입니다.

즉, 유저에게 받는 이미지가 규격화 되어 있지 않기 때문에, 큰 이미지에 한해 resize를 하면서 데이터 이동간 리소스를 최소화 했습니다.

그럼 여기서 눈치가 빠른 분들은 한 번 더 이렇게 물으실 수 있습니다.

“처음부터 이미지를 줄여서 저장하면 되는 거 아니야 ??”

그러나, 원본 이미지를 가지고 있어야 이미지 화질에 대한 Voice Of Customer(이하 VoC)에 대응할 수 있습니다. 쉽게 말해서, 고객이 이미지가 마음에 들지 않는다며 교체를 요구했을 때, 원본 이미지가 있어야 대응할 수 있는 것이지요.

그래서 원본 이미지는 따로 저장하고, resize된 이미지를 별개로 가지고 있어야 한다고 판단하였습니다.

원본 이미지 resize를 위한 트리거 개발 과정은 다음과 같습니다. (AWS 공식 문서)

1. 권한 정책 생성
2. 실행 역할 생성
3. Lambda 함수 생성
4. 함수 코드 배포
5. S3 트리거 생성 (S3와 Lambda 함수 연결)
6. Lamda 함수 테스트

Lambda 함수의 역할은 다음과 같습니다.

1. 이미지 리사이즈

jpg(jpeg), png

• 이미지의 width가 1240(렌더링 되는 이미지 width x 2)을 넘을 시 aspect-ratio를 유지한 상태로 이미지를 resizing 합니다.
• 이미지가 1240이 넘지 않을 시에는 원본 데이터를 넘깁니다.

gif

• gif일 경우에는 원본 데이터를 넘깁니다. 람다의 호출 페이로드 요청 및 응답 제한은 6MB이기 때문에 용량이 큰 gif의 경우 람다를 통해 처리하는 것에는 무리가 있었습니다. 이 과정에서 여러 대안을 강구했지만 결국 원본을 전달하는 것이 가장 적절하다고 판단하였습니다.

2. 확장자 유지

• 이미지 처리 과정에서 sharp 라이브러리 사용 시 자동으로 확장자가 변경되는 경우가 있는데요. 이 경우에는 sharp의 force 속성을 통해 확장자를 유지시킬 수 있습니다.

3. 이미지 돌아감 방지

• 이미지를 resizing 하는 과정에서 파일의 메타데이터인 exif data가 사라지는 경우가 있는데요. 이를 방지하기 위해 widthMetadata() 속성을 사용하여 이를 예방할 수 있습니다.

4. 버킷 이동

• sourceBucket에 데이터가 들어오면 resizing된 이미지를 destinationBucket으로 이동시킵니다.

2. SIH 생성

AWS의 CloudFormation을 통해 SIH를 생성할 수 있습니다.

이후, 사용할 S3 bucket 이름 설정을 통해 사용할 수 있습니다.

1. CloudFormation을 통한 SIH 생성
2. 설정한 S3 bucket 이미지 업로드 후 테스트
3. CloudFront에서 사용할 도메인으로 설정 (예: image.tumblbug.com)

상세 구현 가이드는 이곳에서 확인할 수 있습니다.

3. SIH 적용

일단, 여기까지 따라오신 여러분 정말 칭찬 드립니다. 👍👍👍

지금까지 설명한 내용을 한번 되짚어 보겠습니다.

1. 사용자가 이미지를 올립니다.
2. 해당 이미지가 원본 S3 bucket에 저장됩니다.
3. bucket에서 트리거가 발동되어 resizing bucket에 저장됩니다.
4. 사용자에게 요청된 이미지는 resizing bucket에서 가져옵니다.

그럼 예리하신 몇몇 분께서는 이런 질문을 하실 수 있습니다.

“만약 이미지를 최초로 업로드 한 사람이, 이미지가 resizing 처리가 되기 이전에 이미지를 요청하면 어떻게 되나요 ?”

이럴 때 사용할 수 있는 기법이 폴링입니다.

폴링은 쉽게 말해, 가져오고 싶은 이미지를 가져올 수 있을 때까지 주기적으로 요청하는 방식입니다. 폴링 기법 구현을 위해 이미지가 성공적으로 호출될 때까지 1초마다 요청하였습니다.

그런데 CDN과 폴링을 같이 구현하다 보면 한 가지 문제가 생기는데요. 이는 CloudFront의 error caching minimum TTL 때문입니다.

CloudFront는 error caching minimum TTL이 기본적으로 10초입니다. 이는 쉽게 말해서 캐시 된 에러는 최소 10초간 유효하다라는 의미인데요. 폴링을 사용하여 동일한 이미지를 요청한 뒤에 에러가 발생하면, 이미지가 resizing-bucket에 저장되더라도, 10초가 지나야 이미지를 가져올 수 있었습니다.

이를 해결하기 위해 캐시 버스팅을 사용하였습니다. 캐시 버스팅을 하기 위한 방법은 다양하지만 저희는 그 중 width를 1px씩 변경하며 요청하는 방식을 사용하였습니다.

캐시 버스팅은 방대한 내용을 포함하고 있어 자세한 내용은 다음 포스트에서 다루도록 하겠습니다.

4. 적용 테스트

테스트는 PO, PM과 함께 실제 이미지들을 넣어보면서 진행하였습니다.

주요 테스트 사항은 다음과 같습니다.

• JPG, JPEG, PNG, GIF가 성공적으로 렌더링 되는지
• 이미지의 화질이 너무 떨어지지 않는지

5. 배포

현재 서비스되고 있는 기능을 오류 없이 배포한다는 것은 많은 준비작업을 필요로 합니다.

오류를 최소화하기 위해, production과 같은 환경을 가지는 alpha 환경을 Elastic Beanstalk을 통해 배포해서 실제 production이 배포되기 전에 실제와 동일한 환경에서 테스트 해 볼 수 있었습니다. 절차는 아래와 같습니다.

1. alpha 환경 생성 및 어플리케이션 배포
2. production S3 bucket에 resize 트리거 적용
3. 실제 사용자들이 등록한 이미지가 신규 도메인으로 잘 서비스 되는지 확인
4. production 배포

도입 후 지속적인 개선 전략

피드백 수집 및 적용 방법

AWS CloudWatch를 통해 지속적인 요청량과 로그를 실시간으로 모니터링할 수 있습니다.

적용 후 결과 추이

위 사진을 통해 SIH를 통한 요청이 증가함을 알 수 있습니다.

위 사진을 통해 SaaS의 요청과 bandwidth가 줄어들고 있음을 알 수 있습니다.

결론

도입 총평

크라우드 펀딩 특성상 상품 이미지 화질에 대한 VoC들이 종종 있었습니다. 그러나 SIH 실제 production 배포 이후 몇 달 동안 관련 VoC가 없었다는 점에서 성공적으로 배포가 이뤄졌다는 확신이 들었습니다.

향후 계획

gif를 걷어내고 mp4로 전환할 계획을 가지고 있습니다. gif의 경우 대용량 파일이 많고, mp4로 gif를 완전히 대체가 할 수 있을 것이라고 판단하였기 때문입니다. (관련 자료 1, 관련 자료 2)

텀블벅 메인 페이지에 SIH를 적용하면, 성능과 비용 측면에서 더 극적인 효과가 나타날 것 같습니다. 따라서 이후에는 텀블벅 메인 페이지에도 SIH를 도입할 예정입니다.

피드백

위의 문제 해결 과정과 관련하여 피드백이 있다면 남겨주세요. 뿐만 아니라, 기술적으로 토론하고 싶은 것들이 있다면 harry@backpac.kr로 메일 주시면 재밌는 얘기들 나눌 수 있을 것 같습니다.

교훈과 배운 점

• 텀블벅 페이지가 가진 문제를 발견하고, 해결 방안을 찾고, 리포트를 작성하여 건의한 뒤에 실제 production 배포까지 이뤄낸 첫 프로젝트였기 때문에 성취감이 두 배였습니다.
• 텀블벅 이미지 최적화를 위한 첫 여정을 시작한 것 같아서 기쁘고, 이후의 작업들도 잘 마무리되었으면 좋겠습니다.
• 시간 대비 경험이 많을수록 성취감의 크기가 큰 것 같은데 이번은 텀블벅에서의 첫 번째 프로젝트인 광고 플랫폼 이후로 가장 성취감이 큰 프로젝트였습니다.
• 이번에 새로 합류하신 민석 님과의 협업이 수월했고 결과적으로 물 흐르듯이 작업을 진행할 수 있었습니다.
• FE로써 어려운 문제를 해결할 수 있으려면 인프라 지식이 필요하다는 생각이 들었습니다.
• AWS에서 제공하는 서비스를 사용해 볼 수 있어서 좋았습니다.
• FE에 국한되지 않고 소프트웨어에서 항상 가장 중요한 문제를 잘 해결하는 개발자가 되고 싶다는 목표가 생겼습니다.

Written by Tumblbug TS Engineering Cell

Content writer
Hyunwoo Na

백패커팀과 함께 할 인재를 영입 중입니다.
지금 여기에서 지원해 보세요!

이미지 최적화 여정(1): AWS Serverless Image Handler was originally published in Backpackr Team (idus, Tumblbug) on Medium, where people are continuing the conversation by highlighting and responding to this story.

오늘은 DevOps 셀에서 간헐적으로 순간 요청이 급증하면서 서비스 요청 처리 지연이 발생하고, 이로 인해 다른 서비스도 영향을 받는 문제를 인프라 레벨에서 해결하고자 했던 과정과 경험을 공유하고자 합니다.

들어가기 전에

아이디어스는 Kubernetes(EKS)에서 서비스를 운영하고 있습니다. Kubernetes 서비스를 운영할 때 우리는 수많은 Pod를 정의합니다. Pod는 하나 이상의 컨테이너로 이뤄져 있고 각 컨테이너 별로 리소스(CPU, Memory)를 정의합니다. 리소스 명세는 Requests와 Limits으로 나누어집니다. 어떻게 리소스를 정의했느냐에 따라 사용 가능한 자원은 물론, Pod scheduling 및 Eviction, QoS 등 실제 운영에 전반적인 영향을 주게 됩니다.

DevOps 셀은 image 서비스의 지표 모니터링 중에 특정 패턴을 발견하고, CPU Limit 설정에 대해 의문을 갖게 되었습니다. 관련하여 조사 및 테스트를 진행했으며 도출된 결과를 바탕으로 Production 환경에 일부 적용 했습니다. 이 과정들과 결과를 공유하고 서로의 경험과 의견을 나누고자 합니다.

왜 CPU Limit을 의심해?

Memory와 달리 CPU는 압축 가능한 리소스입니다.[1] 이는 Pod 간 CPU 사용을 위한 경합이 생기더라도 CPU Throttling이 생길지언정 시간을 나눠 분배 가능하다는 뜻입니다.

그럼에도 불구하고 저희는 Memory처럼 CPU 역시 Limit을 미리 정의하여 운영하고 있었습니다. CPU Limit을 지정하지 않으면,

• 시끄러운 이웃이 되어 다른 서비스에 영향을 주면 어떡하지?
• 심지어 kubelet 같이 Kubernetes를 운영하는 핵심 system에게도 시끄럽게 굴어서 노드가 Unready 상태로 변한다면?

와 같은 우려(두려움)가 있기 때문이었습니다. 아마 많은 팀이 비슷한 근거로 비슷한 운영을 하고 있을 것이라 생각됩니다.

어느 날 셀에서 특이한 지표를 확인했습니다. image 서비스에 순간적으로 요청이 몰렸습니다. 그리고 HPA가 반응하기도 전에 응답 속도가 급속히 증가하였습니다. image 서비스 Pod들은 꾸역꾸역 받아둔 요청들을 처리하다가 결국 요청 처리를 못하는 상태에 빠졌습니다. 그렇게 늦어진 요청 처리는 다른 일부 서비스 지표에도 영향을 주었습니다. 재밌는 점은 노드의 전체 CPU 사용률이나 다른 이웃(Pod)들의 CPU 사용률은 여유 있었다는 것이었습니다. image 서비스는 혼자 애쓰고 있었고 결국 얼럿을 통해 도움을 외치고 있었던 것입니다.

image 서비스의 언어상 이슈든 예외적인 순간 요청 대응이 안 되는 구조든, 근본 원인이 무엇이든 간에 인프라 레벨에서 이 현상을 빠르게 완화하고자 했습니다. 컨테이너 리소스를 늘리거나 HPA 임계값을 낮추는 등 가장 쉬운 방법을 먼저 적용해 두고 다음 방법을 고민했습니다(조금 완화되었나 싶었을 때도 동일 패턴은 나타나고 있었습니다.).

고민 중에 앞서 언급했던 재밌는 점이 다음 아이디어로 이어졌습니다. 다른 노드의 여유 CPU 자원이 있었음에도 image 서비스는 우리가 정해준 CPU Limit 때문에 여유분을 온전히 사용하지 못했음을 지표로 확인했습니다. 노드가 가지고 있던 CPU 자원 여유분을 사용할 수 있었다면 어땠을까요? 그러니까 CPU Limit을 설정하지 않는다면? 혹시 관련해서 다른 팀 혹은 엔지니어는 어떻게 생각하고, 운영하고 있을까요?

조사

먼저 조사부터 시작했습니다. 관심을 갖고 살펴보기 시작하니 CPU Limit(앞으로 언급하는 Limit은 CPU Limit입니다.)은 생각보다 의견이 뜨뜻하게? 대립 중이었습니다.

두 주장 모두 자세히 살펴보고 비교하면 좋겠지만, 우리의 관심사는 CPU Limit 안 함!이었기 때문에 해당 주장 위주로 살펴보았습니다. 그들은 다음과 같은 근거로 주장하고 있었습니다.

• CPU는 압축 가능한 자원이다.
• Kubernetes에서 system이 필요로 하는 CPU는 따로 보장받기 때문에 노드 상태에 영향을 주지 않는다.
• CPU Limit이 없는 두 pod 간 CPU 경합이 발생한다면 Request 비율(정확히는 CPU Share)대로 CPU를 분배받는다.
• 즉 Request 정의를 해당 컨테이너가 최소로 보장받아야 하는 만큼의 값으로 정의되어 있다면 성능을 바라보고 Limit을 해제해도 된다.

Limit 설정이 오히려 유연하고 효율적인 자원 사용에 도움이 되지 않는다고 해석되었습니다. 일리 있는 주장인 것 같습니다. 위 내용들이 사실이라면 특히 우리 image 서비스 상황을 타개할 좋은 방법일 것 같습니다. 검증하기 위해 먼저 테스트를 진행해 보았습니다.

테스트 진행

테스트 환경 및 방법

• c5.large 노드 한 대
  - 2 vCPU / 4Gi Memory
  - 시스템 예약 및 daemon들을 제외하고 CPU 여유분은 약 1370m
  - 테스트 Pod 3개를 배포하고 나면 370m 정도 여유[2]
• 테스트 Pod
  - image 서비스 Pod: 500m / 1024Mi
  - 더미 1(other-0) Pod 100m(200m) / 128Mi
  - 더미 2(other-1) Pod 100m(200m) / 128Mi

이렇게 구성하고 스트레스(image pod는 실제 요청으로, others는 코드로)를 주며 지표를 케이스별로 확인해 보았습니다.

관찰하려는 지표는 아래와 같습니다.

• Pod CPU 사용량
• 노드의 여유분 대비 CPU 사용률
• 노드의 전체 CPU 사용률
• image Pod 요청량 및 응답 코드

이제 크게 세 가지 케이스로 나눈 뒤,

1. 모든 Pod가 Limit 정의됨
2. image Pod만 Limit 없음
3. 모든 Pod가 Limit 없음

각각 세부적으로 또 두 가지 케이스로 나눕니다.

1. 일부 Pod idle, 나머지 Pod full-load
2. 모든 Pod full-load

즉 총 여섯 가지 케이스의 지표를 확인했습니다.

케이스 1: 모든 Pod가 Limit 설정되어 있음

케이스 1–1: image full-load | others idle

더미 Pod(이후 other-0, other-1으로 지칭)이 모두 idle 상태이고 노드의 CPU 여유분이 더 있어도 image Pod는 자신의 Limit만큼만 CPU를 사용합니다.

케이스 1–2: 모든 Pod full-load

역시 노드 CPU 여분이 있음에도 각자 Limit만큼만 CPU를 사용할 수 있음을 확인할 수 있습니다.

케이스 2: image Pod Limit 없음 | others Pod Limit 있음

케이스 2–1: Image full-load | others idle

image Pod가 요청 처리를 위해 노드의 여유분 CPU를 100%를 사용하는 것을 확인할 수 있습니다.
그럼에도 노드 전체 CPU 자원을 다 쓰는 것은 아닙니다.

케이스 2–2: 모든 Pod full-load

other-0, other-1, image 순서로 스트레스를 주었습니다.

other-0을 보면 자신이 사용해야 할 CPU는 뒤에 어떤 스트레스 Pod가 들어오든 꾸준한 사용률을 보임을 확인할 수 있습니다.

마지막으로 image에 스트레스를 주자 other-0, other-1이 사용하고 있는 여유분 CPU를 제외하고 나머지를 사용하는 것을 지표로 통해 확인할 수 있습니다.

특이사항이 있다면 일부 지표가 끊기는 현상을 확인할 수 있는데 이에 관해선 마지막 테스트 결과에서 다시 언급하겠습니다.

케이스3: 모든 Pod가 Limit 없음

케이스 3–1: image idle | others full-load

케이스 2–1에서 image Pod 혼자 스트레스일 때와 비슷한 양의 여유분 대비 및 전체 대비 CPU 사용률을 others가 나누어 사용하고 있음을 확인할 수 있습니다.

(지표 끊김 현상은 이번에도 발생하고 있습니다.)

케이스 3–2: 모든 Pod full-load

케이스 3–1에서 image Pod에도 스트레스 주자 CPU 사용률 비율이 바뀌었습니다.
마치 케이스 2–2와 비슷한 형태를 최종적으로 보여 줍니다.
세 Pod 중에 CPU를 할당받지 받지 못해 LivenessProbe를 실패하여 Restart 되는 Pod는 없었습니다.
노드가 Unready 되는 상황도 없었습니다.

(지표 끊김 현상은 이번에도 발생하고 있습니다.)

테스트 결과

테스트를 진행하면서 다음 내용들을 확인할 수 있었습니다.

CPU Limit이 없어도,

1. 노드 상태에 영향을 주지 않습니다; kubelet 등 system이 사용할 CPU에 영향을 주지 않습니다.
   1) 노드 상태 중에 CpuPressure는 없습니다. 처음에 언급했듯이 압축 가능한 자원이기 때문이라 생각됩니다.
   2) Node-pressure Eviction 문서를 살펴보면 CPU 사용량 기준으로 Pod를 Eviction 시키는 일도 없습니다.
2. Limit 없는 Pod가 Limit 있는 다른 Pod를 굶겨 죽이진 않습니다.
3. 2번과 조금 다른 상황인데 BestEffort QoS(좀 더 정확하게는 CPU Request가 없는) Pod는 영향을 받을 수 있습니다. 위에 지표 끊김 현상이 그것입니다. deamon 중에 node-exporter가 지속적으로 LivenessProbe를 실패하며 죽었기 때문입니다.
   1) 이는 CPU Request가 없을 때 CPU Share(Request * 1024) 기본 값이 2이기 때문입니다. CPU Request가 100m(0.1 * 1024)인 others Pod만 해도 CPU Share는 102이니까 꽤 차이가 납니다.
   2) 사실 꾸준히 Request에 비율대로 CPU를 분배한다고 언급했지만, 사실 원론적으론 CPU Share 비율대로 우선순위를 선정하여 분배합니다. 기본값인 2로는 CPU Share가 매우 낮기 때문에 아사할 수 있습니다.
   3) Helm chart repo에 포함된 DaemonSet은 BestEffort인 경우[3]가 있습니다. 만약 Limit 해제를 고려하신다면 꼭 한 번 살펴보시길 추천드립니다.
   4) 기술적인 상세한 내용은 하단 참고에 Kubernetes resources under the hood 시리즈에 상세히 설명되어 있습니다.
4. 모든 Pod가 Limit이 없고 스트레스 상태일 땐 CPU Share 비율대로 분배받습니다.

그리고 덤으로 image Pod의 (부분적이지만) 현상 재현과 개선 사항도 지표로 확인할 수 있었습니다.

Run#1: 케이스 1–2 | Run#2: 케이스 3–2

노드의 여유 자원을 모두 사용함으로써 향상되고 안정적인 응답속도를 보여줍니다.

요청 수 자체는 Run#2가 Run#1보다 약 2배 정도 많습니다.

Production 적용 및 결과

테스트 결과의 3번 사항만 조심하면 큰 사전 준비 없이 Production에 적용할만하다고 판단 했습니다. 사실 빠른 롤백이 언제든 가능하므로 그걸 믿고 진행한 부분도 있습니다.

그럼 적용 결과를 공유 하겠습니다. (비교 지표를 잘 정리해주신 동현님께 감사드립니다.)

먼저 응답 속도 P99는 적용 이후 24시간 기준 지표로 봤을때 감소 효과가 있었습니다.

CPU Throttling도 사라졌습니다.

궁극적으로 원했던 순간 트래픽 급증 때 응답 속도도 편안해졌습니다.

결론

고백하자면 CPU Limit 해제 쪽의 주장에 좀 더 집중하여 조사하고, 테스트를 진행 후 빠르게 Proudction에 적용했던 것 같습니다. 특히 Kubneretes resources under the hood 글을 통해 Kubernetes와 Linux에서 CPU라는 자원을 어떻게 관리하는지 좀 더 자세히 이해할 수 있었습니다. 기술적 부분 없이 테스트와 결과만 있는 이 글을 보고 나서 호기심이 생겼다면 꼭 한 번 정독해 보는 것을 추천합니다.

반대 측 주장을 좀 더 자세히 들여다봐야 보다 정확히 판단하겠지만, CPU Limit을 두고 양측의 주장하는 바는 서로 정반대지만 그 이유는 조금 성격이 다르다고 판단되었습니다. 우리 셀 내부에서는 이렇게 결론 내렸습니다.

워크로드 성격에 따라 순간적인 요청이 몰리는 패턴을 보인다던가, 응답 속도가 중요할 땐 CPU Limit 해제.
응답성보다는 안정적인 자원 활용(Batch 형태의 Pod들이 배포되어 있는 환경)이 중요하다. 혹은 순간 치고 오는 패턴 없이 항상 꾸준한 처리를 하는 워크로드라면 CPU Limit을 설정.

지금까지 공유드린 내용을 다른 엔지니어 혹은 팀들은 어떻게 생각하는지 궁금합니다. 함께 의견을 나눌 수 있으면 좋겠습니다.

요약

• 아래 조건을 충족한다면 CPU Limit을 설정하지 않은 Pod가 노드 및 이웃 Pod를 좀 먹지 않는다.
  - 모든 컨테이너는 필요로 하는(보장받아야 하는) CPU만큼 Request로 정의되어야 한다.
  - CPU Request가 없는 경우 CPU Share 기본값이 너무 낮아 CPU를 분배받는 우선순위가 매우 낮다.
• CPU Limit이 없는 Pod 끼리 CPU 경합이 생기면 CPU Share 비율 대로 분배받는다.
  - 비율이라 함은 결국 상대적이라는 뜻이다.
• 모든 상황을 관통하는 CPU Limit 설정 정답은 없다. 상황에 맞게 판단하자.
• 우린 불을 껐다.

이어서 더 생각해 보면 좋을 주제들

연관하여 아래 주제들도 좀 더 생각해보거나 이미 경험 있다면 나누면 좋을 것 같습니다.

• 반대 주장(CPU Limit 유지)과 이유
• 컨테이너의 적정 CPU Request 측정 — 특히 Java Application
• 컨테이너의 Memory 리소스 설정 및 cgroup v2, QoS for Memory

참고

주장: CPU Limit 해제!

Kubernetes resources under the hood — Part 1 (Part 3까지 쭉 이어집니다.)

Kubernetes의 CPU requests와 limits :: Outsider’s Dev Story (위 글을 잘 정리한 우리말 문서. 감사합니다!)

Kubernetes Throttling Doesn’t Have To Suck. Let Us Help! | Netdata Blog

For the Love of God, Stop Using CPU Limits on Kubernetes (Updated) | Robusta

주장: CPU Limit 필수!

CPU limits and requests in Kubernetes

Why You Should Keep Using CPU Limits on Kubernetes (For the Love of God, Stop Using CPU Limits On Kubernetes 글에 대한 반박)

각주

[1] Kubernetes 1.25에서 GA된 cgroup v2를 통해 1.27부터 Memory 관리에도 변화가 생깁니다.

[2] Pod CPU Requests와 배포 후 여유 CPU 자원 차이는 Sidecar(istio) 때문입니다.

[3] Burstable QoS DaemonSet 예시

# prometheus-node-exporter의 경우 이런 식으로 되어있습니다.
resources: {}
  # We usually recommend not to specify default resources and to leave this as a conscious
  # choice for the user. This also increases chances charts run on environments with little
  # resources, such as Minikube. If you do want to specify resources, uncomment the following
  # lines, adjust them as necessary, and remove the curly braces after 'resources:'.
  # limits:
  #   cpu: 200m
  #   memory: 50Mi
  # requests:
  #   cpu: 100m
  #   memory: 30Mi

Written by idus DevOps Cell

Content writer
Seonsoo Choi

백패커팀과 함께 할 인재를 영입 중입니다.
지금 여기에서 지원해 보세요!

Kubernetes Pod Resources: CPU Limit was originally published in Backpackr Team (idus, Tumblbug) on Medium, where people are continuing the conversation by highlighting and responding to this story.

감사하게도 좋은 기회로 이번 re:Invent 에 다녀오게 되었습니다.

리인벤트 준비

세션 예약

리인벤트는 엄청난 규모의 행사로, 2,800개가 넘는 세션들이 준비되어 있습니다. 미리 예약해 두는 것이 가능하므로, 개인적으로 저는 일찍부터 세션 목록을 살펴보고 각 세션의 특징들을 숙지한 후, 관심이 가는 세션에 하트를 눌러 미리 예약해두었습니다.

물론 walk-in으로도 참석할 수 있지만, 인기 있는 세션들은 빠르게 자리가 차버려서 놓치는 경우도 있습니다. 그래서 관심 있는 세션은 미리 예약하고 가시는 것을 추천드립니다.

또한, 가능하다면 세션 간 이동을 고려하여 시간과 거리를 체크해두는 것이 좋습니다. 이는 세션 간 이동 시간을 줄여서 세션에 집중할 수 있게 도와줍니다.

자격증

리인벤트 참가자들에게는 자격증 시험 반값 바우처가 제공되어 적은 부담으로 시험을 볼 수 있었습니다.

AWS 자격증 소지자들만 입장할 수 있는 이 공간은 앉을 자리부터 간식, 음료까지 세심한 배려가 돋보였습니다. 자리는 편안한 의자들이 배치되어 있었고, 작업을 위한 탁자와 콘센트가 충분히 마련되어 있어 노트북을 꺼내어 앉아서 이전 세션을 복습하거나 내용을 정리하기에 최적의 환경이었습니다.

행사 중간중간에 자유롭게 들락날락하며 새로운 지식을 습득하는 것도 중요하지만, 그러한 정보들을 정리하고 숙고하는 시간도 필요하다고 생각했습니다. 특히나 회사에서 AWS를 활용하고 있는데도 배경 지식이 부족한 경우, 이 자격증 라운지에서 공부하면서 실무와 이론을 연결시킬 수 있는 유용한 경험이 될 것입니다.

리인벤트 시작

re:Invent 의 시작은 뱃지를 받는 것으로 시작되었습니다. 이 기간에는 라스베가스 호텔의 투숙객 대부분이 리인벤트 참석자라 앞사람을 따라가면 됩니다 (노트북을 들고, 백팩을 메고 목에 뭐 걸고 다니면 백프로).

로비는 다양한 국적과 배경을 가진 행사 참가자들로 붐볐습니다.

길을 잃어도 행사장 곳곳에는 스태프들이 위치하고 있었고, 언제든지 도움을 청할 수 있었습니다.

세션

re:Invent 다양한 유형의 세션 중에서 주로 chalk talk와 workshop을 선택하여 참여하였습니다. 이들 세션들은 breakout과 innovation talk과는 다르게 스트리밍 되는 것이 아니라 실시간 참여가 필요한 형태였습니다.

세션은 난이도에 따라 level 1부터 level 4까지 제공되었습니다. AWS 서비스를 사용해 본 경험이 없는 초보자라도 level 1 세션에서 AWS 서비스에 대한 기본 개념과 이해를 쌓을 수 있었습니다. 또한, level 4 세션에서는 AWS 서비스의 세부 사항과 커스터마이징 방법에 대한 심층적인 내용을 다루어 더 깊은 이해를 얻을 수 있었습니다.

리인벤트 세션은 다양한 주제와 난이도로 구성되어 있어 참가자들이 자신의 수준과 관심사에 맞는 세션을 찾아 참여할 수 있었습니다. 이를 통해 AWS에 대한 이해를 높일 뿐만 아니라, 새로운 기술 동향을 익히고 경험을 쌓을 수 있었습니다.

Chalk talk

Chalk Talk 세션에서는 두 명의 발표자가 함께 나와서 장표를 보며 설명하면서 동시에 칠판에 그림을 그리고 참석자들과 소통하며 세션을 진행합니다. 참석자들은 자신들이 직면해봤던 문제들이나 발표자의 설명 중 더 깊이 알고 싶은 내용을 질문하며 함께 진행되었습니다. 질문이 세션의 30 ~ 50%을 차지하는 정도로 상당한 비중을 차지했습니다. 저 또한 질문의 퀄리티에 대해 생각해보는 시간이었습니다.

Workshop

Workshop은 노트북이 필수적인 형식으로, 제가 참여한 두 번의 세션은 각각 퀴즈 방식과 튜토리얼 방식으로 진행되었습니다.

첫 번째 세션은 퀴즈 방식의 Workshop이었습니다. 참가자들은 주어진 문제에 대한 해결책을 찾아내는 과정에서 협업과 토론이 이루어졌습니다. 특히, 문제에 막혔을 때 주위 참가자들에게 질문하고 논의하면서 해결해 나갔던 경험이 인상적이었습니다.

두 번째 세션은 튜토리얼 방식의 Workshop이었습니다. 이번에는 참가자들에게 주어진 지침을 따라가며 특정 기술이나 서비스를 직접 사용해보는 시간이 주어졌습니다.

두 번의 Workshop 세션에서 느낀 가장 큰 장점은 바로 실전에서의 경험이었습니다. 노트북을 통한 실습이 주는 현실적인 경험은 이론적인 학습을 보완하는 데 큰 도움이 되었습니다.

Keynote

세 개의 키노트 중 CEO 의 키노트만 참석했는데요, 워낙 많은 사람들이 들으려다보니 메인 홀은 금방 차고 다른 홀에서 실시간으로 스트리밍되는 영상으로 봤습니다.

이 키노트를 통해 리인벤트라는 단어에서 느껴지는 자긍심을 공유하며, 차세대 신기술을 공개하는 모습을 지켜보는 경험을 했습니다. 초반에는 S3와 EC2의 성능 향상에 대한 발표가 이어졌고, 그 후로는 주로 AI/ML와 관련된 발표가 중심이었습니다. AI/ML의 다양한 사용 사례와 개발 중인 주요 기술에 대한 이해를 높일 수 있었습니다. 또한, 기존 제품에도 AI/ML을 적용해 성능 향상과 자동화를 도입하는 경향이 두드러졌습니다. 발표 중에는 AI/ML의 보안과 권한에 대한 강조도 뚜렷했습니다.

이어서 다양한 기술 소식들 중 몇 가지를 간략히 소개하겠습니다.

1. Codewhisperer : 현재 존재하는 코드와 주석 기반으로 실시간 코드 추천을 제공하는 AI Code Generator입니다. IDE에 플러그인으로 설치하여 사용 가능하며, 코드 추천의 reference 로그를 확인할 수 있습니다. 그러나 현 시점에서는 아직 Copilot이 더 좋다는 의견이 있습니다.
2. Amazon Q: 자연어로 질문과 답을 받을 수 있는 기업형 챗봇으로, 현재 AWS 콘솔에 챗봇 형식으로 제공되고 있습니다. 코드위스퍼와 통합 가능하며, AWS 인프라 설계 시 Best practice를 제공하고 네트워크 이슈에 대한 도움을 줍니다. 권한 제한을 통해 유저의 액세스 권한에 따라 응답이 달라진다는 특징이 있습니다.
3. Aurora PostgreSQL, Amazon DynamoDB, RDS for zero ETL integration with RedShift: 데이터 파이프라인 없이 RDS, NoSQL 데이터를 RedShift로 옮길 수 있는 발표로, 데이터를 extract, transform, and load 하는 과정이 필요 없이 효율적으로 데이터 이동이 가능하다는 것을 강조했습니다.

기억에 남는 세션

기억에 남는 세션 중 몇 가지를 소개하겠습니다.

1. Break Network, Fix Network Workshop

이 세션은 여러 VPC로 구성된 환경에서 발생한 특정 문제를 해결하는 workshop이었습니다. 여러 VPC를 연결하고 권한을 부여하여 인스턴스 간의 연결을 확인하는 등 다양한 작업을 수행하면서 업무에서는 경험하기 어려운 환경에서의 문제 해결 과정을 체험했습니다.

2. Amazon Q 세션

이 세션은 키노트를 듣고 Amazon Q를 실무에 활용해볼 수 있을 것이라는 생각에서 참여한 것으로 기억됩니다.

이 세션에서는 Amazon Q의 활용법과 구체적인 예시를 통해 참가자들에게 서비스의 특징을 자세히 소개했습니다. 사용자들은 자연어로 질문을 하고 해당 서비스가 어떻게 응답하는지를 실제로 체험하며 서비스의 강점을 파악할 수 있었습니다. 또한, Amazon Q가 어떻게 다른 AWS 서비스와 통합되어 현업에서 어떻게 활용될 수 있는지에 대한 실제 사례도 공유되었습니다.

3. Differentiated Performance for Databases with Amazon EC2 & Amazon EBS

이 세션에서는 EC2와 EBS의 다양한 조합에 따라 데이터베이스의 성능이 어떻게 달라질 수 있는지에 대한 내용이 다뤄졌습니다. RDS와 NoSQL을 중점으로 다양한 사용 사례를 다루면서, 참가자들은 원하는 요구사항에 따라 어떻게 인스턴스와 볼륨을 선택하고 최적의 성능을 얻을 수 있는지에 대한 가이드를 얻었습니다.

Expo

엑스포는 큰 규모로 진행되었고 세계적인 기업들이 부스에 있었습니다. 특히, DataDog와 MongoDB는 엑스포의 중심에 위치하여 AWS와의 깊은 관련성을 나타내고 있었습니다. 여러 부스 중에서는 보안, 개발, 데이터, 모니터링 등 다양한 IT 분야에 관련된 기업들이 참가하여 최신 기술과 솔루션을 선보였습니다. 이러한 부스에서 기업들의 전문가들과 직접 대화하고 제품 데모를 체험함으로써 실질적인 지식을 얻을 수 있었습니다.

re:Play

마지막 날에는 re:Play에 참석했습니다. 총 3개의 큰 무대가 있고 하나는 게임, 미끄럼틀 등 여러 행사가 진행되고 하나는 밴드의 live 무대, 다른 하나는 DJ의 무대가 진행되었습니다. 모든 양 사이드에는 음료를 받을 수 있는 바가 있고 원하는대로 맥주, 칵테일, 음료를 만들어주었습니다.

마무리

좋았던 점

AWS 브랜드의 강력한 파워로 모인 전 세계의 IT 관련자들이 모여 전 세계의 스케일을 느껴볼 수 있어서 뜻 깊었습니다. 그리고 바로 앞에서 Netflix, Redis와 같은 유명 기술의 개발자들이 발표를 들었던 것에 동기 부여를 많이 받았습니다. 또한 AWS 에 대해 계속해서 알아가면서 인프라에 대한 흥미를 갖고 돌아온 듯 합니다.

아쉬운 점

주로 모든 세션이 영어로 진행되고 네트워킹을 하는 것에도 언어의 장벽이 느껴져, 영어에 대한 한계를 느꼈습니다.

또한, 현재 회사에서는 AWS를 사용하고 있지만, 인프라 개발에 직접 참여하지 않아 서비스에 대한 전반적인 이해가 부족하다고 느꼈습니다. 다양한 서비스를 사용하고 공부했다면 더 풍부한 경험을 쌓을 수 있었을 것이라 생각했습니다. 회사에서 사용하지 않았더라도 다양한 기술에 도전해보면서 더 넓은 시야를 갖게 되었으면 하는 아쉬움이 남았습니다.

종합적으로, 이 경험은 기술의 다양성과 규모를 체감하게 해주어 그동안의 좁은 시야에서 벗어나게 해준 좋은 계기였습니다.

동행한 동현님과 정호님께는 많은 도움을 받아서 고마움을 전하고 싶습니다.

Written by Tumblbug TS Engineering Cell

Content writer

Hwieun Kim

백패커팀과 함께 할 인재를 영입 중입니다.
지금 여기에서 지원해 보세요!

AWS re:Invent 2023 후기 (3) was originally published in Backpackr Team (idus, Tumblbug) on Medium, where people are continuing the conversation by highlighting and responding to this story.

라스베이거스에서 열린 AWS의 re:Invent 2023에 참여한 후기를 공유합니다.
여행 경험과 기술 행사 내용을 담았습니다.

교통

라스베이거스는 re:Invent 행사장이 모여있는 중심지와 공항까지 거리가 가까운 편입니다. 장거리 비행 후 호텔까지 빠르게 갈 수 있어서 첫날 여유롭게 휴식을 취할 수 있었습니다.

길거리에서 택시를 많이 볼 수 있는데, 라스베이거스에서는 일반적으로 거리에서 택시를 멈출 수 없고 호텔 내부나 호텔이 지정한 택시 승차장에서 택시를 이용할 수 있다고 합니다. 저는 우버나 리프트 같은 공유 차량 서비스를 자주 이용했는데, 호텔마다 공유 차량 서비스를 탈 수 있는 위치(“Rideshare”)가 정해져 있습니다. 호텔 로비에서 멀리 떨어진 경우가 있어서 위치를 미리 파악해 두어야 합니다.

re:Invent는 여러 호텔의 컨퍼런스 홀을 사용하고 있습니다. 가까운 거리의 호텔은 주로 걸어서 이동했으며, 일부에는 전용 통로가 있는 경우도 있었습니다. 먼 거리를 이동하는 경우에는 주로 셔틀버스나 모노레일을 이용했습니다.

배지 수령

세션이 진행되는 컨퍼런스 홀에 입장하기 위해서는 참가자임을 확인할 수 있는 배지를 수령해야 합니다. 먼 거리 이동을 위한 셔틀버스나 모노레일 탑승에도 배지가 필요합니다.

행사 시작 전날부터 첫날까지는 라스베이거스 공항에서 배지 수령을 할 수 있습니다. 행사장에서도 배지 수령이 가능해서 행사 첫날 아침에 받으러 갔습니다. 배지 앞면에는 사진, 이름, 회사 이름이 나와있으며 뒷면에는 행사장 곳곳에서 사용할 수 있는 Wi-Fi 정보, 간단한 안내사항이 적혀있습니다.

배지 수령 후에 SWAG(광고물)를 받았는데, 올해에는 회색 후드와 물병을 받았습니다. 물병에는 QR 코드가 있어서 스캔해보니 캄보디아에 물을 후원하는 프로젝트가 진행되고 있었습니다. 컨퍼런스 홀 곳곳에 물을 마실 수 있는 곳이 있었는데 캄보디아에 물이 전달이 되길 바라며 이 물병으로 물을 마셨습니다.

세션

AWS Events 앱을 통해서 세션을 미리 확인해 볼 수 있고 예약도 가능합니다. 인기가 많은 세션은 줄이 길어서 현장 대기로는 듣지 못하는 경우도 많으니 꼭 듣고 싶은 세션은 앱을 자주 확인하고 미리 예약하는 것이 좋습니다.

Keynote, Breakout Session은 유튜브를 통해서 나중에도 시청할 수 있습니다. 하지만 현장에서 직접 개발자에게 질문할 수 있는 점 때문에 관심 있는 세션은 현장에서 듣는 것을 추천합니다.

Workshops, Builders’ Sessions은 직접 노트북을 가져가서 체험하는 세션으로, 전 세계의 개발자들과 함께하는 특별한 경험입니다. 난이도가 기록된 세션 소개 페이지를 참고하여 선택하는 것이 도움이 됩니다. 중간에 막히는 경우에는 AWS 전문가들에게 도움을 받을 수 있습니다.

기술 혁신 소개

AWS의 CEO인 Adam Selipsky의 Keynote에서 신규 기능이 많이 발표되었습니다. 그중에 출시가 기대되는 것들을 알아보았습니다.

• Amazon S3 Express One Zone
  S3 Standard보다 10배 빠른 데이터 접근 속도에 50% 낮은 비용을 자랑합니다. 다른 파일시스템을 거치지 않고 바로 접근할 수 있다는 점에서 모델 트레이닝이나 EMR에서 사용했을 때 효과를 낼 수 있을 것 같아서 출시가 기대됩니다.
• AWS Graviton 4
  Graviton 3 대비 성능이 많이 올랐다고 합니다. 특히 Java 어플리케이션에서 45% 성능 향상이 되었다고 해서 기대가 됩니다. 하지만 작년에 발표된 Graviton 3가 최근에 서울 리전에 출시한 것을 보면 버전 4는 내년을 기약해야 할 것 같습니다.
  최근에 운영중인 서비스를 Graviton 2 인스턴스로 이전하여 비용을 크게 절감한 적이 있습니다. 이후 버전은 비용보다는 성능 향상이 기대되며, 동일한 성능이라면 더 적은 인스턴스를 사용하여 비용 절감의 효과를 가져올 수 있을 것 같습니다.

이번에 세션을 들으면서 인공지능, 기계학습과 관련된 세션이 정말 많다고 느꼈습니다. 그중 흥미로웠던 것을 소개하려고 합니다.

• Amazon Bedrock
  다양한 고성능 파운데이션 모델을 단일 API로 제공하는 완전 관리형 서비스로 다수의 세션에서 소개가 되었습니다. 코드 작성 없이 다양한 FM을 손쉽게 실험하고 미세조정, 검색 증강 생성과 같은 기술도 사용할 수 있다고 합니다.
• Amazon EC2 Capacity Blocks
  GPU 용량 확보가 어려워지면서 비용 효율적으로 GPU를 확보할 수 있는 기능이 새로 제공됩니다. Amazon EKS에서도 활용할 수 있어서 기대되는 기능 중 하나입니다.
• Amazon SageMaker HyperPod
  탄력적으로 환경을 구성할 수 있으며, 분산 트레이닝이 간소화되었고 최적화된 자원 활용을 할 수 있는 새로운 서비스입니다. 긴 시간에 걸쳐서 트레이닝이 진행되는데 막바지에 에러가 발생한다면 처음부터 다시 실행해야 해서 시간과 비용이 낭비되었었습니다. 분산 트레이닝과 회복 시스템으로 이를 해결할 수 있을 것 같아서 기대되었습니다.

식사

세션을 열심히 듣다 보면 배가 고플 때가 있습니다. re:Invent 참가자들을 위해 컨퍼런스 홀에서 아침, 점심, 그리고 오후 간식이 제공됩니다.

아침식사는 오전 7시부터 9시까지 (화요일에만 6시 30분부터 8시 30분까지) 부페 형태로 제공됩니다. 다양한 과일, 요거트, 머핀, 빵, 주스 등이 매일 달라 매번 새로운 메뉴를 즐길 수 있었습니다. 주 메뉴로는 계란 스크램블, 베이컨, 머핀 샌드위치 등이 다양하게 나왔습니다.

점심 식사는 오전 11시부터 오후 1시 30분까지 제공되었습니다. 부페 형태로는 물론, 간편한 샐러드나 샌드위치 도시락도 함께 제공되었습니다. 이에 사과와 쿠키도 포함되어 있었습니다.

오후 4시쯤에는 커피와 차와 함께 간식이 제공되었습니다. 세션 중에도 간식을 즐기며 배를 달래는 것이 가능했습니다.

EXPO

re:Invent에서 큰 즐길 거리 중 하나는 EXPO입니다. 여기에는 참가한 업체들이 제품을 홍보하고 개발자들과 소통할 수 있는 기회를 제공합니다. 저는 이곳에서 평소 궁금했던 사항들을 물어보고 많은 것을 배웠습니다.

Amazon도 자사의 제품들을 소개하는 부스를 운영했는데, SageMaker를 사용하면서 겪었던 문제에 대해 상담을 받고 해결책을 얻을 수 있었습니다. 또한, Bitbucket을 사용 중인데 Atlassian 부스에서 Bitbucket Pipeline의 Arm 지원 로드맵에 대해 물었더니 내년 중 지원한다는 답변을 얻었습니다. Elastic에서는 최근 발표한 ‘ES|QL’에 대한 관련 대화를 나눌 수 있었습니다.

EXPO를 돌아다니다 보면 티셔츠, 양말, 모자 등의 SWAG를 나눠주는 업체들을 많이 만날 수 있었습니다. 이런 아이템들을 받기 위해 배지를 스캔하는데, 이때는 업체에 이름과 이메일 등의 정보를 제공하게 됩니다.

느낀 점

re:Invent 참석으로 얻은 가장 큰 수확은 전 세계의 개발자들과의 네트워킹이었습니다. 이들과의 대화를 통해 회사에 유용한 인사이트를 얻었고, 세션을 통해 앞으로의 계획을 구체화할 수 있었습니다. 이런 소중한 경험을 통해 기술과 혁신의 향연이 얼마나 다양하고 역동적인지를 다시 한번 느낄 수 있었습니다.

Written by idus Search&Recommend Cell

Content writer

Jeongho Kim

백패커팀과 함께 할 인재를 영입 중입니다.
지금 여기에서 지원해 보세요!

AWS re:Invent 2023 후기 (2) was originally published in Backpackr Team (idus, Tumblbug) on Medium, where people are continuing the conversation by highlighting and responding to this story.

AWS re:Invent 이벤트는 글로벌 클라우드 컴퓨팅을 위한 학습 콘퍼런스로 AWS에서 주최하고 있습니다. 오프라인으로 진행하는 re:Invent 이벤트에서는 키노트와 2,000개 이상의 세션, 교육과 인증 기회, 엑스포 및 다양한 이벤트가 있습니다.

평소 온라인으로 re:Invent 세션을 듣긴 했지만 라스베이거스 현지에 직접 가는 것은 처음이어서 기대와 긴장감이 존재했습니다.

준비 과정

re:Invent 참석을 위한 등록 과정을 마친 후 애플 앱스토어와 구글 플레이에서 AWS Events 앱을 설치했습니다. 세션 카탈로그를 보니 약 3,000개의 세션이 있는데 제가 관심을 가지고 있는 항목을 선택하여 날짜별로 세션을 검색할 수 있었습니다. 세션을 검색하기 위한 옵션이 다양해서 조건에 맞게 빠르게 검색할 수 있습니다.

re:Invent는 Caesars Forum, Encore, Mandalay Bay, MGM Grand, The Venetian, Wynn 이렇게 6개의 장소에서 진행되는데 각 장소마다 무료 셔틀버스를 이용해 이동할 수 있습니다. 가까운 장소는 도보로 이동하는 편이 나았습니다. 하나의 장소도 매우 넓기 때문에 다음 세션을 위해서 빠르게 이동해야 좋은 자리를 얻을 수 있습니다.

이벤트 장소가 매우 넓고 세션 수가 많기 때문에 원하는 세션을 모두 듣는 것은 어려웠습니다. 그래서 일별로 원하는 세션이 많은 장소를 중심으로 동선을 최소화해서 세션을 들었습니다. 세션 장소가 몰려 있는 The Venetian에 비해 Mandalay Bay는 상대적으로 가장 멀리 있어서 두 장소는 같은 날 가는 일이 없도록 일정을 짰습니다.

참석자가 많은 세션은 발표자가 직접 나오는 현장 외에 영상으로 동시에 중계하는 경우가 많습니다. 세션 카탈로그의 세션명에 SIMULCAST라고 붙어 있는 것들인데 The Venetian에 Content Hub라는 장소에서 이런 세션을 보기 편했습니다.

https://aws.amazon.com/ko/blogs/korea/aws-reinvent-2023-for-korean-customers/ 문서를 보시면 보다 re:Invent를 잘 이용할 수 있습니다.

세션 중 인상적인 내용

AWS re:Invent 2023 기간 동안 AWS 제품과 직접 연관이 있는 세션은 약 2,800개 정도인데 AI/ML에 대한 세션이 760개로 가장 많았습니다. AI/ML에 대한 관심이 높은 것을 확실히 체감할 수 있었습니다. 아담 셀립스키(Adam Selipsky) AWS CEO의 키노트에서도 AI/ML을 많은 시간을 할애했습니다. S3와 같은 AWS의 대표적인 제품들의 신규 기능도 AI/ML을 사용하는데 연관되는 것이 많았으며, EXPO에 참여했던 다른 회사들도 AI/ML을 중심으로 비즈니스를 전개하는 듯한 인상을 받았습니다.

개인적으로 퍼블릭 클라우드의 비용 최적화에 대한 관심이 높았는데, 그런 점에서 베르너 보겔스(Werner Vogels) 아마존 CTO의 키노트는 상당히 인상적이었습니다. 키노트에서 그는 클라우드 비용 관리에 있어 검소한 설계자가 되어야 할 때라고 전했습니다. 클라우드 전에는 사용할 수 있는 하드웨어의 한계가 있어 이를 효율적으로 사용하기 위한 설계가 많았습니다. 클라우드의 도입으로 하드웨어의 한계는 사라지고 비용을 염두에 둔 설계는 사라지고 있다고 말했습니다. 그리고 AI/ML을 많은 곳에서 사용하면서 폭발적으로 비용이 증가하고 있습니다. 비용은 비즈니스와 밀접하며, 지속 가능성과도 밀접합니다. 제가 있는 백패커에서도 비용 최적화를 위한 다양한 활동을 하고 있는데 조금 더 관심을 기울여야겠다는 생각을 했습니다.

AWS에서 새로 발표한 제품과 기능들도 많은 관심을 가지게 만들었습니다. Amazon S3 Express One Zone, Amazon Q, Amazon Q Code Transformation, Graviton 4, 대용량 요청을 처리 시 AWS Lambda 함수 12배 빠른 확장, Amazon Managed Service for Prometheus collector, 자연어를 사용하여 Amazon CloudWatch 로그 및 지표 쿼리, Amazon S3와 Amazon OpenSearch Service zero-ETL 통합, Amazon EKS 파드 ID, Amazon ElastiCache 서버리스, Amazon Inspector 신규 기능, Amazon Bedrock과 관련 기능 등을 세션을 통해 발표되었습니다.

이 외에도 많은 세션이 있었지만 약 2,800 개의 세션을 5일 동안 보는 것은 현실적으로 어려운 일이고 미처 예약하지 못한 세션은 듣는 사람이 많아 세션장 입장부터 어려웠습니다. 자세한 내용에 대해 관심이 있는 분들은 re:Invent 2023에 대한 요약글이나 다른 후기를 통해 보실 수 있습니다.

기타 활동

re:Invent 기간 동안 세션 외에 다양한 활동에 참여할 수 있습니다. 저는 주로 Expo와 Datadog과 프라이빗 미팅, re:Play에 참여했습니다.

Expo는 AWS를 포함한 다양한 회사의 부스가 모여 있는 장소로 각 회사에 대한 궁금한 점을 묻고 들을 수 있기도 하고, 티셔츠 같은 Swag을 받을 수도 있습니다. 같이 re:Invent를 참여했던 동료가 AWS SA에게 질문하는 모습을 사진으로 찍어 보았습니다.

아이디어스/텀블벅의 서비스 관찰 가능성을 높이기 위해 Datadog을 이용하고 있는데, re:Invent 기간 내 Datadog에서 프라이빗 미팅을 제안해 주셨습니다. 평소 궁금했던 부분을 직접 만나 설명을 들을 수 있었고 Datadog의 신기능을 알려주셔서 좋았습니다.

re:Play는 11월 30일(목) 밤에 진행되었는데 re:Invent를 기념하기 위한 파티입니다. re:Invent 참석자는 무료로 참석할 수 있고 무제한의 음료와 음식, 놀이 공간이 제공됩니다. 유명한 가수의 라이브 공연도 볼 수 있습니다.

아마존 풀필먼트 센터 투어

12월 1일(금)에 아마존 풀필먼트 센터를 투어 할 수 있는 기회를 얻었습니다. 이 자리를 빌려 투어 할 수 있게 신경 써 주신 백패커 담당 AWS 어카운트 매니저님, AWS 코리아 스타트업 팀에게 감사드립니다.

The Venetian에서 약 40분 정도 이동하여 아마존 풀필먼트 센터에 방문했습니다. 먼저 물류 혁신을 위한 AWS의 발표가 있었는데 여기서도 AI/ML에 대한 내용이 많았습니다.

두 번째 발표는 아마존에서 상품을 고객에게 배송하는 과정을 순서대로 설명해 주었습니다. 단계가 매우 체계적이고 오랜 기간 축적된 노하우를 조금이지만 알게 되었습니다.

간단하게 식사한 후, 풀필먼트 센터 현장을 직접 방문하여 각 과정을 직접 보면서 설명을 들었습니다. 설명 후에 직접 체험해 볼 수 있는 기회도 있었는데, 저는 구경만 했습니다.

마지막으로

AWS re:Invent 2023을 직접 참석할 수 있는 좋은 기회를 주신 백패커팀과 장시간 저의 업무를 대신 맡았던 동료들께 감사드립니다. re:Invent 참석 준비 및 이벤트 기간 동안 편하게 생활할 수 있도록 아낌없이 지원해 주신 솔트웨어에도 감사하다는 말씀드립니다.

Written by idus DevOps Cell

Content writer
Donghyun Ha

백패커팀과 함께 할 인재를 영입 중입니다.
지금 여기에서 지원해 보세요!

AWS re:Invent 2023 후기 was originally published in Backpackr Team (idus, Tumblbug) on Medium, where people are continuing the conversation by highlighting and responding to this story.

아이디어스팀은 2022년 11월 28일(월) ~12월 2일(금)에 라스베이거스에서 진행한 행사인 AWS re:Invent에 참여했습니다.

행사에 참여한 경험을 공유드리고 추후에 있을 AWS re:Invent 예비 참석자 여러분께 유용한 팁을 전달해 드리고자 합니다.

AWS re:Invent란?

AWS re:Invent는 AWS의 클라우드 컴퓨팅 및 기술 분야에서 가장 큰 규모의 행사 중 하나로, 세계 각국의 기술 전문가와 엔지니어들이 모여 다양한 세션과 워크샵, 전시회 등에서 최신 기술 동향 및 경험을 공유하는 자리입니다.

참가자 등록

행사에 참여하면 가장 먼저 시작해야 할 것은 참여자 등록입니다.
여권과 같은 신분증을 반드시 챙겨 본인 확인을 진행해야 합니다.

Keynote

AWS re:Invent Keynote는 AWS 고객과 비즈니스 전문가, 클라우드 커뮤니티 전체에게 AWS의 기술 및 비즈니스 전략에 대한 중요한 정보를 제공합니다.

AWS re:Invent를 참석한다면 강력하게 추천해 드릴 수 있는 이벤트입니다.

그만큼 많은 인파가 모이기 때문에 키노트 시간보다 15분 일찍 참여하는 것을 권장합니다. 만약 듣지 못하더라도 영상을 통해 실시간 공유와 번역도 지원되고, Youtube에 영상이 업로드됩니다.

AWS re:Invent 2022 Keynote의 주요 키워드는 다음과 같습니다.

1.Graviton3 인스턴스 타입 출시

2.HPC7 & Trn1 & C7gn 고성능 컴퓨팅 리소스 출시

3.Amazon GuardDuty RDS Protection 서비스 출시

4.Amazon Supply Chain 서비스 출시

Expo

Expo는 AWS가 제공하는 다양한 제품과 서비스를 소개하고, AWS의 파트너사 및 고객사의 제품과 서비스를 체험하고, AWS의 전문가와 대화할 수 있는 기회를 제공합니다.

이 공간에서는 다양한 제품 및 서비스 데모, 워크샵, 기술 세션, 네트워킹 및 파트너사 스폰서 부스, Swag 등이 제공됩니다.

Session

Session은 다양한 주제로 구성되어 있습니다.
기술 세션, 전문가 패널 토론, 교육 세션, 실습 랩, 데모 및 해커톤 등이 포함됩니다. 세션 또한 온라인으로 제공되며 실시간 라이브 스트림과 Youtube를 통해 언제든지 참여할 수 있습니다.

2022 AWS re:Invent Session에서 개인적으로 추천하고 싶은 세션은 Are you integrating or building distributed applications? (API308) 입니다.

발표 스타일과 내용이 엔지니어라면 누구나 매력을 느낄 수 있는 Session으로 느껴졌습니다.

AWS re:Invent 예비 참석자 여러분들을 위한 팁

1.립밤을 챙겨주세요!

네바다주 라스베이거스는 사막 지역으로 매우 건조합니다. 하루 이틀을 지내다 보면 어느새 입술이 하얗게 일어나있습니다. 미리 립밤을 챙겨 입술 보습을 챙깁시다.

2.Session은 AWS re:Invent 등록 후 바로 확인해주세요!
인기 세션은 금방 마감됩니다. 듣고 싶은 세션 놓치지 않도록 빠르게 진행해주세요.

3.AWS Events 앱을 받아주세요!

- IOS 앱 다운받기

- Android 앱 다운받기

갑자기 듣고 싶은 세션이 생겼다면 앱을 활용해 바로 Session 등록을 진행할 수 있습니다.

4.각 Session 사이에 여유 시간을 잡아두세요!

AWS re:Invent 행사에서 강연에 참여하실 때는 충분한 여유시간을 가지고 일정을 세우는 것이 좋습니다.

행사가 열리는 주요 호텔 내부 강연장은 카지노를 거쳐 입구에서 꽤 먼 곳에 위치할 수 있기 때문입니다. 호텔 간 이동을 해야 하는 경우에도 셔틀버스를 이용하더라도 최소 1시간은 준비해야 합니다.
(같은 호텔 내의 강연장이더라도 강연 세션 이동에 최소 30분을 고려해야 합니다.)

강연 세션 장소에 적어도 30분 전에 도착해야 예약한 자리를 찾아 들어갈 수 있으며, 예약하지 않은 분들도 대기를 통해 참여할 수 있습니다.

예약이 불가능한 경우 대기열에 대기할 수 있으니 이 역시 고려해야 합니다.

글을 마치며

솔트웨어에서 AWS re:Invent 행사 이외에도 네트워킹 자리와 여행자 키트를 준비해 주어 매우 감사합니다. 또, 아이디어스 팀을 대표하여 세계 최대의 클라우드 행사인 AWS re:Invent 행사에 참여하게 되어 매우 기쁩니다.

미래의 AWS re:Invent 참석자 여러분께 작은 도움이 되길 바라며 글을 마칩니다.

감사합니다.

Written by idus DevOps/Core system Cell

Content writer
Gyeongjun Paik, Jongchan Park

아이디어스팀과 함께 할 테크인재를 영입 중입니다.
지금 여기에서 지원해 보세요!

[아이디어스] 2022 AWS re:Invent 탐방기 was originally published in Backpackr Team (idus, Tumblbug) on Medium, where people are continuing the conversation by highlighting and responding to this story.

아이디어스팀에 합류하면 on-boarding 기간에 입사자 가이드를 공유 받습니다.

업무에 필요한 여러 계정 신청 방법, VPN 설정 방법 그리고 개발 환경 셋팅 방법 등이 정리된 위키 문서인데요. Jira, Bitbucket, Postman, Datadog 등 웬만한 툴들은 경험해 보았는데 유독 이름은 익숙하지만 낯선 툴이 하나 있었습니다.

그 이름은 바로 Charles!

(툴을 처음 접했을 당시) 왕세자 이름의 툴이라니?!
신선한 마음에 곧바로 계정을 발급받아 찰스를 켰지만 금방 다시 껐어요. 어떤 용도인지 알지 못했고, 이 툴을 알아가야겠다는 마음보다 메인 업무에 빨리 적응해야겠다는 마음이 컸기 때문이었죠.

그렇게 시간이 흘러 여러 스프린트를 진행하던 중, QA 기간마다 반복되는 API 작업 요청에 어떻게 대응하면 좋을지 고민되었습니다. 프로젝트 리더* 님께 상황을 설명드리니 proxy 아이디어를 주셨고, 셀리더* 님께 개발 조직에서 proxy를 어떻게 사용하는지 여쭤봤을 때 찰스를 말씀해 주셨어요!

미뤄왔던 숙제를 할 시간이 된 것 같은 기분이랄까요?

여기서 잠깐, 아이디어스팀의 개발 문화 엿보기 🔍

• 프로젝트 리더(PL) : 프로젝트 별로 각 파트의 개발자들이 모여요. 이 중에서 프로젝트의 개발 방향을 리드하는 PL이 정해집니다.
• 셀 리더 : 제가 속한 API셀의 테크 리더에요.

찰스를 본격적으로 알아가게 된 계기를 설명하는데 서두가 길었네요 ;)
저처럼 찰스 하면 과거 영국의 왕세자이자 현재 영국의 국왕인 분만 떠올렸던 분들을 위해 설명드리면,

Charles(찰스) 란?

웹 디버깅 프록시 툴로 디버깅을 위해 원하는 모든 네트워크의 흐름을 모니터링할 수 있고 프록시서버의 역할로 특정 네트워크의 요청과 응답을 핸들링 할 수 있습니다. 공식 홈페이지에서 다운로드할 수 있고, 30일 무료 사용기간 후에는 라이센스를 구입해야 해요.

구글링하면 많이 나오는 찰스의 설정 방법 설명은 생략하고 이 글에서는 실무에서 활용하기 좋은 몇 가지 꿀팁들을 알려드릴게요!

여기까지 긴 글 읽으신 분들에게 끝까지 힘내서 읽으실 수 있도록 박수 한 번 드립니다~

이번 스토리에서는 찰스와 핸드폰 연동이 되어있음을 가정하고 설명합니다.

꿀팁0. 프록시 설정하기

본격 꿀팁에 앞서 이 설정이 선행되어야 합니다!
프록시 설정만 잘해도 혼자서 뚝딱 많은 정보를 얻을 수 있어요.

먼저, 프록시를 설정할 호스트 정보를 등록합니다.

Proxy > SSL Proxying Settings 메뉴에서 설정하실 수 있어요.
(*버전별로 메뉴 순서의 차이가 있습니다.)

SSL Proxying 탭에서 Enable SSL Proxying 을 체크하시고 Add를 눌러 호스트명과 포트번호를 입력합니다.

이해를 돕기 위해 임의의 호스트명( *.abc.com)으로 입력하였어요! 서브도메인을 * 처리하여 abc.com 도메인으로 들어오는 모든 네트워크 통신을 허용해 주었습니다.

다음으로, 찰스 화면에서 모니터링할 호스트 정보를 등록합니다.

이번에는 Proxy > Recording Settings 메뉴에서 설정해요.

Include 탭에서 Add 를 클릭후 SSL Proxying settings 에서 등록했던 호스트정보와 같이 입력해주세요!

두 가지 설정을 마쳤으면 마지막으로 SSL Proxying 과 Recording 을 Start 합니다.

SSL Proxying 과 Recording 이 Stop 상태일 때 메뉴에는 Start ~ 로 표시되고, 아이콘은 흑백(비활성화)으로 현재 아무 동작도 안 하고 있음을 나타내요. 메뉴나 아이콘 클릭 또는 단축키 입력으로 두 가지 기능을 활성화시켜 줍니다.

이렇게 설정하면 현재 어떤 네트워크 통신이 일어나는지 모니터링할 수 있어요. 찰스에 앱을 연동하고 앱을 실행하면 어떤 API를 어느 값으로 호출하는지 알 수 있습니다. 응답 결과를 확인할 때 유용한데 특히 오류 상황을 쉽게 파악할 수 있어요. 마치 병원에서 초음파검사를 통해 어디가 문제인지 확인하는 것처럼 말이죠!

혹시 다음 이미지처럼 Path는 비어있고, 데이터가 알아볼 수 없는 문자로 보이시나요?

SSL Proxying 기능이 비활성화 상태에서 발생하는 상황으로 Recording 기능과 함께 활성화시켜주는 것 기억해 주세요 :)

꿀팁1. Status Code 변경하기

찰스의 Rewrite 기능을 이용하면 원하는 대로 Request 나 Response 데이터를 핸들링할 수 있습니다! Request Header를 수정할 수도 있고, Response Body의 일부 데이터를 변경할 수도 있죠. Rewrite의 기본 활용이라 생각하는 Http 상태 코드 변경하는 방법부터 알려드릴게요.

Tools > Rewrite 메뉴에 진입합니다.

Enable Rewrite를 체크하고 왼쪽 영역의 Add를 클릭해 주세요. 오른쪽 위 영역의 Add를 클릭해 Status Code를 변경하고 싶은 API를 입력해줍니다. 저는 임의의 Host 와 Path를 입력하였어요. 만약에 /products/1/detail , /products/2/detail 처럼 일정한 형식을 가진 EP를 테스트하고 싶다면 와일드카드를 사용해 /products/?/detail 또는 /products/*/detail로 입력하시면 됩니다.

Http 상태 코드를 변경할 때 Type 은 Response Status를 선택합니다. Match 영역의 Value에는 변경 대상이 될 상태 코드를 입력합니다. 정규식 표현을 지원해서 2xx 상태코드 전체를 치환할 수도 있어요. Replace 영역의 Value에는 변경하고 싶은 값을 입력하고 OK를 눌러 적용해 주세요.

비교를 위해 Rewrite 비활성화 상태에서 API를 호출해 봅니다. Response Code가 200으로 정상이네요.

Rewrite 를 활성화하고 다시 API를 호출하면 💣 이모지와 함께 Notes 항목이 추가로 생겼습니다.

Rewrite Tool: status changed to "500"

지금까지 설정한 대로 잘 적용된 것을 노트 메시지를 통해 재확인했어요!

실무에서는 Status Code의 종류와 Response Body로 API의 예외처리를 구현하는데, 이렇게 Rewrite 기능을 이용해 간단히 테스트하실 수 있답니다.

Response Body를 일부 변경할 때는 Rewrite를 이용하고, 전체 내용을 변경하는 방법은 꿀팁3 에서 알려드릴게요 :)

꿀팁2. Request Header 변경하기

개발환경에서 Request Header를 핸들링하여 테스트해야 할 상황이 생기기도 합니다. 이 경우에도 Rewrite를 이용할 수 있어요.

Rewrite Rule 의 Type 을 Modify Header로 선택하고 Match 의 Name 에는
변경하고 싶은 Header 명을 입력해주세요.
헤더의 모든 값을 하나의 값으로 치환하고 싶은 경우, Match 의 Value 필드는 비워두고 Match whole value 를 선택합니다.

Replace의 Name은 변경을 원하지 않는다면 Math 의 Name 과 같은 값을 입력하시고, 변경을 원한다면 새로운 값으로 입력하시면 됩니다! Value에는 치환하고 싶은 값을 입력해주세요.

꿀팁1 에서 봤던 Notes가 또 있네요! 이 외에도 Rewrite를 통한 변경 내용은 Overview 탭의 Notes 필드 또는 Notes 탭으로 확인하시면 됩니다 :)

꿀팁3. json 파일로 Response Body 변경하기

꿀팁1 에서 알려드린 Status Code 변경과 함께 Response Body도 같이 변경하면 앱에서 API 오류 대응 테스트를 편하게 할 수 있습니다.
또는 API 의 Response를 변경에 앞서 side-effect 를 확인하는 용도로 이 기능을 활용할 수 있어요.

신규 API가 개발될 예정일 때 Mock 데이터를 json 파일로 클라이언트에 먼저 전달하면, 클라이언트와 백엔드 개발을 동시에 진행할 수 있는 장점이 있습니다!

Map Local 에 진입할 수 있는 방법은 3가지가 있어요.

첫 번째 방법은 메뉴바를 이용해 Tools > Map Local 에 들어갑니다. 두 번째 방법은 단축키(⌥ ⌘ L)를 이용하는 방법이에요. 이 두 가지 방법은 변경할 API를 직접 입력해야하는 번거로움이 있습니다.

세 번째 방법은 Sequence에 표시된 API 호출 목록 중 수정을 원하는 API를 선택한 후 우클릭 메뉴에서 Map Local에 들어갑니다.

우 클릭 메뉴로 진입했을 때의 장점은 Map From 필드가 자동으로 채워진다는 점이에요!

메뉴바 또는 단축키로 Map Local 메뉴에 진입한 경우에는 Enable Map Local 체크 후 Add로 매핑정보를 입력할 수 있습니다. Map From에는 호출하는 API 정보를 Map To에는 API의 응답값으로 내려줄 로컬 파일 경로를 입력합니다.

Choose 로 파일을 선택하면 편리하지만, 직접 입력하신다면 파일의 절대 경로를 입력해 주세요!

Mapped to local file: /Users/jihyang/idus/sample-data/sample-products.json

잘 적용되었다면 Notes에 로컬 파일로 매핑되었다는 정보와 함께 API의 응답 결과가 로컬파일 데이터로 출력되는 것을 확인하실 수 있습니다.

꿀팁4. localhost 응답 결과로 Response Body 변경하기

개발 서버에 반영하기 이전에 로컬에서 작업한 API를 앱에서 호출하게 설정할 수도 있습니다. 앱에서 *.abc.com/products 라는 API를 호출했을 때 찰스를 통해 localhost/products 라는 API를 호출하도록 하는 기능입니다.

이를 활용하면 실제 앱에서 사용하는 Request Header 와 Query Parameter 들로 API 를 테스트할 수 있어서 보다 안정적인 API로 개발해서 배포할 수 있는 장점이 있어요!

Map Local처럼 Map Remote 에 진입하는 방법도 3가지가 있습니다.

Tools > Map Remote 방법으로 설명을 이어가도록 할게요!

설정화면은 Map Local 과 유사하지만 Map To 항목이 달라지고 체크할 항목이 하나 더 추가됨을 보실 수 있습니다. 예시 화면에서도 감을 잡으셨을 텐데요~

Map Remote의 Map To 항목에는 호출할 API 를 입력합니다. 로컬의 Docker 환경에서 실행 중인 애플리케이션을 호출할 때도 Host에 localhost로 입력하시면 돼요 :) Map From 에 입력한 origin API의 헤더값을 remote API에도 전달하려면 Preserve host in header fields를 선택해줍니다!

remote API를 localhost로 설정한다면, 꿀팁0 에 나왔던 Recording Settings 에서 Include 항목으로 http://localhost 를 추가해야 해요. 그래야 Sequence 에서 localhost 로 호출된 항목을 확인하실 수 있습니다.

Mapped from remote URL: https://sample.abc.com/products

Map Remote 가 정상 동작하면 Notes 에서 위와 같은 메시지를 볼 수 있어요!

여기까지 읽고 계신 여러분을 위해 소소한 ✨보너스 팁도 알려드립니다. 찰스가 잘 안되신다면 체크해 보세요 ✅

찰스와 앱을 연결해서 사무실에서는 잘 사용했는데, 재택 할 때는 접속이 안돼요!

• Wi-Fi 네트워크 대역이 변경됐을 때 발생하는 상황입니다. 앱에 설치한 프로파일을 삭제 후, 재 설치해 보세요!

cURL error 60: SSL certificate problem: self signed certificate in certificate chain 에러가 발생해요!

• Proxy > macOs Proxy 체크를 해제하세요!
• 해당 설정이 체크되어 있으면, 연결된 Wi-Fi 의 프록시 메뉴에서 웹 프록시 와 보안 웹 프록시 가 활성화됩니다.

더 많은 분들이 찰스를 유용하게 업무에 이용하실 수 있도록 실무에서 활용하고 있는 꿀팁들로 정리해 봤는데요 조금이나마 도움이 되셨기를 바랍니다 😉

여러분들의 찰스 활용법도 댓글로 공유해 주시면 좋을 것 같아요!

Written by idus API Cell

Content writer
Jihyang Lee

아이디어스팀과 함께 할 테크인재를 영입 중입니다.
지금 여기에서 지원해 보세요!

도와줘요, 찰스(Charles)! 업무 효율 높이는 웹 디버깅 프록시 툴 사용법 was originally published in Backpackr Team (idus, Tumblbug) on Medium, where people are continuing the conversation by highlighting and responding to this story.

이 글에서는 디스플레이 영역에 유저가 관심 있을만한 콘텐츠를 보여주기 위해
유저 세그멘테이션 시스템을 개발했던 이야기를 해보려고 합니다.

이제 시작할게요!

새로운 요구사항의 등장: 유저 세그멘테이션

마케팅 팀에서는 전환율을 올리기 위해 다양한 시도를 하고 있었고,
그 시도 중 하나로 특정 기준을 정해 유저 세그먼트를 분류하여 타겟 유저 그룹에
적절한 콘텐츠의 배너를 보여주고자 하는 요구사항이 있었습니다.

백엔드 개발자로서, 유저 세그멘테이션이 뭔지 모르는 것은 부끄러운 일이 아닐 것입니다. 혹시나 당시의 저처럼 유저 세그멘테이션이 뭔지 몰랐던 분들을 위해 잠시 설명을 하고 넘어갈게요.

유저 세그먼트란?

유저 세그멘테이션이란 커다란 그룹의 유저를 특정 기준에 따라 작은 집단으로 나누는 것을 의미한다. 유저 세그멘테이션의 목적은 유저의 행동과 선호, 필요로 하는 것을 이해하여 유저 경험을 증진 시키고 비즈니스적인 목표를 달성하는 것이다.

사용자가 분류되는 기준은 전부 말씀드리기는 어렵지만 최근 주문 일자,
최근 로그인 시각, 멤버십 가입 여부 등의 기준이 있었습니다.

사실 유저 세그먼트라는 것이 단순무식하게 구현한다면 수십 개의 where 절과 필요한 테이블 모두를 조인한 쿼리 하나로 모든 것을..해결할 수 있는.. 그런 것이죠.

하지만 아이디어스의 백엔드 서비스는 MSA 구조로 전환하는 과정에 있었고,
일부 서비스의 데이터베이스는 이미 분리가 되어 있는 상태였습니다.

전통적인 개발 방식과 단점

만약 전통적인 개발 방식으로 진행한다면,
유저의 마지막 주문일자를 기준으로 해당 유저가 어떤 세그먼트에 속하는지 판단 하려면, 주문 테이블에 쿼리를 날려 조회해야 했을 것입니다.

이 방식은 개발 자체는 심플해질지 몰라도 아래와 같은 단점을 갖게 됩니다.

• 레거시 서비스를 담당하고 있는 메인 DB에 부하를 줄 수 있음
• 즉 시스템 간에 장애 전파가 일어나기 쉬운 구조가 됩니다.
• Microservice로 분리되어 서빙되고 있는 상태에서 서로 다른 디비를 조회해 응답하게 된다면.. 서비스하기에 적절한 latency를 보장하기 어렵습니다. 결과를 캐시를 하더라도 캐시를 타지 못한 최초 요청은 꽤나 오랜 시간이 걸리겠죠.

Materialized view(구체화된 뷰)의 도입

위에 언급된 단점을 해결할 수 있는 방법으로 떠오른 것은 구체화된 뷰를 구성하는 것이었습니다.

Materialized view는 MSA 구조에서 여러 서비스의 데이터를,
그것을 필요로 하는 서비스가 원하는 형태로 반 정규화해서 동기화된 복제본을 가지고 있는 것을 말합니다.

CQRS 패턴과도 밀접한 연관을 가지고 있는 패턴으로, read model 을 분리해서
저장하는 형태입니다. Chatgpt 에 물어보니 아래와 같이 잘 알려주네요.

What is materialized view in MSA?

MSA 에서 머테리얼라이즈드 뷰는 미리 계산된 데이터 셋입니다. 머테리얼라이즈드 뷰는 각 마이크로 서비스가 가진 데이터를 복제하여 들고 있으면서, 필요한 구조로 비정규화된 데이터를 제공함으로써 조회 성능을 향상시킵니다.

마이크로 서비스 아키텍처에서, 일반적으로 각 마이크로서비스는 각자의 데이터를 저장하고 관리할 책임을 갖습니다. 이 때문에 여러 마이크로 서비스에서 복잡한 쿼리로 데이터를 조회해오기가 어렵습니다.

기존의 모놀리스 구조에서 데이터베이스의 join으로 처리하던 일을, MSA 구조에서는 application 로직을 통해 조인을 해야합니다. 이 방식은 조회성능 문제를 발생시키고, 쿼리에 조건을 걸기가 어려워지는 문제가 있습니다. 머테리얼라이즈드 뷰는 여러 마이크로서비스의 데이터를 하나의 데이터 셋으로 만듦으로써, 이 문제를 해결합니다.

머테리얼라이즈드 뷰는 조회가 많은 어플리케이션의 성능을 향상시킵니다. 미리 정의된 데이터 셋을 만들어 두기 때문에, 어플리케이션은 데이터를 훨씬 빠르게 찾아낼 수 있고, 전체적인 시스템의 부하를 줄일 수 있습니다.

머테리얼라이즈드 뷰는 보통 비동기로 업데이트가 되기 때문에, 완전한 실시간성을 보장하지는 못합니다. 이 단점은 전체적인 시스템 성능의 향상에 대비하면 대부분 납득할 만한 수준입니다.

결론적으로 머테리얼라이즈드 뷰는 마이크로서비스에서 데이터 조회를 최적화하는 유용한 기술입니다. 하지만, 데이터 동기화를 유지하기 위한 많은 노력이 필요합니다.

Materialized view는 다 좋지만, chatgpt 가 마지막 문장에 알려주었듯이 데이터 동기화 유지가 관건입니다. 개인적으로는 구체화된 뷰를 사용하면서 느꼈던 장단점은 아래와 같은 것이 있었습니다.

장점

• 조회 성능이 우월하게 빠르다.
• 시스템 간 장애 전파가 방지된다. 예를 들어 주문 시스템에 장애가 발생해도 segment 기능은 정상적으로 동작한다.

단점

• 필드 추가시마다 전체 데이터를 다시 동기화해야 한다.
• 데이터 동기화를 위한 추가 작업이 들어가며, 동기화가 깨질 위험성이 있다.
• 비동기로 데이터가 동기화되기 때문에 완전한 실시간성을 보장하지 못함.

꽤 많은 단점에도 불구하고, 위 두 가지의 장점 때문에 구체화된 뷰 패턴을 사용하기로 결정했습니다.

데이터 동기화 방법

데이터 동기화는 MSA 구조상에서 Event driven으로 처리가 되기 때문에
Event driven architecture 와도 밀접한 연관이 있습니다.

예를 들면, 고객이 주문을 하는 경우 주문 시스템은 레거시 서비스에 존재하기 때문에, 레거시 서비스에서 kafka를 통해 결제 완료 이벤트를 발생시킵니다.

해당 이벤트에 관심을 갖는 각 마이크로서비스가 해당 메시지를 전달받아
필요한 로직을 수행하는데, marketing 서비스에서는 해당 이벤트를 전달받으면 Materialized view를 업데이트하도록 구성했습니다.

이를 위한 작업 순서는 아래와 같았습니다.

• aggregator의 코드 내에 materialized view 동기화를 위한 이벤트 발행 로직을 작성합니다. 예를 들면, 로그인 시 로그인 이벤트를 발행하고, 결제가 완료되면 checkout 이벤트를 카프카로 발행합니다.
• 이때 materialized view 가 초기화되고 유지되는 방식은 검색 색인 방법론의 정적색인, 동적색인과 동일합니다.
• 먼저, 동적색인(증분색인)을 위한 코드를 개발해 배포합니다.
  materialized view 를 지속적으로 업데이트하기 위한 작업으로,
  aggregator에서 발행했던 이벤트 들을 marketing 서비스가 받을 때마다
  지속적으로 materialized view \를 업데이트합니다.
• 이때 유의할 점은 이벤트 처리의 멱등성과 동시성을 잘 고려하는 것입니다.
  특히 업데이트 로직의 멱등성 유지는 정적 색인과 혹시 모를 장애 상황에
  이벤트 재처리를 위해 필수적입니다.
• 이후 정적 색인을 위한 코드를 개발해 실행합니다. 이때 기존 데이터 소스에 존재하는 모든 데이터를 조회해 materialized view에 import 시킵니다.

잠깐.. 멱등성이 뭔지 모르시는 분들을 위해 잠깐 설명하고 넘어갈게요. 아신다면 넘어가셔도 됩니다.

멱등성?

멱등성을 유지하는 함수는 아래와 같은 수식을 갖습니다.

f(f(x)) = f(x)

이벤트 처리에서 멱등성이 유지되어야 한다는 말은, 같은 이벤트를 여러번 수신하더라도 결과적으로 저장되는 상태는 동일해야 한다는 뜻입니다.

위키백과에 따르면..

멱등법칙(冪等法則) 또는 멱등성(冪等性, 영어: idempotent)은 수학이나 전산학에서 연산의 한 성질을 나타내는 것으로, 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 의미한다. 멱등법칙의 개념은 추상대수학(특히, 사영작용소·폐포연산자 이론)과 함수형 프로그래밍(참조 투명성의 성질과 관련된)의 여러 부분에서 사용하고 있다. — 위키백과

MSA 구조에서 서비스 간 이벤트 처리에 있어서 대부분의 경우 멱등성을 유지하는 것을 권장합니다.

다시 돌아와서, 위의 과정을 마치고 나면 데이터 소스와 materialized view 간의 동기화가 준 실시간으로 유지됩니다. 간단하게 표현하면 아래와 같습니다.

카프카 이벤트가 유실되지 않는 한 구체화된 뷰와 데이터 소스 간의 동기화는 유지됩니다. 만약 유실된 이벤트가 있다고 해도, 추가로 발행하면 되고, 혹시 이벤트를 수신해 처리하는 과정에 문제가 있었다면 kafka의 offset을 특정 시점으로 돌려 이벤트를 replay를 하면 됩니다. 동적색인 시 멱등성을 유지해야 하는 이유가 바로 이벤트 재처리를 위한 것이죠.

세그멘테이션의 구현

위에 설명한 과정을 통해 유저의 활동 데이터를 marketing 서비스의 데이터베이스에 저장했으니, 그다음은 해당 데이터를 사용해 유저가 어떤 세그멘트에 속하는지 판단하는 로직을 구현하는 것이었습니다.
유저 세그멘테이션 기능은 아래와 같이 단순한 질의에 대답만 하면 되는 간단한 일입니다.

“헤이, 1번 유저는 무슨 세그멘트에 속해?”

마케팅 서비스는 위 질의를 받으면, 먼저 캐시를 확인합니다. 캐시가 비어있으면 위에서 구현한 user 활동 관련 정보를 집약한 materialized view(user activity)를 조회하여 segment 분류 조건에 따라 해당 사용자의 세그먼트 리스트를 만들어 캐시에 저장합니다.

그리고 user activity에 대한 업데이트가 발생할 때마다 해당 유저에 대한 캐시를 제거하여 다음 요청에 갱신되도록 합니다. 플로우를 간단하게 sequence diagram을 그려보면 이렇습니다.

세그먼트 데이터 업데이트

세그먼트 데이터 조회

위 과정들을 통해 marketing service는 자체적으로 가진 뷰를 통해 필요한 유저 데이터를 유지하고, 해당 유저의 세그먼트를 매우 빠른 성능으로 계산해낼 수 있었습니다.

그래서..얼마나 빨랐냐고요?

Average latency는 3ms였으며, p99 latency 가 20ms 가 채 안 되는 빠른 속도의 조회 성능을 볼 수 있었습니다.

사실 어떤 서비스들은 이 정도의 응답속도까지 필요하지 않을 수는 있습니다.
여러분들도 트레이드오프를 잘 고려해 보시고, 성능과 응답속도, 장애에 대한 내성이 중요하다면 Event driven architecture와 materialized view를 도입해 보시길 권해드립니다.

그럼 긴 글 읽어주셔서 감사합니다.
잘못된 점에 대한 지적이나 토론은 언제나 환영이니 댓글 많이 남겨주세요!

Written by idus Core system Cell

Content writer
Jongchan Park

아이디어스팀과 함께 할 테크인재를 영입 중입니다.
지금 여기에서 지원해 보세요!

User segmentation 시스템 개발기 was originally published in Backpackr Team (idus, Tumblbug) on Medium, where people are continuing the conversation by highlighting and responding to this story.

아이디어스팀은 대한민국 No .1 핸드메이드 마켓 플레이스로서 ‘핸드메이드’의 가치를 찾아 확장과 성장을 지속하고 있습니다.

아이디어스팀들의 주니어 구성원분들도 아이디어스의 One team 문화 안에서 Superb colleague 분들과 함께 성장하고 있는데요.

각자의 위치에서 열심히 노력하며, 아이디어스 서비스를 개발하고 있는 여섯 번째 타자 Web platform셀 예진님을 만나 아이디어스팀에 대한 이야기를 들어보았습니다:)

Q. 안녕하세요!~ 간단한 자기소개 부탁드립니다.

안녕하세요. 저는 Web platform셀 김예진입니다🙂

작품 등록부터 운영까지 작가님들의 작품 활동에 필요한 전반적인 기능을 제공하는 작가 2.0 서비스의 프론트엔드 개발을 맡고 있습니다!

Q. 어떻게 아이디어스팀에 조인하시게 되었어요?

평소에 좋아하는 서비스라 공고를 확인하자마자 바로 지원했었어요!

대학생 때부터 아이디어스 앱을 계속 이용해왔기 때문에,
만약 아이디어스팀에 최종 합격하여 프론트엔드 개발을 맡게 된다면 찐 사용자의
입장에서 개발할 수 있을 거라 생각했거든요.

Q. 최근 진행하고 있는 업무는 무엇인가요?

작가 앱 신규 프론트엔드 서비스를 개발하고 있어요.

기존 Android, iOS 로 나누어져 있던 작가 앱을 하이브리드 앱으로 개발하게 되어, 개발 초기 단계부터 참여하게 되었는데요!

작년 7월쯤 시작해서 올해 초에 론칭을 하게 되었어요.

얼마전에 작가 2.0 의 데스크톱 버전까지 론칭한 이후, 사용성 개선 작업을 열심히 하고 있답니다👏

Q. 가장 기억에 남는 프로젝트나 성취감을 느꼈던 일이 있다면 무엇인가요?

작가 2.0 서비스의 댓글 기능을 개발했던 것이 가장 기억에 남습니다.😎

아무래도 작가님들이 댓글 기능을 주문, 메시지 다음으로 많이 활용하고 계실 텐데요! 많이 사용하시는 만큼 개발할 때 사소한 부분 하나하나 신경 써서 작업을 했는데, 지금까지 사용성에 큰 이슈와 버그 없이 댓글 기능을 잘 활용하고 계신 것 같아서 뿌듯합니다!

Q. 신입 개발자로서 혹시 당황했던 에피소드도 있으신가요!?

작가웹 첫 론칭 때 저희가 QA를 진행했었는데 QA 티켓이 어마 무시하게 나왔던 기억이 있어요😂

해당 스프린트에 회고를 진행했는데, “설계 리뷰하는 시간을 가져보자”라는 의견이 나와서 개발 프로세스를 변경했던 경험이 있습니다.

기존에는 PRD 리뷰 이후 설계하는 과정 없이 바로 개발에 들어갔었거든요.

회고 이후 PRD 리뷰 이후 설계한 내용을 팀원들과 함께 리뷰하는 과정이 추가되었답니다.

이후 QA 티켓의 개수는 현저하게 줄어 들었어요.😊

→ 해당 프로젝트에 대한 자세한 내용 보러가기

아이디어스 프론트엔드 개발자들은 어떻게 일할까?

Q. 아이디어스팀의 프론트엔드 개발자로서 하루 일과를 설명해 주신다면요?

출근 후 자리에 앉으면, 어제 남았던 업무와 오늘 할 일을 정리해서 기록합니다.

오전에는 작가 웹 프로젝트 스크럼에 참여를 하고 있고 있고요.
이후 점심 전까지는 개인 업무를 진행합니다.

점심을 먹은 후에는 간단하게 셀 스크럼을 진행하는데요.
셀 스크럼에서는 이슈가 있다면 간단하게 이야기하고, 팀원들과 아침에 정리해뒀던 어제 한 일, 오늘 할 일을 공유하고 있습니다.

혹시 이슈가 있다면 그 이슈에 대해 논의하고 싶은 사람들이 남아 이야기하곤 해요.

그 이후에는 개인 업무를 정리하고 퇴근합니다.

Q. 셀 문화나 장점이 있다면 어떤 점일까요?

세 가지로 말씀드릴 수 있을 것 같아요.

첫 번째는 Be Open입니다.

셀원 분들이 모두 오픈 마인드를 가지고 계셔요😊

주니어, 시니어 상관없이 자유롭게 의견을 이야기할 수 있는 환경이고, 주니어의 의견 반영도 적극적으로 해주십니다. 그래서 더 많이 배울 수 있고, 많이 성장할 수 있는 것 같아요.

두 번째는 코드 리뷰가 굉장히 활발합니다.

저희 Web platform 셀은 10년 후에도 살아남을 수 있는 코드를 만들기 위해!!
적극적인 리뷰 문화를 바탕으로 업무를 진행하고 있어요.

모르는 부분이 있다면 온라인/오프라인 미팅을 통해 코드 리뷰를 진행하기도 하고요. 좋은 PR에는 코멘트도 서로 남깁니다.

세 번째는 매 스프린트마다 회고를 진행하는 것인데요.

저희 팀은 스프린트를 2주 단위로 진행하는데, 스프린트가 끝날 때마다 회고를 진행하고 있어요. 그때마다 팀원들이 잘한 점과 아쉬운 점을 공유하는데, 잘한 점은 더 발전시키고 아쉬운 점은 다음 스프린트 때 개선하며 발전시켜 나가고 있습니다.

Q. 셀 내 일하는 방식은 어떤가요?

아까 장점에 다 언급한 것 같아요!🙂

현재 작가앱 프로젝트를 진행하고 있는 분이 팀 내 네 분이 계세요. 저만 자리가 동떨어져 있었는데, 지금은 옆자리로 자리를 옮겨서 매일 귀찮게 해드리고 있답니다 ^^

너무 tmi 인가요😂😂 결론은 이제 죽고 못사는 사이가 됐답니다~ (는 예진님 피셜🙌🏻)

Q. 개발문화/ 셀문화 이외에 아이디어스팀에서 일하며 가장 만족스러운 점이 있으신가요?

이 질문도 세 가지로 답변드릴 수 있을 것 같아요!

결론부터 말씀드리면 일하기 좋은 회사라고 생각합니다!

첫 번째, 구성원 누구든지 의견을 내고 서비스에 반영할 수 있다는 점이 신기하고 좋았어요. 슬랙 채널 중 #idea_makes_idus라는 채널이 있어요.

#idea_makes_idus: 아이디어스 서비스 전반에 대한 기능 개선과 새로운 서비스 제안을 누구든지 할 수 있는 채널

저도 이곳에 의견을 낸 적이 있는데요!

PO 분들이 고민해 보시고, 우선순위에 따라 실제로 서비스에 적용되는 경우도 많습니다.

두 번째는 구성원들을 위한 복지가 아주 잘 갖춰져 있어요.
휴가를 눈치 보지 않고 쓸 수 있다는 점이 가장 좋고, 장기 휴가도 사전에 팀원들에게 공유만 하면 자유롭게 사용할 수 있어 리프레시 하기 좋다고 생각합니다.

세 번째는 최신 장비 지급과 도서 구매 복지입니다. 업무에 도움이 되는 도서를 손쉽게 구매할 수 있어요~!
지난주에도 도서 구매를 신청했는데 빨리 도착했으면 좋겠어요 ㅎㅎ!

Q. 아이디어스팀에서 이루고 싶은 목표가 있다면 무엇인가요?

작가 2.0 서비스 리뷰 5.0 달성이 목표입니다!!! 😎

아이디어스팀 슈퍼 주니어 6인의 인터뷰가 모두 마무리되었습니다:)

One team 문화 안에서 Superb colleague 분들과 함께 성장하고 있는
주니어 분들의 인터뷰 재미있게 보셨나요?

다음에 더 새롭고 재미있는 콘텐츠로 찾아오도록 하겠습니다.

Written by idus Friends Cell

Content writer

Saeyan Ryu

아이디어스팀과 함께 할 테크인재를 영입 중입니다.
지금 여기에서 지원해 보세요!

고속성장 중인 주니어 개발자 6인을 소개합니다. was originally published in Backpackr Team (idus, Tumblbug) on Medium, where people are continuing the conversation by highlighting and responding to this story.

아이디어스팀은 대한민국 No .1 핸드메이드 마켓 플레이스로서 ‘핸드메이드’의 가치를 찾아 확장과 성장을 지속하고 있습니다.

아이디어스팀들의 주니어 구성원분들도 아이디어스의 One team 문화 안에서 Superb colleague 분들과 함께 성장하고 있는데요.

각자의 위치에서 열심히 노력하며, 아이디어스 서비스를 개발하고 있는 다섯 번째 타자 Android셀 연재 님을 만나 아이디어스팀에 대한 이야기를 들어보았습니다:)

Q. 안녕하세요!~ 자기소개 부탁 드립니다.

안녕하세요~! 저는 현재 아이디어스팀에서 Android 개발을 맡고 있는 이연재입니다.😄 현재 Next level이라는 프로젝트에서 홈 파트 Android 개발을 맡고 있어요.

Q. 어떤 기준으로 아이디어스라는 회사를 선택하셨어요?

먼저 제가 사용하고 있는 앱이었어요.

회사를 선택하는 기준에 있어 관심사도 굉장히 중요하다고 생각하는데, 아이디어스는 실제로 제가 사용하고 있는 앱이었기에 관심을 가지고 일을 할 수 있을 것 같았습니다~!

그리고 앱을 만드는 이커머스 회사에서 일을 하고 싶었어요. 이커머스가 다양한 도메인들이 많기 때문에 그 부분을 경험해 보고 싶었습니다.

Q. 어떤 계기로 아이디어스팀에 조인하시게 되었어요?

저는 회사를 보는 기준이 2가지가 있는데요.

첫 번째, 선한 영향력을 줄 수 있는 회사인지를 봐요.

수공예 시장에 있어서 아이디어스가 있기 전에는 공예 작가님이 아무리 좋은 작품을 만들어도 판매할 수 있는 채널이 제한적이었잖아요.

그런데 아이디어스가 생긴 이후에는 언제 어디서든 공예 작가님들이 편리하게 판매를 할 수 있게 되었어요. 이렇게 수공예 시장을 활성화시키고 소상공인들과 상생하는 아이디어스팀의 선한 영향력이 저에게 와닿았어요.

실제로 아이디어스는 많이 파는 것이 아닌, 나만을 위한 가치에 우선을 두고 핸드메이드 문화를 만들어나가고 있어요. 작가님들을 위한 세무, 촬영, 저작권, 촬영 스튜디오 등의 지원 프로그램도 많답니다!

두 번째는 개인의 성장성이에요. 제가 성장할 수 있는 곳인가를 크게 봤는데 아이디어스팀의 컬쳐핏 6가지를 보며, 이전 회사보다 제가 더욱 성장할 수 있을 거라고 생각했어요.

실제로 업무 과정도 체계적이고요!😄

Q. 최근 진행하고 있는 업무는 무엇인가요?

저는 ‘Next level’ 프로젝트에서 홈 파트를 개발하고 있어요.

제가 처음 팀에서 개발한 것이 “아이디어스 취향 서베이”인데요.

아이디어스에 처음 방문하시는 분이나 장기로 접속하지 않으신 분들은, 홈 유닛이 활성화되지 않아요. 그래서 이 취향 서베이를 통해 자신의 취향에 맞는 카테고리를 선택하면 추천 유닛을 활성화할 수 있는데요.

현재 이 부분을 개발하고 고도화 해나가고 있습니다.

직전에 소개되었던 iOS셀 기현 님과 함께 개발하고 있어요.🙂

Q. 아이디어스팀의 Android 개발자로서 하루일과를 설명해 주신다면요?

저는 팀 스크럼이 10시 40분에 있어서 보통 10시에 출근하고 있습니다.
출근하자마자 항상 곳간에서 음료수를 가지고 와요.

그 후 진행되는 팀 스크럼에서는 어제 한 일에 대한 이야기, 오늘은 어떤 작업을 할 건지에 대해 이야기를 합니다. 이 부분을 이야기 하기 위해 사전에 내용을 정리한 후 15분 정도 진행되는 스크럼에 참여를 하고 있어요.

그리고 프로젝트 스크럼을 이어서 하는데요.
이 스크럼에서는 이슈사항과 질문사항을 정리해서 프로젝트 팀원들과 이야기합니다.

프로젝트 스크럼을 마치면 11시 15분쯤 되고, 그때부터 퇴근 전까지는 개발로 시간을 보내고 있습니다.

Q. 셀 문화나 장점이 있다면 어떤점 일까요?

저희 Android 셀원 분들은 묵묵하게 서로를 잘 챙겨주는 편이에요. 코드 리뷰 또한 활발하게 진행되고 있어요!😎

위에서 팀 스크럼 때 이슈나 업무 관련 얘기를 공유한다고 말씀드렸었는데요. 그 자리에서 모르는 부분이 있다면 바로 질문하고 해결하는 시간도 가지고 있습니다.

그리고 저희 셀원 분들 중 시니어 분들이 많이 계세요. 그래서 다들 굉장히 전문적이시고, 같이 일하기에 최고의 동료라 생각해요!

아주 많이 배우고 있습니다.😊

Q. 아이디어스팀에서 일하면서 가장 만족스러운 점이나 자랑하고 싶은 점이 있다면요?

일단 곳간 간식들과 음료가 너무 좋고요.

아무래도 제가 주니어이다 보니 강의나 스터디에 관심이 많았는데, 도서비와 교육비를 다 지원해 주셔서 너무 좋습니다.

금액 제한 또한 없어서 더 만족스럽습니다. 입사하자마자 직무 관련된 꽤 비싼 강의를 들었는데 실제로 그 강의가 업무에 도움이 많이 됐었어요.

Q. 아이디어스팀에서 이루고 싶은 목표가 있다면 무엇인가요?

제가 아까 회사를 보는 중요 기준 중에 ‘개인의 성장성’을 말씀드렸었는데요.

아이디어스팀에서 많이 배우고 아주 크게 성장을 하고 싶은 마음이 있었는데, 현재 여기서의 3개월은 정말 폭풍 성장을 했다고 제 스스로 느꼈어요.

그래서 앞으로는 개발자로서의 관점에서뿐만 아니라, 더 큰 관점에서 앱이 어떻게 돌아가고, 프로세스나 비즈니스적인 부분까지 모두 성장하고 싶은 목표를 가지고 있습니다.😎

Written by idus Friends Cell

Content writer

Saeyan Ryu

아이디어스팀과 함께 할 테크인재를 영입 중입니다.
지금 여기에서 지원해 보세요!

고속성장 중인 주니어 개발자 6인을 소개합니다. was originally published in Backpackr Team (idus, Tumblbug) on Medium, where people are continuing the conversation by highlighting and responding to this story.