CSF のアプリケーション要求ルーティング処理

このポストは、10 月 31 日に投稿された Application Request Routing in CSF の翻訳です。 編集メモ: 今回は、Windows Azure 顧客アドバイス チームの Christain Maritnez が執筆した記事をご紹介します。 アプリケーション要求ルーティング処理 (ARR、英語) は、Windows Azure Web サイトや Outlook.com などの大容量で中核的なアプリケーションに利用されています。マイクロソフト全体で使用されているテクノロジの中でも非常に重要であるにもかかわらず、最も話題になりにくいテクノロジであると言えます。それは無理もないことですが、ARR を Windows Azure アプリケーションで直接使用するという話は、さらに話題に上りません。マイクロソフトでは、Cloud Service Fundamentals (CSF) が示すパターンの 1 つに、複数のクラウド サービスに作業を分割し、ユーザーに基づいてクラウド サービスへのアフィニティを透過的に作成するというものがあるため、このテクノロジを CSF で使用しました。この手法は、クラウド サービスをスケール単位として使用しローカル データを大量に保持している (データがそれを使用するコードと近い場所にある) 大企業のお客様においてパフォーマンス上で有利だったという、過去の経験に基づいています。ARR がこの要件を満たすうえで適しているのは、自然なことと言えます。 複数のクラウド サービスと聞くと、最初は戸惑い、複数のクラウド サービスを使用する代わりに Windows Azure トラフィック マネージャー (WATM) を使用すればよいのではないかと思うかも知れません。実際、パフォーマンスや業務継続性を考慮して複数のクラウド サービスで処理を分割するためにルーティングを行うときは、ほとんどの場合、WATM…


内部サーバーで負荷分散を実現する方法

このポストは、10 月 31 日に投稿された How to Load-Balance Internal Servers の翻訳です。 編集メモ: 今回は、Windows Azure 顧客アドバイス チームのプログラム マネージャーを務める Chris Clayton の投稿をご紹介します。 私は 2009 年から Windows Azure の仕事に携わっており、この間、大企業や中小企業の多数のお客様に向けたソリューション構築の支援も手掛けてきました。そうした中、ソリューションが進化するにつれて内部サーバーの負荷分散を行う必要に迫られることが度々ありました。この記事を執筆している今の時点では、Windows Azure には負荷分散に対応する組み込み型ソリューションはありませんが、パブリック エンドポイント用アクセス制御リスト (ACL、英語) を導入することで、標準でサポートされている Windows Azure のサービスやコンポーネントでこの問題に対応できるようになります。 ここでは仮想マシン上で実行中の、ASP.NET Web API で外部に面している内部サービスのファサードとして機能している 1 組の Internet Information Services (IIS) サーバーの負荷分散を実行する場合について説明します。負荷分散を行うパブリック エンドポイントを作成してそれぞれの IIS サーバーで共有すると、すべてのパブリック エンドポイントにアクセスする Windows Azure の標準ロード バランサーを使用して、サーバー間ですべてのクエリの負荷分散を実行できます。 インターネットに接続しているだれもが私のサービスにアクセスできるようになってしまうのではないかと心配していましたが、ACL をエンドポイントに適用すると、私のクラウド サービスへのアクセスを制限できるようになります。下の図のように、ACL…


クラウド サービスの基礎 – キャッシュの基本事項

このポストは、10 月 4 日に投稿された Cloud Service Fundamentals Caching Basics の翻訳です。 「Cloud Service Fundamentals (英語)」アプリケーション (別名「CSFundamentals」) は、データベースをバックエンドとする Azure サービスの構築方法を説明するためのものです。前回の「DAL – RDBMS のシャーディング」という記事では、データベース層を水平方向に拡張する「シャーディング」という技術について取り上げました。今回は、キャッシュの必要性や考慮すべき事項、Windows Azure での構成方法と実装方法について解説します。 分散キャッシュ アーキテクチャは拡張部分に構成されます。そこではもともと備わっているパーティショニング機能と共に、複数の (物理または仮想) マシンがクラスター リングの一部として協働しており、ワークロードを分散させています。キャッシュは <キー, 値> の検索パラダイムであり、値はシリアル化されたオブジェクトであるため、データベース内の複数のテーブルにまたがる JOIN などのような、非常に複雑なデータ保存処理の結果セットとなる可能性があります。そのため、データ ストアに対して処理を複数回行う代わりに、キャッシュに対してすばやいキー検索を実行します。 キャッシュの対象を理解する まず始めに、ワークロードを分析し、適切なキャッシュ対象の候補を決定する必要があります。あらゆる時点のデータがキャッシュされますが、キャッシュと「真の情報源」との間に許容される「古さ」は、アプリケーションに受け入れられる範囲内である必要があります。一般的に、キャッシュは、ユーザー プロファイルやユーザー セッション (単一ユーザーの読み取りと書き込み) などの参照用 (すべてのユーザーの読み取り専用データ) に使用したり、リソース データ (ロック API を使用するすべてのユーザーによる読み取り/書き込み) に使用することができます。ただし、場合によっては、特定のデータセットがキャッシュ対象として適切でないことがあります。たとえば、特定のデータセットが急速に変化したり、アプリケーションが許容する古さの限度を超えていたり、トランザクションの実行が必要であったりする場合です。 容量を計画する 次に、アプリケーションに必要なキャッシュの容量を推測します。このとき、キャッシュ サイズだけでなく、一連の指標を調べて、開始時のサイズの目安を決定します。 キャッシュ サイズ:必要なメモリ容量の概算には、オブジェクトのサイズとオブジェクトの数の平均値を使用できます。 アクセス パターンとスループットの要件:読み取りと書き込みが混在している場合、新しいオブジェクトの作成、既存のオブジェクトのリライト、またはオブジェクトの読み取りが起きていることを示しています。 ポリシー設定:Time-To-Live…


DAL – RDBMS のシャーディング

このポストは、9 月 6 日に投稿された DAL – Sharding of RDBMS の翻訳です。 編集メモ: 今回は、クラウドおよびエンタープライズ グループで AzureCAT プログラムのシニア マネージャーを務める Shaun Tinline-Jones と Chris Clayton による記事をご紹介します。 「Cloud Service Fundamentals (英語)」アプリケーション (別名「CSFundamentals」) は、データベースをバックエンドとする Azure サービスの構築方法を説明するためのものです。内容としては、シナリオ、実装アーキテクチャ、そしてログ記録に再利用可能なコンポーネント、構成やデータ アクセスの説明が含まれています。このコード ベースは、運用環境への展開を前提に、Windows Azure で高可用性かつスケーラブルなサービスを配信するためのベスト プラクティスを実際に体験していただけるよう、Windows Azure カスタマー アドバイザリー チームが作成しました。 現在では、たいへん多くの企業の皆様がクラウドの活用を推し進めていることから、ソリューションに求められるニーズは、コストの削減、俊敏性の向上、スケールの拡大など、非常に多様化しています。たとえば、「クラウド スケール」の達成を目標とするソリューションでは、その戦略が、ハードウェアのアップグレードによって容量を増加させる「垂直スケール」から、特定のタスクを共有するコンピューターの数を増加させる「水平スケール」へと変化しています。このトレードオフのよい例が、Web ファームの作成です。Web ファームでは、ある負荷の処理を 1 台のマシンが単独で行うのではなく、同一の Web サイトのコンテンツを多数のサーバーで処理します。 コンピューティング ノードに水平スケーラビリティを導入する計画を開始しても、リレーショナル データベース管理システム (RDBMS) やキャッシュなどの、特に複雑で、深刻な緊急事態を引き起こす可能性のある階層については、着手しない場合がほとんどです。これらのサービスでは、入出力処理が激しく実行され、また単一のインスタンスに統括されていることが多々あります。水平スケーラビリティをこのような状態の階層に実装する手法の 1 つに、「シャーディング」があります。シャーディングとは、RDBMS のデータを複数のデータベースに論理的に分割する方法です。このとき、通常は同一のスキーマが使用されます。たとえば、この手法を使用すると、従業員テーブルを別々の…


クラウド サービスの基礎: テレメトリ – レポート作成

このポストは、8 月 30 日に投稿された Cloud Service Fundamentals: Telemetry – Reporting の翻訳です。 Windows Azure のクラウド サービスの基礎 (CSF) (英語) のテレメトリ コンポーネントの設計と実装に関する 4 つ目のブログ記事へようこそ! 「テレメトリの基礎とトラブルシューティング (英語)」では、導入済みの Windows Azure ソリューションの情報を得るために使用できる基礎的なツール、情報源、スクリプトの概要など、アプリケーションの健全性に関する基本原則を説明しました。2 つ目の記事の「テレメトリ – アプリケーションのインストルメント (英語)」では、アプリケーションが監視という面でどのように最大の情報源となりうるか、そしてアプリケーションの本稼働後に管理容易性という目標を達成するために、アプリケーションを最初に正しくインストルメントすることの重要性について述べました。3 つ目の記事では、お使いのソリューションにおけるさまざまなコンポーネントやサービスから監視と診断の情報を収集するための、データ取得パイプラインの自動化とスケーリングの方法について説明し、この情報をクエリ可能な操作ストアにまとめました。 4 つ目のこの記事では、レポート作成について取り上げます。基本的には、組織でのさまざまな分析やレポート作成の要件に合わせて必要となるシステム情報を取得する方法について述べます。マイクロソフトが提供しているソリューションの概要についてはこの記事で提供し、実装の詳細な手順については、関連する Wiki ページ (英語) で説明します。具体的には、ここでは、データベース層のリソース使用率、エンド ツー エンドの実行時間分析などの項目をすばやく抽出する方法と、それらをレポートやダッシュボードに表示させる方法を説明します。一方 Wiki では、操作ストアの基礎となる実装について、分析クエリの使用例を示しながら見ていきます。また、提供するレポート パッケージについても触れ、Excel を利用してさらに深いレベルの分析を行う方法を説明します。さらに、提供されたヘルパー関数を拡張し、要件に合わせて詳細情報を取得する方法についてもお見せします。 CSF におけるテレメトリ データベース このシリーズの前回の記事では、下のデータ フロー図に示したコレクター タスクの CSF 実装である、データ パイプラインについて説明しました。これらのコレクター タスクは CSF テレメトリの…


Windows Azure の Linux 仮想マシンにおけるスワップ領域 – パート 2

このポストは、8 月 9 日に投稿された SWAP space in Linux VM’s on Windows Azure – Part 2 の翻訳です。 この記事は Azure CAT チームの Piyush Ranjan (MSFT) が担当しました。 前の記事「既成の Linux イメージを実行する Windows Azure 仮想マシンのスワップ領域 – パート 1」で説明したように、Azure IaaS でギャラリー イメージからプロビジョニングされる Linux 仮想マシンには、既定ではスワップ領域が構成されません。そこで前の記事では、リソース ディスク (/mnt/resource) にファイル ベースのスワップ領域を構成するための簡単な手順を紹介しました。ただ注意してほしいのは、その手順は、既にプロビジョニングされ、実行中の仮想マシンに対するものだという点です。それよりも、仮想マシンのプロビジョニングと同時に、スワップ領域が自動的に構成されれば理想的であり、後の段階で大量のコマンドを手動で実行する労力が省けます。 仮想マシンのプロビジョニング段階で自動的にスワップ領域を構成するうえで決め手となるのは、Windows Azure Linux エージェント (waagent) の使用です。大部分のユーザーは、Linux 仮想マシンの内部でエージェントが動作していることを漠然とは知っていても、よくわからないため放置している場合がほとんどです。実は、waagent に関する優れたドキュメントが Azure ポータルに用意されています。Windows Azure Linux エージェント…


既成の Linux イメージを実行する Windows Azure 仮想マシンのスワップ領域 – パート 1

このポストは、7 月 29 日に投稿された SWAP space in Windows Azure Virtual Machines running pre-built Linux Images – Part 1 の翻訳です。 この記事は、Azure CAT チームの Piyush Ranjan (MSFT) が執筆したものです。 近年、Windows Azure のインフラストラクチャ サービス (仮想マシンおよび仮想ネットワーク) の一般的な普及に伴い、クラウドの経済性、規模、速さという利点を得るために、より多くの企業のワークロードがパブリック クラウドに移行してきています。私は最近そのような企業のワークロード、つまりクラウド内のビッグ データ関連のプロジェクトにかかわっていました。ここではこれらに関連するいくつかのヒントとベスト プラクティスを皆さんにお伝えしたいと思います。 このプロジェクトでは、既成の Linux イメージを使用して、Windows Azure に複数ノードの Hadoop クラスターをデプロイする必要がありました。私は Windows Azure イメージ ギャラリーから入手した CentOS 6.3 イメージを使用して中規模な仮想マシン (VM) を準備し、単一ノードのコア Hadoop をデプロイしました。デプロイ自体は成功しましたが、テスト開始時にやや重いワークロードがかかっており、VM が頻繁にフリーズしたり応答を返さないという現象がみられました。 CPU…


クラウド サービスの基礎 – フォールト トレラントなデータ アクセス層のご紹介

このポストは、7 月 25 日に投稿された Cloud Service Fundamentals – Introduction into Fault-Tolerant Data Access Layer の翻訳です。 編集メモ: 今回は AzureCAT チームの Valery Mizonov (英語) の投稿をご紹介します。 先日のブログ記事「テレメトリ – アプリケーションのインストルメント (英語)」では、Windows Azure SQL データベース サービスに一時的障害が発生しても運用を持続できるよう、「Windows Azure でのクラウド サービスの基礎」コード プロジェクトにおいてフォールト トレラントなデータ アクセス層の課題に取り組んだことをお伝えし、あわせて、アプリケーションのインストルメントに関するベスト プラクティスや、ソリューションの信頼性と回復性を高めるヒントをご紹介しました。 この記事では、回復性にすぐれたデータ アクセス層を構築するとは実際にどういうことか、またそのデータ アクセス層を構築するという重要な要件に対して、「クラウド サービスの基礎」プロジェクトでどのようにアプローチしたかについて、詳しく掘り下げていきます。 クラウドベースの分散アプリケーションや分散サービスの構築は、困難を極める作業です。最新のクラウド インフラストラクチャには、リソース調整、通信障害、プラットフォーム サービスの動作不安定など、設計上のものや異常に起因するものを含め、さまざまな落とし穴があるためです。このクラスの問題は通常、アプリケーション固有のサービス レベル契約 (SLA) について常に把握すると共に、潜在的な一時的障害を検出し、失敗した処理を再試行するという方法で解決されます。 処理を再試行するかどうか的確な判断を下すためには、既知の一時的障害およびその識別子 (エラー コードまたは例外のタイプ) のナレッジ ベースを構築する必要があります。これは、非常に煩雑で時間のかかる作業です。しかし、Windows Azure 開発者は、この作業を一切行わずに、より重要な作業に専念できます。一時的障害に対処するためのナレッジやインテリジェンスは、Enterprise…