Azure Site Recovery – その概要と、可能なこと・不可能なこと

ASR – その意義と概要

Public Cloud として Azure を選択するメリット (Advantage) の 1 つに、Microsoft が長年培ってきたオンプレミス・テクノロジーとの融合 (ハイブリッド技術) がある。クラウドへの本格参入ができない古い体質の業界や企業では、オンプレミスにある資産を Public Cloud に移すのは不可能かもしれないが、こうした安価でスケーラブルなクラウドが、いざというときのリカバリー サイトとして利用できるなら現実味があるだろう。
Azure Site Recovery (ASR) は、そうした「現実解」のニーズに対応した Public Cloud のサービスと言って良い。

Azure Site Recovery (ASR) を介することで、オンプレミスのマシン イメージを Azure 上に Replication し、いざオンプレミス環境に障害が発生した際には、このバックアップされたイメージ (.vhd) を元に、すぐに Azure 上にマシンを稼働して (Failover して)、VPN や閉域網などを経由して企業内から継続的にサービスを利用可能にする。
Primary の復旧が完了したら、Reverse Replicate といって、稼働中の (Azure 上の) リカバリー サイトを元の Primary サイトへ戻すための仕組み (要するに “Failback”) も提供する。


(From Microsoft Hybrid Cloud Blog)

この Azure Site Recovery (ASR) について、よくある疑問点 (利用時の初歩的な質問) を以下の 3 つの観点でまとめたので、これから導入を検討される方は参考にしていただきたい。
後述の通り、ネットワークまわりをどう設計するかは、充分な考察が必要だ。

ASR – よくある疑問 (まとめ)

対象のソース

Primary として選べるソースタイプとしては、以下が利用可能。
なお、現在、Windows Server 2016 の Physical Server はサポートされていないので注意してほしい。(いずれ対応されると思うが)

  • Physical Machine (On-Premise)
  • Hyper-V 上の Guest VM (On-Premise)
  • VMWare 上の VM (On-Premise)
  • Azure 上の VM

いまでは Azure 上の VM などもリカバリー可能だが、ASR は、当初はオンプレミス上の環境をクラウドにリカバリーして事業継続するためのサービスとして登場しており、ASR を中継することで、On-Premise to Azure だけでなく、Azure を中継した On-Premise to On-Premise のリカバリーに使うことも可能だ。

ネットワーク

ASR ではいろいろなアーキテクチャが考えられるが、ここでは話が混乱しないよう On-premises to Azure で考えてみよう。

上述の通り、Failover 後は、企業内からリカバリー先のマシン (今回の場合、Azure 上のマシン) を利用するため、Azure 上の Recovery Site と On-Premise との間はあらかじめ同じネットワークに入れることになる。(あらかじめ Azure の Site-to-Site VPN や ExpressRoute で Recovery 先と接続しておく。)
このように、ASR 利用時は、DR (Disaster Recovery) 時も踏まえた充分なトポロジー設計が必要になる。

例えば、Azure では、同一ネットワーク上に同一のアドレス空間を持たせることはできないので、Recovery された VM は一般に IP アドレスが変更される。このため、リカバリー対象のマシンで DNS サーバーとの接続が必要になり、Azure の Virtual Network (VNet) 上の DNS Server としてオンプレ側の DNS Server を指定したり、あるいは Failover の際に DNS Server も Replication するなど方針を決める必要があるだろう。(Failover 先の Azure VM で IP Address を同じにすることも不可能ではないが、ASR がこうした仕組みを備えているわけでないため、自身でこうした Subnet Failover (転換処理) を実装することになる。)

ASR は、上述の通りイメージ ベースでの Recovery になるので、すべてを ASR に頼るのではなく、データベース (RDB), AD (Active Directory) などでは、下記のようなコンポーネントが持つ Recovery テクノロジーを組み合わせることも検討する。(Multi-Tier アプリケーションのように複数台のマシンで状態の一貫性が必要になる場合には、Multi VM Consistency という機能を有効化することで一貫性を維持できる。)

また、オンプレミスから Azure への Replication (delta による差分反映など) では一般にインターネット (Azure に向けての inbound の https ポート) が使われるが、以下も考慮しておこう。

  • トラフィック送信にインターネットを使わず、Azure ExpressRoute Public Peering を使うよう構成することも可能
  • ただし、現在、トラフィック送信に Site-to-Site VPN を使うことは不可能

一方、Failback では、一般にインターネット回線は利用できないので注意してほしい。Failback の場合は、Azure 側から On-Premise への https による inbound アクセスがおこなわれるため、Azure Network (Azure VNet) からの VPN か ExpressRoute を介して On-Premise につなぐことになるためだ。(Failback も計画に含めるなら、戻す際のネットワーク構成も考慮する必要がある。)

ネットワーク帯域については、ASR Capacity Planner が使用できる。(この ASR Capacity Planner は、Azure 上の ASR 設定の途中でリンクが表示され、ダウンロードを促すようになっている。)

運用手順

ASR では Failover は自動でおこなわれないので、運用・監視は自身でおこない (または、他製品を組み合わせて)、UI (Azure Portal), スクリプト, SDK などから能動的に Failover を呼び出す。(Failover を呼び出すと、Recovery 先でリカバリー イメージを元に VM が起動する。)
なお、OMS と組み合わせた場合は、既に構成のための機能が OMS に Built-in されている。

下記の 3 種類の Failover が提供されていて、いわゆる障害発生時に呼び出す「Unplanned Failover」は、他の 2 つと異なり Failover 時に最新の Delta Replication は作成しない。(その時点でとられている最新のイメージを元に Failover する。)

  • Test Failover
  • Planned Failover
  • Unplanned Failover

Failover 後の処理は、Azure Automation Runbook を使うことができる。VNet 等の Azure Resource の構成や、VM 内でのセットアップスクリプトの実行などは、Azure Automation Runbook を組み合わせて構成する。

Microsoft Azure : Add Azure Automation runbooks to recovery plans
https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-runbook-automation

 

ここでは ASR 導入の際の初歩的な疑問を中心にまとめたが、細かなトポロジーや FAQ は以下が参考になるので是非参照してほしい。

Azure Site Recovery support matrix (On-premises to Azure)
https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-support-matrix-to-azure

Azure Site Recovery FAQ
https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-faq

 

Advertisements

コマンドで理解する New Azure ML ステップ・バイ・ステップ

新しい Azure Machine Learning (Preview) は基本的にコマンドから使う。(実際、Azure Portal からは一部の機能しか使えない。)

ここでは、このコマンドを順に見くことで、新しい Azure Machine Learning がどのようなものか確認する。
ざっくりと Experimentation と Model Management という独立した 2 つの作業にわかれている。

準備

ここで紹介するコマンドを使うには、後述の Azure Machine Learning Workbench をインストールするか、下記の通り個別にパッケージをインストールする。

pip install azure-cli
pip install azure-cli-ml

CLI コマンドのヘルプを見るには -h オプションを使用する。
この投稿では、コマンドを難解にしない目的から必要最小限の引数しか指定しないが、細かな設定については下記のように確認してほしい。

# show what resource can be used
az ml -h
# show what command can be used for workspace
az ml workspace -h
# show what option can be used for workspace creation
az ml workspace create -h

また、以降を進める前に、CLI から、あらかじめ Azure にログインをしておこう。(az login を実行する。)

Experimentation Account と Workspace の作成

新しい Azure ML のアカウントには Experimentation Account と Model Management Account がある。
モデル構築時は Experimentation Account を作成し、ここに Workspace を作成して、Workspace 内で個々の Project を作成する。

下記は、CLI コマンドを使って、リソースグループ myRG01 に Experimentation Account (名前 exacc01) と Workspace (名前 testws01) を作成している。(なお、Experimentation Account と Workspace は Azure Portal からも作成できる。)

# Create experimentation account
az ml account experimentation create -n "exacc01" -g "myRG01"
# Create workspace
az ml workspace create -a "exacc01" -n "testws01" -g "myRG01"

Training フェーズ (モデルの作成)

Python のコード作成、トレーニング、モデル作成には Azure Machine Learning Workbench (Windows 版、Mac 版) や Visual Studio Code Tools for AI というデスクトップ ツール (IDE) が提供されている。
なお、これらを使うには、あらかじめ前述の Experimentation Account を作っておく必要がある。(起動時に Experimentation Account を確認する。)

aml_workbench

ここではこれらのツールの使い方は説明しないので “チュートリアル : Classify Iris” を参照してほしいが、主に下記のようなことをおこなう。

  • 上記で作成した Workspace に Project を新規作成
  • Data Set を準備・整形 (dataprep)
  • Python で Training のコードを作成 (学習済モデルの作成)
  • 実行と結果の確認

(補足 : Project は単なるローカル環境のフォルダではなく、Azure 上のリソースとして作成される。カレントフォルダーの Project が Active Project として認識され、例えば、Active Project 上で az ml account experimentation show と入力すると、その Project の Experimentation が表示される。)

新しい Azure Machine Learning はツールに依存しておらず (Open で)、その後の作業も含め Azure Machine Learning Workbench などがなくても Azure Machine Learning のサービス全体を利用できるが、実際、Azure Machine Learning を使うなら Workbench を使わないともったいない。理由は、下記の通り Azure Machine Learning Workbench 自体が高機能なためだ。
(言い換えるなら、この Azure Machine Learning Workbench 自体が、新しい Azure Machine Learning の半分を占めているといっても過言ではない。)

  • Data の準備では、元のデータを変えることなく、Data cleaning のための細かなステップをエディタでビジュアルに定義できる。(Power BI などで使われていた手法だ)
    メトリクスごとのデータ プロファイルをみながら編集できる。
  • PROSE と呼ばれる AI による Data Wrangling テクノロジにより、ちょっとしたデータ整形なら、Excel の Autofill のように賢く自動解釈する。(“Diving deep into what’s new with Azure Machine Learning” 参照)
  • トレーニングでは、config を構成し、ローカルマシン以外に、DSVM や HDInsight Spark cluster などを容易に使える。つまり、学習の際、Azure 上の GPU 等の高尚なコンピューティング環境を容易に扱える。(“Configure compute environment” 参照)
    なお、Azure のサービスを介しておこなわれるので、Workbench を使わない場合でも Experimentation Account が必要だ。

Workbench には、他にも Jupyter Notebook とのインテグレーション、ROC 曲線などによる可視化 等、多くのサポート機能を備えている。

Python のコードを作成して学習が完了したら、学習済のモデル ファイル (.pkl) を作成しておく。

Scoring フェーズ

学習済モデル ファイル (.pkl) ができたら、これを元に Scoring のコードを作成して、これを Web Service として発行する。

以下は、付属している Iris の Scoring のサンプルだ。(あやめの種類を区別する Logistic Regression のモデルを扱っている。)
この中の以下の処理に注目してほしい。

  • カレント フォルダから、前述で学習したモデル (下記の model.pkl) をロードしている。
  • 下記の通り、このあとの Web Service 化にそなえて、init() (初期化の処理), run() (Web Service 本体の処理) を定義し、これらを main から呼び出してデバッグする。
  • Azure Machine Learning が提供する generate_schema() 関数で、Input (入力引数), Output などの Web Service の仕様を json で出力している。
# Import data collection library. Only supported for docker mode.
# Functionality will be ignored when package isn't found
try:
  from azureml.datacollector import ModelDataCollector
except ImportError:
  print("Data collection is currently only supported in docker mode. May be disabled for local mode.")
  # Mocking out model data collector functionality
  class ModelDataCollector(object):
    def nop(*args, **kw): pass
    def __getattr__(self, _): return self.nop
    def __init__(self, *args, **kw): return None
  pass

import os

# Prepare the web service definition by authoring
# init() and run() functions. Test the functions
# before deploying the web service.
def init():
  global inputs_dc, prediction_dc
  from sklearn.externals import joblib

  # load the model file
  global model
  model = joblib.load('model.pkl')

  inputs_dc = ModelDataCollector("model.pkl", identifier="inputs")
  prediction_dc = ModelDataCollector("model.pkl", identifier="prediction")

def run(input_df):
  import json

  # append 40 random features just like the training script does it.
  import numpy as np
  n = 40
  random_state = np.random.RandomState(0)
  n_samples, n_features = input_df.shape
  input_df = np.c_[input_df, random_state.randn(n_samples, n)]
  inputs_dc.collect(input_df)

  pred = model.predict(input_df)
  prediction_dc.collect(pred)
  return json.dumps(str(pred[0]))

def main():
  from azureml.api.schema.dataTypes import DataTypes
  from azureml.api.schema.sampleDefinition import SampleDefinition
  from azureml.api.realtime.services import generate_schema
  import pandas

  df = pandas.DataFrame(data=[[3.0, 3.6, 1.3, 0.25]], columns=['sepal length', 'sepal width','petal length','petal width'])

  # Turn on data collection debug mode to view output in stdout
  os.environ["AML_MODEL_DC_DEBUG"] = 'true'

  # Test the output of the functions
  init()
  input1 = pandas.DataFrame([[3.0, 3.6, 1.3, 0.25]])
  print("Result: " + run(input1))

  inputs = {"input_df": SampleDefinition(DataTypes.PANDAS, df)}

  #Genereate the schema
  generate_schema(run_func=run, inputs=inputs, filepath='./outputs/service_schema.json')
  print("Schema generated")

if __name__ == "__main__":
    main()

ここまでで、学習済モデル ファイル (上記の model.pkl)、Web Service の仕様を定義した Json ファイル (上記の service_schema.json)、そしてこの Scoring 用の Python コード (score_iris.py とする) が準備できた。

Computing Environment の作成と設定

以上で必要なファイルは整ったので、Web Service 化して展開 (deploy) する。
ここからは Model Management の作業になるが、必要なファイルさえ揃っていれば、ここまで使ってきた Experimentation Account 等は必要ない。

まず、前提知識をいくつか記載する。

新しい Azure Machine Learning を使った Web Service 化では、展開の際に AKS (Azure Container Service の Kubernetes cluster) と ACR (Azure Container Registry) が使われる。このため、あらかじめ、コマンド az provider register --namespace Microsoft.ContainerRegistry によって Azure Container Registry プロバイダーを登録しておく必要がある。(既に登録済の場合は OK)

また、Web Service 化は、ここで紹介する方法以外に、単一のコマンドですべて生成することもできるが、ここでは構成などを理解できるように、あえて複数コマンドでわけて展開をおこなう。(構造が理解できてきたら、単一コマンドで省力化しても良いだろう。)

まず、展開の前に、展開環境である Computing Environment を下記の通り新規作成する。
ここでは、testenv01 という名前の Computing Environment を East US 2 に作成する。(Kubernetes クラスタの名前は「testenv01」になる。)

なお、下記の -c (--cluster) オプションで Azure Container Service (AKS) が使用されるが、オプションを指定しない場合は local の docker container に展開される。(ここでは省略するが、コマンドを使って local と AKS を切り替えることも可能。)

az ml env setup -n testenv01 -l eastus2 -c

上記のように -g (--resource-group) オプションを省略すると、このコマンドによって testenv01rg と testenv01rg-azureml-cxxxx の 2 つのリソースグループが新規作成され、後者のリソースグループに Azure Container Service の各ノード (VM) が展開される。(xxxx は数字。今回は testenv01rg-azureml-c7294 だった。)
これらのリソースグループはこのあとのコマンドで使うのでおぼえておく。

下記のコマンドで Computing Environment がすべて表示されるので、作成中の環境の provisioning state が Succeeded になるまで待つ。(特に新規に Azure Container Service を作成する場合は、最初のノード作成に時間がかかる。)

az ml env list

Succeeded になったら、下記コマンドを実行して、この作成した環境を Active Compute Environment として設定する。

az ml env set -n testenv01 -g testenv01rg

なお、作成された Compute Environment の情報は Azure 上に保存されるが、この Active Compute Environment はその作業環境上のみ (使用しているクライアント上のみ) の設定なので注意。
以下のコマンドで Active (Current) の環境を確認できる。

az ml env show

Model Management Account の作成と設定

次に、下記コマンドで Model Management Account を新規作成する。(このあと登録するモデルは、ここでバージョン等が管理される。)

az ml account modelmanagement create -l eastus2 -n testmg01 -g myRG01

つぎに、下記コマンドによって、上記で作成した Model Management Account  を使用中の作業環境 (クライアント) における Active な Model Management Account として設定する。

az ml account modelmanagement set -n testmg01 -g myRG01

Active な Model Management Account は下記コマンドで確認できる。

az ml account modelmanagement show

Web Service としての展開 (Deploy)

下記コマンドで、前述で作成した学習済モデル ファイル (model.pkl) を登録する。(何度も登録するとバージョンが 2, 3 とあがっていくので注意。)
この際、登録されたモデルの ID (model id) が出力されるので、これをコピーしておく。(以降では model id を 08ceeb5842eb4fa4a94d47533d7e3aab とする。)

az ml model register -m model.pkl -n model.pkl

つぎに、下記コマンドで、上記で準備した Web Service 用の Scoring のソース (score_iris.py) と仕様 (service_schema.json) を登録して Manifest を作成する。ここで、-i (--model-id) オプションは、上記で登録したモデルの ID である。つまり、使用するモデルは都度 変更できる。
(なお、何度も登録すると Manifest のバージョンがあがっていくので注意。)

この Manifest 作成時に manifest id が出力されるので、これをコピーしておく。(以降では manifest id を 789c3c18-b385-423f-b88c-429a2973b99b とする。)

az ml manifest create -n testmanifest1110 -f score_iris.py -r python -i 08ceeb5842eb4fa4a94d47533d7e3aab -s service_schema.json

この Manifest を使って、下記の通り Image を新規作成して登録する。Image の実体は、ACR (Azure Container Registry) に登録される。(この ACR は、上記の az ml env setup コマンドで新規作成されたリソースグループの中にある。)
作成時、イメージの Id が出力されるので、これをコピーしておく。(以降では image id を a61ba643-884d-4181-a7cb-b1b9c6c48b3e とする。)

az ml image create -n testimage1110 --manifest-id 789c3c18-b385-423f-b88c-429a2973b99b

あとは、この登録されたイメージを使って、下記の通り Web Service を展開して起動する。
今回は使用しないが、追加の Package が必要な場合には -c オプションで Conda Dependencies File (.yml) を指定できる。
なお、下記で “realtime” と指定しているが、今後、”batch” (Azure Batch 展開) も可能になるようだ。

az ml service create realtime --image-id a61ba643-884d-4181-a7cb-b1b9c6c48b3e -n testapp1110 --collect-model-data true

下記の通り出力されるので、出力された service id (testapp1110.testenv01-90e88070.eastus2) をおぼえておく。(このサービスを利用する際に使用する。)

Creating service............................Done
Service ID: testapp1110.testenv01-90e88070.eastus2
Usage for cmd: az ml service run realtime -i testapp1110.testenv01-90e88070.eastus2 -d "{\"input_df\": [{\"petal length\": 1.3, \"petal width\": 0.25, \"sepal width\": 3.6, \"sepal length\": 3.0}]}"
Usage for powershell: az ml service run realtime -i testapp1110.testenv01-90e88070.eastus2 --% -d "{\"input_df\": [{\"petal length\": 1.3, \"petal width\": 0.25, \"sepal width\": 3.6, \"sepal length\": 3.0}]}"
Additional usage information: 'az ml service usage realtime -i testapp1110.testenv01-90e88070.eastus2'

Web Service の利用

展開された Web Service (REST) の URL, Port, エンベロープなどは、下記コマンドで確認できる。

az ml service usage realtime -i testapp1110.testenv01-90e88070.eastus2
Scoring URL:
  http://13.68.115.32:80/api/v1/service/testapp1110/score

Headers:
  Content-Type: application/json
  Authorization: Bearer <key>
    (<key> can be found by running 'az ml service keys realtime -i testapp1110.testenv01-90e88070.eastus2')

Swagger URL:
  http://13.68.115.32:80/api/v1/service/testapp1110/swagger.json

Sample CLI command:
  Usage for cmd: az ml service run realtime -i testapp1110.testenv01-90e88070.eastus2 -d "{\"input_df\": [{\"petal width\": 0.25, \"sepal width\": 3.6, \"sepal length\": 3.0, \"petal length\": 1.3}]}"
  Usage for powershell: az ml service run realtime -i testapp1110.testenv01-90e88070.eastus2 --% -d "{\"input_df\": [{\"petal width\": 0.25, \"sepal width\": 3.6, \"sepal length\": 3.0, \"petal length\": 1.3}]}"

Sample CURL call:
  curl -X POST -H "Content-Type:application/json" -H "Authorization:Bearer <key>" --data "{\"input_df\": [{\"petal width\": 0.25, \"sepal width\": 3.6, \"sepal length\": 3.0, \"petal length\": 1.3}]}" http://13.68.115.32:80/api/v1/service/testapp1110/score

Get debug logs by calling:
  az ml service logs realtime -i testapp1110.testenv01-90e88070.eastus2

Get STDOUT/STDERR or Request/Response logs in App Insights:
  https://analytics.applicationinsights.io/subscriptions/b3ae1c15-4fef-4362-8c3a-5d804cdeb18d/resourcegroups/testenv01rg-azureml-c7294/components/mlcrpaib1917249512d#/discover/home?apptype=Other%20(preview)

ここで認証用に使用する key は、下記コマンドで出力できる。

az ml service keys realtime -i testapp1110.testenv01-90e88070.eastus2
PrimaryKey: 6d452f09a4xxxxxxxxxxxxxxxxxxxxxx
SecondaryKey: ec7453b683xxxxxxxxxxxxxxxxxxxxxx

このため、Fiddler などを使って下記の通り HTTP Request をおこなう。
今回は、あやめの情報 (ガクの幅など) を渡すことで、そのあやめの種類をモデルから推測して返している。

POST http://13.68.115.32:80/api/v1/service/testapp1110/score
Content-Type: application/json
Authorization: Bearer 6d452f09a4xxxxxxxxxxxxxxxxxxxxxx

{
  "input_df": [
    {
      "petal width": 0.25,
      "sepal width": 3.6,
      "sepal length": 3.0,
      "petal length": 1.3
    }
  ]
}
HTTP/1.1 200 OK
content-type: application/json

"\"Iris-setosa\""

Scaling

前述の通り Kubernetes の Cluster が使用されるため、以降は kubectl コマンドで管理できる。
しかし、よく使う Agent Node (Virtual Machine) や Replica の一部の管理タスクは Azure ML のコマンドも使えるので最後に紹介しておこう。

例えば、下記は、Azure ML のコマンドを使って Agent Node (Agent の Virtual Machine) を 3 台に変更する。

az acs scale -g testenv01rg-azureml-c7294 -n testenv01 --new-agent-count 3

下記は、Autoscale の設定を解除して、この Agent 上に動いている Replica を 3 つに設定している。(下記の通り kubectl コマンドを使わずに設定できる。)

az ml service update realtime -i testapp1110.testenv01-90e88070.eastus2 --autoscale-enabled false
az ml service update realtime -i testapp1110.testenv01-90e88070.eastus2 -z 3

 

ご覧のように、新しい Azure Machine Learning を使うと Python で構築した Score (Test) の処理をそのまま Web Service として発行できるが、同じようなことが可能な Server Platform (オンプレミスの製品) として Machine Learning Server というものが使えるのをご存じだろうか。旧 R Server と呼んでいたもので、現在は Python も使えるようになっている。
また、コマンドや構成の一部で runtime として「python」を指定している点に気づいたかと思うが、現在 Model Management のみ R がサポートされているらしく、今後、R の Experimentation やドキュメントも出てくることだろう。
Machine Learning Team Blog で書いているように、これらのプラットフォーム (クラウド版の Azure ML とオンプレ Server の ML Server) は今後 統一化されていく予定らしい。

 

参考にした情報 :

Azure Machine Learning Tutorial – Classify Iris :
https://docs.microsoft.com/en-gb/azure/machine-learning/preview/tutorial-classifying-iris-part-1

Azure Machine Learning Reference :
https://docs.microsoft.com/en-us/azure/machine-learning/preview/data-prep-python-extensibility-overview

ngrok を ASP.NET で使う (Debug と Capture)

昨今の WebHook や BOT 開発のように、インターネット上で Inbound 呼び出しされる Web アプリの Debug や HTTP Protocol (Raw) Capture をする場合に欠かせない ngrok を ASP.NET と組み合わせて使う場合に必要な設定と動作確認方法を簡単に紹介する。

ASP.NET プロジェクトの設定

ngrok を使うには、まず、ASP.NET のプロジェクトに以下の設定をおこなっておく。

まず、Visual Studio のプロジェクトのプロパティで、[すべてのユーザーにサーバー設定を適用] (Apply server settings to all users) が選択されていることを確認する。(既定では選択されているはず)

apply_settings

開いている Visual Studio ソリューションのフォルダーの .vs\config にある applicationhost.config (IIS Express が使用) を開き、下記の binding を追加しておく。

<configuration>
  . . .

  <system.applicationHost>
    . . .

    <sites>
      . . .

      <site name="WebApplication1" id="2">
        <application path="/" applicationPool="Clr4IntegratedAppPool">
          <virtualDirectory path="/" physicalPath="C:\Demo\WebApplication1\WebApplication1" />
        </application>
        <bindings>
          <binding protocol="http" bindingInformation="*:60587:localhost" />
          <binding protocol="http" bindingInformation="*:60587:*" />
        </bindings>
      </site>
      . . .

ngrok の実行と動作確認

上記の ASP.NET Web アプリケーションを localhost で Debug 実行したら、ngrok をダウンロード (および展開) して、コマンド プロンプトから下記の通り実行する。(60587 は、この ASP.NET Web アプリケーションが実行されている IIS Express でのポート番号)
特に ASP.NET では、Host ヘッダーをちゃんと指定しないと Bad Request (400) になるので、下記の通り指定する。

ngrok http 60587 --host-header="localhost:60587"

上記の実行結果として下記の通り表示されるが、これは、インターネット上の http://ae8b8019.ngrok.io のアドレスが Tunnel されて http://localhost:60587 に行くよ、という意味。

Tunnel Status                 online
Version                       2.0.25/2.1.1
Region                        United States (us)
Web Interface                 http://127.0.0.1:4040
Forwarding                    http://ae8b8019.ngrok.io -> localhost:60587
Forwarding                    https://ae8b8019.ngrok.io -> localhost:60587

Connections                   ttl     opn     rt1     rt5     p50     p90
                              0       0       0.00    0.00    0.00    0.00

そこで、あとは、ブレークポイントを置いて、http://ae8b8019.ngrok.io に接続すると、Tunnel されてきて、ちゃんとブレークポイントで止まる。

HTTP Capture

Web ブラウザを使って上記出力の http://127.0.0.1:4040 (http://localhost:4040) を表示すると、下図の通り HTTP Protocol (Raw) を Capture できる。
WebHook や BOT で、どのような request が来ているか簡単に確認可能だ。

HTTP_Capture

BOT 開発のように双方向連携をおこなうものは、この ngrok と Fiddler を一緒に使えば、inbound と outbound の双方がキャプチャーできるので、最強のデバッグ環境を手に入れることができる。

 

Azure VM (Ubuntu) の MySQL 環境構築

Azure Virtual Machine (Azure 仮想マシン) の Ubuntu (LINUX) を使って、MySQL 環境 (リモート接続環境、データベース作成まで) を構築する手順のメモ MySQL のインストール Azure Virtual Machine を構築したら、まずは、MySQL をインストール。 SSH, Putty などのターミナルから (リモートで) ログインをおこない、以下のコマンドを入力すれば OK。

sudo -s
sudo apt-get install mysql-server

下記の通り入力 (MySQL に root でログイン) して、正しくインストールされたかどうか確認。

// login to mysql
mysql -u root -p
// check status
mysql> status

MySQL の停止と起動は下記の通り入力する。

sudo service mysql stop
sudo service mysql start
(または sudo service mysql restart)

Database の作成 つぎに、MySQL にログインして Database を作成する。

// login to mysql
mysql -u root -p
// create database
mysql> create database testdb character set utf8;

作成されたデータベースを確認するには以下の通り。

mysql> show databases;

Remote 接続の設定 つぎに、MySQL Workbench、コマンドユーティリティ (mysql コマンド等) からリモートで管理できるように、リモート接続の設定をおこなう。 まず、作成した Azure Virtual Machine で [Settings] – [Endpoints] を選択し、MySQL の Port 番号 3306 の Endpoint を追加する。(この Endpoint を開けておく。) set_endpoints つぎに、MySQL 側でリモート接続ができるように、vi /etc/mysql/my.cnf  で下記の箇所を編集 (変更) する。 Host (Server) の IP Address は、ifconfig で確認できる。(inet addr と書かれている箇所) 変更前

bind-address = 127.0.0.1

変更後

bind-address = [Host の IP Address]

MySQL にログインし、今回は root で Remote Access できるように、下記の通り権限付与しておきます。 今回は、root に、すべてのホストからのすべての権限を付与しています。

grant all privileges on testdb.* to root@"%" identified by
  '[root password]' with grant option;

下記を実行すると、mysql.user テーブルに root@% が登録されているのがわかります。

select user, host from mysql.user;

+-------+-----------------+
| user  | host            |
+-------+-----------------+
| root  | %               |
| root  | 127.0.0.1       |
| root  | ::1             |
| root  | localhost       |
| ...   | ...             |
|       |                 |
+-------+-----------------+

以上で、Remote の環境から、MySQL のコマンド ユーティリティ (mysql コマンド等) や MySQL Workbench を使って接続できるようになります。 例えば、下記の通り入力して、あるデータベースから、別のデータベースに、オブジェクト (テーブル、データなど) を移行できます。

cd [mysql dir]/bin
mysqldump -u [username] -p[password] -h[hostname] [database name]
  --add-drop-table > [save file path]
mysql -u[username] -p[password] -h[hostname] --default-character-set=utf8
  [database name] < [read file path]
cd C:\Program Files\MySQL\MySQL Server 5.6\bin
mysqldump -u root -pP@ssw0rd -hmyserver01.cloudapp.net testdb01
  --add-drop-table > C:\tmp\db.sql
mysql -uroot -pP@ssw0rd -hmyserver02.cloudapp.net
  --default-character-set=utf8 testdb02 < C:\tmp\db.sql

Bing Maps の Geocode、逆 Geocode のプログラミング

Bing Maps の Geocode (住所から地図を取得)、Reverse-Geocode (地図から住所を取得) の JavaScript プログラミング (サンプル コード) をメモしておく。

例えば、下記の UI を持つ Web ページ (html) と仮定する。

Bing_sample

Geocoding のプログラミング

まず、上図のテキスト ボックスに日本の住所 (文字列) を入力して Pin アイコン (左上) を押すと、 Bing Maps の地図を更新するサンプル コードは、下記の通り。(説明は、コメントを見てほしい。) なお、あらかじめ、Bing Maps のサイトからアクセス キーを取得し、 下記の <access key> に設定しておく。

<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8" />
  <meta http-equiv="X-UA-Compatible" content="IE=Edge"/>
  <script src="http://ajax.aspnetcdn.com/ajax/jquery/jquery-1.9.0.min.js"></script>
  <script src="http://dev.virtualearth.net/mapcontrol/mapcontrol.ashx?
    v=6.3&mkt=ja-jp"></script>
  <script>
  $(document).ready(function () {
    map = new VEMap('map');
    map.LoadMap();
    map.SetCenterAndZoom(new VELatLong(35.70, 139.7), 13);

    //
    // GeoCoding sample
    //
    $('#checkloc').click(function () {
      var addrval = $('#addresstxt').val();
      var requestUri =
        'http://dev.virtualearth.net/REST/v1/Locations?'
        + 'output=json&countryRegion=JP&addressLine='
        + encodeURI(addrval) + '&key=<access key>&c=ja-jp';
      $.ajax({
        url: requestUri,
        dataType: 'jsonp',
        jsonp: 'jsonp',
        beforeSend: function (xhr) {
          $('#msgline').html('changing map ...');
        },
        success: function (data, status) {
          $('#msgline').html('got location !');
          if (data &&
            data.resourceSets &&
            data.resourceSets.length > 0 &&
            data.resourceSets[0].resources &&
            data.resourceSets[0].resources.length > 0) {

            // 返された bbox (位置情報) の内容から地図を更新
            var bbox = data.resourceSets[0].resources[0].bbox;
            map.SetMapView(new VELatLongRectangle(
              new VELatLong(bbox[0], bbox[1]),
              new VELatLong(bbox[2], bbox[3])));

            // Bing Map にプッシュピンを設定
            var lat = new VELatLong(
              data.resourceSets[0].resources[0].point.coordinates[0],
              data.resourceSets[0].resources[0].point.coordinates[1]);
            var pin = new VEShape(VEShapeType.Pushpin, lat);
            map.AddShape(pin);
          }
        },
        error: function () {
          $('#msgline').html('error.');
        }
      }); // ajax
    }); // click

    $('#msgline').html('ready !');

  }); // ready
  </script>
</head>
<body>
  <p>
    <div>
      <a href="#" id="checkloc">
      <img src="pin.png" width="50" border="0" />
      </a>
    </div>
    <div>
      <input type="text" id="addresstxt" style="width:400px" />
    </div>
  </p>
  <div id="map" style="position:relative;width:400px;height:300px;"> 
  </div>
  <p id="msgline" style="background-color:gray;">initializing ...</p>
</body>
</html>

また、都道府県名や市区町村名など、入力欄をわける場合があるが (下図)、この場合には、下記の通りプログラミングすると良い。

Bing_sample2

<script>
 $(document).ready(function () {
  ... skip code ...

  var requestUri =
    'http://dev.virtualearth.net/REST/v1/Locations?output=json&countryRegion=JP'
    + '&adminDistrict='
    + encodeURI($('#districttxt').val())
    + '&locality='
    + encodeURI($('#localitytxt').val())
    + '&addressLine='
    + encodeURI($('#linetxt').val())
    + '&key=<access key>&c=ja-jp';
  $.ajax({
    url: requestUri,
    dataType: 'jsonp',
    jsonp: 'jsonp',
    ... skip code ...

</script>

... skip code ...

<div>
  都道府県
  <input type="text" id="districttxt" /><br />
  市区町村
  <input type="text" id="localitytxt" /><br />
  番地など
  <input type="text" id="linetxt" /><br />
</div>

... skip code ...

Reverse-Geocoding のプログラミング

今度は逆に、Bing Maps の地図をマウスで右クリックすると、 その位置の住所をテキスト ボックスに設定するサンプルだ。

<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8" />
  <meta http-equiv="X-UA-Compatible" content="IE=Edge"/>
  <script src="http://ajax.aspnetcdn.com/ajax/jquery/jquery-1.9.0.min.js"></script>
  <script src="http://dev.virtualearth.net/mapcontrol/mapcontrol.ashx?
    v=6.3&mkt=ja-jp"></script>
  <script>
  $(document).ready(function () {
    map = new VEMap('map');
    map.LoadMap();
    map.SetCenterAndZoom(new VELatLong(35.70, 139.7), 13);

    //
    // Reverse-GeoCoding sample
    //
    map.AttachEvent("onclick", function (e) {
      // マウスの右クリック以外の場合は、何もしない
      if (!e.rightMouseButton)
        return;

      $('#msgline').html('getting location ...');

      // マウスの選択位置から latlong を取得
      var lat;
      if (e.latLong) {
        lat = e.latLong;
      } else {
        var pxl = new VEPixel(e.mapX, e.mapY);
        lat = map.PixelToLatLong(pxl);
      }

      // Bing Map にプッシュピンを設定
      map.Clear()
      var shape = new VEShape(VEShapeType.Pushpin, lat);
      map.AddShape(shape);

      // latlong から場所の詳細情報を取得
      map.FindLocations(lat, function (loc) {
        $('#addresstxt').val(loc[0].Name);
        $('#msgline').html('location changed !');
      });
    }); // AttachEvent

    $('#msgline').html('ready !');

  }); // ready
  </script>
</head>
<body>
  <p>
    <div>
      <a href="#" id="checkloc">
      <img src="pin.png" width="50" border="0" />
      </a>
    </div>
    <div>
      <input type="text" id="addresstxt" style="width:400px" />
    </div>
  </p>
  <div id="map" style="position:relative;width:400px;height:300px;"> 
  </div>
  <p id="msgline" style="background-color:gray;">initializing ...</p>
</body>
</html>

なお、https (SSL) のサイトから、http のサイトのサービス (jsonp など) を呼び出すことはセキュリティー上の理由から許可されていない。(ブラウザーが警告を表示する。)
Bing Maps では https (SSL) による呼び出しもサポートしているため、このような場合には、下記の通り、「s=1」のクエリー文字列を入れて https (SSL) を使用する。(これを入れておかないと、内部で使用される jsonp 呼び出しなどで http が使用されてしまうので注意。)

<script type=”text/javascript” src=”https://dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6.3&mkt=ja-jp&s=1“></script>

MongoLab で、Cloud な MongoDB 活用

最近アナウンスがあったが (ここ に日本語で紹介してくれている)、 Azure store で提供されているサービスが、Azure Portal から使えるようになった。Azure 上で Multi tenant で提供されている著名なサービス (例えば、MySQL のクラウド版の ClearDB や、SMTP メールの SendGrid など) とか、 データを提供する各種サービスが Azure ポータルから使えるわけだ。

ここで嬉しいのは、Amazon (AWS) だけでなく、Azure からも MongoLab が扱える点だ。(MongoLab は、MongoDB 版の “Database as a Service” と思ってもらえば良い。データベース サーバーの監視や起動・停止、バックアップなど、SLA を自分で実装するのではなく、契約ベースで利用する。)
Azure Virtual Machine (Azure VM) で、Linux や Windows で MongoDB を立てても良いが、 Azure ポータルから MongoLab のデータベースを立て、「MongoDB のサービス」として Azure 上の C# などからアクセスできるようになる。つまり、すべて PaaS のプラットフォームを使って簡易に利用できる。(この場合、もちろん、使用する MongoDB は Azure 上の Region で hosting される。)

残念なのが、現段階 (2012/11/03) の Azure Preview では、アカウント Profile が United States の場合しかアドオンを利用できないようで、つまり、日本で契約している場合は、まだ上図の画面を拝むことはできない。(この制約はいずれなくなるらしいが、少なくとも今は無理だ。)
2012/12/25 追記 : ようやく、日本語の Azure Preview Portal からも使えるようになった。
そこで、ClearDB なども同じだが、本家の MongoLab のサイト (https://mongolab.com/home) から Azure の MongoLab が使えるので、 今回は、その手順で、簡単に使い方を紹介したい。(MongoDB そのものに関する細かな手法については、専用のサイトを参照してほしい。)

Sign-up と Database の作成

まずは、MongoLab のサイト (https://mongolab.com/home) に行ってサインアップをおこなう。ちなみに、0.5 GB までの Shared Plan (他のデータベースと、仮想マシンを共有) なら無償で使える。

そして、データベースを作成するが、ここで、下図の通り、Provider として Azure を選択しよう。

データベース作成の際に、Database User の作成とパスワードを設定するが、このあと説明するように、パスワードは URI としても使用されるので、できるだけ @ (アットマーク) など URI の予約語は使わないほうが良い。

なお、残念ながら、現時点の MongoLab では、Windows Azure 用の Dedicated VM Plan はないらしく、 専用の VM で作って VNET (Virtual Network) で構成するなどの使い方は試せない。(まあ、Amazon 版の Dedicated VM Plan も、まだ Beta なんだけどね)

データベースが作成されたら、データベースが使用している xxxxxxxx.mongolab.com のサーバーの名前解決をしてみると良いだろう。ちゃんと、 zzzzzzz.cloudapp.net という Azure のドメインで動いていることがわかる。 また、データベースの管理画面 (下図) を見て、使用している MongoDB のバージョンもチェックしておこう。下図の通り、 右下に mongod プロセスのバージョンが表示されているが、 現在は、バージョン 2.0.7 であることがわかる。(このため、C# から Linq とかも問題なく使える。)

このあと見ていくように、MongoLab は、MongoDB のコマンドライン ユーティリティ (mongo) を使って管理できるが、 この際、できる限り、同じバージョンの MongoDB を入れておいたほうが良い。そのためにも、使っている mongod のバージョンはちゃんと把握しておこう。

Command Line からの管理

では、実際に、コンソール (mongo) から管理をおこなってみよう。 上図の画面の通り、MongoDB の接続先のアドレスが表示されているので、MongoDB をインストールして、コマンドライン ユーティリティ (mongo) でこのアドレスに接続する。(下記の dbuser と dbpassword は、データベース作成時に追加したユーザー情報だ。また、server name, database port の部分もテナントによって異なるので注意してほしい。)

mongo <server name>.mongolab.com:<database port>/<database name>
  -u <dbuser> -p <dbpassword>

いつものようにプロンプトが表示されるので、 あとは、普通の MongoDB の使い方と同じだ。 例えば、下記では、現在使用しているデータベースの名前を取得している。

> db.getName();
testdb

下記では、 Orders コレクションの Name プロパティに Index 作成をおこなっている。

> db.Orders.ensureIndex({Name:1});

コマンドラインを使う場合、1 つ注意点がある。Azure の癖を知っている人には説明の必要はないと思うが、 Azure は、一定時間 Idle 状態の接続は強制切断される。このため、 コマンドライン ユーティリティも長時間ログインしたままにせず、面倒かもしれないが、仕事が終わったら、まめに exit しよう。(Socket エラーなど、切断されていたら、再度、mongo で入りなおす。)

プログラミング言語 (Driver) からの接続

プログラミング言語からも、いつものように利用できる。(なので、特に説明の必要はないが、念のため書いておこう)
例えば、C# から接続する場合、いつものように、10gen の Official C# driver を NuGet から取得する。

あとはプログラミングをおこなうだけだ。Driver から接続する際の接続文字列も、上記の管理画面に表示されている。以下のフォーマットの接続文字列となる。

mongodb://<dbuser>:<dbpassword>@<server name>.mongolab.com:<server port>/<database name>

以下のコードを記述すると、登録や検索が問題なくできることがわかる。何度も繰り返すが、一般的な MongoDB の使い方と何ら変わらない。(下記は、ASP.NET MVC のサンプル コードだ。)

using MongoDB.Driver;
using MongoDB.Bson;
using MongoDB.Driver.Linq;

public class Order
{
  public ObjectId _id { get; set; }
  public string Name { get; set; }
  public int Price { get; set; }
  public string Category { get; set; }
}

public ActionResult Test1()
{
  MongoServer server = MongoServer.Create(@"mongodb://<dbuser>:
    <dbpassword>@<server name>.mongolab.com:<server port>
    /<database name>");
  MongoDatabase db = server["<database name>"];
  MongoCollection col = db.GetCollection("Orders");

  // save
  Order obj1 = new Order()
  {
    Name = "test1",
    Price = 100,
    Category = "material"
  };
  col.Insert(obj1);
  Order obj2 = new Order()
  {
    Name = "test2",
    Price = 200,
    Category = "material"
  };
  col.Insert(obj2);
  Order obj3 = new Order()
  {
    Name = "test3",
    Price = 150,
    Category = "food"
  };
  col.Insert(obj3);

  // find (Linq)
  Order sel = (from c in col.AsQueryable()
        where c.Name == "test2"
        select c).FirstOrDefault();

  ViewBag.Message = string.Format("_id:{0}, Price:{1}",
    sel._id, sel.Price);

  return View();
}

あとは、完成したアプリケーションを Azure に発行すれば、 同じ Region で動作する MongoLab を使ったクラウド アプリケーションの出来上がりだ。(パフォーマンスなどを考慮し、できるだけ、MongoLab のデータベースと同じ Region に発行しておこう。)

Bulk の処理などを実行してもらうとわかるが、まあそれほど違和感ない速度で返ってくる。(ただし、Shared なので、いろいろ状況に応じ変わってくるとは思うが。。。)

(追記) Dedicated 登場

Mongolab : Announcing New MongoDB Instances on Microsoft Azure」にあるように、MongoLab の Dedicate 版が提供された。

以前はスケーラブルな構成がむずかしかったが、この Dedicated 版により、待望の Replica Set、さらに「Mongolab : Plans & Features」によると Sharding Cluster も利用できるようなので、是非 お試しあれ。(まだ試していない)

AWS Elastic Beanstalk による .NET 開発 (手順)

Amazon Elastic Beanstalk や RDS for SQL Server を使った .NET 開発について書こうと思う。

基本的な流れ

まずは、どんな風に使っていくか簡単に書いておこう。 当然だが、利用するためには、事前に Amazon Elastic Benastalk にサインアップをしておく。(Security Credential にアクセスし、そこに表示されている口座番号 (Account Number)、Access Key ID、Secret Access Key をコピーしておく。)

つぎに、Visual Studio の入っている開発環境には、AWS Toolkit for Microsoft Visual Studio をインストールしておく。(なお、今回は、Visual Studio 2010 を使った。)

Visual Studio を起動すると、AWS 用に「AWS Console Project」、「AWS Web Project」などのプロジェクト テンプレートが表示されるが、Azure と違って、他のプロジェクト テンプレートを使用しても、そのまま AWS に配置できる。例えば、プロジェクト テンプレートから ASP.NET MVC Application を選択して普通にプロジェクトを新規作成し、開発 (プログラミング) をおこなって、AWS に配置することもできる。

プロジェクト作成の際は、ターゲット フレームワークに注意してほしい。現時点 (2012/05) の Amazon Elastic Beanstalk では、.NET Framework 2.0、.NET Framework 4 が使用可能なため、このいずれかのフレームワークで構築しておく。(今回は、.NET Framework 4 を使った。)

適当にコードを作成したら、「Publish to AWS」で AWS に発行できる。

この際、発行用の AWS アカウントの情報を入力する画面が表示されるので、上記でコピーした Account Number (口座番号)、Access Key ID、Secret Access Key を入力して「OK」を押す。

以降はウィザードが表示されるので、ウィザードに従って、Region、配置方法、ドメイン (URL)、Container Type (これは、現在は 2008 R2 / IIS 7.5 だけのようだ)、ターゲット フレームワーク (.NET 2.0 か .NET 4) などの基本情報を設定して先に進み、「Deploy」ボタンを押す。 配置が完了すると、設定した URL でアプリケーションに接続できるようになる。(なお、Windows Azure のように、パッケージ (zip ファイル) を作成して、あとから AWS Management Console でアップロードすることもできる。)

内部では、配布用のパッケージ (.zip) が S3 上にアップロードされ、環境への配置時に EC2 のインスタンス作成や、Elastic Load Balancer (ELB)、Auto Scaling Group などの設定がおこなわれているようだ。(このため、配置後は、これらを個別に管理することもできる。) また、配置後は、指定した URL を使った health check が走り、ローカルでちゃんと動いていても、AWS への配置で接続できない場合などは、この health check のエラーとなる。このため、このエラーが表示される場合は、実際に Fiddler などを使って接続先の URL が返すエラーの内容を確認してみると良いだろう。

Beanstalk アプリケーションの管理

配置後の管理は、主に、AWS Management Console で可能だ。(Windows Azure の管理ポータルと同じだと思えば良い。) この画面を使うと、ログの確認や、構成の変更 (例えば、インスタンスの最大数など)、インスタンスの開始、停止、Terminate など、さまざまな設定と管理をおこなうことができる。 通常の AWS の利用では、EC2、ELB など設定を個別でおこなう必要があるが、この画面で Elastic Beanstalk を管理すると、関係する EC2 インスタンスや ELB などの設定を同時におこなってくれる。(例えば、Scaling のインスタンス数の設定を増減させた場合など。) また、SSL (https) 関連などの基本的な設定も、この管理画面でおこなうことが可能だ。

また、Visual Studio の「表示」 – 「AWS Explorer」メニューを選択して表示される AWS Explorer を使うと、(Visual Studio 上で) 簡単な管理や状態の確認などがおこなえる。(RDS の管理などもできる。) ここでは、上記で設定した配置の際のアカウントの編集なども可能だ。

Amazon RDS for SQL Server

Amazon RDS でも SQL Server が使えるため、例えば、ASP.NET の Membership database を SQL Server に作成して、Beanstalk アプリケーション (ASP.NET アプリケーション) から利用することなども可能だ。さっそく使ってみよう。

まず、AWS Management Console で「RDS」を選択し、「Launch DB Instance」をクリックすると、SQL Server (Express Edition、Web Edition、Standard Edition、Enterprise Edition)、MySQL、Oracle などが表示されるので、該当の Edition の SQL Server を選択して、インスタンスを作成する。(その際に表示されるウィザードで、Allocated Size や、Matser DB の UserName / Password などを設定する。)

インスタンスが作成されて利用可能 (Available) になったら、ポータルを使ってエンドポイント (サーバー名) やポートの確認が可能だ。

サーバー名と、Master DB の UserName / Password を入力することで、sqlcmd (コマンドライン ユーティリティ) や SQL Server Management Studio (GUI のユーティリティ) で接続できる。(あとは、いつも通りの要領で、SQL Server を管理すれば良い。) 例えば、接続先のサーバー (エンドポイント) が xxxxxxxxxxxxx.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com の場合、sqlcmd でログインして、aspnetdb という名前のデータベースを作成する場合は、下記のコマンドになる。(1433 はポート番号だ。)

sqlcmd -S xxxxxxxxxxxxx.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com,1433 -U testadmin -P Password
1> create database aspnetdb
2> go

試しに、Visual Studio コマンド プロンプトから Aspnet_regsql.exe を実行して、上記で作成したデータベース (aspnetdb) にメンバーシップ データベース (テーブル、ストアド プロシージャなど) を作成し、Beanstalk のアプリケーションでこのメンバーシップ DB を使用してみたが、まったく問題なく使用できた。(ただし、Beanstalk アプリケーションの発行の際に、接続先の RDS インスタンスとして、上記を選択すること。)

ドキュメントをちゃんと読むとわかるが、実は、RDS for SQL Server でも、そこそこ「クラウドならでは」の制限はある。しかし、この程度の内容で比べてみると、SQL Azure の場合は、専用のスクリプト を使用する必要があるが (クラウド環境にあわせて、使えない機能がかなりあるため)、RDS for SQL Server の場合には、「SQL Server そのまま」といった感じで使えることがわかる。

Remote Desktop による接続

ちょっと上の用語と混同してしまうが、今度は Remote Desktop Service の “RDS” の話。

Windows Azure 同様、Remote Desktop Protocol (RDP) を使ったリモート インスタンスへの接続も可能だ。(Beanstalk というより、要は、EC2 におけるただの Remote Desktop 接続なんだけど。。。)

改めて、知らない人のために設定方法を書いておくと、まず、いくつか準備が必要だ。AWS Management Console で「EC2」を表示して、「NETWORK & SECURITY」 – 「Key Pairs」で Key Pair を作成しておく。この際、.pem ファイルのダウンロードを促されるので、このファイルをローカルに保存しておく。そして、上記の Beanstalk アプリケーションの配置の際に、下図の通り Key Pair を指定して配置をおこなっておく。

Beanstalk アプリケーションの配置後には、AWS Management Console で「EC2」を表示し、作成された EC2 インスタンスの Action で「Get Windows Admin Password」を選択する。

すると、下記の画面が表示されるので、「Privete Key」に、上記でダウンロードした .pem ファイルの内容をコピーして貼り付け、「Decrypt Password」ボタンをクリックすると、マシンの Administrator のパスワードが表示される。(同時に、接続先のマシンのアドレスなども表示される。)

あとは、Remote Desktop を使用して直接接続するか、AWS Explorer から Elastic Beanstalk のインスタンスを表示して「Connect to Instance」ボタンを押すことで、Remote Desktop を使って AWS のインスタンスにログインできる。(Scaling でインスタンスが複数ある場合は、インスタンスを選択する画面が表示される。なお、AWS Management Console の EC2 の管理画面から Remote Desktop で接続することも可能。)

上図の「Connect to Instance」を使用すると、パスワードを使用せず、前述した .pem の Private Key で接続することもできる。

AWS の Remote Desktop を使用した接続では、ローカルのドライブ (使用しているマシンのドライブ) もマウントされているため、ローカルからリモートへのファイル コピーなども容易だ。

サーバー側における、Beanstalk アプリケーションの管理 (イベント ビューアーの確認など) や、ちょっとしたファイルの設定など、簡単な管理に使うことができて便利だ。(もちろん、ちゃんと incremental deployment をした場合と異なり、配置パッケージのバージョン管理の対象からは外れてしまうが。。。)

結局のところ …

このように、AWS (Elastic Beanstalk) と Windows Azure (Cloud Service) の基本的な構築と管理の流れは似ている。どうやら、今後は、こういった PaaS スタイルの構築と公開にも、さらに慣れておいたほうが良さそうだ。

ただ、ちゃんと見てみると、上記の通り、同じ PaaS の概念ではあるが、性質 (位置づけ) が異なっているのも事実だ。.NET 開発に限って言うなら、Azure では PaaS 用にプラットフォームのベースから洗練されているのに対し、こちら (Elastic Beanstalk) は、IaaS 上の .NET の開発・配置を簡素化 (サポート) してくれるユーティリティーといったほうが正確だろう。使用されているベースは、EC2 など、IaaS のそれと変わらない。(そもそも、AWS 自体は IaaS のプラットフォームなだけに、当たり前だが。) Windows Update の適用 (セキュリティー面) や、環境そのもののバージョン アップなど、いろいろ細かなことを考えると気になるところだ。

しかし、逆に、こうした概念のため、上記のように、作成するプロジェクトもクラウド用の特別な設定は比較的 少なく、使用しているプラットフォームも PaaS 特有の設定 (例えば、Azure ではお馴染みの、PaaS 独自の自動化された部分や、ドライブごとの役割の違い、など) は比較的少ない。つまり、ポータブルで、分かりやすいという点はメリットだろう。

無論、この Beanstalk は、細かなことを考え始めると、まだまだ本格的な .NET 開発には足りない部分が多い。.NET を使うなら Azure のほうが良いにきまっているが、こうした「分かり易さ」という点は、”あり” かもしれない。(いろいろな特徴の PaaS が出てきて、選択できるのは良いかも。。。)