【ハンズオン参加レポ】「AWSの基礎を学ぼう 特別編 最新サービスをみんなで触ってみる はじめての位置情報サービス」に参加しました
はじめに
本日は毎週土曜日恒例のAWSハンズオンに参加しました。
今日はAWS Location Serviceという名前も初めて聞いたサービスのハンズオンでした。
調べてみたら正式ローンチが2021年6月という直近でリリースされたサービスでした。
いつもはさらっと全体の流れとハンズオン内での感想を記事にした参加レポ形式での投稿でしたが、今日は再度ハンズオンをやり直しながら振り返りをする、そんな投稿にしてみます。
事前準備
下記のGitHubから資材をダウンロードしましょう
https://github.com/harunobukameda/Amazon-Location-Service:embed:
→リポジトリをローカルにgit cloneするのが一番早いと思います
ハンズオン
今回使用するハンズオンのシナリオはダウンロードした「location service workshop」をつかって進めていきます。(PDFでもドキュメントでもどちらでもOK)
概要
ハンズオンのシナリオをまとめると下記の流れになっています。
- Amazon Location serviceで地図(Maps)を作成
- 認証基盤の作成
- 地図を埋め込んだHTMLの作成とホスティング
- Location ServiceでGeo Fence機能を実装
- Location ServiceでTrackerを作成
- Lamda関数を作成
- IoT coreのルールアクションを設定
- IoT CoreのからMQTTテストクライアントからテスト実施 `
項目を並べていても少しイメージしづらいと思うので、実際にハンズオンを復習したときのキャプチャを見ていきましょう！ 手順通り実施していくと、ざっとこんな感じのものができますよというくらいのスクショを貼り付けています。
ハンズオン実施
リージョンはバージニア西部でやっていますが、基本Location Serviceがサポートしているリージョンならどこでもできるかと思います。
1. Amazon Location serviceで地図(Maps)を作成
地図の名前をつけ、地図の種類を選択
リクエストベースの課金を選択
地図が作成できた
2. 認証基盤の作成
Cognito IDプールを作成する
※「認証されていないIDに対するアクセスの有効化」をやっておくこと
IDプールと同時にCognito認証用のIAMロール(認証必要版と不要版の2種類)が作成される。
認証不要版のロールに、1で作成したMapにアクセスできるポリシーをアタッチします。
3. 地図を埋め込んだHTMLの作成とホスティング
ダウンロードした「test.html」を手順通り修正し、作成したS3バケットにアップロードする。
アップロードしたオブジェクトのパブリックアクセス許可の設定を行う。
バケットのアクセス許可設定→オブジェクトのアクセス許可設定の順番で設定します。
アクセス許可設定後、オブジェクトのURLにアクセスし地図が表示されたら成功！
4. Location ServiceでGeo Fence機能を実装
https://geojson.io/で任意の位置情報を取得する。
今回は京都御所の付近にしてみた。
最寄りの駅にピンを落とし、座標をメモ。
駅を囲うように領域を作成し、出力されたJSON全体を「geo.json」として保存。
領域外にピンを落とし、座標をメモ。
Location serviceのマネコンでGeo fence collectionを作成し、Geofenceを追加。
メモった座標が問題無ければ登録できるはず
5. Location ServiceでTrackerを作成
Trackerを作成し、4で作ったGeo FenceとLinkさせる
6. Lamda関数を作成
LambdaからLocation ServiceにアクセスするためのIAMロールを作成する
→Locationサービス用のIAMポリシーがないため、Administartorアクセス用のポリシーを使用する(強すぎる権限のためほんとは良くない)
Lambda関数を作成する
→実行ロールに既存のロール→先程作成したロールを指定する
コードソースのlambda_function.pyに「lambda.txt」の中身を貼り付け、deployする
→7行目のTRACKER_NAMEの変数を作成したTrackerの名前に書き換えておく
7. IoT coreのルールアクションを設定
IoTCoreのマネコンからルールアクションを設定する
→「1つ以上のアクションを設定する」で6で作成した関数を設定する
→手順書の「SELECT * FROM 'iot/location'」の一番うしろの「'」が全角になっているので注意！
Lambda関数側から確認するとトリガーにIoT Coreが設定されていることが確認できる。
8. IoT CoreのからMQTTテストクライアントからテスト実施
事前にCloudWatch logsの画面を出しておき、MQTTテストクライアントからトピックを公開する
はじめに領域内側の位置情報を入力したもの、次に領域外の位置情報とタイムスタンプを変更したものでテストを実施する
CloudWatch logsのストリームで「Enter」「Exit」のログが確認できる
お片付け
下記サービスを削除します
※手順ではCognito IDプールが不足してます
- Cognito IDプール
- Location Service
- Trackers
- Geofence collection
- Maps
- Lambda関数
- S3バケット
- IAMポリシーとロール
- AWS IoT Core
- ルール
以上、ハンズオンの復習を実施しました。
気になった方は、ぜひハンズオンでサービスに触れてみてください。
最後に、の前に個人的にハマったところや参加者の方がハマっていた点がいくつかあったので、紹介したいと思います。
はまったところ
1. 位置情報の指定時のミス
- 緯度経度の指定を逆にしてしまって、エラーになったそうです。
- locationで指定しているlat、longは、latitude(緯度)とlongitude(経度)の略なので、逆にしてしまうと地球に存在しない座標になってしまいます。
{
"payload": {
"deviceid": "GPS-Device-001",
"timestamp": 1608166810,
"location": {
"lat": 35.0302,
"long": 135.7594
}
}
2. タイムスタンプの更新
- IoT Coreのテストクライアントを何度か実行したときは、実行に失敗したときでもタイムスタンプを更新し続けないとNG
- 時間を置いたときは10刻みだとだめだったので50くらい増やしたりした
- タイムスタンプを厳密に監視しているようです
↑このタイムスタンプってなんなんだ？？って思って調べてみた
https://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/life-cycle-events.html
timestamp イベントが発生した時間の近似値 (Unix エポックからのミリ秒単位)。timestamp の精度は +/- 2 分です。
→ うーん謎。実際の時間じゃなくて相対的な時間ってことなんかな。
(7/18 21:17 追記)
亀田さんからTwitterで返信頂いた。
→相対的な時間と勘違いしていたが、逆でエポックタイムは絶対時間だった。基準値から何秒後とかそういったケースで役に立つのでiot系システムでよく使われるみたいですね。ありがとうございます！エポックタイムは、閏秒などに左右されない絶対時間として機能するので、iot系のいろんなシステムで使われます。単純に基準値から何秒だったかを知りたいだけなケースがあるのど、数学的に大きい方が後の時間ととても明快です！
— kame (@kame92782224) 2021年7月18日
3. Geo FenceとTrackerのリージョン間違えでLambdaの実行エラーになっていた。
- 初回実行だとLambda用のロググループが作成されなく、エラーが検知できないのでLambdaコンソールからテストを実施し発覚した。
4. TrackerのLink忘れ
- 再作成したときにTrackerとGeoFenceのLinkを失念して、Location ServiceのCloudWatch logsに出力されなかった。
最後に
本日は新しいサービスのAmazon Location Serviceだけでなく、IoTについても少し学ぶことができました。
IoTというワードは興味がないわけではなかったですが、実際どんな技術なのか、どんな事ができるのかわかっていなかったので、身近に感じることができた気がします。
今回は仮想Trackerを使用しましたが、IoTデバイスがあれば実際の位置情報を使用することももちろん可能なので持ってる方はやってみてはどうでしょう？
1万円前後から買えるようなのでみたいなので、そのうち欲しくてたまらなくなったら買うかもしれません笑
【ハンズオン参加レポ】「AWSの基礎を学ぼう 特別編 最新サービスをみんなで触ってみる AWS App Runner」に参加しました。
はじめに
毎週土曜日の日課で、今週もAWSハンズオンイベントに参加しましたので、参加レポートを書いていきます。
今日はLTの参加者が多くチャット欄も盛り上がってました。
ハンズオン編
ハンズオンまとめ
App Runnerは爆速でWebアプリをデプロイできる
→リージョン負荷状況、アプリのサイズにもよる
リリース直後のサービスのため、まだまだ制約がたくさんある
→詳しくはGithubのロードマップを確認しよう
App Runnerについて
- コンテナアプリケーションを簡単にデプロイ可能
- デプロイ方法：
- ECR or GitHub
- 対応リージョン：
- 料金体系：
- コンテナプロビジョニング料金
- アクティブコンテナ料金
- 自動デプロイ料金
- ビルド料金
ハンズオン実施概要
今日のハンズオン資料は下記主催の亀田さんのGithubのPublicリポジトリで公開されています。
https://github.com/harunobukameda/AWS-App-Runner
1. ECR/GithubにWebアプリ(Dockerイメージ or ソースコード)をアップロードする
Github接続は下記のような機能で実装されているようです
App Runner は、アカウントに「AWS Connector for GitHub」というアプリをインストールすることで、ソースコードをデプロイします。このアプリは、メインの GitHub アカウントまたは GitHub 組織にインストールできます。
2. App Runnerからアプリケーションをデプロイする
- CPU/メモリ：
- 1-2 vCPU
- 1-4 Memory
- まだ小さいものしか選択できないので今後のアップデートに期待
- デプロイトリガー：自動
- ソースに更新があった場合に自動でローリングアップデートしてくれる
- ヘルスチェック：
- /(スラッシュ)にたいしてTCPで疎通を行う
- アプリによっては意識しないといけないかも
3. デプロイ完了
- 発行されたドメイン(CNAME)から、Webアプリにアクセス可能。今回はHello World!!が見えるとこまで
- ログ：設定なしで見ることが可能、CloudWatchLogsへ自動で登録される
学んだことやTipsなど
VPCに組み込めない
- ロードマップ上には記載されているので、そのうち対応されるかも
- App RunnerのGitにロードマップあります！
https://github.com/aws/apprunner-roadmap/issues
- ざっと見た感じ「VPC統合」「サーバレス化」のISSUEが盛り上がってます。
- コメント数多い=早く実装されるではないかと思いますが。。
- ex). RDSとApp Runnerを接続したい場合は？
App Runner以外のこと
- ECRのTagについて：
- コンテナを扱うときはTagをつける(一般的にはlatest)
- 実際に運用する場合、 latest運用だと辛いので、コンテナイメージのtag = gitなどのコミットID にするとトレースが楽
LT編
今週は、3名の方のLTがありました。
いつもより盛り上がった！気がします。
LT①：App Runner + Copilot Pipeline
Speaker:：おぎさん
まとめ
- コンテナ環境のデプロイを簡単にできる
- App Runnerへのデプロイにも対応した！
- マネコンポチポチでやった手順が、copilot initで一発でいける
- 「copilot pipeline init」を使えば、Codeシリーズを利用したCI/CDパイプラインを自動構築できる
注意点
- copilot initを実行時点で空のECSができる
- App runnerのVPC対応を見越しているのか？
- App RunnerとCodeBuildでDockerのバージョンが違う
- 1ステージ=1VPCになるのでVPC運用に注意
LT②：AWS App RunnerでASP.NET Core Webアプリケーションを動かしてみた
Speaker：木村さん
www.slideshare.net
まとめ
- App Runnerは超優秀
- 手軽にWebアプリを動かすPaasとして優秀
- .NETアプリも動く
- 他言語のCI/CDもやりたい
- ちょっと高い
Tips
- 環境変数設定時には「：」は「__(アンダーバー2つ)」で表す ※EBも同じ
LT③: App Runner + Railsで詰まったこと
speaker：水本さん
まとめ：苦労したところ
まとめ：よかったところ
- デプロイが楽
- ログが見やすい
- CloudWatchログとの自動連携
2021年6月の振り返りと7月の目標設定
はじめに
今月も振り返りと目標設定やっていきます。
6月の目標と振り返り
6月の実績
- AWS DVAに合格する
- 6/26に受験し合格！
- イベントに4回参加する
- ブログ等へ技術系記事を2本書く
- 技術系記事は書けませんでした。
- 本を2冊読む、技術系を最低1冊
- 読みきった本はなし、積ん読が倍増(2冊→5冊)
6月の感想(というか反省)
全体的に目標未達成、遅延完了が目立ったので今月は反省会。
6月はDVAの受験日を遅らせてしまった(6/12→6/26)ことにより、他のタスクに集中できなかったと考えられる。 今後は可能な限り受験日は遅らせず、もし遅らせたとしても他タスクも遂行できるようにやり方を考えたい。
- イベントの参加回数は多だが、アウトプット(感想レベル)がほぼ無
イベント参加時のメモはたくさんあるが、その日に記事としてあげる！をしなかったせいで、記事化する気力を失っていった。 来月はイベント参加→その日のうちに記事化を徹底してみる。 絶対やらなければいけないとまでは思わないが、習慣づけはやっておきたい。
- 技術系記事書けてない問題
そもそもあまり手を付けられてないのが問題なので、まずは1つ目から書いてみよう。
- 読書
これも進まなかった。(むしろ積ん読が増えた) 技術系の本も頂いたり買ったりしたので、書評を技術系記事として上げるのもいいかも。 とにかくまずやってみる、を徹底したいです。
7月の目標
- イベントに4回参加する
- イベント参加→その日のうちにアウトプット
- ブログ等へ技術系記事を2本書く
- まず1つ書く。技術系書評もあり。
- 本を2冊読む
- 技術系を最低1冊
- 8月の学習予定を立てる
- 1ヶ月有給消化期間になるので予め目標を立てておきたい。
さいごに
学習面で反省が多い月でした。 来月もがんばります。
【参加レポ】「AWSの基礎を学ぼう 特別編 最新サービスをみんなで触ってみる Network Firewall」に参加しました
はじめに
平日の疲れのまま突入してしまい１日を無駄にしがちな土曜日は、ハンズオン&アウトプットするに限る！
ということで昨日は下記のイベントに参加しました。
例のごとく、振り返りも兼ねて、参加レポートを書いてみました。
今日何をやったか
下記構成図のような、NetworkFWで制御したVPC環境を構築する(すべてマネコンから)
- 外部Internet→InternetGW→NetworkFW→EC2の環境を構築。
- NetworkFWのIPSルールを設定。
- すべての通信をalertとしてCloudWatchLogsへ出力する。
- すべての通信を拒否(drop)する。
Tipsまとめ
- RouteTableの設定変更を行うときは一旦サブネットの関連付けを解除する必要がある。
- そのままだと設定変更できないよ。
Suricataとは
- OSSのIPS(侵入防止システム)
- AWSのマネージドサービスでいうとNWFW
- 独自の記法でルールを書ける。 参考：dev.classmethod.jp
- OSSのIPS(侵入防止システム)
ALBとIPSを併用する場合は、L7制御したい場合はWAF、L4までならNWFWという使い分けができる。
感想
- VPCまわりのNW特有の複雑さがややこしい。
- 手順通りやっただけでは迷うところがあったので、絵に書いてみたところ少し理解は深まった。
- 実際より複雑な環境を設計する際にはもっと難しそう。
- マネコン操作でハンズオンをやるのはきつい。
- CloudFormationやCLIから操作をすることに慣れてきていたので、マネコン操作の取り回しのしづらさに改めて気づいた。
- 主催の亀田さんもマネコン使用の手順書は作りたくないとのこと。
- とはいえ、よくわからなくても動かせるので「まず触ってみる」には適した手法だと思った。
- CloudFormationやCLIから操作をすることに慣れてきていたので、マネコン操作の取り回しのしづらさに改めて気づいた。
- とりあえず触ってみるはすごい。
- ちょっとわかった気になって、次回以降の学習ハードルが下がる。
- 毎回思うけどあえて書いとく。
2021年5月の振り返りと6月の目標設定
はじめに
5月の末日になったので、前回設定した目標に対して実績がどうだったか振り返りと、6月の目標設定を宣言します。
5月の目標(振り返り)
5月の実績
AWS SysOpsに合格
- 目標達成！
Zennの記事は...0本
- 目標達成ならず...だが、はてブロに記事を4本投稿(ハンズオンや勉強会)
- 目標達成？(一応)
- ブログ記事の内容
- 【勉強会メモ】AKIBA.AWS ONLINE #03 -IaC を語りたい 編- に参加しました
- 【ハンズオン参加レポ】JAWS-UG CLI専門支部 #179R AWS CLI環境入門(Cloud9)に参加しました
- 【ハンズオン参加レポ】「AWSの基礎を学ぼう 特別編 最新サービスをみんなで触ってみる はじめての可観測性」に参加しました
- 【ハンズオン参加レポ】JAWS-UG 初心者支部#37 codeシリーズハンズオンに参加しました
- イベント参加→ブログでアウトプットを始めてから、内容の定着率がより鮮明になったのを感じるので、これからも継続していきたい。
- 6月はイベント参加レポだけでなく、やってみた系記事も書いてみよう。
- 目標達成ならず...だが、はてブロに記事を4本投稿(ハンズオンや勉強会)
- 本は2冊読んだ
5月の感想
2021年5月は、個人的には、上旬のSysOps取得の達成感から勉強や読書といったインプットにあまり集中できず、ダレてしまったところ自覚があったのですが、下旬にかけて意識的にハンズオンやイベントに参加することにより、インプット/アウトプットを強制されたことがいい方向に働いたなと思いました。
結果的に、アクティブに過ごせた月にできたと思います。
6月はよりアクティブにエネルギッシュに過ごせるように追い込んでいきたいと思い、目標設定してみました。
6月の目標設定
おわりに
先月宣言した通り、振り返りを継続できました。
来月もしっかり振り返りやります。
【ハンズオン参加レポ】JAWS-UG 初心者支部#37 codeシリーズハンズオンに参加しました
Speaker：亀田さん Lambdaはステートレスかつイベントドリブンを意識、冪等性も意識する とはいっても夜間バッチしたい人へ Amazon Managed Workflows for Apache Airflowの略。下記のことが実現できるそう。 Airflow を迅速かつ大規模にデプロイ 運用コストの削減 ビルトインセキュリティで Airflow を実行 参考：https://aws.amazon.com/jp/managed-workflows-for-apache-airflow/ Airflowをたくさん作れるらしい！ Airflowとは？？？ Apache Airflowはいわゆるワークフローエンジンと言われるツールの一種で、
複数のタスクの実行順序を定義するワークフローの作成、実行のスケジューリング、監視などを行うことができます。 参考：https://dev.classmethod.jp/articles/airflow-getting-started/ CloudFrontの料金は間違えがちだよ、という話でした。 Speaker：織田さん 東京リージョンにCodeシリーズを利用したCI/CDパイプラインを構築する 参考) リンク生きていれば下記が実施した手順です https://shigeru-oda.github.io/code-handson-20210527/#0
LT：AWS勉強中に勘違いしがちなこと＠Part2
①Lambdaはバッチ処理基盤？
そもそもLambdaってなんだろう
バッチ処理ってそもそも何？
まとめ
②CloudFrontの料金の話
まとめ
③インススタンスストアとは？
EC2インスタンスのストレージの種類
EC2の構造
まとめ
ハンズオン：Codeシリーズハンズオン
ゴール
実施手順
やったこと
1回目：CodeStarを使ってCodePipelineを構成
2回目：手動でサービスそれぞれの構築を実施
少しだけハマったところ
ハンズオンの感想
【ハンズオン参加レポ】「AWSの基礎を学ぼう 特別編 最新サービスをみんなで触ってみる はじめての可観測性」に参加しました
初めに
今日はAWSエバンジェリストシリーズの「はじめての可観測性」というハンズオンに参加してきました。
例のごとく、メモをもとに参加レポートを書いてみました。
いきなりまとめ
New Relicさんのお話
Speaker：New Relic 清水さん
ゴール
Spaker紹介
- Eコマースの会社(Works Applications)→AWS→New Relicの経歴
- なぜNew Relicなのか？
- 運用をサポートしたい
- みんながやりたいことは監視ではなく、本業に集中したい
- なぜNew Relicなのか？
- New RelicとAWSの関係：深い
可観測性ってなに？
- 監視って何？
- 旧来はサーバ自体の監視
- サーバ監視だけだとうまく行かないことが多い
- サーバの状態からMWの状態をなんとか追うことはできるが、、、
- 現代はより複雑化
- 本当に解決したいことは問題は、サーバの監視だけじゃわからないよね
- 可観測性=常にシステム全容の状態把握と改善ができる状態
- オブザーバビリティの範囲：広い
- 全部見ることはできるが、広すぎる
- インフラだけじゃなくてビジネスも全部見れる
- New Relic オブザーバビリティプラットフォーム
- フロントからエンドまで全てを観測
- 全レイヤーで可視化できる
- オブザーバビリティの範囲：広い
- 旧来はサーバ自体の監視
クラウドオブザーバビリティの今とNew Relic
New Relicの公式ページ：https://newrelic.com/jp/platform
デモ
- 複数アカウントのCloudwatchの監視を一元で可能
- 視覚的にCPUが上がったホスト、メモリ使用率が上がったホストを確認できる
- モバイル用のAPIでどのURLでエラー率が上がったか、まで追跡できる
- エラー毎にチケット管理できて、担当者も設定できる
- フリートライアル：1ユーザ100GBまで無料
質問
ここまでの感想
ハンズオン
Speaker: AWS 亀田さん
目的
CFnやCDKを使用し可観測性のあるEKS環境を構築し、CloudWatch、X-Ray等のサービスを使用して構築したシステムの状態を監視する
事前準備
CFnでCloud9環境を構築
参考：https://github.com/harunobukameda/Observability
- Cloud9はデフォルトで10GBのEBSを作成するが、今回のCFnでは30GBへリサイズを行う
- Cloud9環境で構築する
- CDKをBootstrapする
- EKS環境を構築する
本題
- CloudWatch ServiceLens
-
- 遅延やエラーを視覚的に判断できる(色や円の大きさ)
- トレース
- サービスマップからトレースの内容を表示させる
- エラーが発生していた場合、エラーの詳細も確認できる
- APIコールの内容も確認できる
- エラーが発生していた場合、エラーの詳細も確認できる
- サービスマップからトレースの内容を表示させる
- アナリティクス
- どのURLで遅延が発生しているか？を確認できる
- どのURLで遅延が発生しているか？を確認できる
- 遅延やエラーを視覚的に判断できる(色や円の大きさ)
CloudWatch Contributor Insights
CloudWatch Synthetics
CloudWatch Container Insights
- 確認する対象のコンテナを選択し、監視対象に追加すると下記が確認できる
- クラスター毎の稼働状態
- 今回構築した環境のコンテナ全体像マップ
- 確認する対象のコンテナを選択し、監視対象に追加すると下記が確認できる
CloudWatch Lambda Insights
- Lambda関数全体の実行状態をグラフで確認できる
- 画面下部の詳細のTraceからLambdaのメモリ使用率が確認できる
- メモリ使用率が100%を超えているのはメモリ不足でキャッシュしているから？(説明聞きそびれました。。)
- Lambda関数全体の実行状態をグラフで確認できる
CloudWatch Anomaly Detection
CloudWatchのメトリクスから、特定のメトリクスの異常検知を有効化し、メトリクスの傾向と、時間/日/週単位のパターンの両方を２週間学習させることができる
※メトリクスに 2 週間分のデータが揃っていなくても、メトリクスの異常検出を有効にすることができる- メンテナンス日の指定や異常しきい値の手動指定もできる
- メンテナンス日の指定や異常しきい値の手動指定もできる
ハンズオンの感想
- X-rayについて直感的に理解できた
- SysOps Administratorの試験で概要は知っていたが、ハンズオン形式で体験したのは今回が初めてで、視覚的に理解が深まった
- 使ったことがなかったCloudWatchの機能を学べた
- CloudWatchは基本的な機能(メトリクス、logs、Event)しか扱ったことがなかったので、サービス全体を体験でき、概要を掴むことができた
全体の感想
New Relicさんのプレゼンを通じて、可観測性について理解が深まった
ハンズオンでは、普段のハンズオンや環境構築では、とりあえず詳細モニタリング有効にしておく、とかCloudWatchAgent入れておく、とかくらいで、CloudWatchのサービス全般を使ってみたことはなかったのでかなりいい経験になった。
エバンジェリストシリーズに初めて参加したが、「はじめての」とついている割に濃密なハンズオンで自分にとって負荷も高かったが、終わってみれば良いストレスだった。
以上
