Windows Azure 用アプリケーション開発 Step-by-Step チュートリアル ガイド第 4 章 Windows Azure 運用環境における課金目次4.1 Windows Azure 運用環境における課金を安く抑える方法
最後に本章では、Windows Azure の課金を安く抑えるためのコツについて解説します。 前提として、ここに書かれている情報は、2010 年 6 月 25 日時点での情報をまとめたものであり、また、あくまで参考情報となっております。必ず、オフィシャル サイトの最新情報をご参照ください。
4.1 Windows Azure 運用環境における課金を安く抑える方法Azure の課金の詳細については、Windows Azure のサイト (上記) に詳しくまとめられていますが、なかなかとっつきにくいのも確かだと思います。そこでここでは、課金に関するポイントを解説します。 Windows Azure プラットフォームでは、基本的に、「サービス」と「トラフィック」が課金対象になります。
サービスに対する課金に関しては、各サービスで課金方式が異なるため、注意が必要です。特に、開発中に課金が膨らみやすいのはコンピュート サービスとなっています。そのため、コンピュート サービスの利用方法には、特に注意してください。 4.1.1 トラフィックの課金トラフィック課金については、以下の点に注意する必要があります。 A. 同一拠点 (≠ 同一地区) の Azure データ センター内の通信に関しては課金対象ではない同一データ センター内に配置されたサーバー間の通信は課金対象とはなりません。例えば、コンピュート サービス (Web ロールなど) と SQL Azure が同一のデータ センター (例えばシンガポールなど) に存在する場合、その間の通信に関しては課金がかかりません。しかし、コンピュート サービスが香港、SQL Azure がシンガポールにあると、その間の通信に関してはトラフィック課金がかかります (この場合、両方のデータ センターで課金が発生します)。 B. トラフィック課金の単価は、データ センターの場所によって異なるクライアント ユーザーがどこにいるかではなく、サービスがどのデータ センターに配置されているのかによって課金が決まります。(アジアはトラフィック課金の単価が高めなため、注意してください 。※ 北アメリカやヨーロッパに配置すると通信料はやや安くなりますが、開発中はそれほどトラフィックが多くならないため、必ずしもメリットは大きくないでしょう。) C. 運用時はトラフィック課金が比較的膨らみやすい単価だけ見ると少額ですが、実際のWebサイトではそれなりの金額になります。例えば、約 500 KB の Web ページが 5,000 回/日のペースで呼び出されたとしても、500 KB × 5,000 回 × 30 日 = 75 GB の転送量になり、決して無視できないデータ転送量になるため、注意が必要です。 D. 開発中のトラフィックはそれほど大きくならないが、巨大なデータ転送には注意する開発時はユーザー数が少ないでしょうから、通常は数 GB もあれば十分であり、数百円程度で済むでしょう。ただし、初期データのアップロードなど、巨大データの転送には注意してください。 ページのトップへ 4.1.2 Windows Azure コンピュート サービスの課金コンピュート サービスの課金は、「物理マシン リソースの占有量」と「トラフィック量」に応じて決まります。 A. マシン占有課金 = 単価 × サイズ × デプロイ時間 × インスタンス数マシン占有に対する課金は、「CPU の利用時間」ではなく、「サーバー リソースの占有量と時間」により課金が決まるところがポイントです。コンピュート サービスでは、アプリケーションをアップロードした時点から "Delete" されるまでの時間が課金の対象となります。なぜなら、"Suspend" や "Stopped" などの状態のように、サービスが停止していた状態であっても、リソースを占有しているためです。実際の利用時には、"Suspend" 状態でサーバーを放置せず、使用後は必ず "Delete" し、空の状態にするようにしてください。
B. "Production" 環境と "Staging" 環境の課金単価は同一Staging 環境といっても、ここにアップロードしたアプリケーションは、しっかりと Windows Azure インフラの CPU やメモリ リソースを占有しています。このため、"Staging" 環境に置いたアプリケーションについても、課金が行われます。 通常、Staging 環境は、Production 環境のアプリケーションをアップグレードする前の、最終動作確認環境として利用されますが、利用が済んだら、これも必ず "Delete" するようにしてください。 C. 課金時間は、「デプロイ～削除」までを 1 時間単位で繰り上げ計算つまり、数分しか配置していなかったとしても、1 時間分の課金が行われる、ということになります。よって、以下のような操作は避けてください。
以上のことをきちんと押さえておくと、Production 環境のアプリケーションをアップグレードする正しい方法が分かってきます。具体的にまとめると、以下のような手順になります。 正しいアップグレード手順
うっかり放置すると、Small インスタンス 1 つであっても、1 か月あたり 8,000 円程度の課金になってしまいます。決して安い金額ではないので、十分注意しながら利用してください。 ページのトップへ 4.1.3 Windows Azure ストレージ サービスの課金ストレージ サービスに関しては、トラフィック課金に特に注意してください。ストレージ サービスでは、「ストレージ利用量」、「トランザクション数」、および「トラフィック量」の 3 つにより課金が決まります。2010 年 6 月 25 日時点での単価は、以下のようになっています。
これらの数字から考えると、ストレージ サービスの課金の大半は、トラフィック課金になるはずです。特に、マルチメディア ファイルなどの、巨大な BLOB データを、ストレージに置いて配信するような場合には、十分な注意が必要です。
ページのトップへ
4.1.4 SQL Azure データベース サービスの課金データベース サービスの課金については、以下に注意してください。 A. サービスの課金は、データベースの数とエディションと実際のデータ量により決定例えば下図の例の場合には、Business Edition のデータベースが 1 つ、Web Edition のデータベースが 1 つで、それぞれに対して課金が発生します。データベース サービスの場合、容量制限があるためにデータベースの数を増やしたくなるわけですが、むやみに増やせば、それ相応に課金額も増えていく、ということに注意してください。
なお、2010 年 6 月末に、データベース サービスの最大容量が拡大され、実容量を加味した課金方式に変更されました。例えば、Web Edition のデータベースに対して、ある日、3 GB のデータが入っていた場合には、¥4,895.10 の日割りが課金され、次の日、データが 0.8 GB に減った場合には、¥979.02 の日割りが課金されるようになっています。詳細は Web ページの情報をご確認ください。
B. オンプレミス SQL Server などとの連携を行う場合は、トラフィック課金に注意特に、データベースのデータの一括転送などは、どうしても容量がかさみがちになります。トラフィック課金がかなりの額になることも想定されるため、十分に注意してください。 ページのトップへ 4.1.5 課金状況の確認なお、上記のいずれに関しても、課金状況は MOCP サイト (Microsoft Online Services Customer Portal サイト)から確認できますが、課金情報はリアルタイムではなく遅れがあるため、注意してください。
また、本セクションで解説した課金ロジックは実際の課金ロジックを単純化したものです。実際の課金ロジックはかなり複雑になっておりますので、より詳細を知りたい方は、以下の情報を参照してください。
ページのトップへ 4.1.6 課金の予測さて、ここまで課金の仕組みなどについて、ざっと解説してきました。ここで、実際にご自身のアプリケーションの場合にどの程度の課金となるのか気になると思います。しかし、これに関しては、case-by-case としか言いようがありません。Web アプリケーションの中身は千差万別であり、必要なサーバー台数も、データ転送量も、本当にまちまちというのが実態です。 もし実際に Azure プラットフォームを使う前に、課金がどの程度になるかを知りたいようであれば、既存の類似アプリケーションについて、以下のようなポイントを考えてみたり、調べてみたりするとよいでしょう。
サーバー台数の見積もりなどは、原理的に机上での評価が難しい領域になります。そういう観点からも、プロトタイピングなどを通して実機検証を行い、見積もり精度を高めていくことを推奨します。 |
.jpg "図 1")
.jpg "図 2")
.jpg "図 3")
.jpg "図 4")
.jpg "図 5")
ページのトップへ