카프카 핵심 가이드 - 7. 신뢰성 있는 데이터 전달
카프카는 다양한 신뢰성 활용 사례가 있으며, 신뢰성 보장을 위해 여러 방법을 제공한다. 브로커 설정과 프로듀서, 컨슈머의 올바른 사용으로 신뢰성이 유지되며, 에러 처리와 모니터링을 통해 시스템의 안정성을 검증할 수 있다.
0개의 댓글
0개의 질문
카프카는 다양한 신뢰성 활용 사례가 있으며, 신뢰성 보장을 위해 여러 방법을 제공한다. 브로커 설정과 프로듀서, 컨슈머의 올바른 사용으로 신뢰성이 유지되며, 에러 처리와 모니터링을 통해 시스템의 안정성을 검증할 수 있다.
0개의 댓글
0개의 질문
MySQL 8.0부터는 권한을 Role로 관리하며 사용자 계정은 IP 주소와 호스트명까지 고려하여 생성된다. 시스템 계정과 일반 계정으로 나뉘며, 비밀번호 관리 및 권한 설정에 대한 다양한 옵션이 제공된다.
0개의 댓글
0개의 질문
카프카의 내부 매커니즘은 주로 주키퍼와 브로커 간의 관계를 다루며, 클러스터 멤버십과 컨트롤러의 역할에 대해 설명하고 있다. 또한, KRaft 컨트롤러에 대한 새로운 설계와 복제 기능, 리더 선출 과정 등을 소개하고 있다.
0개의 댓글
0개의 질문
카프카에서는 애플리케이션 내부에서 직접 관리 명령을 통해 AdminClient를 사용하여 카프카를 관리할 수 있으며, 비동기적이고 최종적 일관성을 가지는 API를 제공한다. AdminClient의 메서드들은 Options 객체를 인수로 받아 다양한 설정을 통해 사용되며, 토픽 설정, 브로커 설정 등을 제어할 수 있다.
0개의 댓글
0개의 질문
FastAPI와 SQLAlchemy 쿼리 최적화를 위해 세션 처리 방식을 변경하고, AsyncSession을 테스크별로 사용해야 함을 알 수 있었다. 이전에는 세션을 매번 새로 생성했지만, 이제는 task 별 세션을 관리하여 문제를 해결하고 API 소요 시간이 개선되었으며, 병렬 처리를 통한 I/O time 개선으로 큰 최적화가 이루어지진 않았다.
0개의 댓글
0개의 질문
카프카 컨슈머는 컨슈머 그룹의 일부로 동작하며, 파티션에 대응되지 못한 컨슈머는 놀게 되므로 적절한 파티션 수를 설정하는 것이 중요하다. 리밸런스는 컨슈머 그룹이 사용하는 파티션을 재할당하는 것으로, 조급한 리밸런스와 협력적 리밸런스 방식이 있으며, 3.1 버전 이후에는 협력적 리밸런스가 기본값으로 사용된다.
0개의 댓글
0개의 질문
카프카 프로듀서는 메시지를 생성하고 네트워크 상에서 전송하는 과정을 거친다. 메시지 전송 방식은 Fire and forget, Synchronous send, Asyncronous send로 나뉘며, 각각의 방식에 따라 메시지 전송 및 처리 방법이 달라진다.
0개의 댓글
0개의 질문
FastAPI와 SQLAlchemy를 사용하여 중복 쿼리 최적화하는 과정과 결과에 대해 설명하고 있습니다. 중복 쿼리를 줄여 성능을 개선하기 위해 중복 쿼리 메모리 캐싱이나 코드 수정을 통한 최적화 방법을 제안하고, identity map을 활용하여 세션 메모리에서 엔티티를 반환하는 방법으로 성능 향상을 이끌어내는 내용이 담겨 있습니다.
0개의 댓글
0개의 질문
카프카를 설치하고 실행하는 방법부터 주요 설정까지 알아보았습니다. 주요 설정 중에는 브로커 ID, 리더 분산 설정, 메시지 보존 시간 등이 있습니다.
0개의 댓글
0개의 질문
기업에서 데이터는 중요한 부분이며, 카프카는 데이터를 효율적으로 다루기 위한 메시지 발행/구독 시스템으로 분산 커밋 로그와 스트리밍 플랫폼으로 사용됩니다. 카프카는 확장성과 성능 면에서 우수하며, 다중 클러스터 운용이 가능하고 안정적인 데이터 보관을 제공합니다.
1개의 댓글
0개의 질문
동아리 코드당이 사용 중인 Qindao OJ 오픈소스의 성능 문제로, 메모리를 과도하게 사용할 때 Memory Limit Exceeded 대신 Runtime Error가 발생하여 문제가 있었으며, Stage 서버에서 1GB를 넘는 메모리 사용 시 Runtime Error가 발생하는 등 sandbox 내부적으로 메모리 한계가 존재함을 확인했습니다.운영 환경에서는 memory hard limit을 조절하여 512MB로 제한된 문제에서 Runtime Error를 방지할 수 있다는 해결책이 제시되었습니다.
1개의 댓글
0개의 질문
FastAPI, SQLAlchemy, Alembic을 사용한 프로젝트에서 DEV 배포 자동화를 완료하고 PROD 배포 자동화를 위해 스키마 정보를 업데이트하고자 하는 요구사항과 해당 작업을 위해 Lambda 함수를 활용하는 방법이 소개되었습니다. 또한, RDS 연결 정보 보안처리에 대한 IAM 인증 및 Docker 사용 방법 등이 제시되었으며, Lambda 함수와 S3 간의 설정 문제에 대한 해결책을 찾기 위해 더 많은 고민이 필요함이 언급되었습니다.
0개의 댓글
0개의 질문
Node의 이벤트 루프 환경에서 libuv의 백그라운드 쓰레드 수와 CPU 코어 수의 상관관계를 조사한 결과, CPU 코어 개수가 많을수록 백그라운드 Thread를 병렬로 처리할 수 있어 성능이 향상되는 것으로 나타났다. 그러나 너무 많은 Thread를 설정하면 Context Switching 비용으로 인해 오히려 성능이 감소하는 것을 확인할 수 있었다.
1개의 댓글
0개의 질문
부동산 지수를 계산하기 위해 거대한 matrix를 다루는 연산 프로그램에서 메모리와 연산 속도 문제가 발생했다. 병렬 처리로 해결하려 했지만 쓰레드는 GIL때문에 효율이 떨어지고, 프로세스는 메모리 문제가 발생하여 각각의 연산을 파일로 저장하는 방식으로 최종적으로 문제를 해결하였다.
1개의 댓글
0개의 질문
SQLAlchemy를 사용한 프로젝트에서 트랜잭션과 지연로딩 에러가 발생했는데, created_at 필드에 접근하는 과정에서 발생한 문제를 해결하기 위해 트랜잭션 내에서 커밋을 통해 데이터를 가져오거나, 필드를 제거하거나 클라이언트 default 값으로 설정하는 방법 등 여러 가지 해결책이 제시되었다.하지만 완벽한 해결책은 아니라고 판단되며, SQLAlchemy 2.0의 mapped_column을 사용하면 eager_defaults 옵션을 통해 이런 문제를 더욱 쉽게 처리할 수 있다는 참고 자료도 있었다.
0개의 댓글
0개의 질문
FastAPI 프로젝트에서 기존 방식의 커스텀 에러 처리를 개선하기 위해 Not Found 에러를 추가하고, 이를 관리하는 패키지와 핸들러를 만들어 등록하는 방법을 소개하였다. 요청 시 발생한 404 코드와 메시지를 반환하는 핸들러 등록은 앱의 구조 변경과 유지보수에 도움이 될 것으로 기대된다.
0개의 댓글
0개의 질문
python project의 도커 이미지 최적화를 통해 shapely 패키지와 시스템 라이브러리가 docker image 사이즈에 큰 영향을 미치지 않았으며, dive 툴을 활용하여 불필요한 파일들을 .dockerignore에 추가해 이미지 사이즈를 289MB에서 276MB로 줄였다.pytest 라이브러리들은 가볍기 때문에 dev-dependencies를 배포시 제외하여 이미지 사이즈를 줄일 수 있었다.
0개의 댓글
0개의 질문
FastAPI 프로젝트 구조를 변경하여 SQLAlchemy session 사용 방식을 개선했으며, 기존 service 레이어를 service, repository 레이어로 분리하고 response schema와 dto를 나누는 등의 작업을 했다. 이에 추가적인 소요가 감소하고 request 단위 세션과 repository method 단위 조회용 세션을 도입하여 세션 사용 방식도 개선했다.
0개의 댓글
0개의 질문
FastApi 프로젝트 구조 변경을 위한 best practice에는 Spring의 장점과 Fastapi의 비동기 처리 가능성을 혼합하는 방식이 제안되었다. Dependencies를 효율적으로 관리하고 DI 방식을 사용하여 유지보수성과 유닛 테스트 용이성을 증진시키는 것이 중요한데, 도메인별로 폴더를 구분하고 서비스 레이어를 분리하여 개발하는 것이 권장된다.
0개의 댓글
0개의 질문
JavaScript의 toFixed() 함수를 사용하면 숫자를 지정한 자릿수로 반올림할 수 있으며, 반환형은 문자열입니다.
1개의 댓글
0개의 질문