困った時はどうするの？ concrete5 サイト調査とは？

Katz Ueno
Katz Ueno

Katz です。

concrete5 が 2003 年にリリースされてから、14年が経ちました。日本語版も正式にリリースされたのが、2009年なので、もう8年。

最近、お客様から、別の業者が作った concrete5 の調子がおかしいので原因を調査して欲しいという依頼がが数件立て続けにお問い合わせいただきました。

せっかくなので、コンクリートファイブジャパンが普段行っている原因調査の流れを紹介します。

コンクリートファイブジャパンは concrete5 を熟知しているメンバーが揃っているので、原因の調査を行うことは出来ると思いますが、なんでも見通すことが出来る超能力者ではありません。

それは、concrete5 のサイトは柔軟さ上に、使用しているアドオンや、ページ数、ファイル数、独自カスタマイズ、利用しているサーバースペックや設定によって様々な原因が考えられるからです。

ですので、弊社では、concrete5 のサイトの中身がどのようになっているか、調査費用をいただいて原因調査を行います。

しかし、この原因調査、残念ながら問題の解決を保証できるものではありません。しかし、お客様から、原因調査ではどのような物が必要なのか、聞かれているので、弊社のお客様向けに、流れと必要になりそうな情報を共有するために書いてみました。

このブログ記事は、都度更新してまいります。

 

concrete5 サイトのトラブル・パフォーマンス調査の流れ

コンクリートファイブジャパン株式会社による、concrete5 調査は下記の流れで行います。

 

  1. エラーログを確認
    • concrete5 のエラーログ
    • サーバー: Apache や nginx などのアクセスやエラーログ
    • サーバー: MySQL のエラーログ (ただし膨大になるので取っていないサーバーが多い)
    • サーバー: Cron で発生しているのであれば Cron のログ
    • サーバー: 他にロードバランサーなどがあれば、そのログ
    • メール: メールなどであれば、そのメールのエラーのコピー
    • その他、他サービスと連携しているのであれば連携先のエラー
    • レンタルサーバー会社で特定のアップグレードなどを行っているか
  2. エラーの再現テスト
    • 同じ環境でエラーが再現するかテスト
      • concrete5
        • 閲覧テスト
        • 編集テスト
        • データ送信テスト
        • 管理画面での設定テスト
        • テスト環境があればテスト環境で実施。本番環境のみであれば、非公開ページを新たに作成してテスト。
      • PHP ファイル
        • テスト用プログラムを非公開領域に置き、設定確認・プログラムのテスト
      • MySQL
        • テスト用プログラムを非公開領域に置き、設定確認・プログラムのテスト
      • ネットワーク
        • HOSTS ファイル書き換え、テストドメインを立ち上げてテスト
  3. 問題発生源の切り分け
    • concrete5 コアのエラー
    • 既存パッケージのエラー
    • パッケージにカスタマイズをしたものエラー
    • オリジナル開発のエラー
    • サードパーティーライブラリのエラー
    • PHP 自体のエラー
    • Apache や nginx などの Web サーバーエラー
    • MySQL や MariaDB などのデータベースエラー
    • アクセス集中負荷によるエラー
    • DNS 設定や SSL 証明書によるエラー
    • ハードウエアエラー (CPU・メモリ・ディスク)
    • サーバー側：ネットワークエラー (ファイヤーウォール・バランサー・ネットワーク設定自体)
    • ユーザー側：ネットワークエラー (インターネット回線・ファイヤーウォール・ネットワーク設定自体)
    • ユーザー側：ネットワーク端末 (ブラウザ・ウイルスソフト・ファイヤーウォール設定)
  4. 解決策の模索
    • 4-1. concrete5 コア
      • 管理画面のシステム設定内で解決する問題か
      • config ファイル設定で解決する問題か
      • アップグレードで解決するか
      • パッチで解決するか
    • 4-2. 既存パッケージ
      • アップグレードで解決するか
      • パッチ作成で解決するか
    • 4-3. パッケージカスタマイズ
      • パッチ作成で解決するか
      • 再度追加カスタマイズで解決するか
    • 4-4. サードパーティーライブラリのエラー
      • 最新バージョン使用で解決するか
      • パッチ作成で解決するか
    • 4-5. PHP 自体のエラー
      • 設定変更で解決するか
        • メモリーエラーか
        • アップロードエラーか
        • 実行時間が短いエラーか
      • 足らないモジュールのインストールが必要か
      • バージョンアップが必要か
    • 4-6. Apache や nginx のエラー
      • .htaccess など再起動を必要としない設定変更で解決するか
      • 再起動を必要とする設定変更で解決するか
      • 足らないモジュールのインストールが必要化
      • Apache / nginx のバージョンアップなどが必要か
    • 4-7. MySQL や MariaDB のエラー
      • テーブル個別の問題
        • ダメージを受けているテーブルが原因で Repair を行ったら解決するか
        • テーブルの最適化が必要で、定期的な最適化で解決するか
        • テーブルの構造の問題で、構造やインデックスなどプログラム部分の見直しが必要か
      • データベース個別の問題か
        • データベース個別の設定、構造やインデックスの指定などプログラム部分での見直しが必要か
      • サーバー全体の問題か
        • InnobDB (MyISAM) キャッシュ設定変更で解決するか (構造やインデックスの指定などプログラム部分での見直しが必要)
        • ハードウエアのパフォーマンスが落ちていて、交換が必要か。
    • 4-8. アクセス集中によるエラー
      • 攻撃を受けているので、WAF や、特定 IP や国全体ブロックで対応できるものか
      • 一時的なTV砲などのものなので、特定の時間だけサーバーを増強するか、クラウドに移行するか。
      • 恒久なアクセス増大によるもなので、サーバーの増強を行うか
    • 4-8. DNS や証明書エラー
      • DNS 設定によるエラーで、DNS 設定で解決するか
      • SSL 証明書の有効期限切れ等によるエラーなので、SSL 証明書の更新が必要化
    • 4-9. ハードウエアによるエラーか
      • 物理的に CPU 処理速度が足らないエラーで、サーバーの増強を行う必要があるか
      • 物理的に メモリが足らないエラーで、サーバーの増強を行う必要があるか
      • 物理的にディスク容量が足らないエラーで、サーバーの増強を行う必要があるか
    • 4-10. サーバー側のネットワークのエラーか
      • バランサーなど・ネットワーク設定の見直しで解決するか
      • ファイヤーウォール設定見直しで解決するか
      • ユーザー側のネットワークのエラーなので、インターネット回線・ファイヤーウォール・ネットワーク設定自体で解決するか
      • ユーザー側のネットワーク端末の問題なので、ブラウザの変更や、ウイルス設定の見直しで解決するか
  5. 解決策の提案
    • 原因が不明の場合もあります
    • 解決策を提示します
      • concrete5 コアーのアップグレード
      • パッケージのアップグレード
      • カスタムプログラムの修正
      • サーバーの設定変更の提案
      • サーバーの乗り換え提案
      • サーバー増強の提案
      • セキュリティ対策のご提案

 

調査で必要になるデータや作業

調査を行う上で、必要になるデータは、エラーの症状によって変わってきます。

できるだけ、お客様のご負担にならないように段階的にデータのお渡しをお願いしています。

 

  1. 最初に必要なもの (こちらでヒヤリングをし調査のお見積を行います)
    • エラー発生時のスクリーンショット
    • concrete5 管理画面のログ
    • Apache / nginx によるエラー発生時前後24時間の、access & error ログ
    • 使用しているサーバー情報。
      • レンタルサーバーであればプラン名とその仕様書。
      • オリジナルであればサーバーの仕様書
    • WAF、監視ツールなどを利用していればエラー発生時のログ
    • レンタルサーバー会社で特定のアップグレードなどの作業を行ったか
    • 制作会社やサイト管理者・編集者が特定のファイル・パッケージを編集したか
  2. 調査開始で必要なもの (この段階から費用が発生します。)
    • concrete5 管理者以上の権限、できれば id=1 のスーパー管理者権限
    • SFTP など concrete5 が設置されているファイルが置いてある場所のログイン情報
    • sudo 権限のある SSH アカウント情報
    • テストサイトがあれば、テスト環境の同じ情報
    • サーバーがコントロールパネルを所有している場合は、コントロールパネルのログイン情報
  3. 初期の調査後に必要なもの
    • 4-1. concrete5 コア, 4-2. 既存パッケージ, 4-3. パッケージカスタマイズ, 4-4. サードパーティーライブラリのエラーが原因の場合
      • サイトのオリジナルカスタマイズアドオンなどがあった場合に、開発者にヒヤリングが必要な場合があります。
    • 4-5. PHP 自体のエラー, 4-6. Apache や nginx のエラー, 4-7. MySQL や MariaDB のエラー​ であれば、状況に応じて下記の情報が必要になる場合があります。
      • php.ini の設定情報 
        • 特に default_charaset, mb_string 関連, post_max_size, file_upload 関連, memory_limit, max_execution_time など
        • キャッシュを利用していればキャッシュ設定
      • httpd.conf や nginx.conf 全文 (include されているもの含めて)
        • StartServer, MinSpareServers, MaxSpareServers, ServerLimit, MaxLients, MaxRequestsPerChild, Timeout, KepAlive, MaxKeepAliveRequests, KeepAliveTimeout などの設定値を中心に必要な場合があります。
      • phpmyadmin や MySQL への SSH 接続
      • 上記の設定を変更することがレンタルサーバーなどのプラン的に可能かの確認
    • 4-7. MySQL や MariaDB のエラー​
      • 個別のデータベースやテーブルの問題であれば phpmyadmin などのログイン情報
      • MySQL 全体のエラーであれば MySQL の設定情報
        • my.cnf などのデータ
          • InoobDB テーブルののエラーであれば InoobDB 関連の設定値
          • MyISAM テーブルのエラーであれば MyISAM 関連の設定値
    • 監視ツールの導入
      • 別料金になりますが、可能であれば、 New Relic や Mackerel.io などの監視ツールのインストールもお願いする場合があります。

 

 

同じソフト・サーバーを使い続けるとメンテナンスは必要ですね。

以上

＜ 前へ 一覧へ戻る 次へ ＞