CStory

Sliding window rate limiter 구현 레디스의 sorted set 자료구조를 이용해서 sliding window rate limiter를 구현할 수 있다. 우선 Rate Llimiter란, 단위 시간당 요청 및 처리량에 제한을 두기 위한 소프트웨어적 기법이다. 악성 사용이나 비정상적인 동작에 의한 시스템 및 로직의 문제 등을 사전에 방지하고자 할 때 가장 기초적인 방법이다. 대표적인 사례들로는 결제시스템이나 로그인의 단위 시간당 시도 횟수 제한 등이 있다. Sliding Window는 window 즉 창문과 같은 직사각형이 슬라이딩하듯 움직이는 거라고 생각하면 된다. 정확히는 현재 처리하고자 하는 양을 window로 제한하ㅏ고 이를 시간의 구간을 연속적으로 이동하는 것이다. 대표적인 사..

이번에는 CacheDB인 Redis를 이용해서 데이터를 빠르게 조회하는 방법에 대해 알아볼 예정이다. Cache란? 우선 Cache는 데이터가 미래에 사용될 것이라고 예상하여 미리 빠르게 조회할 수 있도록 따로 저장해두는 것을 말한다. 여기서 Cache hit 은 조회하는 데이터를 캐시에서 발견했을 때 Cache miss 는 발견하지 못했을 때 Hit rate(ratio)는 access시도 횟수 대비 hit를 성공한 비율이다. Cache의 사용 사례 캐시는 CPU 칩 내부에서 디스크의 접속 시간을 줄이고자 내부의 캐시메모리로 메모리 IO에 의한 속도를 줄일 때 사용된다. 데이터베이스에서 인덱싱 데이터는 메모리에 올려두고 관리하기 때문에 인덱싱 기준으로 조회하면 조회 속도가 빠르다. 웹 브라우저에서도 최근..

Fluentd에서 필터링 후 전송하기!! 다시 서버1로 돌아와 Fluentd 필터링과 전송을 위한 세팅을 진행한다. 우선 Opensearch서버로 로그를 보내기 위해서 plugin 설치가 필요하다. sudo fluent-gem install fluent-plugin-opensearch 그리고 다시 fluent.conf 파일을 vi로 연다. 인풋에 대한 태그인 source 밑에 output 설정으로 위한 태그인 match를 아래처럼 추가한다. Opensearch의 index lifecycle을 시간으로 가져가기 때문에 log에 담긴 시간 값에 맞는 index로 전송할 수 있다. @type opensearch hosts $opensearch_server_ip:9200 logstash_format true l..

우선 Fluentd를 진행 중이선 서버1은 놔두고 서버2로 들어간다. Fluentd에서 OpenSearch로 로그를 보내려면 서버 2에 OpenSearch가 설치되어있어야 하기 때문에 서버2에 OpenSearch 설치와 함께 Dashboard까지 설치하려고 한다. 우선 두 번째 EC2 서버에 접속한다. 설치전 아래 사항을 확인해둔다. sudo apt update sudo apt install build-essential -y 아래에서 환경에 맞는 OpenSearch 파일을 다운받는다. https://opensearch.org/downloads.html Opensearch 2.11.1 opensearch.org wget으로 tar.gx파일을 다운받고 tar -xvf 로 해제하였다. opsearch-2.4...

이번에는 실제로 EFK를 구축해보려고 한다. 아래는 계획한 기본적인 아키텍처이다. * 미리 ec2 서버 2대를 생성하였다. 1. Fluentd 설치하고 로그 확인 가장 먼저 App에서 만든 로그파일을 Fluentd가 파싱하고 이를 다른 서버에 있는 Opensearch에게 전송하는 것이다. *** 서버 1에서 진행 Fluentd 설치 이를 위해 Fluentd를 설치해야하는데 https://docs.fluentd.org/installation/before-install Before Installation - Fluentd Fluentd sometimes uses predictable paths for dumping, writing files, and so on. This default settings for..

EFK(ELK) 구축 해보기!! (서버 로그 수집) - 2. EFK 소개와 아키텍처 EFK란 우선 EFK는 ElasticSearch, Fluentd, Kibana 의 앞자 글자만을 딴 것이다. 더 잘 알려진 ELK는 Elastic stack으로 구성되었으며, 여기서 L은 Logstash이다. Elastic stack의 유료화로 인해 ElasticSearch -> OpenSearch Fluentd Kibana -> OpenDashboard 를 사용한다. Fluentd Log를 수집, 파싱, 전송을 담당한다. App의 파일을 읽기 위해 App과 같은 호스트에 뜬다. Fluentd는 적은 리소스로 로그를 파싱&전송 규칙을 태그 방식으로 정한다. OpenSearch(ElasticSearch) Log를 저장하는 ..

로그 우선 로그란, 컴퓨터가 운행 도중에 남기는 유의미한 기록을 말한다. 로그에는 1) Timestamp 2) 로그 레벨 3) 로그 내용 4) 발생 위치 등이 일반적으로 들어간다. 로그는 파일을 남기지만 수집이 따로 필요한 이유는 1. 시스템에 장애가 나면 로그파일에 다시 접근할 수 없을 수 있다. 2. 관리해야하는 프로그램이나 인스턴스 수가 많아지면 개별적으로 확인하기 어렵다. 3. 필터링이나 검색 등을 이용해서 로그를 더욱 활용하여 시스템 신뢰도를 높일 수 있다. 로그 수집 아키텍처 환경에 따라서 다양하게 로그를 수집할 수 있다. 1. 파일을 이용한 수집 App이 만든 Log File을 별도의 Log Collector가 수집하고 전송한다. 장점으로는 1. 디자인 패턴에서 중요한 '관심사의 분리'가 이..

JDBC JDBC : Java Database Connectivity 만약 표준 인터페이스가 없다면 어떨까? 아마 각 데이터베이스마다 어떤 함수를 써야하는 지 찾아보며 수정해야할 것이다. 그래서사용자가 자바에서 제공하는 표준인터페이스에서 정의된 클래스와 함수를 데이터베이스의 종류와 상관없이 사용하고 사용하고자 하는 DB에 따라 라이브러리만 바꾸면 JDBC에서 해당 DB에 따른 함수를 요청해준다. JDBC는 기본적으로를 상정하고 만들었으며 NoSQL이나 빅데이터 계열은 JDBC를 따르지 않고 독자적인 메소드를 만드는 편이다. ODBC ODBC : Open Database Connectivity JDBC가 인기를 얻자 이제는 Java말고 프로그래밍 언어나 운영체제와 상관없이 독립적으로 DBMS를 사용하고자 ..

RDBMS란 Relational Database : Relational Model을 기반으로한 Database이다. RDBMS는 Relational Database Management System을 말한다. 특징 테이블 형태로 표현되며 row와 column을 가진다. 테이블 안에는 각 레코드(row)를 구분할 수 있는 PK(Primary key)를 가진다. 이 PK로 다른 테이블과 연결될 수 있으며, 이를 FK(Foreign key)라고 한다. 하나의 작업단위를 Transaction(트랜잭션)이라고 한다. Transaction 데이터의 CRUD(create, read, update, delete)를 문제없이 처리하기 위해 ACID 특성을 지원한다. Atomicity(원자성) - 모두 처리되거나 아니거나 ..

RE 데이터셋을 구축하기 위해 RE 관련 논문 2개를 데이터셋 구축 위주로 보았다. TAC Relation Extraction Dataset Position-aware Attention Supervised Data Improve Slot filling 논문 안에 있는 내용이다. Slot filling 과제는 Subject 엔티티와 Object 엔티티의 relation tag를 채우는 것을 말한다. 이 논문의 경우는 새로운 데이터셋인 TACRED를 생성하였다. 이전에 TAC KBP로 Knowledge base를 확장하기 위한 데이터셋이나 SemEval-2010등이 있었는데 양이 적거나 task에 적합하지 않아서 새로 만들었다고 한다. TAC KBP 챌린지를 통해서 데이터를 가져왔으며 2009-2015년까지..