「まあともかく実験して調べたのでまとめる」
「前提はなんだい?」
「SQLサーバを使用するAzureのComputeServiceがある。これをWebサイトとして配置するにはどうすれば良いかだ。データベースは新規に作らずに共有する」
「それは可能なのかい?」
「割と簡単に可能だった。ただし、1つだけ罠があって、データベースの共有が上手く行かなかったので、そこで時間を食った」
「じゃあまとめてくれ」
「これは、あくまで調査の時点での状況であることを予め断っておくぞ」
「時間が経過すると状況が変化するかもしれないわけだね」
「そうだ。それがクラウドだ」
- 普通にComputeServiceのWebRoleを1つを含むソリューションを作成しておく
- ComputeServiceのプロジェクトを発行するとComputeServiceへの発行になる
- WebRole1(名前を変更していればその名前)のプロジェクトを直接発行すると、普通のWebSiteの発行になる。Azure WebSiteの発行も選択可能
- ただし、WebRole1であっても【発行】ではなく【Microsoft Azureに発行】を選ぶとComputeServiceになる模様
- 既存のSQL Serverに接続するためには、ComputeServiceは特に意識する必要は無い。ただ単にファイアウォールでポートを開いて適切な接続文字列をWeb.Configに設定するだけ
- Azure WebSiteに発行する際、データベースに関していろいろ質問されるが、それらに答えると必ず新規のSQLサーバが作成されてしまい、既存のサーバに接続できない。必ず既存サーバへの接続情報をWeb.configに書いた上で、発行ダイアログでは【データベース不使用】を選ぶ。接続文字列の上書き設定もチェックを外しておく。つまり手動で全ての接続を予めWeb.configに設定しておき、システムにデータベースの設定はいじらせない
- ComputeServiceのWebRoleのプロセスはWebSiteとして動作させると動かないので、そこに意味のあるコードは入れない。その他WebSite側のプロセスは走るが、WebRole側のプロセスは走らないので注意。当然、WebSite側のプロセスはリサイクルされてすぐ消えてしまうので、WebSiteで動作させる場合、普通に書く限り常駐される処理は記述できない
- WebSiteであっても、インスタンス数を増やしてスケールアウトできるので、プロセスのローカルなメモリやストレージにデータをキャッシュしない
感想 §
「結局どういうことだい?」
「ComputeServiceとWebSiteは同じAzureという名前のサービスの下にあるから、一見似たように見えるかも知れないが実際の中身は別物。いろいろな方法論が別物」
「どこが違うの?」
「非常に多くの部分が違う。デフォルトのドメイン名も違うし、利用できる技術のバリエーションも違う。その上、デフォルトのデータベースが違う」
「どう違うわけ?」
「ComputeServiceだとSQLはオプション。標準でNoSQLのStorageが付いていくる。ところがWebSiteに配置するとデフォルトでSQLサーバを作成してくれる」
「君の感想はどうなんだい?」
「マイグレーションのパスとして、SQLが使用できることは悪いことではないと思う。おいらは使いたくないけどね。(以下発言削除)」
「ふう。危ない危ない。そこまで過激なことを言ったら夜道で刺されるぞ」
「刺しに来ればいい。その方が話が簡単だ」
「ともかく話を戻せ」
「そうだな。こちらが考える【クラウド】あるいは【Azure】の使いこなしとは9割がAzure Storageの使いこなしそのものなのだ。もしも、そのためのノウハウが要らないなら、Azure屋の自分が仕事をする理由の9割は無いと思って良いだろう」
「なぜそこまでStorageにこだわるわけ?」
「いちばん基本的なサービスに標準で付いてくるストレージがそれだからだ。そしてクラウドはスケールアウトする関係上変化する情報は全て全インスタンスから共有されるストレージに入れて共有する必要がある。事実上、【クラウド=スケールアウト=ストレージの使いこなし】なんだよ」
「SQL使うとどうなるの?」
「昔からあるただの三層システムと大差が無くなる」
「君が持っているAzure対応のノウハウに意味が無いってことだね」
「そうだな。しかし、自分はAzure屋さんであるまえにC#屋さんだ。C#で書くことが前提ならば、ある程度はそこまで目配りせねばなるまい」
