Linux

Linux의 Redirection

리눅스의 리디렉션은 명령어의 **표준 입출력 (Standard Input/Output)**을 다른 파일이나 명령어로 연결하여 사용자가 원하는 대로 입출력을 제어할 수 있는 기능입니다. 리디렉션은 파일과 명령어 간의 데이터 흐름을 조정하여 결과를 저장하거나 입력 데이터를 변경할 때 매우 유용합니다. 리디렉션에는 표준 출력, 표준 입력, 표준 오류가 있으며, 각각 > (출력), (입력), 2> (오류) 기호를 사용하여 처리합니다. 1. 리디렉션 종류 리디렉션은 아래와 같은 세 가지 기본 형태로 나뉩니다. 1. 표준 출력 리디렉션 (Standard Output Redirection) • 기호: > • 설명: 명령어의 출력을 파일로 저장합니다. 만약 파일이 이미 존재하면 해당 파일 내용을 덮어씁니다. • 예시..

2024. 11. 8. 16:52

Linux

Linux의 Pipe

리눅스의 **파이프(pipe)**는 명령어 간의 데이터를 효율적으로 전달하는 기법으로, 명령어의 결과를 다른 명령어의 입력으로 바로 전달하여 데이터 흐름을 만들 수 있습니다. 파이프를 사용하면 복잡한 명령어 작업을 하나로 연결하여 처리할 수 있으며, 데이터가 메모리에서 바로 이동하기 때문에 속도와 자원 효율성이 뛰어납니다. 파이프의 작동 방식 파이프는 기본적으로 명령어 간에 **표준 출력(Standard Output, STDOUT)**과 **표준 입력(Standard Input, STDIN)**을 연결하여, 한 명령어의 출력이 다음 명령어의 입력이 되도록 만듭니다. 이를 통해 다음과 같은 방식으로 데이터가 흐릅니다:명령어1 | 명령어2 | 명령어3 위와 같이 명령어들을 파이프로 연결하면, 명령어1의 출력..

2024. 11. 8. 16:44

Microservices Architecture

Apache Kafka와 ActiveMQ

1. Apache Kafka Apache Kafka는 대용량의 데이터 스트림을 실시간으로 처리하기 위해 설계된 분산 메시징 플랫폼입니다. 일반적으로 대량의 이벤트 데이터를 빠르게 수집하고, 그 데이터를 다양한 애플리케이션이나 데이터베이스로 전송할 때 사용됩니다. 주요 특징  • 분산 시스템: Kafka는 다수의 서버에 걸쳐 클러스터링이 가능하여 높은 확장성과 내구성을 제공합니다. • 데이터 스트림 유지: Kafka는 기본적으로 메시지를 디스크에 저장하여 장기간 보존할 수 있습니다. 이는 데이터 스트림을 한 번에 소비하지 않고 여러 소비자가 개별적으로 필요한 시점에 데이터를 읽을 수 있게 합니다. • 이벤트 중심 아키텍처: 대규모 데이터 파이프라인 구축에 적합하며, 많은 애플리케이션에서 이벤트 중심 아키텍..

2024. 11. 8. 16:26

Microservices Architecture

Amazon EC2, SC3

Amazon EC2 (Elastic Compute Cloud) EC2는 AWS의 가상 서버(인스턴스) 서비스를 의미하며, 클라우드에서 컴퓨팅 리소스를 제공하여 애플리케이션을 실행할 수 있도록 돕습니다. 1. 기능 및 특징 • 스케일링: 사용자는 필요에 따라 인스턴스를 확장하거나 축소할 수 있습니다. 예를 들어, 트래픽이 증가하면 인스턴스를 늘리고, 트래픽이 줄어들면 다시 줄일 수 있습니다. • 다양한 인스턴스 유형: 사용자의 요구에 맞게 다양한 인스턴스 유형이 제공됩니다. CPU, 메모리, 네트워크 성능에 따라 최적화된 인스턴스를 선택할 수 있습니다. • 보안: VPC(가상 사설 클라우드)에서 인스턴스를 배포하여 네트워크를 격리하거나, 보안 그룹을 통해 인스턴스의 네트워크 접근을 제어할 수 있습니다. •..

2024. 11. 8. 16:17

Microservices Architecture

Kafka의 Source, Target, Topic, Partition

1. Source (소스) Source는 Kafka에 데이터를 전송하는 시작점으로, 다양한 애플리케이션이나 시스템이 Source 역할을 할 수 있습니다. Source는 Kafka에 데이터를 전송하기 위해 Producer API를 사용하여 특정 토픽에 데이터를 지속적으로 전송하게 됩니다. Source의 예시와 구성  • 애플리케이션 로그: 예를 들어 웹 애플리케이션에서 사용자 행동 데이터를 실시간으로 Kafka에 전송하여 로그를 수집합니다. • IoT 센서 데이터: IoT 장비들이 센서 데이터를 Kafka에 전송하여 실시간으로 모니터링할 수 있습니다. • 데이터베이스 변경 사항: 데이터베이스가 업데이트될 때마다 해당 변경 사항을 Kafka로 전송해 데이터베이스의 변경 사항을 여러 시스템에서 공유하도록 할 ..

2024. 11. 7. 10:28

Microservices Architecture

Kafka의 Lag와 Burrow

Kafka의 Lag와 Burrow는 Kafka 클러스터에서 메시지 소비 상태를 모니터링하고 최적화하는 데 중요한 개념입니다.  1. Kafka Lag Lag는 Consumer가 아직 읽지 못한 메시지 수를 의미합니다. Lag는 Consumer가 토픽의 최신 메시지에 얼마나 뒤쳐져 있는지 측정하는 지표로, Kafka에서 성능과 안정성을 모니터링하는 데 중요한 역할을 합니다. Lag 계산 방법 Kafka의 Lag는 토픽의 최신 오프셋과 Consumer가 마지막으로 커밋한 오프셋 간의 차이로 계산됩니다: • Lag = 최신 오프셋 - 커밋된 오프셋 • 최신 오프셋은 토픽 파티션의 마지막 메시지 위치를 의미하며, 커밋된 오프셋은 Consumer가 마지막으로 처리한 위치를 나타냅니다. Lag의 의미와 관리  • ..

2024. 11. 7. 10:21

Microservices Architecture

Kafka의 Broker, Replication, ISR (In-Sync Replica)

1. Kafka Broker **브로커(Broker)**는 Kafka 클러스터의 핵심 구성 요소로, 메시지를 저장하고 관리하며, 클라이언트(Producer, Consumer)와 통신하는 역할을 합니다. 주요 특징  • 메시지 저장 및 관리: 브로커는 메시지를 특정 토픽과 파티션에 저장합니다. 각 브로커는 독립적인 서버로 동작하며, 하나의 Kafka 클러스터에는 여러 개의 브로커가 존재할 수 있습니다. • 부하 분산: 여러 브로커가 함께 데이터 저장을 분담하여 성능을 최적화합니다. 클러스터의 리더 브로커가 메인 역할을 하며, 팔로워 브로커들이 레플리카를 유지합니다. • 클러스터 관리: 브로커는 Zookeeper를 통해 클러스터에 대한 메타데이터를 관리하고, 리더 선출 등의 작업을 진행합니다. 데이터 흐름 ..

2024. 11. 7. 10:19

Microservices Architecture

Kafka의 Producer와 Consumer

Kafka의 Producer와 Consumer는 Kafka의 핵심 구성 요소로, 각각 메시지를 생성하고 소비하는 역할을 합니다. 1. Kafka Producer Producer는 Kafka에서 메시지를 생성하고 특정 토픽으로 전송하는 역할을 합니다. 주요 특징  • 토픽 지정: 메시지를 전송할 때 특정 토픽을 지정하며, 해당 토픽이 존재하지 않으면 자동으로 생성됩니다. • 파티션: Kafka 토픽은 여러 파티션으로 나뉘어 데이터가 분산 저장되므로, Producer는 메시지를 특정 파티션으로 보내는 전략을 가집니다. • 파티션 전략: 메시지 키를 지정하여 특정 파티션에 메시지를 보낼 수 있고, 키가 없을 경우 라운드 로빈 방식으로 분배됩니다. • 부하 분산: 여러 파티션으로 데이터가 분산되기 때문에 소비자..

2024. 11. 7. 10:16

Microservices Architecture

JMS API

JMS API 프로그래밍 모델 JMS 애플리케이션의 기본 구성 요소는 다음과 같습니다:  1. 관리 객체: 연결 팩토리와 대상 2. 연결 (Connections) 3. 세션 (Sessions) 4. 메시지 프로듀서 (Message Producers) 5. 메시지 소비자 (Message Consumers) 6. 메시지 (Messages)  다음 섹션은 각 구성 요소를 간단히 설명하고 코드 예제를 통해 생성 및 사용 방법을 보여줍니다. JMS 관리 객체 (Administered Objects) JMS 애플리케이션의 두 가지 주요 관리 객체는 **대상(Destination)**과 **연결 팩토리(Connection Factory)**입니다. 이 객체들은 일반적으로 프로그래밍이 아닌 관리적 방식으로 유지 관리됩..

2024. 11. 6. 11:07

Spring Boot

Thymeleaf

Thymeleaf는 자바 기반의 서버 템플릿 엔진으로, HTML을 사용하여 서버 측에서 데이터를 렌더링하는 데 사용됩니다. Spring Boot와 함께 사용될 때는 특히 MVC(Model-View-Controller) 패턴에 적합하여 정적 HTML 파일에 동적인 데이터를 삽입해 클라이언트에게 전달하는 방식으로 웹 페이지를 생성합니다. Thymeleaf의 주요 특징  1. HTML 친화적: • Thymeleaf는 HTML 파일에서 직접 템플릿 엔진 기능을 추가할 수 있는 태그 속성(th:text, th:href 등)을 제공합니다. • HTML 표준을 유지하면서, 브라우저에서 직접 확인할 수 있어 디자이너와 개발자 간의 협업에 용이합니다. 2. 서버 사이드 렌더링: • 클라이언트가 요청을 보낼 때 서버가 H..

2024. 10. 31. 16:47

Spring Security

RFC6265

RFC6265는 HTTP 쿠키에 대한 표준 규격을 정의한 문서로, 쿠키의 생성, 저장, 삭제, 보안 설정 등에 대한 규칙을 제공합니다. HTTP 쿠키는 웹 애플리케이션에서 사용자의 세션 유지, 로그인 상태 관리, 사용자 맞춤형 경험 제공 등을 위해 활용됩니다. RFC6265는 특히 보안 강화를 위해 쿠키의 SameSite 속성을 도입하고, 다양한 보안 지침을 명시합니다. RFC6265의 주요 개념과 규칙 1. 쿠키의 기본 구조 RFC6265에 따르면 쿠키는 이름-값 쌍으로 저장되며, 다음과 같은 구성 요소를 가집니다:  • Name (이름): 쿠키의 이름을 설정합니다. • Value (값): 쿠키에 저장할 값을 설정합니다. • Domain (도메인): 쿠키를 사용할 수 있는 도메인을 지정합니다. 특정 도..

2024. 10. 31. 16:44

Spring Security

SameSite

SameSite는 쿠키의 보안 속성으로, 쿠키가 외부 사이트의 요청과 함께 브라우저로 전송되는 방식을 제어합니다. 이를 통해 CSRF(Cross-Site Request Forgery) 공격을 방지하는 데 도움을 줍니다. SameSite 속성에는 세 가지 옵션이 있으며, 각각의 옵션이 쿠키 전송을 제한하는 방식이 다릅니다. SameSite의 세 가지 옵션  1. SameSite=Strict 2. SameSite=Lax 3. SameSite=None 1. SameSite=Strict  • 동작: 엄격한 모드로, 쿠키가 외부 사이트에서 전송된 요청에는 절대 포함되지 않습니다. • 사용 예: 사용자가 직접 입력한 도메인에서만 쿠키가 전송되며, 링크나 외부 사이트에서 리디렉션되는 요청에는 쿠키가 포함되지 않습니다..

2024. 10. 31. 16:42

Spring Security

CORS(Cross-Origin Resource Sharing)의 Simple Request와 Non-Simple Request

CORS(Cross-Origin Resource Sharing)는 웹 페이지가 다른 도메인의 리소스에 접근할 때 보안을 위해 특정 규칙을 적용하는 방식입니다. 이때 요청은 Simple Request(단순 요청)과 Non-Simple Request(비단순 요청)으로 나뉩니다. 1. Simple Request (단순 요청) 단순 요청은 브라우저에서 서버에 사전 요청(preflight) 없이 바로 요청을 보낼 수 있는 CORS 요청 유형입니다. 사전 요청이 없기 때문에 네트워크 자원이 절약되고, 단순한 API 호출이나 기본 리소스 접근에 사용됩니다. Simple Request의 조건  1. 허용된 HTTP 메서드: • GET • POST • HEAD 2. 허용된 요청 헤더: • 추가적인 사용자 정의 헤더를 사..

2024. 10. 31. 16:27

Spring Security

Spring Security 인증 아키텍처

Spring Security 인증 아키텍처 이 글에서는 Spring Security의 인증 아키텍처를 다룰 것입니다. 아래 이미지는 Spring Security가 HTTP 요청을 인증하는 전체 과정을 보여줍니다. 각 컴포넌트가 어떤 역할을 수행하며 어떻게 상호작용하는지 단계별로 설명합니다.  인증 프로세스의 주요 구성 요소  1. Http Request (사용자 요청) • 사용자가 애플리케이션에 접근할 때 보낸 HTTP 요청입니다. 이 요청은 사용자 자격 증명(주로 사용자 이름과 비밀번호)을 포함할 수 있습니다. 2. AuthenticationFilter • AuthenticationFilter는 Spring Security의 필터 체인 중 하나로, HTTP 요청을 가로채고 자격 증명을 추출하여 인증을 ..

2024. 10. 31. 10:33

Spring Security

FilterOrderRegistration 클래스 구조와 역할

이 클래스의 주요 역할은 Spring Security 필터들이 올바른 순서로 실행되도록 각 필터의 순서를 지정하는 것입니다.@SuppressWarnings("serial")final class FilterOrderRegistration { private static final int INITIAL_ORDER = 100; private static final int ORDER_STEP = 100; private final Map filterToOrder = new HashMap(); FilterOrderRegistration() {Step order = new Step(INITIAL_ORDER, ORDER_STEP);put(DisableEncodeUrlFilter.class, order.next());pu..

2024. 10. 31. 10:14