スケーラビリティとパフォーマンスチューニングの経験が持つ価値を、過小評価するのは簡単です。どちらも"あとで"、もしくは"私たちが本当に人気が出たら"取り組むべき問題です。初期のベンチャーはすぐに(それらに対して)お金を費やす事は決して望みませんし、より大きな企業でも、必要とされる変化に素早く対応して実装できる事はほとんどありません。複数の専門的なチームを必要とするため、すぐに政治的、技術的なバトルを伴う、解決するのが難しい問題へとなってしまいます。
しかし、それは私たちの頭から離れる事は決してありません - 以前開催された数回のQConカンファレンスでも、"あなたがいつも憂慮しているアーキテクチャについて"と言うセッションは圧倒的な人気を誇りました - そして間違いなく - 私たちは'偉大なやつら'がそれを行う方法について、TIPSやトリックを学びたいと熱烈に願っているのです。
InfoQ.com向けのこのバーチャルパネルでは、大企業やプロジェクトからスケーラビリティやパフォーマンスの著名人を招待し、みんなが夢に描いているような結果を達成するための秘密を明かしてもらいました。
参加者の中には、かつてTwitter株式会社でアーキテクトを務め、Starlingメッセージキューの主要開発者であるBlaine Cookが含まれています。Blaineは"いかにしてRubyとRailsをスケールさせるか"と言う対話の中で活発な意見を述べており、そうした方面ではっきりとした経験を持っています。
彼は、eBayマーケットプレース・アーキテクチャグループにおける著名なアーキテクト、Randy Shoupと協力してきました。2004年から、eBayの検索基盤における主幹アーキテクトを務めています。そしてMatt Youillは、Betfairにおける最高技術責任者です。6年以上にわたり、彼はBetfairのテクノロジーにおけるアーキテクチャのほとんどを導いてきました。より最近では、Betfairの先進技術グループとともに、より長期的な視野を持つ先進的なプロジェクトに移っています - 戦略、研究、そしてFlywheelテクノロジーを含む特別なプロジェクトです。
参加者をかき集めるため、私たちは Railsのパフォーマンスツールのスペシャリスト、FiveRunsにも加わるよう頼みました。こうしたエンジニアリングチーム全てが、ある午後一堂に会し、彼らの持つ答えを論じました - そのほとんどが、パネルの中で我々にもたらされたのです!with panel within a panelを簡略化して訳してあります -Shumpei 8/31/08 9:11 PM
Q1: 多くの人々が、パフォーマンスとテクノロジーを同じ問題だとひとくくりにしています。この誤解に対してどう応えますか?
Randy: どんな特定の言語やフレームワークにも依存せずに、スケーラビリティの問題を論じる事には多くの価値がある、と言う意見に私は賛成です -- そうしたパターンは同様に、実装の戦略とも無関係です。とはいえまずは、パフォーマンスとスケーラビリティを私たちは区別していると言う事を確かめておきましょう。パフォーマンスは、単一のリクエストを捌くのに使われるリソースの事です。スケーラビリティとは、より多くのリクエストを捌く必要が生じたときにリソース消費量をどのように増やしていくか、についてのものです。
それらは関連していますが、同じ物ではありません :-)。幸運にも、一方を改善するための多くのアプローチが、もう一方をも改善する事がしばしばです。しかし極端な場合、非常に高速なシステムがあまりスケーラブルではないと言う事もあり得ますし、その逆も然りです。
FiveRuns: FiveRuns: 我々が関心を持っているのは、パフォーマンス対スケーラビリティ対可用性(と言う関係)です。私たちはパフォーマンスを、(複数の)操作をいかに素早く完了させる事が出来るか、と言う物だと定義しています。例えばレスポンスタイムや、1秒間にいくつのイベントを処理できるか、と言った事です。しかしスケーラビリティは - より多くの要望を処理するために、アプリケーションがどれくらいうまくスケールアップするかと言う事です(例: ユーザの数、リクエストの割合、データのボリュームなど)
Q2: パフォーマンスのボトルネック解消に取りかかるとき、その原因追及はどうやってはじめますか?
Matt: 全ての問題は違う物ですが、ほとんどの場合、観察結果を集めて(例:多くの人と話す)問題の領域を狭めて行くと言うパターンじゃないかと私は思います - 何が起こっているのかがわかれば、何が起こっていないのかを切り分ける事が出来るでしょう。
心に留めておく事が2つあります。ボトルネックこそが問題である、と言う事です。例えば、非効率的なプロセッサ利用を気にかけたところで、IOに束縛されたアプリケーションではあまり問題にはなりません。そして、本番環境での監視を行う事が重要です。ステージングでも開発環境でも、それ以外でもありません。人為的な環境で、問題を再発生させて情報を得ようとしても、人為的な見識を作り出すだけです。
Blaine: 直感(素早いですが、信頼性が低く、誤りがち)、そしてモニタリング(あらかじめ作業を必要としますが、問題に対する様々な解決策を与えてくれる)です。人々はテスト駆動開発については話しますが、スケーラビリティに必要とされるのはメトリック(測定)駆動開発なのです。
JMeter やTsungのようなツールは負荷のシミュレートを可能にしますが、全てを鵜呑みにする事はできません。もしあなたが長い時間をかけて(どれほどの長さかは、あなたのやり方やテストを作る人によって変わります)非常に注意深くテストを構築したならば、より良いデータを得る事は出来ます。しかし、全てが本当のトラフィックに近いと言う訳でもありません。
Randy: 問題に気付いた箇所から初めて、そこからさかのぼって作業すると言うのが典型的です。アプリケーションスタックの全レベルにおいてより多くモニタリング/遠隔計測をすれば、これを行うのがより簡単になります。またそうすることによって、問題を調べている様々な専門分野のチームの助けにもなります。
Q3: Webアプリケーションの問題に取り組むとき、最も便利だったツールは何ですか?
FiveRuns: ブラウザレベルでは、firebugが最適なツールです。単一ページのパフォーマンスをユーザがどのように感じるか、についてのいくらかの見識を得る事ができます。私たちはまた、自動的な負荷テストを行うために、abとhttperfを好んで使います。そして私たちは、セッションレベルとページレベルの経過時間をfirebugから得る事が出来ます。
Matt: 私たちは、出来合いのツールとカスタムのツールを組み合わせて使っています。出来合いのツールは素晴らしいですが、出来合いであると言う事はそれらが汎用的であると言う事を意味しています。それらは、私たちのアプリケーションに取って重要な、特有のメトリックに関する知識を持ちません。例えば BetfairにおけるWebアプリケーションのコンテキストにおいては、特定のページに対するリクエストの割合とタイプが、関連するビジネスイベント - フットボールゲームでゴールが入った、もしくはもうすぐ点が入りそうだ - と相互に関連がある、などになるでしょう。汎用的なツールには、"フットボールゲーム"と言うオプションはありません。
Blaine: Gangliaは素晴らしいです。NagiosやZabbix(例えば)は、物事がおかしくなったときに教えてくれますが、ちょっとしたツールを使えば、あなたはgangliaから全てを得る事が出来ます。MySQLでは、Innotopによる「遅いクエリのログ」が非常に役立ちます。1ミリ秒以上、1秒未満の全てのクエリが行っている事を見たければ、mysqlのマイクロ秒ログパッチを使ってください。
Randy: ロギングについては同意せざるを得ません - 私たちが自由に使える中で、最も便利なツールは私たちのモニタリングフレームワークです。私たちのアプリケーションサーバは、全ての基本的なオペレーション - あらゆるURLの実行、入れ子のデータベースアクセス、入れ子のサービス呼び出しなど - に対する呼び出し/トランザクションにかかった時間をログ出力するのに、そのフレームワークを使います。これにより本番環境におけるほとんどの問題をリモートから診断する事ができるので、デバッガでアタッチする必要は全くありません。私たちはまた、こうしたログの検索可能な履歴を保持しており、様々な方法で振り返る事ができます。以前と現在のパフォーマンスを比較したり、長期間にわたる傾向を比較したりできるのです。
Q4: そして、診断を必要とするスタック全体(もしくはコア部分)の問題を抱えたとき、どんなツールが役に立ちますか?
Randy: インフラのC++部分には、GDBとDTraceが明らかに役立ちます。コアダンプやpstackは価値のあるツールです。eBayにおけるインフラの大部分を占めるJavaには、トレーシングや様々なJavaデバッガを使用します。デバッガはあなたの最初のツールであるべきではありませんが、最終的なツールには違いありません。本番用のコードはリモートから問題を診断するために、十分な量のインストゥルメンテーションが必要です。
Matt: 私たちは数多くのマジックを持っています!私達は問題を再現し、それらをデバッグする(スタックの問題を含みます)ために、様々なツールを使用します - Visual Studio, Eclipse, WinDbg, cdb, Purify, Fortify, dtrace, そして私たちのアーキテクチャ用に作られたカスタムのツールです。
Q5: Yahoo!パフォーマンストップ10などの記事は役に立つとお考えですか?スケーラビリティはドメイン、もしくはアプリの問題ではありませんか?
Blaine: はい、その両方です。いくつかの点では、スケーラビリティの問題はドメインの問題からシフトしてきます。例えばもしあなたがmemcacheや同様のもの(分散ハッシュテーブルとメモリベースのキャッシュ)を使用していないのなら、それは依然として"ドメイン"の領域に置ける問題です。いくつかのアプリは、良く理解されています。静的なコンテンツをスケールすることは、現在では基本的に些細な事であり、あなたの企業が持つお金、そして良い社会組織を必要とするだけです。
FiveRuns: 私たちは、Yahoo!パフォーマンスの記事のようなリソースは役立つと考えています。私たちは、アプリケーションのアーキテクチャを問題領域にマッチさせる事が重要だと考えています - 実際、ソフトウェアシステムの品質に制約を課すのが問題領域である、と私たち全員が考えています。
言い換えると、私たち全員が問題領域に対して期待するのは、パフォーマンスやスケール、可用性などの期待値を定義することです。もちろん、これら(そしてそれ以外も)の品質の間にはトレードオフが存在します。例えば機能の多さと市場に出るまでの時間などであり、問題領域を修正するのに効果があります。
Matt: もちろん、こうした記事に書いてある事は全て役に立ちます。とはいえ、高い品質の(実行可能な)システムを作るのは、比較的達成可能な目標です - 品質をいかにして維持するか、についての良いアドバイスを見た事はありません - それは、ガバナンスの一部です。ITシステムは最初は輝かしく始まり、錆び付き、ボロボロになり、一から作り直すよう運命づけられているように見えます。現在以降きれいにペンキを保っておくことですら、非常に難しいのです。
Q6: スケーラビリティとパフォーマンスチューニングは、しばしば消火活動のように見えます; 今すぐフィックスしなくてはならない問題です。成熟したコードベースにおける、パフォーマンス上の退行をどうやって追跡するのですか?
Randy: eBayでは、プロジェクトは厳しい負荷テストとパフォーマンステストフェーズを経る事になります。それにより、サイトに上がる前にパフォーマンス上の問題の可能性を突き止めて解決しています。
Matt: 私たちは異なるプロセスを経ています - こうした問題は、アプリケーションが実稼働している間にのみ、本当に突き止める事の出来る物だと私は考えています。アプリケーションが効果的に分割されるよう努力し、本番環境において一つのサーバにデプロイします。問題なさそうに見えたらそれを他のサーバにもデプロイし、さらに他のサーバへ・・・となります。このように広めて行く過程で、パフォーマンス上の問題を早期に捉える事が出来るよう、有効なモニタリング/測定インフラに対する確実な投資を行ってください。
デプロイする前にパフォーマンス上の問題を捉えようとしないでください。実稼働中の条件を再現する事はできませんし、結果として、信頼に足るような現実的な測定結果を得る事は出来ません。
Blaine: イエス、モニタリングです。注意深くモニタリングしてください。モニタリングについて私は触れていましたっけ?遅さを見てください。退行しているように見えたら、あなたのチェンジログを見返してみてください。簡単に問題を特定できるはずです、なぜなら、あなたはインクリメンタルなデプロイを頻繁に行っているからです・・よね?
FiveRuns: 私たちが付け加えるなら、既知の良いパフォーマンスを、基準として正しく定着させる事が重要だと言う事です。そして、エンドユーザからの機能要求の欠陥に織り込まれた、あらゆるパフォーマンス上の問題を良く調べてください - ときどき、機能的な欠陥にしか見えないものも、実際にはパフォーマンスの問題をも含んでいます。
Q7: 捉えるのが本当に重要な指標はなんですか?
Randy: あなたのビジネスに影響を与えるような指標(例:ページの重さ、ユーザのレスポンスタイム)と、あなたを制限するような指標(例:メモリ、CPU、ネットワークの帯域など)です。ご想像の通り、eBayのインフラのいくつかの部分はCPUに制約を受け、その他の物はメモリの制約を受け、そしてその他は I/Oに束縛されています。もちろんマーフィの法則が保証するように、あなたがあまりしっかり重視していなかった指標が、あなたに噛み付くのです!
Blaine: あなたのアプリによります。全ての物が遅延を引き起こします。最も時間がかかっていそうだ、とあなたが考える部分を見つけ、それらの時間を計測し、計測したものとトータルの遅延時間が明らかに異なっているなら、それらを見つけてください。ページのロード時間は、250ミリ秒を下回るかどうかという単純な問題です。そのポイントを超えると、ユーザは(一般的には)違いを指摘できなくなります。そして、あらゆる最適化はパフォーマンス(例:API)とコストの最適化です。
クラスタがどう見えているかを知ってください; もしあなたが容量をオーバーしていたら、より容量を確保してください。以上で話は終わりです。より多くのマシンを買ってください。この記事を読むのを辞め、より多くのマシンを買いに行ってください。もしそれが単に容量だけの問題なら、あなたのアプリは全体的に見て低品質ではありません(パフォーマンスに関しては優秀です、mysqlをチューニングしたりすれば)、マシンを買いに行ってください。あなたはアプリを速くする事ができ、後にお金を節約する事ができます。しかも、とりあえずマシンを買う事であなたは多くのストレスから解放され、ただしくスケールするために一息つく、と言う時間が与えられるのです。
Matt: あなたのビジネスに対する問題だと言う事を確かめ、あなたの得た計測結果が何を意味しているかを確かめてください。CPUの計測結果は、そのときどんなビジネス機能が実行されているのかを知らなければ、意味がありません。
FiveRuns: 全体的に言って、究極の指標は「顧客がレスポンスに何を期待しているか、を捉えることだ」と言う事に、私たち全員が同意しています。レスポンスにより、システム全体におけるその他の要素全てを意味付ける事ができます。例えば、gmailは他のEメールサービスよりもメールを素早く受け取れます。なぜならこの'レスポンス'(例えば、メールが送られ、それをgmailで見られるまでの時間など)がユーザが望む物にマッチしたものであり、他の技術的な指標は無関係だからです。
Q8: パフォーマンスは、アプリケーションの一般的な"健康状態"をどのように表していますか?
Matt: パフォーマンスは重要な部分ではありますが、部分でしかありません。ちょっと古いですが、ISO 9126はシステムの計測基準についてはじめるのに良い場所です。
" 健康状態"は興味深いコンセプトです。医学においては、人体に置ける個々の細胞のパフォーマンスが測られる事はありませんが、脈拍や体温、血圧、呼吸と言った"生命兆候"のあつまりとして計測されます。大きなシステムも、同様にして測られるべきです - 一つのサーバのメモリ消費量よりも、システム全体を通じて何人のユーザがオンラインかを語る事のほうが役に立ちます。それぞれの大きなシステムが必要としているのは、鍵となるいくつかの生命兆候です。
Randy: パフォーマンスは、絶対の基本原理です。貧弱なパフォーマンスは、ユーザエクスペリエンスの品質にも反映するのと同様、インフラのコストにも直接反映してきます。最終的な収益にも直接響きます。期待を下回るパフォーマンスのアプリケーションは"未完成"であり、まさしく必要とされる機能を欠いたアプリケーションと同様です。
FiveRuns: 一般的には、貧弱なパフォーマンスは常に大きなバグである、そして一つ大きなバグがあるところには他の大きなバグもあるのでは、と心配になるのには全員同意しているようです。そして、健康と言うのはユーザ/所有者の体験に依存した何かであると考えています。
しかし、そこには逆の例もあります。例えばWebアプリケーションでは、少ない観衆に対していくつかの奇抜な機能を提供する事が意図されます。スケーラビリティの問題はアプリケーションの'健康状態'であるとは考えられません。それとは別に、gmailのような協力なアプリケーションは常にパフォーマンス(やスケーラビリティや可用性)の問題を抱えているので、(スケーラビリティが問題になったら)アプリケーションの'健康'が損なわれているとされるでしょう。
Blaine: アプリは単に、複雑な物事が生じていることから遅くなるときがあります。そしてそれはスピードアップする事はできません。それは、相互作用や負荷の許容量の問題になります。あなたのコードが悪くてアプリが遅く、さらに負荷が高まると全て遅くなると言うことがあります(特にロックを引き起こすコードと関係があります, 例えばSQLロックやNFSロック、あらゆる種類の分散ロックなど)。
Q9: リアルなパフォーマンスと感覚的なパフォーマンスの間には、コンセプトの違いが存在します。どちらをフィックスするのが重要でしょうか?
FiveRuns: 感覚的なパフォーマンスとは、エンドユーザの感覚ですから、それをフィックスする事が最も重要です。しかし、私たちは感覚的なパフォーマンスは測るのが難しいと考えています - 例えばそれはコンテキストに依存しますし、感覚を得る人と同じコンテキストに接する事は常にできる訳ではありません。それに、彼らのコンテキストを作り上げるすべてのものを私たちがコントロールする事もできないでしょう。
Blaine: 速いふりをしてください。感覚的なパフォーマンスの勝ちです。作業を解放するために、バックエンドのキューイングを使用してください。ユーザが望む物を見せ、あなたのアプリの他の面に対して、どうやってフィルタをかけるかを考えてください。単一の高価なリクエストを行うより、JavaScriptのポーリングを使って安価なリクエストを何度も行ってください。高価な物事はリクエストの最初に並列で行い、リクエストが完了する前にそれらの結果を収集してください。
Matt: 私は反対です - リアルがより重要です。何かに見せかける事よりも、実際に高いパフォーマンスを実現しましょう。
Randy: 私はどちらも大事にします:-) あなたが「リアルなパフォーマンス」と呼ぶ物がコストに影響するのに対し、感覚的なパフォーマンスは、ユーザエクスペリエンスに影響します。これは究極的には、その時点でどちらが大きな痛みを生じている点か、に関するビジネス上の決定です。そして、相対的な優先順位がそれに依存します。
Q10: ほとんど毎週、だれかが新しいWebサーバやアプリサーバ、データベース/ORMレイヤをリリースしています。これら全てに対して何か思うところはありますか?これはよいことなのでしょうか - それともチューニングの作業を難しくするのでしょうか?
Blaine: 私はapacheを使っています。欠点はありますが、きちんと動作します。私はMySQLを使っています。欠点はありますが、きちんと動作します。現れるなりあなたの問題を全て解決してくれるようなアプリケーションはありません; いくつかのアプリは、物事を理解し、かつ/もしくはフィックスするのを簡単にしてくれます。いくつかのアプリは生まれつきよく出来ていますが、いくつかのアプリはデバッグすること、かつ/もしくはフィックスするのがより難しくしてくれます。
データベースについては、分散型ハッシュテーブルではインデックスを持てません。あなたが分散インデックスを必要とするなら、あなたはまだそれを知らないだけです。BigTableと、それに関連するオープンソースプロジェクトは、分散インデックスではありません。MapReduceは分散インデックスではありません。あなたの分散インデックスがどのような物かを見いだし、それを作ってください。
Matt: 良い事です。とても良い事かも知れません。各カテゴリに置いて提案されているほとんどのものは、おおよそ似通っています。絶え間ないイノベーションを見るのは良い事です。しかし、カテゴリごとの提案はより少なく、全く異なるカテゴリーがより多く、より多様性を持つようになるともっと良いのではないでしょうか。
FiveRuns: そうしたプロダクトを作っている側としては、私たちはこの質問に強い関心があります!私たちは、それは良い事だと考えています - イノベーションを喚起し、考えるに値する新しいアイデアを生み出してくれます。しかし私たちは、ツールのベストな組み合わせを使う事に全力を注いできました - 新しい事は、必ずしもベターである事を意味しません。
Randy: 選択肢があるのは良い事です。選択したもので何をするかはあなた次第です。その時々の流行りを追いかける事は、役に立たない何かに固執する事と比べて、特に生産的だと言う訳ではありません。私が言いたいのは、eBayのような24x7の業務においては、十分試験されたテクノロジーを活用するのに、私たちは極めて気をつける必要があると言う事です。それは、私たちのコミュニティに対する私たちの責任です。いつでも私たちは何か新しい物を作る事を考えていますが、それをサイトに載せようと考える前に、私たちは非常に広範囲な評価作業を行うのです。
Q11: この分野で、よく間違って伝えられている事は何でしょうか?
Matt: そうですね、私がちょっと残念に思う事を一つ上げると、良いアイデアも宣伝されるか、より一般的になってしまうと、アイデアの質が劣化してしまう事です。例えばデータの保存です - 速くて、大量のデータを保存できるソフトウェアを作り上げるのは非常に難しいです。あきらかにそれは商業向けです(例えば、多数の潜在顧客がいます)。もしどちらもうまくできるのなら、それは素晴らしい事ですが、それは結局妥協され、特に速くも巨大でもなくなってしまいます - ベンダの虚偽表示をよそに!
これが一般的であるとか、常にこのようであるというわけではなないですが。
Blaine: ソフトウェアを使うだけでスケールさせる事ができると言う事です。"言語はスケールしない。フレームワークはスケールしない。アーキテクチャがスケールするのだ。"
スケーラビリティは社会的な問題です。ビジネス、戦略、そして技術的な人間の協力が中心となりますそれが成功しないのであれば、スケールさせようとする努力は失敗に終わります。もしあなたの会社が、成功裏に成長するために協力することの必要性を理解していないのなら、あなたは失敗するでしょう。 YouTubeは、この社会的な部分がうまく言っていたからこそスケールしました。彼らはサーバを買いました、彼らは資金計画を持っていました、彼らは帯域を持っていました。彼らは一つの物事を選び、それをうまくやり、組織としてスケールさせる事を決断ました。天才エンジニアの努力によって魔法のように起こった物ではありませんでした。
あなたは失敗するでしょう。素早く学習する事で、失敗を免れるでしょう。それで良いのです。箱から出したとたんにスケールするようなサービスを作らないでください。なぜなら恐らくあなたはインタラクションデザインが悪いと言う事を学び、立ち戻ってそれをもう一度行う必要が生じるでしょうから。そうこうしているうちに、正しくスケールするよう作れていなかった誰かが、インタラクションデザインを正しく得て、6ヶ月から1年あなたより先んじる事になります。
FiveRuns: パフォーマンスの向上/スケーラビリティの向上が'簡単'だということです - パフォーマンスやスケーラビリティの問題を解決するのは、常に外から見る程簡単な訳ではありません - 批判するのは簡単です。そしてその場において与えられた*全ての*制約を実際に解決するのはとても難しい事です。私たちの経験では、パフォーマンスとスケーラビリティの問題を解決するのは、技術と問題領域の双方における、深い知識と経験が必要とされます。
Randy: パフォーマンスとスケーラビリティの間の差です ;-)
原文はこちらです:http://www.infoq.com/articles/scalability-panel
(このArticleは2008年7月22日に原文が掲載されました)