정말 유익한 글이었음. 이런 기술적 접근 과정을 공유해주는 게 너무 좋음
내가 직접 같은 문제를 겪지 않더라도, 어떤 사고방식으로 접근했는지 보는 것만으로도 배움이 많았음
솔직히 말하면, 이건 처음부터 serverless를 쓰지 않았으면 훨씬 깔끔했을 것 같음
수 초짜리 데이터를 억지로 AWS serverless 패러다임에 끼워 넣으려다 불필요한 비용과 복잡성이 생긴 느낌임
그래도 메모리 기반 솔루션으로 옮긴 건 좋은 선택이었음
결국 네트워크 처리량과 RAM 확보를 위해 무거운 인스턴스를 돌리게 된 셈인데, CPU는 거의 안 쓰고 있음
TLS handshake가 CPU를 많이 쓴다고 했지만, 그게 주요 병목일 것 같진 않음
그래도 이런 워크플로우 맞춤형 시스템 설계를 시도하는 점은 흥미로웠음
사실 제목처럼 “S3를 직접 구현했다”기보다는, S3 앞단에 메모리 캐시를 둔 구조였음
멋지긴 하지만 완전한 자체 S3 대체는 아님
맞음, 그래도 기존 클라이언트를 바꾸기 어려우니 S3 API를 흉내 내야 했던 것 같음
제목이 뭐든 간에 흥미로운 프로젝트였음
왜 굳이 메모리 캐시여야 했는지는 이해가 안 됐음. 로컬 스토리지로도 충분했을 듯함
HN 스타일로 말하자면, Nanit이라는 회사 자체에 대해 이야기하고 싶음
Nanit은 클라우드 기반 아기 모니터 카메라를 운영함. 모든 영상과 오디오가 E2EE 없이 업로드됨
하드웨어는 비싸고, 구독 없이는 거의 쓸 수 없음. 게다가 $200짜리 스탠드를 사야 수면 추적 기능이 열림
이런 구조가 결국 클라우드 종속 모델을 강화하는 게 아쉬움
그래도 이번 글처럼 S3 의존을 줄이고 자체 스토리지로 옮긴 건 잘한 일임
나는 만족한 고객임. Nanit을 고른 이유는 단순히 “잘 작동했기 때문”임
다른 제품들은 앱이 불안정했음. 로컬 우선 + E2EE 솔루션이 있으면 좋겠지만, 현실적으로 사용성이 더 중요했음
E2EE 관련해서, 이 경우엔 단순 저장이 아니라 클라우드에서 영상 분석을 수행하므로 E2EE 자체가 불가능함
진짜 E2EE를 원한다면 로컬에서 분석을 하고 결과만 업로드해야 함
나는 직접 나무로 거치대를 만들어 썼는데, 당시엔 소프트웨어 제한이 없었음. 지금은 바뀐 건지 궁금함
“셀프 호스팅 영상은 어렵지 않다”는 말엔 동의 못함. 일반 사용자 입장에선 전혀 고려 대상이 아님
사실 아기 모니터에 클라우드가 꼭 필요한지도 모르겠음. 어차피 근처에 신뢰할 수 있는 어른이 있음
이 글은 마치 스스로 문제를 만든 뒤 해결했다고 자축하는 느낌이었음
차라리 처음부터 로컬 저장 하드웨어를 팔았다면 단순하고 저렴했을 것임
클라우드 중심 설계는 이제 2015년식 접근 같음
글은 훌륭했지만, ‘delete on read’를 S3에서 구현했을 때의 비용 절감 효과도 궁금했음
S3가 초 단위 과금이라면 절약폭이 꽤 컸을 수도 있음
또 이 솔루션은 사실상 S3의 ‘reduced redundancy’ 옵션과 유사함
$50만 절감했다고 하는데, 전체 비용이 얼마였는지 모르겠음
그게 $50만 중 $50만1달러인지, $5천5백만 달러 중 $50만인지에 따라 의미가 달라짐
맞음, 사실 이런 문제는 기술보다 AWS와의 가격 협상(PPA) 으로도 해결 가능함
그래도 S3는 여전히 가성비 좋은 서비스라서, 우리도 AWS를 떠나더라도 S3와 SQS는 유지할 예정임
처음부터 잘못된 아키텍처를 선택한 뒤, 캐시로 덧칠한 느낌임
평균 2초짜리 영상을 S3에 올릴 이유는 중복 저장 외엔 없음
그냥 서버에서 직접 처리했다면 S3, SQS, Lambda 모두 없앨 수 있었을 것임
맞음, S3는 저장용이지 처리용이 아님
이렇게 단순한 문제를 왜 이렇게 복잡하게 만든 건지 모르겠음
“앱 개발에 집중하고 인프라는 단순화하라”는 고전적인 교훈 같음
차라리 캐시를 비디오 처리 서버 안에 직접 넣는 게 더 나았을 것임
제목은 차라리 “S3를 잘못 썼다”가 더 정확했을 듯함
진짜로, 왜 수백만 개의 짧은 임시 파일을 S3에 저장하려 했는지 이해가 안 됨
결국 자체 메모리 스토어를 만들었는데, 차라리 Redis 같은 걸 썼으면 됐을 일임
직접 만든 시스템이 다운되면 영상은 사라지는 건가?
처음부터 Kinesis나 SQS로 보냈으면 훨씬 나았을 것임
Hacker News 의견
정말 유익한 글이었음. 이런 기술적 접근 과정을 공유해주는 게 너무 좋음
내가 직접 같은 문제를 겪지 않더라도, 어떤 사고방식으로 접근했는지 보는 것만으로도 배움이 많았음
솔직히 말하면, 이건 처음부터 serverless를 쓰지 않았으면 훨씬 깔끔했을 것 같음
수 초짜리 데이터를 억지로 AWS serverless 패러다임에 끼워 넣으려다 불필요한 비용과 복잡성이 생긴 느낌임
그래도 메모리 기반 솔루션으로 옮긴 건 좋은 선택이었음
TLS handshake가 CPU를 많이 쓴다고 했지만, 그게 주요 병목일 것 같진 않음
그래도 이런 워크플로우 맞춤형 시스템 설계를 시도하는 점은 흥미로웠음
사실 제목처럼 “S3를 직접 구현했다”기보다는, S3 앞단에 메모리 캐시를 둔 구조였음
멋지긴 하지만 완전한 자체 S3 대체는 아님
제목이 뭐든 간에 흥미로운 프로젝트였음
HN 스타일로 말하자면, Nanit이라는 회사 자체에 대해 이야기하고 싶음
Nanit은 클라우드 기반 아기 모니터 카메라를 운영함. 모든 영상과 오디오가 E2EE 없이 업로드됨
하드웨어는 비싸고, 구독 없이는 거의 쓸 수 없음. 게다가 $200짜리 스탠드를 사야 수면 추적 기능이 열림
이런 구조가 결국 클라우드 종속 모델을 강화하는 게 아쉬움
그래도 이번 글처럼 S3 의존을 줄이고 자체 스토리지로 옮긴 건 잘한 일임
다른 제품들은 앱이 불안정했음. 로컬 우선 + E2EE 솔루션이 있으면 좋겠지만, 현실적으로 사용성이 더 중요했음
진짜 E2EE를 원한다면 로컬에서 분석을 하고 결과만 업로드해야 함
이 글은 마치 스스로 문제를 만든 뒤 해결했다고 자축하는 느낌이었음
차라리 처음부터 로컬 저장 하드웨어를 팔았다면 단순하고 저렴했을 것임
클라우드 중심 설계는 이제 2015년식 접근 같음
글은 훌륭했지만, ‘delete on read’를 S3에서 구현했을 때의 비용 절감 효과도 궁금했음
S3가 초 단위 과금이라면 절약폭이 꽤 컸을 수도 있음
또 이 솔루션은 사실상 S3의 ‘reduced redundancy’ 옵션과 유사함
$50만 절감했다고 하는데, 전체 비용이 얼마였는지 모르겠음
그게 $50만 중 $50만1달러인지, $5천5백만 달러 중 $50만인지에 따라 의미가 달라짐
처음부터 잘못된 아키텍처를 선택한 뒤, 캐시로 덧칠한 느낌임
평균 2초짜리 영상을 S3에 올릴 이유는 중복 저장 외엔 없음
그냥 서버에서 직접 처리했다면 S3, SQS, Lambda 모두 없앨 수 있었을 것임
이렇게 단순한 문제를 왜 이렇게 복잡하게 만든 건지 모르겠음
“앱 개발에 집중하고 인프라는 단순화하라”는 고전적인 교훈 같음
차라리 캐시를 비디오 처리 서버 안에 직접 넣는 게 더 나았을 것임
제목은 차라리 “S3를 잘못 썼다”가 더 정확했을 듯함
결국 자체 메모리 스토어를 만들었는데, 차라리 Redis 같은 걸 썼으면 됐을 일임
직접 만든 시스템이 다운되면 영상은 사라지는 건가?
처음부터 Kinesis나 SQS로 보냈으면 훨씬 나았을 것임