オープンソースシステムを利用した 大規模Webサイトの構築 Apache/PHP/PostgreSQLを利用した大規模Webサイトを構築す る際のシステム設計とPHPプログラミングについて 大垣 靖男 <[email protected]> 日本PHPユーザー会 Electronic Service Initiative, Ltd. 大規模Webシステムの必要要件 大規模システムには高いシステムパフォーマンスが必要 多数の同時ユーザーに対応 高いWebサーバー負荷 多数の同時接続に対応 高いDBサーバー負荷 非常に多いネットワークトラフィック 高いネットワーク負荷 大規模なWebシステムでは負荷を効率よく分散し、ボトルネックになるシステムを作らな いことが重要 システム規模、システムの特徴をインフラ設計/システム設計/コーディングが重要 大規模Webシステムの必要要件 多数の同時ユーザー数への対応 多数の同時接続数への対応 大量のネットワークトラフィックへの対応 ここでは、単純化のため、システム可用性の確保などは考慮しないこととする（実際のシステムで は当然考慮しなければならない） ここでいう大規模Webシステムとはシステムの複雑性ではなく、システムユーザーの規模が大規 模であることとする 大規模Webシステムは高性能であることが必須条件 Electronic Service Initiative, Ltd. 1 大規模WebシステムはApache/PHP/PostgreSQLで 構築できるか？ 現状のApache/PHP/PostgreSQLでもかなり大規模なシステム構築が可能 Apache/PHP/PostgreSQLの問題点 Apacheには大きな問題が無いが、非常に多い同時リクエストが発生した場合のパフォーマンス 確保が課題 PHPのPostgreSQLモジュールにはコネクションプーリング機能が無いため、DB性能の確保が課 題 PostgreSQLはレプリケーション機能が弱い PHPは比較的高速に動作するサーバーサイドスクリプト言語だが、大規模システムには 向かない側面を持つ スクリプト型言語 コネクションプーリングが未サポート モジュールとして動作していても、PHPエンジンを利用するだけでWebサーバーのパフォーマンスは半分以 下に低下 スクリプト実行は遅い 永続的接続はサーバープロセス/スレッド毎に確保 他の多くのシステムと同様にPostgreSQLは同時ユーザー数が多すぎると100%の性能が発揮できない PHPを利用した大規模サイトの構築にはちょっとした工夫が必要！ Electronic Service Initiative, Ltd. 大規模Webサイト構築の注意点 システム負荷の見積もり 各システムの性能特性の把握 ページのリアルタイム性の評価 必要なログの評価 サブシステム間での連携（関係） の評価 ピークシステム負荷は？ ピーク性能特性は？ リアルタイム性が必要なページ （データ）は？ どのようなログが必要か？ サブシステム間での連携時の性 能は？ 700 600 500 リクエス ト数 表示遅延 クエリ数 処理遅延 400 300 200 100 0 64 128 192 256 Electronic Service Initiative, Ltd. 2 PHPからPostgreSQLへのアクセスにおける問題点 Pgsqlモジュールの永続的DB接続と非永続的DB接続 永続的接続はDB接続をWebサーバープロセスが終了するまで維持 非永続的接続はリクエスト終了時にDB接続を切断 コネクションプーリング データベース性能の確保には重要な技術 PHPはコネクションプーリングをサポートしていない コネクションプーリングと同様な仕組みはシステム構成またはPHPプログラムで作成 可 Electronic Service Initiative, Ltd. 他のPHPの問題点 スクリプトエンジン Webサーバー（Apache） とPHP PHPは内部的にプログラムをバイトコード（中間コード）にコンパイルし実行する １行のバイトコードの実行にはC言語にして数千行以上のコードが実行される リクエストをまたがるデータ保持を行う、効率的な機能が提供されていない オブジェクト指向プログラミングはオーバーヘッドが大きい モジュールとして実行されたPHPはPHPスクリプト実行しなくてもパフォーマンスを低 下させる 実行されないコードもリクエスト毎にコンパイルするため、読み込むコード量に比例し てパフォーマンスが低下する セッションとシリアライズ PHP Sessionモジュールはオーバーヘッドが大きいserialize/unserializeを実行する Electronic Service Initiative, Ltd. 3 通常のシステム構成 Apache/PHP/PostgreSQLを利用したWebシステム ファイアーウォール Apache+PHPサーバー Apache+PHPサーバー Apache＋PHPサーバー PostgreSQLサーバー Electronic Service Initiative, Ltd. 通常のシステム構成の問題点 「通常のWebシステム」の特徴 複数あるWebサーバーは全て同じサービスを提供 データベースサーバーへの接続は非永続的接続を利用し、最大接続数を超えて接 続に失敗した場合は再接続を試みる（または永続的接続を使用） ファイアーウォールは接続制限などを行わない 負荷分散はラウンドロビンDNSを利用する 「通常のWebシステム」の問題点 Webサーバーへの負荷分散の為に、Webサーバーを追加する事が難しい 瞬間的な高負荷に対応しにくい 全てのページリクエストが全てのWebサーバーで処理されている データベースサーバーへの接続数が多くなりすぎる リバースプロキシーが無い 負荷の高いプログラムなどにシステム全体の性能が左右される Electronic Service Initiative, Ltd. 4 スケーラビリティーを考慮したシステム構成の例 Apache/PHP/PostgreSQLを利用したシステム ファイアーウォール --limitを利用 Apache+PHPサーバー +Squid Apache+PHPサーバー +Squid Apache+Squid PostgreSQLへの接続数を制限 PostgreSQLサーバー Electronic Service Initiative, Ltd. スケーラビリティーを考慮したシステム構成の例 特徴 静的コンテンツと動的コンテンツを持つWebサーバーに役割を分担 Squidを利用しリバースプロキシーを構築 IPTablesを利用しDoS対策を実施 負荷分散はIPTablesを利用 PHPからのデータベース接続数を制限 永続的接続を利用しApacheプロセス数で接続数を制限 非永続的接続を利用しPHPスクリプトからSemaphoreを利用して接続数を制限 問題点 非永続的接続はコネクションプーリングより性能が悪い 永続的接続を利用した接続の場合、コネクションプーリングと同等のパフォーマンス が期待できるが柔軟性にかける Electronic Service Initiative, Ltd. 5 大規模システムの設計 リバースプロキシーの導入は必ず検討する イメージなど静的なコンテンツ専用サーバーの導入を検討する ラウンドロビンDNSよりIPTablesのDNATの利用を検討する 他にもIPTablesはDoS対策として利用可能 データ更新が管理できる場合、バッチ処理などによりデータをレプリケーション する アクセスログなどはテキストベースで収集し、DB化が必要な場合はバッチ処理 でおこなう WebサーバーからDBサーバーへのアクセス数を何らかの形で制限する HTTPヘッダーによるロードバランスをサポートするシステムの導入を検討する etc Electronic Service Initiative, Ltd. 大規模システムのPHPプログラミング 利用可能な場合バイトコードのキャッシングを考慮する リバースプロキシーの利用を考慮する 動的なページ生成は最小限にとどめる 配列のハッシュ機能を活用する（e.g. in_array()を利用しない） 同じスクリプトを何度もrequire/includeしない 過度なオブジェクト指向は避ける 読み込まれるスクリプト行数に注意する 実行されるスクリプト行数に注意する スクリプトは常に最も短い時間で実行が完了するようにコーディングする（i.e. sleepや不適切に設定されたMTAを使わない） エラーハンドラと出力バッファを利用した効率的なエラー処理を行う 開発時には遅いマシンを利用して開発する etc Electronic Service Initiative, Ltd. 6 結論 Apache/PHP/PostgreSQLを利用した大規模Webシステム作れるか？ システム構成やプログラム設計を工夫し、これらのソフトウェア+αを利用すると同 時アクセスユーザー数が数千〜数万ユーザーになるシステムを構築することは十分 可能 Electronic Service Initiative, Ltd. 最後に パフォーマンステストはしていますか？ リクエスト数 遅延時間 CPU/メモリ利用率 Electronic Service Initiative, Ltd. 7
© Copyright 2024 Paperzz
