ecsimsw

도입 배경 시작하기 앞서 기존의 배포 방식을 먼저 설명하려고 한다. 적용한 프로젝트의 배포 방식은 아래 그림처럼, 젠킨스가 프로젝트를 빌드, 전달하고 실행 스크립트에 의해 인스턴스 내부에서 실행하고 있다.   그렇게 빌드된 jar 파일을 실행하는 과정은 단순히 실행 중인 Application 프로세스를 종료하고, 새로 빌드된 Application을 띄우는 것이었는데, 이런 기존 방식에 두 가지 문제가 있었다. 기존 방식의 실행 스크립트 확인하기더보기#!/bin/bashecho "> 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-..

Load Balancing과 세션 유지로드 밸런싱을 간단히 말하면, 트래픽을 한 서버에서 모두 처리하는 것이 아니라, 다수의 서버에 적절하게 분배해주는 것이다. 보통 여러 대의 WAS 전면에 Web Server를 두고, 요청을 WAS에 적절히 나누는 식으로 사용된다. 이렇게 로드 밸런싱을 이용하면 서버의 부담도 줄일 수 있으면서, 한 서버가 다운되더라도 서비스를 이어갈 수 있다는 장점이 있다. 문제는 세션이다. 세션은 서버에 데이터를 저장한다고 배웠는데, 여러 was에 요청을 분산하면 세션 지속에 문제가 없을까 궁금했다. 해결책먼저 세션 지속을 보장하는 Web Server를 사용할 수 있을 것 같다. 예를 들면 NginX plus는 Session Persistence를 지원하고 있음을 확인했다. Ses..

WAS에 전면에 Web Server를 두는 이유WAS에서도 정적 자원을 처리할 수 있음에도, 아래와 같이 web server를 was 전면에 두는 꼴의 서버 구조가 보편적인 이유가 궁금했다.왜 WAS와 독립된 Web server를 따로 두는 걸까. 그 이유를 정리해보았다.   정적 요청은 WAS까지 안가도 되잖아?WAS는 바쁘다. 요청을 처리해야하고, DB 서버가 분리되어 있다면 DB 서버와 통신도 해야할 것이다. 정적 자원 요청을 전면 web server에서 빠르게 처리해주면 WAS에 부담이 줄 것이다.     이때 서버에 따라  캐싱을 사용할 수 있을 것이다. (예를 들면 NginX는 정적 컨텐츠의 캐싱을 지원한다.) 요즘의 웹 페이지는 모두 동적이지, 정적인 컨텐츠가 있다면 얼마나 있을까를 고민하는..