Docker 기본 원리

Docker 는 Linux 의 Container 기술이다. 일단 Linux 에 해당하는 기술이라고 하는 이유와 함께 Container 를 위한 제반사항들에 대해서 알아본다.

과거에 Solaris 에 Zone 이라는 기술이 있었다. 가상화기술이 아니라 Container 기술이라고 소개가 되었던 기억이 있다. Solaris 9 에서 이전의 Solaris 8 을 Zone 이라는 기술을 이용해서 하나의 하드웨어에서 돌릴 수 있었다.

Linux 진영에서는 Jail 이라고 해서 chroot 로 파일시스템을 격리하는 기술을 이용해 마치 독립된 하나의 운영체제처럼 사용했었다. 지금도 검색을하면 Jail 환경에서 웹서버를 돌리는 기술 문서가 나온다.

그러다가 Linux 진영에서 아예 커널에서 이것을 지원하도록 만들기 시작했는데, 그것이 LXC 다. 내가 전에 직장에서 이것을 이용한 서비스를 만들던 친구녀석이 있었는데, 그때 나도 같이 봤던 기억이 있다. LXC 에서 cgroup 은 핵심이였다. 돌이켜 생각해보면 지금의 도커만큼이나 LXC 를 이용해서 구현을 할 수 있었던 것으로 기억한다. 하지만 노력과 비용이 너무 많이 들어갔다는게 문제였다.

Docker 는 정확하게 LXC 의 뼈대를 가졌다고 볼 수도 있다. 혹자는 최근의 Docker 는 LXC 를 버리고 libcontainer 를 독자적으로 사용하기 때문에 LXC 와 다르다고 하겠지만 LXC 가 사용하는 하부 구조를 Docker 도 그대로 사용한다 것을 부인할 수 없다.

  • Namespace
  • Cgroup

Docker 의 핵심은 위 두가지로 모두 Linux 커널에서 지원해야 한다. Docker 가 Linux 의 Container 기술이라고 하는 이유다. 실제로 Windows, Mac OS 에서도 설치할 수 있지만 설치할때 가상머신을 설치하고 난후에 Docker 를 설치하는걸 볼 수 있다.

Namespace

Namespace 는 마치 예전에 chroot 와 비슷하다. 다른 것이면 chroot 는 파일 시스템 격리를 우선했지만 Namespace 는 6가지를 지원한다.

  • File System
  • Process
  • Network
  • IPC
  • Hostname
  • User

Namespace 는 프로그래밍 세계에서도 사용하는 용어인데,  그곳에서 보여주는 특성과 동일하다. 6가지에 대해서 격리된 공간(isolated space)를 만들어준다. 운영체제는 분명 1개인데, 여러개의 격리된 독립적인 공간을 가질 수 있다.

물론 이를 위해서는 커널에서도 지원해야 한다.

Cgroup

Cgroup 은 Linux 시스템의 자원(Resource) 를 제어할 수 있게 해준다. 자원에 대해서 그룹을 생성한다. 그리고 그 그룹을 특정 사용자가 사용할 수 있도록 소유권을 준다. 그러면 사용자가 프로그램을 실행할때 cgroup 을 할당하면 거기에 있는 자원만큼만 사용하게 된다.

다음과 같은 자원을 제어할 수 있다.

  • Memory
  • CPU
  • I/O
  • Network
  • Device

당연히 이것도 커널에서 지원해야 한다.  커널이 지원하면 다음과 같이 /sys 에 cgroup이 나타난다.

 

애초에 Docker 도 LXC 를 이용해 구현되었다가 지금은 runC 라고 하는 걸 독자적으로 만들어서 사용하고 있다고 한다.

참고:

  1. Docker(container)의 작동 원리
  2. 초보를 위한 도커 안내서 – 도커란 무엇인가?

Amazon RDS의 Read Replica 에 Multi-AZ Deployment 지원.

2018년 1월 11일날자로 “Amazon RDS 읽기 전용 복제본은 이제 다중 AZ 배포를 지원합니다.” 를 발표했다.

한글화를 하니까 그런지 잘 와닫지 않는데, URL 주소를 보면 확실히 이해가 될 것이다. 그런데, 저 글에서 한가지 불만이 있다. 다이어그램이 없다는 거!!

하지만 놀랍게도 AWS 의 트위터에서 이것을 소개하는데 다이어그램이 있었다. 그래서 다이어그램을 첨부한다.

amazon rds read replicas now support multi az deployment
amazon rds read replicas now support multi az deployment

링크에 내용 중에 다음을 주목할 필요가 있다.

이제 프로덕션 데이터베이스에 대한 재해 복구(DR) 전략의 일부로서 다중 AZ과 함께 읽기 전용 복제본을 사용할 수 있습니다. 잘 설계 및 테스트된 DR 계획은 재해 후에도 비즈니스 지속성을 유지하는 데 필수적입니다. 소스 데이터베이스와 다른 리전에 배치된 읽기 전용 복제본은 스탠바이 데이터베이스로 사용되다가 지역 장애가 발생했을 경우 새 프로덕션 데이터베이스로 승격될 수 있습니다.

DR 구축할때 Amazon RDS 에 Read Replica Multi-AZ 기능을 이용하면 무중단 운영이 가능하다는 이야기가 되겠다.

Amazon S3 버킷 성능 끌어올리기

이글은 “How do I improve the performance of my S3 bucket?” 의 내용을 번역한 것입니다. 오역이 있을 수 있습니다.

이슈

Amazon S3 에 작업부하(workload)가 굉장히 높을때, S3 성능은 작업부하에 맞춰서 확장되지 않는다. 이런 상황이 발생하면 때때로 HTTP 500, 503 에러를 받게된다. 다음과 같은 작업부하에서 어떻게 Amazon S3 버킷의 성능을 최적화 할 수 있을까?

  1. 100 request/sec 넘는 혼합된 요청 타입(GET, PUT, DELETE 혹은 GET bucket)
  2. 300 request/sec 넘는 GET 요청.

개관

Amazon S3 는 각 AWS 리전에서 Object Key 이름의 인덱스(index) 를 관리한다. Object Key 들은 인덱스에서 여러 파티션에 걸쳐서  UTF-8 바이너리 순서대로 저장된다. Key 이름은 Key 가 저장되는 파티션을 결정한다. 순차적인 접두사(sequential prefix)를 사용하는것은, timestamp 나 알파벳 순서와 같이, Amazon S3 가 아주 많은 Key들에 대해 특정 파티션을 지정하게될 것이고 이는 잠재적으로 막대한 파티션의 I/O 용량을 쓸 가능성이 높아진다.

해결책

작업부하가 혼합된 요청 타입일때, Key 이름에 접두사처럼 해쉬 스트링을 추가함으로써 키 이름에 랜덤화를 도입하라. Key 이름에 랜덤화 도입으로 인해서, I/O 부하는 여러 인덱스 파티션에 걸쳐 분산되어질 것이다. 예를들어, 문자 순서의 MD5 해쉬를 계산할 수 있으며, Key 이름에 해쉬로부터 3 혹은 4개 문자를 Key 에 접두사처럼 더하는 계획을 세울 수 있다. 다음의 예제는 16진 해쉬의 4문자를 접두사 더한 Key 이름들을 보여준다.

4문자 해쉬 접두사가 없으면, S3는 각 Object 이름이 examplebucket/2013-26-05-15-00-0  시작되는 1이나 2 인덱스 파티션에 모든 부하가 분산될 것이고 인덱스에 모든 Object 는 알파벳-숫자 순서로 저장되어진다. 4문자 해쉬 접두사는 로드를 여러 인덱스 파티션에 걸쳐 분산시켜준다.

작업부하가 대부분 GET 요청을 보내는 거라면, Key 이름에 랜덤화를 추가할 수 있다. 게다가, 여러분은 높은 데이터 전송율과 낮은 레이턴시를 필요로하는 사용자에게 컨텐츠를 분산하기 위해 CloudFront 와 Amazon S3 를 통합해 운영할 수 있다.

Object Key 이름에 랜덤화 도입과 Amazon CloudFront 와 Amazon S3 의 통합 운영에 대한 더 많은 정보는 Request Rate and Performace Considerations 를 봐라.

CentOS 6 버릴때가 됐다.

이제 CentOS6 은 버릴때가 됐다. 오늘 PHP 7 버전을 설치하려고 보니 crypto library 가 sodium 을 필요로 하는데 이게 버전이 1.0 이상 버전이다.

문제는 이 버전을 설치하기위해서는 autoconf, automake 를 별도로 설치해줘야 하며 libzip 의존성에서도 1.0 버전 이상을 요구해 의존성 패키지가 계속 생긴다. CentOS6 에서의 컴파일러 관련 패키지들이 버전이 낮은게 문제가 계속 되고 있다.

CentOS6 의 End of life 는 2020년 11월 30일까지로 아주 오랜기간동안 지원을 해왔다. 어떤 소프트웨어를 아주 오랜기간 지원을 한다는 것은 매우 어려운 일인데, 이렇게 오랬동안 지원해준데에 감사할 따름이다.

현 시점에서 가장 좋은 배포판으로는 Ubuntu 16.04 이다. CentOS7 은 커널 버전이 3.10 이지만 , 물론 비공식으로 4.x 버전을 사용할 수 있다,  Ubuntu 16.04 는 4.x 버전이다. 커널 버전에 따른 성능 향상도 무시못함으로 될 수 있으면 Ubuntu 16.04 를 사용하는 것이 좋다.

MySQL 5.7 초기화 오류 메시지

MySQL 5.7 이 릴리즈 된지도 오래 지났다. 인기 있는 데이터베이스 시스템이라서 그런지 현장에서 많이 쓰이는 거 같다. 무엇보다도 Replication 기능의 향상이 많은 사용자를 끌어들이는 느낌이다.

이 글에서는 개인적으로 MySQL 5. 7 를 사용하면서 느낀 변화에 대해서 기술하고자 한다. 변화에 대한 기술은 MySQL 5.6 과 비교한 것이다.

데이터베이스 초기화

기존에는 mysql_install_db 를 사용했지만 이제는 mysqld 에 옵션으로 –initialize 를 주고 실행하면 시스템 데이터베이스와 테이블, innodb 저장소등을 만들어준다.

기존의 MySQL 5.6 에서 사용하는 my.cnf 파일을 가져다 초기화를 하면 위와 같이 warining 과 함께 ERROR 가 발생하면서 중단된다.

unkown variable ‘log_bin_basename’

분명히 메뉴얼에는 존재하는데도 인식이 안된다.  알수 없는 옵션이라고 하면서 데이터베이스 초기화가 안되는데 log_bin 옵션에다가 해주면 된다.

 

explicit_defaults_for_timestamp

TIMESTAMP 컬럼 데이터 타입에 대한 기본값에 대해 명시적으로 지정을 할지 말지를 결정하는 옵션. 기본은 OFF 이나 그럴 경우에 위와 같이 경고 메시지가 나온다.

TIMESTAMP 를 컬럼에서 사용할때 기본값을 명시하지 않으면 이전 버전에서는 “NOT NULL DEFAULT CURRENT_TIMSTAMP ON UPDATE CURRENT_TIMESTAMP” 가 된다. 하지만 5.7 에선 위 옵션을 이용해서 ON 으로 지정할 경우에 “NULL DEFAULT NULL” 값이 지정이 된다.

‘innodb-autoextend-increment’: unsigned value 10485760 adjusted to 1000

MySQL 5.7 에서 innodb-autoextend-increment 옵션 값은 1 ~ 1000 사이의 값이여야 한다. 단위는 MB 이여서 최고값 1000 은 1GB 가 된다. 이 경고 메시지는 10MB 라고 값을 입력함에 따라 값의 범위를 벗어나 생긴 것이다. 1 ~ 1000 사이의 값을 넣어주면 된다. 단, 단위는 생략.

이 옵션은 file-per-table 테이블스페이스 파일 이나 general 테이블 스페이스 파일에는 아무런 영향을 주지 않는다. 이러한 파일은 innodb-autoextend-increment 세팅과 상관없이 자동으로 확장된다. 초기의 확장은 소량으로 진행되지만 이후에는 4MB 씩 늘어난다.

Using innodb_support_xa is deprecated and the parameter may be removed in future releases. Only innodb_support_xa=ON is allowed

MySQL 5.7.10 버전 이후부터는 항상 활성화 된다. innodb_support_xa 를 비활성화 하면 replication 이 안전하지 않게 되고 바이너리 로그 그룹 커밋(Binary log group commit)과 관련된 성능 향상이 되지 않아 더이상 허용되지 않는다.

Using innodb_file_format is deprecated and the parameter may be removed in future releases.

5.7 이후에 기본값이 Barracuda 로 바뀌었으며 가까운 미래에 없어질 것이다. 원래 이 옵션은 5.1 버전으로 다운그레이드를 위해서 만들어졌으며 5.1 은 더 이상 지원을 하지 않게됨에 따라서 필요하지 않게 되었다.

옵션을 설정하지 않으면 된다.

AWS Certified Solutions Architect – Associate Exam 시험 후기

AWS 자격증 시험 으로 다양한 종류가 있는데,  AWS Certified Solutions Architect – Associate Exam 도 그중에 하나다. 아마도 시스템 인프라를 다루는 사람들이라면 제일 먼저 도전하게 되는 AWS 자격증 시험 인데, 이 글은 이 시험에 대한 후기이며 앞으로 이 시험을 준비하는 사람들을 위해서 도움이 되길 희망한다.

시험준비 – 교재

AWS 를 현장에서 사용하고 있다고 하더라도 AWS 자격증 시험 을 치르는 것은 또다른 문제다. AWS 서비스 자체가 매우 방대하고 시험에서 중점적으로 어느부분을 테스팅 하는지 모르기 때문에 현장의 경험에만 의존해 시험을 치루기에는 무리가 있다.

특히, 나 처럼 AWS 서비스를 이용하면서도 특정 서비스에 치중된 것만 이용할 경우에는 별도의 시험 준비가 필요하다.

자격증 시험이라고 하면 먼저 교재를 떠올린다. 더군다나 국제 자격증이라면 시험을 준비하기 위한 무언가가 절실해 지는데 그때마다 적절한 교재를 우선 찾게 된다.

AWS Certified Solutions Architect – Associate Exam 의 경우에는 교재는 많지 않다. 하지만, 아예 없지는 않고 해외서적으로서 있다.

AWS Certified Solutions Architect - Associate Exam 교재
AWS Certified Solutions Architect – Associate Exam 교재

‘OFFICIAL STUDY GUIDE’ 문구가 눈에 뛴다.

아무튼, 나의 경우에는 이 교재를 온라인 주문으로 구매했다. 구매는 교보문고 인터넷을 통해서 주문하면 되는데, 내가 구매할때 시점에서 $43 였으며, 원래 가격은 $60 인데 할인받았다, 배송비를 포함해 한화로 63,000 원이 들었다. 배송은 15일 정도 걸린거 같다.

AWS 자격증 시험을 준비하는데 길잡이로서 교재는 매우 훌륭한 역활을 한다. 하지만 서적으로 구매하는 것보다는 E-Book 으로 구매하길 권장한다. 이유는 영문으로 작성된거는 둘째치고 폰트가 작았다. 물론 영어권 사람들에게는 그 폰트 크기가 표준이겠지만 한국 사람으로서 느끼기에는 폰트가 작아보였다. 그러다보니 읽기 불편하고 집중도 안되고 진도는 안가게 되고 시간을 많이 소비했다.

E-Book 이라면 컴퓨터에서 볼수 있고 확대/축소 기능을 이용해서 자신이 원하는 대로 볼수 있다. 또, 한가지 더 이점이 있는데 각종 아키텍쳐 그림들이 서적에서는 흑백으로 인쇄된반면에 E-Book 에서는 컬러로 되어 훨씬 이해력을 높여준다.

교재의 기능은 시험 준비를 위한 길잡이와 동시에 체계적인 정리로 인해서 머리속에 정리해주는 느낌도 준다. 마치 컴퓨터 파일을 적절한 디렉토리로 나누어 저장하도록 도와주는게 교재가 아닐까 싶다.

AWS Certified Solutions Architect – Associate Exam 교재 단점.

이 글을 쓰는 시점이 2018년 2월 3일이다. AWS 서비스는 분기별로 크게는 년도별로 서비스들을 확장해 왔다. 시간이 흐름에 따라, 그 시대에서 트랜드를 반영하는 기술들이 대거 만들어지고 고객에게 제공해왔다.

그래서 그런지 실제 시험과 이 교재와의 차이가 있다. 대표적인 것이 ECS 였다. 이 교재에는 ECS 에 대한 내용이 없다. 하지만 실제 시험에서는 ECS 에 대한 문제가 다수 나왔다. 기억나는 것중에 하나는 ECS 서비스을 이해해야만 풀수 있는 문제였고 다른 하나는 ECS 서비스에 보안 설정 문제였다. 하지만 교재에는 ECS 서비스에 대한 내용은 없다.

API Gateway + Lambda 도 역시 이 교재에는 없다. 하지만 시험에는 다수 출제되었다.

또 다른 단점은 여러 서비스를 조합해 탄력적(Elasticity) 인 아키텍쳐 설계와 관련해 많은 모범사례들을 다루지 않는다. 이 교재는 시험 범위에 포함된 각 서비스들에 대한 특징을 기술하고 이를 잘 이해하는지를 테스트하는 연습문제로 구성되어 있다. 물론 후반부에 이에 대해 별도의 챕터가 있지만 그것만으로 AWS Certified Solutions Architect – Associate Exam  에서 요구하는 관점을 전부 얻기는 문제가 있어 보인다.

마지막 단점으로는 책의 구성이다. 이는 시험을 보고 난후 느낀 개인적인 단점인데, 책의 구성은 AWS 의 서비스를 중점적으로 설명하고 부가적으로 보안과 확장성을 가볍게 언급하는 정도였다.

하지만 AWS Certified Solutions Architect – Associate Exam 시험을 본 봐로서 주어진 문제자체부터가 AWS 서비스를 조합하고 여기서 보안을 어떻게 할것이며 탄력적인 운영을 위해 설정해야 하는 옵션들에 대해서 물어본다.  탄력적이고 지속적인 서비스를 위한 관점이 시험문제 전반에 흐르고 있고 이를 구현함에 있어 필요한 보안설정을 어떻게 해야하는지가 더해진다.

이러다보니 나 같은 경우에 시험문제가 상당히 어려웠다. AWS Certified Solutions Architect – Associate Exam 교재에 연습문제 수준, 그러니까 특정 서비스에 국한된 옵션 설정이나 기능들을 묻는 문제의 비중은 거의 없다. 설사 그러한 옵션을 묻는 문제조차도 두가지 이상의 서비스를 조합해 서비스를 할 경우에 어떤 서비스의 옵션을 활성화를 해야지만 원하는 결과를 얻을 수 있는가? 식으로 나온다.

이래가지곤 교재만으로 시험을 통과하기에는 상당한 어려움이 있다. 그 만큼 이 교재도 현 시점과 갭이 상당하다는 것이다.

AWS Certified Solutions Architect – Associate Exam 교재, 지침서는 필요.

단점을 보면 지침서, 교재, 오프라인 강의등이 별도움이 안될것 같이 와 닿을 것이다. 하지만 그런 의미로 전달하고자 하는 말이 아니였다. 교재, 지침서에 나오는 수준에서 각 서비스별 특징과 속성만 잔득 외워서 시험에 응시하면 문제가 될 수 있다는 것을 말하고자 하였다.

실제 문제에서는 각 서비스별 특징과 속성에 대한 문제는 몇 문제가 출제되지 않는다. 그것이 시험에 당락을 결정할만큼 출제 수도 많지 않아서 교재, 지침서만 달달 외워서는 문제가 있다는 것이다.

하지만 교재, 지침서, 오프라인 강의등은 모두 중요하다. 문제를 이해하기 위해서는 각 서비스의 특징과 속성을 매우 잘 알고 있어야 하기 때문이다. 문제가 두 서비스를 같이 사용하는 경우에 뭔가 안되는데 이럴경우 어떤것을 해야하나? 하는 식의 문제도 다수 나온다. 이런 문제는 당연히 두 서비스의 특징과 옵션들을 알고 있어야 문제를 풀수 있다.

다만, 교재에서는 Scaliable, HA 등과 같은 Elastic 관련 아키텍처에 대한 챕터가 1번 나오고 그 내용도 매우 적다. 각 서비스에 대한 특징과 속성을 다 외우고 난 후에 어떻게 하면 탄력적인 아키텍쳐를 디자인하는 지에 대한 다양한 모범사례를 많이 소개했더라면 좋았을 것 같다.

물론, 이러한 다양한 모범사례는 인터넷에 많이 나와 있어서 궂이 교재, 지침서, 오프라인에서 논의가 되어야 하는지 의문이라고 반문할 수도 있겠지만 그래도 시험의 합격을 위함이 아니라 다양한 모범사례에서도 탄력적인 아키텍쳐에 잘 부합하는 사례정도는 될수 있는 한 많이 소개 해줬으면 하는 이쉬움이 남는다.

이 글을 읽게 되면 ‘시험 존나 어렵겠네.. ㅠㅠ’ 하면서 자신감을 잃으리고 쓴 글이 절대 아닙니다. ‘존나 어렵다’ 라는 건 개인마다 다 달라서 그것을 절대적인 기준으로 삼기에는 무리가 있습니다. 저의 경우에만 ‘존나’ 어려웠던 것이고 그것이 나에게 어떤 부분이 어려움을 느끼게 해줬는지에 대해서 혹시나 타인에게 이러한 어려움도 있다는 것을 공유함으로써 앞으로 응시하고자 하는 분들에게 참고가 됐으면 하는 바람이였습니다.

이 시험에 응시하고자 하시는분들의 건투를 빌어요. 도움이 되고자 하는 마음에 두서 없이 적은것이 공포를 불어 일으킨거 같아 마음이 아프네요.

이 글이 공포심을 불러 일으킨다면 더 이상 이 글로 인해서 좋지 못한 영향을 주는 바 그냥 ‘뭐 개같은 글이 있나??’ 식으로 치부하고 넘어가셨으면 합니다. 글이 너무 진지해 많은 분들에게 어려움만 남기게 된거 같아 마음이 아프네요.

이 글의 내용은 참고만 하고 마음에 담아 두시마시고 어짜피 시간이 흐름에 따라 유효하지 않을 겁니다. 몇일간만 더 열어두고 비공개로 바꿀께요. 죄송합니다. _(__)_

AWS Certified Solutions Architect – Associate Exam 시험 관점.

앞서 교재 단점에서 언급것과 같이 AWS Certified Solutions Architect – Associate Exam 시험의 관점은 명확하다.

  1. Elastic Architecture
  2. Security to AWS Service
  3. Hybrid Architecture
  4. Service’s Features and Funtions

가장 큰 핵심은 ‘Elastic’ 과 ‘Security’ 다. Elastic 혹은 Elasticity 는 AWS 가 추구하는 핵심이다. 이를 위한 Cloud 라고 보면된다. 가용성, 내구성, 확장성 이라는 단어도 이 Elastic 이라는 단어안에 포함된다.

두번째는 Security 이다. AWS 에서 최우선으로 고려하는 것이 바로 Security 라고 한다. 이를 위해서 IAM 서비스와 각종 감시를 위한 서비스들을, 예를들어 CloudTrail, AWS Config, VPC Flow… , 를 제공한다.

세번째는 하이브리드 아키텍쳐 였다. 이것도 의외였다. 상당히 많은 문제들이 이 하이브리드 아키텍쳐에 대한 것이였다. AWS Cloud 서비스와 On-premise (Data Center) 와 연동된 아키텍쳐에서의 다양한 문제들이 나왔다. 작게는 VPN 연결 설정 문제부터 시작해서 이러한 환경에서 Security 를 어떻게 확보할 것이지를 묻는 문제였는데 상당히 촘촘한 문제였고 답문 예제도 상당히 촘촘했다. 그러다보니 문제와 답문 예제를 상당히 꼼꼼하게 읽지 않고서는 풀수 없는 문제였다.

하이브리드 아키텍쳐에 대한 문제가 많이 나온데에는 아마도 현 시점에서의 AWS 서비스의 사용방향을 반영한 결과라고도 보인다. 모든 서비스를 AWS 를 사용한다면 이러한 아키텍쳐에 대한 고민이 없겠지만 현실적으로 각종 법규와 같은 제약으로 인해서 Data Center 와 연동해야하는 시점이다. 이러한 현실에서 AWS 서비스가 지향하는 탄력적이고 보안성이 높은 아키텍쳐 설계를 위해서는 반드시 알아야할 내용이기도 하다.

내가 시험에 응시한 현 시점에서 자주 출제된, 비중있게 나온 문제의 서비스는 다음과 같다.

  • Auto Scaling Group
  • VPN, VPC Peer
  • Multi AZ, Replicated
  • ECS, Lambda and API Gateway

모든 시험문제 전반에 이러한 과점은 끝임없이 깔려 있다. 특정 서비스에 대한 특징이나 옵션에 대한 질문에서 조차도 이러한 탄력적이고 보안적인 측면으로부터 시작된다. 이러다보니 앞에서 언급한 비중있게 나온 문제도 같은 서비스지만 문제 과점은 달랐다.

예를들어 다음과 같다.

  1. VPN 서비스를 이용해 외부와 연결을 해야하는데 AWS 서비스에서 해줘야할 것은?
  2. VPN 서비스를 이용해 외부와 연결된 상태인데 On-premise 에는 이미 Active Directory 를 이용해 Role 기반으로 Account 를 관리중이다. 무슨 서비스를 이용하는게 적절하며 어떻게 계정을 설정해야 하는가? (Choose TWO)

Auto Scaling Group 에 경우에는 다양한 모범사례(Best Practice) 에서 어떻게 설정해야하는 문제가 다수 나왔다. 모범사례는 다양한 아키텍쳐를 의미한다고 보면된다. 몇걔의 Subnet 에 몇개의 EC2 Instace 가 있으며 가용성을 100% 유지하기 위한 구성으로 적합한 것, 현재 Elastic Load Balancer 뒤에 여러 Subnet 중에 한쪽 Subnet 에만 EC2 Instance 가 구성되어 있는 경우에 가용성을 높일 수 있는 구성등을 묻는 문제등이다.

또, 강조하고 싶은게 문제를 아주 면밀히 주의깊게 읽어봐야 한다. 영어라면 더 더욱 두번 읽어서라도 그 뜻을 반드시 이해해야 한다. 여러 서비스를 조합해 설정을 요구하는 것인지 보안을 요구하는지에 대한 관점을 먼저 파악하고 난 후에 질문내용에 따라 답을 정해야 한다.  문제 자체가 상당히 꼬여있고 일종의 “낚시성” 지문도 많아 상당한 주의가 요구된다.

영어로 시험을 볼 경우에 각 서비스가 지향하는 무게 중심을 잘 알아야 한다. Durability, Consistency 등에 무게를 둔 서비스인지를 잘 알아야 한다. 언뜻 보기에 여러 서비스가 모두 사용 가능한것처럼 보이지만 문제에서 요구하는 타켓을 잘 집어 내야한다.

시험 후기

개인적으로 AWS 서비스를 현장에서 사용하고 있다. 만 3년정도 된거 같다. 하지만 현장에서 사용한다고 해서 모든 AWS 서비스를 이용한건 아니다. 나의 경우에는 고작 해봐야 EC2 Instance 와 Elastic Load Balancer, Amazon S3 정도다.

CloudTrail, AWS Config, CloudFront, VPC Flow 사용은 비교적 최근이였고 특히 IAM 사용은 최근이다. IAM 의 경우에 현장에서는 보안적인 측면으로 인해서 권한을 잘 주지 않는다. 하지만 확실한 것은 IAM Administrator 권한 없이 무언가를 해보기에는 상당한 제약이 있으며 이로인해서 IAM의 강력한 기능과 모범사례를 이해하기에는 한계가 있다.

또, AWS Certified Solutions Architect – Associate Exam 에 경우에 현재의 기술 트랜드에 대해 철저한 테스트를 한다. 대표적인 것이 ECS 였다. Docker 로 대표되는 기술이자 Micro Acrchitecture 설계를 요구하는 분야다. 최근에 가장 핫 이슈이기도 함과 동시에 이론상으로만 논의되는게 아니라 현실적으로 이미, 아니 몇년 전부터 현장에서 사용되어지는 기술이다. Lambda + API Gateway 도 빠질 수 없다.

이러한 트랜드 외에도 외부 Data Center 나 On-premise 와 포함한 Hybrid Architecture 설계와 보안에 대한 테스트도 당연한 것이다.

본 시험을 치르기 전에 봤던 모의고사 시험과, 총 20문제에 $20를 내면 AWS Training 에서 볼수 있다,  갭이 너무나 컸다. 이래도 되나 싶을 정도 였다. ECS 관련된것도 Lambda + API Gateway 관련된 것도 없었다.

상당히 어려웠다. 사실상 탈락과도 같았다 할 정도의 턱걸이 합격이 였다. 그래서 그런지 집으로 돌아오는 내내 찝찝함을 떨칠 수가 없었고 마음만 더 무거워 졌다. 애시당초 이 시험을 본 목적은 내가 AWS 서비스를 잘 이용하고 있고 이해하고 있는지가 궁금해서였다. 많은 사람들이 내가 AWS 서비스를 사용한다는 이유로 많은 문의를 했고 그에 대해서 내가경험을 기반으로 이야기를 해줬는데 그렇게 해서는 안되는 거다. 경험만큼 큰 이론이 어디있냐 하겠지만 AWS 서비스를 만든 전문가만 하겠으며 그런 사람들이 말하는 수많은 이론과 목적들을 내 경험만으로 그것을 습득했다고 보기는것은 자만심 그 자체 아니겠나….

그래서 AWS 서비스가 지향하는 바가 무엇이며 어떻게 하는것이 잘 사용하는지에 대해서 알고 싶었고 가장 효율적인 방법이 바로 자격증 시험이라 판단해 도전했지만 처참했다. 합격은 숫자에 불과해…

부록1 어떤 사람들에게 적합한가?

AWS Certified Solutions Architect – Associate Exam 은 시스템 인프라를 다루는 사람에게 유리하다. 작게는 SE (System Engineer) 에서부터 크게는 DevOps 분야에서 종사하는 사람에게 적합하다. 각종 서비스와 용어들이 이 분야에서 자주 사용되어지고 실전으로 몸에 익힐 수 있기 때문이다.

국내 자격증 처럼 이론상으로만 공부하고 응시할 수준은 아니다. 실제로 AWS 서비스를 상당히 잘 사용해본 사람에게 유리하다. 특히나 다양한 모범사례(Best Practice) 와 백서(WhitePaper) 등을 꼼꼼히 읽어봐야 한다.

따라서 AWS 서비스를 다양하게 직접 다루어봐야 한다. 그리고 탄력적이면서 보안성을 높이는 관점과 현재 기술 트랜드에 대해서 학습을 해야 한다.

부록2 시험 응시 등록은 어떻게 하나.

AWS Training 웹 사이트가 있다. 로그인을 위해서 먼저 AWS 계정이 필요하며 Training 을 위한 계정 연동을 위한 간단한 추가 정보를 요구한다.

로그인이 정상적으로 되면 시험 응시 등록은 AWS Training 웹 싸이트에서 모두 가능 하다.  시험에 응시 등록후에 모든 결과는 Training 계정에 메일로 모두 발송된다. 따라서 잘 알려진 메일서비스를 사용한게 좋다.

부록3. 영문으로 시험을 볼 경우에 30분 연장을 할 수 있다고 들었다. 어떻게 하나.

나도 이 부분에 대한 정보를 찾아봤지만 자세하게 나온건 없었다. 그래서 AWS 에 문의 메일을 보냈고 2~3일 후에 다음과 같이 안내 메일을 받았다.

시험 시간 30 추가 요청은 아래 절차를 따라주시기 바랍니다.

1) AWS Certification Account 접속

2) 상단 네비게이션에서 Upcoming Exam 클릭

3) 오른쪽 네가지 선택 Request Exam Accommodations 선택

3) Request Accommodation 클릭

4) Accommodation Type 드롭다운 박스에서 ESL +30Minutes 선택

5) Create 클릭 

위 메일 내용에서 1 -> 2 로 넘어가는 단계가 한 단계 더 있다. AWS Certification Account 에 접속하면 바로 Upcoming Exam 메뉴가 보이지 않는다. 다음과 같이 하면 된다.

  1. 먼저 AWS Training 웹 사이트에 로그인을 한다.  로그인을 하면 위쪽 왼쪽에 “자격증” 메뉴가 있는데 그걸 클릭.
  2. 다음과 같이 화면이 바뀐다. 여기서 “AWS 자격증 계정” 클릭.
  3. AWS Training Certification Account
    AWS Training Certification Account
  4. 화면이 바뀜과 동시에 URL 이 https://www.certmetrics.com/amazon/ 로 바뀌고 영문 페이지가 나온다. 이제 “Upcoming Exams” 메뉴가 상단에 보인다.
  5. 나머지는 앞에 메일 내용 3번부터 따라하면 된다.

이것을 요청해서 통과되면 모든 자격증 시험 시간이 일괄 30분 연장된다. 심지어 모의고사 시험 시간도 30분 연장 된다.

시험 문항은 55문항이며 기본 80분 + 30분 더해서 110분으로 영문 시험을 봤다. 시험이 끝나고 받은 메일로 보니 55문항을 53분만에 푼것으로 나왔다. 너무나 시간을 활용을 못했다고 봐야 한다. 영어시험이라고 하더라도 110분이면 아무 많은 시간이며 한문제 한문제를 좀 더 고심하면서 풀었다면 좀 더 좋은 성적을 거뒀을 지도 모른다. 시험에 응시할 분들은 모든 시간을 충분히 활용하길 바란다.

반드시 모의시험을 보길 권장한다. 단일 서비스의 특징이나 설정 문제는 이 모의시험에서 비슷하게 많이 출제가 되었다. 인터넷에 덤프가 있다고 들었는데, 안 봐서 모르겠지만, 내 느낌으로는 별 도움이 안될거 생각된다.

부록4 인상 깊었던 문제 한 두개 정도 기억나면 말해달라…

이게 문제가 안될지 모르겠지만 한가지 적어보자면… 이런문제가 있었다.

Q) Database 시스템에 operating system privileges 를 주려고 한다. 적절한 것은 ?

A) Database 시스템만 나오면 “오~ RDS” 라고 자동 반응하게 된다. 실제로 답문항에 RDS 어쩌구 하는게 있었다. 하지만 문제를 잘 봐야 한다. 문제의 포커스는 operating system 에 권한을 주려고 한다는 것이다.  그 OS 에 Database 시스템이 동작하고 있다는 것이다.

그러면 이것은 RDS 로 구성한게 아니라 EC2 Instance 에 Database 를 올린 것이 된다. 따라서 문제를 바꿔 말하면 EC2 Instance 에 Database 를 위한 권한이 필요하다는 이야기고 이는 결국 IAM Role 기반으로 권한 설정을 하는 것이 가장 적합하다고 하겠다. Database 에 권한을 부여하면 되지 않냐하겠지만 문제에서는 OS 레벨에서 권한이다.

부록5 기타 및 주의해야 할 것.

시험 응시 등록을 할때에 시험장을 고를 수 있다. 물론 모든 시험장이 같은 일자와 시간을 제공하진 않는다. 어떤 시험장은 주말에 응시할 수 없다. 나의 경우에 강남 시험장을 이용했다. 주말 오후 4시에 응시할 수 있는 곳은 그곳 뿐이였다.

반드시 15분 전에는 도착을 해야 한다. 나의 경우에 3시 45분부터 시험 응시 확인을 시작했다. 따라서 그 이전에 도착을 해야 좋다. 주말이라 그런건지는 몰라도 응시생은 나 포함해서 3명이여서 금방 끝나버려서 늦게 도착하면 어떻게 될지 모른다.

시험 응시 등록을 마치면 메일이나 Dashboard 에서 응시번호, 응시일자 장소등이 기입된 페이지가 나오고 인쇄할 수 있도록 해놨다. 인터넷 상에서는 이 페이지를 인쇄하고 가야한다고 해서 가지고 갔지만 그건 필요가 없었다.

한가지 ‘벙쪘던’ 것은 반드시 2개의 신분증 카드가 필요하다는 것이다. 한국 사회에서 신분증명은 주민등록증, 자동차 운전면허 둘중 하나만 있으면 된다. 그래서 시험장에서 응시생 확인을 할때에 자동차 운전면허만 보여줬더니 하나를 더 내놓으라는 것이다.

이게 뭔가 싶었다. 하지만 시험 응시 등록 완료 안내 페이지에는 반드시 자신의 신분을 증명할 2개의 수단을 제시해야한다고 되어 있다. 하지만 그것을 간과했던 나는 크게 당황했는데 등록확인해주시는 분이 ‘신용카드’ 도 된다고 해서 신용카드를 보여줬다.

한국 사회에서 신용카드가 무슨 신분증명이 될까 싶다만은 어쨌거나 반드시 2개여야 한다. 주민등록증과 운전면허증, 신용카드, 학생증, 여권 등에서 2개만 가지고 있으면 된다. 돌이켜 생각해보면 많이 당황한 순간이 였다.

시험장에 가면 등록확인을 한다. 내가 응시한 시험장 한쪽 벽면에는 사물함, 그건 마치 헬스장 사물함 처럼 보였다!!!, 있고 거기에 소지품을 넣어야 한다. 한가지 중요한 것은 호주머니에 아무것도 가지고 들어갈 수 없다. 모두 살물함에 보관해야 한다.

시험장 안에는 마치 도서관 처럼 컨닝을 못하도록 책상이 놓여있다. 그리고 책상에는 A4 몇장과 연필이 제공된다. 특이한 것은 귀마개도 제공됐다. (나는 사용하지 않았다!)  시험장에서 제공된 A4와 연필은 시험이 끝났다고 해서 들고 나올 수 없다. 들고 나올 경우 부정으로 간주 시험이 취소처리 된다.

마지막으로 시험감독관의 말을 주의깊게 들어야 한다. 그중에서 시험이 끝나고 난후 결과를 바로 확인하는 페이지가 나오는데, 그 화면이 나오면 창을 닫거나 오른쪽 위에 “Exit” 버튼을 누르지 말고 그대로 나오라고 했다. 시스템에 문제인지 Exit 버튼을 누르면 문제가 생길수 있다는 말을 하던데 암튼 이러한 주의사항을 잘 새겨들어서 합격에 들뜬 나머지 깔끔하게 정리하자 했다가는 큰 고충을 겪을 수도 있다. 그냥 다 놔두고 몸만 나오면 된다.

Trac 설치 및 실행

현재(2018년)에 Trac 을 설치해서 사용하는 사람이 있을지 모르겠지만, 개인적으로 뭔가를 할때 제일 좋은 툴은 것 같다. 그런데, Trac 설치는 가끔 하는거라 할때마다 헤메곤 하는데 기록해두기 위해서 이 글을 작성한다.

Python 2.7

Trac 은 현재 Python 2.7 에서 잘 작동한다. Python 2.7 이 설치되어 있어야 한다. 현 시점에서 CentOS 7, Ubuntu 16.04 LTS 에서 기본으로 Python 2.7 이 설치되어 있어 별도로 Python 2.7 을 설치할 필요는 없다.

pip, setuptools 설치

Trac 뿐만 아니라 Python 의 라이브러리를 설치하기 위해서 pip 를 이용한다. 역시나 이것도 프로그램이라서 pip 를 설치해줘야 한다.

설치하는 방법은 다음과 같이 두가지가 있다.

  • 배포판 패키지로 설치
  • setuptools 을 이용한 설치.

CentOS 7 과 Ubuntu 16.04 LTS 에서는 pip 패키지를 제공 한다. 별도로 setuptools 을 이용한 설치를 할 필요가 없다.

설치를 마쳤으면 최신버전으로 다음과 같이 업데이트를 해준다.

그리고 setuptools 은 많은 Python 라이브러리들을 설치할때 이용된다. 이것도 CentOS 7, Ubuntu 16.04 LTS 에서 패키지로 제공 한다. 설치해 주자.

Trac 1.0.15 설치

현재 2018년 1월에 Trac 최신 버전은 1.3 이다. 하지만 Trac 에 설치되는 플러그인들이 아직 1.2 이상을 잘 지원하지 못한다. 그래서 1.0.1 버전을 설치하기로 했다.

이렇게 함으로써 Trac 의 설치는 끝난다.

Trac 프로젝트 생성

Trac 은 알겠지만 Project Management 프로그램이다. 그래서 프로젝트를 만들어 줘야 한다.

위와같이 프로젝트를 생성해 준다.

프로젝트가 생성이 되었다면 이제 프로젝트를 관리할 ID 에 권한을 부여해줘야 한다. 보통 ID 는 admin 으로 하고 다음과 같이 프로젝트 Administrator 퍼미션(Permision)을 부여해준다.

admin 이라는 ID 를 추가하면서 퍼미션을 TRAC_ADMIN 으로 부여 했다.

로그인 인증 설정

admin 이라는 ID 로 로그인 인증을 위해서는 인증을 위한 방법을 먼저 정의해야 한다. 인증 방법에는 다음과 같이 두가지 방법이 있다.

  • Basic Auth by HTTP
  • Htdigest

나의 경우에는 Htdigest 방법을 사용한다. 이를 위해서 AccountManager 플러그인을 설치했다.  그리고 Htdigest 인증 파일을 작성해줘야 한다. 이를 위해서 다음과 같이 Htdigest 인증 파일을 만들어주는 trac-digest.py 파일을 이용한다.

위 소스를 trac-digest.py 로 저장한다. 그리고 다음과 같이 실행해 준다.

AccountManager 플러그인을 활성하고 이를 이용해서 이 인증 방법을 지정해준다. 다음과 같이 trac.ini 설정 파일을 편집해 준다.

Trac 실행

Trac 실행은 먼저 다음과 같이 CLI 로 할 수 있다.

CentOS 7, Ubuntu 16.04 LTS 는 Systemd 가 기본이다. 시스템 부팅 프로세스에 등록하기 위해서 systemd 스크립트를 다음과 같이 작성해 준다.

/etc/default/tracd 파일에 다음과 같이 프로젝트 정보를 기술해 준다.

이제 다음과 같이 systemd 스크립트 활성화 하고 시작해준다.

이렇게 한 후 서버에 8000 포트로 접속해서 “LocalProject” 프로젝트 리스트가 나오면 정상이다.

그리고 로그인을 할때에 앞서 설정한 계정과 비밀번호로 로그인을 하면 된다.

PHP7 설치하기

이 문서는 php7.2 설치 문서 입니다.

1. 준비

CentOS 가 최소설치되었다고 가정하고 시작했기 때문에 컴파일 환경을 구축해야 합니다.

Ubuntu16.04 의 경우에는 다음과 같은 프로그램이 설치되어 있어야 합니다.

 

2.Download and Unpack

최신버전을 다운로드 받아야 합니다.

3. Configure and Compile

이제 PHP에서 사용할 기능들을 결정해야 합니다. PHP에서 제공하는 기능은 아주 많지만 여기서는 다음과 같은 기능들을 사용할 것입니다.

아무런 에러없이 끝났다면 다음과 같이 컴파일을 해주고 설치해준다.

4. Configure to the installed php7

config-file-scan 디렉토리를 생성해 준다.

그리고 php.ini 파일을 /opt/php-7.2.1/etc 디렉토리로 복사해준다.

그리고 다음과 같이 php-fpm 을 위한 설정 파일도 만들어 준다. 이것은 php-fpm.conf.default 파일을 php-fpm.conf 파일로 복사해주고 다음과 같이 설정해 주면 된다.

그리고 pool 을 php-fpm.d 디렉토리에 설정해 준다. 보통 기본으로 www.conf 가 있는데 이것을 활요하면 된다.

위 설정은 각 서버 환경에 맞춰 해줘야 한다. 얼마나 사용자를 받느냐에 따라서 pm 값을 달리 해줘야 한다.

마지막으로 다음과 같이 systemd 를 위한 서비스 파일을 다음과 같이 작성해 줍니다.

위 내용을 php-fpm.service 파일로 /etc/systemd/system 디렉토리에 작성해 주고 systemd 에 등록해준다.

5. Verify

php-fpm 이 잘 동작하는지 확인 하는 방법으로 cgi-fcgi 명령어를 활용하는 법이 있다. 이 명령어는 php-fpm 처럼 FastCGI 로 동작하는 서버에 직접 연결을 할 수 있게 해준다.

php 정보를 표시해줄 파일을 작성하고 다음과 같이 cgi-fcgi 를 사용해 본다.

index.php  파일에는 ‘phpinfo();’ 를 호출해 php 설치에 관한 정보를 출력하도록 했으며 각종 파라메터를 쉘 환경변수에 지정해서 cgi-fcgi 로 전달해준다.

Maven 저장소 URL 변경하기

Maven 3 을 쓰다보면  Update나 Build 시에 Maven은 어딘서가 의존성 패키지를 다운받는다. 다운받은 파일을 어디에 저장할 것인가 를 지정하는것이 localRepository 이다.

문제는 어딘가에서 받아오는 저장소 URL 이 간혹 접속이 불가할 경우가 문제가 된다. 나 같은 경우에 일하고 있는 사무실 환경에서는 어찌된 영문인지 Maven이 패키지를 제대로 가지고 오지 못하고 있었다. 원인은 “Connection Time Out” 으로서 “https://repo.maven.apache.org/maven2” 에 접속이 되지 않아 발생 했다. 자세히 보니 https 로 접속이 안되는 문제였다.

이와같이 접속이 불가능 할 경우에는 Maven 저장소 URL 을 바꿀 필요가 있다.

pom.xml 에서 바꾸기

일차적인 방법으로는 프로젝트의 pom.xml 파일에서 저장소 위치를 지정하는 것이다. 먼저 저장소 위치가 어떻게 되는지 알수가 있다. 그것은 Eclipse 에서 pom.xml 을 열면 편집영역 하단에 “Effective POM” 탭이 보인다. 여기서 중간쯤에 보면 다음과 같은 저장소 URL 이 보인다.

Maven 3 에서 기본 세팅된 저장소 URL 을 살펴 볼수 있다.

아니면 pom..xml 이 있는 프로젝트 디렉토리에서 다음과 같은 명령어로 Effective POM 상태를 출력해 볼 수 있다.

이제 기본적인 저장소 URL 을 알았으니 이것을 바꿔보자. pom.xml 탭을 클릭해 다음과 같이 바꿔보자.

이렇게 하면 Maven의 기본 저장소 URL을 변경이 된다.

Maven settings.xml 설정 파일에서 바꾸기

만일 프로젝트가 아주 많이 있다면 일일이 프로젝트마다 앞에 방법대로 pom.xml 을 수정한다는 것이 바보같은 짓이된다. 이럴때에는 Maven의 설정 파일인 settings.xml 에서 설정 해주면 된다.

다음과 같이 설정 해준다.

이렇게 변경 후 저장하고 Eclipse 를 재시작하면 모든 프로젝트에 Effective POM 을 보면 저장소 위치가 변경된 것을 확인할 수 있다.

Maven 다중 모듈 프로젝트 구성

STS Eclipse를 이용하면 손쉽게 Spring MVC 프로젝트를 구성할 수 있다. Spring MVC 프로젝트에는 Java 파일과 Web Content 파일을 모두 포함한다. 이를 Dynamic Content, Static Content 등로 구분하기도 한다.

문제는 이렇게 하나의 프로젝트에 모든 것을 담을 경우에 다음과 같은 문제가 발생할 수 있다.

  • 분리 배포가 불가능 하다. 요즘에는 WAS 앞에 Web 서버를 따로 두어 Static Content 를 서비스 하는 아키텍쳐가 많은데 하나의 프로젝트에 모든 것을 담게 되면 분리 배포가 어렵다.

단 하나의 큰 문제인데 이 문제를 가볍게 여길 수 없다. 실제 프로젝트를 할때에 이것을 간과해 나중에 아주 힘들어지는 경우가 허다 하다.

그래서 Spring MVC 기반의 프로젝트를 할때에는 Dynamic Content, Static Content를 분리해 진행하는 것이 좋은데, Maven 에서는 이를 ‘다중 모듈 프로젝트 구성’ 이라는 기능으로 제공하고 있다.

Root 프로젝트 생성

다중 모듈 프로젝트를 생성하는 첫번째는 Root 프로젝트 생성이다. 이름에서도 알수 있듯이 이 모든 모듈 프로젝트에 뿌리가 되는 프로젝트를 말한다.

이는 ‘Maven Project’ 를 통해서 생성 할 수 있다.

Maven Project 생성
Maven Project 생성

위와같이 Maven Project를 통해서 생성할때 한가지 주의해야 하는 것이 있는데, Pakaging 형태를 pom으로 해야만 한다. Root 프로젝트는 하위 프로젝트에 기반을 제공하는 것으로 별도 was 배포용 패키지를 만들지 않는다.

Root Project 에 pom Packaging
Root Project 에 pom Packaging

이렇게 하면 Root Project가 생성이 된다.

이 상태를 그대로 두고 Static Content를 위한 하위 프로젝트를 먼저 생성한다.

하위 프로젝트 생성(Static Content)

Static Content 를 위한 하위 프로젝트는 오로지 CSS, Java Script, Images 만을 위한 것이여서 Spring Mvc 샘플 프로젝트를 만들 필요는 없다. 간단하게 Maven Module 로 제작하면 된다.

앞에서 생성한 Root Project 에서 마우스 오른쪽 버튼을 눌러 Maven Module 생성하기를 시작한다. 그리고 다음과 같이 ‘maven-archetype-webapp’ 를 선택해준다.

Maven 으로 webapp 생성
Maven 으로 webapp 생성

이렇게 하면 Root Project 밑에 디렉토리로 하위 프로젝트가 위치하는게 보이고 이와 별도로 이클립스에 프로젝트로도 보인다.

Root 와 Static 프로젝트 모습
Root 와 Static 프로젝트 모습

Static 프로젝트에 pom.xml 를 보면 Root 프로젝트와 연결된 설정이 보인다.

이제 Static 의 디렉토리 구조를 바꾼다. 이는 이전에 글을 참고 하면 잘 나와 있는데 여기서는 WebContent 디렉토리만 인식시켜주면 되기 때문에 pom.xml 에 설정해주고 파일을 옮기면 된다.

그리고 Static 파일을 위한 디렉토리를 생성한 다음에 가짜 파일을 하나 만든다.

Static 파일을 위한 CSS, JS, Images 디렉토리 생성
Static 파일을 위한 CSS, JS, Images 디렉토리 생성

이렇게 한 후에 Build 를 하면 WebContent 이하 디렉토리 내용이 war 파일로 작성되어 진다. war 파일이긴하지만 Static만 있으면 되기 때문에 이 Static 파일만 담기도록 해보자. pom.xml 을 다음과 같이 수정 한다.

** 위와같이 설정해도 원하는데로 동작하지 않습니다. 아신다면 덧글 남겨 주시면 고맙겠습니다. **

이렇게 한 후에 SystemVLabs-Static 에 빌드를 하면 WebContent 디렉토리에 내용들이 war로 만들어진다. 또, RootProject 에서 빌드를 하면 하위 모듈로등록된 SystemVLabs-Static 도 빌드가 되면 정상적으로 프로젝트가 세팅된 것이다.

하위 프로젝트 생성(Dynamic Content)

이제 Dynamic Content 를 위한 하위 모듈 프로젝트를 생성해야 한다. 이는 여러 방법이 존재하는데, 내가 보기에 가장 손쉬운 방법을 설명하고자 한다.

먼저 STS Eclipse 의 Spring MVC 샘플 프로젝트를 생성한다. 그러면 기존의 RootProject와는 별도로 프로젝트가 생길 것이다.

Spring5 샘플 프로젝트
Spring5 샘플 프로젝트

이제 이것을 export 를 해주는데, File System 으로 export 를 한다.

Export를 File System 으로 한다.
Export를 File System 으로 한다.

대상 디렉토리는 RootProject 로 지정한다.

Spring5의 RootProject 로 Export
Spring5의 RootProject 로 Export

이렇게 한 후에 RootProject 를 ReFresh 하면 방금 Export 한 Spring5 디렉토리가 보인다.

이제 기존의 Spring5 프로젝트는 디스크에서 삭제도 체크해  삭제한다. 그리고 이제 프로젝트를 Import 한다.

Existing Project into Workspace
Existing Project into Workspace

“Existing Projects into Workspace” 를 선책하고 Next,

Export된 Spring5 디렉토리 지정
Export된 Spring5 디렉토리 지정

이렇게 하면 RootProject 하위가 아닌 독립된 프로젝트로 나타난다.

마지막으로 RootProject 의 pom.xml 에 방금 등록한 하위 모듈 프로젝트로 등록해 준다.

그리고 새로 등록한 하위 모듈 프로젝트의 pom.xml 에는 parent 모듈을 등록해 준다.

이렇게 함으로써 Dynamic Content 를 하위 모듈 프로젝트 등록은 다 된 것이다.