목록전체 글 (316)
ecsimsw
좋아하는 것 어렸을 때부터 문제를 해결하는 것을 좋아했다. 책장에는 추리 소설이나 퀴즈 책만 있었고, 장기, 체스가 세상에서 가장 재밌는 게임이었으며, 수학 문제를 푸는 희열에 중고등학교 때는 솔직히 수학만 했다. 풀이를 고민하고 딱 해결했을 때의 그 쾌감, 그리고 그걸로 주변 친구들에게 받던 인정이 그렇게 좋았던 것 같다. 다른 어느 때보다 재밌었다. 문제 푸는 것만큼이나 뭔가를 만드는 것을 좋아했다. 죄다 과학자나 대통령을 꿈꾸던 주변 친구들이 하나둘씩 현실적인 장래희망을 갖게 될 때 까지도 나는 발명가를 꿈꿨다. 매일 작은 수첩과 그 크기의 샤프를 들고 다녔던 기억이 난다. 갑자기 드는 생각을 기록하고 싶어서. 그 작은 샤프도 내가 만들었었다. 그리고 사람을 좋아한다. 그냥 사람들과 함께 하는게 너..
스케줄러 정기적으로 실행해야 하는 테스크가 있을 수 있다. 일정 시간 간격으로 로직을 실행하거나, 일정 스케줄러는 그런 테스크를 처리하기에 유용하게 사용할 수 있다. 예를 들면 10초마다 한 번씩 혹은 매월 1일마다 한 번씩 지정한 로직을 수행하도록 하는 것이다. 이번 프로젝트에서 매일 한번씩 정산하는 로직을 수행해야 한다. 처음에는 아래처럼 단순히 요청 처리를 위한 스레드와 별도의 스레드를 생성하고 그 안에서 무한정 시간을 비교하는 로직을 수행하려 했으나, 스프링의 스케줄러를 사용하면 직접 스레드를 관리하지 않아도 되고, 시간 비교를 효율적으로 할 수 있을 것이라는 생각에 스프링 스케줄러를 사용하게 되었다. 스프링 프레임워크에서 Quartz 라이브러리를 사용할 수 있다. 스프링 프레임워크에서 기본적으로..
도입 배경 시작하기 앞서 기존의 배포 방식을 먼저 설명하려고 한다. 적용한 프로젝트의 배포 방식은 아래 그림처럼, 젠킨스가 프로젝트를 빌드, 전달하고 실행 스크립트에 의해 인스턴스 내부에서 실행하고 있다. 그렇게 빌드된 jar 파일을 실행하는 과정은 단순히 실행 중인 Application 프로세스를 종료하고, 새로 빌드된 Application을 띄우는 것이었는데, 이런 기존 방식에 두 가지 문제가 있었다. 기존 방식의 실행 스크립트 확인하기 더보기 #!/bin/bash echo "> now ing app pid find!" CURRENT_PID=$(pgrep -f back-end) # PID 구별 key로 back-end가 들어갔다. 본인 환경에 맞게 수정한다. echo "$CURRENT_PID" if ..
CloudWatch agent 로그 파일 지정과 이벤트 수집 Spring application에서 발생하는 로그 파일을 확인하기 위해 매번 인스턴스에 직접 들어가서 파일을 확인하는 작업은 번거롭고, 위험하다. 가급적이면 개발자 개인이 배포 서버 인스턴스를 직접 건드는 작업을 피하고 싶었고, application에서 생성되는 로그 파일을 CloudWatch에 출력하고자 했다. 애플리케이션에서 생성된 파일을 CloudWatch에 출력하는 방법, 그리고 파일로 생성하지 않고 서버의 정보를 CloudWatch에 직접 뿌리는 방법을 공부해왔다. 전자의 경우에는 에러 파일을 그래도 출력하기 위함이었고, 후자의 경우에는 서버의 동작 여부를 확인하기 위함이었다. 해당 프로젝트내에선 사실상 에러 로깅 외의 로그가 없었고..
AWS Cloudwatch Agent AWS Cloudwatch로 인스턴스 상태를 확인, 관리할 수 있다. CloudWatch에서 기본적으로 제공하는 cpu 사용률, 네트워크 패킷 수 외에도, 다음을 따라 Cloudwatch agent를 이용하면 해당 인스턴스의 메모리와 디스크 사용률까지도 확인할 수 있다. 적용한 Cloudwatch 대시보드는 아래와 같다. 1. IAM role, ec2 cloudwatch API 생성 2. 원하는 ec2 인스턴스에 해당 role 적용 3. 우분투 기준, CloudWatchAgent 다운로드 및 설치 wget https://s3.amazonaws.com/amazoncloudwatch-agent/ubuntu/amd64/latest/amazon-cloudwatch-agent..
배경 이번 프로젝트의 경우에는 jdk8이 문제가 없던 상황에서 잘 쓰다가 jdk11이 필요한 상황이었다. 예를 들면 rabbitMQ나 sonarqube를 사용하는데 11 이상이 필요한 것을 확인했다. dev 서버, prod 서버, 프론트 서버, 딥러닝 학습 서버,,, 이번 프로젝트 안에서 기존에 젠킨스 설정을 잡아둔게 너무 많아 새로 젠킨스를 설치할 수는 없었고, 결국 버전을 바꾸기로 했다. 그 과정이 명확하게 설명이 된 블로그가 없길래 한번 정리해본다. default version : 8 도커를 이용해서 젠킨스 설치 시 기본으로 설치되는 jdk 버전은 8이다. 젠킨스 서버 내부에서 jdk 를 설치하고, 버전을 지정할 수 있는데 무료는 젠킨스9 까지이다. 그런데 젠킨스에서 설치 지원을 안한다는거지 젠킨스..
이끌기 위한 용기는 없고, 따르기 위한 존중도 없고. '이끌든지, 따르든지, 비키든지'. CNN 창업자 테드 터너가 한 말이라고 한다. 이전까지는 이렇게까지 와닿지 않았는데, 이번 팀 미션을 하면서 크게 공감한 말이다. 저 한 문장은 내 잘못된 태도와 앞으로 어떻게 바뀌어야 하는지를 모두 포함하고 있었다. 프로젝트 초반에 열정이 앞서 의견을 마구마구 내었다. 물론 의견을 잘 내주고 대화에 참여해주는 것은 중요하다고 생각한다. 문제는 나는 비판만을 말했다. 스스로도 모호하고, 정확히 알지 못하면서, 투덜대기만 했다. 성장을 위해서 비판이 분명히 필요한 것은 맞지만, 내 비판은 성장을 위하지 않았다. 그저 '뭔가 거슬리고, 내 것과 다르다' 라는 생각 아래 문제점을 찾았던 것 같다. 어느 순간부터 내가 문제..
그런 REST API로 괜찮은가 지금껏 RESTful 한 API를 설계하고 있는 줄 알았다. 'REST API 설계 가이드'를 구글링하고 다른 블로그 들에서 소개하는 REST API 형식에 따라 적절한 요청 메소드와 URL, 에러 코드와 응답 내용만 맞추면 그게 RESTful 하다고 생각하고 있었다. 이응준님의 그런 REST API로 괜찮은가 세미나를 보고, 그 생각이 완전히 부서졌다. 지금 내 설계를 REST API라는 단어로 표현하면, REST API를 처음 소개하고 제안한 로이 필딩이 노하실 것이다. 그래서 왜 Rest API라고 불리우는 인터페이스들이 로이 필딩이 제안한 RESTful이 아닌 건지, 그럼 진짜 REST API는 어떻게 만드는 건지 정리하고자 한다. "I am getting frus..