×
  1. Magento 1.9 community のメンテナンスについて
みんなのお仕事相談所
発注者からの相談
サイト構築・ウェブ開発の見積もり・相場に関する相談

Magento 1.9 community のメンテナンスについて

解決済
回答数
23
閲覧回数
314
困ってます  : 困ってます

現在AWS EC2上にあるMagento 1.9 サイトが不安定ですが、原因が分かりません。

アクセスは一日 2000セッションほどで少ないと思うのですが、EC2上でCPU稼働率100%となりダウンします、定期的にこの現象が起き、増加傾向です。

まずは安定稼働のためのトラブルシューティングが最優先ですが、その他も相談できるWeb開発、サーバーサイドに詳しい方がいらっしゃれば幸いに存じます。
よろしくお願い申し上げます。

2019年06月19日 10:11

ベストアンサーに選ばれた回答

ソラ君さんからの回答

御社の問い合わせ内容は、エンジニアが必要ではないんですよ。
特定の開発言語のスキルは必要としない。

何が必要かと言えば「サーバー管理責任者」としての運用経験
つまり、そういう保守経験があるひとなら調査対応できる。

企業のシステム部などで、サーバー管理や運用を経験している人を探せばいい。

AWSのシステム保守を経由するのがよいだろうが、保守契約が高額ならだけどね。
大手企業の保守契約はとんでもない価格の場合が多いから。

俺はほとんど、設定の問題だと思ってますが、例外的にハードの性能が満たさないで
落ちる場合もあります。 設定が問題なければハードのスペックを疑うのが良いでしょう

オープンソースを利用している場合、それにバグや問題があればコミュニティでほぼ問題視
されまs。
何も話題になってない場合、設定やハードが性能要求を満たしてない場合が大半です。

ハードが性能要求を満たしてない場合システムを調査してもバグでも設定ミスでもないので
問題が表面化しません。
ログには出る場合もありますが・・・

サーバーの運用保守経験がある人間なら見ればわかると思うのでそういう人に依頼すると
良いでしょう。

こういうトラブル対応は開発エンジニアではないので、間違えないように

2019年06月20日 14:48
相談者からのお礼コメント

皆様貴重なアドバイスを本当にありがとうございました。私にとっても非常に良い経験になりました。皆様のおかげで、私が相談するべき方向性も理解できてきました、本当にありがとうございます。今後ともよろしくお願い申し上げます。

2019年06月20日 14:59

すべての回答

ソラ君さんからの回答

そういう内容は提供元のAmazonに対応要求するのが確実でしょう。
あそこは複数のサポートプランを用意してます。

AWS サポートのプラン比較
https://aws.amazon.com/jp/premiumsupport/compare-plans/

ビジネスサポートプランやエンタープライズサポートプランを検討してみてはどうですか?
AWSが高いと感じるなら他社のVPSを検討するのもありだと思います。

一概に言えないが、ハードウェアチューニング等が必要な場合は、
AWSで対応要求するとかえって高くなる場合も多くあります。
しかし、AWSに固執するならAWSの顧客窓口で相談するほうがよいでしょう。

2019年06月19日 10:43
ソラ君さんからの回答

Amazon→AWS

2019年06月19日 10:44
ソラ君さんからの回答

性能要求テストなど直接調査をしてないので一概に言えませんが
ハードの性能が業務の要求する処理に追いつかないのであれば、ハードの性能を上げるのが確実です。

しかし、価格が跳ね上がる場合もあります。
そういう場合は他社のVPSで高性能で価格が安い所を検討する方が利口な場合もあります。

基本的に提供業者を変更しても、ドメインを取得しているなら大きな問題にはならないはずです。
利用者はドメイン名でアクセスしますから。

2019年06月19日 10:52
相談者コメント

アドバイス有難うございます。AWSサイドにも相談してみます。私自身はエンジニアでありませんが通常稼働ではCPU20%以下で稼働する内容のサイトです。現在はm3xlargeを適応していますが、アクセスがない状態にもかかわらず、インスタンスを立ち上げるとすぐにサイトが落ちてします状況です。何らかの原因で異常な負荷になっていると思っていますが、このあたりの診断をお願いできる方はいらっしゃらないでしょうか。

2019年06月19日 10:57
ソラ君さんからの回答

大雨できる人は、沢山いると思います。

>>> 現在はm3xlargeを適応していますが、アクセスがない状態にもかかわらず、インスタンスを立ち上げるとすぐにサイトが落ちてします状況です。

そこまで絞り込めているのであればインスタンスを起動時の実行ログの監視とGoogle アナリティクス等を利用して調査・改善するのが一般的ですが
したとしても、最終的に対応相談はAWSのカスタマー窓口になるでしょう。
大体実行ログに詳細が出力されるんですよ

AWSに固執するならカスタマー窓口に相談するのが先決だと思いますよ。
強制はしませんが。

2019年06月19日 11:17
ソラ君さんからの回答

大雨できる人は→対応できる人は

2019年06月19日 11:17
ソラ君さんからの回答

>>>インスタンスを立ち上げるとすぐにサイトが落ちてします状況
ハードでなく設定の可能性もそこそこ高くなりました。
まぁ、設定が悪いのかもね

2019年06月19日 11:21
shinkakuさんからの回答

まず考えられるのはDBのINDEX不備とか攻撃ですね。
既にマルウェアに感染しているかもしれないし、SPAMの踏み台になっているかもしれません。

2019年06月19日 11:23
ソラ君さんからの回答

>>> まず考えられるのはDBのINDEX不備とか攻撃ですね。
>>> 既にマルウェアに感染しているかもしれないし、SPAMの踏み台になっているかもしれません。

そこは後で疑っても良いと思いますよ。
Magento 1.9と書いてあるのでOpenSourceでしょ。
プログラムの不備というのも世界レベルなので考えにくい。
設定ミスが有力かな。

また、感染とかはAWSだと後で疑ってもいいと思う。
大手じゃないかぎり、ハッカーも暇じゃないしウイルスとかだと特定のサイトでなく広範囲にでるだろうから。

2019年06月19日 11:29
shinkakuさんからの回答

>ハードの性能が業務の要求する処理に追いつかないのであれば、ハードの性能を上げるのが確実です。

最初にハードを疑うのはレベルの低いエンジニアですよ。

2019年06月19日 11:38
ソラ君さんからの回答

設定が確実ならオープンソースの場合プログラムの問題の可能性は低いです。

調査工数の費用や時間を考えるなら、設定に問題がないなら安くて早く解決出来る場合もあります。
低いとか高いとかでなくケースバイケースで柔軟な判断が必要だと思いますよ

2019年06月19日 11:40
※匿名希望さんからの回答

m3xlarge=メモリ15GB、4vCPU。これで立ち上げただけで落ちるとかw
中国かどっかから攻撃喰らってんじゃないの?
既にOS乗っ取られてないですかw?
topコマンド打ったら一番上に来るのはなんですか?
lastコマンド打ったら何が返ってきます?
/var/log/配下とかに大量にログ溜まってないですか?
間違いなく、何かまずいことが起きていると思いますね

2019年06月19日 12:48
※匿名希望さんからの回答

今すぐに手を打った方が良いと思いますね

2019年06月19日 12:49
ソラ君さんからの回答

>>> /var/log/配下とかに大量にログ溜まってないですか?
Logを確認するのが確実だろうね。
ただ、見方を知らないというか、分からない人だと思いますよ。
そういうことが出来る人ならここで質問しない。

だから、AWSの技術サポートにまず相談するほうが良いと思うけどね。
おれは、乗っ取りより設定ミスを疑ってますけどね。
可能性は0とはいわないけど、そういうのは1社でなく多くの企業で発生すると思うから。
オープンソースのコミュニティなどで騒がれてないなら、あまり考えつらいかな。と思うけどね

2019年06月19日 12:55
shinkakuさんからの回答

まず相談者の別案件の情報から推測したサイトの22ポートが全開放ですね。
あと該当サイトに接続すると直ちに別のドメインにリダイレクトされるけど何も帰ってこない。
IP直でデフォルトページが表示されるのでhttpdは生きている

おそらくMagentoの管理画面にもなんのアクセス対策をしていないのでは?
セキュリティ対策もへったくれもない業者が構築したもよう

・・・

ああ、、
てか管理画面のログイン画面が見えてしまった。。。
ここから乗っ取られてマルウェアを仕込まれた可能性が考えられる

匿名さんが言ったように大至急手を打った方がいいです

2019年06月19日 13:23
ソラ君さんからの回答

>>>おそらくMagentoの管理画面にもなんのアクセス対策をしていないのでは?
>>>セキュリティ対策もへったくれもない業者が構築したもよう

だから、設定の問題だと何度も言っているのだけど・・・
機能拡張等の開発依頼じゃないから、設定レベルが分かる程度で対応できるはず。 プロならだけど。
そんなエンジニアならどこにでもいる。
AWSの技術サポートでも十分な可能性も十分ある。 
開発エンジニアが必要とはかぎらない内容。 設定が理解出来る程度でいいんでないかな。


2019年06月19日 13:31
shinkakuさんからの回答

> だから、設定の問題だと何度も言っているのだけど・・・

ずいぶんアバウトですね
「何の」設定問題が「何を誘発して」「どのように」影響するのか推測してあげた方がいいです。

「増加傾向」が意味することは?

2019年06月19日 13:46
ソラ君さんからの回答

>>> ずいぶんアバウトですね
>>> 「何の」設定問題が「何を誘発して」「どのように」影響するのか推測してあげた方がいいです。

調査工数もタダではないんですよ。 ここのベンダーは無料奉仕するひともいるみたいだけど。
無料でやる気はないです。

無料でしてあげるなら、どうぞしてあげて下さい。
喜ぶと思いますよ。

有料ならクライアントが依頼先をまず、選び単価交渉する権利があるんですよ。
選ぶのはクライアントですね

2019年06月19日 13:49
shinkakuさんからの回答

いや別に無料でやれとは言って無いですよ

とにかく「ハード性能が悪い!」と言って顧客に余計なお金を使わせるエンジニアが多いので
少し気になっただけです。INDEXも効いていない数千万レコードのDBを操作のたびに走査するような
作りになっているとかざらにあります。それを「設定ミス」の一言で「ISPに相談しろ」というアドバイスを
私はしないので営業方針の違いですね。ISP責任範疇のレイヤーでもなさそうだし。

2019年06月19日 14:10
ソラ君さんからの回答

>>> とにかく「ハード性能が悪い!」と言って顧客に余計なお金を使わせるエンジニアが多いので
>>> 少し気になっただけです。

OpenSourceの場合コミュニティで問題がでてない場合、大半が設定なんですよ。
ただ、プロに依頼して設定が間違いないというなら、ハードを上げてみたら。
という事です。

要は設定に問題なくコミュニティなどで問題が報告されてないような物を
Sourceから解析して調べてたら調査工数だけで高くなるということです

なので、「ケースバイケース」だと書きました。

ここのQ&Aは無料アドバイスなので、ここで提案できることはアバウトです
そこまで俺は無料奉仕しません。
ちゃんと調査するのは、クライアントが依頼する業者に要望すればいい話だと思います。

2019年06月19日 14:17
CodeLabさんからの回答

複数の原因が考えられるので、この情報だけでは判断はできないかと思います。
どのようにしたらよいかは、場合によりますので、まずは調査ということで依頼を出してみてはいかがでしょうか?

2019年06月19日 16:48
相談者コメント

皆様、貴重なアドバイス有難うございます。
ご察しの通り、私はユーザー側の人間でして内部ソースやサーバー側のことは素人です。

>>複数の原因が考えられるので、この情報だけでは判断はできないかと思います。
>>どのようにしたらよいかは、場合によりますので、まずは調査ということで依頼を出してみてはいかがでしょうか?

おっしゃる通り化と思います、そのようにさせていただきたく存じます。
引き続きよろしくお願い申し上げます。

2019年06月19日 17:32
xxxxxxxxxxx12200さんからの回答

保守会社とちゃんと契約することですよ。

2019年06月20日 13:00
ソラ君さんからの回答

御社の問い合わせ内容は、エンジニアが必要ではないんですよ。
特定の開発言語のスキルは必要としない。

何が必要かと言えば「サーバー管理責任者」としての運用経験
つまり、そういう保守経験があるひとなら調査対応できる。

企業のシステム部などで、サーバー管理や運用を経験している人を探せばいい。

AWSのシステム保守を経由するのがよいだろうが、保守契約が高額ならだけどね。
大手企業の保守契約はとんでもない価格の場合が多いから。

俺はほとんど、設定の問題だと思ってますが、例外的にハードの性能が満たさないで
落ちる場合もあります。 設定が問題なければハードのスペックを疑うのが良いでしょう

オープンソースを利用している場合、それにバグや問題があればコミュニティでほぼ問題視
されまs。
何も話題になってない場合、設定やハードが性能要求を満たしてない場合が大半です。

ハードが性能要求を満たしてない場合システムを調査してもバグでも設定ミスでもないので
問題が表面化しません。
ログには出る場合もありますが・・・

サーバーの運用保守経験がある人間なら見ればわかると思うのでそういう人に依頼すると
良いでしょう。

こういうトラブル対応は開発エンジニアではないので、間違えないように

2019年06月20日 14:48
ソラ君さんからの回答

あと、補足しておくと・・・上文で書いてある通り、乗っ取りとかの可能性はほとんどありません。
0%とはいいませんけどね。

オープンソース系でそういう問題が発生していれば、コミュニティでほぼ問題視され、大騒ぎになります。

過去にもWordPressの乗っ取り問題やStrutsフレームワークでの乗っ取り問題が発生しましたが、そういうのは被害が1社で留まりません
また、ニュースになったりもします。

何も騒いでないと言うことは可能性が限りなく低いでしょう。
何もセキュリティを考慮して設定してないのでダダ漏れしてる可能性はありますが。

サーバー管理経験がある人ならちゃんと対応できるので依頼すればいいですよ。

2019年06月20日 14:57
ご意見箱

× 今後表示しない