4.1 메모리 관리 개요 메모리 관리 : 프로그램 실행 중 필요한 데이터를 저장하고, 필요 없어진 데이터를 제거하는 과정

자동 메모리 관리 : 가비지 컬렉션을 통해 불필요한 메모리를 자동으로 해제

#잡생각 : GC가 이슈가 되서 confluence 오류가 있던적이 있었음! 그래서 주마다 설정해서 flush 하는 작업이 처리되면서 I/O 가 뛰었던것 같음 그때 힙메모리 설정 조정도 했었던거 같음 (aws 파라미터 수정해서)

참조 카운팅 : 객체가 몇 번 참조되는지를 기록하여 참조가 0이 되면 메모리를 해제

#잡생각 : 오 이거 aws aurora 스냅샷이랑 비슷하넹

파이썬은 메모리를 할당할 떄 PyObject 구조체를 사용

모든 파이썬 객체는 이 구조를 기반으로 하여, 참조 카운트와 타입정보를 포함

sys.getrefcount로 조회하기 단 디버깅할때만 쓰이는게 좋음

4.2 리스트의 정의와 사용법 리스트는 순서가 있는 변경 가능한 컬렉션 다양한 데이터 타입을 포함할 수 있으며, 인덱스는 0부터 시작

컬렉션이라는것은 무언가를 모아놓은 공간이고 순서가 있고, 다양한 타입을 포함할수 있다는게 특징임

리스트를 대괄호를 사용하여 생성 추가는 append(), extend(), insert() 매서드 사용 가능

슬라이싱을 통하여 추출할 수 있습니다.

파라미터를 학습한다 : 모든 파라미터는 숫자들의 배열을 학습하는건데 이 카피를 많이 쓰게 됨

a=[1,2,3] b=a.copy[]

4.2 딕셔너리 딕셔너리 딕셔너리는 키-값을 저장하는 변경 가능한 컬렉션입니다. 키는 고유해야 하며 해시 가능해야합니다. 딕셔너리는 중괄호를 사용하여 생성됩니다.

비어있으면 안됨

제가할때는 del 키워드를 이용하여 제거가능하고 pop으로도 가능함

4.3 집합의 정의 (중복이 허용되지 않아서 연산에 유용함) 집합의 정의와 사용법

4.4 튜플의 정의 튜풀은 순서가 있는 변경 불가능한 컬렉션임 리스트와 비슷하지만 한번 생성되면 수정할 수 없음

튜플의 값을 변환하는 것을 확인할 수 있음 튜플 카운트로 하고....

튜플에 있는 항목 x의 첫번째 인덱스를 반환

python 반복문과 조건문 그리고 함수

###if,elif,else 문

기본문법 if 조건1: 실행할 코드1 elif 조건2: 실행할 코드2 else 그외 : 실행할 코드3

score = int(input("점수를 입력하세요: "))
if score >=90:
    grade = "A"
elif score >=80:
    grade = "B"
elif score >=70:
    grade = "C"
elif score >=60:
    grade = "D"
else:
    grade = "F"

## 여기에 코드 작성
print(f"학점: {grade}")코드를 입력하세요

중첩 조건문

if, else, ifelse

숫자 입력은 input으로 받아서 int로 변환 숫자가 양수인지 음수인지 그리고 짝수인지 판별하시오

${discount_amount:.2f}

fstring 과 .2f : 소숫점 두자리수까지 나타내라 파이썬 3.6부터 도입된 문자열 포맷팅 방식

반복문

while과 for문

시퀸스는 배열을 의미하는것임! 여기서 리스트나 튜플이나 스트링은 시퀸스라고 할 수 있음

for 문의 경우 sequence의 길이만큼 나오는 것임! list로 바꿔보면 range 자체를 출력해보면 됨! 예를 들어 list(range(1,6))

for문에서 range ( 시작점, 끝점) 여기서 끝점 신경쓸것 ㅋㅋㅋ

1. 고가용성을 위한 cloud 구축의 필요성
2. data ai 를 위한 리소스
3. -
4. 클라우드의 상호호환성이 중요 ㅋㅋ (근데 얘내들도 outbound 는 돈받음)
5. 보안강화 (당연한거긴함) planet-sacle protection ㅋㅋㅋㅋㅋ
6. 비용 최적화 (scale-up, scale-out) provides near-real-time or short lag for biling data and alerts

개발자 키노트1 : Next'24 제시하는 10가지 핵심 전망 wht's new AI

Gemini 1.5 pro 2M context winodw, context caching 1M for high-volume tasks where cost and latency matter (with low cost)

Hugging face intergration with Vertex AI published model hugging face (based by domain)

promt management (version history and management)

google cloud infrastructure (GPU/TPU)

vertex ai agents (using natural language)

langchain on verex AI (flameworks에 따라 다르지만 최대한 지원하는편)

langchain을 어떻게 이용하는지 보여주는 부분이 필요 (개발형 모델을 선택하고 도구 정의 - 오케스트레이션 앱 간리형 배포)

Ground with google search

vertex ai search (out of the box)

Rag system APIs Call (by myself)

Firebase **이거 뭔지 모름

https://appmaster.io/ko/blog/paieobeiseuran-mueosibnigga

개발자

liner google (tool)

Gemma open models

LLM (미래를 만드는 AI 개발자를 위한 GOOGLE CLOUD AI RESEARCH)

gEMINI 1.5 FLASH 검새기반 답변 기술이 필요

COLUD AI 검진 엔진 유저질문 > 클라우드 AI 검색엔진 > 답변 (관련된 고객 문서)

(검색엔진의 맞춤화) - 이거 아마도

llms distillation (증류) : 더 작교 효율적인 모델로 합축하는 기술

prompt engineering 까지해서 답변이 나오는 이유까지

vertex AI

LLMs 관련 진행연구 (정형 데이터 행성 )

context 크기 비교
long context 토큰의 갯수가 연관이 있기때문에 multi-turn

long context or RAG

CHATBOT은 RAG을 적용하기 좋을것임

멀티모달은 Long context로 적용하기 좋을 것임

Gemini 멀티모달 기능으로 제품가치 강화하는 법 long context 학습시간이 오래 걸릴것임!!

모델 하나를 잡고 파보는 경험이 필요함 RAG는 Generation 하기 위한 방법임 파이토치로 모델을을 실험할때 많이 쓰임 텐서는 고치기 힘듬 7빌리어 이하가 sLLM 임! LangChain 의 문법이 너무 많아서 일부를 활용해서 써야함 PEFT 평가를 2번을 하는데

1. RAG에 대한 평가지표에 대한 부분 (아이디어 영역들)
2. RAG를 프롬프트로 Generation 을 하고 평가를 함 평가기준은 어떻게 : 테스트 데이터 셋을 어떻게 해야할지 고민해보아야함 airflow dag를 활용해서 스케줄링하고 서빙.. airflow : 스케줄러 같은것임 크롤링 - 모델학습 -.... (배치서빙이라는것) class 월수금 10:00-18:30 peer session 화,목 오후 16:00-17:00

그라운드 룰 : 각자 한가지씩 정한 룰

1. 피어세션 전에 적어도 질문 하나씩 만들어오기 2, 서로 개인회고에 리뷰 남겨주기

2. 사소한 팁이라도 1개씩 공유하기

3. 도움될만한 자료들 요약해주기

4. 오전 9시 30분에 30분정도 pre-피어하기 : 각자 to do 나누기

5. 모더레이터 역할 공지 & 일정 & 제출 횟수 체줄

6. 서기 역할

class1 :

##1. 파이썬의 탄생과 c와의 관계

java : clean code python 은 규약이 많아지지 않으므로 간결해서 좋은것 같음

데분쪽은 python 을 쓸수밖에없음 백앤드는 java scrit node를 쓸수는 없..

파이썬은 c로 작성이됨

주요 용도가 다름 파이썬 : 웹 개발, 대분, ai c언어 : 운영체제, 임베디드

정적타입으로 되어있으면 이미 코드를 작성할때 타입이 정해지기 떄문에 오류는 없을 것인데

동적 타입의 경우는 작동시 할당 받음으로... ex) string 으로 들어갈때 문제가 발생 할 수 있음

우리는 vs code 를 쓸것임

컴파일어는 쭉 짜서 한번에 돌리기 인터프리터 언어는 한줄한줄 기계어로 번역하는 방식임 (자연어: 사람이 이해할수있는 언어) 동적인 데이터 타입을 결정할 수 있도록 지원 즉, 변수를 명명할때 숫자, 문자 구분에서 자유로움

** 코드를 파이써닉하게 짜야한다. 위의 장점을 잃지 않게 짜야한다. **

MySQL 몇가지 특성

1. Nested Loop Join 만 가능
   • HASH 나 이런건 플러그인을 설치하든 외부에서 작성된것을 Import
   • 이 조인만 가능하다는 것은 외부 테이블 건수에 따라서 처리해야할 대상이 많아짐, 적절한 드라이빙 테이블 대상을 선정해야함 (선행 테이블 사이즈 * 후행 테이블 접근횟수)
   • 두테이블에 조인컬럼에 인덱스를 무조건 고려해야함
   • "대량 데이터 처리에 적합한 JOIN 은아님"
2. 단일 코어에서 쿼리 처리
   • CPU 코어 개수를 늘리는 튜닝보다, 작업을 병렬처리가 아닌 직렬로 하기때문에, 코어를 강력한것으로 쓰는게 좋음
3. 엔진을 선택할 수 있음
   • MySQL 스토리지 엔진이 구분되어 원하는 특성에 맞게 엔진 사용이 가능
4. 비교적 손쉬운 비동기 이중화가 가능하기 때문에 스케일아웃에 적합함
5. MVCC
   • 목적은 잠금을 사용하지 않는 일관된 읽기를 하는 데 있다.
   • 동시성 처리를 위해 잠금을 걸지 않고, Undo 로그에 기록되어있는 데이터값을 그대로 읽어온다. 이것이 여러버전이면, 일관성, 동시성이 보장됨

MySQL 엔진 + 스토리지 엔진

1. 포어그라운드 스레드(주로 사용자 데이터 처리) 쿼리를 요청하면 MySQL 엔진에서 커넥션 핸들러가 커넥션과 인증처리

--> SQL 인터페이스를 통해 처리 방식을 제공받고 --> "SQL Parser"를 통해 문법오류 파악하고 그것이 문제가 없으면(syntax) 내부에서 처리하기 좋게 트리(토큰) 형식으로 변경 --> 전 처리기가 파서 트리를 보고 구조적(메타정보 확인, 컬럼 유무,권한 유무) 문제가 있는지 파악 --> SQL 옵티마이저가 통계를 참고하여 수행계획을 세움 --> 수행 계획대로 접근하여 스토리지 엔진을 통해 데이터를 가져옴 2. 백그라운드 스레드(그 밖의 유지보수 작업) --> change buffer/ log buffer / deadlock monitor / dirty memory buffer를 쓰고 지우거나

메모리 & 파일 구조

1. Adaptive_Hash_Index

   B-Tree의 탐색 비효율(보조 인덱스를 수행할때 어차피 키를 찾고 다시 서칭해야하는 이슈나 밸런스가 깨져서 효율적인 탐색이 불가한 상태에서의 검색) 을 극복하기 위해, 인덱스에 자주 사용되는 데이터를 해쉬로 가지고있음 이것은 MySQL이 판단해서 해시로 가지고 있는 값이고 어떤 것을 태울지 모름, 탈때는 수행속도가 아주 빠르고 효율적임 옵션으로 제어 가능.테이블 DROP 시 해당 인덱스도 삭제되기때문에

   이슈 발생(성능 영향) 여지 있음

2. Change Buffer==Insert Buffer

   보조 인덱스의 변경에 고비용에 대비한 영역, "데이터 버퍼에서 해당 인덱스에 데이터가 없으면" 디스크로 가는것이 아닌 버퍼를 활용하여 비용을 줄임

3. Redo Log

   변경된 페이지의 트랜잭션 내용이 메모리에 상존하다가 갑자기 서버가 크래시나 다운이 되어 디스크에 채 쓰지 못하는 상황이 발생할때, 대비하도록 Redo Log가 설정값으로 주기적으로 기록(log buffer 내 redo buffer에 선 기록 후 디스크로) 딱 FLUSH 직전 변경분만 가지고있음

4. Undo Log

   데이터의 변경 직전 데이터를 보관하는데, MVCC 사용을 위한 장치 동시성을 향상시키나 변경시 버퍼 내 메모리 리소스를 사용하고 파일에 작성하므로 트랜잭션 지연(롱 트랜잭션)이나, 대용량일 경우 문제(메모리 경합)가 더욱 커질수 있음 메모리에 의존하여 계속해서 사용량을 증가시키거나 리소스를 사용하므로 때문에, 등장한것이 5.7에 Undo 테이블 스페이스 역시 log buffer 내 undo log buffer 를 먼저 쓰고 파일을 씀

5. Double Write Buffer

5%~10% 성능 손해를 감수하고 메모리에서 FLUSH 된 "데이터"를 이곳에도 저장하여, OS에 디스크 쓰기 단위가 달라 발생하는 충돌이나 장애 발생하여 "디스크에 변경이력을 저장하지 못했을때" 이곳에서 대조해서 복구

InnoDB 특징

1. Key 기반의 Clustering
2. Row-level 기반 잠금
3. ACID 트랜잭션 처리를 위한 고안(Commit/Rollback, 제약조건, 잠금)
4. 동시성 향상을 위한 잠금이 필요없는 일관된 읽기(MVCC)
5. 데드락 모니터링
6. 데이터가 복원하기 좋게 영구적으로 보관되므로 포랜식에 가치가 있음

데이터분석팀에서 사원 및 부서정보 수정요청이 왔었음 (공통점이 있다면 중국어중 간체자가 일부라는점)

간체자: 중국의 문자 개혁에 따라 글자 모양을 간략하게 고친 한자 https://ko.wikipedia.org/wiki/%EA%B0%84%EC%B2%B4%EC%9E%90

[상황에 대한 이해]** Check1. 문제가 된다고 하는 서비스를 바라보는 table이나 view가 어딘데? **

문제점 : 현업(데이터 분석팀)에서 전달받은 문제가 된다고 하는 데이터 셋쪽의 DB는 데이터 분석 팀의 DB이기 때문에 접근이 불가능함

*대체 해결점 : 그렇다면 그 DB에서 연결되는 linked 구조를 확인해달라고 요청하여 Souce DB를 확인함

문제가 되는것으로 추정되던 대상

view이름을 전달 받아서 확인해보았을때 관리하는 서버중에서 MySQL Webo DB에서 Emp view에서 데이터를 가져가는 것을 확인함

*Check2. 그렇다면 해당 Webo DB에서 문제가 되는 대상을 확인해보자 *

view?, Table? : 둘다 깨짐 (예시 이미지일 분이며, 실제로는 네모 모양으로 깨졌음) (table과 view는 mysql 상에서 스케줄러를 이용하여 매일 동기화 되는 시스템이었음) * *check3. 그렇담 임시조치로 MySQL Webo db에 문제되는 데이터만 별도로 update 하면안되나? *

MySQL 내 조치에서는 문제점이 없었음! (약 150 rows 업데이트완료) 그러나 동기화이슈발생! (MSSQL TO MYSQL)

이유: SQLSERVER에서는 연결된 끝점(서버)의 테이블의 데이터를 UPSERT할때 기존데이터의 정합성을확인하기때문에 "행을 업데이트 할 수없습니다. 일부 값의 마지막으로 읽은 후에 바뀐 것 같습니다" 라는 ERROR MESSAGE 확인

그래서 원복처리하고 임시조치없이 빠르게 처리를 목표로함

Check4. 데이터는 어디서 받아오는데? *전체적인 데이터 구조는 다음과 같았음

단, 데이터를 끌어오는방식은 다음과 같음

SQLserver 에서 서버 연결하기 : https://wakeupslaves.tistory.com/21 SQLserver에서 SP로 왜 사용해야하는데? (성능) : https://devkingdom.tistory.com/323 Sqlserver에서 SP 짜는 예시 : https://devkingdom.tistory.com/324 sqlserver에서 스케줄러 거능 방법 : https://omty.tistory.com/30

** check5. 그렇다면 SQlserver 에서는 데이터가 깨지나?**

데이터가 안깨지는것을 확인! (예시 table)

*=그렇다면 뭔가 잡배치 동기화 진행시 문제가 생긴게 아닐까를 의심 *

##여기서 궁금증일수 있는거 MSSQL > MYSQL 어떻게 동기화 시키는데? ODBC를 이용하여! 혹은 JDBC 를 이용하여!

ODBC란? 엄청나게 많은 SQL회사 각각의 제품을 ODBC 연동 API로 쉽게 관리하는것!

HOW TO!

1. MySQL 연결 드라이버 다운로드 (드라이버 다운로드 : https://dev.mysql.com/downloads/connector/odbc/
2. ODBC 데이터 원본관리자에서 [시스템 DSN] 탭을 선택하고 [추가]버튼 클릭 연결 속성에서 대상이되는 (Destination db) 설정 그럼 요로코럼 나오는데 이제 이후 이 odbc를 msssql 에서 이용해서 연결해줘야함!
3. SQL Server의 SSMS 도구에서 [새 연결된 서버]를 실행하여 링크드서버를 등록 서버 유형은 [기타 데이터 원본]에서 공급자를 OLE DB Provider for ODBC Drivers를 선택 그다음 보안 탭에서 사용자 로그인 계정과 비밀번호를 입력 이후 링크드 서버 등록이 완료되면 ssms 에서 추가된 linked 서버 확인가능

물론 코드로 확인가능! 원격저장 프로시저에서 사용되는 링크드서버로그인 정보를 확인 exec sp_helplinkedsrvlogin 연결된 서버에서 테이블에 대한 정보 반환 exec sp_tables_ex 'WeboDB'

*Check.6 그렇다면 해결책은? * AS-IS : MySQL ODBC 5.3 ANSI Driver TO-BE : MySQL ODBC 5.3 Unicode Driver

무슨차이점인데? MySQL ODBC ANSI Driver는 시스템 로케일에 따라 ANSI 문자 세트를 사용하며, 주로 영어와 같은 기본 라틴 문자 세트를 사용하는 애플리케이션에 적합합니다.

MySQL ODBC Unicode Driver는 Unicode 문자 세트를 사용하여 전 세계 모든 문자를 지원하며, 다국어 및 국제화된 애플리케이션에 적합합니다.

참고* : 동일한 이슈 확인 https://forums.mysql.com/read.php?37,634839,634839#msg-634839

** FINAL. 해결완료!**

알고가야할것들 1.ANSI VS Unicode 2.ODBC? JDBC? 3.DB연동 관리 이대로 옳은가?

1. ANSI VS UNICODE

2. ODBC와 JDBC의 특징 비교

3. DB연동관리 이대로 옳은가? ㅎㅎㅎㅎㅎ 레거시...

• NL Join(Nested Loops join) : 중첩된 반복문, 랜덤 엑세스 2개 이상의 테이블에서 하나의 집합을 기준으로 순차적으로 상대방 row를 결합하여 원하는 결과를 조합하는 조인방식

조인해야할 데이터가 많지 않을 경우에 유용하게 사용됨

드라이빙 테이블로 한 테이블을 선정하고 이 테이블로부터 where절에 정의된 검색 조건을 만족하는 데이터를 걸러낸 후 이 값을 가지고 대상 테이블에 반복적으로 조인 조건을 만족하는 최종 결과값을 얻어냄

Driving Table이란 JOIN을 할 때 먼저 액세스 되어 ACCESS PATH를 주도하는 테이블을 Driving Table이라고 합니다. 즉, 조인을 할때 먼저 액세스 되는 테이블을 Driving Table이라고 하며 나중에 액세스 되는 테이블을 Driven Table이라고 합니다. 여기서 Driving Table은 옵티마이저가 결정하고 자연스레 Driving Table이 아닌 테이블은 Driven Table로 결정됩니다.

Nested Loops join의 장단점

1. 인덱스에 의한 랜덤 액세스에 기반하고 있기 때문에 대량의 데이터 처리시 적합하지 않음
2. driving table로는 데이터가 적거나 where절 조건으로 row의 숫자를 줄일 수 있는 테이블이어야함
3. driven table에는 조인을 위한 적절한 인덱스가 생성되어 있어야함
4. 선행 테이블의 결과를 통해 후행 테이블을 액세스 할때 랜덤 I/O가 발생

** NESTED LOOP JOIN의 성능 개선 포인트 ** 적절한 드라이빙 테이블의 선정 NESTED LOOP JOIN을 할때는 어떤 테이블이 먼저 액세스 되느냐에 따라서 속도의 차이가 크게 날 수 있습니다. 앞서 NESTED LOOP JOIN 동작 과정에서 살펴보았듯이 먼저 액세스 되는 Driving Table의 조건을 만족하는 결과 row수가 많다면 그만큼 반복해서 Driven Table에 접근해야 하므로 성능은 자연히 나빠질 것입니다. 따라서 NESTED LOOP JOIN방식을 채택하였다면 Driving Table의 선택이 매우 중요합니다. 그렇기에 Driving Table은 WHERE 절로 최대한의 데이터를 거를 수 있는 테이블이나 애초에 데이터의 양이 적은 테이블로 선정하는 것이 좋습니다.

• Hash Join : 해쉬값 비교, 인덱스 미존재 사용가능, 동등조인만 가능

• Sort Merge Join : 조회범위가 많을때 주로 사용하는 조인 방법론 양쪽 테이블에 각각 access하여 그 결과를 정렬하고 그 정렬한 결과를 차례로 scan해 나가면서 연결고리 조건으로 merge하는 방식 주로 조인 조건 칼럼에 인덱스가 없거나, 출력해야할 결과 값이 많을때 사용

인덱스 미존재 사용가능, 동등조인 비동등조인 가능

https://grafana.com/grafana/dashboards/6102-timescaledb-hypertables/

재해 복구 ✓ 전체 워크로드를 별도의 장소에 복사하는 것에 중심 ✓ 지진, 홍수 등의 재난 이벤트 ✓ 재해 복구의 목표는 비즈니스의 연속성

고 가용성 ✓ 일부 워크로드(워크로드 구성요소)의 서비스를 지속하는 것에 중심 ✓ 컴포넌트 실패, 네트워크 문제, 소프트웨어 문제, 시스템 과부하 등의 재해 복구 보다 구체적이고 작은 범위 ✓ 고 가용성의 목표는 시스템의 기능 수행 시간의 최대화

정상배포

Lambda • 코드를 실행하여 동작하는 서버리스 컴퓨팅 • EC2는 서버를 시작하고, 애플리케이션을 설치하고 서버가 계속 실행되며 사용자가 직접운영 해야함 • Lambda는 AWS에서 서버 운영에 필요한 모든 인프라를 관리 • Lambda 사용자는 코드를 입력하여 실행만 하면 됨 • Lambda 요청할 때에만 시스템을 사용하는 온디맨드 방식의 이벤트 중심의 실행 •** Lambda는 사용한 만큼만 비용을 지불 **(코드를 실행한 횟수와 실행한 시간으로 과금) • EC2는 Auto Scaling기능을 사용해 서버를 확장하지만 Lambda는 사용량이 늘어나면 자동으로 용량이 확 장되므로 용량 계획이 필요 없고 확장성이 뛰어남 • 다양한 프로그래밍 언어를 지원 (Node.js, Python, Java, C#, Ruby 등) • AWS Lambda 함수는 실행당 최대 15분 동안 하도록 구성 (1초에서 15분 사이의 값으로 제한 시간을 설정) • 동시에 처리가능한 실행 수는 1000건이며 요청을 통해 한도 증가 가능 • Lambda는 독립적으로 사용하지 않고 다른 서비스와 결합하여 사용됨 • 결합서비스: API Gateway, Kinesis, DynamoDB, SNS, SQS, S3, CloudFornt 등

Amazon Elastic Container Service(ECS) • Docker 컨테이너를 배포, 관리하는 컨테이너 오케스트레이션 서비스 _ Amazon Elastic Kubernetes Service(EKS) • AWS에서 Kubernetes를 실행하는 서비스 • Kubernetes는 대규모 컨테이너 애플리케이션을 배포, 관리하는 데 사용하는 오픈 소스 컨테이너 오케스트레이션 시스템 _ AWS Fargate • 서버리스 컨테이너 서비스 • 서버 프로비저닝, 패치 적용, 클러스터 용량 관리 또는 인프라 관리를 AWS에서 자동으로 수행 • Amazon Elastic Container Service(ECS) 및 Amazon Elastic Kubernetes Service(EKS)와 연동되는 서비스 • ECS와 EKS 모두 Fargate를 통해 프로비저닝된 컨테이너를 사용하여 자동으로 컨테이너 크기를 조정(Auto Scaling)하고 로드 밸런싱 가능 _ Amazon Elastic Container Registry(Amazon ECR) • Docker 등의 컨테이너 이미지를 공유, 배포 등의 관리 서비스 • ECR에서 공유된 이미지를 사용하여 ECS, EKS에서 컨테이너 구성

Amazon Elastic Container Service(ECS) • Docker 컨테이너를 지원하는 컨테이너 관리 서비스 • Amazon EC2 인스턴스의 관리형 클러스터에서 애플리케이션을 손쉽게 실행 가능 • ECS에서 애플리케이션 가용성을 유지 관리하고 애플리케이션 용량 요구 사항에 따라 컨테이너 규모를 확장하거나 축소 • CPU사용량, 메모리 사용량, 로드발란서 요청 수, EventBridge 이벤트, SQS Queue 와 결합하여 Auto Scaling 수행 가능 • Application Load Balancer 및 Network Load Balancer를 사용하여 트래픽 분산 가능

• ECS 시작 유형 (ECS Launch Type) ✓ Fargate 시작유형 ➢ 서버리스 방식으로 Amazon ECS 워크로드를 호스팅. 사용자가 EC2 인스턴스를 관리할 필요 없음 ✓ EC2 시작유형 ➢ Amazon ECS 클러스터를 등록하고 사용자가 직접 관리하는 EC2 인스턴스에서 컨테이너화 된 애플리케이션을 실행 ✓ ECS Anywhere ➢ Amazon ECS 클러스터에 등록하고 원격으로 관리하는 온프레미스 서버나 가상 머신(VM)에서 컨테이너화 된 애플리케이션을 실행

클러스터 생성 - autoscaling group (ec2)

인스턴스 런칭

이후 테스트 만들고 > 서비스 만들기!

ec2보안그룹생성

Amazon Elastic Kubernetes Service(EKS) • AWS에서 Kubernetes를 실행하는 서비스 • Kubernetes는 컨테이너(Docker 등) 애플리케이션의 배포, 확장 및 관리를 자동화하기 위한 오픈 소스 시스템 ** **• 배포 옵션 ✓ Amazon EKS : 자체 Kubernetes 컨트롤 플레인 또는 노드를 설치, 운영 및 유지 관리할 필요 없이 AWS에서 관 리 하는 AWS 클라우드에 Kubernetes 클러스터를 배포하는 옵션 ✓ Amazon EKS Anywhere : 온프레미스에서 Kubernetes 클러스터를 생성하고 운영할 수 있게 해주는 배포 옵션

노드 유형 (Node Types) ✓ EKS managed node groups ➢ EKS에서 자동으로 EKS 클러스터의 노드(Amazon EC2 인스턴스) 생성 및 관리 ➢ 사용자가 보안 및 업데이트 등의 일부분을 설정 및 관리 가능 ➢ 모든 관리형 노드는 Amazon EKS에서 관리하는 Amazon EC2 Auto Scaling 그룹의 일부로 프로비저닝됨 ➢ 관리형 노드 그룹을 생성할 때 온디맨드 또는 스팟 용량 유형을 선택할 수 있음 ✓ Self managed nodes ➢ 사용자가 직접 EKS 클러스터의 노드(Amazon EC2 인스턴스) 생성 및 관리 ➢ 온디맨드 또는 스팟 용량 유형을 선택할 수 있음 ✓ AWS Fargate ➢ 노드 관리를 AWS에서 담당 ➢ AWS에서 EKS의 모든 환경을 자동으로 관리

• AWS인프라 세트를 수동으로 프로비저닝하면 많은 노력이 소요됨 • 예, AMI생성, EC2생성, 보안그룹적용, Auto Scaling, ALB등의 세트를 수백 대 여러 리전에 배포한다면? • 수동 작업 말고 코드를 작성하여 자동화 한다면? • 코드를 통해 인프라를 프로비저닝, 관리 하는 서비스가 CloudFormation (Infrastructure as Code) • 코드를 통해 자동화 하여 AWS 인프라를 생성, 업데이트, 삭제 가능 • AWS인프라를 프로비저닝하는 비용과 시간을 절약 할 수 있음

• 구성 요소 ✓ Template : 인스턴스 유형, AMI ID, VPC, IP 주소 등의 인프라를 구성하기 위한 설정 값이 있는 JSON 또는 YAML 형식의 텍스트 파일로 이루어진 템플릿 ✓ Stack : Template을 사용하여 생성된 리소스 ✓ Change Set : Stack 리소스 변경 사항에 대한 세트

• DNS는 사람이 읽을 수 있는 도메인 이름(예: www.amazon.com)을 컴퓨터가 읽을 수 있는 IP 주소(예: 192.0.2.44)로 변환하는 시스템 • Route 53은 AWS에서 제공하는 DNS (Domain Name System) 서비스 • Route 53의 기능 ✓ 퍼블릭 도메인 구매 또는 이전 (.com, .net, .co.kr) ✓ AWS내부 VPC에서만 사용할 수 있는 프라이빗 도메인 생성 ✓ 라우팅 정책 적용(단순 라우팅, 가중치기반, 지리적위치, 지연시간, 장애조치, 다중값 응답)

Domain Level

DNS Resolution

Route53 – TTL DNS recursive resolver(ISP 업체가 운영하는 DNS 재귀적 리졸버)가 이 레코드에 관한 정보를 캐싱할 시간(초) 살아있는 시간이 300초!!

주요 DNS 레코드 유형 • DNS 레코드를 통해 트래픽을 도메인에 라우팅하는 방식을 Domain Name System(DNS)에 알려줌 • A - 도메인 네임을 IPv4 주소로 라우팅 (www.google.com -> 192.100.10.1) • AAAA - 도메인 네임을 IPv6 주소로 라우팅 • CNAME - 도메인 네임을 도메인 네임으로 라우팅 (site.google.com -> blog.google.com) • ALIAS - 도메인 네임을 AWS리소스로 라우팅 (www.google.com -> AWS EC2) • MX(Mail eXchanger) - 이메일 서버연동시 메일의 소유를 확인하기 위한 레코드 • NS(Name Server) – DNS레코드를 가진 DNS 서버를 식별 하기 위한 레코드 • SOA(Start Of Authority) – 도메인의 정보와 권한을 가진 레코드

퍼블릭도메인 생성

*DNS 서비스는 도메인 네임을 IP주소로 변환해서 반환함 레코드 값 : 이 IP주소를 가지고 도메인의 호스팅 영역에 있는 것 이 레코드 값에 따라 라우팅을 할수 있음 Route53의 DNS에는 다양한 라우팅 정책이 있음

1. 단순 라우팅 Route53 – 라우팅 정책 – 단순 라우팅 (Simple) • 도메인 네임 -> IP주소로 라우팅 • 라우팅 대상이 여러 개(예, 2개의 IP주소)인 경우 랜덤하게 라우팅 됨

인스턴스 웹서개 여러개~! 퍼블릭 ip주소

로드밸런서 통해서 연결

1개 로드밸런서 - 3개의 서버

로드밸런스로 alias 별칭 기능

2. 가중치 기반 라우팅 정책 Route53 – 라우팅 정책 – 가중치 기반 (Weighted) • 접속자가 요청하는 횟수의 가중치(%)를 기준으로 라우팅하는 방법 • 트래픽을 분산하거나 버전이 다른 애플리케이션을 테스트 하는 경우 유용

3. 지연시간 라우팅 • 가장 짧은 지연시간을 제공하는 리전으로 라우팅 하는 방법

4. 지리적 위치 라우팅 정책 • 지연시간(Latency)기반 라우팅은 사용자와 가까운 AWS리전으로 라우팅 • 지리적 위치 라우팅은 사용자가 속한 대륙이나 국가를 기준으로 라우팅 하는 방법 • 예, 한국 또는 아시아로 부터 오는 트래픽을 지정된 서버 IP로 라우팅

Route53 – 상태 검사 (Health Check) • 서버의 상태를 모니터링 하는 기능 • 상태확인을 모니터링하고 상태가 좋지 않은 경우 다른 서버로 라우팅 하는 장애조치를 구성할 수 있음

5. 장애 조치 (Failover) - 기본(Primary)라우팅이 실패하면 보조(Secondary)로 자동 라우팅 되는 방식

보조는 연결 하지 않아도됨

보안그룹을 바꿔서 비정상으로 만들기

레코드로 가면 - 보조 레코드로 라우팅

6. 다중값 응답 라우팅 정책 • 사용자가 요청 시 Route53 DNS에서 다수의 값을 반환하는 라우팅 • 리소스의 상태 확인을 하여 DNS에서 상태확인에 따라 정상인 경우만 IP주소를 전달

• 여러 AWS 계정을 중앙에서 관리 • Organizations는 글로벌 서비스 • 전체 계정을 관리하는 계정을 관리계정(Master Account)라고 함 • 그** 외의 계정은 멤버 계정이라고 부름** • 조직관리를 위해 OU(Organization Unit)이라는 조직 단위로 그룹화 하여 관리 • 그룹마다 서비스 제어 정책(SCP, Service Control Policy)를 적용해서 액세스를 제한 해야 하는 서비스를 제어할 수 있음 • 계정을 통합하면 결제를 한곳으로 통합 가능하고 볼륨 가격 할인을 받을 수 있음

*AWS Organizations - OU * • OU(Organization Unit)이라는 조직 단위로 그룹화 하여 관리 하는 기능 • 사용중인 AWS계정을 Root OU로 초대 하여 멤버 계정으로 만들 수 있음

AWS Organizations - SCP • 서비스 제어정책, Service Control Policy(SCP) • 계정에 대한 AWS 서비스 액세스 제어 정책 • 계정에 특정 AWS 서비스에 대한 액세스를 제한할 수 있음 • SCP 정책은 계정 또는 OU단위에 적용 할 수 있음 • OU에 적용하면 OU에 속한 계정과 OU는 모두 동일한 정책이 적용됨(정책상속)

기본적으로 root라는 계정이 있음

계정초대

조직단위 생성 및 권한 관리

서비스 제어 정책

CloudWatch • AWS 클라우드 리소스와 AWS에서 실행되는 애플리케이션을 위한 모니터링 서비스 • 지표를 수집 및 추적하고 로그 파일을 수집 및 모니터링하고 경보를 설정 • Amazon EC2 인스턴스, Amazon DynamoDB 테이블, Amazon RDS DB 인스턴스 같은 AWS 리소스뿐만 아니라 애플리케이션과 서비스에서 생성된 사용자 정의 지표 및 애플리케이션에서 생성된 모든 로그 파일을 모니터링 • 시스템 전반의 리소스 사용률, 애플리케이션 성능, 운영 상태를 파악

지표(Metrics) • AWS 클라우드 리소스 및 AWS에서 실행하는 애플리케이션을 모니터링 • CPU사용량, 네트워크 사용량 등의 AWS 서비스에 대한 측정값 • AWS 제품 및 서비스에 대한 지표가 자동으로 제공되며 자체 애플리케이션 및 서비스에서 생성된 사용자 정의 지표도 모니터링

대시보드(Dashboard) • AWS 리소스 및 사용자 정의 지표의 그래프를 한눈에 볼 수 있는 대시보드 기능

로그(Logs) • 애플리케이션에 대한 로그를 수집하는 기능 • Lambda, CloudTrail, ECS, API Gateway 등의 AWS서비스에 대한 로그를 수집 • AWS서비스 이외에도 Log Agent를 설치하여 로그를 수집 가능 • 로그를 S3, Kinesis Data Stream, Kinesis Data Firehose, AWS Lambda로 전송 가능

경보(Alarms) • 지표값에 대한 알림을 생성하는 기능 • 예, Amazon EC2 인스턴스 CPU 사용률, Amazon ELB 요청 지연 시간, Amazon DynamoDB 테이블 처리량, Amazon SQS 대기열 길이, AWS 청구서 요금에 대한 알림 • 생성된 알림을 이메일을 전송하거나, SQS 대기열에 게시하거나, Amazon EC2 인스턴스를 중단 또는 종료하거나, Auto Scaling 정책을 실행하도록 경보를 설정

Amazone EventBridge • 거의 실시간으로 이벤트를 자동 전송 하는 서비스 • 90개 이상의 AWS 서비스에서 이벤트를 자동 수집 • SaaS 애플리케이션 및/또는 AWS 서비스의 이벤트에 반응하는 애플리케이션을 구축하려고 할 때 사용 • 예, 이벤트 소스에 대한 EventBridge 규칙을 구성하여 Amazon SNS 주제에 메시지를 게시하여 관리자에게 이메일로 알림

CloudTrail&Config

CloudTrail •** AWS 계정이 수행하는 작업에 대해 로그를 기록하는 서비스** • AWS 내에서 수행되는 모든 계정 활동에 대해 기록이 됨 • 로그는 CloudWatch Logs 또는 S3 버킷에 저장 가능 •** CloudTrail은 모든 계정에 기본으로 활성화 되어 있음** • CloudTrail 로그 파일은 KMS 사용하여 암호화 가능 • CloudTrail Insight를 사용하여 AWS 계정에서 비정상적인 활동을 감지 가능 • CloudTrail 로그 파일 무결성 검증 기능을 사용하여 CloudTrail에서 로그 파일을 지정된 Amazon S3 버킷으로 전송한 이후로 CloudTrail 로그 파일이 그대로 유지되거나, 삭제되거나, 수정되었는지 확인 가능 • AWS 계정의 거버넌스, 규정준수, 운영감사, 위험감사에 활용

Config **• AWS 리소스 구성 변경 사항을 로그기록 하는 기능** • 버킷액세스 변경, 보안그룹 설정변경, ALB 설정 변경 등 모든 변경 사항에 대해 로그 수집 가능 • 수집된 로그는 분석, 보안감사를 위해 S3 버킷으로 저장 가능 • 리소스 구성변경이 발생되면 알림을 SNS주제로 전송 가능 • Config 규칙을 설정해서 AWS리소스 구성이 규정준수를 하고 있는지 평가 가능

AWS Systems Manager • AWS 클라우드에서 실행되는 애플리케이션 및 인프라를 관리하는 데 도움이 되는 기능 모음 • 여러 AWS 서비스의 운영 데이터를 중앙집중화하고 AWS 리소스 전체에서 작업을 자동화 가능 • Amazon EC2 인스턴스, 엣지 디바이스, 온프레미스, 또는 가상 머신(VM)에 SSM Agent를 설치하여 Systems Manager에서 리소스를 업데이트, 관리 및 구성 가능 • System Manager 기능

애플리케이션 관리 ✓ Application Manager ** ➢ 애플리케이션의 컨텍스트에서 운영 데이터(예: 개발 상태, Amazon CloudWatch 경보, 리소스 구성 및 운영 문제)를 보고, 패치 적용 및 자동화 런북 실행과 같은 수정 작업을 수행 ✓ **AppConfig ➢ 애플리케이션 구성을 생성, 관리 및 빠르게 배포 ✓** Parameter Store **➢ 구성 데이터 관리 및 암호 관리를 위한 스토리지. ➢ 암호, 데이터베이스 문자열, (AMI) ID, 라이선스 코드와 같은 데이터를 파라미터 값으로 저장 ➢ 값을 일반 텍스트 또는 암호화된 데이터로 저장 가능

변경 관리 ✓ Automation : ➢ 유지 관리 및 배포 태스크를 자동화. ➢ AMI 생성 및 업데이트, 드라이버 및 에이전트 업데이트를 적용, Windows Server 인스턴스에서 암호를 재설정, Linux 인스턴스에 서 SSH 키를 재설정, OS 패치 또는 애플리케이션 업데이트를 적용 ✓ Change Manager : ➢ 애플리케이션 구성 및 인프라에 대한 운영 변경을 요청, 승인, 구현 및 보고하기 위한 엔터프라이즈 변경 관리 프레임워크 *✓ Maintenance Windows : * ➢ 운영 체제 패치, 드라이버 업데이트, 소프트웨어 또는 패치 설치와 같이 노드에서 중단 가능성이 있는 작업 수행 시기에 대한 일정 을 정의

노드 관리 ✓ Fleet Manager : ** ➢ 온프레미스 또는 클라우드에서 실행하는 플릿을 관리. ➢ 하나의 콘솔에서 전체 서버 플릿의 상태 및 성능 상태를 볼 수 있으며 개별 노드(서비스, 장치 또는 기타 리소스)로 액세스하여 콘솔에서 디스크 및 파일 탐색, 로그 관리, Windows 레지스트리 작업, 사용자 관리와 같은 일반적인 시스템 관리 태스크를 수행 ✓ Session Manager :** ➢ 인바운드 포트를 열고, Bastion 호스트를 유지하고, SSH 키를 관리할 필요 없이 보안성과 감사 가능성을 갖춘 엣지 디바이스 및 인스턴스 관리 기능을 제공. ➢ 인스턴스 원격접속 기능 *✓ Patch Manager : * ➢ 대규모 클라우드 그룹 또는 온프레미스 인스턴스 및 엣지 디바이스에서 운영 체제 및 소프트웨어 패치를 자동으로 선택하고 배포

운영관리 *✓ Explorer * ➢ AWS 리소스에 대한 정보를 보고하는 사용자 지정 가능한 운영 대시보드 *✓ OpsCenter * ➢ OpsItem이라는 운영 문제를 집계하고 표준화하는 동시에 진단 및 해결에 도움이 되는 상황에 맞는 데이터를 제공 ➢ 이벤트, 리소스, 계정, Config 변경사항, CloudTrail로그, CloudWatch정보 등 *✓ Incident Manager * ➢ AWS 호스팅 애플리케이션에서 발생하는 인시던트를 관리. ➢ 사용자 참여, 에스컬레이션, 실행서, 대응 계획, 채팅 채널 및 인시던트 후 분석을 결합하여 팀이 인시던트를 더 빠르게 분류하고 애플리케이션을 정상 상태로 되돌릴 수 있도록 지원

AWS Cognito • 애플리케이션에 대한 로그인 및 인증을 제공하는 기능 • 웹과 모바일 앱에 빠르고 사용자 가입, 로그인 및 액세스 제어 기능 • 애플, 구글, 페이스북 등의 계정과 통합 가능

AWS Single Sing-On(SSO) • SSO는 중앙에서 관리하는 하나의 계정으로 여러 애플리케이션에 로그인하는 기능 • AWS Organization, Active Directory, SAML 2.0 과 통합 가능 • SAML은 인증을 지원하기 위한 표준 데이터 포맷

Key Management Service(KMS)

암호화 (Encryption) • 데이터를 도난이나 해킹으로부터 보호하기 위한 방법 • 3가지 암호화 방법 ✓ 전송중 암호화: 네트워크로 전송하는 트래픽을 암호화 ✓ 서버측 암호화: 서버에 저장된 데이터를 암호화 ✓ 클라이언트측 암호화: 데이터를 보내기전에 암호화

Key Management System (KMS) 소프트웨어 방식의 암호화 • 암호화 키를 생성 및 관리하는 서비스 • 키(Key)는 암호화를 하고 암호를 해독하는 역할 • AWS에서 암호화에 관련된 서비스는 대부분 KMS와 관련되어 있음 • EBS, S3, RDS등의 AWS 서비스 데이터 암호화에 KMS 사용 • 키를 자동교체 하는 기능 지원 • 감사를 위해 AWS CloudTrail과도 통합되어 모든 키 사용에 관한 로그를 제공

• 3가지 유형의 키 제공 고객 관리형 키(Customer managed keys) ** ✓ 사용자가 생성, 소유 및 관리하는 AWS 계정의 KMS 키 ✓ 키 정책, IAM 정책 및 권한 부여, 암호화 구성요소 등의 제어 권한을 사용자가 가짐 *AWS 관리형 키(AWS managed keys) * ✓ AWS 서비스가 고객의 계정에서 고객 대신 생성, 관리 및 사용하는 KMS 키 ✓ 키 정책, 키 삭제 등의 제어 권한이 없거나 제한이 있음 **AWS의 키(AWS owned keys) ✓ AWS 서비스가 여러 AWS 계정에서 사용하기 위해 소유하고 관리하는 KMS 키 모음

** CloudHSM** 하드웨어 방식의 암호화 • KMS는 AWS에서 관리하는 소프트웨어 방식의 암호화 • CloudHSM은 AWS에서 제공하는 하드웨어 암호화 장비를 통한 하드웨어 방식의 암호화 • KMS와 다르게 암호화 키관리는 사용자(클라이언트)가 해야함 • 고객 제공 키(SSE-C, Customer Provided Keys)에 적합한 방식

KMS 다중 리전 키 (Multi-Region Keys) • 여러 리전에서 동일한 키를 가지고 있는 것 • 다중 리전 키의 각 세트에는 동일한키 구성 요소와 키 ID가 있으므로 AWS KMS를 다시 암호화하거나 크로스 리전 호출을 수행하지 않고 하나의 AWS 리전에서 데이터를 암호화하고 다른 AWS 리전에서 복호화 가능 • 예를 들어 아시아 태평양(시드니)의 복제본 키를 사용하여 데이터를 암호화하고, 데이터를 미국 서부(오레곤)로 이동한 다음, 미국 서부(오레곤)의 복제 키를 사용하여 암호를 복호화 • 동일한 키를 사용하면 다른 리전의 데이터를 서로 다른 키로 다시 암호화 할 필요가 없음 • Amazon DynamoDB 글로벌 테이블 및 DynamoDB 암호화, 멀티 리전의 복제된 S3 버킷의 암호화 등에 사용 가능

권한정의 가능 - 사용자나 역할을 정할 수 있음

키를 사용할수 있는 사람을 별도로 지정할수도 있음

키를가지고 암호화로 사용하면 됨

고객관리형키는 키의 관리자, 삭제, 액세스 컨트롤이 가능함

Secrets Manager • 보안 정보(자격증명)를 중앙 집중식으로 저장, 검색, 액세스 제어, 교체, 감사 및 모니터링하는 서비스 • 보안정보는 데이터베이스 자격 증명, 온프레미스 리소스 자격 증명, SaaS 애플리케이션 자격 증명, 타사 API 키 및 Secure Shell(SSH) 키 등이 될 수 있음 • 보안정보(자격증명,Secret)을 유지하는 방법 ✓ 사용자가 소유하고** AWS Key Management Service(KMS)에 저장한 암호화 키를 사용해** 저장 보안 정보를 암호화 ✓ 사용자는** AWS Identity and Access Management(IAM) 정책을 사용하여 보안 정보에 대한 액세스를 제어 ✓ 사용자가 보안 정보를 검색하면 Secrets Manager가 해당 보안 정보를 복호화하여 TLS를 통해 안전하게 로컬 환경으로 전송 • 보안정보(자격증명)을 자동으로 교체 및 관리 가능** ✓ Amazon RDS, Amazon Redshift 및 Amazon DocumentDB와 기본적으로 통합되며 사용자 대신 이러한 데이터베이스 자격 증명을 자동으로 교체 ✓** Lambda의 코드와 통합하여 30일, 60일 등의 자격증명 자동교체 날짜를 지정하여 실행가능**

AWS Certificate Manager(ACM) • SSL/TLS 인증서를 중앙에서 관리하는 서비스 • AWS 리소스에 사용할 공인 및 사설** SSL/TLS(Secure Sockets Layer/전송 계층 보안) 인증서**를 관리 및 배포 할 수 있음 • SSL/TLS 인증서는 ACM에서 자동으로 갱신 됨

Shield & WAF

Shield : AWS웹 애플리케이션을 DDoS(Distributed Denial of Service) 공격으로부터 보호 DDoS(Distributed Denial of Service) 공격 수십 대에서 많게는 수백만 대의 PC를 원격 조종해 특정 웹사이트에 동시에 접속시킴으로써 단 시간 내에 과부하를 일으키는 행위

Shield는 2가지 유형을 제공 Shield Standard ✓ 모든 AWS사용자에게 적용되어 있음(무료) ✓ SYN/UDP Flood등 기본적인 DDoS공격 보호

Shield Advanced ✓ 스탠다드 서비스보다 많은 보호 제공 (유료) ✓ EC2, ELB, CloudFront, Route53등에서 정교한 DDoS 보호제공

WAF – Web Application Firewall ** • 웹 애플리케이션을 보호하는 방화벽 • **HTTP (OSI 7계층)에서 동작 • Application Load Balancer, API Gateway, CloudFront에 적용 가능 • WAF의 Web ACL(Access Control List)를 통해 정의할 수 있는 기능 ✓ 악성 IP 주소차단 ✓ 특정 국가의 엑세스 제어(차단) ✓ SQL Injection, Cross-Site-Scripting(XSS) 방어 ✓ 속도기반규칙(Rate-based rules)으로 DDoS공격방어 ** AWS Firewall Manager** AWS Organizations의 여러 계정과 애플리케이션의 방화벽 규칙을 중앙에서 구성 및 관리할 수 있는 보안 관리 서비스 • 중앙의 관리자 계정에서 방화벽 규칙을 수립하고, 보안 정책을 생성하며, 전체 인프라에 걸쳐 중앙에서 적 용 가능 • 중앙에서 여러 AWS 계정 및 리소스에 걸쳐 있는 Amazon VPC에 대해 AWS WAF 규칙, AWS Shield Advanced 보호, 보안 그룹 및 AWS Network Firewall 규칙 및 AWS Marketplace 서드 파티 방화벽 규칙 및 Amazon Route 53 Resolver DNS Firewall 규칙을 중앙에서 구성 가능

###실습 필요

GuardDuty, Macie, Inspector

Amazon GuardDuty** • AWS 계정 및 워크로드에서 악의적 활동을 모니터링하고 상세한 보안 결과를 제공하는 위협 탐지 서비스 • 공격자 정찰, 인스턴스 침해, 계정 침해 및 버킷 침해와 같은 위협을 파악하도록 지원하여 AWS 계정, 워크로드 및 데이터에 대한 광범위한 보호를 제공 • 보안 탐지 결과를 GuardDuty 콘솔과 Amazon CloudWatch Events로 전달하여 알림을 토대로 조치를 취할 수 있고 기존 이벤트 관리 또는 워크로드 시스템에 통합 가능

실제 방어는 할 수는 없음

** Amazon Macie** • 데이터 보안 및 데이터 프라이버시 서비스로서, 기계 학습 및 패턴 일치를 활용하여** AWS에서 민감한 데이터를 검색하고 보호** • 이름, 주소 및 신용 카드 번호와 같은 개인 식별 정보(PII)를 포함하여 대규모의 점점 증가하는 민감한 데이터 유형 목록을 자동으로 감지 • S3 버킷에 기계 학습 및 패턴 매칭 기법을 적용하여 개인 식별 정보(PII)와 같은 민감한 데이터를 식별하고 사용자에게 알릴 수 있음

** Amazon Inspector** • Amazon Elastic Compute Cloud(EC2) 및 컨테이너 워크로드에서 소프트웨어 취약성과 의도하지 않은 네트워크 노출을 지속적으로 스캔하는 자동화된 취약성 관리 서비스

SQS Queue • SQS는 Poll 방식으로 메시지를 전송 (Consumer가 메시지를 요청하여 받는 방식) • Consumer 가 메시지를 소비하면 SQS Queue에서는 메시지가 삭제됨 ** SQS - 표준대기열 vs FIFO 대기열**

SQS – 배달 못한 편지 대기열 **(DLQ, Dead Letter Queue)** • 일반적으로 메시지는 처리될 때까지 계속 메시지를 보냄 • 이 경우 다른 메시지처리까지 영향을 줄 수 있음 • 일정 횟수 이상 시도 후 처리되지 못한 메시지는 DLQ로 이동하여 보관

SQS - 제한 시간 초과/표시 제한 시간(Visibility Timeout) • 메시지소비자가 대기열에서 메시지를 수신하고 처리하면 메시지는 계속 대기열에 있음 • 연결 문제 또는 메시지소비자의 애플리케이션 문제로 인해 메시지를 다시 수신해야 할 수 있기에 Amazon SQS에서 메시지를 자동으로 삭제하지 않음 • 소비자는 메시지를 수신하고 처리한 후 대기열에서 이 메시지를 삭제해야 함 • 제한 시간 초과는 메시지 소비자가 메시지를 수신 후 다른 소비자가 메시지를 다시 처리하지 못하게 하기위한 기간 **(SQS에서 다른 소비자가 메시지를 수신하고 처리할 수 없도록 차단하는 기간)** • 메시지의 기본 제한 시간은 30초 (최소는 0초, 최대 시간은 12시간)

**SQS – Short Polling(짧은 폴링) vs. Long Polling(긴 폴링) • 폴링은 SQS Queue로부터 메시지를 가져오는 방법 (Consumer가 메시지를 요청) • Short Polling(디폴트 값)은 메시지 queue가 비어 있어도 메시지 소비자의 메시지 요청을 즉시 반환하는 방법 • Long Polling은 queue에 메시지가 비어있으면 메시지가 도착할 때까지 또는 메시지 수신 대기시간 (Receive message wait time)이 완료 될 때 까지 메시지 요청을 기다림 • 메시지 수신 대기시간은 1초 부터 최대 20초까지 설정 가능 • Long Polling을 사용하면 빈 응답의 수를 제거하여 Amazon SQS 사용 비용을 절감할 수 있음 • 예, API 요청 수를 감소시켜 효율성 향상 및 애플리케이션의 지연시간 감소

Simple Notification Service (SNS) • 메시지 전송 서비스 • 게시자(Publishers)에서 구독자, Subscriber(생산자 및 소비자 라고도 함) 로 메시지를 전송 • 애플리케이션 간(A2A) 및 애플리케이션과 사용자 간(A2P) 통신 • SNS는 Push 방식으로 메시지를 전송(Subscriber에게 메시지를 보내는 방식) • 전송 순서

1. SNS에서 주제(Topic) 생성
2. 구독 생성(메시지를 받는 사람)
3. 메시지 생성
4. 구독자에게 메시지 전달

SNS + SQS Fan Out • Amazon SQS와 Amazon SNS는 둘 다 AWS 내 메시징 서비스 • Amazon SNS를 사용하면 애플리케이션에서 정기적으로 업데이트를 확인하거나 ‘폴링(Polling)'할 필요 없이** ‘푸시(Push)' 메커니즘을 통해 다수의 구독자에게 메시지를 보낼 수 있음 • **Amazon SQS는 분산 애플리케이션에서 폴링 모델을 통해 메시지를 교환하는 데 사용되는 메시지 대기열 서비스. 이 서비스를 통해 송신 구성 요소와 수신 구성 요소를 분리

SNS FIFO Topic • SNS FIFO 주제는 메시지가 주제에 게시된 정확한 순서로 구독된 Amazon SQS FIFO 대기열에 메시지를 전달 • SQS FIFO 대기열을 사용하면 대기열의 소비자는 메시지가 대기열로 전송된 정확한 순서로 메시지를 수신 • 예, 은행 거래 로그, 주식 시세 표시기, 항공편 추적기, 가격 업데이트, 뉴스 브로드캐스팅, 인벤토리 관리

** Kinesis**

실시간 스트리밍 데이터를 손쉽게 수집, 처리 및 분석 하는 서비스 • 비디오, 오디오, 애플리케이션 로그, 웹 사이트 클릭스트림 및 IoT 텔레메트리 데이터와 같은 실시간 데이 터를 수집 • 데이터가 수집된 후에야 처리를 시작할 수 있는 것이 아니라 데이터가 수신되는 대로 처리 및 분석

• Kinesis 서비스 유형 ✓** Kinesis Data Streams: 데이터 스트림을 수집, 저장 및 처리 ✓ Kinesis Data Firehose: 데이터 스트림을 AWS 데이터 스토어에 로드 (저장기능은 없음) ✓ **Kinesis Data Analytics: SQL 또는 Apache Flink로 데이터 스트림 분석 ✓ Kinesis Video Streams: 비디오 스트림을 수집, 저장 및 처리

Kinesis Data Streams • 데이터 스트림을 캡처, 처리 및 저장할 수 있는 스트리밍 데이터 서비스 • 실시간(Realtime) 서비스 • Amazon DynamoDB, Amazon Aurora, Amazon CloudWatch 및 AWS IoT Core와 같은 AWS 서비스의 기존 리소스에서 데이터를 보낼 수 있음 • 스트리밍 데이터를 AWS Lambda, Amazon Kinesis Data Analytics, Amazon Kinesis Data Firehose 등으로 전송 • 데이터 스토리지가 있음 (1일 ~ 365일 사이의 기간으로 데이터 보관)

Kinesis Data Firehose (ETL 솔루션임) • 스트리밍 ETL(extract, transform, and load) 솔루션 • 스트리밍 데이터를 데이터 스토어와 분석 도구에 로드 • 스트리밍 데이터를 캡처하고 변환한 후 Amazon S3, Amazon Redshift, Amazon OpenSearch Service 및 Splunk로 로드하여 비즈니스 인텔리전스 도구 및 대시보드를 통해 거의 실시간으로 분석 • 거의 실시간(Near Realtime) 서비스 • 데이터 스토리지가 없음 (데이터를 저장하지 않음)

Kinesis Data Analytics • SQL 또는 Apache Flink를 사용하여 실시간으로 스트리밍 데이터를 변환하고 분석 • Apache Flink는 데이터 스트림 처리를 위한 오픈 소스 프레임워크 및 엔진 • Amazon Kinesis Data Streams 및 Amazon Kinesis Data Firehose 스트리밍 소스로부터의 데이터 수집 가능

Amazon MQ • Apache ActiveMQ 및 RabbitMQ용 관리형 메시지 브로커 서비스 • JMS 및 NMS와 같은 업계 표준 API와 AMQP, STOMP, MQTT, WebSocket 등을 비롯한 메시징 프로토콜을 지원 • 활성(Active)/대기(Standby) 브로커 배포모드를 지원하여 고가용성 및 장애조치 가능 • 클라우드 기반의 애플리케이션은 SNS, SQS 메시지 서비스를 사용하는 것을 추천 (스케일링, 고가용성, 더 나은 성능, 더 많은 기능 등) • 기존에 Apache ActiveMQ 및 RabbitMQ 등의 애플리케이션을 온프레미스에서 사용하고 있고 코드의 변경 없이 클라우드로 마이그레이션 할 경우 Amazon MQ 사용

API Gateway • 개발자가 API를 생성, 게시, 유지 관리, 모니터링 및 보안 유지를 할 수 있게 하는 서비스 • API: Application Programming Interface • RESTful API 및 WebSocket API를 지원 • 예, 애플리케이션이 API를 통해 백엔드 시스템 및 데이터에 액세스 하여 통신

*AWS Step Functions & Amazon AppFlow *

• 시각적 워크플로(workflow) 구축 서비스 • 애플리케이션의 구성 요소를 단계별로 배열 하여 다단계 애플리케이션을 구축하고 실행 • 사용 예 ✓ 데이터 처리: 여러 데이터베이스의 데이터를 통일된 보고서로 통합, 분석 및 기계 학습 워크플로 조정 ✓ DevOps 및 IT 자동화: 지속적 통합 및 지속적 배포를 위한 도구 구축, 인프라의 변경에 자동으로 대응하는 이벤트 중심 애플리케이 션 생성 ✓ 전자 상거래: 주문 처리, 재고 추적 등 프로세스 자동화 ✓ 웹 애플리케이션: 강력한 사용자 등록 프로세스와 로그인 인증 구현

Amazon AppFlow • Software-as-a-Service(Saas) 애플리케이션과 AWS 간에 안전하게 데이터를 전송할 수 있게 해주는 서비스 • SaaS 애플리케이션과 데이터를 교환하기 위해 AWS 서비스용 API 커넥터를 구축(코드 작성)하고 관리할 필요 없음 • 소스: Salesforce, SAP, Zendesk, Slack 및 ServiceNow와 같은 서비스형 소프트웨어(SaaS) 애플리케이션 • 대상: Amazon S3 및 Amazon Redshift와 같은 AWS 서비스 • 일정에 따라, 비즈니스 이벤트에 대한 응답으로 또는 온디맨드로 데이터 플로우를 실행 가능

Amazon Athena • 표준 SQL을 사용해 Amazon S3에 저장된 데이터를 분석할 수 있는 쿼리 서비스 • Athena로 데이터를 로드 할 필요 없이 S3에 저장된 데이터를 직접 사용 • CSV, JSON, ORC, Avro 또는 Parquet와 같은 다양한 종류의 데이터 형식을 지원 • 예, S3에 csv 데이터 파일을 저장하여 Athena를 사용해 SQL 쿼리를 하는 비용 효율적인 솔루션 구축 • Athena 연합 쿼리를 사용하여 Amazon CloudWatch Logs, Amazon DynamoDB, Amazon DocumentDB, Amazon RDS, JDBC 호환 관계형 데이터베이스(Apache 2.0 라이선스에 따른 MySQL, PostgreSQL 등)와 같은 데이터 원본에 저장된 데이터에 대해 SQL 쿼리 수행 가능 • Amazon QuickSight와 통합하여 쿼리된 데이터를 시각화 할 수 있음

Amazon Redshift • 데이터웨어하우스 서비스 • 데이터 웨어하우스는 의사 결정을 위한 정보의 집합 • 데이터 웨어하우스는 여러 소스로부터 얻은 구조화되거나 반 구조화된(정형 및 반정형) 대량의 데이터를 중앙 집중화 및 통합 하여 데이터 웨어하우스의 분석 기능을 통해 데이터에서 귀중한 비즈니스 통찰력을 도출 하여 의사결정을 개선 • Amazon S3, Amazon RDS, Amazon DynamoDB, Amazon Kinesis Data Firehose, Amazon EMR, AWS Glue, AWS Data Pipeline 및 Amazon EC2 또는 온프레미스의 모든 SSH 지원 호스트를 비롯하여 다양한 데이터 소스에서 Amazon Redshift로 데이터를 로드 • 비즈니스 애널리스트, 데이터 엔지니어, 데이터 사이언티스트 및 의사 결정권자는 비즈니스 인텔리전스(BI) 도구(예, Amazon QuickSight), SQL 클라이언트 및 기타 분석 응용 프로그램을 통해 데이터에 액세스

Amazon OpenSearch Service (Amazon Elastic Search Service) • OpenSearch는 Elasticsearch에서 파생된 오픈 소스 분산 검색 및 분석 제품 • 로그 분석, 실시간 애플리케이션 모니터링 및 웹사이트 검색 등을 쉽게 수행할 수 있게 해주는 서비스 • 다양한 소스에서 스트리밍 데이터를 Amazon OpenSearch Service 도메인으로 로드 ✓ Amazon Kinesis Data Firehose 및 Amazon CloudWatch Logs와 같은 일부 소스는 OpenSearch Service 를 기본으로 지원 ✓ Amazon S3, Amazon Kinesis Data Streams 및 Amazon DynamoDB와 같은 다른 소스는 AWS Lambda 함수를 이벤트 핸들러로 사용하여 로드

AWS QuickSight • 클라우드 기반의 비즈니스 인텔리전스(BI) 도구 • 대시보드, 그래프 등의 시각화를 통한 데이터 분석을 통해 의사결정을 도와주는 서비스 • AWS 데이터, 타사 데이터, 빅 데이터, 스프레드시트 데이터, SaaS 데이터, B2B 데이터 등의 다양한 데이터 소스와 연결 가능 • CSV 파일과 Excel 파일을 업로드하고, Salesforce와 같은 SaaS 애플리케이션에 연결하고, SQL Server, MySQL 및 PostgreSQL과 같은 온프레미스 데이터베이스에 액세스하고, Amazon Redshift, Amazon RDS, Amazon Aurora, Amazon Athena 및 Amazon S3와 같은 AWS 데이터 소스를 원활하게 검색

AWS Glue • 데이터 분석을 위한 ETL(Extract, Transform and Load, 추출, 변환 및 로드 ) 서비스 • 다양한 소스에서 데이터 검색 및 추출, 데이터 강화, 정리, 정규화 및 결합, 데이터베이스, 데이터 웨어하우스 및 데이터 레이크에 데이터 로드 및 구성 등의 여러 작업을 포함

AWS Lake Formation • 데이터 레이크 서비스 • 데이터 레이크는 조화되거나 반구조화되거나 구조화되지 않은 모든 유형의 대량의 데이터를 저장, 처리, 보호하기 위한 중앙 집중식 저장소

Amazon EMR(Elastic MapReduce) • 클라우드 빅데이터 플랫폼 • MapReduce는 분산 병렬처리 컴퓨팅 모델의 이름 • EMR은 빅데이터 플랫폼인 Hadoop 클러스터를 손쉽게 생성해 주는 서비스 •** Apache Spark, Apache Hive 및 Presto와 같은 오픈 소스 프레임워크를 사용** • 데이터 처리를 위한 EMR 클러스터(수십 ~ 수백 대의 EC2 인스턴스)를 자동으로 구성하고 확장 및 축소를 하는 기능을 함 • 머신러닝, 빅데이터 처리 등에 사용

관계형 데이터베이스 (RDS) • 데이터들이 서로 연결되어 관계들로 구성된 데이터베이스 • 데이터를 테이블 형태('스키마'라고 부른다)로 관리 하여 관계를 통해서 연결된 여러 테이블에 분산 • SQL 언어를 사용하여 데이터를 검색 및 조작 • 데이터를 중복없이 다루기에 데이터 무결성이 보장 • 관계를 맺고 있는 데이터가 자주 변경 되는 애플리케이션에서 주로 사용 • Amazon RDS, Amazon Aurora 가 대표적인 서비스

NoSQL = non-SQL = non relational database • NoSQL = non-SQL = non relational databases • 관계 구조를 갖지 않는 데이터베이스 관리 시스템 • 관계 구조가 없기에 대규모의 데이터를 유연하게 처리할 수 있는 것이 강점 • NoSQL 데이터 베이스는 Key-Value Database, Document Database, Column Family Database, Graph Database 종류가 있음 • 대표적인 AWS Key-Value 데이터 베이스는 Amazon DynamoDB

인 메모리 데이터베이스

• 디스크가 아닌 주 메모리에 데이터를 보유하고 있는 데이터베이스 • 디스크 검색보다 자료 접근이 훨씬 빠른 것이 가장 큰 장점 • 데이터 양의 빠른 증가로 데이터베이스 응답 속도가 떨어지는 문제를 해결할 수 있는 대안 • Amazon Elasticache 가 대표적인 AWS 인-메모리 데이터 베이스 서비스

** RDS** • 관계형 데이터 베이스 서비스 (Relational Database Service) • Aurora, PostgreSQL, MySQL, MariaDB, Oracle, SQL Server 등의 RDS 엔진을 AWS에서는 제공 • SQL 쿼리를 이용하는 데이터 베이스 용도에 사용 • DB 다운타임 없이 스토리지 용량만큼 자동으로 확장 가능 (Storage Auto Scaling) • 3가지 데이터베이스 스토리지 유형 제공 ✓ 범용 SSD 스토리지: 일반적인 용도 ✓ 프로비저닝된 IOPS SSD 스토리지: 빠른 I/O가 필요한 경우 사용 ✓ 마그네틱 스토리지: 액세스 빈도가 낮은 경우 사용

*RDS 백업 *(• Amazon RDS는 DB 인스턴스 백업 및 복구를 위한 두 가지 방법, 즉 자동 백업 및 데이터베이스 스냅샷(DB스냅샷)을 제공)

자동백업 (Automated backup) ✓ 백업을 수행하는 백업 기간을 설정 ✓ 백업 보존 기간은 1일 부터 최대 35일까지 설정 가능 ✓ DB 인스턴스를 특정 시점으로 복구 가능 (Point in time recovery) ✓ RDS는 DB 트랜잭션 로그를 5분마다 백업 하므로 가장 오래된 시점 부터 5분전까지 시점으로 복구 가능 ✓ 자동백업을 비활성화 하려면 보존기간을 0으로 설정

데이터베이스 스냅샷(DB Snapshots) ✓ 사용자가 수동으로 스냅샷 생성가능(수동 백업) ✓ 사용자가 지정한 만큼 백업을 보존할 수 있음 (스냅샷 보존기간 없음) • 특정 시점으로 복구 또는 DB 스냅샷에서 복구 작업을 수행하면 새로운 엔드포인트를 가지는 새 DB 인스턴스가 생성 됨(필요한 경우 기존 DB 인스턴스를 삭제할 수 있음) • Amazon RDS DB 스냅샷과 자동 백업은 S3에 저장

RDS 보안 • SSL/TLS를 사용하여 애플리케이션과 DB 인스턴스 간의 전송 중 암호화 가능 • AWS Key Management Service(KMS)를 통해 관리하는 키를 사용하여 모든 데이터베이스 엔진에 대한 저장 중 암호화 가능 • 암호화 되지 않은 DB 인스턴스 암호화

1. RDS 인스턴스 스냅샷 생성
2. 암호화 된 스냅샷 복사본 생성
3. 암호화 된 스냅샷에서 RDS 인스턴스 복원 • 암호/패스워드 이외에 IAM 사용자 및 역할을 통해 데이터베이스 인증 적용 가능 • RDS에 보안그룹을 연결하여 IP주소, EC2 인스턴스에 대한 데이터베이스 연결 제어 가능 • RDS Audit Logs 기능을 사용해 보안 감사에 활용 가능 (로그 데이터 장기 보관을 위해 로그를 CloudWatch Logs에 보낼 수 있음)

RDS - 읽기 전용 복제본 (Read Replica)

• 읽기만 가능한 DB 인스턴스의 복제복을 여러 개 만드는 기능 • 읽기를 별도로 분리하여 성능을 향상 • 원본 DB의 읽기/쓰기 트래픽을 분산시켜 성능 향상 • SQL쿼리를 많이 하는 리포팅 툴의 경우 읽기 복제본으로 연결하여 쿼리 성능 향상 • 읽기 전용 복제본이 작동하려면 백업이 활성화된 상태로 유지되어야 함 • 활성 상태의 장기 실행 트랜잭션이 있으면 완료 후에 읽기 전용 복제본을 생성하는 것을 권장

RDS – 다중 AZ (Multi-AZ) :데이터 베이스를 여러 가용영역에 배치 하는 것 • 내구성과 가용성을 향상 시킬 수 있음 (RDS 데이터베이스 다운타임이 가장 적게 할 수 있음) • DB 인스턴스에 대한 업데이트는 가용 영역 전체에서 예비 복제본에 동기식으로 복제 • 한곳의 DB가 장애 발생하면 다른 곳으로 자동연결 하도록 장애 조치 수행 (재해 복구 용도로 사용) • Standby Replica(예비복제본)은 읽기 트래픽 처리 불가 (다중 AZ RDS는 읽기 트래픽 분산 용도가 아님)

//

RDS – RDS Custom • EC2에 RDS를 설치하여 구성하는 경우는 사용자가 서버를 포함한 모든 부분을 관리 • RDS는 AWS에서 데이터베이스와 운영체제(OS)를 모든 부분을 관리하는 완전관리형 서비스 • RDS Custom은 사용자가 데이터베이스와 운영체제에 대한 관리 권한을 가짐 ✓ 예) 사용자 지정 DB 및 OS 패키지 설치, 특정 DB 설정 구성, 파일 시스템 구성, 자체 라이센스 관리 등

** RDS PROXY** Proxy는 중계하는 기능, 그냥 RDS만 사용하면 애플리케이션과 데이터베이스가 다이렉트로 연결이 됨. 그런데 프록시 서버를 중간에 놓게 되면 애플리케이션과 데이터베이스 사이에 RDS Proxy가 놓이게됨 (중간에 연결하는 기능) 여러개의 애플리케이션이 있을수 있고 이게 여러개의 RDS 프록시에 연결되고, 프록시가 데이터베이스에 연결하면 여러 어플리케이션이 데이터베이스 연결을 공유할 수 있기 때문에 리소스를 효율적으로 사용할 수 있음!

장점1) 장애조치 시간이 감속 애플리케이션 연결을 유지하면서 예비 DB인스턴스에 자동으로 연결됨ㅁ으로 장점2) 보안 - 중간에 프록시가 있으니까! 장점3) 데이터베이스 성능 유지 매번 새로운 연결을 데이터베이스에 직접 만들 필요가 없기 때문에 이 연결을 만드는데 필요한 데이터베이스의 메모리 및 cpu 등의 사용량을 감소 시킬수 있음, 데이터베이스에 열린 연결 수 제어

• 데이터베이스 프록시 기능 • 애플리케이션이 데이터베이스와 연결 풀링(pool)하고 공유하도록 하는 기능 • 여러 애플리케이션 연결에서 데이터베이스 연결을 공유할 수 있으므로 데이터베이스 리소스를 효율적으로 사용 • 데이터 베이스 장애 조치 시간 감소 ✓ 애플리케이션 연결을 유지하면서 예비 DB 인스턴스에 자동으로 연결 • 보안 개선 ✓ 데이터베이스에 AWS IAM 인증을 필요에 따라 적용하고 AWS Secrets Manager에 보안 인증 정보를 안전하게 저장 • 데이터 베이스 성능 유지 ✓ 데이터베이스 연결 풀을 설정하고 매번 새 데이터베이스 연결을 여는 데 필요한 메모리 및 CPU 오버헤드 없이 이 풀에서 연결을 다시 사용 ✓ 연결 요청이 지정된 한도를 초과하는 경우 애플리케이션 연결을 거부 (데이터 베이스 열린 연결 수 제어) 하여 부하 감소

Aurora는 aws에서 개발한 rds엔진임

auto scaling

** Aurora** >특징 • RDS 호환형 관계형 데이터 베이스 • RDS에서 제공하는 읽기 전용 복제본, KMS암호화, 스냅샷 백업, 오토스케일링, RDS Proxy 등을 제공 • AWS에서 만든 서비스로 다른 RDS보다 저렴한 비용에 성능이 더 뛰어남 • 다른 RDS보다 속도는 3-5배 빠름 • 데이터베이스 설정, 패치 적용 및 백업과 같은 관리 태스크를 자동화 • 개별 DB 인스턴스 기반이 아닌 여러 인스턴스를 하나로 운영하는** 클러스터 DB **기반으로 구성 됨

Aurora DB 클러스터 • 하나 이상의 DB 인스턴스와 이 DB 인스턴스의 데이터를 관리하는 클러스터 볼륨으로 구성 • DB 인스턴스는 읽기/쓰기 작업을 하는 기본 DB인스턴스와 읽기 작업만 하는 Aurora 복제본으로 구성 • 각 Aurora DB 클러스터는 기본 DB 인스턴스에 더해 최대 15개까지 Aurora 복제본을 구성

Aurora 복제본(Replicas) • 3개의 가용영역에 6개의 데이터 사본을 자동 복제하여 고 가용성 및 성능 향상 지원 • 마스터 DB와 최대 15개의 Aurora Read Replica 지원 • 읽기 로드를 여러 복제 본에 분산시켜 성능을 향상시킬 수 있음 • 마스터 DB에 장애 발생시 최대 30초 이내에 복제본 중 하나가 기본 인스턴스 역할로 변경 되는 장애조치 (Failover) 가능 - rds는 MZ를 사용하여 standby • Aurora Auto Scaling을 사용해 워크로드에 따라 Aurora 복제본 수를 자동으로 조정 가능

Aurora 글로벌데이터베이스 • 다른 리전으로 데이터베이스 복제하는 기능 • 1초 미만의 대기 시간(RPO 1초)으로 최대 5개의 보조 리전에 복제 • 보조 리전 중 하나가 1분 이내에 읽기 및 쓰기 기능으로 승격 가능 (RTO 1분) • 재해복구 용도, 사용자가 가까운 리전에서 빠르게 액세스 가능

Aurora Database Cloning • 현재 Aurora DB 클러스터를 복제하여 원본과 동일 데이터를 갖는 새 Aurora DB 클러스터를 생성하는 기능 • Snapshot을 만들고 복원하는 것보다 빠르고 비용 효율적 • Production DB 클러스터에 영향없이 테스트, 개발 등의 용도를 위한 Staging DB 클러스터 생성 가능

Aurora Machine Learning • Aurora DB에서 Machine Learning 기능 사용 • Amazon SageMaker 또는 Amazon Comprehend 서비스와 통합하여 사용 가능 • 예, 쿼리를 사용해 고객 프로필, 쇼핑기록, 제품 카달로그 데이터를 SageMaker 모델로 전달하여 학습 후 제품 권장 사항 데이터를 가져옴

Aurora 멀티 마스터 클러스터 • 단일 마스터 클러스터 ✓ 단일 DB 인스턴스는 모든 쓰기 작업을 수행하며, 기타 모든 DB 인스턴스는 읽기 전용입니다. 라이터 DB 인스턴스가 사용 불가 상태가 되면 장애 조치 메커니즘이 읽기 전용 인스턴스 중 하나를 새 라이터로 승격 • 멀티 마스터 클러스터 ✓ 모든 DB 인스턴스는 쓰기 작업을 수행 ✓ 라이터 DB 인스턴스가 사용 불가 상태가 될 때 어떤 장애 조치도 없음 ✓ 읽기/쓰기 DB 인스턴스가 사용 불가 상태가 될 때 장애 조치 프로세스 및 관련 지연이 발생하지 않음

Aurora Serverless • DB 인스턴스 운영 및 데이터 베이스 용량을 수동으로 관리 하지 않음 • 특정 DB 인스턴스 유형을 선택하지 않음 • 사용량에 따라 DB 용량을 자동으로 빠르게 용량을 확장하고 축소하는 기능 • 사용한 만큼만 DB 용량을 초당 요금으로 지불 • DB 사용빈도가 낮은 애플리케이션에 효과적

ElasticCache • 인메모리 데이터 스토어 • 1밀리 초 미만의 빠른 응답시간을 제공 • 빠른 응답이 필요한 애플리케이션에 사용 • 기존의 DB와 연결하여 DB응답성능을 개선하기 위해 사용 (사용하는 DB 데이터를 캐시) • ElastiCache를 사용하기 위해서는 애플리케이션의 코드변경이 필요 • 세션 스토어, 게임 리더보드, 스트리밍 및 분석과 같이 내구성이 필요하지 않는 기본 데이터 스토어로 사용 • 오픈소스 인메모리 데이터베이스 솔루션인 Redis또는 Memcached 두가지 유형을 지원 • Memcached는 멀티쓰레드 지원, Redis는 싱글쓰레드만 지원 • 일반적으로 Redis가 더 많은 기능을 지원 (스냅샷 백업, 복제기능, 고가용성 제공 등)

*ElastiCache vs. Read Replica *

RDS Read Replica • 데이터베이스: 영구적인 데이터 저장 • 데이터가 계속 변경되는 쿼리(Query)의 읽기 성능 향상에 적합 (데이터가 지속적으로 원본과 동기화 됨)

ElastiCache • 인-메모리 캐싱: RAM과 같이 빠른 하드웨어에 일시적으로 저장 • 지연시간을 줄이는 목적으로 주로 사용 • 속도는 빠르지만 저장할 수 있는 공간에 제약이 있음 • 변경이 없는 동일한 데이터를 계속 읽는 경우의 성능 향상에 적합 (데이터 변경 시 원본으로 부터 데이터를 로드해야 함)

DynamoDB

• NoSQL 데이터베이스 서비스 • 키-값, 문서 데이터 모델 지원 • 서버리스 서비스 • 용량에 맞게 자동으로 확장 및 축소(Auto Scaling) 하므로 관리 및 운영 오버헤드 최소화 • 10밀리 초 미만의 빠른 응답을 제공 • 초당 수백만개 이상의 요청 처리 가능 • 지연시간이 짧은, 빠른 응답이 필요한 애플리케이션에 사용 • 쇼핑몰 장바구니, 은행 트랜잭션, 게임 플레이어 기록 저장 등에 사용

백업 및 복구 • DB 테이블에 대해 온디맨드 백업을 생성하고 특정 시점으로 복구를 활성화 • 특정 시점으로 복구 PITR(Point-in-time recovery)를 사용해 최근 35일 이내 원하는 시점으로 테이블 복원가능

DynamoDB 테이블 클래스 • DynamoDB Standard : 기본형으로 대부분의 워크로드에 권장 • DynamoDB Standard-IA : 애플리케이션 로그, 오래된 소셜 미디어 게시물, 전자 상거래 주문 내역 및 과거 게임 성과와 같이 자주 액세스하지 않는 데이터를 저장하는 테이블에 대한 비용을 줄임

읽기/쓰기 용량모드 • 온디맨드 모드: 초당 읽기/쓰기 처리량을 자동으로 조정, 트래픽 예측이 불가능한 경우 사용 • 프로비전드 모드: 읽기/쓰기 횟수를 수동으로 조정. 트래픽 예측이 가능한 경우 사용

DynamoDB Accelerator (DAX) • 데이터베이스 앞에 인메모리 캐시를 사용해서 DB의 읽기 성능을 향상시키는 기능 • 마이크로 초 단위의 응답시간을 제공

TTL(Time to Live) • DynamoDB 유지 시간(TTL)을 사용하여 항목별 타임스탬프를 정의하여 항목이 더 이상 필요하지 않은 시점을 결정 • 지정된 타임스탬프 날짜 및 시간이 지나면 DynamoDB 테이블에서 항목을 삭제 • 예, 애플리케이션에서 1년 동안 사용하지 않은 사용자 또는 센서 데이터를 제거 • 예, 만료된 항목을 Amazon DynamoDB Streams 및 AWS Lambda를 통해 Amazon S3에 보관

글로벌테이블 • 리전간에 데이터베이스를 복제하는 기능 • 모든 리전에서 읽기, 쓰기 가능 • 복제본 테이블에 있는 항목의 모든 변경 사항은 동일한 글로벌 테이블 내의 다른 모든 복제본에 1초 이내로 복제됨 • 하나의 리전에 문제가 발생해도 다른 리전으로 라우팅 되므로 재해 복구 기능을 함 • 사용자는 가까운 리전에서 DB를 사용하기에 더욱 빠른 성능 지원

DynamoDB Streams • DB 테이블에 저장된 항목에 변경이 발생하는 경우 변경 사항을 캡쳐하는 기능 • 예, 변경 사항에 대해 Kinesis Data Stream으로 보낼 수 있음 • 예, 변경 사항 이벤트가 발생할 때마다 이벤트를 Lamba로 트리거 하여 Amazon SNS로 전송하여 이메일 등의 이벤트 알림을 생성할 수 있음

읽기 일관성 • DynamoDB에서 데이터를 읽을 때, 사용자는 읽기를 최종적 일관된 읽기나 강력한 일관된 읽기로 지정 가능 • 최종적 일관된 읽기(기본값) ** ✓ 최종 일관성 옵션은 읽기 처리량을 최대화 ✓ 최종적 일관된 읽기는 최근 완료한 쓰기 결과를 반영하지 못할 수 있음** • 강력한 일관된 읽기 ✓ 읽기 전에 성공적인 응답을 수신한 모든 쓰기를 반영한 결과를 반환 ✓ 최종적 일관된 읽기 보다 읽기 지연시간이 길어지거나 처리 용량을 많이 사용

** DynamoDB – Amazon S3와 통합

Export to Amazon S3 (S3로 내보내기)** • DynamoDB 테이블의 데이터를 S3 버킷으로 보내는 기능 • 자동 백업인 특정 시점으로 복구(PITR)기간내의 데이터만 내보낼 수 있음 (최대 35일) • 기능 사용을 위해서는 특정 시점으로 복구 PITR(Point-in-time recovery)가 활성화 되어야 함 • 데이터를 DynamoDB JSON 형식 또는 Amazon Ion 텍스트 형식으로만 내보낼 수 있음 • S3로 내보낸 데이터를 Athena, AWS Glue, Lake Formation 등의 다른 AWS 서비스를 사용하여 데이터에 대한 분석과 복잡한 쿼리를 수행 가능 • 테이블 내보내기는 테이블의 읽기 용량을 사용하지 않으며 테이블 성능 및 가용성에 영향을 주지 않음 • 테이블 데이터를 다른 AWS 계정이 소유한 S3 버킷 및 해당 테이블이 있는 리전과 다른 리전으로 내보낼 수 있음

** Import to Amazon S3 (S3에서 가져오기)** • S3의 데이터를 DynamoDB 테이블로 가져오는 기능 • CSV, DynamoDB JSON 형식 또는 Amazon Ion 텍스트 형식을 가져올 수 있음

Other Databases Amazon DocumentDB (with MongoDB compatibility) • MongoDB를 호환하는 Document Database • MongoDB는 JSON 데이터를 저장, 쿼리 및 인덱싱하는 데이터베이스 시스템

Amazon Keyspaces (for Apache Cassandra) • Apache Cassandra 호환 데이터베이스 서비스 • Apache Cassandra는 오픈소스 NoSQL 분산 데이터베이스 • Wide Column 데이터 베이스 모델 사용

Amazon Neptune • 그래프 데이터베이스 서비스 • 노드들의 관계들로 이루어진 데이터 베이스 (예, SNS)

Amazon Quantum Ledger Database(Amazon QLDB) • 원장(Ledger) 데이터 베이스 • 데이터에 적용된 모든 변경 사항에 대해 암호로 확인할 수 있는 완전한 기록을 제공

Amazon Timestream • 시계열(time serise) 데이터베이스 서비스 • 시계열 데이트는 시간에 따라 저장된 데이터 (예, IoT 센서 데이터)

Database Migration Service (DMS) 데이터베이스를 마이그레이션 하는 서비스 (DB -DB) 온프레미스에서 aws 또는 aws내에서 마이그레이션 가능 원본 db를 사용하는 중에도 지속적으로 마이그레이션가능 같은 종류의 서로 다른 종류 DB도 마이그레이션 가능 이 기종의 DB는 Schema Conversion Tools(SCT)를 이용하여 데이터 스키마를 마이그레이션 대상 db에 적합하게 변환해야함 같은 종류의 db는 데이터 변환 필요가 없음

CloudFront 특징 • 사용자에게 가까운 곳의 엣지로케이션에서 데이터를 전송 • 글로벌 배포 • 전세계 사용자에게 최상의 경험을 제공 • 콘텐츠 지연시간을 최소화 하면서 제공 • 비디오 콘텐츠 등의 실시간 스트리밍 배포 • 웹사이트 속도를 높여 해외사용자에게 향상된 브라우징 경험 • EC2 등의 오리진 서버의 부하를 줄일 수 있음 • 오리진에서 CloudFront로 전송되는 비용은 부과 되지 않으므로 비용 절감 효과가 있음 • 사용자의 요청 헤더 값(디바이스, 최종 사용자의 위치, 최종 사용자가 사용하는 언어 및 다양한 조건)에 따라 서로 다른 버전의 콘텐츠를 캐싱하여 제공할 수 있음

price class • 비용 절약을 위해 가격등급에 따라 배포하는 엣지 로케이션 수를 줄일 수 있음 • 3가지 가격등급이 있음 ✓ 전체 가격 등급(Price Class All) : 모든 리전에 배포 ✓ 가격 등급 200(Price Class 200) : 대부분의 리전에 배포 ✓ 가격 등급 100(Price Class 100) : 일부 리전에 배포 하며 가장 낮은 비용

Origin Group : CloudFront에 대한 고가용성 • 오리진 장애 조치를 사용하여 CloudFront를 설정 • 기본 오리진과 보조 오리진이 포함된 오리진 그룹을 생성 • 기본 오리진을 사용할 수 없거나 실패를 나타내는 특정 HTTP 응답 상태 코드를 반환하는 경우 CloudFront는 자동으로 보조 오리진으로 전환

Lambda@Edge :lamda는 컴퓨팅 서비스로 코드를 사용하여 함수를 싱핼 할 수 있는 컴퓨팅 서비스가 Lambda임, 이 컴퓨팅 서비스를 클라우드 프론트에서 Edge 로케이션에서 실행 할 수 있음 그래서 유저가 클라우드 프론트를 통하여 콘텐츠를 전달하게 되면 특정 함 수를 실행할 수 있도록 • CloudFront를 통해 전달되는 콘텐츠를 사용자 지정하는 함수를 실행할 수 있게 해주는 AWS Lambda 가 확장된 컴퓨팅 서비스 • Node.js 또는 Python 함수를 작성한 후 사용자와 가까운 엣지 로케이션에서 해당 함수를 실행 • 다음과 같은 CloudFront 이벤트가 발생할 때 Lambda 함수를 실행 ✓ CloudFront가 최종 사용자의 요청을 수신할 때(최종 사용자 요청) ✓ CloudFront가 오리진에 요청을 전달하기 전(오리진 요청) ✓ CloudFront가 오리진의 응답을 수신할 때(오리진 응답) ✓ CloudFront가 최종 사용자에게 응답을 반환하기 전(최종 사용자 응답)

• Lambda@Edge 사용 예 ✓ A/B 테스트를 위해 사이트의 다양한 버전을 볼 수 있도록 쿠키를 검사하고 URL을 다시 작성 ✓ User-Agent 헤더를 확인하여 사용 중인 디바이스를 기반으로 디바이스의 화면 크기에 따라 다른 이미지를 반환 ✓ 최종 사용자 요청 또는 오리진 요청 이벤트가 발생할 때 HTTP 응답을 생성 ✓ 데이터 전송 비용을 줄이기 위해 사용자에게 전송되는 파일을 압축

CloudFront 실습 s3버킷을 만들고 파일에 권한주기

URL을 복사해서 붙여넣으면 웹페이지가 나오는데

이 버킷을 클라우드 프론트를 만들수 있음

PRICING

버킷에 불러와서 사용하게 됨 > 각 위치에서 알 수 있게함

ColudFront 보안 Cloud Front 보안 액세스 – 뷰어 / 오리진 프로토콜 정책

:Match viewer (기존것을 참고하여 앞이랑 맞춤)

Cloud Front 보안 액세스 – OAI (Origin Access Identity) OAI(Origin Access Identity)를 통해 S3버킷의 액세스를 클라우드 프론트를 통해서만 하도록 할 수 있게 하는 기능

Singed URL, Signed Cookies 서명된 URL또는 쿠키를 이용해서 콘텐츠에 접속하는 기능 URL또는 쿠키에는 콘텐츠만료기간, 액세스가능한 IP주소를 저장할 수 있음 유료 콘텐츠나 보안을 위해 콘텐츠의 유효/만료 기간을 지정해야 하는 경우 사용 (예, 승인된 사용자만 콘텐츠를 볼 수 있도록 허용) 서명된 URL은 1개의 파일에 1개의 서명만 저장 (1개의 파일 접속을 위한 URL) 서명된 쿠키는 하나의 쿠키로 여러 개의 파일 접속 가능

지역 제한 (Geographic Restrictions) 특정 국가에서의 콘텐츠 액세스를 제한 하는 기능 법률적인 사항으로 국가별로 저작권이 다른 경우에 사용가능 2가지 지리적 제한 옵션 ➢ 화이트리스트(Whitelist): 리스트에 있는 국가만 액세스 허용하고 나머지는 모두 거부 ➢ 블랙리스트(Blacklist): 리스트에 있는 국가만 액세스 거부하고 나머지는 모두 허용

AWS Web Application Firewall(WAF), AWS Shield와 결합해 DDoS 방어 기능을 함

필드 레벨 암호화 ✓ 신용 카드 번호와 같이 사용자가 제출한 데이터를 안전하게 오리진 서버로 업로드할 수 있게 해주는 CloudFront의 기능 ✓ PUT/POST 요청이 오리진으로 전달되기 전에 엣지로케이션에서 비대칭 암호화 키를 사용하여 데이터를 추가로 암호화 ✓ 데이터는 프라이빗 키를 가진 애플리케이션만 복호화 할 수 있음

복사한 정책 붙여넣기

직접 엑세스 하는경우에는 에러가뜸

도메인을 통해서는 접속됨 (OAI 적용)

지리적 제한도 가능!

Global Accelerator 개요

• 가장 가까운 위치로 트래픽을 라우팅하여 인터넷 대기시간을 줄이고 전송 성능을 향상하는 서비스 • Global Accelerator를 미사용시 서버로부터 지리적으로 먼 사용자는 많은 인터넷 라우팅을 하여 속도가 느림 • Global Accelerator를 사용하면 사용자는 가까운 거리의 엣지로케이션으로 라우팅하고 엣지로케이션과 서버는 AWS전용네트워크 연결로 전송속도가 빠름

특징 • 글로벌 액셀러레이터에는 2개의 Anycast 퍼블릭 고정 IP가 생성됨 (IP 주소 연결 방식) • Anycast는 네트워크 트래픽을 가장 가까운 노드로 전송하는 라우팅 방식 • Elastic IP, EC2인스턴스, ALB, NLB 등의 AWS 엔드포인트를 연결하여 사용 가능 • 애플리케이션의 Health Check기능을 통해 하나의 서버 장애 발생시 다른 서버로 라우팅 가능

비교! : 둘다 엣지 로케이션을 사용하는 특징이 있음

Amazon CloudFront 변화하는 동적인 IP 주소 세트를 사용 • 전 세계에 분포된 엣지 로케이션을 사용 • 엣지 로케이션을 콘텐츠를 캐시 하는데 사용 • HTTP 프로토콜을 처리하는데 적합 • 캐시 가능한 콘텐츠(예: 이미지, 비디오) 와 동적인 콘텐츠(예: API 가속화 및 동적 사이트 제공)의 성능을 개선

Global Accelerator ** • **고정된 IP 주소를 사용 • 전 세계에 분포된 엣지 로케이션을 사용 • 엣지 로케이션을 가장 가까운 리전의 엔드포인트로 최적화된 경로를 찾는데 사용 • TCP, UDP 프로토콜을 처리하는데 적합 • TCP 또는 UDP를 사용하는 광범위한 애플리케이션의 성능을 개선 • Non-HTTP를 사용하는 게임(UDP), 미디어, VoIP, 모바일 앱, IoT등의 다양한 애플리케이션의 성능을 향상 • 고정 IP 주소가 필요한 HTTP에 사용

Global Acceleraotr 실습

두개의 리스터 기입

각 리스너에 엔드포인트 연결

인스턴스를 종료하면

자동으로 연결됨