Windows Azure で大規模サービスを設計する際のベスト プラクティス


このポストは、10 月 16 日に投稿された Best Practices for Designing Large-Scale Services on Windows Azure の翻訳です。

編集者注: 本日の記事は主任プログラミング ライターの Jason Roth が執筆したもので、カスタマー アドバイザリ チームが Windows Azure 環境で大規模サービスを設計する際のベスト プラクティスに関する新しいホワイトペーパーをまとめたものです。

先日、「Windows Azure クラウド サービスで大規模サービスを設計する際のベスト プラクティス (英語)」と題する新しいホワイト ペーパーを発表しました。これは実際のお客様のプロジェクトに基づいて設計パターンとガイドラインをまとめたもので、さまざまな Windows Azure 実装事例と、それにより実証された最適な戦略と設計パターンを集めています。

プラットフォームについて

このホワイト ペーパーは、大きく 3 つのセクションに分かれています。

  • 設計コンセプト
  • Windows Azure の解説
  • ベスト プラクティス

ベスト プラクティスのセクションは、先の 2 セクションの内容を前提に書かれていますので、こちらを先にお読みください。ベスト プラクティスのセクションには、独自性豊かな事例が記載されています。まず Windows Azure とその一般的な設計原則についての理解を深め、最適化を的確に実施するための準備をするとともに、実装の事例を適切に把握できるようにしてください。

優れた設計 - 労力に見合う効果

大規模なアプリケーションを設計する際には、慎重な検討や計画立案が必要で、実装作業も複雑になります。Windows Azure の場合、最も基本的な設計原則の 1 つとして、スケールアウトという概念があります。これは、需要が増大した際に、より高性能 (かつ高価) なハードウェアへの投資を次々と実施する代わりに、コンピューターまたはサービス インスタンスの数を増やして対応する方法です。

ベスト プラクティスには、各 Windows Azure サービスでスケールアウトを実施したさまざまな事例が紹介されています。たとえば、Windows Azure では、SQL データベースを実行中のサーバーに対してスケールアップを実施することはできません。その代替手段として、SQL データベース インスタンスを後から追加して使用できるようにアプリケーションを設計します。この場合、何らかの形でデータをパーティション分割する手法が用いられます。

そのためには、当然、パーティション分割戦略の適切な選択、および各パーティションの協調処理の的確な実施という課題があります。このホワイト ペーパーは、ユーザーの皆様が意思決定を行う際に、技術的知識と過去のお客様の事例の双方を参考としていただけるようになっています。

パーティション分割によってスケーラビリティが向上することを示す非常に明確な例として、SQL データベースが挙げられます。しかし、プラットフォームの能力を最大限に活用するには、他の役割やサービスも同様にスケールアウトする必要があります。たとえば、ストレージ アカウントにはトランザクション レートの上限があり、仮想マシンには CPU やメモリの上限があります。複数のストレージ アカウントを使用し、構成済みの仮想マシンすべてを対象にスケールアウトするような設計であれば、非常に大きなスケールが実現できます。

スケーラビリティは設計作業を行う上で重要な要素の 1 つですが、これ以外にも設計における重要な考慮事項があります。このホワイト ペーパーでは、遠隔測定と自己診断によるデータ収集が必須であることが強調されています。このことは、ソリューションのコンポーネント化およびパーティション分割の進展と共に、重要度が増してきています。他には、可用性とビジネス継続性の 2 点について注目しています。スケーラビリティが実現されても、サービス停止や回復不可能な規模でのデータ損失が発生するようでは意味がありません。

ベスト プラクティスとプラットフォームの進化

Windows Azure では常に進化や改良、新サービスの追加が続けられています。最新リリースでは Windows Azure 仮想ネットワークやサービスとしてのインフラストラクチャ (IaaS) などの新機能が追加され、大規模アプリケーション向けのオプションがさらに豊富になりました。このホワイト ペーパーは Version 1.6 に基づいて執筆されているため、プラットフォームに追加された最新機能のうち、一部については取り扱っていません。

それぞれの決定の理由を理解するには、この作業の目標をもう一度考えてみる必要があります。このホワイト ペーパーでは、設計の参考としてお使いいただくために、お客様が実際に実施した実装の成功事例をご紹介しています。これらの作業の計画、テスト、反復には数か月を要するため、一部の新しいサービスや機能については、このホワイト ペーパーの内容が更新されるまでにしばらく時間がかかります。しかし、このホワイト ペーパーに示されている設計原則はすべて現在でも適用可能です。また、Windows Azure のすべての新機能についても同様です。

今後も、新しいホワイト ペーパー、コード サンプル、および事例をご提供し、これらのベスト プラクティスの実装方法について一部をご紹介します。

チェックリストではありません

チェックリストは便利なもので、すべての項目にチェックマークをつけると、成功したような気分になれます。しかし、「Windows Azure クラウド サービスで大規模サービスを設計する際のベスト プラクティス (英語)」に記載されている情報をチェックリストとして使用しないでください。お客様の事例は、1 つ 1 つが異なる独自のものです。お客様の事例が、現時点で中規模と大規模の間くらいであるとします。この場合、プラットフォームとベスト プラクティスについての理解が得られると、お客様にとって重要であるのは、短期的には推奨事項の一部のみかも知れません。しかし、今後、これらの設計戦略のうちの一部または全部が必要になる可能性もあります。

このホワイト ペーパー (英語) をお読みになり、下のコメント欄へ皆様のご意見やご感想をお寄せください。

Comments (0)

Skip to main content