とあるはてな社員の日記 - まっさらなサーバを30分で本番投入できるようにする
すこし前にはてなスターのリリースがされたのですが、サービス開始直後にありがちなことに、時々負荷で遅くなったり、アクセスしにくくなったりしてしまいました*1。これではいけない、ということで、すぐ次の日に、バックエンドのサーバを一気に10台近くまで増やして、おおむね快適に使える状態になっていると思います。この時に、新しいサーバをまっさらな状態から、だいたい30分程度で本番投入することができていました。これを、どのように実現したのかを軽く紹介したいと思います。 ちなみに、サービスの重さは、サーバ増強だけで済むものではなく、それ以降も、Javascriptが重い!とか、アプリケーションロジックで重いSQL を走らせてしまって遅いという問題は何回かありました。が、そこはインフラではなく、アプリケーションの問題で、アプリケーションの改善は、継続的に進んでいると思います。ので、今回は、インフラの話に限定
CodeZine：DeNAの人気サイトに学ぶ LAMPによるWeb-DBシステム構築/運用の極意（前編）（モバオク, モバゲー）
シングルマスタの非同期レプリケーション機能では、マスタサーバーが1台に限定され、マスタからスレーブへの複製は非同期で行なわれるため遅延が生じ、短時間のスケールで見ると全スレーブとの同期が保証されない。しかし、その反面スレーブの台数を増加させていってもマスタサーバーの更新負荷は大きくならず、スケーラビリティを維持できるという利点がある。DeNAによる運用実績でも、マスタとスレーブ間の遅延は通常数秒程度以内に収まる。 このレプリケーションを利用する場合、アプリケーション側ではデータ更新時にはマスタサーバーへ接続し、データ参照のみを行なう場合はスレーブサーバーへ接続するように作成する必要がある。 Webや携帯電話向けサービスの場合、小さな規模で始めてユーザー規模、データ規模、ページビュー数を徐々に増加させていくことが多い。小さな規模のためDBの負荷分散が不要な場合でも、マスタサーバー1台、スレー
cyano: mod_proxy_balancerで中〜大規模サーバー運用するときの勘所 - (1) mod_proxy_balancerの設定編
mod_proxy_balancerで中〜大規模サーバー運用するときの勘所 - (1) mod_proxy_balancerの設定編 Apache2.2から、ロードバランシングをしてくれるmod_proxy_balancer というモジュールが標準添付になりました。 このモジュール、その名前の通り、ApacheレベルでHTTPリクエストをバックエンドのサーバーに振り分けることでロードバランシングをしてくれるモジュールです。 Apacheの公式ドキュメントや試しに入れてみた人のBlogなどは散見されますが、実際の現場で運用している事例というのはまだ無いようです。 そこで、実際にピーク時にover 500 request/secでmod_proxy_balancerなサーバーを運用している経験をふまえ、つまずいた点などを公開していきたいと思います。 まず、mod_proxy_balancerの
ポートチェック【外部からポート開放確認】
ポートチェックテスト【外部からのPort確認】は、サーバー監視者向けにご提供しています。 ご指定のホスト名またはIPアドレスのご指定ポート番号に、当社サーバーよりTCP接続を行うことで、外部（インターネット）からの疎通確認を行うことができます。 「メンテナンスを行ったが、サーバやネットワーク機器にアクセスできるか？」 「サーバやルータのポートは開放されているか？」 「サーバやルータのポートは閉じているか？」 Port応答チェック ご指定のサーバやネットワーク機器に当社サーバより「Portコマンド」を発行し結果をブラウザ上に表示します。 該当サーバに実際にアクセスされますのでログが残る場合があります。 ご自身で管理・運営しているサーバやネットワーク機器のみでご利用ください。 使用不能文字：<>"{}|\^[]`#;?@&=+$,'()
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
