InfoQ

News

スケーラビリティを知っていると思いこんでないか?

作者 Gavin Terrill, 翻訳者 編集部 投稿日 2007年10月16日 午後8時26分

コミュニティ
Architecture
トピック
パフォーマンス&スケーラビリティ
タグ
グリッドコンピューティング,
Parallel Programming,
ロードバランシング
「スケーラビリティ」という言葉は、ソフトウェアベンダのプレスリリースにたびたび登場(したり、冷水器に関する話題にのぼったり)するが、誤解されていることが多い。たとえば、スケーラビリティの話をしているときに、パフォーマンスや高可用性を推論する人が多い。「What is scalability?(source)」(スケーラビリティとは何か)という質問への回答を試みてRoyans K Tharakan氏は次のように述べている。
スケーラビリティとは単にやっていることを大きな規模で行うことです。Webアプリケーションのスケーリングとは、そのアプリケーションをより多くの人が使えるようにすることです。スケールアウトしている間、パフォーマンスの改善方法はわからなくてもいいのです。そして、より多数のユーザーを扱えるようにスケール(調整)できるのであれば、個別の故障が複数あっても構わないのです。
Royansが特に言及しているのは、スケーリングに関して現在選択肢が2つあることだ。
  • 垂直スケーラビリティ - 同一論理ユニット内で資源を追加して処理能力を向上させること。例としては、既存のサーバにCPUを追加したり、既存のRAID/SAN記憶装置にハードドライブを追加することにより、記憶領域を拡大したりすることが挙げられます。
  • 水平スケーラビリティ - 資源の論理ユニットを複数追加して、単一ユニットとして動作させること。大部分のクラスタ化ソリューションや分散ファイルシステム、ロードバランサは、水平スケーラビリティに役立ちます。
アーキテクトはリニア・スケーラビリティの達成に努力するが、リニア・スケーラビリティとは、システムへの資源追加に比例して、一貫したスループット率を維持する能力を指す。しかし、資源を追加すればオーバーヘッドの増加も招くため、達成は困難である。Royansはこれを「スケーラビリティ要因」と呼び、スケーラビリティの種別分類を行う目安としている。
  • スケールアップを行っても、スケーラビリティ要因が一定である場合。リニア・スケーラビリティと呼びます。
  • しかし、コンポーネントによっては、他のコンポーネントほど上手くスケールしないものがあります。スケーラビリティ要因が1,0未満のものをサブ・リニア・スケーラビリティと呼びます。
  • まれなケースですが、コンポーネントを単に追加するだけでパフォーマンス(スケーラビリティ要因)が良くなる可能性もあります(ディスクスピンドルが増えると、一つのRAID内の複数ディスクスピンドル全体のI/Oが改善します)。これをスープラ(超)・リニア・スケーラビリティと呼びます。
  • アプリケーションがスケーラビリティを考えて設計されていない場合、スケールアップするに従って、実際に事態が悪化する可能性もあります。これをネガティブ・スケーラビリティと呼びます。
ソフトウェア開発では万能の規範アプローチが存在しないことが多々あるが、スケーラビリティの問題を解決する万能アプローチもない。Royansは「緊急にスケーラビリティが必要な場合は、垂直にスケールするのが一番手っ取り早い方法」と提案しているが、「垂直スケーリングは発展するに従ってどんどん費用がかさみ」、そして「無限の水平リニア・スケーラビリティ達成は難しいが、無限の垂直スケーラビリティは不可能」と警告している。Royansは続けて次のように述べている。
一方、水平スケーラビリティでは、高価なサーバを次々に増設する必要はありません。水平スケーラビリティとは、既存のストレージとサーバ・ソリューションを用いて実施されるものです。けれども、水平スケーラビリティが安上がりというわけでもありません。アプリケーションをゼロから構築して、単一アプリケーションとして複数のサーバ上で動作するようにしなければなりません。
Royansはスタック全体のスケーラビリティに取り組む上でのアドバイスを記事の最後に記し、次のように締めくくっている。
スケーラブルなWebアプリケーションが上手く動作するようにするには、全レイヤーを均等にスケールしなければなりません。その中にはストレージ・レイヤ(クラスタ化ファイルシステム、s3など)、データベース・レイヤ(パーティショニング、フェデレーション)、アプリケーション・レイヤ(memcached、スケールアウト、terracota、tomcatクラスタなど)、Webレイヤ、ロードバランサ、ファイヤーウォールなどが含まれます。たとえば、将来のWebトラフィックを処理するために必要な複数のロードバランサが導入できない場合、Webレイヤの水平スケーラビリティにどれほどの金銭と労力をつぎ込もうとも、何の効果ももたらしません。Webトラフィックは、ロードバランサで処理できる量に制限されることになるのです。
原文はこちらです:http://www.infoq.com/news/2007/10/whatisscalability
ブックマーク
digg+,
reddit+,
del.icio.us+,
dzone+,
Hatena

No comments

返信

特集コンテンツ一覧

トップスポーツチームの監督に教わる秘訣

この論文では、氏が発見した原則を要約し、その原則をいかにしてソフトウェア開発に応用するかを説明します。

事例研究:Dutch Railwaysのプロジェクトにおける分散拠点でのスクラム・プロジェクト

この記事では、私達がどのようにして大規模(240人月、10万行強)でインドとオランダの開発者も参加したスクラム・プロジェクトを成功させたのかを示しています。

Agile2008チーム参加レポート - 帰国そして変化

Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。参加者はカンファレンスで各々の発表や、各セッションへの参加、諸外国のエンジニアとの出会い、ステージ上で DearXPを熱演などの様々な思い出を抱えて、無事日本に戻ってきました。

SilverlightとJavaのインターオペラビリティ

マイクロソフトのRobert Bellが、SilverlightとJavaを使用したインターオペラビリティのシナリオを紹介し、サンプルコードを例にとってアーキテクチャの手引きを提供します。

Agile2008 チーム参加レポート - カンファレンス参加編

Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。サブミッションが選択された人、そうでない人も含めて、個々の目的意識の確認、膨大なプログラムから聞きたいセッションの選択、旅行の準備、プレゼンテーションの準備の期間を終えて、無事当日を迎えました。

Agile2008 チーム参加レポート - 動機/準備編

筆者はアジャイルソフトウェア開発についての年に一度の国際会議であるAgile2008に初めて参加してきました。今年の日本からの参加者の数は14名にも及び、発表者は5名、受け持ったセッションは8つに及び、例年にない活躍を見せました。なぜ今年のAgile2008では、これほど多くの日本人が参加し発表に至ったのか? そのレポートをお届けします。

Javaトラブルシューティングメルマガ総集編 2008/08~09

エスエムジーでは、Java全般を対象にしたトラブルシューティングサービス「JaTS」を提供しています。この記事では、前回に引き続き、JaTSにて蓄積したトラブル事例とその解決ノウハウの一部をお送りしている「Javaトラブルシューティングメールマガジン」(JTSMM)の総集編として、過去2ヶ月のトラブル事例と追加情報をダイジェストとして提供いたします。

モデル駆動アプローチがうまく機能しない(しなくなる)8 つの理由

この記事では、モデル駆動アプローチがうまく機能しない、または機能しなくなることによって期待した結果が実現できなくなる 8 つの理由について書きたいと思います。