連載:.NET中心会議議事録

第2回 現場開発者視点で答える「Windows Azure業務アプリ開発の実際」

デジタルアドバンテージ 一色 政彦
2010/03/26

Windows Azureに関する性能

一色 オンプレミスからクラウドへ移行すると、アプリは従来のオンプレミスと同じ性能を発揮できるのかどうかという点も心配なところです。クラウド・コンピューティングでは、サーバが雲の向こう側に存在し、オンプレミスよりもクライアントとサーバ間の距離が遠くなるので通信速度も低下するでしょうし、インフラストラクチャ・レベルでCPUを増強したり、メモリを増やしたりしてスケールアップすることはできないので、マシン自体のパフォーマンスが不足するケースもあるのではないかという不安があります。また、クラウドの特徴の1つとしてスケーラビリティが挙げられますが、本当にスケーラビリティが高いのかも気になります。さらにオンプレミスと比べて、開発スピードも余計な手間が増えて遅くなってしまうのではないかという危惧(きぐ)もあります。

 こういった不安や疑問がアンケートでも多く寄せられています。実際にWindows Azureの性能が問題になることはないのでしょうか。

経験者が語るWindows Azureの性能

新野 これも実際の開発を経験して、市川さんや橋本さんがどう感じているかをお聞かせください。

市川 先日のTech Days 2010のわたしの担当セッション「Windows Azure Platform徹底検証」でも述べました。検証結果では、小規模から中規模であれば、同時接続数が何百アクセス来たとしても、表示完了までの平均応答時間は約3秒と、問題ないレスポンスが得られています。スケーラビリティに関しても、インスタンス数を1、2、4、8と増加させて、その結果を検証しました。当たり前ですが、ちゃんとスケールされるのを確認できました。検証結果全体を見ても、とても良好なパフォーマンスを発揮していると思います。

 しかし、もちろん通常のサイトではほとんどあり得ないことだと思いますが、同時実行数が何千アクセスにもなると、応答時間は厳しい結果が出ることが予想されます。その目安は、わたしのセッション資料に掲載されています。

 性能にはさまざまな要因が絡んできます。例えば、Webサーバへの負荷や、SQL Serverデータベース、ネットワーク、ディスクI/Oなどがボトルネックになったりします。単純にWebサーバへの負荷が増しているだけであれば、インスタンス数を増やせば性能を改善できます。しかしストレージ・サービスへの負荷が増している場合は、なかなか解消できません。実際、テーブル・ストレージへの登録処理は遅く、アプリ全体のパフォーマンスを低下させる原因になります。このテーブル・ストレージへのアクセスに気を付ければ、性能としては問題ない数値が得られています。

 ただし、Windows Azureはマルチテナントなので、隣のアプリが高負荷な場合、自分のアプリにも影響が出てきてしまいます。CPU空間は区切られているので影響を受けないと思いますが、NIC(=ネットワーク・インターフェイス・カード)は共有していると考えられるので、隣が大量のパケットを流していると、その影響を受けてパフォーマンスが低下してしまう可能性はあります。こういった内部事情はブラックボックスなので、実運用しないと見えてきません。当然、チューニングの余地もないと思います。「クラウドはブラックボックスである」ということは、初めから認識しておく必要があります。

 ちなみにAmazon EC2では、ソフトウェア・レベルのWAN高速化装置で各拠点をつないで転送スピードを速めるようなベータ・テストも始まっているそうです。Windows AzureでもVMロールが提供開始されれば、そういったサービスを開発・提供する会社が登場するかもしれません。

Publickey
新野 淳一

新野 ビジネス・アプリでは、非機能要件として良好な応答速度が求められることがあります。その場合、Windows Azureではどうすればよいのでしょうか?

市川 これに対しては、Windows Azureがベスト・エフォートであることを、エンド・ユーザー企業に最初に理解・同意してもらう必要があります。そもそもインターネット自体がベスト・エフォートで動作する仕組みです。その部分も含めて、きちんとエンド・ユーザー企業に説明する必要があります。

新野 なるほど。次に橋本さんお願いします。

橋本 Windows Azureロール・インスタンスのサイズが、Small、Medium、Large、X-Largeと4種類あり、パフォーマンスを選択できる状態にありますが、わたし自身はこれをあまり信頼していません。というのも、日によってパフォーマンスが異なるからです。わたしが性能面で実施していることは、Windows Azureを最小構成で組んでみて、それがエンド・ユーザー企業の期待するパフォーマンス要求を満たすかどうかを検証することだけです。皆さんがWindows Azureのパフォーマンスを検証する場合には、一番使われそうな典型的な機能を用いて、その応答時間が何秒かを調べる必要があります。

 わたしが執筆した記事では、300人分ぐらいのデータを検索して一覧に取得し、ボタンを押すと1件1件の詳細を閲覧できるSilverlightの業務アプリを紹介しました。このアプリを米国のWindows Azureデータセンターに配置していた場合、300件のデータが返ってくるまでに5秒ぐらいかかっていましたが、東南アジアのシンガポールのデータセンターに移したところ、3秒ぐらいに改善できました。ただし、市川さんがおっしゃったようにベスト・エフォートなので、パフォーマンスについてはエンド・ユーザー企業とよく話し合い、合意を取っておく必要があると思います。

SQL Azureとストレージ・サービスの性能

新野 Windows Azureでは、Key-Value型ストレージとRDBの2種類のデータベースが提供されていますが、これらの性能はどうなのでしょうか?

橋本 わたしが実際に活用したのはSQL Azureで、ストレージ・サービスは実運用では利用していません。

 一般的にいわれるのは、「ストレージ・サービスの読み取りは高速だが、登録処理に関しては遅い」ということです。ですので、まだまだパフォーマンス改善の余地があると思います。

 SQL Azureのパフォーマンスは、十分に業務で使えるレベルに達しています。わたしが開発した例は会費計算の事務アプリだったので、事務を担当する利用者が10人ほどと最初から決まっており、同時アクセスについてそれほど気にする必要がありませんでした。しかしこれが、例えば千人が同時に使用するアプリとなるとどうなるかは、今後検証して確かめる必要があると思っています。

砂金 Windows Azureの良さは既存の資産を移行しやすいことだと語られることが多いです。だからといって、現在実行しているアプリをそのままクラウドに乗せれば、スケールしてパフォーマンスが高まるわけではありません。スケールさせるには、スケールできるようにサービスを設計し直して作り替えなければなりません。

 パフォーマンス改善はマイクロソフトでも努力しています。まずアジア地域に2カ所(シンガポールと香港)データセンターを構築しました。これにより、米国と比べて、だいたい半分ぐらいのレイテンシ(=遅延)で収まるようになっています。ただし日によって、そのレイテンシ状況は変化します。

 また、まだ正式サービスではありませんが、CDN(=コンテンツ配信ネットワーク)も提供しています。CDNとは、ブロブ・ストレージにあるデータを、世界中の各地域にあるキャッシュ・サーバを介して使えるようにする技術です。トレースルート(tracertコマンド)を調べると、非常に近い場所から高速にデータが送信されることを確認できます。これをうまく活用して、例えば大容量のデータはブロブ・ストレージに配置してCDN経由でアクセスすると、応答速度が飛躍的に改善するはずです。CDNの正式サービス開始は公式に発表されていません。現在はCTPとして無償で使えるようになっていますので、ぜひ試してみてください。

 さらに、クラウド環境とオンプレミス環境をセキュアなVPNで接続するサービスを、“Project Sydney”というコード名で進めています。できるだけ早い段階で、この詳細も情報共有させていただきたいと考えています。

 マイクロソフトは現状に満足しているわけではなく、現在、改善の途中です。できるだけ皆さんのご期待に応えるべく、頑張っています。でも、それを待って行動するよりは、いまからできる範囲で工夫しながらご活用いただけるとうれしいです。そこで培った知見は、今後も生かせると思いますので。

Q&A

新野 では、ここからQ&Aに移ります。会場からご質問があれば、お願いします。

会場 クラウド開発では、Key-Value型ストレージの理解不足がネックになっています。今後、これに関する事例や情報共有が行われる予定でしょうか?

砂金 「Key-Value型ストレージは扱いにくい」といううわさが先行してしまっていると思います。実際にはそんなに厄介で難しい技術ではありません。例えばC#やJavaでデータをオブジェクトとして記述しているのに、それをわざわざRDBに格納する方がよっぽど大変な作業です。Key-Value型ストレージのコードは、それに比べるとすごくシンプルです。

 今回の質問では、Key-Value型ストレージを使うにしても高速化するためのTIPSなどがないかというのがポイントだと思いますが、アーキテクチャ・パターンやサンプル・コードを提供し始めています。例えばMSDNでは、Code Recipeという日本独自のコンテンツでWindows Azure関連のコンテンツを増やしていきますし、Key-Value型ストレージを活用するためのアーキテクチャ・パターン(例:Windows Azure Guidance(英語))に関する情報も今後提供していきたいと考えています。また、Windows Azureストレージ(テーブル、ブロブ、キュー)の使い方を詳しく解説した日本語のホワイト・ペーパーをすでに提供しています。今後、ストレージ開発のTIPS的な情報も増やしていきたいと考えています。

市川 コミュニティを運営する立場で話すと、いうなれば「いま、Windows Azure開発者コミュニティの大同団結が必要だ」と考えています。マイクロソフトにだけ頼っていると、日本のWindows Azure開発は遅々として進まない部分があります。であれば、われわれ現場にいる人間が、ボランティア・ベースになってしまいますが、継続して現場で役立つ情報を発信していく必要があると思っています。前に述べたとおり、クラウドはブラックボックスです。検証結果の情報などは、マイクロソフトから直接発表できないものもあるでしょう。こういった情報をコミュニティから積極的に発信していきたいです。これからは、コミュニティの横の壁を越えてでも団結して、クラウドに関する情報を広く提供していこうと考えています。

会場 Windows Azureではメール送受信やPDF出力は可能なのでしょうか?

砂金 結論からいうと、どちらも可能です。ただし、Windows Azure上にメールを送るためのライブラリが存在するわけではありません。従って、SMTPをWorkerロールで実装して、25番ポートを開けて外部と通信する必要があります。

 しかしながら、例えば誰かによってスパム配信サーバがWindows Azure上に構築されたとき、環境によっては、そのIPアドレス帯に含まれるアプリからのメールがスパムと判定されてしまい、必要なメールが正確に届かなくなる可能性があります。まだそういった報告は、現実にはありませんが、そういう可能性があることに留意しておく必要があります。必ずメールが送信できることを保証したい場合には、Exchange Onlineのような外部サービスを利用するといったアーキテクチャ構成にしてください。

 PDF出力に関しては、既存の資産やコンポーネントは基本的に動きますが、グラフィックスやデバイス・ドライバを使うライブラリは動作しません。

橋本 わたしの開発事例でも帳票出力機能はやはり必須でした。そこでサードパーティ製コンポーネントを利用してみたのですが、まず課題となったのがライセンス形式です。一番使いたかったコンポーネントはサーバ・ライセンスというライセンス形態を取っており、インスタンスを簡単に増減させるクラウドには対応していませんでした。そのため、仕方なく開発者ライセンスで提供されているサードパーティ製コンポーネントを利用することにしました。

 また、ほとんどのサードパーティ製コンポーネントがWindows Azure上ではPDF出力できませんでした。というのも、PDFコンポーネントは基本的にPDFデータを生成するために一時ファイルを作成します。Windows Azureでは基本的に任意のフォルダに書き込みできないので、その書き込みのロジックでエラーが発生します。これは解決不可能な問題でした。最終的な妥協案としては、PDF形式ではなくRTF形式というWordドキュメントの形式でファイル生成して、それをエンド・ユーザーにダウンロードしてもらい、ユーザー環境で印刷してもらうようにしました。

 現時点では各コンポーネント・ベンダはWindows Azureについては様子見の状況ですので、現時点では開発者側で何らかの工夫をする必要があるのが現実です。

新野 いまなら、Windows Azure対応のPDFライブラリを開発すれば、それでビジネスができるかもしれませんね。

会場 (笑)

新野 時間になりましたので、パネル・ディスカッションは終了します。ありがとうございました。

 Windows Azureはまだ始まったばかりである。だからこそいまからチャレンジして、道を切り開いていきたい。今回のパネル・ディスカッションを受けて、そう思った人も少なくないかもしれない。Windows Azure Communityの市川さんからは、「コミュニティの壁を乗り越えて、大同団結でWindows Azureに取り組みましょう」という熱いメッセージもいただいている。Windows Azureに何か感じるものがあれば、コミュニティに参加したり、技術ブログ記事を書いたり、何かアクションを起こしてみてはいかがだろうか。End of Article


 INDEX
  [連載] .NET中心会議議事録
  第2回 現場開発者視点で答える「Windows Azure業務アプリ開発の実際」
    1.各社のクラウド・プラットフォームの比較
    2.なぜWindows Azureを使うのか?
    3.Windows Azureのセキュリティ・障害補償とサポート
    4.ライセンス形態や課金
  5.Windows Azureに関する性能

インデックス・ページヘ  「.NET中心会議議事録」


Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)
- PR -

注目のテーマ

業務アプリInsider 記事ランキング

本日 月間
ソリューションFLASH