omuronの備忘録

個人的な備忘録

サバワ「AWSプロフェッショナルへの道」の感想

AWS ポエム 勉強会

昼休みにサーバーワークスさんが面白そうなライブ配信をしていたので、ご飯食べながら眺めました。 （冒頭の挨拶で、「ご飯食べたりしながら気軽に見てください！」といってたので）

serverworks.doorkeeper.jp

77人の参加者登録で、99人とか視聴者いたけど中の人が結構みてたんだろうか。
以下、ポエム的な所感です。

日本に AWS 資格全種類持っている人は 14 人しかいないんですね。 昔「どやTech」という各自の自慢話をする勉強会（1回きりで2回目はなかった）の記憶が蘇りました。 当時、AWS 資格にスペシャリストがなくアソシエイト3種とプロフェッショナル2種の計5冠だった時代。 5冠を達成した人のプレゼンがあって「日本に5人しかいない」と、どやってました。 その後、別の勉強会で当時サーバーワークスの中の人も自己紹介で5冠達成していることを書いており、「さすがプレミアパートナーのサーバーワークスすごい。」と感じた覚えがあります。

今回モデレーターしてた営業の松本さんも、ソリューションアーキテクトプロフェッショナル持っているし、社内の某取締役「プロフェッショナルもってないなんて人間じゃないｗ」と言ってたらしいし、プレミアパートナーの会社はやっぱりレベルが高いですね。 そのうち SAP チャレンジしたいと思ってたけど、値段と試験時間的にまったくできる気がしない。 誰でもとれると言われるような試験でも、「行動を起こして受験する」というのが何よりもハードルが高いので、色々な資格持っている人は本当にすごいと思います。 持って無くて、あーだこーだ言うのは負け惜しみにしかならないし。

スペシャリストを狙う場合は、「セキュリティ」が最優先とのこと。 他のスペシャリストでも問題が重複するし、まずは抑えるべきと。 なにはともあれ、Black Belt の熟読は必須っぽいです。

「SAP が一番難しいけど役に立つ」とのことでした。 自分がまず目指すのは、アソシエイト3冠かな。 SAA の内容忘れる頃に、復習のため他のアソシエイト検討して再勉強しよう。

アーカイブはこちら

www.youtube.com

CloudFront のログを Athena で日付指定して検索

AWS

CloudFront のログを検索するのに Athena の利用はよくすると思います。
日付を検索するのに少しコツが必要だったので、備忘録メモです。

参考ドキュメント

docs.aws.amazon.com

日付検索の注意点

次のクエリでは、2018 年 6 月 9 日～6 月 11 日に CloudFront で処理されたバイト数を加算します。date 列名は予約語であるため、二重引用符で囲みます。

SELECT SUM(bytes) AS total_bytes
FROM cloudfront_logs
WHERE "date" BETWEEN DATE '2018-06-09' AND DATE '2018-06-11'
LIMIT 100;

date 列名は予約語であるため、二重引用符で囲みます をちゃんと調べずにクエリを叩いて失敗してしまいました。
CAST を利用した場合は、二重引用符で囲まなくても問題なさそうです。

date >= CAST('2019-05-01' AS TIMESTAMP)

CAST の参考にした Qiita 。

qiita.com

独自ドメインが利用できず CloudFront から S3 にリダイレクトされてしまう

AWS

独自ドメインを指定した CloudFront から S3 のデフォルトドメインにリダイレクトされてしまう原因の備忘録メモです。

一般的な静的 Web サイト実装で Route53 - CloudFront - S3 を利用する構成での出来事です。

f:id:omron:20200603182259p:plain

CloudFormation で上記環境を作って、開発環境で無事動く状態になりました。
本番環境も、CloudFormation なら一発で同じリソースを作成できるので、CloudFormation スタック作ればすぐ作成完了！
と思ったのですが、できあがった URL にアクセスすると S3 のドメインにリダイレクトされてしまう現象が発生しました...

全く同じ設定を使ってるはずなのになぜだ？と公式ドキュメントを探すと原因が判明しました。

aws.amazon.com

Amazon S3 バケットを作成後、そのバケット名がすべての AWS リージョンに伝達されるまで、最大で 24 時間ほどかかる場合があります。

これが原因であれば、同じ設定をしているのに動作が違うことについて、納得できます。
しばらく放置しているとちゃんと Route53 のドメインでアクセスできるようになりました。

急いでいる場合は、明示的にリージョン指定すると良さそうです。

バケットを作成後 24 時間以内に Amazon S3 にアクセスする必要がある場合は、バケットのリージョンのエンドポイントが含まれるように、このディストリビューションのオリジンドメイン名を変更します。たとえば、バケットが us-west-2 にある場合は、オリジンドメイン名を bucketname.s3.amazonaws.com から bucketname.s3-us-west-2.amazonaws.com に変更することができます。

公式ドキュメント優秀ですね。
だいたい調べたいことが見つかります。
前回の記事 と同様で、「何もしてないのに直った」という時間が解決することが AWS では稀によくあります。

Lambda@Edge が削除できなかった

AWS

Lambda@Edge の削除ができなかったのでその原因の調査メモ。

Lamda@Edge は、バージニアリージョンで作成する必要があるため、その他のリソースと CloudFormation のスタックがわかれてしまい、依存関係が発生して削除がしにくい状況になりがちです。
依存するスタックの更新をして、CloudFront から削除されていることを確認後、Lambda@Edge 関数を削除しようとしたけど、エラーになり一向に削除ができませんでした。

すでに参照されてないのに削除できない原因を調査するために、公式ドキュメントを検索。

Lambda@Edge 関数を削除できるのは、関数のレプリカが CloudFront によって削除された場合のみです。 ... レプリカは通常、数時間以内に削除されます。Lambda@Edge 関数のレプリカを手動で削除することはできません。

マネジメントコンソールで、CloudFront の Status が Deployed になっていても、「Lambda@Edge 関数のレプリカ」というのが内部的に残っている模様。
関数レプリカという状態になるのを初めて知りました。

マネジメントコンソールだと、Deployed と表示され、処理が終わってるように見えるから騙されてしまった。
ドキュメントに従い、おとなしく小一時間まったら無事削除ができました。

「JAWS-UG CLI専門支部 #155R EC2入門」受講で知った AWS コンプリータ

勉強会 AWS

jawsug-cli.connpass.com

皆さん大好き EC2 です。
資料は connpass からリンクされている こちら 。

前回の S3 入門の記事は こちら

AWS コンプリータ

ハンズオンに入る前に話題にできてた AWS コンプリータなんですが、これ全く知りませんでした。

docs.aws.amazon.com

bash – 組み込みのコマンド complete を使用します。

$ complete -C '/usr/local/aws/bin/aws_completer' aws

AWS コンプリータを設定すると、大量にある aws コマンドのオプションがタブ補完が効くようになります。
自身の環境（ macOS ）を検索するとちゃんと /usr/local/aws/bin/aws_completer に実行ファイルがありました。
bash を利用しているのであれば ~/.bashrc に設定すれば、次回以降補完が効くようになります。

$  echo "complete -C '/usr/local/aws/bin/aws_completer' aws" >> ~/.bashrc

上記を設定してターミナルを再起動したあとは、例えば $ aws e でタブキーを叩くと

$ aws e
ec2                 elasticache         emr 
ecr                 elasticbeanstalk    es 
ecs                 elastictranscoder   events
efs                 elb                 
eks                 elbv2

ちゃんと補完候補がでてきました。
$ aws ec2 でタブを叩くと

$ aws ec2 
Display all 329 possibilities? (y or n)

accept-reserved-instances-exchange-quote 
accept-transit-gateway-vpc-attachment 
accept-vpc-endpoint-connections 
...

と、ちゃんと ec2 のオプションが大量に出てきました。

恥ずかしながら 20 年コマンドラインを叩いているのに bash の組込コマンド complete も知りませんでした。
bash の補完に使うコマンドなんですね。

所感

肝心のハンズオンをすっ飛ばした感想で申し訳ないんですが、このような思いも寄らない知見を得れるのは、勉強会に参加する喜びの一つですね。
ハンズオンも知ってることは多かったものの ユーザーデータの作成 とかは、普段使わないのでもちろん勉強になりました。
ユーザーデータで、「EC2 起動時に内部で aws コマンドを叩いて自身で EIP を設定するようにするのとかエモくないですか」（実際に話した言葉とは違うので雰囲気だけはこんな感じだったかと）はとても共感できました。
能動的に EC2 が自身の設定をしていくのすごいエモい。

Draw.io めっちゃ便利

ポエム

PlantUML の記事のときにも書いたのですが...
図を書くときは Cacoo のみ利用してました。

少し前に Qiita で VSCodeでDraw.ioが使えるようになったらしい！ という記事がバズったので、 PlantUML よろしく VSCode プラグインで導入して利用し始めました。
導入方法は Qiita などまとめているところが多いのでそちらを参照ください。

PlantUML を使ったときとほぼ同じ感想になってしまうのですが、無料かつローカルで簡単に利用できるのは素晴らしいですね。
AWS 構成図を書くことが多いのですが、Draw.io での作図で基本的に問題なさそうです。

Cacoo と比べて気になるところは少なからずあります。

  • Cacoo よりも重たい感じがする
    • 図が大きくなるとレスポンスがあまりよくない
  • 最新版 (v0.4.0) でエクスポートができなかった
    • v0.3.0 にダウングレードして解決
  • コラボレーションがすこしめんどくさい
    • VSCode の LiveShare で一応できるんだけど...
  • コピペのショートカットが効かない
    • メニュー上は表示されてるんだけどなぜ？

気になるのは今の所この程度です。
.dio ファイルをそのまま Git で管理もできるし、 SVG 出力してしまえば、GitHub 上で簡単に表示もできます。
テキストで管理できるため、Git での差分管理ができるというのが、素晴らしい。
先日受講した Infra Study Meetup #2「VM時代の開発とCloud Native時代の開発」受講 でも、ハマコーさんが構成図の重要性を説いてました。

speakerdeck.com

リポジトリで、CloudFormation とともに AWS 構成図をドキュメントとして一括管理できるので、今後も活用したいと思います。

「JAWS-UG CLI専門支部 #154R S3入門」受講

勉強会 AWS

jawsug-cli.connpass.com

サービスの中心で必ずといってもいいほど使うことになる S3 です。 資料は connpass からリンクされている こちら 。

前回の SNS 入門の記事は こちら

ハンズオン

基本的によく使っているコマンドだったので、自分用メモとしては省略。
Webホスティングは、S3 を直接公開することはせずに、CloudFront + ACM でドメインを振った上でアクセス制限を行っております。
そのため --acl public-read について初めてでした。
簡易的に公開するのには便利ではありますが、不要なものを公開しないようにして事故には注意する必要があります。

所感

今回一番すごいと思ったのは、新たに準備された ハンズオンガイド です。
少し引用します。

  1. 「完了すること」を最優先すること。 (全体把握)
  2. 必ず復習すること。(インプット)
  3. 自分なりにカスタマイズしてオリジナル手順にしてみること。 (アウトプット)

どれも大事ですが

「ハンズオンでおいていかれたときの絶望感がすごい。そのため完了を最優先としすべてコピペで完了するようにしている。」

ということを言っておられました。
これにはとても共感できます。
ハンズオンでおいていかれたときの絶望感は本当に辛くて、終了までただ眺めるだけの状態になったことが過去何度かあります。
こういった人をケアするための準備がとても素晴らしいと感じました。