KT 에이블스쿨 : 클라우드 서비스 3일차 정리




    클라우드 서비스

    6일 과정 : 24.05.14 (화) ~ 22 (수)

    3일차 240517(금) 교육 정리




    3일차 이론

    저장 서비스 (블록, 파일, 객체)

    블록 스토리지 : amazon EBS

    1. 마치 레고 블록 처럼, 큰 데이터를 여러개의 작은 블록들로 나눠서 저장한 것. 나중에 필요할때 빠르게 다시 조립 가능

    2. 대용량 트랜잭션, 데이터 저장이 요구되는 곳에 적합. 빠르게 정보를 찾아냄

    3. EBS 1개 안에는 작은 여러개의 블록(데이터)를 모아놓은 저장소

    4. EC2 인스턴스 하나에 여러개의 EBS를 두는 아키텍처임 (EBS 하나에 여러개의 인스턴스X)


    • SSD 기반 EBS 볼륨유형

      SSD는 데이터를 빠르게 읽고 쓸수있음

      • 범용 SSD : 일반용도로 쓰기 좋은 스토리지

      • 프로비저닝된 IOPS SSD

        용량이 256,000으로 크기에 일반적으로 불가능한 여러 인스턴스를 하나의 EBS로 연결하는 방식이 가능함


    • EBS 스냅샷

      • EBS 볼륨의 백업을 만드는 기능

      • EBS 볼륨에 저장된 데이터의 특정 시점을 캡처해 저장함

      • 점진적 백업: 처음 스냅샷을 만들 때는 전체 데이터를 백업하지만, 그 다음부터는 변경된 부분만 백업함. 이는 스토리지 사용량과 백업 시간을 줄여

      • 데이터 복구: 스냅샷을 이용해 언제든지 데이터를 복원 가능

      • 복제: 스냅샷은 다른 곳(AZ, 리전)으로 복제 가능. ⇒ 데이터를 더욱 안전하게 보호, 지역 간 장애에 대비. 글로벌 서비스 지연시간 줄이기 위함

        (s3는 저장용량을 거의 무한으로 확장할 수 있기에, 글로벌의 경우 s3에 저장)

      • EBS 볼륨 암호화 : 볼륨에 저장된 데이터를 암호화하면, 스냅샷, 스냅샷으로 생성된 볼륨 모두 암호화됨


    • 인스턴스 스토어

      = AWS에서 제공하는 임시 블록 스토리지

      • EC2 인스턴스와 함께 제공되며, 인스턴스가 실행 중일 때만 데이터를 저장
      • 처리시간이 정말 빠름
      • 인스턴스가 중단되거나 종료되면, 인스턴스가 어디 서버랑 연결될지 모르기에 데이터가 손실됨 (임시용 - 버퍼, 캐시 )




    파일 스토리지 : amazon EFS/FSx

    • 특징

      • 데이터를 파일 단위로 저장하는 방식 (ex. 컴퓨터 파일, 폴더)

        계층적 파일 및 폴더 구조로 저장되는 데이터 저장소 유형

      • 공유 파일 시스템으로 활용됨 - 여러 사용자나 앱이 접근해 파일 공유 가능

        (ex, 회사에서 직원들이 동시에 문서 작업할때, 파일 스토리지를 쓰면, 모든 사람이 같은 파일을 보고 수정함)

      • (장점) 확장성이 좋음(앱이 늘어날수록 파일 스토리지도 늘어나야하니까)


    • Amazon EFS

      • 리전 내 여러 AZ에서 실행되는 EC2 인스턴스가 액세스해 공통 데이터 소스 공유 가능

        (EBS는 동일 AZ였고, 다른 AZ간 혹은 리전간 복제를 해야함)

      • 용량 자동 확장, 축소 - 대규모 분석 작업, 빅데이터 처리에 적합

        EFS 파일 시스템을 EC2 인스턴스에서 접근하기 위해서는 탑재 대상을 사용 탑재 대상은 각 AZ마다 하나 탑재 대상에 보안그룹 설정해 EFS 파일 시스템으로의 트래픽 제어 가능 (ex. 특정 IP(회사 내), 포트만 접근 허용, 특정 프로토콜 제한 등의 정책 설정 가능)



    객체 스토리지 : amazon S3

    • 특징

      • 확장성이 거의 무한대 - 원하는 사용 용도대로 저장 가능

      • 구조화 데이터, 비구조화 데이터 대량 저장을 위한 스토리지 유형

      • 데이터를 큰 덩어리(객체)로 저장하는 방식

        • 각 “객체 데이터”는 “데이터” + “데이터에 대한 설명(메타 데이터)”를 가짐

        • ex) 사진 하나가 객체, 사진 마다 고유한 이름으로 저장되고 설명 포함 가능

          ⇒ 회사에서 방대한 사진, 동영상 저장할때 객체 스토리지 사용함

          ⇒ 유튜브에서 동영상 저장할때 객체 스토리지 씀

      • 이름-키를 매핑해 검색 용이

      • 객체 저장 시 고유의 URL이 부여되 Rest API를 통한 액세스 가능



    • Amazon S3 (simple, storage service, 3개의 s)

      • 액세스 제어 정책

        ex) 인사 담당자만 급여 데이터 볼수있는데, 마케팅 담당자가 급여 데이터에 접속 불가능하도록 설계하는 것

      • 버킷(bucket)

        • 버킷은 S3 내 객체 저장을 위한 저장소
        • 버킷이름은 모든 AWS 리전의 모든 AWS 계정에서 반드시 고유해야함 = 전세계 AWS에서 유일해야함
        • 버킷에 저장할 수 있는 객체 수는 제한 없음

      • 객체(object)

        • 파일, 이미지 등 업로드하는 객체
        • 객체는 수정이 불가능함. (이름 같으면) 덮어쓰기 or 삭제 가능


    • 스토리지 클래스

      참고 : https://velog.io/@leesh0567/S3-Standard-란

      • (왼쪽, 사용용) 자주 접근하는 데이터 > 저장비용 ↑ , 요청비용 ↓
      • (오른쪽, 저장용) 자주 접근하지 않는 데이터 > 저장비용 ↓ , 요청비용 ↑


    • 수명 주기 정책 (lifecycle policy)

      • 데이터를 생성하고 활발히 사용접근할땐 s3 스탠다드를 쓰고,

        n일, n주, n개월이 지날때 한단계씩 오른쪽으로 스토리지를 이동하는 것

      • 문제점 : 데이터 유형/성격별로 주기 차이가 있는데, 모든 데이터를 동일하게 규칙화하는 것

      • 이 문제를 해결한 서비스(유료) = s3 intelligent-tiering : 모니터링 결과에 따라 자동으로 수명 주기 처리


    • 액세스 정책

      • 기본값 : S3에서 버킷 생성시 소유자만 버킷에 액세스 가능

      • 정책 : 소유자가 Make Public 설정 및 액세스 정책 작성해 다른 유저에게 권한 부여 가능

        1. Make Public : 불특정 다수에게 액세스 부여 (ex. 웹 호스팅, 스트리밍 서비스)
        2. Access Policy : 사용자별로 권한 설정함

          • 정책을 json으로 써야하는데, AWS policy generator 활용하면 원하는 정책을 선택하면 json 스크립트로 바꿔줌

      • s3 presigned urls

        • presigned url 만들어서 30분(일정시간)만 접근할 수 있도록 하자, 시간지나면 접근X

          버킷 정책을 업데이트하지 않고, 어떤 유저에게 임시로 권한 줄때 사용



    • 정적 웹사이트 호스팅

      • DNS

        • A 타입 : naver.com → 128.0.4.80 (기본적으로 알고있는 dns 기능)
        • CNAME 타입 : blog.bucketname3o aws.com → awstest.com

      • 버킷 URL을 통해서도 접근 가능하지만 DNS를 통해 특정 도메인을 사용하여 호스팅 할 수도 있음

        (Route53은 AWS에서 제공하는 DNS 서비스임) cname 타입으로 긴 url을 짧게 dns 처리함

      • Amazon S3를 사용하여 정적 웹 사이트를 호스팅할 수 있음 (정적 HTML 파일, 이미지, 동영상, JavaScript 형식) – HTTP만 지원, 퍼블릭 읽기 액세스와 버킷 정책 적용 필요


    • 미디어 저장 및 배포

      • CDN

        • 지역 엣지 로케이션에 캐시 서버를 분산 배치

        • 서비스를 제공하는 원본 서버의 트래픽을 줄이고, 지연시간을 줄이기 위함

        • (활용분야)

          1. 캐싱 서비스 : 웹서버에 이미지 컨텐츠의 빠른 전송을 위함 - ex) 쇼핑몰, 커뮤니티
          2. 다운로드 서비스 : 대용량 컨텐츠나 패치로 한번에 많은 컨텐츠 전송 - ex) 게임 다운, 업데이트, 백신 패치
          3. 스트리밍 서비스 : 영상 컨텐츠 스트리밍 ex) 동영상, 인강

        • (작동로직)

          1. 사용자는 엣지 로케이션에 요청해서,

            캐시된 데이터가 있는지(hit) 없는지(miss)를 확인함

          2. (캐시된 데이터가 없으면) 원본 서버로 이동 (bucket, origin)

            ⇒ 원본 콘텐츠가 캐싱을 위해 엣지 로케이션으로 전송

          3. 엣지에서 사용자에게 전송



    • 버전 관리 (버저닝 기능 활성화)

      • 객체 수정이 안되어서, 업로드(덮어쓰기) or 삭제만 가능

      • 버전 기능 활성화

        1. 덮어쓰기 했을때, 이전 버전에 ID가 생겨서 축적 → 이전 버전으로 되돌아가기 가능

        2. 삭제시, 영구 삭제를 안하고, 삭제 마커를 삽입시킴 (만약 삭제를 취소하면, 삭제 마커가 제거되서, 삭제했던 이전 버전으로 돌아가기 가능)

          (버저닝 기능 비활성화하고 삭제하면, ㄹㅇ 삭제되서 못돌아감)

        • (단점) 용량, 메모리 차지 = 비용올라감 (비용을 감당할만큼 중요한 데이터인지 판단이 필요)



    • 객체 잠금 (S3 object lock)

      • 고정된 시간 동안 또는 무기한으로 객체의 삭제 또는 덮어쓰기를 방지하기 위한 기능
      • ex. 금융, 의료 분야 규정 준수 요구사항을 충족할때 등



    • 데이터 암호화

      1. 데이터를 전송할때 암호화
        1. ex) https (암호화해서 웹 통신)
      2. 데이터 저장할때 암호화하는 방식
        1. s3 관리형 키 : s3에서 자체적으로 자동으로 관리, master key → 암호화 → 객체 암호 완료 이 플로우인데, 키 생성,관리, 암호 전과정을 자동으로 하는 것
        2. aws kms 키 : master key, 암호화 키 생성은 고객이 하고, 키 관리는 aws가 함
        3. 고객 제공 키 : amazon에서 암호화 키를 관리하는걸 못믿겠다. 내가 가지고 있다가 필요할때마다 잠깐씩 aws에게 주는것, aws는 이 키를 저장하지 않음


    • 데이터 이동

      • Multipart Upload
        • 대용량 객체를 쪼개 병렬로 업로드하고, 다 업로드되면 재조합해 S3에 저장
        • 쪼갠걸 병렬로 업로드하다 실패하면, 다른 부분에 영향 안주고 다시 시작하면됨
      • transfer acceleration
        • 엣지와 리전은 전용선으로 연결되어있음.
        • 엣지 로케이션을 통해 S3 버킷으로 대용량 전송 가능, 전송 속도 개선을 위함
      • 대~~~용량의 온프레미스 데이터를 클라우드로 마이그레이션하기 위한 HW 장비
        • snowcone(8TB, 작은 박스크기), snowball edge(80TB), snowmobile(엑사바이트, 트럭)


    • 데이터 복제 (객체 복제)

      • 리전 내 AZ간 / 리전 간 복제
      • 규정 준수사항 충족, 대기시간 최소, DR 등의 목적


    • 이벤트 알림

      • 새로운 객체가 버킷에 추가, 덮어쓰기 등 이벤트 발생시 알림을 전송하는 기능


    • AWS outposts

      • AWS 인프라, 서비스, API 및 도구를 HW로 기업에게 제공하는 클라우드 하이브리드 솔류션

      • ex. 병원 : 병원은 환자의 정보를 매우 빠르고 안전하게 다뤄야하는 곳

        만약 이 정보를 멀리 떨어진 곳에 있는 컴퓨터(클라우드)를 통해 처리하려면, 정보가 오고 가는데 시간이 걸리고 때로는 위험할 수도 있어요. 그래서 병원에서는 AWS Outposts를 사용해서 필요한 컴퓨터 서비스를 병원 내부에 설치해요. 이렇게 하면 환자 정보를 더 빠르고 안전하게 다룰 수 있어요.




    DB 서비스 

    • DB : 데이터의 집합, 데이터는 보통 물리적 장치에 저장됨
    • DBMS : 데이터에 접근해 데이터를 저장, 조회, 관리하는 환경 지원 (오라클)
      • 클라우드에서 제공하는 DB 서비스는 DBMS 들임


    관계형 DB (Amazon RDB)

    • 특징

      • 데이터를 고정된 데이터 스키마(행, 열)로 저장
      • SQL로 데이터 처리
      • 데이터 중복을 피하기 위해서, 여러 테이블로 나눠 저장
      • 데이터는 테이블간 관계로 이뤄져있음


    • Amazon RDS

      • Fail-over

        • 가용성 (장애발생 시 대응)
        • primary db가 문제 생기면, standy db로 작동
        • 동기식 복제

      • Read Replica : 읽기전용 복제본

        • 확장성 (읽기성능 향상, 지연시간 최소화)

          Primary DB에서 Read / Write를 하는데, 부하가 집중되면 처리가 늦어지니까

          읽기는 Read only Zone에 있는 DB가 처리하면 속도 빨라짐

        • 비동기식 복제


    • RDS > Amazon Aurora : AWS에서 만든 DBMS

      • (왼쪽) 기존 DB 서비스 : primary, standy 두개의 DB, 2개의 가용영역이 있음
        • 동기식 자동 복제
      • (오른쪽) Aurora : primary + Read replica로 읽기전용 2개가 있음
        • primary 장애 발생시에는 read replica가 쓰기까지 지원해서, primary 기능 대체함
        • 비동기식 자동 복제 : primary가 변하면 자동 동기화



    비관계형 DB(=noSQL) - Amazon DynamoDB

    • 특징

      • 동적인 스키마(행, 열) 구조라 운영하는 과정에서 처음과 다른 데이터형식을 추가, 수정 가능

        (RDB는 처음에 구조시킨대로 쭉 해야함)

      • 데이터 중복 발생 가능, 테이블 조인 필요가 없고 데이터 구조 변경 용이 - 유연

      • SQL로 데이터 처리



    • Amazon DynamoDB

      • 데이터를 key별로 파티션에 분산 저장함

        • 조회할때, 키값으로 해당 파티션을 바로바로 찾을 수 있음. ⇒ 읽기 쓰기가 빠름
        • 파티션이 자동확장됨 ⇒ 대규모 데이터 처리 가능

        (RDB는 처음부터 끝까지 나올때까지 수직적으로 찾아야해서 비교적 시간이 좀 걸림)

      • 가용성 : 1개 리전 내 3개의 AZ에 복제본을 구성하기에 한곳에서 장애나도 무사함

      • (활용분야) 게임(이벤트, 게임데이터 업데이트 등), 홈쇼핑(쇼핑몰 장바구니)



    인메모리 DB (Amazon ElastiCache)

    • 특징
      • 대부분의 DB는 디스에 저장하는데, 메모리에 데이터를 저장하는걸 인메모리DB라함
      • 캐싱, 실시간 데이터처리 처럼 빨리 처리해야하는 경우 적합
      • 휘발성, 비쌈



    • Amazon ElastiCache

      • 1밀리초 미만의 응답시간




    DB 서비스 비교

    • 관계형 DB vs 비관계형 DB

    • 비관리형 DB vs 관리형 DB

      DBA 직업이 온프레미스 환경에서 자체 DB를 관리했지만, 클라우드로 옮기면, 비관리형이더라도, 서버부분은 관리가 필요없고 클라우드에서 관리형 DB를 쓰면, 전체를 다 자동적으로 관리해줌

    • 마이그레이션

      온프레미스의 DB를 aws의 클라우드 db로 마이그레이션하는걸 자동으로 하는 서비스가 있






    3일차 실습

    1. 객체 스토리지 이해 - S3

    2. DB 인스턴스 생성











    댓글

    댓글 쓰기

    이 블로그의 인기 게시물

    [KT 에이블스쿨 - IT 트랜드] 국내외 AI 관련 규제

    이미지
    KT 에이블스쿨에 참여하면서 IT 트렌드 스터디하고있는데, 발표자료로 오늘은 ChatGPT 4-o 내용을 준비했다.  NIA (한국지능정보사회진흥원)의 디지털 법제 Brief 중  AI 규제와 관련된 내용 3개의 보고서를 읽고 발표에 참고했다.  해외 "사법기관 인공지능 이용지침" - 보고서 링크 - 발행일 24.02.15 이 보고서에는 사법기관에서 AI 를 어떻게 이용하면 되는지를 지침으로 정의한 캐나다와 영국 사례를 소개했다.  캐나다와 영국은 23년 12월에 이를 마련했고, 호주와 뉴질랜드 등 같은 영연방 국가들도 유사한 지침을 내렸다.  캐나다 캐나다 "법원의 인공지능 이용 원칙 및 지침" (23.12.10) AI 사용을 알리는 문구 명시   작성한 문서의 가장 앞쪽에 이런 문구를 명시해야함 "Artificial intelligence(AI) was used to generate content in this document" (인공지능을 사용하여 이 문서의 컨텐츠를 생성하였습니다) 7가지 원칙  (책무) 의사결정에 인공지능을 사용할 가능성에 대해 책임 (기본권 등 존중) 인공지능 사용으로 인해 사법 독립성, 사법 접근권 및 차별 없이 공정 한 심리를 받을 권리 등이 침해되지 않도록 보장 (비차별) 인공지능 사용으로 차별 이 재생산되고 악화되지 않도록 보장   (정확성) 인공지능의 이용에 사용된 데이터는 확인 및 검증된 데이터만 사용   (투명성) 인공지능이 사용하는 모든 데이터 처리방법에 대해 외부 감사 실시 (보안) 기밀성 프라이버시 출처표기 등이 보장되는 안전한 기술환경 에서 데이터 저장 및 관리   (사람의감시) 판사 및 재판 연구원은 인공지능 생성물을 자신들의 업무에 사용하고자 하는 경우 해당 생성물의 결과를 검증 공개협의(publicconsultation) 없이 자동화된 의사결정 도구 등 인공지능을 판결 명령에 사...
    자세한 내용 보기

    KT 에이블스쿨 : IT 인프라 (1일차~5일차) 공부 정리

    이미지
       IT 인프라 24.05.7 (화) ~ 13 (월)  네트워크, 서버, 저 장장치(IT 인프라)를 온프레미스 환경에서 어떻게 구성하는지를 배웠다. 1일차  개념 (네트워크)   IT 인프라 이해 온프레미스 하이브리드 클라우드 IT 인프라 구성도  네트워크 이해 네트워크 종류 PAN : personal area LAN : local  MAN : metropolitan (대도시) WAN : wide (광대역)  네트워크 구성요소 전송 단말기 전송매체 전송 프로토콜 네트워크 장비 OSI 7계층  스위치 네트워크 스위치 : MAC 주소를 기반으로 노드와 노드간 연결 중개(허브, 다리처럼) 스위치 동작방식 캡슐화 IP 주소 서브넷 마스크 : IP주소 중 네트워크 주소, 호스트 주소 구분해줌 서브넷팅 : 네트워크를 작은 단위의 네트워크로 분할(00구 > 00동, 00동)  공인IP, 사설IP NAT : 사설IP를 공인IP로 변환 ARP : IP 만 알고 있을 때 Mac 주소를 확인 할 수 있도록 해줌 라우터와 라이팅 DHCP : TCP/IP를 Client에게 자동으로 할당해 IP 충돌방지  DNS 게이트웨이 라우터 모드  실습 (Cisco 패킷트레이서) 스위치 동작  스위치를 통한 네트워크 구성해 통신 확인 (ping ip주소) 맥주소 테이블 확인하며 동작 방식 이해 (show mac-address-table) 참고출처 : cisco 1. pc에 ip 설정 2. 스위치와 pc 간 노드연결 (이더넷 포트에 연결) 사설 IP주소, 공인 IP 주소 확인 라우터  라우터 모듈 선택하고 장착해 설정  라우터 모드 사용자: Router> 기본 관리자: Router#  enable 전체 설정모드 : Router(config)#  conf t          ...
    자세한 내용 보기

    KT 에이블스쿨 : 핀테크 아이디어 공모전

    이미지
      KT 에이블스쿨을 하면서 발표 스터디를 했는데,  발표 스터디원의 일부랑 핀테크 아이디어 공모전에 참가했는데 그 과정을 정리해볼려고 한다.  조원 모집  처음에 핀테크 분야로 공모전을 찾은 것은 아니었다. 아이디어, 데이터분석과 관련된 공모전을 나가고 싶어서, KT 에이블스쿨의 발표 스터디에서 조원을 모집했다.  다들 열정이 많아서 바로 모을 수 있었다.  그뒤에, 공모전을 찾아서 투표를 했는데, 핀테크 아이디어 공모전의 표가 가장 많아서 이걸로 하게 되었다.  https://fintech.or.kr/web/expo/idea.do?menu_id=10300   공모전 일정은 이렇게 되어있고, 원래는 제출이 7월 초였으나 기한이 연장되었다.  며칠 뒤에 1차 발표가 나오는데, 좋은 결과가 있으면 좋겠다.  5월 30일에 시작을 했고,  팀즈로 주 1-2회씩 만나서 회의를 했다.  아이디어 선정 아이디어 부분은 구글 스프레드시트에서  각자가 가지고 있는 핀테크 관련 아이디어를 공유하고, 주1회 만나서 아이디어를 공유했다.  첫번째 회의에서는 여러 아이디어를 공유했지만, 모두 마음에 드는 아이디어가 없어서  기존 아이디어를 디벨롭하거나 추가해 다시 회의를 했다.   인당 최소 4개씩 찾아서 적기로 했고,   핀테크 샌드박스 규제 사이트, 핀테크 10가지 서비스 종류, 핀테크 기업의 신사업 등을 공유하면서 아이디어를 생각할려고 노력했다.  그러다가, 팀원 중 한분이 핀테크의 "STO (토큰증권)"라는 새로운 기술을 알려주셨다.  국내에 현재 1개 기업만 있고, 신기술이라서 규제가 제대로 마련되지 않은 새로운 분야였다.  팀원 모두 만장일치로 STO 기술을 활용한 아이디어를 제안하기로 결정했다 !  STO는 토큰증권으로 현재의 조각투자랑 비슷한 방식인 소액투자이다....
    자세한 내용 보기