Microsoft decode 2018 2日目
の編集・凍結
Top
/
Microsoft decode 2018 2日目
[
トップ
] [
編集
|
凍結
|
差分
|
添付
|
リロード
] [
新規
|
一覧
|
検索
|
最終更新
|
ヘルプ
]
Active
Rubyチートシート
成果物リスト
勉強会ログ
↑
アイデア
Webサービス案
Androidアプリ案
電子工作案
GreaseMonkey案
contribute
編集
↑
Recent
2023-11-12
自動車保険
2023-08-04
HDDリスト
2023-08-03
docker
2023-05-17
Rubyチートシート
2023-03-30
RAID5/トラブル20230324
2023-03-25
PC/misuzu
2023-03-24
PC
2023-03-23
PC/DESKTOP-7SL5J8R
2022-12-16
Linux
2022-11-09
Linux/ディスクイメージ取得
2021-05-23
CTF
2021-03-17
PC/misumi
2020-08-31
COMP
2020-03-28
PC/misumi/ubuntu
Windows 10
2018-06-04
Microsoft decode 2018 2日目
Microsoft decode 2018 1日目
2018-04-07
カメラ
2018-01-06
電力自由化
2017-12-21
CROSS×BEATS
ページを凍結するにはパスワードが必要です。
B
I
U
D
H
[[]]
<br>
--
管理者パスワード:
AD05 ハードコアデバッギング 資料 https://sway.com/3d6nNMtdQYxI2pJN?ref=Link #contents * 開発者におくる Power BI を使う時に考えるべきアーキテクチャ 〜 データを溜めるのは誰だ? [#ycd00f33] - Twitter @yugoes1021 - デモ: 参加者がQRコードを読んで、アンケートに答える -- Power BIでリアルタイム集計 -- 実装はMicrosoft Forms -> Microsoft Flow(Logic Appsでも可能) -> Power BI Service -- 内部の詳細: [[アンケートを即可視化!〜MS Forms ⇒ MS Flow ⇒ Power BI〜>https://www.slideshare.net/yugoes1021/ms-forms-ms-flow-power-bi-83167435]] - Power BI Desktopでレポート作成 → publish -- Google Analyticsなどとも接続可能 -- 利用するには、Office 365のアカウントを作るのが正攻法 -- Azure ADを自分で作ればアカウント不要 - Power BI Embedded -- アプリにレポートを埋め込みたい場合に使う - 大事なのは -- 計画 -- ビジネスニーズ -- シナリオ -- レポートを見て何をするのか? -- レポートが表現するストーリー -- 作り直し、やり直しを恐れない - データを見て検討し、現場に反映するまでがBI -- 現場の人が直接データを見るのもアリ - ある時点までのデータ・今この瞬間のデータ は明確に分ける -- 分析用レポート・リアルタイムダッシュボード -- リアルタイムダッシュボード --- 現状を見て、予定通りか、異常はないか(OKかNGか) ** データの取り方 [#kf18ddee] - データを取る -- インポート -- 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 [#d0ce7bc3] - Data Analysis Expressions - 計算列やメジャーを作成するために使用する言語 - Excelライク ** その他 [#sd642017] - Excelで集計作業すると、データを準備するのに労力の80%くらいがかかっている -- DBとBIツールを連携すると、そこを20%くらいにできる - リアルタイムダッシュボード -- ストリームデータもDBに保存しておく。後から分析できるようにするため - オンプレミスデータゲートウェイ - データを溜めるのは誰だ? -- エンジニアはもちろん、BIに関わる全ての人 * なぜ、そのサービスを選ぶのか?ークラウドにおけるアーキテクチャ選択眼 [#qaef3362] - クラウドでは、サービスを前提として必要な部分だけを作る or 設定すれば動く - クラウドでは変化に適応できる -- なぜならクラウド自身がそれがないと成立しないから - クラウドの特性を理解した上で設計する -- クラウド前提のアーキテクチャを理解する - 制約を受ける代わりに、変化する力を得る -- 何が制約で、何を得られるかを正しく理解する -- 最先端が正しいとは限らない - オンプレをそのままクラウドに持って行くのは難しい - コンテナは「実行環境のバージョン管理」 - Blue Green型の無停止デプロイ - サーバレス: 現代のシェルスクリプト。簡単なことを簡単にできる - 非同期による分離 -- 機能の分離: キューの形式が同じならサービスが増えても影響ない -- 性能の分離: キューの向こうの負荷に引きずられない - 大本営発表は信じない。自分で試すこと - なぜそのサービスを選ぶのか、エンジニアに説明責任がある * 加速するSaaS、PaaSシフトに対応できるNWソリューション by Azure PaaS [#y55eaa39] 途中参加。ルーティングやIPアドレス制限を自動で設定するシステム? - Web Apps -- 当時はIISのみ -- グローバルIPが4つ。メンテナンスで変更される -- 20秒ほどアクセスしないとコールド状態になり、次回のアクセスが6〜7秒遅延する - SQL -- Azure ADでユーザー認証 - Application Insight -- Web Apps, FunctionsからTrackEventを送信 * NoOps へ舵を切れ 〜 Azure で実現するサーバレス自律運用システム [#e1dec96f] - 完全自動化はほんとに可能なのか? - 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は可能だが、クラウドに似た形に役割と組織の再編成が必要 - アプリにも回復力を持たせる必要がある -- 例: 長いバッチを走らせてるとインスタンスを移動できない -- 「大きな処理より複数の小さな処理」「ステートレス」「非同期処理」「処理の冪等性」「処理結果をすべて記録」 -- シンプルな「リトライ」で素早く回復するのを目指す - 非機能要求のハードルを上げる -- 設計が大事。回復性のレベルは後から変更できない。最初から高い目標を目指す - クラウドにお任せ → 設計がおざなりになりがち。アプリもちゃんと設計してね * セキュリティマニアックス 〜みんなで守ろうコネクテッドカー〜 [#x05a2e75] - ラジコンでデモもやります - 自動車のソフトウェア化 -- ハードウェアの計器がディスプレイに変わってきている -- 今どきは戦闘機もタッチパネルになってる -- 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 ― その魅力 [#q7d6ee22] - 講演者の経験 -- サーバをC#で実装 -- クライアントをAngular + TypeScriptで実装 - Blazorは、WebAssemblyで.NETランタイムを実行する仕組み -- AjaxでDLLを読む -- SPAのフレームワーク込み -- VSのIDEサポート -- Razorテンプレートを使用 - C#なのでサーバとクライアントで型やロジックを共有できる -- JSONだと日付型のシリアライズがいまいち(?) - NuGetライブラリの資産も使える - html内もリファクタや参照元検索ができる - まだExperimental - 欠点: ダウンロードするDLLのサイズが大きい * HoloLens で実装する AI と IoT [#s3ccf182] - 今までのIT技術は、デスクワーカーの効率化が中心だった - HoloLensで現場の作業者(ファーストラインワーカー)の効率化をしたい - 空間音響 - 活用シーン -- トレーニング -- 作業支援 -- 設計 -- 構成・見積もり -- 販売支援 - Hololens → クラウド → PCなど -- 熟練者の作業の流れを記録 -- IoTのエッジデバイスとして使う - IoTデバイスで集めたデータをHololensで可視化する -- バルブを閉めたら、ちゃんと水が止まったかをHololensで確認 -- クラウド側の流れは画像参照 -- 本番環境では、Power BIとも接続しておくと、Hololensを持ってない人もデータが確認できる - IoTデバイスは、オンラインにラズパイのシミュレータもある - Dynamics365 -- Hololensで作業のアシストはできた -- それ以外の指示書作成・スケジュール・報告・在庫管理などを効率化 - AI -- ボイスメモをテキスト化・翻訳して記録 -- Siriみたいなエージェントと会話 -- COTOHAと連携してみた -- コピー機が紙詰まり --- プリンタの状態はクラウドにつながってて把握されている --- 今プリンタの前にいることはHololensでわかる --- ここを直してください、と3Dモデルで表示 * 帰ってきた インフラ野郎 Azure チーム 〜Azure データセンター テクノロジー解体新書 2018春〜 [#eb2e1568] - 非公開情報は出せませんが、論文でこっそり公開してるようなのをいろいろ話します - 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おすすめ
凍結する
凍結しない
タイムスタンプを更新
テキスト整形のルールを表示する
Last-modified: 2018-06-04(月) 11:44:07