Category: Learning Levels

“재해 상황에서 모든 서버를 같은 방식으로 복구해야 할까요?” 재해복구(DR, Disaster Recovery)는 시스템 장애나 재해 상황에서 서비스를 복구하기 위한 체계입니다. 백업을 확보하고 복제를 구성하는 것까지는 비교적 명확한 작업에 해당합니다. 일반적으로 재해복구의 목표는 모든 시스템을 장애 이전 상태로 되돌리는 것으로 설정됩니다. 다만 모든 시스템에 동일한 복구 수준을 적용하려면 그만큼의 자원과 운영 부담이 따릅니다. 복구 시간을 짧게 잡을수록 […]

발전소에는 목적이 다른 시스템과 문서가 함께 존재합니다. 원격 진동 고장진단 시스템(Remote Vibration Monitoring System, RVMS)은 회전설비의 베어링 진동을 상시 감시하고 임계치 초과를 알려 줍니다. 운전 매뉴얼과 로직 도면에는 조치 절차와 설비 관계가 기록되어 있습니다. 하지만 경보가 발생한 뒤 원인 후보를 좁히고, 여러 지표를 비교하고, 필요한 근거를 찾아 조치 순서를 정하는 일은 여전히 전문가의 경험에 의존합니다. […]

이 글은 2026년 4월 1일 AWS DevOps & Developer Productivity 블로그에 게시된 Securely connect AWS DevOps Agent to private services in your VPCs(Alexandra Huides, Jordan Merrick, Mohak Kohli, Tipu Qureshi 공저)를 한국어로 번역∙편집한 글입니다. 원문 게시 이후 서비스가 업데이트됨에 따라, 콘솔 화면 구성·연결 상태값·DNS 해석 옵션 등은 현행 AWS DevOps Agent 사용자 가이드 기준으로 갱신했습니다. […]

EKS 노드에 파드(Pod)를 더 밀도 있게 채워서 컴퓨트 비용을 줄이고 싶은데, 스케줄러 설정에는 손댈 방법이 없어 아쉬웠던 적이 있으신가요? 대규모 이벤트로 트래픽이 많아지는 순간 오토스케일링이 조금 더 빨리 반응해 주기를 바랐던 경험은 어떠신가요? 지금까지 Amazon EKS에서 이런 요구를 해결하기가 쉽지 않았습니다. kube-scheduler와 kube-apiserver 같은 컴포넌트의 구성이 EKS 컨트롤 플레인 고유의 영역이었기 때문입니다. 2026년 8월 12일, […]

이 글은 AWS Database Blog에 게시된 Running pgvector in production on Amazon Aurora PostgreSQL by Stefan Aichholzer 을 한국어 번역 및 편집하였습니다. Amazon Aurora PostgreSQL-Compatible Edition에서 pgvector를 실행하면 이미 익숙한 데이터베이스 위에 프로덕션 수준의 벡터 스토어를 구축할 수 있으며, Amazon Aurora의 운영 도구, 고가용성, 확장 기능이 이를 뒷받침합니다. 이러한 조합 덕분에 pgvector는 개념 증명(PoC)에서 서비스 […]

들어가며 아임웹의 서비스 진입 경로는 AWS 계정과 VPC, 클러스터에 걸쳐 확장되어 왔습니다. 그 과정에서 로드밸런서 계층의 한도에 부딪혔는데, 상향 신청으로 해결되는 한도도 있었지만, ECS 서비스당 Target Group 5개 제한처럼 상향 대상이 아닌 것도 섞여 있었습니다. 이를 계기로 마이크로 프론트엔드(Micro-Frontends, MFE) 서빙 경로를 대상으로 서비스 네트워크를 재설계했습니다. 재설계의 골자는 외부 진입점(North-South)과 서비스 간 연결(East-West)의 분리입니다. 기존 […]

Bedrock Mantle 기반 GPT‑5.6 연동부터 cached Web Search, AWS PrivateLink 전용망, 관측성과 비용 운영까지 생성형 AI 코딩 에이전트를 엔터프라이즈 기업 환경에 도입할 때는 모델 성능만큼 인증, 데이터 경로, 네트워크 격리, 비용 배분과 감사 가능성이 중요합니다. Codex는 이제 ChatGPT 데스크톱 앱의 Codex 보기, Codex CLI, IDE 확장, Codex SDK와 codex exec 같은 로컬 워크플로에서 Amazon Bedrock을 […]

실리콘투는 한국의 뷰티 브랜드를 전 세계 고객에게 유통하는 글로벌 플랫폼 기업입니다. 수많은 브랜드와 상품, 국가별 물류가 실시간으로 맞물려 돌아가고, 이 방대한 흐름을 CMS, WMS, OMS를 비롯한 여러 사내 시스템이 나눠 맡습니다. 사업이 커질수록 업무 규칙도 함께 불어났고, 그 규칙은 저장 프로시저(SP, Stored Procedure. 데이터베이스에 넣어 두고 불러 쓰는 SQL 로직 묶음), 소스 코드, 그리고 여기저기 […]

들어가며 아임웹은 2026년 7월 10일 새벽, Amazon ElastiCache 기반 운영 캐시들을 Redis 6.x/Valkey 7.2 에서 Valkey 9.1로 업그레이드했습니다. 대표 범용 캐시는 SSR(Server-Side Rendering) 경로와 여러 서비스 로직에서 반복적으로 조회되는 캐시로, 비교 구간 3.5시간 동안 7억 건 이상의 명령어를 처리했습니다. 업그레이드 이후 전날 동일 시간대 대비 전체 CPU는 86.6%, Engine CPU는 31.6%, GET latency는 30.5%, SET latency는 53.6% 감소했습니다. 명령 수 차이를 보정한 Engine CPU / 1M commands도 27.4% 낮아져, 단순 트래픽 차이가 아니라 엔진 효율 개선을 운영 메트릭으로 확인할 수 있었습니다. 이 글에서는 아임웹이 왜 캐시 엔진 효율을 중요하게 여겼는지, Valkey 9.1 업그레이드 전 어떻게 캐시 전반을 점검했는지, 그리고 실제 운영 메트릭에서 어떤 변화가 나타났는지 공유합니다. 아임웹 소개 아임웹은 누구나 쉽게 브랜드 웹사이트와 쇼핑몰을 […]

해당 포스트는 당근의 최용환님, 조승환님, 오현준님과 함께 작성했으며, AWS Summit Seoul 2026에서 발표한 세션 내용을 기반으로 합니다. 이 시리즈의 1부에서는 서명키 보안의 중요성과 당근이 하이브리드 전략을 선택한 과정을, 2부에서는 CloudHSM 아키텍처와 다계층 접근 제어 전략을 다루었습니다. 이번 마지막 글에서는 이 인프라 위에서 서명 시스템을 어떻게 구현했는지, PKCS#11 기반 시스템 운영에서 겪은 트러블슈팅, 그리고 수천만 개의 […]