기술 블로그 모음

요즘 우리나라는 어느 회사든 글로벌 진출을 염두에 두고 있습니다. 대부분의 분야에서 우리나라 시장은 가파른 속도로 축소될 전망이므로 해외 진출은 하고 싶은 것이 아닌 할 수밖에 없...

리디의 적극적인 대응으로 콘텐츠 불법 유통과 피해 확산을 막을 수 있었다. The post 리디, DRM 해제기 불법 공유 텔레그램 채널 폐쇄 이끌어 appeared first on 리디주식회사 RIDI Corporation.

NGINX App Protect WAF V5 – 기존 NGINX 통합 설치 가이드 이 포스트는 기존에 NGINX가 설치된 인스턴스에 NGINX App Protect WAF V5(NAP WAF)를 추가로 설치하여 통합하는 방법을 설명합니다. app-protect-module 패키지를 설치하고, Docker를 통해 waf-enforcer, wa...

안녕하세요, 이스트시큐리티입니다.   통합 보안 전문 기업, 이스트시큐리티가 오는 3월 19일(수)부터 3월 21일(금)까지 일산 KINTEX에서 개최되는 eGISEC 2025 전자정부 정보보호 솔루션페어에 참가하여 기업 고객을 위한 더욱 강력한 보안 대응 전략을 제시합니다!   이번 eGISEC 2025에서는 이스트시큐리티...

인터넷에서 원하는 정보가 나오지 않아 답답했던 적 있나요? 하이퍼클로바X는 방대한 데이터 속에서 길잡이처럼 원하는 정보를 쏙쏙 찾아주는 기술을 가지고 있다는데요. 대체 어떻게 길을 찾고 있는 건지, 한 번 알아볼까요? 연결의 힘 보험 약관 수백 페이지, 내가 원하는 정보는 어디에..? 연말정산 항목에서 내게 해당하는 정보를 빠르게 찾을 수 있을까? 이...

안녕하세요, 당근 프로덕트 디자이너 Ina입니다.당근의 웹사이트를 알고 계신가요? 당근 웹사이트에서는 당근의 다양한 서비스를 앱 설치 없이도 만나볼 수 있는데요. 사용자들에게 당근의 매력을 알리는 중요한 창구예요.당근 웹사이트: https://www.daangn.com/Karrot 글로벌 웹사이트(캐나다): https://www.karrotmarket.com/ca/Karrot 글로벌 웹사이트(일본): https://www.karrotmarket.com/jp/이번 글에서는 당근의 글로벌 서비스 Karrot의 사용자들이 웹에서도 당근을 쉽게 만날 수 있도록, 북미와 일본 지역을 대상으로 검색 엔진 최적화(SEO)를 강화하고 자연스럽게 앱 설치로 이어지는 매물 중심 탐색 경험을 개선한 웹사이트 프로젝트를 공유해보려고 해요.SEO란 무엇일까요?SEO(Search Engine Optimization)는 검색 엔진 최적화를 의미해요. 구글이나 네이버 같은 검색엔진에서 사용자가 원하는 정보를 검색했을 때, 당근의 웹사이트가 상단에 노출되도록 만드는 작업이에요.예를 들어, “중고 아이폰 15”라는 키워드를 검색했을 때 당근 웹사이트가 검색 결과 첫 페이지에 노출된다면, 더 많은 사람들이 사이트를 방문하게 될 거예요. 이는 곧 서비스 성장으로도 이어지겠죠.즉, SEO는 검색 결과에서의 노출뿐만 아니라 사용자와의 연결을 강화하는 필수 전략이라고 볼 수 있어요.SEO를 위한 유저 경험 만들기이 프로젝트의 핵심은 당근 웹사이트의 검색 랭킹을 높이기 위해, 다음 세 가지 요소를 충족시키는 것이었어요:관련성(Relevance): 사용자가 실제로 원하는 키워드와 유용한 콘텐츠 제공품질(Quality): 신뢰도를 높이는 양질의 콘텐츠 및 백링크사용성(Usability): 모바일 친화성, 페이지 속도, 보안 등 사용자 중심의 사이트 환경위와 같은 기술적인 SEO 목표를 달성하면서, 동시에 사용자 만족을 높이기 위해선 어떤 경험이 필요할까요?저는 이 문제를 해결하기 위해 당근의 디자인 원칙 세 가지와 검색 랭킹을 높이기 위한 기술적 솔루션 세 가지를 매칭해보고자 했어요.연결된 경험 — 관련성(Relevance)직관적인 경험 — 품질(Quality)사용자를 위한 개선 — 사용성(Usability)(참고) 당근의 디자인 원칙 7가지1. 연결된 경험2. 사용자를 위한 개선3. 직관적인 경험4. 하나의 화면 하나의 목표5. 단순한 시각 요소6. 적절한 피드백7. 간결한 문구1. 관련성(Relevance)을 위해 ‘연결된 경험’을 제공해요맥락에 맞는 키워드를 배치해요사용자들이 실제로 많이 검색하는 키워드를 자연스럽게 배치하고자 검색 결과 페이지에 필터를 추가했어요.필터는 탐색 편의를 높여요. 동시에 필터에 포함된 키워드가 검색 결과에도 노출되죠. 따라서 사용자 경험과 SEO 모두에 긍정적인 영향을 줘요.그 외에도 검색창 아래에 인기 키워드를 배치하는 등 키워드가 노출되는 곳을 다양하게 늘려나가고자 했어요.지역 설정 기능을 제공해요당근을 떠올리면 가장 먼저 생각나는 ‘동네’ 키워드를 웹사이트에 녹여내기 위해, 동네 설정과 검색 기능을 추가했어요.이를 통해 사용자는 동네에서 거래되는 물건을 쉽게 확인할 수 있게 되었어요. 또한 검색 엔진에서 ‘서초동’ + ‘소파’ 같은 지역 키워드를 함께 입력했을 때도 자연스럽게 당근 웹사이트를 만나볼 수 있게 되었어요.2. 품질(Quality)을 위해 ‘직관적인 경험’을 제공해요카테고리 목록을 추가해요글로벌 Karrot은 중고거래 서비스만 제공하고 있어요. 그래서 카테고리 페이지를 추가해 사용자들이 어떤 카테고리가 있는지 한눈에 파악하도록 돕고, 카테고리 자체로도 검색 결과가 보일 수 있도록 개선했어요.카테고리 자체가 검색 결과가 되도록 노출하기카테고리도 하나의 검색 결과로 만들며 검색 엔진에 노출되도록 개선했어요브레드크럼(Breadcrumb)을 추가해요“홈 > 부동산 > 매물”처럼 현재 위치와 다음 동선을 한눈에 파악할 수 있도록 내비게이션 흐름을 구성했어요.브레드크럼(Breadcrumb)은 사이트 품질을 높여요. 동시에 사용자에게 지금 어느 페이지에 있고 이전에 어떤 페이지를 거쳤는지를 명확히 알려줘, 직관적인 탐색 경험을 강화해요.3. 사용성(Usability)을 위해 사용자를 위한 개선을 만들어요반응형 디자인글로벌의 다양한 디바이스 환경을 고려해, 화면 크기에 따른 배치·컴포넌트를 6가지 브레이크포인트로 정교하게 설계했어요. 그 결과, 모바일 디바이스·태블릿·웹 등 다양한 환경에서도 웹사이트를 불편함 없이 이용할 수 있게 되어, 사용성(Usability)이 크게 향상됐어요.결과배포 한 달 이후의 결과예요🇨🇦 북미(캐나다): Impression(노출) 약 20배 성장, 클릭이 2배 성장했어요.배포 이후의 성장 그래프🇰🇷 한국 (24년 11월 초에 동일한 UX/UI로 개편) : 월 접속자 수 약 43% 상승했어요. (기존 426만 → 610만)마치며이번 프로젝트는 ‘관련성(Relevance)’, ‘품질(Quality)’, ‘사용성(Usability)’의 세 가지 핵심 요소를 사용자 중심의 디자인으로 풀어낸 SEO 전략으로, 당근의 웹사이트가 더 많은 사용자에게 노출되고 건강하게 성장할 수 있는 발판을 마련한 프로젝트라 뜻깊게 참여할 수 있었어요.이 프로젝트에 함께해 준 토니, 리바이, 리아, 헤일리, 해나, 브랜딩팀 리지, 쿄, 유니와 이어서 웹사이트를 널리 알리는데 애써주시는 SEO Growth 팀에게 응원과 감사의 마음을 전해요!건강한 SEO로 성장하는 웹사이트 만들기 was originally published in 당근 테크 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Kubernetes Web UI Dashboard 배포 및 사용법 Kubernetes Dashboard 는 Kubernetes 클러스터를 시각적으로 관리할 수 있는 웹 기반 UI입니다. 이를 통해 클러스터의 리소스를 모니터링하고, 애플리케이션 배포 상태를 확인하며, 직접 추가, 수정 및 삭제하는 등의 작업을 수행할 수 있습니다. 본 문서에서는 Kube...

주요내용 25년 3월 소식에서는 다음과 같은 유용한 정보들을 만나보실 수 있습니다. 2024 Frameworks Year in Review Netlify의 웹덕후들이 2024년의 흐름 그리고 25년도에 대한 기대를 정리해 줍니다. How long is a second in JavaScript? JavaScript에서 '초'의 길이와 시간 측정의 역사와 과학적 배경을 탐구해 봅니다. Optimizing the Critical Rendering Path 웹 페이지의 초기 렌더링을 지연시키는 주요 자원들을 식별하고, 이를 최적화하여 사용자 경험을 향상시키는 방법을 다룹니다. Sunsetting Create React App React 공식 팀이 Create React App(CRA)을 더 이상 유지하지 않기로 결정했습니다. >> FE News 25년 3월 소식 보러가기 ◎ FE News란? 네이버 FE 엔지니어들이 엄선한 양질의 FE 및 주요한 기술 소식들을 큐레이션해 공유하는 것을 목표로 하며, 이를 통해 국내 개발자들에게 지식 공유에 대한 가치 인식과 성장에 도움을 주고자 하는 기술소식 공유 프로젝트 입니다. 매월 첫째 주 수요일, 월 1회 발행 되고 있으니 많은 관심 부탁드립니다. ▷ 구독하기

주요내용 25년 2월 소식에서는 다음과 같은 유용한 정보들을 만나보실 수 있습니다. Cascading Spy Sheets: Exploiting the Complexity of Modern CSS for Email and Browser Fingerprinting Javascript와 Cookie 없이 CSS만으로 브라우저 지문 채취의 가능함이 증명되었습니다 The Ai-Assisted Developer Workflow: Build Faster and Smarter Today AI를 활용한 다양한 개발 도구가 어떻게 개발 방식을 변화시킬 수 있는지 알아봅니다. Toss Frontend Fundamentals 토스의 프런트엔드 개발자들이 공개한 변경하기 쉬운 프론트엔드 코드를 위한 지침서 Do JavaScript frameworks still need portals? Dialog, popover, CSS anchor positioning 등의 기능으로 Portal(React), Teleport(Vue) 를 대체하는 방법을 소개합니다. >> FE News 25년 2월 소식 보러가기 ◎ FE News란? 네이버 FE 엔지니어들이 엄선한 양질의 FE 및 주요한 기술 소식들을 큐레이션해 공유하는 것을 목표로 하며, 이를 통해 국내 개발자들에게 지식 공유에 대한 가치 인식과 성장에 도움을 주고자 하는 기술소식 공유 프로젝트 입니다. 매월 첫째 주 수요일, 월 1회 발행 되고 있으니 많은 관심 부탁드립니다. ▷ 구독하기

이 글에서는 글로벌 컨퍼런스인 COP29, CES 2025, WEF 2025에서 강조한 ESG 관련 메시지를 통해 ESG 경영에 영향을 미칠 수 있는 주요 이슈들을 재조명하고자 합니다.

대부분의 애플리케이션은 다양한 형식을 통해 가용 콘텐츠와 상호 작용해야 합니다. 이러한 애플리케이션 중에는 보험 청구 및 의료비 청구서와 같은 복잡한 문서를 처리하는 애플리케이션도 있습니다. 모바일 앱은 사용자가 생성한 미디어를 분석해야 합니다. 기업들은 문서, 이미지, 오디오, 비디오 파일 등의 디지털 자산을 기반으로 의미 체계 인덱스를 구축해야 합...

지난 9월에 AWS GenAI Loft London에서 애플리케이션을 라이브로 구축했을 때의 좋은 추억이 떠오릅니다. 샌프란시스코, 베를린 등의 지역에 AWS GenAI Lofts가 다시 설치되어 스타트업과 개발자에게 협업 공간과 몰입형 경험을 계속 제공하게 되었습니다. 놓칠 수 없는 AI 제품 및 서비스 이벤트, 워크숍, 네트워킹 기회를 직접 체험할...

이직 / 팀 이동 후 어색한 코드를 내 코드로 녹여내기까지의 여정을 공유합니다.

Kubernetes CronJob 을 이용한 NGINX Pod 로그 관리 Kubernetes에서 NGINX Pod의 로그를 효과적으로 관리하는 것은 시스템 유지보수와 운영의 핵심 요소입니다. 일반적으로 로그는 Pod 내부에서 생성되며, 이를 적절히 보존하거나 주기적으로 정리하지 않으면 저장 공간 부족과 같은 문제를 초래할 수 있습니다. 이를 해결하기 ...

안녕하세요! GS리테일 DX COE팀의 김헌기입니다.  오늘은 제가 GenAI 기술을 접한 경험과, 그 중에서도 특히 AI 코드 에디터 활용 경험을 공유하고자 합니다.1. GenAI ...

 # 들어가며 안녕하세요. NHN Cloud의 클라우드AI팀 이태형입니다. 로그 데이터가...

Kafka Connect와 JDBC 커넥터를 이용해 DB 데이터를 쉽게 Kafka로 전송하는 방법과 발생 가능한 문제를 해결하는 방법을 공유합니다.

Jaeger, OpenTelemetry 활용 Kubernetes 트래픽 흐름 추적 이 포스트에서는 Kubernetes 클러스터에 OpenTelemetry Operator를 통해 Jaeger 를 배포하고, OpenTelemetry Collector와 통합하여 Pod 간의 트래픽 흐름을 추적하는 방법을 다룹니다. 클러스터 내부의 마이크로서비스 애플리케이션...

본 글은 2024년도 12월에 올리브영 테크플랫폼센터 오거나이저에 의해 작성되었습니다. 새로운 경험의 서막: 마곡의 한 호텔 연회장에 모인 올리브영 엔지니어들 2024년 11월 1…

이 아티클에서는 LLM이 생성한 결과물을 사용자가 기대하는 수준의 정확성과 일관성을 유지하면서 윤리적인 결과를 산출하는지 LLM의 신뢰성 평가 방법과 사례에 대해 알아봅니다.

이 전망은 삼성SDS 마케팅팀 MI그룹에서 2024년 말에 400여 명의 국내 IT 의사결정 관계자를 대상으로 실시한 설문 결과로서, 2025년도에 직면할 국내기업의 경영 환경과 IT 투자 전망 중 서비스산업을 집중 분석하였습니다.

시작하며 안녕하세요. Enablement Engineering 팀에서 SRE(site reliability engineer)로 일하고 있는 어다희입니다. 저희 팀은 LINE 서비스...

Istio Ambient Mesh 설치 가이드 이 포스트는 Istio Ambient Mesh가 무엇인지 알아보고, Kubernetes 클러스터에 Istio Ambient Mesh 를 설치하는 방법을 다룹니다. Istio Ambient Mesh는 기존 Sidecar 기반의 Istio Service Mesh를 대체하는 새로운 아키텍처로,서비스 간 보안(m...

안녕하세요, 누구나 쉽게 시작하는 클라우드 네이버클라우드(ncloud.com)입니다. #네이버클라우드 #네이버클라우드캠프 #네이버클라우드캠프서포터즈 지난 1월 17일 오후, 네이버 파트너 스퀘어 역삼에서는 '2024 네이버클라우드캠프 서포터즈 해단식'이 진행되었습니다. 서포터즈 분들은 지난 3개월간 엄청난 열정과 솜씨로 네이버클라우드캠프 소식들을 콘텐...

이 전망은 삼성SDS 마케팅팀 MI그룹에서 2024년 말에 400여 명의 국내 IT 의사결정 관계자를 대상으로 실시한 설문 결과로서, 2025년도에 직면할 국내기업의 경영 환경과 IT 투자 전망 중 유통/리테일 산업을 집중 분석하였습니다.

이 글에서는 리눅스 커널 기능인 Control Groups(이하 cgroups)에 대해서 간단히 알아보고, Kubernetes(이하 k8s)가 cgroups를 어떻게 사용하는지 살펴보겠습니다. Kubernetes와 cgroups 간의 관계를 이해하는 데 도움이 되기를 바랍니다. cgroups란 cgroups는 시스템에서 실행되는 여러 프로세스를 그룹으로 묶고, 각 그룹이 사용할 수 있는 CPU, 메모리, I/O, 네트워크 등의 자원 사용을 제한하고 격리하는 리눅스 커널 기능입니다. 이 글에서는 여러 자원 중 k8s와 관련이 깊은 CPU와 메모리 자원에 대해 살펴보겠습니다. 출처: How I Used CGroups to Manage System Resources 리눅스에서 cgroups를 사용하는 방법에는 여러 가지가 있지만 여기에서는 간단한 cgroupfs를 통해서 진행해 보겠습니다.(이 글에서는 cgroups v1을 이용합니다.) 셸에서 mount 명령어를 실행하면 다음과 같이 cgroups를 사용하기 위한 가상의 파일 시스템이 있는 것을 볼 수 있습니다. 디렉터리를 만들거나 파일 내용을 수정하는 것으로 cgroups의 기능을 사용할 수 있습니다. $ mount ... cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) ... /sys/fs/cgroup 하위 디렉터리를 보면 다음과 같이 다양한 자원을 볼 수 있습니다. 이 글에서는 이 중에서 cpu,cpuacct와 memory 디렉터리만을 사용하겠습니다. $ ll /sys/fs/cgroup dr-xr-xr-x 6 root root 0 6월 19 15:11 blkio lrwxrwxrwx 1 root root 11 6월 19 15:11 cpu -> cpu,cpuacct dr-xr-xr-x 6 root root 0 6월 19 15:11 cpu,cpuacct lrwxrwxrwx 1 root root 11 6월 19 15:11 cpuacct -> cpu,cpuacct dr-xr-xr-x 3 root root 0 6월 19 15:11 cpuset dr-xr-xr-x 6 root root 0 6월 19 15:11 devices dr-xr-xr-x 3 root root 0 6월 19 15:11 freezer dr-xr-xr-x 3 root root 0 6월 19 15:11 hugetlb dr-xr-xr-x 6 root root 0 6월 19 15:11 memory lrwxrwxrwx 1 root root 16 6월 19 15:11 net_cls -> net_cls,net_prio dr-xr-xr-x 3 root root 0 6월 19 15:11 net_cls,net_prio … 메모리 설정 우선 간단히 설정할 수 있는 메모리부터 알아보겠습니다. /sys/fs/cgroup/memory 하위에 test1 디렉터리를 만들었는데요, 이것만으로 하나의 cgroup이 만들어집니다. 디렉터리 안의 내용을 보면 여러 설정값이 있습니다. $ sudo mkdir /sys/fs/cgroup/memory/test1 $ ll /sys/fs/cgroup/memory/test1 … -rw-r--r-- 1 root root 0 8월 6 15:23 cgroup.clone_children --w--w--w- 1 root root 0 8월 6 15:23 cgroup.event_control -rw-r--r-- 1 root root 0 8월 6 15:23 cgroup.procs -rw-r--r-- 1 root root 0 8월 6 15:23 memory.failcnt --w------- 1 root root 0 8월 6 15:23 memory.force_empty -rw-r--r-- 1 root root 0 8월 6 15:23 memory.kmem.failcnt -rw-r--r-- 1 root root 0 8월 6 15:23 memory.kmem.limit_in_bytes -rw-r--r-- 1 root root 0 8월 6 15:23 memory.kmem.max_usage_in_bytes -r--r--r-- 1 root root 0 8월 6 15:23 memory.kmem.slabinfo -rw-r--r-- 1 root root 0 8월 6 15:23 memory.kmem.tcp.failcnt -rw-r--r-- 1 root root 0 8월 6 15:23 memory.kmem.tcp.limit_in_bytes -rw-r--r-- 1 root root 0 8월 6 15:23 memory.kmem.tcp.max_usage_in_bytes -r--r--r-- 1 root root 0 8월 6 15:23 memory.kmem.tcp.usage_in_bytes -r--r--r-- 1 root root 0 8월 6 15:23 memory.kmem.usage_in_bytes -rw-r--r-- 1 root root 0 8월 6 15:23 memory.limit_in_bytes -rw-r--r-- 1 root root 0 8월 6 15:23 memory.max_usage_in_bytes -rw-r--r-- 1 root root 0 8월 6 15:23 memory.memsw.failcnt ... 이 중에서 k8s와 관련된 값은 다음 3가지입니다. memory.limit_in_bytes: 프로세스의 메모리 사용량이 이 값을 초과하면 시스템이 해당 프로세스의 작업을 중단시키거나 오류 발생(기본값은 uint64 max) memory.soft_limit_in_bytes: 프로세스의 메모리 사용량이 이 값을 일시적으로 초과하는 것은 허용, 지속적인 초과는 금지(기본값은 uint64 max) tasks: cgroup에 속한 프로세스 ID(기본값은 없음) 위 설정값을 변경하면서 어떻게 동작하는지 실험해보겠습니다. 우선 100MB의 메모리를 차지하는 프로세스를 백그라운드로 하나 생성합니다. $ stress --vm 1 --vm-bytes 100M & 이제 memory.limit_in_bytes 값을 1MB로 설정하고, tasks에는 이 프로세스의 ID를 써보겠습니다. 파일 내용을 수정하면 cgroup 설정이 변경되므로 매우 편리합니다. OOM이 발생하여 프로세스가 종료되는 것을 볼 수 있습니다. memory.limit_in_bytes 값을 초과하는 프로세스는 바로 중단되기 때문입니다. $ echo 1048576 | sudo tee memory.limit_in_bytes $ echo {PROCESS ID} | sudo tee tasks $ stress: FAIL: [42715] (415) <-- worker 42716 got signal 9 stress: WARN: [42715] (417) now reaping child worker processes stress: FAIL: [42715] (451) failed run completed in 15s [1]+ Exit 1 stress --vm 1 --vm-bytes 100M 그렇다면 k8s에서 메모리 설정은 cgroup 설정과 어떤 관련이 있을까요? 실험을 위해 간단한 Pod를 하나 실행해 보겠습니다. apiVersion: v1 kind: Pod ... resources: requests: memory: "512Mi" limits: memory: "768Mi" k8s는 위 Pod를 위해서 아래 위치에 cgroup 하나를 생성합니다.(위치는 k8s 버전에 따라 다를 수 있습니다.) /sys/fs/cgroup/memory/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podbea85cd8_f91e_45e8_8570_505487b16d77.slice/crio-d8bad6a478b6b509661a9ad2c76d189b0659c75eb2ee5ca5ba93fe87ab093b65.scope/container 위 디렉터리로 이동해서 메모리 관련 croup 설정이 어떻게 변경되었는지 살펴보겠습니다. memory.limit_in_bytes의 값은 limits.memory에 설정된 768Mi입니다. limits 값을 초과하면 Pod이 종료되어야 한다는 것을 생각해보면 당연합니다. $ cat memory.limit_in_bytes 805306368 <- 768Mi 그렇다면 memory.soft_limit_in_bytes 값은 어떻게 설정되었을까요? limits.requests에 설정된 512Mi로 예상하셨겠지만 의외로 기본값인 uint64 max가 들어 있습니다. docker는 --memory-reservation 옵션으로 memory.soft_limit_in_bytes 값을 설정할 수 있지만, k8s는 이를 cgroup 설정에 사용하지 않고 Pod 스케쥴링 시에만 참고한다고 합니다. $ cat memory.soft_limit_in_bytes 9223372036854771712 <- (uint64 max) CPU 설정 다음으로 CPU 설정 테스트를 위해 /sys/fs/cpu,cpuacct 하위에 test2 디렉터리를 만들어서 또 다른 cgroup을 만들어 보겠습니다. $ sudo mkdir /sys/fs/cpu,cpuacct/test2 $ ll /sys/fs/cpu,cpuacct/test2 -rw-r--r-- 1 root root 0 7월 4 18:38 cgroup.clone_children -rw-r--r-- 1 root root 0 7월 4 18:38 cgroup.procs -rw-r--r-- 1 root root 0 7월 4 18:38 cpu.cfs_period_us -rw-r--r-- 1 root root 0 7월 4 18:38 cpu.cfs_quota_us -rw-r--r-- 1 root root 0 7월 4 18:38 cpu.rt_period_us -rw-r--r-- 1 root root 0 7월 4 18:38 cpu.rt_runtime_us -rw-r--r-- 1 root root 0 7월 4 18:38 cpu.shares -r--r--r-- 1 root root 0 7월 4 18:38 cpu.stat -r--r--r-- 1 root root 0 7월 4 18:38 cpuacct.stat -rw-r--r-- 1 root root 0 7월 4 18:38 cpuacct.usage -r--r--r-- 1 root root 0 7월 4 18:38 cpuacct.usage_all -r--r--r-- 1 root root 0 7월 4 18:38 cpuacct.usage_percpu -r--r--r-- 1 root root 0 7월 4 18:38 cpuacct.usage_percpu_sys -r--r--r-- 1 root root 0 7월 4 18:38 cpuacct.usage_percpu_user -r--r--r-- 1 root root 0 7월 4 18:38 cpuacct.usage_sys -r--r--r-- 1 root root 0 7월 4 18:38 cpuacct.usage_user -rw-r--r-- 1 root root 0 7월 4 18:38 notify_on_release -rw-r--r-- 1 root root 0 7월 4 18:38 tasks 이번에도 많은 설정이 보이지만 이중에서 k8s와 관련된 4가지 값만 알아보겠습니다. cpu.cfs_period_us: CPU 자원에 대한 액세스를 재할당하는 주기(기본값 100000 = 0.1초) cpu.cfs_quota_us: 할당된 CPU 사용 시간(기본값 -1). 할당된 CPU 사용 시간을 모두 사용한 경우 나머지 시간 동안 CPU 사용이 제한됨(CPU 스로틀링). cpu.shares: 다른 group에 비해 상대적인 CPU 사용량(기본값 1024) tasks: cgroup에 속한 프로세스 ID(기본값은 없음) cpu.cfs_period_us에 설정된 시간 안에는 cpu.cfs_quota_us에 설정된 시간 동안만 CPU 자원을 제한 없이 사용할 수 있고 나머지 시간에는 CPU 사용량이 제한됩니다. 예를 들어 cpu.cfs_period_us가 100000(100ms)이고 cpu.cfs_quota_us가 50000(50ms)이면, 100ms 중 50ms 동안은 CPU 자원을 제한 없이 쓸 수 있고 나머지 50ms 동안은 절반의 CPU 자원만 쓸 수 있습니다. 이 설정이 잘 적용되는지 테스트해 보겠습니다. 테스트에 사용한 장비는 4코어입니다. 메모리 테스트에서 사용한 stress 프로그램으로 4코어 장비에서 4개 코어를 모두 쓰도록 프로세스를 4개 실행했습니다. 4개 코어 모두 100% 사용되는 것을 볼 수 있습니다. 이 상태에서 프로세스 하나만 100000μs(100ms) 중 50000μs(50ms) 동안만 CPU를 쓸 수 있도록 변경해 보겠습니다. $ echo 100000 | sudo tee cpu.cfs_period_us $ echo 50000 | sudo tee cpu.cfs_quota_us $ echo {SECOND PROCESS ID} | sudo tee tasks 2번째 프로세스가 CPU 자원을 절반만 사용하는 것을 볼 수 있습니다. CPU 관련 설정은 하나 더 있습니다. cpu.shares는 cgroup 간의 상대적인 CPU 사용량을 나타냅니다. 예를 들어 cgroup이 4개 있는데 모두 cpu.shares 값이 1024라면 각 cgroup은 CPU 자원을 1/4씩 사용합니다. 1024/(1024+1024+1024+1024) = 25% 만약 다음 그림처럼 특정 cgroup의 cpu.shares 값을 1536으로 증가시키면 해당 cgroup은 1536/(1536+512+1024+1024) = 37.5%의 CPU 자원을 사용할 수 있습니다. 다시 실험을 해보겠습니다. 4코어 장비에 cgroup을 2개 만들고 각 cgroup마다 4개의 프로세스를 실행해서 전체 CPU 자원을 다 소모할 정도로 부하를 준 다음 다음과 같이 설정을 변경했습니다.(cpu.cfs_period_us와 cpu.cfs_quota_us는 기본값인 100000과 -1 사용) $ echo 1024 | sudo tee cpu.shares $ echo {FOUR PROCESS IDS} | sudo tee tasks $ echo 512 | sudo tee cpu.shares $ echo {OTHER FOUR PROCESS IDS} | sudo tee tasks CPU 사용률이 1024/(512+1024) = 66.6%와 512/(512+1024) = 33.3%로 나뉘는 것을 볼 수 있습니다. 그렇다면 CPU와 관련된 cgroup 설정은 k8s에서 어떻게 적용될까요? Pod을 실행해서 cgroup 설정을 비교해 보겠습니다. cpu.cfs_period_us의 k8s 기본값은 100000(100ms)이고, Pod manifest로는 이 값을 변경할 수 없습니다. cpu.cfs_quota_us 값은 limits.cpu 값으로 결정됩니다. 예를 들어 limits.cpu 값을 "4000m"로 설정하면 최대 4코어의 CPU 자원을 사용할 수 있으며 cpu.cfs_quota_us 값은 400000(400ms)이 됩니다. 만약 limits.cpu를 설정하지 않으면 cpu.cfs_quota_us는 -1이 됩니다. 이는 제한이 없다는 의미입니다. cpu.shares 값은 requests.cpu 밀리코어 값을 1000으로 나누고 1024를 곱한 값입니다. 예를 들어 requests.cpu를 "2000m"로 설정하면 cpu.shares 값은 2000/1000*1024=2048이 됩니다. apiVersion: v1 kind: Pod ... resources: requests: cpu: ”2000m" <-- cpu.shares 2048 limits: cpu: ”4000m" <-- cpu.cfs_period_us 100000 (k8s 기본값) cpu.cfs_quota_us 400000 (만약 4코어 장비라면 -1로 설정한것과 같음) 이 밖에도 CPU의 특정 코어만 독점해서 쓸 수 있는 cpuset 기능도 있지만 이 글에서는 생략하겠습니다. 관심 있는 분은 아래 문서를 참고해 주세요. CPUSETS Kubernetes v1.31: New Kubernetes CPUManager Static Policy: Distribute CPUs Across Cores 마치며 k8s가 cgroups를 어떻게 사용하는지 간단히 알아보았습니다. 끝으로 짧은 k8s 운영상의 경험을 말씀드리면서 글을 마무리하고자 합니다. requests.memory 값은 limits.memory 값과 같게 설정합니다. 두 값을 다르게 한다고 자원을 아껴 쓸 수 있는 것은 아닙니다. API 서버처럼 latency가 중요한 경우 CPU 사용량 제한 때문에 응답 시간이 늦어지면 안 되므로 limits.cpu 값을 설정하지 않습니다. 이렇게 해도 request.cpu(cpu.shares) 비율대로 Pod 간 CPU 자원이 배분되므로 다른 프로세스의 자원을 과도하게 빼앗지는 않습니다.

안녕하세요, 누구나 쉽게 시작하는 클라우드 네이버클라우드 ncloud.com입니다. 오직 네이버클라우드에서만 제조 솔루션사 통합 지원 프로그램 네이버클라우드는 제조 DX에 앞장서는 제조 솔루션사가 클라우드와 AI로 급변하는 기술 트렌드 속에서 경쟁력을 갖출 수 있게 돕습니다. 지금 바로 프로그램 지원하고 클라우드 사업 구조 안착 지원, 비용 절감 + ...

AWS Parallel Cluster를 생성해 보도록 하겠습니다. The post AWS Parallel Cluster 생성 appeared first on NDS Cloud Tech Blog.

이 블로그에서는 AWS Systems Manager의 주요 기능과 그 활용 방안을 단계별로 살펴보겠습니다. The post AWS Systems Manager란? appeared first on NDS Cloud Tech Blog.

흔히 사용되는 AWS 제품 중 EC2, RDS, Fargate, Lambda의 비용을 줄이는 방법에 대해 알아보겠습니다. The post Reserved Instance & Savings Plan appeared first on NDS Cloud Tech Blog.