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