Amazon S3 에 작업부하(workload)가 굉장히 높을때, S3 성능은 작업부하에 맞춰서 확장되지 않는다. 이런 상황이 발생하면 때때로 HTTP 500, 503 에러를 받게된다. 다음과 같은 작업부하에서 어떻게 Amazon S3 버킷의 성능을 최적화 할 수 있을까?
100 request/sec 넘는 혼합된 요청 타입(GET, PUT, DELETE 혹은 GET bucket)
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 를 통합해 운영할 수 있다.
이제 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 를 사용하는 것이 좋다.
TIMESTAMP 컬럼 데이터 타입에 대한 기본값에 대해 명시적으로 지정을 할지 말지를 결정하는 옵션. 기본은 OFF 이나 그럴 경우에 위와 같이 경고 메시지가 나온다.
TIMESTAMP 를 컬럼에서 사용할때 기본값을 명시하지 않으면 이전 버전에서는 “NOT NULL DEFAULT CURRENT_TIMSTAMP ON UPDATE CURRENT_TIMESTAMP” 가 된다. 하지만 5.7 에선 위 옵션을 이용해서 ON 으로 지정할 경우에 “NULL DEFAULT NULL” 값이 지정이 된다.
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 isdeprecated andthe parameter may be removed infuture releases.Only innodb_support_xa=ON isallowed
MySQL 5.7.10 버전 이후부터는 항상 활성화 된다. innodb_support_xa 를 비활성화 하면 replication 이 안전하지 않게 되고 바이너리 로그 그룹 커밋(Binary log group commit)과 관련된 성능 향상이 되지 않아 더이상 허용되지 않는다.
Using innodb_file_format isdeprecated andthe parameter may be removed infuture releases.
5.7 이후에 기본값이 Barracuda 로 바뀌었으며 가까운 미래에 없어질 것이다. 원래 이 옵션은 5.1 버전으로 다운그레이드를 위해서 만들어졌으며 5.1 은 더 이상 지원을 하지 않게됨에 따라서 필요하지 않게 되었다.
AWS 자격증 시험 으로 다양한 종류가 있는데, AWS Certified Solutions Architect – Associate Exam 도 그중에 하나다. 아마도 시스템 인프라를 다루는 사람들이라면 제일 먼저 도전하게 되는 AWS 자격증 시험 인데, 이 글은 이 시험에 대한 후기이며 앞으로 이 시험을 준비하는 사람들을 위해서 도움이 되길 희망한다.
시험준비 – 교재
AWS 를 현장에서 사용하고 있다고 하더라도 AWS 자격증 시험 을 치르는 것은 또다른 문제다. AWS 서비스 자체가 매우 방대하고 시험에서 중점적으로 어느부분을 테스팅 하는지 모르기 때문에 현장의 경험에만 의존해 시험을 치루기에는 무리가 있다.
특히, 나 처럼 AWS 서비스를 이용하면서도 특정 서비스에 치중된 것만 이용할 경우에는 별도의 시험 준비가 필요하다.
자격증 시험이라고 하면 먼저 교재를 떠올린다. 더군다나 국제 자격증이라면 시험을 준비하기 위한 무언가가 절실해 지는데 그때마다 적절한 교재를 우선 찾게 된다.
AWS Certified Solutions Architect – Associate Exam 의 경우에는 교재는 많지 않다. 하지만, 아예 없지는 않고 해외서적으로서 있다.
아무튼, 나의 경우에는 이 교재를 온라인 주문으로 구매했다. 구매는 교보문고 인터넷을 통해서 주문하면 되는데, 내가 구매할때 시점에서 $43 였으며, 원래 가격은 $60 인데 할인받았다, 배송비를 포함해 한화로 63,000 원이 들었다. 배송은 15일 정도 걸린거 같다.
AWS 자격증 시험을 준비하는데 길잡이로서 교재는 매우 훌륭한 역활을 한다. 하지만 서적으로 구매하는 것보다는 E-Book 으로 구매하길 권장한다. 이유는 영문으로 작성된거는 둘째치고 폰트가 작았다. 물론 영어권 사람들에게는 그 폰트 크기가 표준이겠지만 한국 사람으로서 느끼기에는 폰트가 작아보였다. 그러다보니 읽기 불편하고 집중도 안되고 진도는 안가게 되고 시간을 많이 소비했다.
E-Book 이라면 컴퓨터에서 볼수 있고 확대/축소 기능을 이용해서 자신이 원하는 대로 볼수 있다. 또, 한가지 더 이점이 있는데 각종 아키텍쳐 그림들이 서적에서는 흑백으로 인쇄된반면에 E-Book 에서는 컬러로 되어 훨씬 이해력을 높여준다.
교재의 기능은 시험 준비를 위한 길잡이와 동시에 체계적인 정리로 인해서 머리속에 정리해주는 느낌도 준다. 마치 컴퓨터 파일을 적절한 디렉토리로 나누어 저장하도록 도와주는게 교재가 아닐까 싶다.
이 글을 쓰는 시점이 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 교재에 연습문제 수준, 그러니까 특정 서비스에 국한된 옵션 설정이나 기능들을 묻는 문제의 비중은 거의 없다. 설사 그러한 옵션을 묻는 문제조차도 두가지 이상의 서비스를 조합해 서비스를 할 경우에 어떤 서비스의 옵션을 활성화를 해야지만 원하는 결과를 얻을 수 있는가? 식으로 나온다.
이래가지곤 교재만으로 시험을 통과하기에는 상당한 어려움이 있다. 그 만큼 이 교재도 현 시점과 갭이 상당하다는 것이다.
단점을 보면 지침서, 교재, 오프라인 강의등이 별도움이 안될것 같이 와 닿을 것이다. 하지만 그런 의미로 전달하고자 하는 말이 아니였다. 교재, 지침서에 나오는 수준에서 각 서비스별 특징과 속성만 잔득 외워서 시험에 응시하면 문제가 될 수 있다는 것을 말하고자 하였다.
실제 문제에서는 각 서비스별 특징과 속성에 대한 문제는 몇 문제가 출제되지 않는다. 그것이 시험에 당락을 결정할만큼 출제 수도 많지 않아서 교재, 지침서만 달달 외워서는 문제가 있다는 것이다.
하지만 교재, 지침서, 오프라인 강의등은 모두 중요하다. 문제를 이해하기 위해서는 각 서비스의 특징과 속성을 매우 잘 알고 있어야 하기 때문이다. 문제가 두 서비스를 같이 사용하는 경우에 뭔가 안되는데 이럴경우 어떤것을 해야하나? 하는 식의 문제도 다수 나온다. 이런 문제는 당연히 두 서비스의 특징과 옵션들을 알고 있어야 문제를 풀수 있다.
다만, 교재에서는 Scaliable, HA 등과 같은 Elastic 관련 아키텍처에 대한 챕터가 1번 나오고 그 내용도 매우 적다. 각 서비스에 대한 특징과 속성을 다 외우고 난 후에 어떻게 하면 탄력적인 아키텍쳐를 디자인하는 지에 대한 다양한 모범사례를 많이 소개했더라면 좋았을 것 같다.
물론, 이러한 다양한 모범사례는 인터넷에 많이 나와 있어서 굳이 교재, 지침서, 오프라인에서 논의가 되어야 하는지 의문이라고 반문할 수도 있겠지만 그래도 시험의 합격을 위함이 아니라 다양한 모범사례에서도 탄력적인 아키텍쳐에 잘 부합하는 사례정도는 될수 있는 한 많이 소개 해줬으면 하는 이쉬움이 남는다.
이 글을 읽게 되면 ‘시험 존나 어렵겠네.. ㅠㅠ’ 하면서 자신감을 잃으리고 쓴 글이 절대 아닙니다. ‘존나 어렵다’ 라는 건 개인마다 다 달라서 그것을 절대적인 기준으로 삼기에는 무리가 있습니다. 저의 경우에만 ‘존나’ 어려웠던 것이고 그것이 나에게 어떤 부분이 어려움을 느끼게 해줬는지에 대해서 혹시나 타인에게 이러한 어려움도 있다는 것을 공유함으로써 앞으로 응시하고자 하는 분들에게 참고가 됐으면 하는 바람이였습니다.
이 시험에 응시하고자 하시는분들의 건투를 빌어요. 도움이 되고자 하는 마음에 두서 없이 적은것이 공포를 불어 일으킨거 같아 마음이 아프네요.
이 글이 공포심을 불러 일으킨다면 더 이상 이 글로 인해서 좋지 못한 영향을 주는 바 그냥 ‘뭐 개같은 글이 있나??’ 식으로 치부하고 넘어가셨으면 합니다. 글이 너무 진지해 많은 분들에게 어려움만 남기게 된거 같아 마음이 아프네요.
이 글의 내용은 참고만 하고 마음에 담아 두시마시고 어짜피 시간이 흐름에 따라 유효하지 않을 겁니다. 몇일간만 더 열어두고 비공개로 바꿀께요. 죄송합니다. _(__)_
AWS Certified Solutions Architect – Associate Exam 시험 관점.
앞서 교재 단점에서 언급것과 같이 AWS Certified Solutions Architect – Associate Exam 시험의 관점은 명확하다.
Elastic Architecture
Security to AWS Service
Hybrid Architecture
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
모든 시험문제 전반에 이러한 과점은 끝임없이 깔려 있다. 특정 서비스에 대한 특징이나 옵션에 대한 질문에서 조차도 이러한 탄력적이고 보안적인 측면으로부터 시작된다. 이러다보니 앞에서 언급한 비중있게 나온 문제도 같은 서비스지만 문제 과점은 달랐다.
예를들어 다음과 같다.
VPN 서비스를 이용해 외부와 연결을 해야하는데 AWS 서비스에서 해줘야할 것은?
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일 후에 다음과 같이 안내 메일을 받았다.
위 메일 내용에서 1 -> 2 로 넘어가는 단계가 한 단계 더 있다. AWS Certification Account 에 접속하면 바로 Upcoming Exam 메뉴가 보이지 않는다. 다음과 같이 하면 된다.
먼저 AWS Training 웹 사이트에 로그인을 한다. 로그인을 하면 위쪽 왼쪽에 “자격증” 메뉴가 있는데 그걸 클릭.
다음과 같이 화면이 바뀐다. 여기서 “AWS 자격증 계정” 클릭.
AWS Training Certification Account
화면이 바뀜과 동시에 URL 이 https://www.certmetrics.com/amazon/ 로 바뀌고 영문 페이지가 나온다. 이제 “Upcoming Exams” 메뉴가 상단에 보인다.
나머지는 앞에 메일 내용 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 버튼을 누르면 문제가 생길수 있다는 말을 하던데 암튼 이러한 주의사항을 잘 새겨들어서 합격에 들뜬 나머지 깔끔하게 정리하자 했다가는 큰 고충을 겪을 수도 있다. 그냥 다 놔두고 몸만 나오면 된다.
admin 이라는 ID 로 로그인 인증을 위해서는 인증을 위한 방법을 먼저 정의해야 한다. 인증 방법에는 다음과 같이 두가지 방법이 있다.
Basic Auth by HTTP
Htdigest
나의 경우에는 Htdigest 방법을 사용한다. 이를 위해서 AccountManager 플러그인을 설치했다. 그리고 Htdigest 인증 파일을 작성해줘야 한다. 이를 위해서 다음과 같이 Htdigest 인증 파일을 만들어주는 trac-digest.py 파일을 이용한다.
2018년… 또 한해가 밝았다. 어쩌면 한 해를 시작할때마다, 오래전 부터, 뭔가 강도가 세지는 느낌을 받곤 했다. 뭔가 나를 옥죄어 온다는 그런 답답함, 불합리적인 무언가가 올 한 해도 나를 옥죌 거라는 힘든 생각이 한 해가 밝을때 마다 강하게 든다.
지금까지는 그것이 무엇인지를 모르는 상태에서 답답함이 나를 힘들게 하는 것중에 하나였다. 도대체 뭘까.. 실체도 없는데 밀려오는 올가미를 그냥 앉아서 참고 견뎌야 하나… 하는 어떤 답답함…
그런데, 35세를 지나면서 그것이 실체가 무엇인지를 대충 알것만 같다. 그리고 그러한 답답함을 제공하는 원인에는 한국인이라는 사고체계가 근본적인 문제이며 따라서 이것을 해결할 방법이 없다는 것도 알게 돼었다.
한국인의 정신적 질병.. 사람 관계 좋아=성격 좋아=밝아
한국인의 정신적 질병이라고 나는 진단하는 것중에 하나가 다음과 같은 말이다.
사람 관리 하나는 잘해
대표적인 병적인 증상이다
사람관리를 잘한다… 이 말 한마디로 인해서 한국 사회는 다음과 같은 사람이 사회적인 역활로서 최상이라고 판단한다.
밝고 활동적이며 창의적인 인재.
인간이란 참으로 신비로운 존재다. 나이를 먹어감에 따라 여러사람의 행동양식이나 사고체계에 대해서 면밀히 생각해보는 시간을 많이 가지게 된다. 저녁 먹고나서 할일 없이 멍때리고 있으면 지난 과거에 어떤일이 회상이 되면서 그 일에 개입된 인간들이 했던 말과 행동들을 관찰하게 되는 것이다. 그럴때마다 인간이란 존재가 저렇게 다양할 수가 있나… 그 무엇으로 제단할 수 없는 각각이 독립된 개체라는 사살에 감탄을 하곤 한다.
사회 생활이란 것이 과연 제도적 장치일까? 다시 말해서 인간이 집단생활을 영위하기 위해서 만들어진, 그래서 어떤 질서적인 체계가 사회일까….
그다지 밝아보이지도 않고 활동적이지도 않은 인간 유형을 많이 접하게 된다. 우선적으로 내가 그렇다 보니, 끼리끼리 논다고, 그런 사람들이 눈에 들어오는건 어쩔 수 없다. 밝아보이지도 않고 활동적이지도 않은 많은 사람들이 예민한 성격일 경우가 많았던 것도 우연일지도 모른다.
하지만 그렇게 예민한 성격은 어떤 일에 있어서 꼼꼼함과 창의적인 열정을 많이 보유한 사람들이였다. 그다지 밝아보이지도 않아서 그가 무슨일을 하는지 주위 사람들이 잘 알아보지는 못하지만 그런 사람들은 적어도 자신이 하는 일에 대해서 꼼꼼하게 처리하려고 애쓰는 모습을 많이 보게 된다.
꼼꼼하게 일을 처리하기 위해서는 자신이 하는 일에 대해서 많은 이론적 지식과 경험을 보유하고 있어야 하는데, 그러다보니 이런 부류의 사람들은 자신의 일에 대해서 많은 노력을 기울이고 그러한 노력을 위해서 끊임없이 자기 스스로 열정을 불러 일으킬려고 노력한다.
30대 중반 이후부터…. ‘세상 편하게 살 방법’
문제는 한국 사회에서는 대부분 30대 중반 이후가 되면 저러한 노력과 열정을 가진 인간이 되기를 꺼려 한다는데 있다.
30대 중후반에 여기저기 면접을 보러다니다보면 항상 하는 질문이 있다.
지금까지 어떤 팀을 이끌거나 프로젝트를 이끌어본 경험이 있는가?
30대 중후반까지 어떤 팀을 이끌거나 프로젝트를 이끌어본 경험은 없지만 어떤 문제를 근본적으로 해결해보고자 밤을 세워가며 많은 논문과 글을 읽고 되도 않는 C 코드를 해석하면서 문제를 해결해 본 경험은 있다.
하지만, 한국 사회에서 30대 중후반까지 어떤 걸 이끌어보지 못했다면 더 이상 그 분야에서 채용되기가 힘들다. 30대 중후반에쯤 되면 돈도 많이 줘야 할테고 그 돈에 비례해서 그에 해당하는 직급과 업무를 줄려고 한다. 그런한 자리는 어떤 팀을 책임지는 위치밖에 없다.
내 주변을 관찰해 보면 IT 판이 돌아가는걸 잘 아는 인간들이 적지 않다. AWS가 뭐고 어떤 프로젝트에서 무엇을 써야 하고 이럴땐 어떻게 하는게 좋은지 정도를 아는 사람들이다. 그들은 넓게 알지만 깊게는 잘 모르는 경우이고 대부분은 또 안타갑게도 이론적 배경이 없는 사람들도 상당수다.
이런 사람들이 술을 먹으면 항상 하는 이야기가 있다.
빨리 팀장 달고 싶다.
팀장을 달아야 더 이상 누군가로부터 지시를 받지 않고 문제 해결을 위해서 낑낑대며 노력하지 않아도 된다는 거다. 팀장이되면 그져 윗사람들과 이런저런 정책이나 세우고 문제가 생기면 아랫사람에게 ‘해결해놔’ 말 한마디면 되고… 아랫사람의 성과는 곧 나의 성과… 이렇게나 세상 편한게 어딧냐는 거다.
적어도 기술적인 열정과 문제해결을 위한 노력따위는 않해도 된다는 논리다.
다시 앞에 이야기를…
기업에서 원하는 인재상… 밝고 활동적이고 인간관계가 좋은 사람…. 그런 사람들은 하루 빨리 편한 생활을 위해 노력한 사람들이 대부분이란게 문제다.
그리고 그러한 인간들이 리더가 되면 어떻게 되나? 끼리끼리 논다라는 진리에 의해서 그들과 같은 부류의 인간유형을 유능한 인간으로 치부한다. 다시 말해서 그다지 밝지도 않고 활동적이지는 않지만 자신의 하는 일에 대해서 열정을 가지고 문제를 해결할려고 낑낑대는 인간을 ‘한심한 인간’ 으로 치부하는 거다.
야.. 언제까지 이러고 살거냐? 빨리 팀장 달고 해야지 ㅎㅎㅎㅎㅎ
내가 있는 곳도 여지 없이 그런 꼴이 되어가고 있다. 나는 현재 시스템을 주로 다룬다. 그런데 나와 같은 일을 하는 다른 시스템 엔지니어는 안타갑게도 능력이 없다. 자신의 직업에 대해 능력이 없는데도 그들이 지금까지 살아 남을 수 있었던 이유는?
회사의 이사와 매일 담배 피면서 어울리고 술을 마시고 이러다보니 살아남을 수 있었다. 하루는 이런 일이 있었다. 이사가 나를 불러 갔더니 나와 같은 나머지 두 사람(시스템 엔지니어)도 함께 있었다. 문제는 내가 담당하는 시스템은 아니였는데 그래도 시스템 엔지니어니까 문제 해결을 위해서 불렀다는 거다.
아주 간단한 문제였는데, 그걸 몰랐다는것에 처음 놀랐고 이사가 한 말이 나를 분노케 했다.
니가 애들보다 잘하니까 니가 처리줬으면 좋겠어..
밝고 활동적이고 인간관계가 좋은 인간들은 힘들고 고통스럽기까지 하는 자기분야의 문제해결을 위한 시간을 쏟지 않는다. 그런 인간들은 그러한 고통을 어떻게하면 회피할까 하는 궁리만 한다.
그러다보니 사람관리를 잘 해야한다. 자신이 못하는 일을 대신 처리해줄 호구를 잘 고르고 또 시켜먹어야 내가 편하니까… 그런데, 한국에서는 그런 인간유형을 ‘능력자’ 라고깢 치켜세우니 이 얼마나 기가막히는 일인가…
하루는 이사가 나를 부르더만, 잠깐 다른 프로젝트 할 수 있냐고 했다. 지금 급한 일이 생겨서 그걸 해줄 사람이 필요한데, 능력이야 니가 좋으니 니가 한 1년가서 해줬으면 한다는 거다. 출퇴근 거리만 2시간이고 막장으로 치닫는 프로젝트니 능력있는놈이 정리를 해야하니 내가 했으면 했단다….
밝지도 않고 그렇다고 인간관계가 넓지는 않지만 내가 하는 일에 열정을 다해 경력을 쌓기 희망하는 사람은 저런 병적인 인간에게 먹이감이 될뿐이다. 왜? 병적인 인간이 아니겠나… 남의 능력과 경력을 갈취해 자신의 삶을 편안하게 하는것이 과연 제대로된 인간 유형이라고 할 수 있나? 그걸 한국 사회에서는 ‘능력자’ 라고까지 하니… 미치광이 사회집단 그 이하도 아니다.
발표자들… 곱게는 안보인다.
요새 어떤 분야에서 기업들의 사례 발표를 많이 한다. 사례를 통해서 많은 것을 배울수 있는 기회라 자주 간다만, 갔다와서 한번씩 찾아보는 자료 하나가 있다. 발표자의 경력이다. 웃기게도 그 발표에 나타난 인간들이 ‘리더’ 라는게 놀랍다.
물론 그러한 아키텍쳐를 구축하고 적용하는데 리더의 역활도 중요하다. 하지만 그 큰 아키텍쳐를 그 발표자 혼자 다 이해한다고? 실무자는??
몇일이 자닌후에 뻔뻔하게도 경력에 ‘xxx 시스템 구축 책임’ 이라고 자랑스럽게 새겨넣는다. 이런 사람에게 기본 베이스부터해서 차근차근 따져 물어보면 제대로 답변하는 인간 못봤다.
아키텍쳐를 구축하는데 있어서 리더는 그야 말로 팀원들의 의견을 조율하고 필요한 자원을 제공하는데 있다. 어떤 프로젝트를 잘 관찰해보면 리더 빼고 그 프로젝트에 중심에 있는 사람들이 여럿있는데 이런 사람들이 핵심 인력이라고 봐야 한다. 잘 모르겠다면 일이 몰리는 사람이 핵심 인력이라고 보면된다.
그런데, 한국 사회는 그런 인력을 데리고 이래라 저래라 하는 인간들이 많다는게 문제라는 거다.
30대 초반에 사람들에게…
절대 열정을 가지고 일하지 말라… 그져 대충대충… 눈치보면서 살다가 ‘아.. 저 녀석과 친분을 맺으면 내 인생을 땡겨줄지도 몰라’ 하는 인간이 보이면 인맥을 잘 쌓아놔라…
뭔가 한 분야에게 소위 ‘덕후’가 되고자 한다고면 외국으로 탈출하라…. 적어도 거기에서는 한국의 정신병적인 인간유형이 당신의 리더가 될 가능성은 현저히 낮다.
올한해도… 저런 정신병적인 인간하고 힘겨루기…
나이가 먹어가면 갈수록 저런 인간들과 얼굴을 맞대야 하는 순간들이 많아진다는게 문제였다. 뭔가 모르는 옥죄오는 것들… 저런 인간들이 사방에 깔려 있다는게 문제다…
니네 인생 니네가 알아서 살아라… 인간관계 좋아? 술 처먹고 업무 조율하는게 능력이냐? 그래서 니들은 이사와 친분쌓아 능력좋은 사람에게 일 몰아주기 하는걸 능력으로 아는 모양인데… 올 한해 뚝배기 많이 깨줘야겠다고 다짐한다.
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 이 보인다.
Effective POM 에서 Maven 저장소 URL
XHTML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<repositories>
<repository>
<snapshots>
<enabled>false</enabled>
</snapshots>
<id>central</id>
<name>Central Repository</name>
<url>https://repo.maven.apache.org/maven2</url>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<releases>
<updatePolicy>never</updatePolicy>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
<id>central</id>
<name>Central Repository</name>
<url>https://repo.maven.apache.org/maven2</url>
</pluginRepository>
</pluginRepositories>
Maven 3 에서 기본 세팅된 저장소 URL 을 살펴 볼수 있다.
아니면 pom..xml 이 있는 프로젝트 디렉토리에서 다음과 같은 명령어로 Effective POM 상태를 출력해 볼 수 있다.
Maven CLI 명령어로 Maven
ZSH
1
mvn help:effective-pom
이제 기본적인 저장소 URL 을 알았으니 이것을 바꿔보자. pom.xml 탭을 클릭해 다음과 같이 바꿔보자.
Maven 저장소 URL 바꾸기
XHTML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<repositories>
<repository>
<releases>
<enabled>true</enabled>
</releases>
<id>central</id>
<url>http://repo.maven.apache.org/maven2</url>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<releases>
<enabled>true</enabled>
</releases>
<id>central</id>
<url>http://repo.maven.apache.org/maven2</url>
</pluginRepository>
</pluginRepositories>
이렇게 하면 Maven의 기본 저장소 URL을 변경이 된다.
Maven settings.xml 설정 파일에서 바꾸기
만일 프로젝트가 아주 많이 있다면 일일이 프로젝트마다 앞에 방법대로 pom.xml 을 수정한다는 것이 바보같은 짓이된다. 이럴때에는 Maven의 설정 파일인 settings.xml 에서 설정 해주면 된다.
다음과 같이 설정 해준다.
Maven 저장소 URL 변경을 위한 settings.xml 파일 설정
XHTML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<profiles>
<profile>
<id>myprofile</id>
<repositories>
<repository>
<releases>
<enabled>true</enabled>
</releases>
<id>central</id>
<url>http://repo.maven.apache.org/maven2</url>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<releases>
<enabled>true</enabled>
</releases>
<id>central</id>
<url>http://repo.maven.apache.org/maven2</url>
</pluginRepository>
</pluginRepositories>
</profile>
</profiles>
<activeProfiles>
<activeProfile>myprofile</activeProfile>
</activeProfiles>
이렇게 변경 후 저장하고 Eclipse 를 재시작하면 모든 프로젝트에 Effective POM 을 보면 저장소 위치가 변경된 것을 확인할 수 있다.
이렇게 한 후에 SystemVLabs-Static 에 빌드를 하면 WebContent 디렉토리에 내용들이 war로 만들어진다. 또, RootProject 에서 빌드를 하면 하위 모듈로등록된 SystemVLabs-Static 도 빌드가 되면 정상적으로 프로젝트가 세팅된 것이다.
하위 프로젝트 생성(Dynamic Content)
이제 Dynamic Content 를 위한 하위 모듈 프로젝트를 생성해야 한다. 이는 여러 방법이 존재하는데, 내가 보기에 가장 손쉬운 방법을 설명하고자 한다.
먼저 STS Eclipse 의 Spring MVC 샘플 프로젝트를 생성한다. 그러면 기존의 RootProject와는 별도로 프로젝트가 생길 것이다.
Spring5 샘플 프로젝트
이제 이것을 export 를 해주는데, File System 으로 export 를 한다.
Export를 File System 으로 한다.
대상 디렉토리는 RootProject 로 지정한다.
Spring5의 RootProject 로 Export
이렇게 한 후에 RootProject 를 ReFresh 하면 방금 Export 한 Spring5 디렉토리가 보인다.
이제 기존의 Spring5 프로젝트는 디스크에서 삭제도 체크해 삭제한다. 그리고 이제 프로젝트를 Import 한다.
Existing Project into Workspace
“Existing Projects into Workspace” 를 선책하고 Next,
Export된 Spring5 디렉토리 지정
이렇게 하면 RootProject 하위가 아닌 독립된 프로젝트로 나타난다.
마지막으로 RootProject 의 pom.xml 에 방금 등록한 하위 모듈 프로젝트로 등록해 준다.
RootProject의 pom.xml 에 모듈 추가
XHTML
1
2
3
4
<modules>
<module>SystemvLabs-Static</module>
<module>systemvLabs-Web</module>
</modules>
그리고 새로 등록한 하위 모듈 프로젝트의 pom.xml 에는 parent 모듈을 등록해 준다.
parent 프로젝트 등록
XHTML
1
2
3
4
5
6
<parent>
<groupId>io.systemv</groupId>
<artifactId>RootProject</artifactId>
<version>0.0.1-SNAPSHOT</version>
<relativePath>../pom.xml</relativePath>
</parent>
이렇게 함으로써 Dynamic Content 를 하위 모듈 프로젝트 등록은 다 된 것이다.
만일 WAS 서버를 Tomcat 을 이용해 개발을 하고 있다면 Maven tomcat7 플러그인을 이용해서 배포를 할 수 있다. 참고로 이클립스의 tomcat add-on 과는 다른 것이다. 이것은 Tomcat 에서 제공하는 Manager 기능을 이용한 것이다.
그리고 이 문서의 내용은 Tomcat 8 버전에서도 이용 가능 하다.
Tomcat 설정
Tomcat 의 Manager 기능을 이용하는 것이여서 Tomcat Manager 설정을 먼저 해줘야 한다. 아시겠지만 Manager 접근을 위해서는 인증 설정을 해줘야 하는데 이 인증은 Tomcat 의 ㅊCATALINA_HOME/conf/tomcat-users.xml 파일을 다음과 같이 설정 해준다.
앞서 설정을 한다고 해도 원격에서 Manager 접속은 불가능 하다. 왜냐하면 Tomcat 자체에 Manager 접속을 로컬호스트만 허용하도록 되어 있기 때문이다. 이것은 “CATALINA_HOME/webapps/manager/META-INF/context.xml” 파일에 설정되어 있다.
