2023-12-20-TIL
Today I Learned
NAS vs NFS
이름이 비슷해서 같이 비교되지만 층위가 다르다. NAS(Network Attached Storage)는 네트워크에 붙은 파일 저장 장치나 그런 구성을 말하고, NFS(Network File System)는 원격 파일을 로컬 파일처럼 다루게 해 주는 프로토콜이다. NAS 장비는 NFS, SMB 같은 프로토콜로 파일을 제공한다. 두 번째 링크인 Quobyte 글도 NFS는 이름과 달리 원격 서버의 파일 시스템에 접근하는 프로토콜이고, Linux와 Unix에서는 NFS, Windows에서는 SMB/CIFS가 NAS에 접근하는 데 주로 쓰인다고 구분한다.
NFS 버전 4는 RFC 7530에 정의되어 있다. 초록은 이전 버전과 달리 파일 잠금과 MOUNT 프로토콜 지원을 프로토콜 안에 통합했다고 설명한다. 마지막 링크는 Linux 서버와 클라이언트를 기가비트 이더넷으로 연결해 NFS, SMB, SSHFS의 성능을 암호화 여부별로 비교한 글이다.
- https://www.naschannel.com/nas/211/
- https://www.quobyte.com/storage-explained/what-is-network-filesystem/#:~:text=Is%20NAS%20the%20same%20as,read%20more%20about%20NAS%20here).
- https://blog.ja-ke.tech/2019/08/27/nas-performance-sshfs-nfs-smb.html
- https://blog.ja-ke.tech/2019/08/27/nas-performance-sshfs-nfs-smb.html
m3u8
m3u8은 재생 목록 파일 형식이다. 각 줄에 미디어 파일의 경로나 URI를 적고, #으로 시작하는 줄에 태그를 둔다. RFC 8216은 HTTP Live Streaming(HLS)의 재생 목록으로 이 형식을 쓰며, 재생 목록은 UTF-8 텍스트이고 확장자는 .m3u8 또는 .m3u라고 정한다. 파일 첫 줄은 #EXTM3U이고, #EXTINF로 각 구간의 길이를 적는다.
1
2
3
4
5
#EXTM3U
#EXTINF:9.009,
segment0.ts
#EXTINF:9.009,
segment1.ts
HLS에서는 영상을 짧은 조각으로 나누고 m3u8 파일이 조각 목록을 알려 준다. 여러 화질의 재생 목록을 묶는 마스터 재생 목록을 두면 플레이어가 네트워크 상태에 맞는 화질을 골라 받는다. 같은 형식은 음악 재생 목록에도 쓰여서, 링크한 Spotify 커뮤니티 글처럼 로컬 파일로 만든 m3u 재생 목록을 가져오는 데도 쓴다.
- https://community.spotify.com/t5/Your-Library/Easily-crate-playlist-with-local-files-or-import-m3u/td-p/5435274
Event Bridge
Amazon EventBridge는 이벤트로 애플리케이션 구성 요소를 연결하는 서버리스 서비스다(AWS 문서). 이벤트를 처리하는 방식은 두 가지다.
- 이벤트 버스: 여러 소스에서 이벤트를 받아 규칙에 맞는 여러 대상으로 보내는 라우터다.
- 파이프: 소스 하나에서 대상 하나로 보내는 점대점 연결이다. 중간에 변환과 보강을 넣을 수 있다.
여기에 cron이나 rate 식으로 작업을 예약하는 EventBridge Scheduler가 있다. 서버에서 @Scheduled로 돌리던 정기 작업을 서버 밖에서 트리거하거나, 한 서비스에서 일어난 일을 다른 서비스가 구독하게 할 때 쓴다. 발행하는 쪽은 누가 이벤트를 받는지 몰라도 되어서 서비스 사이의 결합이 느슨해진다.
- https://aws.amazon.com/ko/eventbridge/
- https://dev.classmethod.jp/articles/i-used-eventbridge/
id generator with synchronized method
애플리케이션에서 순번 ID를 만들 때 가장 단순한 방법은 카운터를 증가시키는 메서드에 synchronized를 붙이는 것이다.
1
2
3
4
5
6
7
public class IdGenerator {
private long last = 0;
public synchronized long next() {
return ++last;
}
}
Java 튜토리얼은 synchronized 메서드의 효과를 두 가지로 설명한다. 같은 객체의 synchronized 메서드 호출은 서로 끼어들 수 없고, 메서드가 끝나면 다음 호출에 변경 내용이 보이도록 happens-before 관계가 생긴다. 그래서 한 JVM 안에서는 중복 없는 번호가 나온다.
한계는 범위다. 이 보장은 같은 객체, 같은 프로세스 안에서만 유효하다. 서버를 두 대 띄우면 각 서버가 1부터 세기 시작해서 ID가 겹친다. 재시작하면 카운터도 초기화된다. 여러 서버에서 유일한 ID가 필요하면 DB 시퀀스, 서버 번호를 ID에 섞는 방식, UUID 같은 다른 방법이 필요하다. 단일 서버 안에서도 잠금 없이 증가시키려면 AtomicLong.incrementAndGet()을 쓸 수 있다.
Release Versioning Best Practices
버전 번호 규칙으로 가장 널리 쓰이는 것은 Semantic Versioning이다. MAJOR.MINOR.PATCH 형식에서 하위 호환되지 않는 API 변경은 MAJOR, 하위 호환되는 기능 추가는 MINOR, 하위 호환되는 버그 수정은 PATCH를 올린다. 1.0.0-alpha처럼 하이픈 뒤에 사전 배포 표시를, 1.0.0+20130313144700처럼 더하기 뒤에 빌드 메타데이터를 붙일 수 있고, 빌드 메타데이터는 버전 우선순위 비교에서 무시된다. 버전 번호만 보고도 업그레이드해도 되는지 판단할 수 있게 하자는 것이 핵심이다.
- https://www.codium.ai/blog/best-practices-of-versioning-in-software-engineering/
댓글
아직 댓글이 없습니다