AWSの話題を中心に、日々の業務やプログラミングの徒然を綴るエンジニアブログです。

HANDS LAB

HANDS LAB ENGINEERS BLOG

ハンズラボエンジニアブログ

12

作者別: YusukeKarakita

「DeepLens」セットアップしてみました!

Pocket

こんにちは、百木田です。

現在開催中のre:Inventに参加のためラスベガスに来ております!
今朝のキーノートにて「DeepLens」という新サービスが発表されました!!
DeepLensはAWSオリジナルのカメラ付きデバイスを使うことで、エッジでの映像の撮影からリアルタイムな解析までの実装をより簡単にしてくれるサービスです。

サンプルプロジェクトが用意されているのでこれらを使って試すことができます。

  • OBJECT DETECTION
  • HOT DOG NOT HOT DOG
  • CAT AND DOG
  • ARTISTIC STYLE TRANSFER
  • ACTIVITY RECOGNITION
  • FACE DETECTION

DeepLensのwork shopに参加した人にはデバイスを配布されるということで行ってきました!
このデバイス、Amazon.comで$249.00で予約受付がされています。

DeepLens販売ページ

先ほど開封の儀を済ませ、セットアップまでをやってみましたので手順を共有します。

1. DeepLensのコンソールにアクセス

https://aws.amazon.com/jp/deeplens/

スクリーンショット 2017-11-29 22.54.05.png (2.3 MB)
「Get started with your DeepLens」を選択します。

2. デバイスを登録

左上のハンバーガーアイコンをクリック

  • 「Resources」の「Devices」を選択
  • 「Register device」を選択

デバイス名

スクリーンショット 2017-11-29 22.55.02.png (158.3 kB)

必要なIAMロールたちを作成

それぞれのサービスを実行するためにIAMロールが必要なので、「Create a role in IAM」からすべてのロールを作成します。右上の「Refresh IAM roles」を押すと、作成したIAMロールが選択できるようになります。

スクリーンショット 2017-11-29 22.58.19.png (373.2 kB)

証明書をダウンロード

後ほどDeepLensにアップロードします。

スクリーンショット 2017-11-29 22.58.30-2.png (177.0 kB)

3. DeepLens本体を準備・接続

SDカードを挿入

32GBのSDカードが同梱されているのでそれを後ろに挿します

電源に接続

電源アダプタも同梱されています。

電源ボタンを押して電源を入れる

DeepLensのネットワークに接続

電源を入れてから少しすると「AMDC-xxxx」のようなネットワークが出てくるのでそれに接続します。

ブラウザから http://192.168.0.1 にアクセス

DeepLensの設定ページが表示されます。

4. DeepLensをネットワークに接続

ここからはDeepLensがホストする設定ページ( http://192.168.0.1 )での作業になります。
DeepLensをつなぐネットワークをプルダウンメニューから選択し、Wi-Fiパスワードを入力して「Save」します。
スクリーンショット 2017-11-29 23.15.03.png (134.8 kB)

5. アップデートプログラムをインストール・再起動

右下の「Install and reboot」を選択します。
今回の場合は5分くらいかかりました。
スクリーンショット 2017-11-29 23.15.24-2.png (252.9 kB)

アップデート中はランプが点灯します。アップデート、再起動が終了すると点滅に変わるので再度DeepLensのネットワークに接続して http://192.168.0.1 にブラウザからアクセスします。

6. 証明書をアップロード

手順1の際にダウンロードした証明書をアップロードします。
スクリーンショット 2017-11-30 0.35.38.png (133.2 kB)

7. デバイスの設定

デバイスの設定をします。今回は以下のような設定にしてみました。
スクリーンショット 2017-11-30 0.36.29.png (228.5 kB)

8. 設定の確認

スクリーンショット 2017-11-30 0.38.46.png (140.0 kB)

完了!

正しく設定が完了するとこのような画面が表示されます。
スクリーンショット 2017-11-30 0.38.51.png (77.9 kB)

まとめ

現場からは以上です。
サンプルプロジェクトも試してみたいです。

Pocket

12月9日、10日開催!キッチンハッカソン2017の見どころを紹介!

Pocket

こんにちは。百木田です。

すでに告知しておりますが2017年12月9日(土)、10日(日)と2日間に渡り、Oisix.daichiさんとハンズラボが共催でキッチンハッカソン2017を実施します!

Connpassイベントページ

テーマはその名の通りキッチン!

Oisix.daichiさんは食材を取り扱っており、ハンズは豊富なキッチン用品を取り扱っているということで、今回はキッチンをテーマにやってみようということになりました。
普段、キッチンに立つ方は、こんなのあったらいいのになー、を実現してみてください!料理をしない方でも、こんなアプリあったら料理するかも?とか、もしくは料理する方のお悩みを聞いて、それならこうできるのでは?とかをこのハッカソンで実現してみてください。
技術テーマは特に設けない予定なので、モバイルアプリ、Webアプリ、IoT、AI、ロボット、フィンテックなど、興味のあるものに挑戦してみてください!

会場はOisix.daichiさんの新オフィス!会社にキッチンだと!?


先日も関係者が集まり、そちらのオフィスにお邪魔してキックオフミーティングをしてきたのですが、とてもおしゃれな空間でテンションあがりました!
そしてなんと同じビルの1階にはキッチンが併設されており、料理ができるようになっているんです!
ミーティング後にキッチンを見学させていただいたのですが、その時も料理をしている最中で、会社の一室で本格的に料理をしている光景に驚きました。
写真はそのキッチンルームに併設されている作業スペースです!このスペースでハックしてもらう予定です!

Oisix.daichiさんの食材を使った手料理!

ハッカソン当日はそのキッチンでOisix.daichiさんのスタッフの方々が調理し、料理を振る舞っていただけるとのことで、そちらもハッカソンとともにお楽しみいただけます!

豪華審査員!嬉しい賞品も??

審査員にはOisix.daichi執行役員の奥谷孝司氏、数々のハッカソンを開催したり、大規模なコミュニティとなっているIoTLTのオーガナイザーでもあるdotstudio CEO 菅原のびすけ氏東急ハンズCIO(最高情報責任者)で弊社CEOの長谷川秀樹、他、など豪華メンバーを予定しているのでそちらもお楽しみに!!

優勝チームおよび優秀チームには、Oisix.daichiさんとハンズから、両社ならではの賞品を予定していますのでぜひ優勝目指してハックしてください!

詳細は申し込みページからご覧ください!

Connpassイベントページ

Pocket

CodePipelineの進行状況をSlackに通知する

Pocket

こんにちは。百木田です。
CI、回してますか?

CodePipelineで実行するステージの進行状況を手軽に見たいと思い、Slackに流れるようにしたので共有します。

ポイントとしては、CodePipelineからLambda functionを呼ぶのではなく、CloudWatchイベントでCodePipelineステージのステータスの変化を検知してLambda functionを呼び出します

今回はできるだけシンプルにするために、すでにCodePipelineは作成済みの想定で、すべてのステージにおけるSUCCEEDEDFAILEDのステータスを通知します。なのでCodePipelineに変更は必要ありません。
また、Slack Botを作成しトークンを発行して使っていますがIncomming Webhookでも同じようなことはできるかと思います。

Serverless Frameworkを使ってCloudWatchイベントの設定と、slackに通知するためのLambda functionをデプロイします。

環境

ディレクトリ構成

デプロイ

コードは記事の下の方に書いときます。上記のディレクトリ構成のように配置したらデプロイします。

デプロイできたらCodePipelineを動かしてみます。そうするとslackにこのような通知が来るかと思います。

いつの実行結果なのかをトレースできるようにCodePipelineの実行IDの前半7桁を表示しています。この辺はお好きにカスタマイズしてみてください。

まとめ

CloudWatchイベントの検知がリアルタイムじゃないので、CodePipelineの進行と通知にラグがあったり、前のステージの実行完了と次のステージの実行開始の通知が前後することなどもありますが、実行結果がわかればいいかなくらいの感じなので気にしないことにしてます。

ありがとうございました。

以下、コードたち

status_notification.py

serverless.env.yml

serverless.yml

※ detailのセクションを消すと、すべてのステータスが検知対象になります。

Pocket

東急ハンズでAmazon Chimeを導入した時に調べたこと

Pocket

こんにちは。百木田です。

今年の2月にリリースされたAmazon Chimeをこの度、東急ハンズの会議に使ってみることになりました。

以下がChimeを採用したいくつかの理由です。

  • シンプルな操作
  • 最大100人がビデオミーティングに参加可能
  • 主催側から参加者をミュート可能

Chimeを本格的に利用することになり、いろいろ調べたのですがまだまだナレッジが少なく試行錯誤したので、わかったことを残しておこうと思います。

Chimeアカウントとユーザー

Chimeにはアカウントユーザーという単位が出てきます。イメージ的にはアカウントは会社やチームなどのグループで、ユーザーは個人に紐づくものです。

ChimeユーザーはAmazon.co.jpのアカウントと紐付いていて、AWSアカウントを持っていなくても使用できますが、AWSコンソールからChimeアカウントとChimeユーザーを紐付けることでユーザー管理をすることができるようになるなど便利に利用できます。

以下がChimeアカウントの種類です。

少し補足するとこんな感じ。

Amazonアカウント

・ AWSアカウントで管理されていない単独のアカウント(ユーザー)。

チームアカウント

・ AWSのChimeで作成したアカウントにユーザーを招待できる。

エンタープライズアカウント

・ 自社のドメインをAWSアカウントのChimeへ登録する必要あり。
・ そのドメインのメールアドレスでChimeにログインすると自動的にアカウントにユーザーが追加される。

ちょっとややこしいです。整理するために図にしてみました。

グループミーティングをホストするにはPro Editionを付与したChimeユーザーが必要です。主催者によってミーティングがホストされると、Chimeユーザーを作成していない人でもミーティングIDを教えてもらうことでミーティングに参加することができます。

ポートと通信帯域の要件

通常のビデオミーティングをする場合は以下のそれぞれのIPアドレス:ポートに対するアウトバウンド通信を許可してあげる必要があります。

IP Address

  • 52.54.62.192/26
  • 52.54.63.0/25
  • 52.54.63.128/26
  • 52.55.63.128/25

Ports

  • TCP/443
  • UDP/16384:17383
  • UDP/3478

ポートの要件はこちらに記載されています。
hosts-ports-and-protocols-needed-for-amazon-chime

各機能を利用する上で必要な通信帯域はこちらに記載されています。
what-are-the-bandwidth-requirements-for-amazon-chi

料金体系

各ユーザーエディションごとの料金は公式サイトに記載されているとおりです。

ユーザーはAWSコンソール上からエディションをGrantさせたりRevokeさせたりできるのですが、課金されるのはProエディションをGrantさせてた期間の日割り計算になります。
なので1ユーザーを1ヶ月のうち合計20日間ProエディションをGrantさせていた場合、

という計算になります。
なお、課金は1ユーザーごとになるため、2ユーザー以上利用した場合はユーザー数分の課金が発生します。

AD連携

AWSのAD Connectorを利用することでChimeのAD連携をすることができます。しかしながらAD連携するにはAD Connectorがバージニアリージョンにある必要があります。

まとめ

以上となります。Chimeの使用感や問題点、会議する上で工夫したこと、考慮した方がいいことなどあるのですが、そちらは別の機会に書ければと思っています。
Chime自体、登場したばっかりでまだまだ改善の余地がありますがフィードバックをしつつ、アップデートに期待したいと思います。
ありがとうございました。

Pocket

IAMポリシーで自分の所有リソース以外の操作を制限する

Pocket

こんにちは。百木田です。

先日、こんなことがありましたね。
Amazon S3ダウンの原因、コマンドの入力ミスで多数のサーバを削除。

人間が関わっている以上、人的ミスはどうしても避けられないので工夫してミスを減らしましょうという教訓ですね。

今回のブログでは新しい技術は使ってないですが、そんなニュースもあったので人的なミス防止に関連する共有です

AWSを導入している企業であればAWSの機能や技術を検証するために、
サービス提供しているアカウントから分離された検証用アカウントを利用している場合も多いかと思います。
本番環境ではユーザーに適切な権限を付与し、事故を防止していることと思いますが、検証環境では事故の影響が小さかったり、検証するために必要な権限が多い or 不明確であったりということもあり、それぞれのIAMユーザにAdministrator権限に近い権限を付与しているといったこともあるかと思います。

自分が操作しているリソースのすぐとなりに他の人が検証で使用しているリソースがある場合、そういった権限を持っていれば少しコンソール操作をしくじっただけでリソースが消え、両者、冷や汗状態です。

基本的に私はしくじる側の人間だと思っているので、そんな環境でコンソール操作するのはめちゃくちゃイヤなわけで、寝ぼけながら操作しても自分以外の管理するリソースを操作すること無いようにしたかったわけです。
(入社した月にそんなことやらかした時にはもうあれですね。)

今回はEC2インスタンスの[開始/停止/再起動/削除]操作を制限するポリシーを設定します。

設定方法

  1. 操作制限を書いたIAMポリシーを作成
  2. 自分の使用しているIAMユーザーに対して作成したIAMポリシーを付与
  3. 自分が管理しているEC2インスタンスにタグ付け
      Ownerというタグネームに対して自分のIAMユーザー名を設定
      

作成したIAMポリシーは以下です。

「操作するEC2インスタンスのOwnerタグと、現在使用しているIAMユーザー名が異なる場合はActionの操作を拒否」という内容です。
また、どのユーザーでも同じポリシーが使用できるようにユーザー名の部分は変数を指定しています。

試してみる

Ownerタグに自分のIAMユーザー名が設定されているインスタンスは操作できます。

そうでないリソースは操作時にエラーが出るようになりました。

CLIで試しても同様にエラーとなります。

まとめ

権限を少し工夫するだけで安心して作業できるようになりました。
現在お使いのIAMユーザーにIAM操作権限が付与されていれば今からでも手軽に設定できると思いますので実施してみてください。

Pocket

12