Spring MVC hello world Example in STS

spring pivotal이 글은 STS(혹은 Eclipse) 를 사용해서 Hello World 를 만드는 법에 대한 것이다.  Eclipse, STS 를 설치했다면 자체적으로 간단한 샘플 프로젝트를 제공 한다. 아무런 설정도 필요없고 간단하게 패키지명만 입력해주면 샘플 프로젝트가 제공되고 브라우저를 통해서 확인할 수 있다.

Eclipse 에는 Spring IDE 플러그인이 설치된 것으로 가정한다.

Spring Legacy Project

STS나 Eclipse 를 설치했다면 Spring Legacy Project 를 제공한다. File 메뉴 -> New -> Other.. 를 클릭하면 나오는 팝업창에서 ‘Spring’ 폴더를 클릭하면 다음과 같은 화면에 ‘Spring Legacy Project’ 가 보입니다.

Spring Legacy Project 생성 팝업
Spring Legacy Project 생성 팝업

이제 ‘Next’ 를 누르면 다음과 같은 화면이 나온다.

Spring 템플릿. 그런데 MVC Project 가 없다.
Spring 템플릿. 그런데 MVC Project 가 없다.

하지만 위 화면과 같이 나올 수도 있다. 원래는 MVC Project 가 나와야 하는데, 보이지 않는다. 그럴때는 위 화면에 ‘Configure templates…’ 를 클릭한다.

Template Projects 수정
Template Projects 수정

위 화면과 같이 두가지를 순차적으로 삭제 해준다. 위와같이 하면 이전화면이 다음과 같이 나온다. 삭제하고 난후에도 이전화면에서 ‘Spring MVC Project’ 가 나타나지 않으면 Eclipse 를 재시작해준다.

Spring MVC Project 생성
Spring MVC Project 생성

위 화면과 같이 Project name 에는 ‘HelloWorld’ 를 적어주고 아래 Template 은 ‘Spring MVC Project’ 를 선택하고 ‘Next’ 를 해준다.

패키지명 작성
패키지명 작성

위와같이 패키지명을 입력하고 난 후에 Finish 를 누르면 Hello World 프로젝트가 작성된다.

Spring MVC Project 로 작성된 Hello World
Spring MVC Project 로 작성된 Hello World

이를 실행시키면 Hello World 를 브라우져에서 확인해 볼수 있다.

UTF-8 로 출력하기

이는 Deployment Discriptor 인 Web.xml 파일에 Encoding 설정을 UTF-8 로 설정해 줘야한다. 이는 다음과 같다.

Session 공유 테스트 코드

WAS 서버를 세팅할때에 Session 을 공유하도록 가끔은 구성할 때가 있다. 요즘은 spring-data-redis 를 이용해서 Redis 에 Session 을 저장하도록 지원하고 있지만 WAS  서버 자체적으로 Session 을 공유하도록 설정해서 운영할 수 있다.

이때 과연 WAS  서버들간 Session 이 제대로 공유되고 있는지를 확인할 필요가 있는데 이때 사용할 수 있는 코드다. 참고로 이 코드는 다음의 github 저장소에서 가지고 왔다.

먼저, Controller 를 다음과 같이 수정한다.

그리고 다음과 같이 home.jsp 파일을 수정해준다.

위와같이 수정하고 실행을하면 세션관련된 내용을 출력되고 세션 공유를 테스트해 볼 수 있다.

JBoss EAP 에서 세션 공유

코딩만으로는 Session 공유가 되지 않는다. WEB-INF 디렉토리에 ‘jboss-web.xml’ 을 만들고 다음과 같이 작성한다.

그리고 web.xml 파일에 다음을 추가해 준다.

위와 같이 하면 웹 애플리케이션에서 세션이 공유된다.

Spring 개발을 위한 Eclipse 세팅하기

eclipse ide

이제 Java 개발을 하기위해서는 Eclipse가 필수가 됐다. 아니 Java 뿐만이 아니라 웬만한 언어들과 개발에 필요한 각종 인프라들을 제공해주는 단순한 하나의 IDE 가 아닌 개발환경 그 자체가 되어가는 듯한 느낌이다.

Java 개발에 거의 표준이 된 Spring Framework 를 이용한 개발을 할때도 Eclipse도 필수중에 필수이다.

Spring 개발을 위해 필요한 Eclipse 세팅에 대한 글이다. 초보자분들을 대상으로 함으로 이미 많은 경력을 쌓은 개발자는 읽을 필요가 없다.

준비물

현시점(2016.05)에서 안정적인 자바 개발을 위한 프로그램과 버전들은 다음과 같다.

  • Jdk 1.8
  • Maven 3.3.9
  • Eclipse 4.5.2 (mar2), STS 3.7.3

한가지 알아야 할 것은 STS 3.7.3 이다. Springsource Tools Suites 로서 Spring 개발사(?)에서 Eclipse 와 Spring Tools Suites 를 통합시킨 것이다. Eclipse 와 완전히 동일한 환경이지만 STS를 설치하면 별도의 Spring 을 위한 설치작업을 할 필요가 없기 때문에 많이 사용한다.

여기서는 Eclipse 4.5.2 를 가져다 Spring 을 위한 환경을 구축하는 것으로 하겠다. 설치와 환경설정으로 나뉘어 서술할 것인데, 설치를 제외한 환경설정 부분은 Eclipse 나 STS나 동일하기게 적용된다.

마지막으로 시스템은 Windows 64bit 을 사용하는 것으로 한다.

설치하기

Jdk 1.8 설치

먼저, Jdk 1.8 을 설치해야 한다. Maven 때문에 반드시 JDK를 설치해야 한다. Windows 64bit 버전을 다운받아 설치한다. 그리고 JAVA_HOME, CLASS_PATH, PATH를 시스템 환경 설정을 해준다. 이 과정은 검색해보면 많이 나오니까 따로 기술하진 않겠다.

Maven 3.3.9 설치

Maven 은 Java 개발에 필요한 각종 라이브리 의존성, 빌드, 테스트를 자동화해주는 툴이다. 대부분 Java 개발이 대규모로 이루어지고 있어 이러한 것을 자동으로 처리해주는 필요가 많이 생겼는데 Maven이 그걸 자동으로 해준다.

Eclipse 에서는 Maven 과 통합이 되어서 사용자가 별도의 명령어를 치거나하는게 아니라 Eclipse 에서 전부 Maven 관련된 일을 수행할 수 있다.

설치는 아주 간단하다. Maven 홈페이지에서 다운받아서 압축해제만 해주면 끝이다. 나는 압축을 해준 다음에 C:\ 디렉토리로 그냥 옮겨줬다.

  • C:\apache-maven-3.3.9

설치를 했다면 설정을 해줘야 한다. Maven 설치한 디렉토리에 repository 라는 디렉토리를 생성한다.

maven repository 디렉토리 생성
maven repository 디렉토리 생성

conf 디렉토리에 보면 setting.xml 파일을 텍스트 에디터로 열어서 다음과 같이 localRepository 부분에 방금 생성한 repository 디렉토리를 지정해준다.

Maven 자체에 대한 설정은 아주 많은데, 보통의 경우에 여기까지만 해도 개발하면서 이용하는데 아무런 문제가 되지 않는다.

Eclipse 설치

Eclipse 설치를 위해서 홈페이지에 가보면 다양한 Eclipse를 볼수 있다. 그것들은 마치 STS 와 동일한 것들이라고 보면 된다. C/C++ 를 위한 Ecclipse, PHP를 위한 Eclipse, Java 를 위한 Eclipse 등 많은 Eclipse 통합 제품들을 제공하는데 우리는 Java EE 를 위한 Eclipse 를 다운받는다.

  • Eclipse IDE for Java EE Developers

시스템 운영체제에 맞는것을 다운받으면 된다. 다 다운받으면 압축해제해서 C:\ 로 옮겨준다. 나 같은 경우에는 다음과 같다.

  • C:\eclipse-jee-mars2

Eclipse 설정

먼저 Eclipse 를 실행한다. 모든 설정은 Eclipse 실행한 상태에서 하게 된다.

실행을 했다면 ‘Help’ 메뉴 -> Check for Updates 를 실행해서 Eclipse 를 최신상태로 업데이트를 반드시 해준다.

Spring Tools Suites Plugin 설치

Plugin 설치는 Marketplace 를 이용해서 아주 쉽게 할 수 있다. ‘Help’ 메뉴 -> Eclipse Marketplace 를 클릭하면 Marketplace가 실행된다.

Marketplace 에서 Spring 으로 검색해서 설치버튼 클릭
Marketplace 에서 Spring 으로 검색해서 설치버튼 클릭

위 화면과 같이 ‘Spring’ 으로 검색해서 나오는 ‘Spring IDE 3.7.3.RELEASE’ 에 Install 클릭해준다. 그러면 화면이 바뀌고 설치하고자하는 추가 컴포넌트들을 선택하는 화면이나오는데 잘 모르면 그냥 ‘Confirm’ 클릭하고 라이센스에 동의해주고 ‘Finish’ 클릭하면 설치가 진행된다.

중간에 인증되지 않은 Plugin 을 설치하겠냐고 물어보는 팝업창이 나오기도 하는데 ‘Yes’를 해주면 설치가 완료 된다.

Maven 설정

Eclipse 를 실행하고 ‘Window’ 메뉴 -> Preferences 를 클릭하고 나오는 창에서 ‘maven’ 으로 검색한다.

maven 설정
maven 설정

위 화면과 같이 ‘User Settings’ 부분에 앞에서 Maven 설치시에 수정했었던 settings.xml 파일을 인식 시켜준다.

한가지 더 Maven 을 위한 설정이 존재하는데 다음과 같이 Jdk 의 tools.jar 을 library 에 포함시켜줘야 한다. 만일 이것을 하지 않게되면 Maven 사용시에 다음과 같은 오류를 만나게 될 수도 있다.

이는 tools.jar 을 필요로 하는 것인데 다음과 같이 인식시켜주면 된다.

tools.jar 추가해주기
tools.jar 추가해주기

이로써 Spring 개발을 위한 설정은 모두 끝났다.

하지만, 추가적인 필요한 설정을 해주자.

Edit Encoding,  line delimiter 설정

Windows 에서 Eclipse 를 사용하게되면 Eclipse의 기본 파일 인코딩은 MS949로 시스템 기본 문자셋을 따른다. 하지만 지금 세상은 UTF-8 세상이 된지 오래다.

또, Line delimiter 라고 해서 한줄을 다 쓰고나서 Enter 를 누르면 ‘\n’, ‘\r\n’ 이 두가지 형태로 라인이 끝임을 마킹하게 되는데 이는 Windows 나 Unix 에 따라 다르다. 이는 개발한 애플리케이션이 어느 시스템에서 동작하는지에 따라 선택해준다. 나는 Unix 로 바꿔줬다.

Encoding, Line delimiter 변경
Encoding, Line delimiter 변경

Line Numbering

텍스트 화면 왼쪽에 줄번호를 보이게 하면 개발시에 아주 편리하다. 설정은 다음과 같이 한다.

Line Number 보이기
Line Number 보이기

Eclipse Color Themes 설치

개발을 하다보면 Edit에 Syntax Highlight 를 변경하고자 하는 욕구가 나온다. 이럴때에 Color Theme를 설치하고 바꿔주면 된다. 이것도 Plugin Marketplace 에서 설치가능하다.

Eclipse Color Theme 설정
Eclipse Color Theme 설정

Plugin 을 설치하고 나면 위와같이 전에 안보이던 Color Theme 가 나오고 많은 Syntax Highlight Color 들을 볼수 있고 원하는 것을 선택할 수 있게된다. (원래는 선택하면 미리보기 기능을 제공했지만 현시점(2016.05)에서는 어찌된 영문인지 ‘곧 돌아온다’라는 문구만 나온다.)

이로써 Spring 개발을 위한 Eclipse 세팅에 대해서 간단히 알아봤다.

윈도우용 JDK Portable 설치.

윈도우용 JDK를 보면 Portable 설치가 없다. 설치를 할려면 Windows Installer  를 이용하는 방법 밖에 없다. 문제는 두개의 버전, 1.7과 1.8 버전의 JDK 를 설치할 수가 없을 수도 있다. 최신판을 설치된 상태에서 구 버전을 설치할려면 이미 최신버전이 설치가 되어 있어서 설치가 안될 수도 있다.

이럴때 Linux 용 처럼 압축만 해제하면 쓸수 있도록 할 수 있지 않을까? 이 글은 JDK를 압축해제하는 것만으로 설치하는 방법인 Portable 설치에 대해서 다룬다. 또한, 이글은 다음 링크의 내용을 정리한 것이다.

참고로 JDK 1.7 버전만 가지고 테스트 됐다.

준비

구 버전의 Windows Installer 를 다운받는다. 보통은 .exe 확장자로 끝나는 파일이다. 또 다른 프로그램이 필요한데 .exe 를 압축해제할 수 있는 압축/해제 소프트웨어다. 많은 압축/해제 소프트웨어가 있지만 7-zip 을 이용했다.

압축해제

jdk 압축 해제
위 그림과 같이 7-zip 을 설치한 후 마우스 오른쪽 버튼을 클릭하면 .exe 파일을 압축해제할 수 있다.

압축을 해제하면 jdk-7u80-windows-x64 디렉토리가 생성되고 그 안에 ‘tools.zip’ 압축파일이 보인다. 그럼 이 tools.zip 도 압축을 해제한다.

pack 파일을 jar 파일로 변환하기

tools.zip 파일을 보면 pack 파일들이 보인다. windows installer 의 패키징 파일이다. 이것을 unpack 해서 jar 파일로 만들어주는게 핵심이 된다.

cmd 창에서 작업을 해야해서 cmd 창을 띄운다. 그리고 방금 압축해제한 디렉토리인 tools 로 이동한다.

cmd 창에서 tools 로 이동
cmd 창에서 tools 로 이동

그리고 다음과 같이 입력한다.

위와같이 하면 pack 파일이 전부 jar 파일로 변환된다.

이제 tools 디렉토리를 ‘JDK1.7’ 로 이름을 바꾸고 C:\ 로 이동시키면 Portable 하게 설치가 완료된다.

JBoss EAP 5 MySQL JNDI 설정

Jboss EAPJNDI 는 자바 애플리케이션 서버라면 거의 다 지원하는 기능이다. 이는 특정한 자원의 접근을 디렉토리 접근하듯이 하도록 해준다. 여기서 자원이라면 대부분 외부 서버에 있는 저장소들을 말한다.

MySQL, PostgreSQL, Oracle, MS SQL 등 외부 저장소에 접속할때마다 저수준의 드라이버를 올리고 인증을 넣는게 아니라 자바 애플리케이션이 구동되면서 접속하을 해놓고 이것을 디렉토리화해서 올려놓으면 자바 애플리케이션에서는 이 디렉토리에 접근하는 것만으로 외부자원에 접속이 끝이 나게 되어 간편해진다.

이 글은 JBoss EAP 5 MySQL JNDI 설정에 관한 글이다.

MySQL Connector/j

MySQL에서는 자바 애플리케이션을 위해서 접속 드라이버를 제공한다. jar 파일로 작성되 배포되고 있어 다운받아서 지정된 위치에 넣기만 하면 된다.

JBoss EAP 5 는 글로벌 library 디렉토리, Node Library 디렉토리가 존재하는데 node 디렉토리에 다운받아 넣는다. 다시말하면, Jboss EAP 5 의 경우에, jboss-as/server 아래에보면 all, default, production, standard 등의 디렉토리가 보이는데 이걸 node 라고 한다. 여기서 나는 all node 에 lib 디렉토리에 MySQL Connector/J 를 넣어주면 된다.

현 시점에서의 버전은 5.1.39 이다.

 

MySQL DataSource

이제 JBoss 에 MySQL DataSource 를 설정해준다. 앞에서 잠깐 말했지만 특정 node 에 설정을 해주게되는데 나는 all 노드에 설정을 할 것이다.

일단 mysql-ds.xml 파일을 다음과 같이 작성한다.

  • 11번째 줄이 아주 중요하다. JNDI 이름인데, 이 이름을 가지고 자원을 호출하게 된다.
  • 12번째 줄은 접속 서버 정보이다. 호스트네임이나 IP주소, 접속 데이터베이스명을 적어주면 된다. Unicode 와 CharacterEncoding 은 옵션으로 MySQL 서버와 맞게 설정해 주어야 한다.
  • 14번, 15번 줄은 접속을 위한 인증정보를 적어준다.

이걸 mysql-ds.xml 로 저장한 후에 $JBOSS_HOME/server/all/deploy/ 디렉토리에 넣으면 된다.

애플리케이션 WEB-INF/jboss-web.xml 작성

자바 애플리케이션을 작성할때에 WEB-INF 디렉토리를 만나게 된다. Deployment Descriptor 로 정의되는 web.xml 파일이 위치하는 디렉토리다. 여기에 jboss-web.xml 파일을 다음과 같이 작성한다.

  • 12,13 줄이 아주 중요하다. JNDI 명을 적어주는데, 앞에 mysql-ds.xml 파일에서 설정한 이름만 적어주는게 아니라 jdbc, java: 등을 함께 적어준다. 이거 의외로 안 적어주고 안된다는 사람이 많으니 주의해서 적어주자.

애플리케이션 WEB-INF/web.xml 작성

Deployment Descriptor 파일로 불리우는 web.xml 파일에 다음과 같은 내용을 추가해준다.

  • 5줄 에 JNDI 이름을 적어준다. jdbc/ 를 꼭 붙여준다.

여기까지가 JNDI 설정에 관한 것이다. 이 이상은 프로그래머가 사용하는  ORM 에 따라서 JNDI 호출 방법이 달라진다. 하지만 JBOSS 에서 JNDI가 잘 설정되어 있는지를 살펴볼 수있다.

root Context 설정

이제 애플리케이션에서 JNDI를 설정해 보면 다음과 같다.

jndiName 설정을 어떻게 하는지 주의깊게 봐야 한다.

 

확인하기

설정한 JNDI가 잘 설정되었는지는 맨 처음 JBoss 를 시작할때에 로그에 나온다.

이것은 JNDI 설정 파일을 읽었을 뿐 실제로 접속이 잘되는지를 나오지 않는다. 이는 JBoss Admin Console 를 통해서 가능하다.

JBoss Admin Console JNDI 확인

위 그림과 같이 Test Connection 을 클릭하면 접속 테스트를 해준다.

JBoss Admin Console JNDI 접속 실패

위 그림을 보면 Status 가 성공으로 나와서 접속 성공한으로 착각하는데, 이것은 Test Connection 명령이 성공했다는 것이고 그에 대한 결과는 그 아래에 위와같이 나온다. 위 경우에 접속 실패.

이것저것 문제를 해결한 후에 다시 Test Connection 을 하고 성공하면 설정이 정상적으로 된것이다.

 

Ubuntu 14.04 의 JBoss EAP 5.2 init 스크립트

JBoss EAP 5.2 를  Ubuntu 14.04 에서 운영할 경우에 서비스 시작을 init 에 등록하기 위한 스크립트. Wildfly 에 내용을 가지고 와서 마이그레이션 했다.

아래는 jboss-env.sh 의 내용.

 

TCP 기반 JBoss 5 Clustering 하기

Jboss EAPAWS EC2 에서 JBoss EAP 5.2 를 설치하고 운영할때에 보통 클러스터링을 설정하게 된다. 문제는 JBoss EAP 5.2 에서 클러스터링은 JGroup 을 기반으로 작성되어 있다. 중요한 것은 클러스터링을 할때에 Multicast UDP 를 사용한다는 것인데, AWS EC2 에서는 Multicast 자체를 지원하지 않는다. 따라서 JBoss EAP 5.2 를 AWS EC2 에서 운영하면서 클러스터링을 기본 설정값으로 설정하고 실행시키면 클러스터링이 되지 않는다.

이럴때 TCP 를 이용하면 가능해진다. 이 포스트는 AWS EC2 에서 TCP 기반 JBoss Clustering 에 관련된 내용이다.

MPING을 TCPPING으로 바꾸기

Cluster 의 프로토콜 설정은 다음의 파일에 정의되어 있다.

  • deploy/cluster/jgroups-channelfactory.sar/META-INF/jgroups-channelfactory-stacks.xml

여기에 TCP 스택 부분에 보면 MPING 설정부분을 코멘트처리하고 TCPPING부분을 언코멘트해준다.

여기서 핵심이 jboss.jgroups.tcp.tcpping.initial_hosts:localhost[7600],localhost[7600] 부분이다. 이부분은 도메인을 입력해줘야 하는데, 대부분 /etc/hosts 파일에 아이피와 짧은 도메인명으로 정의를 해준다.

이렇게 주석을 해제해준 상태에서 JBOSS 옵션으로 -Djboss.jgroups.tcp.tcpping.initial_hosts=node1[7600],node2[7600] 을 주게 되면 두개의 node 가 TCPPING 으로 묶이게 된다.

Cache 매니저에서 jgroup 스택 프로토콜 바꾸기

이것은 다음의 파일에 정의 되어 있다.

  • deploy/cluster/jboss-cache-manager.sar/META-INF/jboss-cache-manager-jboss-beans.xml

이 파일에서 jboss.default.jgroups.stack:udp 를 jboss.default.jgroups.stack:tcp 로 모두 교체해준다.

하지만 이 방법외에도 JBOSS 옵션으로 -Djboss.default.jgroups.stack=tcp 를 정의해주고 인스턴스를 시작해주면 적용된다.

JBoss Messaging 을 TCP 로 바꾸기

JBoss Messaging 을 TCP 로 바꾸기 위해서 다음 파일을 열어서 다음과 같이 변경해 준다.

이 옵션 변경은 커맨드라인으로 제공하지 않기 때문에 반드시 수동으로 이 파일을 편집해 줘야 한다.

JBOSS 시작 옵션으로 설정하기

위 파일들을 바꾸는 대신에 다음과 같이 시작과 같은 옵션만으로 TCPPING 으로 바꿀 수 있다.

이 옵션 설정은 매우 중요하다.

먼저, jboss.messaging.ServerPeerID 는 반드시 Cluster 내에서 유일해야 한다. 중복되면 서버 시작시에 오류갈 발생된다.

jboss.service.binding.set 은 default 포트를 기준으로 상대적으로 포트를 할당한다. default 는 각종 서비스 포트에 기본 값으로 Cluster 의 경우에는 7600 포트, HTTP 는 8080 이다. ports-01 은 default 보다 100 을 더해서 Cluster 는 7700, HTTP 는 8180 이된다.

위 jboss.service.binding.set 은 jboss.jgroups.tcp.tcp_port 와 혼동이 될 수 있다. 예를들어 ports-01 인상태에서 tcp_port=7600 으로 했다면 100을 더해서 7700 이 된다. 하지만 ports-01 인 상태에서 tcp_port=7700 이면 실제 Cluster TCP 포트는 100을 더한 7800 이 된다. 결론적으로 tcp_port 의 실제 값은 지정한 값에 binding.set 값을 더한 값으로 된다.

jboss.jgroups.tcp.tcpping.initial_hosts 는 binding.set 과 tcp_port 값을 더한 포트 값을 적어주면 된다. 왜냐하면 이게 실제로 사용되어지는 포트가 되니까 결국에는 이곳의 포트값은 실제로 서버에서 사용되어지는 Cluster Port 값을 적으면 된다.

주의사항

이 설정을 테스트 하기위해서는 서로 다른 머신이 있어야 한다. 같은 서버상에 인스턴스를 두개를 실행시켜서하면 안된다. 반드시 서로 다른 서버에 인스턴스와 테스트를 해야지 성공한다. 이유는 아직 나도 잘 모르겠다.

[AWS] Private Subnet 으로 서비스 구성하기.

AWS 는 전 세계적으로 가장 인기있는 Cloud Platform 이다. Web Console을 이용해서 원하는 자원을 구성하고 컴퓨터, 네트워크, 저장소등을 실시간으로 생성할 수 있으며 네트워킹 구성도 실시간으로 구성이 가능하다.

그래서 많은 IT 업체들이 AWS 클라우드를 사용하고 있다. 특히나 전 세계를 대상으로 인터넷 서비스를 하려는 업체들은 AWS 를 통해서 막대한 IT 인프라 구축비용 절감하고 있다.

오늘은 AWS 클라우드를 이용해서 가장 많은 구성이며 기본적인 구성인 Web Service 를 Private Subnet 을 이용해 구성해보도록 하겠다.

이 포스트는 AWS 클라우드에 대해서 어느정도 기초지식을 갖추고 있다고 가정하고 쓰여졌다. AWS 클라우드를 사용하기 위해서는 기본적인 개념들이 존재하는데, 예를들어 VPC, ELB, Security Group, Route Table, InterGateWay 등에 대해서 모두 알고 있다라고 가정한다.

목표

내가 목표로하는 전체적인 시스템 구성은 다음과 같다.

Private Subnet 서비스 구성도

위 구성도에서 눈여겨 봐야할 포인트는 다음과 같다.

  • 외부 인터넷과 연결을 위해서 반드시 Public Subnet 이 한개는 있어야 한다.
  • 서비스를 제공할 인스턴스들은 Private Subnet 에 있어야 한다.
  • Private Subnet 에 있는 인스턴스들에서 외부와의 인터넷 통신은 Public Subnet 에 있는 NAT 서버를 통해서 한다.
  • Private Subnet 에 Web Service 인스턴스들은 ELB(Elastic Load Balancer) 를 통해서 하며 ELB는 반드시 Public Subnet 에 있어야 한다.

 

VPC 생성하기

AWS 서비스에 가입하면 각 Region 마다 기본적인 사항들이 자동으로 생성된다. 그중에 VPC도 다음과 같이 기본으로 생성이 된다. Tokyo Region은 다음과 같다.

  • VPC CIDR: 172.31.0.0/16
  • Route table: rtb-ef0bcd8a
  • Network ACL: acl-3cef2859
  • Subnet: subnet-55d41722
  • Subnet Type: Public

Default VPC 은 인터넷과 자동으로 연결된 거대한 하나의 Public Subnet 기도 하다. 하지만 나는 이 Public Subnet 을 사용하지 않고 새롭게 VPC을 생성할 것이다. VPC 의 생성에서 고려해야할 사항은 얼마만큼의 IP 대역을 사용할 것인가에 있다.

Web Service VPC 생성
Web Service VPC 생성

Subnet 생성하기

이제 서브넷을 생성해야 한다. 중요한 것은 Public Subnet 1개와 Private Subnet 1개는 반드시 있어야 한다.

여기서 중요한 것도 IP 대역이다. 한 서브넷에 얼마만큼의 IP 대역을 쓸것인가 하는 것이다. 나는 다음과 같이 할당 했다.

  • Public Subnet: 10.31.0.0/22 – 1018 개 IP 대역, AZ: ap-northeast-1b, Name: JumpSubnet(NAT)
  • Private Subnet: 10.31.4.0/22 – 1018 개 IP 대역, AZ: ap-northeast-1b, Name: WebSubnet

여기서 한가지 Public Subnet, Private Subnet 을 구분하는 설정값은 존재하지 않는다. AWS 에서 이 둘의 구분은 Internet Gateway 와 연결이 되어진 네트워크이냐 아니냐에 따라 달라진다. Internet Gateway 에 연결되었다면 Public, 그렇지 않으면 Private 이라는 개념이다. 그럼 이러한 연결 설정은 어디서 하는가?

Subnet 에 대해서 Internet Gateway 연결을 하거나 기타 네트워크 경로 설정은 Route Table 에서 하기 된다.  Route Table 에서 생설할때에 고려해야 할 사항은 다음과 같다.

  • 어느 서브넷과 연결시킬 것인가?
  • 어떤 외부세계와 연결시킬 것인가?

Route Table 이 존재하면 수정을하고 없으면 생성을 하면 된다.

Public Subnet

Public 서스넷 Route Table 서브넷 연결
Public 서스넷 Route Table 서브넷 연결
Public 서스넷 Route Table 라우팅 테이블
Public 서스넷 Route Table 라우팅 테이블

Public Subnet 을 위한 Route Table 은 위와같이 연결할 서브넷과 라우팅 테이블을 정의해주면 된다. 여기서 핵심은 라우팅 테이블에서 Internet Gateway 연결을 해줘야한다. 위 화면에서 igw-98de5cfd 가 바로 그것이다.

Internet Gateway 가 연결되어 있다면 그것이 Public Subnet 이 된다.

Private Subnet

Private 서스넷 Route Table 서브넷 연결
Private 서스넷 Route Table 서브넷 연결
Private 서스넷 Route Table 라우팅 테이블
Private 서스넷 Route Table 라우팅 테이블

Private Subnet 을 위한 서브넷 연결과 라우팅 테이블은 위와 같습니다. 라이팅 테이블을 보면 Internet Gateway 연결이 없다. 그래서 이 라우팅 테이블과 연결된 Subnet 은 Private Subnet 이 된다.

Private Subnet 은 외부 인터넷과 연결이 안되기 때문에 Private Subnet 인스턴스에 접속하고 제어하고 Private Subnet 의 인스턴스들이 인터넷연결을 위한 NAT 인스턴스가 필요하다.

Security Group 생성

Security Group 은 인터넷 방화벽이라고 생각하면 편하다. Security Group 은 인스턴스마다 할당할 수 있다. Security Group 에도 NAT를 위한 것과 NAT 에 의존해야할 인스턴스를 위한 것 두개를 만든다.

Security Group 을 생성할대는 Inbound 프로토콜, 포트 와 Outbound 프로토콜, 포트 를 생각해야 한다.

NAT Security Group

Outbound 는 “All Traffic” 으로 제약을 풀어줘도 된다. 보안상 외부로의 접속을 차단해야할 상황이라면 설정을 해야하면 된다.

Inbound 접속 제한을 해야함으로 다음과 같이 설정해준다.

NAT 를 위한 Security Group
NAT 를 위한 Security Group

중요한 사항은 80, 443, ICMP 에 대한 NAT 접속은 Private Subnet 으로부터 받는걸로 설정을 해야 한다는 것이다.

NAT 의존하는 인스턴스를 위한 Security Group

Outbound 는 “All Traffic” 으로 제약을 풀어줘도 된다. 물론 보안상 문제가 된다면 제한을 걸고 싶은 포트를 지정해주면 된다.

NAT 에 의존하는 인스턴를 위한 Security Group
NAT 에 의존하는 인스턴를 위한 Security Group

SSH 서비스 접속포트는 NAT 서버 주소를 지정해준다. HTTP, HTTPS, ICMP 는 모든 영역에서 접속을 허용하도록 한다. 왜 이렇게 하냐하면 HTTP, HTTPS 는 AWS 의 Public ELB 를 통해서 외부로 서비스를 해야하는데 Public ELB -> private subnet 인스턴스에 접속이 이루어져야 하기 때문인데 문제는 접속할 IP를 알수가 없다. 그래서 접속하는 주소지를 모두 열어준다.

NAT Instance 생성

NAT Instance 가 필요한 이유는 다음과 같다.

  • Private Subnet 에 있는 인스턴스들을 제어하기 위해
  • Private Subnet 에 있는 인스턴스들이 인터넷을 하기 위해.

Private Subnet 에 있는 인스턴스들이 인터넷이 되어야 하는 이유는 OS 및 각종 소프트웨어의 자동 업데이트 때문이다. 보안 업데이트를 하기위해서는 업데이트 프로그램을 다운로드해야하는데 대부분 인터넷을 통해서 다운로드가 된다. 따라서 Private Subnet 도 인터넷이 되어야 한다.

또다른 이유는 AWS 의 S3 와 같은 외부 서비스를 이용하기 위해서다. S3 저장소는 HTTP 주소를 통해서 자원에 접근할 수 있도록 해주는데, 이를 Private Subnet 에서 이용하기 위해서는 인터넷이 되어야 한다.

NAT Instance 는 외부에서 연결을 해야함으로 EIP를 할당해준다. EIP가 없더라도 Public Ip를 할당해줘야 한다. 그리고 Subnet 은 Public Subnet 과 연결해 준다.

  • Instance: EC2 Linux System
  • Subnet: JumpSubnet(NAT)
  • Seucrity Group: NAT 를 위해 생성한 Security Group
  • EIP, Public IP 할당

중요한 것은 반드시 Public Subnet 에 인스턴스를 생성해 준다.

Private Subnet Route Table 조작

이제 앞에서 Private Subent 의 Route Table 을 조작할 때다. Private Subnet 의 Route Table 은 Local 외에 모든 연결을 NAT Instance 로 가게 설정 한다.

Private Subnet 을 위한 라우팅 테이블 조작
Private Subnet 을 위한 라우팅 테이블 조작

위와 같이 두번째 타켓으로 NAT 인스턴스를 지정해 준다. 그러면 이 라이팅에 연결된 Subnet 들은 외부와 통신을 위해서 NAT 인스턴스를 통해서 이루어지게 된다.

NAT 인스턴스 마스커레이딩 설정

지금까지의 내용은 인터넷을 찾아보면 나온다. 하지만 여기까지만 하면 절대로 Private Subnet 에 인스턴스에서 인터넷이 될수가 없다. 지금까지의 작업은 Network 단에서의 작업이였다. Security Group은 인스턴스단에서 이루어진 방화벽 작업일뿐 패킷의 경로를 조작해주는 것은 아니였다.

그런데, 이 모든 것을 다한다고 하더라도 OS에서 패킷의 경로를 원하는대로 조작해주지 않으면 Private Subnet 에 인스턴스들로부터 온 패킷과 받는 패킷들은 전송되지 않는다.

NAT 라는 것을 간단하게 설명하자면 우리가 가정에서 많이 쓰는 공유기와 같은 기능을 한다. 외부의 공인아이피를 가지고 내부의 사설 아이피를 할당해서 인터넷이 되게하는 것이 공유기의 역활인데, NAT 도 똑같다.

공유기가 없던 시절에 리눅스를 이용해서 공유기를 만들었었는데, 리눅스에 네트워크 카드를 두개 끼우고 하나는 외부망에 하나는 내부망에 연결하고 내부망에 허브를 두고 서로 통신이되도록 리눅스에서 설정을 해줬었다. 이 설정을 마스커레이딩(MASQUERADE) 이라 불렀다.

먼저 리눅스 커널에서 패킷을 포워딩 하도록 다음과 같이 설정해 준다.

그리고 iptables 에 nat 체인에 마스커레이딩 설정을 해준다.

Private 인스턴스 접속

Private 인스턴스를 접속하기 위해서는 다음과 같은 절차를 따른다.

  • 먼저 NAT 서버에 SSH 접속을 한다.
  • NAT 서버에서 Private 인스턴스로 접속을 한다.

Private 인스턴스에 접속한 후에 OS 업데이트 명령을 쳐보고 잘된다면 설정이 제대로 된 것이다.

ELB  설정.

Elastic Load Balancer 는 여러개의 서버들을 한대 묶어서 분산을 시켜주는 역활을 한다. 기존의 L4 스위치와 같은 역활을 하는 것인데 설정을 하게되면 ELB 접속을 위한 도메인이 생성된다. 이 도메인은 Amazon 에서 자동할당된 것으로 이것을 바꾸고 싶다면 DNS 서버에서 CNAME 으로 도메인을 등록하면 된다.

한가지 ELB의 제약 조건이 있는데, 그것은 반드시 Internet Gateway 와 연결되어야 한다. 이 말을 바꿔서 말하면 ELB는 반드시 Public Subnet 에 위치해야 한다는 뜻이다.

결국 ELB 때문이라도 반드시 하나의 Public Subnet 이 있어야 한다는 결론이 나온다.

ELB 설정
ELB 설정

위 그림을 보면 JumpSubnet(NAT)가 보이는데, 이게 바로 Public Subnet 이다. 반드시 1개의 Public Subnet 을 포함한다면 나머지 서브넷은 Private 이여도 상관이 없고 Private Subnet 에 있는 인스턴스들도 ELB를 통해서 서비스를 할 수 있게 된다.

ELB 에서 뒷단의 인스턴스들을 선택하기 위해서는 먼저 Subnet 을 반드시 선택해줘야 한다.

Private Subnet 의 인스턴스가 선택된 상태
Private Subnet 의 인스턴스가 선택된 상태

위와 같이 Private Subnet 의 인스턴스를 선택할 수 있다. ELB의 경우 대부분 HTTP 80 을 Inbound 로 받기 때문에 Private Subnet 안에 설치한 인스턴스에 웹서버를 올리기 되면 ELB를 통해서 서비스를 제공할 수 있게 된다.

 

이것으로 간단하게 Private Subnet 으로 서비스 구성하기 에 대해 간단하게 정리해 봤다.

다음 지도 API 좌표값 얻기

다음 지도 API를 이용해서 좌표값을 얻는 PHP 예제 소스

 

가상 Guest 이미지 마운팅

가상 Guest OS의 이미지를 마운트하는 법을 설명합니다. 이미지 마운트에는 두가지 방법이 있습니다.

첫번째방법

1.Guest OS 이미지에 파티션으로부터 디바이스 맵(Device Map)을 생성합니다.

2.볼륨(Volume) 그룹을 스캔합니다.

이렇게 볼륨이 잡히면 이 방법은 유효합니다. 그렇지 않으면 두번째 방법을 사용해야 합니다.

3.볼륨(volume) 그룹의 속성을 바꿉니다.

볼륨의 상태를 확인합니다.

4.이제 볼륨을 마운팅하면 됩니다.


이렇게 마운트가 되면 마운트 포인터(Mount Point)를 통해서 접근할 수 있습니다. 언마운트(Umount)는 다음과 같이 합니다.

5.언마운트(Unmount) 합니다.

6.볼륨속성을 바꿉니다.

7.디바이스 맵을 지웁니다.

두번째 방법

두번째 방법은 위의 첫번째 방법 2번째에서 오류가 날경우에 사용하면 됩니다. 즉, 볼륨을 스캔했는데 볼륨이 없다면 바로 마운팅하는 것입니다.

1.Guest OS 이미지에 파티션으로부터 디바이스 맵(Device Map)을 생성합니다.

2.볼륨 그룹을 스캔합니다.

이렇게 볼륨 그룹이 없다고 나옵니다.

3.그냥 마운트를 하면 됩니다.

4.Unmount 는 다음과 같이 합니다.

 

CentOS 7 Systemd 이해하기

CentOS 7로 배포판 버전이 바뀌면서 가장 크게 바뀐것이 Systemd 입니다. 기존의 볼수 없었던 서비스 하나일뿐이라고 생각할 수 있지만 Systemd 는 단지 서비스 하나의 문제가 아닙니다.

Linux 의 기본 뼈대 프로세스

Linux는 운영체제 입니다. 전원을 넣고 부팅이 되는 과정에서 시스템을 초기화하고 기타 서비스들을 위한 환경을 조성하고 그들을 시작시켜주는 일을 하는 초기화 프로세스가 필요합니다.

CentOS 6 까지는 Sys V 라고해서 init 프로세스가 이것을 담당했습니다. 커널이 메모리에 로딩되면 가장 먼저 실행되는 프로세스로 init 프로세스를 실행시킵니다. 이 프로세스는 init 스크립트, init 설정등을 기반으로 RunLevel 이나 각 서비스별 실행 스크립트를 실행시키는 겁니다.

CentOS 7 로 올라오면서 Sys V 의 init 프로세스를 버리고 Systemd 로 바꾼 겁니다. 이는 Linux 의 기본 뼈대 프로세스를 바꾼 것으로 매우 큰 변화라고 할만 합니다. Systemd 는 기준의 Sys V init 보다 훨씬 많은 기능을 제공 합니다.

  1. 시스템 부팅 프로세스
  2. Service Management
  3. cgroup 을 이용한 프로세스 자원관리
  4. 서비스 프로세스 관리

흔히들 Daemon 프로그램들을 위한 로깅, 자원할당, 부팅관리등 Systemd 로 모두 할 수 있습니다.

주요한 명령어들

Systemd 를 위한 주요한 명령어들은 다음과 같습니다.

  1. systemctl
  2. systemd-analyze
  3. systemd-cgls
  4. systemd-cgtop
  5. systemd-loginctl

현재 작동하고 있는 서비스들 목록은 다음과 같이 확인 가능 합니다.

위 목록은 현재 동작중인 서비스들만 보여주는데, 모든 서비스들을 보고 싶다면 다음과 같습니다.

서비스 활성화, 비활성화, 시작, 정지, 재시작

부팅시에 서비스를 시작하도록 하기위 해서는 다음과 같이 해줍니다.

서비스 비활성화, 시작, 중지, 재시작, 릴로드는 다음과 같습니다.

서비스가 활성화, 실행중인지 다음과 같이 질의를 할 수 있습니다.

서비스 및 설정 파악

서비스에 대한 systemd 설정에 대한 모든 정보를 다음과 같이 확인할 수 있습니다.

각 서비스들은 서로간의 의존관계를 가지고 있습니다. 이는 다음과 같은 명령어로 확인이 가능합니다.

특정 서비스에 대한 의존성을 알고 싶다면 서비스명을 주면 됩니다.

Systemd 자체를 재시작하기 위해서는 다음과 같이 합니다.

Unit File 편집

다음과 같이 Unit file 출력도 지원합니다.

Systemd 는 기본적으로 /usr/lib/system 디렉토리에 Unit File 을 보관합니다. 그런데, 커스터마이징 하기위해서 이 파일들을 직접 편집하기 보다는 /etc/systemd/system/ntpd.service.d 처럼 커스터마이징 하고 싶은 서비스의 디렉토리를 만들고 .conf 로 끝나는 설정파일을 만들어서 바꾸고자하는 설정을 넣으면 됩니다. 만일 이러한 과정이 귀찮다면 단순하게 다음과 같이 함으로써 자동으로 알아서 커스터마이징 설정파일을 만들어줍니다.

위 명령어는 다음을 수행 합니다.

  1. /etc/systemd/system/ntpd.service.d 디렉토리 생성
  2. 시스템에 등록된 기본 편집기(대부분 VIM)을 연다.
  3. 내용을 입력하고 저장하면 1에서 생성한 디렉토리에 override.conf 파일을 생성하고 내용을 읽는다. (여기서 systemctl daemon-reload 는 불필요)

만일 /usr/lib/system/system/ntpd.service Unit File 자체를 편집하고 싶다면 –full 옵션을 주면 됩니다.

부팅 상태 분석

Systemd 의 주요한 임무는 부팅 과정을 관리하고 정보를 제공하는 것입니다. 부팅 시간 정보는 다음과 같이 확인할 수 있습니다.

총 1분 28초 정도 부팅하는데 걸렸다는 걸 알수 있습니다.

부팅과정에 각 서비스별 초기화하는데 걸린 시간은 다음과 같이 확인할 수 있습니다.

초기화하는데 걸린 시간을 기준으로 정렬해서 정보를 보여줍니다. kdump.service 가 1분 4초정도의 시간을 소비했습니다.

이러한 분석은 다음과 같이 html 파일로 덤프해서 볼 수도 있습니다.

plot.html 은 다음과 같습니다.

systemd-analyze plot

부팅시에 시간이 많이 걸리는 서비스들에 대해서 빨강색으로 표시해줍니다. 이 정보는 부팅과정에서 소비되는 시간을 측정해서 개선점을 찾게 도와줍니다.

시간을 많이 잡아먹는 서비스들을 트리형태로 엮어서(chain)로 볼수도 있습니다.

MariaDB 서비스에 대해서 엮여서 시간을 많이 소모하는 하는 서비스들을 보여 줍니다.

특정 서비스에 대해서 critical-chain 을 보고 싶다면 인수로 서비스명을 주면 됩니다.

서비스 실행을 실패한 서비스들은 다음과 같이 체크 가능 합니다.

타겟바꾸기

Systemd 에서 타겟(Target)은 동시에 서비스들을 시작하는걸 허용하기 위한 그룹 메커니즘입니다. 이는 Sys V 에 Run Level 과 비슷합니다. Sys V 에서는 init 명령어를 통해서 Run Level 를 바꿀 수 있었는데, Systemd 는 타겟을 바꿀 수 있습니다.

이 타겟에 따라서 부팅시 시작되는 서비스들이 달라집니다. 기본 값은 muti-user.target 입니다. 기본 값은 다음과 같이 바꿀 수 있습니다.