Alexa スキル - ベストプラクティス
開発は大きくわけて2つ
VUIデザイン
処理ロジック(lambda)
スキルの種類
- カスタムスキル
- スマートホームスキル
- フラッシュブリーフィングスキル
インテント 命令
スロット 値
アルファベット、句読点削除、漢数字に変換される
開発プロセス
設計
使われるスキルとは?
- 日々使うユースケース
- 会話フローがシンプル、音声の方が楽
- コンテンツが最新
- 特別な体験
- 覚えやすいスキル呼び出し名
- できることが明確
- ハッピーパスを記入する
- スキルフローを作る
- 開発はシンプルに
What’s new
- コンソールUIが新しく
- ask cli+cloud9
- インテント履歴、ユーザーが実際に使用した履歴
- 新しいビルトインスロット
- 同義語の登録
- Permissions
- ダイアログモデル
- Alexa側で処理する機能、インテントがハマるまでアレクサ側で処理することができる
- SSML(発音を変えたり、合間を入れたり、気持ちを込めた言い方にしたり、オーディオファイル、効果音を入れたり、効果音はフリーで用意されている)
- キッズ向けのスキルを公開できるようになった。
- スキル公開するとTシャツもらえる。
- 100$まで無料のクレジットがある。
- AmazonPayの使用、米のみ。
Dive Deep Alexa Voice Service
- スライド参照
Amazon Aurora Under the Hood
Storageの仕組み
- キャッシュレイヤの分離
- キャッシュをデータベースプロセス外に移動
- スケールアウト可能な分散ストレージ
- 3つのAZで分散し、コピー
セキュリティ
- データの暗号化
- SSL接続
- VPCネットワーク分離
- ノードへの直接アクセス不可
設計思想
- 10G-64TBシームレスに自動スケールアップ
- 3AZに6つのデータのコピー作詞絵
- フォーラムシステム採用
- 継続的にS3へ増分バックアップ
- 分散ストレージである
- レプリケーション(Quorum)
- Quorum(クォーラムモデル)
- Auroraは6つ
- Vr+Vw>V(読込、書込みが、少なくとも1つの共通コピーを保持)
- Vw > V/2(書込みクォーラムは過半数のコピーを保持)
- 2つのコピーに障害が起こっても読み書きに影響はない
- 3つのコピーに障害が発生しても読込は可能
- 自動検知、修復される
- なぜ6つのコピーが必要なのか
- AWSは大規模環境
- AZ障害は影響範囲が広域
- AZ+1の障害(2重障害)を許容し、修復する必要がある
- 3つのAZの場合、6つのコピーが必要
- 2/3クォーラムでは不充分、4/6クォーラムで実装してる
- MTTRの短縮
- 小さなセグメントで修復が短くなる
- Auroraは10GBのセグメントを使用
- フォールトトレラントを使用して、パッチ適用時に影響を及ぼさない
- storage cluster
- ProtectionGroupごとに6つのストレージノード(10GB)を使用
- LSNを持っており、不足重複しているレコードを判別可能
- MemberShipChange without stalls
* クォーラムセットとエポックを使用
* エポックEpoch(監視時系列のバージョン番号のようなもの)
* 停止なしのAZ+1のフォールトトレランス、積極的に障害を検出可能
- 無停止で実行可能
- 長時間のAZ障害に対する備え
- デグレモードにより3/4クォーラムに切り替える
- AZ障害発生中に別の二重障害/AZ障害が場合でもデータロストが防げる ## クォーラムシステムの課題
- Read/Writeコスト
- Writeコスト: ログレコードのみストレーじノードに送信されるので、6倍のログ書込みだが、1/9のネットワークトラフィックのみ
- Readコスト: 各ノードが最新でレイテンシが少ないか情報を持っているので、どこにアクセスすればいいかわかる
- コスト
- 6つのコピーは全て同一ではない。
- 6つのコピーが必要だが、6倍ではなく、3倍より少し多い程度
Nintendo Switch (TM) 向けプッシュ通知システム「NPNS」
- NPNS(Nintendo Push Notification Service)
- 常時接続を使用
- 使用例
- フレンドのオンライン通知
- みまもりSwitchでの設定変更
- DL開始、完了指示
- 1億台に備える、AWSリージョン規模の生姜い未満は可動、遅延は数秒から数分
- XMPPCluster
- 常時接続&通知
- ConsumerAPI(ID管理)
- RESTfulAPI
- ProviderAPI
- RESTfulAPI
ConsumerAPI
- ejabberd
- Erlangで書かれたOSS
- クラスタ対応のXMPPサーバー
- 大規模で利用実績あり
RDS MySQL5.7
ElastiCache + Redis
Consul ejabberd + FailerDetection
SQS
Redisにはセッション情報を保持
MySQLにはゆーざー情報を保持
Route53
ELBを不採用しない利用
- 常時接続ができない
- プロトコルがあわない
- 剪定時期で見合わせ
DNSのラウンドロビンでロードバランス
Route53に全ノードのAレコードを登録
ConsulがRoute53を操作
ejabberdを2方向から死活監視
- Consul
- AutoScaling
- Blue Green deploy
ASG単位でドメイン切替
新旧ノードを同じAZに配置
ドリップ処理ジョジョにBLue -> Greenに移動
常時接続では接続処理が最も高負荷
再接続タイイングを分散させたい
DNSのエイリアス処理
AutoScaling (Lifesycle hook) -> Cloudwatch event -> Run COmmand -> EC2instance
省メモリ化
ejabberd を省メモリ化
opensslのメモリ削減開放
hibernateのチューニング
r3.large1台あたり72万接続
SGのセッション数の上限 -> SGの無効
限界まで接続可能になった
TCP切断対策
無通信期間にKeepAlive(L4, L7で)
L4でTCPKeepAlive
time: ユーザーごとに可変
interval * proves: クラスタ間で対照実験
10 * 2 -> 15 * 10
切断を40%削減
KeepAlive(L7)
データを入れたパケットを定期的に送信
約700万同時接続
約2万通/秒
約200億/月
導入予定
- NLB
- Fargate