御成門プログラマーの技術日記

Microsoft AzureやAngularなどの技術情報を発信します。

トップ > Microsoft Azure > Global Azure Bootcamp 2019@Tokyo 参加メモ

Global Azure Bootcamp 2019@Tokyo 参加メモ

Microsoft Azure 勉強会・セミナー参加レポート Microsoft関連

Global Azure Bootcamp 2019@Tokyoに参加してきました。
備忘録としてメモを公開します。

Azure CosmosDB Deep Dive

  • Cosmos DB

    • データベース、mongodb など様々な形式のDB
    • 全世界であっという間に使える

  • 設計思想

    1. アクセスに対する要求に自由に対応できる
    2. ミッションクリティカルなサービスで使える。遅延が少ない
    3. すぐに使えること
    4. 全世界中にホストする。その場ですぐにレプリケーションできる
    5. 1-4に対してSLAが担保されている

  • どこからのリージョンでも、読み書きもできる。

  • 構成

    • アカウント
      • データベース
        • コンテナ
          • アイテム

  • レプリカ データを実際にもっているもの 複数のレプリカ群からなる
    → データを失われないために複数。
    → リーダーがいて書き込みの指令を受け取り、残りのレプリカに書き込んでいく。
    → 残りのレプリカは読み込み専用。フォワーダーが他のリージョンに情報を送っている。

  • パーティションキー

    • どのレプリカに行くのかが決まる。
    • なんでも構わない。
    • ちょうどいいくらいにばらけているように設定する
    • パーティションは自動的に分散する

  • お金のおはなし(リクエストユニット)

    • 異なるDBタイプをあつかっているので共通した単位が必要
      →　RU（リクエストユニット）
    • 1リクエストユニット = 1kbのドキュメントを呼び出す
    • RUをさばくための計算資源を予約され、保証される。
    • RUの割り当てが足りない場合、処理できなくなる。

  • 一貫性モデル

    • 音符マークのやつ
    • 全世界に書き込みを行ったときにレイテンシーが発生するか
    • データベースを書き込んだ時にだれが読めるのか
      • eventual consistency 弱い
      • strong 書き込んだ瞬間に全世界で使える。→トレードオフが存在する。一貫性は最強。レイテンシーがあるかもよ
        • CAP定義 → Consistency、Availability、Patition Toleranceは共存できないという考え方
    • COSMOSDBではこれを5段階で制御できる
    • わかりやすい？
      例https://docs.microsoft.com/ja-jp/azure/cosmos-db/consistency-levels#consistency-levels-explained-through-baseball

  • 本日の資料 ここにある内容を話していただけだよ https://github.com/AzureCosmosDB/content/tree/master/decks

Smart Store リファレンスアーキテクチャ Deep Dive!

  • 資料はこちら
    https://speakerdeck.com/miyake/smart-store-deep-dive

  • Smart Store
    https://news.microsoft.com/ja-jp/2019/01/29/blog-smart-store/

  • リファレンスアーキテクチャ

    • 在庫管理や商品管理の共通的な部分はマイクロソフトのソリューションを使う

  • Microsoft Smart Box

    • 小さいAmazon goみたい
    • バックエンドは全部Azure
    • サーバーレスとマイクロサービスの構成になっている
      • サーバーレス
        • できるだけシンプルな基盤にしたい
        • スケーラーびりてぃを柔軟に調整したい
        • リアルタイム性の重視

  • モバイルデバイスへのPush通知

    • プッシュ通知の機能はAppCenterを使用している
    • android firebase cloud messaging
    • App Centerの設定
      • プロジェクト作る
      • ザマリンにコピペ
      • ファイヤベースにプロジェクト作る
      • notification hub はザマリンの場合、ネイティブにがりがりかかないといけない
      • AppCenterならForms側に書けるのでメリットがある。

      • プロジェクトのパッケージ名とfirebaseの設定を合わせないとPush通知が最初だけは来る。

      • http://masatoru.hatenadiary.jp/entry/2018/12/19/235900

  • サーバーレス

    • Azure Functions V2
    • CQRSによるバックエンド
    • Cosmos DB SDKは3.xを使用する

  • リアルタイムWEBによる管理UI

    • SignalIR Serviceによるリアルタイム通知
      • Serverless Mode
        • Hubの実装が不要になる。
      • signalr.jsを使って更新イベントを待ち受ける
        • ほぼコピペで大丈夫
      • Vue.jsでのリアルタイム描画

  • マイクロサービスのデプロイ

    • サーバーレスを一括デプロイする方法
    • ARM Templateを使用する
      • マイクロサービスごとにテンプレートを分割する
      • Linked テンプレート

ARMテンプレートを使い倒せ!ソシャゲを支えるInfra as Codeの極地

  • ARMテンプレートとは

    • 概要
      • 各リソースをJSON形式でテンプレート化
      • ARMテンプレートはあくまでリソースを作るもの。リソースグループより上は作らない

    • 構造

      • parameters
        • デプロイ時にユーザーが入力する値
      • variables
        • テンプレートが持つ値
      • resources
        • デプロイの実行内容

    • 機能

      • アプリケーションの開発と同様に関数やループ処理ができる。
        • 文字列結合 Add
        • 四則演算 Add
        • ループ処理

  • プロジェクトについて

    • インフラ提供とサーバーサイド開発
    • 2社のお客様向けにほぼ同じ設計で提供 →資産と再利用できる
    • 複雑な構成をポータルで作ることができるのか

  • サンプルソース

    • variables
      • PrefixKeyで設定しておく
      • concatを使って接頭辞をセット
      • たくさん作るときに作業ミスせず、命名規則にのっとって作成できる。
    • 発行時に宛先リソースグループをミスることが大きい

    • VMの台数が異なる。初期構成より台数が増える可能性がある。

      • ループ関数を使う

    • 各VMに「連番」で割り当てる必要である。プライベートIPもわける。

    • マニアックな2重ループ
      • linkedテンプレート

  • 利用時の要点

    • 命名規則

      • なるべくシンプルにしたほうがいい
      • 後ろにつけるパターンがいい

    • 依存関係(dependsOn)

    • ファイル分割

    • ドキュメント作成
      • 依存対象のリソースを記述する
      • 中身を理解していない状態で変更しても問題ない部分をしていする。.

サーバーレスは次のステージへ〜 Durable FunctionsによるステートレスなFunctionの実現 〜

  • 今回のセッションの内容
    今回のセッションの内容はここにすべて書いてあるよ
    https://tech-lab.sios.jp/archives/12991

  • Duarable Functions

    • Azure Functionsで実現しようとすると複雑なコードになってしまうものをすごく短いコードで簡単に実現できる。
    • Azure Functions のオーケストレートツール

  • サーバーレスの限界

    • Functionsはロングランニングのバッチ実行などが苦手

  • 構成

    • クライアント関数
      オーケストレーター関数を起動するための関数
    • オーケストレーター関数
      アクティビティ」関数を起動するための関数。
    • アクティビティ関数
      実際の処理を行う関数

  • 例：並列処理

    • DurabuleFunctionsを使わない場合

    • Durable functionsを使った場合

      • たった100行くらい
      • 1/5程度

  • どうやってうごいているのか

    • control Queue
      • クライアント関数を動かす
    • WorkItem Queure
      • オーケストレーター関数を動かす
      • アクティビティ関数を動かす

  • Durable Functions目覚まし

Azureのサーバーレスで限界を超えよう～スマートスピーカースキル開発を題材に～

スマートスピーカスキルは制約が大きい

  • スマートスピーカースキルの概要と得意

    • VUI(Voice User Intesrface)が中心
    • よく使うスキル タイマー 料理のとき、カップ麺のときに超便利

  • ウェイクワード

    • ウェイクワードを変えることで起動するデバイスを分けることができる。

  • クローバーのみバッテリーを内蔵しているので、セッションとかで便利

  • 求められるスキル

    • スマホより便利なとき
      • 運転中、料理中、トレーニング中など手が離せないとき
      • 就寝時にベッドに入ったあと

  • スキルの制約

    • 複雑なパラメーターの入力が必要なものは不向き
    • タイムアウトが非常にシビア
      • 呼びかけたあとにユーザーからの入力がないとすぐにきれてしまう。
    • 返答も音声だけなので理解できる内容には限界がある。

  • スキル開発の流れ

    • バックエンドはHTTPのJSONでやり取り
    • Azureでバックアップを実装する
      • FunctionsとLogic Appsがよく出てくる

  • Logic Appsを使って完全ノーコーディング
    詳細はこの記事
    https://qiita.com/himarin269/items/f5d00e649899288e8596

    • クロスプラットフォーム対策 = ロジックの共通化をする
    • Logic Apps
      • HTTPをトリガーとするフローを作ることができる
      • ロジックアップ同士やAzure内外のサービスと連携しやすい
      • JSONの扱いが簡単
        「サンプルのペイロードを使用してスキーマを生成する」サンプルJSONからJSONの解析を行ってくれる。
      • Dialogflowと連携時、URLを一部変える必要がある

  • AzureFunctionsでのスキル開発

  • コードを書きたいなら、Azureの場合ならFunctionsが圧倒的におすすめ
  • コールドスタートの遅さがVUIの大敵
    • 動くまで20分くらいかかることもある
    • 特にVUIは応答に長いと不安にアンる
    • タイムアウトすることもある

  • コールスタート対策

    • App Serviceプランを使う
      • 安いというメリットが失われる
      • 最低でもS1プランが必要になる
    • 定型文を返しているすきにFunctionsAppを起動する
      • LogicAppで受けて、定形レスポンスを返すタイミングでFunction Appを空のリクエストして起こしておく。

  • Durable Functionsを使ってスキルの常識を覆す

    • ラインに投降した内容をスピーカーに話させる。
    • Lineとクローバーをつなげているのは「Durable Functions」のみ
    • ContinueAsNewで状態の保持