GA technologies SREの永冶です。今回デブサミに初めて参加しました。
都合上2/14の1日目のみの参加となりましたが、業務時間内に行かせてもらったのとせっかくの機会なので、デブサミの感想と心に残ったセッションについて書きたいと思います。
デブサミとは
Developers Summit(通称: デブサミ)は翔泳社主催のソフトウェア開発者、システム開発者、ネットワーク管理者、運用者を対象にした総合ITカンファレンスです。
2003年から開催されている歴史あるイベントです。
今回参加したデブサミ2019は2/14、2/15と目黒のホテル雅叙園東京で開催されました。
感想
会場の雅叙園は目黒駅から徒歩3分とアクセスもよかったです。
そもそも雅叙園に来たのが初めてだったのですが、とてもオシャレでインスタ映えしそうな景色がたくさんありました。
これはすごいところにきてしまったと、興奮が抑えられませんでした。
2Fには受付やA~Eのセッションの会場があり、企業のブースが数多くありました。
印象に残った企業といえば、リクルートさんが「普段使っているプログラミング言語アンケート」をやっていました。Java、Python、JavaScriptがよく使われている感じでした。 あとブラックサンダー美味しかったです。
また、ビズリーチさんがプログラミング言語の缶バッジとペットボトルをノベルティにしていて、僕はよく使うRubyとPythonの缶バッジをゲット！
翔泳社やオライリーの技術書が多数販売されており、一般参加で10%割引になるなどお得でした。 また、セッションの開始前は、会場入り口に行列ができ、いい意味で熱気を感じることができました。 お昼のセッションでは軽食(サンドイッチとお茶)が提供され、小腹を満たすことができました。
やはり、こういったカンファレンスは参加するだけでも、他の会社の取り組みを知ることで自分の会社に適用できる事例もあるかもしれず、とてもいい刺激になりました。 新卒1年目で登壇しているような人もいて、僕もいつかはデブサミで登壇できるように話題を準備しようと思いました。
印象に残ったセッション
ここからは特に印象に残ったセッションを紹介していこうと思います。 セッション中のメモをもとに書いており、講演の内容と異なる可能性がありますのでご注意ください。 講演の内容が公開され次第、リンクを共有し違う部分があったら修正します。
サポートを、上手く使って迅速解決！‐現場が泣いて喜ぶ問い合わせ方法-
伊藤 裕史 アマゾン ウェブ サービス ジャパン サポートを、上手く使って迅速解決！‐現場が泣いて喜ぶ問い合わせ方法-
このセッションは、先日AWSが公開した「技術的な問い合わせに関するガイドライン」の内容に沿ったものになっています。 技術的な問い合わせに関するガイドラインは一時期はてブでバズり、1000以上もブックマークされました。
問い合わせする上で意識すること
- 正しい基本情報の入力を入力してください
- 質問の種類、サービス、カテゴリは正しいですか?
- 問い合わせの言語が意図したものになっていますか?(英語での問い合わせになっていないですか?)
- 適切な緊急度は設定されていますか?
- タイトルに「緊急」とか書いても意味ないですよ
- 質問者のアカウントは対象リソースの所有者になっていますか?
- セキュリティの側面から、アカウントが違ったら問い合わせには答えられません
- 課題を明確化してください
- お客様の解決したい問題を詳しく教えてください
- 具体的なリソース名をあげ、どのような問題が起こっているか書くと良いです
- アクセス元や、どのプロトコルで通信したかも教えてください
- 最終的に実現したいことを共有ください
- そもそも問題が起きていて、問題を解決しなければいけないのですか
- 状況の正確な共有をお願いします
- いつどこで問題が起きている、いましたか
- 対象リソースとリージョンを明記してください
- 発生時刻と継続状況についてお知らせください
- 復旧優先か、原因確認が目的か教えてください
- ログ、画面キャプチャの共有をご検討ください
- 初期の起票段階でログ、キャプチャを添付することで解決までの時間が短くなります
- 機密情報はマスクしてください
- いつどこで問題が起きている、いましたか
- 経緯の共有をしてください
- 事象の再現手順を教えてください
- サポートで検証用のインスタンス立てたりすることもあるので
- 事象の再現手順を教えてください
サポートエンジニアへのフィードバックをお願いします
- 褒めると喜びます
- 星一つとかの場合は、その理由をぜひ教えてください
- 自己解決した場合もご連絡ください
印象に残ったところ
サポートの方は社外の人なので、連携して障害を乗り越えるためには、多くのことを共有しないといけないのは当然なのですが、
社内で連絡する際も、状況、経緯、課題をきちんと共有することって大事だと思いました。
なまじ前提知識があると、多分こういうことだろうと推測で動いてしまうこともあると思っていて、そういうことがミスコミュニケーションに繋がり、
障害対応などのスピードにも影響が出てしまうかもしれません。
社内で誰かに対応を依頼したりする場合に、ここで言われていることを意識して書くようにし、お互いに迅速な対応ができるようにしていきたいです。
入社半年での開発ストーリー - 千人規模の顔認証受付サービスを1ヶ月で作った話 -
針原 佳貴 アマゾン ウェブ サービス ジャパン 入社半年での開発ストーリー - 千人規模の顔認証受付サービスを1ヶ月で作った話 -
ざっとメモ
Face Recognition gateというサービスをイベント用に作ります
- イベントの受付を顔認証で！
- しかし厳しいセキュリティ基準があります
- イベントまで1ヶ月しかないのと運用できるのかという問題があります
最初にやったのがPR/FAQを書くことです
- PR(プレスリリース)/FAQはWorking BackwardsというAmazonの開発手法に則ったものです
- PR
- 素早く、簡単に認証できます
- 顔認証と社員証の所持を合わせた二要素認証を行います
- FAQ
- 誰が作っていますか?
- 針原さんたち5人が作っています
- データは保存されますか?
- 顔写真は保存されません
- イベント後のデータの取り扱いはどうなりますか?
- 運用記録だけ残し、残りのデータはAWSアカウントごと削除します
- 他の手段による入場は可能ですか?
- 社員証による入場が可能です
- 誰が作っていますか?
初期設計
- 一から画像分析のAPIを作成することは１か月という限られた時間の中では厳しいです
- Amazon RekognitionというAWSのマネージドサービスを使ってAPIの開発を最小限にしました
- Deep Learningを用いた画像分析のAPIサービス
- 送った画像に似た登録済みのFaceIDを検索する機能を提供します
- リアルタイムで認証することが可能です(0.5s程度)
- ゲート通過のオペレーション
- 登録済みの人が1s(2回)試せば99%の確率でOKが出るようにしました
テスト段階
- 実際にテストしてみてUI/UXの重要性を感じました
- フィードバックから、処理を実行している間に「認識中」と表示させるようにしました
- 認証失敗の一番の原因は登録もれでした
- 実際にテストしてみてUI/UXの重要性を感じました
最終的なアーキテクチャの設計
- 一人一枚の写真でOK
- S3にアップし、DynamoDBに名前などを保存します
- Amazon Rekognitionで照合します
- CloudWatchでログを保存します
- ログ証跡のみ別のAWSアカウントのS3に残します
- イベント終了後に使用したアカウントは削除します
- ログ証跡のみ残ります
- 検証環境ごと(Develop Staging Production)にアカウントを用意しました
- 実データは本番にしか入れないようにしました
- 一時的な認証情報を利用する
- IAM Roleを使用します
- APIエンドポイントを用意しませんでした
- これは時間的な制約によるものです
- S3 DynamoDBはサーバサイド暗号化をしています
- TTLを指定し一定時間経つと自動で削除するようにしました
- 登録用の写真、顔認証の画像は保存しません
- 東京リージョンのみを使用しました
- データが東京リージョンに限定されます
- レスポンス時間を最小化するためでもあります
イベント当日
- 当日の計測
- レスポンスは3sくらいかかってしまいました
- ポケットWi-fi使ってたりしてネットワーク環境が良くなかったようです
- 現地の照明環境が良くなかったことも認識に影響を与えたようです
- メガネをかけてると精度が悪くなるようです
- イベント当日のコストが$20以下でした
- アンケート 4.5/5
- 速い、すごいという感想で好評でした
- 当日の計測
最後に
- Working Backwardsがアイデアを発展させる上での絆
- PR/FAQを作る
- AWSを使うと新しいアイデアを思いついてから短時間でサービスを構築できます
- 仲間がいれば心強いです
感想
PR/FAQというのが僕にとっては新しい概念で面白いと思いました。
開発前からあらかじめ、プレスリリースを用意しておくことで、どんなサービスか説明でき、設計の助けになるような気がしました。
Amazonの一人一人がリーダーであるという考えに基づき、
開発者がテスト運用まで考え、試行錯誤を繰り返していいものを作成していこうという気概が感じられ、
さらに新卒入社して1年たらずで、これほどのサービスができるのかということですごくエモい内容でした。
反省
申し込みが遅れたので、人気のセッションは満席になってしまっていました。
しかし当日立ち見でも人気のセッションを見ることができるみたいだったので、次回参加時は見たいものは立ち見する意気で行こうと思います。
まあ、そもそも申し込み開始したら即応募しろって話なんですが。
あと、個人スポンサーも最前列でセッションを聴けたり、技術書を一般参加者よりも安く購入できるみたいなので、お金に余裕があったら応募したいです。
