SQL Azure と Cosmos DB をメインにWindows Azureの情報を発信
MSDNフォーラムで、マイクロソフトのApurvaさんが投稿した「Logging Features limits FAQ」を意訳した投稿です。
Windows Azure Webサイトで動作しているPHPサイトのエラー情報の取得方法について説明します。
Windows Azure 管理ポータルで、WebサイトのCONFIGUREタブを選択し、3つのロギングオプションを有効化します。3つのロギングは、Webサーバーのログ、詳細なエラーメッセージ、失敗したリクエストのトレースです。それらを有効化するために、diagnosticセクションを探し、それぞれをONにし、SAVEボタンをクリックします。
それらのログを確認する方法の１つは、FTP経由で参照する方法です。Azure管理ポータルの右端のパネルで、FTP HOSTNAMEとDEPLOYMENT ?FTP USERを参照します。FTPクライアントを使用して、接続します。
そのほかにログを確認する方法として、MacとLinux用のWindows Azureコマンドラインツールを使用する方法があります。次のコマンドを実行すると、.zipファイルでダウンロードすることができます。
azure site log download <site name>
このコマンドは、Linux/Macのスーパーユーザーで実行する必要があります。
PHP.iniで次の設定をします。
display_errors=On
log_errors=On
error_log = "D:\home\site\wwwroot\bin\errors.log"
FTP経由でXDebugプロファイルを取得することができます。
Windows Azure WebサイトでのXDebugの有効化方法についてを参照してください。
サイトでエラーを調べ始めると、favicon.icoの404エラーが大量に記録されていることに気づきます。エラーを解消するには単純に、favicon.icoをrootディレクトリに配置することです。
Brain氏のBlog投稿「Getting Error Info for PHP Sites in Windows Azure Web Sites」をざっくりと意訳して紹介した投稿です。
Developer Camp 2012 Japan Fall
Day1 2012年10月4日（木）16:40～17:40
Microsoft Corporation
Azure Application Platform Team
Software Development Engineer in Test
河野通宗
Togetter:Inside Windows Azure Web Sites by @superriver
セッション資料
Windows Azure Web サイト (コードネーム Antares) の内部の仕組みについて詳しくお話します。Web サイトのロール構成、プロビジョニング時の動作をはじめ、高可用性とスケーラビリティを提供するメカニズムについて、開発チーム中唯一の日本人エンジニアが開発途中のエピソードも交えてお伝えします。エバンジェリストも知らない話が聞けるかも知れません。
Azure Webサイトを作っている人。
SDET（Test Developer：テストコードを毎日書いて触ってきゃっはーと楽しんでいる）人で
Twitter:superriver（帝国兵と俗に呼称されている）
Azure Webサイトのコードネーム：アンタレス（Antares）
アンタレスチームは40人（Dev/Test/PM）。
スコット・ガスリー配下のチームメンバーは2~300人。
AAPT（Azure Application Platform）チームで、Websites以外にも幾つか存在する。
部屋の看板？ 
スコット・ガスリー配下のチームロゴなんだって。 
Strat Simple
Go Live
Rapid Scale
宣伝文句で、ASP.NET、MVC、Python、PHPをサポートとなっている。
Rubyはサポートしないのかという話ですが、クラウドサービスの方では使えるなっていますが、Websitesの方でも使える。
昔、大きくチームが2つありました。
河野さんは元々ファンダメンタルよりのAzureチームにいた。もっとデプロイの手続きを簡単にしたいと考える人がファンダメンタルなチームにいっぱいいました。
具体的に改善したいと思ったことがあって、ミニプロジェクトが立ち上がった。
一方で、IIS 6やIIS 7を開発し続けていたチームがありました。
IISの基本機能として元々マルチテナントの機能を持っていたが、それなりの問題点もあった。
問題点があり、改善しようとプロジェクトが走っていました。
この2つのプロジェクトが社内のデモの場か何かで、お互いの存在を認識し、似たようなことやってるなら一緒にやろうよっとなり、プロジェクト・アンタレスが1年半ほど前に始まった。
Antares開発プロジェクトの原則どこかに明文化されているわけじゃないけど、開発の経緯をみてきて河野さんなりにまとめてみた。
次の図が全体構成。ピンクの部分はAzure自体のインフラで、この部分はAzure Websaitesチームは触れることができない。Azureインフラの上にWebsitesを構築している。
赤色の部分がAzure Websitesの部分で、大きく2つに分かれている。
1つが、Websites master API endpoint。Azureのインフラと直接通信して、サイトを作成したり、削除したりする。メインのコントローラー部分。
そして、Stamp。実際にサイトを作成した時に、サイトが格納される場所となっている。
Azure Websitesは、クラウドサービスとして実装されていて、Azureの上に作られている。
Stampの部分が世界各地のデータセンターに展開されていて、今後増やしていきたいと思っている。
アジアにも1つStampを置く予定となっている。今、設定をしたりする。
サイトを作成するときの挙動についての説明。
Webブラウザ開く際の挙動についての説明。
前の手順は複雑で時間がかかる。すでに一度WebWorkerの上にサイトが作成された場合について説明する。
この仕組みがあるだけで、エクストララージでホストされているWebWorker1つで、1000以上のサイトを軽くホスティングすることができる。DWSがこのサービスの肝になっている。
データベースがパフォーマンスのボトルネックとなるので、サイトがすでに出来上がっている場合は、データベースへのアクセスを抑えるように実装されている。Runtimeのデータベースがダウンするとシステム全体がダウンしてしまうので、システムの弱いところとなっている。
もっと厄介なのがサイトと直接通信するSite DB。こちらはコンテンツ（CMS）次第なので手出しができない。CMSによっては秒間数百のトランザクションを発行させるので、1つのWebWorkerにいくつもホストされるとスロットリングを起こしてしまい、ほかのサイトまでアクセスできなくなってしまう。
問題解決が困難なのでSQLのアクセスだけは、移し替えてある。
※行間を勝手に補足して想像してみると……。
同一のWebWorkerから、SQL Databaseに大量にアクセスすると、SQL Detabaseのスロットリングサービスの対象になってしまう。
根本解決が困難なので、SQL Databaseにアクセスするサイトは別のWebWorkerに載せ替えて、高速に動作するようにしている。高速に動作すればSQLの問い合わせ時間が短くなるのでスロットリングサービスの対象になりにくい……ってことかな？
じゃ、Dos Guardの対象にもなっちゃったりするのかな？さすがに無いか……。
Stampの内部構造は、次の要素で構成されている。
| API endpoint | Stamp内のAPIエンドポイントがStamp内のサイト作成などをつかさどっている。 |
| Frontend | IIS ARR上に実装されたロードバランサー |
| WebWorker | WebWorkerのインスタンスの上でサイトのコンテンツが読み込まれ動作している。シェアとかリザーブなどいくつかある種類は、WebWorkerの種類を指している。 |
| Runtime DB | SQL Databaseには、Runtimeの情報を保存している。 |
| Publish endpoint | WebDeployとかFTPなどの外からのリクエストを受け取るエンドポイント。FTPは、データのパスとコントロールのパスと2つセッションをはるが、Azureのロードバランサーはラウンドロビンでしか動かないので、Publish Endpointのインスタンスが複数あると分離されてしまってうまく動かないことがあるので、Publish endpointはAzure内ではあるがIPが固定されている。 |
| File Server | VHD Blobsに対してproxyの役割を果たすインスタンス。 |
上の図では、赤い四角1つしか書いてないところがあるが、全部複数のインスタンスを使用している。赤い四角を全部足して、1つのStampごとに1000インスタンスぐらい動作していて、今全部で5000インスタンスぐらい動いている。
コンテンツは、BlobのVHD上に格納されている。
File Serverは、VHDをドライブとしてマウントしている。File Serverは全部のVHDをマウントしている。File Serverには、必ずスペアの空いているスタンバイ用のFile Serverを用意している。 
File Serverに障害が発生したら、スペアのFile Severが切り離されたVHDをマウントしてダウンタイムを少なくしている。現在は切り替えに30秒ほどかかるので、短くしたいと考えている。 
現在のAzureドライブの仕様上限である1TBのVHDをたくさん保持している。1TBのVHDファイルを1つのStorageに100個までしか保存できないので、全部で100TBしかない。サブスクリプション辺りの容量が1GBなので、10万人程度しかホストできない。
なので、たくさんグループ化して使用するようにしている。これで無制限の容量を使用できるようになる。 
「East USしか選べない」
「West USしか選べない」と言う質問がある。
一番最初にサイトを作成するときは、３～４か所から選べたが、一度選んでしまうと以後は、そのリージョンにしか作成できないようになっている。
サブスクリプションが課金単位。Websitesの中に、Webspaceという概念があり、ユーザー割り当て単位となっている。1つのサブスクリプションには1つのWebspaceという制約となっており、1つのWebspaceの中に最大10個までのWebsiteを作成できる。（これは実装上の問題なので、将来的には変更する可能性が高い。）
WEBMARIXをクリックすると自動的にPublish設定ファイルをダウンロードしてきて、サイトを発行できる。
空っぽのサイトを作成。 
App_Codeというディレクトリを作成して、クラスを作成する。クラスを作成するとPublishした先で自動的にコンパイルして実行されるので便利。
リファレンスを追加。
クラスに追記。
スタートしていないので修正。
もっかい修正。
Defaultに記載。
デバッグするために、詳細エラー表示のためcustomErrosをoffに変更。
最後は、デバッグ過程であれやこれやとなったのでファイル名を変更して無事完了。
こんな感じで、プロセスを実行することもできる。
system32も見える。
他のサイトのコンテンツとかクラウドサービスは見えないようになっていたり、ローカルでWebsocketsを開いたり、セキュリティホールになりそうなものはプロテクションしている。
その範囲を除いて、いろいろできる。
notepadとか起動すると返ってこなくなってしまうので注意が必要。
独自の監視を作りこんでいる。
Azureがモニタリングのインフラを提供しているので、それを採用している。
各コンポーネントに対して、Azureインフラでモニタリングしている。
さらにAzureのロードバランサー経由で、外側からFrontendやPublisherに対してデプロイしたりアクセスしたりして正常に動作しているかを確認している。
全世界にインスタンスを置いて相互に死活監視をしてくれるゴメスというマイクロソフト外部のサービスを活用して死活監視をしている。
Failすると大量のメールが…。多いと一日1000通とかくる。
//マイクロソフトも開発者側への通知はメールなんだなぁ……。
アジャイル開発で、1つのスプリントは3週間から長くても6週間。
バックログからフィーチャ洗い出しして、優先順位つけて実装するフィーチャを決定する。
スクラムは毎日短いミーティングをして情報共有している。
進捗を細かく確認しながら進める。
最初は30人全員でやっていたが、今はフィーチャごとに細かくチームを分けてスクラムを実施している。
以下のテストをすべて自動化していて、河野さんテスターチームは、テスト用コードを書くお仕事。自動化するメリットは、一度動いてしまえば以後は自動的にテストできる。
テストフレームワークは、（TFS便利だなぁ使おうかなと思った）作るのが好きなので、基本全部自分たちで作ってしまう。当然、ほかのチームが開発したもので使用できるものは使用する。再利用しやすいテストコードを書いている。
Azure固有の機能を使用しないという原則があるので、次のようなアップグレードとなっている。
アップグレードには注力していて、完璧と言えるまでは決してアップグレードを実施しない。サービスがダウンしないように注力している。
クラウドとは？
クラウドとは何かを定義していません。
ユーザー含めて、みんなで使っていくものだと思う。
どんどん使ってフィードバックください。フィードバックに飢えています。
面白い使い方を教えてください。
教えてもらえると、チーム側のインプットになる。
クラウドは生もの。