기본적인 프로젝트를 생성하면 다음과 같은 web.xml이 생성되어 있을 것이다.

기본적으로 "/"경로를 호출할 때, 쓰일 수 있는 페이지의 형식을 <welcome-file>로 정의해 놓았다.

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" id="WebApp_ID" version="3.0">
  <display-name>servlettest</display-name>
  <welcome-file-list>
    <welcome-file>index.html</welcome-file>
    <welcome-file>index.htm</welcome-file>
    <welcome-file>index.jsp</welcome-file>
    <welcome-file>default.html</welcome-file>
    <welcome-file>default.htm</welcome-file>
    <welcome-file>default.jsp</welcome-file>
  </welcome-file-list>
</web-app>

 

 

앱을 외부로 디플로이 하기 위해 자신의 프로젝트를 톰캣에 추가 하였을 것이다.

web.xml에 매핑을 하지 않았을 경우, Servlet을 호출 할 때

http://<YOUR_IP_ADDRESS>/<ROOT_CONTEXT>/<패키지 이름이 포함된 클래스 이름>

과 같이 매우 긴 주소로 호출 할 것이다.

 

 

하지만 이러한 형식은 클래스 이름이 그대로 노출되기 때문에 보안상 좋지 않습니다. 따라서 이런 방식으로 사용하지 않고, 서블릿 클래스에 대해 대응하는 매핑된 이름으로 실제 서블릿을 요청한다.

 

매핑을 web.xml에서 정의 할 수 있는데 정의하는 방식은 다음과 같다.

  <servlet>
  	<servlet-name>mappingname</servlet-name>
  	<servlet-class>package.YourServlet</servlet-class>
  </servlet>
  
  <servlet-mapping>
  	<servlet-name>mappingname</servlet-name>
  	<url-pattern>/name</url-pattern>
  </servlet-mapping>

 

1. <servlet> 태그

이 태그는 프로젝트 내부의 servlet를 외부에 드러낼 수 있도록 servlet에 이름을 지어주는 역할을 한다.

<servlet-name>태그를 이용하여 서블릿의 이름을 지어주고,

<servlet-class>태그를 이용하여 이름을 지어 줄 서블릿을 선언한다.

 

 

2. <servlet-mapping> 태그

이 태그는 내부의 servlet와 외부 요청에 대한 논리적인 경로를 설정해준다.

<servlet-name>태그를 이용하여 외부에 드러낼 서블릿의 이름을 설정한 다음,

<url-pattern>태그를 이용하여 외부에서 접근할 url 경로를 설정해준다.

 

 

 

 

위를 테스트 하기 위해 나는 test패키지를 생성하여 testServlet 클래스를 생성하였다.

package test;

import java.io.IOException;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class testServlet extends HttpServlet{

	@Override
	protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
		System.out.println("doGet method is called");
		super.doGet(req, resp);
	} // get 요청에 대한 override class이며, get방식에 대해 요청을 처리하는 클래스이다.

	@Override
	public void destroy() {
		System.out.println("destroy method is called");
		super.destroy();
	} // servlet이 종료될 때 호출되는 class

	@Override
	public void init() throws ServletException {
		System.out.println("init method is called");
		super.init();
	} //최초 servlet call을 다루는 override class
	
	

}

 

 

이 Servlet 클래스를 논리적인 주소로 매핑시키기 위해 다음과 같이 web.xml을 수정하였다.

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" id="WebApp_ID" version="3.0">
  <display-name>servlettest</display-name>
  <welcome-file-list>
    <welcome-file>index.html</welcome-file>
    <welcome-file>index.htm</welcome-file>
    <welcome-file>index.jsp</welcome-file>
    <welcome-file>default.html</welcome-file>
    <welcome-file>default.htm</welcome-file>
    <welcome-file>default.jsp</welcome-file>
  </welcome-file-list>
  <servlet>
  	<servlet-name>mappingname</servlet-name>
  	<servlet-class>test.testServlet</servlet-class>
  </servlet>
  
  <servlet-mapping>
  	<servlet-name>mappingname</servlet-name>
  	<url-pattern>/name</url-pattern>
  </servlet-mapping>
</web-app>

mappingname이라는 이름으로 test 패키지의 testServlet클래스에 대해 이름을 지어준 뒤,

"/name" 이라는 논리적인 경로와 매핑시켜주었다.

 

 

 

다음은 테스트 결과 캡쳐 화면이다.

 

위와 같이 잘 호출 되었음을 알 수 있다.

일반적인 리눅스 터미널에서 awscli를 설치하였을 때, 보통은 제대로 작동하지만, git bash는 윈도우 상에서 리눅스 시스템을 사용하도록 에뮬레이터로 “흉내” 낸 것이기 때문에 경로가 잘 매칭 되지 않는 문제가 빈번히 일어난다. 그 결과로 다음과 같이 제대로 명령어가 작동하지 않는 경우가 종종 일어난다.

리눅스 환경에서도 경로 해석이 잘못 될 경우, 일어나는 에러이다.

 

위 문제를 해결하기 위하여 가장 먼저 awscli가 어떤 언어 기반으로 실행되는지 찾아보았다. 공식 aws github를 찾아본 결과, python을 사용하는 것을 알 수 있었다.

 

Python기반으로 실행되는 스크립트 임을 알게 되었으니, 이제 실행파일이 어디 있는지 확인해보았다. 일반적으로 pip uninstall 명령어를 사용하면 다음과 같이 패키지가 설치 된 경로를 출력한다.

 

위와 같이 내 컴퓨터에서 awscli가 설치된 경로는

c:\users\it1903004\appdata\roaming\python\python37\scripts\aws

 임을 알 수 있었다.

 

awscli를 사용할 때 마다 위 경로를 계속하여 타이핑 하는 것은 매우 비효율적이므로 위 경로의 스크립트를 python으로 실행시키는 것을 “aws“명령어로 alias시켜 사용하기로 결정하였다. alias를 등록하기 위해서 사용자 root 디렉토리 경로에서 ./bashrc파일을 생성하였다.

vi ~/.bashrc
//vi editor 상으로 aws script가 있는 경로에 있는 파일을 python으로 실행시키는 코드를 입력한다.

alias aws='python "c:\users\it1903004\appdata\roaming\python\python37\scripts\aws"'
//입력 후 :wq로 저장한다.


source ./bashrc 
//source 명령어로 ./bashrc 파일을 시스템 상에 적용한다.

 

 

 

 

 

다음과 같은 절차를 거치게 되면 최종적으로 시스템 상에서 aws명령어를 정상적으로 사용할 수 있게 된다.

 

 

1. 의문점

자주 사용하는 AWS Resource에 대해 조사하는 도중 홈페이지에 기술된 EC2 Default Limit과 AWS Service Quota의 내용이 상이하였습니다. 이에 대한 자료가 없어 상이한 내용에 대한 캡처본과 함께 AWS Support Center에 Case Open을 하였습니다.

상이한 내용은 다음과 같습니다.

 

  • AWS 공식 홈페이지의 EC2 Default Limit

 

  • AWS Service Quota에서의 EC2 Default Limit (개인 실습 계정 현황)

 

 

 

 

2. case 답변 본문

답변의 본문은 다음과 같습니다.

Hello,

I would like to thank you for your patience while we waited for the EC2 Service Team to get back to me.

 

When they were reviewing your questions as well as the screenshots provided, they have informed me of the following:

 

There is a slight difference between the new change vCPU's and the old from EC2 classic platform. The difference is that vCPUs uses a quota that allows you to lunch resources dependant on what is the factor as per the documentation below:

 

"Q: What are vCPU-based limits?" https://aws.amazon.com/ec2/faqs/?nc1=h_ls#EC2_On-Demand_Instance_limits

 

Example if your quota is 1,308 you can launch 1,308 t2.micro instances and/or 654 t2.nano's with 654 t2.mirco's.

 

The previous quota limits were based on what is provisioned to your account, which means if the limit was 5 for t2.micro you would only be able to lunch 5 t2.micro's and nothing else.

 

Also the reason why your default limits differ from the documentation is due to account specific information such as when your AWS Account was created, billing history and utilization of the account. The documentation was based on an average of all our customers.

 

Should you at any time have any additional questions or concerns in this regard, please do let us know by responding back to this case. I wish you a wonderful day further!

 

 

 

3. 정리 및 결론

위 본문을 정리하면 다음 두문장으로 설명이 가능합니다.

 

  • 공식 홈페이지 EC2 Default Limit : AWS 전체 사용자가 사용하고 있는 자원에 대에 대해 프로비저닝 된 Limit.

  • AWS Service Quota Default Limit : 계정의 생성날자, 지불 이력, 자원 사용 이력 등에 따라 프로비저닝 된 한도.

 

 

즉, 모든 계정은 새로 만들게 되면 지불 이력과 자원 사용 이력이 없기 때문에 default Limit을 매우 낮게 잡습니다. 그러나 사용이력이 생기면 이를 AWS에서 프로비저닝 하여 새로운 Limit을 적용합니다. 이에 대해 실제로 적용이 되는지 주변에서 Service Quota 현황을 동의를 구하고 수집하였습니다.

 

 

 

  • t2.micro를 5회 미만 생성한 계정의 Service Quota 현황

 

 

  • t2.medium을 10회 이상 생성한 계정의 Service Quota 현황

 

 

 

  • 프리티어를 한도 내에서 다양한 실험을 한 계정의 Service Quota 현황

 

 

 

위 경우와 같이 한도 증가 신청을 하지 않고도 자동으로 프로비저닝 되어 할당된 한도가 증가하는 것을 확인 할 수 있었습니다.

+ Recent posts