230317 TIL

1.  Redis란

• Key, Value 구조의 비정형 데이터를 관리하고 저장하기 위한 오픈 소스 기반의 비관계형 데이터 베이스 관리 시스템이다. (DBMS)
• 데이터베이스, 캐시, 메세지 브로커로 사용되며 인메모리 데이터 구조를 가진 저장소이다.
• key, value 저장소 중 가장 순위가 높다.

 1)인메모리 데이터 구조 저장소를 사용하는 이유

• 사용자가 많지 않을 때는 WEB-WAS-DB 의 구조로도 DB에 무리가 가지 않지만 사용자가 많아지면 무리가 간다.
• 캐시는 한번에 읽어온 데이터를 임의의 공간에 저장하여 다음에 읽을 때 빠르게 결과값을 받도록 도와준다.\
• 같은 요청이 여러번 들어온 경우 캐시서버에서 바로 결과값을 주어 속도를 높이고 DB부하를 줄인다.

 2)캐시서버의 두가지 패턴

• Look aside cache
  1. 클라이언트가 데이터를 요청
  2. 서버는 데이터가 존재하는지 Cache 서버에 먼저 확인
  3. Cache 서버에 데이터가 있으면 DB에 데이터를 조회하지 않고 Cache 서버에 있는 결과값을 클라이언트에게 바로 반환 (Cache Hit)
  4. Cache 서버에 데이터가 없으면 DB에 데이터를 조회하여 Cache 서버에 저장하고 결과값을 클라이언트에게 반환 (Cache Miss)
• Write back
  1. 웹서버는 모든 데이터를 Cache 서버에 저장
  2. Cache 서버에 특정 시간 동안 데이터가 저장됨
  3. Cache 서버에 있는 데이터를 DB에 저장
  4. DB에 저장된 Cache 서버의 데이터를 삭제

 3)Redis의 특징

• Key, Value 구조이기 때문에 쿼리를 사용할 필요가 없습니다.
• 데이터를 디스크에 쓰는 구조가 아니라 메모리에서 데이터를 처리하기 때문에 속도가 빠릅니다.
• String, Lists, Sets, Sorted Sets, Hashes 자료 구조를 지원합니다.
  • String : 가장 일반적인 key - value 구조의 형태입니다.
  • Sets : String의 집합입니다. 여러 개의 값을 하나의 value에 넣을 수 있습니다. 포스트의 태깅 같은 곳에 사용될 수 있습니다.
  • Sorted Sets : 중복된 데이터를 담지 않는 Set 구조에 정렬 Sort를 적용한 구조로 랭킹 보드 서버 같은 구현에 사용할 수 있습니다.
  • Lists : Array 형식의 데이터 구조입니다. List를 사용하면 처음과 끝에 데이터를 넣고 빼는 건 빠르지만 중간에 데이터를 삽입하거나 삭제하는 것은 어렵습니다.
• Single Threaded 입니다.
  : 한 번에 하나의 명령만 처리할 수 있습니다. 그렇기 때문에 중간에 처리 시간이 긴 명령어가 들어오면 그 뒤에 명령어들은 모두 앞에 있는 명령어가 처리될 때까지 대기가 필요합니다.
  (하지만 get, set 명령어의 경우 초당 10만 개 이상 처리할 수 있을 만큼 빠릅니다.)

  4)Redis 사용 시 주의 사항

• 서버에 장애가 발생했을 경우 그에 대한 운영 플랜이 꼭 필요합니다.
  : 인메모리 데이터 저장소의 특성상, 서버에 장애가 발생했을 경우 데이터 유실이 발생할 수 있기 때문입니다.
• 메모리 관리가 중요합니다.
• 싱글 스레드의 특성상, 한 번에 하나의 명령만 처리할 수 있습니다. 처리하는데 시간이 오래 걸리는 요청, 명령은 피해야 합니다.

2.  ElasticSearch

• 일반적인 검색 엔진은 웹에서 정보를 수집하여 검색 결과를 제공한다. DB의 비정형 데이터를 색인하고 검색하는 것은 불가능 하다.
• 엘라스틱 서치는 비정형 데이터를 색인하고 검색하는 것이 가능하다.
• 또한 장점중의 하나인 역색인 구조를 사용함으로써 빠른 검색이 가능하다.
  • 역색인 : 키워드를 통해 문서를 찾는 방식

 1)관계형 데이터베이스와 비교

엘라스틱 서치	관계형 데이터베이스
인덱스	데이터베이스
샤드	파티션
타입	테이블
문서	행
필드	열
매핑	스키마
Query DSL	SQL

• 용어
  • 스키마 : 데이터베이스의 구조와 제약조건에 관해 전반적인 명세를 기술한 것
    • Attribute(속성), Entity(개체), Relation(관계), 제약조건들

 2)특징

• 기본적으로 HTTP를 통해 JSON형식의 RESTFul API 를 사용 가능
• Scale Out : 샤드를 통해 규모가 수평적으로 늘어날 수 있다.
• 고가용성 : Replica를 통해 데이터의 안정성 보장
• Schema Free : Json 문서를 통해 데이터 검색을 수행하므로 스키마 개념이 없다.
• 클러스터 : 엘라스틱서치에서 가장 큰 단위 시스템, 최소 하나 이상의 노드로 이루어진 노드들의 집합이다. 서로 다른 클러스트는 데이터의 접근,교환을 할 수 없는 독립적인 시스템으로 유지되며, 여러대의 서버가 하나의 클러스터를 구성할 수 있고, 한 서버에 여러개의 클러스터가 존재할 수 도 있다.
• 노드 : 엘라스틱 서치를 구성하는 하나의 단위 프로세스를 의미
  • master-eligible node : 클러스터를 제어하는 마스터로 선택할 수 있는 노두
    • 인덱스 생성, 삭제
    • 클러스터 노드들의 추적, 관리
    • 데이터 입력 시 어느 샤드에 할당할 것인지
  • Data node : 데이터와 관련된 CRUD 작업과 관련 있는 노드, CPU와 메모리 등 자원을 많이 소모하여 모니터링이 필요하고 master 노드와 분리되는 것이 좋다.
  • Ingest node : 데이터를 변환하는 등 사전 처리 파이프라인을 실행하는 역할
  • Coordination only node : data node와 master-eligible node의 일을 대신하는 이 노드는 대규모 클러스터에서 큰 이점이 있습니다. 즉 로드밸런서와 비슷한 역할을 한다고 보시면 됩니다.
• 인덱스/샤드/복제
  • Index : RDMBS에서 database와 대응하는 개념
  • sharding : 데이터를 분산해서 저장하는 방법, elasticsearch에서 스케일 아웃을 위해 index를 여러 shard로 쪼갠것이다. 기본적으로 1개가 존재하며, 검색 성능 향상을 위해 클러스터의 샤드 갯수를 조정하는 튜닝을 하기도 한다.
  • replica : 또 다른 형태의 shard라고 할 수 있다. 노드를 손실했을 경우 데이터의 신뢰성으 위해 샤드들을 복제한다.  따라서 Replica는 서로 다른 노드에 존재할 것을 권장한다.

3)엘라스틱 서치의 장점

1. 오픈소스 검색 엔진 : 아파치 재단의 루씬(Lucene)을 기반으로 개발된 오픈 소스 검색 엔진
2. 전문 검색(Full Text) : 내용 전체를 색인해서 특정 단어가 포함된 문서를 검색하는 것
3. 통계 분석 : 비정형 로그 데이터를 수집하고 한 곳에 모아 통계를 분석 할 수 있다. ex)Kibana
4. 멀티테넌시 (Multi-teneancy) : 검색할 필드명으로 여러 개의 인덱스를 한번에 조회할 수 있다.
5. 역색인 : 역색인 구조를 통해 특정 단어를 찾을 때 문서 전체에서 찾는 것이 아닌, 단어가 포함된 특정 문서의 위치를 알아내어 빠르게 결과를 찾아낼 수 있다.
6. 분산 환경 : 데이터를 샤드라는 작은 단위로 나누어 제공한다. 데이터를 분산하여 빠르게 처리한다.

4)엘라스틱 서치의 단점

1. 실시간이 아니다 : 엘라스틱 서치는 데이터 저장 시점에 해당 데이터를 색인한다. 색인된 데이터는 1초 뒤에나 검색이 가능해져 실시간으로 검색이 불가능하다. 내부적으로 커밋, 플러쉬와 같은 복잡한 과정을 거친다.
2. 트랜잭션과 롤백 기능이 없다 : 전체적인 클러스터의 성능 향상을 위해 비용 소모가 큰 롤백과 트랜잭션 기능이 없다.
3. 데이터의 업데이트를 제공하지 않는다 : 엘라스틱서치는 문서를 수정(update)하지 않는다. 엘라스틱 서치에서 업데이트느 기존 문서를 삭제하고 다시 삽입하는 방식이다.

 

3.  CI/CD : 지속적 통합(Continuous Integration)/지속적 배포(Continuous Deployment)

• 매번 개발자가 코드를 수정하고 빌드와 테스트를 하고 배포까지 한다면 시간이 많이 걸린다.
• 하지만 git에 코드를 올리는 것만으로도 누군가가 빌드와 테스트, 배포까지 해준다면 시간단축이 된다.

 1)CI란?

• 빌드/테스트 자동화 과정
• 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트 되어 공유 리포지토리에 통합되므로 여러명의 개발자가 동시에 애플리케이션 개발과 관련된 코드를 작업할 경우 서로 충돌하는 문제 해결 가능
• CI의 실행은 소스/버전 관리 시스템에 대한 변경 사항을 정기적으로 커밋하여 모든 사람에게 동일 작업 기반을 제공하는 것으로 시작된다.
• 커밋 시 빌드와 테스트가 자동으로 이루어져 동박을 확인하고 변경으로 인해 문제가 생기는 부분이 없도록 보장
• CI/CD 파이프 라인의 구현을 위한 첫 번째 단계이다.

 2)CD란?

• 배포 자동화 과정
• 지속적 서비스 제공(Continuous Delivery)과 지속적인 배포(Continuous Deployment)를 의미
• 빌드, 테스트 및 배포 단계를 자동화 하는 DevOps 방식을 극한까지 끌어 올린다. 코드 변경이 파이프라인의 이전 단계를 모두 성공적으로 통과하면 수동 개입 없이 해당 변경 사항이 프로덕션에 자동으로 배포
• 성숙하고 입증된 지속적 통합 및 지속적인 전달 단계를 기반으로 한다. 간단한 코드 변경이 정기적으로 마스터에 커밋되고, 자동화된 빌드 및 테스트 프로세스를 거치며 다양한 사전프로덕션 환경으로 승격되며, 문제가 발견되지 않으면 최종적으로 배포

 3)CI/CD 종루

• Jenkins
• CircleCi
• TravisCi
• Github Actions
• etc

4.  Docker

• Go언어로 작성된 리눅스 컨테이너 기반으로 하는 오픈소스 가상화 플랫폼

 1)가상화를 사용하는 이유

• 서버 사용율이 낮은 서버들의 리소스는 낭비될 수 밖에 없는데 그렇다고 한 서버안에 모든 서비스를 올리면 안정성에 문제가 생긴다. 그래서 안정성을 높이며 리소스도 최대한 활요할 수 있는 방법으로 나타난게 서버 가상화이다.
• 대표적인 가상화 플랫폼으로는 VM이 있고 VM은 OS가상화이다.
  • VM : 하나의 서버가 있고 HostOS( 맥,리눅스,ms윈도우 등)가 올라간다. 호스트 OS에 의해 VM을 가상화 시켜주는 하이퍼바이저(virtual box, Xen, KVM, VMware)들이 있다. 하이퍼 바이저를 사용해 원하는 운영체제로 GuestOS를 올려 여러 VM을 만들 수 있다. GuestOS도 HostOS와 같이 하나의 독립적 OS를 가지고 사용가능하다. 
  • 컨테이너 : VM과 HostOS 까지 설치는 동일하다. 이 OS에 의해 컨테이너를 가상화 시켜주는 여러가지 소프트웨어중에 도커를 가장 많이 사용한다. 도커를 설치하고 컨테이너 이미지를 만들면 이미지에는 한서비스와 그 서비스가 돌아가는데 필요한 라이브러리들이 있다. 
  • VM과 컨테이너의 차이 : 구조적으로 컨테이너는 한 OS를 공유하지만 VM은 각각의 OS를 띄워야하는 구조이기 때문에 컨테이너가 빠르다. 다만 VM은 호스트가 윈도우일때 게스트로 리눅스를 설치해 사용가능하지만, 컨테이너는 리눅스 OS에서 윈도우용 컨테이너를 사용할 수 없다. 또한 보안적으로 VM은 분리되어 있어 서로 피해가 가지 않지만 컨테이너는 보안의 문제가 생길 수 있다.
  • 쿠버네티스 : 여러 컨테이너들을 한 파트라는 개념으로 묶을 수 있다. 한 파트가 배표의 단위이다.컨테이너는 시스템을 모둘별로 쪼개서 개발을 했을 때 큰 효과를 발휘할 수 있다.

 2)컨테이너란

• 서버 사용율이 낮은 서버들의 리소스는 낭비될 수 밖에 없는데 그렇다고 한 서버안에 모든 서비스를 올리면 안정성에 문제가 생긴다. 그래서 안정성을 높이며 리소스도 최대한 활요할 수 있는 방법으로 나타난게 서버 가상화이다.

 

5.  Logstash

• 데이터 집계, 변환 ,저장
• 형식이나 복잡성과 관계없이 데이터를 동적으로 수집, 전환, 전송한다.
• grok을 이용해 비구조적 데이터에서 구조를 도출하여 IP주소에서 위치 정보 좌표를 해독하고, 민감한 필드를 익명화하거나 제외시키며, 전반적인 처리를 손쉽게 해준다.
• 입력 : 모든 형태, 크기, 소스의 데이터 수집(ex. Filebeat)
  • 데이터는 여러 시스템에서 다양한 형태로 보관된 경우가 많은데 Logstash는 일반적인 다수의 소스에서 동시에 이벤트를 가져오는 다양한 입력을 지원한다. 로그, 메트릭, 웹 애플리케이션, 데이터 저장소 및 다양한 AWS 서비스에서 모두 지속적으로 스트리밍 되는 방식으로 손쉽게 수집할 수 있다.
• 필터 : 데이터 이동 과정에서의 구문 분석 및 변환(ex. Grok)
  • Logstash 필터는 데이터가 소스에서 저장소로 이동하는 과정에서 각 이벤트를 구문 분석하고 명명된 필드를 식별하여 구조를 구축하며, 이를 공통 형식으로 변환 통합하여 분석을 더욱 강력하게 만드는 동시에 비즈니스 가치를 높여줍니다.
  • Grok은 임의의 텍스트를 구문 분석하고 구조화합니다. 구조화되지 않은 로그 데이터를 구조화되고 쿼리 가능한 것으로 구문 분석하는 좋은 방법입니다.
• 출력 : 스태시를 선택하여 데이터 전송(ex. Elasticsearch)
  • Logstash는 Elasticsearch를 포함하여 원하는 곳으로 데이터를 라우팅할 수 있는 다양한 출력을 지원하기 때문에 여러 저장소로 데이터를 다운스트림하는 유연성을 확보할 수 있습니다.

 1)logstash 사용 예시

• 이벤트 저장
• Apache 웹 로그를 입력으로 사용
• 로그를 파싱
• 파싱된 데이터를 Elasticsearch 클러스터에 쓰는 고급 파이프라인 생성
• 여러 입출력 플러그인을 연결하여 서로 다른 다양한 소스의 데이터를 통합

• Logstash 파이프라인에는 input(입력) 및 output(출력)이라는 두 가지 필수 요소와 filter(필터)라는 하나의 선택적 요소가 있습니다. 입력 플러그인은 원본의 데이터를 가져오고 필터 플러그인은 지정한 대로 데이터를 수정하며 출력 플러그인은 대상에 데이터를 씁니다.

 

6.  아파치/ 톰캣/아파치 카프카/ 아파치 루신

 1)아파치(Apache)

• 세계에서 가장 많이 쓰는 웹 서버 중 하나
• Apache 재단에서 만들었으며 다양하고 기능적인 면에서 우수하다.
• 구축이 쉽지만 아파치 자체만으로는 무겁고, Squid와 함께 Slowloris취약점이 발견었다.
  • 프로그래밍 숙련자나 대형사이트 운영자는 Nginx, IIS를 주로 사용
  • 대부분의 중소기업들은 무료라서 많이 사용
• 정적인데이터를 처리하는 웹서버이다.

 1-1)톰캣(Tomcat)

• 아파치 재단의 어플리케이션 서버이다.
• 자바 서블릿을 실행시키고 jsp코드가 포함되어 있는 웹페이지를 만들어준다.
• webserver에서 넘어온 동적인 페이지를 읽어드려 프로그래밍을 실행하고 결과를 다시 html로 재구성하여 아파치에게 돌려준다.
• 동적인 데이터를 처리하는 웹서버이다.
• WAS(web Application Server)라고 불린다. 
• 웹서버와 웹컨테이너의 결합으로 다양한 기능을 컨테이너에 구현하고 다양한 역할을 수행하는 서버이다.

 1-2)WAS의 구성

• 사용자 request(웹 브라우저) > 웹서버> was(동적처리) > 웹서버 >사용자 응답 메시지(웹 브라우저)

• 아파치와 톰캣의 장단점

	장점	단점
Apache(static)	1. 처리 속도가 빠름 2. 구조가 단순하여 비용절감 3. 트래픽 과부하에 강하다.	1. 정적인 데이터만 처리가 가능 2. 다른 서비스와 상호작용 불가
Tomcat(dynamit)	1. 데이터 흐름이 유동적이다.	1. 아파치에 비해 속도가 느리다. 2. 부가적인 비용이 발생한다. 3. 트래픽 과부하게 약함

 2)아파치 카프카(Apache Kafka)

• 카프카는 웹사이트, 어플리케이션, 센서 등에 취합한 데이터를 스트림 파이프라인을 통해 실시간으로 관리하고 보내기 위한 분산 스트리밍 플랫폼이다.
• 데이터를 생성하는 어플리케이션과 데이터를 소비하는 어플리케이션 간의 중재자 역할을 함으로써 데이터의 전송 제어, 처리, 관리 역할을 한다.
• 카프카 시스템은 여러 요소(노드)와 함께 구성될 수 있어 카프카 클러스터라고 불리기도 하며, 어플리케이션과 서버간의 비동기 데이터 교환을 용이하게 하며, 하루에 소 조개의 이벤트 처리가 가능하게 만드는 역할을 한다.
• 즉 플랫폼에 서비스를 연결하여 데이터 흐름을 실시간으로 제어하는 중추 역할을 한다.

• 기본 구성 요소
  • Cluster : 여러 대의 컴퓨터들이 연결되어 하나의 시스템처럼 동작하는 컴퓨터들의 집합
  • Producer : 데이터를 만들어 내는 전달자의 역할
  • Consumer : 프로듀서에서 전달한 데이터를 브로커에게 요청하여 메시지(데이터)를 소비하는 역할
  • Broker : 생산자와 소비자와의 중재자 역할
  • Topic : 보내는 메시지를 구분하기 위한 카테고리화
  • Partition : 토픽을 구성하는 데이터 저장소로서 수평확장이 가능한 형태
• 하나 이상의 브로커로 아래와 같이 클러스터를 구성한다.

• Kafka의 Pub-Sub 모델
  • 송신자가 메시지를 특정 수신자에게 직접 보내는 것이아닌 Topic이라는 카테고리를 묶어서 보내고 구독자는 해당 Topic을 구독함으로써 메시지를 받는다.

• Kafka의 특징
  1.  여러 전달자(Producer)가 동시에 메시지를 전송하고, 여러 소비자(Consumer)가 동시에 받을 수 있다.
  2. 한 노드가 메시지를 전송하면 전달자와 소비자를 중재하는 브로커에서 전달자가 전달한 메시지를 브로커의 동작에 영향을 주지 않고 처리 속도 및 장애 복구를 유지할 수 있게 하기 위해 일정 기간 동안 파일로 저장
  3. 트래픽이 높아지면 브로커를 추가해서 클러스터 확장 가능
  4. 처리 속도가 저하되면 소비자 또는 생산자를 추가해 처리량을 늘릴 수 있다.
  5. 소비자가 프로듀서의 메시지 생성속도를 따라가지 못할 때 컨슈머를 그룹으로 묶어 프로듀서에서 보내는 속도와 읽는 속도의 균형을 맞출 수 있다.
• Kafka의 장단점
  • 앞선 특징이 장점이라 할 수 있지만 모니터링 및 관리 도구가 불편하여 메시지 조정이 필요한 경우 성능이 크게 저하되며, 클러스터의 대기열 수가 증가하면 상대적으로 느리게 동작하는 경우가 있다.

• 카프카의 용도
  • 플랫폼으로 끊임없이 들어오는 데이터를 일괄적으로 묶어서 처리하고 데이터를 전달한다.
  • IoT 데이터 처리, 금융거래 사기 방지 등에 사용한다.
  • 오픈마켓에서 사용자의 활동을 분석해 전략적 비즈니스를 도와주는 수집/분석을 한다
  • 넷플릭스, 트위터, 링크드인, 오라클 등에서 사용중이다.

 3)아파치 루씬(Apache Lucene)

• java언어로 이루어진 오픈 소스 형태의 정보 검색 라이브러리
• 어플리케이션이 아니라 search application 을 만드는데 사용하는 라이브러리 이다.
• 이 라이브러리를 기반으로 하여 아파치 쏠라(Apache Solar)혹은 엘라스틱 서치(ElasticSearch)가 구동된다.
• 전문 검색(Full Text) 색인 및 검색 기능을 필요로 하는 어플리케이션에 적합하며, 웹 검색 엔진 및 로컬 단일 사이트 검색 구현에서 유횽하다.
• 색인과 검색 기능을 제공함으로 그외에 모든 것(문서 수집, text 추출, 검색기능을 제공하는 서버, 사용자 인터페이스 등)은 개발자가 구현해야한다.
• 아래 그림의 짙은 녹색을 아파치 루씬이 지워준다고 생각하면 쉽다.

• 루씬 색인의 특징
  • 우수한 확장성
  • 고성능의 색인
  • 시간당 150GB이상 처리가능하고 작은 메모리 사용량(1MB 힙 메모리 요구)
  • 색인이 늘어나도 배치 색인만큼 빠른 색인 가능
  • 텍스트 색인 시 색인 파일의 용량은 텍스트의 20~30%수준
• 루씬 검색의 특징
  • 가장 적합한 결과를 상위에 반환하는 순위 검색을 지원하는 점
  • 풍부하고 강력한 검색어 유형을 제공하는 점(Phrase Query, Wildcar Query, Proximity Query, Range Query 등)
  • 필드 검색을 지원하는 점
  • 다중 색인 검색을 지원하는 점
  • 준 실시간 검색이 가능하다는 점
• 루씬의 색인과 검색 과정
  1. 필드를 가진 도큐먼트를 생성
  2. IndexWriter 객체를 만들고 도큐먼트를 addDocument() 메서드를 사용해 색인에 추가
  3. QueryParser.parse()를 사용하여 문자열에서 쿼리 생성
  4. IndexSearcher를 생성하여 쿼리를 search()메소드에 전달.

7.  쿠버네티스(Kubernetes)

• 컨테이너화된 애플리케이션 관리시스템

 1)기능

• 실제 프로덕션 환경에서 애플리케이션들은 여러 컨테이너에 걸쳐있으며 이러한 컨테이너는 여러 서버 호스트에 배포되어 있다. 이 떄문에 컨테이너를 위한 보안은 멀티 레이어 구조로 되있고 복잡할 수 있다.
• 쿠버네티스 오케스트레이션을 사용하면 여러 컨테이너에 걸쳐 애플리케이션 서비스를 구축하고 클러스터 전체에서 컨테이너 일정을 계획하고 확장하여 관리할 수있으며 IT 보안을 한층 강화할 수 있다.

 2)주요 구성 요소

• 클러스터 : 컨트롤 플레인 및 하나 이상의 컴퓨팅 머신 또는 노드로 구성된다. 최소 하나 이상의 제어판 컴포넌트와, 이것과 연결된 몇 개의 워커노드로 구성되어 있다.
• 컨트롤 플레인(제어판) : 노드를 제어하는 프로세스들이 모여있다. 여기서 모든 태스크 할당이 시작된다.
  • etcd : 클러스터의 모든 데이터를 담고 있는 key-value 저장소, 인프라를 원하는 상태로 만들기 위해 정상 상태에 대한 snapshot 및 관리에 필요한 메타데이터를 저장
  • kube-api-server : 클러스터의 허브로 클라이언트와 etcd에 저장된 데이터 사이의 상호작용을 중개한다. 사용자, 클러스터 내 구성요소 그리고 외부 컴포넌트가 서로 통신할 수 있도록 HTTP API제공
  • kuge-scheduler : 새로운 POD를 감지하여 어떤 워커노드에 실행시킬지 선택, 노드의 현재 상태와 Pod의 요구사항을 체크
  • kube-controller-manager : API 서버를 통해 클러스터의 다양한 컴포넌트들의 상태를 감지하고 원하는 상태로 만들어준다. 다양한 컨트롤러가 하나로 패키징되어 단일 프로세스 내에서 실행되게 한다.
• 워커노드 : kublet이라는 프로세스가 돌아가고 있는데, 이 kublet은 다른 노드와 서로 통신하거나 컨테이너를 실행하는 등의 태스크를 실행할 수 있게 한다. 
  • kublet : 각 노드에서 실행되는 기본 노드 에이전트. 컨테이너를 생성,삭제하고 상태를 모니터링 하며 마스터 노드와 통신을 담당한다. 쿠버네티스에서 생성되지 않은 컨테이너는 관리 안한다
  • kube-proxy : 모든 워커 노드마다 실행되는 네트워크 프록시이다. 다른 Pod간의 네트워크 통신과 클러스터 바깥에서 Pod로 네트워크 통신을 가능하게 해준다

 

 

11.  참조

 1)ElasticSearch : https://victorydntmd.tistory.com/308

[Elasticsearch] 기본 개념잡기

 2)엘라스틱서치 기본 개념 : https://devfunny.tistory.com/384

엘라스틱서치의 기본개념 및 장점/단점

 3)엘라스틱서치와 스프링 예제 : https://tecoble.techcourse.co.kr/post/2021-10-19-elasticsearch/

Spring Data Elasticsearch 설정 및 검색 기능 구현

 4)VM과 컨테이너의 개념과 차이: https://daaa0555.tistory.com/464

VM(가상머신) 과 Container(컨테이너)의 차이

 5)Docker 핵심 개념 : https://khj93.tistory.com/entry/Docker-Docker-%EA%B0%9C%EB%85%90

[Docker] Docker의 개념 및 핵심 설명

 6)Logstash : https://dc2348.tistory.com/32

[Logstash] Logstash란?

 7)아파치와 톰캣 : https://m.blog.naver.com/sincc0715/221815775570

HTTP 아파치(Apache)란 무엇인가?

8)아파치 카프카 : https://blog.naver.com/PostView.naver?blogId=arkdata&logNo=222632637775&parentCategoryNo=&categoryNo=14&viewDate=&isShowPopularPosts=true&from=search 

아파치 카프카 (Apache Kafka)란?

9)아파치 루씬 :https://min-nine.tistory.com/m/223

Apache Lucene 이란? - 아파치 루씬에 대한 학습

10)쿠버네티스 : https://www.codestates.com/blog/content/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4