今日もひたすら勉強と検証と殴り書きです、平成最後の夏です
※この記事は2018年7月25日に書きました

Day3 Azure App Serviceとストレージ、Backup

Web Appsって？

仮想マシンを作らなくてもWebアプリを構築できるプラットフォームです
ASP.NET, PHP, Node.js, Pythonなんかのフレームワークを使用できます
C#, HTML5, PHP, Javaなんかの一般的なPGM言語も利用可能
Visual StudioやGitHubなんかとも簡単に統合可能

その前にDay2の続きで各種開発環境を構築していきます…。

SQL Server install centerのインストールメモ

スタートメニューからInstall Centerを選択
SQL Server Management Toolsのインストール
SQL Server Management Studio 17.8.1のダウンロード
デスクトップから実行してインストールを開始
※サイズが大きいのでサーバローカルへ保存した後、インストールする

Azure PowerShellのインストールメモ

googleでAzure SDKをググって
Visual StudioだったりAzureの開発を行うためのものやコマンドラインツールを
インストールするためのページへ

コマンドラインツールからAzure PowerShellを選んで[実行]
Azure PowerShell version 5.7.0 (2018/7/24時点)をインストールする

Az Copy(Storage用)のインストールメモ

これも上記のAzure SDKのページから[Az Copy]を選んでインストールする

App Serviceのプランと価格

Freeは無料だけどインスタンスを複数持ったりとかカスタムドメインを割り当てられない
Sharedは専有できないけども安い、カスタムドメイン持つので開発環境にGood
BasicはSharedの上位互換で、インスタンス複数まで3まで作れる(Front/Backend)
StandardはVPNハイブリッド接続が使え、express-routeなどが使えるようになる
PremiumやIsolatedという上位のプランがある、値段はSharedの20倍〜50倍以上

Azure App Serviceを実装してみよう

左から[App service]から[追加][Web App]を選択する
アプリ名、リソースグループ（これは消しやすいよう新規で）作る
OS環境はWindowsを選択
App Serviceプランを新規で作っておく
Application insightsはONにしておいて、[作成]

Azure Portalから発行プロファイルを取得

[App service]から該当のアプリ選んだら、発行プロファイルを取得します
Visual Studioの環境にPublishSettingsファイルを移す

デプロイスロットの設定(Standard以上)

デプロイスロットとはPaaSであっても裏側では仮想サーバ（Web server)が可動している
そのWeb serverの中の運用スロットにアプリが展開されている
スタンダード以上のプランの場合は別にデプロイスロットを作って運用スロットの前のステージングとして使える
Localの開発環境でテストしたらデプロイスロットへアプリを移しテスト
問題なければ運用スロットとデプロイスロット間でスワップ（入れ替え）して本番適用

[デプロイスロット]からスロットの追加を選択
OKでデプロイスロットを作っておく

デプロイ資格情報

[デプロイ資格情報]からFTP/デプロイユーザ名を入力
パスワードを入れておいて[保存]をクリック

Visual Studioの検証環境でテスト

研修用のソリューションファイルをVisual Studioで参照
デバッグ無しで実行してローカル開発環境上でWeb pageが立ち上がるかテスト
その後、先程ダウンロードしておいた発行プロファイルをデスクトップに配置
ソリューションファイル名を右側のペインから選び右クリックで[発行]を選択
その後、発行プロファイルをインポートする

Traffic Manager

大規模なグローバルWebアプリを実行する場合にDNSを使って各Webアプリのエンドポイントへ負荷分散する仕組み

Azureロードバランサは同一リージョンのインスタンスのみに対応
異なるリージョン間で負荷分散するにはTraffic Managerを使用する
Traffic Managerはラウンドロビンの機能を使って負荷分散するため別のリージョン間または異なるサブスクリプション間での負荷分散も可能
DNSラウンドロビンとはDNSサーバに同一のFQDN/異なるIPアドレスのレコードを作成する方法
名前解決要求があるとレコードを順番に使用することで負荷分散する

Azureのストレージ

コンポーネントは下記の通り

Storage
DocumentDB
Azure SQL
StorSimple
CDN（ビデオやオーディオ、ストリーミング）にも対応

Azure Storageの概要

URL
可用性をたもつためのレプリケーション
ストレージの種類
- BLOBストレージ
  - 最も汎用的なストレージ
  - 仮想マシンのディスクやログが格納される、一番利用される
- テーブルストレージ
  - エクセルのデータシートみたいなもの
  - 文字情報を行（エンティティ）で管理する
  - 非リレーショナルなDB(OracleやSQLとは違う）
- キューストレージ
  - アプリのやり取り
  - 一時記憶域として利用される
- ファイルストレージ
  - 一番新しいBLOBに似ている（非構造化ファイル）
  - 従来のオンプレのWindowsファイル共有をサポートする
  - SMB(ファイル共有プロトコル)によるファイル共有サービスをAzure上で提供
  - ファイルサーバを要するアプリケーションシステム向けのサービス
    - 例：IaaSでわざわざNASを構築する手間が省ける

ストレージアカウント

Azureストレージを利用するためにアカウントを作成する必要がある
管理ディスク：ストレージアカウントやディスクなどを勝手に作ってくれる
昔はストレージアカウントを作って、ストレージのタイプ(BLOB)やストレージを作成するという工程があった
場所：明示的に作った場合FQDNがポータルから確認でき下記のようなURLが定義される
- 例：http://mystorageaccount.blob.core.windows.net
レプリケーションオプション
- 対障害性と可用性を確保するためにデータをレプリケートする
- ストレージアカウント内のデータを別の物理ホストや別リージョンのホストへ複製する
- 複製されるのはストレージアカウント内のデータのみとなる
- このオプションでは例えば仮想マシンならVHDだけが複製される
- 異なるリージョン間での複製（地理冗長/GRS)は定められたペアリージョンのみ
  - 非同期でデータも多いので値段が高め
- ローカル冗長(LRS)は1つのリージョンの1つの施設内に存在する3つのコピー間でデータ動悸される
- ゾーン冗長(ZRS)は1つのリージョン、複数の施設内でレプリケートする
  - 例：JP Eastは埼玉と東京DCがあるがZRSは未だ対応していない
- 可用性セット(AS)とは違う、VHDだけ、ストレージ内のデータに特化している
- 読み取りアクセス地理冗長
  - 西日本は読み取り専用の西日本リージョンを見せる
  - 東日本は本番で東日本リージョンを見せて本番ワークロード負荷を下げる
  - 西日本からアクセスしたらアプリ上で西日本リージョンストレージを見せるなど設計/実装が開発者側で必要（MS社はそこまでサポートしてくれない）

地理冗長(GRS)の障害時の挙動

何らかの天災で東日本リージョンが動かなくなったら、マイクロソフトは復旧の余地がある限り、まずはプライマリ拠点での復旧を検討する
だめならストレージアカウントのフェールオーバが実施されセカンダリリージョンのIPの切り替えれる（ユーザ側で操作はする必要がない、できない）
本当にシステム全体をDRに備えたいなら東や西にも同一のシステムを構築する必要がある（ユーザ側でDR対応でシステムを切り替えたい、コストは倍になる）

ストレージアカウントを作ってみる

左の[ストレージアカウント]を選択して追加をクリック
アカウント名、デプロイモデルを選択
アカウントの種類は汎用を選ぶ
場所やレプリケーション(LRSやGRS)を選ぶ
仮想ネットワークはIaaSからこのストレージへアクセスができるようになる設定

ストレージアカウントに対するコンテナ(ファイル入れる用のハコ）を作成

コンテナを作成からハコを作る
あとはファイルをアップロードするだけ
BLOBではなくファイルストレージを使えばSMBが使える
Windows系からネットワークドライブをマウントするとNASとして使える（便利）

CDN (Content Delivery Network)

ユーザエクスペリエンス向上
分散型サービス拒否攻撃からの保護
スケーラビリティの向上

Azureバックアップ

バックアップしたいサーバ等からAzure Portalへブラウザでアクセス
「すべてのサービス]から検索ウィンドウで[Re...]と入れる
[Recovery Servicesコンテナ]を選択
名前等を入れて作成を押してデプロイ

Azure Recovery Services Agentと設定

作成したRecovery Servicesコンテナを選択
プロパティからセキュリティPINを取得
Backupの資格情報もダウンロードする　※最新のRecovery Services Agentにチェック
Agentをダウンロードしてインストールする
[バックアップ]から資格情報をダウンロードする
VaultCredentialsをデスクトップへ保存
Agentのインストールウィザードからポチポチして[登録処理を続行]をクリック
資格情報コンテナを先程のVaultCredentialsを選択して登録
暗号化の設定でパスフレーズを入力、パスフレーズはバックアップする必要有
[完了]をクリックしてAzureBackupに登録される

Backup Agent上でスケジュール設定

右側からスケジュールを選択
バックアップ対象をツリーから選択
バックアップスケジュールを設定
リテンションポリシーの設定
正常に完了を確認できたら閉じるをクリック
[いますぐバックアップ]をクリック
[バックアップ]をクリック

Azure Backupから復旧(リストア)

Backup site Recoveryのコンテナを選択
[バックアップアイテム]を選択
どこからバックアップされたがリストで見ることができる　例：Azure Backup Agent
Azure Backup Agentをダブルクリック(ポータルでは確認まで）
Azure Backupのエージェントから[データ回復]を選択
対象のフォルダやファイルに対してマウントしてバックアップの過去データを参照できる
必要な分だけファイル（エクスプローラ）でリストアできる

Azure Site Recovery

オンプレミスのDRにも利用できる
オンプレミスの環境をAzureへ移行する方式でSite Recoveryをすることもある

Azure SQL Database

非リレーショナルなDBで文字列が基本、シンプルでビックデータなどに使える
OS等の保守責任からも逃れることが出来、DBA(DB管理者）に優しい
インスタンスを2つ以上作ると99.99%の可用性がついてくる

Azure SQL DBの作り方

左から[SQLデータベース]を選択し追加をクリック
データベースの名前を作成（サーバの名前じゃないよ）
リソースグループを選択
ソースの選択は[空のデータベース]を選択
サーバを選び[新しいサーバの作成]を選択
サーバ名や作成するユーザ情報を入力
※App servicesのときはサーバは意識ほぼしなかったけどサーバを作らなければならない
価格レベルなどの入力して[作成]

SQL Server Management Studio

スタートからManagement tools 17から管理ツールを開く
左から事前に読み込んだテーブルを選択（テーブルは別途作る必要がある）
Azure PortalからAzure SQLのFQDN（サーバ名)を取得
Management Studioから[ファイル]/[オブジェクトエクスプローラを接続]
FQDNをサーバ名に入れて、認証はSQL Server認証、Azure SQL DBのユーザ情報
Studioの左側にAzure SQLが見れたらOK

Azure SQL Databaseは管理マシンが存在する場所で出力ポートTCP1433が有効である必要がある

とりあえずAzure SQLは盛りだくさんなので、今日はここで殴り書きをストップ

※この記事は2018年7月25日に書きました