골드에그

두 스토리지 타입 모두 인스턴스가 종료되어도 저장하기 위한 용도로 사용된다.

EBS

• 네트워크 볼륨 드라이브 (USB Stick)
  
  • 네트워크 사용 필요
• 하나의 인스턴스에만 마운트 가능 (advanced 한 방법으로 multi-attach 도 가능)
• 특정 가용성 존에 연결
• EBS Elastic Volume
  • 볼륨 사이즈 변경 가능 ( 용량은 늘릴 수 있지만 줄일 수 없음 )
  • IOPS 나 처리량만 변경 가능 
  • 가동 중지 시간 없이 바로 변경 ( 인스턴스를 재시작하거나 볼륨을 삭제하지 않아도 된다 )
• 사용 시 주의사항
  • 기본적으 인스턴스가 종료될 때 Root EBS 볼륨도 같이 삭제된다
  • Root EBS 볼륨이 삭제되지 않으려면 'Delete on Terminated' 옵션을 비활성화한다
  • 기본적으로 다른 부착된 EBS 볼륨은 삭제되지 않는다

EFS

• 완전관리형 NFS (Network File System)
• 많은 인스턴스에 동시에 마운트 가능
• POSIX 파일 시스템 (표준 파일 API)
  • AMI 기반 Linux 인스턴스에 부착 가능 (윈도우 불가능)
• NFS v4.1 프로토콜 사용
• Security Group 으로 Access 제어할 수 있음
• KMS 서비스를 통한 암호화 가능
• 용량 계획 필요 없음. 자동 스케일링 지원
• 성능
  • NFS 에 1000 개의 세션이 동시 접근 가능하고 각각 10 GB / s 처리량 가능
  • 최대 Peta Byte 용량까지 지원 가능 자동 스케일링
• 성능 모드
  • EFS 생성 시에 설정 가능 
  • 일반 목적 - 민감한 지연 시간이 필요한 서비스에 사용 가능 (웹 서버, CMS)
  •  Max I/O  - 더 높은 최대 처리량 / 병렬 실행 (빅데이터, 미디어 처리)
• 처리량 모드
  • 버스팅 - 1TB 는 초당 50MB 인데 버스트는 초당 100MB 까지 상승 가
  • 프로비저닝 - 스토리지 크기에 상관 없이 처리량 설정 가능
  • 엘라스틱 - 워크로드 기반 자동 스케일링 업 / 다운 지원
    • 초당 3GB 읽기 / 초당 1GB 쓰기 업 가능
• 클래스
  • lifecycle 정책 설정하여 일정한 기간 이후 계층 이동 가능
  • Standard - 스토리지에 자주 접근이 필요한 경우
  • IA(Infrequent Access) - 자주 접근하지 않은 경우. 더 저렴한 비용
  • Archive - 1년에 한 번 접근하는 경우. 50% 저렴한 비용
• 가용성과 내구성
  • Standard - 여러 가용 영역에 배치. 프로덕션용으로 적합
  • One-zone - 한 개의 가용역역에 배치. 개발용으로 적합

EBS vs EFS

S3 정의

• 객체 스토리지
  • 버킷은 디렉토리, 객체는 파일과 유사
  • 객체 크기는 5TB 까지 저장
• 무한히 스케일링이 가능
• 버킷 이름은 모든 계정 모든 리전 통틀어 유일해야 한다
• 버킷은 리전에 위치
• 사용 사례
  • 아카이브 저장
  • 백업 및 장애 복구
  • 어플리케이션, 미디어 호스팅
  • 데이터 레이크
  • 정적 웹 사이트 호스팅

S3 복제

S3 Storage Class

S3 Lifecycle Rules

• LifeCycle Rule 을 통해 S3 버킷 스토리지 클래스를 자동으로 전환할 수 있다.
• 스토리지 클래스를 전환할 뿐만 아니라 유효기간이 만료되어 삭제도 가능하다. (전환 작업, 만료 작업)
• 버킷 전체나 버킷 내부 특정 Prefix 단위, Tag 단위로 설정이 가능하다.
• 사용 시 주의사항
  • Standard => Standard-IA => Intelligent-tier => OneZone-IA => Glacier => Deep-Archive 클래스로 순으로 전환이가능하지만 역순은 불가능하다. 사본 생성 후 사본을 옮겨야 한다.
• 사용 사례
  • 이미지 원본은 60일 이내에 즉시 복구가 가능하고, 썸네일은 쉽게 만들 수 있는데 마찬가지로 60일 정도 보관하고 6시간 이내에 복구해야 한다.
    • => 이미지 원본은 Standard 보관, 60일 이후 Glacier 로 전환, 썸네일 이미지는 OneZone-IA 보관 60일 이후 삭제
  • 드물지만 삭제된 객체는 30일 이내에 즉시 복구가 가능해야 하고, 최대 1년까지는 삭제한 객체를 48시간 내 복구해야 한다.
    • => S3 버저닝 활성화 후, 이전 버전은 Standard-IA 로 전환하고 30일 이후에는 Glacier Deep-Archive 로 전환

S3 Analytics

• 스토리지 접근 패턴을 분석해 언제 S3 스토리지 객체를 변환해야 하는지 S3 Analytics 서비스를 사용할 수 있다.
• 오직 Standard 로 부터 Standard-IA 로 보낼 때만 사용 가능하다.
• 데이터 분석이 가능하도록 보고서 (.csv) 가 24 ~ 48 시간 주기로 매일 업데이트된다.

S3 Event

• S3 EventBridge 로 전달하거나 직접 SNS, SQS, Lambda 로 보낼 수 있다.
• 직접 보내는 경우, 여러 개의 이벤트 소스로 전달할 수 있다.
• 직접 보내는 경우 S3 가 행동할 수 있도록 SNS, SQS, Lambda 의 Resource Policy 정책이 허용되어 있어야 한다.

S3 Performance

baseline

• S3 는 아주 많은 수의 요청량을 처리하기 위해 자동으로 스케일링한다. 지연율은 보통 100 ~ 200 ms 정도이다.
• 버킷의 prefix 당 최대 초당 쓰기 요청(PUT/COPY/POST/DELETE) 횟수은 3,500, 최대 초당 읽기 요청(GET/HEAD) 횟수은 5,500 이다.
• 버킷의 총 최대 요청 횟수와 버킷 당 prefix 의 개수는 제한이 없으므로 더 많은 요청을 받기 위해서는 요청량이 집중되는 오브젝트 단위를 분석해 prefix 로 분리해야 한다.
• 사용 사례
  • bucket/1/file => /1/, bucket/2/file => /2/, bucket/3/file => /3/, bucket/4/file => /4/ 라면 최대 22,000 요청량 가능

Multi-Part Upload (분할 업로드)

• 매우 큰 파일을 업로드 시 전송 속도를 향상하기 위해 파일을 분할하여 병렬 업로드한다.
• 100MB 이상 파일은 분할 업로드 권장, 5GB 이상 파일은 분할 업로드 필수
• 사용 사례
  • 100GB 파일에 대해 멀티파트 업로드
    • CreateMultipartUpload 호출
    • 총 100GB 크기에 대해 각각 100MB 파트를 업로드하는 1000개의 개별 UploadPart 호출
    • CompleteMultipartUpload 호출

S3 Transfer Acceleration

• 버킷 파일을 AWS 의 엣지 로케이션으로 전송함으로써 접송 속도를 높이는 방식이다.
• 공용 인터넷을 최소한으로 거치고 사설 AWS 네트워크 라인을 사용하기 때문에 속도가 훨씬 빠르다.
• Multi-Part Upload 기능과 호환

S3 Byte-Range Fetches

• 파일의 특정 바이트 일부 범위만 읽기 요청하는 방식이다.
• 병렬 요청 가능
• 사용 사례
  • 다운로드 속도 가속화
    • Multi-Part Upload 기능의 반대 전략으로 매우 큰 파일을 분할하여 병렬 다운로드한다. 예를 들어 100 GB 파일을 100 MB 씩 분할해서 10 번 반복 요청한다.
  • 헤더 부분 읽어서 파일 확장자 확인

 

S3 Encryption

Amazon S3에서는 4가지 방법으로 S3 버킷의 객체를 암호화할 수 있다.

• Server-Side Encryption (SSE)
  • Server-Side Encryption with Amazon S3-Managed Keys (SSE-S3)
    • Amazon S3 관리형 키를 사용하는 서버 측 암호화
  • Server-Side Encryption with KMS Keys stored in AWS KMS (SSE-KMS)
    • AWS KMS 키를 사용하는 서버 측 암호화
  • Server-Side Encryption with Customer-Provided Keys (SSE-C)
    • Client 가 제공하는 키를 사용하는 암호화
    • AWS Console 에서는 확인이 불가능하고, SDK 프로그래밍 방식만 지원 가능
• Client-Side Encryption
  • Client 에서 직접 암호화 후 전송하고 다운로드 후 복호화하는 방식

SSE-S3

• 기본 S3 객체 암호화 방식
• AWS S3 에서 처리, 관리, 및 소유하는 키를 사용하여 암호화
• AES-256 알고리즘으로 암호화
• 클라이언트에서 "x-amz-server-side-encryption": "AES256" 로 header 조작 필요

SSE-KMS

• AWS KMS(Key Management Service) 서비스를 통해 처리되고 관리되는 키를 사용하여 암호화
• 사용자가 KMS 서비스를 통해 키를 관리할 수 있음
• CloudTrail 로그를 통해서 키 사용 여부들을 감사 가능
• 클라이언트에서 "x-amz-server-side-encryption": "aws:kms" 로 header 조작 필요
• 사용 시 주의사항
  • 업로드 시 GenerateDataKey KMS API 를 호출하고, 다운로드 시에는 Decrypt KMS API 를 호출하는데 이 API 가 초당 할당량 제한이 있음. 지역에 따라 다르지만 5,500, 10,000, 30,000 req/s.
  •  쓰로틀링 방지를 위해, 서비스 할당량 콘솔을 통해 초당 할당량을 높인다.

SSE-C

• Client 가 키를 생성해서 AWS 에 전송하고 서버 측에서 암호화 (Client 가 직접 키 관리)
• HTTPS 에서만 가능
• AWS 에서 키를 관리하지 않으므로 HTTPS 요청마다 암호화 키를 HTTP 헤더에 제공해야 함

Client-Side Encryption

• AWS 에서 키 생성, 관리 및 암복호화 하지 않고 클라이언트 측에서 모두 수행하는 방식
• Amazon S3 Client-Side Encryption Library 와 같은 클라이언트 라이브러리 사용
• 클라이언트가 데이터를 S3 에 업로드하기 전에 암호화하고, 다운로드 후 복호화한다.

S3 전송 암호화 (SSL/TLS)

• S3 는 두 가지 방식의 엔드포인트를 제공
  • HTTP 엔드포인트 (암호화하지 않음)
  • HTTPS 엔드포인트 (전송 중 암호화)
    • SSL 또는 TLS 방식으로 암호화
• HTTPS 를 권장
• 대부분의 클라이언트는 기본적으로 HTTPS 엔드포인트를 사용

S3 암호화 강제

• S3 버킷 정책을 사용하여 전송 중 암호화를 강제하거나, 오브젝트 업로드 시 특정 암호화 방식으로 강제할 수 있음
• 전송 중 암호화 강제
  • Effect => Deny
  • Condition => (Bool) aws:SecureTransport: false
• S3 객체 업로드 시 암호화 헤더 없는 경우 거부
  • Effect => Deny
  • Condition => (StringNotEquals) s3:x-amz-server-side-encryption: aws:kms
  • Condition => (Null) s3:x-amz-server-side-encryption-customer-algorithm: true
• 사용 사례
  

  

  • 왼쪽 정책은 SSE-KMS 방식 아니면 거부. 오른쪽 정책은 SSE-C 방식 아니면 거부.

• 아니면 기본 암호화 방식을 채택할 수 있다.
• 해당 버킷 정책은 항상 기본 암호화 전에 평가된다.

S3 Access Points

• S3 에 접근하는 사용자나 그룹이 많아지고 S3 에 저장하는 데이터의 유형이 많아짐에 따라 Bucket Policy 에 모든 접근 권한을 설정하기가 복잡해졌다.
• S3 버킷 Prefix 별로 사용자나 그룹의 접근 권한 설정을 한다.
• 접근할 수 있는 포인트인 DNS Name 과 Access Point Policy 를 가지고 있다.
• 사용 시 주의사항
  • VPC 내부에서만 접근하도록 설정하려면
    • VPC Endpoint(Interface 나 Gateway) 무조건 생성 필요
    • VPC Endpoint Policy 에서 S3 Access Point 와 S3 Bucket 둘 다 allow 정책 허용 필요

S3 Object Lambda

• S3 Object Lamda 기능이 출시되기 이전에는 각 어플리케이션의 요구사항을 충족시키기 위해 데이터를 추가 가공 후, 여러 개의 S3 버킷을 준비해서 오브젝트를 반환하거나 S3 Bucket 앞 단에 Proxy 인프라를 설계하여 가공했다.
• AWS Lambda 함수를 사용하여 S3 오브젝트를 반환하기 이전에 결과 값을 수정한다.
• 사용 사례
  • 개인 식별 정보(PII) 삭제
  • 데이터 형식 변환(예 : XML to JSON)
  • 이미지 동적 크기 조정 및 워터마킹
  • 마케팅 차원에서 요청 사용자의 개인 데이터 추가 작업
• 사용 시 주의 사항
  • S3 Access Point 와 S3 Object Point 두 개 다 모두 필요
  • 외부에서 접근 가능하도록 하려면 S3 Access Point 의 Policy 조작 필요
• 참고
  • https://aws.amazon.com/ko/blogs/korea/introducing-amazon-s3-object-lambda-use-your-code-to-process-data-as-it-is-being-retrieved-from-s3/
  • https://medium.com/musinsa-tech/s3-object-lambda%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%9C-on-demand-%EC%9D%B4%EB%AF%B8%EC%A7%80-%EB%B3%80%ED%99%98-%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%86%8C%EA%B0%9C-5e3650cc27a9

S3 CORS

• 웹 브라우저에서 다른 Origin 에 대한 요청으로 인한 공격을 방지하고자 SOP(Same Origin Policy) 정책을 도입함
  • Origin은 scheme (protocol) + host (domain) + port 로 Same Origin 은 프로토콜, 도메인, 포트 번호가 같아야 함
• 하지만 웹 사이트들이 다른 도메인 영역에 웹 자원을 로드하고 서비스하고 있는 경우가 많아 특정 Origin 만 접근이 가능하도록 설정이 필요했다. CORS(Cross-Origin Resourse Sharing) 이라는 기능이다.
• 현재 웹 사이트를 방문하면서 다른 Origin 의 자원을 사용해야 하는 경우, 다른 Origin 서버에서 허용 응답을 보내주어야 한다.
  • 정확히는 응답 헤더로 Access-Control-Allow-Origin, Access-Control-Allow-Methods 등 CORS 헤더를 보내주어야 한다.
• 마찬가지로 S3 에서도 CORS 헤더를 설정함으로써 특정 출처와 메서드들을 허용할 수 있다.
  

  

S3 Delete 방지

MFA 사용

• 사용자가 중요한 S3 작업을 수행하기 전에 MFA (Multi-Factor Authentication) 다중 인증을 추가로 요구할 수 있다.
• 버전 관리 활성화 필수
• MFA Delete 기능을 활성화 / 비활성화 할 수 있는 권한은 버킷 소유자만 가능
• MFA가 필요한 작업은 다음과 같다.
  • 객체 버전을 영구적으로 삭제
  • 버킷에서 버전 관리를 중단할 때
    

S3 Object Lock

• WORM (Write Once Read Many) 모델로 지정된 기간 동안 특정 객체 버전을 삭제하는 것을 방지한다.
• 버저닝 기능이 무조건 활성화 되어 있어야 함
• 버킷 내의 모든 객체에 각각 적용 가능
• 보관 모드
• ( * 법적 보관은 보관모드는 아니나, 비교를 위해 같이 정리하였다 )

S3 Access Logs

• 감사 목적으로 S3 버킷의 모든 액세스를 로깅할 수 있다.
• 승인 또는 거부 여부와 상관없이 모든 계정에서 S3에 대한 요청이 로그로 남는다.
• 로깅 대상 버킷은 동일한 AWS 리전에 있어야 한다.
• Amazon S3 서버 액세스 로그 형식: https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/LogFormat.html
• 사용 시 주의사항
  • 로깅 버킷을 모니터링하는 버킷과 동일하게 설정하면 무한 루프 발생

Pre-Signed URLs

• 접근 권한 인증을 마쳤는데도 불구하고 다른 AWS 서비스 제한 때문에 S3 에 도달하지 못 할 수 있다.
• 접근 권한에 대한 인증을 마치면 직접 S3 에 접근할 수 있는 URL 을 발급해준다.
• URL 만료 기한
  • S3 Console 은 1분부터 720분(12시간)까지 설정 가능
  • AWS CLI 는 --expires-in 매개변수로 만료 시간을 지정할 수 있으며, 초 단위로 설정 가능 (기본값은 3600초, 최대 604800초(168시간))
• 미리 서명된 URL을 받은 사용자는 GET / PUT에 대한 권한을 URL을 생성한 사용자로부터 상속받음.
• 사용 사례
  • 로그인한 사용자만 S3 버킷에서 프리미엄 비디오를 다운로드할 수 있도록 허용
  • URL을 동적으로 생성하여 계속 변경되는 사용자 목록이 파일을 다운로드할 수 있도록 허용
  • 일시적으로 사용자가 S3 버킷의 특정 위치에 파일을 업로드할 수 있도록 허용

Step Functions

AWS 의 마이크로서비스 워크플로우 구현을 위한 오케스트레이션 서비스

Lambda 와 같은 서버리스 서비스들을 조합하여 구현

Step Functions 특징

• AWS 의 다른 서비스들과 네이티브하게 연계 통합 가능
• 비즈니스 로직 중심 워크플로우 설계 가능 (관리형 서비스(내결함성, 안정성, 확장성, 고가용성))
  
  • 빌트인 된 try-catch-finally 패턴을 통해 타임아웃, 재시도, 에러메세지 관리가 가능하여 장애 대응에 원할
  • 모니터링 후, 요청량에 따른 자동 스케일링 가능
• 다양한 상태를 활용하여 워크플로우를 정의하기 쉬움

Step Functions 구조

Action 과 Flow 컴포넌트로 구성되어 있음

• Action
  • 다른 AWS 서비스를 활용하여 작업을 수행
  • 예 : 람다 함수 호출, SNS Publish, AWS Fargate 서비스 호출
• Flow
  • task 들의 제어 흐름을 정의하는 7가지 상태
  • 분기 choice, 반복 map, 동시 실행 parallel, 디버깅 path, 타이머 wait, 성공 success, 실패 fail

Step Functions 구축

• Workflow Studio
• IaC 프레임워크 + 서버리스 개발용 라이브러리(Chalice)
• Serverless Framework (https://www.serverless.com/framework/docs)

Step Functions 는 특성 상 비지니스 로직과 밀접하게 연결되어 있어 인프라와 애플리케이션을 디커플링하여 개발하면 새로운 개발 요청이 들어왔을 때 인프라와 코드를 둘 다 수정해야 되는 단점이 있음.

따라서, 인프라와 애플리케이션을 커플링하여 서비스 변경에 더 민첩하게 반응할 수 있는 애플리케이션 특수적 인프라를 활용하는 추세임.

Step Functions 한계점

Step Functions 는 별도의 요청으로 상한을 올릴 수 있는 소프트 할당량과 상한을 올릴 수 없는 하드 할당량이 있다.

소프트 할당량은 유연하게 대처가 가능하므로 하드 할당량에 대해서 알아본다.

• 페이로드의 최대 크기 (256 KB)

페이로드는 오직 실행이나 컨텍스트 관리에 필수적인 데이터만 포함하여 핸들링하는 것이 바람직하다.

이외 데이터들은 다른 서비스나 서버에 저장 후 로드한다.

• 실행 기록의 최대 이벤트 개수 (25,000 개)

상태머신을 활용할 경우, Step Functions 는 해당 실행에 대한 모든 이벤트를 기록하기 시작한다.

각 상태마다 2 ~ 5 개 정도의 이벤트가 발생한다. 예를 들어 람다 호출의 경우, 람다 예약 => 람다 시작 => 람다 성공 순으로 이벤트가 기록된다.

이베트 개수를 줄이는 방법이 있을 수 있다. 하지만 권장하지 않는다.

예를 들어, 여러 개의 Lambda 함수를 활용하여 병렬처리하는 구조의 애플리케이션을 Lambda 함수 하나로 포팅한다면 이벤트의 개수는 줄일 수 있지만, 병렬 처리로 얻는 속도, 효율 등의 장점들을 모두 포기해야 한다.

Lambda 함수를 통해 상태머신을 재실행하는 방법을 AWS 에서 권장하고 있다.

1 . (plan) StateMachine 시작 전 작업 크기를 계산하고, 현재 실행 정보를 담고 있는 컨텍스트 정보를 생성한다.

• 총 처리해야 하는 개수
• 현재 처리 개수
• 커서

2 . (fetch, apply) 병렬 작업자들에게 할당할 작업들을 생성하고 반복 처리한다.

• 최대 동시성(동시 실행 가능한 작업자의 최댓값)을 고려하여 전체 작업을 처리 가능한 크기의 작업으로 분할한다.
• 반복 실행을 통해 순차 처리한다. 아래 3, 4 단계를 참고한다.

3 . (aggregate) apply 결과 값들을 취합한다.

4 . 더 이상 작업이 없다면 Finish, 아직 작업이 있고 최대 반복 횟수 도달했다면 ExecuteNew, 최대 반복 횟수 미달했다면 다시 fetch 실행

4 - 1 . ExecuteNew 로 실행했다면 현재 실행의 Context 정보도 같이 전달하여 plan 재실행

Active Worker 패턴

AWS 서비스 이외에 다른 서비스(온 프레미스 서비스, 써드 파티 SDK, 다른 클라우드 서비스) 처리 시 지연시간으로 인해

비동기적인 처리가 필요할 수도 있다. 만약 Lambda 로 구현한다면 지속적으로 폴링해야 할 수도 있다. 불필요한 시간을 소요할 수 있으며 결국 Lambda 의 최대 실행 시간인 15분을 넘길 수 있다.

외부 서비스와 통합하기 위해 Activity 를 사용하는 것을 권고한다. 상태머신의 진행을 비동기적으로 바꿀 수 있다.

그런데 아래 공식 문서는 코드 분리 측면으로 봐야되고, 위 병렬 실행 TIP 과는 다른 컨셉으로 봐야 될 것 같다.

https://docs.aws.amazon.com/ko_kr/step-functions/latest/dg/tutorial-use-sfn-api-cont-exec.html

참고

https://www.youtube.com/watch?v=EZrL7p7Qlp4

개념

인프라 구축을 코드형 인프라(IaC) 로 구성할 수 있도록 괸리된 환경에서 배포해주는 서비스

• 지정된 사용자가 원하는 서비스를 골라 프로비저닝
• 해당 서비스에 다양한 Action 들까지 제공
• CloudFormation 으로 구성
• 내부적으로는 Systems Manager Automation 사용

구조

AWS Service Catalog 는 제품, 포트폴리오으로 구성되어 있다.

제품

• 엔드유저에게 제공할 미리 구성된 AWS 인프라
• 각 제품 별 버전 설정 가능
• 신규 버전 생성 시 서비스 액션 역시 다시 연동 필요
• CloudFormation Output 으로 엔드유저에게 정보 제

포트폴리오

• 다양한 제품을 모은 관리 단위
• 그룹/역할/사용자에게 해당 포트폴리오를 이용할 수 있는 권한 부여 가능
• 다른 계정과 공유 가능
• AWS Budget 생성 가능 (Tag 기반)

제약조건

• 사용자가 제품을 프로비전할 때 사용하는 권한
• 사용자가 권한을 가지고 있지 않더라도 제품을 생성하는데 필요한 권한 부여 가능
• 반대로, 사용자가 충분한 권한을 가지고 있어도 제품을 생성 및 사용하는데 제약할 수 있는 권한 부여 가능
• = > 즉 사용자의 권한을 가지고 프로비저닝을 하는 것이 아니라 제약 조건에 명시된 권한으로 프로비저닝
• 서비스 액션 등에도 제약 조건 권한 사용 가능
• IAM 정책 기반
• 아래 유형의 권한으로 구성
  • 시작
  • 알림
  • 템플릿
  • StackSet
  • 태그 업데이트

서비스 액션

• 앤드유저가 제품을 프로비전 후, 제품을 제한적으로 관리하는 방법
• 각 액션 수행 후 이벤트 로그를 통해 수행 결과 확인 가능
• 내부적으로는 Systems Manager Automation 사용

서비스 카탈로그 실습

1 . AWSServiceCatalogEndUserFullAccess 정책 가진  enduser 사용자를 생성한다.

(서비스 카탈로그에 접근 가능한 접근만 가지고 있다.)

2 . enduser 사용자가 사용할 제약조건 역할을 생성한다. 정책 생성 후 역할을 연결!

3 . 서비스 카탈로그에 제품 생성 후, 포트폴리오 생성한다.

4 . 해당 포트폴리오에 enduser 사용자를 추가하고 제약조건 역할을 연결한다.

인프라 관리자가 아니라면, 프로비저닝 하위 항목들만 표시된다. 인프라 관리자가 생성한 항목들만 확인할 수 있다.

삭제 시 주의해야 할 점

포트폴리오 삭제 시 제품과 포트폴리오에 연결된 주체/역할 부터 먼저 삭제해야 함

Amazon EKS 가 마스터 노드를 Amazon EKS Node groups 가 워커 노드를 관리해준다.

EKS 인증

1 . kubectl 명령을 내리면 Kubernetes Master Node 서버에 API 호출

Kubernetes API 서버 인증 토큰과 IAM 인증 토큰(Kubeconfig 파일) 토큰을 함께 보냄.

2 . 요청한 사용자가 IAM User 가 맞는지만 확인

별도로 Policy 정책은 확인하지 않음. aws-auth 라는 configmap 을 생성함. (Kubectl edit configmap aws-auth -n kube-system 명령어로 확인 가능)

Groups 에는 쿠버네티스 RBAC 권한 정보가 포함됨.

EKS 역할

영역으로 분류

특정 네임스페이스 내 리소스 사용 권한 설정과 클러스터 전역의 리소스 사용 권한 설정으로 나뉠 수 있다.

책임으로 분류

IAM Role 과 유사하게 리소스에 대한 권한이 명시적으로 기재되어 있는 Role 과 해당 Role 의 권한을 할당받을 사용자나 그룹을 설정하는 Role Binding 으로 이루어져 있다.

사용자 추가하고 싶을 때

1 . IAM Role 생성

정책들은 확인하지 않고 사용자인지만 확인하기 때문에 빈 역할만 생성해도 된다.

2 . aws-auth Configmap 의 mapRole 에 추가

3 . ClusterRole 또는 Role 생성

4 . ClusterRoleBinding 또는 RoleBinding 생성

5 . aws-auth Configmap 의 mapRole 에 group 설정

6 . 대상 사용자의 kubeconfig 파일에 인증 정보 설정

kubectl 명령어를 호출할 때, 어떤 role 로 실행할지 명시를 해주어야 하기 때문에 이 설정이 필요하다.

EKS 네트워크 구조

단일 호스트일 때 쿠버네티스 네트워크는 eth0 물리 네트워크 인터페이스, docker0 브릿지 네트워크, veth0 가상 네트워크 인터페이스 구조로 구성되어 있다. Pod 안에 여러 개의 컨테이너를 생성하면 가상 네트워크 인터페이스를 공유하면서 하나의 IP 를 부여받게 된다. Pause 컨테이너를 통해 공유하게 된다.

참고로 도커에서는 --net=container:컨테이너이름 옵션을 주게되면 위와 같이 컨테이너 간 네트워크 공유를 할 수 있다.

다중 호스트일 때는 위와 같이 각 호스트 간 내부 IP 가 충돌하는 문제가 발생할 수 있다. 그래서 각 호스트가 여러 개 되어도 각 컨테이너를 찾아갈 수 있게 모든 호스트의 브릿지 네트워크에 각기 다른 IP 를 할당하는 Overay Network 구조를 생각하게 되었다.

쿠버네티스 코어에 있는 것은 아니고 weave net 이나 AWS CNI, calico, flannel 등 쿠버네티스 플러그인으로 제공한다. 그 중 Amazon EKS 는 AWS CNI 를 사용한다.

그런데 AWS CNI 는 다른 플러그인과 다르게 가상 IP 를 부여하는 것이 아닌 VPC IP Range 내부 IP 를 할당하게 된다.

DaemonSet 의 IPAM 이라는 모듈에서 ENI 로부터 IP 를 받아 Pod 를 할당하게 되는데

ENI 가 할당할 수 있는 IP 수를 초과하면 추가로 ENI 를 생성해서 IP 를 부여한다.

인스턴스 유형마다 최대 ENI 개수와 ENI 당 할당할 수 있는 최대 IP 주소가 다르다.

Amazon EC2 인스턴스 유형 사양 - Amazon EC2 (네(트워크 사양 참고)

따라서 최대로 띄울 수 있는 Pod 의 수 = 인스턴스 유형에 따른 ENI 수 * (ENI 별 IP 수 - 1) 개이다. (ENI 자체가 할당 받는 IP 주소가 한 개 있으므로)

EKS 볼륨 관리

Pod 가 내려가면 데이터가 날라가기 때문에 안정적인 데이터 관리가 필요하다.

심플하게 안정적인 저장소를 준비한 다음 컨테이너에 안정적인 저장소를 마운트하면 된다. EBS 나 EFS 를 준비한다.

1 . Storage Class 를 생성

어떤 저장소를 사용할 것인지 명시한다.

2 . Persistent Volume Claim 생성

어떤 스펙으로 생성할 것인지 명시한다.

3 . 컨테이너에 마운트

EKS 모니터링

마스터 노드 로그는 대상 클러스터 로깅 설정으로 CloudWatch 에 로그가 적재되고 확인할 수 있다.

Pod 모니터링은 Container Insights 를 통해 확인할 수 있다.

1 . 워커 노드의 IAM Role 편집

2 . CloudWatchAgentServerPolicy 정책 추가

3 . 빠른 시작 설정

4 . CloudWatch 페이지 이동

5 . Container Insights 선택

6 . 대상 EKS 클러스터 선택

출처

쿠알못이 Amazon EKS로 안정적인 서비스 운영하기 - 최용호 (넥슨코리아) :: AWS Community Day 2020 (youtube.com)