반응형

h3. Gatling ???

 

- Gatling은 오픈 소스 부하 테스트 프레임워크로 Scala로 개발되었으며, Async Http Client와 Netty, 그리고 Akka를 사용한다.

- Gatling은 여러 개의 테스트를 실행하는 것이 가능하며 복잡한 시뮬레이션도 테스트 가능하다.

- Gatling은 무료 성능 측정 툴로 강력한 report기능을 제공해 주는 장점이 있습니다.

 

간단하게 사용법에 대해서 설명하도록 하겠습니다.

 

 

h5. \[ 시작전 설치 \]

 

[참고] Gatling을 사용을 위해서는 자바가 설치되어 있어야함[http://gatling.io/#/resources/download]

들어가서 zip파일을 받아 압축을 풀어줍니다.

 

 

 

h5. *1. Gatling 디렉터리 구조*

 

/bin 에는 스크립트를 생성(녹화)하는 recorder.sh와 스크립트를 실행하는 gatling.sh 파일이 있고

 

/conf에는 설정 파일이, /lib에는 라이브러리가,

 

/results에는 스크립트를 실행한 결과 페이지(HTML)가,

 

마지막으로 /user-files에는 녹화한 스크립트 파일(scala)과 데이터 파일이 들어 있습니다.

테스트 데이터 파일은 data 폴더에, 스크립트 파일은 simulations 폴더에 있고, 각각이 클래스 패스가 잡혀 있으니 구조에 맞춰 파일을 위치시키면 됩니다.

 

 

 

 

h5. *2. 스크립트 작성*

/user-files/simulations 안에서 동작시킬 스크립트를 작성합니다.

brooklynGatlingTest.scala 가 테스트를 위해 작성한 스크립트 입니다.

 

 

 

스크립트 내용은

{code:scala}

import io.gatling.core.Predef._

import io.gatling.http.Predef._

import scala.concurrent.duration._

 

class BrooklynGatlingTest extends Simulation {

   val httpProtocol = http

                .baseURL("http://10.161.0.28:8080")       // 테스트할 base URL

                .acceptCharsetHeader("ISO-8859-1,utf-8;q=0.7,*;q=0.7")

                .acceptHeader("text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8")

                .acceptEncodingHeader("gzip, deflate")

                .acceptLanguageHeader("en-US,en;q=0.5")

                .disableFollowRedirect

 

  val scn = scenario("Brooklyn DB select Test Scenario")

    .exec (

          http ("request_1" )

        .get ( "/randomAdid" )  // 테스트하고자하는 페이지 URI

         .check(status.is (200))

        )

 

     setUp(

     scn.inject(rampUsers(100) over (1 seconds))  // 1초에 100명의 유저

     ).protocols(httpProtocol)

}

{code}

자세한 옵션 및 사용법은 아래 링크를 참고하시면 좋을 것 같습니다.

\[ 참고링크 \][https://greencrayon00.wordpress.com/2015/11/01/%EA%B0%9C%ED%8B%80%EB%A7%81gatling%EC%9C%BC%EB%A1%9C-%EC%84%B1%EB%8A%A5-%ED%85%8C%EC%8A%A4%ED%8A%B8%ED%95%98%EA%B8%B0-1%EB%B6%80/]

 

 

 

 

h5. *3. 테스트하기*

작성한 스크립트로 실제 테스트를 진행해보도록 합시다.

테스트는 bin/ 디렉터리로 이동해 ./gatling.sh 스크립트를 실행합니다.

해당 스크립트를 실행하게되면 컴파일된 파일의 목록을 보여줍니다.

 

 

 

위와 같이 뜨면 brooklynGatlingTest가 0번째 목록에 있기때문에

콘솔에 0을 치고 enter.

 

Simulation BrooklynGatlingTest started가 뜰때까지 enter.

 

테스트가 수행되는 과정이 보이게 됩니다.

 

 

테스트가 완료되게 되면 테스트 결과를 리포트로 받아보실 수 있습니다.

 

 

 

h5. *4. 리포트확인*

리포트트는 result 디렉터리에서 확인가능하고 테스트별 디렉터리가 생겨납니다.

테스트 디렉터리내의 index.html을 열어보시며 테스트 결과를 볼 수 있습니다.

 

 

 

 

 

*자세한 설정 및 옵션은 아래 url 참고부탁드립니다.*

[http://gatling.io/docs/2.2.3/]

반응형
반응형

 JSP/SERVLET 파트에서 SERVLET이 동작하는 흐름에 대해서 알아봤다. 컨테이너에서 서블릿이 초기화되고 그 해당 서블릿이 어떻게 DispatcherServlet에 의해 처리되어 뷰를 반환하게 되는지에 대해 살펴보도록 하겠다.


  DispatcherServlet에 대해 간단히 설명하자면, DispatcherServlet은 Controller로 향하는 모든 웹 요청의 진입점이며 웹 요청을 처리, 결과 데이터를 Client에게 제공하는 역할을 한다.네 맞습니다. DispatcherServlet은 우리가 각각 분리하여 만든 Model 파트와 Controller파트 View 파트를 조합하여 브라우저로 출력해주는 역할을 수행하는 클래스이며 DispatcherServlet으로 인해 web.xml의 역할을 획기적으로 축소시켜 주었다.

예전 DispatcherServlet이 있기전에는 모든 사용자의 요청 url을 일일이 해당 요청을 처리하는 servlet과 매핑시켜주는 작업을 지정해 주었어야만 했다.예를 들어, 기본URL/happy, 기본URL/contents, 기본URL/subject 등의 요청이 들어왔을 때 이에 해당하는 서블릿과의 매핑 작업을 web.xml에 모두 정의해주고 사용했어야 했던 만큼 web.xml 도 복잡해지고 손수 작업에 필요한 서블릿 정의와 매핑작업을 해줘야 했기 때문에 여간 귀찮은 일이 아니였다.

하지만 지금은 web.xml에

이렇게 DispacherServlet을 정의해주고 모든 URL에 대해 매핑을 해주게 되면 DispatcherServlet이 요청 url에 해당하는 컨트롤러를 찾아 매핑해주게 된다. 얼마나 고마운 일인가. 위의 소스코드에 대해 이해가 안가시는 분은  http://blog.naver.com/kim3zz/220273028176 servlet 매핑에 대한 설명 부분을 참고하시길 바란다.


DispatcherServlet은 이렇게 web.xml 을 획기적으로 축소시켜주었고 개발자에게 요청에 따른 컨트롤러를 일일이 매핑해야하는 번거로움 또한 덜어주었다. 이제 그럼 DispatcherServlet이 어떻게 동작하는지에 대해 알아보자.

[ 그림 1 ] 사용자가 특정 URL을 요청하게 되고 웹서와 컨테이너를 거쳐 해당 요청이 DispatcherServlet을 타게 된다.

[ 그림 2 ] DispatcherServlet은 요청에 대한 정보를 HandlerMapping에게 보내 요청을 처리할 수 있는 Controller을 찾아 DispatcherServlet에게 다시 반환하게 됩니다. HandlerMapping은 클라이언트 요청을 어떤 Controller가 수행할지의 여부를 결정해 주며 스프링의 디폴트 전략에 의해 BeanNameUrlHandlerMapping이 설정되어 있어 따로 설정을 하지 않아도 요청 url과 동일한 이름을 갖는 Controller을 찾아 매핑시켜 주게 된다.

[ 그림 3 ] DispatcherServlet은 해당 컨트롤러에게 요청에 대한 처리를 부탁하고 컨트롤러는 요청을 처리한 후에 응답받을 ModelAndView를 리턴하게 됩니다.

[ 그림 4, 5 ] ViewResolver는 컨트롤러가 반환한 ModelAndView를 받아 해당 view가 존재하는지 검색하게 됩니다. 해당 View가 있다면 전처리 과정을 거쳐 해당 View를 반환해 줍니다.

InternalResouceViewResolver를 보시면 name="prefix"와 "suffix"를 보실 수 있는데 컨트롤러가 던지 view 앞에 붙여지는 것이 prefix이고 뒤에 붙여지는것이 jsp가 되게 됩니다. 예를 들어 컨트롤러가 "board"라는 뷰 스트링 객체를 던졌다면 리졸버를 통해 /WEB-INF/views/board.jsp 가 되어 해당 뷰에서 요청이 보여지게 됩니다.

다음에는 web.xml에서는 어떠한 작업들이 이루어지는 지에 대해 살펴보도록 하겠습니다.

ref :https://kisukpark.wordpress.com/2013/08/29/spring-mvc-%EA%B8%B0%EB%B3%B8-%EA%B0%9C%EB%85%90/http://egloos.zum.com/springmvc/v/504151




반응형
반응형


리눅스 소유자/그룹 변경 root 에서 irteam 으로~!소유자가 root일 경우에는 일반 계정으로 해당 스크립트 수정이 안되거나 빌드시 해당 스크립트에 접근이 안되는 문제가 있다. 따라서 톰캣, 아파치 등 설치할 때 sudo 계정이 아닌 일반 계정으로 설치하는 것이 좋다.

부득이하게 sudo 권한으로 설치를 했다면 다음과 같은 명령어로 권한 변경

sudo chown -R[옵션] [소유자:소유그룹] [디렉토리 or 파일명]> -R : 하위 디렉토리/파일에 모두 적용> 해당 파일의 모든 파일들을 순환하며 소유자 그룹 변경

그림에서 보면 logging.properties와 server.xml이 root로 되어있어서 일반 계정으로 수정 불가능

sudo chown -R irteam:irteam server.xml로 소유자 변경

변경된 것을 확인 할 수 있다.

서버 작업 시 특정 계정으로 스크립트를 실행했는데 접근이 안된다면 chown 명령어를 통해 소유자 및 그룹을 변경하도록 하자!!!




반응형
반응형



 안녕하세요. 오늘은 crontab에 대한 간단한 소개와 crontab을 통한 특정 기간 이상이 지난 log를 삭제하는 법에 대해서 살펴보도록 하겠습니다. 지나치게 불필요한 log를 많이 가지고 있게 되면 서버 메모리 공간에 여유가 부족해 문제를 일으킬 수도 있기에 일정 기간이 지난 로그 혹은 불필요 로그는 가지고 있지 않는 편이 원할한 서버 관리에 도움을 줄 수 있음을 상기하고 포스팅 시작해보도록 하겠습니다.

#CrontabCron은 원하는 시간에 특정 명령을 서버에서 실행 시키기 위한 데몬으로 특정 시간에 특정 작업이 필요할 경우 사용하게 됩니다.예를 들어 매일 자정에 그 날에 자료를 백업을 한다거나 매일 새벽 2시에 로그를 백업하는 작업이 필요한 경우 등 이렇게 특정 시간에 반복적으로 작업을 할 경우에 사용됩니다.한 마디로 일정 기간마다 특정 명령을 실행하도록 하는 것이다.

#Crontab 사용하기

crontab -l> 현재 crontab에 등록 된 작업보기

crontab -e> crontab 편집하기


crontab 등록




#Crontab 작업~ crontab -e를 열어 원하는 시간대에 작업이 이루어질 명령어를 등록해 줍니다.

제가 등록해준 작업은 #Tomcat log 쪽으로 매일 23시 59분에 rotatelog.sh를 실행하게 됩니다.

rotatelog.sh에서는 아파치로그, 프로젝트 로그, 톰캣로그를 삭제하는 스크립트가 작성되어 있습니다.



현재 3년 이상 된 로그들도 쌓여 있는 것을 확인 할 수 있는데 서비스 특성상 1년 까지만 보관하면 별문제 없을 것 같아 현재 날짜를 기준으로 일년이 지난 로그들을 삭제하도록 하였습니다.

#Crontab 등록 스크립트 작성시 find명령어 간단 정리

 

                                      이미지 출처 : http://dbrang.tistory.com/867



이상으로 포스팅을 마치겠습니다.




반응형
반응형


 안녕하세요. 이번에는 전에 한 번 포스팅 했던 '아파치 톰캣7 따라잡기 Part.1"에서 정리하지 못한 부분을 추가적으로 포스팅하도록 하겠습니다. 책을 정리하는 입장에서 제가 잘 몰랐던 부분이나 필요 부분을 문서화 시키는 작업임에 다소 설명적인 부분이 많이 생략될 수 있음을 이해해주시면 감사하겠습니다. 정리를 시작하도록 하겠습니다.


왜 아파치 HTTP 서버를 사용하는가?# 정적 컨텐츠를 효율적으로 제공톰캣도 정적 컨텐츠를 제공할 수는 있지만 아파치 HTTP 서버에 비해 반응 시간이 느리다.

# 10퍼센트 속도 증가아파치 HTTP 서버는 콤캣과 비교해 10퍼센트 정도 더 효율적으로 정적 컨텐츠를 제공한다. 사용자 부하가 높은 상황에서는 아파치를 통합하는 것이 좋다.

# 클러스터링아파치는 톰캣에 다중 인스턴스 연결을 안정적으로 제공하는 가장 효율적인 서버다.

# 보안아파치는 사용자와 호스트 기반 보안을 제공한다. 톰캣에서도 이 기능을 제공한다. 따라서 우리는 애플리케이션의 요구사항을 고려해 아파치와 톰캣 둘 중 누구의 보안을 활성화할 것인지 결정해야 한다.

# 다중 웹사이트 호스팅아파치 HTTP 서버의 가장 훌륭한 기능 중 하나는 다중 웹사이트 호스팅 기능이다. 다중 웹사이트 호스팅은 톰캣 7에서 처음 선보인 기능으로 http.conf를 이용해 32개가 넘는 가상 호스트를 설정할 수 있다. 32개 이상의 가상 호스트를 설정하려면 virtual.conf 파일을 별도로 만든 다음 http.conf에서 virtual.con를 포함하도록 설정해야 한다. (32개 이상이 아니더라도 virtual.conf 파일을 두어 사용하는 경우도 있음)


아파치 Jserv 프로토콜 (Apache JServ Protocol)Jserv는 평문 텍스트가 아닌 바이너리 형태의 데이터를 네트워크로 전송하도록 개발된 프로토콜이다. Jserv는 TCP와 패킷 기반 프로토콜을 사용하므로 웹 서버 성능이 증가한다. 보통 AJP라 부른다.AJP 프로토콜은 mod_jk와 mod_proxy로 이루어졌다. mod_jk와 mod_proxy는 브라우저를 통해 높은 컨텐츠 응답률을 전송할 때도 도움이 된다.

mod_jkmod_jk는 아파치느 IIS(Internet Information Service) 같은 웹 서버를 톰캣 7과 통합할 때 사용하는 AJP 커넥터다. mod_jk를 설치하지 않으면 톰캣에 프론트엔드 웹 서버를 제공할 수 없다. mod_jk는 프론트엔드 웹 서버 뒤에 톰캣을 숨기고 URL을 접근할 때 포트 번호를 제거하는 데 상당히 유용한 모듈이다.

mod_jk.conf 파일의 세부 정보모듈 경로아파치를 시작할 때 모듈을 로드할 위치를 정의한다.EX ) LoadModule jk_module modules/mod_jk.so

작업자 파일 경로작업자 파일 위치를 정의한다. 작업자 파일은 톰캣 인스턴스의 IP, 포트, 로드 분산 방법 등의 정보를 포함한다.EX ) JkWorkersFile conf/workers.properties

# 로그 파일로그 파일은 아파치 톰캣 통합 과정이 기록된다. 아파치/톰캣 간의 연결 양호 상태도 기록된다.EX ) JkLogFile logs/mod_jk.log

# URL 매핑URL 매핑은 아파치 컨텍스트 경로, 정의된 URL 요청 재전송 규칙을 정의한다. 다음과 같이 URL 매핑을 설정했다면 사용자가 http://localhost/sample라는 URL을 입력햇을 때 해당 요청을 톰캣 node1으로 재전송한다.EX ) JkMount /sample/* node1

# 로그 수준로그 수준 파라미터는 mod_jk에서 수행하는 다양한 이벤트를 logs가 어떻게 처리할지를 정의한다.EX ) JkLogLevel info

workers.properties의 세부 정보# 노드 이름호스트의 공통 이름worker.list = node1

# 톰캣의 AJP 포트 세부 정보톰캣에서 AJP 요청을 어떤 포트로 수락하는지worker.node1.port = 8009

# 톰캣 호스트 IP톰캣 인스턴스가 실행 중인 IP 주소worker.node1.host = 10.130.240.31

# 사용중인 프로토콜통신에 사용하는 프로토콜. 기본값은 AJPworker.node1.type = ajp13

# 부하 분산 방법라운드 로빈, 연결 지속 등worker.noe1.1bfactor = 1

톰캣 설정커넥터 포트기본적으로 톰캣은 HTTP 프로토콜 8080포트에서 실행된다. 모든 사람이 기본 포트 번호를 알고 있으므로 해커는 쉽게 포트에 접근해 서버 공격을 시도할 수 있다. 따라서 톰캣의 보안상 가능하면 항상 커넥터 포트와 AJP 포트(기본 값 8009)를 바꾸는 것이 좋다.

# 톰캣을 루트 사용자로 실항하는 것은 치명적인 결과를 초래할 수 있다. 따라서 루트가 아닌 새 사용자를 만들고 만든 사용자가 톰캣 서버를 실행할 수 있도록 권한을 부여하는 방식을 이용한다. 루트와 사용자 그룹에서 설정 파일에 접근할 수 있어야 하며, 이 사용자/그룹에 logs 등의 다른 디렉터리의 읽기/쓰기 권한도 줘야 한다.

# 톰캣 7의 SSL 설정 : 데이터 통신을 안전하게 보호하는 방버븡로 SSL(Secure Socket Layer)이  있다. SSL은 안전한 채널을 통해 데이터를 전송하는 암호 프로토콜이다. 서버가 암호키를 클라이언트 브라우저로 전송하면 클라이언트 브라우저가 암호키를 복호화 한 다음 서버오 클라이언트간에 핸드셰이크(handshake)가 이뤄진다. (이를 가리켜 안전 계층에서 두 방향 핸드셰이크가 일어났다고 한다.)언제 톰캿애 SSL이 필요한가?톰캣을 프론트엔드 서버로 사용할 때 SSL을 더 효과적으로 활용할 수 있다. 아파치나 IIS를 사용한다면 아파치나 IIS 서버에 SSL을 설치할 것을 권장한다.


다음은 마지막 톰캣에서 직면하는 문제들에 대한 해결책에 대해 책의 마지막 부분을 정리하도록 하겠습니다.




반응형
반응형

한가지. 메이븐이란 무엇인가?

메이븐을 한 마디로 정의해서 말을 하자면 개발자로 하여금 프로젝트 관리를 쉽게 도와주는 빌드 툴이라고  할 수 있습니다.

메이븐은 pom.xml이라는 파일에 기반합니다. POM(Project Object Model)이란 Xml 파일에 기반하여 반복적으로 진행되어 왔던 프로젝트 빌드, 리포팅, 문서화 작업등을 도와주는 문서라고 할 수 있습니다.

두가지. 많이 사용되고 있는 ANT와 MAVEN의 비교

아파치 앤트(Apache Ant)는 공통적인 프로젝트 디렉토리 구조와 같은 공식적인 관례를 가지고 있지 않으며, 개발자가 직접 소스코드의 위치와 소스코드의 빌드가 된 파일의 위치, 산출물을 어디에 위치시켜야 하는지 정확하게 지정해주어야 한다. 또한 앤트는 빌드를 실행하는 goal과 goal의 디펜던시를 정의할 수 있는 라이프 사이클을 가지고 있지 않다. 따라서 각 goal에 일일이 작업에 대한 순서를 지정해 주어야한다. 반면,

아파치 메이븐(Apache Maven)은 관례를 가지고 있다. 메이븐은 COC(Convetion over Configuration)의 개념에 입각한다. 설정보다 관례라는 뜻으로 앤트와는 다르게 하나 하나 작업에 대한 순서를 지정해주고 산출물에 대한 위치등을 정해줘야 한다면 메이븐은 어디에 소스코드가 위치하고, 소스코드 컴파일, 컴파일 된 소스코드의 산출물의 위치 등이 이미 다 지정되어 있어 따로 일일히 작업을 해주지 않아도 된다. 메이븐은 pom.xml 파일을 생성하고 기본 디렉토리 안에 소스를 위치시키는 것이 위의 빌드, 리포팅 등의 많은 작업들을 위해 해주어야하는 것의 전부이다.나머지는 메이븐의 특정 관례에 따라 처리하게 된다.

물론 설명으로만 보면 Maven이 Ant보다 훨씬 편해보이지만 그 어떤 것이 더 좋고 나쁘다고 말하기는 힘들 것 같다. 적적한 때에 적절한 툴을 사용하는 것이 중요하고 Maven이 Ant보다 더 많은 작업들을 개발자 입장에서 훨씬 쉽게 처리할 수 있지만 Ant보다 자유도가 떨어지기 때문에 세세한 컨트롤을 필요한 부분에 있어서는 Ant가 이점이 있다. 그러나 Ant는 너무나도 큰 자유도 때문에 script를 재사용하기 어렵고 문법 또한 훨씬 복잡하므로 개발을 하면 할수록 더욱 복잡해지고, 같은 내용을 반복적으로 사용해야하는 단점이 있다.

세가지. 메이븐의 장점

   1. 메이븐은 편리한 Dependency Libaray관리 기능을 제공한다.

프로젝트를 진행하다 보면 특정 기능을 구현하기 위해 jar파일 등의 라이브러리가 필요할 경우가 있다. 이 경우 메이븐 pom.xml에 단지 denpency만 추가시켜주면 알아서 해당 라이브러리를 다운받아 주게 된다.


이렇게 단순히 dependency만 추가하게 되면 junit을 사용할 수 있는 라이브러리를 다운 받아준다. 이러한 특징으로 인해 여러명이서 프로젝트 작업을 진행 할 경우 라이브러리 파일을 git이나 svn과 같은 도구를 통해 주고 받지 않고도 프로젝트에 필요한 라이브러리들을 pom.xml 하나로 쉽게 관리할 수 있는 큰 장점이 있다.

  2. 모든 프로젝트가 일관된 디렉토리 구조와 빌드 프로세스를 유지할 수 있다.


 설정보다 관례(Convention over Configuration)라는 아이디어에 따르면 옆과 같이 메이븐 프로젝트로 시작하게 되면 src/main/java, src/main/resouces, src/test/java, src/test/resources와 같은 구조를 발견할 수 있다. 이렇게 메이븐 프로젝트는 공통 구성을 가지게 되고누군가가 이 프로젝트를 봤을 경우 메이븐에 기반한 프로젝트라는 것을 쉽게 인식할 수 있을 뿐만 아니라 프로젝트의 전반적인 내용에 대해 어느정도 유추할 수 있게 된다. 이렇게 메이븐 템플릿 프로젝트로 프로젝트를 생성하면 프로젝트의 뼈대를 자동으로 생성할 수 있게 되는데 이 같은 기능을 아키타입(archetype)이라고 한다.

  3. 메이븐이 제공하는 다양한 플러그인을 활용할 수 있다.

  4. 신규프로젝트 세팅을 쉽고 빠르게 진행할 수 있다. (Archetype 기능을 통해)

사가지. Pom.xml의 기본 구성요소

Maven 프로젝트를 생성하면 pom.xml 파일이 프로젝트 루트 디렉터리에 생성된다. 이 pom.xml 파일은 Project Object Model 정보를 담고 있는 파일로서, 이 파일에서 다루는 주요 정보는 다음과 같다.

  1. 프로젝트 정보 : 프로젝트의 이름, 개발자 목록, 라이선스 등의 정보를 기술

  2. 빌드 설정 : 소스, 리소스, 라이프 사이클 별 실행할 플러그인 등 빌드와 관련된 설정을 기술

  3. 빌드 환경 : 사용자 환경 별로 달라질 수 있는 프로파일 정보를 기술

  4. POM 연관 정보 : 의존 프로젝트 (모듈), 상위 프로젝트, 포함하고 있는 하위 모듈 등을 기술


잘 안보이지만 왼쪽 위에 보이는 Group Id, Artifact Id, Packagin, Version 에 대해 설명하겠다.

Group Id : 프로젝트를 생성하는 조직의 고유 아이디어를 결정. 보통 Domain Name을 사용

Artifact Id : 프로젝트를 식별하는 유일한 아이디를 말한다. 보통 Project Name을 사용

Packaging : 프로젝트를 어떤 형태로 패키징 할지 결정한다. 진행하고 있는 프로젝트의 경우 웹 프로젝트이기 때문에 war로 설정되어 있다.

Version : 프로젝트 버전 구조 [메이버 버전.마이너 버전. 순차 버전 - 식별자]가 되겠다. 현재는 1.0.0-BUILD-SNAPSHOT으로 지정되어 있는 것을 볼 수 있다.

밑에 보이는 Overview, Dependencies, 등등이 있는 탭에 pom.xml을 눌러보면

과 같이 pom.xml에 표시되어 있는 것을 확인할 수 있다. pom.xml 은 workspace상에 여러 군데 있을 수 있고 hierarchy에 따라 overwrite 또는 상속을 받게 된다.

참고.

자바 세상의 빌드를 이끄는 메이븐 - 박재성 저

[포스팅을 하며]

글을 쓰는 일이 정말 쉽지 않다는 것을 다시 한 번 느낀다. 앞으로 현업에서 새롭게 습득한 지식이나 어려움을 겪었던 경험들에 대해서도 포스팅 해볼 생각이다. 아직은 많이 부족하지만 꾸준히 지식 습득에 노력을 기울이고 학습한 내용에 대해 포스팅 하며 더욱 지식을 굳건히 할 수 있도록 해야 겠다. 미흡하거나 잘못 된 부분의 경우 댓글을 통해 얘기해주면 감사하겠습니다.



반응형
반응형

 


  안녕하세요. 오늘은 아파치 권장 설정인 ServerTokens에 대해 알아보도록 하겠습니다. 최근 이슈중에 보안팀에서 저희가 서비스하는 서버의 정보가 다 노출되고 있다는 메일을 받았습니다. 메일을 받고 실제로 curl --head URL주소를 처서 보니 서버정보가 다 노출되고 있는 것을 확인 할 수 있었습니다. 그럼 어떻게 서버정보가 노출이 되고 있었는지, 해결책은 무엇인지에 대해서 알아보도록 하겠습니다.


문제상황 ] 

 

위의 그림을 보시면 curl --head UR을 통해 요청에 의한 reponse의 head값을 받아 오는 것을 확인할 수 있습니다. 문제는 SERVER의 정보가 모두 노출되고 있다는 점입니다. 이로인해 클라이언트는 해당 서버의 정보(웹 서버 종류, 운영체제의 종류, 설치된 모듈, 마이너버전, 메이저 버전 등)가 다 노출되게 됩니다. 이렇게 서버 정보가 필요 이상으로 노출 될 경우 악의적으로 이용될 수 있음에 꼭 기본적인 내용만을 노출하도록 할 필요가 있습니다.


해결책 ]

위와 같은 문제점을 해결하기 위해 필요한 것이 ServerTokens 입니다. 보통 아파치 설정파일인 httpd.conf내에서 정의합니다. ServerTokens의 역할은 클라이언트 웹브라우저에게 서버의 정보를 얼마나 알려주냐를 설정하는 것입니다. 따라서 아래와 같은 순서로 서버 정보 노출을 예방하도록 해야합니다.


1. 자신의 서버의 정보가 노출되고 있는지 확인한다.


2. 확인이 되고 있다면 Apache의 httpd.conf에 ServerTokens가 설정되어 있는지 확인한다. (아파치 내에서 http-default.conf를 Include 하고 있다면 해당 부분에 설정이 되어 있는지 확인한다 꼭!!!)


3. 설정된 곳을 찾아 ServerTokens 옵션을 Prod로 변경해준다. 이 때 ServerSignature도 On에서 Off로 변경해준다.(보통 함께 붙어 있다. On에서 Off로 변경시 브라우저 상에서 아파치 서버 정보를 노출하지 않겠다는 의미)

 

#ServerTokens의 설정 값은 Prod, Major, Minor, Min, OS, FULL이 있다.


4. 설정을 변경한 후 아파치를 재시작 해준다.


이렇게 ServerTokens를  Prod로 설정을 마치고 다시 재시작한 결과는 다음과 같다.


서버정보에 웹 서버의 이름만 표시된 걸 확인할 수 있다.



이렇게 간단한 설정으로 인해 우리의 중요한 서버정보가 노출됨을 막을 수 있다. 지금 당장 확인해보고 필요 이상의 서버정보가 노출되고 있다면 요렇게 변경해 주길 바란다. 참고로 ServerTokens 지시어는 디폴트로 설정되어 있지 않고 ServerTokens 지시어 설정을 안했을 경우 Full 설정 처럼 모든 정보를 노출하게 된다! 지금 당장 확인 고고씽~!!!

 

 



반응형
반응형


  안녕하세요. 오늘은 클라이언트가 GET, POST이외의 메소드로 작업 요청을 하였을 경우 문제가 될 수 있는 PUT, DELETE 등의 메소드를 비활성화 시키는 내용에 대해 포스팅 하도록 하겠습니다. 해당 이슈 또한 서버 보안이슈로 보통 주로 사용하는 GET, POST이외의 메소드 이외의 메소드로 인해 서버의 정보가 변조/삭제당하거나 악의적인 파일이 삽입될 수 있는 등 악의적으로 이용 될 수 있습니다. 따라서 불필요한 HTTP 메소드들을 비활성화 시켜주도록 합니다.

문제상황 다음과 같은 그림과 같이 PUT메서드로 해당 URL에 요청을 한 결과 200이 떨어지는 것을 확인 하실 수 있습니다.



참고로 PUT 메소드는 서버에서 포함되어 있는 개체를 저장하는데 사용되며(악성 파일 업로드 등의 악의적으로 이용 가능), DELETE 메소드는 서버에서 리소스를 제거(리소스 삭제 등 악의적 이용 가능)하는데 사용 됩니다. 따라서 해당 메소드들의 사용을 비활성화 시켜줘야 한다.


해결방법 나와 같은 경우에는 대부분의 요청이 tomcat으로 처리되고 있었기 때문에 web.xml에 다음과 같은 security-constraint설정을 통해 해당 문제를 해결해 주었다.

그림을 보면 운영에 필수적인 메소드 외의 PUT, DELETE, TRACE 메소드의 사용을 막게끔 web.xml을 통해 설정하고 있다.아파치를 통해서도 해당 문제를 해결 할 수 있는 방법이 있는데 이 경우에는 다음과 같이 처리해줄 수 있다. 아파치의 httpd.conf에서 처리해준다.

<Directory /home> // 해당 도메인의 경로<Limit PUT DELETE CONNECT OPTIONS> // 차단하려는 메소드allow from IP // 허용하려는 사람의 IPdeny from all // 그 외 모든 접속 차단함</Limit></Directory>


혹은 반대로 허용하는 메소드만 정의해줄 수도 있다.

<Directory /home> // 해당 도메인의 경로    <LimitExcept GET POST> // 허용메소드        Order deny,allow

        Deny from all

    </LimitExcept>

</Directory>



해결후 테스트밑의 그림과 같이 PUT 메소드로 해당 URL을 요청한 결과 응답으로 403 Forbidden이 뜬 모습을 볼 수 있다.



이와 같이 많은 힘이 들지 않고도 우리의 서버를 안전하게 지킬 수 있다. 모두들 한 번 점검해보고 안전한 서버 운영을 위해 불필요한 메소드를 비활성화 해주길 바란다.

최근 숙박앱 '여기 어때'에서  SQL Injection공격으로 인해 개인정보 유출 사건이 있었다. 항상 보안을 염두하도록 하자.








반응형
반응형

 


 안녕하세요. 오늘은 최근 겪었던 문제 상황에 대해 포스팅 하도록 하겠습니다. 최근 담당하고 있는 프로젝트 중 고객의 문의가 들어오면 해당 문의가 상담원들에게 배분이 되도록 작동하는 배치성 프로젝트에 문제가 발생했습니다. 특정 시간이 되면 미처리 문의들이 배분이 되어 웹 화면에서 조회가 되어야 정상이지만 어찌된 일인지 아무리 테스트 문의를 넣어보아도 문의가 제대로 배분이 되지 않았습니다. 이 문제를 해결하면서 겪었던 에피소드에 대해 지금부터 포스팅 하도록 하겠습니다. 


# 해당 문제는 알파 환경(정식 사용자들에게 서비스 되지 않는 환경)에서 발생한 상황입니다. 


문제 상황 

:: 고객들의 문의가 상담원들에게 분배가 되지 않는 현상. 고객들이 문의를 넣게 되면 배치성 프로젝트를 통해 미처리 문의들을 상담원들에게 배분해주는 프로젝트가 정상 작동하지 않음


원인 파악

:: 위와 같은 문제상황이 발생하고 일단 서버에 접속해 톰캣이 혹여나 죽진 않았는지 ps -ef | grep java 명령어를 통해 확인해 보았습니다. 확인을 한 결과 톰캣은 정상작동하고 있는 것을 확인하였습니다. 그래도 혹시나 해서 톰캣을 재시작 해보았지만 역시나 정상작동하지 않았습니다. 그렇게 원인 파악에 대해 고민하던 중 선배님 df로 파일시스템을 사용해 보라고 하셨습니다. df 명령어(밑에 간단한 설명)를 통해 파일시스템을 보니 파일시스템 사용률이 100%을 다다랐던 것을 확인 할 수 있었습니다. 

 


해당 문제의 원인은 프로젝트에 약 15개 정도되는 배치성 프로세스(보통 1,2 분에 한 번씩)가 작동하고 있었는데 로그 레벨이 DEBUG로 설정되어 있었던 것이 화근이되었습니다. 이에 아무도움이 되지 않는 불필요한 로그들이 무수히 쌓이게 되었고 파일시스템 사용률이 100%로 치닫게 되었던 것이었습니다.

[그림 출처 : http://changpd.blogspot.kr/2013/05/spring-lo4j.html]


위의 그림을 보시면 log4j의 레벨을 보실 수 있는데 DEBUG로 설정을 하게 될 경우 DEBUG 상위수준의 로그 또한 모두 기록하는 것을 파악할 수 있다. (보통 실제 리얼환경에서는 ERROR 사용) 


문제 해결

:: 먼저 해당 로그 파일들을 제거(실제 리얼환경에서는 백업을 하길 권장)해주고 톰캣을 재시작 해주었다. 실제 환경일 경우 파일 시스템 용량이 특정 %이상 치솟았을 때는 메일, SMS로 상황을 미리 파악하고 대처할 수 있지만 알파환경의 경우에는 그렇지 않기 때문에 파일시스템 용량 상황을 주기적으로 점검해주고 특별한 이슈가 없다면 로그 레벨의 수준을 DEBUG 상위 레벨로 설정해 줄 것을 권장한다.  

 


#df 명령어에 대한 간단한 설명

:: 사용중인 파일시스템의 전체용량, 사용한 용량, 사용가능한 용량, 사용율, 마운트 정보 등을 보여주는 명령어로 현재 사용중인 파일 시스템들의 디스크사용량을 출력한다. df 명령어는 /etc/fstab파일에서 파일시스템정보를 참조하고, /etc/mtab에서 마운트된 정보를 참조한다고 한다. 기본표시 용량단위는 KB(Kilo Byte)이다. 



모니터링을 통해 서버 상태를 항상 체크하도록 합시다^^



반응형

+ Recent posts