AWS summit tokyo 2018 ~Day 1~

今年も来ました、AWS Summit Tokyoです。

各公演を聴きながらメモった内容です。

そのうち公式に動画やプレゼン資料がアップロードされるはずなので、そちらも是非！

AWS Summit Tokyo / Osaka 2018

日本最大級のクラウドコンピューティングカンファレンス、今年はさらに規模を拡大し、東京、大阪の２都市で開催！

AWS Summit Tokyo / Osaka 2018

[10:00-11:30] Day 1 基調講演

開発環境だったりオンプレミスをクラウド化するのを助ける支援プログラム

AWS Well-Achitected

正しくクラウドサービスに最適化できているかのチェックフレームワーク

認定試験やハンズオン（on / off line）

AWS migration acceleration program

サポートプログラム

自動で移行できるサービス(server / database / data)

データストアに新しいサービスが東京で提供開始する

  • Elastic File System 7月から提供
    • 複数のEC2間でマウントできるストレージ

AWS loft tokyo

  • 目黒駅から徒歩１分
  • スタートアップを支援するoff line支援
  • テクニカルアドバイス
  • テクニカルセッション
  • コワーキングスペース
  • ブートキャンプ

GreenGlass

今年はIoT推しかな。

------

  • KDDIの事例
  • SONY銀鏡
  • SOMPOホールディング
  • ABEJA
  • デンソー

13:00-13:40 飛天 1-H1-3-13 Alexa スキル ー ベストプラクティス

大まかなフロー：

  • alexaからjsonで受け、サーバで処理してjsonで返す

Lambda（FaaS）を利用するのがいい

100万req/monthが無料で、スキルを公開すると月100ドルのクレジットをsアービス

アカウントリンクを利用してIoTデバイスの操作も可能

スキルの呼び出し方

  • シンプル
    • アレクサ、{マイレシピ}{を開いて}   ー　開くだけ、次の会話が必要
  • ワンショット
    • アレクサ、{マイレシピ}で{肉じゃがを調べて}   ー　一発で指示が可能

実際に使われるスキルを設計すること


実際にユースケースをハッピーパスを記入してみる

フロー図を書いてみるといい


今年になって開発者コンソールがあたらしくなったよ

IDEもあるので利用してね（AWS Cloud9）

  • ソースコードの管理はCloud9でデプロイはCLIでやるのがよさげ


Synonyms：同義語が定義できるようになった

  • ちいさな、ちいさめな、ちっちゃな　→  小型

プッシュ通知もできるようになるよ


ダイアログモデル

必要な情報を全て取得するまで会話を続けて、最後に処理をするやつ

サーバサイドで埋まったかを確認する処理が必要だったが、alexaが勝手にやってくれるようになった


SSML

タグで読み方の制御やBGMや交換音をだせる


スキルを公開してくれると毎月違うデザインのT-Shirtあげるよ

[14:00-14:40] Dive Deep Alexa Voice Service

利用場所の一位は人が集まる場所、長くいる部屋。リビングや寝室など。

ビジョン：Alexa Everywhere, for Everyone.

用途としては、

  • 料理中のタイマー
  • リモコンの代わりにテレビの入力
  • 自動車のナビ
  • 家の温度コントロール
  • 外出時にWatchを通してAlexaをコントロール
  • PCにALexaが搭載されて音声でコントロール
  • ヘッドフォンやイアホンにAlexaを
  • 火災探知機などの家庭に当たり前の機器にAlexaを搭載され、特別な何かを購入するのではなく。そして同じインターフェースで制御を行える。


Alexaのアーキテクチャ

  1. Alexa Voice Service（アレクサ搭載製品）に対して、wake word「アレクサ、」を待機してる。
  2. ASP音声認識がテキスト変換
  3. NLU自然言語解析でインテントを抽出
  4. スキルを呼び出し
  5. 外部サービスのAPIにアクセス
  6. APIからのjsonレスポンスを元に音声を再生
  7. 実行のURLを元に動作を行う
    • 音楽の再生とかなら音楽の再生できるURLをレスポンスでもらってる
    • 電気をつけるのもIFTTTとかをALexaが叩いてる感じ


Alexa搭載機能に必要なもの

ハードウェア

  • 起動方法に即してマイク、スピーカーや雑音の除去などを行う必要がある
    • Push and Touch - ボタンを押して、Alexaに指示を出す　→  近い範囲で操作
    • 音声起動 - neer field　　→  同じ部屋の中ぐらい
    • 音声起動 - far field    →  部屋をまたいだり
  • 正しいAudio Front Endの選定、アルゴリズム
    • 音響エコー：ノイズキャンセリング機能
    • ビームフォーミング：複数のマイクを搭載して、どのマイクが一番先に音を拾ったかによって角度を割り出す。
  • マイクの配置方法が大事。Alexaなら円形。Alexa Showなどのディスプレイなら前面にならべて。
  • マイクの数はやはり２つ以上はいる
  • S/N比を考慮しながらマイクの数や配置、アルゴリズムの選定を考慮すること。値段が変わってくるよ

どこから手をつけていいかわからない！

→  AVSキットがあるよ！


ソフトウェア

  • データのやりとり
    • Event：デバイス　→  Alexa
    • Directive：Alexa  →  デバイス
  • 一つの音声指示に対しても、結構たくさんのEventやDirectiveのやり取りをしてる
    • マイクの制御したり、音声送ったり、最近ならディスプレィの情報も。
    • 目的は、デバイスの制御をALexa側で一括管理することでデバイスには複雑なLogicを入れないようになってる。
  • ？デバイス側で全部のイベントを解釈して処理を入れないといけない？
    • AVS Device SDKを入れてくれればOK
    • AlexaとのAPI通信をラッピングしてる
    • OSSだから独自実装でも可

ソフトウェアもなんだか複雑でめんどくさい！

→  SDKがあるよ！


AVS Device SDKの利点

  • 音声の検知「アレクサ、」の検知を各言語で。
  • イベントが検知されたらAlexaに転送。HTTP/2でやってるよ。ACL。
    • Eventごとにコネクション貼ってる。
    • Alexaからデバイスにアクセスする場合用のコネクションもある（スマホアプリからデバイスに音声の指示を出す時など、アラームとか）
  • 受け取ったDerectiveのハンドリングして、アクションを起こすAgent（音声再生、アラーム鳴らす、音声のキャプチャ、音量調整など）に指示をだす
  • Focus Managerの仕事：ユーザインタラクションの優先度
    • 音楽再生はアラートの再生よりも優先度が低い


まとめ：開発キットかって、SDKいれたらいいね！

[15:00-15:40] クラウド設計・運用のベストプラクティス集 “AWS Well-Architected Framework” を 100% 活用する方法

AWS Well-Architected Framework（以下WA）とは＞

  • CloudアーキテクチャのBestPlactice
  • 毎年改修が続いてる


設計原則：全５項目

AWS Well-Architected – 安全で効率的なクラウド対応アプリケーション

AWS Well-Architected Framework では、開発者がより迅速に、かつ低リスクでアプリケーションを構築およびデプロイし、AWS のベストプラクティスに従って情報に基づいた決定をするために役立つガイダンスが提供されます。

Amazon Web Services, Inc.

QnA形式のベストプラクティス

  • 質問は出発点であって、起こりうる事態については積極的に考える必要がある
  • Y or Nではなく、判断材料の一つにして


WAの活用例（新規開発時）

  • 継続的なチェックリストにより問題の発見が早かった
  • オンプレからクラウドに移行する際に最適化や改善ポイントが明確になった
  • 今のAWSの自社の設計に関して答え合わせができてよかった

などなど

要件定義はホワイトペーパーを活用できる

設計では要件定義をもとに

構築後の稼働中でも、新しいインスタンスタイプなどは随時でているので、改善を繰り返すことでコストダウンする

[16:00-16:40] Nintendo SwitchTM 向けプッシュ通知システム「NPNS」

Nintendo Switch 約1800万台発売


NPNSとは？

  • プッシュ通知サービス
  • 常時接続を使用
  • 他社サービスは、APNS（Apple）、FMC（Google）


ニュースやe-storeなど様々なサービスから利用されてる


SLAとして

  • １億台に備える
  • 通常時では〜秒、異常時は〜分
  • メッセージはベストエフォート仕様


機能分割

  • XMPP Cluster：常時接続＆通知
    • クラスタを複数分割して並列にしてる。可溶性のため
      • クラスタを増やすことでスケールできるようにしてる
      • DBがスケールしづらいからクラスタ毎に
      • 小さくデプロイカナリアリリース
      • DB障害時にも影響範囲が少ない
      • ELB置いてない
        • DNSのラウンドロビンで行ってる
        • Route53に全ノードのAレコードを持ってる
        • ConsulがRoute53のレコードを変更してる
    • ejabberd使用
    • MySQLとRedis
  • Consumer API：ID管理
    • Ruby on Rails
    • Aurora ← 柔軟にスケールできる
    • Redis
  • Proider API：サーバ間連携向け、通知送信要求
    • Ruby on Rails
    • Aurora
    • Redis
  • その他
    • SQS、ELB、Route53、Consul（ejabberdで使用してる）


クラスタ維持方法

  • ejabberdを２方向から死活監視
    • Consul
      • すぐ反応
      • Route53のレコードを変更
    • instanceが死んだらConsulが反応してRoute53からレコードを決して、新しいinstanceを立ち上げてConsulが検知したらRoute53に追加してOK


デプロイ

  • Blue/Green Deploy
    • ドリップ処理
      • スムーズな切り替え　少しずつBlue→Greenにする
      • 一気には切り替えない
      • 再接続させると一気に負荷がかかるので再接続のタイミングを分散させるため
      • デプロイ時間が長時間！２時間ぐらい
      • Blueで動いてる　→ Greenを準備　→ DNSをGreenに切り替え　→ ドリップ処理ですこしずつユーザの接続を切る　→ 切れたクライアントは再接続しにくるとGreenのレコードをDNSからもらう　＝　徐々に切り替わる！


省メモリ化

  • ejabberdの省メモリ化したのにCPUもメモリを空いてるのに接続数が上がらない問題発生
    • Security Groupのセッションの上限にあたった
    • SecurityGroupを無効にしてNetworkACLに切り替えた


TCP切断対策

  • 使ってないと切れちゃう　→  KeepAliveをL4とL7でいれた
    • L4 tranceport層
      • サーバから定期的に特殊パケットを送信
    • L7 application層
      • データを入れたパケットを定期的に送信
      • ルーターとかが悪さしてる？と思われる


現在の規模

  • TCPコネクション：常時接続数約700万台
  • Push：約2万通/sec


その他

  • Erlangよかった
  • ejabberdはチューニング結構やった
  • AWS起因のサービス障害は発生していない


今後

  • NLBでCross-AZできるから入れたい。Route53更新してる部分も排除できる

[17:00-17:40] 通信業界における AWS の活用事例とアーキテクチャ

通信キャリアの多角化

  • IoT、5G、4k、
  • Life、
  • ビジネス
  • ビックデータの活用

AWSは、ユーザに提供するサービス基盤、データ分析、業務領域で使用してる


サービス基盤事例

KDDI au HOME

  • 家　→ MQTT → IoT SaaS → ECS → dynamoDB → Lambda ... [ DynamodB , Lambda , SNS ]
  • 複数のLambdaでマイクロアーキテクチャ構成


NTT東日本 ひかりクラウドスマートビデオ

  • CDNの利用
  • AWS Direct Connectを利用して安定した通信を提供（利用が閉じたネットワーク通信網内に限られる）


某通信キャリアのフォトクラウド

  • EC2とRDSをセットdえ一つのシャードにして、それを16シャードに分散
  • 障害発生時には原因究明よりも復旧を優先している（一旦スケールさせる）


データ分析事例

NTTドコモ ビックデータ分析基盤

  • 4PBのRedShift
  • End to Endでの暗号化も可能


KDDI データレイク基盤

  • オンプレミス環境の増設コストがあり、機械学習のような柔軟なインフラ環境の需要が増えたため移行
  • EMR：フルマネージドなHadoopクラスタ


Agoop データ分析基盤

  • モバイルの位置情報データの管理
  • モバイル　→ EC2 → Kinesis → EC2 → S3 → EMR(Spark) → S3やRDSへ
  • 要件によってエンジンを切り替える
  • Athena：サーバレスでS3上のデータをスキャンできる。ワンショットの分析に最適。障害時のログ分析とか。


業務システム基盤事例

KDDI API gateway

  • お客様向けサイトからのAPIアクセス
  • Kinesis：リアルタイムストリーム処理基盤


KDDI AIチャット

  • クライアント→Chat(SaaS) → EC2(watcher) → DynamoDB → SQS → DC2 → レスポンス
  • watcherがSaaSにポーリングしてメッセージを取得してる（SaaSの制限のため）
  • 一部の機能、FIFOキューをoregonリージョンで使用してる
  • ECS：コンテナオーケストレーション
    • 常駐型で長時間稼働。
    • マイクロサービス
    • バッチサービスなど


KDDI 三太郎の日キャンペーン

  • LINEプッシュを打った後にページに急激なトラフィックがくる
  • Staticファイルを中心とした軽量なランディングページ
  • CloudFrontにキャッシュ


KDDI プッシュ通知基盤

  • モバイルプッシュの為のサービス基盤
  • キューを介した非同期配信をすることでオンプレミスの時の４倍の処理能力を実現
  • 配信元　→  Elastic BeansTalk → SQS → それぞれのプッシュ
    • コンポーネントの結合を切り離すことができる
    • ベストエフォートなキューとFIFOキューとして機能する

0コメント

  • 1000 / 1000