분류 전체보기 235

클라우드 서비스 기초 개념

👣 Public Cloud Vs Private Cloud 퍼블릭 프라이빗 컴퓨팅 리소스 소유 여부 X O 제공 방법 Internet 사설 네트워크 비고 가상화 기술로 만든 서비스 그대로 사용 가상 컴퓨팅 기술 직접 구축 👣CSP, Cloud Service Provider - 클라우드 서비스 제공 업체 1. 해외 AWS, GCP, Azure, IBM Cloud, Oracle, Alibaba Cloud, Tencent Cloud 2. 국내 Naver Cloud Platform, NHN Cloud, Gabia.Cloud, Kakao i Cloud, Kt Cloud 👣 Cloud Service 특징 1. 탄력성 및 민첩성: 단 한번의 클릭으로 생성/삭제 및 확장 가능 2. 확장성: 급증하는 서비스, 트래픽에 대..

DevOps 2024.01.09

HLS - Http Live Streaming

👣 Reference https://www.cloudflare.com/ko-kr/learning/video/what-is-http-live-streaming HTTP 라이브 스트리밍이란? (HLS) HTTP 라이브 스트리밍이란 HTTP를 전송 채널로 하는 라이브 스트리밍 프로토콜이다. 💡 라이브 스트리밍실시간으로 영상물을 재생하는 것HLS에서는 m3u8과 ts를 사용한다. m3u8은 영상 재생을 위한 velog.io 👣 개요 동영상 파일의 경우, 대부분 큰 용량을 가지고 있어 일부분을 확인하기 위해 전체 파일을 요구하는 것은 낭비이다. 때문에 사용자가 동영상을 요구할 때, 하나의 파일 통짜로 주는 것이 아니라 원하는 시간대의, 원하는 화질의 파일을 건네주면 된다. 이런 작업을 수행하기 위해 여러가지 프..

ETC 2023.12.30

Google의 Gemini 서비스 공개

👣 Reference Gemini - 나무위키 이 저작물은 CC BY-NC-SA 2.0 KR에 따라 이용할 수 있습니다. (단, 라이선스가 명시된 일부 문서 및 삽화 제외) 기여하신 문서의 저작권은 각 기여자에게 있으며, 각 기여자는 기여하신 부분의 저작권 namu.wiki 구글 제미나이(Gemini)! 너 잼민이 아냐? | Smilegate.AI 오늘 소개할 기술은 구글의 제미나이입니다. 제미나이는 구글에서 LLM의 최고는 누구인가, 어떤 모달리티까지 커버할 수 있는가, 요즘 핫한 on-device AI까지 다 먹어버리겠다고 나온 모델입니다. smilegate.ai 👣 개요 구글과 딥마인드가 개발한 멀티모달 인공지능. 여기서 멀티모달이란 기존에 텍스트로만 소통할 수 있던 ChatGPT, Bard와는 달..

Tech Issue 2023.12.09

실시간 영상 스트리밍 서비스인 Twitch 한국 철수

👣 Reference 트위치 대한민국 사업 철수 사건 - 나무위키 한국 시간 기준 2024년 2월 27일부로 한국 내 Twitch 운영이 종료됩니다. 어려운 결정에 이르게 된 자세한 내용은 Twitch 블로그를 통해 확인하실 수 있습니다. [ 펼치기 · 접기 ]오늘 매우 유감스러운 namu.wiki 망 사용료 - 나무위키 국내 망 이용료, 유럽보다 15배 비싸 2016년 8월 18일 CDN 업체인 클라우드플레어는 전 세계의 망 사용료에 관한 글을 올리며 한국의 망 사용료는 유럽보다 15배 이상 비싸며, 2015년 미래창조과학부( namu.wiki 그리드 컴퓨팅 - 나무위키 이 저작물은 CC BY-NC-SA 2.0 KR에 따라 이용할 수 있습니다. (단, 라이선스가 명시된 일부 문서 및 삽화 제외) 기여하..

Tech Issue 2023.12.09

유용한 도구 모음

👣 개요 형식에 얽매이지 않고 자유롭게 메모 가능한 게시글. 👣 Awk - 로그 내용 파싱 도구 로그 내용을 마치 엑셀처럼 분해할 수 있는 유용한 도구 REPOSITORY TAG IMAGE ID CREATED SIZE ubuntu 20.04 1a2b3c4d5e6f 2 weeks ago 73.9MB nginx latest 7a8b9c0d1e2f 3 months ago 132MB myapp v1 3g4h5i6j7k8l 1 year ago 458MB 위와 같은 출력 내용이 있을 때, 공백을 기준으로 파싱을 도와주는 명령어. docker images | awk '{ print $1 }' 만약 위 명령어의 출력값을 호출하면 다음과 같이 1번째 열의 내용이 출력됨. REPOSITORY ubuntu nginx mya..

Bash 2023.11.30

Optimizer 中 캐싱에 따른 검색 속도 향상

👣 개요 캐싱에 따른 검색 속도 향상 여부를 확인하는 실험. 👣 실험 계획 Item 테이블의 Row 갯수는 100만 개 입니다. 테스트를 위해 2개의 메서드를 구성했습니다. 1번째 메서드는 'readById' 메서드로서 단순히 ID값으로 엔티티를 조회하는 메서드입니다. 2번째 메서드는 'readByIdWithCaching' 메서드로서 ' readById'에 단순히 캐싱을 적용했다고 볼 수 있습니다. 실험에 사용되는 테스트 코드는 위와 같이 순차적으로 N번 메서드를 호출하고 해당 실행 시간을 확인하는 형태로 진행된다. 👣 실험 수행 ⚗️ 대조군 - 캐싱 없이 검색 1000번 정도 메서드를 호출했을 때의 결과다. 3149 ms, 즉 3.149초가 걸림을 알 수 있다. ⚗️ 실험군 - 캐싱 적용 후 검색 10..

프로젝트 회고 2023.11.30

Optimizer 中 Projection 연산 적용 시 검색 속도 향상

👣 개요 Projection 연산을 통해 꼭 필요한 정보만 가져와 검색 속도 향상. 👣 실험 계획 Review 테이블의 Row 갯수는 10만 개 입니다. 그리고 Review 테이블의 칼럼 갯수는 총 5개 입니다. 만약 DTO에서 5개의 칼럼을 모두 요구하는 것이 아닌 특정 칼럼만 요구한다는 상황을 가정. ReviewResponse 는 id, rating이라는 2개의 칼럼만 요구하고 있다. 실험에 사용되는 테스트 코드는 위와 같이 순차적으로 N번 메서드를 호출하고 해당 실행 시간을 확인하는 형태로 진행된다. 👣 실험 수행 ⚗️ 대조군 - Projection 없이 그냥 모든 칼럼 가져오기. 50번 정도 메서드를 호출했을 때의 결과다. 16776 ms, 즉 16.776초가 걸림을 알 수 있다. ⚗️ 실험군 -..

프로젝트 회고 2023.11.29

Optimizer 中 N+1 문제 해결 시 검색 속도 향상

👣 개요 N+1 문제 해결 시 검색 속도 향상. 의도적으로 Dto에서 요구하는 엔티티를 Lazy Fetch로 불러와서 N+1 쿼리를 내보내도록 유도함. 그리고 다양한 방법으로 N+1 문제를 해결하면서 성능 향상을 확인. 👣 실험 계획 위 이미지에서 Member 테이블의 ID 칼럼의 1인 데이터와 연관된 Wish 데이터의 갯수는 113개 이다. 즉, 만약 Lazy Fetch로 ID가 1인 Member의 Wish 데이터를 불러오면 1[Member Query] + 113[Wish Query] 개의 쿼리가 불러와질 예정이다. 위와 같이 하나의 Member 정보를 불러올 때, 해당 Member가 Wish 리스트에 추가한 Item들을 함께 불러올 수 있는 DTO인 MemberResponse를 만들고 MemberSe..

프로젝트 회고 2023.11.29

Optimizer 中 반정규화에 의한 통계 쿼리 실행 속도 향상

👣 개요 반정규화에 의한 통계 쿼리 실행 속도 향상 확인. Item 테이블과 연관 관계에 놓여 있는 Review 테이블의 Rating 칼럼을 이용해 Item 당 평균 평점값을 계산하는 통계 쿼리를 반정규화를 통해 성능 향상 여부를 확인. 👣 실험 계획 Item 테이블의 Row 갯수는 100만 개 있고 Review 테이블의 Row 갯수는 10만 개 있다. Review 테이블의 Dummy Data를 만들기 위해 설정한 것들을 보면 item_id는 1~10까지의 값만 임의로 부여되도록 설정하고 rating은 1~5까지의 값을 임의로 부여되도록 설정했다. 따라서, Review 테이블을 item_id 값으로 Group By하게 되면 위와 같은 결과를 얻어낼 수 있다. 의도적으로 평점 평균을 구하기 위해 동원되는 ..

프로젝트 회고 2023.11.29

Optimizer 中 인덱스에 따른 삽입 속도 저하

👣 개요 인덱스의 여부에 따른 삽입 속도 저하 여부를 확인하는 실험. 👣 실험 계획 Item은 name에 인덱스가 부여되지 않았고 해당 Item 테이블의 Row 갯수는 100만 개 입니다. 실험을 위해 사용된 코드는 위와 같이 하나의 엔티티를 저장할 때마다 트랜잭션이 마무리가 되면서 쿼리가 날아가게 된다. 우선 임의의 입력값을 만드는 메서드를 만들어준 다음 대략 10000개의 엔티티를 저장하는 과정을 실행할 계획이었다. 저장한 후, Rollback으로 저장을 취소하는 것이 아닌 최대한 실제 상황과 비슷하게 저장하고 테스트 마지막에 자원을 회수하는 방법으로 테스트를 계획했다. 👣 실험 수행 ⚗️ 대조군 - 인덱스 없이 삽입 우선 10000번 정도 엔티티를 저장했을 때의 결과다. 13936 ms, 즉 13...

프로젝트 회고 2023.11.28