PRDEN

Persistence framework for Spring Batch

prden — Sat, 12 Oct 2024 13:32:22 +0900

결론

• For maximum performance (bulk inserts/updates): Use JDBC Template.

• For a balance of performance and maintainability: Use MyBatis.

• For ease of development and maintainability, where performance is not the highest priority: Use JPA.

For bulk data insert and select in Spring Batch, the choice of persistence framework depends on your specific requirements, particularly focusing on performance, scalability, and ease of use. Here’s a comparison of three popular options:

1. JDBC Template:

• Performance: Highest performance among the three for bulk operations. Since it operates at a lower abstraction level and does not involve object-relational mapping (ORM), it is leaner and faster.

• Control: Provides the most control over SQL queries, allowing you to fully optimize batch inserts and selects with custom SQL and tuning.

• Batch Operations: Supports native batch operations (batchUpdate()), making it highly efficient for large-scale inserts.

• Trade-offs: Requires writing SQL manually, which increases development time and reduces maintainability compared to an ORM.

• Use Case: Best suited for performance-critical applications where raw performance and fine-grained SQL control are required.

Recommendation: Use JDBC Template if you need to handle very large data volumes and performance is a primary concern, especially for bulk inserts/updates/selects.

2. MyBatis:

• Performance: Good performance, but slightly lower than JDBC Template due to its semi-ORM nature. It strikes a balance between raw SQL and object mapping.

• Control: Offers more flexibility than JPA because you can still write custom SQL while benefiting from object mapping.

• Batch Operations: MyBatis also supports batch operations, allowing you to perform bulk inserts and updates efficiently.

• Trade-offs: Requires managing SQL queries but offers better maintainability compared to JDBC Template, thanks to its ability to map result sets to objects.

• Use Case: Ideal if you need a balance between performance and the convenience of mapping objects to SQL queries, but still want more control than an ORM like JPA provides.

Recommendation: Use MyBatis if you want more flexibility than JPA but need better performance and fine control over the SQL queries compared to JPA.

3. JPA (Hibernate):

• Performance: Generally lower performance compared to JDBC Template and MyBatis for bulk inserts/selects because of the overhead of ORM (managing entities, change tracking, etc.).

• Control: JPA abstracts SQL through entities, and while you can use native queries, it’s less flexible than the other two in terms of fine-tuning SQL performance.

• Batch Operations: JPA supports batch processing, but this is not as straightforward as with JDBC Template or MyBatis. You may need to fine-tune JPA settings (e.g., setting batch size, disabling cache/flush strategies) for efficient batch processing.

• Trade-offs: Offers the best developer productivity and maintainability due to automatic entity mapping but at the cost of raw performance, especially for bulk operations.

• Use Case: Best suited for applications where ease of development and maintainability are more important than raw performance.

Recommendation: Use JPA if you prefer a higher abstraction level and are willing to trade some performance for easier development and maintainability.

Conclusion:

• For maximum performance (bulk inserts/updates): Use JDBC Template.

• For a balance of performance and maintainability: Use MyBatis.

• For ease of development and maintainability, where performance is not the highest priority: Use JPA.

For Spring Batch, since bulk operations can have a significant impact on performance, JDBC Template or MyBatis would generally be the better choices over JPA for high-performance bulk operations.

JAVA의 Jar와 war의 차이점

prden — Sat, 12 Oct 2024 11:51:54 +0900

1. Jar와 war의 차이점

Jar SpringBoot의 내장톰켓 vs. War 외장톰켓, jsp 이용시

Maven 혹은 Gradle을 통해 내려받는 라이브러리들(External Libraries)은 CLASS 파일들이 묶인 jar파일로 구성되어 있는 것을 확인할 수 있다.

그리고 서비스 배포시에는 프로젝트를 WAR 포맷으로 묶어서 /webapps 등의 지정된 경로에 넣고 Tomcat 등의 웹 컨테이너(Web Container)를 이용하여 deploy하는 식으로 서비스를 많이 올리곤 한다.

Jar 과 war

.jar 확장자 파일에는 Class와 같은 Java 리소스와 속성 파일, 라이브러리 및 액세서리 파일이 포함되어 있다.

쉽게 JAVA 어플리케이션이 동작할 수 있도록 자바 프로젝트를 압축한 파일로 생각하면 된다. 실제로 JAR 파일은 플랫폼에 귀속되는 점만 제외하면 WIN ZIP파일과 동일한 구조이다.

JAR 파일은 원하는 구조로 구성이 가능하며 JDK(Java Development Kit)에 포함하고 있는 JRE(Java Runtime Environment)만 가지고도 실행이 가능하다.

원하는 구성을 할 수 있는 Jar 포맷과 달리 War은 WEB-INF 및 META-INF 디렉토리로 사전 정의 된 구조를 사용하며 WAR파일을 실행하려면 Tomcat, Weblogic, Websphere 등의 웹 서버 (WEB)또는 웹 컨테이너(WAS)가 필요하다.

WAR 파일도 JAVA의 JAR 옵션( java - jar)을 이용해 생성하는 JAR파일의 일종으로 웹어플리케이션 전체를 패키징하기 위한 JAR파일로 생각하면 된다.

https://ifuwanna.tistory.com/224

[Java] JAR WAR 차이점 및 특징 ( + EAR )

JAR (Java Archive) WAR (Web Application Archive) 모두 JAVA의 jar 툴을 이용하여 생성된 압축(아카이브) 파일이며 어플리케이션을 쉽게 배포하고 동작시킬 수 있도록 있도록 관련 파일(리소스, 속성파일 등).

ifuwanna.tistory.com

* 스프링부트에서의 Jar와 War

스프링부트 프로젝트를 새로 생성할 때, Jar(Java Archive) 또는 War(Web Application Archive) 로 패키징 방식을 선택할 수 있다.

Jar는 class 및 설정 파일들을 압축해서 만들어진 하나의 어플리케이션 혹은 라이브러리다.

War는 JSP나 Servlet 등 WAS 컨테이너 위에서 동작하게끔 빌드된 형태이다. 웹 어플리케이션을 어떻게 설정할 지에 대한 정의가 있는 web.xml 파일을 포함(반드시는 아님 Web Application Initailizer로 대체 가능하다.)

JAR파일에는 WAS가 내장되어 있다.( embedded tomcat을 jar에 내장해서, jar파일로도 빌드가 가능하다.)

따라서 기존 톰켓과 같은 컨테이너를 이용해야 했던 스프링보다 훨씬 간단하게 어플리케이션을 제작/배포할 수 있는 것입니다. 하지만 필요에 따라 외부 WAS를 이용해야할 경우도 생기는데, 이때는 WAR 파일로 패키징을 해야한다.

※ SpringBoot에서 War 로 배포하는 법 : https://prde.tistory.com/330

(출처 : https://mongsil1025.github.io/til/server/warjar/)

https://programmer93.tistory.com/40

JAR vs WAR 차이점 - 삽질중인 개발자

JAR & WAR java 기반의 application의 배포 형태이다. JAVA JAR TOOL을 이용하여 압축한 압축 파일이다. ( 즉, 둘이 같은 압축 형태 ) JAR와 WAR는 사용 목적이 다르다. JAR Java ARchive path 정보를 유지한 상태로 압

programmer93.tistory.com

https://hye0-log.tistory.com/27

[Spring Boot]배포 방법 비교 (JAR vs WAR)

스프링 부트의 장점 중 하나는 실행 가능한 JAR (Executable Jar)로 빌드하여 프로젝트를 바로 실행시킬 수 있다는 점이다. 실제로 스프링부트 관련 문서를 보다 보면 "Executable Jar"라는 단어를 많이 볼

hye0-log.tistory.com

2. 스프링부트에서의 Jar와 Plain Jar 파일 차이

1. batch-app-0.0.1-SNAPSHOT.jar:

This is likely the Spring Boot executable JAR that is created when you package your Spring Boot application. It typically contains:

• The compiled classes of your application.

• All the dependencies required to run the application.

• A manifest with a Main-Class attribute that allows the JAR to be directly executed with the java -jar command, making it a fat JAR (a JAR that includes all dependencies bundled).

This JAR is ready to be run as a self-contained application.

2. batch-app-0.0.1-SNAPSHOT-plain.jar:

This is likely a plain JAR file. A plain JAR:

• Contains only the compiled classes of your application, without dependencies.

• It is not executable, meaning it cannot be run directly using java -jar.

• Typically, this type of JAR is used when the dependencies are managed separately, like in a traditional Java environment where dependencies are provided by an application server or a custom classpath.

Key Differences:

• Executable JAR (batch-app-0.0.1-SNAPSHOT.jar): Contains everything (code + dependencies), can be run directly (java -jar).

• Plain JAR (batch-app-0.0.1-SNAPSHOT-plain.jar): Contains only your code, needs additional dependencies, and cannot be run directly.

jar, plain jar 파일 빌드시 파일 이름 변경 방법

jar {
    archiveBaseName.set("my-custom-plain-jar-name")
}

bootJar {
    archiveBaseName.set("my-custom-executable-jar-name")
}

Purpose of a Plain JAR File

1. Lightweight Packaging: Plain JAR files only contain your application’s classes without bundling external dependencies. This can be useful when you don’t want to include large dependencies in the JAR (e.g., when dependencies are already managed elsewhere, like in an application server).

2. Separation of Concerns: In enterprise environments, plain JARs are used when the infrastructure is already set up to manage and provide the dependencies. This is typical in environments like:

• Application Servers: These servers (e.g., Tomcat, JBoss, WebSphere) often manage dependencies and classpaths, so you only need to deploy the application JAR without its dependencies.

• Shared Libraries: If your project depends on common libraries that are shared across multiple applications, using a plain JAR ensures you don’t duplicate dependencies.

3. For Libraries or APIs: When you’re building a reusable library or API for other projects to consume, you usually create a plain JAR. Consumers of your library are expected to manage dependencies on their own.

4. Testing and Smaller Modules: Sometimes plain JARs are generated for smaller, non-executable modules in a larger system where each module is responsible for different functionality. You might not need an executable JAR for each part.

In short, plain JARs are useful when you have a structured environment that already handles classpath management and dependencies, or when you’re building reusable components or libraries.

3. Jar, palin Jar, War 차이

A plain JAR file and a WAR file (Web Application Archive) serve different purposes, even though both are forms of archives for Java applications. Here are the key differences and similarities between them:

1. Purpose:

• Plain JAR File:

• A JAR (Java ARchive) is typically used for standalone applications or libraries.

• It can contain Java class files, resources (like images or properties files), and manifest files.

• Plain JAR files specifically do not bundle dependencies or configuration to run the application directly (like a Spring Boot “fat JAR” does).

• WAR File:

• A WAR (Web Application Archive) is used for web applications.

• It is designed to be deployed in a Servlet container like Tomcat, Jetty, JBoss, etc.

• A WAR contains web-related resources like WEB-INF/, JSPs, servlets, HTML files, JavaScript, etc., along with the application’s classes and libraries.

2. Structure:

• Plain JAR File:

• Typically contains just your application’s .class files and resources.

• It may have a manifest file but doesn’t contain any web-specific configurations like web.xml.

• It does not bundle external dependencies unless it’s a “fat” or executable JAR.

• WAR File:

• Has a defined structure for web applications, including:

• WEB-INF/ directory for deployment descriptors (like web.xml), classes, and libraries (WEB-INF/lib).

• Static resources like HTML, JSP, CSS, JavaScript files in the root directory.

• Typically includes dependencies within WEB-INF/lib.

3. Deployment:

• Plain JAR File:

• Plain JAR files are not web-deployable. You run them using the java -cp command or by adding them to another application’s classpath.

• You cannot deploy a plain JAR directly into a servlet container (like Tomcat), unless you wrap it in a WAR or an executable JAR.

• WAR File:

• WAR files are specifically designed for web deployments and can be deployed in a servlet container or an application server.

• The servlet container manages the lifecycle and classloading of the WAR.

4. Main Class and Execution:

• Plain JAR File:

• Usually requires a Main-Class entry in its manifest if you want to run it as an application (via java -jar or java -cp).

• But it cannot be run directly as a web application.

• WAR File:

• Contains no Main-Class and isn’t run directly.

• Instead, it relies on the servlet container to load and execute the web application.

5. Use Cases:

• Plain JAR File:

• Used for standalone desktop or console applications.

• Can be a library used by other Java applications.

• WAR File:

• Used for web applications with dynamic web pages (servlets, JSPs, etc.).

• Deployable to servlet containers like Tomcat or Jetty.

4. JVM, JDK, JRE의 차이점

https://ko.strephonsays.com/what-is-the-difference-between-jdk-and-jre

# 컴파일러가 컴파일하고 JVM이 읽어서 OS에게 명령~

1) Java 컴파일러 : java 프로그램을 바이트코드라는 중간 코드로 변환 ->

2) JVM : Java Virtual Machine 으로 바이트 코드를 기계어 코드로 변환하는 추상 기계

( JVM은 플랫폼에 의존적이다. 즉 리눅스의 JVM과 윈도우의 JVM은 다르다. 단, 컴파일된 바이너리 코드는 어떤 JVM에서 도 동작시킬 수 있다. )

3) 소스코드는 CPU가 이해할 수 없고, 프로그래머만 이해 가능 ( Java Compiler가 소스코드 -> 바이트코드로 변환

JVM이 바이트 코드 기계어 코드로 변환 따라서 CPU가 프로그램의 주어진 명령에 따라 작업 실행

4) JRE : 자바 런타임 환경으로 JVM, Java 클래스 라이브러리 및 Java 응용 프로그램을 실행하는데 필요한 기타 파일의 조합이다. 따라서 JRE를 설치하면 Java 프로그램만 실행할 수 있다.(프로그램 개발은 불가능)

5) JDK : 자바 개발 킷트 : JRE + 기타 개발도구(컴파일러(javac), 아카이버(jar), 문서생성기(javadoc))로 구성됨.

https://wikidocs.net/257

A2 JVM, JRE, JDK의 차이

자바에서 사용하는 용어 중 혼동하기 쉬운 JVM, JRE, JDK에 대해서 정리해 보자. ### JVM JVM은 자바 가상머신(Java Virtual Machine)의 ...

wikidocs.net

https://m.blog.naver.com/duqrlwjddns1/221770110714

[Java] JDK? JRE? JVM?

자바를 공부하면서 헷갈리는 용어를 발견해 정리하고 넘어가고자 합니다. 설명에 앞서 Java의 철학은 다음...

blog.naver.com

Jenkins - spring batch

prden — Mon, 7 Oct 2024 22:45:59 +0900

1. Jenkins와 Spring Batch

1) Jenkins의 스케쥴링 크론탭

다중 잡의 병렬처리 : jar을 동일 포트에서 여러개 병렬로 돌린다면 포트 중복이 일어날텐데 ?
Setting server.port=0 effectively disables the HTTP listener in Spring Boot, which is generally unnecessary for Spring Batch jobs that run independently without a web interface.
• Since Spring Batch jobs typically don’t require an HTTP server, this is a safe way to avoid port collisions while running multiple batch jobs concurrently.
port = 0으로 할당하기

server.port=0

server.port=8081 (for one of the jobs, and different for the other if needed)

잡 내의 병렬처리 : 다중 스레드 스탭을 이용해 잡 나누기, 병렬 스텝을 통해 잡 나누기, 비동기 ItemProcessor/ItemWirter를 이용해 병렬 처리하기, 원격 청킹을 통해 Read -> RabitMQ -> Write, 파티셔닝을 통해 병렬처리하기

ifconfig 명령어 및 네트워크 인터페이스 카드

prden — Sun, 22 Sep 2024 14:58:59 +0900

1. ifconfig로 퍼블릭 아이피, 로컬 아이피

the ifconfig command does not display your public IP address. It only shows the local IP addresses assigned to your network interfaces, like the ones on your LAN (Local Area Network) or loopback interface.

Here’s a quick explanation of why:

1. Local IP addresses (Private IPs): These are the addresses you see in the ifconfig output, such as 192.168.x.x or 172.x.x.x. These are used within your local network and are not directly visible to the outside world. For example, 192.168.0.108 in your output is your local IP on the Ethernet interface.

2. Public IP address: This is the IP address assigned to your router (or network device) by your Internet Service Provider (ISP) for communication over the internet. It is not shown in ifconfig because ifconfig only shows the addresses of your machine’s interfaces on the internal network.

퍼블릭 아이피 확인

curl ifconfig.me

2. ifconfig 확인 - 네트워크 인터페이스 카드

1. br-a336ff40d8cd and br-b16b276dfbfa:

• These interfaces are bridge interfaces, typically created by Docker or similar virtualization tools. A bridge interface connects multiple network interfaces together, allowing communication between containers and the host.

• inet: Shows the IP address assigned to this bridge interface. For example, 172.19.0.1 and 172.18.0.1 are the IP addresses for br-a336ff40d8cd and br-b16b276dfbfa, respectively.

• ether: This represents the MAC (Media Access Control) address of the interface, a unique identifier for network interfaces used in Ethernet communications.

• These bridges are likely being used for networking between containers, with their IP ranges (172.x.x.x) often used in private internal network

the br-* interfaces in your ifconfig output are created by Docker or Docker Compose. These bridge interfaces are used by Docker to manage networking between containers and the host machine.

2. docker0:

• Another bridge interface, docker0 is the default Docker bridge. Docker uses this bridge to route container traffic from the host to the external network.

• inet: IP address assigned to this interface is 172.17.0.1, which is within Docker’s default subnet range.

• ether: The MAC address for this interface is 02:42:b3:90:07:28.

• Like the other bridges, this interface enables container networking.

3. enp3s0:

• This is likely the physical Ethernet network interface on your machine. It’s the actual hardware that connects to your local network (wired Ethernet connection).

• inet: The IP address 192.168.0.108 is the IP assigned to this interface by your router in the local network.

• inet6: This is the IPv6 address for this interface (fe80::4fd2:f37b:47b7:e95f), used for communication over IPv6 networks.

• ether: The MAC address 7c:10:c9:d3:1b:ee identifies this physical network interface card (NIC).

• The RX and TX fields show the received and transmitted packets, indicating network traffic passing through this NIC.

4. lo (Loopback interface):

• lo is the loopback interface. It is a special network interface used for local machine communication.

• inet: 127.0.0.1 is the loopback IP address (also known as “localhost”), used to communicate with services running on the same machine.

• inet6: ::1 is the loopback address for IPv6.

• Traffic sent to this interface only travels within your local machine and does not leave your device.

2-1) Loopback is why Loopback

The term “loopback” refers to a special network interface used to route traffic back to the same device that sent it. It is a logical network interface that allows the system to communicate with itself, commonly used for testing and local inter-process communication.

Why is it called “Loopback”?

The word “loopback” comes from the idea of “looping back” network traffic:

• “Loop”: A loop is a circular path, meaning the data goes out and comes right back.

• “Back”: Refers to the fact that the data is sent back to the same system, rather than being transmitted to another device over the network.

Essentially, the data sent to the loopback interface loops back to the machine itself, instead of leaving the machine.

Practical Uses of Loopback:

1. Local Communication: The loopback interface allows applications running on the same machine to communicate with each other using the networking stack without the need for a physical network connection. For example, web servers like Apache or Nginx can be accessed at 127.0.0.1 (localhost) to test locally without going over the network.

2. Testing: Developers often use the loopback interface to test network applications and services without involving external networks.

3. Localhost: The IP address 127.0.0.1 (for IPv4) or ::1 (for IPv6) is reserved for the loopback interface. It is commonly known as localhost, and any traffic sent to this address is routed back to the same machine.

Example:

When you ping 127.0.0.1 or localhost, the traffic is sent out and immediately returned to your system, demonstrating that the network stack is functioning correctly. It’s a quick way to test if the local network configuration is working.

Why It’s Special:

Unlike other network interfaces that connect to external networks, the loopback interface does not require any physical hardware and exists purely for internal communication within the machine. It ensures that the system can route data to itself without needing a real network card or external connection.

3. http://localhost VS. http:127.0.0.1

The issue where http://localhost doesn’t work while http://127.0.0.1 does, especially in browser testing modes (like mobile testing mode), is due to the differences between how localhost and 127.0.0.1 are resolved and handled by various systems and configurations.

Key Differences Between localhost and 127.0.0.1:

1. Name Resolution:

• localhost is a hostname that the operating system needs to resolve to an IP address (usually to 127.0.0.1 for IPv4 or ::1 for IPv6). This resolution is handled either by a system’s DNS resolver or through the hosts file (e.g., /etc/hosts on Linux and macOS or C:\Windows\System32\drivers\etc\hosts on Windows).

• 127.0.0.1 is the direct IP address of the loopback interface and doesn’t require name resolution.

2. Network Stack Handling:

• Some applications or network configurations treat localhost and 127.0.0.1 differently. localhost can sometimes be affected by DNS settings, browser behavior, or even firewall rules.

• Mobile testing modes (or virtual devices) in browsers might treat localhost as a device-specific name that resolves differently in a mobile or isolated environment.

Reasons localhost Might Not Work While 127.0.0.1 Does:

1. DNS or Hosts File Issues:

• The localhost name might not resolve properly due to a misconfigured hosts file or other name resolution issues.

• If localhost is missing or incorrectly mapped in the hosts file, it won’t resolve to 127.0.0.1.

2. IPv6 vs. IPv4:

• Modern systems might try to resolve localhost to the IPv6 address ::1 by default, but if your server is only listening on an IPv4 interface (127.0.0.1), it won’t work.

• 127.0.0.1 forces an IPv4 connection, while localhost could attempt either IPv6 (::1) or IPv4, depending on the configuration.

3. Browser Behavior in Testing Modes:

• When testing in mobile emulation mode, some browsers or virtual machines might treat localhost as a special name and may not map it correctly to 127.0.0.1. This can be due to isolation or containerization of the test environment.

• Mobile emulation modes may use different internal DNS settings that affect how localhost resolves compared to 127.0.0.1.

4. Proxy or Firewall Settings:

• If you’re using any proxies or firewalls, they might behave differently for localhost versus 127.0.0.1. For instance, localhost traffic might be blocked or rerouted through a proxy, while 127.0.0.1 goes directly to the loopback interface.

How to Fix or Investigate:

1. Check the Hosts File:

Ensure that localhost is correctly mapped to 127.0.0.1 in your system’s hosts file. For example:

127.0.0.1 localhost
::1       localhost

2. Force IPv4 in Your Application:

If you suspect IPv6 is causing the issue, ensure your application is bound to both IPv4 and IPv6, or specifically to 127.0.0.1.

3. Try Disabling Proxies:

If you’re using a browser with mobile testing mode, check if there are any proxy settings enabled that might treat localhost differently.

4. Use 127.0.0.1 Directly:

In cases where localhost doesn’t work and you need to test quickly, just use http://127.0.0.1 directly in your browser.

Summary:

• localhost might not work in certain scenarios because of DNS resolution issues, IPv6/IPv4 mismatches, or browser-specific handling in testing modes.

• Using 127.0.0.1 bypasses these issues since it is a direct IP address that doesn’t require name resolution and explicitly uses IPv4.

* DNS name resolution

- name resolution : 도메인 이름에 대응하는 IP 주소 찾아내는 작업

Capturing network requests

prden — Sat, 21 Sep 2024 22:16:21 +0900

Catching (or capturing) network requests to a server is often referred to as packet sniffing or network traffic analysis. This process can be used to monitor, inspect, and analyze the data packets being sent across a network, including requests to a specific server. Here’s a general overview of how to capture these requests and the tools you can use.

1. Using Wireshark (Packet Sniffing)

Wireshark is a popular open-source network protocol analyzer that allows you to capture and inspect data packets in real time. It’s widely used for troubleshooting, network analysis, and security auditing.

Steps to Capture Requests to a Server:

1. Install Wireshark: Download and install Wireshark on your machine from wireshark.org.

2. Start a Capture:

• Open Wireshark and select the network interface (e.g., Ethernet or Wi-Fi) you want to monitor.

• Start the capture by clicking the blue shark fin icon in the top-left corner.

3. Filter Traffic:

• If you want to capture requests to a specific server (e.g., example.com or its IP), you can set a filter to narrow down the traffic.

• Use the following filter syntax:

• To capture traffic to a specific IP address: ip.addr == <server_IP_address>

• To capture traffic on a specific port (e.g., port 80 for HTTP or port 443 for HTTPS): tcp.port == 80

• To capture HTTP requests:http.request

• For a specific protocol (e.g., HTTPS, DNS, FTP):

ssl || tls  # for HTTPS
dns         # for DNS traffic
ftp         # for FTP

• These filters help isolate the specific requests and responses to/from the server you are interested in.

4. Analyze the Packets:

• After stopping the capture, Wireshark will display all captured packets. You can inspect each packet to see the details, including:

• Source IP address

• Destination IP address

• Protocol used (TCP, UDP, HTTP, etc.)

• Request type (GET, POST, etc.)

• Payload data (for unencrypted requests)

• For encrypted traffic like HTTPS, you will see encrypted data unless you have access to the decryption keys (e.g., in a controlled environment or using an SSL proxy).

5. Save or Export Data:

• You can save captured traffic for later analysis or export specific packet data in various formats.

2. Using tcpdump (Command-Line Tool)

If you prefer a command-line tool, tcpdump is a powerful utility for capturing network packets. It’s commonly used on Linux and macOS.

Steps to Use tcpdump:

1. Install tcpdump (if not already installed):

Telnet vs. SSH

prden — Sat, 21 Sep 2024 20:57:30 +0900

1. Telnet (TELecommunication NETwork):

• Purpose: Telnet is used to access remote devices over a network by providing a command-line interface (CLI). It allows you to log in and execute commands on remote devices as if you were physically present.

• Security: Telnet sends all data, including login credentials and commands, in plain text. This means anyone who intercepts the traffic can read the information.

• Port: By default, Telnet operates over port 23.

• Encryption: No encryption is provided, making it insecure for transmitting sensitive information over the internet.

• Use Case: Telnet is now largely deprecated due to its lack of security. It may still be used in controlled or private networks where security is less of a concern, but it’s generally avoided for internet-facing applications.

2. SSH (Secure Shell):

• Purpose: SSH is used for secure remote login to a system over an untrusted network (e.g., the internet). Like Telnet, it allows you to execute commands on remote machines, but it does so securely.

• Security: SSH encrypts the session, including login credentials and data, making it much more secure than Telnet.

• Port: By default, SSH operates over port 22.

• Encryption: SSH uses strong encryption (e.g., RSA, DSA, or ECDSA) to secure the communication, making it safe to use even over the internet.

• Use Case: SSH is the preferred method for remote access in almost all modern systems due to its security features. It’s widely used for system administration, secure file transfers, and tunneling.

3. 그럼에도 Telnet을 사용하는 이유

- 그냥 구닥다리 시스템 or port 연결 테스트 정도

Despite Telnet’s well-known security issues, it is still used in certain situations, often due to its simplicity, legacy support, and specific use cases where security is less of a concern. Here are some reasons why developers or network administrators might still use Telnet:

1. Legacy Systems:

• Older Devices: Some older network devices, hardware, and embedded systems only support Telnet and do not have SSH capabilities. For example, older routers, switches, or industrial equipment may rely on Telnet for remote access.

• Compatibility: In environments where upgrading systems is costly or complex, organizations may continue to use Telnet because it’s the only supported protocol on those devices.

2. Closed or Private Networks:

• Low-Risk Environments: In some cases, Telnet is used within highly controlled or private networks where security risks are minimal (e.g., lab environments, closed local networks). If there’s no internet exposure, the lack of encryption may not be as critical.

• Testing Environments: In development or testing environments, where speed and ease of use are prioritized over security, Telnet might be chosen for basic connectivity checks or diagnostics.

3. Simple Connectivity Testing:

• Quick Diagnostics: Telnet is sometimes used for simple port connectivity tests. For example, it can quickly check if a specific port on a remote system is open, especially for troubleshooting purposes (e.g., firewall issues, network latency).

• Basic Troubleshooting: Some administrators use Telnet to troubleshoot services like web servers or mail servers. For example, Telnet can be used to test HTTP, SMTP, or FTP connections by establishing a raw connection and sending manual commands.

4. Lightweight and Easy:

• No Overhead: Telnet is lightweight, with no need for key exchange, encryption, or complex configurations. This can make it attractive in situations where performance or simplicity is prioritized, such as in real-time or resource-constrained environments.

5. Welfare or Health Checks (Like you suggested):

• Open-Check Usage: In some environments, Telnet can be used for basic health checks on devices or services. It allows quick access to verify that a service is running, especially if no critical data is being transmitted.

• Legacy Monitoring Tools: Some older monitoring or management tools may rely on Telnet for simple pings or to verify service availability without requiring modern protocols like SSH.

6. Educational Purposes:

• Learning Tool: Telnet can be used in educational settings to demonstrate the workings of basic network communication. It’s a simple way to introduce students to the concepts of command-line access, networking, and protocol behavior.

Why It Should Be Avoided in Most Cases:

Even though there are scenarios where Telnet is still used, it should generally be avoided, especially in production environments, for the following reasons:

• Security Risks: Telnet’s plain-text transmission makes it highly vulnerable to man-in-the-middle attacks, eavesdropping, and credential theft.

• No Encryption: Modern security standards demand encryption for remote access to prevent unauthorized access and data breaches.

• Compliance Issues: Many security standards (e.g., PCI-DSS, HIPAA) require the use of encrypted communication, which makes Telnet non-compliant in many regulated industries.

Alternatives for Specific Use Cases:

• For Legacy Devices: Some organizations set up VPNs or jump hosts to tunnel Telnet sessions securely.

• For Port Checking: Tools like nc (netcat) or SSH-based port-forwarding can provide similar port-checking functionality in a secure manner.

7장 HTTPS

prden — Sat, 21 Sep 2024 16:56:45 +0900

1. HTTP의 약점

1) 평문(암호화하지 않은) 통신이기 때문에 도청 가능

HTTP는 자신을 암호화하는 기능이 없기 때문에 통신 전체가 암호화되지 않는다. 즉, 평문으로 HTTP메시지를 보내게 된다. 이를 방지하기 위해 a. 통신 암호화(SSL이나 TLS이라는 다른 프로토콜을 조합해서 HTTP 통신 내용을 암호화할 수 있다.)나 b. 콘텐츠 암호화(콘텐츠 내용 자체를 암호화하는 방법)등을 이용할 수 있다.

2) 통신 상대를 확인하지 않기 때문에 위장 가능하다.

HTTP를 사용한 리퀘스트나 리스폰스에서는 통신 상대를 확인하지 않는다. 따라서 누구든지 리퀘스트를 보낼 수 있고 누구든지 리스폰스를 반환할 수 있다. 이를 보완하기 위해 상대를 확인하는 증명서의 기능을 하는 SSL을 활용할 수 있다. SSL은 암호화뿐만 아니라 상대를 확인하는 수단으로 증명서를 제공한다. 이 증명서는 제3 기관에 의해 발행되는 것이기 때문에 위조하는 것이 거의 불가능하다.

3) 완전성을 증명할 수 없기 때문에 변조 가능

HTTP가 완전성을 증명할 수 없다는 뜻은 만약 리퀘스트나 리스폰스가 발신된 후에 상대가 수신할 때까지의 사이에 변조되었다고 하더라도 이 사실을 알 수 없다는 것을 의미한다.

2. HTTPS( HTTP + 암호화 + 인증 + 완전성 보호 = HTTPS)

위와 같은 문제점을 해결하기 위해 HTTP에 암호화나 인증 등의 구조를 더한 것을 HTTPS라고 부른다.

HTTPS는 통신을 하는 소켓 부분을 SSl(SecureSocketLayer)이나 TLS(Transport LayerSecurity)라는 프로토콜로 대체하고 있다.

즉, HTTP는 SSL과 통신하고 SSL이 TCP와 통신한다. SSl이라는 껍질을 덮어쓴 HTTP가 HTTPS이다.

1) 공개 키 암호화 방식

암호화와 복호화에 하나의 키를 같이 사용하는 방식을 공통키 암호라고 부른다.

공통 키 암호의 딜레마로 나온 것이 두 개의 키를 사용하는 공개키 암호이다. 공개키 암호를 사용한 암호화는 암호를 보내는 측이 상대의 공개키를 사용해 암호화한다. 그리고 암호화된 정보를 받아들인 상대는 자신의 비밀키를 사용해 복호화를 실시한다.

2) HTTP는 하이브리드 암호 시스템

공개키 암호는 공통 키 암호에 비해 처리 속도가 늦다. HTTP는 공개키와 공통 키 암호의 양쪽 장점을 살릴 수 있도록 각각의 방식을 조합해서 통신한다. 키를 교환하는 곳에서는 공개키 암호를 사용하고 그 후의 통신에서 메시지를 교환하는 곳에서는 공통 키 암호를 사용한다.

3) 공개키가 정확한지 아닌지 증명하는 증명서

어떤 서버와 공개키 암호를 사용해서 통신을 하려고 할 때 공개키가 본래 의도한 서버에서 발행한 공개키인지 확신할 수가 없다. 이를 위해 제3기 관인 인증기관을 이용해 안전성을 확보한다. (공개키 인증서)

HTTPS에서는 클라이언트 증명서도 이용할 수 있다. 클라이언트 증명서를 이용해 서버 증명서와 같이 통신하고 있는 상대가 의도한 클라이언트인 것을 증명하는 클라이언트 인증을 할 수 있다. 그러나 비용상의 이유로 은행 인터넷 뱅킹과 같은 곳에서만 사용된다.

3. 항상 HTTPS를 사용하지 않는이유?

SSL 통신이 지연되는 이유에는 두 가지가 있다. 하나는 통신 속도가 떨어지는 것과 다른 하나는 CPU나 메모리 등의 리소스를 다량으로 소비하며 처리가 느려지는 것이다. 네트워크 부하는 HTTP를 사용하는 경우에 비해 2배에서 100배 정도 느려질 수 있다. TCP 접속과 HTTP 리퀘스트, 리스폰스 이외에 SSL에 필요한 통신이 추가되어 처리해야 할 통신이 증가하기 때문이다.

즉, 항상 HTTPS를 사용하지 않는 이유는 암호화 통신은 CPU와 메모리 등 리소스를 많이 필요로 하기 때문이다. 특히 액세스가 많은 웹 사이트 등에서 암호화를 하면 그 부하가 상당하기 때문에 암호화를 사용하는 경우에는 모든 콘텐츠를 암호화하는 것이 아니라 숨겨야 할 정보만 암호화하면서 리소스를 절약한다. 추가적으로 HTTPS를 사용하기 위해서 증명서가 필요하지만, 이를 사용하기 위해서 구매해야 한다. 이 비용 또한 상당하기 때문에 HTTP만 선택하는 경우도 있다.

4. 대칭키 암호화와 비대칭키 암호화

대칭키 암호화
- 클라이언트와 서버가 동일한 키를 사용해 암/복호화 진행
- 키가 노출되면 매우 위험, 연산 속도가 빠름
비대칭키 암호화
- 1개의 쌍으로 구성된 공개키와 개인키를 암호화/복호화 하는데 사용함
- 키가 노출되어도 비교적 안전하지만 연산 속도가 느림.

5. Pem file의 역할 SSL/TLS

In the context of SSL/TLS certificates, .pem files are typically used to store the SSL certificate and the associated private key. Let’s break down the role of each file in your example:

1. abc.com_20240610A2C12.crt.pem (Certificate file):

• This file contains the public SSL certificate for your domain (abc.com in this case).

• The certificate is used by clients (e.g., browsers) to establish a secure connection with the server, ensuring that the server is who it claims to be. It may include information such as the domain name, the issuing Certificate Authority (CA), the validity period, and the public key.

• The certificate is presented to clients during the SSL/TLS handshake to verify the server’s identity.

2. abc.com_20240610A2C12.key.pem (Private key file):

• This file contains the private key associated with the public SSL certificate.

• The private key is used by the server to decrypt the encrypted data sent by clients. It also helps in signing data during the SSL handshake, ensuring that the server holds the private key corresponding to the public key in the certificate.

• This key is highly sensitive and must be kept secure because anyone with access to it can impersonate the server.

How They Work Together:

• When a client (e.g., a web browser) attempts to connect to your server, the server sends the public certificate (.crt.pem) to the client.

• The client uses the public key from the certificate to encrypt data and send it back to the server.

• The server uses its private key (stored in the .key.pem file) to decrypt this data.

• The private key is never shared, while the certificate (public key) is sent to clients.

Both files are essential for enabling SSL/TLS on a server: the certificate file proves the server’s identity, and the private key enables encrypted communication.

6. AES-256, SHA-256, BCrypt, 공개키(비대칭키), 대칭키

1) Hashing의 의미

Hashing is the process of taking an input (or “message”) and generating a fixed-size string of characters, which is typically a “digest” that represents the original data. Hashing is commonly used in computer science for various purposes, such as verifying data integrity, storing passwords, and enabling efficient data retrieval.

Key Characteristics of Hashing:

1. Fixed-Length Output:

• Regardless of the size of the input data, the hash function produces a fixed-length output. For example, SHA-256 always generates a 256-bit (32-byte) hash value, even if the input is one byte or one gigabyte.

2. Deterministic:

• The same input will always produce the same hash output. This consistency is crucial for uses like verifying data integrity.

3. One-Way Function:

• Hash functions are designed to be one-way, meaning it’s practically impossible to reverse the process and determine the original input from the hash. This property makes hashing useful for things like storing passwords securely.

4. Avalanche Effect:

• A small change in the input results in a significantly different hash output. This ensures that even similar inputs generate very different hashes, which is vital for security purposes.

5. Collision Resistance:

• It’s difficult (though not impossible) to find two different inputs that produce the same hash value. This property, called collision resistance, is essential for maintaining the uniqueness of hashes.

Common Uses of Hashing:

1. Data Integrity Verification:

• Hashes are used to verify that data hasn’t been altered. For example, when you download a file, its hash is often provided by the source so you can check if the file was modified or corrupted during transfer.

2. Password Storage:

• Hashing is used to securely store passwords. Instead of storing plain-text passwords in a database, systems store hashed passwords. When a user logs in, the system hashes the entered password and compares it to the stored hash.

3. Digital Signatures:

• Hashing plays a crucial role in digital signatures. A document’s hash is encrypted with a private key to generate a digital signature, ensuring both the document’s integrity and the authenticity of the signer.

4. Hash Tables and Data Structures:

• Hashing is also used in data structures like hash tables, where it helps in quickly retrieving data by mapping input keys to specific locations in memory.

Hashing vs. Encryption:

• Hashing is a one-way process, meaning you cannot recover the original input from the hash. It’s typically used for integrity checks and securing sensitive data like passwords.

• Encryption, on the other hand, is reversible. Data is transformed using an encryption key, and the original data can be decrypted using a decryption key.

Common Hashing Algorithms:

• SHA-256 (Secure Hash Algorithm)

• MD5 (Message Digest Algorithm 5)

• SHA-1 (Secure Hash Algorithm 1)

• BCrypt (designed for password hashing, with salting and cost factor features)

2) BCrypt

BCrypt is also a hashing algorithm, but it is specifically designed for secure password hashing and differs in key ways from general-purpose hashing algorithms like SHA-256. Here’s a breakdown of BCrypt and its purpose:

What is BCrypt?

• BCrypt is a cryptographic hash function designed for securely hashing passwords. It is based on the Blowfish cipher and was created with the goal of being slow and computationally expensive, making it much harder for attackers to perform brute force or dictionary attacks.

How BCrypt Differs from Algorithms Like SHA-256:

1. Purpose:

• SHA-256 and other cryptographic hash functions (e.g., MD5, SHA-1) are designed for general data integrity verification, not specifically for passwords.

• BCrypt is purpose-built for password hashing. It’s designed to make brute-force attacks much more difficult by being deliberately slow.

2. Key Features of BCrypt:

• Adaptive Cost Factor: BCrypt allows for a configurable “work factor,” which makes the hash computation slower. As computing power increases over time, you can increase the cost factor to ensure that password hashing remains computationally expensive.

• Salting: BCrypt automatically adds a unique salt (random value) to each password before hashing, which helps defend against rainbow table attacks. Even if two users have the same password, their BCrypt hashes will be different due to the unique salt.

• Slowness: By being slower than traditional hash functions like SHA-256, BCrypt is more resistant to brute-force attacks, where attackers try many possible passwords to guess the correct one.

3. Password Hashing vs. General Hashing:

• General Hashing (SHA-256): Primarily used for data integrity checks, digital signatures, and other purposes where speed is important. It’s fast and deterministic but not designed to be slow or handle the specific security needs of password storage.

• Password Hashing (BCrypt): BCrypt is designed to be slow and resistant to attacks targeting passwords. The added cost factor and salting mechanisms make it more secure for password storage.

Why BCrypt is Preferred for Password Hashing:

• Slows Down Attackers: BCrypt is computationally expensive, meaning that brute-force attempts to guess passwords will take significantly longer. This makes it much more secure than using fast hash functions like SHA-256 for passwords.

• Built-in Salting: Each password hash generated with BCrypt contains a random salt, preventing attackers from using precomputed hash databases (rainbow tables) to crack passwords.

Conclusion:

Yes, BCrypt is a hashing algorithm, but it is specifically designed for securely hashing passwords. It includes features like salting, adjustable cost, and deliberate slowness to provide stronger protection against password-cracking attacks. It is commonly recommended for password storage, whereas general-purpose algorithms like SHA-256 are better suited for data integrity checks and cryptographic applications.

3) Hashing 알고리즘 적용 된 값에서 평문 끄집어 낼 수 있나

Why You Can’t Reverse a Hash:

1. One-way Function: Hash functions like SHA-256 (which your example hash appears to be from) are designed to be one-way functions. This means that once data is hashed, it cannot be reversed to obtain the original input. The process is non-reversible by design.

2. Collision Resistance: Although theoretically possible, finding two different inputs that generate the same hash (called a collision) is extremely difficult with strong hash functions like SHA-256 due to their mathematical complexity.

3. Preimage Resistance: Given a hash output, it is computationally infeasible to find any input that produces that hash. In other words, starting with a hash like 3a7bd3e2360a3d80af0a359baf9be82678a4a01a8aae4c6f326f6ffb16c25b23, there’s no efficient way to determine what input (plain text) produced it.

Methods People Might Try:

• Brute Force Attack: One could theoretically try every possible combination of input text, hash it, and compare the result with the given hash until they find a match. However, if the original text was sufficiently complex (long, containing various characters), this would take an infeasible amount of time, especially for strong hashing algorithms like SHA-256.

• Rainbow Tables: These are precomputed tables of common inputs and their corresponding hash values. However, modern security practices use techniques like salting (adding random data to the input before hashing) to make rainbow tables ineffective.

4) AES-256 = 대칭키 암호화 알고리즘

AES-256 (Advanced Encryption Standard with a 256-bit key) is not a public key encryption method. It is a symmetric key encryption algorithm, meaning the same key is used for both encryption and decryption of data.

Key Differences Between Symmetric and Public-Key (Asymmetric) Encryption:

1. Symmetric Encryption (like AES-256):

• Same key is used for both encryption and decryption.

• The key must be securely shared between the parties.

• It’s faster and efficient for encrypting large amounts of data.

• Example algorithms: AES, DES, RC4.

2. Asymmetric (Public-Key) Encryption:

• Two keys are used: one for encryption (public key) and one for decryption (private key).

• The public key can be shared openly, but the private key is kept secret.

• Asymmetric encryption is generally slower and used for smaller data, such as encrypting the symmetric key (for hybrid encryption systems).

• Example algorithms: RSA, ECC (Elliptic Curve Cryptography), DSA.

AES-256 Role:

• AES-256 is often used in combination with asymmetric encryption in a hybrid encryption system. For example, the symmetric AES key might be encrypted using a public-key algorithm like RSA, while AES-256 handles the actual data encryption due to its speed.

In short, AES-256 is a symmetric encryption method, not a public-key (asymmetric) one.

NoSQL MongoDB

prden — Wed, 18 Sep 2024 17:15:17 +0900

1. 데이터 모델링과 인덱싱

1) 컬렉션 사이의 관계

객체 내부에 또 다른 객체를 두어 배열 형식으로 임베디드 방식으로 관리할지 vs. RDB 처럼 FK를 두어서 레퍼런스 방식으로 관리할지.

장단점 p270(맛있는 Mongo DB)

In MongoDB, when modeling a “Catalog” database (or any related schema design), the decision between embedding and referencing depends on the specific use case and the nature of your data. Here’s an overview of when to use each approach:

1. Embedding

In this approach, related data is stored within the same document as nested sub-documents. This method is often referred to as denormalization.

When to Use:

• One-to-few relationships: When the related data is small and unlikely to grow significantly.

• Read-heavy operations: Embedding can improve read performance since all data is retrieved in a single query.

• Data that’s tightly coupled: If the embedded data will always be retrieved and updated together with the parent document.

• Low update frequency: Embedded documents are best when you don’t frequently need to update individual pieces of the embedded data.

{
  "_id": 1,
  "name": "Product 1",
  "category": {
    "id": 101,
    "name": "Electronics"
  }
}

In this example, the category is embedded directly within the product document.

Pros of Embedding:

• Faster reads: All related data is in one place.

• Atomic updates: Modifying a document updates both the main document and its embedded documents at once.

Cons:

• Document size: MongoDB has a document size limit of 16MB. If embedded data grows too large, you might hit this limit.

• Duplication: In cases where the embedded data (like categories) is reused across multiple documents, changes in one embedded sub-document might require updating multiple parent documents.

2. Referencing

In this approach, documents reference each other by storing the ObjectId or some unique identifier of the related document. This method is akin to normalization in relational databases.

When to Use:

• One-to-many or many-to-many relationships: When the related data can grow indefinitely or if you need flexibility.

• Write-heavy operations: If you need to update the related data frequently, keeping it in a separate document avoids overwriting large parent documents.

• Data that’s loosely coupled: If the related data is only occasionally needed or can change independently from the main document.

• Avoiding duplication: If the same related data (e.g., categories) is used across many parent documents.

Example:

Products collection:
{
  "_id": 1,
  "name": "Product 1",
  "categoryId": 101
}

Categories collection:
{
  "_id": 101,
  "name": "Electronics"
}

Here, the product document references the category by categoryId.

Pros of Referencing:

• Scalability: Since referenced data is in a separate document, you avoid the document size limit and can scale your collections independently.

• Data consistency: Updates to the referenced document (like a category) are reflected across all related documents.

Cons:

• Slower reads: You might need to perform multiple queries (or a $lookup operation) to fetch related documents.

• Data fragmentation: If documents are spread across different collections, maintaining consistency in relationships can be more complex.

Best Practices

• Embed when data is tightly coupled and grows moderately: For example, embedding category data into products makes sense if categories rarely change and you always retrieve the product with its category.

• Reference when data is loosely coupled or grows large: If categories are shared among many products, and categories can be updated independently, referencing will prevent duplication and large document sizes.

• Hybrid approach: In some cases, you can combine both. For example, you can embed frequently accessed, immutable fields of a related document (like the name of the category) and reference less frequently used or mutable fields.

Example of Hybrid Approach:

{
  "_id": 1,
  "name": "Product 1",
  "category": {
    "name": "Electronics"
  },
  "categoryId": 101
}

In this case, you store the category name directly for quick reads but also reference the categoryId for updates or deeper queries.

Conclusion:

• Embedding is best when you have tight coupling and frequent read operations with little need for updates to the embedded data.

• Referencing is better for flexible, loosely coupled relationships, especially when data grows or is frequently updated.

• Consider a hybrid approach for balancing read performance with flexibility, especially in cases of shared or frequently updated data.

By understanding your data access patterns, frequency of updates, and the relationship between the entities, you can choose the best approach for your catalog database modeling.

Each Document within a collection has a 16MB size limit.

in MongoDB, each document within a collection has a 16MB size limit. This means that the total size of a single document, including its embedded data and subdocuments, cannot exceed 16MB.

Key Points:

1. Document Size: Each individual document in MongoDB is capped at 16MB. This includes the entire document’s data, including any nested or embedded subdocuments.

2. Collection Size: There’s no explicit size limit on an entire collection, which can grow to multiple terabytes. The limit applies only at the document level.

3. Workarounds: If you need to store larger amounts of data:

• Referencing: Break the data into smaller documents and use references between them.

• GridFS: For very large files (e.g., large media files), you can use MongoDB’s GridFS, which allows you to store and retrieve files larger than 16MB by splitting them into smaller chunks.

If you embed too much data in a document and exceed the 16MB limit, MongoDB will throw an error when you try to insert or update that document. Therefore, it’s essential to monitor document sizes and use referencing or alternative strategies when necessary.

2) 인덱싱

2. 복제

3. 샤딩

세션 클러스터링

prden — Sun, 15 Sep 2024 14:53:43 +0900

1. 세션 클러스터링

Session clustering in the Spring Framework allows session data to be shared and synchronized across multiple application server instances in a clustered environment. This ensures that a user’s session is maintained regardless of which server in the cluster handles their request, enabling session failover and load balancing.

Why Use Session Clustering?

In a distributed system, requests from the same user may be routed to different servers. Without session clustering, if a user’s session is stored in memory on one server, and the next request goes to another server, the session data would be lost. To solve this, session clustering ensures that session data is shared across all servers.

How Session Clustering Works

In Spring, you can implement session clustering using external storage to share session data between nodes, ensuring that user sessions are available regardless of the node that handles the request.

Here are a few common approaches to session clustering in the Spring Framework:

1. Using an External Session Store (e.g., Redis, Hazelcast)

2. Using Spring Session (Redis or JDBC Store)

3. Tomcat/Jetty Session Replication

I’ll focus on Spring Session with Redis, which is a popular solution for session clustering in Spring Boot applications.

Example: Spring Session Clustering with Redis

Redis is an in-memory key-value store that is commonly used for sharing session data across a cluster of servers.

Step-by-Step Implementation of Session Clustering Using Redis in Spring Boot:

1. Add Dependencies

To use Spring Session with Redis, you’ll need to add the following dependencies to your pom.xml:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.session</groupId>
    <artifactId>spring-session-data-redis</artifactId>
</dependency>

2. Configure Redis

In your application.properties or application.yml, configure Redis as the session store.

For application.properties:

# Redis configuration
spring.redis.host=localhost
spring.redis.port=6379
spring.redis.password=your_redis_password

# Session configuration
spring.session.store-type=redis
spring.session.timeout=1800s  # Session timeout (30 minutes)

spring:
  redis:
    host: localhost
    port: 6379
    password: your_redis_password

  session:
    store-type: redis
    timeout: 1800s  # 30 minutes session timeout

In your main Spring Boot application class, you can enable Redis-backed session management by adding the @EnableRedisHttpSession annotation:

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.session.data.redis.config.annotation.web.http.EnableRedisHttpSession;

@SpringBootApplication
@EnableRedisHttpSession
public class SessionClusteringApplication {
    public static void main(String[] args) {
        SpringApplication.run(SessionClusteringApplication.class, args);
    }
}

his annotation automatically configures Redis as the session store.

4. Optional: Configure Redis Connection Factory

You may also define a custom Redis connection factory in a configuration class, which allows you to control aspects like connection pool size or timeout.

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.redis.connection.RedisConnectionFactory;
import org.springframework.data.redis.connection.lettuce.LettuceConnectionFactory;

@Configuration
public class RedisConfig {
    
    @Bean
    public RedisConnectionFactory redisConnectionFactory() {
        // You can configure Redis connection properties here
        return new LettuceConnectionFactory("localhost", 6379);
    }
}

5. Handling Sessions in Controllers

Spring automatically handles session management for you. For example, you can store and retrieve session attributes in your controllers as usual:

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

import javax.servlet.http.HttpSession;

@RestController
public class SessionController {
    
    @GetMapping("/session")
    public String sessionExample(HttpSession session) {
        session.setAttribute("name", "John Doe");
        return "Session ID: " + session.getId() + " | Name: " + session.getAttribute("name");
    }
}

When requests hit different nodes in the cluster, Spring will still retrieve the session data from Redis, ensuring that the session remains consistent across all nodes.

6. Start Multiple Application Instances

Now you can start multiple instances of your Spring Boot application, and all of them will share session data using Redis.

You can start your application with different ports like this:

# Start the first instance on port 8080
java -jar -Dserver.port=8080 session-clustering.jar

# Start the second instance on port 8081
java -jar -Dserver.port=8081 session-clustering.jar

7. Test the Session Clustering

• Access the first instance at http://localhost:8080/session. This will create a session and store the session ID in Redis.

• Then, access the second instance at http://localhost:8081/session. You should still see the session data retrieved from Redis, even though you hit a different server instance.

How Spring Session with Redis Works

• Session Storage in Redis: When a user logs in or interacts with the system, their session data is saved in Redis. This is achieved through a key-value pair, where the key is the session ID and the value is the session data.

• Session Synchronization: Each time a new request comes in, the session ID is sent in the HTTP request (usually via cookies). The server retrieves the session data from Redis, regardless of which node in the cluster the request goes to. This allows all instances in the cluster to have a consistent view of the user’s session.

• Failover: If one server fails, the user’s session is not lost because it’s stored in Redis. The user’s session will continue to work on other nodes in the cluster.

Alternative Methods for Session Clustering

1. Hazelcast: Hazelcast is another in-memory data grid used for sharing session data across a cluster.

• You can use Spring Session with Hazelcast as an alternative to Redis.

• Similar setup to Redis, just different dependencies and configuration.

2. JDBC-Based Session Storage: Instead of Redis, you can store sessions in a relational database using Spring Session with JDBC. The sessions are stored in a database, and each server in the cluster can access the same session data.

3. Tomcat Session Replication: If you’re using Tomcat as the servlet container, it has built-in support for session replication. You can configure Tomcat to replicate sessions across all nodes in the cluster using multicast or a dedicated session manager.

Advantages of Spring Session Clustering with Redis

• Scalability: Redis is extremely fast and scalable. It handles session storage with high throughput, which is ideal for applications that need to scale horizontally across many nodes.

• Fault Tolerance: By using Redis as a distributed session store, user sessions are not lost when a server fails.

• Stateless Servers: With Redis handling session data, your servers become stateless, which simplifies scaling and reduces server resource usage.

Conclusion

Session clustering in the Spring Framework can be easily achieved using Spring Session with Redis, allowing multiple application instances to share session data. This approach helps ensure that user sessions are consistent, even when requests are routed to different servers in a clustered environment. The Redis-backed session store is a common solution due to its speed and scalability, but alternatives like Hazelcast or JDBC can also be used depending on your application’s needs.

https://kku-jun.tistory.com/44

세션 클러스터링이란?

세션 클러스터링이란? 세션 클러스터링이란 WAS가 2대 이상 설치가 되어있을 경우 세션을 공유하여 대체된 WAS에도 동일한 세션을 관리하는 것을 의미합니다. 예를 들어 L4 스위치가 사용자를 접

kku-jun.tistory.com

https://junshock5.tistory.com/91

세션 클러스터링 이란?

세션 클러스터링 이란? 두 대 이상의 WAS를 이용하는 경우 로드 밸런싱(대용량 트래픽 처리시 분산시키는 것), 또는 failover(장애 발생시 예비시스템으로 자동전환, 서버 이중화), auto scaling(AWS에서

junshock5.tistory.com

2. JBoss Infinispan

https://jsonobject.tistory.com/441

Spring Boot, JBoss Infinispan을 이용한 분산 캐시 적용하기

개요 마이크로서비스의 유행과 함께 NoSQL 저장소의 사용이 필수인 시대가 되었다. 이제는 전통적인 RDBMS 저장소 만으로는 복잡한 비즈니스 로직과 병렬적인 빠른 동시성 처리 요구를 수용하기

jsonobject.tistory.com

3. 로그인 인증방식 Session VS. JWT

우분투 Wake on Lan 설정

prden — Wed, 11 Sep 2024 21:35:26 +0900

1. BIOS에서 Wake On Lan 설정 Enable

2. ethtool, net-tools, wakeonlan 설치하기

sudo apt-get install net-tools ethtool wakeonlan

3. ifconfig 네트워크 카드 이름 확인 후

sudo ethtool -s 네트워크카드이름 wol g
sudo ethtool 네트워크카드 이름

Wake-on : g 확인

4. 설정 추가

sudo vi /etc/network/interfaces

post-up /sbin/ethtool -s 네트워크카드이름 wol g
post-down /sbin/ethtool -s 네트워크카드이름 wol g

5. 서비스 설정

sudo vi /etc/systemd/system/wol.service

[Unit]
Description=Configure Wake-up on LAN

[Service]
Type=oneshot
ExecStart=/sbin/ethtool -s 인터페이스명 wol g

[Install]
WantedBy=basic.target

https://velog.io/@deogicorgi/우분투Ubuntu-홈서버-구축기1-WOL-설정