タグ付けされた質問 「scalability」

私の知的好奇心のために、FacebookやWikipediaのような大規模なサイトがどのように機能するかを理解しようとしています。スケーラブルなサイトを構築するためのさまざまな手法について読みましたが、それでも特定の詳細については困惑しています。 私を混乱させる部分は、最終的に、DNSがドメイン全体を単一のIPアドレス、またはラウンドロビンDNSの場合は少数のIPアドレスにマップすることです。 たとえば、wikipedia.orgにはタイプA DNSレコードが1つしかありません。そのため、ウィキペディアを訪れる世界中の人々は、DNSで指定された1つのIPアドレスにリクエストを送信する必要があります。 大規模なサイトのIPアドレスをリッスンするハードウェアは何ですか？また、世界中のユーザーへのリクエストから生じるすべての負荷をどのように処理できますか？ 編集1：すべての応答に感謝します！エニーキャストは実行可能な答えのように思えます...特定のIPアドレスがエニーキャストでルーティングされているかどうかを確認する方法を知っている人はいますか。 編集2：トピックをさらに読んだ後、エニーキャストは通常​​動的Webコンテンツには使用されないようです。エニーキャストは通常​​、UDP（DNSルックアップなど）に使用されるか、静的コンテンツに使用されることもあります。 注意すべき興味深い点の1つは、Facebookがprofile.ak.fbcdn.netを使用して、スタイルシートやJavaScriptライブラリなどの静的コンテンツをホストしていることです。この名前をpingするたびに、異なるIPアドレスから応答を受け取ります。ただし、これが動作中のエニーキャストであるか、まったく異なる手法であるかはわかりません。 元の質問に戻ります。私が知る限り、大規模なサイトであっても、少数のパブリックIPアドレスでリッスンする負荷分散ハードウェアの単一の高価な部分があります。

32 domain-name-system  scalability  anycast 

サーバーフォールトで回答できるため、 この質問はStack Overflowから移行されました。 8年前に移行され ました。 多くの人がトラフィックの多いデータベース駆動型Webサイトで作業していることを望みます。そして、主なスケーラビリティの問題がデータベースにある可能性があります。最近、いくつかのことに気付きました。 大規模なデータベースのほとんどは、拡張するためにDBAのチームが必要です。彼らは常にハードドライブの制限と格闘しており、非常に高価なソリューション（SANまたは大規模なRAID、最適化と再パーティション化のための頻繁なメンテナンスウィンドウなど）になります。私には急すぎる:) 最後に、Intel、Samsung、FusionIOなどのように、SLCフラッシュテクノロジーに基づいて非常に高速で手頃な価格のSSDハードドライブの販売を開始した企業をいくつか獲得しました。これらのドライブは、市場で最高の回転するハードドライブよりもランダムな読み取り/書き込みで100倍高速です（1秒あたり最大50,000回のランダム書き込み）。シーク時間はほとんどゼロであるため、ランダムI / OのコストはシーケンシャルI / Oと同じです。これはデータベースにとって素晴らしいです。これらのSSDドライブの価格はギガバイトあたり約10〜20ドルで、比較的小さい（64GB）。 そのため、SSDドライブの十分に大きいRAID 5アレイ（わずか数千ドル）を構築するだけで、従来の方法でデータベースをスケーリングする莫大なコストを回避する機会があるようです。データベースファイルが断片化されているかどうかは気にしません。データベースを100スピンドルに分散させることなく、1秒間に100倍のディスク書き込みを行う余裕があります。。 他の誰かがこれに興味がありますか？私はいくつかのSSDドライブをテストしてきましたが、結果を共有できます。このサイトの誰かがすでにSSDでI / Oボトルネックを解決しているなら、あなたの戦争の話を聞きたいです！ PS。実績のあるRAMベースのSANなど、スケーラビリティに役立つ高価なソリューションがたくさんあることを知っています。私は、$ 50Kでさえ私のプロジェクトには高すぎることを明確にしたいと思います。コストが1万ドル以下で、実装にそれほど時間をかけないソリューションを見つける必要があります。 デイブ、NXC、およびバリー、 返信いただきありがとうございます！私の状況では「安い」という言葉が非常に重要であることを明確にしたいと思います。そのため、安価なDellサーバー（メモリバンクが8つしかない2950ドル$ 4K）を使用する必要があります。既に32 GBのRAMがインストールされているため、この方法でスケーリングを続けることはできません。それに、RAMを追加しても、ディスクWRITEのボトルネックからあなたを救うことはできません。これが今の私の主な問題です。 以前はSSDの寿命に関心がありましたが、最新のウェアレベリングアルゴリズムについて読んだ後、これらのドライブは十分に長く続くと確信しています。私のデータベースは1日あたり300GBを書き込み、2009年には1日あたり1TBを超えると予測されています。エンタープライズSSDは、複数年にわたって1日あたり約10TBの書き込みを処理するように設計されています。 SASからSSDに移行するには手間がかかりすぎるというBurlyの主張には同意しません。私のデータベースは同期ミラーであるため、ミラーの片側をアップグレードしてから数か月間監視し、それが壊れた場合、古いSASハードディスクドライブがまだ残っている2番目のサーバーにフェールオーバーできます...

25 raid  database  hard-drive  ssd  scalability 

Nginx worker_connectionsは、ワーカープロセスで開くことができる同時接続の最大数を設定します。この数には、クライアントとの接続だけでなく、すべての接続（たとえば、プロキシサーバーとの接続など）が含まれます。現在開いているファイルの最大数の制限を超えることはできません。」これに関するクエリはほとんどありません。 これに最適な値または推奨値は何ですか？ 多数のワーカー接続を使用することのマイナス面は何ですか？

25 nginx  connection  scalability  worker-process 

私は長年VMWareを使用しており、数十の実稼働サーバーをほとんど問題なく実行しています。しかし、単一の物理ホストで20個を超えるVMをホストしようとはしませんでした。アイデアは次のとおりです。 Windows XPの機能が低下したバージョンは、512MBのRAMと4GBのディスク容量で動作できます。 5,000ドルで、64 GBのRAMと4つのSASミラーを備えた8コアサーバークラスのマシンが手に入ります。 上記の100台のVMがこのサーバーに収まるため、私のハードウェアコストはVMあたりわずか50ドルです。 誰かがVMWareでこの種のスケーラビリティを達成できるかどうかを知りたいですか？いくつかのテストを行ったところ、奇妙な問題にぶつかりました。20個のVMを起動すると、VMのパフォーマンスが劇的に低下し始めます。同時に、ホストサーバーにはリソースのボトルネックは表示されません（ディスクのアイドル率は99％、CPU使用率は15％未満、空きRAMは十分にあります）。 VMWareやその他の仮想化技術のスケーリングに関する成功事例を共有していただければ幸いです！

24 virtualization  virtual-machines  vmware-esx  scalability  host 

多くの場合、アプリサーバーの前にSLB /リバースプロキシを持つWebアプリアーキテクチャがあります。 SLBへの接続数が、単一の SLBが効果的に処理するには多すぎるリソースを必要とする場合はどうなりますか？具体的でありながら最高の例として、200万の永続的なHTTP接続を検討してください。明らかに、単一の SLBはこれを処理できません。 SLB をスケールアウトするための推奨構成は何ですか？ LBのグループ/クラスターを作成するのは一般的ですか？そうである場合、LBのグループ間でクライアントの負荷はどのように分散されますか？

22 reverse-proxy  scalability  load-balancing 

statsd / graphiteをセットアップして、HTMLデバイスで実行されているJSアプリをログに記録できるようにします（つまり、収容されたLAN環境ではなく、直接制御できない大量の着信データがある場合）。 私の制約： エントリポイントはHTTPを話す必要があります：これは単純なHTTP-to-UDP-statsdプロキシ（たとえば、githubのhttpstatsd）によって解決されます 単一のサーバーの障害に抵抗する必要があります（マーフィーの法則と戦うために:) 水平方向にスケーラブルでなければなりません：webscale、baby！:) アーキテクチャは可能な限りシンプル（かつ安価）に保つ必要があります 私のサーバーは仮想マシンです データファイルはファイラーアプライアンスに保存されます（NFSを使用） tcp / udpハードウェアロードバランサーを自由に使用できます 要するに、データパス：[client]-（http）-> [http2statsd]-（udp）-> [statsd]-（tcp）-> [graphite]-（nfs）-> [filer] これまでの私の調査結果： http2statsd部分のスケーリングは簡単です（ステートレスデーモン） statsd部分のスケーリングは簡単ではないようです（sum、avg、min、maxなどの集計データのグラファイトで一貫性のない値になると思います）。HTTPデーモンがキーを分割するために一貫したハッシュを行わない限り。たぶんアイデア...（しかし、HAの質問があります） グラファイト部分のスケーリングは、シャーディング（カーボンリレーを使用）で実行できます（ただし、HAの問題も解決しません）。明らかに、いくつかのささやきインスタンスは同じNFSファイルを書き込むべきではありません。 ファイラー部分のスケーリングは問題の一部ではありません（ただし、IOが少ないほど良いです:) 共有NFSデータのみを読み取るため、webappのスケーリングは明らかです（私はテストしていませんが）。 だから、誰もが安定したstatsd /グラファイト展開のために共有する経験とベストプラクティスを持っているのだろうかと思っていましたか？

17 http  high-availability  scalability  graphite  statsd 

多くの小さなサーバーに分割して「スケールアウト」するのではなく、「より強力で高価なサーバーに」「スケールアップ」しなければならないシステムがあるのではないかと長い間思っていました。 そのようなシステムは存在しますか？存在する場合、特にシステムをスケールアウトするのではなくスケールアップする必要がある傾向がありますか？（たとえば、ACID苦情データベーストランザクション、またはその他の強力なデータ整合性要件がこのニーズを作成する可能性があります。） スケールアップはスケールアウトよりもはるかに高いハードウェアコストをもたらすように見えるため、可能であれば回避したいように見えますが、常に回避可能かどうかはわかりません。 それでは、スケールアウトできないシステムがあり、代わりにスケールアップする必要がありますか？これを引き起こす原因は何ですか？また、そのようなシステムをどのように識別しますか？（それらは一般に、それらをより簡単に識別できるようにするいくつかの特徴を共有していますか？）

12 database  scalability  infrastructure 

マルチリージョンスキームでWebアプリケーション（PHP、MySQL、memcache）をスケーリングしようとしています。現在、ELBおよびRDSインスタンスの背後にある2つのEC2インスタンスのセットアップを使用しています。これらはすべてUS-EAST（バージニア）リージョンにあります。 EU（アイルランド）地域にも存在感を持ちたいです。これは、少なくともそこに新しいEC2インスタンスが存在することを意味します（他のインスタンスと同一で、同じアプリケーションにサービスを提供します）。 目的のAMIをコピーし、新しいインスタンスをセットアップし、同じELB構成（SSL終了に必要）をセットアップし、Route53で遅延ベースのルーティングを構成しました。そして、提案どおりに機能します。 しかし、EUのクライアントには速度の問題があります。これは、EU EC2インスタンスが米国ベースのRDSインスタンスに接続するという事実によるものです。私の知る限り、AmazonはRDSマルチリージョンレプリケーションをまだ有効にしていません。 単一のRDSインスタンスを使用しながら、セットアップ全体を適切に高速化する方法に関する提案はありますか？ また、物事を拡大する方法に関する一般的なアイデアはありますか？理想的には、さまざまな理由でRDSテクノロジーの使用を継続したいと考えています。それにもかかわらず、私は提案を受け入れています（次のアイデアは、独自のMySQLサーバーをホストすることだと思います）。

11 amazon-ec2  amazon-web-services  scalability  amazon-rds  scaling 

このComputer World記事では、PostgreSQLが64のコア制限まで拡張できることを指定しています。これは、64コアの1つのマルチコアプロセッサを意味しますか？それともコアの少ないマルチプロセッサですか？ 私が尋ねる理由は、PostgreSQLがスケールアップできるプロセッサの数を見つけようとしているためですが、もちろんそれはプロセッサのタイプに限定される可能性があります。ただし、他のデータベースで他の統計情報（つまり、ここでは Microsoft SQL Server が最大320の論理プロセッサに拡張できることを示す）を見つけており、コアの数を指定していません。これは非常にあいまいな統計ですか？ どんな考えでも大歓迎です。ありがとう！

10 database  postgresql  scalability 

私はubuntuにapache / phpを備えた専用サーバーを1日あたり約10K以上のページビューでWordpressブログに提供しています。APCにW3TCプラグインがインストールされています。 しかし、時々サーバーが応答を停止するか、非常に遅くなり、私はそれを元に戻すためにApacheを再起動する必要があります。 私の設定は何ですか？ ServerRoot "/etc/apache2" LockFile /var/lock/apache2/accept.lock PidFile ${APACHE_PID_FILE} TimeOut 40 KeepAlive on MaxKeepAliveRequests 200 KeepAliveTimeout 2 <IfModule mpm_prefork_module> StartServers 5 MinSpareServers 5 MaxSpareServers 8 ServerLimit 80 MaxClients 80 MaxRequestsPerChild 1000 </IfModule> <IfModule mpm_worker_module> StartServers 3 MinSpareServers 3 MaxSpareServers 3 ServerLimit 80 MaxClients 80 MaxRequestsPerChild 1000 </IfModule> <IfModule …

10 apache-2.2  wordpress  php5  scalability 

私の医療画像を保存するための新しいファイルサーバーを提供するように求められました（dicomではなくraw形式）。ITスタッフがいないため、解決策を見つける必要があり、このトピックについてはほとんど何も知りません。 私たちの要件は次のとおりです。3年間で24 TBまで拡張可能、Windowsファイル共有であり、共有は可能な限り大きくする必要があります（1x24TB共有）。私が最初に見つけたのはNETGEAR ReadyNAS 3200です。非常に優れたシステムのようで、大規模なコミュニティを伴っているようです。問題が発生した場合に役立ちます。 しかし、このシステムはどの程度スケーラブルですか？このシステムは「積み重ね不可能」だと言われています。NASのスタッキング方法がわかりませんが、iSCSIイニシエーターを購入し、すべてのNASをiSCSIターゲットとして構成し、すべてのターゲットをカバーするイニシエーターにRAIDを構築して、この大きなRAIDを1つのWindows共有として共有できますか？それともできないのですか？私はスケーラビリティの仕組みについて明らかに途方に暮れているので、誰かがこれを説明できたら、私はとても感謝しています。 誰かが別のソリューション（readynasの仕様に匹敵するが積み重ね可能な別のNASのような）を見た場合、もちろんこれも提案できます。

10 file-sharing  network-attached-storage  scalability  readynas 

ユーザープロフィール画像を保存するWebサイトがあります。各画像は、ユーザー固有のディレクトリ（Linux）に保存されます。現在、30以上の顧客ベースがあります。つまり、30以上のフォルダーがあります。しかし、私の現在のLinuxボックス（ext2 / ext3）は、32000を超えるディレクトリの作成をサポートしていません。どうすればこれを乗り越えられますか？YouTubeの男性でさえ、ビデオのサムネイルに関して同じ問題を抱えています。しかし、彼らはReiserFSに移行することでそれを解決しました。より良い解決策はありませんか？ 更新：IRCで尋ねられたとき、人々はそれをext4にアップグレードすることを求めていました。これには64kの制限があり、もちろんそれを乗り越えることもできます。または、カーネルハッキングで制限を変更します。 更新：ユーザーベースをユーザーIDの範囲に基づいてフォルダに分割するのはどうですか。1つのフォルダで1-1000、他のフォルダで1000-2000を意味します。これは簡単なようです。みんな何て言うの？ 正直なところ、他に方法はありませんか？

9 linux  filesystems  directory  scalability 

64k以上のWebソケットを処理できるアーキテクチャを設計しようとしています。 私たちは最初にAmazon ELBを試しましたが、その設計では、トラフィックやWebSocketの予期しないスパイクは許可されていません。（TCPモードでWebSocketが予期せずタイムアウトする） HAProxyではこれらの制限は適用されませんが、HAとバックエンドサーバー間で維持される〜64kのWebソケットに制限されます。 頭に浮かんだ複数のソリューション： 複数のHAProxyインスタンス、DNSによる負荷分散（Route53には加重オプションがあります） Keepalived、複数の内部IPアドレスを持つ2つのHAProxyインスタンス（実行可能かどうかは不明） これを行うより良い方法はありますか？

8 domain-name-system  load-balancing  haproxy  scalability  websocket 

トラフィックが急増しているサイトを運営しています。そのため、この場合、自動スケーリングソリューションは非常に有益です。現在、Webサーバーは水平方向に自動スケーリングできますが、ボトルネックはMySQLサーバーにあります。 私はAmazon RDSマルチAZを試してみましたが、12 GBのデータベースをアップグレードするには、数分のダウンタイムで15分程度かかります。ある特定の瞬間にトラフィックの急増が起こることをすでに知っていたとき、それは多くの助けとなりました。 Xeroundも検討しました。このサイズのデータ​​ベースでは非常にコストがかかりますが、これはおそらく最良のソリューションです。とにかく、データベースをEUに置くことを法的に必要とするため、これは選択肢ではありません。 私はScalrについて読みましたが、それが役立つかどうか、またどのように役立つかはわかりません。 多くのクラウドホスティングプロバイダーが垂直スケーリングソリューションを提供し、ダウンタイムがゼロであると考えています（Xenハイパーバイザーを使用している限り、それが本当に可能かどうかはわかりません）。それは解決策になるかもしれませんが、ダウンタイムがないのか、MySQL構成（およびOS上の他の多くのこと）がダウンタイムなしでもアップグレードできるのかと思います。 MySQLスレーブサーバーを試しましたが、まったく役に立ちませんでした。 memcacheを使用していますが、これは非常に役立ちますが、それだけでは不十分です。読み取りのためだけでなく、書き込みのためにアップグレードする必要があります。 助言がありますか？前もって感謝します

8 mysql  scalability  amazon-rds  scalr