Microsoft decode 2018 2日目

AD05 ハードコアデバッギング 資料
https://sway.com/3d6nNMtdQYxI2pJN?ref=Link

開発者におくる Power BI を使う時に考えるべきアーキテクチャ 〜 データを溜めるのは誰だ？ †

• Twitter @yugoes1021

• デモ: 参加者がQRコードを読んで、アンケートに答える
• Power BIでリアルタイム集計
• 実装はMicrosoft Forms -> Microsoft Flow(Logic Appsでも可能) -> Power BI Service
• 内部の詳細: アンケートを即可視化！〜MS Forms ⇒ MS Flow ⇒ Power BI〜

• Power BI Desktopでレポート作成 → publish
• Google Analyticsなどとも接続可能
• 利用するには、Office 365のアカウントを作るのが正攻法
• Azure ADを自分で作ればアカウント不要
• Power BI Embedded
• アプリにレポートを埋め込みたい場合に使う
• 大事なのは
• 計画
• ビジネスニーズ
• シナリオ
• レポートを見て何をするのか？
• レポートが表現するストーリー
• 作り直し、やり直しを恐れない
• データを見て検討し、現場に反映するまでがBI
• 現場の人が直接データを見るのもアリ
• ある時点までのデータ・今この瞬間のデータ は明確に分ける
• 分析用レポート・リアルタイムダッシュボード
• リアルタイムダッシュボード
• 現状を見て、予定通りか、異常はないか(OKかNGか)

データの取り方 †

• データを取る
• インポート
• DirectQuery
• ライブ接続
• データを待つ
• REST API

• インポート
• 公開すると、Power BI Serviceから定期的にデータを取りに行く
• 常に全件更新
• じっくり分析用
• DirectQuery
• レポートを参照した瞬間にSQLが発行される
• 長時間かかるクエリには不向き
• ある程度のリアルタイム性
• ライブ接続
• SQL Server/AzureのAnalysis Serviceに接続
• DirectQueryと同じ動作
• REST API
• Power BI ServiceにJSONをPOSTするとデータ更新
• レポートを見てる最中もリアルタイム更新される
• Power BI Desktopは使えない？
• あんまり高頻度でリクエストするとエラーになる(0.5秒おきくらいを推奨)

DAX †

• Data Analysis Expressions
• 計算列やメジャーを作成するために使用する言語
• Excelライク

その他 †

• Excelで集計作業すると、データを準備するのに労力の80%くらいがかかっている
• DBとBIツールを連携すると、そこを20%くらいにできる
• リアルタイムダッシュボード
• ストリームデータもDBに保存しておく。後から分析できるようにするため
• オンプレミスデータゲートウェイ
• データを溜めるのは誰だ？
• エンジニアはもちろん、BIに関わる全ての人

なぜ、そのサービスを選ぶのか？ークラウドにおけるアーキテクチャ選択眼 †

• クラウドでは、サービスを前提として必要な部分だけを作る or 設定すれば動く
• クラウドでは変化に適応できる
• なぜならクラウド自身がそれがないと成立しないから
• クラウドの特性を理解した上で設計する
• クラウド前提のアーキテクチャを理解する
• 制約を受ける代わりに、変化する力を得る
• 何が制約で、何を得られるかを正しく理解する
• 最先端が正しいとは限らない
• オンプレをそのままクラウドに持って行くのは難しい
• コンテナは「実行環境のバージョン管理」
• Blue Green型の無停止デプロイ
• サーバレス: 現代のシェルスクリプト。簡単なことを簡単にできる
• 非同期による分離
• 機能の分離: キューの形式が同じならサービスが増えても影響ない
• 性能の分離: キューの向こうの負荷に引きずられない
• 大本営発表は信じない。自分で試すこと
• なぜそのサービスを選ぶのか、エンジニアに説明責任がある

加速するSaaS、PaaSシフトに対応できるNWソリューション by Azure PaaS †

• Web Apps
• 当時はIISのみ
• グローバルIPが4つ。メンテナンスで変更される
• 20秒ほどアクセスしないとコールド状態になり、次回のアクセスが6〜7秒遅延する
• SQL
• Azure ADでユーザー認証
• Application Insight
• Web Apps, FunctionsからTrackEventを送信

NoOps へ舵を切れ 〜 Azure で実現するサーバレス自律運用システム †

• 完全自動化はほんとに可能なのか？
• NoOps = No Operations…ちょっと違う
• No Uncomfortable Ops。運用の嬉しくないところをなくそう
• 利用者の体験を妨げない
• 「トイル」の最小化(リリース手続き・パッチ適用・リソース監視・夜間待機など)
• コストの最適化
• 障害時の切り分け・不具合修正・デプロイなどほとんどを人間が対応している
• 緊急対応・回復処理はシステムに任せて、人間は原因究明に集中したい
• インフラ担当の働き方改革になる
• NoOpsの3つの能力
• 自己修復
• 無停止メンテナンス
• 自律的リソース調整
• 予定外の負荷変動に自律的に対応
• 実例: AzureのMeltdown/Spectreへの対応
• IaaS利用者からクレーム殺到
• PasS利用者は気づきもしなかった
• Azureだと「問題の診断と解決」で裏で走ったメンテナンスのログが見れる
• 詳細はセッションAD38で
• 自己修復は「取り回しの軽さ」
• ChefでWordpressを構築: 240秒
• WebApp for Containersだと14秒
• 復元力。「壊れない」から「いつでも回復できる」への価値観の転換
• https://docs.microsoft.com/ja-jp/azure/architecture/patterns/category/resiliency
• 回復性 = 復元力 + 回復メカニズム
• 30秒で復旧できれば、障害ではなく遅延で済む
• 一つの目安として、復元力が高いのはコンテナやサーバレスとして扱うもの、VM や非冗長構成は復元力としては低い
• 高い回復性があると、いろいろと広がる
• 秒単位のスケールアウト・スケールイン
• 障害発生時の自己回復
• オンザフライでのインスタンス変更
• 高い回復性を備えたマネージドサービスを選択する
• 仕様にあるフェイルオーバーの時間・スケールアウトの時間から推測するといい
• オンプレでもNoOpsは可能だが、クラウドに似た形に役割と組織の再編成が必要
• アプリにも回復力を持たせる必要がある
• 例: 長いバッチを走らせてるとインスタンスを移動できない
• 「大きな処理より複数の小さな処理」「ステートレス」「非同期処理」「処理の冪等性」「処理結果をすべて記録」
• シンプルな「リトライ」で素早く回復するのを目指す
• 非機能要求のハードルを上げる
• 設計が大事。回復性のレベルは後から変更できない。最初から高い目標を目指す
• クラウドにお任せ → 設計がおざなりになりがち。アプリもちゃんと設計してね

セキュリティマニアックス 〜みんなで守ろうコネクテッドカー〜 †

• ラジコンでデモもやります
• 自動車のソフトウェア化
• ハードウェアの計器がディスプレイに変わってきている
• 今どきは戦闘機もタッチパネルになってる
• F-35戦闘機はソースコードが2500万行
• 最近のハイエンド車は1億行。バグがあるに決まってる
• ハンダ
• ハンダを溶かしてチップをはがし、解析用ボードを挟み込む
• 難読化
• チップのファームウェアをダンプしたら逆アセンブルは簡単
• 車ならではの事情としては、マイコンなので処理速度の制限がある。高温や振動に耐える必要もある
• Hopper disassembler使ってた
• コード署名チェック
• パスワードチェックのプログラムを解析するデモ
• パスワードチェック後のジャンプ命令を書き換えて、任意のパスワードでチェックが通るようにした
• こういうことができるのでコード署名しましょう
• 自動車のCASE
• Connected, Autonomous, Sharing, EV
• CASのリスク
• サプライチェーンリスク
• 部品メーカーの悪い人がバックドアを仕込むリスク
• 物理的なハッキング
• カーシェアリングで、借し出す車に仕掛ける
• GPS付けて個人情報を取ったりとか
• アプリからの侵入
• 車はちゃんとしててもアプリの実装が甘かったり
• 汚染データ・ジャミング
• ドローンの自動離発着が、昼休みになるとトラブる
• 昼休みにタクシーがたくさん止まってた
• 今のタクシーはGPSで位置を監視されている → GPSジャマー(個人でも買える)を使ってサボってた
• それがドローンにも影響してた
• システムへの攻撃
• 道路情報・運行情報のシステムをハッキングして行き先を変える
• リスクの範囲が広すぎるので、みなさん協力してください
• EVでは？
• ガソリン車でも既に電子制御(バイワイヤー)されているので同じ
• 実車のCANメッセージを使ってレースゲームのコントローラを作った人がいる
• 代表的なセンシング技術と攻撃
• ミリ波レーダー
• 超音波
• 逆位相の音波を当てると何も見えなくなる
• カメラ
• 強い光を当てる
• 事例: ジープチェロキー
• 事例: テスラ
• ラジコンカーハッキングデモ
• nmap -> Webの管理画面 -> ディレクトリトラバーサル -> .bash_historyから管理パスワードを拾う -> sshログイン -> cansend

C# で Single Page Web アプリケーションを開発できる Blazor ― その魅力 †

• 講演者の経験
• サーバをC#で実装
• クライアントをAngular + TypeScriptで実装
• Blazorは、WebAssemblyで.NETランタイムを実行する仕組み
• AjaxでDLLを読む
• SPAのフレームワーク込み
• VSのIDEサポート
• Razorテンプレートを使用
• C#なのでサーバとクライアントで型やロジックを共有できる
• JSONだと日付型のシリアライズがいまいち(?)
• NuGetライブラリの資産も使える
• html内もリファクタや参照元検索ができる
• まだExperimental
• 欠点: ダウンロードするDLLのサイズが大きい

HoloLens で実装する AI と IoT †

• 今までのIT技術は、デスクワーカーの効率化が中心だった
• HoloLensで現場の作業者(ファーストラインワーカー)の効率化をしたい
• 空間音響
• 活用シーン
• トレーニング
• 作業支援
• 設計
• 構成・見積もり
• 販売支援
• Hololens → クラウド → PCなど
• 熟練者の作業の流れを記録
• IoTのエッジデバイスとして使う
• IoTデバイスで集めたデータをHololensで可視化する
• バルブを閉めたら、ちゃんと水が止まったかをHololensで確認
• クラウド側の流れは画像参照
• 本番環境では、Power BIとも接続しておくと、Hololensを持ってない人もデータが確認できる
• IoTデバイスは、オンラインにラズパイのシミュレータもある
• Dynamics365
• Hololensで作業のアシストはできた
• それ以外の指示書作成・スケジュール・報告・在庫管理などを効率化
• AI
• ボイスメモをテキスト化・翻訳して記録
• Siriみたいなエージェントと会話
• COTOHAと連携してみた
• コピー機が紙詰まり
• プリンタの状態はクラウドにつながってて把握されている
• 今プリンタの前にいることはHololensでわかる
• ここを直してください、と3Dモデルで表示

帰ってきた インフラ野郎 Azure チーム 〜Azure データセンター テクノロジー解体新書 2018春〜 †

• 非公開情報は出せませんが、論文でこっそり公開してるようなのをいろいろ話します
• Azureなう
• 自前で海底ケーブル引いてます
• Skylakeの48コアが主流
• リスク = 発生確率 * 影響の大きさ
• これまでは後者、広域災害とかを重視してた
• これからは前者、データセンターレベルの障害も重視。意外とこちらが多かった
• IP anycastで、すべてのゾーンにロードバランサを持ってる
• アベイラビリティゾーンの設計は効率重視型・都市適応型がある
• 都市適応型でも遅延は2ms程度に抑えている
• Azure Cloud Shell
• ユーザごとにdockerでubuntuコンテナを生成
• 20分無操作で破棄される
• $HOMEの下はAzure Filesに永続化される
• よく使うツールをかなり網羅している
• Azureの認証周りが設定済み
• Powershell Core on Linuxも今度出る？
• ライブマイグレーション
• インスタンスを動かしたまま引っ越す
• 故障が予測できた場合や、メンテナンス用にサーバを空ける用途にも使われる
• Azure OS
• Windows Serverのサブセット
• ネイティブコードのみ、ドライバなどもない
• できるだけ再起動したくない
• ライブパッチングで、最大30秒程度の停止で済む
• ユーザーレベルではAVSetsをおすすめ
• AVSets内の複数のVMは同時にメンテナンスされない(Update Domain)
• メンテナンス情報が取れる(Instance Metadata)
• PaaSなら上記は勝手にやってくれる
• リージョン間ネットワーク
• Azureサービス間の通信はインターネットに出ない
• SmartNIC
• FPGAを活用したNIC (Accelerated Networking)
• 障害はストレージが多いが、ストレージにアクセスするネットワークの障害が多い
• そこを安定させる目的もある
• DPDK
• アプリからNICに直接アクセス
• VM間のレイテンシが数マイクロ秒になる
• 同一リージョン内 数百us, 28.6Gbps
• 東京・大阪間 数ms, 6Gbps
• (高いインスタンスを使ってるが、デフォルト設定)
• Terraform
• マルチクラウド対応のプロビジョニングツール
• Azure SDK for Goも拡充中。Goおすすめ