HBS FreeTalk

2026-05 월 적립식 투자

bitofsky — Mon, 4 May 2026 10:18:49 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

2021년부터 지속하고있는 내 투자 규칙이다.매수 규칙이 2023년 11월부터 변경되었다. (기존 규칙 LINK)월 적립식 투자규칙매월 1일 매매SCHD, TQQQ를 기계식 매수SCHD를 적립하면서 동시에 QQQ의 양/음봉

hbs.pe.kr

1회 전월 양봉 = x1를 SCHD 매수

지난달 초 x4+ 배율로 매수했던 TQQQ를 37% 수익률로 전액 매도했다. 한달간 가지고있던 것 치곤 꽤 높은 수익을 냈기 때문에 만족한다. TQQQ 매도 금액과 이번달 적립금은 모두 SCHD를 구매했다.

투자규칙에 의해 기계적으로 TQQQ 사고 판 타이밍을 보면 매우 낮은 금액에서 사고 상당히 높은 금액에서 팔고있음을 알 수 있다. 이 투자 모델은 1달에 1회씩만 사고 팔지만 이것이 오히려 자잘한 시장 이벤트 노이즈를 제거하면서 1년에 몇 번 없는 거시적인 큰 하락 이벤트를 놓치지 않고 잘 감지하며 매수~매도 하게 된다.
1년에 한두번 위험자산에 이렇게 크게 먹고 나온 다음 수익들을 안전 배당주에 재투자 하게 된다.

SCHD 상승과 TQQQ 매도를 포함한 최근 3~4개월간의 투자수익률만으로 이미 몇 년치 근로소득 수입 이상을 벌었다.
이러면 근로소득이 큰 의미 있나? 싶을 수 있는데 이럴때일수록 정신 잘 차리고 하락에 대비하는 자세가 필요하다.
안전한 배당주와 채권 비중을 계속 늘리는 이유가 여기에 있다.

그리고 한살이라도 젊었을때 시드머니를 조금이라도 더 키워야한다.

EC2 Master/Worker Process Queue

bitofsky — Wed, 29 Apr 2026 14:46:23 +0900

https://github.com/bitofsky/skills/tree/main/ec2-process-queue

TLDR;

Install Skill

npx skills add https://github.com/bitofsky/skills/tree/main/ec2-process-queue

To AI: 해줘

/ec2-process-queue 이 스킬을 사용해 ec2 c8i-large 인스턴스 10대로 어떠어떠한 작업을 진행해줘

EC2 Master/Worker Process Queue

이 문서는 대량의 독립 작업을 EC2 여러 대에 분산해서 실행하는 master/worker 큐 구조를 설명한다. 특정 업무 도메인이나 처리 내용은 중요하지 않다. 핵심은 “매우 많은 process target을 로컬 큐에 넣고, EC2 worker slot에 균등하게 분배해서, 병렬로 처리하고, 진행 상황을 회수/모니터링하는 방법”이다.

예를들어 s3에 있는 수많은 파일을 EC2 worker 여러 대에서 병렬로 처리하는 상황을 상상해보자. 이 문서에서 설명하는 구조는 이런 유형의 작업에 적합하다.

Local에서 전체 target 목록을 관리하는 master가 있고, 다른 리전의 여러 EC2 인스턴스에 worker slot을 만들어서 master가 local queue에서 target을 pop해서 각 slot의 remote next에 채워준다. 각 worker는 자기 slot의 next에서 하나씩 pop해서 처리한다. worker는 성공/실패를 slot별 파일에 남긴다. monitor는 SSM으로 모든 slot의 상태를 주기적으로 읽어서 진행 상황을 보여준다.

이를 통해 EC2의 네트워크, 디스크 I/O, CPU 같은 리소스를 최대한으로 사용하면서 실시간으로 진행 상황을 모니터링할 수 있고, EC2와 EBS 증가만으로 동시 처리량을 쉽게 늘릴 수 있다.

이 문서는 사람이 읽고 이해하고 쓰기보단 AI에게 제공하고 필요한 준비작업을 AI가 수행하며, 사람은 오직 모니터링 스크립트만 실행해 실행상태 체킹만 하는데 사용하기 위함이다.

이 문서에서 사용하는 용어는 다음과 같다.

용어	의미
process target	처리할 작업 1개를 나타내는 문자열. 보통 URI, key, id 같은 한 줄짜리 값이다.
local queue	아직 EC2에 dispatch되지 않은 target 목록 파일.
master	로컬에서 실행되는 큐 refill 프로세스.
worker slot	EC2 내부의 독립 작업 디렉토리. 예: `/1`, `/2`, `/3`.
worker	worker slot 하나를 담당하는 장기 실행 프로세스.
remote next	각 worker slot에 있는 대기 큐 파일.
status	worker slot의 현재 진행 상태를 나타내는 한 줄짜리 파일.

반드시 챙길 것

이 구조는 단순하지만, 아래 항목을 놓치면 target 중복 처리, target 유실, 잘못된 인스턴스 종료, 실패 원인 추적 불가 같은 문제가 생긴다. AI가 이 문서를 보고 작업을 수행할 때는 이 섹션을 먼저 확인해야 한다.

Queue Lock

local queue에서 target을 pop할 때는 반드시 flock "$QUEUE_FILE.lock"을 사용한다.
remote next에서 worker가 target을 pop할 때는 반드시 slot별 next.lock을 사용한다.
master가 remote next에 append할 때도 반드시 해당 slot의 next.lock을 잡는다.
lock 없이 head, tail, mv, cat >> next를 수행하면 master refill, worker pop, 재분배가 겹칠 때 target이 중복되거나 사라질 수 있다.

Atomic Write

next를 수정할 때는 임시 파일에 쓴 뒤 mv로 교체한다.
status 갱신은 반드시 고유 임시 파일에 쓴 뒤 mv -f로 교체한다.
status.$$처럼 PID 기반 고정 파일명을 쓰면 background monitor와 main process가 동시에 status를 쓸 때 race가 날 수 있다.
권장 형태:

tmp="$(mktemp "${status_file}.XXXXXX")"
printf "%s\n" "$(date -Is) phase=running target=$target" > "$tmp"
mv -f "$tmp" "$status_file"

Target Record

queue record 하나는 반드시 한 줄이어야 한다.
TSV/NDJSON을 써도 literal newline은 넣지 않는다.
shell에서 target record는 항상 quote한다.
target record에 민감한 값이 들어가면 logs, status, ps, pgrep -af 출력에 노출될 수 있으므로 넣지 않는 것을 원칙으로 한다.

Dispatch Audit

master가 local queue에서 target을 pop하고 remote next append에 성공했으면 target_process.dispatched에 기록한다.
remote append 실패 시 pop했던 target은 local queue 앞으로 되돌린다.
dispatched는 “완료”가 아니라 “EC2에 넘김” 기록이다. 완료 여부는 remote completed와 output/result 검증으로 판단한다.

Worker Slot Isolation

한 worker process는 하나의 REMOTE_DIR만 소유한다.
같은 slot에 worker process를 중복 실행하지 않는다.
EC2 한 대에 여러 worker를 둘 때는 /1, /2, /3처럼 디렉토리를 분리한다.
각 slot은 자기 next, completed, failed, status, tmp, logs만 사용해야 한다.

Process Result Validation

process script가 결과물을 만든다면 다음 단계로 commit/publish/write 하기 전에 결과물이 실제로 존재하고 0 byte가 아닌지 확인한다.
외부 명령으로 결과물을 만들면 stdout/stderr를 임시 로그에 남긴다.
실패 시 worker log에 원인이 남아야 나중에 재시도 여부를 판단할 수 있다.
process script는 이미 처리된 target을 만나면 skip하고 성공 처리할 수 있게 만드는 것이 좋다.

Monitor Semantics

NEXT는 아직 실행에 들어가지 않은 remote 대기 target 수다.
현재 실행 중인 target은 NEXT에 포함되지 않는다.
CPU, RX/s, TX/s는 slot별 값이 아니라 인스턴스 단위 값이다. 같은 EC2의 여러 slot 행에 동일하게 반복 표시된다.
completed와 failed는 slot별 누적 파일이다.
실패 target을 재시도해서 성공해도 기존 failed 줄 수는 자동으로 줄지 않는다.
재시도 성공 여부는 output/result 존재 여부, retry 후 completed 기록, 또는 별도 검증으로 확인한다.

Instance Termination

EC2 종료 조건은 “해당 인스턴스의 모든 slot이 NEXT=0이고 phase=idle”일 때다.
일부 slot만 idle이면 종료하면 안 된다.
status가 오래된 uploading, committing, running 상태라면 실제 프로세스 확인이나 output/result 확인 없이 종료하지 않는다.
종료 전 필요한 경우 remote next와 현재 target을 회수한다.
종료 후에는 process-workers.instances와 workers에서 해당 instance-id를 제거한다.

Rebalance

local queue가 비었는데 일부 EC2에 heavy target의 remote next가 몰릴 수 있다.
재분배는 현재 실행 중인 target이 아니라 아직 실행 전인 remote next만 대상으로 한다.
재분배 전 master를 중단한다.
모든 remote next를 flock으로 drain하고, idle slot에 round-robin으로 append한다.
drain/assignment 결과는 파일로 남긴다.

Security

secret은 queue record, status, logs, command line에 넣지 않는다.
process에 secret이 필요하면 SSM Parameter Store, IAM Role, instance metadata 같은 별도 경로로 주입한다.
ps, pgrep -af, worker log가 command line 인자를 노출할 수 있음을 고려한다.

권장 파일 구성

유사한 작업을 새로 구성할 때는 아래와 같은 역할 기반 이름을 사용하는 것을 권장한다. 핵심은 파일명 자체가 아니라 역할 분리다.

역할	권장 파일
process 실행 스크립트	`scripts/process-target.sh`
worker loop	`scripts/process-worker.sh`
master refill	`scripts/process-master-refill.sh`
worker monitor	`monitor-process-workers.sh`
EC2 bootstrap user-data	`scripts/ec2-bootstrap-process-workers.sh`
인스턴스 목록	`process-workers.instances`
worker slot 목록	`workers`
local queue	`target_process.queue`
dispatch audit log	`target_process.dispatched`

기존 구현을 재사용할 때 파일명이 다르다면, 이 문서의 process-* 이름을 실제 파일명에 맞춰 치환해서 사용하면 된다.

전체 구조

기본 아이디어

작업은 두 단계 큐로 관리한다.

로컬 master가 큰 전체 큐를 가진다.
master는 각 EC2 worker slot의 next 파일을 작게 채워준다.
각 worker는 자기 slot의 next에서 하나씩 pop해서 처리한다.
worker는 성공/실패를 completed, failed에 남긴다.
monitor는 SSM을 통해 모든 slot의 status를 읽는다.

이 구조의 장점:

SSH 없이 SSM만으로 배포/실행/모니터링할 수 있다.
EC2 한 대에 여러 worker slot을 둘 수 있다.
master를 중단해도 이미 remote next에 들어간 작업은 계속 진행된다.
worker별 next가 작기 때문에 특정 인스턴스를 종료할 때 회수해야 할 범위가 제한된다.
local queue pop과 remote next pop은 모두 flock으로 보호한다.

큐 계층

Local Queue

예시 파일:

target_process.queue

현재 구현 파일:

target_process.queue

형식:

target-1
target-2
target-3

특징:

한 줄이 process target 하나다.
master만 이 파일에서 pop한다.
병렬 master refill 과정에서 동시에 접근할 수 있으므로 target_process.queue.lock 형태의 lock 파일을 사용한다.
dispatch에 성공한 target은 audit log에 남는다.

Remote Next Queue

각 EC2 worker slot에는 next 파일이 있다.

/1/next
/2/next
/3/next

특징:

한 줄이 process target 하나다.
worker가 하나씩 pop한다.
pop은 next.lock으로 보호한다.
master는 각 next 파일의 줄 수가 MAX_NEXT보다 작으면 부족분만 append한다.

Worker Slot 디렉토리

한 EC2 인스턴스에 여러 worker slot을 둘 수 있다. 현재 구조는 인스턴스당 3개 slot을 사용한다.

/1
/2
/3

각 slot의 구성:

next
next.lock
completed
failed
status
logs/worker.log
tmp/
worker script
process script

slot은 서로 독립적이다. 같은 EC2 안에서도 /1, /2, /3 worker가 동시에 실행된다.

처리 흐름

Master Refill 동작

master는 로컬에서 실행된다.

역할:

workers 파일을 읽는다.
같은 instance-id에 속한 worker dirs를 그룹화한다.
각 인스턴스에 SSM command를 한 번 보내 /1, /2, /3의 next 줄 수를 조회한다.
여러 인스턴스 조회/리필을 병렬로 실행한다.
부족한 수만큼 local queue에서 pop한다.
pop한 target을 remote next에 append한다.
dispatch audit log를 기록한다.
실패 시 pop했던 target을 local queue 앞으로 되돌린다.

주요 환경변수:

변수	기본값	설명
`WORKERS_FILE`	empty	worker slot 목록 파일. 보통 `workers`.
`INSTANCES_FILE`	`process-workers.instances`	instance-id 목록 파일. `WORKERS_FILE`이 없을 때 사용.
`QUEUE_FILE`	`target_process.queue`	local queue 파일.
`DISPATCHED_FILE`	`target_process.dispatched`	dispatch audit log.
`MAX_NEXT`	`5`	worker slot별 remote next를 최대 몇 개까지 채울지.
`REFILL_PARALLELISM`	`20`	master가 동시에 처리할 인스턴스 수.
`INTERVAL_SECONDS`	`30`	refill pass 사이의 대기 시간.
`ONCE`	`0`	`1`이면 한 번만 refill하고 종료.

foreground 실행:

WORKERS_FILE=workers \
QUEUE_FILE=target_process.queue \
MAX_NEXT=5 \
REFILL_PARALLELISM=10 \
INTERVAL_SECONDS=10 \
scripts/process-master-refill.sh

중단:

Ctrl-C

master를 중단해도 remote next에 이미 들어간 target은 worker가 계속 처리한다.

한 번만 refill:

ONCE=1 \
WORKERS_FILE=workers \
QUEUE_FILE=target_process.queue \
MAX_NEXT=5 \
REFILL_PARALLELISM=10 \
scripts/process-master-refill.sh

Worker 동작

worker는 EC2의 특정 slot 디렉토리에서 계속 실행된다.

동작 순서:

REMOTE_DIR로 이동한다.
필요한 디렉토리와 파일을 만든다.
process 실행에 필요한 runtime secret/config를 읽어 환경변수로 준비한다.
무한 루프를 돈다.
next에서 target 하나를 flock으로 pop한다.
process script를 실행한다.
성공하면 completed에 기록한다.
실패하면 failed에 기록한다.
대기 target이 없으면 status에 phase=idle을 쓰고 sleep한다.

slot별 로그:

/N/logs/worker.log

slot별 상태:

/N/status

예시 status:

2026-04-28T06:49:04+00:00 phase=running pct=54% bytes=32979288064 total=60108212049 target=...

Process Script 규약

process script는 target 하나를 받아 처리하는 단일 작업 실행기다.

권장 규약:

인자는 target 하나만 받는다.
성공 시 exit code 0.
실패 시 non-zero.
진행 상황을 PROCESS_STATUS_FILE 같은 status file 환경변수로 주기적으로 기록한다.
status file 갱신은 반드시 원자적으로 한다. 고정된 임시 파일명은 쓰지 말고 mktemp "${PROCESS_STATUS_FILE}.XXXXXX" 같은 고유 임시 파일에 쓴 뒤 mv -f로 교체한다.
임시 파일은 slot의 tmp/ 하위에 만든다.
작업 종료 시 가능한 한 임시 파일을 정리한다.
이미 처리된 target이라면 skip하고 성공 처리할 수 있어야 한다.
process 결과를 다음 단계로 commit/publish/write 하기 전에 결과물이 실제로 존재하고 0 byte가 아닌지 확인한다.
외부 명령을 실행해 결과 파일을 만드는 경우, stdout/stderr를 slot의 임시 로그 파일에 남기고 실패 시 worker log로 노출되게 한다.
process 내부에서 background monitor를 같이 돌릴 경우, monitor와 main process가 같은 status file을 동시에 갱신할 수 있으므로 status write helper가 concurrent-safe해야 한다.

현재 구현에서는 process script가 다음 식으로 worker에서 호출된다.

PROCESS_STATUS_FILE="${REMOTE_DIR}/status" ./process-script.sh "$target"

현재 파일명은 다음과 같다.

PROCESS_STATUS_FILE="${REMOTE_DIR}/status" ./process-target.sh "$target"

새로운 작업으로 재사용할 때는 이 script만 교체하면 master/worker queue 구조는 그대로 사용할 수 있다.

EC2 구성

현재 사용한 예시:

instance type: c8i.large
root volume: gp3
size: 1000 GiB
IOPS: 3000
throughput: 500 MB/s
worker slots per instance: 3

대량 파일 I/O 또는 큰 임시 파일을 다루는 process라면 gp3 기본 throughput은 병목이 될 수 있다. iostat로 확인하면서 throughput을 조정한다.

인스턴스 생성 예시:

aws ec2 run-instances \
  --region us-east-1 \
  --image-id "$AMI_ID" \
  --instance-type c8i.large \
  --count 10 \
  --subnet-id "$SUBNET_ID" \
  --security-group-ids "$SG_ID" \
  --iam-instance-profile Name="$PROFILE" \
  --user-data file://scripts/ec2-bootstrap-process-workers.sh \
  --block-device-mappings '[{"DeviceName":"/dev/xvda","Ebs":{"VolumeSize":1000,"VolumeType":"gp3","Iops":3000,"Throughput":500,"Encrypted":true,"DeleteOnTermination":true}}]' \
  --tag-specifications \
    'ResourceType=instance,Tags=[{Key=Name,Value=process-workers},{Key=Project,Value=process-queue}]' \
    'ResourceType=volume,Tags=[{Key=Name,Value=process-workers},{Key=Project,Value=process-queue}]' \
  --query 'Instances[].InstanceId' \
  --output text

인스턴스 목록과 Worker Slot 목록

process-workers.instances는 instance-id만 담는다.

i-aaaaaaaaaaaaaaaaa
i-bbbbbbbbbbbbbbbbb

workers는 instance-id와 slot dir을 담는다.

i-aaaaaaaaaaaaaaaaa /1
i-aaaaaaaaaaaaaaaaa /2
i-aaaaaaaaaaaaaaaaa /3
i-bbbbbbbbbbbbbbbbb /1
i-bbbbbbbbbbbbbbbbb /2
i-bbbbbbbbbbbbbbbbb /3

생성 명령:

: > workers
while read -r id; do
  printf '%s /1\n%s /2\n%s /3\n' "$id" "$id" "$id" >> workers
done < process-workers.instances

Worker 배포

process script와 worker script를 임시 위치에 올린 뒤 SSM으로 각 EC2에 배포한다.

aws s3 cp scripts/process-target.sh \
  s3://YOUR_BUCKET/_tmp/process-workers/process-target.sh \
  --region us-east-1 \
  --only-show-errors

aws s3 cp scripts/process-worker.sh \
  s3://YOUR_BUCKET/_tmp/process-workers/process-worker.sh \
  --region us-east-1 \
  --only-show-errors

배포 및 실행:

aws ssm send-command \
  --region us-east-1 \
  --instance-ids $(tr '\n' ' ' < process-workers.instances) \
  --document-name AWS-RunShellScript \
  --comment deploy-start-process-workers \
  --parameters commands='[
    "set -euo pipefail",
    "for d in /1 /2 /3; do mkdir -p \"$d/logs\" \"$d/tmp\"; aws s3 cp s3://YOUR_BUCKET/_tmp/process-workers/process-target.sh \"$d/process-target.sh\" --region us-east-1 --only-show-errors; aws s3 cp s3://YOUR_BUCKET/_tmp/process-workers/process-worker.sh \"$d/process-worker.sh\" --region us-east-1 --only-show-errors; chmod +x \"$d/process-target.sh\" \"$d/process-worker.sh\"; touch \"$d/next\" \"$d/completed\" \"$d/failed\"; done",
    "for d in /1 /2 /3; do if ! pgrep -af \"REMOTE_DIR=$d .*process-worker.sh\" >/dev/null; then nohup bash -lc \"REMOTE_DIR=$d AWS_REGION=us-east-1 $d/process-worker.sh\" >> \"$d/logs/worker.log\" 2>&1 & fi; done",
    "sleep 2",
    "pgrep -af process-worker.sh | wc -l"
  ]' \
  --query 'Command.CommandId' \
  --output text

주의:

local에 있는 파일명과 EC2에 배포되는 파일명은 worker script 내부 호출명과 일치해야 한다.
범용화하려면 worker script 내부의 process script 파일명도 같이 변경한다.

모니터링

watch -n 5 'WORKERS_FILE=workers ./monitor-process-workers.sh'

monitor는 다음 방식으로 동작한다.

workers를 instance-id 기준으로 그룹화한다.
인스턴스마다 SSM command 1개를 보낸다.
여러 인스턴스는 병렬로 조회한다.
각 slot의 next, completed, failed, status를 출력한다.
인스턴스 단위 CPU, RX/s, TX/s를 함께 출력한다.
리소스 지표는 SSM command 내부에서 약 1초 샘플링하므로 monitor 실행 시간이 1초 정도 늘어난다.

출력 예시:

INSTANCE               DIR          NEXT  COMPLETED   FAILED     CPU       RX/s       TX/s  STATUS
i-xxx                  /1              2        100        0   82.4%  120.0MB/s   40.0MB/s  2026-04-28T06:49:04+00:00 phase=running pct=54% target=...
i-xxx                  /2              0        103        1   82.4%  120.0MB/s   40.0MB/s  2026-04-28T06:49:03+00:00 phase=idle next=0

TOTAL next=20 completed=1676 failed=5

NEXT는 아직 실행에 들어가지 않은 remote 대기 target 수다. 현재 실행 중인 target은 NEXT에 포함되지 않는다.

CPU, RX/s, TX/s는 같은 인스턴스의 모든 slot 행에 동일하게 표시된다.

상태 Phase

process script가 어떤 phase를 기록할지는 작업마다 다르다. 권장 phase는 다음과 같다.

phase	의미
`idle`	worker가 대기 중이다.
`preparing`	process 실행 준비 중이다.
`running`	실제 process 실행 중이다.
`committing`	결과를 최종 위치나 다음 단계로 반영하는 중이다.
`done`	성공 완료.
`skipped`	이미 처리된 target이라 건너뜀.
`failed`	실패.

현재 process script가 더 구체적인 phase를 출력해도 monitor는 그대로 문자열로 보여준다.

로그와 파일

로컬:

target_process.queue
target_process.queue.lock
target_process.dispatched
target_process.dispatched.lock
logs/master.log          # background 실행 시 선택

remote slot:

/N/next
/N/next.lock
/N/completed
/N/failed
/N/status
/N/logs/worker.log
/N/tmp/

dispatch audit log 형식:

timestamp instance-id remote-dir target

중단과 복구

Master 중단

foreground 실행 중이면:

Ctrl-C

master를 멈춰도 remote next에 들어간 작업과 현재 실행 중인 worker는 계속 진행된다.

Worker 강제 중단

인스턴스를 종료하거나 작업 구조를 바꿀 때는 먼저 remote에 남은 작업을 회수하는 것이 안전하다.

worker 프로세스 중단 예시:

aws ssm send-command \
  --region us-east-1 \
  --instance-ids INSTANCE_ID \
  --document-name AWS-RunShellScript \
  --comment stop-process-workers \
  --parameters commands='[
    "set -euo pipefail",
    "pkill -f process-target.sh || true",
    "pkill -f process-worker.sh || true"
  ]' \
  --query 'Command.CommandId' \
  --output text

process command line에 민감한 값이 포함될 수 있으므로, 운영 중 pgrep -af, ps aux 출력은 주의한다.

Remote Next 회수

아직 실행에 들어가지 않은 target은 각 slot의 next에 있다. 인스턴스를 종료하기 전에 이 파일을 읽어 local queue로 되돌린다.

수집 예시:

aws ssm send-command \
  --region us-east-1 \
  --instance-ids INSTANCE_ID \
  --document-name AWS-RunShellScript \
  --comment collect-worker-queues \
  --parameters commands='[
    "set -euo pipefail",
    "for d in /1 /2 /3; do echo \"###DIR $d\"; sed \"s/^/NEXT /\" \"$d/next\" 2>/dev/null || true; done"
  ]' \
  --query 'Command.CommandId' \
  --output text

회수한 target을 recovered-inflight 같은 파일로 저장한 뒤 local queue 앞에 중복 없이 붙인다.

cp target_process.queue "target_process.queue.bak.$(date +%Y%m%d%H%M%S)"

awk 'NR==FNR { if (!seen[$0]++) print; next } { if (!seen[$0]++) print }' \
  recovered-inflight \
  target_process.queue \
  > target_process.queue.new

mv target_process.queue.new target_process.queue

Remote Next 재분배

작업 후반에는 무거운 target이 특정 EC2나 특정 slot에 몰릴 수 있다. 이때 현재 실행 중인 target은 건드리지 않고, 아직 실행 전인 next만 뽑아 idle slot에 다시 나눠 넣을 수 있다.

절차:

master를 중단한다.
monitor로 idle slot과 next가 몰린 slot을 확인한다.
모든 remote next를 flock으로 drain한다.
drain된 target을 idle slot에 round-robin으로 append한다.
monitor로 분배 결과를 확인한다.

재분배 시 남겨두면 좋은 기록:

rebalanced-process-next.YYYYMMDDHHMMSS.status.tsv
rebalanced-process-next.YYYYMMDDHHMMSS.idle-slots.tsv
rebalanced-process-next.YYYYMMDDHHMMSS.drained.tsv
rebalanced-process-next.YYYYMMDDHHMMSS.assignments.tsv

실패 Target 처리

각 slot의 실패 target은 다음 파일에 남는다.

/N/failed

운영 방식:

monitor의 FAILED 총합을 확인한다.
SSM으로 모든 /1/failed, /2/failed, /3/failed를 수집한다.
실패 원인을 확인한다.
재시도할 target만 local queue에 다시 넣는다.

실패 분석 시 같이 확인할 것:

/N/failed: 실패 target 목록.
/N/logs/worker.log: START, process stderr/stdout, FAIL 주변 로그.
/N/status: 마지막 상태. 단, 재시도나 다음 작업으로 덮였을 수 있으므로 단독 근거로 보지 않는다.
외부 시스템이나 결과물을 사용하는 process라면 input target 존재 여부와 output/result 존재 여부.

자주 발생할 수 있는 구현 이슈:

status.$$처럼 PID 기반 고정 임시 파일명을 쓰면 background monitor와 main process가 같은 파일을 건드려 mv: cannot stat ... 형태의 race가 날 수 있다. mktemp 기반 고유 파일명으로 원자 갱신해야 한다.
결과물 생성 명령이 성공하지 않았는데 commit/publish/write 단계로 넘어가면 path does not exist류 실패가 날 수 있다. 다음 단계로 넘기기 전 test -s "$output_file" 같은 검증을 넣고, 생성 명령 로그를 남겨야 한다.
재시도 성공 후에도 기존 /N/failed 파일의 줄 수는 자동으로 줄지 않는다. monitor의 FAILED 총합은 누적 실패 기록이다. 재시도 성공 여부는 output 존재 여부나 retry 후 completed 기록으로 별도 확인한다.

재시도 방법:

실패 target을 로컬 파일로 모은다.
output이 이미 만들어진 target은 제외한다.
idle slot이 있으면 그 slot의 next에 넣는다.
idle slot이 없으면 NEXT가 가장 작은 slot에 append해서 현재 작업이 끝난 뒤 실행되게 한다.
append는 remote next.lock을 잡고 수행한다.

운영 체크리스트

process target 목록을 만든다.
local queue 파일을 준비한다.
EC2 인스턴스를 생성한다.
process-workers.instances를 작성한다.
workers를 생성한다.
모든 인스턴스가 SSM Online인지 확인한다.
process script와 worker script를 배포한다.
모든 worker slot이 idle인지 확인한다.
master refill을 foreground로 실행한다.
monitor를 별도 터미널에서 실행한다.
local queue가 0이 된 뒤에도 remote next와 active target이 남아 있을 수 있으므로 monitor를 계속 본다.
heavy target이 몰리면 remote next만 재분배한다.
실패 target을 수집하고 필요하면 재시도한다.
완료 후 EC2를 종료한다.

유용한 명령

SSM Online 확인:

aws ssm describe-instance-information \
  --region us-east-1 \
  --filters Key=InstanceIds,Values=$(paste -sd, process-workers.instances) \
  --query 'InstanceInformationList[].{InstanceId:InstanceId,PingStatus:PingStatus,AgentVersion:AgentVersion}' \
  --output table

EC2 상태:

aws ec2 describe-instances \
  --region us-east-1 \
  --instance-ids $(tr '\n' ' ' < process-workers.instances) \
  --query 'Reservations[].Instances[].{InstanceId:InstanceId,State:State.Name,Type:InstanceType,AZ:Placement.AvailabilityZone,PrivateIp:PrivateIpAddress}' \
  --output table

볼륨 설정:

vols=$(
  aws ec2 describe-instances \
    --region us-east-1 \
    --instance-ids $(tr '\n' ' ' < process-workers.instances) \
    --query 'Reservations[].Instances[].BlockDeviceMappings[].Ebs.VolumeId' \
    --output text
)

aws ec2 describe-volumes \
  --region us-east-1 \
  --volume-ids $vols \
  --query 'Volumes[].{VolumeId:VolumeId,Size:Size,Type:VolumeType,Iops:Iops,Throughput:Throughput,State:State}' \
  --output table

I/O 확인:

aws ssm send-command \
  --region us-east-1 \
  --instance-ids INSTANCE_ID \
  --document-name AWS-RunShellScript \
  --comment inspect-io \
  --parameters commands='[
    "set -euo pipefail",
    "df -h /1 /2 /3",
    "iostat -xm 1 5 2>/dev/null || true"
  ]' \
  --query 'Command.CommandId' \
  --output text

인스턴스 종료:

aws ec2 terminate-instances \
  --region us-east-1 \
  --instance-ids $(tr '\n' ' ' < process-workers.instances)

샘플 구현

아래 샘플은 실제 업무 로직을 숨긴 범용 process queue 예제다. process target은 한 줄 단위 record이고, worker는 이 record를 하나씩 pop해서 process script에 넘긴다. 샘플 process는 실제 작업 대신 record를 print하고 잠깐 sleep한다.

Queue Record 형식

가장 단순한 형태는 한 줄 문자열이다.

target-001
target-002
target-003

TSV를 쓰면 shell에서 다루기 쉽다.

target-001    tenant-a    2026-04-01    {"priority":"high"}
target-002    tenant-b    2026-04-02    {"priority":"normal"}
target-003    tenant-c    2026-04-03    {"priority":"low"}

NDJSON을 쓰면 구조화된 데이터를 그대로 전달하기 쉽다.

{"id":"target-001","tenant":"tenant-a","date":"2026-04-01","priority":"high"}
{"id":"target-002","tenant":"tenant-b","date":"2026-04-02","priority":"normal"}
{"id":"target-003","tenant":"tenant-c","date":"2026-04-03","priority":"low"}

중요한 제약:

record 하나는 반드시 한 줄이어야 한다.
worker는 줄 단위로 pop한다.
TSV/NDJSON 안에 literal newline이 들어가면 안 된다.
공백이 포함될 수 있으므로 shell에서 record를 항상 quote한다.

`scripts/process-target.sh`

target 하나를 받아 실제 process를 수행하는 스크립트다. 여기서는 record를 출력만 한다.

#!/usr/bin/env bash
set -euo pipefail

if [ "$#" -ne 1 ]; then
  echo "Usage: $0 '<record>'" >&2
  exit 2
fi

record="$1"
status_file="${PROCESS_STATUS_FILE:-}"

write_status() {
  [ -n "$status_file" ] || return 0
  mkdir -p "$(dirname "$status_file")"
  tmp="$(mktemp "${status_file}.XXXXXX")"
  if printf "%s\n" "$(date -Is) $*" > "$tmp"; then
    mv -f "$tmp" "$status_file"
  else
    rm -f "$tmp"
    return 1
  fi
}

write_status "phase=running target=$record"
echo "$(date -Is) PROCESS record=$record"

# 실제 업무 로직은 여기에 둔다.
# TSV라면 예: IFS=$'\t' read -r id tenant date meta <<< "$record"
# NDJSON이라면 예: id=$(jq -r '.id' <<< "$record")
sleep "${PROCESS_SLEEP_SECONDS:-2}"

write_status "phase=done target=$record"
echo "$(date -Is) PROCESS_DONE record=$record"

`scripts/process-worker.sh`

EC2의 slot 디렉토리 하나에서 계속 실행되는 worker loop다.

#!/usr/bin/env bash
set -euo pipefail

REMOTE_DIR="${REMOTE_DIR:-/work/process-worker}"
IDLE_SLEEP_SECONDS="${IDLE_SLEEP_SECONDS:-10}"
PROCESS_SCRIPT="${PROCESS_SCRIPT:-./process-target.sh}"

cd "$REMOTE_DIR"
mkdir -p logs tmp
touch next completed failed next.lock

if [ ! -x "$PROCESS_SCRIPT" ]; then
  echo "missing executable: ${REMOTE_DIR}/${PROCESS_SCRIPT}" >&2
  exit 127
fi

pop_next() {
  flock next.lock bash -c '
    target="$(head -n 1 next 2>/dev/null || true)"
    [ -n "$target" ] || exit 1
    tail -n +2 next > next.tmp
    mv next.tmp next
    printf "%s\n" "$target"
  '
}

echo "$(date -Is) worker started in $REMOTE_DIR"

while true; do
  if target="$(pop_next)"; then
    echo "$(date -Is) START $target"
    if PROCESS_STATUS_FILE="${REMOTE_DIR}/status" "$PROCESS_SCRIPT" "$target"; then
      echo "$target" >> completed
      echo "$(date -Is) DONE  $target"
    else
      echo "$target" >> failed
      echo "$(date -Is) FAIL  $target"
    fi
  else
    tmp="$(mktemp "${REMOTE_DIR}/status.XXXXXX")"
    printf "%s\n" "$(date -Is) phase=idle next=$(wc -l < next 2>/dev/null || echo 0)" > "$tmp"
    mv -f "$tmp" status
    sleep "$IDLE_SLEEP_SECONDS"
  fi
done

`scripts/process-master-refill.sh`

로컬에서 실행되는 master refill 샘플이다. 같은 instance-id의 여러 slot을 한 번에 조회하고, 인스턴스들은 병렬로 처리한다.

#!/usr/bin/env bash
set -euo pipefail

AWS_REGION="${AWS_REGION:-us-east-1}"
WORKERS_FILE="${WORKERS_FILE:-workers}"
QUEUE_FILE="${QUEUE_FILE:-target_process.queue}"
DISPATCHED_FILE="${DISPATCHED_FILE:-target_process.dispatched}"
MAX_NEXT="${MAX_NEXT:-5}"
INTERVAL_SECONDS="${INTERVAL_SECONDS:-10}"
REFILL_PARALLELISM="${REFILL_PARALLELISM:-20}"
LOCK_FILE="${LOCK_FILE:-${QUEUE_FILE}.lock}"
ONCE="${ONCE:-0}"

touch "$QUEUE_FILE" "$DISPATCHED_FILE"

json_commands() {
  python3 - "$@" <<'PY'
import json
import sys
print("commands=" + json.dumps(list(sys.argv[1:])))
PY
}

wait_command() {
  local instance_id="$1"
  local command_id="$2"
  local status

  while true; do
    status="$(
      aws ssm get-command-invocation \
        --region "$AWS_REGION" \
        --instance-id "$instance_id" \
        --command-id "$command_id" \
        --query Status \
        --output text 2>/dev/null || true
    )"

    case "$status" in
      Success|Failed|Cancelled|TimedOut|Cancelling)
        printf "%s\n" "$status"
        return 0
        ;;
      Pending|InProgress|Delayed|"")
        sleep 1
        ;;
    esac
  done
}

worker_instances() {
  awk '
    NF && $1 !~ /^#/ {
      if (!seen[$1]++) order[++n] = $1
      dirs[$1] = dirs[$1] " " $2
    }
    END {
      for (i = 1; i <= n; i++) {
        id = order[i]
        sub(/^ /, "", dirs[id])
        print id "\t" dirs[id]
      }
    }
  ' "$WORKERS_FILE"
}

pop_local_targets() {
  local count="$1"
  flock "$LOCK_FILE" bash -c '
    count="$1"
    queue="$2"
    [ "$count" -gt 0 ] || exit 0
    [ -s "$queue" ] || exit 0
    head -n "$count" "$queue"
    tail -n +"$((count + 1))" "$queue" > "${queue}.tmp"
    mv "${queue}.tmp" "$queue"
  ' bash "$count" "$QUEUE_FILE"
}

refill_instance_once() {
  local instance_id="$1"
  local remote_dirs="$2"
  local cmd_id status output refill_file encoded

  cmd_id="$(
    aws ssm send-command \
      --region "$AWS_REGION" \
      --instance-ids "$instance_id" \
      --document-name AWS-RunShellScript \
      --comment process-next-counts \
      --parameters "$(
        json_commands \
          "set -euo pipefail" \
          "for d in $remote_dirs; do mkdir -p \"\$d\"; touch \"\$d/next\"; printf '%s\t%s\n' \"\$d\" \"\$(wc -l < \"\$d/next\" 2>/dev/null || echo 0)\"; done"
      )" \
      --query 'Command.CommandId' \
      --output text
  )"

  status="$(wait_command "$instance_id" "$cmd_id")"
  [ "$status" = "Success" ] || return 0

  output="$(
    aws ssm get-command-invocation \
      --region "$AWS_REGION" \
      --instance-id "$instance_id" \
      --command-id "$cmd_id" \
      --query StandardOutputContent \
      --output text
  )"

  refill_file="$(mktemp)"
  while IFS=$'\t' read -r remote_dir count; do
    [ -n "${remote_dir:-}" ] || continue
    need=$((MAX_NEXT - count))
    [ "$need" -gt 0 ] || continue
    payload="$(pop_local_targets "$need" || true)"
    [ -n "$payload" ] || continue
    while IFS= read -r target; do
      [ -n "$target" ] || continue
      printf "%s\t%s\n" "$remote_dir" "$target" >> "$refill_file"
    done <<< "$payload"
  done <<< "$output"

  if [ ! -s "$refill_file" ]; then
    rm -f "$refill_file"
    return 0
  fi

  encoded="$(base64 -w0 "$refill_file")"
  cmd_id="$(
    aws ssm send-command \
      --region "$AWS_REGION" \
      --instance-ids "$instance_id" \
      --document-name AWS-RunShellScript \
      --comment process-next-refill \
      --parameters "$(
        json_commands \
          "set -euo pipefail" \
          "printf '%s' '$encoded' | base64 -d > /tmp/process-refill.tsv" \
          "while IFS=\$(printf '\t') read -r d target; do [ -n \"\$d\" ] || continue; [ -n \"\$target\" ] || continue; mkdir -p \"\$d\"; touch \"\$d/next\" \"\$d/next.lock\"; exec 9>>\"\$d/next.lock\"; flock 9; printf '%s\n' \"\$target\" >> \"\$d/next\"; flock -u 9; exec 9>&-; done < /tmp/process-refill.tsv" \
          "rm -f /tmp/process-refill.tsv"
      )" \
      --query 'Command.CommandId' \
      --output text
  )"

  status="$(wait_command "$instance_id" "$cmd_id")"
  if [ "$status" = "Success" ]; then
    awk -F '\t' -v ts="$(date -Is)" -v instance="$instance_id" '{ print ts "\t" instance "\t" $1 "\t" $2 }' "$refill_file" >> "$DISPATCHED_FILE"
    echo "$(date -Is) refilled instance=$instance_id added=$(wc -l < "$refill_file")"
  else
    cut -f2- "$refill_file" | cat - "$QUEUE_FILE" > "${QUEUE_FILE}.returned"
    mv "${QUEUE_FILE}.returned" "$QUEUE_FILE"
  fi
  rm -f "$refill_file"
}

refill_once() {
  echo "$(date -Is) queue_remaining=$(wc -l < "$QUEUE_FILE")"
  pids=()
  active=0
  while IFS=$'\t' read -r instance_id remote_dirs; do
    refill_instance_once "$instance_id" "$remote_dirs" &
    pids+=("$!")
    active=$((active + 1))
    if [ "$active" -ge "$REFILL_PARALLELISM" ]; then
      wait "${pids[0]}" || true
      pids=("${pids[@]:1}")
      active=$((active - 1))
    fi
  done < <(worker_instances)
  for pid in "${pids[@]}"; do wait "$pid" || true; done
}

while true; do
  refill_once
  [ "$ONCE" = "1" ] && exit 0
  sleep "$INTERVAL_SECONDS"
done

`monitor-process-workers.sh`

간단한 monitor 샘플이다. 인스턴스별로 /1 /2 /3를 한 번에 조회하고, 여러 인스턴스는 병렬로 조회한다.

#!/usr/bin/env bash
set -euo pipefail

AWS_REGION="${AWS_REGION:-us-east-1}"
WORKERS_FILE="${WORKERS_FILE:-workers}"

json_commands() {
  python3 - "$@" <<'PY'
import json
import sys
print("commands=" + json.dumps(list(sys.argv[1:])))
PY
}

worker_instances() {
  awk '
    NF && $1 !~ /^#/ {
      if (!seen[$1]++) order[++n] = $1
      dirs[$1] = dirs[$1] " " $2
    }
    END {
      for (i = 1; i <= n; i++) {
        id = order[i]
        sub(/^ /, "", dirs[id])
        print id "\t" dirs[id]
      }
    }
  ' "$WORKERS_FILE"
}

monitor_instance() {
  local instance_id="$1"
  local remote_dirs="$2"
  local cmd_id status output

  cmd_id="$(
    aws ssm send-command \
      --region "$AWS_REGION" \
      --instance-ids "$instance_id" \
      --document-name AWS-RunShellScript \
      --comment process-worker-status \
      --parameters "$(
        json_commands \
          "set -euo pipefail" \
          "read_cpu() { awk '/^cpu / { total=0; for (i=2; i<=NF; i++) total+=\$i; print total, \$5 }' /proc/stat; }" \
          "read_net() { awk -F'[: ]+' '\$2 != \"lo\" { rx+=\$3; tx+=\$11 } END { print rx+0, tx+0 }' /proc/net/dev; }" \
          "human_rate() { awk -v b=\"\$1\" 'BEGIN { split(\"B/s KB/s MB/s GB/s TB/s\", u); i=1; while (b >= 1024 && i < 5) { b/=1024; i++ } printf \"%.1f%s\", b, u[i] }'; }" \
          "read cpu_total_1 cpu_idle_1 < <(read_cpu)" \
          "read rx_1 tx_1 < <(read_net)" \
          "sleep 1" \
          "read cpu_total_2 cpu_idle_2 < <(read_cpu)" \
          "read rx_2 tx_2 < <(read_net)" \
          "cpu_pct=\$(awk -v t1=\"\$cpu_total_1\" -v i1=\"\$cpu_idle_1\" -v t2=\"\$cpu_total_2\" -v i2=\"\$cpu_idle_2\" 'BEGIN { dt=t2-t1; di=i2-i1; if (dt <= 0) printf \"0.0%%\"; else printf \"%.1f%%\", (dt-di)*100/dt }')" \
          "rx_rate=\$(human_rate \$((rx_2 - rx_1)))" \
          "tx_rate=\$(human_rate \$((tx_2 - tx_1)))" \
          "for d in $remote_dirs; do if ! cd \"\$d\" 2>/dev/null; then printf '%s\t%s\t%s\t%s\t%s\t%s\t%s\t%s\n' \"\$d\" '-' '-' '-' \"\$cpu_pct\" \"\$rx_rate\" \"\$tx_rate\" 'MISSING_DIR'; continue; fi; next=\$(wc -l < next 2>/dev/null || echo 0); completed=\$(wc -l < completed 2>/dev/null || echo 0); failed=\$(wc -l < failed 2>/dev/null || echo 0); status=\$(cat status 2>/dev/null || echo no-status); printf '%s\t%s\t%s\t%s\t%s\t%s\t%s\t%s\n' \"\$d\" \"\$next\" \"\$completed\" \"\$failed\" \"\$cpu_pct\" \"\$rx_rate\" \"\$tx_rate\" \"\$status\"; done"
      )" \
      --query 'Command.CommandId' \
      --output text
  )"

  while true; do
    status="$(
      aws ssm get-command-invocation \
        --region "$AWS_REGION" \
        --instance-id "$instance_id" \
        --command-id "$cmd_id" \
        --query Status \
        --output text 2>/dev/null || true
    )"
    case "$status" in Success|Failed|Cancelled|TimedOut|Cancelling) break ;; esac
    sleep 1
  done

  output="$(
    aws ssm get-command-invocation \
      --region "$AWS_REGION" \
      --instance-id "$instance_id" \
      --command-id "$cmd_id" \
      --query StandardOutputContent \
      --output text 2>/dev/null || true
  )"

  while IFS=$'\t' read -r dir next completed failed cpu_pct rx_rate tx_rate status_line; do
    [ -n "${dir:-}" ] || continue
    printf "%s\t%s\t%s\t%s\t%s\t%s\t%s\t%s\t%s\n" "$instance_id" "$dir" "$next" "$completed" "$failed" "$cpu_pct" "$rx_rate" "$tx_rate" "$status_line"
  done <<< "$output"
}

tmp_dir="$(mktemp -d)"
trap 'rm -rf "$tmp_dir"' EXIT

i=0
while IFS=$'\t' read -r instance_id remote_dirs; do
  [ -n "${instance_id:-}" ] || continue
  i=$((i + 1))
  monitor_instance "$instance_id" "$remote_dirs" > "$tmp_dir/$i.out" &
done < <(worker_instances)
wait

printf "%-22s %-8s %8s %10s %8s %7s %10s %10s  %s\n" "INSTANCE" "DIR" "NEXT" "COMPLETED" "FAILED" "CPU" "RX/s" "TX/s" "STATUS"
total_next=0
total_completed=0
total_failed=0

for f in "$tmp_dir"/*.out; do
  [ -e "$f" ] || continue
  while IFS=$'\t' read -r instance_id dir next completed failed cpu_pct rx_rate tx_rate status_line; do
    [[ "$next" =~ ^[0-9]+$ ]] && total_next=$((total_next + next))
    [[ "$completed" =~ ^[0-9]+$ ]] && total_completed=$((total_completed + completed))
    [[ "$failed" =~ ^[0-9]+$ ]] && total_failed=$((total_failed + failed))
    printf "%-22s %-8s %8s %10s %8s %7s %10s %10s  %s\n" "$instance_id" "$dir" "$next" "$completed" "$failed" "$cpu_pct" "$rx_rate" "$tx_rate" "$status_line"
  done < "$f"
done

echo
echo "TOTAL next=$total_next completed=$total_completed failed=$total_failed"

샘플 실행 흐름

# 1. queue 준비
cat > target_process.queue <<'EOF'
target-001    tenant-a    2026-04-01    {"priority":"high"}
target-002    tenant-b    2026-04-02    {"priority":"normal"}
target-003    tenant-c    2026-04-03    {"priority":"low"}
EOF

# 2. workers 파일 준비
: > workers
while read -r id; do
  printf '%s /1\n%s /2\n%s /3\n' "$id" "$id" "$id" >> workers
done < process-workers.instances

# 3. worker 배포 후 master 실행
WORKERS_FILE=workers \
QUEUE_FILE=target_process.queue \
MAX_NEXT=5 \
REFILL_PARALLELISM=10 \
INTERVAL_SECONDS=10 \
scripts/process-master-refill.sh

# 4. 별도 터미널에서 monitor
watch -n 5 'WORKERS_FILE=workers ./monitor-process-workers.sh'

2026-04 월 적립식 투자

bitofsky — Wed, 8 Apr 2026 13:33:16 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

hbs.pe.kr

2회+ 연속 음봉 = x4+를 TQQQ 매수

전쟁이 격화되고있다. 많이 내려온 TQQQ를 4배수로 매수했다.

2026-03 월 적립식 투자

bitofsky — Tue, 10 Mar 2026 22:07:24 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

hbs.pe.kr

1회 전월 음봉 = x1를 SCHD, 1x를 TQQQ 매수

SCHD는 계속 상승중이고, 나스닥이 이란 전쟁여파로 내리막중이다.

26년 1~2월간 기록적인 SCHD 상승률 덕에 계좌가 빵빵하다.

안먹어도 배부를정도...

새해니 연금저축펀드, IRP, ISA를 새롭게 한도까지 채우기 시작한다.

ISA는 3년 만기가 되어 만기해지 후 연저펀 1,2 계좌에 분산하여 납입했다.

연금은 IRP와 합쳐 1년에 1800까지밖에 불입이 불가능하지만 ISA 만기자금의 경우 예외로 만기 금액의 100%를 불입시켜준다.

이를 통해 세금이연을 누리면서 투자를 이어나갈 수 있다.

2026-02 월 적립식 투자

bitofsky — Sat, 7 Feb 2026 10:52:46 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

hbs.pe.kr

1회 전월 양봉 = x1를 SCHD 매수

SCHD의 기록적인 상승이다.

사실 어느정도 예견되어있었다. 확실한 배당만 주는 100개주식을 모아둔 ETF인데 배당률이 최근 4%에 육박할 정도로 주가가 억눌려있었다. SCHD의 평균은 3% 초중반까지다. 명백한 저평가 구간이며 이를 기반한 상승 여력이 30%에 달했다.

나스닥과 AI 관련 기술주 위주의 테마쪽으로만 자금이 쏠려 가치주가 억눌려있었던 것인데, 이제 순환매로 눌려있던 가치주로 자금이 흘러들어온다.

사람들은 주가가 눌려있는것이 안좋다고 생각한다.
하지만 배당주는 다르다. 회사의 이익잉여금 기반으로 배당을 하니, 저렴하게 살 수 있다면 무조건 이익이다.

1주마다 100원을 주는 주식을 1000원에 팔다가 500원에 팔면 바겐세일인거다. 왜냐면 배당은 100원 그대로도 아니고 오히려 늘어나 101원으로 늘어가니까.. 레버리지, 커버드콜이 끼어있지 않은 순수 1배짜리 배당 ETF는 배당률과 배당금을 보고 수량만 모아가면 된다.

SCHD의 20년간 연평균 토탈리턴은 약 10% 전후로, 최근 눌려있던 주가 상황을 감안하면 거의 배당액(3%) 수준으로 눌려있고 반대로 말하면 한번에 크게 상승할 타이밍이 다가오고 있었고, 이를 위해 수량을 많이 모아두고있는 상황이었다.

뭐, 될거같으니까 룰을 만들어 오래 모아오고 있는데 막상 이뤄지니 재밌네.

배당주 특징은 기록적인 MDD가 -10~-20% 수준으로, QQQ나 S&P500 같은 -50~-60% 보다 훨씬 낮다.
즉, 여기서 폭락장이 발생해도 내 수익률이 음전할 가능성이 이젠 없다는 말이다.

그야말로 목돈을 집어넣고 굴리기에 이것보다 최적인 상황이 있을까..?

재태크는 재정으로 인생의 방향을 결정하는 일이다. 인생의 방향을 좌지우지 하려면 작은 금액으로 100%, 1000%하는것은 의미가 없고, 로또식 운에 맡기는 식으로 전재산을 굴릴 수도 없다.

작은 수익률도 큰 금액으로 움직일 수 있게 크게 굴리면서, 따라오는 리스크는 시간에 녹여 상쇄시켜야한다. 시간을 줄이려는것은 리스크를 안는다는 것이다. 반대로, 시간을 늘리면 리스크는 한없이 사라지며 거의 확정적인 수익률 그래프를 따라가도록 셋팅할 수 있다.

장기투자에서 필요한 것은 인내심이고 그것이 가장 어려운 것이다.

ZZZ 강습전 모독자 킬 (빛아자)

bitofsky — Thu, 22 Jan 2026 08:40:58 +0900

아스트라 1돌파 꽝꽝이. 디스크 셋팅을 고요에서 달빛 4로 변경

자오 전무에 고요 4셋

엽빛나 2돌 전무

2026-01 월 적립식 투자

bitofsky — Thu, 8 Jan 2026 15:12:32 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

매수 규칙이 11월부터 변경되었다. (기존 규칙 LINK)월 적립식 투자규칙매월 1일 매매SCHD, TQQQ를 기계식 매수SCHD를 적립하면서 동시에 QQQ의 양/음봉 여부에 따른 SCHD, TQQQ 선택 매매1회 전월 양봉 = x1

hbs.pe.kr

1회 전월 음봉 = x1를 SCHD, 1x를 TQQQ 매수

원래 지난달이 음봉이었는데 실수했다. 이번달은 슈드와 나스닥 레버리지를 매수했다.
주식 계좌는 폭발적으로 성장하고있다.
적립식 투자인데도 현재 28%가량 토탈리턴 수익률을 기록중인데, 초기 자금의 거치식 수익률로 환산해보면 거의 50%를 넘는 상태라고 볼 수 있다.

회사 일로 계속 스트레스 받는 상황이다.
내가 내린 결정, 과연 옳은 결정인가? 아닌가? 앞날을 한치 앞도 예측할 수 없다.
내년 이맘때쯤 다시 지금을 되돌아보고 소회를 남겨봐야겠다.

Databricks SQL을 위한 경량 Node.js 클라이언트 라이브러리 개발기

bitofsky — Mon, 5 Jan 2026 12:10:11 +0900

들어가며

MCP (Model Context Protocol) Server를 개발하면서 Databricks SQL로 대용량 데이터셋을 쿼리해야 하는 요구사항이 들어왔습니다. 자연스럽게 공식 Databricks Node.js SDK를 사용하려 했지만, 곧 문제에 부딪혔습니다. 대용량 결과를 처리할 방법이 없었습니다.

이 글에서는 이 문제를 해결하기 위해 두 개의 라이브러리(@bitofsky/merge-streams, @bitofsky/databricks-sql)를 개발한 과정과, 그 과정에서 얻은 인사이트를 공유하고자 합니다.

문제: SDK External Links 미지원

SDK에선 fetchChunk로 대량 result set을 부분적으로 처리하도록 callback을 제공하지만, 대량 데이터를 MCP Client로 이렇게 내려줄 수는 없습니다. 이를 위해선 External Links가 필요하지만 이는 SDK에서 지원되지 않으며 API에서만 사용이 가능합니다.

API INLINE vs EXTERNAL_LINKS

Databricks Statement Execution API는 쿼리 결과를 반환하는 두 가지 방식을 제공합니다:

INLINE 방식

// 전체 결과가 응답에 포함됨
{
  "result": {
    "data_array": [
      [1, "Alice", 30],
      [2, "Bob", 25],
      // ... 모든 행
    ]
  }
}

제한사항: 최대 25MB까지만 지원

이 방식의 문제는 명확합니다:

25MB 이상의 결과는 받을 수 없음

EXTERNAL_LINKS 방식

// 결과가 여러 청크로 분할되어 presigned URL로 제공됨
{
  "result": {
    "external_links": [
      { "external_link": "https://s3.../chunk_0.json", ... },
      { "external_link": "https://s3.../chunk_1.json", ... },
      // ... 수십~수백 개의 청크
    ]
  }
}

제한사항: 최대 100GB까지 지원 (INLINE의 4000배!)

이 방식의 장점:

대용량 결과 처리 가능 (최대 100GB)
메모리 효율적 (스트리밍 처리)
각 청크를 병렬로 다운로드 가능

선택의 기로

두 가지 선택지가 있었습니다:

SDK를 사용하고 큰 Result 결과를 포기
Databricks API를 직접 구현하여 External Links 사용

MCP Server의 요구사항을 생각해보니:

수백만 건의 레코드를 다뤄야 함
Databricks가 지원하는 최대 100GB까지 반환 가능하게 하고 싶음

선택은 명확했습니다. Databricks API를 사용한 라이브러리를 직접 구현하기로 결정했습니다.
직접 구현된 라이브러리를 사용하면서 공식 SDK도 병행하게 되면 유지보수가 복잡해질 수 있기 때문에, 라이브러리는 공식 SDK의 거의 모든 기능을 대체하도록 설계했습니다.

쿼리 실행 및 Statement 상태 추적
결과 스트리밍
에러 처리 & 자동 재시도
Result Set 파싱

새로운 문제: 청크 지옥

Databricks API를 직접 구현하니 External Links를 사용할 수 있게 되었습니다. 하지만 새로운 문제가 나타났습니다.

chunk_0.arrow (presigned URL)
chunk_1.arrow (presigned URL)
chunk_2.arrow (presigned URL)
...
chunk_89.arrow (presigned URL)

100만 건 쿼리 결과가 90개의 청크로 쪼개져 왔습니다. 이제 무엇을 해야 할까요?

90개의 URL을 클라이언트에 그대로 전달?
- 90개의 Presigned URL이 LLM Context를 순식간에 고갈시킴
- 클라이언트가 90번의 HTTP 요청을 해야 함
- 각 청크를 순서대로 올바르게 병합하거나 고려하여 쿼리해야 함
- 포맷별 처리 로직 필요 (CSV 헤더? JSON 배열? Arrow EOS 마커?)
서버에서 순서와 포멧을 유지한 올바른 병합 후 단일 URL 제공?
- 훨씬 나은 사용자 경험
- 하지만 직접 구현해야 함

명백히 두 번째가 더 나은 선택이었습니다.

또 다른 문제: 압축 미지원

서버에서 병합하기로 결정했지만, 곧 또 다른 제약을 발견했습니다. Databricks의 External Links는 압축을 지원하지 않습니다.

External Links는 최대 100GB까지 지원하지만, 모두 압축되지 않은 상태입니다:

chunk_0.csv (20MB, 압축되지 않음)
chunk_1.csv (20MB, 압축되지 않음)
...
chunk_89.csv (20MB, 압축되지 않음)

총 크기: 1.8GB (최대 100GB까지 가능)

SQL 쿼리 결과는 대부분 문자열 데이터입니다. 이런 데이터는 압축률이 매우 높습니다:

CSV: 컬럼명 반복, 유사한 패턴
JSON: 키 이름 반복, 공백 문자
실제 압축률: 평균 1/10 이하

클라이언트에게 1.8GB 파일을 다운로드하게 할 것인가, 아니면 180MB만 다운로드하게 할 것인가?

병합 과정에서 gzip 압축을 적용하면 이 문제를 해결할 수 있습니다:

클라이언트 다운로드 시간 10배 단축
네트워크 비용 90% 절감
더 나은 사용자 경험

리서치: 포맷별 병합 문제

청크를 단순히 연결하면 될까요? 아닙니다. 각 포맷마다 고유한 문제가 있습니다.
Databricks API는 3가지 주요 포맷을 지원합니다:

CSV
JSON_ARRAY
ARROW_STREAM

각 포맷별 병합 문제를 살펴보겠습니다.

CSV: 중복 헤더 문제

# chunk_0.csv
name,age
Alice,30
Bob,25

# chunk_1.csv
name,age
Charlie,35
David,40

단순 연결하면:

name,age
Alice,30
Bob,25
name,age        ← 중복!
Charlie,35
David,40

해결: 첫 번째 청크의 헤더만 유지하고 나머지는 스킵해야 합니다.

JSON_ARRAY: 유효하지 않은 JSON

// chunk_0.json
[{"id":1},{"id":2}]

// chunk_1.json
[{"id":3},{"id":4}]

단순 연결하면:

[{"id":1},{"id":2}][{"id":3},{"id":4}]  // 유효하지 않음!

해결: 브래킷을 제거하고 쉼표로 연결한 뒤 전체를 배열로 감싸야 합니다.

ARROW_STREAM: EOS 마커 문제

Arrow IPC 스트림은 각 청크가 독립적인 스트림입니다:

chunk_0: [Schema][RecordBatch][RecordBatch][EOS]
chunk_1: [Schema][RecordBatch][RecordBatch][EOS]

대부분의 Arrow 리더는 첫 번째 EOS 마커에서 읽기를 중단합니다.

해결: 각 청크에서 RecordBatch만 추출하여 새로운 단일 IPC 스트림으로 재인코딩해야 합니다.

해결책: 두 개의 라이브러리

이 문제를 해결하기 위해 두 개의 라이브러리를 분리하여 개발했습니다.

1. @bitofsky/merge-streams

범용 스트림 병합 라이브러리. Databricks에 종속되지 않으며, CSV, JSON_ARRAY, ARROW_STREAM 포맷의 청크를 올바르게 병합합니다.

2. @bitofsky/databricks-sql

Databricks 전용 SQL 클라이언트. Databricks API를 직접 호출하고 merge-streams를 활용하여 External Links를 처리합니다.

@bitofsky/merge-streams: 포맷 인식 스트림 병합

핵심 가치

"When Databricks gives you 90+ presigned URLs, merge them into one."

이 라이브러리는 하나의 문제에 집중합니다: 여러 청크 스트림을 포맷에 맞게 올바르게 병합하는 것.

주요 특징

1. 포맷별 병합

import { mergeStreamsFromUrls } from '@bitofsky/merge-streams'
import { createWriteStream } from 'fs'

// CSV 병합 - 자동으로 중복 헤더 제거
await mergeStreamsFromUrls('CSV', {
  urls: [
    'https://example.com/chunk_0.csv',
    'https://example.com/chunk_1.csv',
    'https://example.com/chunk_2.csv',
  ],
  output: createWriteStream('merged.csv'),
})

// JSON 병합 - 올바른 JSON 배열 생성
await mergeStreamsFromUrls('JSON_ARRAY', {
  urls: [/* ... */],
  output: createWriteStream('merged.json'),
})

// Arrow 병합 - RecordBatch 재인코딩
await mergeStreamsFromUrls('ARROW_STREAM', {
  urls: [/* ... */],
  output: createWriteStream('merged.arrow'),
})

2. 메모리 효율적 스트리밍

전체 파일을 메모리에 로드하지 않습니다. 청크별로 스트리밍 처리하므로:

테스트: 1GB 데이터 (50개 청크)
- 전체 로드 방식: ~1GB 메모리
- merge-streams: ~30MB 메모리
- 절감: 약 97%

3. Pre-connection 최적화

// 현재 청크 스트리밍 중에 다음 청크 연결을 미리 시작
현재 청크:  chunk_0 =====> output
다음 청크:  chunk_1 [connecting...]

이 최적화로 청크 간 HTTP Connection 수립에 필요한 대기 시간이 거의 제거됩니다:

순차 처리: 50개 × 200ms 대기 = 10초
Pre-connection: 첫 청크 200ms + 나머지 ~0ms = 약 1초
개선: 약 10배

4. 진행 상황 추적

await mergeStreamsFromUrls('CSV', {
  urls,
  output,
  onProgress: ({ inputIndex, totalInputs, inputedBytes, mergedBytes }) => {
    const percent = ((inputIndex + 1) / totalInputs * 100).toFixed(1)
    console.log(`Progress: ${percent}% (${(inputedBytes / 1024 / 1024).toFixed(2)} MB read)`)
  },
})

5. 취소 가능한 작업

const controller = new AbortController()
setTimeout(() => controller.abort(), 5000) // 5초 후 취소

await mergeStreamsFromUrls('CSV', {
  urls,
  output,
  signal: controller.signal,
})

실제 사용 예: Databricks + S3 + gzip compression

import { mergeStreamsFromUrls } from '@bitofsky/merge-streams'
import { Upload } from '@aws-sdk/lib-storage'
import { createGzip } from 'zlib'

// Databricks External Links 병합 후 S3에 압축 업로드
const gzip = createGzip()
const passThrough = new PassThrough()

const upload = new Upload({
  client: s3,
  params: {
    Bucket: 'my-bucket',
    Key: 'merged-data.csv.gz',
    Body: passThrough,
    ContentEncoding: 'gzip',
  },
})

const [ result ] = await Promise.all([
  mergeStreamsFromUrls('CSV', {
    urls: databricksChunkUrls,
    output: gzip,
  }),
  pipeline(gzip, passThrough),
  upload.done(),
])

// 이제 단일 S3 URL을 클라이언트에 제공
result.externalLinks[0].external_link;

@bitofsky/databricks-sql: 경량 Databricks API 클라이언트

설계 목표

공식 SDK 없이 Databricks SQL 직접 사용
최적화된 폴링 메커니즘
메모리 효율적인 스트리밍
External Links 완전 지원
Query Metrics 통합

주요 기능

1. 최적화된 폴링 메커니즘

Databricks Statement Execution API는 wait_timeout 파라미터를 지원합니다. 서버에서 최대 50초까지 대기하며, 결과가 준비되면 즉시 응답합니다.

// wait_timeout=50s로 폴링 최소화
const result = await executeStatement(query, auth)

// 진행 상황을 보고 싶다면?
const result = await executeStatement(query, auth, {
  wait_timeout: '0s', // 즉시 응답
  onProgress: (result) => {
    console.log(`State: ${result.status.state}`)
  },
})

2. Query Metrics 지원

Query History API를 통합하여 실시간 실행 메트릭을 제공합니다:

const result = await executeStatement(query, auth, {
  enableMetrics: true,
  onProgress: (result, metrics) => {
    console.log(`State: ${result.status.state}`)
    if (metrics) {
      console.log(`  Time: ${metrics.execution_time_ms}ms`)
      console.log(`  Rows: ${metrics.rows_produced_count}`)
      console.log(`  Bytes: ${metrics.read_bytes}`)
    }
  },
})

3. 다양한 결과 소비 방식

// 1. 전체 수집 (소규모 결과)
const rows = await fetchAll(result, auth, { format: 'JSON_OBJECT' })
console.log(rows) // [{ id: 1, name: "Alice" }, ...]

// 2. 스트리밍 (대규모 결과)
await fetchRow(result, auth, {
  format: 'JSON_OBJECT',
  onEachRow: (row) => {
    console.log(row.id, row.name)
    // DB에 삽입, 파일에 쓰기 등
  },
})

// 3. 바이너리 스트림 (파일 저장)
const stream = fetchStream(result, auth)
await pipeline(stream, createWriteStream('output.csv'))

4. JSON_OBJECT: 스키마 기반 행 매핑

Databricks는 기본적으로 배열 형식으로 결과를 반환합니다:

// JSON_ARRAY 형식
[1, "Alice", 30, "2024-01-01T00:00:00Z"]

JSON_OBJECT 옵션으로 스키마 기반 객체로 변환할 수 있습니다:

const rows = await fetchAll(result, auth, {
  format: 'JSON_OBJECT',
})

// 결과
[
  {
    id: 1n,               // BIGINT → bigint
    name: "Alice",        // STRING → string
    age: 30,              // INT → number
    created_at: "2024-01-01T00:00:00.000Z" // TIMESTAMP → ISO 8601 Format string
  }
]

커스텀 변환도 가능합니다:

const rows = await fetchAll(result, auth, {
  format: 'JSON_OBJECT',
  encodeBigInt: (v: bigint) => Number(v),      // bigint → number
  encodeTimestamp: (v: string) => new Date(v), // string → Date
})

5. mergeExternalLinks: 단일 URL로 병합 + 압축

External Links를 S3 등에 업로드하고 단일 presigned URL을 반환합니다. 여기서 핵심은 병합 과정에서 압축을 적용할 수 있다는 점입니다.

Databricks External Links는 압축을 지원하지 않지만, 이 라이브러리를 사용하면 병합과 동시에 gzip 압축을 적용할 수 있습니다. 특히 CSV나 JSON 같은 텍스트 기반 포맷은 압축률이 매우 높아서 파일 크기를 1/10 이하로 줄일 수 있습니다:

const result = await executeStatement(
  'SELECT * FROM large_table LIMIT 100000',
  auth,
  { disposition: 'EXTERNAL_LINKS', format: 'CSV' }
)

const merged = await mergeExternalLinks(result, auth, {
  mergeStreamToExternalLink: async (stream) => {
    // S3에 gzip 압축 업로드
    const key = `merged-${Date.now()}.csv.gz`
    const gzip = createGzip()
    const passThrough = new PassThrough()

    const upload = new Upload({
      client: s3,
      params: {
        Bucket: bucket,
        Key: key,
        Body: passThrough,
        ContentType: 'text/csv',
        ContentEncoding: 'gzip',
      },
    })

    await Promise.all([
      pipeline(stream, gzip, passThrough),
      upload.done(),
    ])

    // presigned URL 생성
    const externalLink = await getSignedUrl(
      s3,
      new GetObjectCommand({ Bucket: bucket, Key: key }),
      { expiresIn: 3600 }
    )

    const head = await s3.send(new HeadObjectCommand({ Bucket: bucket, Key: key }))

    return {
      externalLink,
      byte_count: head.ContentLength ?? 0,
      expiration: new Date(Date.now() + 3600000).toISOString(),
    }
  },
})

// 이제 하나의 압축된 URL만 반환
console.log(merged.result.external_links[0].external_link)
// https://my-bucket.s3.amazonaws.com/merged-...csv.gz?X-Amz-...

// 실제 효과 예시:
// Databricks External Links: 90개 청크 × 20MB = 1.8GB (압축 안됨)
// 병합 + gzip: 단일 파일 180MB (약 90% 절감)

6. Partial External Links 자동 처리

Databricks가 일부 청크 메타데이터만 반환하는 경우가 있습니다:

{
  "external_links": [
    { "external_link": "https://...", "chunk_index": 0 },
    null, // chunk_index 1은 누락
    null, // chunk_index 2는 누락
    // ...
  ]
}

라이브러리가 자동으로 누락된 청크를 getStatementResultChunks API로 가져옵니다. 사용자는 신경 쓸 필요가 없습니다.

간단한 사용 예

import { executeStatement, fetchAll } from '@bitofsky/databricks-sql'

const auth = {
  token: process.env.DATABRICKS_TOKEN!,
  host: process.env.DATABRICKS_HOST!, // e.g., abc.cloud.databricks.com
  httpPath: process.env.DATABRICKS_HTTP_PATH!, // e.g., /sql/1.0/warehouses/...
}

// 쿼리 실행
const result = await executeStatement('SELECT * FROM my_table LIMIT 10', auth)

// 결과 가져오기
const rows = await fetchAll(result, auth, { format: 'JSON_OBJECT' })
console.log(rows)

실제 적용 사례

1. MCP Server 통합

class DatabricksMCPServer {
  async executeQuery(query: string): Promise<QueryResponse> {
    // 쿼리 실행
    const result = await executeStatement(query, this.auth, {
      disposition: 'EXTERNAL_LINKS',
      format: 'JSON_ARRAY',
      enableMetrics: true,
      onProgress: (result, metrics) => {
        this.sendProgressUpdate({
          state: result.status.state,
          rowsProduced: metrics?.rows_produced_count,
        })
      },
    })

    // 결과 크기에 따라 처리 방식 결정
    const rowCount = result.result?.row_count ?? 0

    if (rowCount < 1000) {
      // 작은 결과: 직접 반환
      const rows = await fetchAll(result, this.auth, {
        format: 'JSON_OBJECT',
      })
      return { type: 'inline', data: rows }
    } else {
      // 큰 결과: S3에 업로드 후 URL 반환
      const merged = await mergeExternalLinks(result, this.auth, {
        mergeStreamToExternalLink: async (stream) => {
          return await this.uploadToS3(stream)
        },
      })
      return {
        type: 'external',
        url: merged.result.external_links[0].external_link,
        rowCount,
      }
    }
  }
}

MCP 클라이언트는 이제:

작은 결과는 즉시 받아서 사용
큰 결과는 하나의 URL로 다운로드

2. 월간 리포트 생성 (압축으로 이메일 첨부 용량 절감)

async function generateMonthlyReport(year: number, month: number) {
  const result = await executeStatement(
    `
    SELECT
      date_trunc('day', order_date) as day,
      product_category,
      SUM(revenue) as total_revenue
    FROM sales
    WHERE YEAR(order_date) = :year AND MONTH(order_date) = :month
    GROUP BY day, product_category
    ORDER BY day, product_category
    `,
    auth,
    {
      disposition: 'EXTERNAL_LINKS',
      format: 'CSV',
      parameters: [
        { name: 'year', value: String(year), type: 'INT' },
        { name: 'month', value: String(month), type: 'INT' },
      ],
    }
  )

  // CSV 압축 및 저장
  // Databricks는 압축을 지원하지 않지만, 병합 과정에서 gzip 적용
  const filename = `/tmp/report-${year}-${month}.csv.gz`
  const stream = fetchStream(result, auth)
  await pipeline(stream, createGzip(), createWriteStream(filename))

  // 압축 효과: 200MB → 20MB (이메일 첨부 제한 해결)
  const stats = await fs.stat(filename)
  console.log(`Report size: ${(stats.size / 1024 / 1024).toFixed(2)} MB (compressed)`)

  // 이메일 전송
  await sendEmail({
    to: 'team@example.com',
    subject: `Monthly Report ${year}-${month}`,
    attachments: [{ filename, path: filename }],
  })
}

개발 과정에서 배운 것들

1. Arrow IPC 스트림의 복잡성

Apache Arrow는 강력하지만 학습 곡선이 있습니다. RecordBatch vs Table의 차이, IPC 스트림 포맷, EOS 마커 등을 이해하는 데 시간이 걸렸습니다만, AI 도구의 도움으로 빠르게 학습해 적용할 수 있었습니다.

2. 스트림 파이프라인 디버깅

Node.js 스트림은 강력하지만 디버깅이 어렵습니다. 특히:

메모리 누수 추적
백프레셔 처리
에러 전파 보장

이를 해결하기 위해 통합 테스트를 많이 작성했습니다.

3. Databricks API의 비문서화된 동작

일부 API 동작이 문서화되지 않았습니다. 예를 들어:

Query History API의 메트릭 인자
청크 갯수, 크기 결정 로직

결론

공식 SDK의 제약으로 시작된 프로젝트가 두 개의 오픈소스 라이브러리로 완성되었습니다.

@bitofsky/merge-streams는:

CSV, JSON, Arrow 포맷의 청크를 올바르게 병합
메모리 효율적인 스트리밍
Pre-connection 최적화
범용적으로 사용 가능

@bitofsky/databricks-sql는:

Databricks API 직접 호출
최적화된 폴링 메커니즘
다양한 결과 소비 방식
External Links 완전 지원
Query Metrics 통합

비슷한 문제를 겪고 있다면, 이 라이브러리들이 도움이 되길 바랍니다.
아직 Production Ready를 보장하지는 않습니다. Production 환경에서 사용하려면 먼저 충분한 테스트를 권장합니다.

젠레스 존 제로 - 강습전 엽석연 65000 킬

bitofsky — Thu, 1 Jan 2026 15:48:32 +0900

젠레스 존 제

케릭터

빛나 2돌 전무
다이아린 명함 스팀오븐
자오 명전

빛나 2돌에서 엽석연 공략 팁

자오 디스크가 4고요라면 고요 스택을 반드시 신경써야함. 변신 전 무조건 자오 장막 또는 스킬로 빠른 지원해서 버프 유지
첫 엽석연 패턴때 패링을 최대한 쳐서 데시벨 확보해야 소베크 미야즈마 실드 두르기 전에 최대한 극딜 가능
- 2돌 명심경
- 자오 장막 + 강특 명심경
- 궁 명심경

젠레스 존 제로 - 폐지 주워 엽빛나 뽑기

bitofsky — Tue, 30 Dec 2025 11:36:56 +0900

이런일이..?

폐지 400개 모아 2돌파 전무 달성

옛날 DOS 시절 게임을 플레이 할 수 있구나

bitofsky — Fri, 19 Dec 2025 09:03:16 +0900

https://archive.org/

인터넷 아카이브 사이트에서 옛날 추억의 DOS 에뮬레이터를 웹브라우져로 바로 플레이 할 수 있도록 하고있다.

내 유년시절 사회과부도 지도를 달달 외우게 만든 대항해시대2도 여기 있다.

옛날 시절 생각이 많이 난다. ㅎㅎ

2025-12 월 적립식 투자

bitofsky — Sun, 7 Dec 2025 13:58:23 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

hbs.pe.kr

1회 전월 양봉 = x1를 SCHD

SCHD가 오르고있다. 현재 전체 계좌의 총 입금액 대비 현재 가치 비율을 누적 수익율로 계산했을때 약 +26%의 수익을 기록중이다.

아무 생각 없이 월 1회 기계적 매매만으로도 매우 잘 워킹하는 투자 모델이라는 것이 검증되고 있다.

2025-11 월 적립식 투자

bitofsky — Mon, 17 Nov 2025 09:10:01 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

hbs.pe.kr

1회 전월 양봉 = x1를 SCHD

나스닥 우상향이 계속되어 계속 슈드만 모으는 상황인데, 최근 한달 크게 올랐다.

나스닥 상승은 포모를 일으킬 수 있었겠지만 올 초 TQQQ로 큰 이익을 본 상황이라 포모가 오지 않는게 장점이다.

올초 컸던 낙폭을 이제 거의 회복했다.

시드가 큰 만큼 이렇게 한번 점프 할 때 마다 목돈이 들어오는 느낌이 기분 좋다.

2025-10 월 적립식 투자

bitofsky — Fri, 10 Oct 2025 15:37:18 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

hbs.pe.kr

1회 전월 양봉 = x1를 SCHD

배당이 제법 들어왔다. 무념무상... 나무아미타불...

2025-09 월 적립식 투자

bitofsky — Mon, 15 Sep 2025 09:45:52 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

hbs.pe.kr

1회 전월 양봉 = x1를 SCHD

계속 슈드만 적립하게 되네...

작년 10월 24% Total Return을 피크로 찍은 후 연초에 박살나 8%까지 하락했다가 TQQQ 60+% 매도로 꽤 복구해 현재 16%의 총수익률을 기록하고 있다.

2025-08 월 적립식 투자

bitofsky — Mon, 25 Aug 2025 07:40:47 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

hbs.pe.kr

1회 전월 양봉 = x1를 SCHD

오른다 오른다

2025-07 월 적립식 투자

bitofsky — Fri, 11 Jul 2025 08:17:46 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

hbs.pe.kr

1회 전월 양봉 = x1를 SCHD

오랜 평행선을 마친듯 이제 서서히 반등한다.

2025-06 월 적립식 투자

bitofsky — Fri, 11 Jul 2025 08:16:20 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

hbs.pe.kr

1회 전월 양봉 = x1를 SCHD 매수

이번달은 2분기 배당달이다.

ZZZ 운규 1번 디스크 종결

bitofsky — Thu, 12 Jun 2025 08:05:12 +0900

이런게 나오네...

BMW 에어컨 냄새 잡기

bitofsky — Mon, 26 May 2025 09:32:53 +0900

어느 차든 여름철 에어컨을 신나게 쓰다보면 시큼한 냄새가 날 수 있습니다.

차마다 냄새를 잡는 방법이 다양한데, 통상 많이 알려진 방법은 내리기전 송풍모드를 하거나 전원을 끄고 독립환품을 켜서 말리라는 팁이 많은데...
별 팁을 다 쓰고 에바크리닝까지 맡겨도 그때뿐, 조금 지나면 다시 올라오던 냄새를 이 방법으로 확실히 잡았으니 꼭 한번 테스트 해보길 바랍니다.

원인

에어컨 가동으로 실외보다 급격히 낮아진 온도로 인한 냉방 라인, 에바포레이터 결로에서 발생한 수분에서 증식한 곰팡이

문제점

내리기전 5분정도 송풍으로는 제대로 습기가 안마름. 독립환풍은 차량 내부 습기 자체를 해결해주진 못함

해결책

독립환풍 메뉴 진입
단축버튼 중 하나를 꾹 눌러 독립환풍을 내가 원하는 번호로 지정
운행 & 운행 종료 (엔진온도 충분히 오른 것 확인)
시동 끔
단축버튼을 눌러 독립환풍 활성화
자동 에어컨 OFF & 온도 최대 (28도)
내기모드로 변경 (송풍구 막지 않음)
하차

목적

BMW 독립환풍으로 차량 전원을 끄고 내려도 15분간 냉난방이 동작하도록 합니다.

이 상태에서 자동 에어컨을 끄고 내기모드에서 수동 28도 최대로 올리면 운행으로 뜨겁게 달궈진 엔진잔열로 환기 온도를 최대치까지 끌어올려주며 실내와 냉난방 라인 전체가 뜨겁게 베이킹됩니다.

이를 통해 실내가 뽀송해지고 냄새를 없앰은 물론, 곰팡이 증식도 어렵게 되어 냄새가 금방 잡히고 재발이 쉽게 되지 않습니다.

매일 할 필요는 없고 에어컨을 좀 쓰기 시작하면 2~3일에 한번 정도만 해주어도 체감상 냄새가 아예 나지 않았습니다.

차량용 방향제는 냄새를 오히려 악화시키는 주범이니 방향제도 쓰지 않는게 좋습니다.

이렇게만 관리해주어도 방향제 없이 항상 산뜻한 실내 공기 환경을 만들 수 있습니다.

냄새가 심한 경우 처음엔 매 운행마다 해주면 금방 잡힙니다.

2025-05 월 적립식 투자

bitofsky — Wed, 14 May 2025 07:30:23 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

hbs.pe.kr

1회 전월 양봉 = x1를 SCHD 매수

사실 양봉은 아닌데 거의 전월과 차이 없어 양봉으로 보고 SCHD를 매수했다.

3~4월 집중 매수했던 TQQQ 평단이 5만원대로, +60%가 넘는 수익률을 기록을 끝으로 매도했다.

룰 대로라면 30%대에서 매도했어야 하는데, 워낙 낮은 저점을 잡은걸로 보여 좀 더 지켜보았다.

TMAP 운전 점수 99점

bitofsky — Sat, 10 May 2025 16:11:06 +0900

자동차보험 갱신 시즌이다.

갱신하려고보니 점수가 엉망이어서 티맵을 탈퇴 후 재가입 한 다음 한달간 열심히 500km를 달렸다.

특수한 상황이 잘 나오지 않아서 점수관리가 용이한 출퇴근시에만 티맵 네비를 백그라운드에 그냥 켜서 두고, 메인은 네이버 네비를 사용했다.

티맵 운전점수는 급가속, 급정거시에 대량의 점수 하락이 있지만 과속(제한속도 15km+ 오버)의 경우엔 점수가 떨어지지 않는다.

때문에 점수 관리를 한다고 틀딱운전을 하면서 차량 흐름을 답답하게 할 필요는 없다.

다만 속도를 규정보다 높였을 때 신호나 상황에따라 급정거(3초내 30km이상 감속)로 인식될 케이스가 더 많이 발생하니 그 부분을 조심했다.

500km 주행동안 급정거 1회 (커브 구간에서 앞에 차량이 서있는걸 상당히 근접해서 발견...)를 기록해 99점을 달성했고 애니카 할인 19%를 받았다.

이제 1년간 티맵 안켠다^_^

2025-04 월 적립식 투자

bitofsky — Thu, 10 Apr 2025 23:43:33 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

hbs.pe.kr

2회+ 연속 음봉 = x4+를 TQQQ 매수

트럼프가 미쳤다. 관세전쟁 여파로 한때 거의 작년 한해 올랐던 상승분 대부분이 다시 내려갔다.

SCHD는 민감종목이 아닌데, 관세에는 직격을 맞는 기업들이 많아 특히 데미지가 큰 것 같다.

우선 많이 내려간 TQ를 대량매수했는데 +25% 이상을 킵하고있으나, 관세 이슈가 향후 어떻게 되느냐에 따라 이것도 다시 반납하고 장기 분할매수 전략을 취할 수도 있어보인다.

우선 가용현금과 채권이 좀 있고, 여차하면 SCHD를 팔고 저가 줍줍도 고려하고있다.

하락장에선 현금이 왕이다.

ZZZ 요즘 꾸준히 하는 게임 젠레스존제로

bitofsky — Thu, 10 Apr 2025 23:40:08 +0900

강습전 패턴 깎는 중인데 명전 미야비로 마리오네트 53165점 달성!

명전으로 킬하는 굇수 수준에선 아직 실수가 많아 보완될 여지가 있다..!

무소과금으로 1%대 달성!

2025-03 월 적립식 투자

bitofsky — Fri, 14 Mar 2025 13:50:56 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

hbs.pe.kr

1회 전월 음봉 = x1를 SCHD, 1x를 TQQQ 매수

당분간 내려가지 않을까..?

G30 520D 공임나라 분당수내점 엔진오일 교환

bitofsky — Mon, 3 Mar 2025 01:19:58 +0900

차일피일 미루다 1만키로가 다되어서야 오일교환을 진행했습니다.

총 비용은 오일 6L, 오일필터, 에어클리너가 총 8만원정도에 공임 3.3만원이 들었습니다.

공임도 저렴한데 작업도 빠르고 서비스로 엔진룸 클리닝과 공기압도 봐주시고 좋습니다.

2025-02 월 적립식 투자

bitofsky — Thu, 6 Feb 2025 11:21:10 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

hbs.pe.kr

1회 전월 양봉 = x1를 SCHD 매수

정부의 똥볼로 연금계좌, ISA에서 국내상장 미국배당금이 15% 줄었다.

한심하다.

일단, 해당 계좌의 주 목적인 연금납입분의 세액공제와 양도소득의 비과세와 연금소득세이므로 당분간은 기존 전략을 유지한다.

2025-01 월 적립식 투자

bitofsky — Tue, 7 Jan 2025 23:37:24 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

hbs.pe.kr

1회 전월 양봉 = x1를 SCHD 매수

본래 새 한해가 시작되었으니 다시 연저펀과 ISA부터 채웠어야 했는데 깜빡하고 일반계좌로 구매했다. ;;

22년 1월부터 시작한 월적립식 투자가 벌써 3년차에 다다른 시점이어서 중간 평가를 해보았다.

현재 누적 입금액 대비 현재 평가액 (배당재투자 포함)은 +19.76% 수익으로, 연평균 수익률 약 6.58%를 기록중이다.

적립식 투자기 때문에 지속적으로 누적금으로 인해 평단가가 상승한 것을 감안해야하며, 선입선출식으로 보고 최초 구매한 주식만 평가해보면 현재 약 +40%... 연평균 13%대 수익률을 기록중이라고 볼 수 있다.

이는 최초 계획했던 수익율을 살짝 초과하고 있는 수치다. (8~12% 예상)

현재까진 잘 워킹하고 있다고 생각하며, 현재의 상승이 이후 있을 큰 하락기에도 버텨내기 위해서 계속 일정수준의 안전자산 비율을 확보해 두려고 한다. (현재 주식:안전자산은 7:3 수준)

520D 타이어 교체 - 컨티넨탈 올시즌 콘택트2

bitofsky — Wed, 4 Dec 2024 18:45:15 +0900

애마 520D 타이어를 바꿔주었다. 기존에는 올시즌 타이어 4짝을 사용중이었는데, 이번에 컨티넨탈에서 새로나온 올웨더인 올시즌 콘택트 2로 변경했다.

타이어 이름이 이상하긴 한데, 삼봉마크가 달린 올웨더가 맞다.

문제는, 내차 후륜이 275 40이라 림폭이 245 45인 전륜과 다른데, 올시즌 콘택트2는 275 사이즈가 없다. (CC2도 이사이즈가 없고...)

그래서 고민하다가, 그냥 뒷쪽은 컨티넨탈 DWS 06+로 달고 앞쪽만 올시즌 콘택트2를 장착시켰다.

DWS도 올시즌이긴 하지만 올시즌중에서는 겨울철 성능이 상급인 놈이고 차도 4륜이라 요정도만 해도 서울 경기권은 별 무리 없지 않을까 생각한 절충안이다.

부디 안전하게 겨울 날 수 있기를!

2024-12 월 적립식 투자

bitofsky — Wed, 4 Dec 2024 18:01:26 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

hbs.pe.kr

1회 전월 양봉 = x1를 SCHD 매수

한해가 간다. 올한해가 지나기전 막판, 계엄령이 터져 식겁하고있다.

2024년 맞나?

쨌는, 올해 투자 자체는 역대급 한해였다고 정리할 수 있다.

2024-11 월 적립식 투자

bitofsky — Fri, 8 Nov 2024 22:09:54 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

hbs.pe.kr

1회 전월 양봉 = x1를 SCHD 매수

본래 음봉인데 실수했다. 크게 안떨어져서 그냥 둠.

SCHD 수익률이 어마어마해졌다.

2024-10 월 적립식 투자

bitofsky — Thu, 10 Oct 2024 17:34:38 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

hbs.pe.kr

1회 전월 양봉 = x1를 SCHD 매수

SCHD를 1배율로 매수했다.

그리고 TQQQ도 수익률 35%에서 전량 매도 후 SCHD를 매입했다.

Razer Viper V2 Pro AS는 웨이코스 = 쓰레기

bitofsky — Fri, 27 Sep 2024 12:01:57 +0900

마우스 성능은 괜찮은편인데 가격에 비하면 물음표

결정적으로 AS가 쓰레기. AS만 좋아도 가격 비싼걸 감수해봄직 한데 마우스 자체가 소모품이라 AS가 쓰레기면 안사는게 답.

그런데 레이저 제품 국내 유통이 웨이코스면 뭐다? 하 말해 뭐해...

차라리 로지텍 G9 여러개 굴릴때 종종 이용했던 로지텍 AS가 천사로 보일정도다.

주변에서 누가 산다고 하면 도시락 싸들고 다니면서 말림^^

잊지마라 웨이코스는 웨이코스다.

2024-09 월 적립식 투자

bitofsky — Thu, 5 Sep 2024 13:50:06 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

hbs.pe.kr

1회 전월 양봉 = x1를 SCHD 매수

이번달은 지난달 샀던 TQQQ가 +35%까지 순간 크게 올랐으나 9월이 되자 귀신같이 떨어져 아직 30% 미만을 유지하고있다. 따라서 매도를 보류하고 당분간 더 보유한다.

SCHD를 1배율로 매수했다.

젠레스 존 제로 - 시유 분쟁구간 8단계 S 클리어

bitofsky — Thu, 15 Aug 2024 14:42:19 +0900

업데이트 이후 S 등급 기준이 시간보단 전투불능이 안되는쪽으로 변경된 것 같다.

8단계-2스테이지는 아예 정신없이 공격이 들어오는데... 콜리다의 경우 회피 반격의 무적이 상당히 긴편이라 회피 반격을 무한으로 쓰면서 그로기를 쌓다가 극딜타임에 딜하는걸 반복하는걸로 깼다.

어렵네...

청의 뽑고싶다. 근데 소과금 유져라 뽑는게 쉽지는 않네...

젠레스 존 제로 - 메마른 꽃밭 11 강도 클리어 기념

bitofsky — Sun, 4 Aug 2024 19:41:37 +0900

어휴 힘들다...!

나이가 들었는지 이제 액션게임 최고 난이도는 순발력이 부치는 느낌이 든다 ㅠ

그래도 몇트 끝에 결국 클리어^^

현질을 거의 안해서 레벨과 템이 덜맞춰진 상태라 그런건가...

2024-08 월 적립식 투자

bitofsky — Sun, 4 Aug 2024 15:39:34 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

hbs.pe.kr

1회 전월 음봉 = x1를 SCHD, 1x를 TQQQ 매수

거의 3년 미국 투자 기간 중 역대급 SCHD 상승장이었던 7월이었다.

배당을 포함한 TR 수익률이 이제 25%를 넘었다.

전월 나스닥은 하락장이었으므로 TQ를 절반 비중으로 매수한다.

당분간 미국 하락장이 예상되는데 연속 하락이 진행될경우 점차 TQ 매수 비중을 늘리게된다.

2024-07 월 적립식 투자

bitofsky — Thu, 4 Jul 2024 08:02:12 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

hbs.pe.kr

1회 전월 양봉 = x1를 SCHD 매수
TQQQ 30% 수익률 달성시 = 매매일에 전량매도 후 SCHD로 분배

5월 나스닥 하락에 매수했던 TQQQ를 수익률 41%에서 매도했다. 매도금 달러는 환전 없이 전액 SCHD 해외판으로 즉시 매수했다.

월중 50%까지 치솟았지만 감정을 배제한 기계적 매매를 위해 월말까지 기다렸고 월말 영업일에 일괄 매도를 진행했다.

이미 1월 매도했던 TQQQ 수익으로 인해 해외주식 양도소득세 공제금은 이미 초과했기 때문에 이번달 수익은 전액 22% 과세대상이다. 기쁘면서 슬픔

올해는 줄창 SCHD 평행선에 수량만 늘리는 중이고, 수익은 나스닥에서 발생하고있다.

Kubernetes AWS EKS 1.30 Update Considerations (ENG)

bitofsky — Fri, 21 Jun 2024 08:52:56 +0900

There may be issues arising from changes not mentioned in the Kubernetes 1.30 release notes and the EKS 1.30 release notes.

Particularly, if you are using EKS Managed Node Group, after updating to 1.30, pods may not function correctly due to failures in EKS Addon or AWS Credentials acquisition, or IMDS (Instance Meta Data Service) access failures.

Here is the official AWS EKS 1.30 Update document.

From 1.30, the default AMI image will change from AL2 to AL2023, and a link to a comparison document between AL2 and AL2023 is provided. However, it does not specify exactly what problems might arise due to the image change.

Let's also look at the document Comparing AL2 and AL2023.

It is a long and verbose change note and does not highlight any specific problematic areas. Since this is a base image change for EC2 node hosts, it should not significantly impact existing workloads running as Kubernetes pod images.

Looking at the Security updates of the changes, there is an item called IMDSv2.

To briefly explain what IMDS is, it stands for AWS Instance Metadata Service, which is an AWS service that allows an EC2 instance to access its metadata. This includes information such as the instance's name, instance type, which network VPC it is in, startup scripts, and so on, accessible through a fixed address (http://169.254.169.254/latest/meta-data/).

Thus, it is used to obtain information related to the EC2, and particularly in AWS EKS, addons use IMDS to automatically understand and operate based on various environment information.

One commonly used EKS Addon, the AWS Load Balancer Controller, also operates by querying VPC information through IMDS without separate input as the default installation option.

IMDS has v1 and v2; v1 is always accessible without security measures, while v2 includes added security measures.

In v2, token authentication is used, and it is designed to limit the number of network hops the caller can go through, ensuring it doesn't exceed a certain number of network interfaces.

Let's look at the Security updates - IMDSv2 section of this document.

It states that from the AL2023 image, instances will run with IMDSv2-only, and to support container workloads, the default hop limit is set to 2.

When requesting IMDS from a virtual container environment, it first goes through the virtual host network from the container, reaching the IMDS endpoint, and this step results in a hop of 2. Thus, if the IMDSv2 hop is set to 1, the HTTP request will fail.

Due to this issue, AL2023 changes the default hop setting to 2 to avoid problems on EC2s running containers like EKS.

However, there is an unmentioned trap in this document when an EC2 for EKS nodes starts with a Managed Node Group.

Managed Node Group includes IMDS settings in its Launch Template.

If you haven't modified the Metadata settings yourself, the AWS Default settings will be used.

So you might think there won't be an issue because of the Default setting, but it's a trap. If no AMI and Metadata settings are made in the Launch Template for Managed Node Group, after updating to EKS 1.30, EC2 nodes will start with AMI automatically changed to AL2023 and Metadata version set to IMDSv2 Required.

Up to this point, it follows the AL2023 document, but the trap is the hop. The hop is set to 1. As described above, accessing IMDS from within a container requires hop 2 due to the host network traversal. Thus, AL2023 AMI's default is also changed to hop 2. But EC2 created by Managed Node Group starts with IMDSv2 and hop 1.

You cannot see this hop count in the EC2 console. After upgrading to 1.30, while troubleshooting issues like pods failing to get AWS credentials or the AWS Load Balancer Controller failing to get vpcId or pods continuously restarting, you will realize that the problem is the hop.

Let's see where this problem is being tracked.

First, there is an explanation in the GitHub issue announcing the release of AL2023.

Amazon Linux 2023 (AL2023) is now generally available for MNG, Karpenter, and self-managed nodes

You can also find a statement in the EKS Managed Node Group documentation.

Customizing managed nodes with launch templates - Amazon EKS

There is also an issue with the AWS Load Balancer Controller.

Does not work on Fresh EKS Cluster with Amazon Linux 2023 AMI Type Nodes

There is also a statement in the AL2023 release blog.

Amazon EKS optimized Amazon Linux 2023 AMI now generally available

There is no mention of problems arising from the hop limit with AL2023 in the 1.30 release note, deprecated note, or any major update check points. It's ridiculous that they made even their own EKS Addon fail to work immediately after the update due to the hop limit.

Only Managed Node Group sets hop to 1, while other EC2 instances are created with hop 2 (like Karpenter, etc.).

This means that in an environment where EC2 is launched in various ways, whether the pod works or not depends on who launched the EC2. Hahaha :) Are they idiots?

The solution is simple. The problem is difficult to identify. Just set the hop to 2 in the Launch Template used by the Managed Node Group.

Kubernetes AWS EKS 1.30 업데이트 고려사항

bitofsky — Fri, 21 Jun 2024 08:44:39 +0900

Kubernetes 1.30 릴리즈 노트와 EKS 1.30 릴리즈 노트에 명시되지 않은 변화점으로 인해 문제가 발생할 수 있습니다.

특히 EKS Managed Node Group을 사용하고 있다면 1.30으로 업데이트 후, EKS Addon이나 AWS Credentials 획득 실패, IMDS (Instance Meta Data Service) 엑세스 실패등으로 pod들이 정상 동작 하지 않을 수 있습니다.

다음은 AWS 공식 EKS 1.30 Update 문서입니다.

1.30부터 AMI 기본 이미지가 AL2에서 AL2023으로 변경된다고 하고있으며, AL2와 AL2023 비교 문서의 링크를 제공하고 있습니다. 그러나 이미지 변경으로 인해 정확히 무슨 문제가 발생할 수 있는지는 표시하고 있지 않습니다.

Comparing AL2 and AL2023 문서도 살펴봅시다.

길고 장황한 change note이며 딱히 문제점이 있을만한 부분을 강조하고 있지도 않습니다.
그리고 이건 ec2 노드 호스트의 베이스 이미지 변경이므로, k8s의 pod 이미지로 도는 기존 워크로드에 큰 영향이 가지 않아야 하는게 정상이기도 합니다.

변경사항의 Security updates를 보면 IMDSv2 라는 항목이 있습니다.

IMDS가 무엇인지 간단히 설명하자면, AWS 인스턴스 메타데이터 서비스의 약자이며 EC2 인스턴스가 자신의 메타데이터에 접근할 수 있도록 제공하는 AWS 서비스입니다. 현재 EC2 환경 내에서 스스로의 이름, 인스턴스 종류, 어느 네트워크 VPC에 떠있는지, 시작 스크립트는 무엇인지 등등을 알 수 있도록 고정된 주소(http://169.254.169.254/latest/meta-data/) 를 통해 이러한 정보를 제공합니다.

즉, 이를 통해 EC2와 연관된 정보들을 획득하는데 사용하며, 특히 AWS EKS에서는 Addon들이 IMDS를 통해 여러 환경 정보를 스스로 파악해 동작하게 됩니다.

EKS Addon 중 많이 사용하게되는 aws load balancer controller 역시 그 중 하나로, VPC 정보를 별도 입력 없이 IMDS를 통해 질의하여 동작하는것이 기본 설치 옵션에서의 동작 방식입니다.

IMDS는 v1과 v2가 있으며 보안 조치 없이 항상 엑세스 가능한것이 v1, 보안 처리가 추가된것이 v2입니다.

v2에서는 특히 토큰 인증을 사용하며, 네트워크 홉 제한을 통해 호출자가 몇 단계 이상의 네트워크 인터페이스를 거치지 못하도록 제한하도록 되어있습니다.

이 문서의 Security updates - IMDSv2 항목을 살펴봅시다.

기본적으로 AL2023 이미지부터 IMDSv2-only 로 인스턴스가 실행되며, 컨테이너 워크로드 서포트 허용을 위해 default hop limit이 2로 설정된다고 명시하고 있습니다.

가상 컨테이너 환경 안에서 IMDS를 요청하면 먼저 컨테이너에서 가상 호스트 네트워크를 거쳐 IMDS endpoint로 들어가며, 이 거치는 단계로 인해 hop이 2가 됩니다. 즉, IMDSv2 hop이 1이라면 http 요청에 실패하게 됩니다.

이런 문제가 있기 때문에 AL2023은 기본 hop 설정을 2로 변경해서 EKS와 같이 컨테이너들을 실행하는 EC2들에서 문제가 없도록 제공한다고 씌여있는 겁니다.

그러나, 이 문서에 표시되지 않은 함정이 있는데 바로 Managed Node Group으로 EKS 노드용 EC2가 시작되었을때입니다.

Managed Node Group은 Launch Template 설정에 IMDS 설정이 포함됩니다.

여기서 Metadata 설정을 직접 수정하지 않았다면 AWS Default 설정을 사용하게 됩니다.

그럼 Default 설정이니 문제가 없겠네? 싶을 수 있는데 함정입니다. Managed Node Group에서 Launch Template에 AMI와 Metadata 설정을 하지 않은 경우 EKS 1.30 업데이트되고 뜨는 EC2 노드부터 AMI는 자동으로 AL2023으로 변경되고, Metadata version도 AL2023의 기본값인 IMDSv2 Required로 시작합니다.

여기까진 AL2023의 문서 그대로입니다만, 함정은 hop입니다. hop이 1로 뜹니다. 위에 서술했듯, Container 내에서 IMDS에 접근하려면 호스트 네트워크를 거치므로 무조건 hop 2가 필요합니다. 그래서 AL2023 AMI의 기본값도 hop 2로 변경한 것이죠. 그런데 Managed Node Group으로 생성된 EC2는 AL2023으로 뜨면서 IMDS는 v2로 띄우고 hop은 1로 띄웁니다.

EC2 console 안에서는 이 hop 수를 볼수도 없습니다. 그냥 1.30으로 올린 다음부터 pod안에서 aws credential을 가져오지 못하거나, aws load balancer controller에서 vpcId를 읽지 못하는 오류가 발생하거나 pod가 무한 재시작 되는 상황에서 문제를 추적하다 보면 이 hop에 문제가 있다는 것을 알게 됩니다.

어디에서 이 문제를 추적하고 있는지 찾아보았습니다.

우선 AL2023 출시를 공지한 github 이슈에서 이에 대한 설명이 있습니다.

Amazon Linux 2023 (AL2023) is now generally available for MNG, Karpenter, and self managed nodes · Issue #1696 · awslabs/amazon-eks-ami (github.com)

Amazon Linux 2023 (AL2023) is now generally available for MNG, Karpenter, and self managed nodes · Issue #1696 · awslabs/amazo

Today, we are announcing general availability of Amazon Linux 2023 (AL2023) on Amazon Elastic Kubernetes Service (EKS). AL2023 is the next generation of Amazon Linux from Amazon Web Services and is...

github.com

EKS - Managed Node Group 설명서의 항목에서도 다음 문구를 발견할 수 있습니다.

Customizing managed nodes with launch templates - Amazon EKS

aws load balancer controller 이슈도 하나 있습니다.

Does not work on Fresh EKS Cluster with Amazon Linux 2023 AMI Type Nodes · Issue #3695 · kubernetes-sigs/aws-load-balancer-controller (github.com)

AL2023 출시 블로그에도 문구가 있습니다.

Amazon EKS 최적화 Amazon Linux 2023 AMI 정식 출시 | 컨테이너

1.30 release note나 deprecated note 등 주요 업데이트 확인 포인트에는 일언반구도 AL2023과 hop 제한으로 문제가 생긴다는 언급이 없습니다. 어처구니 없게 지들이 만든 EKS Addon에서조차 hop 제한으로 업데이트만 하면 바로 동작하지 않게 만들어 놓았죠.

Managed Node Group에서만 hop 1로 걸고, 다른 EC2 생성에서는 hop 2로 생성이 됩니다. (카펜터등)

즉, 여러 방식으로 EC2를 띄우는 환경이라면 EC2를 누가 띄웠냐에 따라 pod가 동작 했다가 안했다가 한다는 말입니다. 하하 :) 병신들이냐 진짜?

해결법은 간단합니다. 이게 문제라는걸 알기 어려워서 문제인거고, Managed Node Group에서 사용하는 Launch Template에서 hop을 2로 설정하면 됩니다.

2024-06 월 적립식 투자

bitofsky — Mon, 17 Jun 2024 12:50:50 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

매수 규칙이 11월부터 변경되었다. (기존 규칙 LINK)월 적립식 투자규칙매월 1일 매매SCHD, QLD, TQQQ를 기계식 매수SCHD를 적립하면서 동시에 QLD의 양/음봉 여부에 따른 QLD/TQQQ 선택 매매1회 전월 양봉 =

hbs.pe.kr

1회 전월 양봉 = x1를 SCHD 매수

24년도 연금저축펀드와 IRP 세액공제분 납입한도가 모두 차서 이제 ISA에서 TIGER미국배당다우존스를 매수했다.

전월에 매입한 TQQQ 상승세가 무섭다. 벌써 +40%... 이거 맞니?

2024-05 월 적립식 투자

bitofsky — Thu, 9 May 2024 20:58:15 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

매수 규칙이 11월부터 변경되었다. (기존 규칙 LINK) 월 적립식 투자규칙 매월 1일 매매 SCHD, QLD, TQQQ를 기계식 매수 SCHD를 적립하면서 동시에 QLD의 양/음봉 여부에 따른 QLD/TQQQ 선택 매매 1회 전월 양

hbs.pe.kr

1회 전월 음봉 = x2를 SCHD, TQQQ 매수

전달 나스닥이 오랜만에 음봉으로 돌아갔다.

그동안 제법 쌓인 현금을 통해 2배수 금액을 SCHD와 TQQQ 매수를 진행했다.

2024-04 월 적립식 투자

bitofsky — Thu, 4 Apr 2024 13:15:13 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

hbs.pe.kr

1회 전월 양봉 = x1를 SCHD 매수

3월도 나스닥은 상승장이었다. 현금을 쌓는다. 최근 계속 연속 상승이었으므로 나스닥은 다 팔고 이제 SCHD와 현금만 쌓이고 있다.

현금은 KOFR 금리 ETF와 ACE 만기자동연장회사채에 나눠 돌린다.

벌써 SCHD의 총 수익률은 20% 가까이 된다. SCHD의 최대 MDD (금융위기)가 20%~30%선이니 이제 왠만한 일로 미장이 박살나도 순익 구간이 깨질 확률이 적어졌다.

배당주가 수익률도 높다니... 사기는 사기다.

Typescript compilerHost를 사용해 컴파일 할 때 주의사항

bitofsky — Wed, 20 Mar 2024 00:46:09 +0900

Typescript compilerHost는 현재 app의 pwd 경로를 기준으로 @types/node 등의 기본 의존성 타입을 찾는다.

따라서 mono repo와 같은 복잡한 구조인 경우 실행되는 app의 경로를 잘 지정하거나, compilerHost.getCurrentDirectory를 overwrite 하여 정확한 경로를 수동으로 지정해줄 필요가 있다.

// typescript는 cwd를 기준으로 node_modules/typescript/lib을 기본 lib 경로로 사용한다. 정확히 바라보도록 설정해준다.
compilerHost.getCurrentDirectory = () => {
  console.log(`compilerHost.getCurrentDirectory`, __dirname, path.resolve(__dirname, `../`));
  return path.resolve(__dirname, `../`);
}

개삽질 history...

Docker / Buildkit 에서 SOURCE_DATE_EPOCH와 rewrite-timestamp 설정

bitofsky — Wed, 13 Mar 2024 17:21:23 +0900

Docker / Buildkit 에서 SOURCE_DATE_EPOCH와 rewrite-timestamp 설정

컨테이너 이미지를 빌드하는 과정에서 동일한 이미지 레이어 구성을 가졌음에도 불구하고 빌드 캐시를 활용하지 않는 경우, 최종 이미지의 해시값이 매번 변경되는 현상이 발생한다. 이러한 변화는 이미지 매니페스트와 각 빌드 단계에서 생성되는 레이어에 현재 빌드 시간이 포함되어 있기 때문으로, 캐시를 재활용하지 않을 경우 동일한 컨텍스트, 소스, 도커파일이라 하더라도 매번 다른 이미지가 생성된다.

기술적 배경을 살펴보면, 도커파일 내에서 apt와 같은 패키지 매니저를 통해 원격 설치를 진행하는 경우, 매 호출 시 동일한 명령어로 이미지를 구성하더라도 실제 파일 시스템에는 변경 사항이 발생할 수 있어 이와 같은 동작이 이루어진다.

그러나 대다수의 시스템은 최종 서버 빌드를 위해 이러한 패키지 설치 단계를 별도의 이미지로 미리 생성하여 사용하는 경우가 많으며, 이 경우 빌드 캐시의 무효화나 빌드 시스템의 병렬 처리로 인해 각 빌드마다 동일한 이미지가 생성되지 않는 현상으로 인해 스토리지 및 네트워크 사용량이 증가하고, 해시 변경을 감지하는 후처리 작업이 더욱 복잡해지는 문제가 발생한다.

이러한 문제에 대응하기 위해, 많은 요구자들은 오랫동안 이미지 스냅샷과 메타데이터의 타임스탬프를 유닉스 타임 0으로 설정하는 것을 요청해왔으며, 이제서야 이러한 요구가 반영된 v0.13.0 버전의 빌드킷 업데이트가 이루어졌다. v0.11.0에서는 SOURCE_DATE_EPOCH 인식 기능이 추가되었으며, v0.13.0에서는 rewrite-timestamp 내보내기 옵션이 추가되었다.

SOURCE_DATE_EPOCH에 대한 자세한 정보는 다음 링크에서 확인할 수 있다: https://reproducible-builds.org/docs/source-date-epoch/

이것들과 함께 touch로 context 파일의 타임스템프들을 모두 동일하게 초기화 하면, 몇번 빌드하던지 모두 같은 이미지 해시가 만들어지게 된다.

# Dockerfile
# syntax=docker/dockerfile:1.5
FROM ubuntu:22.04@sha256:aa772c98400ef833586d1d517d3e8de670f7e712bf581ce6053165081773259d
RUN echo "Hello World" > hello.txt & touch -t 197001010000.00 hello.txt

# bash
docker buildx create --use --driver-opt image=moby/buildkit:v0.13.0
docker buildx build --no-cache --build-arg SOURCE_DATE_EPOCH=0 --output type=image,push=false,rewrite-timestamp=true .
[+] Building 1.1s (8/8) FINISHED                                                                                                                                          
 => [internal] load build definition from Dockerfile                                                                                                                 0.0s
 => => transferring dockerfile: 232B                                                                                                                                 0.0s
 => resolve image config for docker-image://docker.io/docker/dockerfile:1.5                                                                                          0.3s
 => CACHED docker-image://docker.io/docker/dockerfile:1.5@sha256:39b85bbfa7536a5feceb7372a0817649ecb2724562a38360f4d6a7782a409b14                                    0.0s
 => => resolve docker.io/docker/dockerfile:1.5@sha256:39b85bbfa7536a5feceb7372a0817649ecb2724562a38360f4d6a7782a409b14                                               0.0s
 => [internal] load .dockerignore                                                                                                                                    0.0s
 => => transferring context: 2B                                                                                                                                      0.0s
 => [internal] load metadata for docker.io/library/ubuntu:22.04@sha256:aa772c98400ef833586d1d517d3e8de670f7e712bf581ce6053165081773259d                              0.0s
 => CACHED [1/2] FROM docker.io/library/ubuntu:22.04@sha256:aa772c98400ef833586d1d517d3e8de670f7e712bf581ce6053165081773259d                                         0.0s
 => => resolve docker.io/library/ubuntu:22.04@sha256:aa772c98400ef833586d1d517d3e8de670f7e712bf581ce6053165081773259d                                                0.0s
 => [2/2] RUN echo "Hello World" > hello.txt & touch -t 197001010000.00 hello.txt                                                                                    0.1s
 => exporting to image                                                                                                                                               0.2s
 => => exporting layers                                                                                                                                              0.2s
 => => exporting manifest sha256:8be4c0a2a57b95ba10ccf6edc234b2969e46eeea549054ab322243faa44b9ef3                                                                    0.0s
 => => exporting config sha256:47c62c5eb5f254e29365ceda2a043bd48ffccf48f48e7caacad9428db7440a6e

위와 같은 Dockerfile에서 docker build를 하면 이제 항상 동일한 manifest sha가 생성될 것이다. (sha256:8be4c0a2a57b95ba10ccf6edc234b2969e46eeea549054ab322243faa44b9ef3)

현재 남아 있는 문제점으로는, COPY --link 단계에서 타임스탬프 재작성이 이루어지지 않는 것으로 보인다. 이 문제가 해결되기 전까지는 간단한 COPY 명령어를 사용하는 것이 좋을 것으로 보인다.

2024-03 월 적립식 투자

bitofsky — Thu, 7 Mar 2024 08:28:00 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

hbs.pe.kr

1회 전월 양봉 = x1를 SCHD 매수

2월도 나스닥은 상승장이었다. 현금을 쌓는다.

현금은 KOFR 금리 ETF와 ACE 만기자동연장회사채에 나눠 돌린다.

pnpm 심볼릭 링크 버그 수정하기

bitofsky — Mon, 26 Feb 2024 12:12:26 +0900

개요

최근 내부 저장소의 기본 의존성을 최신 버전으로 업그레이드한 이후, 특정 서버가 런타임 중에 중단되기 시작했다.

ERROR 1: uncaughtException : Error: libtensorflow.so.2: cannot open shared object file: No such file or directory

TensorFlow의 Node.js 버전은 모듈 설치 후 설치 스크립트에 의해 운영 체제별로 의존성을 다운로드하거나 소스 코드에서 빌드되며, 결국 빌드된 바이너리 파일을 심볼릭 링크로 연결한 특정 경로를 생성한다. TensorFlow Node.js API는 이러한 심볼릭 링크를 참조한다.

이 모듈의 내부 작동 방식은 사용자가 알 필요가 없어야 한다. 정상적으로 빌드가 완료되면 그냥 작동해야 하지만, 문제가 발생하면 사용자도 이를 알게 된다.

pnpm을 사용하여 모듈을 처음 설치할 때, 모든 파일과 그 인덱스를 캐시 저장소에 기록한다. 두 번째 설치부터는 이 인덱스를 사용하여 파일을 복원한다. 그러나 pnpm 8.7 버전부터 심볼릭 링크된 파일이 인덱스에 포함되지 않는 문제를 발견했다.

이로 인해 CI/CD 빌드 런타임에서 캐시가 없는 상태로 처음 설치할 때는 심볼릭 링크가 생성되어 정상적으로 작동하지만, 빌드 캐시에서 복원하는 두 번째 설치부터는 심볼릭 링크가 누락되어 런타임 오류가 발생한다.

이 문제를 pnpm에 보고했다.

https://github.com/pnpm/pnpm/issues/7691

그러나 비슷한 이슈는 이전부터 존재했고, 아직도 해결되지 않고 있으며 담당자도 뭔가 삽을 푸고있는 것으로 보였다. 이런게 직접 나설 때이다.

이슈 추적

문제의 원인은 심볼릭 링크가 .json 파일 인덱스에 기록되지 않는 것이었다. 따라서 심볼릭 링크를 기록하는 부분을 조사하기로 했다.

pnpm 프로젝트를 다운로드하여 문제를 추적하기 시작했다. 모듈 설치가 완료된 후 내부 디렉토리를 캐싱하는 코드를 찾았다.

해당 코드는 /store/cafs/src/addFilesFromDir.ts에 위치해 있었다.

테스트 케이스를 작성하여 문제를 재현해보았다.

# test directory 설정
~/pnpm/store/cafs/test/fixtures/include-symlink$ ls -li
10272393 lrwxrwxrwx 1 bitofsky bitofsky 10 Feb 23 16:09 link.txt -> origin.txt
10272392 -rw-rw-r-- 1 bitofsky bitofsky  2 Feb 23 16:06 origin.txt

# jest test 추가
test('recognize files in a directory with symbolic links', () => {
  const storeDir = tempy.directory()
  const srcDir = path.join(__dirname, 'fixtures/include-symlink')
  const addFiles = () => createCafs(storeDir).addFilesFromDir(srcDir)

  const { filesIndex } = addFiles()

  expect(filesIndex['origin.txt']).toBeDefined()
  expect(filesIndex['link.txt']).toBeDefined()
})

버전 8.6에서는 테스트가 통과했지만, 8.7 이후 버전에서는 실패했다. 반면 9.x 알파 버전에서는 다시 통과했다.

문제 해결

addFilesFromDir에서 파일 인덱스 목록을 반환하는 과정에 문제가 있음을 확인했다.

버전별 코드 변경 사항을 검토했고, 문제를 식별한 후, 9.x 알파 버전에서 이미 해결된 사실을 확인했다.

그러나 해결이 이 문제를 해결하기 위함이 아니라 코드 개선중 얼떨결에 해결된 것으로 보이며 문제 인식이 없는 한 하위 버전에 자동으로 백포트 하지는 않을 것 같았다.

따라서 8버전에도 이 수정 사항을 백포트하면 될것으로 판단해 pr을 올리는 대신 코멘트를 작성하기로 했다.

https://github.com/pnpm/pnpm/issues/7691#issuecomment-1961697431

pnpm store doesn't have symlink files after version 8.7 · Issue #7691 · pnpm/pnpm

Verify latest release I verified that the issue exists in the latest pnpm release pnpm version v8.7.0~ Which area(s) of pnpm are affected? (leave empty if unsure) Store Link to the code that reprod...

github.com

근본 원인은 nodejs fs 내장 모듈에서 제공하는 readdir과 stat 메소드에서 반환하는 파일의 속성을 조사하는 객체의 차이에서 발생했다.

readdir에서 withFileTypes: true를 주고 디렉토리를 읽으면 디렉토리 내부의 파일 목록을 제공하는데 이 파일 각각은 Dirent object이다.

그러나 stat 메소드에서 해당 파일을 직접 읽으면 Stats object가 반환된다.

8.7 이전에선 readdir() → stat() 과정을 통해 Stats object로부터 isFile() 을 체크했는데 이 메소드는 심볼릭 링크를 true로 반환했다.

8.7 이후에선 성능 개선 목적 때문인지, readdir( withFileTypes: true ) 로 하고 반환되는 file Dirent object로부터 isFile()을 체크했는데, pnpm 개발자가 간과한 것은 심볼릭 링크된 파일의 경우 여기서 false가 반환된다는 점이다. 그래서 8.7 이후부터는 심볼릭 링크된 파일이 사라진 것이었다.

해당 이슈에 대한 담당자의 인지 후, 수정된 버그 픽스가 곧 배포되었다.

이 버그는 오랫동안 지속되었으나, 캐시가 생성된 상태에서 버전 업데이트가 이루어지면 심볼릭 링크가 이미 인덱스에 기록된 캐시를 재사용하기 때문에 새로운 빌드 캐시에서만 문제가 발생해 명확하게 드러나지 않았던 것으로 보인다.

오늘도 지옥불에서 해피 코딩

SYN FLOOD 공격 및 대응 사례

bitofsky — Thu, 8 Feb 2024 14:41:19 +0900

서론
최근 우리 서비스는 네트워크 이상 현상과 그로 인해 발생한 장애를 경험했다.

이 문제는 특정 시간대에 집중적으로 발생했으며, AWS GlobalAccelerator, ELB (L4 NLB), EKS 구성을 통해 제공되는 서비스에 영향을 미쳤다. 문제는 사용자 수의 급격한 감소와 서비스 오동작으로 나타났다.

여러 시스템 지표와 로그 분석 결과 SYN FLOOD 공격으로 인한 것으로 강하게 의심되었다.

SYN FLOOD 공격의 원리
SYN FLOOD 공격은 TCP 연결 과정에서의 취약점을 이용하는 DoS (Denial of Service) 공격 유형 중 하나다.

공격자는 대량의 SYN 요청을 목표 서버에 보내 서버의 반응을 기다리는 SYN-RECEIVED 상태의 연결을 대량으로 생성하게 만든다.

서버는 이러한 미완성 연결에 대해 자원을 할당하며, 이 과정에서 너무 많은 요청이 들어오면 정상적인 트래픽을 처리할 수 없게 된다.

신규 커넥션 연결 뿐 아니라, 기존 연결되어있는 소켓에도 문제가 발생하게 된다.

여타 DDoS 유형의 공격과 차이점은, 신규 연결은 폭발적으로 증가하지만 송수신 트래픽은 급감하는 지표가 관찰된다는 점이다.

실제 사례 분석
우리 서비스에서 발생한 문제는 사용자의 급격한 감소와 서비스의 오동작으로 나타났다.

이 문제를 분석한 결과, AWS의 NLB에서 Pod 타겟에 대한 deregister → register 호출이 지속적으로 감지되었으며, 이는 SYN Flood 공격으로 인한 네트워크 트래픽 이슈가 발생했고 그로인한 health check 실패가 트리거로 작용해 LoadBalancer에서 서비스 Pod가 Deregister된 것이 문제였다.

공격으로 인해 NLB를 관리하는 aws-loadbalancer-controller에서 타겟 노드들이 비정상으로 인식되어 deregister되었으며 Pod 자체의 비정상 동작보다도 NLB에서 Pod들이 제거되어 서비스 트래픽을 아예 받지 못하는 상황이 된 것이 문제였다.

방어 기술 및 대응 조치
이 문제에 대응하기 위해 몇 가지 조치를 취했다.

우선, AWS 엔지니어와 협의를 통해 AWS Shield Advanced를 활성화하여 SYN Flood 공격으로부터의 보호와 알람을 강화했다. 이 서비스는 공격을 완전히 차단할 수는 없지만, 미티게이션을 통해 증상을 완화시키는데 도움을 줄 수 있다.

추가로, 서비스의 상태를 기반으로 연관 서비스에 서킷브레이크 되는 기능을 개발해 도입했다.
이 기능은 단시간에 특정 서비스 트래픽이 발생하는 경우 서비스 레벨에서 일정 시간 기능을 멈추도록 하는 완화 기능을 제공하도록 했다. 서킷브레이크가 동작하면 Grafana와 Slack 등을 통해 담당자에게 알림을 보내어, 신속하게 상황을 인식하고 대응할 수 있도록 했다.

그리고 서킷브레이크를 라이브 환경에 적용한 다음날 바로 이루어진 재공격으로 의심되는 트래픽에서 크게 효과를 보았으며, 서비스 장애를 막는데 큰 도움이 되었다.

서비스에 별다른 타격이 없다고 생각했는지, 공격자들이 더이상 이 서비스로 공격하는 행위를 보지 못하고있다.

결론 및 교훈
SYN FLOOD 공격은 네트워크 보안에 큰 위협이 되며, 이에 대한 효과적인 대응 방안을 마련하는 것이 중요하다.

이번 사례를 통해, 공격에 대한 신속한 인지와 적절한 대응 조치가 서비스의 안정성을 유지하는 데 필수적임을 다시 한번 확인할 수 있었다.

또한, 지속적인 모니터링과 예방 조치의 중요성을 재확인하며, 네트워크 보안을 강화하기 위한 노력을 계속해야 할 필요성을 느꼈다.

2024-02 월 적립식 투자

bitofsky — Fri, 2 Feb 2024 13:27:44 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

기존 규칙: https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-%EC%8B%9C%EC%9E%91 매수 규칙이 11월부터 변경되었다. 월 적립식 투자규칙 매월 1일 매매 SCHD, QLD, TQQQ를 기계식 매수 SC

hbs.pe.kr

1회 전월 양봉 = x1를 SCHD 매수

1월도 나스닥은 상승장이었다.

2024-01 월 적립식 투자

bitofsky — Mon, 15 Jan 2024 09:33:57 +0900

https://bitofsky.tistory.com/entry/%EC%9B%94-%EC%A0%81%EB%A6%BD%EC%8B%9D-%ED%88%AC%EC%9E%90-2023-11%EC%9B%94-%EA%B7%9C%EC%B9%99-%EB%B3%80%EA%B2%BD

월 적립식 투자 - 2023-11월 규칙 변경

hbs.pe.kr

TQQQ 수익 30% 초과 = 전량 매도
1회 전월 양봉 = x1를 SCHD 매수

2023년 한해는 2022년의 손실을 모두 복구하고 +8%가량 이익을 보고 마무리 되었다.

주력인 SCHD는 약세여서 이익이 크지 않았지만 TQQQ를 활용한 레버리지 룰에서 수익이 30%이상 발생하여 이익을 키울 수 있었다.

나스닥은 상승장이었다.