기술 블로그 모음

Istio 를 통한 JWT Claim 기반 라우팅 구현 Istio 와 같은 Service Mesh를 활용하면 JWT Claim을 손쉽게 검증하고 이를 기반으로 동적 라우팅을 구현할 수 있습니다. JWT Claim 기반 라우팅은 사용자의 정보와 권한을 바탕으로 요청을 세분화하고, 맞춤형 트래픽 분배를 가능하게 하는 효과적인 방법입니다. 해당 포스트에서는...

GitHub Action 을 통해 NGINX 로드 밸런서 배포 자동화 구현 이 블로그 포스트는 GitHub Action을 사용하여 NGINX 로드 밸런서 설정의 자동화된 배포 프로세스를 구현하는 방법을 설명합니다. GitHub Action을 활용하여 코드 변경 시 로드 밸런서 설정이 자동으로 업데이트 되도록 구성하고, 이를 통해 효율적이고 안정적인 배...

Rook Ceph 클러스터 Kubernetes 배포 가이드 이 포스트는 Kubernetes 클러스터에 Rook Ceph 클러스터를 배포하여 워커 노드의 스토리지를 통해 Ceph의 분산 스토리지 시스템을 구성하는 방법을 설명합니다. Rook은 Ceph를 Kubernetes에서 네이티브하게 실행할 수 있도록 지원하며, 이를 통해 블록, 파일, 오브젝트 스...

k8s – Multi Master Node 구성 (고가용성) Kubernetes 클러스터는 단일 마스터 노드로 운영될 경우 장애 발생 시 클러스터 전체가 정상적으로 동작하지 않을 위험이 있습니다. 이를 방지하기 위해 Multi Master Node 구성을 활용하면 클러스터의 안정성과 가용성을 향상시킬 수 있습니다. 본 문서에서는 Multi ...

K9s – Kubernetes Cluster Manager K9s 는 Kubernetes 클러스터 관리의 효율성을 극대화하기 위해 설계된 강력한 CLI 도구입니다. YAML 파일을 작성하거나 복잡한 kubectl 명령어를 기억하지 않고도 직관적인 Terminal UI에서 Kubernetes 리소스를 손쉽게 관리하고 모니터링할 수 있습니다. ...

클라우드 스토리지 유형과 특징, 활용 방안 이 포스트는 클라우드에서 주로 제공하는 세 가지 주요 스토리지 유형인 오브젝트 스토리지, 파일 스토리지, 블록 스토리지의 특징과, 각각의 스토리지를 어떤 상황에서 활용하는 것이 적합한지 설명합니다. 이러한 스토리지는 클라우드뿐만 아니라 온프레미스 환경에서도 활용할 수 있으며, 요구사항에 따라 적절한 방식으로 ...

1월 30일부터 Amazon Bedrock Marketplace와 Amazon Bedrock 사용자 지정 모델 가져오기를 통해 DeepSeek-R1 모델을 Amazon Bedrock에서 사용할 수 있게 되었습니다. 그 이후로 수천 명의 고객이 Amazon Bedrock에 이 모델을 배포했습니다. 고객들은 안전한 AI 배포를 위한 견고한 가드레일과 포괄...

북반구의 날씨가 점차 따뜻해짐에 따라, 학습 및 교류의 기회가 더욱 많아지고 있습니다. 이번 주에 샌프란시스코에 머물 예정이며, AWS GenAI Loft에서 열리는 Nova Networking Night에서 만나 라이브 데모와 실제 구현을 통해 Amazon Nova 파운데이션 모델(FM)의 세계를 자세히 살펴보겠습니다. AWS Pi Day는 이제 연...

안녕하세요. 누구나 쉽게 시작하는 클라우드 네이버클라우드 ncloud.com 입니다. 이번 포스팅에서는 네이버 클라우드 플랫폼을 활용해 공공시장 진출 시 필수인 CSAP 보안인증 요건을 해결하는 '디딤365'를 소개해 드리려고 해요! 디딤365는 네이버클라우드의 파트너사로, 공공기관과 비즈니스를 위한 디지털 전환을 지원하고, 컨설팅하고 있습니다. 디딤...

Istio Traffic Management: 모범 사례 살펴보기 이 블로그 포스트는 Istio 를 사용하며 네트워킹 또는 트래픽 관리 문제를 방지하기 위한 특정 배포 또는 구성 지침을 제공합니다. 목차 1. 서비스의 기본 경로 설정2. 네임스페이스 간 구성 공유 제어3. 네임스페이스 간 Istio Destination Rule 적용 문제4. Isti...

2016년부터 게임 개발자들은 단일 게임에서 1억 명의 동시 사용자(CCU)를 지원할 수 있는 확장 가능한 전용 서버 호스팅을 통해 게임을 지원하는 Amazon GameLift를 사용해 왔습니다. 게임 서버 이외의 추가 관리형 컴퓨팅 기능에 대한 고객 요청에 부응하여 게임 퍼블리셔가 글로벌 플레이어와 직접 연결되는 게임 스트리밍 경험을 구축하고 제공할...

안녕하세요, 누구나 쉽게 시작하는 클라우드 네이버클라우드 ncloud.com입니다. 돈과 개인정보를 다루는 만큼 금융∙핀테크 업계는 보안이 정말 중요한데요. 그렇기 때문에 금융∙핀테크 기업이 혁신적인 서비스를 개발하기 위해선 믿을 수 있는 안전한 클라우드 환경이 꼭 필요합니다. 하지만 중소 핀테크 기업이 보안 요건이 충족된 클라우드 인프라를 구축하는 ...

Helm – Kubernetes 패키지 매니저 이 포스트는 Kubernetes의 패키지 매니저와 같은 역할을 하는 Helm 이 무엇인지 알아보고, Helm의 기능과 구성 요소 및 설치 방법과 기본적으로 사용되는 명령어에 관해 설명합니다. 목차 1. Helm이란?2. Helm 주요 기능3. Helm 구성 요소4. Helm 설치 방법5. Hel...

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

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

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

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

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

시작하며 안녕하세요. 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...

이 글에서는 리눅스 커널 기능인 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 자원이 배분되므로 다른 프로세스의 자원을 과도하게 빼앗지는 않습니다.

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.

Helm은 Kubernetes 클러스터에서 애플리케이션을 설치하고 관리하는 데 사용되는 패키지 관리자입니다. The post EKS에서 Helm 사용하기 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 Shield는 DDoS 방어와 고급 보안을 제공하며, AWS WAF 및 Firewall Manager로 웹 애플리케이션 보호와 정책 관리를 지원합니다. The post AWS Shield란? appeared first on NDS Cloud Tech Blog.

클라우드 환경에서 비용을 절감하기 위한 EC2 스케줄링 방법을 살펴보겠습니다. The post AWS EC2 중지/시작 자동화: 사람도 퇴근, 서버도 퇴근! 태그 기반 EC2 스케줄링 appeared first on NDS Cloud Tech Blog.

1. 들어가며 안녕하세요. 쏘카 데이터엔지니어링팀 삐약, 루디입니다. 내용을 시작하기에 앞서, 저희 팀의 업무와 역할에 대해 간략히 소개해 드리겠습니다. 데이터엔지니어링팀은 신뢰할 수 있는 데이터를 쏘카 구성원들이 안정적으로 활용할 수 있도록 기반을 마련하고, 이를 실제 비즈니스에 적용할 수 있는 서비스를 개발하며 환경을 구축하고 있습니다. 데이터 마...

시작하며 안녕하세요. SRE(site reliability engineering, 사이트 안정성 엔지니어링) 업무를 맡고 있는 Enablement Engineering 팀 어다희,...