ECインフラリスク
ECを運営する上でインフラを考えることは重要なことです。ECの継続的な安定運用を目的にインフラ設計するわけですが、投資をすればするほどリスクは減ります。しかし、幾ら投資をしてもリスクがゼロになるわけではありません。正直いえば、どのレベルで割り切るかです。
では、どのようなリスクがあるのか、またどのような回避方法を取るのかを理解し、割り切り＝ポリシーを考えます。
インフラ構造
ECインフラは「止まらない」「性能」の視点で考えます。
１．「止まらない」は、冗長化（複数）構成で、1台が故障しても、他のマシンが稼働しているのでサービスは停止させない構成にすることです。
データベースサーバを設計する際に、ORACLEであれば、Oracle RAC ( Oracle Real Application Clusters ) の製品があります。Oracle のデータベースサーバが故障をしても、もう1台が稼働しているので、運用が止まりません。
WEBサーバは、ロードバランサー（負荷分散）を介した先のWEBサーバを複数存在させることで、対処します。複数台のどれかが故障しても、残りのWEBサーバが稼働しているので、運用は止まらないということです。ロードバランサーが故障したWEBサーバに対して信号を送らなくすることで、成り立っています。
それ以外にも、ロードバランサー、スイッチ、ネットワーク回線なども含めて、基本的には全ての機器、回線を冗長化することになります。
2．「性能」は、レスポンスです。動いてはいるが、遅くて使えないということもあります。止まってはいませんが、現実的には使えないという状態です。
このことを考慮して、ハードウェアでは、メモリサイズ、CPU、ハードディスクの回転数などを検討します。ここで悩ましいことは、どのサイズのメモリ、CPUを選べば性能に問題がないのか、わからないことです。理由は、どれくらいの同時アクセス数、トランザクション等が発生するのか、過去の数字からシミュレーションするしかないからです。実際には、万が一のことを考えてシミュレーション結果よりも、丸めて大きいサイズの機器を購入することが多いのではないでしょうか。
落とし穴
上記のことは、ECインフラを設計する際に、よく話されることだと思います。ハードウェアメーカーなどは、機器を販売、設置することが仕事ですから、お客さまの状況を聞き、最適な機器構成を提案します。このことは、ハードウェアメーカーの範囲ですので、理解できます。
また、ECはハードウェアだけでは成り立たず、ソフトウェアが必要です。ECを開発するSI企業は、ECに必要な機能をヒアリングして開発をします。SI企業は、要望される機能を実装することが仕事ですので、正しく動くことをゴールとしています。
実は、このことが落とし穴を発生させると考えています。運用には、動くというレベルと運用できているレベルがありますが、大きな違いです。SI企業は動くことを基本としているので、運用レベルはハードウェアに依存すると考えていることがあるためです。もし、性能が悪い場合は、サーバスペックを上げてくださいと要望するのである。でも、開発が終わるときには、実機テストもあるので、ハードウェアの購入も済み、設置が完了しています（もしくは、既存のハードウェアで稼働させたいということもあると思います）。この状況で、サーバスペックを上げるということは、追加投資が発生し、リリースを遅らせることになってしまいます。
何故、このような問題が発生するのかといえば、ハードウェアメーカー、SI企業ともに、専門分野には強いが、EC（システム）全体を見ることができる人財がいないためです。ECは、インフラとソフトウェアで構成されることは知っていても、お互いに自分たちの範囲外のことは、弱いので提案することもできず、相手に聞いてくださいという回答になってしまっているのです。
落とし穴を解決するボトルネック設計
ハードウェアは、故障した場合の対処ですので、0か１です。それに対して、ソフトウェア（ミドルウェア含む）は、0.7といったことがある。ようは、レスポンスが悪い状態です。
ECインフラを設計する際には、ボトルネック視点が大切です。ようは、アクセス数が増えれば、当然ながら性能は悪くなる。その際に、どのように対処するかの設計です。
事業が成功すれば嬉しいことではありますが、どこかでボトルネックが発生することは避けられません。
儲かっているのだから、投資をすれば良いという考えもありますが、利益は社員の給与や賞与の原資となるものですし、経営陣としては更なる成長のための投資として使いたいはずです。ですので、ボトルネックをマネジメントして、適切な投資だけにして、継続した運用ができるようにすることが必要になるのです。
では、どうすれば良いかといえば、アプリケーション設計で出来るだけWEBサーバに負荷を吸収させる設計とすることです。データベースがボトルネックになると、とても厄介だからである。データベースは、データの整合性を取るために集中管理されます。だから、ここがボトルネックになってしまうと、対処に困ってしまうのです。
チューニングという手もありますが、それは最初からやっておくべきことなので解決にはならないはずです。対処しようとすると、データベースサーバの置き換え、アプリケーション設計の見直しとなり、大掛かりになる。
また、データベースがボトルネックになり、アプリケーション設計の見直しコンセプトは、データベースへの負荷軽減であり、軽減される負荷はどこにいくかといえば、結局はWEBサーバなのである。
だから、最初からWEBサーバが頑張る設計は、とても重要なことなのである。もし、WEBサーバがボトルネックになったら、WEBサーバを追加すればよい。これは、データベースがボトルネックになった場合に比べて、とても安価で短期間で解決できるのである。
言われてみれば当然のことかと思われるかもしれませんが、実際にプロジェクトに活かされている例は少なく、このことを指示できるプロジェクトマネージャーも少ない。このことは、現実問題として、発注するお客さまから指示をしなければならないことになってしまっているのです。そして、その設計に妥当性があるのか、確認しなければならないのです。
まとめ
ボトルネックとなる箇所は様々で、上記以外にも存在しています。回線の太さもその1つです。
本来ならSI企業やハードウェアベンダーが担ってほしいところですが、期待できない企業が多いのも事実です。大手SI企業だからといっても出来ない企業は多数あります。また、大手企業の情報システム部門であれば、人財も豊富で経験者が指示することはできるでしょうが、中小企業や、オムニチャネルの時代において、これからECを本格化させたい企業にとっては、そのような人財はいませんから、悩ましい問題です。
会社規模により投資できる範囲もあるでしょうし、上記のようなことを理解している情報システム部の設置にも時間とコストがかかります。正直いえば、なかなか上記のことを経験している人は少ないと思います。ですので、自社で抱えるのではなく、クラウドサービスや、コンサルタントに依頼することも1つの選択肢かもしれません。クラウドサービス運営会社は、ノウハウがありSLAで保証しています。また、24時間365日の運用監視をしていますので、自社で運用をECインフラを運用する人財を確保する必要もなくなります。このことは、開発コストや運用コストの経費削減にもつながります。
また、SI企業にコンサルタントを含めるよう要望することや、コンサルタントに相談してみることで、リスク軽減と将来の無駄な投資を抑制することができると思います。
補足
ハードウェアは、どのように構成すれば良いのかという疑問が残る人もいると思いますので、ある企業での考え方をご紹介します。
まず、実際問題として、機器の故障率は製造ロットによっても違います。同じ型番であっても、故障しやすい機器、故障しにくい機器とあるのです。納得できないかもしれませんが、このようなことは、家電などの電子機器でも起きていることだと思います。ようは、想像していないことでもリスクが潜んでおり、リスクがゼロになることは、非現実的であるということを理解しなければなりません。
さて、どのように考えたのか？
・ 複数のハードウェアが同時に発生する確率は低い。
・ 故障時の保守を手厚くする。（24時間対応、数時間で部品交換）
・ 監視基準／体制を整えた。
全ての2重化をしたうえで、数時間のうちに全ての機器が全滅する確率はゼロに近いとしました。WEBサーバが複数台あるので、どれかが故障しても残りで十分に運用できる性能を持たせました。また、監視はデータセンターによる24時間365日の監視を依頼し、問題が発生する予兆、障害アラートがなれば、保守にある対応を実施する体制を整えました。この構成で、運用停止に追い込まれた話は聞いていません。障害は、数年でハードディスク交換が1回でした。このときも、保守手順に従い運用を停止せずに交換が完了しています。実際に、ネットビジネスのインフラをたくさん見てきましたが、技術の進歩もあって、運用停止に追い込まれ話は聞きません。
