LoginSignup
1

More than 3 years have passed since last update.

AWS Summit Tokyo 2018 Day1 私的メモ

Last updated at Posted at 2018-06-05

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

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1