다메카솔

안녕하세요. 다메카솔🐿️ 입니다.

지난 4.17일 PostgreSQL 100% 활용법 밋업에 참석하였습니다.

한동안 공부에 운동에 정신이 없어서 컨퍼런스 관련 정보를 찾아보지 못하고 있었는데, 갑자기 생각나서 찾아보니 평소에자주 사용하는 PostgreSQL 관련 밋업이 있어 바로 신청하였습니다.

신청하면서 개발자 입장에서 데이터베이스로 PostgreSQL와 mysql을 모두 사용해본 경험이 있지만, 둘의 차이가 뭘까? 생각했을 때 그냥 sql만 작성하고 제품 이름만 다르다, postgreSQL은 ORM에 친화적이다 정도로 아무것도 모르고 있다는 사실에 좀 충격받아서 기대를 가지고 참석하였습니다. 

https://www.meetup.com/pgmeetupseoul/events/300140824/

아래는 밋업 정보입니다.

밋업 정보

[📣밋업 안내📣]

• 일시
  2024년 4월 17일 수요일 18:30~20:30 (2시간)
• 모집 일정
  2024년 4월 1일 ~ 4월 16일 (선착순)
• 장소
  삼성역 섬유센터빌딩 2층 컨퍼런스홀 C3룸 (서울 강남구 테헤란로 518)
• 식사
  샌드위치와 생수 제공
• 후원
  비트나인
• 참석비용
  무료

[🎁밋업 참석자 혜택🎁]

• 참석자 혜택 1
  어디서도 들어볼 수 없는 생생한 PG 이야기를 실무자가 직접 들려드립니다.
• 참석자 혜택 2
  현장 추첨을 통해 따뜻한 신상 도서를 선물로 드립니다.
  참석자 혜택 3
  추후 PostgreSQL Meetup Seoul 운영진으로 활동할 수 있는 기회를 드립니다.

[⏰밋업 시간표⏰]

• 18:30 밋업 등록 및 식사
• 18:50 환영인사
• 18:55 보너스 세션: PostgreSQL Community 참여/기여 방법
• 19:05 세션1: 실무에 적용하는 PostgreSQL 아키텍쳐 구성 방법
• 19:35 세션2: PG Extension: 신개념 데이터 구조 저장: Apache AGE
• 20:05 네트워킹
• 20:30 마무리

아는 지인과 함께 세션을 등록하여 도착하였는데, 조금 일찍 도착하였음에도 사람들이 줄을 서 있었습니다.

앞에 계신 분은 함께 참석한 개발자분인데 초상권을 위해 모자이크 처리 하였습니다.

약간 사건 관계자 인터뷰 모자이크 느낌이 나긴 하지만 그림판으로 최선을 다했습니다...

줄을 서서 밋업 신청 확인을 하는데, 신청이 제대로 안되어있어 현장 신청을 하느라 조금 입장이 늦어졌습니다.

사진은 못찍었지만 맛있는 샌드위치랑 물을 주셔서 간단히 저녁 대용으로 먹고 세션을 기다렸습니다.

본격적으로 세션이 시작되기 전에, 오픈소스인 포스트그레 커뮤니티 대한 세션이 있었는데, 어떻게 기여할 수 있는지 절차를 설명해주시는 것을 보고, 항상 마음속으로만 있었던 많이 사용하는 오픈소스에 참여하여 개발자 생태계에 기여해보고 싶다는 생각이 다시 생기기 시작하였습니다.

항상 구체적인 방법이 너무 막막하였는데, 자세한 절차나 사례들을 설명해 주시니 한번 도전해볼까? 라는 생각이 들어 정보를 더 찾아봐야 될 것 같습니다.

세션에 관한 자세한 내용은 생략하고 두 세션 모두 열정적으로 발표해주셔서 시간가는 줄 모르고 들었습니다.

위 사진에 있는 좌석이 거의 만석이 될 정도로 많은 분들이 참석해주셨고, 세션 중간중간에 문답 시간에도 어려운 질문에도 상세하게 답변을 해주셔서 다음에 또 밋업이 있다면 참석할 예정입니다. 

안녕하세요. 다메카솔입니다. 🐿️

현재 회사에서 ISMS-P 인증을 준비하고 있습니다.

이를 위해서 데이터베이스에 저장되는 정보 중에 민감정보 암호화 작업이 어떻게 되는지 파악하고, 암호화 알고리즘이 얼마나 안전한지 점검하는 업무를 수행하였습니다.

이때 점검한 암호화 알고리즘의 종류에 따른 차이점에 대해 찾아보았습니다.

암호화에는 단방향 암호화와 양방향 암호화가 있는데, 이번 시간에는 단방향 암호화에 대해서만 살펴보도록 하겠습니다.

해시 알고리즘

해시 알고리즘은 고정된 크기의 고유한 값(해시 값 또는 해시 코드)을 생성하는 알고리즘입니다. 주어진 입력 데이터에 대해 항상 동일한 크기의 고정된 길이의 출력을 생성하며, 해시 함수라고도 불립니다. 해시 함수의 주요 특징은 다음과 같습니다:

1. 고유성: 서로 다른 입력에 대해서는 고유한 해시 값을 생성합니다. 그러나 해시 함수의 출력 크기가 고정되어 있기 때문에 두 개 이상의 서로 다른 입력이 같은 해시 값을 갖을 수 있습니다. 이것을 '충돌'이라고 합니다.
2. 고속성: 빠르게 계산될 수 있어야 합니다.
3. 역전 불가능성: 해시 값으로는 원래 데이터를 역산하기 어렵습니다. 즉, 해시 값으로는 원래 데이터를 복원할 수 없어야 합니다.
4. 비슷한 입력에 대한 다양한 출력: 입력의 작은 변화에 대해 큰 차이를 가져와야 합니다.

해시 알고리즘은 주로 데이터의 무결성을 검증하거나, 암호화된 비밀번호를 저장할 때 사용됩니다. 대표적인 해시 알고리즘에는 MD5, SHA-1, SHA-256, SHA-3 등이 있습니다.

우리에게 가장 중요한 것은 SHA 알고리즘입니다.

SHA (Secure Hashing Algorithm)는 암호화 보안에 사용됩니다. 이 알고리즘의 가장 중요한 전제는 해시의 비가역성과 고유성입니다. 비가역성-원본 데이터는 안전하고 알려지지 않은 상태로 유지됩니다. 고유성-두 개의 다른 데이터가 동일한 키를 생성 할 수 없습니다.

단방향 암호화 (One-way Encryption 또는 Hashing):

• 특징:
  • 입력 데이터를 암호화한 결과를 역으로 해독할 수 없습니다.
  • 주로 암호화된 값을 저장하거나 전송할 때 사용됩니다.
  • 대표적으로 해시 함수 (예: SHA-256, MD5)가 사용됩니다.
  • 동일한 입력에 대해서는 항상 동일한 해시 값이 생성됩니다.
  • 주로 암호화된 비밀번호를 저장하고, 데이터 무결성을 검증하는 데 사용됩니다.
• 예시:
  • 웹 사이트에서 사용자의 비밀번호를 해시하여 저장하고, 로그인 시에 입력된 비밀번호를 해시하여 저장된 해시 값과 비교합니다.

SHA-1 (Secure Hash Algorithm 1)

• 길이: 160 비트
• 출시 년도: 1993년
• 특징: SHA-1은 빠른 속도와 간단한 구조를 가지고 있습니다. 그러나 현재는 충돌에 취약한 것으로 알려져 있어 보안 측면에서는 사용을 권장하지 않습니다. 실제로 SHA-1은 많은 곳에서 보안 요구 사항을 충족하지 못하게 되었고, 대부분의 보안 전문가들은 SHA-1을 피하고 SHA-2나 SHA-3으로 전환할 것을 권장합니다.

SHA-2 (Secure Hash Algorithm 2)

• 길이: 다양한 길이를 가지고 있으며, 주로 224, 256, 384, 512 비트가 사용됩니다.
• 출시 년도: 2001년
• 특징: SHA-2는 SHA-1의 취약성을 보완하기 위해 개발되었습니다. 다양한 해시 길이를 지원하며, 길이가 길어질수록 더 강력한 보안을 제공합니다. 현재까지 안전하게 사용될 수 있는 해시 알고리즘 중 하나로 간주되고 있습니다.

SHA-256

• 길이: 160 비트
• 출시 년도: 1993년
• 특징: SHA-1은 빠른 속도와 간단한 구조를 가지고 있습니다. 그러나 현재는 충돌에 취약한 것으로 알려져 있어 보안 측면에서는 사용을 권장하지 않습니다. 실제로 SHA-1은 많은 곳에서 보안 요구 사항을 충족하지 못하게 되었고, 대부분의 보안 전문가들은 SHA-1을 피하고 SHA-2나 SHA-3으로 전환할 것을 권장합니다.

비교 요약

• 보안 수준: SHA-1 < SHA-256 < SHA-2 (다양한 길이)
• 사용 권장 여부: SHA-1 (피하길 권장), SHA-256 및 SHA-2 (현재까지 안전한 보안 수준을 제공하므로 사용 가능)

결론

암호화 알고리즘은 SHA-2 이상을 사용하기를 권장하고 있습니다.

참고자료

NIST FIPS PUB 180-4

https://ko.wikipedia.org/wiki/SHA

https://ko.wikipedia.org/wiki/SHA-2

문의 사항이나 도움이 필요하신 분은 댓글 달아주세요!

안녕하세요. 다메카솔입니다. 🐿️

개발중에 발생한 에러를 예방하기위해 원인과 해결방법을 정리해보았습니다.

발생 배경

API에 Request를 보낼때, 서버에서 다음과 같은 에러가 발생하였습니다.

오류 메시지

Cannot construct instance of `class` (no Creators, like default constructor, exist): cannot deserialize from Object value (no delegate- or property-based Creator))

원인

위 에러는  주로 Jackson 또는 다른 JSON 라이브러리를 사용하여 JSON 데이터를 해당 클래스의 객체로 변환하는 중에 발생합니다. 이러한 라이브러리들은 클래스를 직렬화하거나 역직렬화할 때 기본 생성자 (default constructor) 또는 특정 생성자를 사용하는데, 클래스에 기본 생성자가 없거나 또는 라이브러리가 사용할 수 있는 생성자가 없을 때 발생합니다.

직렬화와 역직렬화에 대해 더 궁금하시다면 아래 글도 함께 읽기 좋습니다.

https://damecasol.tistory.com/33

해결방법

• 기본생성자 추가

클래스에 기본 생성자를 추가합니다.. 기본 생성자란 매개변수를 가지지 않는 생성자입니다.

public class YourClass {
    public YourClass() {
        // 기본 생성자 내용
    }
}

• 매개변수가 있는 생성자의 존재

클래스에 매개변수가 있는 생성자가 있는 경우, 해당 생성자도 정의되어 있는지 확인합니다. 만약 라이브러리가 특정 생성자를 필요로 하는데 그 생성자가 없다면 이 오류가 발생할 수 있습니다.

public class YourClass {
    public YourClass(String param1, int param2) {
        // 매개변수가 있는 생성자 내용
    }
}

• @JsonCreator 어노테이션 사용

만약 여러 생성자가 있는 경우, Jackson 라이브러리에서 사용할 생성자를 명시하기 위해 @JsonCreator 어노테이션을 사용할 수 있습니다.

public class YourClass {
    private String param1;
    private int param2;

    @JsonCreator
    public YourClass(@JsonProperty("param1") String param1, @JsonProperty("param2") int param2) {
        this.param1 = param1;
        this.param2 = param2;
    }
}

참조

https://fasterxml.github.io/jackson-databind/javadoc/2.13/com/fasterxml/jackson/databind/ObjectMapper.html

문의 사항이나 도움이 필요하신 분은 댓글 달아주세요!

Vue.js로 개발을 하기위해 환경세팅을 할 때, npm과 yarn을 사용할 일이 있었습니다.

둘 다 node.js 개발환경에 필요한 패키지를 관리하는 패키지매니저라는 것을 알고 있었는데, 어떤 차이점이 있는지, 그리고 두가지를 혼용하여 사용해도 왜 크게 문제가 없는지 궁금하여 각각의 특징과 차이점을 찾아보았습니다.

Yarn과 npm

Yarn과 npm은 둘 다 JavaScript 개발에서 종종 사용되는 패키지 매니저로, 프로젝트의 종속성을 관리하고 설치하는 데 사용됩니다. 이들은 개발자가 애플리케이션에 필요한 외부 라이브러리와 패키지를 쉽게 관리할 수 있게 해줍니다.

npm (Node Package Manager)

npm은 Node.js의 기본 패키지 매니저입니다. Node.js는 JavaScript 실행 환경이며, npm은 Node.js를 다운로드하고 설치할 때 자동으로 함께 설치됩니다. npm은 npm 레지스트리라는 저장소를 통해 수많은 패키지 생태계를 제공합니다. 이는 패키지를 설치, 게시, 관리하는 데 사용되는 명령 줄 도구입니다.

주요 기능:

• 대규모 패키지 생태계: npm은 사용 가능한 수백만 개의 패키지를 보유하고 있어 프로젝트에서 쉽게 사용할 수 있습니다.
• 버전 관리: npm은 패키지 버전을 지정하고 semantic versioning에 따라 종속성을 관리할 수 있습니다.
• 스크립팅: npm에는 다양한 개발 작업을 정의하고 실행할 수 있는 내장된 태스크 러너가 포함되어 있습니다.
• 협업: npm은 자체 패키지를 공유하고 게시할 수 있도록 해주어 다른 사람들이 해당 패키지를 사용할 수 있습니다.

Yarn

Yarn은 JavaScript 애플리케이션용으로 개발된 또 다른 인기 있는 패키지 매니저입니다. Facebook에서 npm의 한계와 성능 문제를 해결하기 위해 개발되었습니다. Yarn은 npm으로 설계된 패키지와 호환될 수 있도록 되어 있습니다.

주요 기능:

• 성능: Yarn은 패키지 설치 및 종속성 해결 등에서 보다 빠르고 안정적입니다. 특히 대규모 프로젝트에서 성능상 이점이 있습니다.
• 결정론적 설치: Yarn은 락파일(yarn.lock)을 사용하여 동일한 종속성 버전이 다른 기기에서도 일관되게 설치되도록 보장합니다.
• 오프라인 모드: Yarn은 내장된 오프라인 캐싱을 가지고 있어 인터넷에 연결되지 않은 상태에서도 패키지를 설치할 수 있습니다.
• 병렬 다운로드: Yarn은 패키지를 병렬로 가져오기 때문에 설치 과정을 크게 가속화할 수 있습니다.

Yarn과 npm의 차이점

• 패키지 설치: Yarn은 결정론적 알고리즘과 락파일을 사용하여 일관된 설치를 보장하는 반면, npm은 package-lock.json 파일을 사용합니다. 이로 인해 설치된 종속성에 약간의 차이가 생길 수 있습니다.
• 성능: 일반적으로 Yarn이 패키지 설치 및 종속성 해결과 같은 작업에서 더 빠르고 효율적입니다. 특히 대규모 프로젝트에서 그 이점이 큽니다.
• 캐싱: Yarn은 내장된 캐싱 기능을 가지고 있어 인터넷 연결이 없는 상황에서도 패키지를 설치할 수 있으며, 다음 설치 과정을 가속화합니다. npm은 npm 버전 5부터 캐싱을 지원하지만 Yarn의 캐싱 기능만큼 고급화되지 않았습니다.
• 사용자 인터페이스: Yarn은 npm에 비해 더 간결하고 사용자 친화적인 명령 줄 인터페이스를 제공합니다.

요약하면, Yarn과 npm은 JavaScript 프로젝트에서 종속성을 관리하는 데 사용되는 패키지 매니저입니다. Yarn은 npm의 성능 및 신뢰성 문제를 개선하기 위해 만들어졌지만, 두 패키지 매니저 모두 JavaScript 생태계에서 널리 사용됩니다. 선택은 주로 개인의 선호도와 프로젝트 요구 사항에 따라 달라집니다.

Nginx는 오픈소스 웹 서버 및 리버스 프록시 서버 소프트웨어로, 다양한 운영 체제에서 사용되며 높은 성능과 안정성을 가지고 있습니다. Nginx는 이벤트 기반 구조를 사용하여 비동기적으로 동작하며, 적은 자원으로 많은 연결을 처리할 수 있어 인기 있는 소프트웨어입니다.

이전에 작성한 Nginx에 대한 소개 글에 이어 Nginx의 구조에 대해 살펴보겠습니다.

https://damecasol.tistory.com/86

Nginx의 구조

NGINX는 이벤트 구동, 비동기 및 비차단 모델을 지원하여 마스터-슬레이브 아키텍처로 구성되어있습니다.

1. Master process : 모든 워커 프로세스를 관리하는 부모 프로세스입니다.
2. Worker process : 클라이언트 요청을 처리하는 자식 프로세스입니다.
3. Event module : Nginx의 비동기 이벤트 처리 엔진으로, I/O 처리를 담당합니다.
4. Cache module : 자주 요청되는 리소스를 캐시하여 처리 속도를 높입니다.
5. HTTP module : HTTP 요청 및 응답 처리를 담당합니다.
6. Reverse proxy module : 웹 서버에서 클라이언트 요청을 받아 백엔드 서버로 전달하는 역할을 합니다.
7. Load balancing module : 여러 백엔드 서버로 부하를 분산하는 로드 밸런싱을 수행합니다.
8. SSL module : SSL/TLS 암호화 연결을 지원합니다.

위의 이미지에서 핵심 부분 3가지를 조금 더 정리하면 다음과 같습니다.

Master Process

클라이언트의 요청에 따라 작업자에게 작업을 할당합니다. 작업자에게 작업이 할당되면 마스터는 작업자의 응답을 기다리지 않는 클라이언트의 다음 요청을 찾습니다. 작업자로부터 응답이 오면 마스터가 클라이언트에 응답을 보냅니다.

Worker Process

워커는 NGINX 아키텍처의 슬레이브이며 마스터를 리스닝합니다(원문 heed). 각 워커는 단일 스레드 방식으로 한 번에 1000개 이상의 요청을 처리할 수 있습니다. 프로세스가 완료되면 응답이 마스터로 전송됩니다. 단일 스레드는 다른 메모리 공간 대신 ​​동일한 메모리 공간에서 작업하여 RAM 및 ROM 크기를 절약합니다. 다중 스레드는 다른 메모리 공간에서 작동합니다.

Cache 

Nginx 캐시는 서버에서 가져오는 대신 캐시 메모리에서 가져와 페이지를 매우 빠르게 렌더링하는 데 사용됩니다. 페이지에 대한 첫 번째 요청 시 페이지가 캐시 메모리에 저장됩니다.

정리

Nginx의 구조를 알아보면서 마스터-슬레이브 아키텍처, 그리고 Nginx가 멀티프로세스 - 단일스레드 방식으로 작동한다는 것을 알게 되었습니다.

위의 내용에 대해서는 후에 더 정보를 찾아봐야 겠습니다.

참고자료

https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/

https://medium.com/@premsuryamj/nginx-architecture-9f97cf7887e2

사내 솔루션을 ASIS JSP + Spring로 구성된 WAS 단일서버에서 Vue.js + Spring으로 UI 차세대를 진행하였습니다.

그에따라 Web서버를 구성해야 할 필요성이 생겼으며, Nginx로 Web서버를 구성하기 위해 찾은 내용을 정리하였습니다.

Nginx란

nginx는 오픈 소스 웹 서버 및 리버스 프록시 소프트웨어입니다. nginx는 Apache와 함께 가장 인기있는 웹 서버 중 하나입니다. nginx는 간단하고 가벼우며 높은 성능과 안정성을 제공합니다.

nginx는 단일 서버 또는 여러 서버에서 사용할 수 있습니다. 여러 서버에서 사용할 경우, nginx는 로드 밸런싱, 캐싱 및 HTTP 및 TCP 로드 밸런싱 기능을 제공합니다.

nginx의 구성은 유연하고 사용자 정의가 가능합니다. nginx 구성 파일은 기본적으로 설정 파일을 읽는 순서로 작성됩니다. 이렇게하면 새로운 구성을 적용하기 전에 이전 구성을 쉽게 되돌릴 수 있습니다.

nginx는 다양한 운영 체제에서 실행될 수 있습니다. 또한 다양한 모듈과 플러그인이 있어서 다양한 기능을 확장할 수 있습니다. 이러한 기능 중 일부는 HTTPS 지원, FastCGI 프로토콜 지원 및 웹 소켓 프로토콜 지원입니다.

nginx는 높은 성능, 안정성 및 유연성으로 인해 많은 대규모 웹 사이트와 애플리케이션에서 사용됩니다.

WEB서버와 WAS 서버

일반적으로, 웹 서버는 정적인 컨텐츠를 처리하고, 애플리케이션 서버는 동적인 컨텐츠를 처리합니다. 이렇게 역할을 나누어 웹 서버는 클라이언트의 요청을 받아 정적인 페이지나 파일을 반환하고, 애플리케이션 서버는 동적인 컨텐츠를 생성하여 반환합니다.

웹 서버와 애플리케이션 서버를 분리하는 이유는 다음과 같습니다.

1. 확장성: 웹 서버와 애플리케이션 서버를 분리하면, 각각의 서버를 별도로 확장할 수 있습니다. 웹 서버를 추가로 배치하여 클라이언트 요청을 더 많이 처리하고, 애플리케이션 서버를 추가로 배치하여 동적인 컨텐츠를 처리하는 데에 집중할 수 있습니다.
2. 보안: 웹 서버와 애플리케이션 서버를 분리하면, 보안 측면에서 더욱 안전한 구성이 가능합니다. 애플리케이션 서버는 외부로부터 직접적인 접근을 받지 않기 때문에, 애플리케이션 서버 자체의 보안성을 높일 수 있습니다.
3. 유지보수: 웹 서버와 애플리케이션 서버를 분리하면, 각각의 역할에 따라 서버를 유지보수할 수 있습니다. 예를 들어, 웹 서버는 정적인 컨텐츠를 처리하므로, 웹 서버를 유지보수할 때 애플리케이션 서버를 중단시키지 않아도 됩니다.

Nginx 기능

wiki에 나열되어 있는 웹 서버 기능은 다음과 같습니다.

• 정적 파일과 인덱스 파일 표현, 자동 인덱싱 기능.
• 캐싱을 통한 리버스 프록시
• 로드 밸런싱
• 고장 진단
• SSL 지원
• 캐싱을 통한 FastCGI 지원
• Name-, IP-기반 가상서버
• FLV 스트리밍
• MP4 스트리밍 모듈을 이용한 MP4 스트리밍
• 웹페이지 접근 인증
• gzip 압축
• 10000개의 동시 접속을 처리할 수 있는 능력
• URL 다시쓰기 (URL rewriting)
• 맞춤 로깅
• 서버 사이드 기능 포함
• WebDAV

이중 궁금한 내용 몇가지만 추가로 찾아보았습니다.

정적 파일과 인덱스 파일 표현, 자동 인덱싱 기능

Nginx는 웹 서버 기능을 수행하며, HTTP 요청에 대한 응답으로 정적 파일을 서비스할 수 있습니다. 이때, 정적 파일이란 이미 생성된 HTML, CSS, JavaScript, 이미지 파일 등을 의미합니다. 이러한 정적 파일들은 일반적으로 웹 서버의 특정 디렉토리에 저장되어 있으며, 클라이언트가 해당 파일의 URL을 요청하면 Nginx는 해당 파일을 응답으로 제공합니다.

Nginx는 클라이언트가 요청한 파일이 없을 경우, 디렉토리 내에 있는 인덱스 파일을 반환합니다. 인덱스 파일은 해당 디렉토리에 위치한 기본 파일을 말합니다. 기본적으로 Nginx에서는 index.html, index.htm, index.php 등을 인덱스 파일로 지정하고 있습니다.

또한, Nginx는 자동 인덱싱 기능을 제공합니다. 자동 인덱싱 기능은 인덱스 파일을 설정하지 않았을 경우, 해당 디렉토리 내에 있는 파일 목록을 자동으로 생성하여 클라이언트에게 보여줍니다. 이때 파일 목록은 정렬된 상태로 제공되며, 클라이언트는 이 목록에서 원하는 파일을 선택하여 다운로드할 수 있습니다.

캐싱을 통한 리버스 프록시

이번에 Nginx를 사용하게 된 주된 이유입니다.

캐싱을 통한 리버스 프록시란, 리버스 프록시 서버가 클라이언트 요청에 대한 응답을 받아서 해당 응답을 캐시에 저장하고, 이후에 같은 요청이 들어오면 캐시된 응답을 바로 제공하는 방식입니다. 이는 웹 서버의 부하를 줄이고, 성능을 향상시키는 데에 유용합니다.

리버스 프록시는 일반적으로 웹 서버 앞단에서 사용되며, 클라이언트 요청을 받아서 웹 서버로 전달합니다. 이때, 리버스 프록시는 요청에 대한 응답을 받아서 클라이언트에게 전달하기 전에 캐시에 저장할 수 있습니다. 이후에 같은 요청이 들어오면 리버스 프록시는 캐시된 응답을 클라이언트에게 바로 전달합니다.

캐시를 통한 리버스 프록시는 다음과 같은 장점을 가집니다.

성능 향상: 캐시를 사용하면 웹 서버의 부하를 줄일 수 있습니다. 이미 캐시된 응답을 제공하기 때문에 웹 서버가 해당 요청에 대한 처리를 다시 할 필요가 없기 때문입니다.

대역폭 절약: 캐시를 사용하면 웹 서버에서 클라이언트로 전송되는 데이터 양을 줄일 수 있습니다. 이미 캐시된 응답을 제공하기 때문에 웹 서버에서 클라이언트로 전송되는 데이터 양이 줄어들기 때문입니다.

빠른 응답 속도: 캐시를 사용하면 클라이언트가 요청한 응답을 바로 제공할 수 있습니다. 이미 캐시된 응답을 제공하기 때문에 웹 서버에서 응답을 생성하는 시간이 필요 없기 때문입니다.

로드밸런싱

Nginx는 로드 밸런싱 기능을 지원하는 웹 서버 및 리버스 프록시입니다. 로드 밸런싱은 여러 대의 서버에 걸쳐 트래픽을 분산시키는 기술로, 클라이언트 요청을 여러 대의 서버에 분산하여 서버의 부하를 분산시켜 안정적인 서비스를 제공하는 것을 목적으로 합니다.

Nginx의 로드 밸런싱 기능은 다음과 같은 특징을 가집니다.

알고리즘: Nginx는 가중 라운드 로빈, IP 해시, Least Connections 등 다양한 로드 밸런싱 알고리즘을 지원합니다. 가중 라운드 로빈 알고리즘은 서버에 부여된 가중치를 기반으로 요청을 분산시키며, IP 해시 알고리즘은 클라이언트의 IP 주소를 해시하여 분산시킵니다. Least Connections 알고리즘은 현재 가장 적은 연결 수를 가진 서버에 요청을 전달하는 방식으로 작동합니다.

Health check: Nginx는 로드 밸런싱 대상 서버의 상태를 주기적으로 확인하는 Health check 기능을 제공합니다. 서버의 상태가 이상하면 요청을 보내지 않고, 정상적인 서버에만 요청을 분산시킵니다.

Sticky session: Sticky session 기능은 클라이언트가 처음 요청한 서버에 계속해서 요청이 전달되도록 합니다. 이 기능을 사용하면 클라이언트의 세션 상태를 유지할 수 있어, 로그인 등의 상태 유지 기능을 구현할 수 있습니다.

Upstream: Nginx는 로드 밸런싱 대상 서버를 Upstream 블록으로 정의하여 관리합니다. Upstream 블록은 로드 밸런싱 대상 서버의 주소와 포트 정보를 포함하며, 서버의 추가나 삭제 등 유지보수 작업이 용이합니다.

다양한 프로토콜 지원: Nginx는 HTTP, HTTPS, TCP, UDP 등 다양한 프로토콜을 지원합니다. 따라서, 로드 밸런싱 기능을 사용하여 다양한 서비스를 제공할 수 있습니다.

참고자료

https://ko.wikipedia.org/wiki/Nginx

TCP 란

TCP(Transmission Control Protocol)는 인터넷에서 컴퓨터들이 신뢰성 있는 데이터 통신을 하기 위한 프로토콜입니다. TCP는 IP(Internet Protocol)와 함께 인터넷 프로토콜 스위트의 핵심 프로토콜 중 하나로, OSI 7계층에서 전송 계층(Transport Layer)에 해당됩니다.

TCP는 신뢰성 있는 데이터 전송을 보장하기 위해 세그먼트(Segment) 단위로 데이터를 나누어 전송합니다. 전송 중 데이터가 유실되거나 손실되었을 경우, TCP는 재전송을 수행하여 데이터의 신뢰성을 보장합니다. 또한, TCP는 흐름 제어(Flow Control)와 혼잡 제어(Congestion Control) 기능을 갖추어, 데이터 전송 시 네트워크 혼잡을 방지하고 성능을 최적화합니다.

TCP는 연결 지향적(Connection-oriented)인 프로토콜로, 3-way handshake를 통해 연결을 설정하고, 4-way handshake를 통해 연결을 종료합니다. 연결 설정 과정에서는 SYN(Synchronize)과 ACK(Acknowledgement) 플래그를 이용하여 연결을 수립하며, 연결 종료 과정에서는 FIN(Finish) 플래그를 이용하여 연결을 종료합니다.

TCP는 다양한 응용 프로그램에서 사용되며, 특히 웹 브라우저와 웹 서버 간의 HTTP 통신에서 사용됩니다.

TCP vs UDP

TCP의 특징을 이해하기 위해선 TCP가 아닌 UDP 프로토콜에 대한 이해도 필요합니다.

TCP와 UDP는 모두 인터넷 프로토콜 스위트의 전송 계층(Transport Layer)에서 사용되는 프로토콜입니다. 그러나 두 프로토콜은 목적과 특징에서 차이가 있습니다.

TCP(Transmission Control Protocol)는 신뢰성 있는 데이터 전송을 보장하는 연결 지향적(Connection-oriented) 프로토콜입니다. 데이터 전송 전에 연결을 설정하고, 데이터를 송수신할 때마다 확인 응답을 주고받아 데이터 전송의 신뢰성을 보장합니다. 데이터 전송 과정에서 패킷 유실이나 손상이 발생하면 재전송을 요청하여 데이터의 정확성과 신뢰성을 보장합니다. 이러한 특성 때문에 웹, 이메일, 파일 전송 등 신뢰성이 중요한 응용 프로그램에서 사용됩니다.

반면에 UDP(User Datagram Protocol)는 비신뢰성 있는 데이터 전송을 하는 비연결형(Connectionless) 프로토콜입니다. 데이터를 송수신할 때 연결 설정 과정이 없으며, 데이터 전송 과정에서 확인 응답을 보내지 않습니다. 이러한 특성 때문에 TCP보다 빠른 전송 속도를 가지고 있습니다. 그러나 데이터 전송의 신뢰성을 보장하지 않기 때문에, 오류나 손상이 발생하면 복구할 수 없습니다. 이러한 특성 때문에 DNS, 멀티미디어 스트리밍 등 속도가 중요한 응용 프로그램에서 사용됩니다.

따라서, TCP와 UDP는 목적에 따라 선택하여 사용해야 합니다. 만약 데이터의 신뢰성이 중요하다면 TCP를 사용하고, 데이터 전송 속도가 중요하다면 UDP를 사용합니다.

3-way handshake

3-way handshake는 TCP 연결을 설정할 때 사용되며, 다음과 같은 과정으로 이루어집니다.

1. 클라이언트가 서버에게 SYN 패킷을 보냅니다.
2. 서버는 SYN 패킷을 받고, 클라이언트에게 ACK와 SYN 패킷을 보냅니다.
3. 클라이언트는 ACK 패킷을 보내서 연결을 완료합니다.

4-way handshake

4-way handshake는 TCP 연결을 해제할 때 사용되며, 다음과 같은 과정으로 이루어집니다.

1. 클라이언트가 서버에게 FIN 패킷을 보냅니다.
2. 서버는 FIN 패킷을 받고, ACK 패킷을 보내서 클라이언트에게 확인합니다.
3. 서버가 데이터를 모두 보낼 때까지 대기합니다.
4. 서버가 데이터를 모두 보낸 후, 클라이언트에게 FIN 패킷을 보냅니다.

전송계층의 특징

전송 계층은 송신자와 수신자 간의 신뢰성 있는 데이터 전송을 보장하기 위한 계층입니다. 이를 위해 전송 계층은 다음과 같은 특징을 가지고 있습니다.

연결 지향성(Connection-oriented)
TCP(Transmission Control Protocol) 프로토콜은 연결 지향성을 가지고 있습니다. 이는 데이터 전송 전에 먼저 연결을 설정하고, 데이터 전송 후에는 연결을 해제하는 과정을 거치는 것을 의미합니다. 이러한 연결 지향성은 신뢰성 있는 데이터 전송을 보장합니다.

비연결 지향성(Connectionless-oriented)
UDP(User Datagram Protocol) 프로토콜은 비연결 지향성을 가지고 있습니다. 이는 데이터 전송에 앞서 연결 설정을 하지 않고, 단순히 데이터를 전송하는 것을 의미합니다. 이러한 비연결 지향성은 전송 속도가 빠르다는 장점이 있지만, 데이터 전송 중 손실이 발생할 경우 복구할 수 있는 기능이 없습니다.

에러 제어(Error control)
전송된 데이터가 손실되거나 손상되는 경우를 대비하여, 전송 계층에서는 에러 제어 기능을 제공합니다. TCP 프로토콜에서는 수신자가 전송한 데이터를 잘 받았는지 확인하는 기능인 'ACK'와 데이터 전송 중 손실된 패킷을 다시 전송하는 기능인 '재전송' 기능 등을 제공합니다.

흐름 제어(Flow control)
전송 계층에서는 수신자가 처리할 수 있는 데이터 양을 조절하기 위해 흐름 제어 기능을 제공합니다. 이를 통해 송신자와 수신자 간의 데이터 전송 속도 차이로 인해 발생할 수 있는 문제를 예방할 수 있습니다.

다중화(Multiplexing)
하나의 호스트에서 여러 개의 프로세스가 동시에 데이터를 전송할 경우, 전송 계층에서는 각각의 프로세스를 구분하기 위한 다중화 기능을 제공합니다. 이를 통해 하나의 호스트에서 여러 개의 어플리케이션이 동시에 동작할 수 있습니다.

확인

사용중인 컴퓨터에서 실제로 연결된 TCP 정보를 확인할 수 있습니다.

CMD 창을 실행한 뒤, netstat -an 명령어를 입력하면 다음과 같이 프로토콜과 로컬 주소, 외부 주소 및 상태를 확인할 수 있습니다.

서버에 요청을 한 뒤 4way handshake를 통해 FIN 명령어를 받아 TIEM_WAIT 상태로 남아있는 연결정보를 확인할 수 있으며, 현재 연결상태로 유지되고 있는  ESTABLISHED, 또한 요청을 기다리고 있는 LISTENING 포트도 확인할 수 있습니다.

알고리즘 문제를 풀 때 답을 제출하기 위해서 문자열을 조작할 때 자주 사용하는 클래스가 두가지가 있습니다.

StringBuilder와 BufferedWriter가 있는데, 두가지 모두 유사하게 사용하고 있지만, 자세하게 어떤 차이가 있는지 그리고 어떤 특징과 장단점이 있는지 잘 정리가 안되어서 각각의 특징과 장단점을 알아봅시다.

StringBuilder와 BufferedWriter는 둘 다 문자열을 처리하는 클래스입니다. 하지만 각각의 특징과 장단점은 다릅니다.

StringBuilder

StringBuilder는 문자열을 조작하는 데 사용되며, 내부적으로 가변 문자열 배열을 사용합니다. 문자열 조작은 메모리 내부에서 수행되므로 속도가 빠르며, 문자열을 추가하거나 수정하는 데 용이합니다. 반면에 StringBuilder는 멀티스레드 환경에서 안전하지 않으므로, 동시에 여러 스레드에서 접근하거나 수정하는 것은 권장되지 않습니다.

StringBuilder의 장점

• 문자열 조작이 빠르다.
• 추가 및 수정이 용이하다.

StringBuilder의 단점

• 멀티스레드 환경에서 안전하지 않다.
• 문자열 출력 기능이 없다.

BufferedWriter

BufferedWriter는 출력 스트림에 대한 버퍼를 제공하여 문자열을 출력할 때 I/O 작업 횟수를 줄입니다. 즉, 출력 작업이 매우 빠르게 수행되며, 매번 파일에 접근하지 않고, 한 번에 많은 양의 데이터를 출력할 때 유용합니다. BufferedWriter는 멀티스레드 환경에서 안전합니다.

BufferedWriter의 장점

• 출력 작업이 매우 빠르다.
• 파일에 접근하지 않고, 한 번에 많은 양의 데이터를 출력할 때 유용하다.

BufferedWriter의 단점

• 문자열 조작 기능이 없다.

참고 자료

StringBuilder 공식문서: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StringBuilder.html

BufferedWriter 공식문서: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/io/BufferedWriter.html

자바로 애플리케이션 개발을 할 때 자주 사용하는 Mybatis와 CDATA에 대해 알아봅시다.

MyBatis란?

MyBatis는 SQL Mapper Framework 중 하나로, 자바 객체와 SQL문 사이의 자동 매핑을 지원합니다. 데이터베이스의 CRUD(Create, Read, Update, Delete) 작업을 간편하게 처리할 수 있도록 도와줍니다.

CDATA 태그란?

CDATA 태그는 XML 문서 안에 특수 문자를 포함시킬 때 사용됩니다. 특수 문자를 그대로 출력하게 해주는 역할을 합니다.

MyBatis에서 CDATA 태그 사용하기

MyBatis에서 SQL문을 작성할 때, 문자열 안에 특수 문자가 포함될 경우 문제가 발생할 수 있습니다. 이런 경우에 CDATA 태그를 사용하여 특수 문자를 그대로 출력할 수 있습니다.

예시

xmlCopy code

<select id="selectUserByName" parameterType="java.lang.String" resultType="User">
	SELECT * FROM users WHERE name = <![CDATA[#{name}]]> 
</select>

CDATA 태그를 사용하면 SQL문 안에서 작은 괄호(<, >)나 & 같은 특수 문자들이 자동으로 이스케이핑되지 않으므로, SQL문 작성 시 편리하게 사용할 수 있습니다.

MyBatis에서 CDATA 태그 사용 시 주의할 점

하지만 CDATA 태그를 사용할 때 주의할 점이 있습니다. 예를 들어, SQL문 안에 ]]> 문자열이 포함된 경우에는 CDATA 태그를 닫는 문자열과 혼동이 발생할 수 있습니다. 이런 경우에는 ]]>]]&gt;와 같이 문자열을 변경해 주어야 합니다.

공식문서

MyBatis 공식문서: https://mybatis.org/mybatis-3/ko/index.html

XML 이스케이핑(MyBatis 공식문서): https://mybatis.org/mybatis-3/sqlmap-xml.html#XML_Escaping

참고자료

MyBatis - SQL Mapper Framework: https://github.com/mybatis/mybatis-3

CDATA Section (MDN Web Docs): https://developer.mozilla.org/ko/docs/Web/XML/CDATA

https://school.programmers.co.kr/learn/courses/30/lessons/42577

문제

전화번호부에 적힌 전화번호 중, 한 번호가 다른 번호의 접두어인 경우가 있는지 확인하려 합니다.
전화번호가 다음과 같을 경우, 구조대 전화번호는 영석이의 전화번호의 접두사입니다.

• 구조대 : 119
• 박준영 : 97 674 223
• 지영석 : 11 9552 4421

전화번호부에 적힌 전화번호를 담은 배열 phone_book 이 solution 함수의 매개변수로 주어질 때, 어떤 번호가 다른 번호의 접두어인 경우가 있으면 false를 그렇지 않으면 true를 return 하도록 solution 함수를 작성해주세요.

제한 사항

• phone_book의 길이는 1 이상 1,000,000 이하입니다.
  • 각 전화번호의 길이는 1 이상 20 이하입니다.
  • 같은 전화번호가 중복해서 들어있지 않습니다.

입출력 예제

phone_bookreturn

["119", "97674223", "1195524421"]	false
["123","456","789"]	true
["12","123","1235","567","88"]	false

입출력 예 설명

입출력 예 #1
앞에서 설명한 예와 같습니다.

입출력 예 #2
한 번호가 다른 번호의 접두사인 경우가 없으므로, 답은 true입니다.

입출력 예 #3
첫 번째 전화번호, “12”가 두 번째 전화번호 “123”의 접두사입니다. 따라서 답은 false입니다.

 

발상

정렬을 하면 앞뒤 비교만으로 간단하게 해결될 것 같아서 정렬 후 순서대로 하나의 문자열을 그 다음 문자열이 포함하고 잇는지 여부를 검사하는 방식으로 접근하였다.

의사코드

1. 입력값 정렬
2. 배열수+1 만큼 반복{
	1. 다음 배열의 값이 현재 배열의 값을 가지고 있으면 false
}
3. true 리턴

 

코드

더보기

        if (phone_book.length == 1) return true;
        Arrays.sort(phone_book);
        for (int i = 0; i < phone_book.length - 1; i++) {
            String pattern = "^"+phone_book[i]+".*";
            if(phone_book[i+1].matches(pattern)) return false;
//            if(phone_book[i+1].contains(phone_book[i])) return false;
//            if (phone_book[i].length() <= phone_book[i + 1].length() && phone_book[i].equals(phone_book[i + 1].substring(0, phone_book[i].length())))
//                return false;
//            for (int j = i+1; j < phone_book.length; j++) {
//                if (phone_book[j].contains(phone_book[i])) {
//                    return false;
//                }
//            }
        }
        return true;
    }

개선

처음엔 contains로 접근하였는데, 테스트케이스를 통과하지 못하는 예외케이스가 발생하였다.

생각해보니 제시된 문자열로 시작하는 경우만 검사해야 하기 때문에, substring으로 수정하여 통과시켰다가

다시 정규식으로 전환하였는데, 정규식은 패턴문자열을 계속해서 만들어야 하다 보니까 성능이 훨씬 안나왔다.