差分表示
- 最後の更新で追加された行はこのように表示します。
- 最後の更新で削除された行は
このように表示します。
AD05 ハードコアデバッギング 資料
https://sway.com/3d6nNMtdQYxI2pJN?ref=Link
* 開発者におくる Power BI を使う時に考えるべきアーキテクチャ 〜 データを溜めるのは誰だ？
- Twitter @yugoes1021
- デモ: 参加者がQRコードを読んで、アンケートに答える
-- Power BIでリアルタイム集計
-- 実装はMicrosoft Forms -> Microsoft Flow(Logic Appsでも可能) -> Power BI Service
-- 内部の詳細は写真にURLあり
- 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型の無停止デプロイ
- サーバレス: 現代のシェルスクリプト。簡単なことを簡単にできる
- 非同期による分離
-- 機能の分離: キューの形式が同じならサービスが増えても影響ない
-- 性能の分離: キューの向こうの負荷に引きずられない
- 大本営発表は信じない。自分で試すこと
- なぜそのサービスを選ぶのか、エンジニアに説明責任がある
* CI20 プロキシ設定自動化
途中参加。ルーティングやIPアドレス制限を自動で設定するシステム？
- 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 や非冗長構成は復元力としては低い
- 高い回復性があると、いろいろと広がる
-- 秒単位のスケールアウト・スケールイン
-- 障害発生時の自己回復
-- オンザフライでのインスタンス変更
- 詳しくは、 slideshare 大規模メンテナンスの裏で何が起きていたのか
- 高い回復性を備えたマネージドサービスを選択する
-- 仕様にあるフェイルオーバーの時間・スケールアウトの時間から推測するといい
- オンプレでもNoOpsは可能だが、クラウドに似た形に役割と組織の再編成が必要
- アプリにも回復力を持たせる必要がある
-- 例: 長いバッチを走らせてるとインスタンスを移動できない
-- 「大きな処理より複数の小さな処理」「ステートレス」「非同期処理」「処理の冪等性」「処理結果をすべて記録」
-- シンプルな「リトライ」で素早く回復するのを目指す
- 非機能要求のハードルを上げる
-- 設計が大事。回復性のレベルは後から変更できない。最初から高い目標を目指す
- クラウドにお任せ → 設計がおざなりになりがち。アプリもちゃんと設計してね
* セキュリティマニアックス 〜みんなで守ろうコネクテッドカー〜
- ラジコンでデモもやります
- 自動車のソフトウェア化
-- ハードウェアの計器がディスプレイに変わってきている
-- 今どきは戦闘機もタッチパネルになってる
-- F-35戦闘機はソースコードが2500万行
-- 最近のハイエンド車は1億行。バグがあるに決まってる
- ハンダ
-- ハンダを溶かしてチップをはがし、解析用ボードを挟み込む
- 難読化
-- チップのファームウェアをダンプしたら逆アセンブルは簡単
-- 車ならではの事情としては、マイコンなので処理速度の制限がある。高温や振動に耐える必要もある
-- Hopper disassembler使ってた
- コード署名チェック
-- パスワードチェックのプログラムを解析するデモ
-- パスワードチェック後のジャンプ命令を書き換えて、任意のパスワードでチェックが通るようにした
-- こういうことができるのでコード署名しましょう
- 自動車のCASE
-- Connected, Autonomous, Sharing, EV
- CASのリスク
-- サプライチェーンリスク
--- 部品メーカーの悪い人がバックドアを仕込むリスク
-- 物理的なハッキング
--- カーシェアリングで、借し出す車に仕掛ける
--- GPS付けて個人情報を取ったりとか
-- アプリからの侵入
--- 車はちゃんとしててもアプリの実装が甘かったり
-- 汚染データ・ジャミング
--- ドローンの自動離発着が、昼休みになるとトラブる
--- 昼休みにタクシーがたくさん止まってた
--- 今のタクシーはGPSで位置を監視されている → GPSジャマー(個人でも買える)を使ってサボってた
--- それがドローンにも影響してた
-- システムへの攻撃
--- 道路情報・運行情報のシステムをハッキングして行き先を変える
- リスクの範囲が広すぎるので、みなさん協力してください
- EVでは？
-- ガソリン車でも既に電子制御(バイワイヤー)されているので同じ
-- 実車のCANメッセージを使ってレースゲームのコントローラを作った人がいる
- 代表的なセンシング技術と攻撃
-- ミリ波レーダー
-- 超音波
--- 逆位相の音波を当てると何も見えなくなる
-- カメラ
--- 強い光を当てる
- 事例: ジープチェロキー
- 事例: テスラ
- ラジコンカーハッキングデモ
-- nmap -> Webの管理画面 -> ディレクトリトラバーサル -> .bash_historyから管理パスワードを拾う -> sshログイン -> cansend
* Blazor
TODO: ノートを文字起こし
* 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おすすめ
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おすすめ
