식사중에 warning 알람이 발생했습니다. 식사를 멈추고 업무에 복귀해야 할까요?어플리케이션 또는 시스템 문제가 발생했을때, 알람을 받게 하는것은 쉽습니다.하지만 실제 그 알람의 본질이 어떤것인지, 얼마나 중요성이 높은것인지 판단하는 것은 훨씬 어렵습니다.특히 당장

AWS Lambda의 Cold start와 관련되 발생할 수 있는 실수에 대해 공유합니다Lambda를 통해 workload를 운영할때 겪는 가장 첫번째 문제는 Cold Start입니다. Lambda는 배포된 이후 처음 요청이 들어온 경우 Download CodeStar

istio는 디코딩 불가능한 문자열을 포함한 xff spoofing으로 한번에 박살낼 수 있습니다당연히 공격하라는 의도가 아니라 대비하라는 의도입니다. 왜냐면 제가 당했거든요 🥲istio Operator 기준으로 작성하였습니다. operator가 아닌 다른 방식으로도

FOCP는 FinOps Certified Practitioner의 줄임말입니다시험 난이도는 쉬우면서도 어렵습니다300달러라는 어마어마한 비용이지만, 할인은 없으니 당장 그냥 시도하세요60분 50문제라는, 보기에는 다소 빠듯한 시간같아 보이지만 용어가 익숙하다면 절반의

EKS, Fargate, Datadog에 대한 기본적인 설명은 없습니다 사건의 발단 Karpenter를 사용하면 Node의 Lifecycle이 굉장히 짧아질 수 있습니다. 그래서 가능하면 크리티컬한 워크로드의 경우 karpenter가 제어하는 노드가 아닌 manag

이 전 포스팅의 연장입니다.대부분의 어플리케이션 Pod들은 초기화 단계에서 높은 CPU를 요구하는데 반해, 그 이후 과정에서는 낮은 CPU를 요구합니다.그렇다면 Pod의 requests를 어떻게 설정할 수 있을까요?초기 높은 CPU를 기준으로 삼으면\-> over pr

이 글을 적고싶지 않았습니다. 이렇게 까지 되면 안됬던겁니다. 뭔가 말이 안되는... 진짜로 이런일은 다시는 일어나면 안되기 때문에 부끄러운 결과지만 글을 씁니다 문제의 발단

Karpenter의 docs에는 잘못된 부분들이 있습니다. 일부 유저에게는 크리티컬할 수도 있는 부분인데, 어떤 일이 있었는지 공유합니다.주의 이 글은 Karpenter의 설치 방법과 작동 방식 등을 설명하는 내용은 전혀 아닙니다.우선 EKS에 Karpenter를 설치