글쓴이 보관물: seapy

Xcode 에서 Pod 프로젝트의 경고 표시 없애기

Xcode를 이용해 개발을 하다보면 cocoapod를 이용해 외부 라이브러리를 사용하게 되는데요. Swift 언어가 계속해서 발전하다보니 새로운 버전에서 deprecated 되는것들이 많아져서 1년만 지나도 꽤 많은수의 경고문구를 보게 됩니다. 내 프로젝트의 경우 소스코드를 직접 수정하면 되지만 외부 라이브러리들은 해당 프로젝트의 상황에 따라서 경고되는 항목들을 고치지 못하는 경우가 많습니다.

이렇게 되면 어느순간부터 내 프로젝트의 빌드 경고창에는 외부 라이브러리들의 경고가 많아져서 내 프로젝트의 경고가 묻히고 수정해야 된다는 사실을 인지하지 못하게됩니다.

위의 경우 총 58개의 경고가 있는데 이중 56개는 외부 라이브러리들의 경고표시입니다. 내 프로젝트의 경고표시는 제일 아래쪽에 2개가 위치합니다. 또한 경고문구는 기본으로 펼쳐져 있어서 스크롤을 아래까지 해야 겨우 볼 수 있습니다. 프로젝트가 커져서 사용하는 외부 라이브러리가 많아지면 경고는 300개를 넘는경우도 있습니다.

다행히도 이 문제를 해결할 방법이 있습니다. cocoapod의 경우 Podfile에 아래 내용을 추가해서 Pod 프로젝트들에 대해 경고가 표시되지 않도록 설정 할 수 있습니다.

inhibit_all_warnings!

전체 Podfile 의 샘플을 보면 다음과 같은 식입니다.

platform :ios, '9.0'
target 'MyProject' do
  use_frameworks!
  inhibit_all_warnings!
  pod 'Alamofire', '~> 4.5'
end

전체 Pod이 아닌 특정 Pod의 경고만 표시하지 않으려면 pod 선언할때 옵션으로 선언합니다.

pod 'Alamofire', '~> 4.5', :inhibit_warnings => true

Podfile 을 수정하고 pod install 을 다시 실행한후 Xcode 프로젝트에서 빌드를 다시하거나 클린빌드를 하면 기존에 보이던 Pod 프로젝트의 경고표시가 모두 사라진것을 볼 수 있습니다.

이 옵션은 pod init 으로 Podfile을 처음 생성할때 기본으로 들어가면 좋을것 같은데 기본 옵션은 아닙니다.

유튜브

달구지 코딩이라는 유튜브 채널을 만들어서 운영중입니다. 이 포스트 내용은 아래 유튜브 영상에서도 확인할 수 있습니다. 유튜브 구독 부탁드려요 ^^

참고자료

게시글의 아마존, iTunes 링크들을 통해 구매를 하시면 제휴(Affiliate) 프로그램에 의해 저에게 일정 금액이 적립될 수 있습니다. ^_____^

.bot 도메인 등록하기

Amazon에서 .bot 도메인을 등록할 수 있도록 해서 등록 방법을 소개하려고 합니다.

.bot 도메인 등록을 대행하는 EnCirca 사이트의 설명을 보면 현재는 Landrush 2 기간으로 .bot 도메인 등록을 아무나 할 수 없고 봇을 운영중인지 확인후 등록할 수 있는 권한을 주는것으로 보입니다. 봇을 운영중인지 확인하는 것은 Amazon Lex, Microsoft Bot Framework, Dialogflow, Pandorabots, Gupshup, Botkit Studio 등 봇 관련 서비스들과의 연동을 통해서만 가능합니다.

아마도 2018년 5월 31일 이후에는 봇을 운영중인지 확인작업 없이 일반 도메인 처럼 등록되지 않을까 싶은데 확실한 정보는 아닙니다.

절차가 좀 길고 복잡한데 영상으로도 촬영 했으니 참고하세요.

.bot 도메인 등록을 위해서 우선 amazon registry 사이트에 접속합니다.

접속후 검색창에 구매하고자 하는 도메인 이름을 입력하고 다음 절차로 이동합니다.

아마존 계정에 로그인 되어 있지 않다면 다음 화면으로 넘어가기전에 아마존 로그인이 필요합니다.

봇을 운영중인지 확인하는 작업이 필요합니다. 목록에 나온 서비스중 본인이 운영중인 봇 서비스를 선택하면 확인작업에 대한 절차가 설명됩니다. 봇을 현재 운영하고 있지 않다고 가정하고 Amazon Lex를 이용해 봇을 생성하고 인증하는 절차를 설명하겠습니다.

Amazon Lex를 선택하면 오른쪽에 봇을 확인하기위해 필요한 절차가 표시됩니다.

준비 작업

아마존 웹서비스 계정에 로그인해서 Cross Account Role을 생성하고 545643940769 계정에 대해 권한을 추가하는 작업이 필요합니다. 그럼 이제부터 Role 을 생성해보겠습니다.

AWS 콘솔에 로그인후 IAM 메뉴에서 Roles 선택하고 Create Role 버튼을 클릭합니다.

Account ID와 External ID 항목에 앞선 .bot 도메인 등록 사이트에서 알려준 정보를 입력합니다.

다음 화면에서는 Role에 부여할 Policy 를 선택해야 되는데요. AmazonLexReadOnly를 선택합니다.

Role 이름은 나중에 알 수 있도록 적당히 잘 정하고 설명에도 잘 적어둡니다. 여기까지는 공식사이트에서 설명하는 절차인데요. 제가 해보니 여기서 한가지가 더 필요합니다.

IAM 콘솔에서 Policies 를 선택하고 Create Policy 버튼을 클립합니다.

JSON 탭을 선택하고 아래 내용을 추가합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "lex:PostText"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

Policy 를 생성했다면 앞서 생성했던 Role을 선택하고 Attach policy 버튼을 클릭해서 방금 생성한 Policy를 추가합니다.

최종적으로 위와 같은 Role을 얻게 됩니다. 이제 .bot 도메인 등록 사이트로 돌아갑니다.

임시로 Lex 봇 만들기

Amazon에서 제공하는 봇 서비스를 이용해 임시로 봇을 생성하겠습니다.

AWS 콘솔에서 Lex 페이지에 접속해서 새로운 Lex 봇을 생성합니다. Lex 봇을 처음 생성한다면 아마 첫화면에 Get Started 버튼이 보일텐데 해당 버튼을 클릭합니다.

봇 생성을 위한 페이지가 표시되는데 아마존이 제공하는 기본 샘플을 이용하면 코딩을 하지 않아도 됩니다. Try a sample 에서 BookTrip을 선택하고 하단의 COPPA 항목은 No로 선택합니다.

봇 페이지에서 오른쪽 위의 Publish 버튼을 클릭합니다.

alias 는 아무이름이나 입력하고 publish 버튼을 클릭합니다. 배포하는데 1분정도 시간이 걸리니 잠깐 쉬다 오세요.

배포가 완료되면 위와 같이 표시되는데요. 여기서 Bot Name과 Alias를 적어두세요.

도메인 등록하기

이제 준비 작업은 모두 끝났습니다. .bot 도메인 등록 사이트로 가서 아까 보였던 봇 확인 작업창에 앞서 준비했던 내용들을 입력합니다.

AWS cross account role ARN 항목에는 앞서 생성했던 Role의 Role ARN을 입력합니다.

봇 인증이 성공했습니다! 저 같은 경우 이미 해당 도메인에 대해 봇 인증이 되있는 상태라 메시지가 조금 다르게 나왔지만 페이지는 동일합니다.

Continue to registration 버튼을 클릭하면 도메인 등록을 위한 페이지로 이동합니다.

가격이 $75 네요!! Site Builder 옵션은 선택하지 않아도 도메인 등록하는데 문제 없습니다.

실제 도메인 등록은 EnRica 사이트를 이용해서 진행되기 때문에 해당 사이트 가입을 위한 주소 정보를 선택하라고 나올텐데요. 기존 아마존 계정에 있는것을 선택하거나 새로 입력해서 다음 단게로 넘어갑니다.

다음 화면에서는 EnRica 사이트 가입 절차가 나옵니다.

저도 여기 까지만 해봤고 더이상은 진행하지 않았습니다. 하지만 이 다음부터는 일반적인 도메인 등록 절차와 동일할테니 쉽게 할 수 있을겁니다.

정리

아마존에 .bot 도메인을 등록할 수 있게 한다고 해서 호기심에 내 아이디를 선점 해볼까라는 생각이었는데 생각보다 절차가 복잡했고 가격도 $75로 비싼편입니다.

.bot 도메인에 대한 확인 작업은 아마도 2018년 5월 31일 이후에는 없어질것으로 보여서 이 글이 큰 도움이 되지 않을수도 있지만 미리 선점하려는 분들에게 도움이 되었으면합니다.

마지막으로 제가 운영중인 개발관련 유튜브 채널인 달구지코딩 구독 부탁드립니다 ~ AWS 서비스를 포함한 다양한 소프트웨어 개발관련 내용을 업로드 하고 있습니다.

참고자료

게시글의 아마존, iTunes 링크들을 통해 구매를 하시면 제휴(Affiliate) 프로그램에 의해 저에게 일정 금액이 적립될 수 있습니다. ^_____^

Slack 프록시 서버 – slackboard 소개

슬랙(Slack)을 자주 사용하다 보면 여러가지 연동을 하게 됩니다. 서버나 특정 상태에 따라 슬랙에 메시지를 보내는데요. 연동도 쉬워서 사용 할수록 더 많은 연동을 하게 됩니다.

이번에 소개하려는 slackboard는 슬랙에 메시지를 전송할때 아쉬운 부분을 해결해주는 기능을 가지고 있습니다. slackboard의 주요기능은 다음과 같습니다.

  • 커맨드 라인에서 쉽게 메시지 전송
  • 쉘 스크립트가 비정상적으로 종료됬을때 슬랙 메시지 전송
  • 태그 이름만으로 미리 지정한 채널이름, 사용자 이름, 이모지 설정
  • QPS 제어 기능

이중 slackboard를 꼭 써야하는 이유중 하나는 마지막의 QPS 제어 기능입니다. 일반적으로 사용하는 슬랙의 Incoming webhooks의 경우 초당 1건의 메시지로 제한되어 있어서 1초에 메시지를 여러개 전송하면 일부 메시지가 유실될 수 있는데 slackboard의 QPS 제어 기능을 이용하면 메시지가 유실되지 않게 분산해서 전송합니다.

유튜브 영상으로도 촬영 했으니 참고하세요.

그외 장점 및 사용헤 대해서도 하나씩 알아 보기 전에 설치 방법을 알아 보겠습니다.

서버 설치

slackboard는 프록시 서버를 설치해야 하는데요. golang으로 작성되어 있어 사전에 go 언어를 빌드 할 수 있도록 준비해야합니다. go 언어가 설치 됬다면 아래 명령어로 slackboard 를 설치합니다.

$ go get -u github.com/cubicdaiya/slackboard/...

프록시 서버 설정을 위해 환경설정 파일(config.toml)을 생성하고 수정합니다.

[core]
port = "60000"
slack_url = "https://hooks.slack.com/services/XXX/YYY"
qps = 1
max_delay_duration = 5

[log]
access_log = "stdout"
error_log = "stderr"
level = "error"

[[tags]]
tag = "dalguji"
channel = "#general"
username = "seapy"
icon_emoji = ":smile:"
parse = "full"

[[tags]]
tag = "fail"
channel = "#dalguji"
username = "seapy"
icon_emoji = ":warning:"
parse = "full"

slack_url에는 본인의 슬랙 설정에서 얻은 Incoming webhooks 주소를 입력합니다.

[[tag]] 로 시작하는 섹션은 태그를 지정하는 것으로 해당 태그 이름으로 요청이 들어오면 미리 지정된 채널이름, 사용자 이름, 사용자 이모지, 파싱모드를 적용하는것입니다. 태그를 지정해두면 메시지를 보낼때마다 채널과 사용자 이름등을 전달하지 않아도 됩니다.

서버 시작 및 기본 예제 테스트

slackboard 서버 시작 명령어는 다음과 같습니다. 간단하죠

$ slackboard -c config.toml &

실제 운영시에는 systemd 같은 서비스에 등록해두고 사용하면 좋습니다.

테스트 메시지를 보내기 위해 아래 명령어를 사용합니다.

$ echo 'Hi dalguji coding' | slackboard-cli -t dalguji -s localhost:60000

echo 명령어를 이용해 stdout 으로 메시지를 전송했고 slackboard-cli 명령어는 stdout으로 받은 메시지를 dalguji 태그와 함께 localhost:60000 서버로 전송합니다.

메시지를 전송하기만 하는 클라이언트 입장에서는 슬랙의 Incoming webhooks 주소를 이용해 curl 로 보낼수도 있지만 slackboard 설치하고 서버 주소만 알면 간단하게 전송 할 수 있게됩니다.

커맨드가 정상적으로 종료되지 않을 경우 알림

제가 slackboard를 사용하는 이유중 하나인 명령어가 비정상적으로 종료 되었을때 슬랙으로 에러 메시지를 알려주는 기능을 살펴 보겠습니다.

아래 명령어를 실행하면 some-command라는 명령어를 알 수 없다고 하면서 에러가 발생할겁니다.

$ slackboard-log -s localhost:60000 -t fail -- some-command

하지만 에러가 발생하면 localhost:60000 서버의 fail 태그로 어떤 이유로 명령어가 실패 했는지 전송하고 프록시 서버는 이를 슬랙으로 전송합니다.

저는 주로 쉘 스크립트를 정기적으로 실행하는데 실패하면 알림을 받고 싶을때 사용하는데요. 우선 아래와 같은 쉘 스크립트 파일(dalguji.sh)을 하나 만들어 둡니다.

#!/bin/sh
echo "dalguji script"

에러가 발생하지 않을 정상 스크립트 입니다. 이 스크립트가 정상 실행되는지 보겠습니다.

$ slackboard-log -s localhost:60000 -t fail -- dalguji.sh

정상 실행될때는 슬랙에 메시지도 안오고 그냥 echo 만 실행됩니다. 스크립트를 조금 변경해서 에러가 발생하도록 해보겠습니다.

#!/bin/sh
eeeeecho dalguji script

$ slackboard-log -s localhost:60000 -t fail -- dalguji.sh

다시 실행해보면 에러가 발생하고 에러 내역이 슬랙에 표시됩니다.

이러한 작업은 쉘 스크립트만으로도 할 수 있겠지만 이를 구현하려면 내가 만든 쉘 스크립트나 명령어를 감싸서 실패를 체크하고 슬랙으로 전송하는 스크립트를 직접 만들어야 됩니다. 하지만 slackboard는 간단한 설치와 설정으로 쉽게 사용할 수 있습니다.

성공했을때도 보내고… 실패 했을때도 보내고 싶다면?

마지막으로 쉘 스크립트가 성공이나 실패 했을때 모두 결과를 slack으로 전송하고 싶다면 아래와 같은 방법을 사용합니다.

$ dalguji.sh 2>&1 | slackboard-cli -s localhost:60000 -c dalguji

스크립트 실행중 발생한 stderr 출력을 stdout으로 리다이렉트 하고 해당 메시지를 슬랙으로 전송하는 방법입니다.

참고자료

게시글의 아마존, iTunes 링크들을 통해 구매를 하시면 제휴(Affiliate) 프로그램에 의해 저에게 일정 금액이 적립될 수 있습니다. ^_____^

Amazon CloudWatch 수집된 지표에 수식계산 Metric Math

아마존 웹서비스를 사용하다보면 사용중인 서비스를 모니터링 하기 위해 CloudWatch 를 한번씩은 사용하게 됩니다. 많은 지표들이 제공되지만 제공되는 지표에 몇가지 더하거나 조합하는 경우 이번에 소개하는 Metric Math 를 이용합니다.

RDS Total IOPS 수치 확인하기

RDS의 모니터링을 예로 들어보면 Read IOPS, Write IOPS라는 지표를 별도로 제공하는데 RDS의 IOPS 제한은 Read와 Write IOPS를 더한값으로 적용됩니다. 그래서 Total IOPS를 알고 있는것이 중요한데 CloudWatch 에서는 Total IOPS를 지표 정보로 제공하지 않습니다.

저 같은 경우 기존에는 Total IOPS를 모니터링 하기 위해 1분마다 Read IOPS와 Write IOPS를 조회하고 다시 Total IOPS라는 새로운 지표로 CloudWatch에 저장하는 작업을 하고 있었습니다. 하지만 Metric Math 기능을 이용하면 더이상 이렇게 할 필요가 없습니다.

CloudWatch 대시보드 혹은 Metrics 에서 RDS 를 선택하고 Read IOPS, Write IOPS를 각자 설정후 Graphed metrics 탭을 선택하고 테이블 상단의 Add a math express 버튼을 클릭합니다.

클릭하면 테이블 목록 상단에 e1 이라는 id를 가진 행이 추가되고 Details에는 SUM(METRICS()) 라고 입력됩니다. 이 수식의 의미는 현재 선택된 지표들을 모두 더한다는 의미입니다. 이 경우 Read IOPS + Write IOPS 인거죠. 수식을 이해하기 쉽게 m1 + m2로 변경해도 동일한 의미가 됩니다. 여기서 m1, m2는 각 행의 id 값입니다.

Total IOPS만 그래프에 표시하기 위해 체크 박스에서 e1 을 제외한 m1, m2는 체크를 해제하면 위와 같이 Total IOPS만 그래프에 표시되는것을 확인할 수 있습니다.

ElastiCache Hit Rate 계산 하기

ElastiCache 의 Hit Rate를 계산하는 것도 Metric Math를 이용하면 유용한 수치입니다. 캐시가 적당하게 잘 되고 있는지 볼 수 있는 유용한 지표가 Hit Rate인데 CloudWatch에서는 제공되지 않습니다.

이제 직접 Hit Rate를 계산해 보겠습니다.

Metrics 에서 모니터링을 원하는 ElastiCache 인스턴스의 Get Hits, Get Misses를 선택하고 앞서 했던 것처럼 Add a math express 버튼을 클릭합니다. 수식 입력란에 (m1 / (m1 + m2)) * 100를 입력하고 m1, m2의 그래프 체크박스를 해제하면 Hit Rate를 볼 수 있습니다.

정리

CloudWatch는 AWS 서비스를 이용하다 보면 한번쯤 접하게 되고 모니터링이나 알림 용도로 자주 사용하게 됩니다. 하지만 제공하지 않는 지표가 있거나 여러 지표를 조합하고자 하는 경우 불편한점이 있었는데 Metric Math 기능으로 인해 사용하기 편해졌습니다.

아쉽게도 현재는 수식이 적용된 지표에 대해서는 알림 기능을 제공하지 않습니다. 알림을 받고 싶다면 기존 방식처럼 별도의 CloudWatch 지표를 매분 마다 생성해야합니다.

이 내용은 제가 운영하는 유튜브 채널인 달구지코딩에서도 확인할 수 있습니다. 구독과 좋아요 부탁드립니다 ^^

참고자료

게시글의 아마존, iTunes 링크들을 통해 구매를 하시면 제휴(Affiliate) 프로그램에 의해 저에게 일정 금액이 적립될 수 있습니다. ^_____^

Capistrano 배포시 HostKeyMismatch 발생 오류 해결

배포를 하는데 HostKeyMismatch 에러가 발생 하면서 서버에 접속 하지 못해 배포가 실패 했습니다. 에러 메시지를 보니 ~/.ssh/known_hosts 파일에서 ec2에 해당하는 항목을 지워서 해결 했지만 앞으로도 계속해서 발생 가능한 문제였습니다.

웹서버를 운영하다보면 AWS의 스팟 인스턴스를 이용해서 많은 트래픽에도 유연하게 대처하는 경우가 있습니다. 스팟 인스턴스의 특성상 서버가 새로 투입되었다가 필요 없어지면 삭제하기를 반복합니다.

서버의 추가와 삭제를 반복하다보면 새로 추가한 서버의 자동 생성된 도메인 이름이나 IP가 예전에 사용했던 서버와 같은 경우가 발생할 수 있습니다. AWS의 자동 생성된 도메인 이름은 다음과 같은 형식입니다.

ec2-00-111-222-333.ap-northeast-2.compute.amazonaws.com

그래서 좀 찝찝 하지만 ec2의 자동 생성된 호스트 이름에 대해서는 known_hosts에 추가하지 않고 관련 체크도 하지 않도록 capistrano 설정에서 아래와 같이 추가했습니다.

server 'ec2-??.ap-northeast-2.compute.amazonaws.com', 
   roles: %{app web}, 
   ssh_options: { verify_host_key: false }

verify_host_key 옵션을 추가한 서버에 배포 할때는 known_hosts 에 추가하지 않고 체크도 하지 않습니다.(capistrano 예전 버전에서는 verify_host_key대신 paranoid 였습니다.)

이렇게 하더라도 서버에 직접 접속 할때면 여전히 know_hosts에 관련된 내용을 추가하려고 하는데요. 이것이 싫다면 .ssh/config에서 특정 호스트에 대해 체크하지 않도록 할 수 있습니다.

Host ec2-*.ap-northeast-2.compute.amazonaws.com
  StrictHostKeyChecking no
  UserKnownHostsFile /dev/null

저는 이 옵션을 사용하지 않습니다. 서버 배포는 자주 해서 문제가 발생할 여지가 높고 배포를 급하게 해야될때 이런 문제가 발생하면 당황하게 되지만 서버에 ssh로 접속하는 상황에서는 중복되더라도 known_hosts 파일에서 지워주는게 귀찮지 않았거든요.

게시글의 아마존, iTunes 링크들을 통해 구매를 하시면 제휴(Affiliate) 프로그램에 의해 저에게 일정 금액이 적립될 수 있습니다. ^_____^

Amazon Athena를 이용해 CloudFront 로그 분석하기

CloudFront(클라우드 프론트)를 이용하다 보면 요청 로그를 직접 분석해야 할 필요가 있습니다.

CloudFront에서 제공하는 통계 메뉴에서도 전체 요청수, Hit, Miss, Error, 상태코드, 용량, 인기객체 등 많은 데이터를 볼 수 있지만 각 요청중 오래 걸리는 요청에 대해 분석하고 싶은 경우에는 CloudFront 로그를 직접 확인해야합니다.

CloudFront 로그파일 저장

CloudFront 기본 옵션은 요청 로그를 따로 저장하지 않습니다. 로그를 저장하기 위해 Distribution 설정에서 Logging 옵션을 On으로 변경하고 로그가 저장될 S3 버킷 이름과 경로를 지정합니다.

저장된 로그의 저장 기간을 설정하기 위해 S3 Bucket 설정에 가서 Management > Lifecycle 에서 Lifecycle Rule을 새로 생성후 Prefix에 따른 로그 삭제 기간을 설정합니다.

삭제에 대한 정책을 생성하지 않으면 용량이 점점 커져서 비용이 비싸지고 로그 분석하는 데도 오래 걸립니다. 문제 해결에 필요한 로그라고 판단되는 3일치 데이터만 놔두고 3일이 지나면 삭제되도록 설정했습니다. 기간은 서비스 특징에 따라서 조정하면 됩니다.

Athena 테이블 생성하기

Athena 에서는 데이터를 분석하기 전에 테이블 생성작업을 해야합니다. 생성할 테이블은 앞서 생성했던 S3 데이터를 참고 하도록 설정하는것이고 이 시점에는 논리적인 테이블만 생성되고 실제 S3 데이터를 읽지 않습니다.

Athena의 Query Editor에서 아래 쿼리를 입력후 실행하면 cloudfront_logs 테이블이 생성됩니다.

CREATE EXTERNAL TABLE IF NOT EXISTS cloudfront_logs (
  `date` date,
  `time` string,
  `location` string,
  bytes bigint,
  requestip string,
  method string,
  host string,
  uri string,
  status int,
  referrer string,
  useragent string,
  querystring string,
  cookie string,
  resulttype string,
  requestid string,
  hostheader string,
  requestprotocol int,
  requestbytes bigint,
  timetaken double,
  xforwardedfor string,
  sslprotocol string,
  sslcipher string,
  responseresulttype string,
  httpversion string
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe'
WITH SERDEPROPERTIES
 (
 "input.regex" = "^(?!#)([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)\\s+([^ \\t]+)$"
 )
LOCATION 's3://로그가저장된S3버킷이름/cf-logs/';

준비를 위한 작업이 모두 끝났습니다. 복잡하다고 생각할수도 있지만 다른 서비스를 이용하는 경우 여기까지의 준비 작업을 위해 데이터를 파싱하고 다시 저장하는등의 작업을 해야되는것을 생각하면 Athena의 준비 작업은 간단합니다.

느린 요청 로그만 추출하기

이미지 요청 속도가 특별히 느린 사용자들의 특징을 찾기 위해 응답시간이 느린 로그만 추출 해보겠습니다.

SELECT 
   date,
   time,
   timetaken,
   location,
   requestip,
   resulttype,
   responseresulttype,
   concat('https://', host, uri)
 FROM "default"."cloudfront_logs" 
 WHERE 
   timetaken > 1
 LIMIT 100;

위 SQL은 응답시간이 1초 이상 걸린 로그만 보여줍니다. 이를 통해 특정 엣지에서 요청이 느린것인지 아니면 특정 IP만 느린지 확인할 수 있습니다.

엣지 로케이션 별로 1초 이상 걸린 요청의 갯수를 알고 싶다면 아래 SQL을 실행합니다.

SELECT 
   location,
   count(*) as cnt
 FROM "default"."cloudfront_logs" 
 WHERE 
   timetaken > 1
 GROUP BY location
 ORDER BY cnt DESC

결과를 보니 별 의미는 없네요. ICN으로 시작하는건 한국 엣지 로케이션인데 절대적인 요청수가 많다보니 1초 이상 걸린것도 많이 나왔습니다.

이외에도 UserAgent를 분석해 기기나 OS에 따른 구분이나 HTTP 프로토콜 버전에 따른 구분등 할 수 있는것이 많습니다. 본인만의 SQL을 좀더 잘 만들어 본다면 CloudFront를 잘 사용하는데 도움이 될것입니다.

주의 할점

Athena는 데이터 분석에 필요한 데이터를 스캔하는 용량 만큼 과금됩니다. SQL을 잘못 작성해서 너무 많은 데이터를 참고 하게 되면 많은 비용이 청구 될 수 있으니 데이터를 적절히 제한해서 SQL 을 작성하는 노력이 필요합니다.

데이터가 많지 않으면 그냥 막 해도 상관 없습니다. 1TB 데이터를 스캔 하는데 $5 정도라서 데이터가 100기가 라면 500원 10 기가라면 50원이니까요 ^^

참고자료

대표 이미지 : Photo by NASA on Unsplash

게시글의 아마존, iTunes 링크들을 통해 구매를 하시면 제휴(Affiliate) 프로그램에 의해 저에게 일정 금액이 적립될 수 있습니다. ^_____^

iOS 삽질 할뻔 : Xcode 9.2로 업그레이드하면 앱스토어 업로드 불가

최근 들어 애플의 소프트웨어 버그가 자주 발생해서 말이 많은데 오늘은 개발자들이 macOS, iOS 개발할때 꼭 사용해야하는 Xcode에 심각한 버그가 발생했습니다.

12월 5일(화)에 iOS 11.2 SDK를 포함한 Xcode 9.2 버전이 새로나왔는데요. 이 버전으로 업그레이드후 열심히 개발하는데까지는 좋은데 앱스토어에 앱을 업로드 하려고 하면 오류와 함께 실패한다고 합니다.

2017년 12월 6일(수) 기준으로는 이 문제가 발생하지 않습니다.

아래와 같은 오류가 발생한다고 하는데요. 정식출시된 Xcode 인데 잘못된 버전으로 인식해서 앱스토어에 업로드 할 수 없는 버그가 발생한거죠 ㅜㅜ

ERROR ITMS-90534: "Invalid Toolchain. New apps and app updates must be built with the public (GM) versions of Xcode 6 or later, macOS, and iOS SDK or later. Don't submit apps built with beta software including beta macOS builds."  

해결 방법은 Xcode 9.2를 완전히 지우고 앱스토어가 아닌 애플 개발자 센터 홈페이지에가서 Xcode 9.1 버전을 직접 다운로드 받아서 설치해야 합니다. Xcode 용량이 10기가 정도 했던거 같은데… 인터넷이 느린 저희 집이라면 근처 스타벅스 가서 받아야겠네요.

이 게시글의 제목이 삽질이 아니라 삽질할뻔인 이유는 저는 영향을 받지 않았기 때문입니다!!! 오늘 오전에 Xcode 9.2 업데이트도 했고 앱스토어에 업로드도 했지만 저는 빌드는 bitrise.io 라는 서비스를 사용하고 있기 때문에 영향이 없었습니다. bitrise.io 에서는 여러가지 버전의 Xcode를 가지고 있고 원하는 Xcode 버전만 변경하면 되서 이번 영향에서 벗어날수 있었습니다! bitrise.io 적용한지 몇주 안됬는데 ㅎㅎ 운이 좋았네요.

이 포스트의 bitrise.io 링크를 눌러서 가입하시면 제 무료범위의 빌드 시간이 늘어나는 혜택이 주어집니다! 기본은 10분인데 조금씩 늘어나고 5명이 되면 티셔츠 받을수 있어요!

조만간 시간이 되면 bitrise.io 서비스에 대해서도 글을 적을게요. 개인적으로는 bitrise.io를 빌드 하는데 사용하고 있는데 여러가지 서비스중에 제일 마음에 들었어요. Xcode 베타 버전도 빠르게 지원합니다. 회사에서는 유료 계정으로 사용중입니다.

참고정보

게시글의 아마존, iTunes 링크들을 통해 구매를 하시면 제휴(Affiliate) 프로그램에 의해 저에게 일정 금액이 적립될 수 있습니다. ^_____^

윈도우 10 우분투에서 도커 설치하기

윈도우 10에 설치한 우분투에서 도커를 설치하는것이 쉽게 되지는 않습니다. 그냥 생각하기에는 우분투에 도커 설치하면 잘 될것 같지만 몇가지 설정이 필요합니다.

BIOS에서 하드웨어 가상화 옵션 활성화

윈도우에서 도커를 사용하기 위해서는 Hyper-V 설치와 하드웨어 가상화 옵션 활성화가 필요합니다. Hyper-V 는 윈도우 10에 리눅스를 설치하면서 자동으로 설치되고 활성화 되는것같아요.

하드웨어 가상화 옵션은 BIOS 에서 CPU 설정에서 가능합니다. Intel CPU는 VT-x, AMD CPU AMD-V(SVM)등의 이름으로 찾을수 있습니다.

제 컴퓨터는 Intel CPU를 사용하고 있었고 BIOS는 ASUS 제품인데 아래와 같은 화면입니다. 여기서 가상화 관련 옵션이 Disabled 되어 있는데 Enabled로 변경후 저장하고 컴퓨터를 종료합니다.(컴퓨터 재시작이 아니라 종료후 재시작을 추천하고 있습니다)

우분투와 윈도우에 도커 설치

우분투에서 도커를 사용하기 위해서는 윈도우 10과 우분투 모두에 Docker를 설치해야합니다.

이렇게 두개를 동시에 설치하는 이유는 우분투에만 도커를 설치할 경우 도커 데몬이 시작하지 않기 때문입니다. 윈도우에 설치한 도커는 도커 데몬 역할을 하고 우분투에 설치한 도커는 클라이언트 역할을 합니다. 우분투에서 실행한 도커 명령어는 윈도우에서 실행중인 도커 데몬에 전달되는 방식입니다.

윈도우와 우분투에 모두 도커를 설치 했다면 우분투 .bashrcDOCKER_HOST 환경변수를 윈도우 컴퓨터로 설정하도록 추가합니다.

export DOCKER_HOST='tcp://0.0.0.0:2375'

쉘을 재시작하거나 우분투를 종료후 다시 실행후 docker ps 등의 명령어를 실행해보면 잘 동작하는것을 확인 할 수 있습니다.

참고정보

게시글의 아마존, iTunes 링크들을 통해 구매를 하시면 제휴(Affiliate) 프로그램에 의해 저에게 일정 금액이 적립될 수 있습니다. ^_____^

윈도우 10 우분투에 ZSH 사용하기

윈도우 10 우분투의 기본 쉘은 BASH 입니다. 하지만 저는 평소에 zsh을 사용하고 있어서 zsh을 설치해보기로 했습니다.

zsh 설치는 간단합니다.

$ sudo apt-get install zsh

설치하고 나서 chsh 을 이용해서 기본 쉘을 bash 에서 zsh로 변경합니다.

$ sudo chsh -s which zsh

우분투를 재시작하면 기본 쉘이 zsh 로 변경한것을 확인 할 수 있습니다.

zsh 만 설치하면 아쉬우니 oh-my-zsh 도 설치합니다.

$ sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"

문제점 수정

위의 방법으로 설치후 zsh 을 사용하다보면 백그라운드에서 프로세스를 실행하려고 하면 오류가 발생합니다.

$ test & 이런식으로 백그라운드에서 실행하려고 하면 오류가 발생하죠.

이 문제는 .zshrc 파일에 아래 내용을 추가하면 해결됩니다.

unsetopt BG_NICE

마지막으로

zsh 설정하면서 pure 라는 zsh prompt를 설치하지 못한것은 아쉽습니다. 평소에 사용하던거라 설치하려고 했는데 ZSH 5.2+ 이상을 요구 하고 있어서 설치하지 못했습니다. 윈도우 10 우분투에서는 apt로 설치하는게 5.1 버전까지 입니다. 직접 컴파일해서 설치 할 수도 있겠지만 그렇게까지는 하고 싶지 않았습니다.

참고정보

게시글의 아마존, iTunes 링크들을 통해 구매를 하시면 제휴(Affiliate) 프로그램에 의해 저에게 일정 금액이 적립될 수 있습니다. ^_____^

윈도우 10에 Ubuntu 설치 및 초기설정

윈도우 10에서 Bash를 지원하기로 했다는 소식을 들었던거 같은데 최근에 윈도우에서 사용해볼 일이 생겨서 설치하면서 생겼던 문제들과 해결방법을 적어보려고 합니다.

윈도우에서 Bash 지원하는것은 윈도우에서 리눅스를 실행하는 방식으로 변경되었습니다. 그래서 윈도우 10 최신 버전을 설치하고 윈도우 스토어에서 Ubuntu를 검색해서 설치하면됩니다. open SUSE도 설치 할 수 있지만 Ubuntu를 추천하고 있습니다.

설치 방법은 간단합니다. 윈도우 스토어에서 linux 혹은 ubuntu로 검색해서 나온 앱 목록에서 Ubuntu를 “다운로드” 하면 설치가 진행됩니다.

설치가 완료된후 Ubuntu 앱 아이콘을 시작메뉴에서 더블 클릭하면 터미널이 실행되면서 우분투로 진입합니다.

처음 실행하는 경우 위 화면과 같이 우분투에서 사용할 계정이름을 입력하라고 나오는데 여기서 사용하고 싶은 이름을 입력하면됩니다. 윈도우의 사용자이름과 동일할 필요가 없습니다.

생각보다 쉽게 우분투가 설치되었습니다 !

이제부터는 우분투를 잘 사용하기 위한 초기 설정에 대해서 주제별로 알아보겠습니다. 아래의 설정을 안해도 사용하는데 문제는 없지만 해두면 좋습니다.

터미널 색상 변경하기

윈도우에서 처음으로 우분투를 실행하고 ls 명령어나 vi 로 문서를 열어보면 파란색이 눈에 잘 안보이는것을 경험하게 됩니다. 단순히 불편한 문제를 넘어서 특정 문자열들이 잘 안보이고 이로인해 문제가 발생할 여지가 있습니다.

Ubuntu를 실행하고서 해당 앱 왼쪽 상단의 우분투 로고에 마우스 오른쪽 버튼을 누른다음 속성을 선택합니다.

속성창에서 “색”을 선택합니다.

“색”에서 중간쯤 보면 여러가지 색상이 박스로 표시되어 있는데요. 이 하나하나의 색을 슬롯이라고 했을때 총 16가지의 색상 슬롯이 있습니다. 이 각각의 슬롯을 선택하고 오른쪽 위에 “선택한 색 값”을 아래와 같이 변경합니다.

Slot 1: Red: 48, Green: 10, Blue: 36
Slot 2: Red: 52, Green: 101, Blue: 164
Slot 3: Red: 78, Green: 154, Blue: 6
Slot 4: Red: 6, Green: 152, Blue: 154
Slot 5: Red: 204, Green: 0, Blue: 0
Slot 6: Red: 117, Green: 80, Blue: 123
Slot 7: Red: 196, Green: 160, Blue: 0
Slot 8: Red: 211, Green: 215, Blue: 207
Slot 9: Red: 85, Green: 87, Blue: 83
Slot 10: Red: 114, Green: 159, Blue: 207
Slot 11: Red: 138, Green: 226, Blue: 52
Slot 12: Red: 52, Green: 226, Blue: 226
Slot 13: Red: 239, Green: 41, Blue: 41
Slot 14: Red: 173, Green: 127, Blue: 168
Slot 15: Red: 252, Green: 233, Blue: 79
Slot 16: Red: 238, Green: 238, Blue: 238

그리고 이제 왼쪽 상단의 “화면 텍스트” 를 선택하고 슬롯 16을 선택합니다. 이런식으로 “팝업 배경”은 슬롯 16, “화면 배경”, “팝업 텍스트”는 슬롯 1로 선택하고 확인 버튼을 클릭합니다.

터미널 색상이 이쁘게 바뀐게 확인되나요? 가독성이 떨어지던 파란색도 이제 잘 보입니다 ^^

디렉토리(폴더)의 배경 색상지우기

위에 ls 결과를 보면 뭔가 마음에 들지 않는게 있지 않나요? 그건 바로 폴더 이름에 녹색 배경이 들어가는 겁니다. 가독성도 떨어지고 굳이 폴더를 이렇게 중요하게 표시해야되나 싶을텐데요.

배경에 색상이 들어가게 보이는건 해당 폴더의 권한이 모든 사용자가 폴더에 쓰기 권한을 가졌기 때문입니다. 모든사용자에게 쓰기 권한이 열려있을 경우 다르게 보이게 하려고 이런식으로 표시됩니다.

그런데 윈도우 우분투를 사용하는 경우 폴더를 만들거나 git clone 을 하는등 모든 폴더를 만들때마다 쓸데없이 모든 사용자들이 쓰기가능한 상태로 만들기 때문에 보안측면에서도 안좋고 보기에도 안좋은 문제가 발생합니다.

.bashrc 파일을 열어서 아래와 같이 umask를 설정하면 해결됩니다.

if [[ "$(umask)" == '000' ]]
then
   umask 022
fi

이제 우분투를 종료후 재시작하거나 쉘을 재시작 하면 폴더를 생성할때 권한이 제대로 설정되고 ls 했을때 배경색이 보이지 않는것을 확인할 수 있습니다. 기존에 이미 생성된 폴더의 경우는 권한을 변경해야합니다.

참고로 이 설정은 우분투에서만 동작하며 윈도우 파일시스템(/mnt/c 같이 윈도우 파일시스템 마운트 된곳) 밑에서는 여전히 777 퍼미션으로 폴더가 생성됩니다.

마지막으로

윈도우에서 우분투가 된다고 해서 기대를 많이 했지만 맥에 익숙해져있던 제가 윈도우에서도 개발을 쉽게 하기에는 아직 많은 장벽들이 있네요. 키보드도 그렇고 윈도우에서 직접 실행할때보다는 덜하지만 개발툴 설정등… 위에 정리한것 말고도 여러가지 문제들이 있는데 차차 블로그 포스트를 통해 전달드리겠습니다.

참고자료

게시글의 아마존, iTunes 링크들을 통해 구매를 하시면 제휴(Affiliate) 프로그램에 의해 저에게 일정 금액이 적립될 수 있습니다. ^_____^