「TwilioJP-UG大阪+AWScean合同勉強会」に行ってきました

Tweet

ノンEC2のススメ

アイレット河村さん

EC2は柔軟すぎる

PaaSの良いところ
手軽に開始、目的に特化、管理が不要、便利な運用機能

Lambda
インフラ管理が不要、コードに集中出来る

Amazon Auroraの活用

AWS 清水さん

MySQLとの比較
ゲームメーカー年間2,200万などコスト減
レスポンス向上

利用した容量だけ課金

キャッシュレイヤを分離しているので本体障害時の復旧時にいきなりキャッシュがある状態を維持できている
64TBまでシームレスにスケール
3AZに6のデータコピー
継続的にS3にストリーミング増分バックアップ

Mariadb driverでインスタンスエンドポイントを使うとフェイルオーバーが高速

RDS for MySQLからスナップショットで移行可能

Data export and import guide

AWS の新サービスを本番に取り入れていくコツ

シナジーマーケティング 坂井さん

小さく始めて小さく失敗する
失敗は小さくても学ぶ事が出来る、大きな失敗は道が途絶える事がある
すぐにやめられるようにしておく
稟議が通らず予算が取れずに出来ないのなら勝手にやって結果を出して説得する、ダメだったら損害分を自分で払えばいいぐらいのサイズで始める

変化を嫌がる人は巻き込まなくても良い。放っておく。
重力には逆らえない。反対派を説得する必要などない。
正しく結果を出すものであれば、放っておいてもその時は必ずやってくる。

モバイル開発を便利にするAWS

NRIネットコム 高柳さん

APIとモバイルアプリの並列開発時にAPIGatewayのMock Integrationをモバイルアプリも開発テストに使う
HTTPStatusCodeのテストが出来る
I/Fが決まった時点でAPIGatewayを作ってしまう
本番のAPIとの間にもAPIGatewayを挟んで、双方の仕様変更を吸収してしまう

JavaScriptとSQLが書ければIoTエンジニアと名乗ってもいい！AWS IoT超入門

クラスメソッド 清野さん

クラウド、ビッグデータ、IoT、機械学習などのバズワードになったものの共通目的は「自動化」
ビジネスを自動化する事でコアビジネスに集中する
コアビジネスのためのデータ収集、分析に無駄な作業を発生させない

コアビジネスまでの領域は事業部門にはどうでもいい

GithubからSDKをクローンして必要な箇所を修正してクラウドへ送れればもうIoTエンジニア

Device Gatewayは自動でスケールする
Rules EngineはほぼSQL
※グラフ化はkibana
Device Shadow

caPath はシマンテックとかにあるのを落としとく

今日からでも出来るとある企業のtwilio活用方法

シナジーマーケティング 矢熊さん

従来の電話サポートシステムと比較した際のtwilioのメリット
カスタマイズが自由に出来る
システム連携が簡単
初期費用がなくコストが低いので小さく始められる
導入が簡単
情報が多いので開発しやすい

月額1,000円以下で運用中

SORACOMアルファベット

アドベン吉田さん

Wi-Fiモジュール 880円
Bluetooth 980円

MVNE Mobile Virtual Network Enabler

テレビ連動プラットフォーム開発とAWS

HAROiD 小野寺さん

日テレとBasculeで設立した会社

事例
Tovy 視聴者が作ったキャラクターが番組に参加
CHaRin TVでチャリンなポイントサービス

テレビの双方向化 テレビ局だけではなく家庭のテレビからも発信

テレビ連動
一瞬に人を集める事が出来る
高負荷、リアルタイム、早いレスポンス、高信頼性、アクセスが予測にくい
開発難易度が高くリソース確保が難しい
テレビは今でもSha-1
スケールしやすい構成
機能別にマイクロサービス化をしておき必要な時に必要なサービスを組み合わせられるように用意をしておく

Twilio API 連携のセキュリティ

1×1 新原さん

twilioからではない偽造post、twilioを利用した偽造postを防ぐ

通信経路の暗号化
https

通信元を制限
Basic認証、digest認証が使える
http://user:pass@example.com/
IP制限はtwilio側で非公開、ただし、どうしてもの場合はセールス相談

リクエストを検証
X-Twilio-Signatureヘッダ
勝手にヘッダに入っている
アルゴリズムがあるのでその通りに算出して判定する
アルゴリズムを知らなくてもsdkがあるのでそれを使えば良い

今日の感想

マイクロサービス化による機能の効率化が必要。
2回も3回も同じコードは書きたくないというのはそのとおり。
1度作ったものを使いまわせるように蜜結合させない機能づくりのしなければならないな〜。
仕様変更を吸収できる仕組み、吸収しやすい仕組みとして間にかますAPIはありだと思う。
なのでこのパーツとしての機能部分を外注するのはありだが、それを結合するのは中の仕事にしたいとやはり思う。

最後までお読みいただきましてありがとうございました！

【PR】 「AWS認定試験対策 AWS クラウドプラクティショナー」という本を書きました。

【PR】 「AWSではじめるLinux入門ガイド」という本を書きました。

【PR】 「ポケットスタディ AWS認定 デベロッパーアソシエイト」という本を書きました。

【PR】 「AWS認定資格試験テキスト＆問題集　AWS認定ソリューションアーキテクト - プロフェッショナル」という本を書きました。

@yamamanx

開発ベンダー5年、ユーザ企業システム部門通算9年、ITインストラクター5年目でプロトタイプビルダーもやりだしたSoftware Engineerです。
質問はコメントかSNSなどからお気軽にどうぞ。
出来る限りなるべく答えます。

このブログの内容/発言の一切は個人の見解であり、所属する組織とは関係ありません。
このブログは経験したことなどの共有を目的としており、手順や結果などを保証するものではありません。
ご参考にされる際は、読者様自身のご判断にてご対応をお願いいたします。

また、勉強会やイベントのレポートは自分が気になったことをメモしたり、聞いて思ったことを書いていますので、登壇者の意見や発表内容ではありません。