BE Resources
- version : jdk21
- SequencedCollection 이 인터페이스는 컬렉션의 양쪽 끝에 요소를 추가, 검색, 제거하는 메서드를 제공합니다.
- SequencedSet
- SequencedMap
가상 스레드는 시스템에 최소한의 오버헤드를 가하기 때문에 한 애플리케이션에 수천 개의 스레드를 가질 수 있습니다.
- Type Pattern을 활용할수있도록
- 예시
- Garbage Collection
- version : 3.3.1
- version : 1.18.34
- version : 1.5.5
- mapstruct vs modelMapper
- 컴파일 시점 매핑코드 생성 -> 빠른 성능, 안전성보장, 오류감소
- Annotation processor
- 복잡한 매핑에 더 유연.
*dependency implementation 'org.mapstruct:mapstruct:1.5.5.Final' annotationProcessor 'org.mapstruct:mapstruct-processor:1.5.5.Final'
// Lombok과 함께 사용할 경우 )))lombok -> mapstruct 순으로 annotationProcessor 'org.projectlombok:lombok-mapstruct-binding:0.2.0'
jjwt-api-0.11.5
version : 3.9.0 Sops
version : 8.0.33
opensearch-java Client User Guide
- 영속성 레이어에서 오픈서치를 구현하는데 필요한 curd 레포지토리를 제공, 적용할 버전 1.5.1
- version: 3.1.x
- 효율적인 로그 저장
- Loki는 메타데이터만 인덱싱하고 로그 데이터 자체는 압축된 형태로 저장합니다. 이는 인덱싱을 최소화하여 스토리지와 검색 성능을 최적화합니다.
- 비용 절감
- Loki는 로그 데이터의 인덱싱을 최소화하기 때문에, Elasticsearch와 같은 다른 로그 관리 시스템에 비해 스토리지 비용과 인덱싱 오버헤드가 낮습니다. 이는 대량의 로그 데이터를 저장하고 관리할 때 큰 비용 절감을 가능하게 합니다.
- Kubernetes 친화적
- Loki는 Kubernetes 환경과 긴밀하게 통합되도록 설계되었습니다. Prometheus와 유사한 라벨링 방식을 사용하여, Kubernetes에서 로그 데이터를 쉽게 수집하고 관리할 수 있습니다.
- Grafana와의 통합
- Loki는 Grafana와 자연스럽게 통합됩니다. Grafana 대시보드를 통해 Loki에 저장된 로그 데이터를 쉽게 시각화하고 분석할 수 있습니다. 이는 로그 데이터와 메트릭 데이터를 통합하여 모니터링 환경을 단순화합니다.
- 간단한 아키텍처
- Loki는 복잡한 인프라 구성이 필요하지 않으며, 설정이 간단합니다. 이는 빠르게 설정하고 사용할 수 있도록 해줍니다.
- 다양한 로그 수집 도구와 통합
- Loki는 Fluentd, Fluent Bit, Promtail 등 다양한 로그 수집 도구와 통합되어, 다양한 소스에서 로그 데이터를 쉽게 수집할 수 있습니다.
- 전체 텍스트 검색이 필요 없는 경우
- Loki는 전체 텍스트 검색을 제공하지 않지만, 메타데이터 기반의 필터링을 통해 효율적으로 로그를 조회할 수 있습니다. 이는 전체 텍스트 검색이 필요 없는 로그 데이터에 적합합니다.
결론
- Loki는 로그 데이터의 저장 및 관리를 보다 효율적이고 경제적으로 할 수 있는 도구입니다. Kubernetes 환경과의 뛰어난 통합성, Grafana와의 원활한 연동, 그리고 낮은 스토리지 비용 덕분에 많은 조직에서 Loki를 선택하여 사용하고 있습니다. 전체 텍스트 검색이 필요 없는 로그 데이터의 경우, Loki는 특히 적합한 솔루션입니다.
- 로그의 전체 텍스트 검색이 필요 없다면 다른 로그 관리 시스템에 비해 가벼운 Loki만 사용하는게 어떨까 싶습니다.
- version: 7.2.5
- version: 1.27.0
- version: 8.14
- version: 3.0.x
Fluent Bit과 Logstash는 모두 로그 및 데이터 수집, 처리, 전송을 위한 도구입니다. 두 도구의 특징과 차이점을 비교해 보겠습니다.
Fluent Bit:
-
경량화:
- C로 작성되어 매우 작은 메모리 풋프린트 (약 650KB)
- 리소스 사용이 적음
-
속도:
- 빠른 처리 속도
-
플랫폼:
- 다양한 플랫폼 지원 (Linux, Windows, macOS, 임베디드 시스템)
-
사용 사례:
- 주로 엣지 컴퓨팅, IoT, 컨테이너 환경에서 사용
-
설정:
- 비교적 간단한 설정
-
플러그인:
- 제한된 수의 플러그인, 하지만 필수적인 것들은 포함
-
확장성:
- C로 플러그인 개발 가능
Logstash:
-
리소스 사용:
- Java 기반으로 상대적으로 큰 메모리 풋프린트
- 리소스 사용량이 더 많음
-
기능:
- 더 풍부한 기능과 다양한 플러그인 제공
-
플랫폼:
- 주로 서버 환경에서 사용
-
사용 사례:
- 대규모 데이터 처리, 복잡한 데이터 변환 작업에 적합
-
설정:
- 더 복잡하고 상세한 설정 가능
-
플러그인:
- 매우 다양하고 풍부한 플러그인 생태계
-
확장성:
- Ruby로 플러그인 개발 가능
-
Elastic Stack:
- Elasticsearch, Kibana와 함께 ELK 스택의 일부로 자주 사용
주요 차이점:
-
성능과 리소스 사용:
- Fluent Bit: 더 가볍고 빠름, 적은 리소스 사용
- Logstash: 더 많은 리소스를 사용하지만 복잡한 처리 가능
-
사용 환경:
- Fluent Bit: 제한된 리소스 환경, 엣지 컴퓨팅, 컨테이너에 적합
- Logstash: 서버 환경, 대규모 데이터 처리에 적합
-
기능의 복잡성:
- Fluent Bit: 간단하고 직관적인 설정
- Logstash: 더 복잡하지만 강력한 데이터 처리 기능
-
플러그인 생태계:
- Fluent Bit: 제한적이지만 필수적인 플러그인 제공
- Logstash: 매우 다양하고 풍부한 플러그인 생태계
-
데이터 처리 능력:
- Fluent Bit: 기본적인 필터링과 변환
- Logstash: 복잡한 데이터 변환, 풍부한 필터 옵션
선택 기준:
- 리소스가 제한된 환경이나 경량화가 필요한 경우 Fluent Bit을 선택
- 복잡한 데이터 처리나 변환이 필요한 대규모 환경에서는 Logstash를 선택
- 컨테이너 환경이나 엣지 컴퓨팅에는 Fluent Bit이 더 적합
- ELK 스택을 완전히 활용하고자 한다면 Logstash가 더 적합
- 간단한 로그 수집 및 전송만 필요하다면 Fluent Bit으로 충분
- 다양한 데이터 소스와 복잡한 데이터 파이프라인이 필요하다면 Logstash가 더 적합
실제 사용 시나리오:
-
하이브리드 사용: 많은 조직에서는 Fluent Bit과 Logstash를 함께 사용합니다. Fluent Bit을 엣지나 소스에 가까운 곳에서 데이터를 수집하는 데 사용하고, 이를 중앙 Logstash 인스턴스로 전송하여 더 복잡한 처리를 수행합니다.
-
마이크로서비스 환경: 컨테이너화된 마이크로서비스 아키텍처에서는 각 서비스 컨테이너에 Fluent Bit을 사이드카로 배포하여 로그를 수집하고, 중앙 로그 저장소나 분석 시스템으로 전송할 수 있습니다.
-
IoT 환경: 리소스가 제한된 IoT 디바이스에서는 Fluent Bit을 사용하여 데이터를 수집하고 중앙 시스템으로 전송할 수 있습니다.
-
대규모 데이터 처리: 대량의 로그 데이터를 처리하고 복잡한 변환이 필요한 엔터프라이즈 환경에서는 Logstash가 더 적합할 수 있습니다.
결론: Fluent Bit과 Logstash는 각각의 강점이 있는 강력한 도구입니다. 선택은 프로젝트의 요구사항, 인프라 환경, 처리해야 할 데이터의 복잡성 등을 고려하여 이루어져야 합니다. 때로는 두 도구를 함께 사용하여 각각의 장점을 최대한 활용하는 것도 좋은 전략이 될 수 있습니다. 중요한 것은 자신의 사용 사례와 환경에 가장 적합한 도구나 조합을 선택하는 것입니다.
- 위 토글 내용을 고려하여 간단한 로그 수집 및 전송용으로 충분하고, 리소스 사용이 적고 빠른 처리 속도를 가진 Fluent Bit 사용이 어떨까 싶습니다.
- version: 27.0.3
- version: 1.30
- version: 11.1
- version: 2.53
- Dependencies
- implementation 'org.springframework.boot:spring-boot-starter-actuator' // Promethesus에서 사용할 메트릭 정보를 위해
- implementation 'io.micrometer:micrometer-registry-prometheus'
- version: 0.52.x
- CLI 도구로 설치해서 사용
- Javasccript 사용
- 스터디 필요
Grafana k6는 오픈 소스 성능 테스트 도구로, 개발자와 DevOps 팀이 웹 애플리케이션, API 및 마이크로서비스의 성능을 테스트하고 모니터링할 수 있도록 설계되었습니다. Grafana Labs가 인수하여 Grafana 생태계의 일부가 되었습니다. 주요 기능과 특징은 다음과 같습니다.
-
스크립트 기반 테스트:
- k6는 JavaScript로 작성된 테스트 스크립트를 사용합니다. 이는 개발자들이 친숙한 언어를 통해 테스트 스크립트를 작성하고 유지 관리할 수 있게 해줍니다.
-
확장성:
- k6는 단일 인스턴스에서 실행할 수 있으며, 필요에 따라 분산된 환경에서 수천 개의 동시 가상 사용자를 처리할 수 있습니다.
-
결과 시각화 및 모니터링:
- k6는 다양한 백엔드에 결과를 보낼 수 있습니다. Grafana와 통합하여 실시간으로 성능 테스트 결과를 시각화하고 모니터링할 수 있습니다.
-
사용자 시나리오 시뮬레이션:
- 복잡한 사용자 시나리오를 쉽게 시뮬레이션할 수 있어, 다양한 사용자 행동 패턴을 테스트할 수 있습니다.
-
자동화:
- CI/CD 파이프라인에 쉽게 통합할 수 있어, 지속적인 성능 테스트가 가능하게 합니다.
-
경량화:
- k6는 경량화된 도구로, 성능 테스트를 실행할 때 최소한의 시스템 자원을 사용하여 효율성을 극대화합니다.
-
다양한 프로토콜 지원:
- HTTP/1.1, HTTP/2, WebSocket 등을 지원하여 다양한 유형의 애플리케이션을 테스트할 수 있습니다.
-
웹 애플리케이션 성능 테스트:
- 다양한 시나리오를 통해 웹 애플리케이션의 성능을 테스트하고 병목 지점을 찾아냅니다.
-
API 부하 테스트:
- RESTful 및 GraphQL API의 성능을 테스트하고, 높은 부하 시의 응답 시간을 분석합니다.
-
마이크로서비스 테스트:
- 마이크로서비스 아키텍처의 성능을 테스트하여 서비스 간의 상호작용 및 의존성을 확인합니다.
-
CI/CD 통합:
- 지속적인 배포 파이프라인에 성능 테스트를 통합하여, 새로운 릴리스가 성능에 미치는 영향을 미리 파악합니다.
k6는 Grafana와 원활하게 통합되어, 성능 테스트 결과를 Grafana 대시보드를 통해 실시간으로 시각화하고 분석할 수 있습니다. 이를 통해 성능 테스트 데이터를 다른 모니터링 데이터와 함께 분석할 수 있어, 시스템 성능을 보다 종합적으로 이해할 수 있습니다.
Grafana k6는 현대적인 애플리케이션의 성능 테스트와 모니터링을 위한 강력한 도구입니다. 사용자 친화적인 스크립트 작성, 뛰어난 확장성, 그리고 Grafana와의 통합을 통해 성능 테스트를 쉽고 효과적으로 수행할 수 있습니다. 이를 통해 개발팀과 운영팀은 애플리케이션의 성능을 최적화하고, 사용자 경험을 향상시킬 수 있습니다.
- 주요 목적: 일반적인 데이터 저장 및 액세스
- 액세스 속도: 즉시 또는 거의 즉시 액세스 가능 (밀리초 단위)
- 비용: 고가용성 및 신속한 액세스를 제공하므로 비교적 높은 비용
- 사용 사례: 자주 액세스해야 하는 데이터, 웹 사이트 콘텐츠, 데이터 백업 및 복구, 빅데이터 분석, 모바일 및 IoT 애플리케이션 데이터 저장소
- 스토리지 클래스: 여러 스토리지 클래스가 있어 사용 패턴에 따라 비용 최적화 가능. 예를 들어, Standard, Standard-IA (Infrequent Access), One Zone-IA, Intelligent-Tiering 등
- 주요 목적: 장기 아카이빙 및 백업, 드물게 액세스하는 데이터 저장
- 액세스 속도: 느린 액세스 시간. Standard, Bulk, Expedited 세 가지 복구 옵션이 있으며, 몇 분에서 몇 시간까지 걸릴 수 있음
- 비용: 매우 저렴한 비용. 주로 장기 보관을 위한 저비용 스토리지
- 사용 사례: 법적 규제 준수를 위한 데이터 보관, 디지털 자산 아카이빙, 로그 및 분석 데이터 장기 저장
- 스토리지 클래스: Glacier 및 Glacier Deep Archive. Glacier Deep Archive는 Glacier보다 더 저렴하지만 복구 시간이 더 오래 걸림
복구 시간
Amazon S3 Glacier
- Expedited: 몇 분 이내에 액세스 가능
- Standard: 3~5시간 내에 액세스 가능
- Bulk: 5~12시간 내에 액세스 가능
Amazon S3 Glacier Deep Archive
- Standard: 12시간 이내에 액세스 가능
- Bulk: 48시간 이내에 액세스 가능
- implementation(platform("software.amazon.awssdk:bom:2.21.1"))
- implementation("software.amazon.awssdk:s3")
- 데이터 액세스가 잦지 않고 로그 파일 아카이빙 용도로 사용하기에 비용이 더 저렴한 Amazon S3 Glacier 사용이 적절할 듯 합니다.
- version: 4.0.0
Ollama Github, Llama 3 Requirements
- 프로젝트 진행 시 사용 token은 100만건으로 충분할 듯하여 5달러 지불하고 GPT 사용하는게 좋아보입니다.