About idempotent

이미지
 이번글에서는 프로그래밍에서 멱등성에 대해 정리하고 실제 상황에서 어떻게 구현해야지 멱등성을 달성할 수 있는지 작성하겠다. 멱등성이란?  영어로는 idempotent. 사전적 정의로는 "연산을 여러 번 적용하더라도 결과가 최초 실행 결과가 그대로 보존되는 성질을 의미" 이다. 실제 서비스에서 일어날 수 있는 상황에 멱등성을 통해서 해결해보자.  고객이 아마존이나 쿠팡에서 상품을 구매하려고 한다. 고객은 상품을 구매하기 위해서 결제를 해야 한다. 이 때 결제는 두 번 이상 실행되어서는 절대 안된다.  1. 일명 "따닥" 으로 고객이 버튼을 빠르게 두 번 클릭하는 상황이 발생할 수 있다. 2. 고객이 첫번째 결제 요청을 하고 실제로 결제가 처리되었지만 네트워크 오류로 응답이 전달되지 못하여 고객이 버튼을 다시 클릭하는 상황이 발생할 수 있다.  만 원을 결제했는데, 실제 2만원이 결제되는 최악의 상황은 발생하지 않아야 한다.  데이터베이스 고유 키 제약조건 (unique key constraint)  1. 결제 요청을 받으면 테이블에 새 레코드를 넣으려고 시도한다. 2-1. 새 레코드 추가에 성공했다면 이전에 처리한 적이 없는 결제 요청이다. 2-2. 새 레코드 추가에 실패했다면 이전에 받은 적이 있는 결제 요청이다. 이러한 중복 요청은 처리하지 않는다. 일회성 토큰 Nonce(Number used Only Once) UUID 또는 timestamp 와 같은 값을 사용하여 정확히 한 번만 사용할 수 있는 장치를 마련한다. 행위에 대한 혹은 도메인(결제)에 대한 식별자 역할을 한다. 이미 처리된 동일한 Nonce 값이 들어온 경우 중복 요청으로 간주하고 처리하지 않는다. 이 때 한 가지 고려할 점은 이 값을 서버에서 제공하여 일회용 토큰으로써 사용하는 것이다. 클라이언트에서 값을 받는것은 언제든지 위조 될 수 있기 때문이다. 간단한 예제 코드 UUID 일회용 결제 토큰을 Redis 를 활용하여 사용 여부를...

sneak peek jitpack

이미지
 생산성을 위해서 여러 프로젝트에서 반복적으로 사용되고 있거나 앞으로 사용될 프로젝트 코드를 효과적으로 관리하기 위해서 라이브러리로 관리하는 방법을 선택할 수 있다. 그렇다면 라이브러리를 어떻게 관리하는 것이 좋을까? java, kotlin 을 사용하여 개발을 할 경우, maven, gradle 을 통해서 의존성을 관리한다. 이 때 의존성들의 저장소는 Maven Central 혹은 jCenter(현재는 지원 중단) 처럼 공개 레포지토리일 수도 있고, 단체에서만 사용하는 사설 레포지토리일 수도 있다. 이러한 레포지토리를 지원하는 여러 툴이 있다.  Maven Central 에서 아티팩트를 올리기 위해서는 요건이 엄격하다. 따라서 JitPack 을 사용하여 찍먹해보겠다. 먼저 github 레포지토리 2개를 판다. 하나는 라이브러리용이고, 나머지는 라이브러리를 사용한다. 라이브러리 :  https://github.com/ndgndg91/hello-jitpack 아래는 build.gradle.kts 파일이다. maven-publish 플러그인을 사용해야 하며, publishing 을 설정해야한다. 아래는 재사용할 코드를 간단하게 작성해보았다. 그리고 git tag 를 통해 버전을 관리한다. https://github.com/ndgndg91/hello-jitpack/releases/tag/0.0.2 사용할 라이브러리를 작성하고 git tag 를 땄으면 1차 준비는 완료했다. 다음은 https://jitpack.io  에 가서 내가 작성한 github repository 를 검색한다. 0.0.2 이라는 git tag 를 확인할 수 있다. 그리고 build Log 를 확인할 수 있다. 여기까지 성공했다면 다음은 쉽다. https://jitpack.io/com/github/ndgndg91/hello-jitpack/0.0.2/build.log 사용:  https://github.com/ndgndg91/use-jitpack build....

Spring Boot Actuator readiness, liveness probes on k8s

이미지
Spring Boot 를 사용하여 서버 어플리케이션을 개발하고 Kubernetes 상에서 운영할 때 Container 의 상태를 확인하고 복구가 불가능한 경우 재시작 시켜야 되는지 알 필요가 있다. 또한 Container 가 트래픽을 받아들일 준비가 되었는지 상태를 알아야한다. 이때 각각 liveness, readiness probes 를 사용한다. 아래와 같이 Kubernetes deployment 에 liveness 와 readiness probes 를 설정한다. initialDelaySeconds 는 Container 가 실행되고 90초 이후에 설정된 path 에 Get 요청을 통해서 정상상태를 확인한다. 200 ~ 399 status code 를 5초이내에 응답 받으면 성공으로 확인한다. periodSeconds 는 10초 주기로 확인한다. 연속해서 3번 비정상 응답을 받을 경우 liveness 는 실패로 돌아가고 Kubelet 은 Container 를 재시작시킨다. 이번엔 Spring Boot 어플리케이션을 보자. gradle 을 사용할 때 아래와 같이 의존성을 추가한다. 그리고 application.yaml 에 아래와 같이 설정한다. 유의해야할 점은 exposure.include 에 * 를 쓰게되면 불필요한 정보가 모두 노출되어 보안에 취약해진다. 예를 들어, heapdump 또는 shutdown 같은 기능을 노출하게 되면 외부에서 공격점이 될 수 있다. /actuator path 요청시 아래와 같이 응답을 받는다.  exposure 에 health, info 만 설정해서 두가지만 확인할 수 있다. /actuator/health 를 확인해보자. endponint.health.probes.enabled=true 로 설정해서 liveness, readiness 를 지원한다. /actuator/health/liveness 와 /actuator/health/readiness 를 확인해보자.  spring boot application 에...

Install and Run Kafka on my M1 Macbook

이미지
 M1 맥북 로컬에 카프카를 설치하는 방법은 두가지가 있다. binary 로 다운받아서 설치하는 방법과 간단한 homebrew 를 통해서 설치하는 방법이 있다. homebrew 로 진행해보자. m1 의 homebrew 통한 설치 경로는 아래와 같다. - 바이나리와 스크립트는 /opt/homebrew/bin - Kafka 설정들은 /opt/homebrew/etc/kafka - Zookeeper 설정은 /opt/homebrew/etc/zookeeper - log.dirs config (the location for Kafka data) 는 /opt/homebrew/var/lib/kafka-logs 1. homebrew 설치 1 /bin/bash -c " $( curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh ) " 2. kafka 설치 brew install kafka 3. zookeeper 실행 zookeeper-server-start /opt/homebrew/etc/zookeeper/zoo.cfg 4. kafka 실행 kafka-server-start /opt/homebrew/etc/kafka/server/properties Zookeeper 없이 실행하기 - Kraft 1. Kafka UUID 생성 kafka-storage random-uuid # 76BLQI7sT_ql1mBfKsOk9Q 2. 포맷팅 kafka-storage format -t <uuid> -c /opt/homebrew/etc/kafka/kraft/server.properties # Formatting /opt/homebrew/var/lib/kraft-combined-logs with metadata.version 3.4-IVO. 3. kafka 실행 kafka-server-start /opt/homebrew/etc/kafka/kraft/server.properties ...

How to prevent replay attack?

이미지
Replay Attack 이란? replay attack 은 공격자가 유효한 네트워크 데이터 패킷을 가로채서 이후에 다시 사용하는 네트워크 공격의 유형이다. 데이터를 다시 전송하여 시스템이 정상적인 데이터로 처리하도록 한다. replay attack 은 실제로 정상적인 요청으로 보이기 때문에 탐지가 어렵다. 덧붙여 원래 전송이 암호환된 경우에도 성공할 수 있다. replay attack 은 반복적인 요청을 통해 시스템에 과부하를 줄 수 있다. 이로 인해 시스템의 정상적인 작동을 방해할 수 있다. 공격자는 그림과 같이 데이터 전송이 시작될 때까지 기다린다. 이후에 통신 채널을 스니핑하여 데이터를 추출한다. 공격자는 데이터를 입수하여 목적에 따라 데이터를 수정해서 다시 사용할 수도 있다. 수신자는 변조된 데이터를 받았지만 정상적인 데이터로 취급한다. 대표적인 4가지 유형이 있다. 네트워크, 무선, 세션, HTTP 가 있다. 네트워크 replay attack 은 공격자가 네트워크 트래픽을 가로챈 후 나중에 다시 전송한다. Wireshark 또는 tcpdump 와 같은 도구를 사용한다. 무선 replay attack 도 동일하게 무선 통신을 가로챈 다음 다시 전송한다. 세션 replay attack 은 두 당사자 간의 세션을 가로챕니다. HTTP replay attack 은 공격자가 HTTP 요청과 응답을 캡처하여 HTTP replay attack을 실행한다. 실제 예시 앨리스가 웹을 사용하여 온라인 뱅킹 계좌에 로그인하려고 한다고 가정한다. 앨리스가 로그인 자격 증명을 입력하고 제출 버튼을 클릭하면 로그인 요청이 인터넷을 통해 은행 서버로 전송된다. 공격자 밥은 네트워크를 모니터링하여 로그인 요청이 전송되는 것을 캡처한다. 그런 다음 밥은 앨리스가 계정에서 로그아웃할 때까지 기다렸다가 캡처한 로그인 요청을 은행 서버로 재전송한다. 로그인 요청이 유효하므로 서버는 이를 수락하고 밥에게 앨리스의 계정에 대한 액세스 권한을 부여한다. 어떻게 하면 Replay Attack...

About Websocket minimize data size and data transfer cost on cloud

이미지
웹소켓은 클라이언트와 서버간의 양방향으로 상호작용할 수 있게 만들어준다. 주로 채팅, 게임, 금융 거래 시스템 등 실시간 데이터 처리를 위해서 사용한다. 웹소켓을 사용하지 않고 롱폴링과 같은 방법을 사용할 수 있지만, 매 데이터 교환마다 새로운 요청을 보내야 한다. 웹소켓은 한번의 커넥션으로 지속해서 통신할 수 있어서 낮은 latency 를 보장한다. 따라서, 더 빠르고 유려한 사용자 경험을 제공할 수 있다. 내가 운영하는 서비스에서 웹소켓을 사용하고 있다고 가정해보자. 그리고 추가로 사용자가 접속할 때 항상 웹소켓을 사용해야 한다. 예를 들어, 주식 시장이나 코인 시장의 가격을 실시간으로 확인하거나, 교통의 흐름을 추적한다고 가정해보자. 실시간으로 제공해야 하는 제공해야 하는 데이터가 많아진다. 사용자가 많아질수록 또한 제공해야 하는 데이터가 많아진다. AWS와 같은 클라우드를 사용하여 서비스를 운영하는 상황일 때 데이터의 양이 많아질 경우 비용 증가로 이어지게 된다. AWS Data Transfer Cost 가 부과되는 방법은 다양하지만 이번 경우에서는 AWS 환경에서 Internet 환경으로 data 가 전송되는 구간에 대해서 정리해보겠다. 2023-03-12 기준 서울 region 에서 인터넷으로 데이터 송신 비용이다. 처음 100GB 전송은 무료이며 이후 부터 전송량 별 비용이 감소한다. 0 ~ 100GB 무료 100GB ~ 10340GB  0.126USD/GB 10340GB ~ 41060GB 0.122UDS/GB ... 생략 이렇게 산정되는데 10TB를 꽉 사용했다는 가정하에 가격은 1302.84 USD 이다.  2023-03-12 기준 1달러 환율은 1,320.64원이다.  1720582.6176 원으로 172만 5백원이다. 무시할 수 있는 비용이 아니다. 어떻게 해당 비용을 줄일 수 있을까?  Data Serialization json 일반적으로 WebSocket 으로 데이터를 교환할 때 흔히 사용한다. text...

About UTF-8, Base64

이미지
컴퓨터는 항상 비트를 다룬다 그리고 비트를 사용해 수와 같은 대상을 표현한다. https://infondgndg91.blogspot.com/2023/02/about-binary-number.html  그렇다면 문자나 키보드에 있는 다른 기호는 어떻게 표현할까? ASCII(American Standard Code for Information Interchange) 키보드에 있는 모든 기호를 7bit 를 할당했다. 예를 들어 65 는 대문자 A 66은 대문자 B를 표현한다. 아래 링크에서 확인할 수 있다. https://www.asciitable.com/ 위와 같이 글자를 출력하는 데 쓰이지 않고 장치를 제어하기 위해 쓰이는 control character 가 있다. 이 중 상당수는 통신 제어를 위한 문자다. ACK(수신확인) '메세지를 받았음' 이고, NAK(반수신확인)는 '메세지를 받지 못했음'을 의미한다. 유니코드(Unicode)  아스키는 영어를 표현하는 데 필요한 모든 문자를 포함하고 있어서 상당 기간 표준 역할을 했다. 초기 컴퓨터는 미국산 혹은 영국산이었기 때문이다. 컴퓨터가 널리 쓰이게 되면서, 이외의 언어를 지원해야 했다. 국제 표준화 기구인 ISO(International Standard Organization) 은 ISO-646, ISO-8859 를 도입했다. 기본적으로 아스키를 확장해 유럽 언어에 필요한 액센트 기호나 그 밖의 발음 구별 기호를 추가했다. 그리고 일본 산업 표준  위원회는 JIS(Japanese Industrial Standards) 일본 문자 표현을 위해서 JIS X 0201 을 만들었다. 또한 중국어, 아랍어, 한국어(KS C 5601) 등 표준도 생겼다.   이렇게 많은 표준이 존재한 이유는 비트가 지금보다 더 비쌌다. 그래서 최대한 문자를 7비트나 8비트에 욱여넣었다. 비트가격이 떨어지면서 유니코드라는 표준이 생겼다. 문자에 16비트 코드를 부여했다. 16비트면 지구상의 모든 문자...