남산 아래 개발자들

AWS 인프라 운영 중 기존에 생성한 Instance와 유사한 인스턴스를 추가로 생성하려고 하는 경우기존에는 AMI (이미지) 백업을 통한 Instance 생성작업을 사용했습니다. 하지만 지난 11월 부터   AWS 에서 추가로 Template 기반의 인스턴스 생성 기능을 지원하고 있습니다. Template 기능을 활용하면 AMI Image VPC Subnet Storage Security Group UserData 등의 정보를 Template 으로 관리하여 인스턴스를 생성 할 수 있게 됩니다. 이렇게 Template 기능을 활용하면 인프라 구성에서 설정적용에 소요되는 시간을 절약할 수 있습니다. Template 기는 사용을 위해 EC2 대시보니 – 인스턴스 – Launch Template s   메뉴로 이동합니다. Create Launch template 버튼을 클릭합니다. Template  이름과 버전을 선택 할 수 있습니다. Source Template 을 사용하면 기존의 Template 구성을 수정하여 사용할 수 있습니다. AMI ID , Instance Type , Key Pair 를 선택 할 수 있으며 입력하지 않으면 Template 에 포함하지 않습니다. 네트워크 인터페이스 추가 및 Storage 추가 Security Group 을 설정할 수 있습니다 Advanced details 항목에서 IAM Role , 종료방법, User Data 등 상세설정이 가능하며 마찬가지로 입력하지 않으면 미반영 상태로 저장 됩니다.   Create Launch Template 버튼을 선택하면 아래와 같이 탬플릿 생성완료 메시지가 표출됩니다. Close 를 선택하여 종료합니다. 탬플릿이 생성되었습니다. 테스트를 위해 Template 선택 후 작업  - Launch instance from template 을 선택합니다. Template

지난 포스팅을 통해서 Intel CPU 보안 취약점 발견에 따른 OS 별 대처방법에 대해 살펴보았습니다. 지난포스팅 보러가기 오늘은 AWS 에서 사용중인 Ubuntu 서버의 보안취약점 대응을 위한 Patch 작업을 진행해 보도록 하겠습니다. 우선 현재 운영중인 Ubuntu 섭서의 Kernel 버전을 확인해 보겠습니다. Krenel 버전 확인을 위해 명령어를 입력합니다. 1 $  uname –r  cs 다음은 패키지 정보 리스트를 최신으로 업데이트 합니다. 1 $ sudo apt-get update cs 다음은 패키지 관리자 리스트에서 리눅스 커널의 이미지 버전을 검색합니다. 1 $ apt-cache search linux-image cs AWS 환경에서 운영되은 Instance 이므로 AWS 용 Lunux 커널을 사용해야합니다. linux-aws - Amazon Web Services (AWS) 시스템 용 Linux 커널 linux-euclid - Intel Euclid 시스템 용 Linux 커널 AWS 시스템용 Linux 커널 중 최신 버전인  1049 버전을 사용해서 업데이트를 진행하도록 하겠습니다. 1 $ sudo apt-get install linux-image-4.4.0-1049-aws cs 업데이트 작업 시도중 위와 같이 에러가 발생한다면 아래와 같이 명령어를실행한 이후 다시 업데이트 작업을 진행 합니다. 1 $ sudo apt-get –f install cs 작업 진행 중 추가 디스크 용량이 필요하다는 메시지가 출력됩니다. “Y” 를 입력합니다. 다시 커널 업데이트 작업를 진행 합니다. 작업이 완료후 서버를  재부팅  하면 최신 커널 버전으로 업데이트 되는것 을 확인할 수 있습니다.

안녕하세요. 남산돈가스입니다. 오늘은 AWS의 API Gateway에서 연결 된 API들의 API키 발급을 통한 요청 제한, 그리고 사용량 계획을 통한 사용량 조절을 알아보겠습니다. 네이버클라우드에서 제공하는 SENS를 통해서 문자 발송서비스를 OPEN API로 요청하는 법을 지난 포스팅에서 다루어 보았습니다. 문자발송서비스를 앞으로 다양한 사용자에게 제공한다고 가정해보았을 때, 각각의 사용자들의 모두 컨트롤하기 어려운 상황에 놓이기 마련입니다. 그런 경우에 대비하여 API Gateway는 연결해놓은 API에 한하여 사용자들에게 API Key를 관리하여 요청 권한을 제공하고, 사용량 계획을 이용하여 일,월 요청 수 또는 n초 당 m개의 요청 수를 제한하는 기능을 제공하고있습니다. 이 두가지의 기능만을 이용한다면, 다양한 사용자에 대한 API 관리가 용이해질 수 있습니다. 그럼, 차근차근 하나씩 설정을 해보도록하겠습니다. 먼저 API Gateway 콘솔 화면에서 좌측 사용량 계획탭을 선택합니다. 사용량 계획에 대한 이름과 설명을 입력한 뒤, 중간의 조절 부분을 보시면 요율과 버스트를 설정할 수 있습니다. 요율을 n초당 요청 수를 설정하는 곳이고, 버스트는 해당 n초에 대해서 m번의 요청을 가능도록 하는 지 설정하는 부분입니다. 조절부분의 설정을 마치셨다면, 하단의 할당량에서 일,주,월 당 n개의 요청건수를 허용하는 양을 설정합니다. 사용량 계획 설정을 마치고 다음을 선택하면, 연결 된 API 스테이지를 설정하는 화면입니다. 앞에서 설정한 사용량 계획을 어떤 API에 적용할 지 설정하는 부분입니다. 저는 nCloud_SENS API의 dev스테이지에 사용량을 설정했습니다. 다음 화면은 사용량 계획 API 키를 발급하는 화면입니다. 'API 키 생성 후 사용량 계획에 추가' 버튼을 선택합니다. API 키 생성 팝업에서 저는 남산돈가스(사용자)의 API 키를 발급했습니다. 다음과 같이

지난 포스팅에서 Certification Manager 를 통한  SSL 적용방법에 대해 다룬적이 있습니다. 지난포스팅 보러가기 SSL 인증서를 발급받기 위해서는 이메일 인증을 통해  사용중인 도메인 소유자 임을 인증해야 합니다. 얼마 전부터 AWS 에서 DNS 검증을 통한  도메인 소유자 인증을 지원하기 시작 했습니다. 도메인 계정 관리자와 서비스 관리자가 따로 있다면 매번 도메인 소유자 인증때 마다 계정 관리자에게 확인을 하거나 고객사에 연락하여 확인을 요청하는 방법밖에 없었지만 더이상 이런 번거로운 작업이 필요 없어 졌습니다. 아래와 같은 방법으로 도메인 인증을 진행합니다. 1. SSL 인증서 요청 인증서 요청 페이지 에서 사용하고자 하는 도메인 이름 입력 후 다음을 선택 합니다. 2. 검증 방법선택 검증방법에 DNS 검증이 추가 되었습니다. DNS 검증을 선택하고 다음을 선택합니다. 3단계: 검토 및 요청에서 내용을 확인후 다시 다음 단계로 넘어 갑니다. 3. 검증 도메인이 검증 대기 상태로 등록 됩니다. DNS 에 CNAME 항목에 입력할  이름 / 값  정보가 노출 됩니다. 도메인 사이트로 이동하여 DNS 설정 메뉴에서 해당 값을 입력해주면 되지만 Route53을 사용하고 있다면 “Route 53 에서 레코드생성” 버튼을 선택하면 됩니다. 클릭해 보겠습니다. 생성 버튼을 클릭하면 Route 53 을 통해 자동으로 CNAME 이 등록됩니다. 도메인 등록 성공 메시지가 표출 됩니다. 변경사항 전파에 30분이 소유 된다고 하니 계속을 선택하고 기다립니다. 기다리는 동안 Route 53 메뉴로 이동해서 확인해 보면 CNAME 이 등록된 것을 확인해 볼 수 있습니다. 다시 인증서 요청 화면으로 이동합니다. 변경사항 전파가 완료되면 도메인 검증이 완료되고 인증서가 정상적으로 발급되었다는 메시지

AWS 계정 생성후 12개월 동안 주어지는 Free-tier 사용을 위하여 T2.micro 인스턴스를 생성하게 됩니다. 일반적으로 많이 사용되고 있는 T2 계열 인스턴스의 가장 큰 특징은 CPU 크레딧 입니다. T2 인스턴스는 실행되는 동안 CPU 크레딧을 누적하고 최대 성능을 필요로 할때 누적 되어있던 크레딧을 사용(CPU 버스팅)하는 구조입니다. 이런 구조적 제약으로 인하여 누적된 크레딧을 모두 소진한 경우에는 CPU 성능에 제한이 적용되게 됩니다. *CPU 크레딧 CPU 크레딧 하나는 1분 동안 100%의 사용률로 실행되는 vCPU 하나에 해당합니다. vCPU, 사용률 및 시간의 여러 가지 조합이 CPU 크레딧 하나에 해당합니다. 예를 들어, vCPU 하나가 2분 동안 50%의 사용률로 실행되거나, vCPU 2개가 2분 동안 25%의 사용률로 실행될 수 있습니다. CPU 를 지속적으로 많이 사용하지 않는 서비스의 경우 많이 사용되지만 갑작스런 사용량의 증가가 있을 경우 언제 CPU 성능제한이 일어날지 모르기에 실제 운영중인 서비스는 어쩔수 없이 M4 계열을 이용하는 경우가 많습니다. 이런 제약조건에도 불구하고 T2 인스턴스의 인기가 매우 높기에 지난주 AWS에서 T2 인스턴스를 위한 신규 기능을 추가로 발표 했습니다. 바로 T2 무제한 (Unlimited) 기능 입니다. AWS 공식 블로그에 나와 있는 T2 무제한 기능의 설명입니다. *T2 무제한 기능 T2에서 제공하는 버스트 모델을 확장하여, 이제 최대한 낮은 비용으로 원하는 기간 동안 높은 CPU 성능을 유지할 수 있는 기능을 추가합니다. 사용하시려면 인스턴스를 시작할 때, 이 기능을 활성화하면 되고, 이미 실행 중인 인스턴스에 대해 이 기능을 활성화할 수도 있습니다. 24시간 동안 평균 CPU 사용률이 기준선보다 낮을 경우, 중간에 급증하는 모든 사용량이 시간당 T2 인스턴스 가격에 포함됩니다. 인스턴스가 장기간에 걸쳐 높은 CPU 사용률로 실행될 경우 소액의

지난 포스팅을 통해 AWS 통합계정 설정을 통한 계정관리 및 비용할인에 대해 알아보았습니다. 통합결제계정을 사용하는 경우 통합할인에 매우 유용하지만 Credit 을 사용하거나 예약인스턴스(RI) 를 사용하고 있는 경우에 계정별 사용비용 계산이 복잡해 지는 문제가 발생 합니다. 이는 AWS 에서  고객할인을 최대한 많이 보장하고자 통합계정을 사용하고 있는 경우 예약인스터스(RI) 요금에 대해서 자동으로  혼합(Blended) 요금을 적용하기 때문입니다. 아래는 혼합요금에 대한 AWS 설명 입니다. http://docs.aws.amazon.com/ko_kr/awsaccountbilling/latest/aboutv2/con-bill-blended-rates.html#Blended_Calculated 간단하게 Blended 요금에 대해 알아 보면 아래는 t2.micro 에 대한 요금 기준 입니다. 온디맨드 는  $0.0144 표준 1년계약 (선수금 없음) 은  $0.009 입니다 아래 그림과 같이 통합으로 연결되어 있는 계정 중 하나의 계정에서만 RI 를 적용한다고 가정해 보겠습니다. 위의 그림으로 보면 Nmadopass 계정은 $0.0144 , Fico2000 계정은 $0.009 가 시간당 청구 되어야 합니다. 그런데 실제 청구서를 보면 (0.0144 + 0.009) / 2 = 0.0117 과 같이 Namdopass $ 0.0117 (Blended price*) fico2000 $ 0.0117 (Blended price*) 로 표출되는 것을 확인 할 수 있습니다. 아래 그림은 실제 청구서에 Blended 금액이 표시된 화면 입니다. 예약인스턴스가 혼합 요금으로 적용된 것을 확인 할 수 있습니다. 이렇게 복잡한 비용관리를 간소화 하고자 AWS 에서 최근 계정간 RI 공유 비활성화 기능을 지원하기 시작 했습니다. 설정을 위해서 마스터 결제 계정 콘솔로 로그인 합니다. 결제 대시

안녕하세요. 남산돈가스입니다. AWS Lambda - API Gateway로 S3 파일 업로드 API 만들기 #1 , #2 에 이어 마지막 시간인 API Gateway - Lambda 연결 및 테스트가 남았습니다. 지난 포스팅까지 Lambda를 이용해 업로드 함수를 생성했고, API Gateway와 S3 기본설정을 통해 S3 파일 업로드 기능의 기본설정을 마무리했습니다. 오늘은 이 두 설정들을 연결하여 최종적으로 S3 업로드 Micro Service를 완성하겠습니다. 먼저 지난 포스팅에서 API Gateway를 생성했고, uploader라는 리소스까지 생성했습니다. 이번엔 이 uploader라는 리소스에 POST 매서드를 추가하고 작성했던 Lambda Function을 설정합니다. 통합 유형 - Lambda 함수 Lambda 리전 - 'Lambda함수를 생성한 리전' Lambda 함수 - '작성한 Lambda 함수명(리전 선택 시 자동완성으로 검색 가능)' 위와 같이 설정한 뒤 저장을 선택합니다. 저장을 선택 시 다음과 같이 uploader라는 리소스 밑에 post 매서드가 생성 된 것을 확인하실 수 있습니다. 다음으로, 우측 상단의 통합 요청을 선택하시면 아래와 같은 화면이 나옵니다. 그 중에서 하단의 본문 매핑 템플릿을 선택합니다. 요청 본문 패스스루에서 '정의된 템플릿이 없는 경우'를 체크하고 Content-Type에 매핑 템플릿 추가하여 multipart/form-data  을 추가하고 '템플릿 생성'에서 매서드 요청 패스스루를 클릭하시고 아래와 같은 패스스루가 나온 것을 확인하셨으면 저장을 누릅니다. 여기까지 설정을 완료하셨다면, API Gateway와 Lambda Function의 연결이 모두 완료 된 것입니다. 이제 실제 이 API Gateway를 배포하여 엔드포인트를 발급받고 실제 업로드가 되는지

안녕하세요. 남산돈가스입니다.  이번 포스팅에서는 웹을 개발하면서 가장 골칫거리지만 자주 쓰이게 될 수 있는 파일 업로드 기능 구현에 대해서 포스팅하려고합니다.  하지만 일반적인 파일업로드가 아닌, Lambda로 S3에 파일을 업로드 시키는 함수를 생성하고, 해당 Lambda함수를 API Gateway에 연결하여 multipart-form 형식으로 파일을 업로드하는 Serverless 파일업로드를 구현할 예정입니다.  이런 방식으로 업로드기능을 구현하게 되면, 추후에 어디든지 파일업로드 기능을 쓸 수 있는 Micro Service가 될 수 있습니다. 포스팅은 다음과 같이 3회에 걸쳐 진행되겠습니다. #1. Lambda 함수 생성 #2. API Gateway, S3 셋팅 #3. API Gateway - Lambda 연결 및 테스트 그렇다면 지금부터 그 첫번째 단계인 Lambda 함수 생성을 진행해보겠습니다. 먼저 Lambda 서비스에 접속한 뒤 Node.js 기반의 새로운 함수를 생성합니다. 함수를 생성하면 아래와 같이 트리거가 추가되지 않은 날것의 함수가 생성된 것을 확인하실 수 있습니다.  쥐도 새도 모르게 변하는 AWS 콘솔 덕분에(?) 매번 포스팅할 때마다 Lambdad의 콘솔화면이 다채롭게  변하고있네요...ㅎㅎ 기존의 포스팅에서는 위 사진처럼 인라인으로 편집하는 포스팅만 진행했었는데 금번 포스팅에서는 외부 node_module을 사용하는 경우라 로컬에서 작업한 소스를 ZIP파일 형식으로 업로드하여 함수를 생성해보겠습니다. 로컬 터미널에서 upload라는 폴더를 생성하고 index.js을 생성합니다. index.js 그리고 해당 함수에 필요한 node_module을 install 하기 위해서 npm install 명령어를 사용합니다. 필요 모듈 aws-sdk : AWS javascript sdk 모듈 parse-multipart : multipart형식으로