今日、Wordpressは最も人気のあるCMSの1つです。 当初はブログのエンジンとして考えられていましたが、今日ではさまざまな種類のサイト、特にニュースポータルやオンラインメディアで使用されています。 Wordpressには、企業Webサイト、教育およびエンターテイメントポータルがあります。
Wordpressは多くのクライアントによって使用されています。多くのクライアントは、このCMSのセットアップに関する質問を頻繁に寄せています。
インターネットでWordpressをインストールおよび設定するための多くの詳細な手順があります。 この記事では、ほとんどのWordpress出版物が十分な注意を払っていない問題に触れたいと思います。 Wordpressのサイトの作業を最適化する方法について説明し、セキュリティと安定性のレベルを改善するための推奨事項を示します。 すべての例でUbuntu 12.04を使用しています。
DBMSを構成します
DBMSの選択
ご存じのとおり、Wordpressの操作には、MySQL DBMSが必要です。 最近、このDBMSの代替実装（フォーク）が普及しており、その中で最も普及しているのはPercona ServerとMariaDBです。 多くのオンラインインストール手順では、MariaDBの使用を推奨しています。
このフォークは標準のMySQLと比較して生産性が高く安定しているため、Percona Serverの使用をお勧めします。 さらに、Perconaにはシステム統計を収集するためのより多くの機能があります。
サーバーにPerconaをインストールするには、最初にキーをインポートする必要があります。
$ apt-key adv --keyserver keys.gnupg.net --recv-keys 1C4CBDCDCD2EFD2A
次に、次のリポジトリを/etc/apt/sources.listファイルに追加する必要があります。
deb http://repo.percona.com/apt precise main deb-src http://repo.percona.com/apt precise main
そして、コマンドを実行します：
$ sudo apt-get update
その後、標準パッケージマネージャーを使用してpercona-serverをインストールできます。
$ sudo apt-get install percona-server-server percona-server-client
エンジンを選択します：MyISAMまたはInnoDB？
MySQLデータベースで最も人気のあるエンジンはMyISAMとInnoDBです。 エンジンが正しく選択されていない場合、パフォーマンスと一貫性に問題があります。
これらのエンジンの機能をより詳細に検討してください。
MyISAMはSELECTサンプルで良好な結果を示しますが、これは主にトランザクションサポートと外部キーの不足によるものです。 ただし、レコードを変更および追加すると、テーブル全体が一時的にロックされるため、高負荷時に深刻な遅延が発生する可能性があります。
このエンジンの間違いない利点は、全文検索と圧縮です。 MyISAMのデータ形式はクロスプラットフォームであり、データベースのバイナリファイル（テーブル）をコピーするだけで、あるサーバーから別のサーバーにデータを簡単に転送できます。
InnoDBは、最新バージョンのMySQLでデフォルトエンジンとして使用されます。
MyISAMとは異なり、InnoDBはトランザクションと外部キーをサポートします。 Percona Serverは、InnoDBと完全に互換性のある独自のエンジンXtraDBを使用します。 InnoDB / XtraDBのデータはキャッシュされます。 ほとんどのデータがキャッシュから読み取られると、InnoDB / XtraDBのパフォーマンスはMyISAMのパフォーマンスよりも数倍高くなります。
MyISAMとInnoDB / XtraDBの比較、およびMySQLとそのフォークの比較に関する記事が多数あります（特に、 ここのパフォーマンステストを参照してください ）。 理論的な詳細には触れず、実際的なアドバイスに限定しません。MyISAMは、全文検索が必要な場合にのみ選択する必要があります。 InnoDB / XtraDBは、他のすべてのタスクで問題なく動作します。 ところで、MySQL / Percona Server 5.6+では、InnoDBの全文検索が既にサポートされています。
DBMS構成の最適化
サイトが発展するにつれて、データベース内のデータ量が増加し、データベース設定を変更する必要があります。 サイトの最適な機能を確保するために、MySQLの現在の構成が最適に構成されている方法を定期的に確認することをお勧めします。 この検証は、最も有名で人気のあるmysqltuner.plの特別なスクリプトを使用して実行するのが最も簡単です。 次のコマンドを使用してダウンロードできます。
$ wget https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl $ chmod + x ./mysqltuner.pl $ ./mysqltuner.pl
このスクリプトはMySQL統計を収集し、既存の設定を改善するための推奨事項を提供します。
Webサーバーを構成する
Apacheオプション
Apache設定は、ファイル/etc/apache2/apache2.confに保存されます
Apache構成ファイルには、max_clientsなどのパラメーターがあります。これは、クライアント要求の並列処理のために起動されるプロセスの最大数です。 一見すると、このパラメーターの最大値を設定する必要があるように思えるかもしれません。 ただし、実際には、状況は異なります。
1つのApacheプロセスが20 MBのRAMを消費すると仮定します。 パラメータmax_clientsが200に設定されている場合、すべてのプロセスでピーク負荷が発生すると、200×20 MB = 4 GBのメモリが必要になります-これはApacheのみで行われます！ メモリが不足すると、最も単純なクエリでも非常に遅くなります。 また、サーバー上のソフトウェアが機能しなくなる場合があります。
したがって、max_clientsパラメーターの設定が大きすぎることはお勧めできません。 要求の数が設定値を超える場合、これらの要求はすべて、ビジーなプロセスが解放されるとすぐにキューに入れられて処理されます。
パフォーマンスを向上させるために、構成ファイルの対応する行を修正してキープアライブ接続を無効にすることもお勧めします。
キープアライブオフ
バックエンド+フロントエンド= Apache + Nginx
多かれ少なかれ負荷の大きいWebプロジェクトには、マルチレベルアーキテクチャが必要です（これについては既に説明しました）。 Wordpressに基づいたほとんどのプロジェクトでは、バックエンドの2レベルのアーキテクチャ-フロントエンドが非常に適しています。 バックエンドApache、フロントエンド-Nginxとして、次のバンドルを使用することをお勧めします。
ただし、別のオプションも可能です-バックエンドとしてphp-fpm、フロントエンドとして-同じNginx（たとえば、 こことここの設定手順を参照） 。 多くの出版物は、php-fpm + Nginxバンドルの方が高速であるか、消費するメモリがはるかに少ないと主張しています。 ただし、これらの記述に明確に同意することはほとんど不可能です。
インターネットで公開されたテストは、健全な量の懐疑的な態度で処理する必要があります：多くの場合、php-fpm + Nginxは、Apacheが適切に構成されていないため、より良い結果を示します（たとえば、 テストレポートとその重要な分析を参照してください。 ここで興味深い議論）。 私たち自身の経験に基づいて、ほとんどのWordpressプロジェクトでは、Apache + Nginxの組み合わせが非常に適していると言えます。 ソリューションの選択は、生産性の向上だけでなく、解決するタスクの詳細と技術的利便性の考慮に基づいている必要があります。 私たちの意見では、Apacheはより柔軟に構成できます。 別のWebサーバーとして、Nginxのバックエンドとして、およびphp-fpmのフロントエンドとして使用できます。
一般的な作業スキームは次のようになります。Nginxはユーザーからリクエストを受信し、Apacheによって送信されるか、独立して処理されます。 Apacheリクエストは、動的コンテンツの処理に関連して送信されます-たとえば、phpスクリプト。 Nginxは、グラフィックス、JS、CSS、テキストファイル、XMLファイルなどの静的要素を返すリクエストを個別に処理します。
要求を処理し、Nginxのコンテンツを渡すと、Apacheは切断され、他の要求の処理に進みます。 これにより、作業が大幅に加速されます（たとえば、インターネット接続が遅い場合は重要です）。
さらに、Memcachedサーバーを使用して、動的なリクエストの配信を高速化できます（たとえば、 こちらのインストールと設定の手順を参照してください ）。
セキュリティを提供します
Wordpressの機能を拡張するには、多数のプラグインが使用されます。 これらのプラグインにはさまざまな脆弱性が絶えず検出されており、このため、一部のシステム管理者はこのプラグインに偏っています。 実際、Wordpressベースのサイトはしばしば攻撃の標的になりますが、時間の経過とともに、開発者はプラグインを改良して既存のセキュリティ上の欠陥を排除します。 以下に、Wordpressを設定するためのいくつかのヒントを示します。これにより、サイトの脆弱性を減らすことができます。
Wordpressがインストールされているサーバー上のマルウェアおよびスクリプトの脆弱性から身を守ります。 ClamAV + Maldetスキャナーの使用をお勧めします。 AVのインストールと設定の手順については、 こちらをご覧ください 。 WPScanを使用して脆弱性を検索することもできます。
データベースのテーブルプレフィックスを変更します。 デフォルトでは、wp_プレフィックスはWordpressデータベースに設定されています。 これにより、MySQLインジェクションの脆弱性の使用が簡素化されます。テーブル名がわかっている場合、悪意のあるコードを挿入したり、情報を変更したり、完全に削除したりするのがはるかに簡単になります。 Wordpressの新しいバージョンには、インストール中にプレフィックスを選択する機能があります。
以前のバージョンのWordpressを使用している場合は、専用のプラグインを使用してプレフィックスを変更できます。 最も有名で人気のあるものは、プレフィックスチェンジャーです。 ただし、これらのプラグインの多くは常に正しく動作しないため、使用する前にデータベースをバックアップすることをお勧めします。
wp-config.phpファイルを移動します。 wp-config.phpファイルには、不正アクセスから保護するための重要なWordpress設定が含まれています。 デフォルトでは、このファイルはルートディレクトリに保存されますが、上記のディレクトリに移動できます。 ルートディレクトリにwp-config.phpが見つからない場合、Wordpressは自動的に検索します。
SSL証明書を取得し、SSL暗号化を有効にします。 これを行うには、wp-configファイルに次の行を追加します。
/ * SSL暗号化を有効にする* / define（ 'FORCE_SSL_LOGIN'、true）; define（ 'FORCE_SSL_ADMIN'、true）;
Wordpressのバージョン情報を削除します。 攻撃者が古いバージョンのWordpressを使用していることを発見した場合、既存の脆弱性を利用してサイトをハッキングできます。 したがって、バージョン情報を削除するのが最適です。
まず、ファイルyoursite / readme.htmlを削除する必要があります。このファイルから、使用しているWordpressのバージョンを簡単に見つけることができます。
テーマフォルダーにあるheader.phpファイルから、使用されているバージョンを確認することもできます。 次の行が含まれています。
<meta name = "generator" content = "WordPress" />
この行全体を削除できます。 テーマのheader.phpファイルにそのような行がない場合、ほとんどの場合、wp_head（）関数が呼び出されたときにWordpressによって自動的に挿入されます。 この場合、functions.phpファイルに次のコードを追加することにより、セクションからバージョン情報を削除できます。
remove_action（ 'wp_head'、 'wp_generator'）;
function selectel_remove_version（）{
return '';
}
add_filter（ 'the_generator'、 'selectel_remove_version'）;
セキュリティキーを変更します。 上記のwp-config.phpファイルには、セキュリティキーのセクションがあります。 次のようになります。
define（ 'AUTH_KEY'、 ''）; define（ 'SECURE_AUTH_KEY'、 ''）; define（ 'LOGGED_IN_KEY'、 ''）; define（ 'NONCE_KEY'、 ''）;
キーはパスワードのハッシュに使用されます。 多くの場合、経験豊富なユーザーであっても、このセクションに注意を払っていません。 一方、セキュリティキーの変更は非常に簡単です。https ：//api.wordpress.org/secret-key/1.1に移動し、生成されたキーをwp-config.phpファイルにコピーするだけです。 この手順は、サイトの初期セットアップ中に一度だけ実行すれば十分です。
wp-contentおよびwp-includesフォルダーへのアクセスを制限します。 セキュリティ上の理由から、wp-contentフォルダーとwp-includesフォルダーのコンテンツへのアクセスをブロックすることをお勧めします。 グラフィック、JS、CSSを除くすべてのファイルへのアクセスをブロックする必要があります。 これを行うには、各フォルダーに.htaccessファイルを作成し、次のコードを入れます。
注文許可、拒否 すべてから拒否 すべてから許可
空のwp-content / plugins / index.htmlファイルを作成します。 これにより、使用するプラグインに関する情報が利用できなくなります。 Wordpressプラグインには脆弱性が含まれている可能性があり、サイバー犯罪者によって悪用される可能性があります。
リストにアクセスできないようにするには、次の行をpluginsフォルダーに保存されている.htaccessファイルに追加することもできます。
オプション-インデックス
wp-adminフォルダーへのアクセスを制限します。
アクセスを制限するには、このフォルダーに.htaccessファイルを作成し、次のコードをそこに配置する必要があります。
AuthUserFile / dev / null AuthGroupFile / dev / null AuthName "アクセス制御" AuthType Basic 注文拒否、許可 すべてを拒否 ＃は、たとえば、示します。 自宅のコンピューターIP から許可する ＃ここで、職場でブログを書く1つまたは複数のIPアドレスのアドレスを示します から許可する から許可する
特定のIPアドレスのセットへのアクセスを制限することは必ずしも便利ではありません。 パスワードでのみwp-adminフォルダーへのアクセスを構成できます。 これを行うには、.htauthファイルを作成します。
$ htpasswd -c /home/yourdirectory/.htauth
/ public_html /ディレクトリの1レベル上に配置します
次に、wp-adminフォルダーに.htaccessファイルを作成し、次のコードをそこに配置する必要があります。
AuthName "管理者のみ" AuthUserFile /home/yourdirectory/.htauth AuthGroupFile / dev / null Authtype Basic ユーザー<username>が必要
おわりに
Wordpressのようなシンプルで直感的なCMSの設定もかなり複雑な作業であり、経験豊富なユーザーでさえ常に注意を払わない多数のニュアンスが含まれています。 上記の推奨事項が役に立つことを願っています。 私たちの側では、 サーバー管理サービスの新しいパッケージの一部として、Wordpressで複雑なプロジェクトの設定と最適化を支援する準備ができています 。
もちろん、この記事に記載されている推奨事項のリストは完全ではありません。 コメントでコメントを表明し、Wordpressでプロジェクトを最適化した経験を共有していただければ幸いです。
ここにコメントを投稿できない読者は、私たちのブログに参加してください。