【AWS】AWS認定ソリューションアーキテクト-アソシエイトに合格しました

AWSのソリューションアーキテクト(アソシエイト)を受験し、無事合格することができました。巷には、この試験の合格談がいくつもアップされていますが、例にもれず本サイトでも合格にいたるまでのプロセスを一つの例としてまとめてみたいと思います。

点数

連絡待ち

予備知識

  • AWSクラウドラクティショナーの基礎知識(デジタルコース)を受講
  • AWS Architecting on AWSレーニングを受講
  • ルンバの位置監視サービスで少しAWSを触る
  • 実務でのAWSの利用経験はなし

勉強方法

  • AWSの参考書を読む
  • AWS模擬試験を受ける
  • 書籍のAWS問題集を解く
  • UdemyのAWS問題集を解く

勉強期間

 1ヶ月半程度(8月中旬~9月下旬)

受験までの流れ

まず、予備知識として無料のセミナーやAWSのトレーニングによって、AWSが提供するサービスについてある程度の概要は掴んでいた感じです。また、以前投稿したルンバの位置監視サービスを作った経験から、LambdaやDynamoDBなどのサーバレスのサービスについては、具体的な使用イメージを持っていました。 そこから、AWSのトレーニングの復習と範囲外の内容を学習するため、問題集を購入し、勉強をはじめました。購入した本は↓になります。AWSのサービスについて網羅的に書かれていて内容も分かりやすかったと思います。寝る前に1時間位読むを毎日繰り返していた感じです。

テキストを大体2周くらいしたタイミングで、実力を測るためAWSの模擬試験を受けました。結果は、52%で芳しくない結果に。振り返ると、参考書でサービスの概念はなんとなく押さえていましたが、少し踏み込んだ仕様を押さえていなかったので、試験の中で問われるサービス構築のために必要な対応を導き出すことができなかったのだと思います。この点、参考書だけで合格するのはかなり難しいと感じました。

そのため、問題を繰り返す解くことで実践力をつけようと考えましたが、これだという問題集が書籍やWebでも見つからなかったというのが正直なところです。結局、こちらのAWS問題集(AWS)で勉強することにしました。こちらの問題集を、結果として受験までに2周しました。問題数もそこそこあり感覚を掴むのに役立ちましたが、書籍というメディアのため、将来的には情報が古くなることが気がかりです。

書籍だけの勉強では、問題数とカバー範囲に不安を感じ、UdemyのAWS模擬試験を解きました。こちらは難易度が高めという紹介があり、試験で出される問題の難易度の上限を確認する意味でも取り組む価値があると考えました。実際に受けたところ、確かに難しい。高難易度の模擬試験は正答率5割程度でした。この模擬試験を受けて、解説内容で復習することで応用力は付いたと思います(その後、書籍の問題集に戻って解いたところ簡単に感じた)。ただ、高難易度の模擬試験⑤を受けたところ、試験範囲から外れた問題が多く出てきたような感じがしたので、そこでこの模擬試験を使った勉強は打ち切りました。

www.udemy.com

受験した感想

テストセンターで受験しました。受験の感想としては、問題の日本語がわからないことが予想以上に多かったです。英語の原文を読んで問題を理解することを何回もしました。問題の内容としては、参考書や問題集でカバーしていない問題が何問か出ましたが、多くの問題は問題集でカバーされている内容であり、繰り返し問題集を解いてパターンを押さえておけば答えられるという印象でした。

人に伝わるパターンとは

パターンを開発チームに浸透させていくには、どうしたらいいか、ここで仮説として思うのは、分かりやすい言葉でパターンを記述するのはもちろんのこと、文体を読みやすいように工夫することも必要なのではないか、ということです。

上司の部下に対する接し方として、一緒になって課題を考えてあげるいわゆる伴走型の上司が求められていると言われて久しいですが、パターンについても同様のことが言えるのではないか。

というのは、パターンは、ある比較的熟練者が他の人にノウハウを伝達する目的で作ります。そう考えると、パターンを記述する人には技術的あるいは知識的優位に立つという前提が生まれ、そこには意識するしないに関わらず上下関係が生じることになります。

もちろん、学会などの正式な場でパターンを発表するという時には、型に則った形で整理するのが良いと思います。それとは別に、特にチームで一緒に働いているメンバーに対して知識を共有するには、先の伴走型のようにパターンを通じて一緒に分かち合おう、という意思が伝わるものが良いのかなと思うのです。体温の伝わるパターン、でしょうか。

体温の伝わるパターンとは、どのようなものでしょうか。パターン記述の型や文体、色々な観点がありそうです。最近はこんなことを考え始めています。

パターンに関しては、慶應大の伊庭先生が長年研究をされています。伊庭先生の研究室の学生をメンバとしたコラボレーション・パターンを拝見したのですが、人に伝えようという意識が伝わるパターンに感じました。

人に伝わるパターンというのは、どのようなもので、どう書くのか。このあたり、どこかで時間をとって考えてみたいなと思います。

【AWS】【AWS IoT Core】【やってみた】ルンバが本当に掃除しているのか監視するアプリをつくってみた(番外編)

 前回の投稿で作成した、「ルンバの位置監視サービス」開発の番外編になります。ルンバの位置をどのように取得するかという課題を解決するまでの紆余曲折を書きます。ここは、開発技術についての説明はありません。ただの苦労話といえば苦労話なのですが、実際の開発ではこういった泥臭い試行錯誤も必要なのだな、という教訓としてここに記録を残しておきます。

 前回の投稿はこちら。

highitoh.hatenablog.com

ルンバの位置をどう検知するか

 サービスの実現にあたっては、ルンバの現在位置をどのように取得するかという問題を解決しなければなりません。ここに関しては、アプリをつくるという目的からは外れたところなので、なるべくさっさと終わらせたい気持ちが強かったのですが、ここでかなり手間取りました。

 センサでモノの位置を取得する方法について、Googleで色々と調べてみたのですが、なかなかこれだという方法がみつからない。一番想像しやすいGPSを使う方法は精度の観点で難しく、ビーコンを使う方法も同じく精度の観点で難しい模様。自動運転などで使われているLiDARは、難易度が高く設備も数十万と高すぎる。マップを作成して自己位置を推定する方法(SLAM)もあるようですが、専門的な知識がない人間には敷居が高すぎる。。

最初の有望株:NFCタグ

 そんな中、最初の有望株として見つけたのが、NFCタグを使用する方法。日常的には、交通系ICカードなどに利用されている技術ですね。スマートフォンNFCリーダがあるので、ルンバの上にスマートフォンを取り付けて、天井からぶら下げたNFCタグの下を通過したときに位置情報をクラウドに送信すれば実現できそう。ちょうど、改札でカードをピッとタッチするイメージですね。

 実際に、NFCタグを10枚買ってみて実現できそうか試してみたのですが、これがどうやら難しそうであることがわかりました。どこが問題かというと、検知範囲の狭さです。本当にNFCタグの真下をスマートフォンが通過しないと反応しないので、ルンバの現在位置を知ろうとすると大量のNFCタグが必要になります。一つのNFCタグの大きさは3cmほど。これを、ルンバが通りそうな場所に張り巡らせようとするとタグが何百枚、費用的にも数万円かかってしまいます。そして、使い終わったあとのタグを、一体どう処理したらいいのか。。。ということで、NFCタグを使った方法は却下となりました(まあ、なんとなくそんな予感はありましたが)。

f:id:highitoh:20210905134818j:plain
検証に使ったNFCタグ(左)。大きめのタグを買いましたが、それでも今回の目的を実現するには程遠く。。

QRコードを使った方法を思いつく

 手軽な実現方法はないのではないかと、半ばあきらめかけた時もありましたが、ある時QRコードを使った方法を思いつきました。スマートフォンにつけたカメラでQRコードを読み取り、そのデータを送信する方法です。この方法であれば、NFCタグで問題となった検知範囲の問題についても、ある程度の範囲であれば読み取ってくれそう。。

 この方法も最初はうまくいきませんでした。スマートフォンのカメラでQRコードを読み取ろうとすると、ルンバの移動スピードが速く読み取れないことがわかりました。どうやら、処理性能が足らないようです。また、読み取れたとしても、読み取ったデータをクラウドに送信する処理を、専用のスマートフォンアプリを開発して実現しなければならないため、目的がもはやスマホアプリ開発になってしまいます。

 ということで、カメラを使ってQRコードを読み取る方法も却下。検知性能が問題であれば、ということで、専用のリーダを使ったら良いのではないかと思い、思い切ってQRコードリーダを発注。Amazonで小型でポータブルで比較的安い(何万もしない)ものがあったので、これを使ってみることにしました。

https://www.amazon.co.jp/gp/product/B07T35G1QN/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1

 これがうまくいきそうでした。リーダーをルンバの速度で動かして、50cm離れたQRコードを読み取ることができました。リーダーの場合、カメラとは違って検知範囲が狭くなりますが、QRコードを複製してA4の紙に敷き詰めれば、広範囲での検知ができそうです。これは、NFCタグではできない解決方法ですね。

 また、読み取ったデータをテキストデータでBluetooth送信してくれることも魅力的でした。これであれば、デバイス依存のアプリを作ることなく、PC側で受け取ったデータを整形してAWSに通信してあげればよく、実装のコストも抑えられそうです。

 いろいろと試してみたところ、A4用紙に3×4にQRコードを敷き詰めて印刷すると、検知性能に問題がないことがわかりました。あとは、部屋の領域にID番号を割り振って、そのID番号に対応するQRコードをその場所に置いておけば、ルンバの現在位置を送信することができそうです。

f:id:highitoh:20210905133633j:plain
↑実際に部屋に張り巡らせたQRコードの一枚。このQRコードは"3"を表しています。

実際に動かしてみる

 実際に、部屋にQRコードを張り巡らせたときの写真がこちら。壁に梱包用の紐を付けて、途中にQRコードを印刷した紙を部屋のIDに併せてくっつけています。写真は部屋の一部ですが、実験中部屋はQRコードと紐だらけであり、ルンバは下を通り抜けるので大丈夫ですが、人が移動するのは厳しい状況。実際にルンバを動かしている時も、壁に付けていた紐が何度も取れてしまい、紐をまたぎながら修復しに行く、といったことを続けていたのでとても疲れました。

 とはいえ、一応想定通りルンバが下を通るたびにQRコードを読み取ってくれ、ようやくルンバの現在位置を取得することができました。当たり前ですが、この方法ではサービスが動いている間は部屋が使用できなくなってしまうので、実用化するにはこれ以外の方法を採用しないといけませんね。

f:id:highitoh:20210905134822j:plain
部屋に張り巡らせたQRコードの紙。この下をルンバが通ると、上部に取り付けたリーダーでQRコードを読み取ってくれる仕組みです

【AWS】【AWS IoT Core】【やってみた】ルンバが本当に掃除しているのか監視するサービスをつくってみた

 最近、クラウドの開発知識を得たくて、AWSの勉強をしています。勉強するにあたって、知識だけではなく、やはり実践的になにかのサービスを作ってみたほうが勉強になるだろう、ということでネタを考えていました。

 そこで、目に留まったのがルンバ。ボタンを押しただけで部屋の掃除を勝手にしてくれる優れものなのですが、どうも同じところばかり掃除しているように見える。。うちのルンバはスペックが低くカメラが付いていない機種なので、仕方ないといえば仕方ないのですが。。

 ということで、ルンバが実際にどこを掃除しているのかリアルタイムにわかるサービス(Roomba Police)を、AWSを使って作ってみた、というお話になります。

 作成したコードはこちらにアップしています。

github.com

f:id:highitoh:20210815210548p:plain
完成したルンバの監視画面。ベージュのエリアを掃除してほしいのだが。。

システム構成

 全体のシステム構成は下の図のとおりです。ルンバの現在位置は、部屋の位置IDを書き込んだQRコードを読み取ることで検知します。読み取った位置IDをクラウド側に渡すことで、ルンバの位置を監視する仕組みです。クラウド側は、IoT Coreの初級ハンズオンと同等の構成で実現することができました。

https://aws-iot-core-for-beginners.workshop.aws/

f:id:highitoh:20210815205137p:plain

 作成期間は、おおよそ4日程度です。AWSの使い方を勉強する目的で始めたのですが、結局ルンバの位置情報の取得方法(QRコード)の検討とブラウザでルンバの位置を表示するプログラムの実装に半分以上の時間を使った結果になりました。AWS側は、lambdaの実装をサンプルから大部分流用できたのが大きいですね。ただ、サービスを実現するための最低限の作業しかしていないので、IAMなどの設定を加えるとなると、もう少し時間がかかると思われます。

ルンバの位置登録

 ルンバに取り付けたQRコードリーダは、部屋にあるQRコードから位置IDを読み取ります。読み取ったデータは、BluetoothでPCに送信されます。QRコードリーダから送信されるデータは、標準入力でテキストデータの形式で受け取れるので、簡単に取り扱うことができます。

 PCでは、標準入力で位置IDを受け取り、それをMQTTでAWSに送信します。IoT Coreとの接続は、AWS IoT SDKを使う必要があります。Pythonを使用した実装方法は、下のページに詳しく書かれており、この内容を少し書き換えることで実装ができてしまいました。ファイル行数としても、50行強程度です。経験はないのですが、面倒なイメージのある証明書を使ったセキュアな通信を、こんなに簡単に実現できるのかと驚きました。

https://aws.amazon.com/jp/premiumsupport/knowledge-center/iot-core-publish-mqtt-messages-python/

 AWSに送られたMQTTのデータは、IoT Coreで時刻と位置IDが解釈され、バッファとなるKinesis Data Streamsに送られます。lambdaは、Kinesisからデータを受け取り、DynamoDBにルンバの位置情報を登録します。この処理は、IoT Coreハンズオンで使用されているPythonコードを改造して実装しました。これで、ルンバの指定時刻の位置をAWSに登録することができました。

ルンバの位置表示

 続けて、参照側の実現方法です。大きな流れとしては、WebブラウザからS3に格納したHTMLファイルにアクセスし、API GatewayREST API経由でDynamoDBに格納されたルンバの位置情報を取得して表示します。

 Webブラウザは、静的ウェブサイトホスティングを有効にしたS3にアクセスし、Webページを表示します。Webページは、一定時間おきにJavaScriptAPI Gatewayに対しHTTP GETを発行し、ルンバの最新の位置情報を問い合わせます。(今回は3秒おきで更新するように実装しましたが、あんまり更新頻度が大きいとたくさん課金されそう。。今回は個人利用なので良しとします)。API Gatewayは、HTTP GETリクエストを受け取ると、lambdaをキックします。lambdaは、DynamoDBから最新の位置IDを取得して、Webブラウザに返します。このlambdaの実装も、IoT Coreハンズオンの内容の多くを流用して作ることができました。

 Webブラウザは、受け取った位置IDからルンバの位置を計算し、ルンバの画像を移動させます。なお、画像の移動はCSSアニメーションを利用しています。このあたり、フロントエンドの開発知識があまりなかったので、結構時間を使ってしまいました。

検証結果

 このようにして、QRコードリーダから送信された位置情報をもとに、Webブラウザ上にルンバの位置を表示させるサービスを作ることができました。併せて、現在位置の表示だけでなく、過去の動きをトレースするページを作成しました。完成したページは、下の動画のように動きます。リアルタイムにチェックするよりも、後から掃除していたか確認するこちらの方が、ユースケース的には便利そうですね。

 肝心のルンバの動きの方はというと、ベージュのエリアを掃除して欲しかったのですが、あまりそちらには向かってくれなかったようです。。うーむ。 youtu.be

Simulinkでタイマをつくる(Part2)

 Simulinkでタイマを実現する方法の続きです。こちらのタイマは、一定時間置きに1を出力します。一定時間経過後に1を出力し続けるタイマは、Simulinkでタイマをつくる(Part1) - highitoh’s blog

を参照ください。

 また、ここで実装したタイマはelapsed0の期間が20となるものです。elapsed=1となる間隔が20となるタイマは、少し実装が変わってきます。

 

繰り返しタイマ

 

20 
elapsed

 

• elapsed:l

 

繰り返しリセットタイマ

 

reset 
OR 
elapsed

 

• elapsed:l • reset

 

Simulinkでタイマをつくる(Part1)

 Simulinkでタイマを実現するときの実装と、シミュレーション結果をまとめます。ここで実装したタイマは、指定時間経過後に1を出力し続けます。一定時間経過するごとに1を出力するタイマは、Simulinkでタイマをつくる(Part2) - highitoh’s blogを参照ください。

 

通常タイマ

 

20 
elapsed

 

• elapsed:l

 

リセットタイマ

Delayブロックのオプション:「外部リセット」→「レベル保持」

 

reset 
20 
elapsed

 

• elapsed:l • reset

 

ネーブルタイマ

 

enable 
20 
enable 
elapsed

 

• elapsed:l • enable

ファシリテーションスキルの種類

 私自身、エンジニアとしての役割だけでなく、関係者とのヒアリングなどを通じて効果的な施策を考え出したり、条件を交渉したりする役割がこれから求められると感じることが多くなってきました。みんなで高い成果を生み出すにはどうしたらいいか・・・そこから、関係者をうまく惹き込みチームとして最大限の成果を生み出すため、ファシリテーションスキルを上げたいと考えるようになりました。  そもそも、ファシリテーションスキルと一口に言っても、具体的にどのようなスキルが求められるのでしょうか。日本ファシリテーション協会によると、ファシリテーションに求められる能力として、下の4つを挙げています。Webで見つかるファシリテーションセミナーのアジェンダを見ても、これら4つのスキルを柱に話を進めるところも多いようです。

https://www.faj.or.jp/facilitation/

 さらに具体的なイメージを思い描くため、それぞれのスキルに対して、関連する単語を割り当ててみました。主観的な割り振りですが、イメージが付きやすくなったかと感じます。ファシリテーションスキルについて、現状の振り返りと今後の習得の方向性を考えるのに役立つかもしれません。

  • 場のデザインのスキル
    • 目的、論点の整理、参加者の関係性、前提知識、討議時間、進行、雰囲気作り、そもそも論/具体論、チームビルディング
  • 対人関係のスキル
    • コミュニケーション、傾聴、質問、共感、応答、観察、勇気づけ
  • 構造化のスキル
    • 思考、論理、構造化、図解、情報整理、質問力、MECE、ロジックツリー、マトリクス、匠メソッド
  • 合意形成のスキル
    • 結論、アクションプラン、コンフリクトマネジメント、納得感