昨今、パブリッククラウドが進化しており、システムを取り巻く環境が大きく変わってきています。 ここでは、あるECサイトを運営する企業に転職して、システム運用を任されたA氏の奮闘記をご紹介します。
目次
AWS ECサイト 運用状況
A氏が就職した企業はECサイトを運営しており、オンプレミスのシステムからパブリッククラウドのAWSへシステム移行を進めています。移行途中段階なので、まだ古い仕組みが残っており、監視システムは従来から使っているZabbixを使っています。
システムは移行途中ですが、ECサイトは止めることができないため、安定稼働をさせながら移行する必要があります。A氏はSIerとして働いていましたが、ECサイトの運営会社へ転職しました。担当して数ヶ月ですが、経験を活かしてAWSへのシステム移行と運用業務を行っています。
AWS ECサイト システム構成
A氏が担当しているECサイトのシステムはオンプレ環境とAWSの混在した環境となっています。オンプレ環境からアプリケーションをそのままAWSへ移行したこともあり、クラウドのメリットを活かせていない部分もありますが、ECサイトとしての機能は従来どおり稼働しています。
ECサイトへ訪問するお客様はパブリッククラウドのAWSへアクセスします。AWSのCloudFrontからEC2に構築したWebサーバー・APサーバーからDB（RDB）へアクセスする3層構成となっています。また、バッチ処理や従来の監視システムはオンプレミスの構成のまま残っています。これらの機能についてもすべてクラウド化を進める予定となっています。
販促キャンペーン
システムはオンプレとパブリッククラウドの混在した環境となっており、まだクラウド化が完了していませんが、A氏が担当しているECサイトで販促キャンペーンを行うことが決まりました。販促キャンペーンを行うと、目玉商品にアクセスの集中が発生します。
前回のキャンペーンは、オンプレ環境の時に実施し、今回は初めてAWS環境で実施することになります。A氏は、オンプレ環境の時は十分に捌くことができていたのでパブリッククラウドでも問題なく捌けるだろうと思っていました。
トラブル発生
さて、キャンペーンの当日です。午前10時に目玉商品の販売開始です。監視はオンプレ環境にある監視システムで、オンプレ環境とAWS環境の全サーバーの監視をしています。また、特別監視体制を組んでシステム状況をチェックするようにしました。
午前10時になった時、大量のアクセスがきました。最初のうちは順調に捌いていましたが、途中からAPサーバーのCPUが100％に張り付き出したことをZabbixで確認できました。A氏は、これはアクセス集中によるものなので、アクセスを捌くことができればすぐに落ち着くだろうと思っていました。予想通りしばらくするとCPUが落ち着いてきました。
しかし、またすぐにCPUが張り付きました。CPUの張り付きがしばらく続いた後、アプリチームより、全然商品が売れていないと連絡がありました。通常、キャンペーン時特有の状態は商品が売り切れたら収まるのですが、この日はCPUが高いまま収まることなく、商品も売れていません。
アプリチームから「サーバーを増設しろ」と言われ、AWS上でインスタンスを増やしましたが、商品が売れる件数は少ないままです。Zabbixで監視している主要なサーバーにはCPUの高騰以外に異常は見当たりません。
調査を進めた結果、原因はDBへのアクセスする一部のSQLの処理に時間がかかっていたことがわかりました。システムのログやアプリケーションのログを片っ端から調査したところ、アプリケーションのログから明らかに時間がかかっている処理が見つかり、そこから更にコードを見て分析したところ、やっと該当のSQL文に問題があることがわかりました。
アプリチームでアプリのSQLを修正しましたが、結局、原因が判明したのが遅かったため、商品が売り切れてシステムが平常に戻ったのは夜の9時でした。そして、SNS上では商品を購入することができないお客様から批判する投稿で溢れていました。
社長の逆鱗にふれる
キャンペーンの翌日、社長に呼ばれました。アクセス集中により商品を購入できないお客様からの苦情やSNSでの炎上を重く見た社長はご立腹。早速呼び出されました。
社長 「障害に対する対応があまりにも遅い。システムの監視をしていなかったのか？」
A氏 「従来の監視システムでCPU、メモリなど確認していましたが、アプリの処理までは監視できませんでした。」
社長 「監視はシステムに問題あるかないかではなく、お客様からのアクセスが問題ないかを見なければならない。お前達はシステム視点でしか物事を見ていない。重要なのはお客様がどういう状況になっているかだ。今回の件で、お客様からの信頼を失ってしまった。次回はお客様がどういう状況にあるかを把握して、すぐに対応しなさい。」
A氏 「わかりました。早急に対応策を考えます。」
社長 「それと、前々から思っていたが、いつもこのサイトのレスポンスが遅い！」
A氏 「（いや、レスポンスは今回の件とは別では・・・？）」
とA氏は心の中で思いましたが、口答えすると火に油を注ぐように社長の怒りが爆発しそうだったので、何も言えませんでした。
課題
今回、社長に指摘されたのは以下の2点です。
I. サイトの障害対応が遅い
原因を特定するまで時間がかかり過ぎたことによりお客様に迷惑をかけることになりました。この課題に対してはシステムの監視方法を変える必要があります。システム監視はシステム内から監視していますが、お客様はインターネットからアクセスしてきますので、お客様のアクセスがどうなっているのか把握できません。お客様と同じインターネットから監視できれば原因の特定まで時間短縮ができそうです。
II. サイトのレスポンスが遅い
これは今に始まったことではありませんが、前々からの社長の不満が爆発した形となりました。確かに、決してレスポンスは良いサイトではないとA氏自身も感じていました。この課題を解決するには、APM製品を導入する必要があるとA氏は考えました。APM製品を入れるとアプリケーションの内部まで処理を追えるので、性能改善が可能になります。
A氏は前職ではベンダーで働いていたこともあり、いくつかAPM製品を知っていました。しかし、同時にAPM製品が高額であることも知っていました。APM製品を導入すれば、解決出来る可能性は高くなりますが、この規模のECサイトではコストがかかりすぎます。提案したところで、社長が首を縦にふる可能性は低そうです。
解決策
ここまで、ECサイトを運営する企業の課題を、実際にあった話を交えて紹介しました。ここからは、この課題を日本語に対応したクラウド型監視サービス Site24x7（サイトトゥエンティーフォーセブン）で解決する方法を具体的にご紹介します。
まず初めに解決すべきは課題Iのサイトの障害対応が遅いことです。障害対応をするには、まず何が起きているか事象を把握すること（ステップ①）、原因を特定すること（ステップ②）、修正すること（ステップ③）で行います。今回の障害ではステップ①とステップ②の時間を短縮できれば障害対応が早くできそうです。
Site24x7で以下の範囲を監視することでそれを実現できます。
Site24x7のサイト監視
Webサイト監視では、先頭バイト到達時間（FirstByteTime）、最終バイト到達時間（LastByteTime）、DNS解決時間、総応答時間、稼働時間などのパフォーマンス メトリックがあります。
Webサイト監視機能の詳細：
https://www.site24x7.jp/help/getting-started/what-is-a-monitor.html
Site24x7にはインターネットからのサイト監視がありますので、お客様からと同じ条件でアクセスがどうなっているかを把握できます。監視のロケーションも選択できますので、一部の地域だけトラブルが起きているのか、全地域でトラブルが起きているかを把握することができます。
また、Site24x7にはユーザーの処理を確認できるリアルユーザー監視もあります。
Site24x7のリアルユーザー監視
リアルユーザー監視（RUM）では、Webアプリケーションの舞台裏のパフォーマンスを把握でき、エンドユーザー体験を正確に理解できるようになります。RUMは、アプリケーション インタラクションのパターンを視覚化し、Webサイトとアプリケーションへの訪問者に影響している問題を、リアルタイムで提起します。アプリケーション パフォーマンスが、ブラウザー、プラットフォーム、地域、ISPなど、あらゆる視点から分析可能になります。
リアルユーザー監視機能の詳細：
https://www.site24x7.jp/help/getting-started/real-user-monitoring.html
リアルユーザー監視を使えば、ページを訪れたお客様のページの応答時間が何秒かかったのか、ページを構成するcssやscriptごとに何秒かかったのかを確認することができます。
これでステップ①のお客様がどういう状況になっているのか把握することができます。更にSite24x7にはAPMの機能があります。
Site24x7のAPM
Site24x7のAPM機能は、個別のWebトランザクションのパフォーマンスをエンド・ツー・エンドで把握し、パフォーマンス低下のボトルネックを短時間で特定できます。例えば、DevOpsの現場では、Site24x7のサーバー監視機能でITインフラの状態を把握すると同時に、APM機能を利用し、アプリケーション サーバーのパフォーマンスとWebアプリのさまざまなコンポーネントまで包括的に把握できます。
APM機能の詳細：
https://www.site24x7.jp/help/getting-started/apm-insight.html
APMではアプリケーションの内部の処理まで確認することができます。平均応答時間が時系列でわかるため、いつから処理が遅くなっているか簡単に把握することが可能です。
次の画面ではトランザクションごとに処理のかかった時間のトップ5が表示されています。今回と同様のトラブルが発生した場合にはこの画面から調査することができます。
トランザクションをクリックすると、更に詳細なトランザクションごとに応答時間が表示されます。
これでステップ②の原因特定の時間短縮ができます。このようにSite24x7を導入すればお客様の状況を把握し、問題があった場合の原因調査まですることができ、対応がスピードアップします。また、常時アプリケーションのレスポンスやパフォーマンスを計測しておくことで、社長が指摘した課題Ⅱ「サイトのレスポンスが遅い」の解決にも繋がります。
そして、何より重要な点は低コストで導入できるということです。
プランと価格の詳細：
https://www.site24x7.jp/pricing.html
Site24x7を導入した結果、外部からの監視をすることでお客様の利用環境からの監視が可能になりました。レスポンスも数値として表示できるので、社長への報告でも説得力のある資料を作成できるようになり、社長の怒りが爆発することも減らせるでしょう。
まとめ
今回の事例では、AWS上にあるECサイトの課題に対しSite24x7で解決する方法を見てきました。アプリケーションパフォーマンスに関する問題の解決には高いコストが必要だと思いがちですが、課題を整理し、本当に実現しなければならないことを絞っていけば必要なコストは抑えることが可能です。是非要件に合わせてSite24x7の導入をご検討ください。
すべての機能を使えるFREEプランにサインアップ：
https://www.site24x7.jp/signup.html?pack=1&l=ja
免責事項：ここに記載されているすべての著作権、商標、商号は、元の所有者の所有物です。このWebページに含まれる情報は、一般的な情報提供のみを目的としており、そのような情報は、正確性、信頼性、または完全性について調査、監視、または確認されていません。 当社は、ここに含まれる情報への依存に起因する誤り、または損失に対する責任を明示的に否認します。
