Las 낙서장

Kafka

- Pub-Sub 모델의 메시지 큐이고 분산환경에 특화되어 설계되었음

- 기존 RabbitMQ와 같은 다른 메시지큐와의 성능차이(훨씬 빠르게 처리)가 나며 그 외에도 클러스터 구성, Fail-Over, Replication과 같은 여러가지 특징을 가짐

- 아파치 카프카는 분산 스트리밍 플랫폼이며 데이터 파이프라인을 만들때 주로 사용

- 대용량의 실시간 로그처리에 특화되어 있는 솔루션이며 데이터를 유실없이 안전하게 전달하는 것이 주목적인 메세지 시스템에서 Fault-Tolerant한 안정적인 아키텍처와 빠른 퍼포먼스로 데이터를 처리할 수 있음

아키텍처

1. Producer가 데이터를 카프카에 적재

2. Foo와 Bar는 각각 3개의 파티션으로 나뉘어져 있고 이 각각의 파티션들은 3개의 복제본으로 복제

3. 3개의 복제본 중에는 하나의 리더(하늘색)가 선출되게 되고 이 리더가 모든 데이터의 읽기/쓰기 연산을 담당

4. 카프카 클러스터에서 데이터를 가져오게 될 때는 컨슈머 그룹 단위로 가져옴

(이 컨슈머 그룹은 자신이 가져와야하는 토픽 안의 파티션의 데이터를 Pull 하게 되고 각각 컨슈머 그룹안의 컨슈머들이 파티션이 나뉘어져 있는 만큼 데이터를 처리)

5. 저장된 데이터를 Consumer Group A와 B가 각각 자신이 처리해야할 Topic을 가져옴

- 파티션들은 운영 도중 그 수를 늘릴 수 있지만 절대 줄일 수 없음 (파티션을 늘리는 것은 신중하게 고려)

용어

- 프로듀서 (Producer)

• 데이터를 발생시키고 카프카 클러스터에 적재하는 프로세스

• 메시지 송신 API

• 특정 Topic에 해당하는 메시지를 생성하는 프로세스, 메시지를 Broker에 전달 (발행/Publish)

• Producers는 데이터를 그들이 선택한 Topic으로 Publish

• Producers가 메시지를 실제로 어떤 Partition으로 전송할지는 사용자가 구현한 Partition 분배 알고리즘에 의해 결정

  (예를 들어 Round-Robin 방식의 Partition 분배 알고리즘을 구현하여 각 Partition에 메시지를 균등하게 분배하도록 하거나, 메시지의 키를 활용하여 알파벳 A로 시작하는 키를 가진 메시지에 P0에만 전송하고, B로 시작하는 키를 가진 메시지는 P1에만 전송하는 형태로 구성도 가능)

- 카프카 클러스터 (Kafka Cluster) : 카프카 서버로 이루어진 클러스터

• 브로커 (Broker)

• • 카프카 서버

  • Topic을 기준으로 메시지 관리

  • Broker는 클러스터로 구성 (이에 대한 분산처리는 Zookeeper가 처리)

  • Producers와 Consumer가 만날 수 있도록 메시지를 관리하는 서버 클러스터로 Producer에게서 전달받은 메시지를 Topic별로 분류

  • 여러대의 Broker Cluster로 구성 가능하며, Zookeeper에 의해 각 노드가 모니터링

• 주키퍼 (Zookeeper)

• • 분산 코디네이션 시스템으로 카프카 브로커를 하나의 클러스터로 코디네이팅하는 역활을 하며 카프카 클러스터의 리더를 발탁하는 방식도 주키퍼가 제공하는 기능을 이용

• 토픽 (Topic)

• • 카프카 클러스터에 데이터를 관리할 시 그 기준이 되는 개념, 토픽은 카프카 클러스터에서 여러개 만들 수 있으며 하나의 토픽은 1개 이상의 파티션으로 구성 (어떤 데이터를 관리하는 하나의 그룹  개념으로 생각하면 됨)

  • 발행(Publish)된 메시지들의 카테코리

  • 유사한 메시지들의 집합으로 Producer는 메시지를 전달한 Topic을 반드시 지정해야함

  • Partition 단위로 클러스터 각 서버들에 분산 저장

  • 각 Partition은 0부터 1씩 증가하는 offset 값을 메시지에 부여 (Partition내 메시지 식별)

  • 클러스터 내 메시지들은 설정된 기간동안 유지 후 삭제

• 파티션 (Partition)

• • 각 토픽 당 데이터를 분산 처리하는 단위, 카프카에서는 토픽안에 파티션을 나누어 그 수대로 데이터를 분산처리함 (카프카 옵션에서 지정한 Replica의 수만큼 파티션이 각 서버들에게 복제)

  • 로드밸런싱을 목적으로 Topic을 분할하는 것을 의미

• 리더, 팔로워 (Leader, Follower)

• • 카프카에서는 각 파티션당 복제된 파티션 중에서 하나의 리더가 선출, 이 리더는 모든 읽기/쓰기 연산을 담당, 리더를 제외한 나머지는 팔로워가 되고 이팔로워들은 단순히 리더의 데이터를 복사하는 역활만 수행

• 로그 (Log)

• • Producers가 생성한 메시지

• 리플리케이션 (Replication)

• • Fault Tolerance 위해 Partition 단위로 복제

- 컨슈머 그룹 (Consumer Group)

• 컨슈머의 집합을 구성하는 단위, 카프카에서는 컨슈머 그룹으로서 데이터를 처리하며 컨슈머 그룹안의 컨슈머 수만큼 파티션의 데이터를 분산처리하게 됨

• 메시지 수신 API

• Broker에게서 구독(Subscribe)하는 Topic의 메시지를 가져와 사용(처리)하는 프로세스

• Topic에 할당된 쓰레드 개수만큼 쓰레드가 만들어지면 Partition으로부터 메시지를 읽음

• 하나의 쓰레드는 1개 이상 Partition으로 부터 메시지를 읽을 수 있음

• Public void run 메소드 내에 while(is.hasNext())에서 블록킹 되어 있다가 Partition으로 메시지가 들어오면 이 곳에서 메시지를 읽음, 따라서 다른 타겟으로 메시지를 처리하는데 적합한 장소

• (메시지를 파일로 저장하던지 대용량 입력이 가능한 하둡이나 NoSQL로 저장하기에 유용)

- 컨슈머 API (Consumer API)

• 컨슈머에 두 가지 API 제공 (Simple Consumer API, High-Level Comsumer API)

• 세부적인 것들은 모두 추상화되어 있어 몇 번의 간단한 함수 호출로 Consumer를 구현할 수 있는 High-Level Consumer API

• offset과 같은 세부적인 부분까지 다룰 수 있지만 이 때문에 구현하기가 상당히 까다로운 Simple Consumer API가 제공

카프카 파티션 읽기, 쓰기

- 카프카에서 읽기/쓰기 연산은 카프카 클러스터 내의 리더 파티션들에게만 적용

- 하늘색으로 칠해진 각 파티션들은 리더 파티션이며 이 파티션들에게 프로듀서가 쓰기 연산을 진행

- 리더 파티션에 쓰기가 진행되고 난 후 업데이트된 데이터는 각 파티션들의 복제본들에게 복사

- 카프카는 데이터를 순차적으로 디스크에 저장

- 프로듀서는 순차적으로 저장된 데이터 뒤에 붙이는 Append 형식으로 Write 연산을 진행

- 이때 파티션들은 각각의 데이터들의 순차적인 집합인 오프셋(offset)으로 구성

- 컨슈머 그룹의 각 컨슈머들은 파티션의 오프셋을 기준으로 데이터를 순차적으로 처리하게 됨 

- 중요한 것은 컨슈머들은 컨슈머 그룹으로 나뉘어서 데이터를 분산 처리하게 되고 같은 컨슈머 그룹 내에 있는 컨슈머 끼리 같은 파티션의 데이터를 처리할 수 없음

- 파티션에 저장되어 있는 데이터들은 순차적으로 데이터가 저장되어 있으며 이 데이터들은 설정값에 따라 데이터를 디스크에 보관 (기본 7일)

- 컨슈머 그룹단위로 그룹 내 컨슈머들이 각각 파티션의 데이터를 처리하는 모습을 나타낸 것으로 만일 컨슈머와 파티션의 개수가 같다면 컨슈머는 각 파티션을 1:1로 맡게 됨

- 만일 컨슈머 그룹안의 컨슈머의 개수가 파티션의 개수보다 적을 경우 컨슈머 중 하나가 남는 파티션의 데이터를 처리

(컨슈머 개수가 파티션의 개수보다 많을 경우 컨슈머는 파티션의 개수가 많을때까지 대기)

사용 예제

Why Use It? 왜 사용하나요?

- High-throughput message capacity

쉽게 이야기해서 단 시간 내에 엄청난 양의 데이터를 컨슈머 쪽으로 전달 가능합니다. 다른 경쟁 제품에 비해 많은 양의 데이터 전송이 가능한 이유는 크게 두 가지 있는데 우선 첫째, 기존의 메세지 시스템이 메세지 브로커 쪽에서 가지고 있던 모든 복잡한 과정 또는 연산들을 제거했고 둘째, 하나의 토픽에 대해 여러 개의 파티션으로 분할 할 수 있도록 해서 컨슈머 쪽에서 분산 처리할 수 있도록 하였습니다. 좀더 자세히 설명하자면 기존의 메세지 시스템들은 (RabbitMQ 같은) 각각의 토픽에 대해 컨슈머들의 인덱스 (데이터를 어디까지 전송받았는지를 알려주는) 정보를 메세지 브로커 쪽에서 관리하였는데 카프카는 이 부분을 컨슈머 쪽으로 책임을 옮겼으며 또한 메세지를 유지하는 방법도 메모리에 잠시 보관하였다가 컨슈머에 전송된 후 삭제하는 방법이 아니라 일반 파일에 Log 형식으로 (데이터가 날짜순으로 저장되고 Append만 가능한 형식) 관리하여 전송 후에 Delete 연산이 필요없는 방식을 사용하고 있습니다. 또한 토픽의 분할 기능을 제공하여 같은 토픽에 대해 여러 개의 컨슈머가 동시에 메세지를 전송 받는 등의 분산 처리를 지원하여 많은 양의 데이터 전송을 가능하게 하고 있습니다.

- Scalability와 Fault tolerant

카프카는 클러스터 모드를 지원하고 있으며 위에 언급했던 토픽 파티셔닝 (하나의 토픽을 여러 개의 파티션으로 나눌 수 있는 기능)과 파티션 복제 (Replication) 기능을 통해 확장성과 Fault tolerant (부분적으로 고장나더라도 중요한 기능들은 정상적으로 작동하는 특성)을 제공하고 있습니다.

- 메세징 시스템 외에 다양한 용도로 사용 가능

일반적인 메세징 시스템과 달리 카프카는 다양한 용도로 사용 가능하며 자세한 사용 용도에 대해서는 아래의 글을 참조하세요.

Use Cases (카프카의 사용 용도의 예)

- Messaging System: 가장 일반적으로 많이 사용되고 있는 용도로 메세지 제공자 (Producer 또는 Source)와 수신자 (Consumer 또는 Sink) 사이에서 메세지를 전달해주는 역할을 합니다. 각각의 컨슈머 (또는 컨슈머 그룹)는 전달받기를 원하는 메세지의 토픽에 구독 신청해야 하며 하나의 토픽에 여러 컨슈머가 구독 신청 할 수 있습니다. (이 경우에 메세지는 구독신청한 모든 컨슈머한테 Broadcast 됩니다.)

- Website Activity Checking 및 Monitoring: 링크드인에서 처음 만들고 사용했던 목적처럼 웹사이트가 정상적으로 돌아가는지 또는 웹사이트 사용 시 유저들의 패턴이 어떻게 되는지 모니터링 또는 웹사이트 이벤트 체킹의 목적으로도 사용 가능하며 (중간에서 메세지를 전달하는 중간자의 역할을 할 수도 있지만 메세지 자체가 디스크에 일정 기간 동안 로깅이 되어 있기 때문에 직접 분석도 가능합니다.)

- Log Aggregation: 하나의 웹사이트가 여러 대의 서버로 운영되고 있다면 (대부분의 엔터프라이즈 웹사이트들이 그렇듯이) 각각의 서버에 있는 로그를 통합해주는 시스템 구축에도 사용 가능합니다.

- Stream Processing & Batch Processing: 요즘 빅데이터 쪽에서 가장 핫한 Spark나 Storm같은 Stream Processing (스트림 처리)을 지원하는 플랫폼이나 Hadoop과 같이 Batch Processing (일괄 처리)을 지원하는 플랫폼과 연결햐여 메세지의 변환도 가능합니다.

- Etc: 그 외에 연결된 DB나 서치 엔진의 일시적 서비스 장애 때문에 다운이 되었을 때 메세지들을 잠시 저장해줄 수 있는 임시 버퍼의 역할도 가능하며 Operational metrics (각각의 토픽에 대해 들어오는 메세지의 수를 정기적으로 체크하여 그 수가 너무 낮거나 높을 때 문제가 있는 확인차 운영팀에 메일등을 통해 알려주는 용도)나 Event sourcing (특정 이벤트들을 시간 순으로 기록하여 나중에 필요할 때 사용하는 용도) 등의 용도로도 사용되고 있습니다.

참조 URL

https://epicdevs.com/17

http://utk-unm.blogspot.com/2016/10/apache-kafka.html

https://dadk.tistory.com/5

https://engkimbs.tistory.com/691

https://medium.com/@umanking/%EC%B9%B4%ED%94%84%EC%B9%B4%EC%97%90-%EB%8C%80%ED%95%B4%EC%84%9C-%EC%9D%B4%EC%95%BC%EA%B8%B0-%ED%95%98%EA%B8%B0%EC%A0%84%EC%97%90-%EB%A8%BC%EC%A0%80-data%EC%97%90-%EB%8C%80%ED%95%B4%EC%84%9C-%EC%9D%B4%EC%95%BC%EA%B8%B0%ED%95%B4%EB%B3%B4%EC%9E%90-d2e3ca2f3c2

PinPoint

- APM (Application Performance Management) Tool로서 Java로 만들어진 Large-Scale 분산 시스템에서 사용될 수 있음

- 대규모 분산 시스템의 성능을 분석하고 문제점을 진단, 처리하는 Java 플랫폼

특징

- 분산된 애플리케이션의 메시지를 추적할 수 있는 분산 트랜잭션 추적

- 애플리케이션 구성을 파악할 수 있는 애플리케이션 토폴로지 자동 발견

- 대규모 서버군을 지원할 수 있는 수평 확장성

- 코드 수준의 가시성을 제공해 문제 발생 지점과 병목 구간을 쉽게 발견

- bytecode instrumentation 기법으로 코드를 수정하지 않고 원하는 기능을 추가

기능

- ServerMap (서버맵)

• 대상 서버와 연결된 다른 서버와의 관계 다이어그램

• 각 구성요소가 어떻게 상호연결되는지 시각화

• 각 노드를 클릭하여 현재 상태, Transaction 수 등과 같은 구성요소에 대한 세부 사항을 확인할 수 있음

- Request/Response Scatter Chard (스캐터)

• 요청별 응답시간에 따른 그래프

• Request 수, Response 패턴을 시각화

• Transaction은 차트에서 드래그함으로써 추가 상세 정보를 선택할 수 있음

- CallStack (콜스택)

• 하나의 뷰에서 병목지점, 실패위치(points of failure)를 식별

• 분산 환경에서 모든 Transaction에 코드 수준의 가시성을 확보할 수 있음

- Inspector (인스펙터)

• CPU 사용량, 메모리/GC, JVM Arguments와 같은 Application 상세 정보를 제공

아키텍처

1. HostJVM은 현재 실행중인 Application이 돌아가는 WAS (해당 위치에 PinPoint Agent가 설치)

2. HostJVM이 동작하는 동안 PinPoint Agent는 Profile 정보를 Profiled Applications로 전송

3. 수집된 정보는 Pinpoint Collector가 HBase에 기록

4. 기록된 정보는 Pinpoint Web UI를 통해 확인

용어 

- HBase (for storage) : PinPoint Agent로부터 수집된 정보를 기록 (Haddop database)

- Pinpoint Collector (Deployed on a web Container) : 외부에서 전송되는 정보를 수집

- PinPoint Web (Deployed on a web Container) : PinPoint Collector가 수집하여 HBase에 기록된 정보를 확인

- PinPoint Agent (Attached to a Java Application for Profiling) : 모니터링할 Host JVm에 설치되어 정보를 전송

참조 URL

https://dev2.prompt.co.kr/33?category=98615

https://d2.naver.com/helloworld/1194202

Crawling (Web Scraping)

- 특정 페이지에 있는 정보들을 내가 원하는 포맷으로 가져오는 것

- 컴퓨터 소프트웨어 기술로 웹 사이트들에서 원하는 정보를 추출하는 것을 의미

- 웹 사이트를 자동으로 돌아다니며 분석 및 저장 등을 하는 행위 정도로 저장할 수 있음

- 사람들이 웹페이지에 직접 접속해서 정보를 읽어들이는 것과 유사

- 인터넷상에 흩어져 있는 자료들을 사람 대신에 프로그램을 통하여 서핑하며 수집과 가공을 하는 것

- 이때 프로그램의 구성에 따라 서핑 능력 차이가 발생하게 되는데 대표적으로 자바스크립트의 처리를 하는지 못하는지에 여부가 있음

크롤링 매커니즘

1. 크롤링 대상선정 (API 또는 웹 문서)

• 웹 상의 데이터는 고유한 ID를 가지는데 이를 URI이라 부르며 웹 사이트 주소인 URL과 URN이 있음

• 간단하게 과일에 대한 네이버 검색 결과를 크롤링하려면 아래의 결과에 대한 URL을 선정하는 과정

2. 데이터 로드

• 데이터 로드는 웹사이트를 켜는 것과 같음

• 만약 API라면 XML, JSON 문서가 될 것이고, 웹 페이지라면 HTML 문서를 다운 받는 것

3. 데이터 분석

• 로드된 데이터에서 필요한 부분을 뽑아내는 것을 의미 (웹 사이트에서는 사용자가 필요로 하지 않는 부분이 많음)

• 어떠한 부분을 수집할지, 어떤 부분을 수집하지 않을지 선정하는 과정

4. 수집

• 데이터 분석 과정을 통해서 수집할 내용을 선정했다면 이를 추출하여 파일 또는 데이터를 메모리상에 저장하는 과정 

크롤링을 하기전 알아야하는 지식

HTTP Method

- Get

• 리소스 요청 (크롤링에 주로 사용) => 받아들이는 역활

• 주소와 함께 메시지를 남김

• 파일 업로드 불가

• 잘 설계된 서비스라면 주로 조회 요청시 사용

• 실생활에 비유하자면 엽서

- POST

• 대기 리소스 추가 요청이나 수정, 삭제 목적으로 사용 (크롤링에 주로 사용) => 사용자가 추가로 요청하는 것

• 주소와 함께 메시지나 파일도 보낼 수 있음

• 파일 업로드 지원

• 잘 설계된 서비스에서 주로 추가, 수정, 삭제 요청시에 사용

• 실생활에 비유하자면 택배

- PUT 

• 리소스 수정 요청

- DELETE 

• 리소스 삭제 요청

- HEAD 

• HTTP 헤더 정보만 요청, 해당 자원의 존재 여부를 확인하기 위한 목적

- OPTIONS 

• 웹 서버가 지원하는 메소드 종류 반환 요청

- TRACE 

• 클라이언트의 요청을 그대로 반환

HTTP 요청 / 응답 패킷 형식

요청 패킷

- 요청 헤더 : 클라이언트에서 필요한 헤더 Key / Value를 셋팅한 후 요청, 전달

- 첫번째 빈줄 : Header와 Body 구분자

- Body : 클라이언트에서 필요한 Body를 셋팅한 후 요청, 전달

응답 패킷

- 응답 헤더 : 서버에 필요한 Key / Value를 셋팅한 후 응답, 전달

- 첫번째 빈줄 : Header와 Body 구분자

- Body : 서버에서 필요한 Body를 셋팅한 후 요청, 전달

요청 패킷 vs 응답 패킷

- 요청 헤더는 클라이언트에서 필요한 헤더 Key / Value를 셋팅한 후 요청, 전달을 하지만 응답헤더는 서버에 필요한 Key / Value를 셋팅한 후 응답, 전달

- 쉽게 생각하면 클라이언트는 사용자이기 때문에 당연히 서버에 요청을 할 것이고 서버는 서비스하는 업체 입장이기 때문에 응답을 해주는 것

(Ex. 클라이언트 - 요청 (음식점의 주문), 서버 - 응답 (주문받은 음식을 전달)

헤더

- HTTP 요청 / 응답 시에 헤더 정보가 Key / Value 형식으로 셋팅됨

- 대부분 브라우저에서는 다음 헤더를 설정하는데

• User-Agent : 브라우저의 종류

• Referer : 이전 페이지 URL (어떤 페이지를 거쳐왔는지에 대한)

• Accept-Language : 어떤 언어로 응답을 원하는가

• Authorization : 인증 정보

- 크롤링을 할때는 User-Agent 헤더와 Referer를 커스텀하게 설정할 필요가 있음

• 서비스에 따라 User-Agent 헤더와 Referer 헤더를 통해 응답을 거부하기도 함 (Ex. 네이버 웹툰)

바디

- HTTP 요청시에는 Body가 없고 응답에만 있음 (요청에는 당연히 없는 것이고 요청에 대한 응답에 있는게 당연함)

(Ex. HTML 코드, 이미지 데이터, JavaScript 코드, CSS 코드 등등)

기타

- 파싱

• 가공되지 않은 문자열에서 필요한 부분을 추출하여 의미있는 (구조화된) 데이터로 만드는 과정

- Request의 원리

• 첫 응답만 받으면 추가 요청이 없음

• 단순한 요청에 최적화

• HTML 응답을 받더라도 이에 명시된 이미지/CSS/JavaScript 추가 다운을 수행하지 않지만 직접 다운로드 요청은 가능

- Selenium

• 웹 브라우저 자동화 툴

• JavaScript/CSS 지원, 기존 GUI 브라우저 자동화 라이브러리

• 사람이 웹 서핑하는 것과 동일한 환경이지만 그만큼 리소스를 많이 사용

• 웹 브라우저에서 HTML에 명시된 CSS/JavaScript를 모두 자동 다운로드하여 적용

• Selenium이 직접하지않고 크롬등의 툴을 가지고 사용하기 때문에 리소스 사용이 많음

참조 URL

https://rednooby.tistory.com/96

https://jcdgods.tistory.com/317

https://www.slideshare.net/2minchul/web-scraping-75314593

REST 정의

- REST는 Representational State Transfer이라는 용어의 약자로 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처

- 웹에 존재하는 모든 자원(이미지, 동영상, DB 자원 등)에 고유한 URI를 부여해 활용하는 것으로 자원을 정의하고 자원에 대한 주소를 지정하는 방법론

- 자원의 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미

- 자원(Resource)의 표현(Representation)에 의한 상태 전달

• 자원(Resource)의 표현(Representation)

  * 자원 : 해당 소프트웨어가 관리하는 모든 것 (Ex. 문서, 그림, 데이터, 해당 소프트웨어 자체 등등)

  * 자원의 표현 : 그 자원을 표현하기 위한 이름 (Ex. DB의 학생 정보가 자원일 때 ’Students’를 자원의 표현으로 정함)

• 상태(정보) 전달

  * 데이터가 요청되어지는 시점에서 자원의 상태(정보)를 전달

  * JSON 혹은 XML을 통해 데이터를 주고 받는 것이 일반적

- REST 아키텍처는 Hypermedia API의 기본을 충실히 지키면서 범용성을 보장

- Network 상에서 Client와 Server 사이의 통신 방식 중 하나

REST 개념

- HTTP URI을 통해 자원을 명시하고 HTTP Method (POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미

- REST는 자원 기반의 구조(ROA, Resource Oriented Architecture) 설계의 중심에 Resource가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍처를 의미

- 웹 사이트 이미지, 텍스트, DB 내용 등의 모든 자원에 고유한 ID인 HTTP URL을 부여

- CRUD Operation

• Create : 생성 (POST)

• Read : 조회 (GET)

• Update : 수정 (PUT)

• Delete : 삭제 (DELTE)

• HEAD : header 정보 조회 (HEAD)

Richardson Maturity Model (RMM)

레벨 0

- 웹의 기본 메커니즘을 사용하지 않는 단계로 HTTP를 통해 데이털르 주고 받지만 모든 데이터 요청 및 응답과 관련한 정보를 HTTP의 Body정보를 활용

POST /appointmentService HTTP/1.1

[various other headers]

<openSlotRequest date = "2010-01-04" doctor = "mjones"/>

- POX (Plain Old XML)로 요청과 응답을 주고받는 RPC 스타일 시스템으로 HTTP Method는 POST만 사용하며 특정 서비스를 위해 클라이언트에서 접근할 Endpoint는 하나

레벨 1 - 리소스

- RMM에서 REST를 위한 첫 단계는 리소스를 도입하는 것으로 모든 요청을 단일 서비스 Endpoint로 보내는 것이 아니라 개별 리소스와 통신

POST /doctors/mjones HTTP/1.1

[various other headers]

<openSlotRequest date = "2010-01-04”/>

- 즉 함수를 호출하고 인자들을 넘기는 것이 아니라 다른 정볼르 위해 인자들을 제공하는 특정 리소스로 요청을 보냄

- 이럴 경우 이점은 자원이 외부에 보여지는 방식과 내부에 저장되는 방식을 분리할 수 있다는 것

- 예를 들어 클라이언트 단에서 완전히 다른 포맷으로 저장하더라도 JSON 형태의 데이터를 요청할 수 있음

레벨 2 - HTTP Method

- 레벨 1의 URL + HTTP Method 조합으로 리소스를 구분하는 것으로 응답상태를 HTTP Status code를 활용 (현재 가장 많은 RESTful API 이 단계를 제공)

GET /doctors/mjones/slots?date=20100104&status=open HTTP/1.1

Host: royalhope.nhs.uk

- 발생한 에러의 종류를 커뮤니케이션하기 위해 상태코드(Status Code)를 사용하는 것, 그리고 안전한 오퍼레이션 (GET 등)과 안전하지 않은 오퍼레이션 간의 강한 분리를 제공하는 것이 레벨 2의 핵심 요소

- Status Code를 사용한다는 것은 기존에는 유저 생성 요청을 했을 경우 302 등의 리다이렉트 요청을 서버에서 내려주는 방식이었다면 지금은 201(created)로 유저 생성 성공을 알릴 뿐 페이지 이동은 Client 단에서 해결하는 방식 (Login의 경우 성공은 200, 실패시 인증실패는 401, 성공했으나 권한 문제는 403 등)

- 즉 서버는 순수하게 API로서의 기능만 제공하게 되는 것 (View는 Client에서)

- 강한 분리를 제공하는 것은 HTTP에서 GET은 멱등박식으로 자원을 추출하는데 이에 어떤 순서로든 얼마든지 호출하든 매번 같은 결과를 얻도록함 (이에 통신상의 모든 참여자에게 캐싱 기능을 지원하는 다양한 방법을 제공)

레벨 3 - 하이퍼미디어 컨트롤

- HATEOAS (Hypertext As The Engine Of Application State) 애플리케이션 상태 엔진으로서의 하이퍼 미디어

- 하이퍼 미디어란 하나의 컨텐츠가 텍스트나 이미지, 사운드와 같은 다양한 포맷의 컨텐츠를 링크하는 개념

- 이것은 관련 컨텐츠를 보기위해 링크를 따라가는 방식과 유사한 방식으로 동작하는데, 클라이언트가 다른 자원에 대한 링크를 통해 서버와 (잠재적으로 상태 변이를 초래하는) 상호작용을 함

- 즉 특정 API를 요청한 후 다음 단계로 할 수 있는 작업을 알려주는 것이며 다음 단계의 작업을 위한 리소스의 URL을 알려주는 것

- 이 단계를 적용하면 클라이언트에 영향을 미치지 않으면서 서버를 변경하는 것이 가능

GET /doctors/mjones/slots?date=20100104&status=open HTTP/1.1

Host: royalhope.nhs.uk

HTTP/1.1 200 OK

[various headers]

<openSlotList>

<slot id = "1234" doctor = "mjones" start = "1400" end = "1450">

            <link rel = "/linkrels/slot/book"

            uri = "/slots/1234"/>

</slot>

<slot id = "5678" doctor = "mjones" start = "1600" end = "1650">

            <link rel = "/linkrels/slot/book"

            uri = "/slots/5678"/>

</slot>

</openSlotList>

- 단점은 클라이언트가 수행할 작업을 찾기 위해 링크를 따라가기 때문에 컨트롤 탐색에 꽤 많은 호출이 발생할 수 있다는 것

- 또한 복잡성이 증가할 수 있으며 HTTP 요청상에 나타나는 부하로 낮은 지연시간이 요구될 때 문제가 될 수 있음

- HTTP 기반의 REST 페이로드는 JSON 또는 바이너리 등의 포맷을 지원하므로 실제로 SOAP보다 훨씬 간결할 수 있지만 쓰리프트와 같은 바이너리 프토토콜에는 상대가 되지 못함

- 또한 웹 소켓의 경우 HTTP 초기 핸드세이크 후에 클라이언트와 서버 간에 TCP 접속이 이루어지고 브라우저에서 스트림 데이터를 보낼 때 효율적일 수 있음

- 따라서 HTTP가 대규모 트래픽에는 적합할 수 있지만 TCP 또는 다른 네트워킹 기술 기반의 프토콜과 비교하면 낮은 지연시간이 필요한 통신에는 그다지 좋은 선택이 아닐 수 있음

- 이러한 단점에도 HTTP 기반의 REST는 서비스 대 서비스의 상호작용을 위한 합리적이고 기본적인 선택

REST 구성 요소

1. 자원 (Resource) : URL

- 모든 자원에 고유한 ID가 존재하고 이 자원은 Server 존재

- 자원을 구별하는 ID는 ‘/group/:group_id’ 와 같은 HTTP URL

- Client는 URL을 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청

2. 행위 (Verb) : HTTP Method

- HTTP 프로토콜의 Method를 사용

- HTTP 프로토콜은 GET, POST, PUT, DELETE와 같은 Method를 제공

3. 표현 (Representation of Resource)

- Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답을 보냄

- REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등의 여러 형태의 표현으로 나타낼 수 있음

- JSON 혹은 XML을 통해 데이터를 주고 받는 것이 일반적

REST의 특징

1. Server-Client (서버-클라이언트 구조)

- 자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client

• REST Server : API를 제공하고 비즈니스 로직 처리 및 저장을 책임

• Client : 사용자 인증이나 Context(세션, 로그인 정보) 등을 직접 관리하고 책임

- 상호간 의존성 줄어듬

2. Stateless (무상태)

- HTTP 프로토콜은 Stateless Protocol이므로 REST 역시 무상태성을 가짐

- 무상태성이란 작업을 위한 상태정보를 따로 저장하고 관리하지 않음 (세션 정보나 쿠키 정보를 별도로 저장하고 관리하지 않기 때문에 API Server는 들어오는 요청만 단순히 처리하면 됨)

- Client와 Context를 Server에 저장하지 않음 (세션과 쿠키와 같은 Context 정보를 신경쓰지 않아도 되므로 구현이 단순해짐)

- Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리

• 각 API 서버는 Client의 요청만을 단순 처리

• 이전 요청이 다음 요청의 처리에 연관되어서는 안된다는 것 (이전 요청이 DB를 수정하여 DB에 의해 바뀌는 것은 허용)

• Server의 처리방식에 일관성을 부여하고 부담이 줄어들어 서비스 자유도가 높아짐

3. Cacheable (캐시 처리 기능)

- 웹 표준 HTTP Protocol을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용 가능

• HTTP가 가진 가장 강력한 특징 중 하나인 캐싱 기능 적용할 수 있음

• HTTP Protocol 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현이 가능

- 대량의 요청을 효율적으로 처리하기 위해 캐시가 요구

- 캐시 사용을 통해 응답시간이 빨라지고 REST Server 트랙잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률을 향상시킬 수  있음

4. Layered System (계층화)

- Client는 REST API Server만 호출

- REST Server는 다중 계층으로 구성될 수 있음

• API Server는 순수 비즈니스 로직을 수행하고 그 앞단에 보안, 로드밸런싱, 암호화, 사용자 인증 등을 추가하면 구조상의 유연성을 줄 수 있음

• 로드밸런싱, 공유 캐시 등을 통해 확장성과 보안성을 향상시킬 수 있음

- Proxy, Gateway 같은 네트워크 기반의 중간 매체를 사용할 수 있음

5. Self-descriptiveness (자체 표현 구조)

- REST API 메시지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조로 되어 있음

- Server로부터 스크립트를 받아서 Client에서 실행 

- 반드시 사용할 필요 없음

6. Uniform Interface (인터페이스 일관성)

- URL로 지정한 Resource에 대한 모든 조작이 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일

- HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용 가능 (특정 언어나 기술에 종속되지 않음)

REST의 단점

- HTTP 메소드의 한계에 묶임

• REST API는 HTTP 메소드를 이용하여 URL에 대한 행위를 정의하는데 따라서 간단한 수준의 메소드만 지원할 수 있음 (예를 들어 메일을 보낸다라는 행위는 단일 메소드로 구현하기 쉽지않음)

- 표준이 없어서 관리하기 어려움

• REST API는 API 설계 가이드일뿐 명시적인 표준이 아님, 따라서 관리가 어렵고 좋은 API 디자인에 대한 가이드가 쉽지 않음, 어떤 가이드는 특정한 REST API에는 맞지만 또 다른 곳에서는 맞지 않을 수 있음

- RDMS와의 관계

• REST API를 RDBMS에 적극적으로 사용하기 위해서는 RESTful한 테이블 구조가 필요하게 된는데 이것보다는 NoSQL 쪽이 더 잘 맞는 추세

REST API

- HTTP 통신에서 어떤 자원에 대한 CRUD요청을 Resource와 Method로 표현하여 특정한 형태로 전달하는 방식

RESTful

- REST API의 설계 의도를 정확하게 지켜주는 API를 RESTful 하다라고 표현

- RESTful한 API는 구성요소들의 역활이 명확하게 분리되어 있어야 함

- URL은 자원을 정확하고 인식하기 편하게 표현하는데에 집중하고 지우너에 대한 행위는 Uniform하게 HTTP 메소드를 통해 정의해야함

참조 URL

https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

https://nesoy.github.io/articles/2017-02/REST

https://www.a-mean-blog.com/ko/blog/%ED%86%A0%EB%A7%89%EA%B8%80/_/REST%EC%99%80-RESTful-API

https://meetup.toast.com/posts/92

http://blog.naver.com/PostView.nhn?blogId=complusblog&logNo=220986337770

https://brainbackdoor.tistory.com/53

https://hyunalee.tistory.com/1

IAM TAG

- IAM 태그를 사용하면 Key - Value 페어의 형태로 사용자 또는 역활에 사용자 지정 속성을 추가할 수 있음

- 태그를 사용하면 AWS에서 권한을 제어할 수 있음

- IAM 정책을 생성할때 IAM 태그와 연관된 태그 조건 키를 사용하여 다음중 하나를 수행하기 위한 액세스를 제어

• 리소스 : 리소스에 대한 태그를 기반으로 사용자 또는 역활에 대한 액세스를 제어 

  (iam:ResourceTag/key-name 조건 키를 사용하여 리소스에 연결된 태그를 기반으로 IAM 리소스에 대한 액세스를 허용할지 여부를 결정)

• 요청 : 어떤 태그가 IAM 요청에 전달될 수 있는지 제어

  (aws:RequestTag/key-name 조건 키를 사용하여 어떤 태그를 IAM 사용자 또는 역활에서 추가 ,변경 또는 제거할 수 있는지 지정)

• 보안 주체 : 요청을 한 사람(보안주체)이 자신의 자격증명에 연결된 태그를 기반으로 수행할 수 있는 권한을 제어

  (aws:PrincipalTag/key-name 조건 키를 사용하여 요청을 허용하려면 어떤 태그가 보안 주체에 연결되어야 하는지 지정)

• 권한 부여 프로세스의 일부 : aws:TagKeys 조건 키를 사용하여 특정 태그 키를 리소스, 요청 또는 보안 주체에서 사용할 수 있는지 여부를 제어 (이 경우 값은 중요하지 않음)

• 태그키 : aws:TagKeys 조건 키를 사용하여 리소스 또는 요청에서 특정 태그 키를 사용할 수 있는지 여부를 제어

IAM 태그를 사용한 액세스 제어

리소스에 대한 액세스 제어

- IAM 정책에 태그를 사용하여 IAM 사용자 및 역활에 대한 액세스를 제어 (IAM은 그룹에 대한 태그를 지원하지 않으므로 태그를 사용하여 그룹에 대한 액세스를 제어할 수 없음)

- Ex. status=terminated 태그가 지정된 사용자의 삭제를 허용

요청에 대한 액세스 제어

- IAM 정책에서 태그를 사용하여 IAM 사용자 또는 추가, 변경 또는 제거할 수 있는 태그를 제어

- Ex. department=HR 또는 department=CS 태그만을 사용하는 사용자 태그 지정을 허용

보안 주체에 대한 액세스 허용

- IAM 정책에 태그를 사용하여 요청자(보안 주체)가 자신의 자격 증명에 연결된 태그를 기반으로 수행할 수 있는 작업을 제어

- Ex. tagManager=true 태그가 지정된 사용자가 IAM 사용자, 그룹 또는 역활을 관리

태그 키를 사용한 액세스 제어

- IAM 정책에서 태그를 사용하여 리소스, 요청 또는 보안 주체에 특정 태그 키를 사용할 수 있는지 여부를 제어

- Ex. project 키가 있는 태그만 사용자로부터 제거

태그를 사용한 액세스 제어

리소스에 대한 액세스 제어

- IAM 정책의 조건을 사용하여 태그를 기반으로 AWS 리소스에 대한 액세스를 제어

- EC2 인스턴스의 시작 또는 중지를 허용하였지만 인스턴스 태그 Owner가 사용자의 이름 값과 같은 경우로 제한

- 인스턴스 태그 값에 사용자 이름과 계정 사용자가 동일해야 액세스 제어 허용

- 해당 정책을 IAM 사용자에게 연결할 수 있는데 이름이 test인 사용자가 EC2 인스턴스를 시작하려는 경우 Owner=test, owner=test 태그가 지정되어야함, 그렇지않으면 액세스가 거부되는데 태그키는 owner로 일치하지만 조건 키가 대/소문자를 구분하지 않기 때문 (태크기는 대소문자 구분없이 인식하지만 조건키는 대소문자를 구분함)

요청에 대한 액세스 제어

- IAM 정책의 조건을 사용하여 어떤 태그를 AWS 리소스에 추가, 변경 또는 제거할 수 있는지 제어

- 태그에 environment, preprod, production 값이 포함된 경우에만 EC2 CreateTags 작업을 사용하여 태그를 인스턴스에 연결할 수 있음

- ForAllValues 변경자를 aws:TagKeys 조건키와 함께 사용하여 요청에서 environment만 허용됨을 표시 (Environment와 같은 한자리의 대문자가 포함되면 거부됨, 조건키를 사용하여 태그 값과 완벽히 일치해야함)

태그 키 제어

- IAM 정책에서 조건을 사용하여 리소스 또는 요청에 특정 키를 사용할 수 있는지 여부를 제어

- 정책을 사용하여 태그를 사용한 액세스를 제어할 때 aws:TagKeys 조건 키를 사용해야 함

- Secrets Manger 비밀 생성 및 태그 지정이 가능하지만 태그 키 environment 또는 cost-center을 포함해야함

- environment 또는 cost-center 태그가 포함되어 있다면 CreateSecret, TagResource를 허용

예제

- 지정된 태그 (키 : project, 값 : myapp) 가 붙어 있는 인스턴스만 시작 / 중지 가능

참조 URL

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/access_iam-tags.html

IAM 란?

- Identify and Access Management의 약자로 AWS 리소스를 사용하는 유저, 그룹, 사용권한 등을 전체적으로 관리하는 서비스

메뉴 설명

- Groups : 그룹 추가, 삭제 및 그룹별 세부적인 리소스 사용권한을 부여하고 유저들을 그룹별로 묶어서 관리할 수 있음 (그룹에 소속된 유저는 자동으로 그룹이 가지고 있는 권한을 부여받음)

- Users : 유저 추가, 삭제 및 유저를 그룹에 소속시키거나 특정 유저에게만 권한 부여 가능

- Roles : 유저나 그룹에 권한을 부여하는 것이 아닌 AWS의 리소스에 권한을 부여하는 개념 

(Ex. EC2 Instance에서 Lambda 리소스 함수를 부를 경우 EC2는 Lambda를 사용할 수 없는 권한이 없기 때문에 접근이 불가능하다. 이러한 경우 EC2 리소스에 Lambda 사용권한을 부여하게 되면 Lambda 서비스에 접근 가능)

- Policies : 정책이라는 의미지만 실질적으로는 권한 부여에 좀 더 가까운 메뉴

(Ex. EC2의 Nano2 Instance만 실행할 수 있도록 함 / S3의 특정 버켓만 읽기 전용으로 접근 등등)

- Account settings : 계정의 비밀번호 정책을 설정 

용어 설명

용어

- 리소스 : IAM에 저장된 사용자, 역활, 그룹 및 정책 개체

- ID : 식별 및 그룹화에 사용되는 IAM 리소스 객체 (사용자, 그룹 및 역활이 포함)

- 개체 : AWS가 인증에 사용하는 IAM 리소스 객체 (사용자 및 역활이 포함)

- Principal : 엔티티를 사용하여 AWS에 로그인하고 요청하는 사람 또는 애플리케이션

보안 주체 

- AWS 리소스에 대한 작업을 요청할 수 있는 사람 또는 애플리케이션

요청

- 작업 또는 작동 : 보안 주체가 수행하고자 하는 작업 또는 작동

- 리소스 : 수행된 작업 또는 작동에 따른 AWS 리소스 객체

- 보안 주체 : 엔티티(사용자 또는 역활)를 사용하여 요청을 보내는 사람 또는 애플리케이션 (보안 주체에 대한 정보는 보안 주체가 로그인하는데 사용된 엔티티와 관련된 정책이 포함)

- 환경 데이터 : IP 주소, 사용자 에이전트, SSL 사용 상태 또는 시간대와 같은 정보

- 리소스 데이터 : 요청되는 리소스와 관련된 데이터 (DynamoDB 테이블 이름 또는 EC2 인스턴스 태그와 같은 정보가 포함)

- AWS에서 요청을 평가하고 승인하는데 사용되는 요청 콘텍스트로 이 요청 정보를 수집

인증

- 보안 주체가 AWS에게 요청을 보내려면 IAM 엔티티를 사용하여 인증을 받아야함

- S3 및 STS와 같은 몇몇 서비스는 익명 사용자의 몇 가지 요청을 허용하지만 이것들은 규칙 예외

승인

- AWS는 요청 콘텍스트의 값을 사용하여 요청을 허용할지 거부할지 여부를 적용되는 정책을 점검하고 정책을 사용하여 허용 / 거부 결정

- 대부분의 정책은 AWS에 JSON 문서로 저장되며 보안 주체 엔티티에 대한 권한을 지정

- AWS는 요청 콘텍스트에 적용되는 각 정책을 확인하는데 단일 권한 정책에 거부된 작업이 포함된 경우 AWS는 전체 요청을 거부하고 평가를 중지 (명시적 거부)

- 요청은 기본적으로 거부되므로 AWS는 적용 가능한 권한 정책이 요청의 모든 부분을 허용하는 경우에 요청에 대한 권한을 부여

- 단일 계정 내 요청 평가 로직

• 기본적으로 모든 요청을 거부

• 권한정책 (자격 증명 기반 또는 리소스 기반) 에 포함된 명시적 허용은 이 기본 작동을 재정의

• 조직 SCP, IAM 권한 경계 또는 세션 정책이 있는 경우 허용이 재정의함, 하나 이상의 이러한 정책 유형이 존재하는 경우 이들 정책 유형 모두가 해당 요청을 허용해야함, 그렇지 않은 경우 이 값은 묵시적으로 거부

• 어떠한 정책의 명시적 거부는 허용을 무시함

작업 또는 연산

- 요청이 인증 및 권한이 부여된 후 AWS가 요청의 작업 또는 작동을 승인

- 작업은 서비스로 정의되며 리소스 보기, 생성, 편집 및 삭제와 같이 리소스에 대해 수행할 수 있는 사항

- 보안 주체가 작업을 수행할 수 있도록 허용하려면 보안 주체 또는 영향을 받은 리소스에 적용되는 필요한 작업을 정책에 포함해야함

리소스

- AWS가 요청의 작업을 승인하면 계정 내의 관련 리소스에서 해당 작업을 수행할 수 있음

- 리소스는 서비스 내에 존재하는 객체

아키텍처

- 인증 (Authentication) : 사용자의 신원을 증명하는 것 / 클라이언트가 자신이 주장하는 사용자와 같은 사용자인지를 확인하는 과정 (로그인한 사용자는 인증된 사용자)

- 인가 (Authorization) : 권한 부여, 클라이언트가 하고자 하는 작업이 해당 클라이언트에게 허가된 작업인지를 확인 / 특정 리소스에 접근할 수 있는 권한을 부여 (접근 제어)

작동 순서

1. Principal이 인증을 요청

2. Principal은 IAM의 자격 증명을 통해 사용자 확인 (인증)

3. 인증이 완료된 사용자는 요청 콘텍스트 값을 사용하여 JSON 파일로 정의된 정책의 권한을 확인 후 허가된 권한 부여 (인가)

4. 인증과 인가를 통해 사용자가 확인되고 지정된 권한이 부여되면 AWS는 부여된 정책에 따라 사용자에게 허용된 작업을 승인

5. 작업을 승인하고 사용자가 작업할 수 있는 작업 대상 리소스를 지정

IAM Role 사용자 접근 동작

1. 사용자는 자신에게 부여된 IAM Role에게 자신이 보유한 액세스 Key의 인증을 요청

2. IAM Role은 해당 요청에 정의된 정책을 확인하고 부여된 권한에 대한 인가 후 임시 접근 Key 발급

3. 사용자는 IAM Role에게 전달 받은 임시 접근 Key를 통해 리소스에 접근

IAM Role 리소스 접근 동작

1. 관리자가 IAM을 사용하여 역활을 만들고 이 역활의 정책에는 EC2 인스턴스 만이 해당 역활을 맡을 수 있도록 지정 (정책은 S3 Bucket에 대한 읽기 전용 권한만 부여)

2. 사용자가 EC2 인스턴스를 시작하고 관리자가 생성한 역활을 할당

3. 애플리케이션이 실행되면 인스턴스 메타데이터에서 보안 자격 증명 검색에 설명된 대로 EC2 인스턴스 메타데이터에서 임시 보안 자격 증명을 가져옴 (이 자격증명은 제한된 시간 동안에만 유효한 임시 보안자격증명으로 역활을 나타냄)

4. 애플리케이션은 가져온 임시 자격 증명을 사용하여 S3 Bucket에 접근 (역활에 정의된 정책대로 읽기 전용 권한만 사용 가능)

- 애플리케이션은 현재 자격 증명이 만료되기 전에 인스턴스 메타데이터에서 새 자격 증명을 가져와야함 (인스턴스에서 제공되는 임시 보안 자격 증명은 만료되기 전에 자동으로 교체되므로 항상 유효한 설정을 사용할 수 있음)

참조 URL

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/intro-structure.html

https://www.slideshare.net/awskorea/20150109-aws-black-belt-iam-younjin

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html

정책 요약

1. 권한 (노란색으로 표시되는 부분은 오류 배너)

- 정책 요약 or {} JSON 

• 정책 요약과 JSON 파일 전환을 표시

- 서비스 (A)

• 정의된 서비스(리소스)가 나열되고 각 서비스의 세부정보를 표시

• 서비스에 노란색 느낌표 표시가 나오는 것은 정책에서 인식할 수 없는 서비스가 포함된 경우이다. (미분류 서비스라고 표현)

• 서비스 이름에 오타가 있는 경우 / 정책 요약이 지원되지 않는 정책 / 사용자 지정 서비스일 경우 (위의 예제는 오타)

- 액세스 레벨 (G)

• 각 정책이 액세스 레벨 (목록 / 읽기 / 쓰기)의 작업에 대해 전체 또는 제한 중 어느 권한을 정의했는지 표시

• 전체 : 서비스가 사용 가능한 4개 액세스 레벨(목록 / 읽기 / 쓰기 / 권한 관리)에 모두 권한이 있는것을 의미

• 전체 - 읽기 : 서비스가 액세스 레벨 중 읽기에 관한 모든 권한만 있는 것을 의미

• 제한 - 정책이 나열된 각 액세스 레벨 중 하나 이상의 작업에 대한 액세스 권한만 제공

• 제한 - 읽기 : 서비스가 액세스 레벨 중 읽기 권한에 대해서 부분적인 권한만 가지고 있는 것을 의미 

- 리소스 (H)

• 각 서비스에 대해 지정한 리소스를 표시

• 모든 리소스 : 서비스가 보유한 액세스 레벨의 정책을 모든 리소스에 허용된 것을 의미

• 다중(Multiple) / 여러 개를 실행할 수 있습니다 : 서비스가 보유한 액세스 레벨의 정책이 둘 이상의 리소스에 허용된 것을 의미

• 리소스 텍스트 : 서비스가 보유한 액세스 레벨의 정책이 리소스 전체에 대한 것이 아닌 리소스 안에서 특정 부분에 대한 것만 허용된 것을 의미 (BucketName = developer_bucket, ObjectPath=ALL)

- 요청 조건 (I)

• 서비스가 보유한 액세스 레벨의 정책에서 리소스에 대한 특정한 조건을 의미 (해당 조건이 일치해야 정책이 허용)

• 없음 : 정책이 서비스에 대한 조건을 포함하지 않음

• 다중 : 정책이 서비스에 대한 둘 이상의 조건을 포함 (복수의 조건에 따라 허용, 정책을 보려면 JSON파일을 확인해야함)

• Condition text : 정책이 서비스에 대한 조건 하나를 포함 (위의 예제에서는 amz-acl = public-read 로 표시하였는데 acl 조건에 따라 허용된 203.0.113.0/24와 IP가 일치하는 경우에만 정책이 허용)

- 허용 / 명시적 거부

• 명시적 거부 : 서비스가 리소스에 접근하는 것을 거부함 (정의된 정책의 액세스 레벨을 거부)

• 허용 : 서비스가 정의된 액세스 레벨로 리소스에 접근하는 것을 허용

• 위의 경우는 모든 리소스에 S3가 정의된 액세스 레벨로 접근하는 것을 허용하였으나 특정 리소스에 대해서는 접근할 수 없도록 구성한 것

2. 정책 사용

- 해당 Role이 포함된 그룹이나 사용자 표시

- 새로운 사용자나 그룹을 해당 정책에 연갈할 수 있음

3. 정책 버전

- 정의된 정책을 버전별로 저장하여 관리 및 롤백할 수도 있음

4. 액세스 관리자

- 사용자에게 부여된 서비스 권한과 해당 서비스에 마지막으로 액세스한 시간을 표시하여 관리자가 관리

서비스 요약

1. 서비스 (노란색으로 표시되는 부분은 오류 배너)

- 작업 (5)

• 정책내에 정의된 작업이 나열되고 각 작업에 해당하는 리소스와 조건이 표시 

- 인식되지않은 리소스 유형 (7)

• 정책 또는 서비스에 대한 정책내에서 인식되지 않은 리소스 유형이 존재 (오타 / 사용자 지정 서비스 / 정책 요약 지원 안함 등) 

- 인식되지않은 작업 (8)

• 정책 또는 서비스에 대한 정책내에서 인식되지 않은 작업이 존재  (오타 / 사용자 지정 서비스 / 정책 요약 지원 안함 등) 

- 목록 (9)

• 정책이 허용 / 거부하는 액세스 레벨에 따라 1-4개의 섹션으로 작업을 그룹화

• 섹션에는 목록 / 읽기 / 쓰기 / 권한 관리가 있음 

- 액세스 권한 없음 (10)

• 이 정책에 권한을 제공하지 않는 작업이 존재

- 리소스 (13)

• 서비스에 대해 정의된 리소스를 표시

• 위의 예제에서는 S3 서비스의 작업이 S3의 developer_bucket 리소스만 허용되는 것으로 구성

• 리소스 정책에 오류가 있는지 검사하려면 정책 시뮬레이터를 사용해야함

- 리소스 경고 (14)

• 전체 권한을 제공하지 않는 리소스를 포함하는 경우 경고메시지 표시

• This action does not support resource-level permissions. 리소스에 대하여 와일드카드(*)가 필요합니다 : 정책에 리소스 수준의 권한은 있지만 작업 수준에 대한 권한을 제공하려면 “Resource” : [ “*” ] 를 포함해야 함을 의미

• 이 작업은 적용할 리소스가 없습니다 : 지원되는 리소스 없이 작업이 정책에 포함됨을 의미

• 이 작업은 적용할 리소스 및 조건이 없습니다 : 지원되는 리소스 및 조건 없이 작업이 정책에 포함됨을 의미 (이 경우 서비스 정책에 포함된 조건도 있지만 작업에 적용되는 조건이 없음)

- 요청 조건 (15)

• 리소스와 연결된 작업에 조건이 적용되는지 여부를 표시 (JSON 파일을 통해 검토 가능)

- 조건 경고 (16)

• 전체 권한을 제공하지 않는 조건을 포함하는 경우 경고메시지 표시

• <CONDITION_KEY>는 이 작업에 대해 지원되는 조건 키가 아닙니다 : 정책의 작업에 지원되지 않는 서비스 조건 키가 있음

• 해당 작업은 여러 개의 조건 키를 지원하지 않습니다 : 정책의 작업에 지원되지 않는 서비스 조건 키가 두개 이상 있음

• 위의 예제에서 GetObject의 경우 정책에 s3:x-amz-acl 조건 키가 포함되어 있지만 키는 해당 작업에서 작동하지 않음, 작업이 리소스를 지원하더라도 조건이 이 작업에 대해 true가 되지 않기 때문에 정책에서 작업을 위한 권한을 부여하지 않음

작업 요약

- 리소스 (4)

• 정책이 선택한 서비스에 대해 정의한 리소스가 표시

• 위의 예제에서는 PutObject 작업이 모든 객체 경로와 developer_bucket 에서만 허용되는 것으로 구성

• IAM가 제공하는 정보에 따라 arn:aws:s3:::developer_bucket/* 등의 ARN이 표시되거나 BucketName=developer_bucket, ObjectPath=All 등의 정의된 리소스 유형이 표시

- 리전 (5)

• 리소스가 정의된 리전을 표시

• 모든 리전 : 리소스와 연결된 작업은 모든 리전에 적용

• 리전 텍스트 : 리소스와 연결된 작업은 한 리전에 적용 (리전 지정 가능)

- 계정 (6)

• 리소스와 연결된 서비스 또는 작업이 특정 계정에 적용되는지를 나타냄

• 모든 계정 : 리소스와 연결된 작업은 모든 계정에 적용

• 현재 계정 : 리소스와 연결된 작업은 현재 로그인된 계정에만 적용

• 계정 번호 : 리소스와 연결된 작업은 지정된 계정번호의 계정에만 적용

- 요청 조건 (7)

• 리소스와 연결된 작업에 조건이 적용되는지를 표시

• 위의 예제에서는 s3:x-amz-acl=public-read 조건이 포함되었는데 acl 조건에 따라 허용된 203.0.113.0/24와 IP가 일치하는 경우에만 정책이 허용되는 것

ElasticSearch

- Elasticsearch 클러스터를 쉽게 배포, 운영 및 조정할 수 있는 관리형 서비스

- 로그 분석, 실시간 애플리케이션 모니터링, 클릭 스트림 분석 같은 사용 사례를 위한 오픈소스 검색 및 분석 엔진

- AWS ES (Elasticsearch Service)를 사용하면 Elasticsearch API에 바로 액세스해 기존 코드 및 애플리케이션을 서비스를 통해 원활하게 사용할 수 있음

- JSON 포맷으로 RESTfull 방식의 분산 검색 엔진

- Apache Lucene을 바탕으로 하고 있으며 대량의 데이터보단 크지 않은 데이터를 보관하는 역방향 인덱싱 DB 시스템이라 생각할 수도 있음

특징

- Scale

• 다양한 CPU, 메모리 및 스토리지 용량 구성 (인스턴스 유형이라 함)

• 최대 3PB의 인스턴스 스토리지

• AWS EBS 스토리지 볼륨

- 보안

• AWS IAM 액세스 제어

• VPC 및 VPC 보안 그룹을 사용하는 쉬운 통합

• 저장 중 데이터 암호화 및 노드 간 암호화

• Kibana에 대한 AWS Conito 인증

- 안정성

• 리소스를 위한 여러 지리적 위치 (리전 및 가용 영역이라 함)

• 동일한 리전의 가용 영역 두 개 또는 세 개에 노드 할당 (Multi AZ)

• 클러스터 관리 작업 부담을 줄여주는 전용 마스터 노드

• 자동 스냅샷으로 AWS ES 도메인 백업 및 복원

- 유명 서비스와 통함

• Kibana를 사용하는 데이터 시각화

• AWS ES 도메인 지표 및 설정 경보 모니터링을 위한 CloudWatch와의 통합

• AWS ES 도메인에 대한 구성 API 호출 감사를 위한 CloudTrail과의 통합

• AWS ES로 스트리밍 데이터 로드를 위한 S3, Kinesis 및 DynamoDB와 통합

장점

- 아파치 루씬 기반으로 루씬의 기능을 대부분 지원 (자바로 개발)

- 분산시스템 (여러개의 노드 [검색하는 단위 프로세스] 로 구성)

- 확장 시 기존 노드에 새 노드를 실행하여 연결

- 각 노드에 데이터 분산 저장 (복사본 유지하여 충돌로부터 보호)

- 높은 가용성 (실패할 경우 다른 노드로 이동)

- JSON으로 저장 (REST API 지원)

- HTTP Method 지원 (9200 포트부터)

- Kibana와 연동되어 시각화 가능

- ElasticSearch 생성시 IAM 권한이 필요하고 Kibana 접근시 액세스 정책을 IP 기반으로 열어줘야함

아키텍처

1. 데이터 스트림 (데이터의 지속적인 흐름, 전달)이 AWS ES로 보내지면 지정된 인덱스 패턴에 의해 인덱스가 생성 (예를 들어 Stream1_날짜로 하면 위의 그림처럼 일별로 인덱스가 생성)

2. 각 AZ에 ES 데이터 인스턴스와 각 기본 데이터에 대한 복제본 하나가 배포 (샤드는 기본 및 복제본이 서로 다른 인스턴스에 배포되어 있음)

3. Elasticsearch에서 위의 과정으로 업데이트 처리를 하며 해당 업데이트가 새 문서 또는 업데이트된 문서를 수신하는 모든 기본 및 복제본으로 전송

• 업데이트를 처리하는데 몇가지 중요한 특성이 존재

• 첫째로는 각 인덱스 패턴은 기본*, 복제본 수*, 전체 샤드 보존 기간을 배포

• 둘째로는 이 인덱스 패턴에 인덱스가 3개 있더라도 타임 슬라이싱은 새 문서가 이러한 인덱스 중 하나(해당 인덱스 패턴에 대한 활성 인덱스)에만 적용됨을 의미

• 셋째로는 벌크 데이터를 전송하고 임의로 배포된다고 가정하면 해당 인덱스의 모든 샤드는 업데이트를 수신하고 기록

내부 용어

- Document : 검색 단위 문서

- ID : 각 문서에 대한 인식자

- Shard : 인덱스의 부분을 가지는 Lucene 인스턴스

- Index : 검색 데이터 집합

참조 URL

https://mykumi.tistory.com/entry/AWS-ElasticSearchKibanaFluentd-1-AWS-ElasticSearch-%EC%83%9D%EC%84%B1

https://cloud.hosting.kr/techblog_180718_t-shirt-size-your-domain/

CloudWatch

- AWS의 각종 자원들을 모니터링

- Resource의 측정치와 연결하여 Action을 서비스에 취할 수 있음

- 지표에 기반한 알람 서비스 및 그래프를 통한 가시화

아키텍처

- 리소스 사용 및 유저 데이터에 대한 모니터링 값을 메트릭스로 표현하는데 각 네임스페이스 별로 격리하여 표현

- CloudWatch Alarm을 통해 지정한 Resource 임계값이 초과되거나 미만이 되면 알람을 보내고 지정된 작업을 실행 (Auto Scaling을 통한 EC2 인스턴스 scale in/out)

- 통계자료를 그래프를 통한 가시화하여 AWS 콘솔을 통해 출력하거나 사용자 지정 통계로 출력

CloudWatch 용어

네임스페이스 (NameSpace)

- CloudWatch 지표용 컨테이너

- 다른 네임스페이스의 지표는 서로 격리되어 있으므로 다른 애플리케이션의 지표가 실수로 동일하게 집계되는 일은 없음

- 기본 네임스페이스는 없고 CloudWatch에 게시하는 각 데이터 요소의 네임스페이스를 지정해야함 (사용자 지표를 생성할때 네임스페이스 이름을 지정할 수 있음)

- 네임스페이스는 AWS/services 라는 명명 규칙을 사용

지표 (Metrics)

- 지표는 CloudWatch의 기본 개념으로 CloudWatch에 게시된 시간 순서별 데이터 요소 세트를 나타냄

- 지표를 모니터링할 변수로 생각하면 데이터 요소는 시간에 따른 변수의 값을 나타냄 (Ex. EC2 인스턴스의 CPU 사용량은 EC2가 제공하는 하나의 지표)

- 각 지표 데이터 요소에는 타임스탬프가 표시되는데 타임스탬프는 최대 2주전이고 최대 2시간 빠를 수 있음 (타임스탬프를 제공하지 않으면 CloudWatch는 데이터 요소를 받은 시간을 기준으로 타임스탬프를 생성)

- 각 지표는 최대 15개월동안 보관되는데 기간이 설정된 데이터 요소마다 보관기간이 다름

차원

- 지표를 고유하게 식별하는 이름/값 페어로 최대 지표에 차원을 10개까지 할당 가능

- 모든 지표에는 자신을 설명하는 고유한 특징이 있고 차원은 이렇나 특징에 대한 범주로 생각할 수 있음

- 차원을 사용하면 통계 계획을 위한 구조를 설계할 수 있음 (차원은 지표에 대한 고유한 식별자의 일부이므로 지표 중 하나에 이름/값 쌍을 추가할 때마다 해당 지표의 새로운 변형이 생성된 것)

- CloudWatch로 데이터를 전송하는 AWS 서비스는 각 지표에 차원을 연결하고 차원을 사용하여 CloudWatch가 반환하는 결과를 필터링할 수 있음 (지표를 검색할 때 InstanceId 차원을 지정하여 인스턴스에 대한 통계을 얻음)

통계

- 지정한 기간에 걸친 지표 데이터 집계

- CloudWatch에서는 사용자 지정 데이터를 통해 제공되었거나 다른 AWS 서비스에서 CloudWatch에 제공한 지표 데이터 요소를 기반으로 통계를 제공

백분위수 

- 데이터 세트에서 값의 상대적 위치를 나타냄 (Ex. 95백분위는 데이터의 95%가 이 값보다 아래에 있고 5%가 이 값보다 위에 있다는 것을 의미)

경보

- 경보를 사용하여 작업을 자동으로 시작할 수 있음

- 경보는 지정한 기간에 단일 지표를 감시하고 시간에 따른 임계값에 대한 지표 값을 기준으로 지정된 작업을 하나 이상 수행함

CloudWatch Event

개념

- 이벤트

• 이벤트는 AWS 환경이 변경되었음을 나타냄

• AWS 리소스는 상태 변경시 이벤트를 생성할 수 있음

• CloudTrail은 API가 호출될 때 이벤트를 게시

- 대상

• 대상은 이벤트를 처리 (JSON 형식으로 이벤트를 수신)

• EC2 인스턴스, Lambda 함수, Kinesis 스트림, ECS 작업, Step Functions 상태 시스템, SNS 주제, SQS대기열, 기본 제공 대상 등이 여기에 해당

- 규칙

• 규칙은 들어오는 이벤트에서 일치하는 것을 찾아서 대상으로 라우팅하여 처리

• 단일 규칙으로 여러개의 대상으로 라우팅할 수 있으며 이들은 모두 병렬 처리

• 규칙이 처리되는 특별한 순서는 없음

참조 URL

https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html

https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html

https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html

CloudWatch Logs

- 소스에서 로그 파일을 모니터링, 저장 및 액세스할 수 있음

- 기능

• EC2 인스턴스 로그 모니터링

• • CloudWatch Logs를 사용하면 로그 데이터를 통해 애플리케이션과 시스템을 모니터링할 수 있음

    (예를 들어 CloudWatch Logs에서는 애플리케이션 로그에서 발생하는 오류의 수를 추적하고 오류 비율이 지정한 임계값을 초과할 때마다 알림을 전송)

  • CloudWatch Logs는 모니터링하는데 로그 데이터를 사용하므로 코드를 변경할 필요가 없음

    (특정 리터럴문자<NullReferenceException>에 대한 애플리케이션 로그를 모니터링 하거나 로그 데이터의 특정 위치<Apache 액세스 로그의 404 상태 코드>에서 리터럴 문자의 출현 횟수를 계산)

  • 검색할 단어가 발견되면 CloudWatch Logs는 지정한 CloudWatch 지표로 데이터를 보고 (로드 데이터는 전송시는 물론 저장시에도 암호화)

• AWS CloudTrail 기록 이벤트 모니터링

• • CloudWatch에서 경보를 생성하고 CloudTrail에서 포착된 특정 API 활동에 대한 알림을 수신하며 이러한 알림을 사용하여 문제 해결을 할 수 있음

• 로그 보존

• • 기본적으로 로그는 무기한 저장되고 만료기관은 없음

• 로그 데이터 보존

• • CloudWatch Logs를 사용하여 내구성이 뛰어난 스토리지에 로그데이터를 저장할 수 있음

  • CloudWatch Logs 에이전트를 사용하면 호스트에서 로그 서비스로 로테이션된 로그 데이터와 로테이션 되지 않은 로그 데이터를 모두 쉽고 빠르게 전송할 수 있음

• Route 53 DNS 쿼리 로깅

• • CloudWatch Logs를 사용하여 Route53이 수신하는 DNS 쿼리에 대한 정보를 기록할 수 있음

Logs 개념

- 로그 이벤트

• 로그 이벤트는 모니터링 중인 애플리케이션 또는 리소스에 기록된 일부 활동에 대한 레코드

• CloudWatch Logs가 파악한 로그 이벤트 레코드에는 이벤트가 발생한 시점에 대한 타임스탬프와 원시 이벤트 메시지 등 두개의 속성이 포함

• 각 메시지는 UTF-8로 인코딩되어야 함

- 로그 스트림

• 로그 스트림은 동일한 소스를 공유하는 로그 이벤트 시퀀스

• 로그 스트림은 모니터링 중인 애플리케이션 인스턴스나 리소스에서 나온 이벤트의 시퀀스를 표시하는데 주로 사용

• 로그 스트림은 특정 호스트의 Apache 액세스 로그에 연결될 수 있음

- 로그 그룹

• 로그 그룹은 동일한 보존 기간, 모니터링 및 액세스 제어 설정을 공유하는 로그 스트림 그룹을 정의

• 각 로그 스트림은 하나의 로그 그룹에 속해야함 (Ex. 각 호스트의 Apache 액세스 로그에 대해 별도의 로그 스트림이 있으면 로그 스트림을 MyWebSite.com/Apache/access_log라는 하나의 그룹으로 묶을 수 있음)

• 하나의 로그 그룹에서 포함할 수 있는 로그 스트림의 수에는 제한이 없음

- 지표 필터

• 지표 필터를 사용하여 수집된 이벤트에서 지표 관찰값을 추출하고 이를 CloudWatch 지표의 데이터 요소로 변환할 수 있음

• 지표 필터는 로그 그룹에 할당이 되고 로그 그룹에 할당된 모든 필터들은 로그 스트림에 적용

- 보전 기간 설정

• CloudWatch Logs에 로그 이벤트를 보관하는 기간을 설정하는데 사용할 수 있음

• 기간이 만료된 로그 이벤트는 자동으로 삭제

• 지표 필터와 마찬가지로 보존 기간 설정 역시 로그 그룹에 할당되며 로그 그룹에 할당된 보존 기간은 로그 스트림에 적용

CloudWatch Logs .conf File (에이전트 구성 파일)

[general]

state_file = value

logging_config_file = value

use_gzip_http_content_encoding = [true | false]

[logstream1]

log_group_name = value

log_stream_name = value

datetime_format = value

time_zone = [LOCAL|UTC]

file = value

file_fingerprint_lines = integer | integer-integer

multi_line_start_pattern = regex | {datetime_format}

initial_position = [start_of_file | end_of_file]

encoding = [ascii|utf_8|..]

buffer_duration = integer

batch_count = integer

batch_size = integer

[general]

- state_file (상태 파일)

• 상태 파일이 저장되는 장소를 지정

- logging_config_file (기본 구성 파일 위치)

• 스크립트를 통해 에이전트를 설치한 경우 기본 파일 위치 : /var/awslogs/etc/awslogs.conf

• rpm을 통해 에이전트를 설치한 경우 : /etc/awslogs/awslogs.conf

- use_gzip_http_content_encoding 

• true(기본)로 설정되어 있으면 gzip http 콘텐츠 인코딩을 활성화하여 CloudWatch Logs로 압축된 페이로드를 전송

• CPU 사용량을 줄이고 NetworkOut을 낮추며 PUT 레코드 지연시간을 줄일 수 있음

[logstream1] 

- log_group_name

• 대상 로그 그룹을 지정

• 로그 그룹이 없는 경우 이 설정에 따라 로그 그룹이 자동으로 생성

- log_stream_name

• 대상 로그 스트림을 지정

• 리터럴 문자열이나 미리 정의된 변수({instance_id}, {hostname}, {ip_address}) 또는 이 둘의 조합을 사용하여 로그 스트림 이름을 정의

• 로그 스트림이 없는 경우 이 설정에 다라 로그 스트림이 자동으로 생성

- datetime_format

• 타임 스탬프가 로그에서 추출되는 방법을 지정

• 타임 스탬프는 로그 이벤트를 검색하고 지표를 생성하는데 사용

• datetime_format이 제공되지 않는 경우에는 각 로그 이벤트에서 현재 시간이 사용

   

- time_zone

• 로그 이벤트 타임 스탬프의 시간대를 지정

- file

• CloudWatch Logs에 푸시하고 싶은 로그 파일을 지정

• 파일은 특정 파일을 가리키거나 여러 개의 파일을 가리킬 수 있음 (/var/log/system.log* 와 같은 와일드카드 사용)

• 파일 수정 시간에 따라 최신 파일만 CloudWatch Logs로 푸시

• 여러 종류의 파일을 지정하려면 로그 파일의 종류에 따라 다른 로그 스트림에 들어가도록 구성파일에 또 다른 로그스트림 항목을 추가

- file_fingerprint_lines

• 파일을 식별하기 위한 줄의 범위를 지정

• 유효한 값은 하나의 숫자 (Ex. 1)나 대시로 구분된 두 개의 숫자 (Ex. 2-5)

• 기본 값은 1이기 때문에 지문 산출을 위해 첫번째 줄이 사용

• 지정된 모든 줄이 사용 가능한 상태가 되지않는 한 지문줄은 CloudWatch Logs로 전송되지 않음

- multi_line_start_pattern

• 로그 메시지의 시작을 식별하기 위해 패턴을 지정

• 로그 메시지는 패턴과 일치하는 하나의 줄과 패턴과 일치하지 않는 나머지 줄들로 이루어짐

• 유효한 값은 {datetime_format}

• {datetime_format}을 사용할때는 반드시 datetime_format 옵션이 지정되어 있어야함

• 기본 값은 '^[^\s]' 이기 때문에 공백이 아닌 문자로 시작되는 줄이 있으면 이전의 로그 메시지가 종료되고 새로운 로그 메시지가 시작

- initial_position

• 데이터 읽기를 시작할 지점(start_of_file 또는 end_of_file)을 지정

• 기본 값은 파일의 시작 지점 (start_of_file 또는 end_of_file)

• 해당 로그 스트림에서 지속되는 상태가 없을때만 사용

- encoding

• 파일을 정확하게 읽을 수 있도록 로그 파일의 인코딩을 설정

• 기본 값은 utf_8

- buffer_duration

• 로그 이벤트를 일괄 처리하는 기간을 지정

• 최소값은 5000ms이고 기본값은 5000ms

- batch_count

• 일괄 처리할 로그 이벤트의 최대 수를 지정

• 10000까지 가능하고 기본값은 10000

- batch_size

• 일괄 처리할 로그 이벤트의 최대 크기를 바이트로 지정 

• 1048576 바이트까지 가능하고 기본값은 1048576 바이트

참조 URL

https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/logs/AgentReference.html

https://medium.com/@eunsu.shin/aws-cloudwatch-%EC%95%8C%EB%9E%8C-%EC%84%A4%EC%A0%95-aafc19ed5749 - 로그 필터 패턴