Global Azure Bootcamp 2017@Tokyo 個人まとめ

# Global Azure Bootcamp 2017@Tokyo 個人まとめ

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

@Tokyoは日本マイクロソフト本社31階で開催
![@Tokyoは日本マイクロソフト本社31階で開催](https://s3-ap-northeast-1.amazonaws.com/hackmd-jp1/uploads/upload_9b92837eda01cda86a4757653ccc3f37.png)

![会場様子2](https://s3-ap-northeast-1.amazonaws.com/hackmd-jp1/uploads/upload_28fe4bd82cf66dcd4a5d45a0565c2cf4.png)
![会場様子2](https://s3-ap-northeast-1.amazonaws.com/hackmd-jp1/uploads/upload_01ccc557ed92ce76f98fdf294de2060e.png)

@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使ってみたくなった
- ![インフラ全体像](https://s3-ap-northeast-1.amazonaws.com/hackmd-jp1/uploads/upload_bdd1202a68fddd58b4339d2b0afe6015.png)
- ![使っているツール](https://s3-ap-northeast-1.amazonaws.com/hackmd-jp1/uploads/upload_b7e1bd7092717d6428094d691a00c2d2.png)
- 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問題解消
![アーキテクチャ](https://s3-ap-northeast-1.amazonaws.com/hackmd-jp1/uploads/upload_8ccefe55120deeb28915b67a4a51c3e5.png)