[카테고리:] Cloud & Infra

Based on the diagram below, this is a reference architecture for running an e-commerce service on the public cloud without Kubernetes. The goals are fourfold: high availability, low latency, strong security, and cost optimization—especially under burst traffic (e.g., flash sales). The examples assume AWS. 1) High-Level Overview Network Traffic Entry Application Security & Observability Endpoints…

아래 다이어그램을 기준으로, 쿠버네티스 없이 운영하는 e-커머스 public cloud 레퍼런스를 정리했다. 목표는 네 가지다: 가용성, 빠른 응답, 철저한 보안, 비용 최적화(특히 버스트 트래픽). AWS 기준으로 설명한 부분이니 참고 바란다. 1) 전체 구조 개요 2) 요청 흐름(두 갈래) 2-1. 정적/캐시 가능 콘텐츠 Client → CloudFront(+WAF) → S3(정적) | ALB(동적 캐시 가능 경로) 2-2. 동적/이벤트성 경로 3)…

MySQL 8.0 introduces major internal architecture changes — including a new data dictionary, redesigned redo/undo logging, and transactional DDL — that make it incompatible with legacy backup tools.In other words: This post explains how to build a non-disruptive (Hot) physical backup system for MySQL 8.0 using Percona XtraBackup 8.x, covering installation, permissions, scripting, log rotation,…

MySQL 8.0은 내부 구조(redo/undo, data dictionary, transactional DDL 등)가 5.7과 완전히 달라졌다.따라서 예전처럼 XtraBackup 2.4로는 백업이 불가능하다.MySQL 8.0 → XtraBackup 8.x,MySQL 5.7 이하 → XtraBackup 2.4.x이 조합만이 호환된다. 이 글은 MySQL 8.0 환경에서 **Percona XtraBackup 8.x(PXB 8.x)**을 이용한 무중단(Hot) 물리 백업을 구축하는 전 과정을 다룬다.설치, 계정 권한, 스크립트, 로그 회전, 크론 스케줄링, 복구, 검증까지 모두…

pacemaker vs galera : Following up on my earlier post about Pacemaker, I wanted to complement that discussion with a more practical comparison against Galera.If you’re worried about data consistency issues during failover, this guide should help you decide which approach suits your environment. Summary 1) Problem Definition The “best” HA approach depends on: Read-heavy…

pacemaker vs galera : 내부망(MySQL) 고가용성, 무엇을 선택할까이전에 썼던 pacemaker 관련 글에 이어 보완적인 글을 써볼까 한다.특히, failover 가 일어날 경우 정합성 이슈에 대한 보완을 할려고 하는 분들은이 글을 참조했으면 한다. 요약 1) 문제 정의 최적의 HA 방식은 서비스 특성(읽기/쓰기 비중, DDL 빈도), RPO/RTO 목표, 네트워크/보안 제약(ICMP/방화벽), 노드 수·예산, 운영 인력에 의해 갈린다. 2) Pacemaker…

When deploying AWS ECS (Fargate or EC2) in a private subnet, you don’t necessarily need an Internet Gateway or NAT Gateway to access services like ECR, ECS, or CloudWatch Logs. The key is to configure VPC Endpoints so that ECS tasks can securely connect to the required AWS services over a private network. Architecture Overview…

AWS ECS(Fargate/EC2)를 Private Subnet에 배치할 때는 인터넷 게이트웨이와 NAT Gateway 없이도 ECR/ECS/CloudWatch Logs와 통신할 수 있다. 이때 핵심은 VPC Endpoint 구성을 통해 필요한 AWS 서비스에 Private 네트워크로 접근하는 것이다. 아키텍처 시나리오 ECS 배포 준비 1. 애플리케이션 도커라이징 2. ECR 생성 ALB 생성 Task Definition 작성 VPC Endpoint 구성 ECS를 Private Subnet에서 실행할 경우, 최소 4개의…

Knowing who is logging into your EC2 servers via SSH is a critical security concern. Beyond simple monitoring, sending login success and failure events directly to Slack allows you to quickly react to any suspicious activity. In this post, we’ll walk through how to set up alerts using CloudWatch Logs → Subscription Filter → Lambda…

운영 중인 EC2 서버에서 누가 SSH로 접속하는지는 중요한 보안 이벤트다. 단순 모니터링을 넘어서, 로그인 성공/실패 내역을 Slack으로 바로 받아보면 이상 징후에 빠르게 대응할 수 있다. 이번 글에서는 CloudWatch Logs → Subscription Filter → Lambda → Slack Webhook 흐름으로 알림을 구성하는 방법을 정리한다. 1. CloudWatch Agent 설치 및 로그 수집 우선 EC2의 SSH 로그를 CloudWatch Logs로…