AWS入門者がELBのウェビナーを受けてみた!

IT未経験、前職はトラック運転手として日々配達をしていたDreamです。 オンラインセミナーの受講する種類が多くなってきて今までわからなかった単語が理解できるようになってきました。 今回はAWSのオンラインセミナーでELBについて勉強した際のメモをまとめていきます! 続きを読む

カテゴリー 未分類 | タグ

1ヶ月でAWS 認定ソリューションアーキテクトに合格した話

昨年(2017年)の8月にAWS 認定ソリューションアーキテクト – アソシエイトに合格しました。
ほぼゼロからの勉強でしたが、要点を抑えれば短期間でも合格できたので、やったことを紹介します。

1. 前提知識

趣味で触ったことがあるもの。※どれも軽く触った程度

  • EC2
  • ELB
  • S3
  • Lambda (試験には出ない)
  • API Gateway (試験には出ない)

2. 対策内容

2-1. AWS Summit Tokyo 2017 セッション資料・動画

オススメ度: ★★★★★

一番オススメです。
「試験範囲の動画を見る → 実際にAWS上でやってみる」で大体雰囲気つかめました。
各サービスの「入門」だけで十分だと思います。
(話すペースがゆっくりなので、1.5倍速ぐらいで見ないと眠くなります。)

2-2. AWS Black Belt

オススメ度: ★★★★☆

安定の公式資料集です。
そこそこボリュームあるので、自分は理解の浅いサービスに絞って読みました。
(試験範囲の資料は一通り目を通した方が良いのかも?)

2-3. 参考書

オススメ度: ★★★☆☆

唯一の対策本なので、読んでおいて損はないと思います。
ただ情報量は少なめなので、概要をつかむ程度に使いました。

オススメ度: ★★☆☆☆

ハンズオン形式で進めるので、イメージがつきやすいです。
ただこちらも情報量としては足りてないので、合わせて他の対策も必要です。

2-4. AWS WEB問題集

オススメ度: ★★★☆☆

無料枠のみ解きました。
本番と似たような問題が出題されるので、そこそこ参考になります。
(何問かは本番とまったく同じ問題でした。運が良かっただけかも?)

3-5. それっぽい構成で作ってみる

オススメ度: ★★★★☆

ある程度理解が進んだら、サービスを複数組み合わせて何か作ってみるのがオススメです。
自分の場合は以下の構成で、Hello Worldをブラウザから表示するぐらいの簡単なものを作りました。

 VPC + ELB + EC2 + AutoScaling + CloudWatch + Route53

3. 結果

正答率(模擬試験): 75%
正答率(実試験): 72%

試験当日は、そこそこ感触が良かったのですが、思ったより点数が伸びず^^;
何はともあれ、一発合格できて一安心でした。

4. 感想

  • 実際に手を動かすことが一番タメになりました。やってみないとわからないことがけっこうあります。
  • ある程度知識が付いた段階で、模擬試験を受けることがオススメです。雰囲気つかめます。
  • セキュリティグループとネットワークACLに関する問題が多く出題された気がします。
  • とにかく試験会場が暑かった。。。

続きを読む

「おや…ELBのようすが…?」という時に確認すること

私の経験上、「ELBがおかしいぞ!AWSしっかりしろや!」と思ったら、よくよく調べると実装がダメなだけだったというパターンがよくあるのでまとめたい。

あ、ELBと言いながら厳密にはALBの話をメインにします。

CASE 1. 「バックエンドは生きてるはずなのにヘルスチェックが失敗する!」

つまり以下のような症状が出る状況

  1. ヘルスチェックが失敗する
  2. バックエンドに直接アクセスしたら普通にうまくいく
  3. バックエンドのアクセスログ見たら、ヘルスチェックに200を返している

というパターン。
「バックエンドは生きてるしヘルスチェックにも200を返してる!それなのに失敗扱いなんてELBの不具合だ!」と思いたくなる気持ちはわかるが、まずは落ち着いてヘルスチエックの成否の基準を見直そう。

ターゲットグループのヘルスチェック – Elastic Load Balancing

ターゲットが応答タイムアウト期間内に応答するのを待ちます。

つまりバックエンドが200を返していようが、タイムアウトしていたらヘルスチェック的には失敗なのだ。
とりあえずバックエンドのアクセスログから処理時間を確認してみよう。まさか処理時間を出力するようにログフォーマットを設定してないなんて言わないよな?

ちなみにステータスコード200というのも注意が必要で、みんな大好きApacheのドキュメントにこんな記載がある

mod_log_config – Apache HTTP サーバ バージョン 2.4

%s ステータス。内部でリダイレクトされたリクエストは、元々の リクエストのステータス — 最後のステータスは %>s

すこぶる分かりにくい文章だが、要するに
・ %s -> リダイレクトが発生した際に3XXのコードを出力する
・ %>s -> リダイレクトが発生した際に3XXのコードを出力せず、リダイレクト後の処理の結果のコードを出力する

というわけだ。そのため、「200を返してるし、CPU使用率も上がってないから大丈夫なはず」と思ってたら実はリダイレクトしまくってタイムアウトしてた、というパターンもある。
そして、筆者の記憶が確かならApacheではデフォルトで%>sが設定されている。

というわけでこの症状の場合は、ELBの不具合とヘルスチェックのタイムアウト、どちらの方がありえそうか考えて調査をはじめてみよう。

CASE 2. 「HTTPCode_ELB_5XX_Countメトリクスが出てる!」

「5XXはサーバサイドのエラー…ELBが5XXエラーを出しているということは…ELBの不具合や!」と思いたくなる気持ちはわかるが、まあ落ち着いてほしい。
私も過去に502 Bad Gatewayに悩まされ、AWSにも問い合わせたりしたが、結局のところバックエンドの実装がクソだったのが原因だった。
だから落ち着いてまずはこれを見てほしい。

Application Load Balancer のトラブルシューティング – Elastic Load Balancing

うん、分かりにくいな。
5XX系のエラーに絞って、頑張って解説してみよう。

HTTP 502: Bad Gateway

そもそも502 Bad Gatewayというもの自体が分かりにくい。
Wikipediaによると

不正なゲートウェイ。ゲートウェイ・プロキシサーバは不正な要求を受け取り、これを拒否した。

これで理解できる人間はほぼいないだろう。
502 Bad Gatewayについてはこちらのページの解説が分かりやすい。

502Bad Getewayの原因と意味について | ぷろめし|プログラミングよりも飯が好き

ELBに当てはめて考えるなら、「ELBからバックエンドにリクエストを投げたが、解せないレスポンスが帰ってきた」という状況である。
つまり、ELBがイかれている可能性もあるが、バックエンドがイかれたレスポンスを返したり途中でコネクションをブッチしている可能性もあるのだ。

つまり、502 Bad Gatewayが現れたらバックエンドからのレスポンスがどうなってるかを見直した方がいいだろう。

HTTP 503: Service Unavailable

一時的に使えないというやつ。
上記のドキュメントにはターゲットグループにインスタンスが無いという場合しか書いてないが、実は他にも503が発生する可能性はある。

ELBはトラフィック量に合わせて自動でスケールするが、あまりに急激にトラフィックが増加した場合にはスケールが間に合わなくなることがある。そういう場合にはELBの処理能力が足りなくなって503が発生することになる。
ほっといたらそのうちELBがスケールして解決するが、「一瞬たりとも落とせないんだ!」という時は予めPre-warmingを申し込んでおこう。

Elastic Load Balancing の暖気申請について | Developers.IO

見積もりがガバガバだと「ほんまにPre-warming必要か?」と突っ込まれることもあるので、真面目に見積もろう。

HTTP 504: Gateway Timeout

これは分かりやすい。
ELB -> バックエンドの通信がタイムアウトしたということである。
バックエンドの処理を見直すか、タイムアウト時間を伸ばすかの二択だが、基本的にはバックエンドの処理を見直す方が健全である。

色々調べたが、どう考えても実装に問題はない時は…

AWS側の問題という可能性もあるので、問い合わせよう。

続きを読む

2018.1.31勉強まとめ

・デフォルトのリージョン:us-east-1

・AWS Storage Gateway:仮想テープライブラリ。オンプレのデータバックアップなどで使用

Route53:エイリアスレコードを使用してELBにルーティングできる
Zone Apexに割り当てる場合もエイリアスレコード使用

・メタデータ
http://169.254.169.254/latest/meta-data/でメタデータ取得可能
http://169.254.169.254/latest/meta-data/public-ipv4:パブリックIP
http://169.254.169.254/latest/meta-data/local-ipv4:プライベートIP
curl/GETで取得可能。テキストとして返される

・ユーザデータ
http://169.254.169.254/latest/user-data/で取得可能
コンテンツタイプはapplication/octet-stream
カンマで区切られたテキストで取得

プレイスメントグループ
同一のAZ内に複数のEC2を配置可能

プレイスメントグループは、単一のアベイラビリティーゾーン内のインスタンスを論理的にグループ化したものです。サポートされているインスタンスタイプとともにプレイスメントグループを使用すると、アプリケーションが低レイテンシーの 10 Gbps (ギガビット/秒) ネットワークに参加できるようになります。
どちらもインスタンス間における低レイテンシな通信を実現するための機能オプション
クラスタコンピューティングやDBの同期レプリケーションのように、サーバ間の通信レイテンシがサービス品質に影響するような場合に効果を発揮

拡張ネットワーキング
高い帯域幅、1 秒あたりのパケット (PPS) の高いパフォーマンス、常に低いインスタンス間レイテンシーを実現します。

参考URL:https://dev.classmethod.jp/cloud/aws/ec2-placement-group/

侵入テスト
事前にAWSに許可必要
EC2とRDSに限定対象外もある

参考URL:http://kakakakakku.hatenablog.com/entry/2016/08/08/022520

続きを読む

AWS DDoS対策勉強まとめ

・DDOS攻撃
複数の攻撃元が協調して大量のパケットやリクエストを送ってサービスを停止させる

・ランサムDDoS
攻撃者が公開サーバーをいつでも停止できる

下記三軸で考える
【高さ】
レイヤーごと
– アプリケーション層攻撃
アプリケーションリソースを攻撃。
HTTPGET

DNSクエリフロッド
→ボットネットと呼ばれる複数の感染ホストを利用し、大量のクエリをDNSに配信

  • 状態枯渇攻撃
    ファイヤーウォールなどに攻撃
    TCP SYNフロッド
    →クライアントから意図的にACKを返さないことで、他のユーザがアクセス出来なくする
  • ボリューム攻撃
    処理できる能力を越えたトラフィックを送る
    UDP反射攻撃
    →攻撃者はIPを偽装。要求と応答のパケットのサイズ差を利用

【深さ】
アプリケーションごとに対策は違う。
→エッジとリージョンなど

・ウェブアプリケーションの場合
エッジでAWS WAF, CloudFrontを利用
リージョンでセキュリティグループで対策

・クライアント/サーバーアプリケーションの場合
EC2の垂直スケール、拡張ネットワークでトラフィック吸収

・ゲームアプリケーションの場合
Routing Matching ServiceでIP配布
特定のIPのみからアクセスするよう制御

【幅】
・地理的分散
→CloudFrontで配信分散

・攻撃対象隠蔽
→セキュリティグループ使用
→Amazon API Gatewayを利用。Web API公開サーバーを立てない
→ELBでEC2を見せない

・攻撃吸収、緩和
→AWS Shieldによる自動緩和システム
→CloudFrontによるGEOリストリクション
→Route53。高可用性
→ELBとAutoscalingでインスタンスそp増減
→拡張ネットワーク。NICへのアクセスを複数あるようにする

・計画、監視
→CloudWatchでの監視

・AWS Shield Standard
Layer 3/4 protection
→一般的な攻撃から防御
無料

Layer 7 protection
→WAFを利用
→使った分だけ支払い

・AWS Shield Advanced
Standardに加え、より大規模な攻撃からの防御

参考URL:
https://www.slideshare.net/mobile/AmazonWebServicesJapan/20170905-aws-blackbeltddosmitigation-79478348

続きを読む

AWS Elastic Beanstalkで、デプロイ時に一つのインスタンスにだけ実行

Elastic Beanstalk へのデプロイで、一つのインスタンスにだけ実行するには container_commandsleader_only というフラグを立てれば良いと思われるが、上手く動作しなかった。しかもオートスケール時には動作しないらしい。

ので、ELB に問い合わせて自身のインスタンスIDと比較するという方法を取った。下記のスクリプトを配置すれば可能。

#!/usr/bin/env bash

if aws elb describe-load-balancers --query 'LoadBalancerDescriptions[].Instances' --region ap-northeast-1 --output text 
    | cat -n 
    | grep $(curl http://169.254.169.254/latest/meta-data/instance-id) 
    | awk '{print $1}' 
    | grep -q 3
then
    echo 'HOME=/tmp' | sudo tee /var/spool/cron/webapp
    echo '* * * * * php /var/app/current/artisan schedule:run >> /dev/null 2>&1' | sudo tee -a /var/spool/cron/webapp
fi
  • grep -q 3 は決め打ちの番号なので、環境で調整する必要あり。
  • インスタンスの中で curl http://169.254.169.254/latest/meta-data/instance-id とすると、そのインスタンス自身のIDが取得できる。
  • IAMロールの設定が別途必要。Elastic Beanstalkに振られているIAMロールに AWSElasticBeanstalkFullAccess を付与すれば良い。

参考

https://qiita.com/idaaki/items/a356d1785a59d4150358

続きを読む

コピペで使えるELBのアクセスログ解析による事象分析 (ShellScript, Athena)

アクセスログ解析

ELBのアクセスログの事象分析について、ShellScriptとAthenaを用いた実行例についてまとめます。

ShellScript

CLB

No.1 : レスポンスが正常に受け取れていないELBのレスポンスコード毎のカウント

$ awk '$10 == "-"' * | awk '{print $9}' | sort | uniq -c

No.2 : ELBのレスポンスコード毎の数集計

$ awk '{print $8}' *.log | sort | uniq -c

No.3 : 504のレコード一覧

$ awk '$8 == 504'

No.4 : 504がどのELBノードから多く出力されているか

$ grep ' 504 ' *.log | awk '{print $3}' | sed 's/:.*//' | sort | uniq -c

No.5 : バックエンドから正常に応答が受け取れていない時

$ awk '{if (! int($5) < 0) {print $0}}' * | egrep '2018-01-2[45]'

No.6 : target_processing_time の3つの統計値(最小値、最大値、平均)と -1 の値を取った回数を表示する

$ awk '{ print $4,$8,$9,$6 }' * | sort | sed -e 's/ /!!/' -e 's/ /!!/' | awk '{if(count[$1]==0) min[$1]=100; count[$1]+=1; if(max[$1]<$2&&$2!=-1) max[$1]=$2; if(min[$1]>$2&&$2!=-1) min[$1]=$2; if($2!=-1)sum[$1]+=$2; else minus[$1]+=1;} END{for(k in count)print k,", count:",count[k],", max:",max[k],", min:",min[k],", avg:",sum[k]/count[k],", -1:",minus[k];}' | sort -k4nr

No.7 : response_processing_time の3つの統計値(最小値、最大値、平均)と -1 の値を取った回数を表示する

$ awk '{ print $4,$8,$9,$7 }' * | sort | sed -e 's/ /!!/' -e 's/ /!!/' | awk '{if(count[$1]==0) min[$1]=100; count[$1]+=1; if(max[$1]<$2&&$2!=-1) max[$1]=$2; if(min[$1]>$2&&$2!=-1) min[$1]=$2; if($2!=-1)sum[$1]+=$2; else minus[$1]+=1;} END{for(k in count)print k,", count:",count[k],", max:",max[k],", min:",min[k],", avg:",sum[k]/count[k],", -1:",minus[k];}' | sort -k4nr

No.8 : 最も多いリクエスト元のELBノードIPアドレスのリクエスト数

$ awk '{print $3}' * | awk -F ":" '{print $1}' | sort | uniq -c | sort -r| head -n 10 

No.9 : 時間毎のリクエスト数

grep中の二重引用符内は適宜日付等を入れて絞り込み

grep -r "" . | cut -d [ -f2 | cut -d] -f1 | awk -F: '{print $2":00"}' | sort -n | uniq -c

No.10 : 分単位でのリクエスト数

grep中の二重引用符内は適宜日付等を入れて絞り込み

$ grep "" * | cut -d [ -f2 | cut -d ] -f1 | awk -F: '{print $2":"$3}' | sort -nk1 -nk2 | uniq -c | awk '{ if ($1 > 10) print $0}'

No.11 : ユーザーエージェント毎のランキング

$ awk '{split($0, array, """); agent=array[4]; print agent}' * | sort | uniq -c | sort -nr | head

No.12 : TLSでクライアントが最も使った暗号スイートのランキング

$ awk '{split($0, array, """); afterUserAgent=array[5]; print afterUserAgent}' * | awk '{print $1}' | sort | uniq -c | sort -nr | head -5

No.13 : TLSでクライアントが最も使ったTLSバージョンのランキング

$ awk '{split($0, array, """); afterUserAgent=array[5]; print afterUserAgent}' * | awk '{print $2}' | sort | uniq -c | sort -nr | head

No.14 : TLSでクライアントが最も使ったプロトコルと暗号スイートのランキング

$ awk '{split($0, array, """); proto=array[1]; afterUserAgent=array[5]; print proto afterUserAgent}' * | awk '{print $1 " " $13}' | sort | uniq -c | sort -nr | head

ALB

No.1 : target_processing_time の3つの統計値(最小値、最大値、平均)と -1 の値を取った回数を表示する

 $ awk '{ print $5,$9,$10,$7 }' * | sort | sed -e 's/ /!!/' -e 's/ /!!/' | awk '{if(count[$1]==0) min[$1]=100; count[$1]+=1; if(max[$1]<$2&&$2!=-1) max[$1]=$2; if(min[$1]>$2&&$2!=-1) min[$1]=$2; if($2!=-1)sum[$1]+=$2; else minus[$1]+=1;} END{for(k in count)print k,", count:",count[k],", max:",max[k],", min:",min[k],", avg:",sum[k]/count[k],", -1:",minus[k];}' | sort -k4nr

No.2 : response_processing_time の3つの統計値(最小値、最大値、平均)と -1 の値を取った回数を表示する

$ awk '{ print $5,$9,$10,$8 }' * | sort | sed -e 's/ /!!/' -e 's/ /!!/' | awk '{if(count[$1]==0) min[$1]=100; count[$1]+=1; if(max[$1]<$2&&$2!=-1) max[$1]=$2; if(min[$1]>$2&&$2!=-1) min[$1]=$2; if($2!=-1)sum[$1]+=$2; else minus[$1]+=1;} END{for(k in count)print k,", count:",count[k],", max:",max[k],", min:",min[k],", avg:",sum[k]/count[k],", -1:",minus[k];}' | sort -k4nr

Athena

以下、全て CLB を前提とします。
また、以下のような、デフォルトで生成されている sampledb データベースの elb_logs テーブルを使用します。

CREATE EXTERNAL TABLE `elb_logs`(
  `request_timestamp` string COMMENT '', 
  `elb_name` string COMMENT '', 
  `request_ip` string COMMENT '', 
  `request_port` int COMMENT '', 
  `backend_ip` string COMMENT '', 
  `backend_port` int COMMENT '', 
  `request_processing_time` double COMMENT '', 
  `backend_processing_time` double COMMENT '', 
  `client_response_time` double COMMENT '', 
  `elb_response_code` string COMMENT '', 
  `backend_response_code` string COMMENT '', 
  `received_bytes` bigint COMMENT '', 
  `sent_bytes` bigint COMMENT '', 
  `request_verb` string COMMENT '', 
  `url` string COMMENT '', 
  `protocol` string COMMENT '', 
  `user_agent` string COMMENT '', 
  `ssl_cipher` string COMMENT '', 
  `ssl_protocol` string COMMENT '')
ROW FORMAT SERDE 
  'org.apache.hadoop.hive.serde2.RegexSerDe' 
WITH SERDEPROPERTIES ( 
  'input.regex'='([^ ]*) ([^ ]*) ([^ ]*):([0-9]*) ([^ ]*):([0-9]*) ([.0-9]*) ([.0-9]*) ([.0-9]*) (-|[0-9]*) (-|[0-9]*) ([-0-9]*) ([-0-9]*) \"([^ ]*) ([^ ]*) (- |[^ ]*)\" ("[^"]*") ([A-Z0-9-]+) ([A-Za-z0-9.-]*)$') 
STORED AS INPUTFORMAT 
  'org.apache.hadoop.mapred.TextInputFormat' 
OUTPUTFORMAT 
  'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'
LOCATION
  's3://athena-examples-us-west-2/elb/plaintext'
TBLPROPERTIES (
  'transient_lastDdlTime'='1480278335');

HTTPステータスコードが200のレコード一覧

SELECT * 
FROM elb_logs
WHERE elb_response_code <> '200'
ORDER BY request_timestamp;

ELB毎のリクエスト数

SELECT elb_name,
         count(*) AS request_count
FROM elb_logs
GROUP BY elb_name
ORDER BY request_count DESC;

ELB毎のリクエスト数(期間指定)

SELECT elb_name,
         count(*) AS request_count
FROM elb_logs
WHERE request_timestamp >= '2014-01-01T00:00:00Z'
        AND request_timestamp < '2016-01-01T00:00:00Z'
GROUP BY elb_name
ORDER BY request_count DESC;

ELB毎のリクエスト数(期間+ELB 指定)

SELECT elb_name,
         count(*) AS request_count
FROM elb_logs
WHERE elb_name LIKE 'elb_demo_008'
        AND request_timestamp >= '2014-01-01T00:00:00Z'
        AND request_timestamp < '2016-01-01T00:00:00Z'
GROUP BY elb_name
ORDER BY request_count DESC;

ELB毎の5XXエラーのリクエスト数

SELECT elb_name,
         backend_response_code,
         count(*) AS request_count
FROM elb_logs
WHERE backend_response_code >= '500'
GROUP BY backend_response_code, elb_name
ORDER BY backend_response_code, elb_name;

ELB毎の5XXエラーのリクエスト数(ELB指定)

SELECT elb_name,
         backend_response_code,
         count(*) AS request_count
FROM elb_logs
WHERE elb_name LIKE 'elb_demo_008'
        AND backend_response_code >= '500'
GROUP BY backend_response_code, elb_name
ORDER BY backend_response_code, elb_name;

ELB毎の5XXエラーのリクエスト数(期間+ELB 指定)

SELECT elb_name,
         backend_response_code,
         count(*) AS request_count
FROM elb_logs
WHERE elb_name LIKE 'elb_demo_008'
        AND backend_response_code >= '500'
        AND request_timestamp >= '2014-01-01T00:00:00Z'
        AND request_timestamp < '2016-01-01T00:00:00Z'
GROUP BY backend_response_code, elb_name
ORDER BY backend_response_code, elb_name;

ELB毎の5XXエラーのリクエスト数(期間+ELB+URL 指定)

SELECT count(*) AS request_count,
         elb_name,
         url,
         elb_response_code,
         backend_response_code
FROM elb_logs
WHERE elb_name LIKE 'elb_demo_008'
        AND backend_response_code >= '500'
        AND url LIKE 'http://www.example.com/jobs/%'
        AND request_timestamp >= '2014-01-01T00:00:00Z'
        AND request_timestamp < '2016-01-01T00:00:00Z'
GROUP BY elb_name,url,elb_response_code,backend_response_code
ORDER BY request_count DESC limit 10;

ELB毎の5XXエラーのリクエスト数(期間+ELB+URL+UserAgent 指定)

SELECT count(*) AS request_count,
         elb_name,
         url,
         elb_response_code,
         backend_response_code,
         user_agent
FROM elb_logs
WHERE elb_name LIKE 'elb_demo_008'
        AND backend_response_code >= '500'
        AND url LIKE 'http://www.example.com/jobs/%'
        AND user_agent LIKE '%Mozilla/5.0%'
        AND request_timestamp >= '2014-01-01T00:00:00Z'
        AND request_timestamp < '2016-01-01T00:00:00Z'
GROUP BY elb_name,url,elb_response_code,backend_response_code,user_agent
ORDER BY request_count DESC limit 10;

送信元IPのリクエスト数ランキング

SELECT request_ip,
         url,
         count(*) AS request_count
FROM elb_logs
WHERE elb_name LIKE 'elb_demo_008'
        AND request_timestamp >= '2014-01-01T00:00:00Z'
        AND request_timestamp < '2016-01-01T00:00:00Z'
GROUP BY request_ip,url
ORDER BY request_count DESC limit 5;

日付ごとのリクエスト数

SELECT date(from_iso8601_timestamp(request_timestamp)),
         count(*)
FROM elb_logs
WHERE url LIKE '%/jobs/%'
        AND date(from_iso8601_timestamp(request_timestamp)) >= date('2014-12-01')
GROUP BY  1
ORDER BY  1;

直近1年の500エラー発生のリクエスト数

SELECT elb_response_code,
         count(*)
FROM elb_logs
WHERE from_iso8601_timestamp(request_timestamp) >= date_add('day', -365 * 1, now())
        AND elb_response_code >= '500'
GROUP BY  1
ORDER BY  1;

レスポンスに1.0s以上時間がかかっているリクエスト

SELECT url,
         count(*) AS count,
         backend_processing_time
FROM elb_logs
WHERE backend_processing_time >= 1.0
GROUP BY  url, backend_processing_time
ORDER BY backend_processing_time DESC;

任意のエントリ取得(期間+リクエスト元IP 指定)

SELECT *
FROM elb_logs
WHERE request_ip = '245.85.197.169'
        AND request_timestamp >= '2014-01-01T00:00:00Z'
        AND request_timestamp <= '2016-01-01T00:00:00Z';

あるページからの遷移先ページ傾向

SELECT d.*
FROM 
    (SELECT b.request_ip,
         min(b.request_timestamp) AS request_timestamp
    FROM 
        (SELECT *
        FROM elb_logs
        WHERE url LIKE '%/jobs/%') a
        JOIN elb_logs b
            ON a.request_timestamp < b.request_timestamp
        GROUP BY  1 ) c
    JOIN elb_logs d
    ON c.request_ip = d.request_ip
        AND c.request_timestamp = d.request_timestamp
ORDER BY  d.request_timestamp;

参考

ELB アクセスログ

Classic Load Balancer のアクセスログ – Elastic Load Balancing
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/classic/access-log-collection.html#access-log-entry-syntax
Application Load Balancer のアクセスログ – Elastic Load Balancing
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/load-balancer-access-logs.html#access-log-entry-syntax

Athena

Querying Classic Load Balancer Logs – Amazon Athena
https://docs.aws.amazon.com/ja_jp/athena/latest/ug/elasticloadbalancer-classic-logs.html
Querying Application Load Balancer Logs – Amazon Athena
https://docs.aws.amazon.com/athena/latest/ug/application-load-balancer-logs.html

Amazon AthenaでELBのログを調査するときに使ったSQL
https://dev.classmethod.jp/cloud/amazon-athena-sql-for-elb/
Amazon AthenaでELBログをSQLで解析する #reinvent
https://dev.classmethod.jp/cloud/aws/amazon-athena-sql-elb-log-reinvent/
Amazon Athenaではじめるログ分析入門
https://qiita.com/miyasakura_/items/174dc73f706e8951dbdd

続きを読む

AWS ALBのスティッキーセッションについて調べてみた(再接続のたびにセッションの寿命は延びる)

ALBのスティッキーセッションを使うことになったのだが、設定を見るとセッション保持時間しか設定できない。
これだと、例えば24hで設定したとして、24h後のちょっと前にアプリにログインしても、stikky sessionのcookie切れで再ばランシングされて、ログインしていないインスタンスに接続したらログインセッションが切れてしまうことになる。
なんだかなーと思ってマニュアルを読み直すと以下の記述を見つけた。

ターゲットグループレベルでスティッキーセッションを有効にします。
ロードバランサー生成のクッキーの維持期間を秒単位で設定することもできます。
期間はリクエストごとに設定されます。
そのため、各期間の有効期限が切れる前にクライアントがリクエストを送信すると、スティッキセッションが継続されます。
複数のターゲットグループのスティッキーセッションを有効にした場合、すべてのターゲットグループに同じ継続時間を設定することをお勧めします。

若干曖昧だた有効期限内にリクエストを送信するとセッションが延長されるって意味かな?
ということで実際に検証してみることにした。

検証環境

検証環境は以下のとおりとした。
nginxの/stikky.txtにアクセスするとそれぞれnginx01nginx02と返すようにしてある。
スティッキーセッションの期間は3秒とした(実環境ではこんな未時間に設定するわけないけどw)

Client --- ALB --- Nginx01
                └- Nginx02

検証結果

まずは5秒間隔でポーリングしてみる。
コマンド結果をみるとおりNginx01, Nginx02に交互に接続している。
スティッキーセッションが3秒で切れてしまうから、5秒後にアクセスしたときは新規接続とみなされ再振り分け、coocke再発行されるためだ。

[root@localhost ~]# yes "date '+%d-%m %H:%M:%S'|tr 'n ' ' ' ; curl -c ./cookie_elb.txt -b ./cookie_elb.txt http://nginx-1428263045.us-west-2.elb.amazonaws.com/stikky.txt;sleep 5;" | sh
27-01 05:45:03 nginx02
27-01 05:45:08 nginx01
27-01 05:45:14 nginx01
27-01 05:45:20 nginx02
27-01 05:45:25 nginx02
27-01 05:45:31 nginx01
27-01 05:45:36 nginx01

次に1秒間隔でポーリングしてみる。
30秒以上試したが今度はずっとNginx02に接続している。
心配していたセッションの途中切れだが、5秒以上たってもセッションは維持されるようだ。
つまりセッション期間内に再接続すればstikky sessyonの時間も延長される、ということだろう。

[root@localhost ~]# yes "date '+%d-%m %H:%M:%S'|tr 'n ' ' ' ; curl -c ./cookie_elb.txt -b ./cookie_elb.txt http://nginx-1428263045.us-west-2.elb.amazonaws.com/stikky.txt;sleep 1;" | sh
27-01 06:03:12 nginx01
27-01 06:03:14 nginx01
27-01 06:03:15 nginx01
27-01 06:03:17 nginx01
27-01 06:03:18 nginx01
27-01 06:03:20 nginx01
27-01 06:03:21 nginx01
27-01 06:03:23 nginx01
27-01 06:03:24 nginx01
27-01 06:03:26 nginx01
27-01 06:03:27 nginx01
27-01 06:03:29 nginx01
27-01 06:03:30 nginx01
27-01 06:03:32 nginx01
27-01 06:03:33 nginx01
27-01 06:03:35 nginx01
27-01 06:03:36 nginx01
27-01 06:03:38 nginx01
27-01 06:03:39 nginx01
27-01 06:03:41 nginx01
27-01 06:03:42 nginx01
27-01 06:03:44 nginx01
27-01 06:03:45 nginx01
27-01 06:03:47 nginx01
27-01 06:03:48 nginx01
27-01 06:03:50 nginx01

で、スティッキーセッション期間はどれくらいに設定すべきか?

上記検証を踏まえると、バックグランドで頻繁に通信しているようなシステムならスティッキーもそのたびに更新され、ログアウトしない限り維持され続けると思われる。ユーザー操作がないと通信しないシステムの場合、無操作状態が続くとスティッキーセッションの有効期限を迎えてしまうから、システムのセッションタイムアウトと同じに設定するのが良いだろう。そうすれば、システムのセッションが切れて、再ログインが必要になるタイミングでスティッキーセッション有効期限が切れるのでユーザーが意図せず突然セッションが切れてしまう、という事態が防げる。

続きを読む

AWS 認定 Proffesional level を大体一ヶ月で取った話

はじめに

  • 去年の7~8月ぐらいにAssociate levelを3つまとめて取って、AWS 認定 Associate level を大体一ヶ月で取った話(https://qiita.com/yutaChaos/items/2b0b8d9bfe76a597953c) という記事を書きました。その記事の続編です。
    そこから続けてProfessionalも取るぞーと思ったのですが、すこしモチベーションが下がってしまい、ちょっと間が空いてしまいましたが、12月にre:Inventに行かせてもらったこともあり、モチベーションが上がったので、今年の1月に Solutions ArchitectDevOps EngineerProfessional Levelを取得しました。ふりかえりのために勉強方法や感想をまとめたいと思います。

AWS経験

  • 前職まではオンプレのみでAWS経験なし。
  • サーバサイドエンジニア(主にPHP,node,java)
  • 今の会社に入って1半年でVPC,EC2,RDS,ELB,S3を業務で使用。SNS,SQS、DynamoDBなどのサービスは触ったことがない。

勉強期間

  • 12月の終わりの正月休みなどを利用しつつ大体2週間程度
  • 通勤でdocumentを読んだり、休みの日は喫茶店で3~4時間程度勉強していました(家だとあまり集中が出来なくて・・・)

試験の難易度について

  • 個人的な印象ですが、難易度は Solutions Architect > DevOps Engineer だと感じました。
  • Proffesional Levelの問題はAssociate levelと比べると機能の暗記というよりもユースケースからベストプラクティスをどう導き出すか?という観点が多かったように思えます。

取得した資格

  • AWS Certified Solutions Architect – Professional 2017/1/9 取得
  • AWS Certified DevOps Engineer – Professional 2017/1/25 取得

学習を始める前の注意

出題範囲と配点をよく確認する。

  • 各認定のページで出題範囲とサンプル問題がダウンロードできるので、出題範囲と配点はよく確認しておく。
  • Associateでもそうでしたが、Professionalでも基本出題範囲と傾向は点数を取るために重要でした。
  • AWSのサービスは大量にあるのでむやみやたらに勉強するときりがない。出題されない部分ばかりを勉強してしまうと悲劇を起こします。(実体験)
  • 資格によって、各分野の採点配分が異なるので重点を置いて、学習する部分も出題範囲を目安にした方がより効率的に学習できると思います。
  • 公式のblack beltでもAWS認定についてのslideがあるのでこちらを確認することもオススメです。

受験メモ

  • 試験のアグリーメントで試験内容のことは細かく書けないので、各試験の受験後のメモを書いておきます。

AWS Certified Solutions Architect 受験メモ

  • Direct Connectが多いように感じた。
  • リアルタイムはとりあえずkinesis
  • STS連携の問題切り分けておいたほうが良い
  • 問題文のうちの2つぐらいは除ける、のこり2つはどちらも可能であるが、どちらのほうが良い。という問題

AWS Certified DevOps Engineer 受験メモ

  • 問題の大半はCloudFormation,Elastic Beanstalk,OpsWorks の出題傾向が多かった。
  • CloudFormationはparamterや機能名が出て来ることも多い。
  • blue-green deploymentsはもっと勉強しておけばよかった。

勉強方法

  • 今回はいくつかの学習サイトやインターネットの記事を参考に勉強することが多かったです。Associateの勉強は完全に日本語オンリーでやっていましたが、Proffesionalだとあまり日本語の情報もなく、途方にくれていた所、英語圏だと結構情報が多かったので問題傾向や学習内容は英語のものを頼る部分が多かった。
  • 基本的な内容はLinux Academy、わからない問題はdocumentとネットで検索してという形が多かったです。

Linux Academy

  • オンライン学習サービスのLinux Academy( https://linuxacademy.com/ )のAWSコースを受講してみました。(多分日本語で出てくるリナックスアカデミーという学校とは別物)
  • AWS Certified Solutions Architect – Professional Level
  • AWS Certified DevOps Engineer – Professional Level
  • Linux Academyのコースは前編英語です。結構細かい所まで解説してくれるので非常に勉強になります。Cloudの勉強としてはクオリティが高く、結構良かった。
  • 反面試験勉強という観点だけで見ると過剰な部分もある。
  • アプリもあって、videoを保存して見ることも出来るので通勤でも使えた。

A Cloud Guru Forums

  • A Cloud Guruというクラウドの普及活動などをしている団体のforumです。(serverlessconfとかでも有名)
  • 各自の試験の質問や報告などが頻繁に投稿されていて、情報を集めるのに便利。
  • https://acloud.guru/forums/home

Jayendra’s Blog

  • Solutions Architect Professionalのサンプル問題や各解説がたくさん載っているブログ、ただ微妙に正解か怪しい問題も結構ある。
  • http://jayendrapatil.com/

meyrick.net

模擬試験

  • Professinalの模擬試験は絶対受けてください!
  • 本番より難易度が高い気がします。私は模擬試験全部落ちたorz
  • 終了後に正答率が出るので自分の傾向を調べられる.

blackbelt

よくある質問

  • 各サービスのよくある質問にあるユースケースは問題に出ることもあるので確認

AWS クラウドサービス活用資料集

  • https://aws.amazon.com/jp/aws-jp-introduction/
  • AWS公式の中で一番情報がまとまっているのはクラウド活用資料集でした。ユースケースや各オンラインセミナーへのリンクがまとまっています。

公式トレーニング

  • 私は受けたことがありませんが、AWS公式のトレーニングコースがあってもし会社が出してくれたり、余裕があれば受けてみることをおすすめします。

受験

受験方法

  • 2017年の9月からAWSの試験業者がPSIに変更され、受験方法が少し変わりました。テストセンターで受験することはかわらないのですが、kiosk端末で受けてWebカメラで監視されつつ、チャットで指示を受けつつ受験する形です。
  • 今までより試験会場と試験時間が減っているので早めに予約をしたほうがよいと思います。
  • 例外で東京の場合はテンプル大学の場合はkiosk端末ではなく、今までと同じPCだけで受験出来るようになっているので、監視とかが気になる方にはおすすめです。

受験時

  • professionalは80問と問題数も多いので、制限時間170分内に全ての問題を終わらせるためには一問あたり最大2分で終わらせないといけないので、わからない問題にはチェックをつけて、後で回答するようにする心構えぐらいで受けたほうが良い。

さいごに

  • とりあえずAWSの基本の5種が制覇出来たのですごくうれしい!
  • 次はAWS specialityか、Azure or GCPの他のクラウドベンダーの知識もつけていきたい。

続きを読む