mind mind

1. security group 확인하기2. myid 파일에 config 설정대로 숫자 적었는지 확인하기3. /data, /logs 파일 경로 제대로 설정했는지 확인하기

1. SSH 접속이 제대로 되는지 확인 2. ls -al 에서 root 계정인지 사용자 계정인지 확인 3. 복사 대상 파일 혹은 디렉토리를 chmod 777로 변경 4. sudo 명령어로 실행

1. 이미지를 등록하기 위해서는 node instance를 생성한다. 2. instance를 생성할 때, 호스트 IP, Security Group 관리 그리고 제일 중요한 SSH 키 등록이 필요하다. 3. 나머지 정보(CPU, Memory 등)은 알아서 자동으로 세팅해준다. 4. 필요한 기능이 더 추가되면 그 때가서 하면 된다. 5. Hadoop, Spark, Java, Python, Zookeeper 등 필요한 프로그램들을 설치해준다. (wget) - root 하위 cluster 폴더를 만든 후, 각각의 폴더에 다운로드해준다. - /etc/environment에서 환경 변수를 등록해준다. * SSH 키 페어 등록시 헷갈리는 사항 - keygen을 하고 나서, chmod 600을 해줘야 한다. (too ..

1. zookeeper를 먼저 실행한 후, Kafka를 실행해야 한다. 2. sh 파일을 실행하는 것이 아닌, window 폴더 하위의 bat 파일을 실행해야 한다. 주키퍼 기동 – bin\windows\zookeeper-server-start.bat config\zookeeper.properties 카프카 기동 – bin\windows\kafka-server-start.bat config\server.properties

한 번은 프로그램 소스를 보다가 try-catch 문이 남발되어 있는 현상을 목격한 적이 있다. 반복문에 if문을 넣어도 CPU에 굉장한 부담을 주는데 이런 잘못된 예외처리 방식은 문제가 커보였다. 또한, JDBC와 Spring JDBC의 비교를 하면서 내부적인 예외처리에 차이가 있음을 확인했고, Checked Exception와 Runtime Exception의 구체적인 차이가 궁금해졌기 때문에 예외 처리에 대해 긴밀하게 파악하고자 한다. 1. try - catch 문은 일반적인 if 문과는 다르게 자원 할당 및 해제에도 관련이 깊기 때문에 JVM 성능 최적화에 방해가 될 수 있다. 2. 사전에 조건 처리를 해서 배치 처리 대상건수를 조금이라도 줄이는 것이 효율적인 방법이다. 1. Effective J..

주로 배치 작업을 할 때 JDBC의 다양한 기능을 이용해서 도움을 받은 적이 많다. 단순하게 JDBC가 DataSource, Connection, PreparedStatement, ResultSet으로만 알고 있는 것을 넘어서 여러가지 옵션 및 세부 사항을 확인해보도록 한다. (1) checked Exception - Spring JDBC에는 해당 Exception 처리 방식을 Runtime Exception으로 처리해서 뭔가를 개선해줬다는데 과연 어떤 부분이 불완전했던 것일까? - 개발자가 직접 try-catch문을 사용해서 에러처리를 해야하는 것이 불편하다는 것인가? - Runtime Exception에서는 자동으로 Rollback을 해주는데 비해 Checked Exception의 경우 직접 catc..

1. DAO 패턴 2. DataSource 객체 3. JDBC 4. JDBC vs Spring JDBC 5. JdbcTemplate 라이브러리 DAO 패턴이란? - 비즈니스 로직을 분리한 데이터 엑세스 로직으로 DB에 직접 연동된다는 점과 query문이 포함된다는 점이 특징이다. - Spring에선 repository 클래스가 이를 담당한다. DataSource 객체란? - JDBC 라이브러리의 핵심이 되는 객체로 미리 Connection Pool을 설정할 수 있다는 점에서 멀티유저 환경에 필수적이다. - SimpleDriverDataSource : 풀링 지원을 하지 않고 매번 커넥션을 생성하는 DataSource - SingleConnectionDriverDataSource : 순차적으로 진행되는 통합..

본인이 저지른 실수는 아니지만 간혹 DAO 클래스 내부의 Query를 수정할 때, 예기치 못한 오류들이 운영에서 발생하는 경우가 종종 있다. 개발 DB에 쌓인 데이터는 운영 DB에 쌓인 데이터와 일치하지 않기 때문에 DBMS에 설정된 Optimizer 혹은 index plan이 다르게 설정된 것이 그 원인이었다. 해결 방법은 테이블 구조와 FK 관계를 정확하게 파악하고 올바르게 조인을 사용해야 한다. 이젠 쿼리문, DAO 하나를 수정해도 실제 Plan을 확인하면서 개발과 운영에서 동일한 cost가 소요되는지를 확인해야 한다. 이것이 바로 아무리 테스트 코드가 잘 작성되었고 JPA가 많은 기능을 지원해줘도 정확한 DB 트랜잭션을 확신할 수 없는 이유다. 또한 지나친 튜닝은 오히려 데이터 정합성에 오류가 발..