What2Do

On-premise to Cloud Migration 이해하기

무엇을해야하는지 — Fri, 27 Jun 2025 21:53:55 +0900

서론

얼마전 회사에서 서버 이전 작업을 맡게 되었다. 데이터 센터에 있는 서버를 Cloud로 Migration하는 작업을 처음으로 진행하게 되었는데, 정말 복잡했다. 데이터를 이전하는 작업은 어렵지 않았지만, 네트워크 부분을 처리하는 단계가 이해가 잘 되지 않았다. 이에 오늘은 서버를 Migration하면서 주의해야하는 점에 대해 공부를 해보았다.

1. DNS 설정 변경

서버를 이전하면 당연히 처음 생각나는 부분은 IP가 변경된다는 것이다. 특히 회사에서는 sandomain을 직접 운영해서 호스팅을 하고 있었기 때문에 기존 Domain에서 IP를 변경해야하는데 어떤 부분을 변경해야하는지가 중요했다.

DNS 구조

먼저 DNS는 아래 사진 처럼 계층 구조로 이루어져 있다. 최상위에 Root 도메인이 있고, 그다음으로 TLD와 서브 도메인으로 이어진다.

DNS Zone이란 무엇인가?

DNS(Domain Name System) 내에서 특정 도메인 이름 공간을 관리할 수 있는 단위를 말한다. 쉽게 말해서, 도메인과 그 하위 도메인들의 설정을 저장하는 공간이다.

그렇다면 어떤 것들이 DNS Zone에 저장이 되어있는지 알아야한다. 이는 기본적인 CS 지식이지만 한번 더 복기해보자면 아래와 같다.

A	도메인을 IP 주소로 매핑
MX	메일 서버 정보
CNAME	도메인 별칭 (alias) 설정
NS	이 Zone을 관리하는 네임서버
SOA	Zone의 시작을 알리는 레코드

이제 본론으로 돌아와서 서버가 on premise에서 cloud으로 이전이 되어서 IP가 바뀌었다면 어떤 것들을 수정해줘야할까.

가장 먼저 A record를 바꿔주어야 한다. 당연히 바뀐 IP가 기존 도메인으로 향할 수 있어야 하기 때문에 도메인과 IP를 매핑하는 A record를 수정해주어야 한다. 또한 보통 서버가 이전이 되면 네임서버도 바뀌기 마련인데, 그런 경우에는 NS 또한 함께 변경해주어야 한다.

그렇다면, 서버가 이전되고 이 두개만 바꾸면 끝나는 것일까? 이론적으로는 A record와 NS를 변경해주면 끝나는 것은 맞지만, DNS caching을 생각하면 DNS TTL을 수정해줘야한다.

특히 서버 이전을 한다고 하더라도 여전히 해당 웹 서비스는 사용자들이 계속해서 요청을 보내고 있기 때문에 TTL 시간이 길면 누군가는 계속해서 이전 IP로 접속을 하기에 404 값을 받을 것이고, 반대로 TTL 시간이 너무 짧아 버리면 DNS 서버에 불필요하게 요청이 많이 들어가기 때문에 과부하가 걸릴 수도 있다.

때문에 TTL 같은 경우에는 기존 36000에서 90으로 수정을 해주었다. 이는 기존 사용자의 브라우저에 저장된 DNS 캐시값을 빠르게 비워줌으로써 구서버로 라우팅 되는 것을 막을 수 있다.

결론적으로 서버 이전 후, DNS Zone 파일에서 A record, NS, TTL 이 3가지를 바꿔주면서 새로운 IP가 기존 Domain으로 접속 가능하도록 설정해주었다.

2. SSL 인증서 설정 변경

서버를 이전 하면서 같이 적용해줘야하는 것이 SSL 인증서 파일이다. 여기서 SSL 인증서도 같이 넘겨주는 이유는 IP가 바뀌어서가 아니라, 말 그대로 서버가 바뀌었기 때문에 하나의 서버 자원으로써 넘겨주어야 한다는 것이다.

SSL 인증서와 IP 주소의 관계

SSL 인증서 = 특정 도메인 이름(example.com)에 대한 신뢰 보증
인증서에는 example.com, www.example.com 같은 도메인 이름이 들어있지, IP 주소는 포함되어 있지 않다.
따라서 IP가 바뀌더라도 도메인만 그대로면 기존 인증서를 이전한 서버에서 파일만 옮겨 준다면 계속 사용할 수 있다.

그렇다면 SSL 인증서 파일은 어떻게 생겼고, SSL 관련 파일을 신서버에 이전한 다음 어떻게 적용시킬 수 있을까?

CERTBOT 인증서

회사에서는 CERTBOT 인증서를 사용하여 SSL 인증서를 발급 받았다. SSL 인증서 내부를 확인해보면 아래와 같다.

CERTBOT 구성

1. example.co.kr.conf: 인증서 갱신 시 필요한 설정 저장

2. example.co.kr/: 실제 SSL 인증서와 개인 키 파일들, 웹서버에서 사용

이제 이 두가지를 tar를 활용하여 이전하려는 Cloud로 이동 시켜주면 된다. 다만, 중요한 사항은 (구)서버에서 (신)서버로 이전을 시킬 때, 바로 SFTP로 넘기는 것이 아니라, 보안을 위해서는 중간 서버를 거쳐주는 것이 좋다.(회사에서는 이를 작업서버라고 지칭 한다)

tar cf {SSL_configuration_file} example.co.kr*

Cron 작업을 통한 SSL 인증서 적용

이제 신규 서버에서는 SSL 인증서가 교체가 되었으니 이를 실제 nginx에 적용시켜줘야 한다.

이는 이제 cron 작업을 하는 스크립트를 통해 적용이 된다. (보통 5분 단위로 SSL 파일이 바뀌었는지 확인하고 적용시킨다.)

서버 이전을 하게 되면 많은 부분들을 수정해야하지만 사실 크게 보면 두가지를 이전 시켜주어야 한다.

1. 데이터(DB뿐만 아니라 이미지, 파일 등)
2. DNS, SSL과 같은 네트워크 리소스

데이터 같은 경우에는 워낙 다양한 방식이 많고, 중간에 백업 데이터만 잘 관리해주면 큰 문제 없이 옮길 수 있지만 네트워크 리소스 같은 경우에는 TTL등 신경써줘야 하는 부분들이 있기에 잘 옮겨주어야 한다.

SFTP(Secure File Transfer Protocol) 란?

무엇을해야하는지 — Sun, 15 Jun 2025 15:59:49 +0900

SFTP란?

FTP에서 보안이 추가 된 것으로 'SSH의 파일 전송 버전'이라 생각하면 편하다

SSH의 파일 전송 서버 = 22
일반적인 FTP와 다르게 PC와 서버간의 데이터 전송을 암호화 하기 때문에 해킹이나 보안상의 문제점을 방지할 수 있다.

그림 처럼, 기존 FTP는 바로 직접 파일을 올리는 것이라면, SFTP는 암호화 과정을 거쳐서 인터넷에 올라가고 서버간의 이동이 발생한다.

SFTP의 특징

1. 보안성

SSH(Secure Shell) 기반으로 동작하여, 데이터 전송 시 암호화
사용자 인증, 데이터 무결성, 전송 중 기밀성 보장.
FTP에 비해 패스워드, 명령어, 데이터 모두 암호화되어 도청 위험이 낮음.

2. 단일 연결

단일 포트(기본: 22번)를 사용하여 제어 및 데이터 전송을 처리.
FTP처럼 데이터 포트를 따로 열 필요가 없어 방화벽 친화적.

3. 속도

보안 처리를 위한 암호화/복호화 작업 때문에 FTP보다 속도가 느릴 수 있음, 하지만 보안이 중요한 환경에서는 필수 선택.

SFTP Linux 명령어

1. sftp 연결

sftp "작업서버 폴더명(hcchung)"@"대상 IP"

2. 파일 올리기/ 받기

sftp>

// 원본서버
put "파일명"

// 이전서버
get "파일명"

2025 개발자 취업준비 회고

무엇을해야하는지 — Tue, 27 May 2025 17:31:56 +0900

서론

본격적으로 취업준비를 시작한건 1월 말 부터이다. 그전까지는 학교를 다니며 잠깐 계약직으로 4개월정도 일을하다가 1월 부터 차근차근 이력서와 포트폴리오를 정리하고 2월부터는 원하는 기업에 지원을 했다.

이런식으로 3~4개월 정도 준비를 했고, 최근에 대기업은 아니지만 나름 규모가 있는 중견 기업에 클라우드 엔지니어로 최종 합격을 했다. 이 곳에서 나의 첫 사회생활과 커리어를 시작하기로 결정했고 입사까지 2주의 시간이 남아있다.

성공한 취준생이라고 보기에는 어렵겠지만, 그래도 여느 취준생과 마찬가지로 최선을 다했다고 생각하기에 그동안 어떻게 준비를 하고 어떤 목표의식을 갖고 임했는지를 정리해보고자 한다. (절대 정답은 아니고, 그저 개인적인 생각이다)

본론

1. 이력서 & 포트폴리오

취업준비를 하면서 이력서와 포트폴리오를 정말 수도 없이 고쳤다. 그저 내용을 조금씩 바꾸는 것이 아니라, 귀찮더라도 전체 틀을 완전히 갈아 엎은적도 있었고 꾸준히 개선시켜나갔다. 그리고 인터넷에 적은 돈은 아니지만 이력서와 포트폴리오를 첨삭해주는 사람들이 매우 많다. 주변에서는 "그냥 돈 낭비야, 그런거 해봤자 도움 안돼" 라는 말도 있었지만, 사실 나는 취업준비 하면서 이정도 금액 없다고 내가 죽는 것도 아니고 속는 셈 치고 해볼 수 있지 않을까라는 생각에 과감하게 컨설팅과 첨삭도 받았다. 그리고 지금 생각해보면 해당 컨설팅 이후에 서류 합격 비율이 꽤나 늘었다. 특히 내가 생각치 못한 부분(가독성, 트러블 슈팅 등)에서 보완할 점이 많다고 깨닫기도 했었다.

https://kmong.com/@horangya

프로그램 개발 전문가 horangya - 크몽

총거래 수 72건, 평점 5의 IT·프로그래밍 전문가 horangya 님을 만나보세요. 5000원부터 시작!

kmong.com

2. 지원서 제출

2-1. 지원 분야

개발자로써 지원을 할때 특정 직무 하나에 국한되어 지원하지 않았다. 예를 들어 백엔드 웹개발만 지원하는게 아니라 DevOps, Cloud Engineer 뿐만 아니라 ERP 전산직 등 내가 자신 있거나, 유사 프로젝트가 있다면 항상 포트폴리오 내용을 직무에 맞춰서 조금씩 수정해서 제출했다. 이런식으로 하다보니 자연스럽게 내가 어떤 직무에 더 강점이 있는지 알게 되었고, 개인적으로는 Cloud 직무에 더 강점이 있다는 것을 파악을 하고 난 이후, 자격증과 기술 블로그 등 클라우드 분야를 더 깊이 있게 공부를 하고 준비를 했던게 도움이 많이 되었다.

2-2. 지원 기업 기준

지원하는 기업은 개인적으로 다양한 기준을 두고 지원을 했다. 여기서 중요한 것은 그저 "대기업/중견 아니면 지원 안해"라는 것이 아닌 스타트업이더라도 내가 가서 어떤식으로 커리어를 쌓을 수 있는지, 혹은 기업의 성장 가능성을 보고 매우 다양하게 지원했다. 사실 몇년전에 취준을 하고 합격한 선배들은 "그냥 일단 대기업만 바라보고 천천히 준비하면 돼" 라는 말을 매우 많이 들었다. 그 사람들 말이 틀린 것은 결코 아니지만, 사실 현실적으로 2~3년전 개발자 취업시장과 지금의 개발자 취업시장은 매우 다르다. 특히 나는 적어도 서류 제출하고 면접을 보는 것은 기회 비용이 매우 적다고 생각한다. 어쨌든 운이 좋아서 면접까지 보게 되고 떨어지더라도 그것만으로도 취준생에게 있어 매우 좋은 경험이자 노하우가 쌓인다고 생각했다.~~(그리고 면접비도 준다)~~

2-3. 면접

앞선 방식으로 서류를 제출한 결과 3개월 동안 총 6곳에서 서류 합격 결과를 받았고, 그중 4곳에서 면접을 봤다.

스타트업(백엔드/DevOps) 1회, 중견(전산직) 1회, 중견(클라우드) 1회, 대기업(클라우드) 1회.

면접이 있으면 항상 그 기회를 소중하게 생각하고 최선을 다해서 준비했다. 이 회사를 갈지 안갈지는 최종 합격을 통보 받은 이후에 생각하고 결정해도 늦지 않다고 생각했다. 그리고 이런식으로 몇차례 면접을 보면서 느낀점은 볼수록 면접 스킬 특히 기술 면접 부분에서 점점 더 늘었다.(당연히 첫 면접을 제일 망쳤었다)

그리고 평소에 동기들과 CS 면접 스터디를 통해 기본 개념은 머릿속에 갖고 있으려 노력했던 부분도 도움이 되었다고 생각한다.

3. 나만의 강점

취업준비를 하면서 대기업에 지원하고, 수도 없는 광탈을 맛보았다. 특히 처음에는 백엔드를 주로 지원했는데 결과가 처참했다. 그래서 생각을 했던게 "과연 내가 백엔드 개발자로써 강점이 있을까?"라는 생각이었다. 특히 요즘은 백엔드 개발자를 희망하는 사람들이 정말 넘쳐난다. 수요 <<<< 공급 이라고 생각한다. 그래서 내 포트폴리오와 이력서를 보면서 나만의 강점을 찾으려고 노력했다. 솔직히 처음에는 "내가 강점이 어딨어 그냥 평균이지" 라는 생각을 가졌지만 놀랍게도 나같은 사람에게도 강점이 있었고 이런 점을 살려야겠다고 생각을 했다. (개인적으로는 백엔드 개발이 아닌, Ops(DevOps, MLOps, CloudOps) 부분에서의 강점을 밀고 나갔던 것이 도움이 많이 되었다.)

결론

만약 모두가 이름만 대면 아는 대기업이나 연봉 높은 기업에 합격 하는 것이 취준 성공의 기준이라면, 나의 취업준비는 성공했다고 보기 힘들다. 하지만 항상 취준을 하면서 중점을 두었던 부분은 내가 하고 싶은 일과 기업을 찾고자 노력했고 이러한 부분에 있어 현재 나는 만족스럽다.

특히 요즘은 뉴스를 조금만 돌려보아도 "개발자 취업난", "중고 신입" 등 절망적인 키워드 밖에 볼 수 없다. 그래서 생각했던 것이 모두가 처음부터 원하는 기업이나 대기업에 들어 갈 수 없다. 이런 부분에 있어 나는 빠른 자기 객관화가 되었고, 아직 나이도 어리기에 내가 하고 싶은 개발, 커리어를 쌓을 수 있는 곳에 초점을 맞췄다. 특히 개발자라는 직무는 커리어를 쌓기 쉽지는 않지만, 나름 노력한 만큼 인정받을 수 있는 직업이라 생각한다.

향후 계획

일단 가장 1순위는 신입사원으로 회사에 적응하고 열심히 일도 배우고 사회생활도 배울 것이다. 그리고 적응기가 끝나갈때쯤 직장인 동아리, 네트워킹 등 개인 공부와 커리어를 계속해서 쌓아나갈 것이다. 단기적으로 보면 첫 취준은 끝났지만 그렇다고 내 커리어가 끝난 것은 아니기에 앞으로도 꾸준히 공부하고 습득하며 이 분야에 있어 인정받는 그런 클라우드 개발자가 되고 싶다.

AWS Disaster Recovery: 재해 복구 솔루션 방식과 RTO RPO

무엇을해야하는지 — Fri, 16 May 2025 00:33:52 +0900

재해 복구(Disaster Recovery)란

클라우드에서는 다양한 트래픽이 몰리는 상황이나 예기치 못한 장애나 공격으로 인해 서버가 다운되었을 경우 혹은 데이터가 날라갔을 경우 이를 백업하는 단계는 매우 중요하다. 그리고 보통 이러한 재해를 복구하는데 평가되는 요소에는 총 두가지가 있다.

RPO(Recovery Point Objective): 어느 시점부터 백업 데이터를 저장할지
RTO(Recovery Time Objective): 백업까지 얼마나 시간이 소요 되는지

이 두가지 요소는 재해 복구를 하는데 있어 매우 중요한 두가지 요소 이며 보통 RPO와 RTO가 낮을수록 좋은 재해 복구 솔루션이라고 하지는 않고, 전체적인 비용까지 따져가며 현재 인프라와 요구사항에 맞는 복구 솔루션을 구축하는 것이 중요하다.

이제 AWS에서는 이러한 재해 복구를 총 3가지 관점에서 정의하고 바라본다.

1. on premise to on premise(전통적인 방식)
2. on premise to AWS(Hybrid 방식)
3. AWS Cloud Region A to Region B

이제 오늘은 강의를 듣고 위 3가지에는 어떠한 방식들이 있고, 어떤 장단점과 특징이 있는지 정리해보았다.

Backup and Restore

특징:

기존 on premise 데이터들을 주기적으로 S3와 S3 Snapshot에 스냅샷을 찍어 보관 한다.

장애가 발생하게 된다면 주기적으로 저장되어 있던 스냅샷으로 AMI를 통해 EC2를 실행시키고, RDS에는 데이터를 이전하여 서비스를 임시로 원활하게 사용할 수 있다.

단점: 높은 RPO와 RTO

장점: 가격이 저렴하고 구축하기 매우 쉽다.

Pilot Light

특징:

EC2같은 경우에는 실행하고 있지 않다가 on premise 서버에 장애가 발생하면 Route 53이 자동적으로 트래픽을 EC2로 보내게 되고 그제서야 EC2가 실행이 된다. 다만, RDS같은 경우에는 주기적으로 메인 DB로 부터 복제하고 저장하기에 꾸준히 실행중에 있다.

장점: 단점이 없는 것이 장점이다. RTO, RPO 둘다 낮다고 할 수 있고 가격 또한 장애 발생 전까지는 RDS에만 지출이 생기기 때문에 저렴하다고 볼 수 있다.

Warm Standby

특징:

모든 시스템이 장애를 대비하기 위해 최소한의 크기로 돌아가고 있다.

사실 Hybrid로 운영하고 있다고 보면 될것 같다. 다만, on premise에서 FailOver가 발생했을 때만 Route 53이 AWS로 로드 밸런싱을 진행해준다.

Multi Site / Hot Site Approach

특징: Warm Standby와 다른점은 최소한의 크기로 대비를 하는지, 최대한의 크기로 대비를 하는지에 따라 달렸다. Multisite 같은 경우 ASG의 크기를 실제 production 환경에 맞추어 사실상 hybrid로 운영하고 있는 셈이나 마찬가지이다.

장점: RTO, RPO가 매우 낮다

단점: 전체적으러 비용이 비싸다

All AWS Multi Region

특징: 재해 복구 솔루션의 끝판왕이다. 같은 환경을 서로 다른 Region에서 운영하여 그 안정성을 최대한으로 높인다. 또한 Aurora DB로 마스터 db 와 slave db를 두어 master db가 죽더라도 slave db에서 다시 살려내어 복구할 수 있다.

장점: RTO, RPO 도 낮고, 매우 안정적인 솔루션

단점: 비용이 매우 비싸다

어떤 재해복구 솔루션을 써야할까?

재해복구 솔루션에는 정답이 없다. 비싸다고 무조건 안좋은 것도 혹은 RTO가 느리다고 무조건 안좋은 것도 아닌 현재 인프라와 요구사항에 맞춰 RPO, RTO 그리고 비용과 안정성 등 다양한 조건을 고려하여 설계하는 것이 정답이라고 한다.

AWS Networking: 효율적인 네트워킹 구성하는 법

무엇을해야하는지 — Thu, 15 May 2025 16:17:12 +0900

AWS Networking

AWS에서는 다양한 방식으로 VPC를 구축하여 인프라를 구축할 수 있다. 다만, 어떤식으로 구축하느냐에 따라 그 효율과 비용은 천차만별이다. 때문에, 이번 포스팅에서는 강의를 듣고 이와 관련한 내용을 정리해 보았다.

Networking Cost in AWS per GB(Simplified)

[동일 Region 내에서의 Traffic]

일단 가장 먼저 AWS에서는 Inbound로 들어오는 요청은 대부분 무료이다.

또한 같은 Region내의 같은 AZ내에서 private IP로 통신 할 경우 그 비용 또한 무료 이다.

하지만 만약 같은 Region내의 다른 AZ에서 private IP로 통시을 하게 된다면 그 비용은 요청당 0.01가 부과 되게 되고,

public IP 혹은 Elastic IP를 부여하게 된다면, 그 비용은 0.02 달러로 올라가게 된다.

[다른 Region간의 Traffic]

다른 Region에 있다면 다른 VPC가 할당되기 때문에 VPC Connection이나 DX를 설정해주지 않는 이상 private IP로는 통신이 불가능하다. 때문에, 통신 비용은 항상 0.02 달러로 고정이다.

Minimizing egress traffic network cost

개념
Egress Traffic: Outbound Traffic이라고도 하며 AWS에서 외부 네트워크로 요청이 보내지는 상황
Ingress Traffic: Inbound Traffic이라고도 하며 외부 네트워크에서 AWS로 요청이 들어오는 상황

조건
특정 기업의 네트워크내의 서버에서 AWS에 있는 DB에서 값을 받아온다고 가정했을 때, 가장 비용 효율적인 방식을 찾아보기

시나리오1

해당 방식은 온프레미스 네트워크에서 직접 DB로 바로 접근하여 100MB가 되는 값을 바로 받아온다. 이때 100MB가 직접 넘어오기 때문에 비효율적이라고 할 수 있다.

시나리오2

해당 방식은 시나리오1과 달리 application을 AWS 서버에서 실행하게 된다. 만약 DB와 서버가 같은 리전에서 private IP로 통신한다고 가정했을때 두 서비스 간의 통신은 100MB이더라도 무료가 된다. 때문에 실제 user에게 전달되는 50KB에만 비용이 측정되기 때문에 비용 측면에서나 설계 측면에서 훨씬 효율적이라고 볼 수 있다.

S3 Data Transfer Pricing

S3에서 인터넷으로 직접 연결이 될때는 0.09 달러가 부여된다.

시나리오1

Edge Location 할당과 Transfer acceleration을 붙이게 되면 0.04 달러가 추가로 부여되지만, 속도는 최소 50에서 500% 빨라진다는 장점이 있다.

시나리오2

CloudFront를 중간에 두어 통신하게 되면 S3와 CloudFront간의 통신은 무료이고, CloudFront와 인터넷 간의 통신은 0.085 달러로 아주 살짝 저렴하다. 뿐만 아니라 CloudFront에는 기본적인 Caching 기능이 탑재 되어 있기 때문에 지연시간이 낮다는 장점도 있다.

NAT Gateway vs Gateway VPC Endpoint

Nat Gate way와 Gateway VPC Endpoint 둘다 private subnet에 있는 인스턴스가 인터넷을 연결하기 위해 도와준다는 공통점이 있다. 하지만 어떤식으로 구축하는지에 따라 비용차이는 생각보다 크다.

시나리오1: EC2 -> NAT -> Internet Gateway -> Internet

이 방식은 흔하고 간단하지만 비용적인 측면에서는 매우 불리하다.

사실상 한번의 요청에 0.1 달러가 부과되는 셈이다.

시나리오2: EC2 -> VPC Endpoint -> S3 -> internet

해당 방식에서 실제로 VPC endpoint를 사용하는 것에는 비용이 부과되지 않기 때문에 S3와의 Data Transfer에서 발생하는 0.1달러만 부여가 된다. 때문에 앞선 시나리오1보다 10배 가량 비용 효율적이다.

결론

AWS의 VPC에는 알아야할 것이 매우 많다. 기본적인것만 알고 가기에는 모르고 지나치면 손해보는 경우가 많은 것 같다.

참고 자료:

https://www.udemy.com/course/best-aws-certified-solutions-architect-associate/learn/lecture/29389410#overview

AWS Monitoring: CloudWatch vs CloudTrail vs AWS Config 차이

무엇을해야하는지 — Tue, 13 May 2025 17:18:51 +0900

AWS 모니터링

AWS에서는 모니터링 하기 위해 크게 3가지 서비스를 사용한다.

1. CloudWatch

2. CloudTrail

3. AWS Config

이 3가지의 차이점에 대해 명확히 이해하는 것이 중요하다.

모니터링 차이

사실 3가지의 공통점은 그저 '모니터링 시스템'이라는 점을 제외하면 그 어떤 것도 없다.

모니터링 목적

Cloud Watch: 시스템과 애플리케이션를 모니터링

Cloud Trail: AWS 계정 내 API 호출 기록 추적

AWS Config: AWS 리소스의 구성 변경 추적 및 기록

모니터링 대상

Cloud Watch: Peformance와 같은 Metric, Log을 추적한 뒤 알람 및 대시보드 구성

Cloud Trail: 사용자/서비스의 API 요청 (예: StartInstances, PutItem)

AWS Config: 리소스 상태/속성 변경 (EC2 태그 변경, SG 수정 등)

모니터링 기록

Cloud Watch: CPU, 디스크 IO, Log

Cloud Trail: 누가 언제 어떤 API를 호출했는지(IP, 시간, 계정, 서비스 등)

AWS Config: 리소스의 이전 상태와 변경된 상태

이 외에도 실시간성이 제공되는 CloudWatch와 Cloud Trail와 달리 AWS Config는 시간이 소요되는 등 3가지 모니터링 도구는 각기 다른 목적과 사용성을 가진다.

사용 예시 비교

CloudWatch

시스템 및 애플리케이션 상태를 실시간 모니터링

EC2 인스턴스의 CPU, 메모리, 디스크 사용량 추적
Lambda 함수의 로그와 실행 시간 분석
특정 로그 메시지에 대해 알람 설정 (예: "ERROR" 포함 시 알림)

CloudTrail

AWS 리소스에 대한 “누가 무엇을 했는가”에 대한 기록

IAM 사용자가 S3 버킷을 삭제한 기록 확인
어떤 IP에서 어떤 API 요청이 왔는지 추적
AWS 콘솔, CLI, SDK 등 모든 요청 로그 남김

AWS Config

리소스의 구성 변화 이력 추적 및 규정 준수 검사

EC2 인스턴스에 태그가 추가/삭제된 시점 기록
보안 그룹에 포트 22가 열린 시점 추적
“모든 S3 버킷은 암호화되어 있어야 한다” 같은 규칙 설정

참고 자료

https://www.udemy.com/course/best-aws-certified-solutions-architect-associate/learn/quiz/5384020#overview

AWS Monitoring: CloudWatch란 무엇인가

무엇을해야하는지 — Tue, 13 May 2025 16:48:25 +0900

AWS 모니터링

인프라 관점에 있어 모니터링은 서비스를 계속해서 안정적으로 실행할 수 있도록 하고, 오류가 발생했을때 빠르게 문제를 파악하고 수정할 수 있도록 하는 매우 중요한 기능중 하나이다.

AWS Cloud Watch Metric

CloudWatch 란?
CloudWatch는 AWS 모든 서비스에 지표를 제공한다. (여기서 지표란 서비스의 Peformance)
측정 가능한 지표에는 대표적으로 'CPU 사용률, Networkin, Bucket Size 등이 있다.'

하나의 Metric당 최대 측정 기준은 10개로 진행되며, Metric이 많아지면 CloudWatch 대시보드에 추가해 모든 지표를 한 번에 볼 수 있다. 사진과 같이 다양한 GUI로도 확인이 가능하다.

CloudWatch Metric Stream

CloudWatch Metric Stream 이란?
CloudWatch 외부로 스트리밍 할 수 있다. (Near Real time으로 지연시간이 매우 짧다). 또한 Firhose를 사용하여 수집된 Metric을 원하는 곳에 저장하고 분석이 가능하다.

CloudWatch Logs

* Logs

숫자 기반의 측정값 (CPU 사용률, 메모리 사용량 등)

* Metrics

텍스트 기반의 이벤트 기록 (에러 메시지, 시스템 메시지 등)

Log Group: 로그들을 로그 그룹으로 그룹화

Log Stream: 로그 그룹에는 로그 스트림이 있고 애플리케이션 내 인스턴스나 다양한 로그 파일명 또는 컨테이너를 나타낸다.

CloudWatch Logs에서 저장한 로그들은 AWS의 다양한 서비스에서 분석될 수 있다.

1. CloudWatch Logs - Source

CloudWatch Logs "Source"란, 로그 이벤트의 원본(출처)을 의미. 즉, 로그가 어디에서 생성되었는지를 나타내는 정보

웬만한 AWS 서비스에서는 Source로 작동한다.

- SDK, CloudWatch Logs Agent, Cloud Watch Unified Agent

- ElasticBeanStalk(Application에서)

- ECS(Container에서), Lambda 등...

2. CloudWatch Logs - Metric Filter& Source

A. CloudWatch에서는 필터 표현식을 통해 로그를 수집하고 분석 할 수 있다.

-> EX) 특정 IP, ERROR가 들어간 로그 수집

B. Metric Filter를 통해 출현 빈도를 계산해 지표를 만들 수 있다.

C. CloudWatch Logs Insights

-> 로그를 쿼리하고 쿼리를 대시보드에 추가(한번 만들면 빠른 검색 가능)

3. S3 Export

Export까지 12시간으로 Batch 작업으로 저장이 된다.

4. Cloud Watch Logs Subscription

CloudWatch 위에 적용하여 로그를 실시간으로 목적지까지 보내는 필터

5. Cloud Watch Logs for EC2

EC2의 로그를 옮기기 위해서는 가장 먼저 EC2 내에 CloudWatch Logs Agent를 실해하여 로그 파일을 push하고 EC2 인스턴스에 IAM ROLE를 추가해줘야 한다.

(이는 온프레미스 환경에서도 작동한다)

6. CloudWatch Logs Agent & Unified Agent

A. Logs Agent -> 구버전으로 요즘은 사용을 잘 안함

B. Unified Agent

- process, RAM과 같은 세부적인 퍼포먼스 지수를 수집할 수 있다.

- 지표와 로그를 둘 다 사용(기본적으로 Unified Agent가 더 많이 사용되는 이유)

- CloudWatch Log로 로그를 보냄

CloudWatch Alarms

CloudWatch Alarms는 지표에서 알람을 Trigger할 때 사용한다. 또한 Sampling, %, max, min 등의 다양한 옵션을 추가해서 복잡한 경보 정의가 가능하다(AND/OR GATE 포함)

알람 상태는 총 3가지

A. OK: 트리거가 되지 않은 상태

B. INSUFFICIENT_DATA: 상태를 결정할 데이터가 부족한 상태

C. ALARM: 임계값을 넘어 알람이 보내지는 상태

1. CloudWatch Alarm Targets

-> EC2 Instance 동작(종료, 재부팅 등), EC2 Auto Scaling(Scale out or in), SNS 등

2. EC2 Instance Recovery

상태 점검이 이에 해당한다. (ec2 vm 상태 점검, 하드웨어 점검 등)

참고 자료

https://www.udemy.com/course/best-aws-certified-solutions-architect-associate/learn/quiz/5384020#overview

https://choiblog.tistory.com/197

AWS 모니터링 및 감사

AWS 모니터링 모니터링은 서비스를 계속해서 실행할 수 있게 해주는 중요한 기능 중 하나 AWS CloudWatch Metrics CloudWatch는 AWS 모든 서비스에 지표를 제공 지표(metric)은 모니터링 할 지표 CPU 사용률, net

choiblog.tistory.com

AWS Container: ECS, Fargate 이해하기

무엇을해야하는지 — Sat, 3 May 2025 17:12:51 +0900

서론: Docker in AWS

AWS에서 Docker를 관리할수 있는 서비스는 다음과 같이 4가지가 있다. 전부 docker container를 AWS 서비스 위에서 관리, 운영을 도와주는 서비스이다. 여기서 오늘은 ECS, Fargate에 대해 정리를 해봤다.

Amazon ECS(Elastic Container Service)란?

ECS란?

Amazon Elastic Container Service(Amazon ECS)는 컨테이너 애플리케이션을 쉽게 배포, 관리 및 확대할 수 있도록 도와주는 완전 관리형 컨테이너 오케스트레이션 서비스이다. 즉, 도커 컨테이너 관리를 위한 AWS의 전용 플랫폼이다.

ECS에서 제공하는 기능은 아래와 같다.

1. 태스크 정의: 애플리케이션의 블루프린트
2. 클러스터: 애플리케이션이 실행되는 인프라
3. Task: 작업을 수행한 다음 중지하는 배치 작업 같은 애플리케이션
4. Service: 장기 실행되는 상태 비저장 애플리케이션
5. 클러스터 Auto Scaling: Amazon ECS는 클러스터에 등록된 Amazon EC2 인스턴스의 규모 조정을 관리
6. 서비스 오토 스케일링: Amazon ECS는 서비스에서 원하는 태스크 수를 자동으로 늘리거나 줄임

이런 ECS를 실행하는 방식에는 두가지가 있다. EC2와 Fargate 방식이다.

EC2 Launch Type

EC2 인스턴스는 각각 ECS 에이전트를 실행해야함.

실행되면 ECS 에이전트가 각각의 인스턴스를 지정된 ECS 클러스터에 등록, 이후 ECS Task를 수행하기 시작하면 AWS가 컨테이너를 시작하거나 멈춘다. 새 컨테이너가 생기면 시간에 따라 EC2에 지정되고 자동적으로 실행됨.

Fargate Launch Type

AWS에 Docker Container를 실행하는데 프로비저닝 하지 않아 관리할 EC2가 없다

-> Serverless 기능(실제 AWS가 추천하는 기능)

ECS 클러스터에 ECS 태스크를 정의하는데 태스크 정의만 생성하면 ECS 태스크를 AWS가 알아서 실행한다.

작업이나 확장을 위해서 EC2 인스턴스가 필요없기 때문에 Task만 수정하고 배포해주면 되기에 훨씬 더 간편하다.

EC2 Lauch Type vs Fargate Launch Type

좀 더 쉽게 비교를 해보자면,

ECS on EC2는 집을 직접 짓고, 설비를 깔고, 모든 걸 손수 관리하는 방식.

Fargate는 그냥 들어가서 살 수 있게 다 준비된 오피스텔에 입주하는 느낌. (전기세, 수도세는 쓴 만큼만 냄)

사실 가장 큰 차이는 Serverless냐 아니냐의 차이다. 관리, 운영 측면에서 훨씬 편한 방식은 Fargate이기에 AWS에서도 Fargate를 추천하는 이유가 아닌가 예상해본다.

IAM Roles for ECS

이제 ECS 위에서 돌아가는 컨테이너가 AWS의 어떤 서비스와 통합되고 연결될 수 있는지는 IAM Task Role를 통해 AWS 서비스의 API를 사용할 수 있도록 할 수 있다.

1. EC2 Instance Profile(EC2 Lauch Type만 해당)

- ECS 에이전트만이 EC2 istance Profile를 사용

- EC2 인스턴스 프로파일을 이용해 ECS로 API 호출

- CloudWatch Logs API를 통해 컨테이너 로그를 보냄

- ECR에서 도커 이미지를 가져옴

2. ECS Task Role(EC2, Fargate Launch Type 모두 해당)

- 각각의 태스크에서 서로 다른 역할 생성 가능

- ECS 태스크 정의 에서 태스크 역할을 정의

ECS의 데이터 지속성

여러 컨테이너가 유지 되기 위해서는 공유할 수 있는 Data Volume이 필요한데 가장 잘 사용되는 서비스가

EFS이다.

EFS는 Lauch Type과 상관없이 호환이 된다는 장점이 있다.

특히 Fargate + EFS가 합쳐졌을 때는 완전한 Serverless가 완성이 된다. 또한 EFS는 Multi AZ에서 호환이 가능하기 때문에 컨테이너의 영구 스토리지로 사용이 가능하다.

(다만, S3는 EFS로 마운트 불가능)

ECS Auto Scaling

ECS에서 Auto Scaling을 위해 총 3가지를 기준으로 Scaling이 가능하고 이때 AWS Application Auto Scaling을 사용한다.

1. CPU 사용률

2. 메모리 사용률

3. ALB 지표 관련 Request 수

또한, CloudWatch에서 Target을 통해 Target Tracking이 가능하다.

이 외에도 단계적으로 Scaling하는 Step Scaling, 스케줄된 Scheduled Scaling이 가능하다.

Auto Scaling EC2 in Ec2 Launch Type

Fargate Lauch Type에서는 AWS가 전부 다 관리해주기 때문에 Auto Scaling 설정이 필요 없지만, EC2 lauch Type에서는 아래와 같이 직접 Capacity Provider를 통해 Auto Scaling Group에 알려 EC2를 스케일링 해줄 필요가 있다.

ECS Task를 Invoke하는 방법

1. ECS tasks invoked by Event Bridge

말 그대로 특정 Event가 발생하면 실행되는 것이다.

2. ECS tasks invoked by Event Bridge Schedule

특정 Schedule를 통해 실행이 된다.(예: cron과 같이 특정 주기마다 실행)

참고 자료

https://www.udemy.com/course/best-aws-certified-solutions-architect-associate/learn/quiz/5384010#overview

https://choiblog.tistory.com/191

AWS 컨테이너 ECS, Fargate, ECR과 EKS

컨테이너 Docker 앱 배포를 위한 소프트웨어 개발 플랫폼 컨테이너에 앱이 패키징되는데 컨테이너는 표준화되어있어 어느 OS에서나 같은 방식으로 실행 가능 기기와 상관없이 실행 가능 호환성

choiblog.tistory.com

ArgoCD Sync Policy와 Sync 방식

무엇을해야하는지 — Sat, 3 May 2025 13:50:38 +0900

ArgoCD 란?

Argo CD는 Kubernetes 환경에서 GitOps 방식으로 애플리케이션을 배포하고 관리하는 툴이다. Git 저장소에 선언된 Kubernetes 리소스(YAML 등)를 기준으로 클러스터 상태를 지속적으로 감시하고, 자동 또는 수동으로 동기화하여 클러스터 상태를 Git 상태와 일치시킨다.

실제 이전에 Kubernetes에 ArgoCD를 배포하여 롤링배포를 구현한 경험이 있는데 자세한 내용은 아래 포스팅 참고.

https://what2dochris.tistory.com/15

Kubernetes에 ArgoCD 배포하기

ARGOCD 란ArgoCD는 Kubernetes의 애플리케이션 배포를 관리하고 자동화하는 오픈 소스 도구이다.GitOps 원칙을 기반으로 하여, Git 저장소를 애플리케이션의 '단일 진리의 소스'로 사용하고, 이 저장소에

what2dochris.tistory.com

ArgoCD Sync

ArgoCD Sync란 git에 올라와있는 파일을 argocd를 통해 클러스터에 동기화 하는 작업을 뜻한다. 하지만 git manifest file이 변경되었다고 해서 바로 Pod에 적용되지는 않는다. ArgoCD는 Default로 3분에 한번씩 git을 감지하기에 변경이 되었더라도 3분이라는 period를 기다려야한다.

물론 ArgoCD UI에서 강제로 Refresh를 통해 바로 Sync 시켜줄수 있다.

Refresh를 개발자가 눌러주면 3분을 기다리는 것이 아닌 바로 상태 감지를 통해 변경시켜줄 수 있다.

ArgoCD Sync Status

위 과정에서 Refresh, 혹은 git과 pod의 상태를 감지하고 나면 Synce Status라는게 뜬다.

총 두가지가 있다.

Git 상태와 Kuberenetes Cluster의 현재 상태가 같다는 Sync OK 상태와 두가지가 다르다는 OutOfSync 상태.

https://github.com/argoproj/argo-cd/issues/12526

Sync Policy

위 상황에서 만약 Out of Sync 상태가 떴다고 가정했을때 개발자가 취할 수 있는 방식은 두가지가 있다.

1. Auto Sync: 자동 Sync로써 Out Of Sync, 즉 변경점이 확인되었을때 자동으로 클러스터에 변경된 부분을 수정해주는 것이다.

2. Manual Sync: 수동 Sync로써 변경점이 확인되었을때 개발자가 직접 ArgoCD UI에서 Sync 버튼을 눌러 수동으로 변경된 부분을 수정해주는 것이다.

이런식으로 하면 아래와 같이 Git actions - ArgoCD - Kubernetes를 통한 CICD가 비로소 완성이 되었다고 할 수 있다.

추가: ArgoCD Sync Alert to Slack

Hook을 생성하여 ArgoCD가 Sync 될때마다 Slack으로 알람을 보내줄 수 있다.

apiVersion: batch/v1
kind: Job
metadata:
  generateName: app-slack-notification-
  annotations:
    argocd.argoproj.io/hook: PostSync
    argocd.argoproj.io/hook-delete-policy: HookSucceeded
spec:
  template:
    spec:
      containers:
      - name: slack-notification
        image: curlimages/curl
        command:
          - "curl"
          - "-X"
          - "POST"
          - "--data-urlencode"
          - "payload={\"channel\": \"#somechannel\", \"username\": \"hello\", \"text\": \"App Sync succeeded\", \"icon_emoji\": \":ghost:\"}"
          - "https://hooks.slack.com/services/..."
      restartPolicy: Never
  backoffLimit: 2

해당 Yaml파일을 통해 alert를 보내줄 수 있는데 어렵지 않아서 아래 공식문서를 참고하여 금방 구현할 수 있었다.

https://argo-cd.readthedocs.io/en/stable/user-guide/resource_hooks/

참고자료

https://malwareanalysis.tistory.com/408

ArgoCD 6편 - Sync 설정

안녕하세요. 이 글은 ArgoCD시리즈입니다. git에 의도된 상태를 쿠버네티스 클러스터에 동기화 할 때, 필요한 개념과 자주 사용하는 기능을 설명합니다. 영상: https://youtu.be/XBcoj3-pjDA 1. Refresh Period 1.

malwareanalysis.tistory.com

https://argo-cd.readthedocs.io/en/stable/user-guide/resource_hooks/

AWS 통합&메시징: SNS란 무엇이고 언제 사용해야하는가

무엇을해야하는지 — Fri, 2 May 2025 17:15:10 +0900

SNS란

Pub/Sub 메시징 서비스로 하나의 메시지를 여러 수신자에게 동시에 전송하는 서비스

Publisher: 메시지를 주제로 게시

Subscriber: 많은 구독자들은 SNS 토픽에 따라 메시지를 수신하고 보관한다.

SNS에서 이벤트 생산자는 한 SNS 토픽에만 메시지를 보낸다
수신자 또는 구독자는 해당 토픽와 관련된 메시지를 받는 역할이고 생성에 제한이 없다
하나의 SNS 토픽 구독자는 해당 토픽으로 전송된 모든 메시지를 받으며 메시지 필터링도 있다

SNS - Publish 하는 방법

1. SDK Topic Publish:

Topic을 만들고 여러개의 구독을 만든 뒤 토픽을 공개. 해당하는 모든 구독자들이 토픽 메시지를 받게됨

2. Direct Publish:

플랫폼 애플리케이션과 Endpoint를 만들고 플랫폼 Endpoint에 게시

SNS + SQS: Fan Out 패턴

SNS와 SQS를 연결함으로써 Fan Out이라는 패턴이 구현 가능하다. 그리고 이는 가장 대표적인 시나리오이다.

FanOut이란?

하나의 메시지를 여러 SQS 대기열로 보낸다면 많은 문제가 발생할 수 있기에 Fan Out Pattern을 사용해서 원하는 만큼의 SQS 대기열이 SNS Topic을 구독하도록 설정

장점:

a. 완전히 분리된 모델로 만들며 애플리케이션 문제로 인한 데이터 손실이 없다
2. SQS로 작업을 다시 시도할 수 있고 데이터 지속성, 지연성 처리도 수행 가능하다
3. 많은 SQS 대기열 추가 가능
4. SQS 엑세스 정책에서 SNS 주제가 SQS 큐에 메시지를 작성할 수 있도록 허용해야한다
5. 리전간 전달 또한 가능

SNS - FIFO Topic

Topic의 메시지 순서를 지정하는 FIFO 기능 존재하고 SQS FIFO와 비슷하게 그룹ID에 따라 순서를 매겨 전송

장점:

1. 중복 제거가 가능하다.
2. 그룹 ID에 따라 순서대로 전송 가능

SNS FIFO + SQS FIFO의 Fan Out 수행 가능

SNS - Messaging Filtering

SNS Topic을 구독하면서 Topic에 전송되는 메시지는 Json 정책으로 필터링 된다.

즉, Json 필터링으로 SNS를 구독한 사람들에게 필요에 맞는 메시지만 전송 가능하다.

SNS 대표 사용 사례

장애/이벤트 발생 시 실시간 알림 (예: CloudWatch Alarm → SNS → Slack/Email)
모바일 푸시 알림 (FCM, APNs 연동)
주문 완료 후 사용자 및 내부 시스템에 동시에 알림
마이크로서비스 간 브로드캐스트 통신