C-limber(クライマー)株式会社 エンジニアの柿添です。

2月も終わりに差し掛かりました。

変わらずとても忙しいですが、
クライアントさま、パートナーの皆様方にはいつも感謝でいっぱいです。
いつも本当にありがとうございます！

リモートでの作業が多かった私ですが、
最近は出社することもしばしばあります。

C-limberではリモート中、「尋ねたいこと」や「相談したいこと」などあった場合、
すぐにボイスチャットで連絡を取り合っています。

リモート中コミュニケーションの点で問題があると感じたことはないのですが、
気軽な雑談などはやはり出社時のほうがしやすいですね笑

出社も交えつつ、健康に気をつかい(コロナ&花粉)ながら業務に励めたらと思います。

突然起こるサーバーダウン

現在世界中にさまざまなWEBサービスやゲームなどが存在します。

それらを利用中に突然サービスが利用不可になった経験はあるのではないかと思います。
Twitterのハッシュタグにもあるように サーバーダウン サバ落ち 鯖落ち などは広く知られているかと思います。

「鯖落ちしてる！」
「メンテナンスに入ったらしい」
「サーバーダウン中らしい」
「メンテが明けるとどうなる？知らんのか、メンテが始まる」

なんてのは良く目にしますね。

私もサービスが突然利用不可になった場合は確認のためTwitterで騒ぎが起きていないか見に行ってます。
特に業務で利用されているであろうサービスで、 「Google系」「GitHub」「Slack」「Chatwork」あたりが利用不可になっている際には、
とても騒がれていた記憶があります。

利用者目線からすると「早く復旧してくれー！」という感じなのですが、
エンジニアから見るとヒヤヒヤします…。

そもそもサーバーダウンって何なのか

我々はサーバーに対してリクエストを送っています、
ブラウザでページを開くにもリクエストを送り、レスポンスを受け取っています。

「○○のデータをくれ」
→「はい、○○のデータだよ」
「ページが見たいからページの情報を送ってくれ」
→「はい、ページの情報だよ」
「サーバに保存されているゲームのデータを送ってくれ」
→「はい、データだよ」

このやり取りの最中にどこかで止まってしまっていて、
レスポンスが全く返ってこない場合にはサーバーがダウンしていると判断して良いかと思います。

実際にはサーバーは一生懸命処理を行っている場合にでも、 全てのレスポンスに対して止まらずレスポンスを返し続ける状態でなければサーバーダウンとなります。

何故サーバーダウンが起こるのか

どのような時にサーバーダウン状態に陥るのでしょうか。
サーバーダウンが発生するケースを大別して見ていきたいと思います。

アクセス集中

前述の通りサーバーとのやりとりは「リクエスト」から「レスポンス」が返ってこなければ成り立ちません。
アクセスが集中した場合、大量のリクエストがサーバへ押し寄せ、
一つ一つを捌ききれずにレスポンスをまともに返すことができなくなりサーバーダウン状態に陥ります。

サイバー攻撃

悪意を持った第三者がサーバに対して攻撃を行います。
DoS/DDoS攻撃などが挙げられます。 大量のデータを送りつけたり、脆弱性をついて無限ループを発生させたりすることで、サーバーのリソースを食い潰し稼働できない状況に追い込まれます。

機器の故障

サーバーもコンピューターであり、データセンターやサーバールームに機械本体が存在します。
電源やマザーボード、記憶領域、冷却装置、ネットワークインターフェースカード、
等々様々な部品が存在しますが、それらは家電製品と同様故障する場合があります。
それら一部でも故障が発生した場合はサーバーが稼働できずにサーバーダウン状態となります。

AWSでは機器故障時もアナウンスがあり、
C-limberで管理しているサーバは常時バックアップからすぐに復旧が可能です。

サーバーダウンさせないためには

• アクセス集中に対するサーバーの強化
• アクセス集中に対する冗長化
• アクセス集中に対する構成の変更
• サイバー攻撃に対する対策
• 落ちないサービスを利用する

などが考えられます。

アクセス集中に対するサーバーの強化

処理に時間がかかってしまうような場合はそもそもサーバーのスペックを上げてしまうという手があります。
CPUをより強いものに、メモリを増強してしまうなどが挙げられます。
C-limberではインフラでAWSを利用しており、柔軟にスペックの変更が可能です。
ユーザー利用頻度やサーバの負荷からスペックを上げる際にも短時間でのスムーズなスペックアップが可能です。

アクセス集中に対する冗長化

レスポンスを返しきれれば問題ないため、台数を増やしてしまおうという考え方です。
1台で処理できない場合は2台、2台で処理できなければ…と増やして行きます。

大量にアクセスが増えてしまうことが想定される場合は、
数十台、数百台、場合によっては数千台用意する必要が出てくるかもしれません。

C-limberでは増加が見込まれる際のサーバー台数の確保、
負荷によるサーバーの自動増減等も可能です。

アクセス集中に対する構成の変更

レスポンスが返ってこなくなるサーバーダウンですが、原因はどこかに存在します。

• ネットワーク
• HTTPサーバ
• PHP等のスクリプト
• データベース

様々なものを利用し一つのサービスとして形を成しています。
システムが入った場合にはこれらの要素のどこかで止まってしまうだけでサーバーダウンします。
念には念を、様々な設定や対策を施す必要がありますね。

ではそれらを排除した構成にすればどうでしょうか。

• システムを経由せず静的なファイルだけを返す
• 静的なファイルはAWS S3(耐久性99.999999999％)に配置する
• 前面にはAWS CloudFlont もしくは CloudFlare を配置する

静的なファイル公開でこと足りるWEBサイトの場合は頑強な構成を取ることができます。

C-limberではこれらの構成での実績が多数あります。
リアルタイムアクセスが例え数千件あったとしても安定して捌き切ることが可能です。
静的ファイルで対応できるかもしれない場合には一考の余地アリな構成かと思います。

サイバー攻撃に対する対策

個人的に立てたどことも繋がっていないようなサーバのアクセス履歴やログを見ているだけでも、
日々多数の攻撃が繰り返し行われているのがわかります。 特にWordPressを狙った攻撃が一番多く、Movable Typeを狙った攻撃や、設定ミスの脆弱性を狙った攻撃は非常に多く見られます。

サーバのセキュリティ設定を眼鏡にすることはもちろんですが、
前面にWAFを置いて対策してしまうのが一番良いかと思います。

AWS WAFやCloudFlareによるWAFを設置し、
そもそもサーバへ攻撃が到達する前の段階で攻撃を止めてしまおうという考え方です。

C-limberではこれらのサービスを利用し攻撃対策を行なっているサーバー構成が多数あります。
サーバー,サービス,サーバ内の情報や個人情報を守るため導入を検討されてはいかがでしょうか。

落ちないサービスを利用する

ECサイトで一番ネガティブなのはサーバーダウンによる機会損失ではないでしょうか。
上述した様々な対策を施し万全な状態でユーザーを受け入れた場合、インフラのコストは高額なものとなります。

コストが見合わないといったことになりかねません。

C-limberではECサイトの運用にShopifyを利用しております。

• Shopifyのサーバは、365日24時間体制でサーバ監視されている
• Shopifyサーバのモニタリング結果は公表されている
• Shopifyのサーバは、1分間に1万件の注文を処理できる
• Shopifyは、CDNを利用し読み込みを最適化している
• Shopifyは世界各国からアクセスされても、表示速度が遅くなりにくい

等々機会損失を防ぎつつ、ユーザ体験を最大化する要素がたくさんあります。

C-limberではお客様のニーズに合わせたShopifyのカスタマイズ、公開・運用が可能です。
ECサイトの運用に安全性が高く安定した運用が可能なShopifyを選択されてはいかがでしょうか。

まとめ

サーバダウン、サバ落ちには様々な理由と様々な対策方法があります。
C-limberではお客様のニーズに合わせた対策方法を提案することが可能です。
サービス、サーバー構成、システムについて是非ご相談いただければと思います。