기술 블로그 모음

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.

Helm은 Kubernetes 클러스터에서 애플리케이션을 설치하고 관리하는 데 사용되는 패키지 관리자입니다. The post EKS에서 Helm 사용하기 appeared first on NDS Cloud Tech Blog.

AWS Blue/Green 배포의 개념과 장점, 절차에 대해 자세히 알아보겠습니다. The post Amazon RDS Blue/Green 배포란? appeared first on NDS Cloud Tech Blog.

이번 글에서는 AWS CLI의 프로파일 설정과 활용법을 실습과 함께 자세히 알아보고, 효율적인 사용을 위한 팁을 공유하겠습니다. The post AWS CLI 프로파일(Profile) 설정 및 활용법 appeared first on NDS Cloud Tech Blog.

AWS ECS를 통해 고양이&강아지 사진이 랜덤으로 뜨는 웹 애플리케이션을 배포해보는 실습입니다. The post AWS ECS로 웹 애플리케이션 배포하기 appeared first on NDS Cloud Tech Blog.

이번 블로그에서는 AWS Direct Connect의 개념, 구성 요소, 작동 방식, 주요 활용 사례를 알아보겠습니다. The post AWS Direct Connect(DX): 클라우드와 온프레미스를 연결하는 최적의 네트워크 솔루션 appeared first on NDS Cloud Tech Blog.

AWS Shield는 DDoS 방어와 고급 보안을 제공하며, AWS WAF 및 Firewall Manager로 웹 애플리케이션 보호와 정책 관리를 지원합니다. The post AWS Shield란? appeared first on NDS Cloud Tech Blog.