Global Azure Bootcamp 2017@Tokyo 個人まとめ

Global Azure Bootcampとは、全世界のAzure UGが同時時刻に開催するコミュニティイベント。セッションやLTなどが行われる。
2017は4月22日(土曜) 11:00~18:00に開催。
最速開催はニュージーランド。
スイスUGの発表によれば254の地域で開催された。

@Tokyoは日本マイクロソフト本社31階で開催

@Tokyoのリンク
https://jazug.connpass.com/event/52917/

参加者

100名以上が参加

Azureが好き、アップデートが聞きたいという人が半分ほど
聞きたいセッションがあってきたという人が半分ほど
AWSだけではダメだと思ってきた人も数名
大多数がAzureを触っている人
- Azure MLを使ったことがある人半分程
- cognitive servicesを使ったことがある人半分以上
- bot frameworkを使ったことがある人 2,30%　
- Python使ったことがある人ほとんど

*会場アンケートより

スケジュール

11:00〜11:10 会場案内・前振り
11:10〜12:10 Azureって何よ2017年の最新情報をゆるまとめ
12:10〜12:40 ランチ配布＆休憩
12:40〜13:30 Azure 2017年3月障害Deep Dive
13:40〜14:30 bitFlyerを支える仕組み - Azure障害の中1時間未満でサービス復旧を実現-
14:30〜15:00 サポートエンジニアが紹介する、Azure Portal/CLI 使いこなし
15:10〜15:40 Azure ML系「practice over theory」
15:40〜16:30 DocumentDB DeepDive
16:40〜17:30 オルターブースさんのAzure事例（松村さん、森田さん.NET CoreとACS、Web Apps）
17:30~17:50 LT
17:50~ クロージング

セッションメモ

Azureって何よ2017年の最新情報をゆるまとめ by Azure女子部

詳細は以下を参照してください。
https://www.slideshare.net/jazug_girls/azure2017
- Azureビギナー向けに、最近のAzure紹介
- ストレージ、PaaS、IaaSのアップデート紹介

ストレージ

2016年04月 BLOBストレージ登場(ブロックBlob, Append Blobのみ)、HOTとCOOLのオプション
2016年05月 Azure BackupでVM V2のバックアップ機能GA
2016年06月 Azure backupでPremium Storageもサポート
2016年06月 DocumentDBの複数リージョンレプリケーション機能GA
2016年09月 BLOBストレージへの格納時および取得前の暗号化/復号化機能GA
2016年09月 VMディスク暗号化機能GA
2016年10月 Site Recoveryで格納時データ暗号化機能GA
2016年11月 Azure backupでディスク暗号化しているVMのバックアップサポート
2016年12月 Data Lake StoreがGA
2016年12月ブロックBLOBの最大ブロックサイズが４MBから100MBに拡張
- 最大サイズが195GBから4.77TBに拡張
- Page Blobの最大サイズは1TBのまま
- Append Blobの最大サイズは195GBのまま
2017年02月 Managed Disks GA。ストレージアカウントの意識なしにディスクが使用可能
- マスターイメージの使用・管理が楽になった（前はストレージアカウントの数だけ用意する必要があった）
- ストレージアカウント毎の性能上限を気にしなくてよくなった

PaaS

MySQL in Appが登場
- App serviceの中だけでしか使えない
Azure App Service on Linux
- linux上でのwebアプリ実行サポート
高度なアプリケーションの再起動機能。web appsホストのローリング再起動が可能に
Azure FunctionがGA
Azure Functionのvisual studioを使ったローカル/リモートデバック機能
Azure Functionのプリコンパイルがサポート。dllをアップロードして動かせる

IaaS

VMシリーズが増えた
- コンピューティング最適化のF
- ストレージ最適化のL
- GPUインスタンスのN
- ハイパフォーマンス向けのN
Security CenterがGA
Azure DNSがGA
Azure LBがIPv6、複数VIP構成対応
VNETピアリングGA
NICのMACアドレス固定
Azure VPN GatewayでActive-Active構成サポート
Azure monitor, Azure NW watcher
Azure Stack TP3

Azure 2017年3月障害Deep Dive

資料
https://docs.com/user770511/5468/azure20173deepdive
- このセッションについては↑の資料を読むことを推奨します
- 2017年3月8日に発生した東日本のストレージ障害のroot cause analyticsで触れられた、Azureのストレージシステムで使われているロケーションサービス、ストレージスタンプ、フロントエンドレイヤー、パーティションレイヤー、ストリームレイヤーについて説明
- 実際にデータを格納しているエクステントノードの動きやデータレプリカ時の動きなども説明

参考文献
Azureストレージの論文。2011年ごろのものだが、今でも中身は通用する。
https://download.microsoft.com/download/C/0/2/C02C4D26-0472-4688-AC13-199EA321135E/23rdACM_SOSP_WindowsAzureStorage_201110_jpn.pdf

bitFlyerを支える仕組み - Azure障害の中1時間未満でサービス復旧を実現-

資料
https://www.slideshare.net/YutoTakei/azure-75296598
- 3/8の東日本のredis障害では、西日本にredisを立てることで、１時間ほどで復旧できた

ストレージ障害対応方法

GEO冗長をうまく使う
- 今のところペアリージョンが同時に落ちたことはない
- GRSが発動するには最大12時間掛かる
- でもGRSが実際に発動したことはまだない
同じアセットを別のストレージにデプロイしておく
- 接続文字列を外部から動的に変更できるようにしておく（DNS）
CDNを使う

Cloud Service

別リージョンへデプロイ
デプロイ時間が５分以上かかることを想定

Azure DNS

DNS自体を冗長
- Route53使うなど
Traffic Managerもあり

Redis Cache

あくまでキャッシュとして使う
キャッシュがそろうまで30分程

SQL Database

接続文字列を変更できるようにしておく
バックアップをとる
GEO Replicationをとる
- セカンダリで使うときは、Failoverしてからスケールアップするとよい
- 基本コピーではなく、レストアを使う

サポート系

SLAを割った場合、サービス利用料金を返金してもらえるが、自分から申請する必要がある(１か月以内)。
プレミアサポート以外は、顧客のコンテキストを保持しないので、サポートリクエスト時に自分の構成、何が起きているのかを的確に伝えると迅速な回答が期待できる

DocumentDB DeepDive

資料
https://www.slideshare.net/takekazuomi/documentdb-deep-drive
- partition keyによって負荷分散される先のpartionが決定されるので、設計が重要
- 特定のPartionにデータが集中してしまうと性能がでない
- 負荷分散の概要などを説明
- JSONやアクセス数などから必要なRUなどを計算してくれるツール
- https://www.documentdb.com/capacityplanner

オルターブースさんのAzure事例（松村さん、森田さん.NET CoreとACS、Web Apps）

資料
https://docs.com/yuta-matsumura/9364
- オリジナルソースを作るサービスのバックエンドをAzure, AWSのマルチクラウドで構築している
- 当初はcakePHPで作る予定だったが、de:code2016に参加して、Azure使ってみたくなった
-
-
- Azure DNSだけだと、Zone Apexに対応していないので、Route53に変更した
- 基本的にはTerraformやAnsibleで構成自動化しているが、一部は手で管理している

LT

DocumentDBとFunctions

資料
https://docs.com/user508130/4991/documentdbfunctions
- Storage Queue、Azure Function, DocumentDBを組み合わせて大量トランザクションに対応。
- 処理量が多くなるとDocumentDBの429問題発生
- DocumentDBのRUに合わせてFunctionをスケールさせて、Queueの処理量を調整することで429問題解消