今日もひたすら勉強と検証と殴り書きです、平成最後の夏です
※この記事は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を構築する手間が省ける
- BLOBストレージ
ストレージアカウント
- Azureストレージを利用するためにアカウントを作成する必要がある
- 管理ディスク：ストレージアカウントやディスクなどを勝手に作ってくれる
- 昔はストレージアカウントを作って、ストレージのタイプ(BLOB)やストレージを作成するという工程があった
- 場所：明示的に作った場合FQDNがポータルから確認でき下記のようなURLが定義される
- レプリケーションオプション
- 対障害性と可用性を確保するためにデータをレプリケートする
- ストレージアカウント内のデータを別の物理ホストや別リージョンのホストへ複製する
- 複製されるのはストレージアカウント内のデータのみとなる
- このオプションでは例えば仮想マシンなら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日に書きました